Redmineにおけるトレーサビリティの課題は何か？

Redmineにおけるトレーサビリティの現状と課題について考えたことをメモ。
ロジカルでないラフなメモ書き。

【参考】
現場の声からプロセス改善を深掘りする（3）：要求から成果物へのトレーサビリティ (1/2) - MONOist（モノイスト）

保守性・拡張性に優れたシステムを作る（11）：キミの設計に「トレーサビリティ」はあるか (2/2) - ITmedia エンタープライズ

アジャイルプロジェクトにおけるトレーサビリティ・マトリックス

チケット駆動開発がもたらした新しい観点part2～トレーサビリティの拡張: プログラマの思索

チケット駆動開発におけるトレーサビリティのチートシート: プログラマの思索

Redmineをもっと強化できるポイントpart1～上流工程のトレーサビリティ強化: プログラマの思索

アジャイル開発と要件管理: プログラマの思索

日本でモデリングツールが使われない背景: プログラマの思索

【1】ソフトウェア開発におけるトレーサビリティがいかに重要であるか、という点は、システム開発をやっている人なら痛感しているはず。

たとえば、チケット駆動開発の最大のメリットはトレーサビリティだ、という意見がRedmineによるタスクマネジメント実践技法 - プログラマーな日々で紹介されている。
派生開発や、受託開発で本番リリース直後の混乱を経験している人ならば、納得するのではないか？

（引用開始）
チケット駆動開発の効用は、何といってもトレーサビリティ（追跡可能性）の確保だろう。

ソースの変更と変更理由の結束の保証。
一度でも開発を経験した人なら、これがどれだけ大きな価値をもつか説明は不要だろう。
顧客の「いつどんな理由でこの変更をしたのですか？」という問い合わせにマネージャは即答でき、開発者はコメントが書かれていることを祈りながら過去のソースコードを追う必要がなくなるわけだから。

問題は導入コストだろう。
この書籍で実現されていることには憧憬すら覚えたが、アプリケーションは無償でも学習コストは非常に高いと感じた。

段階的導入は可能だろうか？
まずはタスクのワークフローとして使ってみるとか。導入コストは非常に大きな問題だ。
どうにかしてメンバーが前向きに取り組めるようにしないと、やらされていると感じているうちは導入は遅々として進まないだろう。

結論。開発者はもちろん、マネージャにこそ読んでほしい本だ。
（引用終了）

しかし、チケット駆動でトレーサビリティを実現できる基盤がある、と言っても、それを効果的に運用できるか否かは、その組織の成熟度に大きく依存している。

【2】トレーサビリティの利用シーンを洗い出してみる。
トレーサビリティが保証された開発プロセスでは、下記の利用シーンで大いに役立つはず。

【2-1】コードレビュー

Redmineならば、チケットにソース修正履歴があるので、レビューで修正箇所を追跡できる。
機能単位、障害単位にコードレビューしやすい。

【2-2】バグ修正や仕様変更時に、過去の要件を探る

修正対象のソースにある複雑に混み入ったIF文を勝手に修正してよいか？
本番リリース直後の混乱時に、沢山の人のパッチが当たって、何とか収束したパッチなのに、勝手に手を入れてよいのか？
意味不明なパッチにも実は過去の障害修正を引き継いでいる。
触らぬ神に祟りなし。
Redmineならば、仕様変更で修正するソースの修正履歴にチケットNoがあるので、過去の要件と仕様確定の理由を探って、修正要否を判断できる。

【2-3】顧客問合せで、現状の機能や要件の経緯を調査する

この機能はなぜ実装されたのか？　という顧客問合せ。
Redmineならば、全文検索して、チケットから要件と要件確定の経緯を探れる。

【2-4】リリース履歴として公開する

Redmineならば、リリースバージョン→チケット→ソースへドリルダウンして、成果物のソースまで追跡できる。
顧客に説明しやすくなる。
リリース後の保守作業で、開発メンバーもシステムの変更履歴を探しやすくなる。

【2-5】仕様変更のインパクト分析

仕様変更があった時、関係する機能はどれくらいの影響を受けるのか？
対象ソースを直したら、修正が発生するソースの範囲、デグレしていないことを確認すべき回帰テストの対象機能の範囲はどれくらいか？
つまり、インパクト分析で使いたい。

【2-6】トレーサビリティマトリクスの元ネタ

原理的には、縦軸が要求、横軸が機能のトレーサビリティマトリクスを出力できる。
トレーサビリティマトリクスがあれば、派生開発でソース修正を行う時、どれくらいの修正箇所があるのか、影響を受けるソースはどれだけか、回帰テストすべき対象範囲はどれくらいか、を把握できる。
たとえば、XDDPのトレーサビリティマトリクスも、原理的にはRedmineから出力できるはず。

