プロセスの要（かなめ） - フィードバック

Ｖ字モデルのフィードバックを検証する

Ｖ字モデルでは、要求定義によって定義された要求を全て満たしたならば、システム開発が適切に実施されたと考えます。しかし、定義された要求が不適切であったならばどうでしょう？もし定義された要求が不適切であったならば、基本設計から受け入れテストまでの前提が覆され、開発自体が不適切となります。そのため、要求定義が適切であることを検証する必要性が生まれます。

要求定義が適切であることを検証するために、レビューやインスペクションを実施することがあります。レビューやインスペクションを実施し、要求定義にフィードバックします。フィードバックによって、要求定義の進め方、要求定義の成果物の内容と質を見直します。しかし、レビューやインスペクションを実施したとしても、受け入れテスト後にシステムの使用者の要求を満たしきれないことが判明することはあり得ます。

また、受け入れテストにより基本設計からシステムテストまでの活動にフィードバックがなされたとき、そのフィードバックによる変更を反映するだけの時間がありません。このため、フィードバックにより得られるメリットが十分に活かされません。テストは成績を付けるためだけではなく、テストの結果に応じて改善を促すためにも使えます。

以上をまとめると、Ｖ字モデルのフィードバック設計には、次に示す2つの問題点があります。

• システムの使用者によるフィードバックの不足
• フィードバックの結果を開発に反映させる工程の不足

これらの問題により、使用者の満足を得るシステムの開発はイチかバチかのギャンブルになりがちです。過去に類似したプロジェクトを何度も手掛けている場合、使用者の要求が明確に定義できる場合ならばギャンブル性は低くなりＶ字モデルでも機能しますが、経験がない場合や使用者の要求が捉えきれない場合の成功はイチかバチかになってきます。

散髪に行ったときや、服を購入するときを思い出してみてください。散髪では「これでいいですか？」と顧客に確認を求めてきますし、服を買うにしても試着して確認します。満足を得るために、日常ではフィードバックが行われています。

スクラムにおけるフィードバック

スクラムはＶ字モデルにおけるフィードバックの問題を解消します。図5はスクラムの大枠の流れを示した図です。

第3回では写真撮影のゲームを例えとしてスクラムの流れを説明しました。図5におけるプロダクトバックログは顧客から提示された写真に該当します。つまり、顧客から提示された要求です。スプリントゴールは1ヶ月で撮影することを決めた写真に該当します。スクラムでは、１ヶ月でＶ字モデルにおける要求定義から受け入れテストまでを行い、動くシステムをリリース可能な状態にします。１ヶ月間の開発期間をスプリントと呼び、顧客の要求を満たしきるまでスプリントを繰り返します。

スクラムでは、スプリント毎にシステムを成長させ、スプリントが終了する毎に動くシステムが完成します。システムの使用者は完成したシステムを使うことが可能であり、使用者からのフィードバックを得られます。また、フィードバックによって得られた変更点はプロダクトバックログに反映され、次回以降のスプリントで解決する要求となります。スプリントを繰り返すことで、フィードバック結果の反映を可能とします。

スクラムではＶ字モデルにおけるフィードバックの問題は解消され、イチかバチかのギャンブルを避けることができます。もちろん、スクラムを採用することで発生するいくつかの問題を解消する必要性が新たに生まれます。プロジェクトの目的と個性に応じてプロセスを選択することが大切です。