要件のまとめ方: 開発会社に伝わる資料の作り方

「システムを新しくしたい」という思いを開発会社に伝えるため、A4一枚に要望を箇条書きしたメモを渡した。ところが返ってきた見積もりは想定の3倍で、しかも肝心の機能が抜けていた。慌てて追加で説明したら、今度はスケジュールが2ヶ月延びると言われた——初めて外注する担当者から、こうした話をよく聞きます。原因の多くは、開発会社の理解力や技術力ではなく、渡した資料の作り方にあります。

「要件定義書」という言葉を聞くと、分厚くて専門的な文書を想像するかもしれません。しかし、開発会社に最初に渡す資料は、そこまで堅苦しいものである必要はありません。必要なのは、正式な様式ではなく、「何を」「なぜ」「どこまで」作ってほしいのかが、読んだ相手に誤解なく伝わる資料です。

この記事では、開発会社に発注する前に用意する要望資料を、どんな項目で構成し、どう書けば伝わるのかを、実務目線で具体的に解説します。専門知識がなくても、この記事の手順に沿って書き出していけば、開発会社との初回の打ち合わせで的確な提案を引き出せる資料が作れるようになります。

この記事で分かること

この記事を読むと、開発会社に渡す要望資料に最低限含めるべき項目と、それぞれの項目をどんな粒度・どんな書き方でまとめればよいかが分かります。悪い例と良い例を比較しながら、「伝わらない資料」が具体的にどう伝わらないのか、どう直せば伝わるようになるのかを見ていきます。あわせて、資料を渡す前の最終チェックの観点や、この資料と正式な要件定義書・RFPとの関係についても整理します。

すでに社内での課題整理や決裁者への説明を終え、「次はいよいよ資料を作って開発会社に相談する」という段階の方に、特に役立つ内容です。まだ社内準備そのものに着手していない方は、外注準備の全体像を扱った記事を先に読むことをおすすめします。

なぜ「まとめ方」でこれほど差がつくのか

結論から言うと、開発会社に伝わる資料と伝わらない資料の違いは、情報量の多さではなく、「相手が読んで具体的にイメージできるかどうか」にあります。分厚い資料を作っても、抽象的な言葉ばかりが並んでいれば開発会社側は解釈に迷いますし、逆に1枚のメモでも、事実と数字が具体的に書かれていれば、驚くほど正確な見積もりが返ってくることがあります。

伝わらない資料に共通するパターンを整理すると、次のようなものがあります。

• 「使いやすいシステムにしてほしい」「今どきの見た目にしてほしい」など、抽象的な形容詞だけで要望を表現している
• 現状の業務がどう回っているか（誰が、何を、どの順番で行っているか）の説明がなく、いきなり完成形の機能要望だけが書かれている
• 「全部大事」として優先順位がなく、開発会社側がどこまで作ればよいか判断できない
• 数字（件数、頻度、人数、金額の幅）が一切なく、規模感が伝わらない

これらに共通するのは、書いた本人の頭の中にはある情報が、資料の上では言語化されていないという点です。開発会社の担当者は、あなたの会社の業務を実際に見たことがありません。頭の中にある業務の流れや判断基準を、初めて読む人にも分かる形で文字に起こす作業こそが、「要件をまとめる」ということです。

良い要望資料とは、分厚い資料ではなく、「初めて読む人が誤解しようのない資料」のことです。専門用語より、具体的な数字と実例を優先してください。

「要件定義書」とこの記事で扱う資料の違い

正式な要件定義は、本来、開発会社と発注者が打ち合わせを重ねながら共同で作り上げていく工程であり、専門的な様式や粒度で整理された文書として仕上がります。IPA（情報処理推進機構）が公開している「共通フレーム2013」でも、要件定義はシステム開発のライフサイクルの中で独立した重要な工程として位置づけられています。

この記事で扱うのは、その正式な要件定義そのものではなく、要件定義の工程に入る前、発注者側が自社の要望を整理して開発会社に最初に渡す資料です。呼び方は会社によって「要望書」「オリエンシート」「相談メモ」などさまざまですが、役割は共通していて、「開発会社が的確な提案・見積もりを出すための材料」です。

この資料の位置づけを図にすると、次のような流れになります。

社内での課題整理
      ↓
【この記事が扱う資料】要望をまとめた資料（1〜3枚程度）
      ↓
開発会社への問い合わせ・初回打ち合わせ
      ↓
