このメルマガで何度か超上流工程の問題点（重要性）を解説してきました。また弊社Webページでも大変多くアクセスしていただいています。

URL：　http://www.kbmanagement.biz/sub64.html

そこで、今号から連載で「失敗しない要求定義」コースのコンテンツをご紹介いたします。

皆様の屈託のないご意見、感想を期待します。

今号では、まず【研修の目的（ゴール）】について解説します。次号以降、以下の各モジュールのコンテンツについて解説します。

【顧客のビジネスを知る】

【要求引き出しのファシリテーションとインタビュー】

【要求を決定するルール作り】

【要求を記述する】

【研修の目的（ゴール）】は以下のとおりです。

　「顧客の真のニーズを引き出し、モレ、曖昧さを排除した要求定義書を記述できるようになる」

大変難しいゴールを設定していることがお分かりでしょうか。

「顧客の真のニーズ」とは何でしょうか。何を意味するのでしょうか。この辺から解説したいと思います。そもそも顧客は自分の真のニーズを理解しているのでしょうか。

このコースでは、顧客はもはや自分自身の「真のニーズ」を自覚していないことを前提に設計してあります。コースの参加者には、顧客が自覚していない「真のニーズ」を明確にすることにチャレンジしてもらいます。

では一体「真のニーズ（要求）」とは一体何なのでしょうか。そもそも、「要求」とは何でしょうか。

「要求」にもいろいろあります。図をご覧ください。

この図は、有名なK. Wiegersの「ソフトウェア要求」（日経BP）からの引用です。

要求には「ビジネス要求」、「ユーザー要求」、「機能要求」、「業務ルール」．．．．様々な要求があることがお分かりになると思います。ですから「顧客の真のニーズ（要求）」も「顧客の真のビジネス要求」、「顧客の真のユーザー要求」．．．といろいろあると思います。

さらに、機能的な要求（図の左側です）もあれば非機能的な要求（図の右側です）もあります。

では、横に引かれた点線は何を意味するのでしょうか。この点線の意図は何でしょう。考えてみてください。

「ビジネス要求」は誰に聴くのでしょうか。「ユーザー要求」は誰に聴きますか。同じ人に聴きますか。「システム要求」は誰でしょう。みんな異なる顧客に聴かなければ正しい要求を引き出す事ができません。どうやら、横に引かれた点線は要求を引き出す相手の違いを意味しているようですね。

「顧客の真のニーズ」を引き出すためには、様々な要求（「ビジネス要求」や「ユーザー要求」など）に対して、適切な顧客にインタビューやファシリテーションをして、ニーズを引き出さなくてはいけません。それだけチャレンジが必要と言えます。

「真のニーズ（要求）」を分解すると、「（真の）ビジネス要求」、「（真の）ユーザー要求」、「（真の）業務ルール」、「（真の）．．．の要求」．．．になります。

上の図は分解したいくつかの要求と研修のモジュールとの関係です。

ですから、「顧客の真のニーズを引き出す」は、

　「顧客の真のビジネス要求を引き出す（明確にする）」

　「顧客の真のユーザー要求を引き出す」

　「顧客の真の．．．要求を引き出す」

　．．．．

と分解できます。

このように研修ゴールを分解し、より具体的な目的（目標）に分解する作業をゴール分析と言います。インストラクショナルデザインの重要な部分です。

次に、ゴールを分解したもの（タスクと言います）に対して学習目標を設定していきます。タスクに条件（手段）や基準を追加したものです。例えば、「ビジネス要求」では、

タスク：

−顧客のビジネス背景を理解する

−顧客の真のビジネスニーズ（要求）を明確にする

学習目標：

−ビジネス環境分析を使い、顧客のビジネス背景をメンバーに説明できるようになる

　　　−SWOT分析、ロジックツリー分析により、顧客のビジネス要求（問題対策）を明確に

することがができるようになる

これが最初のモジュール【顧客のビジネスを知る】の学習目標となります。

「ビジネス要求」を聴きだす相手は誰でしょうか。システムのユーザーでしょうか、情報システム部員でしょうか。違いますね、相手はCIOもしくは経営者（社長を含めた役員）ではないでしょうか。そのため、単にユーザーにインタビューするのとは違ったスキル（特にビジネス知識）が必要になります。普段、プロジェクトマネージャがあまり使わないスキルです。

上図の横の点線の意味が意外に大きいようです。

「ユーザー要求」はどうでしょう。

小人数ならインタビュースキルが重要です。相手が大勢いる場合は、ファシリテーションです。

「業務ルール」、「．．．の要求」も同じです。基本はインタビューとファシリテーションができれば、その他全ての要求は引き出すことができると思います。それが、2番目のモジュール【要求引き出しのファシリテーションとインタビュー】です。

引き出した要求はすべてそのまま採用されるのでしょうか。そうはいきません。プロジェクトですからQCDの制約をうけます。そのため相異なる要求に対してプライオリティ付が必要です。プライオリティがついて初めて「真のユーザー要求」になります。3番目のモジュール【要求決定のルール作り】です。

つづいて、研修ゴールの後半部分「曖昧さを排除した要求定義書を記述する」の部分です。これは単純です。そのまま4番目のモジュール【要求定義書を記述する】で扱います。

超上流工程を扱っている「失敗しない要求定義」コースの研修ゴールを解説しました。研修ゴールは難しいと感じたかもしれませんが、ゴール分析（インストラクショナルデザインの手法）を実施してタスクに分解し、学習目標を設定すればそれほど難しいものではないと感じていただけたのではないでしょうか。実際の研修は演習、ロールプレイ、ゲームを多く交えて行いますから、大変楽しく学習してもらえます。

尚、この研修ではUMLやDFDといったいわゆる工学的手法は一切扱いません。それ以前の「真の要求」を明確にする事を目的にしているからです。UMLは要らないのではなく、UMLを使用する以前のことの方が重要だと考えているからです。ご理解いただければ幸いです。

次号以降、各モジュールのコンテンツを解説していきます。まず【顧客のビジネスを知る】です。お楽しみにお待ちください。