「まだ要件がまとまっていないのに、開発会社へ相談しても失礼ではないだろうか。」そう迷っている段階では、相談文を書く手も止まりやすくなります。

画面数も、機能一覧も、予算も、すべて確定してからでないと話せないように感じるかもしれません。でも実際には、最初の相談で大事なのは完成した仕様書ではなく、何を確かめたいのか、何がまだ分からないのかを一緒に見える形へ近づけることです。

この記事では、要件が曖昧なまま相談してよい範囲、先に決めるべきこと、決めなくてよいことを整理します。開発会社に丸投げするためではなく、不安な状態から相談を始めるための実践メモです。

要件が曖昧で不安になるのは自然です

「作りたいものはあるけれど、うまく説明できない」

開発会社に相談する前は、「要件」という言葉が大きく見えます。ログインが必要なのか、管理画面はどこまで必要なのか、通知はメールなのかLINEなのか、データはどこに保存するのか。考え始めるほど、まだ何も決まっていないように感じます。

ただ、最初から詳細な仕様がないこと自体は、珍しい状態ではありません。むしろ、相談前の段階では「解決したい困りごと」と「まだ判断できていないこと」が混ざっている方が自然です。

公的なサービス設計の実務でも、作り始める前に課題や利用者、制約を理解する段階が重視されています。たとえばGOV.UK Service ManualのDiscovery phaseでは、サービスを作る前に解くべき問題、利用者、制約を理解することが説明されています。

つまり、要件が曖昧な状態は「相談できない理由」ではありません。何が曖昧なのかを分けることが、相談の出発点になります。

先に結論

要件が曖昧なままでも、開発会社に相談して大丈夫です。ただし、何も渡さずに「いい感じに作ってください」と頼むのではなく、次の3つだけは言葉にしてから相談すると、話が進みやすくなります。

  1. 何に困っているのか
  2. 誰が最初に使うのか
  3. 相談で何を決めたいのか

反対に、最初から細かく決め切らなくてよいものもあります。画面の細部、ボタン文言、管理画面の全項目、通知文面、細かな権限パターンなどは、目的や利用者が見えてから一緒に整理した方がよいことがあります。

相談前のゴールは、完璧な仕様書を作ることではありません。「今決めること」「仮で置くこと」「相談して決めること」を分けることです。

相談前に決めたいこと

相談前に決めたいのは、細かな仕様ではなく、開発会社が「何を一緒に整理すればよいか」を判断するための材料です。

1. 解決したい困りごと

まずは機能名ではなく、困っている状態を書きます。

  • 申込情報をスプレッドシートへ転記していて漏れが出る
  • 問い合わせ後のヒアリングが毎回手作業で時間がかかる
  • 予約枠の調整をLINEで行っていて、確認漏れが起きる
  • 新しいサービスを見せたいが、説明資料だけでは反応が分からない

「予約システムがほしい」よりも、「予約変更の連絡が分散して抜ける」の方が、相談では扱いやすくなります。GOV.UKのDiscovery guidanceでも、最初に提示された解決策をそのまま受け取るのではなく、解くべき問題へ捉え直す考え方が示されています。

2. 最初に使う人

誰に使ってもらうのかが変わると、必要な画面や安全性、運用方法が変わります。最初の相談では、全員分を決めるより、最初の利用者を絞ってください。

  • 管理者だけが使う
  • 社内スタッフ数名が使う
  • 既存顧客だけが使う
  • イベント参加者だけが使う
  • 一般公開する

特に一般公開するサービスと、社内の一部で使う試作では、必要な作り込みが変わります。ここを曖昧にしたままだと、見積もりの前提も大きく揺れます。

3. 相談で決めたいこと

相談の目的も先に分けておきます。

  • 技術的にできるか知りたい
  • どこまで小さく作れるか知りたい
  • 概算の費用感を知りたい
  • 本開発の前に試作できるか知りたい
  • SaaSや既存ツールで足りるか見たい

目的が違えば、開発会社に期待する答えも変わります。「見積もりがほしい」のか「作る前に整理したい」のかを伝えるだけでも、初回相談の質はかなり変わります。

まだ決め切らなくてよいこと

次のような項目は、最初から完全に固めなくても相談できます。

画面の細かなデザイン

色、余白、ボタンの見た目、細かな配置は、最初から確定しなくても構いません。必要なのは「スマホ中心か、PC中心か」「誰がどの場面で見るか」くらいです。

管理画面の全項目

一覧、検索、詳細、ステータス変更、CSV出力など、管理画面は膨らみやすい部分です。最初は「誰が何を見る必要があるか」だけで十分なことがあります。

通知や外部連携の細部

メール、LINE、Google Sheets、決済、カレンダーなどの外部連携は便利ですが、最初から全部を入れると確認事項が増えます。初回相談では、自動化しないと価値が出ない部分と、手動で代替できる部分を分けるのが現実的です。

