プログラマの思索

最近のJiraを見る場面があって、この機能はRedmineに取り入れた方がいいな、と感じたことをラフなメモ書き。
Redmineがもっと強化できそうなポイントは3つあると感じた。
そのうちの1個を書いておく。

【1】議事録Wikiと課題チケットを相互リンクさせる

【1-1】たとえば、要件定義や設計工程では、要件定義ヒヤリングや設計レビューが定期的に開催される。
そのタイミングで、Wikiにその場の議事録を全て書く。
そして、議事録でまとめられた決定事項以外に、課題となった内容は、チケット化する。

その時、Wikiから課題チケットを1クリックで新規作成したい。
そうすれば、ヒヤリングやレビューの打合せ時に、議事録をWikiに書きながら、その場ですぐに課題チケットを発行できる。
後で、課題チケットの詳細を書いて、チーム内で割り振りすればいい。

また、議事録Wikiには、発行した課題チケットのリンク一覧が自動生成されて欲しい。
そうすれば、議事録Wikiを見れば、どこまでが決定して、どこまでが残課題として残っていて、課題がどんな進捗状況なのか、一目で分かる。

【1-2】つまり、議事録Wikiと課題チケットを相互リンクさせるように機能強化することで、トレーサビリティを強化したいのだ。
すなわち、課題チケットの発端となった要件定義ヒヤリング、設計レビューの議事録Wikiと相互リンクさせることで、開発時やテスト工程で要件を探したり、保守フェーズで要件が変更されていった経緯を探すことに使いたいのだ。

現時点でのRedmineでは、構成管理ツール連携によって、ソースコードの変更履歴と障害チケットのトレーサビリティは実現できる。
つまり、開発やテスト工程以後の下流工程のトレーサビリティは標準機能で実現済みだ。

しかし、要件定義や設計工程などの上流工程のトレーサビリティは、機能と運用が上手く調和が取れていないと思う。
「チケットを起票してくれない」「チケットが放置されてしまう」理由の一つは、ここにあるのではないか。

以前の僕は、チケットをストーリーカードにすることで、チケットに要件を当てはめて、タスクに落とす方法を考えていた。
WF型開発におけるWBS駆動によるチケット化も同じ。

ITの地殻変動はどこで起きているのか？: プログラマの思索

しかし、要件や仕様、議事録をチケット化するのは経験上、あまり上手く運用できていないように感じる。
理由は、チケットの機能がすごく柔軟であるので何でもチケット化してしまうと、チケットをフローとして流したいのにストックの性質も持っているために、チケットを安易にCloseできなくなってしまうから。

【1-3】「議事録Wikiと課題チケットを相互リンクさせる」メリットは、課題チケットの発端となるヒヤリングやレビューという打合せがWikiに残ること、そして、課題や作業のようなフローはチケット、議事録はWikiでストックのように使い分けできることだ。
つまり、チケットはフローの処理だけに特化すればいい。
よって、チケットは基本はサクサク流れる。

また、毎回の打合せ議事録Wikiに、新規作成したチケット一覧が課題一覧として自動生成されると良い。
現時点のRedmineでは、WikiListプラグインを使って、毎回の議事録から発生した課題チケットのみを一覧抽出して表形式で記載する方法でカバーできる。

Wiki Lists - Plugins - Redmine

Redmine Wiki ListプラグインでTracのクエリのように使うアイデア: プログラマの思索

このような機能が洗練されれば、課題チケットから発端となった要件ヒヤリングやレビュー議事録にさかのぼれるし、過去の議事録からどんな課題が発生して解決されたのか、という観点でドリルダウンすることもできる。
つまり、課題チケットと議事録Wikiの間でトレーサビリティを実現できる。

特に、上流工程では、要件や仕様がぶれやすいので、要件から仕様書やソースコードに至るまでの成果物へのトレーサビリティが非常に重要になる。
せっかく顧客の打合せで合意した要件が作業漏れで仕様書に反映されなかったり、設計レビューの指摘事項が上がっているのに仕様書に反映されなければ、下流工程で発見することは不可能だから。

【1-4】もっと突き詰めると、議事録Wikiは、Redmineのバージョンと連動できる方が良い。
なぜなら、要件ヒヤリングや設計レビューは定期的に打合せが開催されるので、そのタイミングで作られる議事録は、イテレーションに対応付けやすいから。
そうすれば、上流工程でも、アジャイル開発のような反復的なリズムで、作業できるようになる。

また、チケットに議事録Wikiと連動したRedmineバージョン情報が自動設定されれば、チケットを見るだけで、どの打合せから課題が発生したのか、分かるし、バージョンのリンクから発生源の打合せにさかのぼれる。

さらに、Redmineバージョン単位に打合せから発生した課題チケットが自然にグループ化されるので、チケット集計もやりやすい。
ロードマップ画面に各バージョン単位で、議事録Wikiの内容と、紐付けられた課題チケット一覧が表示されるし、チケット全体の進捗率も表示される。
よって、ロードマップ画面上で、打合せ単位の決定事項、議論の内容、残課題の内容を全て把握できる。

