redmine.tokyo 15 所感

2018年11月14日 0 イベント

2018/11/10 (土) に参加した redmine.tokyo 15 のレポート。前回は登壇したが今回は聴講のみ。

開場前

  • 前回の参加で会場までの交通と時間を把握したつもりだったが、到着はギリギリになった
  • そのため田町駅でそばを食べるのを諦めてコンビニのサンドイッチに
  • 前回登壇していたのと Twitter でキャラ作りの一貫として前回と同じ格好でゆく、と書いたためか受け付けで私だと個体識別された
  • 時間ギリギリのため最後方端に座る、そのためスライドの下 1/3 ぐらいが見えない…

Redmine 4.0 新機能ピックアップ

Redmine 4.0 アウトライン

  • 機能追加とバグ修正は約 200 件、2018/11/9 時点の進捗率は 98%
  • Ruby on Rails 5.2 移行により多くのプラグインが要修正となるだろう
  • MySQL 5.1、PostgreSQL 9.1 以前がサポート外
    • RHEL/CentOS 6 系の yum 標準リポジトリーで入らないバージョン
    • 私が職場で運用している Redmine 環境が CentOS 6 系なので移行しなければならない
    • CentOS 7 へ移行するとして、ついでに Redmine と MySQL を Docker コンポーネント化することも検討したい
  • バージョン番号による変化の話
    • セマンティック バージョニング的な運用
    • Major = フレームワーク更新など大きな影響のあるもの、数年に一度
    • Minor = 多数の機能追加、年に数回
    • Patch = バグ修正や軽微な改善、発表にはなかったが過去の運用を見るに随時

新機能ピックアップ

  • Textile/Markdown プレビューのタブ化
    • GitHub のような感じになる
    • タブ切り替えでページ全体ロードにならなければ便利そう
    • 従来の下側表示は見辛かった
    • うちの Redmine は Markdown にしてあるので、チケットや Wiki に書くときはリアルタイム プレビュー付きエディター (Atom や vscode など) で編集してから貼り付けてた
    • 小〜中規模の文ならこの新プレビューでまかなえそう
  • コンテキストメニュー表示用アイコン
    • チケット一覧がコンテキストメニュー対応しているのに気づきにくい
    • そのため、メニュー表示アイコンを追加した
    • 確かにこの機能、教えるとビックリされる
    • メニューはチケット一覧から一気に担当やステータスを変えられるなど便利なので、この改善により周知されてほしい
  • チケットのウォッチャーで自分以外も選択可能に
    • この機能を前提とした新しい管理手法ができるかも?
    • 少し興味がある程度でウォッチャーに追加するような運用をしていると、フィルターとして有効に機能させるのは難しいそう
  • ユーザーのフィルターにロック中ユーザーを表示
    • 例えば退職したユーザーが担当になっているチケットを探せる
    • 昨年、ちょうどこの用途でこの機能を求めていた時期があった…
  • 親プロジェクトから子プロジェクトのチケットを作成
    • プロジェクト子へ切り替えずに済む
    • プロジェクトを細かく階層化しているなら便利そう
    • うちは極力、浅い階層に収める運用なので使い機会はなさそう
  • コメントの表示順が新しい順なら編集フォームを上に表示
    • 私はこの表示順で使用しているため、待望の機能だ
    • これまでフォームが最下段になるのは地味にストレスだった
    • 前述のプレビュー タブ化と並んで嬉しい
  • チケットリンクの新書式
    • ##123 と書くとトラッカーと題名も表示される
    • 議事録や Release Notes ページにチケット一覧を作成するなどで役立ちそう
    • いままでは普通のリンクでこれをおこなっていた
    • 普通のリンクだと題名変更などで手動追従が面倒だった、自動になるのはありがたい
  • 添付ファイルを連続プレビュー
    • プレビューに前へ次へボタンが追加
    • これらのボタンで前後移動できる
    • 画像はサムネイル表示して興味あるものだけクリックする感じだったから、プレビュー モードがあることを初めて知った
  • 添付された動画・音声ファイルの再生
    • プレビュー画面で再生可能になった
    • この流れで YouTube や Twitter 埋め込みにも対応してほしい
  • CSV エクスポート時にエンコード選択
    • CP932 以外も選択可能に
    • Excel 以外で読むため UTF-8 にできたりする
  • ユーザー一覧の CSV エクスポート
    • チーム単位をまとめてユーザー追加する際に便利そう
    • 受託などで取り引き先の関係者をまとめて追加する、という用途も考えられる
  • ガントチャート右クリックでコンテキスト メニューを表示
    • メニューからステータスや担当者の変更がおこなえる
    • ガントチャートを利用する動機づけの一助になるだろう
  • ガントチャートの表示幅リサイズ
    • ドラッグ & ドロップで変更可能になった
    • コンテキスト メニュー編集とこの機能の流れで、将来はグラフも標準でドラッグ & ドロップによる伸縮編集されることを期待する
  • マイページに活動ブロックを追加
    • マイページ、うちでは意外に使っている人がいるので喜ばれそう
  • リポジトリ画面のファイルと差分表示をタブで切り替え可能に
    • レビュー時に便利そう
    • 編集フォームやこれなど、画面遷移する箇所はタブ化を推進するのかな?
    • SPA 対応は難しくても静的に読み込んでおいたものをタブ切り替えするようにしておけば、画面遷移のストレスをなくせる
    • SPA 化の布石にもなるだろう、タブ切り替えを React や Vue のコンポーネント描画に移行すればよいので
  • シンタックス ハイライト対応言語が大幅に増えた
    • 約 20 から約 130 に
    • ライブラリーを CodeRay から Rogue へ移行した
    • Apache や nginx 設定ファイルなども対象に
    • これまで対応言語が少なすぎて指定なしにせざるを得ない場面が多々あったから非常に嬉しい
  • 動作環境の変更
    • 冒頭で触れていた環境面の話の詳細
    • MySQL 5.1 以前がサポート外に
    • PostgreSQL 9.1 以前がサポート外に
    • RHEL/CentOS 6 系は要注意
    • Ruby 2.5 対応、2.2.1 以前はサポート外
  • Redmine 4.0 は…
    • もうすぐリリース予定
    • 地味だが品質向上と小改善を重ねたバージョン

おまけ

  • Redmine に新機能が追加されるまで
    1. 誰かが redmine.org にチケットを作る
    2. 何かのきっかけ、ここで Redmine への疑問ツイートに前田氏がリプライしているスクリーンショット
    3. 誰かがパッチを書く
    4. 誰かがコミット
    5. 次期バージョンに入る
  • redmine.org のチケットは日本語 OK
    • 日本語で書いても Google 翻訳などを利用した英訳を併記してくれればよい
    • チケットを書くのが楽 (心理面でも) だし、日本人の開発者に意図が伝わりやすい
    • 私も GitHub issues で Google 翻訳に頼ることがある
    • 最近は精度もよくなってるので機械翻訳してから露骨な誤訳を手直し、というのは負担が少なくてよい

