システムを開発する１チームの構成人数は、3人以上10人以下か。（ピザ2枚ルール）

ミッションや共通のゴール設定をしないまま意見を集め、課題のためというよりも個人のための意見しか出てこない状況になっている。

１年後などのチームとプロダクトの目指す姿が、言語化され、いくつかの計測可能な指標により明晰化されているか。

ビジネス上、重要なマイルストーンとそのスケジュールをチームで常に共有し、その進捗を確認しているか。

目標が定量的でなく、第三者からみて達成度合いが不明確なものになっている。

チームのバリューストリームマッピングを作成し、繰り返しボトルネックを把握しながら自動化と学習を繰り返しているか。

アプリケーションコードの循環的複雑度などのメトリクスを、ツール/サービスを用いて継続的に計測しているか。

デッドコードを四半期以上のサイクルで定期的に棚卸しし、削除や分解をしているか。

明文化されているコードレビューガイドラインが存在するか。

コードレビューをできる人物がチームの中におらず、レビュー待ちに1、2営業日がかかる。

デプロイ作業を伴わず、一部の機能を安全にオフにしたり、オンにしたりできるか。( Feature Toggle /Soft Launch/ Dark launchなどの仕組みを導入・実装しているか。)

フォルトインジェクションテストや、カオスエンジニアリング等の仕組みを導入することで、重大事故につながりうるシステムの欠陥を早期に発見するための試みをおこなっているか。

オンライン上で、顧客は自社のサービスを契約したり購入したりできるか。

データ分析基盤を職種を問わず使ってもらうために、簡単な分析をするためのプログラミングや操作の仕方をエンジニア以外のステークホルダーに対しても教育しているか。

事業システムのデータベースに直接アクセスして、分析用の処理を走らせている。

利用中の外部サービスにリアルタイムなデータ連携するための機構が存在しない。

学習済みのモデルを検証し、サービスインするまでの処理は自動化されているか。

簡単なデータ集計であっても、エンジニアを経由しなければ取得できない。

事業、製品のペルソナについて、データや仮説検証で学習したことを受けて定期的に見直しているか。

B2Bなど顧客における関係者が複数人いる場合、購買プロセスの各担当者など、意思決定に関わる人物の数だけ必要なペルソナを作っているか。

インタビュー結果のインサイトをまとめて、共感マップなどを作成しているか。

各画面やパーツごとに組み込まれた細やかなアニメーションや音、振動、トランジションといった動きのあるUI要素がガイドラインに組み込まれていない。

一年に一度以上の頻度で経営幹部も参加するプロトタイプづくりのワークショップを行っているか。

プロトタイプを作るために、プレゼンや大きな稟議が必要になり、プロトタイピングの前に頓挫することが多い。

働く環境について、事業競合や採用競合ともコミュニケーションする機会を意識的に持ち、従業員の満足度において常に改善を繰り返しているか。

各部門は、自部門の仕事をメールベースあるいはチャットなどフロー情報を扱うツールではなく、ストック情報を扱うチケットツールベースで受け取る環境があるか。

古いバージョンのOSやブラウザでしか動作しないツールが使われている。

競争領域ではないシステムについて、業務フローをSaaSに合わせて変更するのではなく、既存の業務フローに合わせてパッケージソフト等をカスタマイズしている。

インシデントレスポンスチームが、社内の専門家と事業責任者を含むチームにより構成されていて、インシデント時の予行練習をおこなっているか。

境界防御モデルではなく、ゼロトラストモデルのセキュリティネットワークを構築しているか。