Services — ケイパビリティ創造 2-4

デジタル内製化を前提とした組織再編

—

何を自社で担うべきかを定め、事業成果につながる組織へ組み替える。

背景と課題

デジタル人材を採用し、開発組織も新設した。それでも、事業部門との役割分担や意思決定の仕組みが従来のままでは、内製化の効果は限られます。また、すべての機能を自社で持つことが良いとも限りません。競争力の源になる機能と、外部の専門性を使うべき機能を見極め、事業の成果につながる組織と運営の仕組みを設計する必要があります。

組織が変わりにくい理由

  • 体制図は新しくなったが、会議の進め方と決裁の流れは前のまま。 事業部門とデジタル部門の責任の範囲と意思決定の流れが従来のままだと、内製組織の役割は「要望を受けて作ること」にとどまります。
  • 人員構成の変化と技術の普及を織り込まない組織は、数年で前提が変わります。 今の問題を解くだけの設計では、人数が減った後の姿に届きません。
  • 効果の見積もりに根拠がないと、投資判断ができません。 開発にAIを入れる時、レビューや管理で増える手間を見込まずに効果を見積もると、導入後にその効果が出ません。
  • 新しいルールを整えても、実践の場がないと現場に根づきません。 お手本がなく、例外ばかりで、直す場もないと、ルールは紙の上に残るだけになります。
  • 外部委託の範囲と知識の移管の責任が曖昧だと、終わった時に社内に能力が残りません。 ルールと手順書を置いて終わる支援も、ずっと常駐する支援も、同じ結果になります。

対象となる企業・状況

デジタル開発の外部への依存を見直したい企業、内製組織を設けても事業部門との連携が進まない企業に向けたサービスです。

  • 社内に一定規模の開発組織があり、AI活用が個人の使い方にとどまっている。
  • 拠点や部門が多く、全社で同じやり方にそろえることに抵抗が予想される。
  • 数年後に社員構成が大きく変わると分かっているのに、組織づくりの目的が足元の効率化にとどまっている。
  • コンサルタントを使ったが、社内に何も残らなかった経験がある。

サービス概要

  • 事業戦略と業務の特性を踏まえ、自社で担う機能、外部と協働する機能、共通にする機能を整理します
    • そのうえで、組織の構造、意思決定の権限、人材の配置、開発と運用のプロセス、ベンダーとの関係を設計し直す
    • 人材の確保だけでなく、開発と改善を続けられる組織運営への移行を支援する
  • 組織の将来の姿は、今の課題と中長期の事業戦略の両方を踏まえて定めます
    • 足元の属人化、引き継ぎ、ばらつきの問題を解いた姿と、将来の市場・社員数・これから広まる技術から逆算した姿を同じ時間軸に並べ、両方を満たす姿を1枚に描く
  • 開発プロセスへのAIの適用は、開発現場に残っている記録で診断します
    • 作業依頼、コードの変更履歴、レビューのやり取り、障害の記録、AIの利用状況を分析し、要件定義から運用保守までの工程ごとに導入前後の流れを設計する
    • 効果は、確認や管理で増える手間を差し引いて示す
  • 社員の理解は「知る、分かる、試す、身につく」の段階を踏むと捉え、権限や評価の仕組みの変更と併せて、段階ごとに施策を変えます
    • なぜ変えるのか、何を変えるのかを繰り返し伝える施策と、実際にやって手応えを感じる場の両方を用意する
  • 立ち上げの実務は当社が担い、運用が固まるにつれて役割をお客様に移します
    • 業務を、自社が持つべき技術・業務の能力と、外部に残す機能を基準に分け、立ち上げ、移行、自走の段階ごとに誰が担うかを入れ替える

提供価値

01内製・外部・共同運営の切り分け案

内製化率や人員数を起点にせず、製品・サービスの価値向上に必要な能力から逆算する。機能を3つに仕分け、事業上の重要性と保有能力を基準に内製・外部活用・共同運営を比べ、その結果として内製化の範囲と人員が決まる

