「アイデアはあるけれど、まだ具体的な形になっていない」という状態で、開発会社に相談することを迷う人は少なくありません。「機能もデザインも決まっていないのに相談したら、失礼にあたるのではないか」「まとまっていない話を聞かせて、時間を無駄にさせてしまうのではないか」——そうした不安から、相談のタイミングを先延ばしにしてしまうケースをよく見かけます。しかし、アイデアが固まっていない段階でも、伝え方を工夫することで、有意義な相談ができます。この記事では、まだ固まっていないアイデアを、開発会社にどう伝えるかを解説します。
この記事で分かること
アイデアが完全に固まっていなくても、相談を始めることは可能です。この記事では、固まっていない部分を、どのように整理して伝えればよいかを紹介します。
結論を先に示すと、押さえておきたいポイントは次の3つです。
- 固まっている部分と、固まっていない部分を分けて伝える
- 「〇〇のようなもの」と、類似のサービスを例に出す
- 相談を通じて、一緒に固めていく姿勢で臨む
この3つのポイントさえ押さえておけば、企画書のような完成度の高い資料を用意する必要はありません。むしろ、固まっていない部分を隠さずに見せることが、良い相談の第一歩になります。
ポイント1：固まっている部分と、固まっていない部分を分けて伝える
アイデアが完全に固まっていない場合でも、「これは決まっている」「これはまだ迷っている」という部分を分けて伝えることで、開発会社側も、どこから相談を始めればいいかが分かりやすくなります。
例えば、「誰の課題を解決したいかは決まっているが、具体的な機能はまだ迷っている」というように、固まっている部分（対象者や課題）と、固まっていない部分（機能の詳細）を分けて伝えることをおすすめします。アイデアの言語化の仕方については、別記事で詳しく解説しています。
「固まっている／固まっていない」を仕分けする具体例
実際にどう仕分ければいいのか、飲食店向けの予約管理サービスを考えているケースを例に見てみましょう。
- 固まっている: 対象は個人経営の小規模飲食店。電話とノートで予約管理をしていて、ダブルブッキングや聞き漏れが多い。この悩みを解消したい。
- 固まっている: 予約を受ける側（店舗）が使う画面と、予約する側（客）が使う画面の両方が必要そうだということ。
- 固まっていない: 予約は電話代わりのフォームでいいのか、LINEと連携すべきか。
- 固まっていない: 有料化するなら、月額制か、予約1件ごとの課金か。
- 固まっていない: 既存の予約台帳アプリとどう差別化するか。
このように書き出してみると、「固まっていない」と感じていた部分の中にも、実は「固まっている前提の上での選択肢の悩み」が含まれていることが見えてきます。開発会社に相談する際は、この仕分けをメモ書きレベルでも構わないので、事前に整理しておくと、初回の打ち合わせがぐっと具体的になります。
仕分けをせずに相談してしまうとどうなるか
逆に、この仕分けをせずに「なんとなくこんなサービスを考えているんですが」という話し方で相談を始めてしまうと、開発会社側は「何が確定情報で、何がこれから決めることなのか」を判別できません。結果として、開発会社側が的外れな深掘りの質問を重ねてしまい、限られた打ち合わせの時間が、本当に固めるべき論点にたどり着く前に終わってしまう、という失敗パターンが起こりがちです。
「対象者と課題」「解決の方向性」「機能の詳細」「収益化の方法」というように、大きな粒度で分類し、それぞれについて「決まっている／迷っている／全く考えていない」の3段階で自己評価しておくだけでも、開発会社側の理解のスピードは大きく変わります。なお、こうした固まっていない部分をどう言葉にして伝えるかというヒアリングの技術については、要件定義のヒアリングのコツでも詳しく取り上げられている。初回相談全体をどう進めていくかを考える上でも参考になるはずだ。
ポイント2：「〇〇のようなもの」と、類似のサービスを例に出す
具体的な機能がまだ固まっていない場合、「〇〇というサービスの、この部分のような機能をイメージしている」というように、既存のサービスを例に出すことで、イメージを伝えやすくなります。
完全に同じものを作るという意味ではなく、「イメージの参考として」類似のサービスを挙げることで、開発会社側も、大まかな方向性を把握しやすくなります。ただし、既存サービスの著作権やブランドを侵害しないよう、あくまで「イメージの参考」として伝えることを明確にしておくことも重要です。
類似サービスを引用する際の伝え方の型
類似サービスを例に出す際は、次のような型で伝えると、意図が正確に伝わりやすくなります。
- 「〇〇のような雰囲気で」（デザインやトーンの参考）
- 「〇〇の、△△という機能のような動きで」（機能単位で切り出して参考にする）
- 「〇〇と似ているが、この部分だけは違う」（差別化したい点をセットで伝える）
例えば、「見た目はInstagramのストーリーズのような縦型のUIをイメージしていますが、投稿の保存期間は24時間で消えるのではなく、ずっと残る形にしたいです」というように、参考にする部分と、あえて変える部分をセットで伝えると、開発会社側は「どこを模倣し、どこを独自性として作り込むべきか」を正確に把握できます。
「〇〇のようなもの」という伝え方で陥りやすい失敗
一方で、この伝え方には注意点もあります。よくある失敗パターンは次の3つです。
- 参考にしたサービスの全機能を暗黙的に期待してしまう: 「Airbnbのようなもの」と伝えたつもりが、開発会社側は主要な予約機能のイメージだけを想定し、決済・レビュー・多言語対応など、Airbnbが持つ全機能まではイメージしていない、というズレが起こりがちです。参考にする範囲を「どの機能・どの画面か」まで絞って伝えることで、このズレを防げます。
- 参考サービスの規模感を無視してしまう: 大手企業が何年もかけて開発した大規模サービスを引用する場合、「同じレベルの完成度を、同じ予算・期間で作れる」という誤解が生まれることがあります。参考にするのは「コンセプトやUIの一部」であり、「開発規模そのもの」ではないことを明確にしておく必要があります。
- 競合サービスの内部構造をそのまま模倣しようとする: 見た目だけでなく、内部のデータ構造やビジネスロジックまで「〇〇と同じにしてほしい」と伝えてしまうと、著作権やブランドの侵害リスクだけでなく、そもそも外部から見えない内部構造を正確に模倣することは技術的にも難しいという問題が生じます。あくまで「見えている部分の参考」に留めるのが安全です。
ポイント3：相談を通じて、一緒に固めていく姿勢で臨む
固まっていないアイデアを相談する際は、「完璧な計画を持って相談しなければならない」と考えすぎず、「相談を通じて、一緒にアイデアを固めていく」という姿勢で臨むことをおすすめします。
多くの開発会社は、アイデアが固まっていない段階からの相談にも対応しており、要件定義の工程を通じて、アイデアを一緒に具体化していくプロセスを想定しています。この姿勢で臨むことで、必要以上に固めようとして時間をかけすぎることを避けられます。
「一緒に固める」相談が機能する理由
開発会社が要件定義という工程を独立して設けているのは、発注者側が最初から完璧な仕様を持ってくることを前提にしていないからです。要件定義とは、まさに「固まっていない部分を、対話を通じて固めていく」ための工程です。逆に言えば、発注者側が要件定義の段階で全てを決め切ってしまうと、開発会社の専門的な知見（技術的な実現可能性や、コストを抑える設計の工夫など）を取り入れる余地が減ってしまうこともあります。
「相談＝すでに固まったものを説明する場」ではなく、「相談＝固まっていない部分を、専門家の視点を借りながら固める場」と捉え直すことで、心理的なハードルが下がるはずです。
「一緒に固める」姿勢が裏目に出るケース
ただし、この姿勢にも注意が必要です。「全部お任せします」というレベルまで委ねてしまうと、開発会社側は発注者の意図を推測しながら進めることになり、後になって「イメージと違った」というズレが生じやすくなります。「一緒に固める」というのは、「思考を完全に手放す」という意味ではありません。核となる部分（誰の、どんな悩みを解決したいか）は自分で持ち続け、そこから先の具体化を一緒に進める、というバランスが大切です。
アイデアが固まっていない場合、事前に準備できること
完璧な計画は必要ありませんが、最低限、「誰の、どんな悩みを解決したいのか」という核となる部分は、自分の言葉で説明できる状態にしておくことをおすすめします。この核となる部分が明確であれば、他の細部が固まっていなくても、有意義な相談ができます。
「あったらいいのに」を、人に説明できる一文にする方法については、別記事で詳しく解説しています。
事前準備チェックリスト
初回相談の前に、以下のチェックリストで自分の考えを整理してみましょう。すべて埋まっていなくても構いませんが、埋まっている項目が多いほど、相談の質は上がります。
- [ ] 誰の悩みを解決したいか、一文で言える
- [ ] その悩みを、自分自身または身近な人が実際に経験したことがあるか
- [ ] 今、その悩みはどう解決されている（我慢している、別の方法で代替している等）か
- [ ] 参考にしたい既存サービスが1つ以上ある（あれば）
- [ ] 固まっている部分・固まっていない部分をリストアップした
- [ ] おおよその予算感（相談段階では出さなくてもよいが、自分の中で持っておく）
- [ ] いつまでに形にしたいか、大まかな時期感
このチェックリストは、正式な仕様書ではなく、あくまで自分の頭の中を整理するためのメモです。開発会社に渡す資料として整えなくても、箇条書きのメモ程度で十分です。
アイデアが固まっていないことを、正直に伝える
開発会社に相談する際、アイデアが固まっていないことを隠さず、正直に伝えることをおすすめします。「まだ機能の詳細は決まっていませんが、こういう課題を解決したいと考えています」と伝えることで、開発会社側も、それに応じた進め方（要件定義に時間をかける、複数の選択肢を提示するなど）を提案してくれます。
固まっていないことを隠して、無理に固まっているかのように話してしまうと、開発会社側の理解と、実際の要望にずれが生じる可能性があります。
「固まっているふり」をしてしまう心理と、その代償
固まっていないことを隠してしまう背景には、「相談する側は、ある程度考えがまとまっていないと失礼だ」という思い込みがあることが多いようです。しかし、開発会社側からすると、発注者が無理に固まっているかのように振る舞うことのほうが、むしろ厄介です。なぜなら、開発会社は発注者の発言を「確定情報」として受け取り、それを前提に見積もりや設計の方向性を検討し始めるためです。
後になって「実はそこまで固まっていなかった」と分かると、それまでの検討や見積もりの前提が崩れ、やり直しの手間が発生します。これは発注者側にとっても、余計な時間とコストの発生につながります。「ここは仮の話として聞いてください」「まだ迷っている部分です」と、迷いの度合いをそのまま言葉にして伝えることが、結果的に双方にとって効率的な進め方になります。
正直に伝えることで得られる、もう一つのメリット
固まっていないことを正直に伝えると、開発会社側から「その部分は、こういう選択肢がありますよ」という提案を受けられることもあります。これは、発注者が一人で悩んでいるだけでは出てこなかった視点であることが多く、専門家に相談する本来の価値の一つです。「自分で全部決めてから相談する」というスタンスでは、こうした提案の機会を狭めてしまう可能性があります。
複数の開発会社に相談する場合の注意点
アイデアが固まっていない段階で、複数の開発会社に相談する場合、それぞれの会社との対話を通じて、アイデアの方向性が少しずつ変わっていくことがあります。この場合、各社に伝える内容がずれてしまい、後で比較しづらくなることがあります。
可能であれば、最初の1社との対話でアイデアの骨格をある程度固め、その後、その骨格をもとに他の会社にも相談する、という順番のほうが、比較がしやすくなります。
アイデアが「対話ごとに変わってしまう」実例
例えば、A社との相談で「決済機能はまず不要かもしれない」という話になり、そのままB社に相談したところ、B社との対話では「決済機能を最初から入れたほうがいい」という話になったとします。この場合、A社とB社に提示した前提条件がすでに異なるため、両社から出てくる見積もりや提案の内容を単純に比較することができなくなります。
このようなズレを避けるには、最初の1社との対話が終わった段階で、その時点での「暫定的な骨格」を書き出しておき、それを他の会社への相談時にも同じ形で提示する、という工夫が有効です。相見積もりを取る際に条件をそろえる方法については、別記事でも詳しく扱っています。
順番を意識しても、骨格が変わることはある
もちろん、最初の1社との対話をもとに骨格を固めても、他の会社との対話でさらに新しい視点が入り、骨格自体を見直したくなることもあります。それ自体は問題ではありません。重要なのは、「骨格が変わったこと」を認識し、それ以前に相談した会社にも、変わった点を共有し直すことです。情報が古いまま放置されると、最終的な比較や意思決定の場面で、どの会社がどの前提に基づいて提案してくれたのかが分からなくなってしまいます。
専門知識を活かしたツールの場合、アイデアの伝え方の工夫
専門分野の業務ロジックに基づくアイデアの場合、機能の詳細が固まっていなくても、その専門分野特有の課題や、業務の流れについては、具体的に説明できることが多いはずです。「機能はまだ決まっていないが、この業務の、この部分に課題がある」という形で伝えることで、開発会社側が、専門的な文脈を理解しながら、機能の提案を検討しやすくなります。
専門分野の伝え方における具体例
例えば、税理士がクライアント向けの請求書管理ツールを考えているケースでは、「一般的な請求書アプリでは対応していない、インボイス制度特有のこの処理が抜けやすい」というように、専門知識に基づく具体的な課題を伝えることができます。機能のUIやボタンの配置までは固まっていなくても、「なぜ既存のツールでは不十分なのか」という業務上の理由を具体的に説明できれば、開発会社側はその制約を踏まえた機能提案を行いやすくなります。
このように、専門分野の知見がある場合は、「機能」という抽象度で悩むのではなく、「業務プロセスのどこに、どんな課題があるか」という、自分が最も詳しい領域の言葉で伝えることを意識すると、固まっていない部分があっても説得力のある相談になります。専門用語が多い業界の場合は、事前に簡単な用語集を用意して渡すという工夫も効果的です。
固まっていないアイデアの伝え方で、実際に起こりやすい失敗パターン
ここまで紹介したポイントを踏まえても、実際の相談の場では、いくつかの典型的な失敗パターンが繰り返し起こります。あらかじめ知っておくことで、同じ失敗を避けやすくなります。
失敗パターン1：資料を作り込みすぎて、身動きが取れなくなる
「固まっていない部分を見せるのは恥ずかしい」という気持ちから、企画書やパワーポイントの資料を何十枚も作り込んでから相談に臨む人がいます。しかし、資料を作り込みすぎると、そこに書いた内容が「もう決めたこと」であるかのように扱われやすくなり、開発会社側からの提案や、対話の中での方向転換が難しくなってしまうことがあります。資料は箇条書きの簡単なメモで十分です。作り込みに時間をかけるより、その時間を「誰の、どんな悩みを解決したいか」を深く考える時間に使うほうが、有意義な相談につながります。
失敗パターン2：「とりあえず全部盛り」で伝えてしまう
アイデアが固まっていないと、不安から「あれもできるようにしたい、これもできるようにしたい」と、思いつく機能を全て伝えてしまうことがあります。しかし、これでは開発会社側も、どの機能が本当に必要で、どの機能が「あったらいいな」程度のものなのかを判断できません。機能を伝える際は、「これがないと、そもそもサービスとして成立しない機能」と、「あったら嬉しいが、後回しでもよい機能」を分けて伝えることをおすすめします。優先順位をつけて伝えることで、開発会社側も、限られた予算・期間の中で何を優先すべきかを一緒に考えやすくなります。
失敗パターン3：相談のたびに前提がリセットされる
一度目の相談で決めたはずの前提を、二度目の相談ではすっかり忘れて、また振り返るところから始めてしまう、というケースもよく見られます。これは、相談の内容を都度メモに残していないことが原因です。簡単な議事録やメモを取り、相談のたびに「前回はここまで決まりました」という共有から始めることで、対話が積み上がっていく感覚を持てるようになります。
失敗パターン4：迷いをそのままぶつけてしまい、対話にならない
「固まっていない部分を正直に伝える」というのは、迷いの内容を整理せずにそのまま口頭で話し続けることとは異なります。「AがいいかBがいいか迷っています」「そもそもこれが必要かどうかも分かりません」というように、迷いの構造（何と何の間で迷っているのか）を整理して伝えることで、開発会社側も一緒に考えやすくなります。整理されていない迷いをそのまま伝えると、開発会社側も何から答えればいいか分からず、対話が深まりにくくなってしまいます。
失敗パターンから見えてくる、共通の対処法
これらの失敗パターンに共通するのは、「情報量の多さ・少なさ」よりも「情報の整理の仕方」が問題になっているという点です。固まっていないアイデアを伝えるときに大切なのは、完成度の高い資料を用意することではなく、今の自分の考えの状態（何が決まっていて、何がどう迷っているのか）を、ありのままに、かつ整理された形で伝えることです。
初回相談前に、自分に問いかけておきたい質問
事前準備チェックリストに加えて、次のような質問を自分自身に問いかけておくと、相談の質がさらに上がります。
- このアイデアで解決したい悩みを、自分自身は本当に困っていると感じているか、それとも「困っている人がいそうだ」という推測にとどまっているか
- このアイデアが実現しなかった場合、今の悩みはどう解決され続けるのか（代替手段はあるか）
- 参考にしている既存サービスがあるなら、そのサービスの「どこが不十分」だと感じて、新しく作りたいと思ったのか
- 予算や期間について、自分の中でどれくらいの許容範囲を持っているか（相談の場で必ず開示する必要はないが、自分の判断軸として持っておく）
- このアイデアを形にできたら、まず誰に一番最初に使ってもらいたいか
これらの質問に答えようとする過程そのものが、固まっていないアイデアの輪郭をはっきりさせる作業になります。全ての質問に完璧に答えられなくても構いません。答えに迷った部分こそが、開発会社との対話で深めるべき論点だと捉えることができます。
固まっていないアイデアだからこそ生まれる、相談の価値
固まっていないアイデアを相談することは、一見すると準備不足のように感じられるかもしれません。しかし実際には、アイデアが固まりきっていない段階だからこそ得られる価値もあります。
すでに機能や仕様が完全に固まった状態で相談すると、開発会社側の役割は「指示された通りに作る」という受け身のものになりがちです。一方、固まっていない段階で相談すると、開発会社側の専門的な知見（似たようなサービスでよくある失敗、コストを抑えるための設計の工夫、技術的な制約と回避方法など）を、企画の初期段階から取り入れることができます。これは、後から仕様を変更するよりも、はるかに効率的にアイデアを良い方向へ育てられる進め方です。
「固まっていないから相談しづらい」のではなく、「固まっていない今だからこそ、相談する価値がある」と捉え直すことで、相談へのハードルは自然と下がっていくはずです。
まとめ：固まっていないアイデアを、相談の力に変える
この記事で紹介した内容を、改めて振り返っておきましょう。まだ固まっていないアイデアを開発会社に伝えるときは、次の3つを意識することが大切です。
- 固まっている部分と、固まっていない部分を分けて伝える。仕分けをせずに話してしまうと、開発会社側が的外れな質問を重ね、限られた打ち合わせの時間を無駄にしてしまいます。
- 「〇〇のようなもの」と、類似のサービスを例に出す。ただし、参考にする範囲（機能単位・UI単位）を明確にし、規模感や内部構造まで暗黙的に期待しないよう注意します。
- 相談を通じて、一緒に固めていく姿勢で臨む。ただし「全部お任せ」にはせず、核となる部分（誰の、どんな悩みを解決したいか）は自分で持ち続けます。
これらに加えて、固まっていないことを隠さず正直に伝えること、複数の開発会社に相談する場合は前提条件をそろえること、専門分野の知見がある場合は業務プロセスの言葉で課題を伝えることも、有意義な相談を実現するための重要なポイントです。
アイデアが固まっていない状態は、決して相談の妨げにはなりません。むしろ、固まっていない段階から専門家の視点を取り入れることで、後からの手戻りを減らし、より良いアイデアに育てていくことができます。この記事で紹介したポイントを参考に、まずは一度、開発会社への相談の一歩を踏み出してみてください。
この記事の次に読みたい記事
固まっていないアイデアの伝え方を理解したら、次は非エンジニアが誤解しやすい技術的な説明についても確認しておきましょう。あわせて次の記事も参考にしてください。