View customize 1.2.0 の紹介

View customize plugin について

  • Redmine の画面をカスタマイズ可能
  • 特定の画面に対して JavaScript や CSS を埋め込む
  • これを利用してプロジェクトのヘッダーを変更したり画面の動作を変えられる
  • Web フロントエンド部分を操作するだけ、というのがポイントで Redmine を再起動せずにカスタマイズできる
  • 参考 View customize pluginを使いこなす

v1.2.0

  • リリース内容
    • コード挿入一を選択可能に
    • ユーザーやプロジェクト情報へ JavaScript からアクセス可能に
    • ローカライズ対応、日本語リソースを追加した
    • コメント欄を追加、一覧表示でコメントがあればそちらを表示
    • 一覧をソート可能に
    • …etc
  • コード挿入位置の選択 (Insertion position)
    • Insertion position という項目を追加、コードをヘッダー以外の場所へ埋め込める
    • 挿入位置を利用した制御について紹介
    • Redmine の操作で DOM 構造が変化した際、挿入位置によっては一緒に再構築されるためデータ変更に自動で追従できる
    • 埋め込み位置が存在しないページではコード埋め込み処理がスキップされる
    • スキップを応用して Path pattern (埋め込み対象ページ) を .* で全対象にしておき、Insertion position で制御するテクニックもあり
  • ユーザーやプロジェクト情報へ JavaScript からアクセス可能に
    • Twitter でこの情報は動的 or 静的取得のどちらだろう?と書いたら静的だと教えていただいた
    • 静的ゆえリアルタイムな変更追従は無理だが実運用で困ることは滅多にないだろう
    • ViewCustomize.context から参照可能
    • 情報が増えたことにとり View customize 側を変更しなくてもユーザーの JavaScript で処理できる範囲が広がる
    • 例えばグループ情報を利用してスクリプトの適用を特定ユーザーに限定する、など
  • カスタムフィールドを使った制御
  • ユーザーのカスタムフィールド
    • ユーザー自身が情報を追加できるのは大きい
    • 他システムやサービスの token を入力して、それと連携するとか
  • ローカライズ対応
    • 日本人にとって UI などが母国語でないだけで利用時のハードルが上がる、これを解消
    • 他の言語もがんばりたい
  • 一覧をソート可能に、コメント欄を追加
    • View customize 一覧の項目にコメントがあればそれを、なければ従来どおりコードを表示するようになった
    • 説明を書く際、従来はコード冒頭にコード ドキュメントとして記述するしかなかったが、これからはコードと切り離されたコメントを管理できようになったためコードを汚さずに済む

redmine導入における効果的なヒント

導入ヒントの概要

  • マズローの欲求 5 段階説などをベースに図示
    • チームのふるまい、利用したい業務、定着までの難敵を整理
    • 難敵の解決や利用業務の定着に必要な「さくせん」を考案、ここで「とくぎ」の概要をまとめる
    • 「さくせん」に基づき「とくぎ」を詳細化
  • 前回の LT に続き、国産 RPG などでよく用いられる「さくせん」や「とくぎ」などの語を採用
  • 目的を達成する動機づけとして近年ゲーミフィケーションの引用される機会が増えた
  • ゲームに親しむものとしては、楽しみながら自然とゲーム攻略のために分析や対策を練っているもので Redmine のようなタスク管理システムも似た存在だと感じている
  • よってゲーム、特に RPG やストラテジー系シミュレーションの世界観は Redmine の理解に有効ではなかろうか?

効果的な導入に向けての研究方針

  • チームのふるまいと対象業務 = マズローの欲求 5 段階説
  • 難敵 = TOC の抵抗の 6 階層
  • さくせん = 難敵の克服、対象業務の精度・成熟度の向上と維持
  • とくぎ = 武器と防具、仲間、魔法

本編

  • マズローの欲求 5 段階説と TOC の抵抗の 6 階層について
  • 難敵を克服して対象業務の制度と熟練度をあげる
  • マズローの話
  • TOC、あとで調べる
  • 自律的ナレッジを目指すために
  • 抵抗の 6 階層について、よくある意見をまとめてみる
  • 「さくせん」と「とくぎ」の内訳
  • 心理的安全性の話
    • 心理的安全性は意図的に作るものではなく後からついてくるもの
    • チケットや Wiki に何かを書いておくと、誰かがそれを見て助けてくれる
    • これは心理的安全性を意図したものではなく、課題や問題を衆目に晒すことにより結果として助けを得られたことになる
    • このような体験が重なることで、課題は問題を自己検閲 (こんなの書いて意味あるのだろうか?的な) するよりもいっそ書き出したほうがよい = 忌憚なく出力する = 心理的安全性が確保された状態になるのではないか
  • 仲間の話
    • どういう人が関わると Redmine をうまく回せるか?
    • 職場ではここに挙げられてるような活動をしている、Redmine 管理者であり、方針の提案やヘルプもおこなう
    • 前回の私の登壇でもこのあたりの話をした
  • 人に聞くなチケットに聞け
    • いま私の職場でも課題になっている問題
    • Redmine 以外にも Slack があるため、そちらで作業依頼と相談がおこなわれる
    • Slack ならテキストな分、まだよくて口頭もかなり多い
    • 部署単位で席が近いゆえ、口頭のほうが早いというのもある
    • テキストで対話することに抵抗を持っている人が多いと感じる
    • テキストはきちんと推敲されたものにしなければ、という雰囲気
    • もっと気軽に、という話を常々しているのだけど長年の文化的なものなのでなかなか理解されない
    • プログラマーであれば BTS としての導入動機があり、チケット蓄積で過去の仕様決定やバグ修正の考察を知れるため「チケットに聞け」の利点をわかりやすく体感できるのだが…
    • これを「説明」するのではなく、なんとか「体験」させたいのがここ数年の私の課題
    • うちの場合、Wiki はよく使われているので「Wiki に聞け」は受け入れられている感じ
    • Wiki は書きっぱなし可能だが、チケットで「対話」するのに抵抗があるのだろう
  • Redmine アップデート センターはよ
    • この意見は様々な人が言及してる
    • インストールと互換検証が自動化されたうえで導入されれば、プラグインやテーマを積極採用できる
    • うちはプラグインによる環境破壊 (実際、Redmime が起動しなくなった経験を何度もしている…) を避けるため排除しているのだが、本当は導入したい
    • アップデート センターやプラグインとテーマの配布システムを構築する気がないのであれば、著名プラグイン (前述の View customize とか) を本体に取り込んでほしいものだ
    • Redine を Docker 運用すれば気軽に環境を捨てたり再構築できるため、本体・本家に頼らずプラグイン運用しやすくなるかもしれない
  • 発表速度
    • 前回のブログで速度について書いたためか、登壇後に今回の速度はどうだった?と氏に尋ねられる
    • 前回を 2 倍速としたら今回は 1.2 倍速と回答