古いプラグインだが、下記のイメージ。

Traceability matrix - Plugins - Redmine

また、トレーサビリティマトリクスを使えば、テスト工程における要件カバレッジやテストカバレッジにも利用できる。
テスト工程の中盤で、どの範囲の要件はテストで品質が保証されたか、テストで網羅できた機能や成果物はどれだけの範囲なのか、を把握できる。
しかも、時系列でトレーサビリティマトリクスや要件カバレッジ、コードカバレッジを出力できれば、品質保証の範囲の時系列の変化を見ることができて、有意義なはず。

【2-7】成果物そのものから、成果物の変更履歴を除去できる

昔は、Excel設計書の修正のたびに変更履歴を追記したり、吹き出しを書いたりしていたが、そういう変更履歴はGitのような構成管理ツールがあれば不要。
変更履歴のようなメタ情報は、構成管理ツールで管理すべき対象だから。
よって、設計書やソースから変更履歴のようなガラクタのコメントは除去されて、最新版で状態維持されているので、成果物がシンプルになる。

SCMコミットログはファイルのメタ情報: プログラマの思索

【3】しかし、トレーサビリティの実現はやはり難しいと思う。
以下、トレーサビリティの課題をあげてみる。

【3-1】トレーサビリティの保証は、手動の運用ルールだけで十分か？

チケット駆動開発の運用ルール「No ticket, No Commit」が徹底されているならば、チケット経由で「要件→チケット→成果物(ソース・設計書)」のトレーサビリティが実現される。
その運用を支える基盤は、構成管理ツール連携というRedmineの一機能で実現できている。

しかし、スキルの低いメンバーでは関連付けの意識が薄く、徹底できない場合も多い。
コミットログに書かれたチケットNoが間違っている時、漏れている時はないか？

但し、Redmineでは、コミット後に関連づけを編集する機能があるので、トレーサビリティを正しい状態へ修正する方法は残されている。

Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog

トレーサビリティは自動で生成できるか？
AIを使ったり、機械学習を使ったり、とか。

でも、自動生成されたトレーサビリティが本当に全て正しいの？という疑問がいつもある。
経験上、自動化しても多分あまり意味がないと思う。
モデル駆動開発におけるソース自動生成のアンチパターンと同じ。
自動生成に頼った運用は、メンバーのモチベーションを高めないから。

【3-2】トレーサビリティを実現する他の方法はあるか？

最も簡単かつ、今後発展性のある機能は、全文検索機能だ。
実際、アジャイルプロジェクトにおけるトレーサビリティ・マトリックスの記事でも「バージョン管理ツールや変更をトラッキングするツールを使用せよ」だけでなく、「シンプルな検索ベースのトレーサビリティ（「Googleで検索するだけ！」）」が紹介されている。

Redmineなら、全文検索プラグインを使うのが一つの解決方法。

Redmineで高速に全文検索する方法 - ククログ(2016-04-11)

Redmineでもっと高速に全文検索する方法 - ククログ(2017-09-25)

全文検索プラグインでは、チケット画面に類似チケットが表示される機能がある。
類似チケット機能は、Redmineというシステムそのものがトレーサビリティを補完する機能と見なすこともできる。
さらに、チケットにスマートフォンのスマートナビのような機能が実現されれば、面白いだろう。

【3-3】チケット関連図を作りたい

要件→チケット→ソースのマップが見たい。
つまり、Lycheeのチケット関連図のような機能がRedmineに欲しい。
この機能は、後方追跡性に相当する。

チケット関連図 | Lychee Redmine（ライチレッドマイン）でプロジェクトの見える化を。そして管理ももっと楽にしよう。

Redmine Lychee Enterpriseシリーズの解剖part3～Redmineのチケット関連図 Lychee Association ChartとRedmineの予実管理をサポートする Lychee Actual Date: プログラマの思索

利用シーンとしては、仕様変更のインパクト分析で使いたい。
たとえば、セキュリティ強化に関する要件に紐づく機能から、実装すべき機能チケットやソースへ追跡して、ソースの修正量、開発工数を測定したい。
そこから、修正見積りに使いたい。

また、プロセス保証にも使いたい。
たとえば、機能安全に関する要件に紐づく機能は本当に実装されているのか、作成された設計書やソースを追跡して、成果物に漏れがないことを確認したい。
そこから、製造物責任法や機能安全規格に関する要件を満たしていることを説明したい。

