第12回東京Redmine勉強会の感想 #redmineT
第12回東京Redmine勉強会では、講演者、参加者、スタッフの皆さん、お疲れ様でした。
大雨の土曜日のために、突然キャンセル40人以上発生したにもかかわらず、参加率90％という驚異的な勉強会。
感想をラフなメモ書き。
間違っていたら後で直す。
第12回東京Redmine勉強会 - Togetterまとめ
【1】@g_maedaさんの発表は、3月のRedmine大阪の発表の改良版。
気になる点は、最後の「Redmine3.4.0になれなかったパッチたち」。
サイドバー折り畳みは、欲しい。
PCの画面が小さいと、フル画面でチケット一覧を見たくなる。
チケット一覧の表示項目が増えると、横スクロールが必要になって、うっとうしい。
また、スマホ、タブレットなど数多くの閲覧媒体が増えてきているので、レスポンシブ対応だけでなく幅広く対応してほしい。
コードハイライト言語を増やす機能追加も早くやってほしい。
特に、VB、C#のコードハイライトがない、という要望は従来からすごく多い。
バージョン内のチケットのD&D機能も早く追加してほしい。
アジャイル開発におけるプロダクトバックログの精査の作業に直結する作業だからだ。
つまり、チケットのリリースの優先順位づけを並び順で表現することは、リリース計画をプロダクトオーナーと開発者が共有しやすくなる点にも直結する。
アジャイル開発の観点では、チケット一覧画面よりも、ロードマップ画面の改良にもっと力を入れて欲しい。
【2】@Madowindaheadさんの講演では、チームの変化やチームの成長を活動画面から事前調査して、支援しているとのこと。
この部分はRedmineの優れた機能そのものだし、チームの成長がRedmineに記録されていく点はチームのモチベーションにもつながるだろう。
あさこさんのツイート: "「決定に関する内容も分かります」 活動内容をどういう粒度で記入するかをしっかり決められているいい事例ですね！！ #redmineT"
akipiiさんのツイート: "#redmineT 成長していることを、変化していることで捉える。まさにRedmine の得意なところ"
また、PMxTMのポジショニングマップが重要だと思う。
縦軸＝PM技術力、横軸＝ツール利用度で、開発チームや開発メンバーをプロットして、どこのセグメントが問題なのか、あるべき姿へどうやってマネジメント力を向上させていくべきか、という観点で分析するのに使える。
特に、Redmineを導入したけど、社内でなかなか広まらない、という時に、どこのセグメントに問題があるのか、という分析のヒントになるだろうと思う。
スライドで面白い点は、社内でRedmine利用度を上げることでマネジメント力を向上させるパターンを経験上3種類あげている点だ。
一つ目は、PM力が大変低く、ツール利用経験も大変低い層。
このセグメントは、「目標になるメンバーと一緒に成長ラインに乗せる」。
つまり、新入社員のように、まだ技術もPMの経験が浅い人は、OJTのような仕組みが有効なのだろう。
二つ目は、PM力は中間くらいだが、ツール利用の経験が浅い層。
このセグメントは、「この位置のメンバーは成長ラインに乗せやすい」。
その理由は、既にマネジメントの経験があり、PMに必要なスキルや概念はある程度分かっている人たちなので、そのスキルを生かしやすい環境としてRedmineを提供すれば、自分たちで問題解決していけるようになるはず、ということだろうと思う。
三つ目は、PM力は高いが、ツール利用度が大変少ない層。
まさにExcelおじさん。
このセグメントは、「メンバーの成長を意識させることで、成長ラインに乗せる」。
この点は、なるほど、と思う。
このセグメントは、自分たちのやり方を持っている人が多いので、なかなか新しいツールを使ってくれない。
でも、自分の立ち位置やメンバーへの影響力は、自分でも分かっている人が多い。
すると、自分がRedmineを使わなくても、メンバーがRedmineを使って自然に成長していけば、自分もちょっとはやってみようか、という気になるのだろう。
つまり、いきなりツールを使いこなせ、とトップダウンでやるのではなく、ボトムアップで攻めていくわけだ。
このパターン集で面白いのは、4象限のうちの右下の部分「ツール利用は多いがPM経験が少ない」セグメントのパターンがないこと。
講演でちょっと触れていたが、このセグメントはヒントを与えたり、支援すれば、自力で解決していってくれる。
個人的には「プログラマ上がりのプロジェクトリーダー」が多いのではないか、と想像する。
そういう人たちには、得意とする技術力をベースとして、Redmineでマネジメント経験を増やしていけば、自然に力が付くのではないか、と想像する。
僕自身もそういう経験があった。
【3】@ktohさんのRedmine全文検索プラグインの話も興味深かった。
たとえば、チケットが数十万枚、数百万枚に増えた場合、それらチケットやWikiなどの情報を、欲しい時に即座に検索できる機能は、Redmineをナレッジシステムとして使うために重要な機能と考える。
Ver3.3では、右上の検索ボックスは表示中のPJだけにデフォルトで絞り込み検索するので早くなっているが、全PJ横断の検索はまだ遅い。
そのような問題を解決するプラグインなので、Redmineをナレッジシステムとして価値を向上させるために有用な機能だと思う。
Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索
Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索
全文検索プラグインで興味を惹く点はいくつかある。
一つは、検索ノイズがなく、ランク別・更新時刻順に表示される点。
Groongaという拡張DBエンジンを使うので、スコアを調整して、有用な検索結果を上位N件に表示してくれる。
注目すべき点は、デフォルトの全文検索結果と全文検索プラグインの検索結果は、件数は同じでもソート順が違う点。
つまり、Google検索みたいに、役立ちそうな情報が上位に表示されるので便利。
また、Google検索のように、AND・OR・NOT検索ができるのも便利。
たとえば、「(Groonga OR Mroonga) -PostgresSQL」みたいに、GroongaまたはMroongaを含むがPostgresSQLを含まないように検索できるらしい。
この機能が検索で使えるならば、過去の障害や仕様変更の履歴を探したい時に、より詳しい検索条件で書けば、より早く到達できるようになるだろう。
さらに、更新時刻順にソートできるのもうれしい機能だ。
検索したい状況をふりかえると、直近で自分や他の担当者が書いた内容を検索したい時が多いからだ。
直近の障害情報、直近の課題やQAを見つけたい時が多いから。
二つ目は、高速である点。
この内容は、既に@akahane92さんがツイートされている。
三つ目は、まだ未実装だが、類似チケットの検索。
これは、Amazonのお勧め商品表示と同じく、協調フィルタリングとか機械学習みたいな機能を使って、この障害チケットに似た過去のチケットはこれこれです、みたいに表示する。
たとえば、障害チケット起票時に、過去の類似バグを表示してくれると嬉しいだろう。
四つ目は、まだ未実装だが、検索ボックスやチケットのタイトル欄などで、入力補完する機能強化。
これは、PJプルダウンのインクリメントサーチのように、検索ボックスで1文字入れたらGoogle検索みたいにコードアシストしてくれる機能みたいなイメージ。
この機能があれば、チケット内容の入力間違いを減らせるし、途中までの文字入力で自動補完してくれるので、チケット入力コストをかなり減らせるはず。
つまり、ただでさえチケット入力は鬱陶しい、と言われがちな弱点に対し、検索エンジンの強化によって入力補完をサポートすることで、チケット入力者の作業コストを減らし、チケットの内容の精度向上に役立てることができるわけだ。
この辺りの機能を欲しいと思う日本人ユーザ、Redmine利用企業は意外に多いのではないだろうか。
なぜなら、Redmineを利用している現場は増えているし、すでに数年以上運用してかなりの枚数のチケットを蓄積している日本企業も多いと思うからだ。
@ktohさんが支援を要請しているので、興味のある人は声掛けしてはどうだろうか。
今後の野望については、下記の記事でアップされている。
redmine.tokyo第12回勉強会：GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)
なお、AWSへのセットアップでは、下記のツイートがあるので注意。
【4】宮本さんの「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」も興味深かった。
ストーリーとしては、既にRedmine＋GitLab＋Jenkins＋Maven＋Artifactoryという開発環境がそろっていて、その上にプロダクトラインのプロセスを実装しようとするお話だった。
お話としては大変興味深いのだが、肝心のRedmineの機能にどのようにマッピングさせたのか、という点はぼかされていて、分からないところが残念笑。
但し、講演中の一言「Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所」という話から想像すると、こんな感じかな。
Redmineには、要件や仕様、それに基づくタスク・課題・障害の情報は一元管理されていて、そのチケットから作業は駆動される。
そして、ソースや設計書などの成果物はGitLabで構成管理されていて、複数の製品ファミリーはGitのブランチで管理されている。
その時、それぞれの製品ファミリーのリリースされたソフトウェア製品は、バージョンでタグ付けされて、それらはArtifactoryでビルドモジュール単位のバージョン管理がなされている。
つまり、各製品は、共通ライブラリやコア基盤となるようなビルドモジュール(たぶんJarやWar)とアプリケーション資産(これもJarやWar)がパッケージングされていて、各製品がリリースされたタイミングで、共通ライブラリのどのバージョンに依存しているか、はMaven＋Artifactoryで構成管理されているのだろう。
つまり、ソフトウェア製品とソフトウェアモジュール(汎用ライブラリ)は、ビルドモジュール単位で構成管理されていて、その構成管理が重要、ということなのではないだろうか。
この考え方はちょうど、業務システムがOracleやApache、.NET Frameworkの特定のバージョンに依存して作られていて、それらも含めて構成管理されている、みたいな考え方と同じではないだろうか。
すると、Redmineにある発端となった要件や仕様から、それに紐づくソース、そこからビルドされてリリースされたソフトウェア製品へトレースできる(後方への追跡性)し、逆に、あるバージョンのソフトウェア製品から要件までトレースできる(前方への追跡性)。
そのような開発プロセスを作りたい、という動機も別途あるのだろうと推測する。
そして、その仕組みは、Redmineのチケット管理や構成管理ツール連携という機能を使えば、チケット駆動のトレーサビリティ機能が導出されて実現できる、みたいなストーリーではないだろうか。
チケット駆動開発を要求工学の品質特性の観点から考える～チケット駆動開発がAgile開発を必要とする理由: プログラマの思索
【5】講演資料はコチラ。
」が発売されているので、目次をリンクしておく。
」かな。
」「
」の2冊を出版した後、もはや「チケット駆動開発」というアイデアはソフトウェア開発では当たり前だと思う。
最近のコメント