DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。
本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。
また、本基準は絶対ではありません。誰かを攻撃したり、アセスメント結果の数字のみに注目して本質的な改善をおろそかにするためのものではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会のWG内で議論をおこないながら、適宜アップデートをしていくものです。
日本CTO協会 DX Criteria WGについて
ご紹介いただいたブログ記事
変更点
バージョン202012→202104の変更点
リモートワークについて
クライテリア一覧
チームに関するクライテリア
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-1-1 | チーム | チーム構成と権限委譲 | システムを開発する１チームの構成人数は、3人以上10人以下か。（ピザ2枚ルール） | メトリクスの計測 | |
TEAM-1-2 | チーム | チーム構成と権限委譲 | ある特定の人物に属人化した仕事を洗い出し、減らしていく仕組みがチームにあるか。 | 学習と改善 | |
TEAM-1-3 | チーム | チーム構成と権限委譲 | チームとチームメンバーの権限について、RACI図やデリゲーションポーカーなどによって、可視化され共有されているか。 | プラクティス | |
TEAM-1-4 | チーム | チーム構成と権限委譲 | チームは価値提供をするのに必要な全職能のメンバーで構成されているか。(フィーチャーチーム) | プラクティス | |
TEAM-1-5 | チーム | チーム構成と権限委譲 | チームおよびチームリーダーは、チームのミッションのために必要な外部のリソースを調達するための予算や権限をもっているか。 | プラクティス | |
TEAM-1-6 | チーム | チーム構成と権限委譲 | チームという単位は存在するが、メンバーのそれぞれのやっている仕事の内容をよく知らないし、代わりにやることもできない。 | アンチパターン | |
TEAM-1-7 | チーム | チーム構成と権限委譲 | チームリーダーが複数のチームやプロジェクトを兼務しており、自チームのためにすべての時間を使うことができない。 | アンチパターン | |
TEAM-1-8 | チーム | チーム構成と権限委譲 | チームリーダーがメンバーに権限委譲できておらず、ボトルネックになっている。 | アンチパターン |
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-2-1 | チーム | チームビルディング | チームは少なくとも半年以上継続して存在しているか。 | メトリクスの計測 | |
TEAM-2-2 | チーム | チームビルディング | チームは月に一度以上の頻度で仕事のふりかえりをおこなっており、その際にプロジェクト憲章またはインセプションデッキを見返して目的を再確認しているか。 | 学習と改善 | |
TEAM-2-3 | チーム | チームビルディング | インセプションデッキまたはプロジェクト憲章を作成し、チームの存在理由についてチーム全員が把握しているか。 | プラクティス | |
TEAM-2-4 | チーム | チームビルディング | 新しくチームに参画するメンバー用のオンボーディング・デック（チームの一員として働き始めるための、価値観・実務・スキル・相互理解のための明文化されたドキュメント集）が存在するか。 | プラクティス | |
TEAM-2-5 | チーム | チームビルディング | チームメンバー全員で定期的にカジュアルにコミュニケーションをとる場がある（ランチ、ディナー、レクレーション等） | プラクティス | |
TEAM-2-6 | チーム | チームビルディング | オンボーディングプログラムが、文章を読むだけのものになっており、ハンズオンやミッション理解の伴わない形骸化したものになっている。 | アンチパターン | |
TEAM-2-7 | チーム | チームビルディング | 1年以上チームのやることが変わっておらず、チームメンバーも固定されている。 | アンチパターン | |
TEAM-2-8 | チーム | チームビルディング | チーム内でチームミッションの改善に関係する議論がどんな理由であれ発生していない。 | アンチパターン |
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-3-1 | チーム | 心理的安全性 | チームメンバーの心理的安全性を測る指標があり、定期的に計測しているか。 | メトリクスの計測 | |
TEAM-3-2 | チーム | 心理的安全性 | 1on1や、落ち着いた場面でのカジュアルな雑談を含む直接業務に関わらないキャリアやタスクの壁打ちを、月に1度程度は実施しているか。 | 学習と改善 | |
TEAM-3-3 | チーム | 心理的安全性 | チームメンバーの行動/発言を明示的に承認行為をおこなう習慣があるか。（成果ではなく行動したこと自体に対して、拍手する・感謝を述べるなど） | プラクティス | |
TEAM-3-4 | チーム | 心理的安全性 | チームメンバー間で挨拶をしたり、雑談をする習慣はあるか。 | プラクティス | |
TEAM-3-5 | チーム | 心理的安全性 | チームの不安や不満などを可視化し、吸い上げるための仕組みを持っているか。 | プラクティス | |
TEAM-3-6 | チーム | 心理的安全性 | ミッションや共通のゴール設定をしないまま意見を集め、課題のためというよりも個人のための意見しか出てこない状況になっている。 | アンチパターン | |
TEAM-3-7 | チーム | 心理的安全性 | 心理的安全性を仲の良さと捉えて、事業のための意見ではなく、仲良くすることが目的化しているため、意見を封殺してしまう。 | アンチパターン | |
TEAM-3-8 | チーム | 心理的安全性 | 事業目標や納期目標に対して、威圧的なマネジメントや権威的な命令を繰り返したことで、意見が出てこない状況になっている。 | アンチパターン |
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-4-1 | チーム | タスクマネジメント | アイデアレベルの要望や構想から、要件に落ちるまでのリードタイムは計測されているか。 | メトリクスの計測 | |
TEAM-4-2 | チーム | タスクマネジメント | 仕事を始めるための定義と、完了するための定義はチームやステークホルダーで定期的に見直されているか。 | 学習と改善 | |
TEAM-4-3 | チーム | タスクマネジメント | 上長やステークホルダーを含め、共通のタスク管理ツールを利用しており、プロジェクトの状況を可視化したダッシュボードに常にアクセス可能か。 | プラクティス | |
TEAM-4-4 | チーム | タスクマネジメント | チームが仕事を始めるために必要な課題やタスクの粒度について、明文化されたフォーマットが存在するか。 | プラクティス | |
TEAM-4-5 | チーム | タスクマネジメント | チームのタスクに関して、「完成(完了)の定義(Definition of DONE)」が存在するか。 | プラクティス | |
TEAM-4-6 | チーム | タスクマネジメント | 他部署からの依頼が明確なタスクツールではなく、担当者へのダイレクトメール/メッセージ/口頭など透明性のない形で行われている。 | アンチパターン | |
TEAM-4-7 | チーム | タスクマネジメント | どのチームタスクであるかが曖昧なとき、ボールが落ちないようにするための仕組みや文化が存在しない。 | アンチパターン | |
TEAM-4-8 | チーム | タスクマネジメント | どのチームタスクであるか曖昧な仕事が発生したあとに、事後検証（ポストモーテム）が行われず都度話し合いで解決している。 | アンチパターン |
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-5-1 | チーム | 透明性ある目標管理 | １年後などのチームとプロダクトの目指す姿が、言語化され、いくつかの計測可能な指標により明晰化されているか。 | メトリクスの計測 | |
TEAM-5-2 | チーム | 透明性ある目標管理 | 仮説的な目標に対して、うまくいかなかった際にチームとして「学んだこと」を言語化・他チームへ公開・学習しているか。 | 学習と改善 | |
TEAM-5-3 | チーム | 透明性ある目標管理 | 四半期にフォーカスすべき目標が言語化され、いくつかの計測可能な指標によって明晰化されているか。 | プラクティス | |
TEAM-5-4 | チーム | 透明性ある目標管理 | フォーカスすべき目標に対して、どのようにアプローチするのかの計画をチームで共有しているか。 | プラクティス | |
TEAM-5-5 | チーム | 透明性ある目標管理 | ビジネス上、重要なマイルストーンとそのスケジュールをチームで常に共有し、その進捗を確認しているか。 | プラクティス | |
TEAM-5-6 | チーム | 透明性ある目標管理 | 目標管理が強く評価制度に結びついているため、ストレッチしたゴール設定をすることが難しくなっている。 | アンチパターン | |
TEAM-5-7 | チーム | 透明性ある目標管理 | 目標項目の一部に、その達成手段が健全に行われているかをチェックするための目標(健全化指標)を立てていない。 | アンチパターン | |
TEAM-5-8 | チーム | 透明性ある目標管理 | 目標が定量的でなく、第三者からみて達成度合いが不明確なものになっている。 | アンチパターン |
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-6-1 | チーム | 経験主義的な見積りと計画 | チームのベロシティを把握しており、その分散値の変化を計測しているか。 | メトリクスの計測 | |
TEAM-6-2 | チーム | 経験主義的な見積りと計画 | 見積りと実績の履歴を元に、見積りの精度を向上させるための方法について定期的な学習/ふりかえりを行なっているか。 | 学習と改善 | |
TEAM-6-3 | チーム | 経験主義的な見積りと計画 | 見積りは、実際にその仕事を行う本人を含むチームの複数人で行われているか。 | プラクティス | |
TEAM-6-4 | チーム | 経験主義的な見積りと計画 | スケジュールがクリティカルな場合には当初から精密に、仮説検証や価値がクリティカルな場合には荒い粒度から段階的に詳細化するなどして、状況に応じて見積りや計画の方法を変えているか。 | プラクティス | |
TEAM-6-5 | チーム | 経験主義的な見積りと計画 | 相対見積もりの基準となる要件（ユーザーストーリー）が存在し、定期的にアップデートしているか。 | プラクティス | |
TEAM-6-6 | チーム | 経験主義的な見積りと計画 | スケジュールのバッファ（緩衝期間）が全体計画に対して1/4以下しかもうけていない。 | アンチパターン | |
TEAM-6-7 | チーム | 経験主義的な見積りと計画 | 機能要件のバッファ(緩衝機能)を全体計画に対して設けられていない。(「必須な機能」と「あったらよい機能」が分類されず、曖昧になっている。) | アンチパターン | |
TEAM-6-8 | チーム | 経験主義的な見積りと計画 | 相対見積もりによって得られたベロシティの数値自体を、生産性の指標にしており、数値的なコミットメントや改善が要求されている。 | アンチパターン |
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-7-1 | チーム | ふりかえり習慣 | ふりかえりのテーマごとに数字を集めたり計測するなどして、ファクトベースで議論できるようにしているか。 | メトリクスの計測 | |
TEAM-7-2 | チーム | ふりかえり習慣 | チームのメンバーは、チームで合意した1カ月以内のサイクルでふりかえりを実施しているか。 | 学習と改善 | |
TEAM-7-3 | チーム | ふりかえり習慣 | ふりかえりの場はチーム全員が参加しているか。 | プラクティス | |
TEAM-7-4 | チーム | ふりかえり習慣 | ふりかえりはテーマを定め、議論を行い次回のふりかえりまでに実行可能なタスクが切り出されているか | プラクティス | |
TEAM-7-5 | チーム | ふりかえり習慣 | ふりかえりにおいて前回のふりかえりで改善するために起案したタスクが実行されたか検証しているか | プラクティス | |
TEAM-7-6 | チーム | ふりかえり習慣 | ふりかえりをしていたが、しばしば意見が出なかったため、ふりかえり自体をやめた。 | アンチパターン | |
TEAM-7-7 | チーム | ふりかえり習慣 | ふりかえるべきテーマに関しての、起きた出来事を時系列に事実関係を整理するなどの準備をせずにふりかえりをすすめている。 | アンチパターン | |
TEAM-7-8 | チーム | ふりかえり習慣 | ふりかえりに適切なファシリテーターがいない。 | アンチパターン |
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-8-1 | チーム | バリューストリーム最適化 | チームのリードタイム、フロー効率性および各工程のサイクルタイムを継続的に計測しているか。(またはエンジニアリングインテリジェンスのサービスを利用している) | メトリクスの計測 | |
TEAM-8-2 | チーム | バリューストリーム最適化 | チームのバリューストリームマッピングを作成し、繰り返しボトルネックを把握しながら自動化と学習を繰り返しているか。 | 学習と改善 | |
TEAM-8-3 | チーム | バリューストリーム最適化 | バリューストリーム改善のために、開発リソースの10%以上を継続的に確保しているか。 | プラクティス | |
TEAM-8-4 | チーム | バリューストリーム最適化 | 設定ファイルや一部のソースコードに対して、エンジニアでなくても必要に応じて修正のためのPull Request(Merge Request)を投げることがあるか。 | プラクティス | |
TEAM-8-5 | チーム | バリューストリーム最適化 | ペアプログラミング/モブプログラミングを実施しているか。 | プラクティス | |
TEAM-8-6 | チーム | バリューストリーム最適化 | 属人的なタスクがある状態を効率的だと解釈して改善をしない。 | アンチパターン | |
TEAM-8-7 | チーム | バリューストリーム最適化 | フロー効率性などの数値指標に囚われすぎて、全体の効率が悪化するなど価値提供に結びつかない状態である。 | アンチパターン | |
TEAM-8-8 | チーム | バリューストリーム最適化 | 数値改善のために簡単で予測可能な仕事ばかりを引き受け、難しめのタスクを引き受けない。 | アンチパターン |
システムに関するクライテリア
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
SYSTEM-1-1 | システム | バージョン管理 | バージョン管理システムの履歴情報(Code Churn)の分析をもとにバグ予測や品質上の問題を指摘するツールを導入し、継続的に改善しているか。 | メトリクスの計測 | |
SYSTEM-1-2 | システム | バージョン管理 | 明文化されたブランチ戦略が存在するか。そして、それは守られているか。 | 学習と改善 | |
SYSTEM-1-3 | システム | バージョン管理 | すべてのアプリケーションコードをGit/GitHubなどのバージョン管理システムで自社管理しているか。（権利を有する全てのソースコードについて、自社がアカウントを管理する統一のバージョン管理システムで扱っているか） | プラクティス | |
SYSTEM-1-4 | システム | バージョン管理 | インフラ構成とシステム要素のプロビジョニングをソースコードとして実行可能な形式にした上で、バージョン管理システムで管理しているか。（Infrastructure as Code） | プラクティス | |
SYSTEM-1-5 | システム | バージョン管理 | 統合テスト/デプロイメントの自動化に関わるソースコードをアプリケーションコードと同一のバージョン管理システムで管理しているか。 | プラクティス | |
SYSTEM-1-6 | システム | バージョン管理 | ソースコード自体のセキュリティレベルを高く設定しており、開発支援系SaaSの利用を禁止している。 | アンチパターン | |
SYSTEM-1-7 | システム | バージョン管理 | バージョン管理システムが複数存在していたり、１つのツールからすべての履歴を閲覧できないなど、中途半端な状態のままになっていないか。 | アンチパターン | |
SYSTEM-1-8 | システム | バージョン管理 | システムのソースコードの閲覧を関連するエンジニアのみに限定している。（別チームのエンジニアや他のステークホルダーが閲覧できない。） | アンチパターン |
データ駆動に関するクライテリア
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-8-1 | チーム | バリューストリーム最適化 | チームのリードタイム、フロー効率性および各工程のサイクルタイムを継続的に計測しているか。(またはエンジニアリングインテリジェンスのサービスを利用している) | メトリクスの計測 | |
TEAM-8-2 | チーム | バリューストリーム最適化 | チームのバリューストリームマッピングを作成し、繰り返しボトルネックを把握しながら自動化と学習を繰り返しているか。 | 学習と改善 | |
TEAM-8-3 | チーム | バリューストリーム最適化 | バリューストリーム改善のために、開発リソースの10%以上を継続的に確保しているか。 | プラクティス | |
TEAM-8-4 | チーム | バリューストリーム最適化 | 設定ファイルや一部のソースコードに対して、エンジニアでなくても必要に応じて修正のためのPull Request(Merge Request)を投げることがあるか。 | プラクティス | |
TEAM-8-5 | チーム | バリューストリーム最適化 | ペアプログラミング/モブプログラミングを実施しているか。 | プラクティス | |
TEAM-8-6 | チーム | バリューストリーム最適化 | 属人的なタスクがある状態を効率的だと解釈して改善をしない。 | アンチパターン | |
TEAM-8-7 | チーム | バリューストリーム最適化 | フロー効率性などの数値指標に囚われすぎて、全体の効率が悪化するなど価値提供に結びつかない状態である。 | アンチパターン | |
TEAM-8-8 | チーム | バリューストリーム最適化 | 数値改善のために簡単で予測可能な仕事ばかりを引き受け、難しめのタスクを引き受けない。 | アンチパターン |
デザイン思考に関するクライテリア
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-8-1 | チーム | バリューストリーム最適化 | チームのリードタイム、フロー効率性および各工程のサイクルタイムを継続的に計測しているか。(またはエンジニアリングインテリジェンスのサービスを利用している) | メトリクスの計測 | |
TEAM-8-2 | チーム | バリューストリーム最適化 | チームのバリューストリームマッピングを作成し、繰り返しボトルネックを把握しながら自動化と学習を繰り返しているか。 | 学習と改善 | |
TEAM-8-3 | チーム | バリューストリーム最適化 | バリューストリーム改善のために、開発リソースの10%以上を継続的に確保しているか。 | プラクティス | |
TEAM-8-4 | チーム | バリューストリーム最適化 | 設定ファイルや一部のソースコードに対して、エンジニアでなくても必要に応じて修正のためのPull Request(Merge Request)を投げることがあるか。 | プラクティス | |
TEAM-8-5 | チーム | バリューストリーム最適化 | ペアプログラミング/モブプログラミングを実施しているか。 | プラクティス | |
TEAM-8-6 | チーム | バリューストリーム最適化 | 属人的なタスクがある状態を効率的だと解釈して改善をしない。 | アンチパターン | |
TEAM-8-7 | チーム | バリューストリーム最適化 | フロー効率性などの数値指標に囚われすぎて、全体の効率が悪化するなど価値提供に結びつかない状態である。 | アンチパターン | |
TEAM-8-8 | チーム | バリューストリーム最適化 | 数値改善のために簡単で予測可能な仕事ばかりを引き受け、難しめのタスクを引き受けない。 | アンチパターン |
コーポレートに関するクライテリア
| Name | Theme | Type | Criterion | PointOfView | Check |
|---|---|---|---|---|---|
TEAM-8-1 | チーム | バリューストリーム最適化 | チームのリードタイム、フロー効率性および各工程のサイクルタイムを継続的に計測しているか。(またはエンジニアリングインテリジェンスのサービスを利用している) | メトリクスの計測 | |
TEAM-8-2 | チーム | バリューストリーム最適化 | チームのバリューストリームマッピングを作成し、繰り返しボトルネックを把握しながら自動化と学習を繰り返しているか。 | 学習と改善 | |
TEAM-8-3 | チーム | バリューストリーム最適化 | バリューストリーム改善のために、開発リソースの10%以上を継続的に確保しているか。 | プラクティス | |
TEAM-8-4 | チーム | バリューストリーム最適化 | 設定ファイルや一部のソースコードに対して、エンジニアでなくても必要に応じて修正のためのPull Request(Merge Request)を投げることがあるか。 | プラクティス | |
TEAM-8-5 | チーム | バリューストリーム最適化 | ペアプログラミング/モブプログラミングを実施しているか。 | プラクティス | |
TEAM-8-6 | チーム | バリューストリーム最適化 | 属人的なタスクがある状態を効率的だと解釈して改善をしない。 | アンチパターン | |
TEAM-8-7 | チーム | バリューストリーム最適化 | フロー効率性などの数値指標に囚われすぎて、全体の効率が悪化するなど価値提供に結びつかない状態である。 | アンチパターン | |
TEAM-8-8 | チーム | バリューストリーム最適化 | 数値改善のために簡単で予測可能な仕事ばかりを引き受け、難しめのタスクを引き受けない。 | アンチパターン |