要件定義で気を付けたい4つのポイント。「アイスクリーム味のチャーハン」を注文しないために

プロジェクトにおいて、成果物を生み出していく際には、多くの想定外が発生します。いざものをつくってみたら「求めていたものとは違った」なんてことは茶飯事。プロジェクトとは、多くの手戻りとの戦いなのです。

誰だって二度手間は避けたいものですし、大きな仕事であればなおさら。作ったあとになって「こんなはずじゃなかった……」となってしまう状況を避けるために、重要なのが「要件定義」です。

要件定義を適切に進めるためには、どこをどう気を付ければよいのでしょうか。本記事では、要件定義で気をつけるべきポイントを解説します。

後藤洋平

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

要件定義と要求定義

要件定義で気をつけるべきポイントの前に、まずは要件定義と要求定義という似た概念についてご説明しておきます。

要件定義とは、「なにをどう作るか」をすり合わせる工程

新しいものを開発したり、取り組みを実施したりするにあたって、必ずその仕事にどの程度のコスト・期間・人員・スキルが必要になるかを事前に見積もります。その見積の根拠となるのが、「要件定義」と呼ばれる工程です。

新しいプロジェクトに着手する前にあるのは「こんな課題がある」「こうなりたい」「こんなものを作りたい」といった要望・要求です。それを実現するために、実際に作るものの役割や機能、寸法や構造などを定めます。これが「設計」という作業です。設計のあとには製造があり、できたものをテストして、合格すれば検収される。各工程の重みづけには軽重あれど、ITに限らずどんなプロジェクトでも、かならずこうしたステップを踏んで進行するものです。

問題は、事前にあるのは「こうなりたい」であって「実際にこれをこう作る」ではないという点です。実際になにをどう作るかが確定していない状態では、どの程度のコストや期間を要するかがわかりません。いきなり闇雲に設計するわけにもいきません。

そこで実施するのが「要件定義」です。要件定義は以下のポイントが大切です。

• 必ず実現したいマストな内容はなにか
• 具体的にどんな技術を使って、どう組み合わせるか
• 設計作業に着手する前に、その設計がどんな基準を満たせばよいか

要求定義とは、依頼主がシステムに本当に求めているものを整理する工程

人はしばしば、深く知らない物についてオーダーするとき、知らず知らずのうちに矛盾した内容を考え出し、伝えてしまうことがあります。

「例えばこんなイメージ」と伝えた情報が、かえって相手に混乱を与えてしまう場合も。しかしそれは、悪意や無能によるものでは決してありません。むしろ善意や親切心から、さまざまな情報を整理し、分析しています。その親切心が、矛盾を呼んでしまい、かえってアダとなってしまうことがあるのです。

有能なプロジェクトマネージャは、そうした矛盾や死角に満ちた言葉が発せられたとき、文字通り受け取ることはしません。「要望」をそのまま受け取らず、「要求」に落とし込むようにします。「相手が本当に望んでいるのはこれではないだろうか」「実は他にも隠れた要望があるのではないか」と類推するのです。

これを「要求定義」と呼びます。矛盾や死角、抜け漏れのある「要望」のなかから、作り手側がシステムにどんなことを求めているのかをくくりだしていく工程です。

要件定義で気を付けたい4つのポイント

1. 「本当にやりたいことは何か」を特定する

要求定義が「こういうシステムが欲しい」の整理であるとするならば、要件定義とは「どう作るか」の明確化です。

ある内容を実現するにあたって、活用できる技術はひとつだけとは限りません。一方、コストや期間といった制約条件もあります。そして、実現方法として何かしらを選んだときに、それがそのまま実現したかったことにぴったり合致する、ということもまた少ないのです。ときには中途半端なシステムになってしまったり、99%は理想とぴったりなのに、あとちょっとだけ、肝心なところが微妙にフィットしていない……といったことは頻繁にあります。

その際に初めて、「その要件は本当に必要なのか」「ほかに代替手段はないのか」といった思考が発動します。そしてそんな思考こそが「なにが本当にやりたいことだったのか」を探る第一歩なのです。

2. 誰かが作った資料を信頼し切ってはいけない

要件定義の時点では、事前の想像とこれから起きる実際の動きの間に、どのようなギャップが存在するかを探るのが大切です。

システム開発プロジェクトの場合だと、開始するまえの見積の段階でRFP（提案依頼書）や業務フロー図、ER図やラフイメージなど、さまざまなドキュメントが作成されます。規模が大きいほど書類の量も多くなってしまうので、読み通すのも一苦労。

その際もっとも注意すべきなのは、「誰かが一生懸命考えて資料にしてくれているから、ここは深く考えなくてもオッケーだろう」と思ってはいけない、ということです。