Redmine使いが注目したJIRAの機能

JIRA のイケてる機能

  • カスタムフィルター
    • Redmine でもおなじみ、チケットなどをフィルタリングするための機能
    • ベーシック モードは Form UI を操作する、よくある形式
    • JQL という簡易スクリプトで条件式をかける
    • 複雑な UI を用意するのではなく、いっそスクリプトで対応しようというのが面白い
    • ありがちな AND と OR 以外に WAS というのがある、現在または過去にその値が設定されているか?という機能
    • スクリプトは学習コストこそ嵩むが自由度は高く、テキストなので理解していないユーザーとも共有しやすい (コピペで済む) メリットがある
  • アジャイル機能
    • かんばん
    • バックログとスプリント
    • レポート機能が強力、分析好きにはたまらないだろう、企業や大きなチームを対象としているであろう商用ソフトウェアらしさともいえる
  • イベントと通知
    • イベント = チケットの内部フック
    • イベント単位のメール通知、Redmine に比べてかなり細かく挙動を制御できるようだ
  • チケット ワークフロー
    • ステータス遷移のカスタマイズ
    • ワークフローのダイアグラム表示がよい感じ
    • Redmine のマトリクス形式も「この範疇を超えることはやるべからず」という複雑化を防ぐためのギプスとして好ましいとは思うけど、複雑にならざるを得ないならダイアグラムかスクリプトを必要とするだろう
    • 簡易的な承認フローの実装

Confluence 連携

アップデート機能

  • 標準でアドオンのインストールと更新を自動管理する仕組みが提供されている
    • アドオン登録することでサブスクリプションによる収益を期待できる
    • これはアドオンを継続的にメンテナンスする動機づけになる
    • 結果、アドオンが死ににくい
  • アドオンはマーケットプレイスで提供
  • ビジネスとして回せているらしく、もりのあさ氏の企業で導入しているアドオンは結構な額を支払っているとのこと
  • Redmine にもこうなって欲しくはあるが、大手資本とビジネス専任者がいないと企画倒れになるだろう
  • Redmine が参考にするとしたら WordPress.com あたりか

困ったところ

  • WBS が組みづらい
    • エピック、ストーリー or タスク、サブ タスクの計 3 階層まで
    • Redmine のように階層を細かく深く管理できない
  • 機能が多すぎて稼働させるまで時間がかかる
    • 「とりあえず動かす」には心理的に重い
    • Redmine だとプロジェクトの立ち上げは機能的にも心理的にも軽すぎて縛りを入れないと雑にプロジェクトを量産できる問題がある、うちも社員個人が Wiki を分けるためだけにプロジェクトを量産してて収束させるのに苦労した
    • WBS もそうだけど、ゆるさと厳しさ (縛り) のさじ加減は難しい
  • 大半はシステム管理者しか触れないため負荷が集中する
    • Redmine だとプロジェクト単位の管理者に機能管理の相当部分を委譲できるから分割統治に向く
    • 一方、運用ルールを明確にしないとプロジェクト管理者ごとに全くことなる運営をしてプロジェクト間のやりとりで問題になったりする
    • 完全な専任を立てられれば JIRA の一極集中も悪くはない
    • 私は分割統治の利点のほうが大きいと思うので Redmine 方式でルール縛りするほうが好み

ある工場の Redmine 2018 ー私が愛用しているプラグインー

最近のできごと

  • Redmine 絡みで IoT やってる
  • 前回のデモは面白かった
  • 今回のデモ、スマートフォンのロックを解除してください、ショートしました?、で失敗 (会場笑)

いいプラグインを使おう

  • プラグインを使うと魅力的な機能が入る
    • しかしバージョンアップ検証が大変
    • でもプラグインを使いたい
    • いいプラグインを使えばいい
    • プラグインの信用度をもって「いい」としている
    • 評価が高かったりちゃんとメンテされていたり
  • 使用しているプラグインの紹介
    • 今回登壇で紹介された View customize や Issue Template など
  • プラグイン使わない派の私としては色々と考えさせられた登壇
    • 私がプラグインを使わない理由は互換性と環境破壊
    • 本登壇で「いいプラグイン」とされているものなら「現在は」問題はないだろう
    • しかし「これからは」については作者に委ねられている
    • Redmine のシステムとして互換性を自動検証する仕組みがないと「作者の努力」に依存することとなり、ここが不安
    • これさえ解決すれば入れたいプラグインはいくつもある
    • WordPress プラグインの場合、自動更新、互換性の自動検証、ユーザー レビューがあるため安心して利用できる
    • Redmine として導入しやすいのは互換性の自動検証だろう、Manifest 的な設定を用意して対応バージョン範囲を明記し、それが本体と一致しないなら無効化すればよい
    • 環境破壊の問題はグループ ディスカッションでも議論した

LT

プロジェクト管理ソフトの群雄割拠をどうやって勝ち抜くか?②

  • 岩崎成記氏
  • 資料
  • リソース予約プラグイン
  • JavaScript の fullcalendar を使用
  • プラグイン開発メモ
  • Ruby on Rails 学習 400、開発 300 時間を費やす
  • Ruby on Rails 以外にも DB など広範な知識が必要
  • よい IDE 見つからず、エディタによる開発、毎回 Redmine リロード
  • テスト環境を用意するもの大変
  • プラグインではなくテーマだが動作確認は Docker がオススメ
    • Redmine コンテナを sameersbn/redmine にすれば複数バージョンも同時に試せる
    • 私は Docker Compose で sameersbn/redmine と mysql を連携して動かしてる
    • ファイル システムのマウント方法による違いのためか、Vagrant だと CSS/JS が更新されても Redmine 本体をリロードするまで反映されないが Docker は Web ブラウザーのリロードで即時反映される
    • Docker は起動と終了も高速なので気軽に動作テストできて嬉しい
  • Vagrant なら onozaty 氏の Redmine Vagrant Box シリーズがよい
    • Redmine のバージョン追従も迅速
    • Docker 移行前はこれを利用していた

あなたは、ねぎ派?ぶどう派?『JavaScriptで選択を便利に』

  • yamasaki24
  • 資料
  • Redmine の画面カスタマイズは JavaScript でおこなえる
  • 実例として複数 select box の連携をとりあげる
  • 大項目、中項目の select box がある
  • 大項目でアイテムを選ぶと中項目がそれにあわせて絞り込まれる
  • 実装の解説
  • ガントチャートのバーを動かす話、これは本体側に取り入れてほしい

