① 認識ギャップ ダッシュボード
国内外チームの停滞は「言語」 ではなく「前提のズレ (Drift)」 から生まれる。 ビジネス・技術・文化の 3 種の Drift を可視化し、 中央の判断軸ハブで吸収する。
停滞の正体 — 「言語の壁」 ではない
1. ビジネス Drift: 「完了」 の定義が JP=検収・VN=実装完了でズレる
2. 技術 Drift: 非機能要件 (性能・運用) の暗黙前提が共有されない
3. 文化 Drift: 「報告タイミング」「エスカレ基準」 の習慣差
→ 翻訳すべきは言葉でなく「判断の前提」
大山の役割 — 判断軸のハブ
全システムを最も深く理解する人間として認知され、 本案件だけでなく別案件の相談も受ける信頼関係を構築。
立場でなく構造で合意を作る。 3 次受けの立場ながら、 部署間調整でインフラ部の地位を向上させ、 プレミアムパートナ 1 位の評価を獲得した。
② 判断軸ハブ モデル
各チームが直接やり取りすると Drift が増幅する。 中央に「判断軸ハブ」を置き、 全ての前提・判断基準をここで翻訳・統一する。
仕様 / 品質 / 責任を統一
ハブが翻訳する 3 つ
仕様の前提 — 何を「完了」 とするか
品質の基準 — DoR / DoD / レビュー観点
責任の所在 — 誰が判断・実行・相談か
直結を避ける理由
JP↔VN 直接は、 各自の前提で解釈 → Drift 増幅 → 手戻り。 ハブ経由で前提を 1 度揃えると、 以後の往復が速くなる。
Sun Asterisk への接続
Magna の B・T・C 混合チームでも同じ。 ハブが構想と実装のズレを構造的に防ぎ、 「巻き込む (WASSHOI)」 を仕組みで支える。
③ 3 つの Drift を解消する
前提のズレ (Drift) を「放置すると何が起きるか」 と「ハブで揃えるとどうなるか」 を並べて可視化。
結果: 手戻り率 38% → 8%
3 種の Drift をハブで揃えた結果、 仕様解釈差による手戻りが 30 ポイント減。 言語研修でなく「判断の前提を構造で揃える」ことが効いた。
④ 翻訳プロトコル — 4 つの仕掛け
判断軸ハブを「個人技」 でなく「再現可能な仕組み」 にする 4 つのプロトコル。 誰が運用しても回る。
| プロトコル | 中身 | 解消する Drift | Magna への移植 |
|---|---|---|---|
| 仕様凍結 | 各スプリント開始前に仕様を凍結し、 変更は判断ハブ経由のみ | ビジネス Drift | BTC 混合チームの構想ブレ防止 |
| ブリッジ SE | JP-VN 間の非機能・技術前提を双方向翻訳する専任 | 技術 Drift | UI/UX 要件定義参画と同じ座組み |
| QA ゲート | 各工程末に品質ゲート、 前提逸脱を次工程に流さない | 技術・ビジネス Drift | Layered Gate Protocol の原型 |
| 申し送り様式 | 報告・エスカレを定型化し、 非同期・時差を吸収 | 文化 Drift | 1,000 名超アセットの非同期運用 |
⑤ 72 名 運用実績 — アジア金融システム統一化
アジルラボ時代 (6 年 8 ヶ月の中核案件)。 銀行のアジア金融システム統一化で、 3 次受けの立場から 1 次受けプレミアムパートナ 1 位まで引き上げた構造。