要件定義は発注側の責任｜技術責任者のいない会社が決めること、開発会社と合意すること

要約

要件定義（どんなシステムを作り、何ができるようにするかを決めること）は、開発会社が手伝う場合でも、成果物の責任は発注側にあります。
発注側が決めるのは、目的と成功を測る数字、「やらないこと」、性能と障害対応の数値の3つです。技術の中身は、開発会社の提案を受けて一緒に詰めます。
合意は文書だけで終わらせず、早い段階の試作品と、週に一度の「動くもの」の確認で、ずれが小さいうちに直します。

技術責任者のいない会社がシステム開発を外注すると、要件定義まで開発会社に任せきりになりがちです。社内に判断できる人がいないため、開発会社の言い分をそのまま受け入れ、稼働したあとで「思っていたものと違う」と気づくことになります。CTO（技術の最高責任者）がいない会社で、私はこの失敗を何度も見てきました。

この記事では、発注側として要件定義で何を決め、開発会社とどう合意するかをまとめます。基準は、私自身が国内の開発会社にも、フィリピンの開発チームにも発注して管理してきた経験から決めたものです。

要件定義は誰の仕事か

要件定義は、発注側の仕事です。

IPA（情報処理推進機構）の資料「超上流から攻めるIT化の原理原則17ヶ条」も、「要件定義は発注者の責任である」としています。開発会社に手伝ってもらっても、責任は発注者に残ります。

同じ資料によると、要件定義は開発全体の工数の1〜2割です。それでも、開発の成否の7〜8割は、ここまでで決まります。

IPA の「ユーザのための要件定義ガイド」も、開発会社任せにせず、業務を担う部門が主体になって関わる必要があるとしています。

私の経験でも、要件定義があいまいなまま丸投げした案件は、「動くけれど使えない」システムになりました。社内に技術の分かる人がいなくても、この責任は発注側に残ります。技術の中身は開発会社に手伝ってもらってかまいません。ただし、何のために作り、何を作り、何を作らないかは、発注側が決めて文書に残しましょう。

発注側が決めることは何か

発注側が決めるのは、次の3つです。

決めること	中身	決めておかないと起きること
目的と成功を測る数字	何のために作るか、何がどうなれば成功か	「動くけれど使えない」システムになる
やらないこと	今回は作らない機能と範囲	あとからの追加の要望で、範囲が膨らむ
性能と障害対応の数値	想定するアクセス数、障害のときにどれだけで復旧するか	稼働後に「聞いていた話と違う」となる

右の列は、私が実際の案件で経験したり、先に決めて防いだりしたことです。

目的と、成功を測る数字

要件定義書（決めた内容をまとめた文書）の形は、Confluence（チームで文書を共有するサービス）のひな形が参考になります。最初に「目的」と「成功の指標」を書き、最後に「対象外」を書く形です。

目的には、この開発が会社の目標にどうつながるかを書きます。成功の指標には、うまくいったかを測る数字を記入しましょう。

ここまでは、技術が分からなくても記述できます。むしろ、事業の目的や成功の数字は、経営者にしか決められない部分です。

やらないこと

ひな形の「対象外」は、今回は扱わないものを書く欄です。やらないことをはっきり書けば、チームは目の前の作業に集中できます。あとで検討するものも、ここに書いておきましょう。

IPA の17ヶ条も「機能要求は膨張する」として、必要最低限から始め、優先順位を付けるよう求めています。

1000万円級の開発（オンライン英会話サイト、トレード分析サイトなど）を担当したときにやってよかったのは、「やらないことリスト」を要件定義書と分けて作り、開発会社と先に合意したことです。スコープ（開発で扱う範囲）の外にあるものを先に決めておいたので、あとから追加の要望が出ても、範囲が膨らみませんでした。このときの経緯は、1000万円級の開発で決めた「やらないことリスト」で説明しています。

「やらないこと」が決まらないときは、私は「他社との違いを生む部分かどうか」で考えます。自社の強みと関係のない業務、たとえば経理や勤怠管理は、自社で作らずに既製の SaaS（インターネット経由で借りて使うソフト）を使います。顧客に届ける価値そのものに関わる部分だけを、費用と時間をかけて作りましょう。

