特集記事 特集記事アーカイブ

これまで皆さんが担当したプロジェクトで混乱は発生しませんでしたか？　どのような混乱がありましたか？

仕様変更や手戻り、納期遅れ、コスト超過など、混乱が発生しなかったプロジェクトは少ないのではないでしょうか。特に昨今のエンタープライズ領域をカバーしなければならないプロジェクトでは、混乱はつき物です。

では、なぜ混乱が発生してしまうのでしょうか。その混乱の根本的な原因はいったい何だったのでしょうか。

一般的に、プロジェクトを成功に導く上で大事にしなければならない6つの要因があります。プロジェクトを成功させるためにプロジェクト開始時、またはプロジェクト遂行時、プロジェクトのライフサイクルを通じて適切に管理していくための成功要因です。

• 目的やねらい、価値が明確化され、共有化されていること
• 対象範囲（スコープ）が明確化されていること
• 利害関係者が洗い出されていること
• スケジュールおよび成果物が定義、共有化されていること
• パフォーマンスを生み出すためのプロジェクト体制が計画されていること
• リスク管理がなされていること

特にプロジェクト開始時、プロジェクトの「目的やねらい、価値を明確にし、利害関係者との間で共有すること」は、安心安全にプロジェクトを遂行するための要です。そこをおざなりに、またはスローガン的な言葉で示しても、プロジェクトを成功に導くことが困難です。ましてや、プロジェクトのコストや納期を的確に見積もることもできません。

ITプロジェクトの現状の姿

皆さんがこれまで経験したITプロジェクトでは、要件開発を進めるための前提、「プロジェクトの目的やねらい、価値」が充分与えられておりましたか。

• プロジェクトが担わなければならないビジネス上の目的や価値、期待は明確に提供されましたか？
• その期待や価値を享受する方（利害関係者）は明確になっておりましたか？
• その期待や価値を実現するためにビジネスとして大切にしなければならないテーマ（達成目標）が明確に示されていましたか？
• そのテーマ（達成目標）を実現するための方策、達成目標（テーマ）を具現化するための制約となる事柄が示されておりましたか？

このような質問をすると、大方のプロジェクトは、目的やねらい、期待や価値があいまいな状態からプロジェクトを開始していたと感じてしまうのではないでしょうか。

ITプロジェクトにも「目的」や「ねらい」、「価値」が存在します。プロジェクトの目的やねらい、価値がわからずして、最適なICTソリューションを開発することが困難なのです。

プロジェクトが混乱するのは、技術的な側面にもまして、このような当然として必要となる前提が充分そろっていないところに原因があるのです。

しかし現実は、それらが明確に提示されることは少なく、おざなりな状態でシステム開発プロジェクトが開始されてしまいます。その結果、要件変更や手戻り、納期遅れやコスト超過などに悩まされてしまうのです。

プロジェクトの目的やねらい、価値の重要性をだれもが（受益者も供給者も）理解することで、そのような問題が回避できるのです。そして、安心・安全にプロジェクトを進めることができるようになるのです。

メタ・モデルが目指す姿

プロジェクトの目的やねらい、利害関係者がプロジェクト活動に抱く価値や期待（顕在的なものだけではなく、潜在的なものも含まれる）を形成したモデルがメタ・モデルです。そのモデルを効率かつ効果的に形成を図るために工学的に組み立てられた方法論が、メタ・モデリングです。

要求の担い手が頭のなかにしまいこんでいるビジネス成功の背後に隠れている要求を要件へと「引出し」、「気づき」と「コンセンサス形成」を育みながら、論理的なフレームワークを活用して真の要件へと形成を図っていくための工学的なやり方です。

またそれは、受益者だけではなく供給者（システム開発者）がシステムの方向性（インフラ設計、アーキテクチャ設計、拡張優位性、保守性など）を決定する際に、重要な判断情報をもたらしてくれます。

これまで、どちらかといえばシステムの設計解・技術解はシステム的な目線で選択されてきました。しかし、最適な設計解・技術解を選択するための判断ポイントは、ビジネスとしての「目的」や「ねらい」、「価値」に照らし合わせて選択されるべきものなのです。

プロジェクト要求の3つの要因

私たちは専門家として、システム開発にまつわる基本知識を持ち合わせています。教育や書籍、実践を通じて多くのことを学んできました。ですが、それらを通じて学んだことを連呼されても、そのサービスを享受する方にはなかなか受け入れてもらえません。

そのサービス（商品）を享受する方が知りたいことは、

• WHY　：　なぜそのサービス（商品）が重要なの？　どのような価値を私に提供してくれるの？
• WHAT　：　それを導入（購入）することで、具体的に何が満たされるの（実現できるの）？
• HOW　：　いくらなの？　どういった使いかたをするの？　使用上の制約はあるの？

などではないでしょうか。

つまり、「目的やねらい、価値（WHY）」と「達成目標（WHAT）」、「方策・方法（HOW）」といった3つの事柄が理解できて初めて、そのサービス（商品）の良し悪しが判断できるようになり、そのサービス（商品）が受け入れられることになります。

