要望/要求/要件/仕様/設計の違いについて解説！

プロジェクトマネジメントという仕事は、数多くの書類と向き合う仕事です。そのなかで、「要望」や「要件」といった「なんとなく大事そうな言葉」にたくさん遭遇します。

たとえば、最近のIT開発の現場で、若年層のPM見習い・開発ディレクターの方に、こんな経験をしたことがあるよ、という人も多いことだと思います。

要望とはなんぞや。要件とはなんぞや？

このことを適切に理解しないと、せっかく書いている大量の書類も、無駄になってしまうかもしれません。

要望と要求の違い

まずは、プロジェクトをキックオフしたあとに、顧客から、何百行もの「要望リスト」を渡される問題から解決しましょう。

以下の二人の登場人物、「アリス」と「ボブ」をイメージしてください。

イラスト提供：loose drawing 様　

要望と要求の違いは、ずばり、以下の通りです。

「要望」とは：
アリスのなかにある「こうだったらいいな」「ああだったらいいな」というもの
（できるかできないか、頼むか頼まないかはさておき、動機や期待として、存在している）

「要求」とは：
依頼業務における成果物や作業、期待効果について、アリスからボブに提示する内容
（ボブはそれを受けて、契約条件を提示し、互いに合意すると、契約が成立する）

プロジェクトマネジメントの世界では「要望を叶えるな、要求を叶えよ」という決まり文句があります。ベテランのPMの方は、きっと、聞いたことがあるかと思います。

通常のビジネスプロジェクトでは、始める前に、必ず作業の見通しを立てて、そこにかかるコストや時間の見積りをするものですが、どんなに事前に計画をしていたとしても、進めていく中で「こうだったらいいな、ああだったらいいな」という「叶えたいことの変化」が、いつでも、いくらでも、発生するものです。

当たり前ですが、始めたあとで、アリスの思いつきで仕事が増えていったら、ボブはパンクしてしまいます。

そうならないためには、どうするか。
「アリスは、思いつきではなく、正式に、対価を払ってやってほしい仕事として、要求を定義する。」
「ボブはそれに対して見積りを行い、互いに納得ができる条件で契約する」というふうにするのが、あるべき姿です。

PM初心者は、つい「顧客満足を高めるためには、要望を叶えなければならない」と、考えます。それはそれで間違いではありません。すべての要望を本当に叶えられたら、確かにアリスは嬉しいはずです。しかし、ボブがアリスの要望を聞きすぎて、キャパオーバーしてしまったら、アリスには不満しか残りません。

要件とはなにか

次に考えたいのが、プロジェクトマネジメントにおける頻出用語、「要件」です。「要件定義」という言葉があり、大規模開発においては、これを行う工程がとても大事だ、と、よく言われます。

では、要件とは、どういう意味か。

「要件」とは：
そのプロジェクトを完了させるために「成果物が満たすべき条件とはなにか」を相談し、定め、合意したもの

よく、辞書を引いたりすると「要件定義とは、情報システムやソフトウェアについて顧客が望んでいる機能や仕様などの概略をまとめたもののこと」といったふうに書いてあることがあります。

結果的に、要件定義書には機能や仕様について書かれることが多いので、その説明が、間違いとは言い切れないのですが、実務家は、そのような浅い理解をしていては、いけません。

「要件」の真の意味は、「そのプロジェクトや、そのプロジェクトにおける成果物がどんな条件を満たしていたら、アリスとボブの双方が、ともに納得し、よろこびあえるのか」ということです。

アリスの頭には、常に「こうだったらいいな、ああだったらいいな」という期待が、いくらでも、湧いてきます。やっていくなかで、ボブの頭にも、湧いてきます。しかし、プロジェクト活動とは、有限の人や時間、知識や技術で実行するものです。無限の要望を、有限の資源で叶えることは、できません。必ず、プロジェクトには制約条件があるのです。

この「現実的に存在する制約」を考えることが、要件定義における最大のポイントです。

「要求」とは「そもそもの趣旨や目的に照らして、その成果物に期待する効果」と言い換えることができます。

では「要件」とはなにか。「それを叶える成果物とは、どのような条件を満たしているか」を、現実的に、実現可能なものとして、整理する、ということです。

結果として「こんな機能を持っている」「こんな性能を発揮する」ということが、要件定義書には書かれるのですが、「こんな技術を用いる」「フレームワークにはこれを採用する」といった、手段に関する内容も、たくさん盛り込まれます。

