機能を削る判断を自分の中で終えたとしても、開発会社との打ち合わせの場で、その判断をどう伝えればいいか分からない、という人は多いはずです。この記事では、開発会社との打ち合わせで、機能を削る交渉をどう進めればいいかを解説します。
この記事で分かること
機能を削る交渉は、単に「これは要りません」と伝えるだけでは、うまく進まないことがあります。この記事では、開発会社との対話をスムーズに進めるための、具体的な伝え方を紹介します。
結論を先に示すと、意識したい進め方は次の3つです。
- 削った理由ではなく、優先順位を伝える
- 開発会社側の視点も聞きながら、調整する
- 削った機能を、完全に諦めたわけではないことを伝える
なぜこの3つが重要なのか。それは、機能を削る交渉が「自分ひとりの意思決定」ではなく、「開発会社とのすり合わせ」だからです。自分の中でどれだけ明確に優先順位をつけていても、それを開発会社側に正しく伝え、開発会社側の視点も取り込みながら合意を作らなければ、打ち合わせは噛み合わないまま終わってしまいます。逆に言えば、伝え方と聞き方を工夫するだけで、同じ内容の交渉でも結果が大きく変わる、ということでもあります。
進め方1：削った理由ではなく、優先順位を伝える
打ち合わせの場で、「この機能は要りません」とだけ伝えると、開発会社側は、なぜ不要になったのかが分からず、提案がしづらくなることがあります。代わりに、機能ごとの優先順位を伝えることをおすすめします。
「Aの機能は絶対に必要、Bの機能は次の段階で追加したい、Cの機能はあれば嬉しいが今回は見送る」というように、優先順位の形で伝えると、開発会社側も予算内でどこまで対応できるかを、具体的に提案しやすくなります。単純に「要る・要らない」の二択ではなく、優先順位という形で伝えることが、対話をスムーズにするポイントです。
なぜ「要らない」だけでは伝わりにくいのか
「この機能は要りません」という発言には、実は複数の意味が隠れています。「今回は不要だが将来は欲しい」のか、「そもそも自分の事業には合わないと分かった」のか、「予算の都合で諦めた」のか。開発会社側は、この違いによって提案の仕方を変える必要があります。将来追加する前提なら拡張しやすい設計を提案できますし、予算の都合であれば、簡易版での実装や、代替手段の提案ができるかもしれません。しかし「要りません」の一言だけでは、開発会社側はどの意味なのかを判断できず、無難な相槌で打ち合わせが終わってしまうことがあります。
優先順位の伝え方の具体例
例えば、予約管理システムの開発を検討しているとして、次のような伝え方の違いがあります。
- 削る理由だけを伝える例：「自動リマインド機能は、正直そこまで重要だと思わないので削ってください」
- 優先順位で伝える例：「予約の受付と管理ができる機能はA（必須）です。自動リマインド機能はB（次の段階）で、まずは手動でお知らせを送る運用で回してみようと思っています。顧客ごとのポイント管理機能はC（今回は見送り）ですが、将来的にリピーター向けの施策として検討したいです」
後者のように伝えることで、開発会社側は「今回のスコープはどこまでか」「将来の拡張ポイントはどこにあるか」を具体的に把握でき、見積もりや設計の提案がしやすくなります。なお、見積書を受け取った際に金額の内訳をどう読み解くかについては、見積書の内訳をどう読むかでも詳しく解説されている。
優先順位づけでよくある失敗パターン
優先順位を伝えようとしても、次のような失敗に陥ることがあります。
- すべてがAになってしまう：「全部必要だと思ってしまい、優先順位がつけられない」という状態です。この場合、「今日ローンチするとしたら、これがないと事業が成立しない機能は何か」という問いを自分に立てると、A（必須）の輪郡が見えやすくなります。
- 優先順位の理由が主観的すぎる：「なんとなく大事な気がする」という理由だけでは、開発会社側も納得材料に欠けます。「この機能がないと、顧客からの問い合わせ対応が回らなくなる」など、具体的な業務上の理由まで添えることをおすすめします。
- 優先順位を打ち合わせの場で即興で決めてしまう：事前に整理せずに打ち合わせに臨むと、その場の雰囲気や開発会社側の説明に流されて、優先順位が場当たり的に決まってしまうことがあります。事前準備の重要性については、後の章で詳しく触れます。
進め方2：開発会社側の視点も聞きながら、調整する
自分の中で決めた仕分けが、必ずしも開発の実情に合っているとは限りません。開発会社との打ち合わせでは、自分の優先順位を一方的に伝えるだけでなく、開発側の視点も聞きながら調整することをおすすめします。
例えば、自分では「後回しにできる」と判断した機能が、実は開発の構造上、最初から組み込んでおいたほうが後々の手間が少ない、ということもあります。逆に、自分では「絶対に必要」と思っていた機能が、実装の難易度が高く、想定以上に予算がかかる、ということもあります。開発会社の視点を聞くことで、自分だけでは気づけなかった判断材料が得られます。
「後から追加すればいい」が通用しない機能とは
個人が見落としやすいのが、「後から追加すればいい」という前提が通用しない機能があるという点です。典型的には、次のようなものが挙げられます。
- 認証・権限管理の仕組み：ユーザーの種別（一般ユーザー・管理者・特定の権限を持つユーザーなど）を後から追加する場合、既存のデータ構造や画面を大きく作り直す必要が出てくることがあります。
- 決済の仕組み：最初は無料提供で始め、後から有料化を検討している場合でも、料金プランや請求のロジックをどう組み込むかによって、初期の設計に影響することがあります。
- データの持たせ方の根幹部分：「あとで項目を増やせばいい」と思っていても、データの構造そのものを変える場合は、既存データの移行作業が発生し、想定以上の手間がかかることがあります。
このような機能については、「今回は使わないが、将来使う可能性がある」ということを開発会社に伝えておくと、拡張しやすい設計を最初から意識してもらえる可能性があります。逆に「今回は完全に不要」と決め切れる機能については、思い切って削ってしまう方が、初期の開発コストを抑えられます。
開発会社からの説明を、どう受け止めるか
開発会社側から「この機能は実装が難しい」「予算がかさむ」といった説明を受けたとき、その場で反射的に「それなら仕方ない」と諦めてしまうのは早計かもしれません。一方で、説明を疑ってかかりすぎるのも、対話を難しくします。バランスの取れた受け止め方としては、次のような質問を投げかけてみることをおすすめします。
- 「難易度が高い理由を、もう少し具体的に教えてもらえますか」
- 「完全な形ではなく、簡易版として実装する場合、費用感はどう変わりますか」
- 「似たような要件を、他のお客様で対応した実績はありますか」
こうした質問を通じて、開発会社側の説明の背景が見えてくると、自分の優先順位を見直すべきか、それでも押し通すべきかの判断がしやすくなります。
進め方3：削った機能を、完全に諦めたわけではないことを伝える
打ち合わせの中で、「今回は見送るが、将来的には追加を検討している」という機能があれば、その意向を開発会社に伝えておくことをおすすめします。これにより、開発会社側は、将来の機能追加を見込んだ設計（後から機能を追加しやすい作り）を意識してくれる可能性があります。
将来の展望を伝えずに、「今の要件だけ」で開発を進めてしまうと、後から機能を追加する際に、想定以上の手間や費用がかかることがあります。将来的な計画があるなら、その旨を早い段階で共有しておくことが望ましいです。
将来の展望を伝えるときの具体的な言い方
将来の展望を伝える際は、抽象的な言い方ではなく、できるだけ具体的なイメージを共有することをおすすめします。例えば、次のような伝え方です。
- 「今回はB2C向けの機能だけで始めますが、半年後を目安に、法人向けのプランを追加したいと考えています。その際は、企業ごとにアカウントをまとめて管理できる仕組みが必要になりそうです」
- 「決済機能は今回入れませんが、利用者が一定数を超えたら、有料プランへの移行を検討しています。無料と有料でどこまで機能を分けるかは、まだ固まっていません」
このように、時期の目安や、想定している方向性まで伝えることで、開発会社側も「どの程度の確度で将来の拡張に備えるべきか」を判断しやすくなります。逆に、「たぶんそのうち何か追加するかもしれません」といった曖昧な伝え方では、開発会社側も具体的な設計上の配慮をしづらくなってしまいます。
見送った機能を、忘れないための工夫
打ち合わせの中で「今回は見送るが、将来検討したい」と話した機能は、時間が経つと自分自身も忘れてしまうことがあります。将来、実際に機能を追加したくなったときに、「なぜ最初にこの機能を見送ったのか」「どんな条件で追加を検討する予定だったのか」を振り返れるように、見送った機能とその理由、将来追加を検討する条件（利用者数が一定数を超えたら、など）を、簡単なメモとして残しておくことをおすすめします。このメモは、次の章で紹介する事前準備のリストと合わせて管理すると、無理なく続けられます。
打ち合わせの前に、準備しておきたいこと
機能を削る交渉をスムーズに進めるために、打ち合わせの前に次の準備をしておくことをおすすめします。
- 機能の優先順位を、A（必須）・B（次の段階）・C（見送り）に分けたリスト
- なぜその優先順位にしたのか、簡単な理由のメモ
- 予算の上限（開発会社に伝えるかどうかは別の判断だが、自分の中では明確にしておく）
これらを事前に整理しておくことで、打ち合わせの場で慌てず、落ち着いて交渉を進められます。予算の開示については、伝えるべきか隠すべきかで意見が分かれる部分もありますが、少なくとも自分の中では明確にしておくことが重要です。
事前準備チェックリスト
打ち合わせに臨む前に、次の項目を一つずつ確認しておくと、当日の交渉がぐっとスムーズになります。
- [ ] 検討している機能を、すべて書き出したか
- [ ] 各機能を、A（必須）・B（次の段階）・C（見送り）に分類したか
- [ ] Aに分類した機能について、「なぜ必須なのか」を一言で説明できるか
- [ ] Cに分類した機能について、「完全に不要」か「将来検討したい」かを区別したか
- [ ] 自分の中での予算の上限を、金額として明確にしているか
- [ ] 予算の上限を開発会社に開示するかどうか、方針を決めているか
- [ ] 打ち合わせで即答を求められた場合、「持ち帰って検討する」という選択肢を自分に許しているか
- [ ] 打ち合わせの記録を、どう残すか（メール・議事録など）を決めているか
このリストは、打ち合わせの直前に見返すだけでも効果があります。特に「Aに分類した理由を一言で説明できるか」は、打ち合わせの場で開発会社側から「なぜ必要なのですか」と聞かれた際に、スムーズに答えられるかどうかを左右する重要な確認事項です。
開発会社から、機能の削減を提案される場合
打ち合わせを進める中で、自分が「必須」と考えていた機能について、開発会社側から「この機能は削ったほうがいい」と提案されることもあります。この場合、なぜその提案をするのか、理由を確認することをおすすめします。
技術的な難易度や、費用面での理由がある場合は、その説明を踏まえて、自分の優先順位を見直す価値があります。一方、理由が明確でない、あるいは納得できない場合は、その機能が自分にとって本当に必要な理由を、改めて説明し、交渉を続けることも選択肢の一つです。
提案を受け入れるべきか、押し通すべきかの判断軸
開発会社からの削減提案に対して、受け入れるべきか、押し通すべきかを判断する軸として、次の3点を意識してみることをおすすめします。
- その機能がないと、事業として成立しないか：削ることで事業の根幹に関わる価値が失われるのであれば、費用や難易度が上がっても、押し通す価値があるかもしれません。
- 簡易版での代替が可能か：フルスペックでの実装が難しい場合でも、機能を絞った簡易版であれば実現可能、というケースは少なくありません。開発会社に「簡易版にした場合はどうか」と聞いてみる価値があります。
- 削った場合の運用でカバーできるか：システムでの自動化を諦めても、手動の運用で一時的にカバーできるのであれば、初期段階では削るという選択肢も検討に値します。
よくあるQ&A
Q. 開発会社から「この機能は難しい」と言われたが、他の会社なら実現できるかもしれない。相見積もりを取り直すべきか。
A. 打ち合わせがまだ初期段階であれば、他社に同じ要件を伝えて反応を比較してみる価値はあります。ただし、機能の難易度に関する説明が、技術的に筋の通った内容であれば、会社を変えても同じ制約に当たる可能性があります。「なぜ難しいのか」の説明の質そのものを、判断材料にすることをおすすめします。
Q. 開発会社の提案を鵜呑みにして機能を削ったが、後から「やっぱり必要だった」と感じたらどうすればいいか。
A. 打ち合わせの記録（メールや議事録）が残っていれば、「見送った理由」と「見送った時点での前提」を振り返ることができます。前提が変わった（利用者数が想定以上に増えた、など）のであれば、追加の機能開発として、改めて開発会社に相談することが可能です。見送った当時の記録がないと、なぜ削ったのかを思い出せず、判断がぶれてしまうことがあります。
Q. 開発会社側の提案に、何度も反対するのは気が引ける。関係が悪くなるのではと心配になる。
A. 理由を確認したうえで、納得できない点を伝えることは、対立ではなく、より良い成果物を作るための対話です。多くの開発会社は、発注者側が自分の事業について真剣に考え、理由をもって発言してくれることを、むしろ歓迎します。感情的な反論ではなく、「なぜその機能が必要なのか」を業務の文脈で説明することを心がければ、関係を損なう心配は少ないはずです。
専門知識を活かしたツールの場合、交渉で伝えたいこと
専門分野の業務ロジックを含む機能については、なぜその機能が核となる価値なのかを、専門知識を持たない開発会社側に、丁寧に説明する必要があります。単に「これは必須です」と伝えるだけでなく、「この機能がないと、業界の実務としてこういう問題が起きる」という背景まで説明することで、開発会社側も優先順位の重要性を理解しやすくなります。
例えば、特定の業界向けの在庫管理や、専門資格に基づく計算ロジックなど、一般的なアプリケーションには存在しない独自の業務フローを持つ場合、開発会社側はその重要性を最初から理解しているわけではありません。「この計算を間違えると、実際の現場でこういうトラブルが起きる」「この確認フローを省くと、法令や業界の慣習に反してしまう」といった、具体的な業務上の影響まで共有することで、開発会社側もその機能を単なる「要望の一つ」ではなく「事業の核」として認識し、優先度の高い扱いをしてくれるようになります。
逆に、専門的な背景を説明せずに「これは絶対に必要です」と繰り返すだけでは、開発会社側からは「なぜそこまで重要なのか分からないが、とりあえず必須と言われているから対応する」という受け止め方になり、設計上の工夫や、コスト面での代替案の提示が得られにくくなることがあります。専門知識を要する機能ほど、背景の説明に時間をかける価値があります。
打ち合わせが1回で終わらないことを、前提にする
機能を削る交渉は、1回の打ち合わせで完全に決着することは、必ずしも多くありません。開発会社側の提案を持ち帰って検討したり、自分の中で優先順位を再考したりする時間が必要になることもあります。
打ち合わせの場で即答を求められても、その場で無理に結論を出す必要はありません。「一度持ち帰って検討します」と伝えることは、決して失礼なことではなく、後悔のない判断をするための、むしろ望ましい姿勢です。複数回のやり取りを経て、機能の範囲が固まっていく、という前提で臨むことをおすすめします。
複数回の打ち合わせで、機能の範囲が固まっていく典型的な流れ
実際の打ち合わせでは、次のような段階を経て、機能の範囲が固まっていくことが多く見られます。
- 1回目の打ち合わせ：自分が考えている機能の全体像を伝え、開発会社側から概算の見積もりと、実装上の懸念点を聞く。
- 持ち帰って検討する期間：開発会社側からの懸念点を踏まえて、優先順位を見直す。予算との整合性を確認する。
- 2回目の打ち合わせ：見直した優先順位を伝え、開発会社側からより具体的な見積もりと、機能ごとの実装方針の提案を受ける。
- 最終確認：削る機能・残す機能・将来検討する機能の最終リストを確定し、双方で認識を合わせる。
このように段階を踏むことを、最初から双方が前提として共有しておくと、1回目の打ち合わせで無理に結論を出そうとする焦りが減り、より落ち着いた交渉ができるようになります。
交渉の記録を、都度残しておく
打ち合わせの中で決まった機能の範囲や、削る・残すの判断については、口頭でのやり取りだけで終わらせず、メールや議事録として記録に残しておくことをおすすめします。
「言った・言わない」のトラブルを避けるためだけでなく、複数回の打ち合わせを経る中で、以前の合意内容を忘れてしまうこともあります。都度の記録が、その後のやり取りをスムーズにする助けになります。
記録に残しておきたい項目の例
議事録やメールでの記録は、形式を厳密に整える必要はありませんが、次の項目を含めておくと、後から振り返りやすくなります。
- 打ち合わせの日付
- その打ち合わせで確定した機能（必須として残すもの）
- 見送りが決まった機能と、その理由
- 「将来検討する」とされた機能と、検討の目安（時期や条件）
- 次回までに、どちらが何を準備するか
こうした記録を、打ち合わせのたびに簡単でも残しておくことで、数ヶ月にわたるやり取りの中でも、判断の経緯を一貫して追えるようになります。特に個人で開発会社とやり取りをする場合、社内に複数の担当者がいるわけではないため、自分自身の記憶だけに依存してしまうと、後から「なぜこの機能を削ったのか」を思い出せなくなるリスクがあります。記録を残す習慣は、地味に見えても、交渉全体の質を支える土台になります。
オンラインでの打ち合わせで、意識したいこと
個人が開発会社に相談する場合、対面ではなくオンラインで打ち合わせをするケースも増えています。オンラインの打ち合わせには対面と異なる特有の注意点があるため、いくつか意識しておきたい点を挙げます。
まず、画面共有をしながら話す場合、資料に書かれていない補足説明が、記録として残りにくいという問題があります。口頭で補足した内容は、打ち合わせ後に議事録として整理し直す必要があります。また、オンラインでは相手の反応が対面より読み取りづらいため、「今の説明で伝わっているか」を、こちらから積極的に確認する姿勢が役立ちます。「ここまでの内容で、何か懸念点はありますか」と、要所要所で問いかけることをおすすめします。
さらに、録画・録音の可否については、事前に確認しておくとよいでしょう。許可が得られれば、打ち合わせの内容をあとから聞き直すことができ、記録の抜け漏れを防げます。個人情報や機密事項を含む内容の場合は、録画データの取り扱いについても、双方で認識をすり合わせておくことが望ましいです。
機能を削る交渉で、陥りやすい失敗パターン集
これまで紹介した進め方を踏まえても、実際の打ち合わせでは、次のような失敗パターンに陥ることがあります。事前に典型例を知っておくことで、自分が同じ轍を踏んでいないか、振り返る材料になります。
失敗パターン1：予算を先に明かしてしまい、削る交渉そのものが不要になる
打ち合わせの冒頭で「予算は50万円です」と先に伝えてしまうと、開発会社側はその予算に収まる範囲で提案を組み立てるため、「削る交渉」自体が発生せず、気づかないうちに重要な機能が最初から提案に含まれていない、ということが起こり得ます。予算をいつ、どこまで開示するかは、機能の優先順位を伝えた後にする、という順序を意識すると、この失敗を避けやすくなります。
失敗パターン2：削った機能について、代替手段を検討せずに終える
「この機能は削ります」と決めた後、その機能が担っていた役割を、何によって代替するのかを考えずに打ち合わせを終えてしまうことがあります。例えば、自動通知機能を削った場合、手動でどう運用するのか、誰がその作業を担うのかまで考えておかないと、実際にサービスを開始した後で、運用の負荷に気づいて慌てることになります。削る際は、「削った後、その役割をどう埋め合わせるか」までを、セットで検討することをおすすめします。
失敗パターン3：開発会社の説明を、専門用語のまま受け入れてしまう
開発会社側の説明の中に、聞き慣れない専門用語が出てきた際、理解したふりをして相槌を打ってしまうことがあります。しかし、専門用語の意味を正確に理解していないと、その説明が自分の判断にどう影響するのかも分からなくなります。分からない言葉が出てきたら、その場で「今の言葉の意味を、噛み砕いて説明してもらえますか」と聞くことは、決して恥ずかしいことではありません。むしろ、理解せずに進めてしまうことのほうが、後々のリスクになります。
失敗パターン4：一度決めた優先順位を、変更してはいけないと思い込む
打ち合わせの中で一度「Aは必須」と伝えたことについて、後から考えが変わった場合でも、「一度言ったことを覆すのは失礼だ」と感じて、変更を言い出せなくなることがあります。しかし、複数回の打ち合わせを重ねる中で、状況の理解が深まり、優先順位が変わることは自然なことです。「前回はAとお伝えしましたが、あらためて検討した結果、Bに変更したいと思います」と、理由とともに伝えれば、多くの開発会社は柔軟に対応してくれます。
失敗パターン5：削った機能の話を、その場の勢いで終わらせてしまう
打ち合わせの空気が和やかに進んでいると、深く検討せずに「じゃあそれで大丈夫です」と流してしまうことがあります。特に、開発会社側からの説明が説得力を持って聞こえた場合、その場の納得感だけで判断を確定させてしまうリスクがあります。重要な機能の取捨選択については、その場で即決するのではなく、「持ち帰って検討します」という選択肢を、常に自分に残しておくことが大切です。
機能を削る交渉と、事業のフェーズの関係
機能を削る交渉のあり方は、事業がどのフェーズにあるかによっても変わってきます。まだ事業のアイデアを検証している段階であれば、削れる機能の範囲は比較的広く取れます。最低限の機能で市場の反応を見る、という考え方に立てば、多くの「あったら嬉しい」機能は、初期段階では思い切って削る判断がしやすくなります。
一方、すでに一定のユーザーがいて、サービスを拡張していく段階では、「削る」という判断が、既存ユーザーへの影響を伴うこともあります。この場合は、新規機能の取捨選択というよりも、既存の使われ方を踏まえた優先順位づけが必要になり、開発会社との打ち合わせでも、現状の利用状況を共有しながら交渉を進めることになります。
自分の事業が今どのフェーズにあるのかを、打ち合わせの前に整理しておくと、開発会社側にも「なぜ今この機能を削るのか」という文脈が伝わりやすくなります。フェーズの共有は、優先順位そのものと同じくらい、交渉を支える重要な情報です。
まとめ
開発会社との打ち合わせで、機能を削る交渉を進める際は、次の3つを意識することをおすすめします。
- 削る理由だけでなく、優先順位の形で伝える
- 自分の判断を一方的に伝えるのではなく、開発会社側の視点も聞きながら調整する
- 削った機能について、完全に諦めたわけではないことを、必要に応じて伝える
これらに加えて、打ち合わせの前の準備、複数回のやり取りを前提にする姿勢、そして交渉の記録を残す習慣が、交渉全体の質を支えます。機能を削る交渉は、一度きりの駆け引きではなく、開発会社と事業の方向性をすり合わせていく、継続的な対話の一部だと捉えることが、後悔のない意思決定につながります。
なお、機能の優先順位を伝える以前に、そもそも要望が開発会社に正しく伝わっているかという点も見落とせません。要件を伝える際に食い違いが起きやすいポイントを押さえておくと、優先順位の交渉そのものがスムーズに進みやすくなる。
この記事の次に読みたい記事
機能を削る交渉の進め方を理解したら、次は実際の見積もり比較についても知っておくと安心です。あわせて次の記事も参考にしてください。
交渉の前提となる検証期全体の進め方については、アイデアを「動くもの」にする。検証期のAI試作と費用の全体像も参考になります。