Redmine本家コピー+投票サイト作成 (Python-Redmine 利用事例)

  • y503Unavailable
  • Redmine本家コピー+投票サイト作成(Python-Redmine利用事例)
  • Redmine への要求レベルは高度化する
  • Redmine 自体に手を入れず汎用言語によりユーザー自身が手を入れられるようにする
  • Python-Redmine を利用して複数 Redmine からデータをコピー
  • チケット画面に投票とタグ機能を追加
  • 作成手順と環境について
  • Redmine は VPS に Ansible で入れている
  • Python-Redmine で外部から Redmine を操作可能

基本手順の順守

  • 齋藤
  • 基本手順の順守と redmine
  • マネージメントの話
  • 議事メモ
    • 私が会議のオーナーでは似たような感じで運用している
    • いわゆる議事録ドリブン
    • 事前に課題 (あれば補足も) を箇条書きした Redmine Wiki を作成、これを議事録の候補とする
    • 事前に議事録の候補を読んでもらってから会議を実行
    • 開始は議事録の候補をプロジェクターなどで投影、課題に発言や決定事項をリアルタイムに書きながら進行
    • 司会 (オーナー) は書紀を兼ねる、エディターのスクロールがそのまま会議の進行になる
    • 司会能力とタイピング速度の両方を要求されるので難しそうだが、実際は議題を読んで各人の意見をタイピングするだけでも場が持つので司会能力はそれほど必要ない
    • 議事録の候補段階で、この登壇で示された要素を書けていれば更に楽だろう
    • 逆にこの程度は用意して事前に読んでもらう (共有してもらう) ぐらいでないと、人を集めて話しても無駄な雑談や脱線が増えるだけだとも思う
  • 課題管理
    • チケット発行基準で「発生翌日までに自分で対応可能なものは除き」というのは面白い
    • 既にチケット運用できているならよいが、これからチケット管理を取り入れるチームは工数よりも手を動かしたいだろうから心理手面で導入によいルールである
    • 私は些細なメモや考えごともチケットで、というようにチケット作成の雑さを許容して「チケット運用経験」を先に積んでもらう方法を採っている
    • チケット運用 = 起票して終了する、という経験を積んでもらってからの方がタスク管理について説明しやすいと考えている
    • なにかを学習する入門方法として経験と理論のどちらを優先するか?という話
  • 計画管理
    • トップ ダウン、ボトム アップどちらを採るか?で変わる話
    • メンテナンスの負担を考慮する、というのはよい視点

小さく始めるRedmine

  • びくんびくん氏、読み上げるだけで笑みのこぼれる命名を見習いたい
  • 小さく始めるRedmine 第15回redmine.tokyo勉強会LT資料 – Speaker Deck
  • Redmine 導入にかつて失敗している
  • 再導入にあたり気をつけたこと
  • いろいろ制限する
  • プラグインも View customize ぐらい
  • 禁止事項をひたすら列挙
  • Redmine アンチパターン、よくわかる
    • リテラシーの話をすると知識を持つ側が教条主義に陥りがちで、私もそうなることがある
    • 味方を増やすのが最優先、そのためにはリテラシーよりも具体的な方法を
    • 「具体的な方法」としてルールや入力項目が多すぎるとビビらせてしまうので、本登壇のように積極的に縛って見えるもの触れるものを減らすのは有効
    • うちはトラッカーを減らした、標準で有効になってる開始日や工数、進捗率も削除したいぐらい
    • GitHub issues + 担当者、ぐらいだと受け入れてもらいやすそう

Redmine Rest API の現在の困りごと

Redmine Community on Discord (Video Message)

  • Max Johansson 氏
  • Redmine on Discord: Intro – YouTube
  • Discord の動画メッセージ
  • 設備や通信のトラブルか、Max 氏とのオンライン対話がなかなかうまくゆかず
  • 会場から Max 氏への質問、そちらでの Redmine を取り巻く状況はどのような感じか?
    • Redmine を使っている人はあまりいない、Gitlab とか使っている
    • コミュニティを立ち上げたことで状況がかわるかもしれない
    • ボランティアでやってる、今後に期待している

今後のRedmineコミュニティの方向性について

  • akipii
  • 今後のRedmineコミュニティの方向性について #redmineT
  • コミュニティをどのように発展させるべきか?
  • 1 スタッフとしての意見
  • Redmine は日本人に向いているのでは?
  • 大阪と東京、ふたつのコミュニティが 2011 年からゆるく長く続いている
  • コミッターが JPL 氏を含めて 3 名というのは知らなかった
    • コミュニティーを拡大しても要望反映のリソース不足が問題になりそう
    • 3 名にしては非常によくやっているとは思うけど、心配

Redmine本、売ってみた。

  • たかのあきこ
  • 今回は欠席?時間がかなり押しているので登壇はスキップしてひとまずグループ ディスカッションに移行
  • 17:40 に合流、開始
  • どうやら保護者会があったそうで、そのため遅れたとのこと
  • スライドが手書きイラストになっててよい、絵が描けるのは強み
  • 本書、技術書典 5 でブースを訪れた時は売り切れていた
    • なので挨拶だけでも、と話しかけたらご厚意によりコピー本をいただいた
    • 感想は後ほど技術書典 5 感想の頒布物編としてブログに書く予定
    • 本書の感想は既に書いたのだが、他に大ボリューム本がいくつかあってなかなか記事がまとまらない…

グループ ディスカッション

Redmine テーマ開発

  • 私のほうから Redmine テーマについて議題をだす
  • redmine.tokyo 14、15 と参加したが Redmine テーマに関する話はほとんどないため
  • 今回だと Max 氏のコミュニティー話で Redmine 標準テーマのモダーン化が検討されている、というものぐらい
  • Redmine 標準テーマ以外を使っていますか?→GitHub 風テーマ (多分 makotokw/redmine-theme-gitmike) が 1 名、あと確か A1 がいて、他の人は標準テーマだった気がする
  • プラグインだと具体的な機能拡張が動機になる
  • テーマは外観が変わるだけなのと、外観の変化による違和感への抵抗により避けられているのでは?
  • 標準テーマでもそれなりな見た目なのもあるだろう
  • プラグインにも言えることだが、Redmine バージョン更新に追従できてないテーマを経験するとプラグインほどには導入動機が高くないので使用を断念するというのもありそう
  • テーマ開発の話
    • 実際に私が minimalflat2 の開発をどのようにおこなっているかデモ
    • SCSS を編集するとリアルタイムで CSS に Transpile され、Web ブラウザー表示が更新される話
    • Docker を使うと Redmine を実際に動かしながらテーマ開発できる話、こちらは Web ブラウザー自動更新できない (フック方法を検討中) ので手動更新としている