資料作成者もまた人であり、部分的な情報をもとに想定を立てて物事を考えています。やすやすとそこに乗っかってしまったが最後、あとでフタをあけたらとんでもない認識のずれがあった、なんてことも多いのです。

3. 過去の事例から得られる情報を活用する

要件定義の際に、過去の事例はとても役立ちます。

開発プロジェクトの作り手側としては、まったく同じではないにしても、近しい目的や機能、ニーズのもとでの実績があるはずです。そこでもまた同じように、考慮漏れや想定外との戦いがあり、何かしらの成果物を作り、実証してきたのではないでしょうか。

そんな過去の情報を利用しない手はありません。過去の事例から得られる成功した情報だけでなく、難しかったことや障害になったことも含めて要件定義に盛り込み開示することで、危険予知にもつながります。

4. 未来の成果物の具体像を想定する

過去の事例を参考にするのとは逆に、未来の情報を先取りするのも大切です。

たとえば完成した納品物に、「設計書」という言葉をひとつ書いたドキュメントを添付するだけでは、そこにどの程度の詳細な情報が掲載されているか分かりません。往々にして、作り手のイメージよりもずっと高品質なものをユーザー側が求めていた、なんてことも多いです。

一つひとつに対して実施するのは手間がかかってしまうことではありますが、序盤戦では労を惜しまず、今後作っていくアウトプットの具体像を互いに確認しましょう。成果物のブレを減らすことにつながります。

要件定義のかなめは、依頼者と作り手の相互理解

人は無意識のうちに「アイスクリーム味のチャーハン」をオーダーしがち

拙著『予定通り進まないプロジェクトの進め方』で提唱した、「アイスクリーム味のチャーハン」という言葉があります。一見、変な言葉ですが、ありがたいことにグロービス社の教科書にも引用いただきました。

「チャーハンください。味は……えーと、アイスクリーム味で。ちなみにうちの子は卵アレルギーなので、代替食で。味にはこだわります。最近流行のエビ風味あんかけチャーハン、あんな感じがいいかなぁ。何かお薦めあります？　あ、あと、安くしてね！　盛り付けは綺麗なのが当然。プロなんだから、そこは気を利かせていい感じにしてくれたらオーケーです(^-^)」

飲食店で、こんな風に注文を出す人はいません。なぜなら、多くの人はアイスクリームの味もチャーハンの味もよく知っていて、基本的には互いに交わらないことをよく知っているからです。

では、こちらはどうでしょうか。

「業務アプリケーションを作りたいです。スマホとPC両方で使いますが、どちらでログインしても見せる情報量は同じにしたいです。ちなみに、ITリテラシーが低いユーザーが弊社には何人か在籍しているので、直感的で使いやすいUIがいいです。インフラは最近流行のクラウドっていうんですか、クラウドがいいです。AWS以外にもベンダーってあるんでしたっけ、おすすめの方でお願いしたいです」

もし「そんなに変なことを言っているように見えない」と感じたとしたら、それは業務システムについてあまり詳しくないからかもしれません。実際はアイスクリーム味のチャーハンと全く同じ状況です。

要件定義は、依頼者と作り手双方の協力が不可欠

新しいプロジェクトにおいて作り手側は、依頼者が何をどう求めているかの深層についてあらかじめ知っていることはまずありません。同時に依頼者側も、プロジェクトを実現する手段について詳しく知っていることはまずありません。だからこそ、ものづくりには「依頼する人」と「作る人」の役割分担が生まれるのです。

この二者が互いの状況や事情をしっかり把握できれば、どんなに未知で困難な仕事であっても、ともに力を出し合ってコラボレーションしていくことが可能になります。

逆にいえば、そのような相互理解をサボってしまうと、常に想定外トラブルに悩まされ、互いに疑心暗鬼なプロジェクトになってしまいます。

「なんとなく合意」ではなく「自信をもってGOサイン」の状態になろう

依頼者にとっても、作り手にとっても、相手の状況や事情を把握するのは、回りくどくて負担に感じる過程です。

依頼者は「面倒なことはおいといて、ざっくり話したものをいい感じにまとめてほしい」と思うでしょう。一方の作り手も「こちらがものづくりしやすくなるように、必要十分に情報を整理してさくっと資料にして渡してほしい」と思うもの。

しかし、だからといって要件定義をおろそかにしてしまい、それらしいドキュメントでOKを出してしまっては、手を付けてからとんでもないトラブルが待っているかもしれません。

そうならないためには、ただひとつしか方法はありません。「なんとなく合意」ではなく「自信をもってGOサイン」が出せるよう、誠実に、親身になって両者の意思疎通をはかることです。

序盤に手間をかけたほうが、終盤戦は楽になることが多いもの。ぜひ、要件定義の品質向上を目指していただきたいと思います。