アリスが良い顧客だった場合、その態度は、「要求が叶えば、手段は問わない」というものになります。そして、ボブが有能なクリエイターだった場合、二人の協力のもと、予算やスケジュールを鑑みて、また心の内にある期待や潜在的な課題についても洞察し、最後に己の強み弱みや専門性も踏まえたうえで「現実解としての、ベストな要件（必ず価値につながると信じられる、プロジェクトの核心的なゴール）」を導き出すものです。

そうでないアリスとボブがタッグを組むと、ふたりして「こうだったらいいな、ああだったらいいな」という夢を並べるだけで、実現不可能な「要件定義書もどき」を作り込んでしまいます。

この違いが、プロジェクトの成否を分けます。

仕様と設計の違い

さて、いよいよ最後に「仕様」と「設計」の違いを解説します。

「仕様」とは：
成果物を利用する状況や環境について整理し、要求する機能や性能をまとめたもの

「設計」とは：
成果物の仕上がりの形や構造、寸法を、図面などによって具体的に表現したもの

ということです。

「仕様」は「要求仕様」とも呼ばれます。
具体例を出したほうがわかりやすいので、例で示します。

分野	仕様（要求仕様）	設計
航空機 自動車 船舶など	●どのような環境で動かすか（寒冷、湿潤、夜間など） ●人や荷物はどれくらい載せたいか ●載せたいのはどんな乗客か、どんな荷物か ●オペレータのスキルレベルはどの程度か ●必要とする航行距離や燃費はどの程度か ●オプション装備は積みたいか（クレーン、大砲など） ●どのように補給や修理等のサプライを受けるか	◯外観、駆体の外観と基本構造 ◯エンジンの内部構造 ◯駆動のための構造（シャフトなど） ◯コクピットの機能（ハンドルやブレーキなど） ◯客室や貨物室の内装（壁、窓、什器など） ◯各部品の材質の選択
ITソフトウェア	●どのような環境で動かすか（端末やOSなど） ●どのような業務に対処するか（入力と出力） ●利用者の習熟度はどの程度か ●どの程度の情報量を処理するか ●必要な処理速度はどの程度か ●どのように保守やメンテナンスをするのか	◯システム構成、アーキテクチャ ◯UI/UXデザイン ◯画面の一覧と遷移 ◯データモデル ◯データベースの内部構造 ◯処理の流れやアルゴリズム ◯自動処理の設計 ◯外部連携や帳票機能
映像作品	●視聴環境（映画館、テレビ、配信など） ●ターゲット視聴者層（年齢、文化的背景、好み） ●作品のジャンルやトーン（SF、コメディなど） ●上映時間と形式（短編、長編、シリーズなど） ●メインのテーマやメッセージ ●提供する視聴覚体験の質（スリル、没入感など）	◯脚本（プロット、キャラクター設定、セリフ） ◯映像の構図と撮影手法（アングル、カット割り） ◯美術やセット、衣装、小道具 ◯照明・色彩設計 ◯演出・演技指導　VFXやCGI ◯編集の構成（カット、テンポ、視線誘導） ◯音響設計・BGM（効果音、音楽、環境音）
ゲーム	●プレイ環境（PC、コンソール、スマホなど） ●ターゲットと想定するプレイヤー層 ●ジャンル（RPG、FPS、パズルなど） ●コアとなる快感原則（探索、戦闘、協力など） ●ゲームプレイ時間 ●ストーリーや世界観 ●提供する感情や体験（達成感、爽快感など）	◯ゲームシステム、ルール設計 ◯レベルデザイン、マップ構成 ◯キャラクター、アートデザイン ◯UI/UXデザイン、操作方法の設計 ◯AIの設計（敵の行動パターン、NPC） ◯音響設計、BGM ◯モデリング、アニメーション ◯ネットワーク・オンライン機能 ◯エンジン、プラットフォームの選定
教育	●学習環境（対面授業、オンラインなど） ●学習者は誰か（年齢、学年、専門性） ●学習内容（数学、プログラミング、語学など） ●学習体験の質（楽しく学ぶ、深く考えるなど） ●学習目標とテーマ、ゴール	◯学習スタイル（講義形式、実践型など） ◯カリキュラムの構成やシラバス ◯教材、コンテンツ（テキスト、動画など） ◯タイムテーブル ◯インタラクション設計（クイズ、ディスカッション） ◯講師やファシリテーターの選定 ◯評価、認定方法の検討

