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

ある特定の人物に属人化した仕事を洗い出し、減らしていく仕組みがチームにあるか。

チームは月に一度以上の頻度で仕事のふりかえりをおこなっており、その際にプロジェクト憲章またはインセプションデッキを見返して目的を再確認しているか。

チームが仕事を始めるために必要な課題やタスクの粒度について、明文化されたフォーマットが存在するか。

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

設定ファイルや一部のソースコードに対して、エンジニアでなくても必要に応じて修正のためのPull Request(Merge Request)を投げることがあるか。

システムのソースコードの閲覧を関連するエンジニアのみに限定している。（別チームのエンジニアや他のステークホルダーが閲覧できない。）

テストカバレッジ基準や自動テストガイドラインを用意し、これらを継続的に改善するための工数がチームで割かれているか。

デプロイ頻度とデプロイ成功率を継続的に測定しており、これらを改善することを目標管理しているか。

ドメインイベントの発火に伴いPublish/Subscribeモデルを利用した仕組みで、関連サービスとの連携が可能か。またその履歴データが保存管理され、これらのイベントリプレイから再突合や監査の自動化が可能か。

結果整合性を考慮したサービスレベルの合意が要件のガイドラインの中に組み込まれているか。

オートスケールなどの仕組みにより、開発者やSREが介在しなくても、適切なキャパシティコントロールができているか。

外部事業者との取引情報について、構造化されたフォーマットでリアルタイムにデータレイクへ保存しているか。

データサイエンス/機械学習/データアプリケーションエンジニアリング/クラウドインフラなどの知見が１名に属人化している。

データ集計・可視化等のためのBIツールを導入しており、エンジニア以外でも使うことができているか。

マーケティングのオペレーションの業務の割合と企画・戦略の業務割合を棚卸しして、自動化・最適化のためのリソースを割いているか。

ビジネスプロセスやミーティングを棚卸しし、不要なもの・従来の用途から離れてしまったものを停止・削除しているか。

自動化ツールを前提とした組織設計をおこなわず、既存の業務や組織にあわせてツールをカスタマイズする。

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

ユーザーインタビューによって見つけた課題に対してどの機能がリリースされているのかが記録されており、その効果も測定されている。

インタビュー参加者が話しやすい雰囲気作りのための工夫がインタビュースクリプトに組み込まれている。

デザインシステムを用いて、デザイナーの介在なしにフロントエンド開発の５割以上が達成できている。

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

デザイナーやプロダクトオーナーはプロトタイピング専用ツールを使うことができるか。

部下が0名ないし1名の管理職が存在する。

障害対応など予測の困難な業務や、輪番対応等の計画された定時外業務があっても、定時出勤することを求めている。

全社員のスキルセットやキャリアを管理しているタレントマネジメントシステムを導入していて、データと計画をアップデートしているか。

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

データとデジタル技術を用いて、どのように事業変革をしていくのかのビジョンを明文化して経営メッセージとして発信し、その推進経営指標をもっているか。

社内のセキュリティ担当者が、近年のセキュリティ動向やシフトレフト、リモートワークについて理解し、事業部門とともに開発リードタイムや生産性の改善のために必要な措置をおこなっているか。