「とりあえず、こんな感じのものを作ってください」。開発会社への最初の問い合わせで、こう伝えてしまう発注者は少なくありません。特に0-10人の会社では、要件定義という専門的な作業に慣れていないため、細かい仕様を詰める前に、ざっくりとしたイメージだけを伝えて発注してしまいがちです。
しかし、この「とりあえず」という伝え方は、後々の失敗の温床になります。開発会社は発注者の頭の中を読み取ることはできず、伝えられた情報の範囲でしか提案・見積もり・開発を行えません。「とりあえず」の裏にある具体的なイメージが伝わらないまま開発が進むと、「思っていたものと違う」「これも当然含まれると思っていた」といった認識のズレが、納品直前や納品後になって表面化することになります。
この記事では、専門的な要件定義の知識がなくても作れる、最初の要望メモの書き方を、具体的なテンプレートとともに解説します。本格的な要件定義書ではなく、あくまで「開発会社に伝わる最初の一歩」としての要望メモに焦点を絞っている点が、本ガイドの特徴です。より体系的な要件のまとめ方については、コラム要件のまとめ方: 開発会社に伝わる資料の作り方で詳しく解説されているので、要望メモを書き終えた後、さらに精度を上げたい場合はあわせて参照してください。
なぜ「とりあえず」が失敗を招くのか
まず、「とりあえず作ってもらう」という伝え方がなぜ危険なのかを整理しておきます。開発会社は、伝えられた情報をもとに、次の3つを組み立てます。
- 見積もり金額: どこまでの機能を、どれだけの手間で作るかによって金額が決まる
- 開発スケジュール: 何を、いつまでに作るかの計画
- 提案内容: 発注者の困りごとに対して、どんな解決策が適切かの判断
「とりあえず」という曖昧な伝え方では、これら3つのいずれも精度が下がります。開発会社は不足した情報を独自に推測して補うしかなく、その推測が発注者の期待とズレていた場合、見積もりも、スケジュールも、提案内容も、すべてがズレたまま進んでしまいます。そして、このズレが発覚するタイミングが遅ければ遅いほど、修正にかかる手間とコストは大きくなります。
つまり、要望メモを作るという行為は、開発会社のためというよりも、発注者自身が期待通りの成果物を得るための、自己防衛の手段でもあるのです。
要件定義とは何が違うのか
「要望メモ」と「要件定義」は、混同されがちですが、目的も精度も異なるものです。両者の違いを整理しておきます。
| 要望メモ | 要件定義 |
|---|---|
| 作成者 | 発注者(自分で書く) |
| 精度 | 大まかな困りごと・目的・希望 |
| タイミング | 問い合わせ前・初回打ち合わせ前 |
| 専門知識 | 不要 |
要件定義は、専門的な知識と経験を要する作業であり、通常は開発会社が発注者にヒアリングをしながら共同で作り上げていくものです。0-10人の会社が、契約前の段階でここまで精緻な文書を自力で用意する必要はありません。この記事で扱う「要望メモ」は、あくまで要件定義の手前、「開発会社に的確に伝わる最初の一歩」を目的とした、もっと簡易なものです。
要望メモに最低限含めるべき6つの項目
要望メモに含めるべき項目を、実際に使えるテンプレートの形で示します。難しく考える必要はなく、それぞれ2〜3行程度で構いません。
- 困りごと・背景: 今、何に困っているか。なぜこのシステムが必要なのか
- 目的: このシステムによって、最終的に何を実現したいか
- 利用者: 誰が、どのくらいの頻度で使うか
- やりたいこと(機能イメージ): 具体的に何ができるようになってほしいか
- 現状の代替手段: 今、その業務をどう処理しているか(Excel、紙、口頭連絡など)
- 予算・希望時期: 出せる予算の上限、いつまでに使いたいか
この6項目を、それぞれ2〜3行の短文で埋めるだけで、開発会社にとって十分に意味のある要望メモが完成します。次のセクションで、実際の記入例を示します。
悪い例と良い例の比較
要望メモの精度がどう変わるかを、具体的な記入例で比較してみます。
悪い例
顧客管理システムが欲しいです。Excelで管理しているのが大変なので、システム化したいです。予算は100万円くらいで、なるべく早く作ってほしいです。
一見それらしく見えますが、この文章からは「どんな困りごとが」「どんな利用シーンで」「何を実現したいか」が具体的に読み取れません。開発会社はこの情報だけでは、機能の範囲を推測するしかなく、精度の低い提案・見積もりしか返せません。
良い例
【困りごと・背景】現在、顧客情報を営業担当者ごとにExcelファイルで管理しており、誰がどの顧客と、いつ、どんなやり取りをしたかが社内で共有できていません。担当者が不在の時に別の人が対応できず、機会損失が発生しています。
>
【目的】顧客とのやり取り履歴を、営業担当者3名全員が同じ画面で確認できるようにしたいです。
>
【利用者】営業担当者3名。1日数回、外出先からスマートフォンでも確認したいです。
>
【やりたいこと】顧客情報(会社名・担当者名・連絡先)の登録、やり取り履歴(日付・内容)の記録、直近のやり取りが一覧で見られる画面が欲しいです。
>
【現状の代替手段】Excelファイルを共有フォルダに置いて、各自が更新しています。
>
【予算・希望時期】予算は100万円前後を想定しています。3ヶ月以内に使い始めたいです。
この良い例では、開発会社が「営業担当者3名向けの、スマートフォン対応を含む顧客管理システム」という具体的なイメージを持って、精度の高い提案・見積もりを組み立てることができます。困りごとの背景まで書かれていることで、単なる機能要望を超えて、開発会社側からの提案(例えば「この規模ならスプレッドシート連携で十分かもしれません」といった代替案)も引き出しやすくなります。
「やりたいこと」を書く際の3つのコツ
要望メモの中でも、特に書きにくいのが「やりたいこと(機能イメージ)」の項目です。ここでは、この項目をスムーズに書くための3つのコツを紹介します。
コツ1: 機能名ではなく、動作をイメージして書く
「予約管理機能が欲しい」という機能名だけでなく、「お客様がWebサイトから空き状況を見て、日時を選んで予約できるようにしたい」というように、実際の操作の流れをイメージして書くと、開発会社に伝わりやすくなります。
コツ2: 「誰が」「何を」「どうする」の形で書く
「営業担当者が、顧客の情報を登録できる」「経理担当者が、月末に売上の一覧をダウンロードできる」というように、主語と動作をセットで書くことで、曖昧さが減ります。
コツ3: 優先順位をつける
すべての要望を同列に並べるのではなく、「これは絶対に必要」「これはあれば嬉しい」という優先順位を明記しておくと、予算内に収まらない場合に、開発会社側が削る箇所を判断しやすくなります。この優先順位づけは、限られた予算の中で発注する0-10人の会社にとって特に重要です。予算帯ごとに現実的な範囲がどのくらいかについては、予算50万円〜200万円で頼める範囲はどこまでかも参考にしてください。
「困りごと・背景」を書くと、なぜ提案の質が上がるのか
要望メモの中で、最も見落とされがちでありながら、実は最も重要なのが「困りごと・背景」の項目です。多くの発注者は、いきなり「やりたいこと」から書き始めてしまいますが、その手前にある「なぜそれが必要なのか」を伝えることで、開発会社からの提案の質が大きく変わります。
例えば、「顧客管理システムが欲しい」という要望だけを伝えた場合と、「担当者が不在の時に別の人が顧客対応できず、機会損失が発生している」という背景まで伝えた場合とでは、開発会社が導き出す解決策が異なることがあります。後者の背景を伝えられた開発会社は、「顧客管理システムの新規開発」以外にも、「既存のノーコード・ローコードツールでの代替」や「もっと簡易な情報共有の仕組み」といった、コストを抑えた代替案を提示できる可能性があります。
背景を伝えることは、開発会社に「余計な情報」を与えることではなく、むしろ発注者にとって最適な解決策を引き出すための重要な情報提供なのです。
要望メモを書く前に、社内で確認しておくべきこと
要望メモを一人で書き上げる前に、実際にそのシステムを使うことになるメンバーがいる場合は、事前に簡単なヒアリングをしておくことをお勧めします。特に確認しておきたいのは次の点です。
- 現状の業務で、具体的にどこに時間がかかっているか
- システム化された場合、業務フローがどう変わってほしいか
- 逆に、変えてほしくない部分(慣れた操作方法など)はあるか
10人未満の会社では、経営者が一人で要望メモを書き上げてしまうケースが多く見られますが、実際に日々の業務で困っている現場の声を反映させないと、完成したシステムが「経営者は満足しているが、現場は使いにくい」という結果になりかねません。たとえ簡単な聞き取りであっても、現場の声を要望メモに反映させることを心がけてください。
悪気なく起こる「言った・言わない」を防ぐ書き方
要望メモを作成する際、後々のトラブルを防ぐために意識しておきたいのが、「暗黙の前提」をできるだけ言語化することです。発注者にとっては「当然そうだろう」と思っていることでも、開発会社にとっては明記されない限り分からない、ということが頻繁に起こります。
暗黙の前提になりやすい項目の例を挙げます。
- スマートフォンでも使えることを前提としているか、パソコンのみでよいか
- 社外の人(取引先や顧客)も使う想定か、社内メンバーのみか
- 既存の他のシステム・サービスとの連携が必要か
- データの引き継ぎ(既存のExcelや別システムからの移行)が必要か
これらの項目は、要望メモの「やりたいこと」の欄に含めるか、あるいは別途「補足事項」として書き加えておくとよいでしょう。「言わなくても分かるだろう」という思い込みを捨て、少しでも重要だと思う前提条件は、面倒でも書き出しておく習慣をつけてください。
要望メモを渡した後、開発会社からの質問には正直に答える
要望メモを開発会社に渡すと、多くの場合、開発会社側から追加の質問が返ってきます。「この機能は、具体的にどんな画面をイメージしていますか」「この情報は、誰が入力する想定ですか」といった質問です。
ここで注意したいのは、分からないことを無理に取り繕わず、「そこはまだ決めていません、一緒に考えてもらえますか」と正直に答えることです。要望メモはあくまで最初のたたき台であり、完璧である必要はありません。開発会社からの質問に答えていく過程そのものが、実質的な要件定義の第一歩になります。この対話を通じて、当初の要望メモには書ききれなかった細部が明確になっていきます。
業種別に見る、要望メモの書きやすさの違い
要望メモの書きやすさは、業種や解決したい課題の種類によっても変わってきます。ここでは、いくつかの典型的なケースごとに、要望メモを書く際に特に意識すべきポイントを紹介します。
業務効率化系(顧客管理、案件管理、在庫管理など)
現状の業務フローが明確なことが多いため、「今、何をExcelや紙でやっているか」を具体的に書き出しやすいのが特徴です。現状の業務の流れを時系列で書き出し、その中で特に時間がかかっている・ミスが起きやすい箇所を明示すると、開発会社に伝わりやすくなります。
顧客向けサービス系(予約受付、問い合わせフォームなど)
利用者が社内の人間ではなく、顧客や取引先になるため、「利用者がどんな環境(パソコン・スマートフォン)で、どんな心理状態でアクセスするか」を意識して書くとよいでしょう。また、顧客対応が絡む場合は、個人情報の取り扱いについても触れておくと、開発会社側でのセキュリティ設計の検討がスムーズになります。
社内コミュニケーション系(情報共有、掲示板的な仕組みなど)
利用してもらうこと自体のハードルが高い分野のため、「使ってもらうための工夫(通知機能、簡単な操作性など)」への要望も含めておくと、単に機能を作るだけでなく、定着を見据えた提案を引き出しやすくなります。
このように、解決したい課題の性質によって、要望メモで重視すべき観点は微妙に変わります。テンプレートの6項目を基本としつつ、自社の課題の性質に応じて、特に力を入れて書くべき項目を意識してみてください。
要望メモは、社内の意思統一にも役立つ
要望メモを作成する過程は、開発会社に伝えるためだけのものではありません。社内で複数人が関わる場合、要望メモを作る作業そのものが、関係者間の認識をすり合わせる良い機会にもなります。
例えば、経営者と現場担当者とで、要望メモの内容についてすり合わせを行うと、次のようなズレが事前に発覚することがあります。
- 経営者は「業務の見える化」を重視しているが、現場は「入力の手間削減」を最優先に考えている
- 経営者は「全社で使う」ことを想定しているが、現場は「特定の部署だけで使えれば十分」と考えている
こうしたズレは、開発会社に要望を伝える前の段階で解消しておくべきものです。もし社内で意見が割れている状態のまま開発会社に要望を伝えてしまうと、開発会社は矛盾した情報をもとに提案せざるを得なくなり、結果的に誰の期待にも十分応えられないシステムができあがってしまうリスクがあります。要望メモの作成を、単なる文書化作業ではなく、社内合意形成のプロセスとして捉えることをお勧めします。
要望メモの分量はどのくらいが適切か
「どのくらいの分量で書けばいいのか分からない」という疑問もよく聞かれます。目安としては、A4用紙1〜2枚程度、文字数にして1000〜2000字程度が、初めての要望メモとして適切なボリュームです。
これより短すぎると、開発会社が必要な情報を汲み取れず、前述の「とりあえず」に近い状態になってしまいます。逆にこれより長すぎると、要点がぼやけてしまい、開発会社側も何を優先して読めばいいのか分かりにくくなります。テンプレートの6項目それぞれを2〜3行程度でまとめれば、自然とこのボリュームに収まるはずです。
もし書いているうちに分量が大きく超えてしまう場合は、「やりたいこと」の項目に機能の詳細を書き込みすぎている可能性があります。詳細な仕様は、契約後の要件定義の段階で開発会社と一緒に詰めていけばよいので、要望メモの段階ではあくまで大枠のイメージを伝えることに徹してください。
要望メモのテンプレートまとめ
最後に、これまで解説した内容を、そのまま使えるテンプレートとして整理します。
【困りごと・背景】
(今、何に困っているか。なぜこのシステムが必要か)
>
【目的】
(このシステムで最終的に実現したいこと)
>
【利用者】
(誰が、どのくらいの頻度で使うか)
>
【やりたいこと】
(具体的な機能イメージ。優先順位をつけて書く)
>
【現状の代替手段】
(今どう対処しているか)
>
【予算・希望時期】
(出せる予算の上限、いつまでに使いたいか)
>
【補足事項】
(スマートフォン対応の要否、社外利用の有無、既存システムとの連携有無など)
このテンプレートをそのままコピーし、自社の状況に合わせて埋めていくだけで、開発会社に伝わる最初の要望メモが完成します。すべての項目を完璧に埋める必要はなく、分からない部分は「未定」と書いても構いません。大切なのは、分かっていることと分かっていないことを、開発会社にも分かる形で切り分けておくことです。
よくある失敗: 要望メモに機能を詰め込みすぎる
要望メモを書き始めると、逆に「あれもこれも書かなければ」という気持ちになり、思いつく限りの機能を詰め込んでしまう発注者もいます。しかし、これは前述の「とりあえず」とは逆方向の失敗であり、注意が必要です。
機能を詰め込みすぎた要望メモには、次のような弊害があります。
- 開発会社が全体像を把握しづらくなり、本当に重要な部分が埋もれてしまう
- 見積もり金額が想定より大きく膨らみ、予算とのギャップが広がる
- 「本当に必要な機能」と「あれば嬉しい機能」の境目が分からなくなる
0-10人の会社が最初の外注で目指すべきは、完璧なシステムを一度に作ることではなく、まず最も重要な困りごとを解決することです。要望メモを書く際は、思いついた機能をすべて書き出した後、「これがなければ困るもの」だけに絞り込む作業を必ず行ってください。絞り込みに迷った場合は、MVP（実用最小限の製品）の考え方、つまり「必要最小限の機能に絞って、まず動くものを作る」という発想を参考にするとよいでしょう。
要望メモと見積もりのやり取りで起きる、よくある行き違い
要望メモを渡した後、開発会社から見積もりが返ってくるまでの間に、いくつかの行き違いが起こりやすいポイントがあります。事前に知っておくことで、スムーズなやり取りにつなげられます。
行き違い1: メモに書いていないことは「含まれない」と解釈される
発注者が「当然含まれるだろう」と思っていた内容が、要望メモに明記されていなかったために、見積もりに含まれていなかった、というケースです。例えば「顧客管理システム」という言葉だけでは、検索機能やデータのエクスポート機能が含まれるかどうかは開発会社によって解釈が分かれます。少しでも必要だと思う機能は、たとえ当たり前に思えても書き出しておくことが重要です。
行き違い2: 抽象的な言葉が人によって異なるイメージを持つ
「使いやすい画面にしてほしい」「見やすくしてほしい」といった抽象的な要望は、発注者と開発会社とで異なるイメージを持ちやすい表現です。可能な限り、「一覧画面で、直近の更新順に並べてほしい」のように、具体的な状態を書くことを心がけてください。
行き違い3: 「早く」の基準がずれる
「なるべく早く」という表現も、発注者は「1ヶ月以内」を想定し、開発会社は「半年以内でも早い方」と解釈する、といったズレが起こり得ます。希望時期は、曖昧な言葉ではなく、具体的な月・週を明記するようにしてください。
要望メモを作る際に、開発会社の視点を借りる方法
初めて要望メモを書く場合、自分だけで完璧なものを作ろうと気負う必要はありません。むしろ、開発会社に相談しながら一緒に磨き上げていくという進め方の方が、現実的で精度も高くなります。
具体的には、次のような進め方をお勧めします。
- まず自分で分かる範囲の要望メモ(たたき台)を作る
- そのたたき台を持って、開発会社に相談する
- 開発会社からの質問に答えながら、内容を肉付けしていく
- 肉付けされた内容を、最終的な要望として文書化し直す
このように、要望メモは一度で完成させるものではなく、開発会社との対話を通じて磨かれていくものだと捉えると、心理的なハードルがぐっと下がります。特に、要件定義の経験がない発注者にとっては、最初から完璧なものを目指すよりも、「たたき台を持って相談する」という進め方の方が、現実的かつ確実です。
要望メモに書くべきではないこと
要望メモには、書くべき情報がある一方で、書かない方がよい、あるいは書く際に注意が必要な情報もあります。
- 技術的な実装方法の指定: 「〇〇というプログラミング言語で作ってほしい」といった技術選定は、専門知識がない状態で指定すると、かえって開発会社の選択肢を狭め、非効率な実装を強いることがあります。技術選定は基本的に開発会社に委ねるのが得策です
- 競合他社のサービス名を出しての比較: 「〇〇というサービスと同じものを作ってほしい」という伝え方は、著作権や特許の観点で問題になる可能性もあるため、あくまで「参考イメージ」として伝えるにとどめ、「同じものを作ってほしい」という表現は避けた方が無難です
- 社内の人間関係や政治的な背景: システムの機能とは直接関係のない、社内の力関係や過去の経緯などは、要望メモに含める必要はありません
これらの点に注意しながら、要望メモはあくまで「何を解決したいか」「何を実現したいか」という機能的な要望に絞って書くことをお勧めします。
まとめ: 完璧な要件定義書ではなく、伝わるメモを目指す
「とりあえず作ってもらう」という曖昧な伝え方が失敗を招く理由は、開発会社が発注者の頭の中を読み取れないという、当たり前の事実にあります。この記事で紹介した6項目のテンプレートは、専門的な要件定義の知識がなくても、誰でも今日から使える形にしてあります。
要望メモは、いわば発注者と開発会社の間の共通言語を作る作業です。専門用語を知らなくても、自分の言葉で困りごとを具体的に説明できれば、それだけで十分に開発会社との対話が成立します。要望メモを作成する際に意識すべき要点を、最後にもう一度整理します。
- 機能名だけでなく、「困りごと・背景」まで書く
- 「誰が」「何を」「どうする」の形で具体的に書く
- 優先順位をつけて、削れる部分と削れない部分を明確にする
- 暗黙の前提(スマホ対応、社外利用の有無など)も言語化する
- 分からないことは無理に埋めず、「未定」と書いてよい
要望メモが完成したら、次は依頼先探しや比較検討に進んでください。紹介での依頼を検討している場合は知人の紹介で開発会社を決めていいのか。少人数企業の見極め方、複数社を比較する余裕がない場合は相見積もりを取る余裕がない小さな会社の、最低限の比較ポイントを参照してください。外注全体の進め方に不安がある場合は、初めてシステムを外注する。何もわからない状態からの最初の一歩から読み進めることで、初めての外注の全体像がつながります。
要望メモは、一度書いたら終わりというものではありません。開発会社とのやり取りを重ねる中で、内容は少しずつ精緻になっていきます。最初から完璧である必要はまったくなく、「今、自分が分かっている範囲を、できる限り具体的に言葉にする」という姿勢さえあれば、それは十分に価値のある要望メモです。曖昧なまま「とりあえず」で進めるのではなく、たとえ不完全でも言葉にして渡す。この小さな一歩が、外注の成否を大きく左右します。今日、この記事のテンプレートを使って、自社の困りごとを紙一枚に書き出すところから始めてみてください。それだけで、次の一歩がぐっと踏み出しやすくなるはずです。完璧を目指さず、まずは書き始めてみることが何よりも大切です。