要求仕様は、ビジネスモデルや業務の要請に基づいて、検討されます。これは、事業の目的や課題が明確になっていれば、そして、事業戦略・戦術のうえで、その成果物を、どのように活かしたいか（ユースケース）が明らかになれば、ある程度論理的に導き出すことができます。

設計は、その求めに応じて、それを満たすモノを、発想し、創造する、ということです。

仕様と設計を考えるうえで難しいのは、「表裏一体である」というです。ゆえに、どの問題から解決するか、ということこそが、実は、プロジェクト進行における、究極の問題でもあります。

「要求仕様をゴールとして定めて、実現する設計解を追い求める」というアプローチもあります。
（ウォーターフォール）

「まずは作って動かして、原理やからくりを理解しながら、仕様と設計を同時に追求する」というアプローチもあります。
（アジャイル）

冒頭で、「仕様書」を書いているつもりなのに「設計書」みたいになる、とか、現実にシステムが動いているのに、仕様書がない、という、IT開発現場の「あるあるネタ」を紹介しましたが、それは、「中途半端なウォーターフォールやアジャイル進行」により、起きていることです。

ちなみに、航空機や自動車の開発においては、そういう素人っぽいことは、おきません。なぜなら、伝統的に、仕様を定めてから設計する、ということが、当然のものとして長年実践されてきて、方法論やひな型が充実しているからです。一方かたやで、ITソフトやWebサービスの場合、どのぐらいの性能が出るかは、作ってみないとよくわからない、とか、既存の成果物をなぞったら、なんとなく大体は動く、という特性があるために、仕様をおざなりにしたまま、UIデザインや機能設計に注力する、ということが、よくあります。

その背景には、飛行機や自動車と、ITソフトウェアだと、求められる安全性の考え方や、性能が出るか出ないかの条件の考え方が全く異なる、ということもあったりします。深く考えていくと、非常に難しくややこしい問題なのですが、やはり、それは、健全なことではありません。

まとめ：「本当にやりたいこと」がわかって初めて、価値になる

実は、世の中のほとんどのビジネスプロジェクトにおいては、「仕様か設計か」の以前に、事業の目的や課題が不明瞭なままで、なんとなく予算をとって、なんとなく計画を立てて、なんとなく契約し、キックオフされる、ということが起きています。

たとえるならば、それは「アイスクリーム味のチャーハン」みたいなものです。

これは、要望/要求/要件/仕様/設計が、ごっちゃになっている状態です。

要望/要求/要件/仕様/設計を仕分けることは、まさに、その「ごっちゃになっている状態」を「整理整頓」することです。

それこそが、プロジェクトの成功確率を高めるための、最大のコツなのです。

著者の見聞してきた経験をもとに思いますが、こういうことが、ちゃんとできているプロジェクト現場は、ほとんど滅多に、ありません。逆にいえば、こういうことがちゃんと整理できるようになれば、飛躍的に、自身や自社の価値を高め、競争力を向上させることができます。

「仕様」と「設計」がごっちゃになってしまっている現場は、ほぼほぼ必ず「要望」と「要件」の区別に失敗しています。

さらには「要件」を「契約」として握る、ということをやるべきだ、ということを理解しておらず「ただ夢を並べた要件定義書もどき」を作成してしまっていることが、ほとんどです。

要件定義書を作成すらしていない、ということも、ままあります。それでも、なんだかんだでデザイナーやエンジニアが、気合と根性で頑張って、なんだかよくわからないが成果物が完成する、ということも多いのが、プロジェクトの面白いところでもありますが。

もっといえば、「上記のロジックや整理整頓をすっ飛ばして、いきなり設計解を提示する」という天才的なスーパークリエイターも、世の中には、います。

みんなが納得するものができれば、それでよいので、そんなプロジェクトマネジメント不在のプロジェクトでも、いいと言えばいいのですが、やはりそれは、人や組織の疲弊を招きますし、再現性というものがありません。プロジェクトの上流で整理整頓をサボると、必ず、中流下流域の誰かが（あるいはユーザーの誰かが）割りを食わされるものです。

それは、最終的には、自社の価値を毀損することにつながります。そうならないように、ぜひ、要望/要求/要件/仕様/設計の仕分けについて、考えてみていただけると幸いです。