TDCソフトのAI変革支援、診断から90日計画へ

TDCソフトは2026年10月15日の公式発表で、企業向け「AI-Native変革デザイン支援サービス」の提供を開始し、8評価軸による診断から候補の優先順位付け、全体設計図、90日アクションプランの策定までを標準2～4週間で支援すると明らかにした。診断結果を提示して終えるのではなく、経営・事業・開発の関係者が次に着手するテーマと実行順序を決めるためのコンサルティングサービスだ。

TECH+の報道は、経営層、事業部門責任者、PMO・企画担当者、開発リーダー、AI推進責任者などを主な対象としている。発注を検討する企業が見極めたいのは、成熟度の評価に加えて、どの業務を選び、何を成功指標にし、誰の判断で実践へ移るのかが成果物に残るかどうかだ。

評価軸は技術と組織の両方を含む

診断はAIツールの利用状況だけを見るものではない。公表された評価領域と、発注側が現状を説明する際に整理しておきたい情報を対応させると、次のようになる。括弧内はサービスが指定した提出書類ではなく、各領域を具体的に話し合うための材料だ。

AI戦略・ビジョン：AI活用を結び付ける事業目標、対象部門、経営上の優先課題。
投資・価値管理：投資判断を担う人、期待する効果、その効果を測る既存の指標。
AI人材・育成：業務利用者と開発担当者の役割、教育状況、必要な技能。
推進人材：部門間の調整や導入を担う人、決定を下すまでの経路。
ガバナンス・倫理：利用ルール、承認手続き、品質や情報管理上の懸念。
データ基盤：対象業務で使うデータの所在、利用権限、更新方法。
AI活用基盤・ツール：既存の利用環境、接続先、運用を担う組織。
組織文化・実験文化：試行の進め方、結果の共有方法、改善を続ける体制。

これらを一律に高得点へ引き上げることが、候補選定の目的ではない。たとえば利用可能なデータがあっても効果を判断する責任者が決まっていなければ、試行を続けるかどうかを決めにくい。一方、推進役がいてもデータの権限や品質が不明なら、実現可能性の見積もりは曖昧になる。各領域の弱点が候補業務にどう影響するかまで見ることで、評価が優先順位付けの材料になる。

短期の工程で何を成果物にするか

標準的な工程は、AI-Nativeアセスメントと成熟度評価、結果を分析するワークショップ、Value Blueprint Workshop、実行計画と次の段階についての合意という順序で示されている。AI活用の候補は、企画、要求、設計、実装、テスト、保守などの工程から抽出し、事業価値と実現可能性の両面で優先順位を付ける。つまり、全社に同じ導入順を当てはめるのではなく、対象業務と制約を踏まえて重点テーマを選ぶ構成だ。

公表された成果物は、現在地の評価から着手順までをつなぐ一式になっている。それぞれの役割を分けておくと、発注側は成果物の名称だけでなく、自社のどの判断に使えるかを確認しやすい。

現状と差分：AI-Native Assessment Report、評価軸のスコアとレーダーチャート、AI-Native Gap Analysisが、強み・課題と目指す状態との差を示す。
目標と候補：AI-Native Vision CanvasとAI Opportunity Mapが、目指す方向と活用候補を整理する。
選定したテーマの設計：AI-Native Value Blueprintが、事業目標、対象バリューストリーム、AIの用途、期待成果、KPI、リスク、前提条件を結び付ける。
実行順序：アクションプランが、選定したテーマを次の期間にどう進めるかを示す。

Blueprintで重要なのは、期待する改善と、その改善を妨げる条件を同じ設計の中で扱うことだ。たとえば開発工程の一部を対象とするなら、作業時間だけを成果指標にするのか、品質確認や承認の負担も含めるのかで、必要なデータと担当者は変わる。これは条件付きの検討例であり、特定の業務で効果が出たという実績ではない。

依頼前に整理したい質問

短い標準期間で候補の選定と計画への合意まで進めるには、発注側が対象範囲と意思決定の仕組みを説明できるとよい。以下は公表された必須提出項目ではなく、評価領域と成果物を自社の判断につなげるための質問票だ。回答が未確定の項目も、そのまま論点として持ち込める。

目的とKPI：改善したい事業成果は何か。現在値を誰が把握し、いつ、どの単位で変化を判定できるか。
対象業務：どの部門の、どの工程を候補にするか。担当者、入力、出力、例外処理を説明できるか。
決定権：候補の優先順位、予算、利用ルールを誰が決めるか。経営、事業、開発の関係者は同じ目標を共有しているか。
データ基盤：必要なデータはどこにあり、誰が利用を許可できるか。欠損、更新頻度、既存システムとの接続は把握できているか。
リスク：機密情報、誤った出力、品質保証、監査への対応を誰が担うか。試行を止める条件は何か。
実行体制：計画策定後に担当するチームはあるか。業務担当者と技術担当者が継続して結果を確認できるか。

すべてを事前に決める必要はないが、対象業務と成功指標がともに曖昧なままでは、候補の事業価値を比較しにくい。データの利用可否や決裁者が未定なら、それも実現可能性を左右する条件になる。質問票の役割は回答欄を埋めることではなく、診断中に解ける問題と、社内で決めなければならない問題を見分けることにある。

実践へ移る条件と後続サービス

今回のサービスで合意するのは、設計図、実行計画、次の段階だ。後続には、開発プロセスの改革、選定チームでの実践、組織への展開を支援するサービスが順次予定されており、名称と内容は変更される可能性がある。したがって、今回の成果物を受け取ることと、選定した業務で実運用を始めることは、発注時に分けて考える必要がある。

Scaled Agile-Japanの中谷浩晃氏は、「組織・人材・業務プロセスの変革」が求められているとコメントしている。選定したテーマを実践へ移す際も、設計上の妥当性だけでは足りない。業務の責任者、利用できるデータ、測定するKPI、品質と利用のルール、着手を認める決定権がそろって初めて、担当チームは計画に沿って動ける。未決定の条件はアクションプランに明記しておくことが、計画策定後の判断を具体的にする。