Article

社内のIT推進リーダーを育成する方法

高田晃太郎
社内のIT推進リーダーを育成する方法

研究データでは大規模なデジタル変革の約70%が目標未達に終わると報告され、要因の上位に「人材の不足」と「現場変革を牽引するリーダー不在」が並びます。¹ ² 開発生産性の分野ではDORAの長年の調査が、変革に成功する組織ほど継続的デリバリーの実装と文化的リーダーシップが噛み合っていることを示してきました。³ 実務でも、アーキテクチャやツールを整えるだけでは不十分で、最終的な成果の差は社内から育ったIT推進リーダーの数と質に現れます。

公開データの比較からも、変革の成功組織は単発の研修より実地の任務に重心を置き、明確なコンピテンシー定義と測定指標で育成を運用しています。⁴ 表層的なスローガンや短命のプロジェクトではなく、事業と技術の橋渡しが日常動作になるまでの仕組み化が要です。本稿では、推進役の役割を解像度高く定義し、社内で再現可能な育成設計と、成果を数値で語る測定フレームを、現場で使えるレベルまで具体化します。

IT推進リーダーの定義とコンピテンシー

まず役割を曖昧にしたまま育成すると、研修は充実しているのに現場の変化が起きないという矛盾が生まれます。ここでいう推進リーダーは単なるPMや上位職のエンジニアではありません。事業側の価値仮説をテクノロジーとプロセスに翻訳し、リスクを制御しながら継続的に価値を出し続ける存在です。本稿ではこの役割を、技術深度、事業実装力、変革推進力という三つの軸で整理します。

技術深度:決め切る力と守る力

十分な技術深度とは、すべてを自ら実装できることではなく、アーキテクチャの論点を切り出し、意思決定を記録し、守る力です。具体的にはADR(Architecture Decision Record:設計判断の記録)で判断を言語化し、セキュリティとSRE(Site Reliability Engineering:信頼性工学)の原則を前提に、パフォーマンスと信頼性のトレードオフを意識します。実務では、変更のバッチサイズを適正化し、トランクベース開発(メインブランチ中心の小刻みな統合)やデプロイ自動化の障害を一つずつ解体していきます。DORAの指標(リードタイム、デプロイ頻度、変更失敗率、復旧時間)を週次で可視化し、改善の手触りをチームに還元することが重要です。³ 過度に最新技術へ傾けば保守性が毀損され、逆に守りに寄り過ぎれば学習速度が鈍ります。だからこそ意思決定の根拠を透明にし、レビューの場で検証可能にしておくことが要になります。

事業実装力:価値仮説を行動に翻訳する

事業実装力は、ビジネスケースの作成やKPI設計を含みます。価値の式をシンプルに定義し、例えば「価値=採用率×利用頻度×節約時間−移行コスト」と置けば、プラットフォーム化や社内ツールの投資判断がぶれません。オンボーディング短縮を狙う施策なら、ベースラインとして現状の導入所要時間と失敗率を計測し、改善後の差分を金額換算して意思決定に繋げます。ここで重要なのは、施策の「採用率」に執着する姿勢です。セルフサービスが存在するだけでは価値になりません。対象チームの何割が日常運用に組み込んだかが成果の中核になります。

変革推進力:人とプロセスを動かし続ける

変革推進力は、ステークホルダーマッピングと合意形成、透明性の高い意思決定、そして現場が動けるように障害物を取り除く能力の集合です。実装では、意思決定の記録、定例の公開レビュー、デモデーという三点を常設すると、判断の筋道が見える化され、デモで実用的価値を魅せることで反対意見も検証可能な問いに変わります。習熟度はイネーブラーとしての影響範囲の広がりで測ります。例えば、直接の権限外チームがどれだけ自発的に合流し、共通コンポーネントを採用したかが一つの証拠になります。

育成設計:選抜、経験学習、仕組みの三層で回す

選抜を属人的にせず、明確なシグナルベースにすることが再現性を高めます。成果物の品質、フィードバックの質、周囲への影響の三点を観測し、「現時点で任せられる」「12カ月で任せられる」の二段階で候補を洗い出します。ここで大事なのは、現職の評価と育成ポテンシャルを混ぜないことです。現状の職能で輝いている人でも、推進役には別の行動特性が求められます。

