作りたいシステムを開発会社にどう伝える？初めての発注で準備したい5つのこと

「こんなシステムがあったら便利なのに」というイメージはあるのに、いざ開発会社に相談しようとすると、何から話せばいいのか分からない。システム開発を初めて発注する方の多くが、最初にぶつかる壁です。

先に結論をお伝えします。最初の相談に、専門的な仕様書は必要ありません。必要なのは「なぜ作りたいのか」「今どう困っているのか」「誰が使うのか」「何が必須なのか」「予算と期限はどのくらいか」の5つを、A4用紙1〜2枚程度にまとめておくことです。

この記事では、システム開発の発注者が開発会社に要望を伝える前に準備しておきたいことを、そのまま使えるメモのひな形・チェックリスト・開発会社への質問例とあわせて解説します。

作りたいものが開発会社に伝わらない3つの理由

準備の話に入る前に、「なぜ伝わらないのか」を押さえておきましょう。理由が分かると、何を準備すればいいかも自然と見えてきます。

理由1：「機能」で話してしまい「目的」が抜ける

発注者の方は「検索機能がほしい」「CSVで出力したい」のように、機能の名前で要望を伝えがちです。ところが開発会社が本当に知りたいのは、その機能を使って何を実現したいのかです。

たとえば「CSV出力がほしい」の裏に「毎月の集計作業を楽にしたい」という目的があるなら、集計結果そのものを画面に表示するほうが安く・早く済むかもしれません。目的が伝わっていないと、開発会社はこうした提案ができません。

理由2：自社の「当たり前」は社外の人には見えない

「月末は締め処理があるので」「この取引先だけは例外で」といった業務の事情は、社内では常識でも、開発会社にとっては初めて聞く話です。発注者が当たり前すぎて言わなかったことが、後から「そんな話は聞いていない」という仕様の食い違いにつながります。

理由3：書かれていないものは見積もれない

開発会社は、聞いた内容をもとに作業量を見積もります。伝わっていない要望は見積もりに含まれないため、後から追加すると追加費用や納期の延長になりやすいのです。

システムの要件を決めることの重要性については、公的機関もはっきりと指摘しています。

📰 出典：IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版」

IPAはこのガイドの紹介の中で、システムの要件を定義する責任は、システムを使ってビジネスに貢献する立場のユーザ（発注者側）にあると言われていること、そしてシステム開発の遅延の過半は要件定義（＝何を作るかを決める工程）の失敗にあると言われていることに触れています。

つまり「何を作るか」は開発会社に丸投げできるものではなく、発注者が主体となって考えるべきことなのです。とはいえ、最初から完璧にまとめる必要はありません。次の5つを準備しておけば、開発会社と建設的な話ができます。

開発会社に相談する前に準備したい5つのこと

1. 目的：なぜ作るのか、何が良くなれば成功か

最も大切なのが目的です。「システムを作ること」自体は目的ではなく、何かを良くするための手段です。

• 何のために作るのか（例：受注処理にかかる時間を減らしたい）
• 何が変われば「成功」と言えるか（例：1件あたり15分かかる入力作業を5分にしたい）
• 作らなかった場合に何が困るか（例：担当者が退職したら業務が回らない）

成功の基準は、できるだけ数字で表しましょう。「便利にしたい」だけでは、開発会社も優先順位をつけられません。数字が正確でなくても「だいたい月に◯時間くらい」で十分です。

2. 現状：今の業務の流れと困りごと

開発会社にとって一番ありがたい資料は、今の業務で実際に使っているものです。

• 使っているExcelファイル、紙の帳票、社内のマニュアル
• 業務の流れ（誰が・何を受け取って・何をして・誰に渡すか）
• どこで時間がかかっているか、どこでミスが起きやすいか

業務の流れは、きれいな図にする必要はありません。箇条書きや手書きのメモで十分です。「現物を見せる」ほうが、言葉で説明するよりずっと正確に伝わります。

※ 実データを見せる場合は、個人情報や取引先情報を伏せるか、秘密保持契約（NDA）を結んでからにしましょう。

3. 使う人と使う場面

同じ機能でも、誰がどこで使うかによって作り方が大きく変わります。

確認したいこと	例
誰が使うか	社内の事務担当5人、営業30人、取引先、一般のお客様
どこで使うか	事務所のPC、外出先のスマホ、工場のタブレット
ITへの慣れ	Excelは使える、スマホ操作に不慣れな年配の方もいる
利用頻度・量	1日に100件入力する、月末に集中する

特に「社外の人（取引先・お客様）も使うかどうか」は、セキュリティ対策や画面の作り込みに影響し、費用が大きく変わるポイントです。

4. 必須の機能と「あれば嬉しい」機能の仕分け

要望を書き出したら、次の2つに分けてみてください。

• 必須：これがないとシステムを作る意味がない
• あれば嬉しい：予算や期間に余裕があれば入れたい

この仕分けがあると、予算内に収まらなかったときに「どこを削るか」「どこを後回しにするか」をスムーズに相談できます。最初は必須だけで小さく作り、使いながら機能を足していく進め方も一般的です。

5. 制約：予算の幅・期限・既存システム・決める人

最後に、前提となる条件を整理します。

