[経営とITを結ぶビジネスアナリシス〜BABOK V3の基礎知識〜]

2015年10月9日(金)庄司 敏浩（IIBA日本支部支部活動活性化委員会委員長）

　「顧客に言われた通りに作ったのに……」──。こんな気持ちを抱いたことが読者にも少なからずあるのではないだろうか。

　情報システムを構築する際には、まず要件定義を実施し、定義された要件に基づいてシステムを開発する。開発者は、「おっしゃる通りに作りました」と納品するわけだが、それがなぜか「こんなシステムを作ってくれと頼んだ覚えはない」と顧客に受け入れを拒否されることがある。あるいは、システム構築の過程で、「どうも自分たちのイメージと合わない」と仕様の変更が何度も繰り返され、プロジェクトが混乱に陥ってしまう。なぜ、このようなことが起こるのか。

　要件定義書には、承認印が押されている。開発者は、この要件定義書の承認を盾に、顧客に自分たちが開発したシステムを受け入れるよう迫ることがよくある。　第3回で説明した「引き出しの結果を確認する」というタスクでは、「ステークホルダーの合意を確認することは非常に重要だ」と指摘した。そこで、読者に考えていただきたい。果たして、承認印を押してもらった要件定義書に記載された内容は、互いに合意が取れているといえるのだろうか？

　合意とは、相手が納得した上で、「YES」と言ってもらうことだ。相手の納得を得るには、その内容を正しく理解してもらわなければならない。顧客は要件定義書の内容を正しく理解して納得しているのだろうか？

　保険会社の方には申し訳ないが、保険の約款をイメージしてほしい。保険に入るためには、約款に合意して印を押す必要がある。だが実際には、保険契約者が約款の内容を正しく理解して印を押していることは少ないように思われる。いざというときに「約款には、こう書いてあります」と説明を受けても、「こんな細かなところまで読まないし、理解できないよ」と思う方が多いのではないかと思う。

　要件定義書も、保険の約款と同じようになっていないだろうか？ひょっとすると、顧客は要件定義書の内容を正しく理解しないまま、作業を先に進めるために印を押しているのかもしれない。それでは、顧客と真に合意したことにはならない。

要求一覧では確認は難しい

　ヒアリングした内容を一覧にまとめて、引き出した要求を確認することがある。しかし、要求一覧では、要求が適切かどうかを確認することは難しい。「適切な」というのは、要求に漏れや、過剰、誤りがなく、また、本来の目的に合致しているという意味だ。要求一覧で確認できるのは、せいぜい、その要求を言ったか言わないか程度である。

　実は、自分の思っていること、すなわちニーズを言葉で完全に表現することは難しい。だから、ニーズを聞いても、そこには漏れ、過剰、誤りが普通に潜んでいるものである。また、常に目的に合致したことを話しているとも限らない。本来の目的からずれた話をすることもよくある。差異化を図りたいはずなのに、差異化につながらない要求だらけのこともある。

　このような要求を基にシステムを開発しても、正しいシステムになるはずがない。ただし、正しくニーズを表明することは難しいが、できあがったもの、あるいは、できあがりつつあるものが、自分のニーズに合っているかどうかは評価できる。結果として、正しくない要求を反映したシステム、たとえそれが、顧客が話した要求どおりであっても、受け入れてもらえないのは、至極当然の成り行きなのだ。

　であるからビジネスアナリシスでは、単にステークホルダーが言ったとおりのソリューションを構築するのではなく、真のニーズに合致したソリューションを求めている。そのために役立つのが、「要求アナリシスとデザイン定義」と「要求のライフサイクル・マネジメント」に定義されたタスクである。

　「要求アナリシスとデザイン定義」には、要求の漏れ、過剰、誤りを探したり、本来の目的と要求が合致しているかを確認したりするタスクが含まれている。要求が適切であるかをステークホルダーに確認するためには、単なる一覧ではなく、要求の構造や要求間の関係を分かり易く表現するタスクが含まれている。

　「要求のライフサイクル・マネジメント」には、要求を定義し、要求に合致したソリューションを提供し、そのソリューションを廃棄するまで、ソリューションが要求に適合し続けるために必要なタスクが含まれている。

【知識エリア：要求アナリシスとデザイン定義】

　要求アナリシスとデザイン定義は、図1に示すように6つのタスクから成り立っている。

タスク1＝要求を精緻化しモデル化する

　引き出しの結果を分かり易く表現することを目的とするタスクである。このタスクのアウトプットは、次の2つに分けられる。

●ニーズの理解に焦点を当てると　　⇒　要求
●ソリューションに焦点を当てると　⇒　デザイン

　ここでのデザインは、ITシステムの「設計」ではない。ソリューションと、ソリューションを構築するとどのように価値を実現できるかの理解に焦点を当て、それを使用できる形で表現したものである。例えば、潜在的なプロセス改善のモデル（ITシステムを利用するかどうかは問わない）、そしてユーザーインタフェーイスのレイアウトやレポートのフォーマット定義も、すべてデザインだと考えられる。

タスク2＝要求を検証する

　要求の漏れ、過剰、誤りを正し、品質のよい要求を定義するためのタスクである。

　受け入れ可能な品質を持つ要求は、以下の特性を満たすと言われている。

●アトミックである
●完全である
●一貫性がある
●簡潔である
●実現可能である
●あいまいさがない
●テストが容易である
●優先順位が付いている
●理解が容易である

タスク3＝要求の妥当性を確認する

　本来の目的と要求が合致しているかを確認するためのタスクである。例えば、このシステムを作ることで、本当に差異化につながるチェンジが実現できるのかどうかを検討する。

タスク4＝要求アーキテクチャーを定義する

　チェンジに関するすべての要求の構造を明らかにする。要求アーキテクチャーを定義することで、すべての要求がビジネス目標を支え、ステークホルダーにとって有用な成果を生み出すことを確実にする。

タスク５＝デザイン案を定義する

　ビジネスを改善する機会を特定し、望ましい将来の状態を実現するための複数のデザイン案を示す。

タスク６＝潜在価値を分析しソリューションを推奨する

　デザイン案それぞれに関する潜在価値を見積り、最適な案はどれかを確定する。