ソフトウェア開発のための中核技術は、1970年代の「構造化手法」から1980年代の「データ中心アプローチ」、1990年代の「オブジェクト指向」、そして近年は「MDA」へと変容してきました。確かに技術要素が変わってきましたが、ソフトウェア開発環境は一向に好転の兆しが見えない状況です。「仕様変更」や「ソフトウェア品質」、「ユーザ・ニーズとの不適合」などの問題に直面してしまいます。この原因として、「要求仕様の不十分さ」や「お粗末なアーキテクチャ」、「要件の複雑さ」、「不十分なテスト」、「合意形成の難しさ」などがささやかれています。それは、「要件定義に関する認識不足」や「プロジェクト活動の目的の曖昧さ」、「要件開発者の役割の曖昧さ」、「要求発生源の多様化」、「要求の複雑さ」、「コンセンサス形成の難しさ」、「要件形成の難しさ」など、要件開発に起因するとりくみが打開のカギを握っているのです。

要件開発の位置づけ

要件開発はCMMIエンジニアリング・カテゴリー「要件開発(RD)」のサブゴール「顧客要件を開発する」、「要件を分析し妥当性を確認する」活動に対応した取り組みです。開発のためのCMMI 1.2版によれば、要件の開発には次の5つの活動が含まれています。

  • 顧客のニーズ、期待、および制約を引出し、分析し、妥当性確認し、そして意思疎通をすることにより、顧客要件を獲得する
    顧客要件は、利害関係者が何に満足するかの理解を構成する
  • 利害関係者のニーズの収集および調整
  • 成果物のライフサイクル要件の開発
  • 顧客要件の確立
  • 顧客要件と首尾一貫した初期の成果物要件および成果物構成要素の要件の確立

そして、「要件開発」プロセス領域は、「SG1:顧客要件を開発する」と「SG2:成果物要件を開発する」、そして「SG3:要件を分析し妥当性を確認する」といった3つの固有ゴールで構成されています。

図:要件開発サブゴールの関連(IDEF0表記法)
図:要件開発サブゴールの関連(IDEF0表記法)

SG1 顧客要件を開発する

利害関係者のニーズや期待、制約、およびインターフェースが集められ、顧客要件に変換することが「SG1:要件を開発する」活動です。そのために、2つの固有プラクティス(SP)が制定されています。

SP1.1 ニーズを引出す
固有プラクティス「SP1.1 ニーズを引出す」とは、利害関係者のニーズや期待、制約、およびインターフェースに関する要求を引き出す活動です。要求を「引出す」とは、「要件を集めるだけではなく、顧客が明示的に提供していない追加の要件を先に見越して特定することである」と言及されています。
ここで重要なことは、顧客が明示的に提供していない追加の要件を先に見越して特定することです。この行為は、経験とか勘に委ねるのではなく、工学としてのやり方を構築することが重要なのです。
SP1.2 顧客要件を開発する
固有プラクティス「SP1.2顧客要件を開発する」とは、利害関係者のニーズや期待、制約、およびインターフェースを顧客要件に変換する活動です。認知された一連の顧客要件を文書化する際に、直接の利害関係者からのさまざまな入力を整理統合し、欠落した情報を獲得し、そして矛盾を解決する必要があります。
顧客要件は、直接の利害関係者のニーズ、期待、制約、およびインターフェースと矛盾することがあり、不整合を適切に解決してから、認知された一連の顧客要件に変換される必要があるとされています。そして、顧客要件は、要件の技術的側面ばかりではなく事業効果に関する情報に基づく決定に起因すると言及されています。

この2つの固有プラクティスを実現するための具体的なアプローチ法が「要件開発」なのです。

「目的」や「価値」を考える

仕事柄、私はお客様からの依頼を受け、提案書を作成する機会が多くあります。

その際、大事にしていること、大切にしていることがあります。それは、提案対象プロジェクトの「目的」や「価値」を深く考えることです。単に提案書を作成するのではなく、プロジェクト発足に至ったお客様のビジネス上の背景や課題、プロジェクトの目的やねらい、価値、達成目標を深く考えるよう心がけています。その時、提案書に盛り込む3つの観点を大事にしながら、目的や価値を明確にするようにしています。

  1. お客様の「価値」 : お客様はこの活動に何を期待しているのか?
  2. 「目的」「達成目標」 : そもそも、この案件はなぜ発生したのか? 何が実現できると嬉しいのか?
  3. 弊社の「価値」 : 弊社がお客様へ一番伝えたいことは何か? 弊社ならではの価値は?

また、「目的」や「価値」、「達成目標」は要求の担い手の視点により粒度もテーマも様々です。単に「目的」や「価値」、「達成目標」をバラバラにとらえるのではなく、つながりを持たせながらまとめる工夫を行います。

