課題駆動型開発を提案します！：開発プロセス再入門（10）（2/3 ページ）

[津田義史（豆蔵），＠IT]

文書による、プロジェクトの状態のモデル化

　課題駆動型開発における課題とはどういった性質のものなのか、紹介しましょう。

・文書という形で、可視化すべきものであること

　課題を発見したら、必ず文書にします。文書化することなく、課題を発見したと言い張ることはできません。数千もの課題を文書にすることなく、すべて頭の中だけで追跡できる人はいません。文書にしなければ、その課題に対してコミットしたことにはなりません。複数人で、その課題を共有することもできません。つまり、課題駆動型開発の文脈においては、課題と文書は同じ意味です。

・その種別によって、書式が決まること

　課題の種別ごとに、その書式が決まります。例えば、第3回 「ビルドはどのような要件を満たすべきか」ではリリースノートの、第9回「不具合追跡でよくある間違い」では不具合報告書の、書式の一例を紹介しました。各文書は必然的な項目だけで構成されるべきであり、各項目は強く意味付けされなければいけません。開発の途中で、安易に文書の項目を追加してはいけません。文書の項目が多過ぎると、書くのも読むのも面倒になるし、どこに何を書くべきなのか分からなくなってしまいます。

・ユニークなID番号が振られること

　課題間（文書間）でリンクを付けられるように、各課題（文書）にはID番号を振ります。例えば、リリースノートにはビルド番号と同じID（<製品名>-<ビルド番号>）を振ります。課題の種別ごとに、IDの書式を決めておくとよいでしょう。

・その種別によって、決められた状態を持つこと

　課題の種別ごとに、その取り得る状態があります。

　 例えば、第2回「反復開発の“反復”とは何をどのように反復するのか」ではビルドの状態遷移を紹介しました。ビルドは ［開発中］、［ビルド中］ といった状態を取ります。リリースノートにビルドの状態を記入する項目を設け、リリースノートで各ビルドの状態を追跡してください。

　また、第8回「ソフトウェアの不具合を追跡するには」では不具合の状態遷移を紹介しました。不具合は ［新規］、［解決済み］ といった状態を取ります。不具合報告書で、各不具合の状態を追跡してください。このほか、テストケースやリスクといった課題も、それぞれ異なる状態の遷移を持つはずです。

・課題の状態によって、その担当者が決まること

　第2回「反復開発の“反復”とは何をどのように反復するのか」で紹介したビルドの状態遷移と、第8回「ソフトウェアの不具合を追跡するには」で紹介した不具合報告書の状態遷移の類似性に注目してください。どちらも、状態によってその担当者が変わります。

・その解決を、実行可能なソフトウェアで確認すること

　すべての課題は、必ずあるビルドにおいて開発者が解決しなければなりません。また、その解決をQAが同じビルドで確認しなければなりません。ですから、課題には、その解決を確認するための手順が添付されなければいけません。このため、すべての課題はテストケースとしての側面を持ちます。一度解決した課題を、リグレッションテストのインプットとして利用することもできます。

・十分に小さいこと

　各課題の大きさの単位は、各ビルド（実行可能なソフトウェア）で実現できる程度にします。これにより、各ビルドで実現すべきタスクリストとして、各開発メンバーの作業を方向付けます。大きい文書を書くよりも、小さい文書をたくさん書くことで、課題解決の見積もりの精度を向上できます。また、各文書の変更を追跡しやすくなるといった効果もあります。

　このような文書を、プロジェクトチーム内にたくさん流通させることです。トヨタのかんばん方式を想像してください。かんばん方式とは、かんばんの流通によって工場内の部品在庫の引き当てを行い、部品在庫を極小化する方法です。課題駆動型開発におけるかんばん（＝解決すべき課題）は、だんだん流通量が増えていくので、トヨタのかんばんと完全に同じものではありません。が、「課題」の流通によってチーム内の人というリソースを引き当てることで、各人の作業量を正しく負荷分散します。そして、各課題の状態と流通量で、現在のプロジェクトの状態を測れます。つまり、文書を使って現在のプロジェクトの状態をモデル化できるのです。ソフトウェア開発という荒波の中を進んでいくには、現在自分たちがどこにいるのか、またどちらの方向に進んでいくべきかを確認するための羅針盤が必要です。解決すべき課題を可視化したドキュメントが、その役割を果たしてくれます。そして、すべての課題をクローズしたとき、あなたは最終ビルドを手にしているはずです。