開発会社主導での正式な要件定義（詳細な仕様のすり合わせ）
      ↓
詳細見積もり・契約

つまり、この資料は「厳密な仕様書」である必要はなく、むしろ厳密さよりも「開発会社が正しく質問を返せる材料になっているか」の方が重要です。詳細な仕様の詰めは、開発会社との対話を通じて行う正式な要件定義の工程に委ねてよく、発注者側が完璧な仕様書を作ろうと気負う必要はありません。

要望資料に最低限含めたい7つの項目

開発会社に渡す資料には、最低限次の7項目を含めることをおすすめします。項目ごとに、なぜその情報が必要なのかを併記しました。

以下、それぞれの項目を具体的にどう書けばよいか見ていきます。

項目1: 背景・課題を「事実」として書く

背景・課題の欄でありがちな失敗は、「業務を効率化したい」「もっと便利にしたい」といった、目的だけを抽象的に書いてしまうことです。開発会社が本当に知りたいのは、その目的の裏にある「今、具体的に何が起きているか」という事実です。

悪い例と良い例を比較すると、違いがはっきりします。

• 悪い例: 「在庫管理が非効率なので改善したい」
• 良い例: 「在庫管理をExcelで行っており、担当者が1人しか更新方法を把握していない。担当者が休むと発注のタイミングが分からず、月に数回、欠品や過剰在庫が発生している」

良い例では、「誰が」「何を使って」「何が起きているか」「頻度はどれくらいか」という要素が入っています。これだけで、開発会社側は「複数人での同時更新が必要」「属人化の解消が目的の一つ」「発注タイミングの通知機能が有効かもしれない」といった仮説を立てられるようになります。事実を書くことは、開発会社に解決策を先回りして考えてもらうための最も効果的な方法です。

背景・課題の欄には、次の3点を意識して書くとよいでしょう。

1. 現状、何をどうやって行っているか(使っているツール・手段も含めて)
2. それによって、具体的にどんな問題が、どれくらいの頻度で起きているか
3. その問題を放置すると、今後どうなりそうか

項目2: 現状の業務フローを書き出す

現状の業務フローは、開発会社に伝わりにくい項目の代表格です。発注者にとっては当たり前すぎて説明を省略してしまいがちですが、開発会社の担当者はその業務を一度も見たことがない前提で読んでいます。

業務フローは、必ずしも専用のツールで綺麗な図を描く必要はありません。次のように、箇条書きで「誰が」「何を」「どの順番で」行っているかを書き出すだけでも、開発会社にとっては十分な情報になります。

1. 営業担当が客先で受注内容を紙の伝票に記入する
2. 事務所に戻った営業担当が、伝票の内容をExcelの受注管理表に転記する
3. 経理担当が、Excelの受注管理表を見ながら請求書を手作業で作成する
4. 請求書を印刷し、郵送で顧客に送付する

このように書き出すと、「どこに手作業が集中しているか」「どこで情報が転記され、入力ミスが起きやすいか」が一目で分かります。開発会社はこの業務フローを見て、「2と3の間を自動化すれば入力ミスと工数の両方が減らせる」といった提案がしやすくなります。逆に業務フローの説明がないまま「請求書作成を自動化したい」とだけ伝えると、開発会社側は現状のどこにボトルネックがあるのか推測するしかなく、的外れな提案につながることがあります。

業務フローを書き出す際は、次の点も併せてメモしておくと、より精度の高い提案を引き出せます。

• その業務は、1日・1週間・1ヶ月あたりどれくらいの件数・頻度で発生するか
• 業務の中で、例外的な処理（特殊な顧客への対応、締め日前後の繁忙など）はあるか
• 現状、その業務でミスや手戻りが起きやすいのはどの工程か

項目3: 要望リストは「MoSCoW」で優先順位をつける

要望を洗い出したら、必ず優先順位をつけます。優先順位のつけ方として実務でよく使われるのが、要望を4段階に分類する考え方です。厳密なフレームワーク名を覚える必要はありませんが、次の4分類は使いやすいので紹介します。

すべての要望を「Must」に分類してしまうと、開発会社はすべてを必須要件として見積もらざるを得ず、金額もスケジュールも膨らみます。逆に、優先順位が明確であれば、「まずはMustとShouldだけで一次リリースし、Couldは運用しながら追加を検討する」といった段階的な進め方も相談しやすくなります。

要望リストを作る際は、機能名だけでなく、その機能が「なぜ必要か」もセットで書いておくことをおすすめします。

