商談の席で「その機能は、いつ使えるようになりますか」と聞かれ、「来月末には」と答えた。開発チームに確認すると、来月末は難しそうだと言われた。営業からは「お客様にもう伝えてしまいました」と連絡が来る。結局、顧客にお詫びをして日付を伝え直すことになった。
こうした経験が続くと、日付を口にすること自体が怖くなります。かといって、「時期は未定です」と答え続ければ、商談は進まず、既存の顧客も先の予定を立てられません。
リリース日が守れない原因は、開発の見積もりがずれることだけではありません。見積もりがある程度ずれるのは避けられないことであり、問題はその先にあります。まだ不確かな時点で、確かな日付として伝えてしまっていることです。
本記事では、開発の進み具合に応じて、伝える時期の細かさを変えていく4つの段階と、リリース日を決める手順、相手ごとの伝え方、遅れそうだと分かったときの対応を、少人数の体制でプロダクトの判断を担っている方に向けて解説します。
なぜ、伝えたリリース日は守れなくなるのか
リリース日を伝え直すことになる場面には、共通する3つの形があります。
1. 最も不確かな時点で、最も細かい日付を伝えている
日付を聞かれるのは、多くの場合、開発に着手する前か、着手した直後です。この時点では、何を作るのかが細部まで決まっておらず、技術的に難しい箇所も見えていません。開発の全期間の中で、最も先が読めない時点です。
ところが、この時点で「11月15日です」と日付まで伝えてしまうと、相手にとってはそれが確かな予定になります。先が読めない時点の予測が、1日単位の約束として受け取られる。ここに無理があります。
開発の見積もりがなぜずれるのかについては、別の記事で原因ごとに整理しています。
📌 関連記事：開発の見積もりがずれる原因と対策｜PdMを兼務する経営者が見直すべき5つの原因と、ずれを前提にした計画の立て方
2. 「開発が終わる日」を「使える日」として伝えている
エンジニアが答える見積もりは、多くの場合、作り終えるまでの期間です。しかし、顧客が知りたいのは、自分が使えるようになる日です。この2つの間には、いくつもの作業があります。
- 動作の確認と、見つかった不具合の修正
- 利用者向けの説明や、ヘルプページの用意
- サポートや営業への社内説明
- 既存のデータの移し替えや、設定の変更
- スマートフォンのアプリであれば、アプリストアの審査
これらを数えずに「開発は2週間で終わるので、2週間後に出せます」と伝えると、開発が予定どおりに終わっても、リリース日は遅れます。
3. 誰が、どこまで言ってよいのかが決まっていない
社内で「11月中に出したい」と話していた目標が、営業を通じて「11月に出ます」として顧客に伝わる。こうした行き違いは、誰かの不注意というより、社内で話す目標と、社外に伝えてよい時期が区別されていないために起こります。
営業の担当者は、顧客の質問に答えようとして、耳にした中で最も具体的な日付を伝えます。伝えてよい表現が決まっていなければ、そうするほかありません。
「目指す日」と「約束する日」を分ける
3つの形に共通しているのは、性質の違う2つの日付が、同じものとして扱われていることです。
- 目指す日：開発チームがこの日までに終えようとしている日。社内で使う。前提が変われば動く
- 約束する日：顧客や取引先に伝え、相手がそれをもとに予定を立てる日。社外で使う。動かすと信頼に響く
目指す日は、チームの力を集めるためのものです。ある程度は挑戦的であってよく、動くことも前提です。一方、約束する日は、相手の予定を左右します。顧客はその日に合わせて社内に案内を出し、研修の日程を組み、場合によっては他社のサービスの解約を決めます。
この2つを同じ日にしてしまうと、目指す日がずれるたびに、約束を破ることになります。目指す日は社内に置き、約束する日は、確かさに応じた細かさで別に決める。これが以降の考え方の土台です。
なお、2つの日付を分けることは、開発チームに隠して社外向けの日付だけを遅らせることとは違います。目指す日も、約束する日も、その差をどう見ているかも、チームと共有したうえで決めます。
確かさに応じて、伝える細かさを変える4つの段階
約束する日は、最初から1日単位で決める必要はありません。開発が進んで先が読めるようになるにつれて、伝える時期を細かくしていきます。
段階1：検討中（時期は伝えない）
作るかどうか、あるいは何を作るかが、まだ決まっていない段階です。この段階では、時期を伝えません。
伝えるのは、「検討している」という事実と、次にいつ状況を伝えられるかです。「現在、対応を検討しています。来月の半ばには、進めるかどうかをお伝えします」という形です。時期を伝えられない代わりに、次に連絡する日を約束することで、相手は待つ見通しを持てます。
段階2：着手が決まった（四半期、または月の単位）
作ると決め、何を作るのかの大枠が固まり、開発の順番に組み込まれた段階です。この段階では、「年明けから3月まで」「11月から12月にかけて」のように、四半期か、1〜2か月の幅で伝えます。
エンジニアには、1点ではなく「早ければいつ、遅くともいつ」という幅で見通しを尋ね、社外には遅いほうを基準に伝えます。
段階3：中身が固まった（月の上旬・中旬・下旬）
細かな仕様が決まり、技術的に難しい箇所の目処が立ち、開発が半ばを過ぎた段階です。ここで初めて、「11月下旬」のように、月の中の時期まで伝えます。
この段階に進む目安は、「残りの作業が、すべて数日単位の作業に分けられているか」です。まだ「調べてみないと分からない」作業が残っている場合は、段階2にとどめます。
段階4：動作を確認できた（日付）
開発が終わり、ひととおりの動作確認を済ませ、残っているのが公開に向けた準備だけになった段階です。ここで初めて、「11月25日」と日付で伝えます。
日付を伝える時期が遅すぎると感じられるかもしれません。しかし、顧客が日付を必要とするのは、多くの場合、社内への案内や研修の準備のためであり、1〜2週間前に分かれば足りることがほとんどです。それより前に必要なのは、「おおよそいつごろか」であり、それは段階2と段階3で伝えられます。
もし顧客が早い時期に日付を必要としている場合は、その理由を尋ねます。理由が分かれば、後述する「動かせない日がある場合」の進め方に切り替えられます。
リリース日を決める5つのステップ
4つの段階を、実際の進め方に落とし込みます。
ステップ1：「作り終えてから、使えるようになるまで」の作業を書き出す
まず、開発が終わったあとに必要な作業を書き出します。動作の確認、不具合の修正、説明資料の用意、社内への説明、データの移し替え、アプリストアの審査など、自社のプロダクトで毎回発生するものを一覧にします。
一度書き出しておけば、次回以降はそのまま使えます。それぞれにかかる日数を、過去のリリースを振り返って書き添えておくと、「開発が終わってから公開まで、おおむね1週間かかる」といった目安が持てます。
あわせて、公開を避ける日も確認します。顧客の繁忙期、月末や月初の締め処理の時期、担当するエンジニアが不在の日、連休の直前などです。不具合が起きたときに、すぐに対応できる日を選びます。
ステップ2：幅で見通しを立て、遅いほうを基準にする
エンジニアに、開発の見通しを「早ければいつ、遅くともいつ」の幅で尋ねます。そこにステップ1の日数を加えたものが、リリースの見通しです。
社外に伝える時期は、遅いほうを基準にします。早く終わった場合に前倒しで案内することは、歓迎されることはあっても、信頼を損ねることはありません。
過去の見積もりと実績の記録があれば、それも使います。「このチームでは、見積もりのおよそ1.5倍かかることが多い」と分かっていれば、遅いほうの見通しをその分だけ後ろに置きます。
ステップ3：動かせない日がある場合は、中身で調整する
展示会、顧客の新年度、法令の施行日など、動かせない日が先に決まっている場合があります。この場合は、日付から逆算して決めます。
日付が動かせないのであれば、調整できるのは中身です。リリースに含めるものを、次の2つに分けます。
- 必ず出すもの：これがなければ、その日に出す意味がないもの
- 間に合えば出すもの：あると良いが、後日の追加でも成り立つもの
社外に約束するのは、「必ず出すもの」だけです。「間に合えば出すもの」は、間に合うと確かめられてから伝えます。あらかじめ分けておけば、期限が迫ってから何を削るかで慌てずに済みます。
ステップ4：社外に伝えてよい表現を、1か所に書く
決めた時期を、社外に伝えてよい表現のまま、営業やサポートが見られる場所に書きます。項目は次の4つで足ります。
| 項目 | 書く内容の例 |
|---|---|
| 機能 | 見積書の一括作成 |
| 段階 | 段階2（着手が決まった） |
| 社外に伝えてよい表現 | 「11月から12月にかけての提供を予定しています」 |
| 次に更新する日 | 10月30日 |
大切なのは、「社外に伝えてよい表現」を文章のまま書いておくことです。「11月中旬目標、遅くとも12月」と社内向けの言葉で書くと、読んだ人によって「11月中旬です」と伝える人と、「12月までには」と伝える人に分かれます。
この一覧に載っていない機能について聞かれたときは、「確認してお返事します」と答える、という決まりもあわせて共有します。
ステップ5：段階を見直す日を、先に決めておく
最後に、次に段階を見直す日を決めます。開発期間の3分の1ほどが過ぎた時点と、半ばを過ぎた時点が目安です。
見直しの場では、次の3点を確かめます。
- 当初の見通しどおりに進んでいるか
- 「調べてみないと分からない」作業が、まだ残っているか
- 段階を1つ進めて、伝える時期を細かくしてよいか
段階を進めたら、ステップ4の一覧を書き換え、営業とサポートに知らせます。見通しが後ろにずれた場合も、同じ場で一覧を書き換えます。
相手ごとの伝え方
同じ時期でも、相手によって伝え方を変えます。
営業・サポートに伝えるとき
社内の担当者には、社外に伝えてよい表現とあわせて、その表現がどれくらい確かなのかを伝えます。「段階2なので、月まではお約束できない」と分かっていれば、顧客から「11月の何日ごろですか」と重ねて聞かれたときに、推測で答えずに済みます。
また、顧客から日付を強く求められたときに、営業の担当者がその場で答えを作らずに済むよう、相談の窓口を決めておきます。「日付を条件にした商談は、返事をする前に必ず相談する」という一文があるだけで、行き違いの多くは防げます。
既存の顧客に伝えるとき
既存の顧客には、時期とあわせて、その時期が変わる可能性と、変わった場合の連絡の仕方を伝えます。
「11月から12月にかけての提供を予定しています。開発の進み具合によって前後する可能性があります。11月の初めに、より詳しい時期をあらためてご連絡します」
時期が幅のある表現であっても、次の連絡がいつ来るのかが分かっていれば、顧客は予定を立てやすくなります。
商談中の相手に伝えるとき
商談では、機能の提供時期が契約の判断材料になることがあります。ここで確かでない日付を伝えると、契約後に約束を破ることになり、関係の出発点から信頼を損ねます。
商談で伝えるのは、現時点の段階に応じた時期までとします。相手が「その機能がなければ契約できない」と考えている場合は、時期を細かく約束するのではなく、その機能が相手の業務のどの場面で必要なのかを尋ねます。今ある機能で代わりになる方法が見つかることもあれば、提供の時期に合わせて利用開始の時期を調整するという提案ができることもあります。
機能の提供日を契約書の条件にすることを求められた場合は、その場で答えず、開発チームと確認したうえで判断します。応じる場合も、約束するのは「必ず出すもの」の範囲に限ります。
遅れそうだと分かったときの対応
4つの段階に沿って伝えていても、伝えた時期に間に合わなくなることはあります。そのときの対応が、信頼を左右します。
分かった時点で、すぐに伝える
遅れを伝えるのは、確定してからではなく、遅れそうだと分かった時点です。顧客にとって困るのは、遅れることそのものよりも、直前に知らされて準備をやり直すことです。2週間前に知らされる遅れと、前日に知らされる遅れでは、同じ日数の遅れでも受け止められ方がまったく異なります。
そのためには、開発チームから「遅れそうだ」という知らせが早く届く必要があります。早めの報告を責めず、はっきり歓迎することが、結果として顧客への連絡を早めます。
伝える内容は4つ
遅れを伝えるときは、次の4つをそろえます。
- 何が変わるのか：どの機能の提供時期が、いつからいつに変わるのか
- なぜ変わるのか：理由を、相手に分かる言葉で短く
- 新しい時期は、どれくらい確かなのか：現在の段階と、次に連絡する日
- 相手に生じる影響への対応：それまでの間に代わりになる方法、個別に相談できる窓口
新しい時期を伝えるときは、前回と同じ細かさで伝え直さないよう注意します。「11月25日」が守れなかったあとに「12月5日」と伝え、それも守れなければ、次に伝える日付は信じてもらえなくなります。確かでない場合は、段階を1つ戻して、「12月中旬」と幅のある表現で伝えます。
変更の経緯を記録する
時期を変更したときは、いつ、何を、なぜ変えたのかを短く記録します。数か月分がたまると、「外部のサービスとの連携が含まれると遅れやすい」「公開前の確認にかかる日数を短く見ている」といった傾向が見えてきます。この傾向が、次にリリース日を決めるときの材料になります。
よくある失敗
- 聞かれたその場で、日付を答える：商談や打ち合わせの場で時期を聞かれると、何か答えなければという気持ちになります。「確認して、明日までにお返事します」と持ち帰ることは、不誠実ではありません。その場で作った日付を伝えるほうが、あとで相手に負担をかけます。
- 開発チームに知らせずに、社外に日付を伝える：社外に伝えた日付を開発チームがあとから知ると、その日付は、根拠のないまま守るべき期限になります。無理な進め方で品質が下がるか、守れずに信頼を損ねるかのどちらかになりがちです。
- 社外向けの日付だけを、黙って遅らせておく：余裕を持たせること自体は必要です。ただし、開発チームに伝えずに行うと、チームの中でどの日付が本当の期限なのかが分からなくなります。余裕は、チームと共有したうえで持たせます。
- 遅れを取り戻すために、確認の工程を削る：日付を守るために動作確認を省くと、公開後に不具合が見つかり、その対応で次の開発が遅れます。顧客にとっても、日付どおりに届いた不具合のある機能より、数日遅れて届いた安定した機能のほうが役に立ちます。
- 一度に大きく出そうとする：多くの機能をまとめて1回で公開しようとすると、最も遅れた1つに全体が引きずられます。分けて出せるものは分け、1回あたりの範囲を小さくすると、時期の見通しは立てやすくなります。
具体例：伝え直しが続いていた状態を見直したケース
従業員14名、建設業向けの工程管理サービスを提供するスタートアップを想定した例です。プロダクトの判断は経営者が担い、エンジニア4名、営業2名、サポート1名という体制でした。
顧客から要望の多かった「工程表の一括出力」について、経営者は商談の席で「来月末には使えるようになります」と伝えていました。開発チームの見積もりは3週間であり、余裕があると考えていたためです。しかし、出力の書式が顧客ごとに異なることが開発の途中で分かり、さらに公開前の確認で不具合が見つかったことで、公開は3週間遅れました。その間に、営業は4社へ日付を2度伝え直すことになりました。
振り返ってみると、次のことが分かりました。
- 日付を伝えた時点では、出力の書式について何も決まっていなかった
- 3週間という見積もりには、確認と説明資料の用意が含まれていなかった
- 営業の2名は、経営者が商談で話した日付を、そのまま他の顧客にも伝えていた
そこで、3つのことを変えました。
- 開発が終わってから公開までの作業を一覧にし、過去3回のリリースを振り返って、おおむね6営業日かかることを確かめた
- 開発中の機能ごとに、段階と「社外に伝えてよい表現」を書いた一覧を作り、営業とサポートが見られる場所に置いた
- 2週間に1度の開発の定例で、段階を進めてよいかを確かめ、その場で一覧を書き換えることにした
次の大きな機能である「協力会社との共有」では、着手の時点で「年内の提供を予定しています」とだけ伝えました。開発が半ばを過ぎ、権限の設計が固まった時点で「12月上旬」に、動作の確認が済んだ時点で「12月8日」に、順に細かくしていきました。途中、ある顧客から日付を早く知りたいという要望がありましたが、理由を尋ねると、年明けの現場で使いはじめたいということでした。「年内には提供します」という表現で、相手の予定には十分に足りていました。
見直しから3か月のあいだ、顧客に時期を伝え直すことは1度もありませんでした。営業の担当者からは、「どこまで言ってよいかが分かっているので、商談で答えやすくなった」という声が出たそうです。
よくある質問（FAQ）
Q1. 幅のある時期しか伝えないと、競合に見劣りしないでしょうか。
商談の場では、具体的な日付のほうが魅力的に聞こえることがあります。ただし、相手が最終的に評価するのは、伝えられた時期に実際に届いたかどうかです。幅のある時期であっても、次に連絡する日を添え、そのとおりに連絡することを重ねると、「この会社の言う時期は信じてよい」という評価が積み上がります。
Q2. 投資家や取締役会には、どのように伝えればよいでしょうか。
事業計画との関係があるため、四半期の単位で伝えることが多くなります。このときも、段階を添えて伝えます。「第4四半期に提供予定。現在は着手が決まった段階で、月の単位での見通しは11月に報告する」という形です。確かさをあわせて伝えておくと、時期が動いたときの説明がしやすくなります。
Q3. 開発チームが、幅で答えることに慣れていません。
「何日かかるか」と尋ねる代わりに、「順調に進んだ場合」と「心配していることが起きた場合」の2つを尋ねると、答えやすくなります。あわせて、「何が起きると遅いほうになるのか」を聞くと、先に確かめておくべき点が見えてきます。
Q4. すでに日付を伝えてしまっている機能があります。どうすればよいでしょうか。
まず、開発チームと現在の見通しを確かめます。伝えた日付に間に合う見込みであれば、そのまま進めます。間に合わない可能性がある場合は、確定を待たず、「遅れそうだと分かったときの対応」の4つの内容をそろえて、早めに伝え直します。
Q5. 1人目のプロダクトマネージャーを迎えたあとは、誰がリリース日を決めるのでしょうか。
日々の段階の見直しと、社外に伝えてよい表現の更新は、プロダクトマネージャーに任せやすい仕事です。一方、契約の条件として日付を約束する場合や、動かせない日に向けて中身を大きく削る場合は、事業への影響が大きいため、経営者が判断に加わる形が安心です。どこまでを任せるのかを、あらかじめ言葉にしておくとよいでしょう。
まとめ
伝えたリリース日が守れなくなる原因は、最も不確かな時点で最も細かい日付を伝えていること、開発が終わる日を使える日として伝えていること、誰がどこまで言ってよいのかが決まっていないことの3つにまとめられます。いずれも、社内で目指す日と、社外に約束する日が、同じものとして扱われていることから生じます。
約束する日は、(1)検討中は時期を伝えない、(2)着手が決まったら四半期か月の単位、(3)中身が固まったら月の上旬・中旬・下旬、(4)動作を確認できたら日付、という4つの段階で、確かさに応じて細かくしていきます。決めるときは、作り終えてから使えるようになるまでの作業を書き出し、幅で見通しを立てて遅いほうを基準にし、社外に伝えてよい表現を1か所に書き、段階を見直す日を先に決めておきます。遅れそうだと分かったときは、確定を待たずに伝えます。
まずは、いま開発している機能を1つ選び、「この機能は、どの段階にあるのか」を確かめてみてください。そして、すでに社外に伝えている時期が、その段階に見合った細かさになっているかを見直してみてください。そこに差があれば、それが次に伝え直しが起こる場所です。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
