Nexusフレームワーク

従業員60名のECサイト運営企業。エンジニア15名を3チーム（フロント・バックエンド・データ基盤）に分けてスクラムを実践していたが、スプリント終了時にフロントとバックエンドの接続がうまくいかず、毎スプリント 2〜3日 の統合作業が発生していた。

Nexusを導入し、以下を変更:

• NIT: CTOがプロダクトオーナー兼任、専任スクラムマスター1名、各チームからアーキテクト1名
• クロスチーム・リファインメント: スプリント開始2日前に全チーム代表が2時間で実施
• Nexusデイリー: 毎朝10時に15分、各チーム代表1名が参加

統合の問題がスプリント初日から可視化されるようになり、「最終日のサプライズ」が消えた。

従業員300名のSIer。金融機関の基幹システム刷新プロジェクトで、5チーム（合計35名）がスクラムを採用。しかし各チームが独自のペースで動き、結合テストのたびにインターフェースの不整合が発覚。結合テストの不具合修正に毎スプリント 延べ40人時 を費やしていた。

Nexusフレームワークを導入。

• NIT: プロジェクトマネージャー + 各チームのテックリード5名で構成
• 共通Definition of Done: APIスキーマの整合性チェック、結合テストのパスを全チーム共通のDoDに追加
• クロスチーム・リファインメント: 依存マップを壁に貼り出し、毎スプリント更新

導入6か月後:

• 結合テストの不具合修正工数: 40人時 → 8人時（80%削減）
• スプリントのベロシティ（全チーム合計）: 92SP → 124SP
• 顧客への中間デモの回数: 月1回 → 2週間に1回（信頼関係が強化）

API仕様の不整合が事前に発見できるようになったことが最大の改善ポイントだった。

本社（東京）と開発拠点2か所（福岡・札幌）を持つソフトウェア企業（従業員45名）。各拠点にスクラムチーム1つ（4〜5名）を配置しているが、拠点間のコミュニケーション不足で「同じ機能を2チームが別々に実装していた」という事故が発生。

Nexusを導入し、リモートでもチーム間の連携を構造化。

• Nexusデイリー: 毎朝9:30にZoomで15分、各拠点のリーダーが参加
• クロスチーム・リファインメント: 隔週月曜にMiroボードで依存マップを更新（60分）
• 統合CI/CD: GitHub Actionsで全チームのコードが自動マージ・テストされるパイプラインを構築

導入前後で重複開発は 0件 に。各チームの開発速度は変わらないまま、プロダクト全体のリリースサイクルが月1回から 2週間に1回 に改善。福岡チームのリーダーは「毎朝15分のNexusデイリーで、他拠点の状況が分かるだけで安心感が全然違う」と話している。