要件定義の進め方の鉄則。”隠れたMUST要件”をあぶり出し、トラブルに備えよう

新しいプロジェクトを進めていく上でもっとも難しいと言われているのが「要件定義」と呼ばれる工程。

要件定義とは、新しいプロジェクトを実現するにあたって、「何を作るか」「どのように作るか」を決めていく工程です。

ウェブサイトでも、スマホアプリでも、あるいは実際に形のあるモノでも、必ずその製作過程には必要となる技術があり、またその特性や制約があります。

そのような詳細について無知なまま要件定義を実施してしまうことは、とても危険な行為です。場合によってはプロジェクトが頓挫してしまったり、時には訴訟に発展することも……。

今回はプロジェクトを失敗させないために、要件定義の進め方の鉄則についてご紹介します。

後藤洋平

プロジェクト工学提唱者。株式会社ゴトーラボ Founder/CEO。「チームに覇気がなく一体感がない」 「議論が空中戦になりがち」 「無駄な会議で時間を浪費しがち」 そんな組織の炎上体質を改善するための、プロジェクト工学ワークショップを提供しています。

そもそも要件定義って何？

要件定義とは、プロジェクト依頼者と受託者のあいだの約束ごと

要件定義とは、何かしらのモノづくりをする際に、完成したあとで「これは依頼したものと違う」「いや注文通りです」という争いが起きないために実施する、 ”事前の取り決め” のことです。

姿かたちのあるモノであれ、アプリやソフトウェアのようなプログラムであれ、はたまたマーケティング施策のようなものであれ、新たなプロジェクトを実現する場合には、必ず何かしらのモノづくりをします。そのモノづくりをするうえで必要になるのが「要件定義」です。

▲プロジェクト依頼者と受託者の間で正しく要件定義できていないと、このような悲劇が起こりかねない（出典：斎藤情報システムデザイン事務所）

モノづくりに着手する前の段階では、各々「こうしたい」「こうなったらいいな」という漠然としたイメージがありますが、その時点では各関係者に具体的なイメージを共有できていないでしょう。実際に作るものが、どんな要素を満たす必要があり、どんな性能を発揮すべきなのか……まだそこに存在しないものについて考えるのは、簡単ではありません。

どんなにコミュニケーションを取りながらプロジェクトを進めていても、いざ具体的なものが出てきた段階で「思ってたのと違う」となることは珍しくありません。そんな悲しい事態を避けるために、モノづくりの依頼者と受託者が一緒になって考えるのが、要件定義なのです。

見積もりが先か、要件定義が先か。 ”鶏と卵” 問題

要件定義は、「作りたいもの」と「採用する技術 / 製品 / 組織等」が組み合わさることで、初めて実施できます。依頼者の要望を無制限に聞き入れるのは、要件定義とはいえません。要件定義は、依頼者と受託者が一緒になって行うべき工程です。また専門性と付加価値が高いため、有償で実施されるべきものです。

しかし、これが法人対法人の関係性だと、すこし困ったことが発生します。それは依頼者にとっては、「要件定義を実施するためにお金を出す」のは、イコール「最終的なモノづくりをする意思決定をした」のと同義となってしまうからです。依頼者は「最初にプロジェクト全体の予算を把握したい」と思っているでしょうが、まずプロジェクトの実現方法を精査しないと、それを作るのにいくらかかるのかの見通しを立てられません。（だからこそ、要件定義が必要なのですが……）

ここで、「要件定義に費用を出すには見積が必要」という依頼者側のニーズと、「見積回答するには要件定義が必要」という受託側の事情が対立してしまいます。まさに鶏が先か、卵が先かといった問題です。

多くの場合は、過去の類似事例を参考に見積の概算を提示する方法が取られます。しかしこの時に提示していた内容が、いざ実際にプロジェクトが始まったら全然違っていた、なんてことも多く、こうしたジレンマが多くの現場の頭を悩ませているのです。

要件定義を進める前にすべきこと

最初にすべきは「モノに関係する人の洗い出し」

そのような問題を解決するために大切なのは、「完成したモノに関わる人」を見極め、その人の本音を引き出すことです。

企業組織とはひとりの人間ではなく、複数の人や部署の集合体であり、そこに所属するさまざまな人の立場や要望があります。情報システムを構築するプロジェクトであれば、それに直接関係するのはエンドユーザーだけでなく、その責任者やシステム管理者などがいます。またその情報システムに入力される情報を生み出す人や、情報システムから出力された情報を受け取る人もまた、間接的な関係者として忘れてはいけません。