事業上の重要性と、持っている能力を基準に、自社で担う機能と外部に任せる機能を判断できる案です。

  • 競争力の源になる機能、外部の専門性を使った方がよい機能、共通にする機能を、事業戦略と業務の特性から仕分けます。
  • 標準化・自動化する基準と、人の判断や地域の特性を残す基準を文書にします。現場に説明する時の拠り所にします。

02事業部門とデジタル部門の責任範囲と意思決定の流れ

体制図だけが新しく決裁の流れが前のままだと、内製組織は要望を受けて作ることに留まる。組織構造・意思決定権限・人材配置・ベンダーとの関係を将来の姿に沿って再設計し、運用の知見が次の要件へ還流するようにする

誰が何を決めるかを定め、組織と権限の設計に使える定義です。

  • 組織の構造、意思決定の権限、人材の配置、ベンダーとの関係を、将来の姿の1枚に沿って設計し直します。
  • 運用で分かったこと(障害、問い合わせ、要望)を次の要件に戻す仕組みまで含めます。

03開発プロセスの診断書と変革計画

開発プロセスを実データで診断し、7工程ごとにBefore / Afterを設計する。効果は粗い合計からガバナンス・レビューの追加工数を差し引いた純効果で示す

現状とAI活用の診断書、工程別の導入前後の流れ、見本となる事例、効果試算、ガバナンス、ロードマップです。

  • 要望の受付から要件定義、設計、実装、テスト、リリース・運用まで、工程ごとにAIが担える作業を定めます。要件の整理、影響範囲の洗い出し、テスト観点の案、リリース文書の下書きなどです。導入前後の流れを比べられる形にします。
  • 効果試算は、工程ごとに作業時間、外注費、開発の期間のどれを減らすかと年間の削減幅を置き、確認や管理で増える手間を差し引いて示します。AIが書いたコードも人が書いたコードと同じ基準でお客様の品質確認を通し、本番に出す前の最終確認は人に残します。

04標準プロセス、人材育成計画、定着の施策

社員の意識の段階(認知・理解・試行・体得)ごとに施策を変え、論理的な施策と直感に訴える施策を両輪で設計する。自走フェーズの基準を最初に合意する

評価と改善の仕組みと合わせ、移行後の運営を自社で続けられる計画です。

  • 社員の理解の段階(知る、分かる、試す、身につく)に合わせた施策を含みます。ベテランが次の世代に教える役を担う仕組み、うまくいった事例を集めて共有する場、定着の様子を測る仕組みも用意します。
  • 自社が持つ機能と外部に残す機能を、3つの段階(立ち上げ、移行、自走)で誰が担うかの図にし、どの時点で外部なしに回せる状態とするかを最初に合意します。

お客様に残る組織能力

  • 今の問題から見た姿と将来から逆算した姿を、1枚の時間軸の図で合意する進め方。
  • 自社の開発の記録からAI適用の優先順位を定める診断の手順と、工程ごとのAI利用ルールと品質基準。
  • 社員の理解の段階に合わせて打ち手を選ぶ考え方と、実案件の中で他の社員に教えられるリーダー。

TASPAの特徴

内製化率や人員数を目標にはしません。製品やサービスの価値を上げるのに必要な能力から組織を逆算し、その結果として内製化の範囲と人員を定めます。体制図を書いて終わりにせず、実案件の中で運用の流れと判断基準をお客様の担当者に移し、会議や決裁の進め方の変更まで扱います。

  • ベテランに「次の世代に教える役」を担っていただき、ヒアリングや有識者の議論の主役にします。 経営層と中核の管理職には、各現場で変革の必要性を自分の言葉で語っていただきます。
  • すでにお持ちのAIツールを前提にし、追加するツールにはその理由と運用の手間を添えます。 開発へのAIの適用は、個人の使い方ではなく、工程ごとの利用ルールと品質基準として組み込みます。
  • 小さな成果を先に出し、変えにくい工程、権限、部門間の責任分担に力を集めます。 不安を感じている社員への個別の支えを施策に含めます。
  • AI実装と組み合わせ、実案件の中で社内の担当者に知識と判断基準を移します。 移管する業務は、先に標準化と自動化を進め、社内で続けて運営・改善できる形にしてから引き継ぎます。