学習設計は「70-20-10」の原則(経験70%・メンタリング20%・体系学習10%)が実務と相性が良いとされています。⁴ 例えば、レガシー領域の抽象化とプラットフォーム移行を一つの任務として定義し、三カ月を一単位に目標と測定指標を握ります。任務の出力はRFC(Request for Comments:提案文書)やADR、移行ランブック、採用率のトラッキングなど、事業価値に直結する実体のある成果に限定します。メンターとは週次30分で意思決定の質を点検し、月次レビューで利害関係者を交え、反証可能な形で進めます。体系学習はセキュリティ、SRE、データガバナンスの基礎をモジュール化し、短期に集中的に補強します。

仕組みとしては、コミュニティ・オブ・プラクティス(同じ課題領域の実践者コミュニティ)を常設し、課題と解決策を横断で共有できる場を作ります。⁶ 例えば、アーキレビュー、インシデントレビュー、デモデーを月内に散らし、意思決定と学習のサイクルが止まらないように設計します。こうすることで、個々の推進リーダーが孤立せず、他チームの知見を自分の任務に迅速に転用できるようになります。

ケース:300人規模組織での9カ月設計(例)

以下は設計例です。序盤の3カ月はベースライン測定とボトルネックの特定。中盤の3カ月でプラットフォーム化の最小価値提供と採用の立ち上げ。終盤の3カ月で広報と標準化に集中します。成果指標は、主要サービスの変更リードタイムが週単位から日単位へ、デプロイ頻度が週次から日次〜複数回/日へ、変更失敗率が一桁台へといったレンジを目標に置くのが一般的です。採用率は最小単位のセルフサービスで60〜70%の到達を3カ月目標にし、オンボーディング時間の20〜30%短縮を狙います。重要なのは、これらを特定個人の力量に依存させず、任務設計、メンタリング、公開レビュー、測定の四点を組み合わせた結果として再現可能にすることです。

人事制度との接続:評価・報酬・ロールの整合

育成を制度に接続しないと、短期の熱量で終わります。評価には行動特性と成果の両輪を入れ込みます。具体的には、採用率、DORA指標の改善、開発者体験のスコア(開発者満足度など)の結果に加え、意思決定の透明性や合意形成の質を観測可能にします。³ 報酬は個人の功績だけでなく、イネーブルメントによる組織全体の性能向上を適切に評価する設計にします。ロールはマネジメントトラックとテックリードトラックの双方から進路が開けるようにし、いわゆるStaff+(上級個人貢献者)が変革の主役になれる道を明記します。

実践の場づくり:任務、透明性、学習のループ

現場での推進は、任務の良し悪しに大きく左右されます。任務は明確な業務仮説、測定可能な成果、時間制約の三点で形にします。例えば「決済基盤の変更を1/3期間で安全に届ける」なら、対象サービス群、現状の指標、期待する改善幅を合意します。開始時にベースラインを測り、途中で阻害要因を洗い出し、終盤で手順を標準化して横展開します。ここで透明性は強力な武器です。意思決定はリポジトリで管理し、レビューは公開、進捗はカンバンで可視化します。これにより、批判は検証に転換され、反対意見も改善の素材になります。

学習のループは、事後検証で完成します。インシデントや失敗が起きた際は、責任追及ではなく因果の解明に集中します。エラーバジェット(許容可能な失敗の度量)を尊重し、回復と改善の時間を守ります。再発防止はプロセス変更、ツール整備、教育のどれで解くのかを明確にし、影響評価まで終えてはじめて完了とします。こうした姿勢が、推進役にリスクを取りに行く心理的安全性を与えます。⁵

コミュニケーション:物語と数値の両輪

変革の支持は、数値だけでも物語だけでも得られません。毎月、ユーザーストーリーと指標のペアを経営と現場に共有します。例えば「新しいセルフサービスにより、Aチームの新機能は準備工数が半減した」という物語に、採用率やリードタイムの推移グラフを重ねます。物語が現場の痛みを伝え、数値が投資の合理性を担保します。推進リーダー自身がこの両輪を扱えるようになると、合意形成のスピードが飛躍的に上がります。

権限なきリーダーシップ:影響力の設計

権限が限定される状況でも、影響力を設計できます。合意形成では、反対意見の根拠を言語化し、実験で検証可能な仮説に変換します。コミュニティでは、他チームの痛点を先に解決する小さな勝ち筋を用意し、自然な合流点を作ります。こうした姿勢を習慣化すると、肩書きの力ではなく、価値提供の実績で人が集まる状態に近づきます。

