【現場レポート】DX Criteria導入から1年でわかった課題と改善アプローチ完全公開！

DX Criteria

アジャイル

DX推進

佐々木隆弘

2025年08月19日

はじめに

メンバーズで技術支援チームで活動している佐々木です。

クライアント企業のDX支援を行う私たちですが、実は「自社のDX成熟度をどう把握し、改善していくか」についても日々模索しています。

その中で活用し始めたのが、「DX Criteria（ディーエックス・クライテリア）」というフレームワークです。

DX Criteriaとは、一般社団法人日本CTO協会が策定した、開発組織のDX（デジタルトランスフォーメーション）成熟度を多角的に評価するための指標群です。

技術基盤、チームの働き方、継続的改善の仕組みなど、複数の観点から組織の状態を可視化し、現状把握と改善活動の指針として活用されます。

本記事では、このDX Criteriaを開発チームに導入して約1年、私たちが実際に直面した課題や運用の工夫、改善のアプローチについて、現場のリアルな視点からご紹介します。

DX Criteria導入の背景と目的

まず、クライアントワークを行う開発チームの支援を進める中で、以下の課題を感じていました。

課題1：組織全体のDX成熟度の理解

開発チームごとに必要なケイパビリティがバラバラであり、組織全体のDX成熟度を客観的に把握できていませんでした。

課題2：改善計画と課題の相関性

各チームの強みや課題が見えても、改善の優先順位や具体的な行動計画との相関性が不明確でした。そのため、効果的な改善サイクルを回すことが困難な状況でした。

これらの課題を解決し、「変化に素早く適応し、継続的に改善していく組織の力」がどの程度あるのかを知りたいと感じていました。クライアントの変化に素早く対応し、価値ある仮説を立てて高速で検証する能力こそが、メンバーズの提供価値であると考えているためです。

この目的を達成するため、または、開発チームの状況把握、行動計画の推進に活用できないかと考え、私たちはDX Criteriaを開発チームの指標として活用し始めました。

導入時の試行錯誤：手探りから始まった学習の道のり

DX Criteriaの導入は、決してスムーズではありませんでした。「DX Criteriaの導入を決定したものの、その具体的な活用方法については、当初は手探りの状態でした」というのが正直なところでした。

導入当初、開発メンバーから以下のような意見が上がりました。

「DX Criteriaって何？どんな基準で評価するの？」
「また新しいタスクが増えるのか...」
「評価しても業務改善に繋がるのか疑問」
これらの課題に対して、私たちは段階的なアプローチを取りました。
📚 勉強会の継続実施：
定期的にDX Criteria勉強会を開催し、各カテゴリごとに実際の評価を行うワークショップを行いました。
💬 オープンな議論の場作り：
勉強会の中では、「なぜこの項目がはい（Yes）なのか？」「この判断基準は適切か？」といった疑問を自由に話し合える雰囲気を重視しました。評価の「正解」を求めるのではなく、チームの現状を正直に振り返ることの価値を伝えました。
🔄 小規模トライアルからスタート：
いきなり全チームではなく、意欲的な数チームから開始しました。その結果を元に目的を達成できそうか判断し、適用の範囲を広げていきました。
1年ほどの試行錯誤を経て、「DX Criteriaを完璧に理解してから始める」のではなく「使いながら学んでいく」というマインドセットが組織に定着しつつあります。この姿勢が、現在の継続的運用の基盤となっています。

実際の運用方法

1年間の試行錯誤を経て、現在は以下のステップで運用しています。

DX Criteriaのアセスメントシート（スプレッドシート形式）を各チームに配布
チーム内で議論し、自己評価記入（Yes/No/Yes but/No but形式）
- Yes：完全にできている（問題なく運用・実施できている）
- No：全くできていない（対応できていない、未着手）
- Yes but：一応できているが、前提や条件に依存している／改善の余地がある
- No but：まだできていないが、着手し始めている／改善に向けた動きがある
共有フォルダへのファイルアップロードでデータ回収
組織横断の技術支援チームによるヒアリングで評価の深掘り
隔週の勉強会で知見共有と評価基準のすり合わせ

実際のスコア分析結果を見ると、メトリクス（計測）の項目が全体的に低いことがわかりました。（参考: DX Criteria クライテリア一覧）また、評価をPoint of View別で分析したところ、プラクティス（実践）は高いが、メトリクス計測が弱いという特徴的なパターンが見えました。

強みと課題

数十のチームが参加した評価の結果、強みとなる部分と改善する必要がありそうな部分が見えてきました。

🟢 開発チームが共通してできている領域（強み）

タスクマネジメント：クライアントワークの特性上、顧客ニーズの把握やスコープ定義の意識が高いことが影響していると考えています。これはプロジェクト成功の基盤となっている私たちの強みと考えています。
ソースコードの明確さ：日常的なコードレビュー文化が深く浸透しており、高品質なコードベースが維持されていることが確認できました。

🔴 改善が必要と考えている領域

ふりかえり習慣：定期的に実施はしているものの、進行の形骸化や具体的な改善アクションに繋がりにくい状況が浮き彫りになりました。
継続的デプロイ：デプロイ頻度や成功率の目標設定・計測体制が十分でなく、開発サイクルのスピードアップに伸びしろがあることが分かりました。

見えてきた課題

このような発見がある一方で、DX Criteriaを継続的に運用していく中で、新たな課題も明らかになってきました。

Excel運用の限界：
想像を超える作業負荷がありました。数十以上のファイルを一つずつ手作業で収集・統合する必要があり、ファイル配布から回収、集約までのプロセス、バージョン管理、評価時の入力項目の多さ、さらには手作業による転記ミスやフォーマットの違いによるデータ品質の問題も発生していました。
評価基準の理解格差と動機付けの問題：
同じ項目でもチーム間で解釈が分かれるケースが頻発しました。「Yes but」と「No but」の境界線が曖昧であったり、技術的な項目における前提知識の差があったり、チーム間での評価基準統一に課題がありました。さらに、アセスメント実施による開発チームの具体的効果の実感が薄く、評価結果から実際の改善アクションが取りづらいなど、メリット訴求と動機付けにも課題がありました。多くのチームから「評価はしたけれど、その後どう活用すれば良いか分からない」という声が上がっており、評価後の活用方法が不明確になっていました。
継続的運用における構造的問題：
PDCAサイクル確立の障壁（定期実施の仕組み化、改善効果の長期追跡、評価結果から次回評価までの改善活動の体系化、DX Criteriaスコア向上と実際のビジネス成果の関連性検証）や、組織横断的展開の複雑性（技術領域の多様性、チーム成熟度格差、プロジェクト特性）がありました。画一的な評価基準の適用だけでなく、各チームの特性に応じたカスタマイズと、組織全体での比較方法のバランスを取ることが重要な課題となっています。
スケーラビリティの問題：
チーム数増加に伴う運用負荷の指数的増加が予想されるため、現在の手作業中心の運用では限界があることが明確になりました。