• 悪い例: 「検索機能」
• 良い例: 「検索機能（過去の受注履歴を、顧客名または受注日で絞り込んで検索したい。現在はExcelのフィルタ機能で探しており、1件探すのに5分程度かかっている）」

理由が書かれていれば、開発会社側が「検索機能そのものは実は不要で、一覧表示に並べ替え機能をつけるだけで十分では」といった、より効率的な代替案を提示できることもあります。機能名だけを要求すると、開発会社はその機能をそのまま作るしかなく、代替案を検討する余地が生まれません。

項目4: 利用者の情報を数字で伝える

システムを実際に使う人の情報は、見積もりの精度に直結する重要な項目でありながら、見落とされがちです。次のような情報を、できる範囲で数字にして伝えます。

• 利用者の人数(社内の利用者、取引先などの社外利用者、それぞれの人数)
• 利用者の役割の種類(管理者、一般利用者、閲覧のみの利用者など、権限が分かれる場合はその区分)
• 利用のタイミングと頻度(毎日使うのか、月末だけ使うのか)
• 想定される同時アクセス数(多くの人が同じ時間帯に使う場面があるか)

たとえば「10人が使う社内システム」と「200店舗、合計1,000人が同時にアクセスする可能性のあるシステム」とでは、必要な設計や想定コストが大きく異なります。この情報が抜けていると、開発会社側は一般的な想定で見積もりを作らざるを得ず、後から「実際にはもっと大規模だった」と分かって手戻りが発生する原因になります。

正確な人数が分からない場合は、「およそ10〜15人程度」のように幅を持たせて構いません。重要なのは、数字を一切書かないまま進めてしまうことを避けることです。

項目5: 非機能面の希望を書く

要望のほとんどは「こういう機能が欲しい」という機能面の話に偏りがちですが、実際にはシステムの使い勝手や安全性を左右する非機能面の希望も、可能な範囲で伝えておくべきです。非機能面とは、機能そのものではなく、「どれくらい速く動くべきか」「どれくらい止まってはいけないか」「セキュリティ面でどこまで求めるか」といった品質面の条件を指します。

すべてを厳密に定義する必要はありませんが、次のような観点は最低限意識しておくとよいでしょう。

IPAが公開している「非機能要求グレード」は、こうした非機能面の要件をどんな観点で整理すればよいかを示した資料で、発注者・開発会社双方の認識合わせに使われることがあります。すべての項目を細かく埋める必要はありませんが、「重要度の高い観点だけでも、開発会社との会話の中で一度確認しておく」という使い方が実務的です。

非機能面の希望を伝えなかった場合、開発会社側は一般的な水準で設計を進めることになります。後から「もっと高い可用性が必要だった」と分かると、設計のやり直しが必要になり、追加費用や納期の遅延につながることがあるため、早い段階での共有が望ましい項目です。

項目6: 既存システムとの関係を整理する

すでに何らかのシステムやツールを使っている場合、新しいシステムがそれとどう関わるのかを明確にしておく必要があります。次の観点を整理しておきましょう。

• 今回のシステムで置き換える(廃止する)既存のツールはあるか
• 引き続き使い続けるツールで、データ連携が必要なものはあるか(会計ソフト、勤怠管理システムなど)
• 既存データ(顧客リスト、過去の取引履歴など)を新システムに移行する必要があるか、あるとすればおおよその件数
• 社内で使っているメールシステムや認証の仕組み(社員が使っているアカウントの仕組みなど)と連携する必要があるか

データ連携やデータ移行は、想像以上に工数がかかる作業です。開発会社に相談する前にこれらの有無だけでも整理しておくと、見積もりの精度が大きく変わります。特に既存データの移行は、「移行するデータの形式が古い、あるいは表記が統一されていない」といった理由で追加の作業が発生しやすいポイントなので、心当たりがあれば早めに伝えておくことをおすすめします。

項目7: 予算・スケジュールの制約を伝える

予算やスケジュールを伝えることに抵抗を感じる担当者は少なくありません。「先に金額を伝えると、その金額まで見積もりを引き上げられるのではないか」という懸念からです。しかし実務的には、予算やスケジュールの制約をまったく伝えないことの方が、双方にとって非効率になりやすいというのが実情です。

