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

インセプションデッキまたはプロジェクト憲章を作成し、チームの存在理由についてチーム全員が把握しているか。

1年以上チームのやることが変わっておらず、チームメンバーも固定されている。

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

ペアプログラミング/モブプログラミングを実施しているか。

数値改善のために簡単で予測可能な仕事ばかりを引き受け、難しめのタスクを引き受けない。

すべてのアプリケーションコードをGit/GitHubなどのバージョン管理システムで自社管理しているか。（権利を有する全てのソースコードについて、自社がアカウントを管理する統一のバージョン管理システムで扱っているか）

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

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

デプロイ完了時、および構成変更時にインフラ構成に関する自動的なテスト(e2eのスモークテストおよびServerspecなどのインフラ環境テスト)を実行しているか。

１つのデータベースに対して複数のシステムからの直接的な参照または書き込みがなされていて、それらの依存性が簡単には追跡できない状況になっている。

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

オンライン・オフラインの両方で、顧客の接点となる行動情報や通知の手段を獲得するためのシステムを開発している組織が社内に存在するか。

事業活動の中に潜在的に存在したが、蓄積できていなかったデータを収集するためのシステム化や業務分析を行うチームは存在するか。

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

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

各施策ごとに獲得した顧客がその後のどのような購買行動/利用行動ができたかをコーホート分析しているか。

意思決定や業務を自動化していくために、業務プロセスを改善するためのソフトウェアエンジニアを含むチームが存在するか。

少なくとも１つの大きな事業仮説に対して、対応する１つ以上のペルソナが作成されているか。

ユーザーインタビュー/ユーザー調査なしに勝手なイメージでペルソナを作っている。

顧客による問い合わせから返信までのリードタイム、問い合わせおよび回答への満足度について定量計測を行い、目標管理をしているか。

構造化されたヘルプページがあり、ヘルプに書かれた内容を改善するために顧客がフィードバックできるか。

フロントエンド開発とバックエンドが密結合しており、APIモックサーバーなどを用いて、バックエンド開発と並行して開発をすすめることができない。

デザイナーがプロジェクトの意思決定に関われなかったり、デザイナーに情報を伝えるのが遅いため、カスタマージャーニー全体に対する価値が発揮しづらくなっている。

社内ナレッジの管理のために、大多数の従業員が気軽にwebベースの文書が作成できる、Wikiサービス等を導入しているか。

チャットツールを通じた雑談を禁止している。または雑談をやめるように注意喚起を促したことがある。

候補者の方との初回面談から、オファーまでのリードタイムを目標とともに管理しているか。（長すぎる選考プロセスは、人材獲得の妨げになる。）

従業員の情報システムへの満足度と利用度、申請から承認までのリードタイムなどの指標を継続的に測定し、改善に生かしているか。

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

セキュリティの意思決定は、定期的に行われているリスクアセスメントにともない、リスクとリターンを定量的に評価した上で行われているか。