プラグインの課題

  • Redmine プラグインは専用の API を用意しておらず、直に DB や UI を操作する
  • そのため Redmine バージョン互換を意識しないと容易に環境が壊れる
  • かといって今から API を整備するか?というと難しそう
  • せめてバージョンの自動検証は実装したほうがよいのでは?
  • 既存チケットになければ私がこの案を登録するかも

技術書典 5 所感

2018年10月9日 0 イベント

2018/10/8 (月) に開催された技術書典 5 へ参加した。以下に所感をまとめる。

待機列から入場まで

会場となる池袋サンシャインシティ 2F 展示ホール D (文化会館ビル 2F) へ到着したのは 10:48。開場は 11:00 なので遅いほうだ。すでに待機列は建物に入り切らず、外まで続いている。

私が並んだのは豊島自動車練習場を見下ろすサンシャインシティ 2F の外階段あたり。最後尾に到着したというツイートを書いていたら、そのる間も人は増え続けて投稿時には後ろに 100 人ぐらい増えてた。その後も順調に増加し続ける。

前回の技術書典 4 では整理券が配られた。そのため公式の状況報告ツイートを確認しながらアキバ散策したのだけど、今回は整理券なしとのことなので一抹の不安が。

しかしこれは杞憂だった。待機列はモリモリ消化されてゆき 11:29 に入場。待ち時間としては 40 分ほど。あとで技術書典 5 関連のツイートを確認したところ開場してからは更に流れが速まったようだ。これぐらいの時間であれば夏冬でもなければ十分に待てるだろう。

待機列すごいツイートを見て参加を断念された方もいたようだが、整理券なしでもこんな感じで済んだので参考にしてほしい。

会場と通路

私は毎年ここで開催される JAGAT の page へ参加しているため事前に規模を知っていた。更に技術書典 5 のサークルリストを見ても配置に余裕のある感じだったので、入場制限が適切なら混雑度もさほどではないと予想していた。

実際に混雑はしたものの前回に比べればかなりスムーズに移動できた。島間の通路は 5 〜 6 人ぐらい横並びで余裕な感じ。おかげで通り過ぎた後によさそうな本を見つけたとしてもサッと戻って購入できた。

しかしこの広さを活かすならば道路のように中央線を引き、往路と復路を明示的に設けたほうがよかったのではないか。進行方向が決められていないため、各人の配慮による譲り合いでかろうじてトラブルを避けられていた印象。

途中でスタッフがサークルの客は端へ寄ってほしいとアナウンスしていたが、これも道路でいう歩道にあたるものがあれば案内しやすいだろう。

技術書典の参加者は私が見るにマナーはよかったので、公式なルールや案内さえあれば協力的なはず。運営側の負担も減らせそう。

QR 決済 (後払い)

技術書典は iOS/Android 向けアプリを提供しており、これを利用すると QR 認証で決済できる。支払いは後日 PayPal か Sprite でおこなう。私は本日 (2018/10/9) に案内がきたので PayPal で支払った。しめて ¥10,400 なり。

技術書典 4 は初参加ということもあり、下調べも不十分でアプリに気づいたのは会場だった。時たま QR コードをスキャンしている様子と QR 決済を推奨しているサークルを見かけて存在を知る。また現金の支払いでまごついたり千円札が不足して購入を諦めた本もあったので次こそ必ず QR 使おうと決めていた。

それを踏まえ今回は事前にアプリをインストールしておいたので積極的に QR 決済を利用した。14 サークルを巡り、うち QR 対応していない 1 サークルを除きすべてこれで決済できた。

QR 認証はスムーズで現金よりもずっと快適。財布の中身を意識せずに済むのも精神衛生上よい。購入の流れはこんな感じ。

  1. サークルへ購入の意思を伝える
  2. アプリから QR コードを読み取る
  3. 頒布物リストが表示されるので種類 (複数の本を扱っている場合) と冊数を選択して決定
  4. 認証後に決済されたことが表示される
  5. サークルに決済表示を見せて本を受け取る

課題はスマートフォンの出し入れ。会場では断続的に QR 決済するため、スマートフォンを持ちっぱなしにするか頻繁に出し入れすることになる。落下による破損などを考慮するとこれは実に危険だ。

もし対策するとしたら長めのネック ストラップがよさそう。首から下げたまま机上の QR を読めてサークル側に画面を見せられるぐらいの長さがあればよい。次回はそうする予定。

買い逃し

技術書典サイトにアカウント登録すると前述のアプリや Web サイトのサークル チェック リストを利用できる。しかし事前にチェックしたにも関わらず買い逃しが発生した。

会場ではサークルの島配置とリスト確認しながら回ったのだけど混雑によりサークル番号が見えなかったり人に流されて通り過ぎてしまうなど、この種のイベントに不慣れな私には厳しかった。疲労もあってリストを見るのが億劫になったのもある。結果としていくつか漏れた。

これはまったく私の落ち度だが、技術書典アプリの対応により改善できそうだとも思う。以下、構想 (妄想)。

まずアプリと Web サイトはアカウントを共有しているのだから、アプリ側にもサークル チェック リストを表示する。アプリには QR 決済のログが表示されるので、これもリストに連携。この組み合わせにより少なくとも購入候補の消化状況はリアル タイムに確認できる。

つぎに島配置。Web サイトや冊子案内のようなサークルの島配置をアプリに表示。QR 決済を利用するユーザーなら常時、または頻繁にスマートフォンを手にするだろうから、この情報も確認しやすいはず。これは効率的にサークルを回るため有用なはず。

島配置については島のタップで所属するサークルのリストをモーダル表示。これがチェック リストと QR 決済に連携され、チェックと決済 (購入) 状況をアイコン表示してくれたら更によし。決済状況については頒布物すべてを購入したら特別なアイコン (王冠とか?) になったりすると嬉しいかも。コレクション欲を刺激するのだ。

入手した頒布物

読むのに時間がかかりそうだから感想はあとで別記事に書く予定。

他にも気になった本は多数あるのだが、技術書典バッグの容量的に厳しくなったので見送った。買い逃しも含む。V8 本が落ちたということで東京ラビットハウスは通り過ぎてしまったのだけどサークル詳細みたら Universal JavaScript Framework 本を出してたようなので寄ればよかった。うかつ。

とはいえ電子版を BOOTH 販売しているサークルもあるので、肉体的な負担を低減するための制約としてバッグひとつ分というのを設けた。薄い本でも集まれば重い (昔の映画は古い、的な表現)。この記事を書いた後で更に BOOTH 購入することもあるだろう。

