チームおよびチームリーダーは、チームのミッションのために必要な外部のリソースを調達するための予算や権限をもっているか。

チームは少なくとも半年以上継続して存在しているか。

新しくチームに参画するメンバー用のオンボーディング・デック（チームの一員として働き始めるための、価値観・実務・スキル・相互理解のための明文化されたドキュメント集）が存在するか。

チームのタスクに関して、「完成(完了)の定義(Definition of DONE)」が存在するか。

機能要件のバッファ(緩衝機能)を全体計画に対して設けられていない。(「必須な機能」と「あったらよい機能」が分類されず、曖昧になっている。)

チームのメンバーは、チームで合意した1カ月以内のサイクルでふりかえりを実施しているか。

バージョン管理システムの履歴情報(Code Churn)の分析をもとにバグ予測や品質上の問題を指摘するツールを導入し、継続的に改善しているか。

コードレビューガイドラインは１年以上メンテナンスされておらず、形骸化している。

APIは何らかのSchema定義言語によって規定され、そこから自動的にクライアントの生成やバリデータの生成が行われているか。

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

開発と SRE が共有する障害報告リストがあり、それぞれに有効な再発防止の仕組みが整うようにリソースを割いているか。

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

顧客の行動履歴データを分析可能な形で保存しており、その割合が顧客全体の7割を超えているか。

データの活用に関して責任のあるポジションを設置していない。

分析・開発や運用のバリューストリーム上の各種サイクルタイムを計測しており、継続的に改善しているか。

実験時の環境を実サービス環境に向けてポータブルにするためのコンテナ化やIaC(Infrastructure as Code)が存在しない。　

売上などの短期的数値ではなく、長期的な事業価値のための間接的指標（e.g.顧客リピート率や予測LTVなど)を主要なKPIとして設定しているか。

実運用時の計算量や計算資源の種別（IoT/エッジ利用/クラウド）などを考慮に入れた上で、モデル選定や実験のプロセスが動いているか。

ユーザーインタビューの実施のための稟議やフローは軽量で、一ヶ月以内に行うことができるか。

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

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

UIデザイナーが作成したデザインをソースコードに自動的に反映するためにツールを利用しているか。

実際のリリース後も入力エラーやタスク時間などを計測しているか。

事業KPIとの関連の薄い些細な項目ばかりに時間を使ってしまう。

どのメンバーにとっても業務的な命令を行う上司は１名か。（その原則が崩れているメンバーを列挙して把握しているか。マトリクス組織であっても指揮系統は１つであるか。）

開発者(およびデザイナー)は、職務遂行に十分なスペックの開発マシンを貸与されているか。(開発マシンは、開発者からのアンケートなどを通じて満足が確認されているか。）

チャットサービスは全社で同一のサービスが導入され、チャットを通じた業務上の手続きの自動化(ChatOps)が可能か。

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

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

従業員および経営幹部に対して、リモートワークのリスクなどの最新のトレンドなどが取り入れたセキュリティ教育がなされていない。