測定とROI:効果を数値で語り続ける

測定は育成の核です。DORAの四指標は開発プロセスの健全性を表し、開発者体験は持続性を示します。³ 四半期ごとに、採用率、リードタイム、変更失敗率、復旧時間、開発者満足度、プラットフォームのNPS(Net Promoter Score:推奨度)の六点を最低限のセットとして追います。特に採用率は、価値が現場に根付いたかを直接に示すため最重要です。目標設定では、短期の行動指標と中期の成果指標を結びます。例えば、最初の90日で対象チームの半数が新しいセルフサービスを週次で使っている状態を目標に据え、その後の90日でリードタイムの中央値を30%短縮する、といった具合です。

ROIは時間価値で語ると納得感が高まります。例として、セルフサービスにより毎回の環境構築が45分短縮され、週2回発生していたとします。5チーム×6人で運用しているなら、週あたり「45分×2×30人=45時間」の回収です。時間単価を仮に7,000円と置けば、週31万5千円、四半期で約400万円の節約になります。ここに移行コストと運用コストを足し引きするだけで、意思決定に必要な粗い見積りが得られます。肝心なのは、こうした計算を施策ごとに同じフォーマットで行い、毎月更新する習慣です。

個人の成長指標:推進リーダー自身の評価

個人の成長は、成果の再現性で測ります。具体的には、別ドメインでの横展開の成功率、影響範囲の拡大、メンタリングを受けた人材の自走率などが指標になります。週次の意思決定レビューの質も有効です。仮説の明確さ、反証の準備、リスクの洗い出し、撤退条件の設定といった観点でドキュメントを点検し、前月と比較します。こうした記録は、そのまま評価と昇進の根拠になり、任務の引き継ぎ時にも有効です。

よくある落とし穴:研修過多、定義不明、測定不全

育成が上手く進まない組織には共通点があります。最初は研修に比重が偏り、現場任務での成功体験がないまま自信だけが目減りします。次に、役割定義が曖昧で責任範囲が拡散し、推進リーダーが本来やるべき仕事ではなく火消しに追われます。最後に、測定が曖昧なため成果が語れず、予算が先細ります。これらはすべて、任務設計、定義、測定の三点を同時に運用すれば回避できます。短いサイクルで仮説検証し、判断の記録を残し、成果と学びを公開する。単純ですが、続けるほどに組織の標準動作になります。

まとめ:次の90日で始める設計

変革は人材から始まり、人材は設計から育ちます。いま手元でできる最初の一歩として、候補者を二名選び、90日間の任務を一つに絞って合意してください。開始前にベースラインを測り、週次で判断を記録し、月次で公開レビューを実施します。採用率とDORA指標を追いかけ、価値の式でROIを語る習慣をチームに根付かせます。これだけで、社内の会話は「ツール導入」から「価値の増幅」に変わり、推進リーダーは成果とともに自信を獲得します。

変革の難易度は高いままですが、やるべきことは明確です。 役割を定義し、任務で学び、測定で語る。この繰り返しが、人に根づく強い仕組みを生みます。あなたの組織で最初の90日をどう設計するか、そして誰と走るのか。今日のミーティングで、その話から始めてみませんか。

参考文献

  1. McKinsey & Company. How to implement transformations for long-term impact. 2023. https://www.mckinsey.com/implementation/our-insights/how-to-implement-transformations-for-long-term-impact
  2. PwC Japanグループ. 日本企業のDX推進実態調査2022 ~1割のDX成功企業から見えてきたDXMOの役割とは?~. 2022. https://www.pwc.com/jp/ja/knowledge/thoughtleadership/dx-survey2022.html
  3. Google Cloud (DORA). Announcing the 2023 State of DevOps Report: Culture is everything. 2023. https://cloud.google.com/blog/products/devops-sre/announcing-the-2023-state-of-devops-report
  4. Rassameethes B, Phusavat K, Kess P, et al. From training to learning: Transition of a workplace for Industry 4.0. Human Systems Management. 2022;41(6). doi:10.3233/HSM-211533
  5. Edmondson AC. Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly. 1999;44(2):350-383. https://www.jstor.org/stable/2666999
  6. Wenger EC, Snyder WM. Communities of Practice: The Organizational Frontier. Harvard Business Review. 2000. https://hbr.org/2000/01/communities-of-practice-the-organizational-frontier