単にこういう活動が大事です。こういう活動を取り入れましょう。こんなやり方をします、といった説明だけでは片手落ちです。自称専門家がただ学んだことを連呼するだけの状況を見るたびに、「どうなんだろう？」と考えさせられる場面が多々見受けられます。非常に残念なことです。

ビジネスとして真に望まれるシステムを開発する上で、真の要求を開発すると同時に、利害関係者の積極的な参画と了解が必要なのです。そして、プロジェクトの要求は受益者にとっての「意味」や「価値」、「期待」に根ざしたとらえ方が必要なのです。一般的な技術解説やシステム的な目線で要件を捉えてはいけません。プロジェクトの目的やねらい、価値を捉える際に、その進め方を説明や解説する方がいますが、それではうまく要件を引出し、形成することができません。その活動のやり方を説明、解説するだけでは不十分です。あえて、活動の初期段階に時間を割き、このような活動を実施するわけですから、その活動にどのようなメリットがあるのかを具体的に語る必要があります。

同時に、それを早くドライブするためには、どのような方にどのように参画していただくことがプロジェクト活動としての最適化につながるのかを理解していただく必要があります。やり方のみを解説または説明し、目的や位置づけ、お客様の価値、プロジェクト・ライフサイクルとしての価値、お客様にとっての真の価値を共有しないで作業を進めてしまっては、せっかくの機会がもったいない（MOTTAINAI）ものとなってしまいます。

今連載では、プロジェクト要求をエンジニアリングとして形成するための工学的な取り組みを紹介しておりますが、実は要件開発方法論は、プロジェクト要求やビジネス要求、システム要求の開発を一つのプロジェクトに特化したアプローチを取るものではありません。プロジェクト横断的にビジネス・ドメイン知識やシステム・ドメイン知識を利害関係者との間で育み、共有および共用化を図ることを目的とした取り組みなのです。

強いては、ソフトウェア・ライフサイクルを通じてビジネスおよびシステムの最適化（コスト削減、保守・拡張容易性など）を図るためのアプローチなのです。

モデリングを意味づける3つの着眼点

要求開発では、それぞれの要求（プロジェクト要求、ビジネス要求、システム要求）をモデルと呼ばれるもので「見える化」「見せる化」を図っていきます。そして、当たり前のことですが、モデリングを行うための3つの着眼点を大事にしています。

まず、モデリングの「目的」です。なぜモデリングを行うのかに関する答え、それがモデリングの「目的」です。案外、モデルを作ることが目的となり、そのモデルを作成する「目的」があいまいになっていることが多いのではないでしょうか。

せっかく大事なリソースや時間を費やし、モデリングを実施するわけですから、モデルを作成する前にモデリングの目的や価値を共有し、モデルの物理量やる粒度（レベル）を決定してからモデリングを開始したいものです。

たとえば、「業務を知るために業務フローを作成しましょう」、といったことが提案されます。このとき、業務フローの物理量や粒度（レベル）に関し、しっかりした議論がなされていないように思います。また、業務フローを作成するための基準が議論されないまま作業を着手しているケースも見受けられます。これでは、いざ作業を開始してもいつ終わるのか、形成されたモデルが全てなのか、はたまた、成果物の粒度が合っているのかなど、誰も判断できないのではないでしょうか。そのためにも、しっかりした目的を持つ必要があるのです。

次に、モデルの「視点」です。誰に読んでいただきたいのか、誰にそのモデルの良し悪しを判断していただきたいのかを定めます。そのために、読み手が理解可能な表現形式をとっていきます。プロジェクト要求はそもそも要求の担い手、つまりビジネス・パーソンになるわけです。ビジネス・パーソンに理解可能な表現形式でなければ適切な判断や応えを得ることが難しくなってしまいます。

システム的な見せ方も大事になるかもしれませんが、せっかく時間をかけて形成したモデルが、読み手にうまく伝わらなかったり、難しい印象を与えてしまったりすることで、コメントやレスポンス、コンセンサスの形成が図れなくなってしまうことはとってももったいないことです。

3番目の着眼点は、「焦点」です。モデルを描く際は、中心点や論点、つまり捉えたいポイントを絞り込むことが大事です。一つのモデルにいろんな事柄が描かれてしまっては、適切な判断を得ることが難しくなってしまいます。そのために、「見せたい」ポイントを絞り込んでモデルを形成することが重要なのです。

当たり前のことですが、この3つの着眼点を見失っては、せっかく時間をかけて形成したモデルが台無しになってしまいます。特に、読み手の視点とモデリングの対象（焦点）が明確でないモデルは、読み手に「考える」ことを放棄させてしまいます。専門化が描いたモデルだからきっと間違いないだろう。なんだか難しいな、きっと大丈夫だろう。読み手が考えることを放棄してしまうことで、要件変更や仕様変更の芽を残してしまう可能性があります。ちょっとした気づかいですが、読み手に積極的に「考えてもらう」、そのために心がけておきたいことです。