つまり、要件ヒヤリングや設計レビューでは、Redmineバージョンを打合せのタイミングと同期させ、さらに、RedmineバージョンのWikiに議事録を残すように運用すれば、自然に反復型開発をRedmine上で実現できるはずだ。

【1-5】では、議事録Wikiを発生源として、上流工程のトレーサビリティを実現する仕組みを作る上で、Redmine標準に足りない機能は何か？

一つ目は、Wikiから課題チケットを1クリックで作成する機能。
さらに、バージョン設定画面のWikiページから課題チケットを1クリックで作成できた場合、チケットのバージョン欄に、バージョン設定画面のWikiページのバージョン情報を自動設定するようにしたい。

そうすれば、議事録Wiki→1クリックでチケット作成、チケットのバージョンリンクから議事録Wikiへ追跡、という前方追跡のトレーサビリティが実現される。

二つ目は、議事録Wikiに、作成した課題チケットを一覧表示させる機能。
そうすれば、議事録Wikiの課題一覧表→リンク押下で各チケットへ遷移、という後方追跡のトレーサビリティが実現される。
現時点では、WikiListプラグインを使って、手作業で課題チケット番号を収集して、表形式にまとめなければならない。

但し、議事録Wikiをバージョン設定画面のWikiページで置き換えるならば、ロードマップ画面に、バージョン単位に紐付けられた課題チケット一覧が自動で表示されるので、課題は解決できる。

三つ目は、議事録Wikiの履歴を残す機能。
議事録Wikiをバージョン設定画面のWikiページで置き換えるならば、ロードマップ画面が議事録の履歴になるので、課題は解決される。

【1-6】今後は、Redmineのあらゆる画面で、チケットを1クリックで起票できる機能が強化されると良いと思う。
さらに、起票元の画面にチケットのリンクが残せるように設定できるなど、チケットと起票元の画面で相互リンクできるとなお良い。

理由は、チケット経由のトレーサビリティの範囲を拡張したいからだ。
チケット管理ツールがMSProjectやExcelよりも優れているメリットが、トレーサビリティ機能なので、その範囲をもっと広げて、Redmine単体でトレーサビリティの設定を制御したい。

現状は、構成管理ツール連携による成果物の修正履歴とチケットの相互リンクだけだが、Wikiやフォーラム、ニュースなどとも相互リンクできるようにしたい。
そうすれば、過去の要件や仕様の変更の経緯をRedmine上で追跡できるし、ソース修正がどの仕様に影響して他の機能にどれだけ影響を及ぼすのか、を考えるきっかけにもなるだろう。

実は、以前、似たような機能として、Redmineのフォーラムのメッセージからチケットを起こすプラグインもあった。
しかし、現在のRedmineでは使えないと思う。

Haruyuki Iidaさんのツイート: "フォーラムのメッセージからチケットを起こすプラグイン。フォーラムでの議論から課題が発生することはよくあるので良いかも。Redmine: Activity - Plugins: Issue from message plugin http://t.co/OkR3LWd"

Issue from message - Plugins - Redmine

Redmineプラグインあれこれメモ: プログラマの思索

【1-7】上記のように、チケットを簡単に発行できる機能と相互リンクさせる機能を強化することで、チケット管理ツールの強みであるトレーサビリティの範囲をもっと広げられるはずだろう、と思う。

上記の考えを発展させれば、下記のように整理できるだろう。

1)プログラミングなどの開発工程では、構成管理の配下にある成果物駆動でチケットを起票して、作業状況を管理していく。
もちろん、構成管理の配下にある成果物とチケットは相互リンクされる。
また、ロードマップ画面で、リリースバージョン単位に作業チケットがグルーピングされ、コミットされた成果物までドリルダウンできる。

2)テスト工程では、障害駆動でチケットを起票して、障害状況を管理していく。
もちろん、ソースの修正履歴と障害チケットは相互リンクされる。
また、ロードマップ画面で、リリースバージョン単位に障害チケットがグルーピングされ、修正ソースまでドリルダウンできる。

3)要件定義、設計工程では、顧客との要件ヒヤリング、設計レビューの打合せ議事録駆動で、チケットを起票して、課題状況を管理していく。
打合せ議事録はWikiでバージョン付けされて、課題チケットと相互リンクされる。
また、ロードマップ画面で、打合せの単位で、議事録・確定した仕様・残課題チケットが一覧表示される。
さらに、課題チケットであがった指摘内容は、構成管理の配下にある設計書へ随時コミットされ、チケットと相互リンクされる。

すなわち、上流工程から下流工程まで、チケットの発生源と作業状況を管理するチケット、成果物を相互リンクさせる運用によって、要件から成果物までのトレーサビリティを実現できるはず。
そして、上流工程のトレーサビリティの課題は、「打合せ議事録をWikiで一元管理して、Wikiに課題チケット一覧を生成する」運用で解決できるはず。

つまり、上流工程の顧客打合せで要件や仕様が決まった経緯はWikiに残し、Wikiからチケット経由のトレーサビリティが全てRedmineで一元管理できれば、ナレッジシステムへ進展できるはず。

このアイデアを試してみる。