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

オンボーディングプログラムが、文章を読むだけのものになっており、ハンズオンやミッション理解の伴わない形骸化したものになっている。

チームメンバー間で挨拶をしたり、雑談をする習慣はあるか。

スケジュールがクリティカルな場合には当初から精密に、仮説検証や価値がクリティカルな場合には荒い粒度から段階的に詳細化するなどして、状況に応じて見積りや計画の方法を変えているか。

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

フロー効率性などの数値指標に囚われすぎて、全体の効率が悪化するなど価値提供に結びつかない状態である。

統合テスト/デプロイメントの自動化に関わるソースコードをアプリケーションコードと同一のバージョン管理システムで管理しているか。

バージョン管理システムが複数存在していたり、１つのツールからすべての履歴を閲覧できないなど、中途半端な状態のままになっていないか。

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

目指すべきアーキテクチャに対してそぐわない点を洗い出すための仕組みが存在しており、それらの情報をもとに改善を進めているか。（アーキテクチャ適応度関数）

システムアーキテクチャの決定・変更・改善に関するドキュメントを管理し継続的な学習機会を設けているか。

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

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

データレイクから、モデルの実サービス適用までの一連の流れのパフォーマンスモニタ・自動化・効率化を行うエンジニアリングチームが存在するか。

データレイクから、データ分析基盤までのETL処理にも自動テストが存在しており、変換エラーなどがモニタリングされているか。

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

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

獲得した顧客に対して、一括配信などの画一的な通達を行っており、投資効果の最適化を実施していない。

顧客体験の向上のための担当エンジニアリングチームが存在せず、システム化や自動化による改善ができていない。

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

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

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

重要機能のタスク成功率/タスク実施時間/学習効率などを計測しているか。

プロダクトの仮説をバリュープロポジションキャンバスや、仮説キャンバスなどで明文化した上で機能定義を行っているか。

人事制度上、管理職位の設定は人事考課上の等級と独立して設置されるようになっているか。（部長職じゃないと、この給与にならないといったような職位と等級が一致するものでないか。）

人事評価者と指示を行う者の不一致がある組織になっている。または、一致するかの確認ができていない。

ここ１年以内に管理職以上で、「コミュニケーションの透明性向上」を目的とした対策を検討し実施したか。

採用部門の予算計画が存在しない、または行使可能な予算金額が年間の採用目標人数の年収合計に対して25%以下しかない。

「募集職種：Webエンジニア」のように曖昧な表現しかされておらず、どのようなスキルやキャリアが求められているのかの解像度が低い。

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