なぜなら、「目的」や「価値」、「達成目標」につながりが見えない提案はお客様にうまく伝えることができないからです。うまく伝えることができなかったら理解していただくことができないからです。

何気ないことですが、提案の機会を最大化するうえでも、個人/組織の知力を最大化するためにも、「目的」や「価値」を深く考え、つながりをもった提案書に仕立て上げるようにしています。

深く「考える」ことの効果

「目的」や「価値」を考えることは、お客様が弊社に対して期待していること、求めていることに他なりません。また、弊社がその活動を通じて提供したい価値なのです。

この活動の効果として、お客様に提案の趣旨が伝えられるばかりではなく、案件にかかわる一人ひとりが、プロジェクトの「目的」や「ねらい」、「価値」、「達成目標」、「進め方」、「成果物」に関する共通の認識が持てるようになります。同時に、共通の認識を持って、安心してプロジェクト活動に取り組むことができるようになります。

この「目的」や「価値」の整理ができていない状態、もしくは「目的」や「価値」が見失われた状態でプロジェクトを開始してしまった場合、その前提を整えるために膨大な時間を割かなければなりません。最終的なプロジェクトの成果も、お客様の期待とはかけ離れたものになってしまうかもしれません。プロジェクトの失敗は、この「目的」や「価値」が整っていないことに起因する問題が多いように思います。

こんなこと当然だとお思いになる方もいるのでしょうが、その前提が整わない状態のままプロジェクトが発足し、その問題が最後まで解決されない状態でモノ作りが優先されてしまっている、これが現状の姿なのではないでしょうか。そして「目的」や「価値」を考えるといった、根本的な部分をないがしろにしたため、プロジェクトが混乱し、失敗してしまうのではないでしょうか。

私たちはプロフェッショナル、専門家として知識と経験を兼ね備えています。システムとしての設計解や技術解は論理的には間違っていないのかもしれません。しかし、「目的」や「価値」を忘れた設計解・技術解はビジネスにとって意味がありません。「目的」や「価値」を明確に定めることで、ビジネスの要求にこたえるソフトウェアが開発できるのです。「目的」や「価値」を考える、ちょっとしたことですが、常に意識しておきたいことです。

要件開発は「気づき」と「納得感」を育む活動

要件開発者は、利害関係者の要求を引出し、分析し、要件のつながりを保ちながら全体網羅的に仕様として形成を図っていく役割を担っていかなければなりません。またその活動は、ソフトウェア技術に関することもさることながら、利害関係者の方々とのコンセンサス形成を図りながら活動を遂行することが重要です。

要求はあるものでも与えられるものでもありません。要件開発者と利害関係者との相互啓発を通じて、「気づき」を深めることで形成することができます。「気づき」を深めることとで「納得感」が持てる結果を導くことができます。

この「気づき」と「納得感」を得るための取り組みが要件開発なのです。

メタ・モデルの位置づけ

要件開発アプローチでは、要求を3つの類型(プロジェクトの目的、プロジェクトの達成目標、プロジェクトの方策)に分け、段階的につながりを保持させながらモデリングを行っていきます。

図:プロジェクト要求の3つの類型
図:プロジェクト要求の3つの類型

企業戦略や事業戦略、業務戦略にフォーカスを与え、プロジェクトの「目的」や「ねらい」、「価値」を深めたモデル、それが「メタ・モデル = 目的(Why)モデル」です。また、プロジェクトが達成しなければならない「目標」、つまり事業および業務、作業として達成を図らなければならないコトを深めたモデル、それが「ビジネス・モデル = 達成目標(What)モデル」です。最後に、ソフトウェア開発に望まれるコト、ソフトウェアとして実現しなければならないコトを深めたモデル、それが「システム・モデル = 方策(How)モデル」です。

このように要件開発では、「メタ・モデル」から「ビジネス・モデル」へ、そして「システム・モデル」へと段階的に要件を深めていくアプローチをとります。

本連載は、ソフトウェア開発プロジェクトが安心・安定した営みができるように、プロジェクトの成否を決めかねてしまう前提条件を整えるための「メタ・モデル」を紹介するものです。

ソフトウェア開発は、「目的」や「価値」を実現するための設計解・技術解を与えていく活動です。その時、なぜそのような設計解・技術解が必要なのかを説明するために、「目的」や「価値」に照らし合わせ判断されることになります。

つまり、「目的」や「ねらい」、「期待」や「価値」がわからなければ、適切なソフトウェアを開発することができないのです。「目的」や「ねらい」、「期待」や「価値」がわかれば、自ずと設計解・技術解も見えてきます。「目的」や「価値」が詳細な部分にいたるまで具体的であればあるほど、ソフトウェア開発も見通しが立てやすくなります。