例外処理のすべて

キャンセル、重複、入力ミス、担当変更、支払い失敗などをすべて最初から作り込むと、開発範囲は大きくなります。まずは起きそうな例外を列挙し、「初回は手動対応でよいもの」を決めてください。

曖昧さを3種類に分ける

要件が曖昧なときは、曖昧な項目をそのまま一つの不安として抱えず、3種類に分けると整理しやすくなります。

1. 事業判断の曖昧さ

本当に需要があるのか、ユーザーが使うのか、売上や業務削減につながるのか。これは開発だけで解決する曖昧さではありません。試作、ヒアリング、限定公開などで確認する領域です。

2. 業務フローの曖昧さ

誰が入力し、誰が確認し、いつ通知し、どこで例外対応するのか。これは現場の動きを整理する領域です。既存のスプレッドシートやLINEのやり取りを見せると、かなり話が進みます。

3. 技術仕様の曖昧さ

ログイン、権限、データ保存、外部連携、セキュリティ、パフォーマンスなど。これは開発会社と一緒に詰める領域です。最初から正解を持っていなくても構いません。

この3つを混ぜたまま「要件が決まっていない」と考えると、すべてを自分で解かなければならない気がしてしまいます。実務上の目安としては、事業判断と業務フローは相談前にメモし、技術仕様は相談で確認すると進めやすくなります。

根拠から見た考え方

ここで使う根拠は、制度や相場の断定ではなく、サービス設計や開発初期の進め方に関する公的・公式情報です。

デジタル庁のデジタル社会推進標準ガイドラインでは、政府情報システムの整備・管理に関する共通ルールや実践ガイドブックが整理されています。同ページでは、実践ガイドブックや要件定義書標準テンプレートが掲載されており、要件定義は「思いついた機能をそのまま並べる作業」ではなく、サービス・業務改革とあわせて扱うものとして位置づけられています。

GOV.UKのLearning about users and their needsでは、利用者やニーズを理解しなければ正しいものを作れないこと、ユーザーニーズは仮説ではなく調査にもとづくべきことが説明されています。これは小さな業務改善にも当てはまります。最初から機能を固定するより、誰のどんな困りごとを解くのかを先に見た方が安全です。

また、GOV.UKのAlpha phaseでは、発見した課題に対して複数の解決案を試し、リスクの高い仮説を検証するために、必要最小限の複雑さでプロトタイプを作る考え方が示されています。Ready Mockでいう試作も、この考え方に近く、完成版を作る前に判断材料を増やすためのものです。

相談前メモの作り方

最初の相談には、長い仕様書よりも短いメモの方が使いやすいことがあります。次の形で、書けるところだけ埋めてください。

相談前メモをそのままコピーできます

決まっていない項目は空欄のままで構いません。初回相談で一緒に整理したいこととして持っていけます。

作りたいものの仮の名前：
今困っていること：
今の代替手段：
最初に使う人：
最初に確認したい価値：
必須だと思っている機能：
後回しでよさそうな機能：
自動化したいこと：
手動でもよさそうなこと：
相談で決めたいこと：
一番不安なこと：

空欄が残っても問題ありません。空欄は「相談で一緒に決めたいこと」として扱えば十分です。

初回相談で聞くとよい質問

要件が曖昧なときは、いきなり「いくらですか」と聞くより、次の質問の方が前提を揃えやすくなります。

  • この内容だと、まず何を確認すべきですか
  • 本開発の前に小さく試せる範囲はありますか
  • いま決めないと見積もりが大きく変わる項目はどれですか
  • 手動運用にすれば後回しにできる機能はありますか
  • 外部連携や管理画面をどこまで入れると重くなりますか
  • SaaSや既存ツールで足りる可能性はありますか
  • 試作で検証するなら、何を成功条件にするとよいですか

この聞き方なら、開発会社も単に機能を積み上げるのではなく、不確実な前提をどこから確認するかを提案しやすくなります。

次にやること

まずは、作りたいものを一文で書いてください。きれいな文章でなくて構いません。

次に、その一文を「困りごと」「最初に使う人」「相談で決めたいこと」に分けます。これだけで、相談の入口はかなり作れます。

もし機能の名前ばかりが増えてしまう場合は、先に開発外注前チェックリストで目的や利用者を整理すると、相談前の材料を揃えやすくなります。見積もりの大きさが不安な場合は、見積もりが高くなる理由もあわせて確認してください。

要件は、最初から完成していなくて大丈夫です。大事なのは、曖昧さを隠すことではなく、どこが曖昧なのかを開発会社と共有できる形にすることです。

参考情報

この記事では、次の公的・公式情報を確認しました。参照日はすべて2026年7月6日です。