概要

• 「80％完了」と言われていたのに「とりあえず動くだけ」のコードしかなかった
• 「最優先で」とお願いしていたのに，他のタスクが優先された

そんな開発あるあるも，距離・時差・文化の壁がある多拠点開発では，致命的な遅れに直結します。

日本・インド・ベトナムの3拠点，計300名体制の開発組織を統括する著者が，失敗の末に辿り着いた，マネジメント設計の知見を初公開。

• 「Summary」「Risk」「Help/Request」の3種セットでの報告を常に義務付ける
• DoD，RACI，PERT，Estimation Poker...見積もりを対話に変えるしくみ
• 「形式を守らせる」のではなく「経験が循環する」ことを主眼にレビューする

仕様伝達，進捗報告，品質管理，ルール運用，人材育成.......各場面で頻出する「ズレ」を解決する実践知！

こんな方におすすめ

• オフショア開発や海外拠点を含む多国籍チームに関わるPMやマネージャーの方
• 本社エンジニアリング部門のリーダー層の方
• 品質，生産性の課題に向き合う管理職の方

サンプル

目次

• まえがき──しくみはあるのに，なぜ進まない・伝わらない・育たないのか

第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.1　技術スキルは現場資産としてマネジメントする
• 5.2　任せ方と信頼関係の設計──テックリード・マネージャーを育てる
• 5.3　経験移譲と配置設計──育つ場をつくる
• 5.4　教育のしくみとしてのレビューとOJT
• 5.5　育てる＝設計するという視点

第6章　進化する海外拠点──しくみで育つ現場の未来像

• 6.1　成長の踊り場をどう越えるか
• 6.2　現地から価値を生む仕掛け
• 6.3　本社と現地が共創するチーム体制へ
• 6.4　AI・分散開発・越境キャリア──次の一手を描く

• あとがき
• 参考文献
• 索引
• 付録チェックリスト

サポート

現在サポート情報はありません。