ただ、「目的」や「価値」が明確にできたからといって必ず質の高いソフトウェア開発ができるということではありません。「目的」や「価値」がきちんと形成できれば、複雑に絡み合った要求を整理することができ、活動の初期段階で要求のヌケやモレ、ダブリに気づくことができるのです。手戻りや仕様変更を未然に防止する手立てなのです。そういった意味でも、まずプロジェクトがどこに向かおうとしているのか、「目的」や「価値」の整理を出発点にすることが重要なのです。

ソフトウェア開発がなかなか思うように進まないのは、意外とこうした情報が欠落しているところに原因が潜んでいるのではないでしょうか。

「目的」や「価値」を引き出すことは至難の技

皆さんのプロジェクトでは、ソフトウェア開発を着手するうえで必要となる要求事項は充分揃っていますか。ヒアリングやインタビューを行えば、きっと要求事項は明確にできるものと考えてはおりませんか。

私の経験では、要求事項が明確に、完全な形で提供されたことはこれまでほとんどありませんでした。しかも、ヒアリングやインタビューを通して、要求事項を明確にしようとしても、なかなかうまくいきません。

ではなぜ、要求事項を確認することが難しいのでしょうか。要求事項を明確化するための技術が未熟であるのかもしれません。でもそれだけではないのです。

そもそも、ヒアリングやインタビューは現場のキーマンを中心として要求事項を確認します。しかし、この時に2つの問題に直面してしまいます。

まず、ヒアリングやインタビューの対象者は明確な要求事項を持ち合わせていないことです。実現して欲しいことは語ってくれたとしても、その「目的」や「価値」をなかなか語ってくれないのです。実現してほしいことは、この「目的」や「価値」に基づいて評価されなければなりません。実現してほしいことが適切に評価できなければ、要求事項の取りこぼしが発生してしまいます。

私自身もそうですが、意外に人は自分が何を求めているのか、何がしたいのかに関して理由を語ることが苦手なのです。しかも、要件開発者も面と向かってその理由を確認することに尻込みしてしまうのです。

また多くの場合、事業戦略や業務戦略が加味された、つながりをもった要求事項として示されることがありません。要求事項間のつながりや要求の担い手間のつながりが示されることはないのです。

しかも、個人的な要求事項が語られ、組織としての要求事項に結びついていないケースが多く見受けられます。ですから、語られた要求事項が正解なのか、十分なのか、矛盾がないのか、真の要件を言い表しているのかを確認することが難しいのです。

このようにヒアリングやインタビューを通じて確認された要求事項を記録におさめ、そのままソフトウェア開発の前提とするのでは、とうてい混乱を避けることはできないでしょう。多くの失敗したプロジェクトの主たる原因は、要求事項を的確に整理できなかったことに起因しています。

当然プロジェクトの「目的」や「価値」は、企業の戦略や事業戦略に基づいたものでなければなりません。「目的」や「価値」を明確にしようとすれば、どうしても企業戦略や事業戦略、業務戦略、つまりビジネス抜きには語ることができないのです。そうなると、単にソフトウェア開発の目的を明確にするという作業が途端に難しくなってしまうのです。

「視点」と「焦点」を定めながら「目的」や「価値」を形成する

また「目的」や「価値」とは、要求の担い手(視点)が関心を寄せる対象(焦点)から捉えた風景にほかなりません。目的づくり段階で、どういう視点と焦点から「目的」や「価値」をとらえたのかがわからなくては、とうてい確認することも納得感を得ることも、コンセンサスを形成することもできません。視点や焦点が不明瞭であれば、異なる立場の異なる視点による意見に対して明確な対応ができなくなります。しいては、実行されるプランも戦略を欠いた場当たり的でインパクトに欠けたものになりかねないのです。

ですから、利害関係者との関係において、さまざまな角度からコミュニケーションを育みながら、適切な質問などを通して要求事項を形成すると同時に、利害関係者に「気づき」をあたえる構えが必要なのです。技術もさることながら、このことを真摯に受け止め、真の要件を開発するための工学的なアプローチを図っていかなければならないのです。

要求は人それぞれの立ち位置によって大きく異なってきます。それぞれの人が関心を示す対象も異なります。

ソフトウエア開発は、それこそ多くの立場が異なる人がかかわってきます。当然、それぞれの人が関心を寄せる対象も実現させたい姿も異なっています。

メタ・モデリングは、この「視点(関心を寄せる人)」と「焦点(関心を寄せる対象)」に基づき、プロジェクトの「目的」や「価値」、「達成目標」を引出し、分析し、形成を図っていく活動です。はじめからひとつの視点に凝り固まるのではなく、さまざまな視点から見える風景を描き、同時に「気づき」や「つながり」を大事にしていく活動です。

図:メタ・モデルの「視点」と「焦点」
図:メタ・モデルの「視点」と「焦点」

次回は、そのための基礎となる考え方「基礎知識」をご紹介いたします。