redmine.tokyo 14 で登壇してみた

2018年5月28日 0 イベント ,

2018/5/26 (土) に redmine.tokyo 14 へ参加 & 登壇。以下、レポっす。

開場前

  • 最寄りは都営浅草線の泉岳寺駅だが、自宅からのルートだと乗り換えが面倒なので京浜東北線の田町駅へ
  • 田町駅で昼食、「いろり庵きらく」の「板そば」を頼んだらボリュームかなり多くて食べきれるか心配だったので飲み込む感じで処理
  • 国際興業三田第 2 ビル、休日なので通用口から入るとのことだが案内してくれる方がいたので迷わず入れた
  • 会場には 12:30 ぐらいに到着、着席
  • 開始までの時間に持参 PC のプロジェクター接続確認してほしいとのこと
  • ここでケーブル忘れに気づく、というか会場にあるのを期待する他力本願メソッドにも程があって、つまりは迷惑かけてしまったスミマセン
  • MacBook Air 2011 だと DisplayPort が必要、会場の方から借りて事なきを得る
  • ケーブルを貸していただいた方の顔を思い出せず @akipii 氏に託したのだが、その後どうなったのだろうか?
  • もしケーブルが戻られていない場合は補填・弁償したいので申し訳ないのですが @akabekobeko まで連絡ください
  • 会場、けっこう埋まっている
  • メイン会場はキャパ 60 人ほど、サブ会場は YouTube 配信をみる感じらしい
  • 会場のスクリーンは 2 種類、スライドと Twitter の #redmineT を映しているもの
  • ハッシュのほうは反応がリアルタイムに更新されてゆくので見てて飽きない

Redmine をちょっと便利に!プログラミング無しで使ってみる REST API

  • プログラミング無しで使ってみるREST API
  • ファーエンドテクノロジー株式会社 前田剛氏 @g_maeda
  • Redmine コミッターとして有名な方
  • curl、jq コマンドを利用して Redmine REST API を操作する
  • Redmine のデータへ Web UI を経由せずにアクセスするための手段
  • HTTP リクエストすると XML or JSON を返す
  • 例えば GET /users/1.json で user ID 1 のユーザー情報を JSON で得られる

REST API だと嬉しいこと

  • 他のシステムから Redmine を操作できる
  • 自動化、チャットボットなど
  • Web UI 操作では難しいことも実現できる

ツール例

REST API 利用準備

  • コマンドラインから API を利用
  • 今回は JSON にします
  • OS は Ubuntu か macOS を想定
  • Redmine の管理画面から「RESTによるWebサービスを有効にする」を ON にすることで許可
  • jq というツールを用意、sudo apt-get install jqbrew install jq で入手
  • アクセスできるかテストしてみる、Terminal に JSON がでれば OK

API で遊んでみる

  • ユーザー情報一覧の取得
  • curl で REST API を呼び、返された JSON を jq で整形する
  • ユーザー情報一覧を CSV に変換してみる、これも jq でいける
  • Redmine にはユーザー情報一覧のエクスポート機能がないため、このテスト時点で Redmine 以上のことを実行できていることになります
  • 応用でユーザーの一括登録もおこなえます
  • チケットの題名を正規表現で探してみる、Redmine では OR 検索できないが、正規表現ならなんでもあり

REST API 活用 TIPS

  • URL の拡張子で XML or JSON が決まる
  • コマンドラインから利用するなら処理しやすい JSON がオススメ、なにより jq が便利
  • 一部のオブジェクトはアクセスに Redmine システム管理者の権限が必要
  • デバッグには curl の -v オプションが便利、HTTP 通信内容を出力できる
  • というか -v つけないとエラー情報すらでない

質疑応答

  • Q. REST API でできて Redmine の Web UI の提供していない操作があるのはなぜ?
    • Web UI の方に手が回ってないだけです
  • Q. REST API、ドキュメントだとベータ版となっている箇所があったりするけど大丈夫?
    • ベータなどのステータスが更新されてないだけです
    • 十分にテストされている (Redmne では自動テストを重視している) ので実用上は問題ないと思われます

Redmine と他システムの連動事例

  • 資料みつけられず
  • 山崎進氏
  • 与えよさらば与えられん
  • 受けるより与えるほうが幸いである
  • 聖書にある言葉、OSS 活動の精神と考えている
  • 今日の登壇もその動機から

MS-Project から Redmine への情報移行

  • MS-Project を XML 出力
  • github に公開されている msproject-import というプラグインで Redmine にインポート

Slack と Redmine の情報移行

  • Redmine から Slack へ
    • アプリを追加する設定で incmming webhook を選択
    • Web Hook 用 URL が表示されるのでメモ
    • Redmine 側、github に公開されている redmine-slack というプラグインをインストール
    • プラグイン画面の入力欄にメモしておいた URL を指定
    • 例えばチケット登録すると Slack に通知がくる
  • Slack から Redmine へ
    • outgoing webhook を選択
    • REST API キーを入力する
    • Slack 側からチケット操作したりできる

Excel から Redmine へ

  • プラグインを利用
  • Excel 風の編集機能は Handsontable を利用
  • jQuery 経由とのこと、Redmine は標準で jQuery がバンドルされている
  • 例えば Redmine 上に非表示のテキストボックスを作成、テーブルに入力されるとテキストボックスに自動反映して Rdmine に Submit するような仕組みを使っている
  • カンマ区切りの文字列が送信されるので、サーバー側で解析して DB 反映

なじむ Redmine

  • なじむ Redmine
  • 私の登壇
  • YouTube 配信してるとのことなので YouTuber 風に「登壇してみた」とか「どーもアカベコです。今日は生放送されてるのでさしずめナマベコですかね?」みたいな感じで始める計画だったのだが…
  • akipii 氏による紹介で「アベコベさん?」と読み間違えられ、そちらのほうが面白かったので計画は破棄
  • #redmineT の書き込みとタイムキーパー用のチャイムが誤爆して何度も鳴るのがかなり気になる
  • 緊張し過ぎて時計みる余裕なかった、結果としてすこし時間オーバー

あとで #redmineT みたらよい反応が多くてホッとした。みなさん優しいですね。

LT

Redmine でデザインの強度作業 on リモートワーク

  • Redmineでデザインの共同作業onリモートワーク
  • 財部香織氏 @kaorabe
  • デザイン業務を Redmine でタスク管理している
  • ワークフロー説明、ブログ記事の場合
  • テキスト入稿、画像ラフ、Illustrator
  • 勘所
    • なるべく早く見られるもので PDCA 回すた
    • チケットにスケッチなどを添付しまくる
    • 注記で感謝を伝えることでコミュニケーションの潤滑油とする
  • …ここでチャイム
  • Redmine 同人誌出版を予定しているとのこと

