「リーン開発の現場」の感想part4～トレーサビリティ、プロセスサイクル効率、構成管理

「リーン開発の現場」で読みながら気づいた点をメモ。
ラフなメモ書き。

【1】トレーサビリティ

チケット駆動開発の大きな利点の一つは、トレーサビリティだろう。
ソースから本来の仕様や障害などの変更理由をいつでも辿ることができる。
No Ticket, No Commitによって、ソースからチケットへのトレーサビリティを実現する。

「リーン開発の現場」を読むと、ヘンリックはかんばん上でトレーサビリティを実現させるための工夫を凝らしている。
第7章「準備OKを定義する」で詳しく書かれている。

機能カードが開発準備OKとなる条件として、まずID(識別子)が振られる。
そのIDは一意なキーであり、要求仕様や設計書などはWikiに記載されており、Wikiに書かれたIDと紐づくように運用されている。
この運用によって、機能カードのIDから本来の要求や詳細な設計内容を辿ることができる。
要求品質の観点では、先方追跡性が実現されている。

機能カードがシステムテスト準備OKとなる条件として、デモが完了しているなどの条件だけでなく、コミットコメントに修正理由と機能IDが残されている条件もある。
「リポジトリにコミットする時に、機能IDでタグ付されるべき」という運用は、まさに「No Ticket, No Commit」と同一だ。
この運用によって、機能カードから実装されたソースへ辿ることができる。
要求品質の観点では、後方追跡性が実現されている。

トレーサビリティは、大規模プロジェクトやオフショア開発など、コミュニケーションがどうしても不足しがちな状況では威力を発揮する。
ヘンリックは「大きなプロジェクトでは、いつもトレーサビリティについて大騒ぎするね」と書いているように、彼も同じような経験をしているのだろうと推測する。

【2】プロセスサイクル効率

12.5節「プロセスサイクル効率」で紹介されている。

プロセスサイクル効率＝作業日数/経過日数

・作業日数＝実際に開発(作業)していた日数。
　⇒WIPステージ(開発中→システムテスト準備OK→システムテスト中)で貼られていた期間。
・経過日数＝サイクルタイム。
　⇒開始日(次の10機能→開発中)から終了日(システムテスト中→受入テスト準備OK)までの期間。

プロセスサイクル効率の意味は、機能カードに携わっている期間のうち、作業待ち時間がどれくらいあったのか、を計測するメトリクスであること。
つまり、プロセスサイクル効率が低いほど、作業待ち時間が多く、無駄が多いことになる。
プロセスサイクル効率が低い機能カードは、かんばんのWIPステージに長期間貼られているものの、実際はほとんど手付かずになっている状況を意味している。

ヘンリックは、プロセスサイクル効率を効率化する意識がない限り、普通の企業では10～15％程度だろうと言っている。
この事実が正しいならば、経過日数10日の機能カードは、実は実績工数が1～1.5人日しかないことを意味する。
この状況では、実績工数1人日のチケットをリリースするには、7～10倍の期間がかかることになる。
つまり、頻繁にリリースするのはとても難しい。

こんな状況に陥りがちな理由は、ソフトウェア開発では、作業待ちになりやすい状況が多いからだろう。
例えば、要件定義後にたくさん設計書を書いたけれども、レビューアが忙しすぎて、レビュー待ちで放置され、ようやくレビューしたら、たくさんの指摘を受けて再修正が発生した。
テスト環境やテストデータが準備されていないために、せっかく開発した機能がテスト待ちで放置されて、ようやくテストしたら、予期しない障害が多発して、手戻りが大きく発生した、などの事例が思い浮かぶ。

作業待ちの時間が減らせるならば、機能カードはかんばん上をスムーズに流れ、サイクルタイムが短くなるからプロセスサイクル効率は高くなるはず。
作業待ちが多い機能カードには、必ずボトルネックが存在するので、ボトルネックを解決すれば、作業待ち時間は減るはず。
プロセスサイクル効率は改善の道具として使えるわけだ。

ソフトウェア開発で作業待ちが発生しないようにするには、特に、機能の実現可能性を調査したりテストするためのテスト環境構築、ビルドの自動化が重要であると個人的には思っている。(当たり前だけれど)

【3】構成管理

第14章「バージョン管理の方法」では、大規模プロジェクトにおける構成管理の手法が書かれている。

trunkはメインブランチであり、最新の安定したブランチ。
「安定している」とは、システムテストの準備ができていること、とヘンリックは定義している。
trunkには、機能テストが通過して、システムテスト準備OKになった機能カードが組み込まれる。

チームブランチは、各チームが開発しているブランチであり、すべてのユニットテストが通過している。
開発中のソースもコミットOKらしい。
チームブランチは、trunkと同期しているが、制限がある。
チームブランチ→trunkは、システムテスト準備OKにならなければコミットできない。
trunk→チームブランチは、毎日同期される。
もちろんコンフリクトは発生するだろうが、頻繁にマージ作業を行なっているらしい。
この運用によって、チームブランチには、開発中だが最新の状態になる。

システムテストブランチは、安定したシステムのバージョンから派生して、システムテストを行うためのブランチ。
最新の機能カードが組み込まれてシステム準備OKになったら、システムテスト中フェーズへ移して、システムブランチ上でテストする運用らしい。
この運用では、システムテストブランチでは、新しい機能カードが組み込まれないため、テストと障害修正だけに専念できる利点がある。
障害修正はシステムテストブランチ上で直接行われ、テストが終われば、trunkにマージされる。

ヘンリックの運用では、システムテストを継続的に実施するが、毎回全てのシステムテストを実施しているわけではない。
回帰テストが自動化されている保証があるし、修正された範囲が限定されているので一部のテストケースを実施すればよいという判断もある。

個人的には、大規模プロジェクトになるほど、わずか1行のソース変更でもサイクルタイムが長くなる傾向にある。
特に、設計者、開発者、テスト担当者のように複数人が役割分担する場合、そのワークフローを通過するだけでも時間がかかってしまう。
ヘンリックが言うように、ソース1行を変更して本番リリースされるまでの時間を計測しておくことは、そのプロジェクトのアジャイル度合いを直接表現するメトリクスになっているだろう。