営業担当は優秀だったのに開発が始まったらうまくいかない？受託開発会社の体制を見るポイント

コンペのプレゼンは完璧だった。営業担当は課題を正確に理解し、的確な提案をしてくれた。

キックオフ後、別の世界が始まる。PMは別人、エンジニアはジュニア、報告は遅い、認識はズレる——営業と開発の分断は、受託開発で最も多いトラブルの一つだ。

営業の上手さと、開発の実行力は別物だ。コンペで見るべきはプレゼン力ではなく、実際にプロジェクトを回す体制だ。

なぜ起きるのか

多くの開発会社では、営業と開発が別組織になっている。

• 営業: 受注を取る（コンペに出る）
• PM: プロジェクトを回す（別の人）
• エンジニア: 実装する（さらに別の人）

コンペに出る営業担当が、実際のプロジェクトに一切関わらない構造は珍しくない。分断自体が違法なわけではない。問題は、分断を隠したまま期待値だけが上がることだ。

典型的に崩れるパターン

• 提案時の課題理解が、実働チームに引き継がれない
• 「シニア前提」の見積もりが、ジュニア中心体制になる
• 定例が報告会化し、意思決定が遅れる
• 営業には通じたのに、PMには毎回一から説明する

深掘り事例：キックオフで顔ぶれが入れ替わった案件

匿名化した一例だ。コンペでは営業とテックリード候補が揃い、課題の言い換えも的確だった。契約後のキックオフ資料で、テックリードは「アサイン調整中」、PMは別案件兼務の名前に変わっていた。

最初の6週間で起きたこと:

• 提案時の技術選定が現場で覆り、設計が二度手間に
• 週次定例の意思決定者が不在で、持ち帰りが増えた
• 発注側が「また営業経由で確認」する二重通信になった

契約条項に「提案メンバーの稼働」がなく、入れ替えを止められなかった。被害はスケジュール遅延3ヶ月と、信頼の毀損だ。分岐点は、書面で名前と稼働を取る前に押印したことだった。

契約前に確認すべき5つのこと

1. コンペに出た人は参画するか

「提案時のメンバーがそのまま参画します」——これを書面で確認する。口頭約束は無効。

2. PMの経歴と稼働率

PMは誰か。同時に何件走らせているか。1人のPMが5件以上並行している場合、注意が必要。

3. エンジニアのスキルと人数

テックリードは誰か。実装エンジニアは何人か。スキルセットは案件に合っているか。

4. 定例の設計

週次報告の形式、意思決定のフロー、エスカレーション経路——ここが具体化されていなければ、着手後に機能しない。

5. 過去の類似案件

同じPM・同じテックリードで、同規模の案件を成功させた実績があるか。

体制を見るチェックリスト

確認項目	OK	NG
提案メンバーの参画	書面で明記	「適宜アサイン」
PMの稼働率	週2日以上	週半日、5件並行
テックリード	名前と経歴が分かる	後日アサイン
定例設計	具体的なフォーマット	「適宜報告します」
エスカレーション	判断者と期限が明確	未定

キックオフ前にやるべきこと

契約後、キックオフ前に以下を要求する。

• プロジェクト体制図（名前・役割・稼働率）
• 最初の4週間の具体的な計画
• 定例ミーティングの日程と参加者
• コミュニケーションツールと報告フォーマット

ここで体制が変わるなら、キックオフ前に判断を変える余地がある。変わった理由が「都合」だけなら、契約条件の見直しを含めて交渉する。

判断軸：この体制で進めてよいか

状況	推奨
提案メンバーの稼働が書面にある	進行してよい
キックオフで主要メンバーが入れ替わった	理由と代替の質を確認。不満なら再交渉
PMが多件並行で定例が形骸化	稼働増またはPM交代を要求
営業経由でないと話が進まない	実働チームとの直経路を設計し直す

次に確認すること

1. 体制図（名前・役割・稼働）は書面にあるか
2. 提案時メンバーとの差分はあるか
3. PMの並行案件数は分かるか
4. 定例の意思決定者は参加するか
5. エスカレーション先と期限はあるか
6. 入れ替え時の事前通知義務はあるか

まとめ

営業の上手さと、開発の実行力は別物だ。

コンペで見るべきはプレゼン力ではなく、実際にプロジェクトを回す体制だ。分断がある会社でも、分断を開示し、実働を契約に落とせるなら取引できる。隠す会社は避ける。

---

開発会社の体制評価・選定支援の相談は、お問い合わせフォーム からどうぞ。