アプローチ

支援プロセス全体図。現状・戦略の分析と将来の姿の設定、機能の役割分担の設計、組織・ガバナンスと開発プロセスの再設計、移行計画と能力移転・定着の4段階を列に、主な確認事項・実施内容・主な成果物・判断の観点を行に置く

ご支援アプローチ詳細

  1. 現状・戦略の分析と将来の姿の設定
    • 主な確認事項:どの機能が競争力の源か。将来の人員構成と技術の普及を織り込むと、組織はどうあるべきか。
    • 実施内容:現場ヒアリングによる業務負荷、属人化、引き継ぎの状況の把握。経営と有識者への将来の問い(市場の推移、社員数、これから広まる技術)。2方向の答えを時間軸の図に置き、将来の姿を1枚で描く。システム部門、開発リーダー層、事業部門へのヒアリングと、AI活用の状況の診断。
    • 主な成果物:組織の将来の姿(1枚)、なぜ変えるのかを社内に説明する言葉、現状の診断書。
    • 判断の観点:将来の姿が自社の社員構成の変化と市場の推移に基づいていること、今の課題の解決だけで終わっていないこと、の2点で判断します。
  2. 機能の役割分担の設計
    • 主な確認事項:自社で担う機能、外部と協働する機能、共通にする機能はどれか。各段階で誰が担うか。
    • 実施内容:機能の仕分けと役割分担の比較。標準化する基準と残す基準の文書化。段階ごとの役割分担の図の作成。
    • 主な成果物:内製・外部・共同運営の切り分け案、役割分担の移行の図、外部なしで回せる状態の基準。
    • 判断の観点:事業部門とデジタル部門のどの役割を、いつから外部なしで担うかを、支援を終える基準にします。
  3. 組織・ガバナンスと開発プロセスの再設計
    • 主な確認事項:誰が何を決めるか。開発の各工程でAIをどう組み込み、人はどの付加価値の高い作業に集中するか。
    • 実施内容:組織の構造、権限、人材の配置、ベンダーとの関係の設計。開発の記録の分析(開発にかかる期間、要件の工数、レビューの指摘の傾向、手戻りの率、障害の分類、AIの利用記録)。工程別の導入前後の流れと見本となる事例。効果試算。工程ごとのAI利用ルールと品質基準。
    • 主な成果物:事業部門とデジタル部門の責任範囲と意思決定の流れ、開発プロセスの変革計画(導入前後の流れ、効果試算、ガバナンス、ロードマップ)。
    • 判断の観点:効果は、確認や管理で増える手間を差し引いて示します。AIが書いたコードも、人が書いたコードと同じ基準で品質を確かめます。
  4. 移行計画と能力移転・定着
    • 主な確認事項:社員は、知る、分かる、試す、身につくのどの段階にいるか。ベテランに先頭に立ってもらうには何が要るか。
    • 実施内容:定着を5段階で進める。計画をつくる、ベテランに先頭に立ってもらう、うまくいった事例を社内で共有する、参加する部門を広げる、社内で続けられる仕組みに整える。進み具合を測る道具の整備。実案件の中で一緒に働きながら、技能を社内の担当者に移す。次の期以降に、他の社員に同じ進め方を教えられるリーダーの育成。
    • 主な成果物:移行計画、標準プロセス、人材育成計画、定着の施策と測る仕組み、実案件で教える仕組み。
    • 判断の観点:標準プロセスは、実案件の中で社内の担当者が実際に回してから移管します。
2-3 ジョイントベンチャーによるAIビジネス開発 ←Services 一覧へ ←2-5 AIドリブンなPMO・ベンダーマネジメント支援 →お問い合わせ →