予算の情報がないと、開発会社は「フルスコープで実現した場合の金額」を提示するしかなく、その金額が予算を大きく超えていた場合、要望の絞り込みからやり直すことになります。おおよその予算の幅を伝えておけば、開発会社側も「この予算内でどこまで実現できるか」という現実的な提案がしやすくなります。

伝える際は、次のような形で構いません。

• 「予算は◯◯円程度を想定しているが、内容次第で多少の前後は検討可能」
• 「◯◯円以内に収めたいが、必須要件を満たせない場合は再検討する」

金額をぴったり決められない場合でも、「上限として動かせない金額」があるなら、それだけでも伝える価値があります。スケジュールについても同様に、「いつまでに」だけでなく「なぜその時期なのか」という理由まで伝えると、開発会社側が優先順位の調整を提案しやすくなります。

良い資料と悪い資料の違いを1枚で比較する

ここまでの内容を踏まえて、同じ「受注管理をシステム化したい」という要望を、悪い例と良い例で比較してみます。

悪い例

現在Excelで受注管理をしていますが、非効率なのでシステム化したいです。使いやすくて、今どきの見た目のシステムを希望します。予算はできるだけ抑えたいです。なるべく早く導入したいです。

良い例

現在、営業担当が客先で紙の伝票に受注内容を記入し、事務所に戻ってからExcelの受注管理表に転記しています(1日あたり平均15件)。転記時の入力ミスが月に数件発生しており、経理担当がその都度、伝票と照合して修正しています。

>

【Must】外出先のスマートフォンから受注内容を直接入力できること(転記作業と入力ミスの削減が目的)

【Should】受注データを顧客名・日付で検索できること(現状、過去の受注を探すのに数分かかっている)

【Could】受注データをもとに請求書を自動作成できること

>

利用者は営業担当5名、経理担当2名の合計7名。予算は300万円程度を想定していますが、必須要件が満たせるなら多少の前後は相談可能です。来期の新体制開始(4月)に合わせて稼働させたく、逆算すると発注から3ヶ月程度での導入を希望しています。

同じテーマでも、良い例の方が圧倒的に情報量が多く、しかも開発会社が「何を」「なぜ」「どこまで」作ればよいかを具体的にイメージできます。良い例のような資料であれば、初回の打ち合わせで開発会社側から的確な質問や代替案が返ってくる可能性が高くなり、結果的にやり取りの回数を減らせます。

開発会社に渡す前のセルフチェック

資料が一通り書けたら、開発会社に渡す前に次の観点でセルフチェックしてみてください。