途中でみえたチケット画面いい感じ。注記の区切りが吹き出しになっている箇所に惹かれる。自作テーマだろうか?

Redmine 同人誌は技術書展に出すのを目標という話をしていた。ちょうど先月、技術書展 4 に参加して刺激を受けたのと、社として関わり始めた XMLパブリッシング準研究会で 6/30 あたりに技術書展のサークル側の人と交流会を実施予定なので私としても興味ぶかい話である。

個人的には次の技術書展で Electron 本でもどうか?と考えていたのだが、この Redmine 本で参加するのも面白そうだ。私が書くとしたら minimalflat2 開発で得たテーマ開発まわりの話かな。

効果的な Redmine 導入のヒント

すごくよさそうな内容なのであとで資料を読む。

しかし 5 分の量ではない (22 ページある)。よって飛ばしまくり、しゃべりもあわせて高速化。大変そうだけどその様子が面白すぎた。時間操作系の能力者的ななにか。

LT 5 分ならスライド 10 ページ以内じゃないと厳しそう。昔、だれかに聞いた話では 1 ページ 1 分ぐらいで計算するとよいそうだ。高橋メソッドみたいな例外は除いて。

Redmine で契約を追え!

  • Redmineで契約を追え!
  • かるね氏 @nekosanz1
  • CI と向き合う事務員の戦い
  • インフラ屋の CI
  • 継続的… ではなく Configuretion Item のこと
  • 契約資料をだいじに
  • 契約のはじまりと終了
  • お客様と仕入先とかならず締結するもの
  • すべての物品はなんらかの契約書に結びつく
  • 難しいところ、数の暴力、契約数が多過ぎる
  • 時間経過による内容変化
  • ツール使えば管理できそうだけど?
    • 買ってもらえなかった…
    • なので Redmine で
  • チケット管理単位の話
  • チケットと体制
  • 1 年まわしてみて契約が迷子になることがなくなった
  • 機器や物品にチケット番号 = 契約番号を貼って管理、生きたチケット

チケット番号を物理的に貼るというのは面白い発想。Redmine が十分に浸透していればチケット番号は外部システムや現実社会でも資料へのポインターとして機能する。

Redmine 連携機能ソリューション紹介

  • スマートなテスト管理クラウド Qualityforward
  • syoshikawa0319 氏
  • QualityForward の話
  • 株式会社ベリサーブ
  • 効率的なテスト ツールを探している
  • BTS はレポートのみとおもっている
  • Quality Forword と Redmine 連携してもっと高度に管理
  • めちゃくちゃ飛ばす
  • Excel ライクな入力、集計
  • 効果など

Redmine として弱い部分をうまく補完している感じでよい。Redmine に絡めたビジネスが成立しているのだとしたら Redmine としても好ましいはず。

まったくの余談だが、大昔に在籍していたプロジェクトでベリサーブ社に検証を依頼していたのだが、やりとりのメールの宛名部分を「ベリサーブ殿」としていたのを見たメンバーの誰かが「ベリサーブでん」と読み、その音のインパクトからしばらく「〜殿」を「〜でん」と読むのが流行ったのを思い出した。

この話を懇親会でしようかと思っていたが機会なかったので、ここに記す。いい話でもなんでもないけれど。

プロジェクト管理ソフトの群雄割拠をどう勝ち抜くか?

  • 資料みつけられず
  • 岩崎成記氏
  • Redmine、MS-Project、Excel、…etc
  • これらの比較用にプロジェクト管理を定量化してみた
  • 趣味は見える化、すごい
  • 状態変化モデルなど、きちんと計測、グラフ化してて納得感ある

実データと理詰めで Redmine のメリットを見える化している点に感心。

VIEW CUSTOMIZE から REST API を使用する

  • View CustomizeからREST APIを使用する
  • もりのあさ氏 @forenoonM
  • 寝坊しました、11 時におきてびっくりしました
  • 転職して Redmine から JIRA になった
  • いろいろ困ってるけど「ぜんぶおれがなんとかする」所存らしい
  • RedmineのJavaScriptからREST APIを使用するの実践編
  • View Customize (JavaScript) から REST API を呼び出す
  • API キーはどうする?
  • 個人設定ページの内容を読み込めばよいのでは?で解決
    • これはダイアログと sesionStorage で解決できそう
    • グループ ディスカッションで一緒になったのでこれを振ったら、当初はそうしようとしたがセッションの引き回しの関係でうまく動かなかったとのこと
  • サンプル、小チケットのコメント追加時に親チケットにもコピーする

スライド中の Redmine スクリーンショットを見るに minimalflat2 を利用しているようで嬉しい。

私は Redmine プラグインに懐疑的で、それはプラグイン自体ではなく配布と互換性を担保する標準の仕組みが提供されていないためである。ただしそれを今から構築するのは難しいだろう。よって、

不具合が起きても Redmine 本体をクラッシュさせることがなく、近年の機能強化が著しい JavaScript、つまり Redmine テーマ側で補完してゆくほうがよいのでは?と考えている。

例えば minimalflat2 ではプロジェクト一覧を開閉可能なメニュー化している。これは Web フロントエンド完結しているが、REST API を利用して Redmine 本体も操作するのはどうか。

本日もこのスライド以外に REST API で Redmine Web UI にない操作をする演目があった。URL を判定すれば画面を特定できるので、例えばガントチャート画面を WBS 風に編集できるとかも画面判定して REST API でチケット期限更新するとかで実現可能なのでは。

という感じのことをこの演目を聞いて考えていた。

redmine git work in progress プラグインの紹介

リポジトリー側の操作がチケットに影響するというコンセプトが面白い。標準でも特定のコミット コメントに応じた処理 (例に挙げられている refs とか) はあるが、この分野は可能性を感じるのでもっと実験されてほしい。

Redmine とスマートスピーカーを連携させてみた

  • Redmine とスマートスピーカー連携させてみた
  • Kohei Nakamura 氏 @netazone
  • スマートスピーカーはいいぞ
  • もってる人は挙手…数人
  • もってない人は拍手…万雷の拍手
  • チケット登録めんどくさい、スピーカーに話しかけるだけでチケット登録はどうか?
  • 実演、会場の反応が熱い
  • OK, Google、チケットを… で登録とか更新する、すごい
  • 仕組みは IFTTTGoogle Assistant、Redmine 連携
  • デバイス、IFTTT、Redmine の順に処理

プログラムわからなくても、これらの要素技術で手軽にこういうのができる時代みたいな話をしていたが、まさしくそうだし、この流れは加速してゆくだろう。