性能と障害対応の条件を、数字で書く

要件には、機能要件と非機能要件があります。機能要件は、システムができること（予約を受け付ける、請求書を出す、など）です。非機能要件は、機能以外の条件で、どれだけ速く動くか、どれだけ止まらないか、止まったときにどれだけで戻るか、といったものです。

非機能要件は、発注側と開発側で認識がずれやすい部分です。IPA も、このずれを防ぐために「非機能要求グレード」という資料を公開しています。

書き方の決め手は、言葉でなく数字にすることです。IPA の17ヶ条も、復旧の条件を「すぐに」ではなく、「5秒以内」「1分以内」のように数字で決めるよう求めています。

私自身、初期の案件では、想定するアクセス数や SLA（障害のときの対応の水準を、発注側と開発側で取り決めたもの）をあいまいにしたまま契約しました。稼働したあとで、開発会社との間に「聞いていた話と違う」という食い違いが起きています。それ以来、性能や障害対応の条件も、必ず数字で文書化しています。

期限も同じです。私はフィリピンのチームとのやり取りで、「金曜日の午後3時までに」のように、日と時刻まで決めて伝えています。「今週中に」とは言いません。受け取る人によって幅が出る言葉は、合意したことになりません。

開発会社とどう合意するか

決めたことは、文書に書くだけでは伝わりきりません。動くものを見ながら進めていきましょう。

仕様書だけで任せない

IPA の17ヶ条は「表現されない要件はシステムとして実現されない」としています。文書やモックアップ（完成後の画面を、デザインだけ先に作ったもの）などを使って要件を正確に伝えるのは、発注者の役目です。

私が失敗したのは、仕様書（作るものの機能や動きを細かく書いた文書）だけを渡して任せきりにした案件です。納品の直前になって、想定とまったく違うものが出てきました。それ以来、最初の段階から試作品（完成前に主な画面や動きを確かめるために作る簡易版）で確認する進め方に変えています。

試作品は、プログラムが完成していなくても作れます。たとえば Figma（画面のデザインを作り、チームで共有するサービス）なら、画面を操作する流れを試作でき、共有した相手も画面上で動かせます。プログラムが分からない経営者でも、画面を触りながら「ここは違う」と指摘できるのです。

週に一度、動くものを見る

私の経験でうまくいったのは、週に一度、動くものを見せてもらった案件です。認識のずれを、早いうちに直せました。うまくいった案件と失敗した案件の違いは、週次デモで防げた失敗、仕様書だけで起きた失敗で説明しています。

これは、アジャイル（短い期間で作っては確かめることを繰り返す進め方）と同じ考え方です。アジャイルの代表的なやり方のスクラムでは、1か月以内の区切りごとに、できたものを確かめる場（スプリントレビュー）を設けます。これは発表会ではなく、次に何をどう変えるかを決める場です。

発注側は、説明を聞くだけでなく、動くものを触って意見を伝えられます。

役割分担を文書化する

私が見てきた成功例では、役割分担を文書に明記し、週次の会議で「完了・遅延・課題」を数字で管理していました。

スクラムでも、何を作り、どれから作るかを最終的に決める人（プロダクトオーナー）は、会議で決めるのではなく、1人に任せます。

会議で出た課題は、GitHub Issues（課題を1件ずつ記録し、担当者を決められる機能）のようなツールで管理できます。

仕様変更は、文書に残す

仕様変更（作ると決めた内容を、途中で変えること）の扱いも、先に決めておきましょう。私は大型のプロジェクトで、週次の進捗会議と、仕様変更の文書化を義務にしていました。

スクラムでは、作るものの候補を、優先順に並べた一覧（プロダクトバックログ）で管理し、中身は随時入れ替えます。追加の要望は、その場の口約束で済ませず、一覧に載せて順番を決め直しましょう。今回の範囲に入れないなら、「やらないことリスト」の「あとで検討するもの」に入れておきます。