• 抽象的な形容詞(使いやすい、今どきの、効率的な、など)だけで説明している箇所はないか。あれば具体的な事実や数字に置き換えられないか確認する
• 現状の業務フローが、初めて読む人にも順番通りに理解できる形で書かれているか
• 要望に優先順位(Must / Should / Could / Won't)がついているか
• 利用者の人数や頻度など、規模感が分かる数字が入っているか
• 予算やスケジュールの制約とその理由が書かれているか
• 資料全体を家族や別部署の同僚など、業務を知らない人に読んでもらっても内容が伝わるか

最後のチェックは特におすすめです。自分では十分に説明したつもりでも、業務を知らない第三者に読んでもらうと、「ここが分からない」という指摘が意外と多く出てきます。開発会社の担当者も、業務を知らない第三者という立場は同じです。

この資料とRFP・契約形態との関係

要望をまとめた資料が十分に整った状態で、複数社に同時に問い合わせて相見積もりを取る場合は、この資料がそのままRFP（提案依頼書）と呼ばれる文書の簡易版として機能します。RFPをどこまで厳密に作るべきかという論点は、RFP(提案依頼書)は中小企業に必要かで詳しく扱っていますが、ここまで紹介した7項目を書き出せていれば、相見積もりに使う資料としても十分な水準に達しています。

また、要望資料の内容は、後の契約形態の検討にも影響します。たとえば「仕様が完全に固まっている案件」であれば成果物の完成を約束する請負契約が選ばれやすく、逆に「要件が流動的で、開発を進めながら仕様を固めていきたい案件」であれば準委任契約が選ばれることもあります。この段階で契約形態まで決める必要はありませんが、要望資料に「仕様がどこまで固まっているか」「今後変更が発生しうる範囲はどこか」を書き添えておくと、開発会社側からの契約形態の提案も的確になります。

契約が具体的に動き出す段階では、開発会社から作業範囲や成果物、費用、スケジュールを明記した書面が提示されることが一般的です。IPAが公開している「情報システム・モデル取引・契約書」は、発注者と開発会社の間で交わされる契約や仕様の整理について、双方が参照できる考え方を示した資料で、契約直前の確認materials として参考になります。

よくある失敗とその防ぎ方

要望資料の作成でよく見られる失敗を、原因と対策のセットで整理します。

失敗1: 完成形のイメージだけを伝え、現状の課題を書かない

「こういう機能が欲しい」という完成形の話から入ってしまい、現状の課題や業務フローの説明が抜け落ちるパターンです。開発会社は現状を知らないまま完成形だけを渡されても、その機能が本当に課題解決に直結しているか判断できません。対策は、要望を書く前に必ず「現状、何に困っているか」を先に書き出す順番を守ることです。

失敗2: 社内の一部署の意見だけで資料を作ってしまう

窓口担当ひとりの理解だけで資料を作ると、実際にシステムを使う現場の実態と離れた要望になりがちです。可能な範囲で、実務者に業務フローと要望のヒアリングをしてから資料に反映することをおすすめします。

失敗3: 「とりあえず全部乗せ」で優先順位をつけない

要望に自信が持てないまま、思いついた機能を全部Mustとして並べてしまうパターンです。見積もり金額が跳ね上がるだけでなく、開発会社側も何を優先して提案すべきか判断できなくなります。前述のMoSCoWの考え方を使い、最低でもMustとそれ以外を分けることを徹底してください。

失敗4: 資料を1社だけに見せて終わりにする

せっかく丁寧な資料を作っても、1社にしか見せなければ、その提案が適正かどうかの判断材料がありません。同じ資料を複数社に見せることで、内容のブレなく相見積もりを取ることができます。

失敗5: 資料を作った後、更新しないまま放置する

打ち合わせを重ねる中で要望が変化することはよくありますが、最初に作った資料をアップデートしないまま話を進めると、途中から参加した担当者や、後から見積もりを再確認する際に、最新の要望と資料の内容がずれてしまいます。要望に変更があった際は、資料自体も都度更新しておくことをおすすめします。

どこまで細かく書くべきか迷ったときの目安

要望資料を作っていると、「これはどこまで細かく書くべきか」で手が止まることがあります。目安として、次の基準で判断すると迷いにくくなります。

• 数字にできる情報(人数、件数、頻度、金額の幅)は、可能な限り数字で書く
• 「なぜそれが必要か」という理由が言えない要望は、いったん保留にして再検討する
• 画面のレイアウトや細かいボタンの配置など、見た目の詳細は、この段階では無理に決めなくてよい(開発会社との打ち合わせで一緒に検討する領域)
• 業界特有の専門用語や社内独自の呼び方は、開発会社には伝わらない前提で、一言説明を添える

逆に言えば、見た目の細部まで発注者側だけで決め切ろうとする必要はありません。要望資料の役割は「何を、なぜ、どこまで」を伝えることであり、「どう実現するか」の詳細設計は開発会社の専門領域です。この線引きを意識すると、資料作成にかける時間も適切な範囲に収まります。

次に読むべき記事

要望資料が整ったら、次に検討したいのは、複数社に相見積もりを依頼する際の資料の扱い方です。RFP(提案依頼書)という言葉に身構える必要はなく、この記事で紹介した資料をそのまま活用できます。RFPをどこまで厳密に作るべきか、削ってはいけない最低限の項目について、RFP(提案依頼書)は中小企業に必要かで詳しく解説しています。

また、まだ社内での課題整理や決裁者への説明など、資料作成の前段階に取り組んでいる方は、外注準備の全体像と発注までの流れを解説した記事を先に読むことをおすすめします。資料を作成する前に、開発会社へ業務フローや売上データを開示することになる場合は、NDA(秘密保持契約)で何を確認すべきかを先に押さえておくと安心です。詳しくはシステム開発を外注するときのNDA(秘密保持契約)。中小企業が確認すべきポイントで解説しています。

情報開示

うちシスなびは、Next.jsフルスクラッチ開発やAI駆動開発を手がける開発会社である株式会社ゼットリンカーが運営しています。「外注のはじめかた」カテゴリは、当社自身の受託開発事業と関わりが深い領域であるため、要件のまとめ方についても、特定の開発会社に有利になるような誘導は避け、発注者自身が主体的に準備を進められることを目的に、中立的な立場で記載するよう努めています。運営者情報・広告方針の詳細は、サイト内の運営者情報ページをご確認ください。