多くの経営者がウェブ制作会社にホームページ制作を依頼する際、最初に言うのは「まず見積もりをください」です。
しかし見積書が届くと、双方の理解はまったく異なります。あなたはニュース投稿やお問い合わせフォームが含まれていると思っていたのに、相手は静的ページ5枚だけを計算していた、ということが起こります。3版目まで修正が続き、工期は1か月延び、費用も超過しました。
問題は開発側ではなく、要件定義書が準備できていないことにあります。ウェブサイト開発の本質は、口頭のアイデアを実行可能なリストに翻訳することです。リストが明確であればあるほど、見積もりは正確になり、手戻りも減ります。
以下、実際のプロジェクトの順序に沿って、着工前に何を準備すべきかを説明します。
一、まず目的と範囲を書く。ページ列挙を急がない
最初の書類はページ一覧ではなく、「なぜ作るのか」です。
次の3点を明確に書きます。この企業サイトが解決すべき問題（リード獲得、ブランド訴求、代理店募集、アフターサポート）、成功をどう測るか（月間リード数、問い合わせ数、滞在時間）、そして明確にやらないこと。
最後の項目は最も見落とされやすく、最もコストを抑えられます。例えば産業機器の会社がコーポレートサイトをリニューアルする際、「今回はオンライン決済も会員制度も行わない」と明記したことで、範囲が明確になり、見積もりは20数万円から妥当な範囲にすぐ下がりました。
落とし穴：目的を「ブランドイメージの向上」と書くのは書かないのと同じです。「顧客が製品型番で検索したときに当社を見つけ、そのまま見積依頼を送信できるようにする」に変えれば、開発側は製品検索とフォームが必要だと分かります。
二、ページ一覧とカラム構造は具体的なページまで落とし込む
表を使ってページをすべて列挙します。ページ名、階層、主な内容、管理画面での編集可否が必要です。
トップページ、会社概要、製品センター、ニュース、お問い合わせはあくまで骨格です。実際に工数に影響するのは詳細です。製品センターに多階層カテゴリが必要か、パラメータ絞り込みが必要か、ニュースにタグ集約を対応するか、などです。
シーン例：チェーンサービス企業が予約ミニアプリ開発を依頼し、当初は「予約できればいい」とだけ伝えていました。ページ一覧を補完した結果、店舗一覧、サービス項目、時間帯選択、注文ステータス、キャンセル規則の5ページが必要と判明し、工数は倍近く異なりました。
落とし穴：「〇〇サイトのような感じ」で説明を済ませないこと。参考サイトはスタイルしか示せず、機能の境界は示せません。
三、機能仕様は「誰が、どのような状況で、何をするか」まで書く
各機能を一文で役割、動作、結果を記述します。例えば「訪問者が製品ページで見積依頼をクリックし、氏名と電話番号を入力して送信すると、管理画面のフォロー待ちリストに入り、同時に営業担当へメールが送られる」。
特にバックエンド管理システムは細かく書く必要があります。誰に権限があるか、どのフィールドを変更できるか、データをエクスポートできるか、操作記録が残るか。これらが開発工数を左右します。
App開発やミニアプリ開発の場合は、ログイン方式、メッセージ通知、決済と返金フローも補足します。決済が絡む場合は、事業者資格やAPI申請期間を事前に確認し、開発完了後に未開通だと分かる事態を避けます。
落とし穴：「バックエンド管理」の4文字を要件として扱うこと。少なくともログイン、権限、コンテンツのCRUD、画像アップロード、ログの5要素を含みます。
四、コンテンツ素材とビジュアル参考は同時に準備する
要件定義書に素材リストを添付します。ロゴのソースファイル、ブランドカラー、製品画像、会社紹介、資格証明、連絡先、届出情報などです。
多くのプロジェクトは素材待ちで止まり、開発側が待っていても工期はカウントされます。誰が素材を提供するか、いつまでに揃えるか、不足時は何で代替するかを取り決めることを推奨します。
ビジュアル部分は参考サイトを3〜5件提示し、「レイアウトが好き」なのか「配色が好き」なのかを明記して、開発側の推測を避けます。
落とし穴：画像を他人のサイトから直接ダウンロードすること。著作権リスクと解像度の問題で、後工程で必ず手戻りが発生します。
五、受入基準と技術制約は事前に明文化する
受入基準は検査可能である必要があります。主要ブラウザとスマートフォン機種の対応範囲、ページ表示速度の目標、フォーム送信成功率、管理画面操作の円滑さなどです。
技術制約には、既存サーバーを使うか、既存システムと連携するか、等保やセキュリティテストが必要か、SEO要件（URL構造、TDK設定可否など）があるかを含めます。
データやアカウントが絡む場合は、契約書にウェブサイトセキュリティテストを一度実施し、一般的な脆弱性を検査することを盛り込むことを推奨します。これは余分な工程ではなく、企業サイトが改ざんされたりデータ漏洩したりするコストはテスト費用をはるかに上回ります。
落とし穴：受入を「要件を満たせば可」と書くこと。「Chrome、Safariおよび主要Android機種で、トップページと製品ページにレイアウト崩れがなく、フォーム送信後3秒以内に管理画面へ記録が届く」に変えれば、争いは大幅に減ります。
MIC Studio が適しているケース
明確な事業目標はあるものの、要件がチャット履歴や頭の中に散らばっており、開発前に誰かに書類として整理してほしい場合。あるいはプロジェクトが企業サイトリニューアル、ミニアプリ開発、App開発、バックエンド管理システムに及び、API連携やセキュリティテストも関わる場合。こうした工程をまたぐ業務は、一つのチームに一括で任せるのが適しています。
MIC Studio の進め方は、まず上記5つの資料を一緒に確認し、範囲と受入基準を確定してから、スケジュールと見積もりを提示します。要件が固まらないまま着工することは、双方にとって消耗です。
実行可能な3つの提案
1. 着工前に目的、やらないこと、ページ一覧を1枚の紙に書き、開発側へ送って確認し、双方署名またはメールで記録を残す。
2. 機能仕様は「役割—動作—結果」で項目ごとに書き、バックエンド管理と決済フローは別途記載する。具体的であるほど見積もりが正確になる。
3. 素材リストと受入基準を契約書の付属書に盛り込み、素材の提供時期と不足時の対応を定め、工期をめぐるトラブルを避ける。
要件定義書は形式ではありません。あなたと開発側の間で唯一信頼できる照合基準です。2日かけて明確に書けば、その後の2週間の手戻りを省けます。