開発会社に問い合わせる前に用意するとよい資料

開発会社に問い合わせる前に、分厚い仕様書を作る必要はありません。

ただし、現在の業務フロー、困っていること、利用者、予算感、希望納期、参考サービス、既存ツールを短く整理しておくと、初回相談の時間を有効に使いやすくなります。

この記事では、中小企業の経営者や、必要に応じてスタートアップCTOが、開発会社へ相談する前に用意しておくとよい資料を整理します。

結論：完璧な仕様書より「判断材料」が大切

問い合わせ前に用意したいのは、完成された仕様書ではなく、開発会社が状況を理解するための判断材料です。

特に、次の項目があると相談が進めやすくなります。

現在の業務フロー
困っていること
想定する利用者
予算感
希望納期
参考にしているサービス
既存ツールや既存データ

最初からすべてを正確に決める必要はありません。「決まっていること」「まだ決まっていないこと」「相談しながら決めたいこと」を分けておくだけでも、見積もりや提案の前提が揃いやすくなります。

用意する資料は簡単なメモでよい

開発会社に相談する前の資料は、社内稟議に使うような正式な文書でなくても問題ありません。

たとえば、次のような形で十分です。

箇条書きのメモ
現在使っているExcelやスプレッドシート
業務の流れを書いた簡単な図
画面の手書きメモ
参考サービスのURL
既存ツールのスクリーンショット

重要なのは、見た目を整えることではありません。開発会社が「誰が、どの業務で、何に困っていて、最初に何を解決したいのか」を理解できることです。

現在の業務フロー

まず整理したいのは、現在の業務フローです。

新しいシステムを作る相談では、「何を作りたいか」よりも先に、「いま業務がどう流れているか」を共有した方が、適切な提案につながりやすくなります。

次の項目をメモしておくと整理しやすくなります。

業務の始まりは何か
誰が最初に情報を受け取るのか
どの順番で確認、入力、承認、連絡が行われるのか
どこでExcel、メール、チャット、紙の書類を使っているのか
最後にどのような状態になれば完了なのか

業務フローは、きれいな図でなくても構いません。「問い合わせを受ける」「担当者が確認する」「Excelに転記する」「上長が承認する」「顧客に連絡する」のように、時系列で並べるだけでも十分です。

困っていること

次に、困っていることを整理します。

ここで大切なのは、「作りたい機能」だけでなく、「なぜ困っているのか」を書くことです。

たとえば、次のような観点で整理できます。

入力や転記に時間がかかっている
担当者によって対応方法が違う
進捗状況が見えない
顧客への連絡漏れが起きやすい
Excelやスプレッドシートが複雑になっている
社内の問い合わせが特定の人に集中している
既存ツールでは業務に合わない部分がある

「予約管理システムがほしい」とだけ伝えるより、「予約内容をメールからExcelへ手入力しており、変更やキャンセルの確認に時間がかかっている」と伝えた方が、開発会社は必要な画面や機能を考えやすくなります。

想定する利用者

誰が使うのかも、見積もりや設計に大きく影響します。

同じ業務改善ツールでも、社長だけが使うのか、事務担当者が毎日使うのか、営業担当者が外出先で使うのか、顧客も使うのかによって、必要な画面や権限は変わります。

問い合わせ前には、次のような情報を整理しておくとよいでしょう。

社内だけで使うのか、社外の顧客も使うのか
管理者、担当者、閲覧だけの人など、役割の違いがあるか
パソコン中心か、スマートフォンでも使う必要があるか
毎日使うのか、月に数回だけ使うのか
ITに慣れていない利用者がいるか

利用者が増えるほど、ログイン、権限管理、画面の分かりやすさ、サポート方法なども検討が必要になります。最初の相談では、全利用者を細かく定義するより、「最初に使う人」と「将来使うかもしれない人」を分けて伝えると整理しやすくなります。

予算感

予算感は、問い合わせ前にできる範囲で伝えた方が相談しやすくなります。

開発会社は、予算によって提案の範囲を変える必要があります。最初からすべてを作るのか、まず主要業務だけを小さく作るのか、既存ツールの組み合わせで足りるのかを判断するためです。

予算を伝えるときは、正確な上限金額でなくても構いません。

まずは小さく試したい
社内稟議前なので、概算を知りたい
初期費用を抑え、後から追加したい
保守費用も含めて考えたい
既存ツールで代替できるなら開発しない選択肢もある

このような考え方を共有するだけでも、開発会社は提案の方向性を合わせやすくなります。