要件開発方法論は、この視点と焦点をそれぞれ3層で意味づけ、各層の視点および焦点に応じたモデリングを行っていきます。同時に、各層につながり（関係）を持たせ、要件を形成していきます。

プロジェクト要件を開発するための3つの基本力

プロジェクト要件を開発するために基本となる3つの力（技術力）があります。それは、「要求引出し力」と「要求分析力」、「要件形成力」です。

要件開発者は、要求の担い手の要求を聞き出し、整理を行う人ではありません。

要求を引出し、引き出した要求のヌケヤモレ、論理性を確認していく力を身につけておかなければなりません。要求の担い手が発話したコトをきっかけに、その要求の充足度を確かめ、要求の担い手が頭の中に仕舞い込んでいる要求、または考えに及ばなかった要求をも踏まえ、引出しを行っていくことが重要なのです。

そのとき、ちょっとしたポイントとコツがあります。

要求引出し力

まず、要求の担い手が発話した情報をある一定の切り口から要求を捉えることがポイントです。

要求の担い手は、先の3つの切り口「目的（WHY）」「達成目標（WHAT）」「方法（HOW）」で要求を語ってくれることはまれなことです。そのとき、どの部分について語られているのかを見極め、不足している要件を補うことがコツです。

私もそうですが、案外人は関心を示したことは語ったとしても、完全な形で要求を発話することが少ないのです。語られた要求を鵜呑みにしない心構えが大事です。

一般的に、要求内容を正確に理解する際には、「WHY（なぜ必要なのか？）」「WHAT（何をしなければならないのか？）」「HOW（どう推進するのか？）」に要求を分類してみるとわかりやすくなります。

要件開発でも、まず要求を「目的」「達成目標」「方法」といった3つの要因で吟味するところから開始します。

プロジェクト要求は、要求の担い手の視点や焦点に応じ、この3つの要求の要因（「WHY」「WHAT」「HOW」）から要素（6W2H）へと段階的に展開していくアプローチを取っていきます。同時に、各要求の担い手に応じた要求の引出しを段階的に実施するためのワークシートを準備しています。

また、要求の担い手に応じた焦点（プロジェクトに関する要求特性）をフレームワークとして定義しております。このフレームワークを活用することで、要求の担い手が関心を示す要求のヌケやモレを確認することができるようになります。

要求分析力

また、上述のような形で確認、充足された要求も要求の要因間に矛盾があったり、他に必要な要因が抜けてしまうことがあります。これを未然に防ぐために、要求の各要因間の論理性を検証することが必要です。

そのために、要件開発では「ソフトシステム方法論（SSM）」のXYZ公式を活用し、要求の論理性を分析するアプローチを採択しています。

要件形成力

さらに、引出し、分析された要件は一つの要件でしかありません。プロジェクト要件として全体網羅的に形成を図っていく必要があります。全体網羅的に要件を形成することはとても骨の折れる作業です。特に、利害関係者との間でコンセンサスを形成することがとても骨が折れる作業です。

要件開発では、この要件の形成を効率かつ、効果的に進めていけるよう、要件の全体を示すフレームワークを提供しています。紙面の関係上、フレームワークの要因や要素、その位置づけは詳しく説明できませんが、俗人的に定義したものではなく、ビジネス・モデリング手法や方法論、ビジネス用語などに基づき定義したフレームワークです。このフレームワークに沿って、分析・検証された要件を配置していきます。

プロジェクト全体として要件を形成する際は、要件をつながりとして形成し、「見える化」することがポイントです。ある要求の担い手の目的を達成するための手段が、その手段の範囲を担当する人の目的となり、さらにはその目的が複数の手段に展開されることがあります。 ある要求の担い手の要件は、その上位組織（上司）の要件と関連し、またその組織の構成メンバーの要件を合わせると上位組織（上位）の要件が達成できるような関係性を作りながら形成を図っていくことがポイントです。　

こうして、経営層から管理層、実務層へとプロジェクト要件がつながった形で形成することが、コンセンサスを形成する上でのポイントになります。

同時に、この形成されたモデルに基づき、どこに焦点を当てた取り組みとするのかを利害関係者間で確認・共有することが重要なのです。そうすることにより、プロジェクトの範囲や優先順位づけが可能となり、システム開発時の要件変更や手戻りを回避するための手立になるのです。

このように、要求の担い手の要求を正確に理解したうえで、新しい業務プロセスを考えたり、ICT技術活用シーンを検討していくことが重要なのです。なぜならば、要求が正しく理解できていないと的外れなソリューション（ICT）を提供してしまうことにもなりかねません。その結果、要件変更が突然起こっても仕方がないことなのです。

次回は、メタ・モデリングの進め方を紹介します。当初全7回でプロジェクトの目的やねらい、価値を形式化するための方法論「メタ・モデル」を紹介する予定でした。一部の読者より、「半年以上も待たないとすべてが理解できないのは残念です」とのご意見をいただき、今回はまとまった記事を連載させていただきました。

要件開発「メタ・モデル」は、次回の「進め方」で最終回となります。