見積もりで、要件のあいまいさを見抜く

見積もりの金額を見ると、要件がどこまで具体的に決まっているかが分かります。

見積もりが高すぎるときは、開発会社が「念のための作業」を上乗せしていることがよくあります。反対に、極端に安い見積もりは、たいていテストや運用保守の工数が抜けています。私は見積もりを受け取ると、設計・実装・テスト・保守の4つに工数がどう配分されているか、その割合を必ず確認します。内訳の見方は、システム開発の見積もりは妥当か、工数の内訳から確かめる方法で説明しています。

見積もりが高いと感じたら、値下げ交渉する前に、要件のどこがあいまいなのかを開発会社に聞きましょう。あいまいな所を確認するのが先です。

もう1つ、私は見積もりの段階で、その開発会社やサービスから離れられなくなった場合（ベンダーロックイン）にかかる費用も試算しています。以前、日本で動画配信のシステムを開発した際、費用を抑えることを優先して、特定のデータベース（データを保存しておく仕組み）に頼った設計を選びました。あとで別のサービスへ移ろうとしたときには、大がかりな作り直しが必要になったからです。業者に縛られないための確認項目は、ベンダーロックイン対策｜技術責任者がいない会社が開発会社・クラウド・SaaSに縛られない方法と脱却の順番で説明しています。

技術が分からない経営者は、何を確かめるか

経営者は、プログラムの中身を読む必要はありません。私は技術が分からない経営者に説明するとき、技術用語を「コスト」「リスク」「時間」に言い換えて伝えています。要件定義も、次のように問えば判断できます。

この開発で、何がどうなれば成功か。数字で言えるか
今回やらないことを、開発会社と合意して文書化したか
想定するアクセス数と、障害のときの復旧の条件を、数字で書いたか
次に動くものを見られるのはいつか
仕様変更はどこに記録し、誰が決めるか
見積もりの、設計・実装・テスト・保守の割合はどうなっているか

答えがあいまいな項目は、契約の前に確認しましょう。

よくある質問

Q: 要件定義を開発会社に依頼してもよいですか。

手伝ってもらうのはかまいません。ただし、開発会社が手伝っても、成果物の責任は発注側に残ります。目的と成功の数字、やらないこと、性能と障害対応の数値は発注側が決め、開発会社が出した案がそれに合っているかを確かめてください。

Q: アジャイルで進めるなら、要件定義はいらないのですか。

いらないわけではありません。アジャイルの考え方をまとめた「アジャイルソフトウェア開発宣言」も、文書より動くソフトウェアを重んじつつ、文書や契約にも価値があるとしています。作るものの順番を決める人も必要です。何を先に作り、何をやらないかは、アジャイルでも発注側が決めます。

Q: 性能や障害対応を、自社だけでは数字にできません。

自社だけで決めきれなくてかまいません。IPA の17ヶ条も、復旧の条件は発注側と開発側が協力して決めるものとしています。開発会社に数字の案を出してもらい、その数字でよいかを、費用と合わせて判断しましょう。大切なのは、「すぐに」のような言葉のまま契約しないことです。

まとめ

要件定義は発注側の仕事です。開発会社が手伝う場合でも、成果物の責任は発注側にあります。
発注側が決めるのは、目的と成功を測る数字、やらないこと、性能と障害対応の数値の3つです。
「やらないことリスト」を要件定義書とは別に作り、開発会社と先に合意すると、範囲が膨らむのを防げます。
性能、障害対応、期限は、「すぐに」「今週中に」ではなく数字で書きます。
仕様書だけで任せず、早い段階の試作品と、週に一度の動くものの確認で合意を重ね、仕様変更は文書に残しましょう。

無料相談のご案内

PH Tech AI は、社内に技術責任者がいない中小企業・スタートアップの、技術の判断と開発体制づくりを支援しています。要件定義で何を決めればよいか、開発会社の提案や見積もりが妥当か、どう進めれば認識のずれを防げるかを、発注側の立場で一緒に整理します。無料でご相談いただけます。まずはお気軽にお問い合わせください。