エンジニア組織全体で取り組むDX改善：現場とマネジメントが連携した生産性向上への挑戦
DXとは
開発者体験
生産性向上が目的
マネージャーの成果はチームの全体成果の合計である
生産性：正確に確認できない
=> 摩擦削減を計測する
摩擦 = 開発を遅くする要因
改善サイクルのメカリズム
摩擦の可視化
定量データ + 定性サーベイ
4半期改善サイクル
サーベイ
15分程度
摩擦に注力
摩擦がどこで生まれているか
結果がすぐにわかる：フィードバック
集中できる：フロー状態
理解しやすい：認知負荷
摩擦は14のカテゴリに分類
改善対象は1〜2個に絞る
参加率
高める必要性がある
全体を考えるため
開発者=>サーベイ
EM=>改善
CTO/VPoEから重要課題であるとして発信
リマインド
透明性
結果・インサイトの共有
次のサイクルに繋げる
ステークホルダー別コミュニケーション
各領域ごとにメッセージを変えて伝える
経営：コスト、リスク
非エンジニア：生産性
改善サイクルの定着と文化
最初のサイクル
チーム単位+エスカレーション
横展開がうまくいかない
上位の組織の動きが見えない
チーム、組織、プラットフォームの三層で改善
チームによる低コストな改善
組織・プラットフォームによる大きな改善
プラットフォームなら複数チームへの改善
実例：Deep Work改善
ミーティングが多い、突発問い合わせ
会議削減、ノーミーティングデイ
問い合わせbot、プロセス整理
組織全体に定着させるために
サーベイ、改善、共有、習慣化のサイクルを回す
サーベイは15分程度のボリュームにする
毎回精査して質問を増やさない
改善は1~2個に絞る
小さく始める
共有
ナレッジの蓄積
改善の結果、トレンドの変化をナレッジベース化
成功事例のパターン化
改善スコアの扱い
改善事例、ストーリーをフィードバック
DXチーム
専任チームで対応しているが、組織が小さいうちはEM有志で対応
ワーキンググループ
20〜40%のコミットメント
エンジニアリングラダーの期待値として明文化
生産性の説明
コスト削減（待ち時間*人数）
リスク低減（インシデント要因の排除）
摩擦削減をビジネス価値にする
まとめ
軸：摩擦低減
測定：定量データ、定性サーベイ
構造：三層による改善
定着：リズム、仕組み化、現場ケア
伝え方：ビジネス価値への翻訳