予算を伏せたまま相談すると、開発会社は広めの範囲で見積もる必要があります。その結果、必要以上に大きな提案になったり、逆に期待していた範囲が含まれていなかったりすることがあります。

希望納期

希望納期も、早い段階で共有しておきたい情報です。

ただし、「できるだけ早く」だけでは、優先順位を決めにくくなります。なぜその時期までに必要なのかを合わせて伝えると、開発範囲を調整しやすくなります。

整理しておきたいのは、次のような情報です。

いつまでに使い始めたいのか
その日付に社内イベント、繁忙期、営業開始、補助的な施策などの理由があるのか
最初から本番運用したいのか、社内で試すだけでよいのか
納期を優先する場合、後回しにできる機能は何か

納期が近い場合は、最初から完成形を目指すより、最低限の機能に絞って段階的に作る方が現実的なことがあります。希望納期と必須機能を一緒に整理しておくと、初回相談で優先順位を話しやすくなります。

参考サービス

参考にしているWebサービスやアプリがあれば、URLやスクリーンショットを用意しておくと便利です。

参考サービスは、「同じものを作る」という意味ではありません。使いやすい画面、分かりやすい入力方法、近い業務の流れなど、参考にしたい部分を伝えるための材料です。

共有するときは、次のように分けると誤解が少なくなります。

どの画面が参考になるのか
どの操作感が近いのか
どの機能は不要なのか
自社業務と違う部分はどこか
デザインだけを参考にしたいのか、業務フローも近いのか

「このサービスと同じものがほしい」だけでは、必要な機能が大きく膨らむことがあります。参考にしたい部分と、不要な部分を分けて伝えることが大切です。

既存ツールと既存データ

現在使っているツールやデータも、初回相談で重要な情報です。

業務改善ツールや小規模Webシステムでは、完全に新しく作るより、既存ツールと連携したり、既存データを活かしたりする方がよい場合があります。

整理しておきたい項目は次のとおりです。

現在使っているExcel、スプレッドシート、チャット、会計ソフト、顧客管理ツール
既存データの形式
データを移行したいか、過去データは残すだけでよいか
外部サービスとの連携が必要か
既存ツールのどこに不満があるか
継続して使いたいツールがあるか

既存データがある場合は、実データをそのまま送る前に、個人情報や顧客情報が含まれていないか確認が必要です。初回相談では、まず項目名や形式だけを共有し、必要に応じて後から安全な方法で共有する方が進めやすくなります。

逆に、最初から決めすぎなくてよいこと

問い合わせ前に、すべてを決めきる必要はありません。

特に、次の項目は相談しながら決めても問題ありません。

画面の細かいデザイン
使う技術やフレームワーク
データベースの構造
すべての入力項目
すべての例外パターン
将来追加したい機能の詳細

もちろん、すでに社内で決まっていることがあれば共有した方がよいです。ただし、最初の段階から技術や細部を決めすぎると、本来解決したい業務課題から離れてしまうことがあります。

開発会社に相談する目的は、要望をそのまま開発項目に変換することだけではありません。業務の状況を踏まえて、作るべきもの、後回しでよいもの、既存ツールで足りるものを整理することも重要です。

問い合わせ前の確認リスト

最後に、問い合わせ前の確認リストとしてまとめます。

現在の業務フローを時系列で書いた
一番困っていることを言葉にした
最初に使う利用者を整理した
予算感や費用の考え方を整理した
希望納期と、その理由を書いた
参考サービスのURLや参考にしたい部分を用意した
現在使っているツールや既存データを整理した
決まっていることと、相談しながら決めたいことを分けた

このリストをすべて埋める必要はありません。分かる範囲で書き、分からない部分は「未定」「相談したい」としておけば十分です。

まとめ：問い合わせ前の資料は、相談を早く進めるための地図になる

開発会社に問い合わせる前に用意するとよい資料は、完成された仕様書ではありません。

現在の業務フロー、困っていること、利用者、予算感、希望納期、参考サービス、既存ツールを整理した短いメモがあるだけでも、初回相談は進めやすくなります。

特に中小企業の小規模Webシステム開発や業務改善ツール開発では、最初から大きく作るより、現状を整理し、優先順位を決め、小さく始める方が失敗しにくくなります。

ウィステリアコードでは、小規模Webシステム開発、業務改善ツール開発、SaaS MVP開発、生成AI活用の初期検証について、発注前の要件整理から相談できます。

「まだ資料が整っていない」「何を用意すればよいか分からない」という段階でも、まずはお問い合わせからご相談ください。