・「80％完了」と言われていたのに「とりあえず動くだけ」のコードしかなかった ・「最優先で」とお願いしていたのに、他のタスクが優先された そんな開発あるあるも、距離・時差・文化の壁がある多拠点開発では、致命的な遅れに直結します。 日本・インド・ベトナムの3拠点、計300名体制の開発組織を統括する著者が、失敗の末に辿り着いた、マネジメント設計の知見を初公開。 ・「Summary」「Risk」「Help/Request」の3種セットでの報告を常に義務付ける ・DoD、RACI、PERT、Estimation Poker...見積もりを対話に変えるしくみ ・「形式を守らせる」のではなく「経験が循環する」ことを主眼にレビューする 仕様伝達、進捗報告、品質管理、ルール運用、人材育成.......各場面で頻出する「ズレ」を解決する実践知！ まえがき──しくみはあるのに、なぜ進まない・伝わらない・育たないのか 第1章 なぜ進まない・伝わらないのか──日常の違和感から考える多拠点連携 1.1 見積もったのに合わない、伝えたのに通じない。現場で起きているすれ違い 1.2 ソフトウェア人材確保とオフショア開発拠点の役割 1.3 技術マネジメントとは何か──しくみ・関係・成果 第2章 任せたのに進まないのはなぜか──進捗と期待値を合わせるしくみ 2.1 報告があるのに不安が残る理由──伝えている」と「伝わっている」のギャップ 2.2 見積もりと期待値のズレを防ぐ設計──前提のすり合わせができているか 2.3 タスク分解と役割整理──属人化を防ぐ任せ方の基本 2.4 異文化環境での任せる再設計──安心と納得を両立させる仕掛け 第3章 仕様が伝わらないのはなぜか──伝える技術の再設計 3.1 技術的な仕様ズレの構造──「何を作るか」が噛み合わない背景 3.2 ドキュメントだけでは足りない意味の共有 3.3 本社と現地、 開発とテストをつなぐ言葉の整理 3.4 ブリッジSEの役割背景を伝えるコミュニケーション設計 第4章 しくみが形骸化するのはなぜか──プロセスを現場で回す方法 4.1 「守られないプロセス」の構造──導入が形骸化する理由 4.2 設計から始める品質づくり──上流での具体策 4.3 フィードバックを価値ある学びに変える──レビュー文化と育成の接続 4.4 日本から守らせるでは動かない──共通ルールの伝え方を見直す 第5章 技術と育成をどう両立させるか──成長する開発組織の設計図 5.1 技術スキルは現場資産としてマネジメントする 5.2 任せ方と信頼関係の設計──テックリード・マネージャーを育てる 5.3 経験移譲と配置設計──育つ場をつくる 5.4 教育のしくみとしてのレビューとOJT 5.5 育てる＝設計するという視点 第6章　進化する海外拠点──しくみで育つ現場の未来像 6.1 成長の踊り場をどう越えるか 6.2 現地から価値を生む仕掛け 6.3 本社と現地が共創するチーム体制へ 6.4 AI・分散開発・越境キャリア──次の一手を描く あとがき 参考文献 索引 付録チェックリスト