• 予算の幅：「上限◯◯万円くらい」「◯◯万〜◯◯万円」など幅でかまいません
• 期限とその理由：「4月の新年度から使いたい」など、なぜその時期なのかも添える
• 既存のシステム：会計ソフトや顧客管理システムなど、連携が必要なもの
• 決める人：社内で最終判断をするのは誰か、承認にどのくらい時間がかかるか

予算を伝えることに抵抗がある方もいるかもしれません。ただ、予算が分からないと、開発会社は「理想の形」で見積もるしかなく、実際の予算とかけ離れた提案が返ってくることがあります。予算の目安を伝えるのは、予算内で実現できる方法を一緒に考えてもらうためだと考えると伝えやすくなります。

そのまま使える「発注メモ」のひな形

上の5つを1枚にまとめるためのひな形です。空欄があっても構いません。「ここはまだ決まっていない」と分かること自体が、開発会社にとって大切な情報です。

• プロジェクト名（仮）：
• 目的：何のために作るか／成功の基準（できれば数字で）
• 現状の困りごと：今どうやっていて、どこが大変か
• 使う人：誰が・何人・どこで・どの端末で
• 必須の機能：
• あれば嬉しい機能：
• 既存のシステム・データ：連携したいもの、移行したいデータ
• 予算の目安：
• 希望する時期とその理由：
• 社内の体制：窓口担当者／最終的に決める人
• まだ決まっていないこと・不安なこと：

この発注メモは、複数の開発会社に相談するときにも役立ちます。同じメモを渡すことで、各社の提案や見積もりを同じ条件で比べやすくなるからです。

打ち合わせで要望を上手に伝える4つのコツ

画面より先に「業務」の話をする

「こういう画面がほしい」から話し始めると、議論が見た目の話に偏りがちです。まずは「今どんな業務をしていて、どこに困っているか」を話し、画面の形は開発会社からの提案を聞いてから考えるほうが、良いシステムになりやすくなります。

「例外」や「たまにあること」も伝える

「基本はこうだけど、月に数回こういうケースがある」という例外は、あとから問題になりやすい部分です。思いつく限り、遠慮せずに伝えましょう。

「例外の話は、早く聞けるほど設計に組み込みやすいんです。『こんな細かいこと』と思わずに教えてください」

分からないことは「分からない」と言う

専門用語が出てきて分からなかったら、その場で聞き返してかまいません。分からないまま進めると、後で「そういう意味だったのか」という食い違いの原因になります。説明を分かりやすく言い換えてくれるかどうかは、開発会社との相性を見るポイントにもなります。

決まったことは文章で確認する

打ち合わせで決まったことは、議事録やメールで残し、双方で確認しましょう。口頭だけのやり取りは、時間がたつと記憶がずれていきます。

発注者がやりがちな失敗パターン

• 「このサイト（アプリ）と同じものを」だけで伝える：見た目は伝わっても、裏側の仕組みや業務の違いは伝わりません。参考例を見せるときは「どこが良いと思ったのか」を添えましょう
• 要望をすべて「必須」にする：費用も期間も膨らみます。本当に必須かどうか、一度立ち止まって考えましょう
• 現場の担当者を巻き込まない：実際に使う人の意見が入っていないと、完成後に「使いにくい」「業務に合わない」となりがちです
• 「プロなので全部お任せします」と丸投げする：開発会社は技術のプロですが、あなたの会社の業務のプロではありません。業務の判断は発注者にしかできません

発注者がやることチェックリスト

• ☐ システムを作る目的と、成功の基準（できれば数字）を書き出した
• ☐ 今使っているExcel・帳票・マニュアルなど、現状が分かる資料を集めた
• ☐ 使う人・場所・端末・利用量を整理した
• ☐ 要望を「必須」と「あれば嬉しい」に分けた
• ☐ 予算の幅と、希望する時期（とその理由）を決めた
• ☐ 連携が必要な既存システムを洗い出した
• ☐ 社内の窓口担当者と最終的に決める人を決めた
• ☐ 実際に使う現場の担当者に意見を聞いた

開発会社への質問例

最初の相談や打ち合わせで、そのまま使える質問です。

• 「この発注メモで、足りない情報や、先に決めておいたほうがいいことはありますか？」
• 「必須の機能だけで作った場合と、すべて入れた場合で、費用と期間はどのくらい変わりますか？」
• 「要望の中で、費用や期間に特に大きく影響しそうなものはどれですか？」
• 「もっと安く・早く目的を達成できる別のやり方（既存のサービスを使うなど）はありますか？」
• 「今後の進め方の中で、こちら（発注者側）が決めたり用意したりすることは何ですか？」

こうした質問への答え方からも、その開発会社が発注者の目的を理解しようとしているかどうかが見えてきます。

まとめ：完璧な仕様書より「目的と現状」が伝わることが大切

作りたいシステムを開発会社に伝えるために、専門知識や細かな仕様書は必要ありません。大切なのは次の5つを整理しておくことです。

• なぜ作るのか（目的と成功の基準）
• 今どう困っているのか（現状の業務と資料）
• 誰がどこで使うのか
• 何が必須で、何が「あれば嬉しい」のか
• 予算・期限・既存システム・決める人

「何を作るか」を決めるのは発注者の大切な役割ですが、一人で抱え込む必要はありません。整理した発注メモをもとに、開発会社と一緒に形にしていけば大丈夫です。まずは発注メモのひな形を埋めるところから始めてみてください。