このように、作るモノ自体について考えるのではなく、モノに関係する人を明確にするのが、要件定義において大切です。関係者を明確にし、彼らから事前に要望をヒアリングしておくことで、モノが完成した後に「こんなはずではなかった」と声を上げる人を減らせるのです。

要件定義に着手する前に、それぞれのセクションを代表する人に対して、事前にヒアリングを実施しましょう。

要件のヒアリングは「可能な限り多角的に」

関係者へのヒアリングの際に、ただ「どんなものが欲しいですか」と聞いて回るだけでは、もちろんダメです。誰だって人は「どんなものが欲しいか」と聞かれたら「便利なものが欲しい」というに決まっています。質問の仕方は十分に工夫しなければなりません。

質問のポイントは「可能な限り多角的に」です。例えば以下のような質問項目が考えられます。

• 現状の課題はどこか
• いまはその課題にどうやって対処（または回避）しているか
• 新しいプロジェクトに期待していることはなにか
• 過去に類似した取り組みをしたときの教訓はあるか
• 現状実現できていて、満足していることは何か

どうしても人は、いま目の前にあるものは「あって当たり前」と感じてしまいます。表面的に出てきた言葉を鵜呑みにしてしまうと、実はそれは「あったらいいな」程度の要望で、その裏に「これは絶対に外せない」というMUST要件が隠れていることもよくあるのです。

絶対に必要なものを取りこぼさないよう、質問を多角的に行い、要件を整理していきましょう。

要件定義を進める際に気をつけたいポイント

「要件定義書らしきもの」にダマされてはいけない！ 隠れたMUST要件をあぶり出そう

要件定義の進め方における最大のポイントは、発注者の頭のなかにある、でもなかなか表には出てこない「隠れたMUST要件」をあぶりだすことです。

どんなプロジェクトも、「こうだったらいいな」「ああだったらいいな」という夢とともに始まります。しかしいざ着手してみると、さまざまな現実の壁にはばまれて、最終的には「最低限これだけは……」というところにたどり着くのがやっとのことも多いです。

要件定義の工程において重要なのは、なにがMUSTで、なにがWANTなのかを見極めることです。そして意外にも、その見極めを阻害するのが「一見、上手にまとめられた要件定義書らしきもの」です。

姿かたちのないものについて考えるのは非常に大変なので、何かしら完成物になっていそうに見えるドキュメントがあると、つい人は「これに頼れば安心！」と考えてしまいがちです。しかし、そのどこに落し穴が潜んでいるかは分かりません。プロジェクトの責任を負う立場の人は、そこで思考停止せずに、自分の目と手で一次情報に接していくべきです。

「ここは着手してから考えればいいかな」はプロジェクト炎上のもと

プロジェクトにおいて想定外のトラブルをもたらす、もうひとつのポイントがあります。それは「いまは忙しいから後でやろう」という発想です。

残念ながら、要件定義どおりに進むプロジェクトはあまり多くありません。だからといって要件定義を後回ししたら、その分トラブルのもとが多く生まれます。身体の健康と同じで、病気になる前に予防するのと、病気になったあとに回復させるのでは、かかるコストが大きく違います。

多少未完成でも構わないので、「次に出すべきアウトプット」を先に洗い出しておく。そうすることで、いま手を付けている仕事のどこに問題があるかが見えてきます。そんな「前倒しの心掛け」が、転ばぬ先の杖となります。

要件定義の完了基準とは

まだ姿かたちのないモノを作るにあたっては、どんなに慎重に要件定義を進めたとしても、状況の変化や考慮不足、関係者の理解の食い違いによって、要件に変更を加えなければならないことがあります。

しかし、それではいつまでたっても要件定義を終えられません。要件定義を終えるためには、定義完了の基準を考え、合意を得ることが大切です。

筆者がおすすめしたいのは、「以下の3つの基準を満たしたらOK」とする方法です。

• やりたいこと、つくりたいモノが明示できている
• その実現手段とあわせて、代替手段が明示できている
• メリットだけでなくデメリットが考慮され、なぜその実現手段を選択したかが説明できている

メリットだけを考えて選択された手段は、かならず死角を生みます。そしてその死角が、想定外のトラブルを生みます。

デメリットや不都合な情報を認識することで、人はすこし慎重になれるのです。自動車の運転でも、「（安全）だろう」運転ではなく「（危険）かもしれない」運転が推奨されていますよね。プロジェクトの世界でもぜひ、「（危険）かもしれない」の意識を持ち続けてほしいです。