最前列に置かれた猫型?のオブジェが気になっていたのだけど、これがスマート スピーカーだった。ハードウェアが絡み、しかもわかりやすいデモなので会場の受けがよい。スマート スピーカーが持つ印象面の効果は無視できない強さがある。

余談だが @nekosanz1 と @netazone は字面が似ている。

パネル ディスカッション

  • Git と Redmine をどのように連携するのが効果的か
  • 司会は松谷秀久氏 @mattani
  • パネラーは楠川智久氏、川端光義氏、NAITOH Jun 氏 @naitoh

Redmine と GitLab の連携利用

  • Redmineとgitの 連携利用事例
  • 楠川智久氏 @tkusukawa
  • Redmine プラグイン WorkTimeWikiLists などを公開してます
  • 自分たちの Git 連携方法についてお話するので、それについて意見や議論したいです
  • システム的には Redmine サーバーから GitLab の Bare リポジトリーを参照
  • Git リポジトリー運用は master で開発して std と production リポジトリーでリリースする形式

Redmine 設定については私の会社と一緒。ウチは Gitflow 風に master でリリース、開発は develop ブランチという感じで運用してる。feature も develop から生やす。

Redmine と GitHub のうまい関係

  • RedmineとGitHubをゆるく使う
  • 株式会社アジャイルウェア 川端光義氏 @agilekawabata
  • アジャイルウェアのコード管理は GitHub
  • レビュー機能が重要、GitHub の PR はそこが優秀
  • エンジニアのための最適なレビュー プロセス
    • 品質向上
    • 集中できる環境
    • エンジニア育成
  • Redmine と連携しづらい
    • Redmine は同一サーバーに Bare リポジトリが必要
  • アジャイルウェアでは
    • マネージメント管理に Redmine
    • 開発は GitHub
  • Lychee Redmine と GitHub 連携

ディスカッション

  • 松谷氏は Git 未経験、SVN と Redmine 連携は利用している
  • SVN に比べて Git のよさってなんですか?
    • 楠川 もう SVN には戻れない、merge が楽、branch 切るのが楽、分散・集約については重視していない
    • 内藤 Redmine 上で PR したい、これを SVN & レビュー プラグインでおこなうとコミットされた後になってしまう、GitHub のように merge 前に PR でレビューしたい
    • 川端 エンジニアは他の人に迷惑かけたくない、SVN だと push しかないのだが Git だと細かく branch 切って他に影響しないように作業をすすめて必要におうじて merge するスタイルなのでエンジニアにとってよい
  • Redmine リポジトリー連携としてどうか、川端さんはおこなっていない (GitHub 管理)、楠川さんはおこなっている
    • 楠川 逆に我々は PR を使っていないのでそのメリットが理解できていない、そうではない部分としてチケットと Git コミットが関連づいているのはよい
    • 川端 エンジニアの開発とコミュニケーションが GitHub 完結しているので困っていない、ただしマネージメントの Redmine との動機はとれていない、齟齬は Slack などで解決、PR に Redmine チケットのリンクをはることはある
  • 対象的な事例だが、GitHub/GitLab と Redmine の使い分け、棲み分けについて聞きたい
    • 楠川 内藤さんのところはどうですか?
    • 内藤 プライベートは GitHub、仕事では Redimine だがローカルで git-svn つかってる、HTTP で Git 公開できないので気軽につかえない
    • ここで挙手して聴者側から参加、これは Gitolite はどうか?ここで Gitolite の仕組みについて説明
    • 内藤 社内規定 (?) におけるアカウント管理の関係があり Gitolite は採用できなさそう
  • このあとも盛り上がっていたが PC のバッテリーが尽きそうなのでメモはここまで
  • 開発者としては Git と GitHub を利用したい、マネージメント層としては Redmine 的なタスク管理のほうが向く、棲み分けるもの?Redmine の機能強化で GitHub 的なもの (PR など) を取り込み一元化できないか?といった感じの話になっていた

GitHub はすでにソフトウェア開発者の中で全世界的に標準インフラ化した感がある。多少の不便があっても運用や周辺ツールでなんとかしているから Redmine に取り込むとしたらかなりの強化が必要だろう。

私としては Redmine から Git リポジトリーを簡単に作成して連携まで自動化するのが第一歩。次に PR 対応するあたりでようやく勝負の入り口という感じ。

グループ ディスカッション

  • 145 名分のアンケート公開
    • Redmine プラグインのシェアなど
  • ディスカッションは 6 人ひと組
  • 登壇内容だったり、その他 Redmine に関するよもやま話をする時間
  • もりのあさ氏などと Redmine 運用や現場の話などで盛り上がる

懇親会

  • ItalianBar KIMURAYA 品川 (キムラヤ)にて懇親会
  • redmine.tokyo の会場から徒歩 20 〜 30 分ぐらい
  • 徒歩組とタクシー組にわかれる、乗り合いならワンメーターちょっとでいけそうな感じなので私はタクシーで
  • 登壇に関する感想や Redmine 運用についていろいろと話す
  • 前田剛氏と Redmine の開発体制について議論
    • 英語力を気にせず redmine.org に参加してほしい
    • Google 翻訳と Ginger 英文チェッカー を通すぐらいでも案外、理解してもらえるのではないか、プロダクトに関する話であれば英語圏の人も拙さは汲み取ってくれるもの
    • Redmine の行く先に不安がある、バージョン系の多様に起因する開発リソース不足、互換性に縛られることで保守化して先進機能 (SPA 化など) へ取り組みにくくなっているのでは、redmine.org 自体が最新 Redmine を採用していないのは大丈夫なのか、…etc
    • 前田剛氏や他の Redmine 開発者もこうした問題点は理解しているのだが、対応に苦慮している
    • オフレコっぽい話もあったので、それは書かないでおく
  • @akipii 氏は Twitter のアイコンがヒグマ?の写真なので赤カブト的な人が来たらどうしようかと思っていたのだが、温厚そうな紳士で助かった

まとめ

自社むけなどは何度かプレゼンしたことがあるのだけど、そうではない一般向けに登壇するのは初めて。

そのため非常に緊張したのだが、結果としては登壇してよかった。

Twitter の #redmineT や懇親会での反応をみるにつけ、巧拙は気にせずリアルでもアウトプットすべきだと感じる。反応を得てこそ。ブログや Twitter でも反応してくれる人はいるが、その場で生の熱意を受けるのは特別な体験である。

以前の私はリアルな交流の内輪ノリが好きになれなくて避けてきた。しかしここ数年、現職の社長や営業の意向もあってセミナーや勉強会で交流を広めるようにしている。こういうのも視野を拡大するために必要なことだと考えるようになった。

そうした経験の一環として redmine.tokyo 登壇はよい機会で、今後も関わっていけたらな、と思っている。