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

はじめに

本連載では、目的に応じてプロセスを設計できるようになることを目指しています。第1回ではプロセスの構成要素、第2回ではプロセスの具体例としてＶ字モデルとスクラム、第3回ではそれらプロセスに内在するパターンについて説明してきました。

今回は、プロセスを設計する際に必ず検討しなければならない共通要素の１つとして、フィードバックを取り上げます。フィードバックは、何らかの活動を行った結果を、その活動に入力することを意味します。例えば、開発を行ったならば、その結果を開発に反映することがフィードバックになります。活動が適切に実施されていることを検証し、方向性を修正することがフィードバックの目的です。第2回、第3回と説明してきた内容を例として、フィードバックについて説明します。

Ｖ字モデルにおけるフィードバック

図1は第2回で説明したＶ字モデルです。システム開発に対するフィードバックは、システム開発が適切に実施されていることを検証し、システム開発の方向性を修正する目的で行われます。システム開発が適切に実施されるとは、どういうことでしょうか？それは、システムの使用者の要求を満たし、問題を解決することです。では、適切であることを確認するには、どうすればよいでしょうか？

Ｖ字モデルでは、要求定義によってシステムの使用者の要求を明らかにします。要求定義で定義された要求を全て満たしたならば、システム開発は適切に実施されたと考えます。定義された要求をシステムが満たしていることを確認する工程が受け入れテストです。

受け入れテストは、基本設計からシステムテストまでの活動に対するフィードバックを生みます。受け入れテストは要求定義に基づきます。受け入れテストの結果に応じて要求定義の方向性を変更することは意図していません。すなわち、受け入れテストは要求定義という活動に対するフィードバックは生んでいません。

フィードバックには活動の方向性を修正する意図があります。受け入れテストの結果に応じて活動の方向性が修正されるのは基本設計からシステムテストまでとなるため、受け入れテストは基本設計からシステムテストまでの活動に対するフィードバックを生むことになります（図2）。

同様のことが基本設計に対しても言えます。基本設計では、要求定義で定義した要求に基づきシステム仕様を決定します。システムがシステム仕様を満たしていることを確認する工程がシステムテストです。システムテストは、詳細設計から単体テストまでの活動に対するフィードバックを生みます（図3）。

ここまでの話を整理すると図4のようになります。フィードバックには対象となる活動があります。対象となる活動が何らかの結果を生みます。その結果を検証することを通じて、対象の活動が適切に実施されていることを検証し、必要に応じて対象の活動の方向性を修正します。フィードバックによって、活動の進め方、成果物の内容と質を見直します。