エンジニア・デザイナーなどの開発メンバーが、PdM・企画と「依頼を受けて作る関係」ではなく「同じ成果を目指して並走する関係」をつくるための実践ガイドです。
目次
1. 基本スタンス
| 受け身の関係 | 伴走する関係 |
|---|---|
| 仕様が決まってから動く | 仕様を決める段階から関わる |
| 「何を作るか」だけを聞く | 「なぜ作るか」「何が良くなれば成功か」を聞く |
| できない理由を返す | 制約と代替案をセットで返す |
| リリースしたら終わり | 効果測定と次の打ち手まで付き合う |
- 目的（Why）を共有することが最優先。 手段（What/How）はそのあとで一緒に決める。
- PdMは「決める人」、開発は「選択肢と判断材料を出す人」。 役割は分けつつ、判断の質には双方が責任を持つ。
- 相手の不確実性を減らすことが伴走の本質。 早く・正直に情報を出すことが最大の貢献になる。
2. フェーズ別の関わり方
2-1. 企画・構想フェーズ（Discovery）
- 企画の初期段階から、技術的な実現性やコスト感をざっくり返す（Tシャツサイズ見積もり：S/M/L/XL）。
- 「この課題なら、こういうやり方もある」と代替案を出す。技術を知っている人だからこそ出せる安い解決策がある。
- 既存データ・ログで仮説を検証できないか提案する。作る前に確かめられることは多い。
- 確認したいこと：
- 解決したいユーザー課題は何か
- 成功をどの指標で判断するか（KPI / 定性ゴール）
- 期限の根拠（外部要因か、社内目標か）
- やらないこと（スコープ外）は何か
2-2. 要件定義・仕様策定フェーズ
- 仕様の「穴」を早く見つける：エッジケース、エラー時、権限、既存機能への影響、データ移行など。
- 要件に優先度（Must / Should / Could） をつけてもらう。削れるものが分かっていればスケジュール調整が楽になる。
- 仕様書をレビューするときは「質問」で返す。「これは〇〇のケースではどうなりますか？」の方が、「抜けています」より議論が前に進む。
- 決定事項と未決事項を分けて記録し、未決事項には担当と期限をつける。
2-3. 開発フェーズ
- 進捗は 「予定どおり / 懸念あり / 遅延」の3段階で、悪いニュースほど早く伝える。
- 実装中に仕様の判断が必要になったら、選択肢＋推奨案＋影響をセットで相談する。
- 例：「A案（工数+2日、UX良）とB案（工数そのまま、一部手動）があります。期限優先ならB案を推奨します」
- 動くものを早めに見せる（デモ・ステージング・スクショ）。文章の仕様より、触れるものの方が認識のズレが見つかる。
- スコープ追加の依頼が来たら、断るのではなくトレードオフを可視化する（何を削るか、何日延びるか）。
2-4. リリース・検証フェーズ
- リリース判定の基準（品質ライン、既知の不具合の扱い）を事前に合意しておく。
- 計測の仕組み（イベントログ、ダッシュボード）は開発と同時に用意する。リリース後に「測れない」が一番もったいない。
- 振り返りでは、結果の数字に加えて仮説がどうだったかを一緒に確認し、次の施策につなげる。
3. コミュニケーションの型
相談・報告のフォーマット
【結論】〇〇について判断をお願いしたいです
【背景】△△の実装中に□□が分かりました
【選択肢】
A: ……（メリット / デメリット / 工数）
B: ……（メリット / デメリット / 工数）
【推奨】Aです。理由は……
【期限】〇日までに決まると予定どおり進められます
見積もりの伝え方
- 1つの数字ではなく幅で伝える（例：「3〜5日、不確実性は外部APIの仕様」）。
- 見積もりの前提条件を明記する。前提が崩れたら見積もりも見直す、と合意しておく。
- 不確実性が大きいものは「まず1日調査（スパイク）して見積もりを出し直す」と提案する。
言い換えの例
| 避けたい言い方 | 伴走する言い方 |
|---|---|
| 「それは無理です」 | 「そのままだと〇週かかります。△△を削れば今月中に出せます」 |
| 「仕様が曖昧です」 | 「この部分、A/Bどちらの想定ですか？」 |
| 「聞いていません」 | 「今の段階で分かってよかったです。影響を洗い出します」 |
| 「技術的に難しい」 | 「〇〇がボトルネックです。代わりに□□なら実現できます」 |
4. 仕組み・会議体
| 仕組み | 目的 | 目安 |
|---|---|---|
| 定例（週1） | 進捗・リスク・判断事項の共有 | 30分。判断事項を最初に扱う |
| 仕様レビュー | 着手前の認識合わせ | 開発メンバーも必ず参加 |
| デモ会 | 動くもので認識のズレを発見 | スプリントごと |
| 決定ログ | 「いつ・誰が・何を・なぜ」決めたかの記録 | ドキュメント / チケットに残す |
| 振り返り | プロセスと成果の改善 | リリース後・四半期ごと |
- 雑談や1on1など、業務以外の接点も信頼関係づくりに効く。
- 非同期（チャット・ドキュメント）と同期（会議）を使い分ける。込み入った議論は15分話した方が早い。
5. 信頼関係を築くために
- 約束を守る / 守れないときは早く言う。 信頼は小さな約束の積み重ねでできる。
- 相手の制約を理解する。 PdMは経営・営業・顧客など多方面からの圧力の中で判断している。
- ビジネス・ユーザーへの関心を示す。 顧客インタビューやデータ分析に同席すると、会話の解像度が一気に上がる。
- 成果は一緒に喜び、失敗は仕組みの問題として扱う。 個人を責めない。
- 「作らない」提案もする。 不要な開発を止めるのも、立派な貢献。
6. よくあるアンチパターン
- 仕様書の投げ渡し：開発が仕様策定に関わらず、着手後に問題が次々出る。
- 見積もりの一人歩き：前提つきの概算が、いつの間にか確定納期として扱われる。
- 悪いニュースの先送り：遅延が直前に発覚し、選択肢がなくなる。
- スコープの静かな膨張：小さな追加が積み重なり、誰も全体の工数を把握していない。
- リリースで終わる：効果を測らず、施策の良し悪しが分からないまま次に進む。
- 決定事項が口頭のみ：後から「言った/言わない」になる。
7. チェックリスト
着手前
- 目的と成功指標を言葉で説明できる
- スコープ外（やらないこと）が明確
- 要件に優先度がついている
- 見積もりの前提が共有されている
- 未決事項に担当と期限がある
開発中
- 進捗とリスクを定期的に共有している
- 仕様判断を選択肢＋推奨案で相談している
- 動くものを早めに見せている
- スコープ変更時にトレードオフを提示している
リリース後
- 計測ができる状態になっている
- 結果と仮説を一緒に振り返った
- 次の打ち手を合意した