PR

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

2011年11月8日(火)
野島 勇土屋 正人

はじめに

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

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

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

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

図1:V字モデル(クリックで拡大)

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

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

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

図2:受け入れテストによるフィードバック(クリックで拡大)

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

図3:受け入れテストによるフィードバック(クリックで拡大)

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

図4:フィードバック(クリックで拡大)
株式会社SRA

(株)SRA コンサルティンググループ所属。米国スリーインワン・コンセプツ社の提唱するストレスマネジメント手法を実践する同社認定のコンサルタント・ファシリテータ。人間の心に興味を持ち、脳科学、心理学、仏教などを学ぶ日々。個人と組織の力を引き出すために、ファシリテーションを社内外に展開中。

株式会社SRA

産業開発統括本部 製造・組込システム部 コンサルティンググループ オブジェクトモデリングスペシャリスト
1956年生まれ。コンピュータメーカを経て1982年にSRAに入社。
最初の10年は、プラント制御やデバイスドライバ等のリアルタイムシステム開発に従事。次の10年は、Webアプリケーション等のビジネスアプリケーション開発に従事。この間に習得した様々な分析設計手法を活かして、次の10年は、開発プロセスのコンサルテーションを担当中。趣味はクラシック音楽とギター、本格ミステリ、仏教(宗教としてではなく哲学・心理学として面白い)。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています