月初に「今月はこの3つを出す」と決めた。ところが、2週目に大口の顧客から「この帳票の形式を変えてほしい」と連絡があり、3週目には商談で「この連携があれば契約する」と言われた。どちらも断れる話ではなく、開発チームに頼んで先にやってもらった。月末になって振り返ると、予定していた3つのうち、出せたのは1つだけだった。
こうした状態が数か月続くと、開発チームは「どうせまた変わる」と考えるようになり、計画そのものが意味を持たなくなります。
差し込み依頼は、なくすことはできません。顧客の業務が止まっている、契約が決まりかけている、といった場面で、予定を理由に断るほうが事業にとって損になることもあります。問題は、差し込みがあること自体ではなく、差し込むかどうかを、その場の勢いで決めていることです。
本記事では、プロダクトの優先順位を決める立場にあり、同時に顧客や商談の窓口にも立っている方に向けて、決めた優先順位を崩さずに、急ぎの依頼を受け止めるための4つのステップを解説します。
差し込み依頼とは何か
差し込み依頼とは、開発の計画を立てたあとに、その計画になかった作業を途中から割り込ませる依頼のことです。割り込み、横入り、と呼ぶ職場もあります。
よくある出どころは、次のとおりです。
- 顧客からの要望：「この項目を追加してほしい」「この形式で出力したい」
- 商談からの依頼：「この機能があれば契約できる」「デモまでに間に合わせたい」
- 不具合の報告：「この画面でエラーが出る」「計算が合わない」
- 社内からの依頼：「集計の数字を出してほしい」「設定を変えてほしい」
- 意思決定者自身の思いつき：「競合がこれを出したから、うちも急ぎたい」
このうち、最後の1つは見落とされがちです。プロダクトの判断を担う人が、顧客や商談の窓口も兼ねている場合、差し込み依頼の多くは、実はその人自身から出ています。顧客の声を最も多く聞き、開発チームに最も直接ものを言える立場にいるためです。
差し込みが重なると、何が起きるか
1件の差し込みは、たいてい小さな作業に見えます。「半日あればできる」「画面の文言を変えるだけ」と考えて頼むことがほとんどです。しかし、差し込みには、作業そのものの時間とは別の負担が伴います。
途中の作業が止まり、戻るのに時間がかかる
エンジニアが別の機能を作っている途中で差し込みが入ると、その機能の作業はいったん止まります。差し込みを終えて戻ったとき、どこまで進めていたのか、何を確かめようとしていたのかを思い出すところから始めることになります。半日の差し込みが、実際には1日以上の遅れになることは珍しくありません。
予定が読めなくなる
差し込みが月に数回あると、「この機能はいつ出るのか」に答えられなくなります。営業や顧客に伝えた日付がずれ、そのずれを埋めるために、また別の差し込みが入る。この繰り返しで、計画全体の確度が下がっていきます。
📌 関連記事：開発の見積もりがずれる原因と対策｜PdMを兼務する経営者が見直すべき5つの原因と、ずれを前提にした計画の立て方
「何が大事なのか」が伝わらなくなる
最も影響が大きいのは、この点です。計画を立てるときには、「今月はこれが最も大事だ」と説明していたはずです。その途中で別の依頼を優先すれば、開発チームは「本当に大事なのは、最後に言われたことだ」と受け取ります。
こうなると、計画を立てる場の意味が薄れます。チームは計画どおりに進めるよりも、次の差し込みに備えて手を空けておくほうが合理的だと考えるようになるためです。
差し込みに対応する4つのステップ
差し込みへの対応は、依頼が来てから考えるのではなく、来る前に受け方を決めておくことが大切です。次の4つのステップで整えます。
ステップ1：依頼を1か所で受ける
最初に決めるのは、差し込み依頼の入口を1つにすることです。
差し込みが増える職場では、依頼がさまざまな経路から、直接エンジニアに届いています。営業が開発のチャットに書き込む、顧客対応の担当者がエンジニアに声をかける、意思決定者が個別にメッセージを送る。エンジニアは、頼まれれば断りにくく、その場で引き受けてしまいます。結果として、誰が何を差し込んだのかを、誰も把握していない状態になります。
入口は、次のどちらかに決めます。
- 受ける人を1人決める：プロダクトの優先順位を決める人が受けます。1人目のプロダクトマネージャーがいれば、その人に任せます
- 受ける場所を1つ決める：チャットの専用の場所や、課題管理ツールの決まった欄に書いてもらいます
あわせて、開発チームには「直接頼まれた依頼は、いったん入口に回してほしい」と伝えておきます。これは、エンジニアが依頼を断る役を負わなくて済むようにするためでもあります。
依頼を受けるときは、次の4点をそろえてもらいます。
- 誰が困っているか（顧客名、社内の部署名）
- 何ができないと、何が起きるか
- いつまでに必要か、その理由
- 代わりの手段があるか（手作業での対応、別の画面での操作など）
特に4つ目が大切です。「CSVで出力したい」という依頼でも、当面は担当者が手作業で作って送れば足りる場合があります。代わりの手段があれば、差し込む必要はなくなります。
ステップ2：3つに振り分ける
集まった依頼は、その場で次の3つのいずれかに振り分けます。
| 区分 | 当てはまる依頼 | 対応 |
|---|---|---|
| 今すぐ入れる | 顧客の業務が止まっている不具合、データの誤り、情報漏えいなどの安全に関わるもの、契約や法令で期限が決まっているもの | 進行中の作業を止めてでも対応する |
| 次の区切りで入れる | 契約や更新の判断に関わるが、数日から数週間なら待てるもの | 次の計画の見直し（1〜2週間後）で、ほかの候補と並べて判断する |
| 候補として積む | 上記以外のもの | バックログに入れ、通常の優先順位付けの中で扱う |
振り分けで迷ったときは、「この依頼を2週間待ってもらったら、何が起きるか」と考えます。顧客の業務が止まり続ける、契約を失う、といった答えになるものだけが「今すぐ入れる」です。「顧客が不満に思う」「商談の印象が悪くなる」にとどまるものは、多くの場合「次の区切りで入れる」で足ります。
実際に振り分けてみると、「今すぐ入れる」に当たる依頼は、全体の1〜2割ほどに収まることがほとんどです。差し込みが多いと感じているときは、本来は次の区切りで足りる依頼まで、今すぐ入れてしまっていることが少なくありません。
なお、依頼の受け手が自分自身でもある場合は、振り分けを翌朝まで待つことをおすすめします。商談の直後や、顧客との電話を終えた直後は、その依頼が最も大事に見える時間帯だからです。
ステップ3：入れるなら、外すものを同時に決める
「今すぐ入れる」または「次の区切りで入れる」と決めた依頼は、計画に加えます。このとき、何を外すか、何を後ろにずらすかを、同じ場で決めます。
開発チームの手が空いていることは、ほとんどありません。外すものを決めずに足せば、計画にあったものが、どれか分からない形で遅れていきます。外すものを先に決めておけば、遅れるのは自分たちが選んだものになります。
外すものを決めるときは、開発チームに次のように尋ねます。
- 「この依頼を入れると、今の計画のどれに、どのくらい影響しますか」
- 「止めやすいもの、止めにくいものはどれですか」
途中まで進んでいる作業を止めると、戻るための時間がかかります。まだ手をつけていない作業から外すのが基本です。
外すものが決まったら、その作業を待っている人に伝えます。営業が顧客に約束していたものであれば、営業にも伝え、顧客への説明を一緒に考えます。差し込みを受け入れたことで、別の誰かとの約束が変わる。この事実を、依頼を受けた時点で関係者に知らせておくことが大切です。
ステップ4：差し込みを記録し、月に一度振り返る
最後に、差し込んだ依頼を記録します。記録するのは、次の5点で足ります。
- 依頼が来た日と、依頼した人
- 依頼の内容
- 振り分けた区分と、その理由
- 外した、またはずらした作業
- 実際にかかった時間
そして、月に一度、記録を見返します。見るべきことは3つです。
- 差し込みに使った時間は、開発全体のどのくらいか
- 同じ顧客、同じ機能、同じ依頼元からの差し込みが繰り返されていないか
- 「今すぐ入れる」とした依頼は、本当に今すぐ必要だったか
1つ目は、次のステップで説明する「差し込みのための枠」の大きさを決める材料になります。2つ目で同じ領域からの差し込みが続いているなら、その領域には、差し込みでは追いつかない根本的な問題があるかもしれません。その場合は、差し込みで個別に対応するのをやめ、計画の中で正面から取り組む候補にします。3つ目は、振り分けの基準そのものを見直すために使います。
差し込みのための枠を、最初から空けておく
4つのステップに加えて、もう1つ効果が大きいのは、計画を立てる時点で、差し込みのための枠を空けておくことです。
たとえば、開発に使える時間のうち、1〜2割は計画に入れず、差し込みや不具合の対応に充てると決めておきます。差し込みがなかった月は、その時間で、バックログの小さな改善や技術的な手入れを進めます。
枠があると、差し込みを受け入れても、計画にあったものを外さずに済む場面が増えます。開発チームにとっても、「この範囲までは差し込みがあり得る」と分かっているため、予定を守りやすくなります。
枠の大きさは、ステップ4の記録をもとに決めます。最初は1割程度から始め、2〜3か月の記録を見て調整します。差し込みに毎月3割以上の時間を使っている場合は、枠を広げるよりも先に、ステップ2の振り分けが甘くなっていないかを見直します。
依頼してきた人への伝え方
差し込みを「次の区切りで入れる」または「候補として積む」と決めたとき、依頼してきた人にどう伝えるかで、その後の関係が変わります。
伝えるのは、次の3点です。
- 受け取ったこと：依頼を確かに受け取り、内容を理解したこと
- いつ判断するか：「次の計画の見直しで判断します。その結果を〇日までにお伝えします」
- それまでの代わりの手段：手作業での対応や、別の操作での回避方法があれば、あわせて伝えます
「今は対応できません」とだけ伝えると、依頼した人は、別の経路から直接エンジニアに頼もうとします。いつ判断されるのかが分かっていれば、待つことができます。
商談からの依頼の場合は、営業の担当者と一緒に、顧客への説明を考えます。「この連携があれば契約する」と言われた場合でも、その連携が契約の決め手なのか、あれば嬉しいという程度なのかは、顧客にもう一度確かめると分かることがあります。
自分が差し込む側になるとき
プロダクトの判断と、顧客や商談の窓口を1人で担っている場合、差し込みを最も多く生み出しているのは、自分自身であることが少なくありません。
自分の依頼にも、ほかの人の依頼と同じ入口と振り分けを使います。開発チームに直接伝えたくなったときは、その前に次の3つを自分に尋ねます。
- 2週間待ったら、何が起きるか
- この依頼を入れるなら、今月の計画から何を外すか
- 外すものを待っている人に、自分で説明できるか
3つ目に答えられない場合は、その依頼は、今月の計画より大事ではないのかもしれません。
また、自分の差し込みも記録に残します。月末に見返したとき、差し込みの多くが自分から出ていると分かれば、それは、計画を立てる段階で見落としていたことがあるというサインです。次の計画を立てるときに、その領域をあらかじめ含めておくことができます。
よくある失敗
- 小さな依頼だからと、記録せずに入れる：「5分で終わる」依頼ほど、記録されないまま積み重なります。月末に振り返ると、小さな差し込みの合計が、予定していた機能1つ分になっていることがあります。
- エンジニアに振り分けを任せる：依頼を直接受けたエンジニアが、その場で判断して引き受けてしまう形です。エンジニアは、事業上の重みを判断する材料を持っていないことが多く、断る理由も説明しにくい立場にあります。振り分けは、優先順位を決める人が行います。
- 外すものを決めずに足す：「なんとか両方やってほしい」と頼むと、どちらも遅れます。何かを入れるなら、何かを外します。
- 不具合をすべて「今すぐ」にする：不具合にも重さがあります。顧客の業務が止まるものと、表示が少し崩れているものを同じに扱うと、計画は毎週のように崩れます。
- 差し込みのための枠を、計画した作業で埋めてしまう：枠を空けても、「余っているなら」と計画に作業を足すと、枠の意味がなくなります。
具体例：毎月の計画が半分しか進まなかったケース
従業員15名、飲食店向けの発注管理サービスを提供するスタートアップを想定した例です。プロダクトの判断は経営者が担い、大口顧客との商談にも自ら出ていました。開発はエンジニア4名で、月初に1か月分の計画を立てていました。
半年ほど、計画した機能のうち、月内に出せるのは半分程度という状態が続いていました。エンジニアからは「計画を立てても、途中で変わるので意味がない」という声が出ていました。
そこで、1か月間、すべての差し込みを記録することから始めました。開発チームのチャットに差し込み専用の場所を作り、直接頼まれた依頼もそこに書き写してもらいました。
1か月後に記録を見返すと、次のことが分かりました。
- 差し込みは23件あり、開発全体の時間の約35%を使っていた
- 23件のうち11件は、経営者自身が商談や顧客との電話のあとに出した依頼だった
- 「今すぐ」と依頼された15件のうち、2週間待つと顧客の業務が止まるものは4件だった
- 同じ大口顧客からの帳票まわりの依頼が、6件あった
翌月から、依頼の入口を専用の場所に限り、振り分けは毎朝15分で経営者が行うことにしました。商談のあとに出た依頼は、その日のうちに書き込むものの、振り分けは翌朝に回すと決めました。あわせて、開発時間の15%を差し込みの枠として空け、帳票まわりは個別に直すのをやめて、翌月の計画で設計から見直すことにしました。
3か月後、差し込みに使う時間は開発全体の約15%に収まり、計画した機能のうち8割ほどを月内に出せるようになったという想定です。経営者は、「振り分けを翌朝にするだけで、自分の依頼の半分くらいは『次の区切りで』になった」と振り返っていました。
よくある質問（FAQ）
Q1. 大口顧客からの依頼は、すべて「今すぐ入れる」にすべきではないでしょうか。
顧客の規模だけで区分を決めると、大口顧客からの依頼がすべて差し込みになり、計画が成り立たなくなります。区分を決めるのは、依頼元ではなく「2週間待ったら何が起きるか」です。そのうえで、契約の更新が近いなど、事業上の事情を考慮して「次の区切りで入れる」の中で優先するのが現実的です。
Q2. 依頼の入口を1つにしても、エンジニアに直接頼む人がいなくなりません。
最初の数週間は、そうした依頼があって当然です。エンジニアには、直接頼まれたら「入口に書いてもらえますか」と返してよいこと、その返事をしても問題ないことを、意思決定者からはっきり伝えておきます。依頼する側にも、入口に書かれた依頼は翌日までに必ず振り分けられることを示すと、徐々に入口に集まるようになります。
Q3. 差し込みのための枠は、どのくらいが適切ですか。
1割程度から始め、記録をもとに調整するのがおすすめです。立ち上げ直後で顧客が少なく、仕様の変更が頻繁にある時期は、2割から3割になることもあります。大切なのは、枠の大きさを感覚ではなく、記録に基づいて決めることです。
Q4. スプリントのような短い周期で開発していない場合は、どうすればよいですか。
区切りが決まっていない場合は、「毎週月曜日に、次の1週間の作業を確かめる」といった見直しの日を1つ決めます。「次の区切りで入れる」とした依頼は、その日にほかの候補と並べて判断します。周期の長さよりも、決まった日に判断することのほうが大切です。
Q5. 1人目のプロダクトマネージャーを迎えたら、差し込みの扱いはどう変わりますか。
依頼の入口と振り分けを、プロダクトマネージャーに任せやすくなります。そのとき、振り分けの基準（今すぐ入れる、次の区切りで入れる、候補として積む）と、これまでの記録を一緒に渡すと、判断がそろいやすくなります。経営者自身の依頼も、プロダクトマネージャーの入口を通すことを、最初に約束しておくことをおすすめします。
まとめ
開発の差し込み依頼は、なくすことはできません。問題は、差し込むかどうかを、その場の勢いで決めていることにあります。
差し込みに対応するには、(1)依頼を1か所で受ける、(2)「今すぐ入れる」「次の区切りで入れる」「候補として積む」の3つに振り分ける、(3)入れるなら外すものを同時に決める、(4)差し込みを記録し月に一度振り返る、という4つのステップで受け方を整えます。あわせて、開発時間の1〜2割を、差し込みのための枠として最初から空けておくと、計画を崩さずに受け入れられる場面が増えます。
まずは、来週1週間に届いた差し込み依頼を、すべて書き出してみてください。誰から、どんな依頼が、どのくらい来ているのか。それが見えるだけで、どこから手をつけるべきかが分かってきます。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
