💡

DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。また、本基準は絶対ではありません。誰かを攻撃したり、アセスメント結果の数字のみに注目して本質的な改善をおろそかにするためのものではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会のWG内で議論をおこないながら、適宜アップデートをしていくものです。

ビジョンとポリシー

🛄

1. DX Criteria 策定の目的とビジョン

ご紹介

導入ガイド

👀

DX Criteriaの使い方_

👀

How to use DX Criteria in English

5つのテーマ

日本CTO協会 DX Criteria WGについて

🗒️

ご紹介いただいたブログ記事

変更点

バージョン202012→202104の変更点

🎧

リモートワークについて

クライテリア一覧

Name	Theme	PointOfView	Type	Criterion
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	チーム	アンチパターン	チーム構成と権限委譲	チームリーダーがメンバーに権限委譲できておらず、ボトルネックになっている。
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	チーム	アンチパターン	チームビルディング	チーム内でチームミッションの改善に関係する議論がどんな理由であれ発生していない。
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	チーム	アンチパターン	心理的安全性	事業目標や納期目標に対して、威圧的なマネジメントや権威的な命令を繰り返したことで、意見が出てこない状況になっている。
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
TEAM-5-1
TEAM-5-2	チーム	学習と改善	透明性ある目標管理	仮説的な目標に対して、うまくいかなかった際にチームとして「学んだこと」を言語化・他チームへ公開・学習しているか。
TEAM-5-3	チーム	プラクティス	透明性ある目標管理	四半期にフォーカスすべき目標が言語化され、いくつかの計測可能な指標によって明晰化されているか。
TEAM-5-4	チーム	プラクティス	透明性ある目標管理	フォーカスすべき目標に対して、どのようにアプローチするのかの計画をチームで共有しているか。
TEAM-5-5	チーム	プラクティス	透明性ある目標管理	ビジネス上、重要なマイルストーンとそのスケジュールをチームで常に共有し、その進捗を確認しているか。
TEAM-5-6	チーム	アンチパターン	透明性ある目標管理	目標管理が強く評価制度に結びついているため、ストレッチしたゴール設定をすることが難しくなっている。
TEAM-5-7	チーム	アンチパターン	透明性ある目標管理	目標項目の一部に、その達成手段が健全に行われているかをチェックするための目標(健全化指標)を立てていない。
TEAM-5-8	チーム	アンチパターン	透明性ある目標管理	目標が定量的でなく、第三者からみて達成度合いが不明確なものになっている。
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	チーム	アンチパターン	経験主義的な見積りと計画	相対見積もりによって得られたベロシティの数値自体を、生産性の指標にしており、数値的なコミットメントや改善が要求されている。
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	チーム	アンチパターン	ふりかえり習慣	ふりかえりに適切なファシリテーターがいない。
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	チーム	アンチパターン	バリューストリーム最適化	数値改善のために簡単で予測可能な仕事ばかりを引き受け、難しめのタスクを引き受けない。
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	システム	アンチパターン	バージョン管理	システムのソースコードの閲覧を関連するエンジニアのみに限定している。（別チームのエンジニアや他のステークホルダーが閲覧できない。）
SYSTEM-2-1	システム	メトリクスの計測	ソースコードの明確さ	アプリケーションコードの循環的複雑度などのメトリクスを、ツール/サービスを用いて継続的に計測しているか。
SYSTEM-2-2	システム	学習と改善	ソースコードの明確さ	デッドコードを四半期以上のサイクルで定期的に棚卸しし、削除や分解をしているか。
SYSTEM-2-3	システム	プラクティス	ソースコードの明確さ	コードレビューをする習慣や規則があり、本番用ブランチ(master / mainなど)へのマージはコードレビューを必須としているか。
SYSTEM-2-4	システム	プラクティス	ソースコードの明確さ	明文化されているコードレビューガイドラインが存在するか。
SYSTEM-2-5	システム	プラクティス	ソースコードの明確さ	コードレビューガイドラインを満たさないコードを自動的に検出・補正する各種Linterやフォーマッタなどのツール群を整備しており、ソースコードを変更する誰もが使うことができるか。
SYSTEM-2-6	システム	アンチパターン	ソースコードの明確さ	コードレビューをできる人物がチームの中におらず、レビュー待ちに1、2営業日がかかる。
SYSTEM-2-7	システム	アンチパターン	ソースコードの明確さ	コードレビューガイドラインは１年以上メンテナンスされておらず、形骸化している。
SYSTEM-2-8	システム	アンチパターン	ソースコードの明確さ	コードレビューガイドラインの多くの項目が、自動的なフォーマッタなどで統一・解決可能な些末な事柄である。
SYSTEM-3-1	システム	メトリクスの計測	継続的インテグレーション	すべてのインテグレーションテストにかかる時間が計測されており、それは30分以内に完了するか。
SYSTEM-3-2	システム	学習と改善	継続的インテグレーション	テストカバレッジ基準や自動テストガイドラインを用意し、これらを継続的に改善するための工数がチームで割かれているか。
SYSTEM-3-3	システム	プラクティス	継続的インテグレーション	プロダクトの半分以上のモジュール/クラスファイルに対して、ユニットテストが存在しているか。
SYSTEM-3-4	システム	プラクティス	継続的インテグレーション	テスト用データやスタブ/モックなどを整備し、テストを書きやすくするための環境整備をしているか。
SYSTEM-3-5	システム	プラクティス	継続的インテグレーション	継続的インテグレーション環境が存在し、開発者は開発ブランチの全テストをリソース調整することなく、自由に行うことができるか。
SYSTEM-3-6	システム	アンチパターン	継続的インテグレーション	一部の人だけがテストを書き、一部の人はテストを書かないといったように自動テストを個々人の努力目標などになっている。
SYSTEM-3-7	システム	アンチパターン	継続的インテグレーション	テスト自体が複雑になって、長期間メンテナンスされていない。
SYSTEM-3-8	システム	アンチパターン	継続的インテグレーション	自動テストが失敗したまま、そのコードが本番デプロイされることを許容している。
SYSTEM-4-1	システム	メトリクスの計測	継続的デプロイ	デプロイ頻度とデプロイ成功率を継続的に測定しており、これらを改善することを目標管理しているか。
SYSTEM-4-2	システム	学習と改善	継続的デプロイ	デプロイ時に社内のユーザーや開発者のみを対象もしくは、一部のサーバのみにサービスをリリースしてエラーがないかを確かめるカナリアリリースができるか。
SYSTEM-4-3	システム	プラクティス	継続的デプロイ	デプロイ完了時、および構成変更時にインフラ構成に関する自動的なテスト(e2eのスモークテストおよびServerspecなどのインフラ環境テスト)を実行しているか。
SYSTEM-4-4	システム	プラクティス	継続的デプロイ	ブルーグリーンデプロイメントができるか。（稼働中のサーバーを切り替えるのではなく、別環境にデプロイ作業をしてから本番の向き先を切り替えるデプロイ手法。）
SYSTEM-4-5	システム	プラクティス	継続的デプロイ	デプロイ作業を伴わず、一部の機能を安全にオフにしたり、オンにしたりできるか。( Feature Toggle /Soft Launch/ Dark launchなどの仕組みを導入・実装しているか。)
SYSTEM-4-6	システム	アンチパターン	継続的デプロイ	デプロイされたコードに問題が発生した際に、前のバージョンへの切り戻しを意思決定してから5分以内に切り戻すことができない。
SYSTEM-4-7	システム	アンチパターン	継続的デプロイ	開発者のメンバー自身が、権限を持つ人物の承認があっても、自分のコードを本番環境にデプロイできない。
SYSTEM-4-8	システム	アンチパターン	継続的デプロイ	デプロイ工程が自動化されておらず、本番反映に1時間以上かかっていたり、特定の時間帯しかできないなどの制約事項がかかっている。
SYSTEM-5-1	システム	メトリクスの計測	API駆動開発	社内外のAPIの利用者にとってのユーザビリティについてヒアリング/アンケートを行い継続的な改善が行われているか。
SYSTEM-5-2	システム	学習と改善	API駆動開発	各APIについて、動作するインタラクティブなドキュメントや管理サービスを持っているか。
SYSTEM-5-3	システム	プラクティス	API駆動開発	プロダクトに対して外部あるいは内部の別のシステムと連携するためのAPIが提供されているか。
SYSTEM-5-4	システム	プラクティス	API駆動開発	APIは何らかのSchema定義言語によって規定され、そこから自動的にクライアントの生成やバリデータの生成が行われているか。
SYSTEM-5-5	システム	プラクティス	API駆動開発	APIに関わる要件は、SDD(スキーマ駆動開発)で開発され、直ちにモックアップサーバーが提供できるか。
SYSTEM-5-6	システム	アンチパターン	API駆動開発	ViewやControllerの層に処理が集中しており、機能をAPIに切り出すことが困難な設計になっている。
SYSTEM-5-7	システム	アンチパターン	API駆動開発	各APIに対して、ネットワークを経由したE2E(ステージング・本番どちらに対するE2Eテストかは問わない)のテストが存在しておらず、死活監視ができていない。
SYSTEM-5-8	システム	アンチパターン	API駆動開発	APIがバージョン管理されておらず、破壊的な変更が利用者から検知できない。
SYSTEM-6-1	システム	メトリクスの計測	疎結合アーキテクチャ	目指すべきアーキテクチャに対してそぐわない点を洗い出すための仕組みが存在しており、それらの情報をもとに改善を進めているか。（アーキテクチャ適応度関数）
SYSTEM-6-2	システム	学習と改善	疎結合アーキテクチャ	システムアーキテクチャの決定・変更・改善に関するドキュメントを管理し継続的な学習機会を設けているか。
SYSTEM-6-3	システム	プラクティス	疎結合アーキテクチャ	ドメインイベントの発火に伴いPublish/Subscribeモデルを利用した仕組みで、関連サービスとの連携が可能か。またその履歴データが保存管理され、これらのイベントリプレイから再突合や監査の自動化が可能か。
SYSTEM-6-4	システム	プラクティス	疎結合アーキテクチャ	結果整合性を考慮したサービスレベルの合意が要件のガイドラインの中に組み込まれているか。
SYSTEM-6-5
SYSTEM-6-6	システム	アンチパターン	疎結合アーキテクチャ	１つのデータベースに対して複数のシステムからの直接的な参照または書き込みがなされていて、それらの依存性が簡単には追跡できない状況になっている。
SYSTEM-6-7	システム	アンチパターン	疎結合アーキテクチャ	疎結合なシステムであるが、分散トレーシングの仕組みがなく、問題発生時の原因特定に時間がかかる。
SYSTEM-6-8	システム	アンチパターン	疎結合アーキテクチャ	自動テストとスキーマ定義の存在しない外部システムとの依存関係が１０ケース以上存在しており、機能開発の影響範囲を特定できない。
SYSTEM-7-1	システム	メトリクスの計測	システムモニタリング	SLI/SLO/エラーバジェットがビジネスオーナーとエンジニアが協議して合意の上設定され、計測されているか。
SYSTEM-7-2	システム	学習と改善	システムモニタリング	開発と SRE が共有する障害報告リストがあり、それぞれに有効な再発防止の仕組みが整うようにリソースを割いているか。
SYSTEM-7-3	システム	プラクティス	システムモニタリング	APMのためのSaaSやツールが導入され、ユーザーからみた応答速度などについて、要因ごとの影響度を定常的に分析できる状態になっているか。
SYSTEM-7-4	システム	プラクティス	システムモニタリング	フォルトインジェクションテストや、カオスエンジニアリング等の仕組みを導入することで、重大事故につながりうるシステムの欠陥を早期に発見するための試みをおこなっているか。
SYSTEM-7-5	システム	プラクティス	システムモニタリング	オートスケールなどの仕組みにより、開発者やSREが介在しなくても、適切なキャパシティコントロールができているか。
SYSTEM-7-6	システム	アンチパターン	システムモニタリング	障害の発生に対しての罰則や謝罪などの、開発者が萎縮したり障害を隠蔽する方向につながるような慣習が存在する。
SYSTEM-7-7	システム	アンチパターン	システムモニタリング	定常的に発生しているサービス上の警告を問題ないものとして無視したり、ログ自体を出さないようにしている。
SYSTEM-7-8	システム	アンチパターン	システムモニタリング	システム構成要素の構築方法や運用方法が属人化しており、同じインスタンスを構築できない。
SYSTEM-8-1	システム	メトリクスの計測	セキュリティシフトレフト	CI/CDのパイプラインにソースコードの自動的なセキュリティチェック（静的解析または動的解析）が組み込まれていて、一定の基準を達さないとリリースされない仕組みになっているか。
SYSTEM-8-2	システム	学習と改善	セキュリティシフトレフト	セキュアコーディングについて、開発者を対象とした教育カリキュラムや研修を実施しているか。
SYSTEM-8-3	システム	プラクティス	セキュリティシフトレフト	専門的なアプリケーションセキュリティの知識を持つメンバーが、専任でセキュリティチームにおり、動向や最新情報をもとに自社サービスをレビュー・改善できているか。
SYSTEM-8-4	システム	プラクティス	セキュリティシフトレフト	OSSのライブラリやミドルウェアを使用する際、それらの脆弱性情報を自動的モニタリング・警告・パッチ適用するための仕組みまたはサービス等を利用しているか。
SYSTEM-8-5	システム	プラクティス	セキュリティシフトレフト	4半期から1年の間で定期的に、全体的なアプリケーションとインフラの脆弱性診断を受けているか。
SYSTEM-8-6	システム	アンチパターン	セキュリティシフトレフト	開発速度（デプロイ頻度）を低下させるようなセキュリティルールが、施行されていて現況に合わせたアップデートが行われていない。
SYSTEM-8-7	システム	アンチパターン	セキュリティシフトレフト	ソースコード中に、漏洩してはならない情報がハードコーディングされている。（それらを分離して管理するようなツールまたは仕組みを導入しているか）
SYSTEM-8-8	システム	アンチパターン	セキュリティシフトレフト	開発企画要件の段階で、設計レベルのセキュリティレビューが実施されていない。(Security by Designの未実施)
DATA-1-1	データ駆動	メトリクスの計測	顧客接点のデジタル化	顧客の行動履歴データを分析可能な形で保存しており、その割合が顧客全体の7割を超えているか。
DATA-1-2	データ駆動	学習と改善	顧客接点のデジタル化	オンライン・オフラインの両方で、顧客の接点となる行動情報や通知の手段を獲得するためのシステムを開発している組織が社内に存在するか。
DATA-1-3	データ駆動	プラクティス	顧客接点のデジタル化	オンライン上で、顧客は自社のサービスを契約したり購入したりできるか。
DATA-1-4	データ駆動	プラクティス	顧客接点のデジタル化	自社サービスやメディアをスマートフォン用のWebサイトまたはアプリとして提供しているか。
DATA-1-5	データ駆動	プラクティス	顧客接点のデジタル化	潜在顧客獲得のために自社メディアやSNSを通じたエンゲージメント活動をしているか。
DATA-1-6	データ駆動	アンチパターン	顧客接点のデジタル化	デジタル上でのプッシュマーケティングをEmailのみに頼っている。
DATA-1-7	データ駆動	アンチパターン	顧客接点のデジタル化	自社のリアルな顧客接点からのデータ収集が技術的な課題・社内ルール・オペレーションの問題でできていないままになっている。
DATA-1-8	データ駆動	アンチパターン	顧客接点のデジタル化	顧客接点のサービス開発がうまく機能していないため、改善の速度やデータの取得が遅延している。
DATA-2-1
DATA-2-2	データ駆動	学習と改善	事業活動データの収集	事業活動の中に潜在的に存在したが、蓄積できていなかったデータを収集するためのシステム化や業務分析を行うチームは存在するか。
DATA-2-3
DATA-2-4	データ駆動	プラクティス	事業活動データの収集	POSや業務システム上のアクセス記録/操作履歴を構造化されたフォーマットでリアルタイムにデータレイクへ保存しているか。
DATA-2-5	データ駆動	プラクティス	事業活動データの収集	音声・動画・文章といった従来構造化できなかったデータソースも事業利活用のために収集しているか。
DATA-2-6	データ駆動	アンチパターン	事業活動データの収集	データ収集プロジェクトが依頼しているデータ入力業務が現場で実施されていない。
DATA-2-7	データ駆動	アンチパターン	事業活動データの収集	データの活用に関して責任のあるポジションを設置していない。
DATA-2-8	データ駆動	アンチパターン	事業活動データの収集	データ収集に関するプロジェクトが存在しないか、進捗していない。
DATA-3-1	データ駆動	メトリクスの計測	データ蓄積・分析基盤	データ分析の基盤実際に操作して数字を取得できる社内の人数と部署数を増やしていくための活動をしているか。
DATA-3-2
DATA-3-3	データ駆動	プラクティス	データ蓄積・分析基盤	ユーザー理解や仮説検証のためのデータ分析のための環境が整備されており、データサイエンティストだけでなくエンジニア・非エンジニアを問わず、プロダクトのステークホルダーに公開されているか。
DATA-3-4	データ駆動	プラクティス	データ蓄積・分析基盤	イベントストリーム処理の基盤を用いてオンライン情報を利用した分析・サービスでの活用をおこなっているか。
DATA-3-5	データ駆動	プラクティス	データ蓄積・分析基盤	データ分析において、個人情報をマスキングする機構が存在しているか。
DATA-3-6	データ駆動	アンチパターン	データ蓄積・分析基盤	事業システムのデータベースに直接アクセスして、分析用の処理を走らせている。
DATA-3-7	データ駆動	アンチパターン	データ蓄積・分析基盤	統一されたデータレイクが存在せず、分析基盤ごとにデータを管理している。
DATA-3-8	データ駆動	アンチパターン	データ蓄積・分析基盤	利用中の外部サービスにリアルタイムなデータ連携するための機構が存在しない。
DATA-4-1	データ駆動	メトリクスの計測	データ処理パイプライン	分析・開発や運用のバリューストリーム上の各種サイクルタイムを計測しており、継続的に改善しているか。
DATA-4-2	データ駆動	学習と改善	データ処理パイプライン	データレイクから、モデルの実サービス適用までの一連の流れのパフォーマンスモニタ・自動化・効率化を行うエンジニアリングチームが存在するか。
DATA-4-3
DATA-4-4	データ駆動	プラクティス	データ処理パイプライン	実運用されているデータ分析・学習のための前処理や学習処理を実行するためのワークフロー処理基盤(ETLの一貫性・冪等性・可用性を確保するための基盤)が存在するか。
DATA-4-5	データ駆動	プラクティス	データ処理パイプライン	学習済みのモデルを検証し、サービスインするまでの処理は自動化されているか。
DATA-4-6	データ駆動	アンチパターン	データ処理パイプライン	週次集計や月次集計の処理が特定の日時に終わることを想定しており、障害が発生した場合にデータが欠損してしまう。
DATA-4-7	データ駆動	アンチパターン	データ処理パイプライン	実験時の環境を実サービス環境に向けてポータブルにするためのコンテナ化やIaC(Infrastructure as Code)が存在しない。
DATA-4-8	データ駆動	アンチパターン	データ処理パイプライン	データサイエンス/機械学習/データアプリケーションエンジニアリング/クラウドインフラなどの知見が１名に属人化している。
DATA-5-1	データ駆動	メトリクスの計測	データ可視化とリテラシー	プロダクトの主要情報のダッシュボードが、常に表示された共用のモニターをチームの座席近辺に配置しているか。リモートワークでは、アクセスしやすい場所にダッシュボードが掲示されているか。
DATA-5-2	データ駆動	学習と改善	データ可視化とリテラシー	意思決定者は、データの読み取り方や統計の基本的な知識について研修トレーニングを受けているか。
DATA-5-3	データ駆動	プラクティス	データ可視化とリテラシー	売上などの短期的数値ではなく、長期的な事業価値のための間接的指標（e.g.顧客リピート率や予測LTVなど)を主要なKPIとして設定しているか。
DATA-5-4
DATA-5-5	データ駆動	プラクティス	データ可視化とリテラシー	データから得られた推論や仮説が間違っている場合にどのようなデータによって検証可能かをもとにデータ収集や分析が行われているか。
DATA-5-6	データ駆動	アンチパターン	データ可視化とリテラシー	要望ベースでデータの集計を繰り返し、雑多なレポーティング項目が棚卸しされていない。
DATA-5-7	データ駆動	アンチパターン	データ可視化とリテラシー	簡単なデータ集計であっても、エンジニアを経由しなければ取得できない。
DATA-5-8	データ駆動	アンチパターン	データ可視化とリテラシー	ダッシュボードは存在するが、データ担当者以外誰も見ておらず形骸化している。
DATA-6-1	データ駆動	メトリクスの計測	機械学習プロジェクト管理	機械学習プロジェクトの具体的な成功指標を持ち、構築したシステムがそれを満たしているかモニタリングしているか。
DATA-6-2	データ駆動	学習と改善	機械学習プロジェクト管理	機械学習の知見を、アプリケーション開発者や非エンジニアのスタッフが利用できるように勉強会などを繰り返し開いているか。
DATA-6-3	データ駆動	プラクティス	機械学習プロジェクト管理	継続的再学習のためのモニタリングと、自動的なモデルのアップデート等の効率的な保守を実現するための仕組みを導入しているか。
DATA-6-4	データ駆動	プラクティス	機械学習プロジェクト管理	実運用時の計算量や計算資源の種別（IoT/エッジ利用/クラウド）などを考慮に入れた上で、モデル選定や実験のプロセスが動いているか。
DATA-6-5
DATA-6-6	データ駆動	アンチパターン	機械学習プロジェクト管理	機械学習チームと事業担当者との間で、事業理解や背景・目的の共有などの時間を十分に設けていない。
DATA-6-7	データ駆動	アンチパターン	機械学習プロジェクト管理	すでに実績のあるクラウドを利用した機械学習ソリューションに対して、検証ができていない。
DATA-6-8	データ駆動	アンチパターン	機械学習プロジェクト管理	機械学習プロジェクトのPoCから実運用するためのエンジニアリング能力をチームが持っておらず、そこから実サービス化が進まない。
DATA-7-1	データ駆動	メトリクスの計測	マーケティング自動化	マーケティングのオペレーションの業務の割合と企画・戦略の業務割合を棚卸しして、自動化・最適化のためのリソースを割いているか。
DATA-7-2	データ駆動	学習と改善	マーケティング自動化	インハウスのマーケティングチームに自動化や分析を行うエンジニアがおり、指標や自動化をともに進めているか。
DATA-7-3
DATA-7-4	データ駆動	プラクティス	マーケティング自動化	媒体ごとの適切なクリエイティブになるようにA/Bテストやバンディッドアルゴリズムなどで最適化しているか。
DATA-7-5	データ駆動	プラクティス	マーケティング自動化	各施策ごとに獲得した顧客がその後のどのような購買行動/利用行動ができたかをコーホート分析しているか。
DATA-7-6	データ駆動	アンチパターン	マーケティング自動化	獲得した顧客に対して、一括配信などの画一的な通達を行っており、投資効果の最適化を実施していない。
DATA-7-7	データ駆動	アンチパターン	マーケティング自動化	顧客獲得に対して、一時的な獲得総数のみを目標としており、継続的な利用について調査していない。
DATA-7-8	データ駆動	アンチパターン	マーケティング自動化	広告運用の成果報告がフォーマットに沿って自動的に行えるようになっていない。
DATA-8-1	データ駆動	メトリクスの計測	自動的な意思決定	自動化が進捗するために、判断基準が明確な目標を掲げているか。
DATA-8-2	データ駆動	学習と改善	自動的な意思決定	意思決定や業務を自動化していくために、業務プロセスを改善するためのソフトウェアエンジニアを含むチームが存在するか。
DATA-8-3	データ駆動	プラクティス	自動的な意思決定	意思決定に関する記録を、プロセスマイニングができる形で保存しているか。
DATA-8-4	データ駆動	プラクティス	自動的な意思決定	意思決定理由について、明確な根拠やガイドラインを作る時間をマネジメントは割いているか。また、ガイドラインの中に倫理規範は含まれているか。
DATA-8-5	データ駆動	プラクティス	自動的な意思決定	ビジネスプロセスやミーティングを棚卸しし、不要なもの・従来の用途から離れてしまったものを停止・削除しているか。
DATA-8-6	データ駆動	アンチパターン	自動的な意思決定	ビジネスプロセス全体のボトルネックを計測せずに自動化・効率化を各部門に任せてしまう。
DATA-8-7	データ駆動	アンチパターン	自動的な意思決定	業務自動化全体のアーキテクチャ設計を行わず、部署個別にRPAなどの自動化ツールを導入する。
DATA-8-8	データ駆動	アンチパターン	自動的な意思決定	自動化ツールを前提とした組織設計をおこなわず、既存の業務や組織にあわせてツールをカスタマイズする。
DESIGN-1-1	デザイン思考	メトリクスの計測	ペルソナの設定	少なくとも１つの大きな事業仮説に対して、対応する１つ以上のペルソナが作成されているか。
DESIGN-1-2	デザイン思考	学習と改善	ペルソナの設定	事業、製品のペルソナについて、データや仮説検証で学習したことを受けて定期的に見直しているか。
DESIGN-1-3	デザイン思考	プラクティス	ペルソナの設定	ペルソナを記述した資料は、施策会議のたびに意識され、参照されているか。
DESIGN-1-4	デザイン思考	プラクティス	ペルソナの設定	ペルソナについて、チームで繰り返し議論されイメージの共有化をしているか。
DESIGN-1-5	デザイン思考	プラクティス	ペルソナの設定	B2Bなど顧客における関係者が複数人いる場合、購買プロセスの各担当者など、意思決定に関わる人物の数だけ必要なペルソナを作っているか。
DESIGN-1-6	デザイン思考	アンチパターン	ペルソナの設定	ペルソナの具体的なライフストーリーが欠如しており、仮説構築につながらない。
DESIGN-1-7	デザイン思考	アンチパターン	ペルソナの設定	過剰に属性情報が肉付けされていて、チームのメンバーが同じユーザー像を想像しづらいペルソナになっている。
DESIGN-1-8	デザイン思考	アンチパターン	ペルソナの設定	ユーザーインタビュー/ユーザー調査なしに勝手なイメージでペルソナを作っている。
DESIGN-2-1	デザイン思考	メトリクスの計測	顧客体験	顧客に対してNPS（ネットプロモータースコア）や満足度を継続的に測定しているか。
DESIGN-2-2	デザイン思考	学習と改善	顧客体験	顧客による問い合わせから返信までのリードタイム、問い合わせおよび回答への満足度について定量計測を行い、目標管理をしているか。
DESIGN-2-3	デザイン思考	プラクティス	顧客体験	構造化されたヘルプページがあり、ヘルプに書かれた内容を改善するために顧客がフィードバックできるか。
DESIGN-2-4	デザイン思考	プラクティス	顧客体験	CRM(顧客管理システム)、SFA(営業支援システム)を導入しており、お問い合わせや行動履歴を把握できているか。
DESIGN-2-5	デザイン思考	プラクティス	顧客体験	顧客が価値を感じるまでの感情的な動きやチャネルを分析したカスタマージャーニーマップを作成しているか。
DESIGN-2-6	デザイン思考	アンチパターン	顧客体験	カスタマーサポートなど顧客接点となるスタッフから、課題の吸い上げができていない。
DESIGN-2-7	デザイン思考	アンチパターン	顧客体験	電話やメールでの対応に対して、柔軟な対応をしすぎてしまい自動化の阻害要因になっている。
DESIGN-2-8	デザイン思考	アンチパターン	顧客体験	顧客体験の向上のための担当エンジニアリングチームが存在せず、システム化や自動化による改善ができていない。
DESIGN-3-1	デザイン思考	メトリクスの計測	ユーザーインタビュー	ユーザーインタビューによって見つけた課題に対してどの機能がリリースされているのかが記録されており、その効果も測定されている。
DESIGN-3-2	デザイン思考	学習と改善	ユーザーインタビュー	直近、半年以内になんらかのユーザーインタビューを行っているか。
DESIGN-3-3	デザイン思考	プラクティス	ユーザーインタビュー	ユーザーインタビューの実施のための稟議やフローは軽量で、一ヶ月以内に行うことができるか。
DESIGN-3-4	デザイン思考	プラクティス	ユーザーインタビュー	インタビュー結果のインサイトをまとめて、共感マップなどを作成しているか。
DESIGN-3-5	デザイン思考	プラクティス	ユーザーインタビュー	インタビュー参加者が話しやすい雰囲気作りのための工夫がインタビュースクリプトに組み込まれている。
DESIGN-3-6	デザイン思考	アンチパターン	ユーザーインタビュー	ユーザーインタビューに関して訓練を受けていないスタッフが実施しており、仮説に対して誘導的すぎたり、クローズドクエッションが多くなったりしている。
DESIGN-3-7	デザイン思考	アンチパターン	ユーザーインタビュー	インタビュー結果が具体的な次の一手（異なる仮説の構築や、具体的な機能反映）につながらずに実施したまま放置されている。
DESIGN-3-8	デザイン思考	アンチパターン	ユーザーインタビュー	仮説をもたずにインタビューを設計しており、インタビューイの要望をそのまま拾い上げたり、サンプルの少ないインタビュー結果をそのままセグメント全体問題としてとらえてしまっている。
DESIGN-4-1
DESIGN-4-2	デザイン思考	学習と改善	デザインシステムの管理	利用頻度の高いコンポーネント等をまとめたデザインシステムを構築し、継続的に棚卸するなど陳腐化することなく改善できているか。
DESIGN-4-3	デザイン思考	プラクティス	デザインシステムの管理	プロダクトに関わるUIパーツは、動作するライブラリとしてまとめられているか。
DESIGN-4-4	デザイン思考	プラクティス	デザインシステムの管理	UIデザイナーが作成したデザインをソースコードに自動的に反映するためにツールを利用しているか。
DESIGN-4-5	デザイン思考	プラクティス	デザインシステムの管理	プロダクトに関わるUIパーツには、OOUIなどの抽象的な情報設計に基づいた共通のポリシーがあり、それらがドキュメント化されているか。
DESIGN-4-6	デザイン思考	アンチパターン	デザインシステムの管理	フロントエンド開発とバックエンドが密結合しており、APIモックサーバーなどを用いて、バックエンド開発と並行して開発をすすめることができない。
DESIGN-4-7	デザイン思考	アンチパターン	デザインシステムの管理	各プラットフォーム（iOS/Android/Web）などで過度に統一の体験を設計しようとしすぎてしまい、それぞれの流儀にそぐわないUIとなってしまっている。
DESIGN-4-8	デザイン思考	アンチパターン	デザインシステムの管理	各画面やパーツごとに組み込まれた細やかなアニメーションや音、振動、トランジションといった動きのあるUI要素がガイドラインに組み込まれていない。
DESIGN-5-1	デザイン思考	メトリクスの計測	デザイン組織	事業に必要なUI/UXデザインの過半数を内製化できているか。
DESIGN-5-2	デザイン思考	学習と改善	デザイン組織	デザイン組織のリーダーは、自社戦略に必要なデザイナーの人事戦略を自ら立案しており、採用・育成についての権限と責任を負っているか。
DESIGN-5-3	デザイン思考	プラクティス	デザイン組織	全社のクリエイティブや顧客体験デザインを担う専門知識を持った経営幹部がいるか。
DESIGN-5-4	デザイン思考	プラクティス	デザイン組織	内製のデザイン組織を持ち、ガイドラインなどを用いて、内製化すべきことと外部の専門家集団を活用することを明確にしているか。
DESIGN-5-5	デザイン思考	プラクティス	デザイン組織	事業責任者は顧客体験やデザイン思考のトレーニングを受けているか。
DESIGN-5-6	デザイン思考	アンチパターン	デザイン組織	デザイナーがプロジェクトを横断して派遣され、兼務が多くなったり関わる期間が短くなるため、各プロダクトにおけるユーザーへの共感や事業価値の理解が弱くなっている。
DESIGN-5-7	デザイン思考	アンチパターン	デザイン組織	個別のプロダクトや事業チームごとに専任で配置されるのみとなっており、デザイナーとしてのキャリアやスキル向上のサポートが乏しい。
DESIGN-5-8	デザイン思考	アンチパターン	デザイン組織	デザイナーがプロジェクトの意思決定に関われなかったり、デザイナーに情報を伝えるのが遅いため、カスタマージャーニー全体に対する価値が発揮しづらくなっている。
DESIGN-6-1	デザイン思考	メトリクスの計測	プロトタイピング	少なくとも四半期に1回以上の戦略仮説に向けたサービスプロトタイプを作成しているか。
DESIGN-6-2	デザイン思考	学習と改善	プロトタイピング	一年に一度以上の頻度で経営幹部も参加するプロトタイプづくりのワークショップを行っているか。
DESIGN-6-3	デザイン思考	プラクティス	プロトタイピング	ある課題の発散のフェーズでは、プロトタイプは極端な仮説に基づいて複数個つくられているか。
DESIGN-6-4	デザイン思考	プラクティス	プロトタイピング	デザイナーやプロダクトオーナーはプロトタイピング専用ツールを使うことができるか。
DESIGN-6-5	デザイン思考	プラクティス	プロトタイピング	作ったプロトタイプは、一度破棄してから製品用の設計を行っているか。
DESIGN-6-6	デザイン思考	アンチパターン	プロトタイピング	プロトタイプを作るために、プレゼンや大きな稟議が必要になり、プロトタイピングの前に頓挫することが多い。
DESIGN-6-7	デザイン思考	アンチパターン	プロトタイピング	MVPを特定せずに、プロトタイピングに製品版の完成度を求めてしまう。(プロトタイプはどれだけ雑に仮説検証が達成できるかが重要である。)
DESIGN-6-8	デザイン思考	アンチパターン	プロトタイピング	一度のプロトタイピングで、中止や製品化を判断してしまう。
DESIGN-7-1	デザイン思考	メトリクスの計測	ユーザビリティテスト	ユーザビリティパフォーマンステストを行い、タスク達成率などを継続的または周期的にトラッキングしているか。
DESIGN-7-2	デザイン思考	学習と改善	ユーザビリティテスト	新規・既存顧客について継続的にユーザビリティの変化がないか示すメトリクス（タスクの成功率など）を計測し、それをもとに改善を行っているか。
DESIGN-7-3	デザイン思考	プラクティス	ユーザビリティテスト	重要機能のタスク成功率/タスク実施時間/学習効率などを計測しているか。
DESIGN-7-4	デザイン思考	プラクティス	ユーザビリティテスト	実際のリリース後も入力エラーやタスク時間などを計測しているか。
DESIGN-7-5	デザイン思考	プラクティス	ユーザビリティテスト	自己申告メトリクスなどを用いて、印象を含めた満足度のテストをおこなっているか。
DESIGN-7-6	デザイン思考	アンチパターン	ユーザビリティテスト	ユーザー調査（何が課題かの発見）とユーザビリティテスト（使い心地が良いか、どのような印象を抱いたか）を区別せず同時に行ってしまう。
DESIGN-7-7	デザイン思考	アンチパターン	ユーザビリティテスト	事業KPIとの関連の薄い些細な項目ばかりに時間を使ってしまう。
DESIGN-7-8	デザイン思考	アンチパターン	ユーザビリティテスト	３名以下の少なすぎるユーザビリティテスト対象者の結果に振り回されてしまう。
DESIGN-8-1	デザイン思考	メトリクスの計測	プロダクトマネジメント	権限を持ったプロダクトマネージャという役職が存在し、１サービスに専任の１名以上が任命されているか。
DESIGN-8-2	デザイン思考	学習と改善	プロダクトマネジメント	幹部人材に対して、プロダクトマネジメントのスキルについての継続的な学習機会を提供できているか。
DESIGN-8-3	デザイン思考	プラクティス	プロダクトマネジメント	プロダクトへの要求をユーザーストーリーなど開発チームと合意したバックログアイテムの単位で明文化し、その優先順位をつけることができているか。
DESIGN-8-4	デザイン思考	プラクティス	プロダクトマネジメント	事業フェーズに応じて、プロダクトマーケティングや詳細な要求分析、UX評価など適切な分業体制を引くことができているか。
DESIGN-8-5	デザイン思考	プラクティス	プロダクトマネジメント	プロダクトの仮説をバリュープロポジションキャンバスや、仮説キャンバスなどで明文化した上で機能定義を行っているか。
DESIGN-8-6	デザイン思考	アンチパターン	プロダクトマネジメント	プロダクトマネージャがソフトウェアプロダクト開発やデザインに関する知見や関心が薄く、チームの関係性が悪化している。
DESIGN-8-7	デザイン思考	アンチパターン	プロダクトマネジメント	プロダクトマネージャとビジネスプロセスやマーケット部門との関係性が薄く、それ起因の実運用によるトラブルが、ほぼ毎回発生している。
DESIGN-8-8	デザイン思考	アンチパターン	プロダクトマネジメント	プロダクトマネージャという役割に予算執行の権限と責任がない。
CORPORATE-1-1	コーポレート	メトリクスの計測	スパン・オブ・コントロール	スパン・オブ・コントロールの基準を(最低4名-最大10名など)設けており、それに外れた部門数などをモニタリングしているか。
CORPORATE-1-2	コーポレート	学習と改善	スパン・オブ・コントロール	兼務及びスパン・オブ・コントロールの基準が適切になるように、定期的に改善が行われているか。
CORPORATE-1-3	コーポレート	プラクティス	スパン・オブ・コントロール	人事制度上、管理職位の設定は人事考課上の等級と独立して設置されるようになっているか。（部長職じゃないと、この給与にならないといったような職位と等級が一致するものでないか。）
CORPORATE-1-4	コーポレート	プラクティス	スパン・オブ・コントロール	どのメンバーにとっても業務的な命令を行う上司は１名か。（その原則が崩れているメンバーを列挙して把握しているか。マトリクス組織であっても指揮系統は１つであるか。）
CORPORATE-1-5	コーポレート	プラクティス	スパン・オブ・コントロール	行っている業務と部門の役割が一致するように部門のミッションステートメント（業務分掌）を明確に決めて全社に公開しているか。
CORPORATE-1-6	コーポレート	アンチパターン	スパン・オブ・コントロール	人事評価者と指示を行う者の不一致がある組織になっている。または、一致するかの確認ができていない。
CORPORATE-1-7	コーポレート	アンチパターン	スパン・オブ・コントロール	部下が0名ないし1名の管理職が存在する。
CORPORATE-1-8	コーポレート	アンチパターン	スパン・オブ・コントロール	組織のガイドラインが存在しない、もしくはガイドラインが存在していても例外が常態化している。
CORPORATE-2-1	コーポレート	メトリクスの計測	開発者環境投資	プロダクト開発に関係する全ステークホルダーに対して、自社のIT環境の満足度やeNPS℠を定期的に測定しているか。
CORPORATE-2-2	コーポレート	学習と改善	開発者環境投資	働く環境について、事業競合や採用競合ともコミュニケーションする機会を意識的に持ち、従業員の満足度において常に改善を繰り返しているか。
CORPORATE-2-3	コーポレート	プラクティス	開発者環境投資	開発者(およびデザイナー)は、職務遂行に十分なスペックの開発マシンを貸与されているか。(開発マシンは、開発者からのアンケートなどを通じて満足が確認されているか。）
CORPORATE-2-4	コーポレート	プラクティス	開発者環境投資	従業員が作成したソフトウェアライブラリを、自社のOSSまたは個人のOSSとして公開するためのガイドラインを準備しており、何らかソフトウェアを公開しているか。
CORPORATE-2-5	コーポレート	プラクティス	開発者環境投資	オフィス内のWi-Fi速度は安定して100Mbpsを超えており、人数規模に十分なキャパシティを持っているか。
CORPORATE-2-6	コーポレート	アンチパターン	開発者環境投資	ソフトウェア開発作業を行う場所で、自由にインターネットを使うことができない。（たとえば、SNSをつかわせないなど）
CORPORATE-2-7	コーポレート	アンチパターン	開発者環境投資	障害対応など予測の困難な業務や、輪番対応等の計画された定時外業務があっても、定時出勤することを求めている。
CORPORATE-2-8	コーポレート	アンチパターン	開発者環境投資	従業員は自身のパソコンへの自由なソフトウェアのインストールを過度に制限されている。
CORPORATE-3-1	コーポレート	メトリクスの計測	コミュニケーションツール	チャットツールにおける全社員が閲覧可能な状態でのコミュニケーションの割合を測定しているか。
CORPORATE-3-2	コーポレート	学習と改善	コミュニケーションツール	ここ１年以内に管理職以上で、「コミュニケーションの透明性向上」を目的とした対策を検討し実施したか。
CORPORATE-3-3	コーポレート	プラクティス	コミュニケーションツール	チャットサービスは全社で同一のサービスが導入され、チャットを通じた業務上の手続きの自動化(ChatOps)が可能か。
CORPORATE-3-4	コーポレート	プラクティス	コミュニケーションツール	社内ナレッジの管理のために、大多数の従業員が気軽にwebベースの文書が作成できる、Wikiサービス等を導入しているか。
CORPORATE-3-5	コーポレート	プラクティス	コミュニケーションツール	各部門は、自部門の仕事をメールベースあるいはチャットなどフロー情報を扱うツールではなく、ストック情報を扱うチケットツールベースで受け取る環境があるか。
CORPORATE-3-6	コーポレート	アンチパターン	コミュニケーションツール	各種ミーティングにおいて、オンラインでアクセスできる共通の議事録をとっていない。
CORPORATE-3-7	コーポレート	アンチパターン	コミュニケーションツール	意思決定者や管理者がチャットツールにログインしておらず、コミュニケーションが取れない。
CORPORATE-3-8	コーポレート	アンチパターン	コミュニケーションツール	チャットツールを通じた雑談を禁止している。または雑談をやめるように注意喚起を促したことがある。
CORPORATE-4-1	コーポレート	メトリクスの計測	人事制度・育成戦略	理想的な自社従業員のスキルセット構成から逆算した採用・育成計画が中長期の計画として定義されているか。
CORPORATE-4-2	コーポレート	学習と改善	人事制度・育成戦略	全社員のスキルセットやキャリアを管理しているタレントマネジメントシステムを導入していて、データと計画をアップデートしているか。
CORPORATE-4-3	コーポレート	プラクティス	人事制度・育成戦略	プロダクト開発に関わる従業員一人あたり年間12万円(月額1万円)以上の教育研修予算があるか。
CORPORATE-4-4	コーポレート	プラクティス	人事制度・育成戦略	専門職向けのジョブ型人事制度があり、管理職と同等かそれ以上の給与で従事しているメンバーが存在するか。
CORPORATE-4-5	コーポレート	プラクティス	人事制度・育成戦略	リモートワークやフレックスタイムなどの柔軟な働き方を導入しているか。
CORPORATE-4-6	コーポレート	アンチパターン	人事制度・育成戦略	高度な専門人材に対して、市場変化を考慮した年収額のアップデートができない人事制度になっている。
CORPORATE-4-7	コーポレート	アンチパターン	人事制度・育成戦略	自己学習のための書籍や、オンライン学習の補助手当がない。
CORPORATE-4-8	コーポレート	アンチパターン	人事制度・育成戦略	新入社員向けカリキュラムが、自社内でしか通用しないノウハウに特化したものとなっている。
CORPORATE-5-1	コーポレート	メトリクスの計測	デジタル人材採用戦略	ソフトウェアエンジニアの採用活動を常に行っており、毎年十分なペースでソフトウェアエンジニアを採用できているか。
CORPORATE-5-2	コーポレート	学習と改善	デジタル人材採用戦略	採用管理システムが導入され、採用に関わる全てのステップ、チャネルからの情報が遅滞なく不足なく集約されているか。
CORPORATE-5-3	コーポレート	プラクティス	デジタル人材採用戦略	候補者の方との初回面談から、オファーまでのリードタイムを目標とともに管理しているか。（長すぎる選考プロセスは、人材獲得の妨げになる。）
CORPORATE-5-4	コーポレート	プラクティス	デジタル人材採用戦略	採用したい人材の基準を明確化したJob Description（求人票）が存在し、現場エンジニアとともに表現を見直すためのワークフローが整備されていて、直近一ヶ月以内に更新されているか。
CORPORATE-5-5	コーポレート	プラクティス	デジタル人材採用戦略	中途採用におけるリファラル採用（社員からの紹介による採用）の比率が全体採用数の30%を超えているか。
CORPORATE-5-6	コーポレート	アンチパターン	デジタル人材採用戦略	採用部門の予算計画が存在しない、または行使可能な予算金額が年間の採用目標人数の年収合計に対して25%以下しかない。
CORPORATE-5-7	コーポレート	アンチパターン	デジタル人材採用戦略	「募集職種：Webエンジニア」のように曖昧な表現しかされておらず、どのようなスキルやキャリアが求められているのかの解像度が低い。
CORPORATE-5-8	コーポレート	アンチパターン	デジタル人材採用戦略	経営や幹部人材が、人材採用に対して責務を負っておらず十分な時間と熱量を費やしていない。
CORPORATE-6-1	コーポレート	メトリクスの計測	モダンなITサービスの活用	従業員の情報システムへの満足度と利用度、申請から承認までのリードタイムなどの指標を継続的に測定し、改善に生かしているか。
CORPORATE-6-2	コーポレート	学習と改善	モダンなITサービスの活用	SaaS間の自動連携を目的としたサービス(iPaaSやLow Code系ツールなど)を導入しており、業務の自動化や効率化をするためのBPR活動を事業部主体で実行しているか。
CORPORATE-6-3	コーポレート	プラクティス	モダンなITサービスの活用	業務に合わせて社内のシステム開発を行うのではなく、デファクトなSaaSなどの利用を行い、そのツールに業務自体をフィットさせているか。
CORPORATE-6-4	コーポレート	プラクティス	モダンなITサービスの活用	表計算やプレゼン資料などはすべてクラウド上で共同編集できるようになっているか。

DX Criteria (v202104)

ビジョンとポリシー

ご紹介

導入ガイド

5つのテーマ

変更点

クライテリア一覧

✅
クライテリア

DX Criteria (v202104)

ビジョンとポリシー

ご紹介

導入ガイド

5つのテーマ

変更点

クライテリア一覧

✅クライテリア

✅
クライテリア