実現方法としては、親チケット＝要件、子チケット＝タスク、リビジョン＝成果物の変更スナップショット、で対応付けできれば良い。
その後、要件→チケット→ソースのリビジョンのツリー構造の絵、つまりチケット関連図を紙で出力できればいい。
また、それら要件は、リリースバージョンでグルーピングすれば、ロードマップ画面がそのままリリース履歴になる。

しかし、いくつか問題も出てくる。
大規模な要件の場合、チケット関連図にあるツリー構造は非常に複雑になるだろう。
A3の紙１枚に収まらないかもしれない。
そうなると、漏れがないのか、確認するのも大変だ。

つまり、要件となる親チケットをグルーピングしたチケット関連図が欲しくなる。
その場合、どんな内容を出力すればいいのか？

一方、ソース→チケット→要件への前方追跡性はどう実現するか？
利用シーンとしては、手を入れるソースを元に影響するソースの範囲、要件の範囲を知りたい。
そこから、ソースの修正量、回帰テストの範囲、修正工数を測定して、見積りに使いたい。
これも一つのインパクト分析。
むしろ、リスク分析にもなる。

派生開発や保守案件のリーダーにとっては、前方追跡性の方が重要だろう。
見積り作業の効率化に直結するからだ。

Lycheeのチケット関連図には、そこまでの機能はないみたい。

【3-4】トレーサビリティマトリクスを作りたい

トレーサビリティマトリクスを作っても、要求や機能の項目が多くなると、A3の１枚資料に収まらなくなる。
要求チケットやソースが多すぎると読みにくくなる。
だから、要求や機能をカテゴリ化する必要が出てくる。

これもチケット関連図の問題点と同じ。

【3-5】チケット関連図やトレーサビリティマトリクスのスナップショットを保持したい

従来は、チケット関連図やトレーサビリティマトリクスを手作業でExcelで作っていた。
しかし、仕様変更やリリースが増えるたびに、これらExcel設計書の保守コストがすごく大きくなる。
度重なる仕様変更を要件管理で反映することすら大変なのに、チケット関連図やトレーサビリティマトリクスを保守するのはもっと大変だ。

本来は、Redmineのようなツールが、チケット関連図やトレーサビリティマトリクスをいつでも欲しい時に自動生成すべきだ。
なぜなら、Redmineにトレーサビリティに関する情報は全て一元管理されているからだ。
それらは、手作業で保守して維持すべき成果物ではない。

一般に、チケット関連図やトレーサビリティマトリクスは、リリースバージョンの単位でスナップショットを残し、記録していくのが良いだろう。
つまり、リリース履歴と一緒に、チケット関連図やトレーサビリティマトリクスも出力されて、要件カバレッジやコードカバレッジも出力できる。
そうすれば、リリースのたびに、システムの要件や機能が時系列でどのように増えていっているのか、その変化を見ることもできるだろう。
たとえば、今回の仕様変更で機能やコード量が大幅に増えたね、とか、一目で分かるはず。

【4】以上のように、Redmineにおけるトレーサビリティの課題を思いつくままあげてみた。
おそらくRedmine標準の機能だけでは、トレーサビリティに関する運用は不十分だろう。

しかし、Redmineによるチケット駆動開発に埋め込まれている「構成管理ツール連携」「全文検索」という機能には大いに可能性が秘められていると思う。
Redmineという一つの箱に全てのデータが一元管理されて集約されているのだから、チケット関連図やトレーサビリティマトリクスのような要望は、チケット集計するだけのRedmineの一プラグインとして実現できるはずだ。

また、全文検索プラグインが提供する「類似チケット」のような機械学習の機能は、もっと色んなアイデアで発展できる余地がある。
Redmineのデータマイニングは、所詮はテキストマイニングに過ぎないのだから、現在のライブラリを流用して色んなことができるはず。
自分たちの会社のRedmineに蓄積された作業ログはその組織文化に依存しているのだから、その会社特有の隠語やコンテキストを事前に把握できれば、効率的に機械学習できるはず。

アイデア段階にすぎないが、トレーサビリティにまつわる機能は、Redmineがあるからこそ、その利用シーンや実現可能性を色々考えることができる。

従来は手作業でトレーサビリティに関する成果物を作成していたが、これがRedmineというツールで手軽に実現できるようになると、開発プロセスにどんな効果を与えてくれるのか？
Redmineによるトレーサビリティのプロセス基盤は、CMMIレベル4やレベル5のようなプロセス保証をどこまで、低コストで実現してくれるのか？

色々考えてみたい。