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

1on1や、落ち着いた場面でのカジュアルな雑談を含む直接業務に関わらないキャリアやタスクの壁打ちを、月に1度程度は実施しているか。

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

相対見積もりによって得られたベロシティの数値自体を、生産性の指標にしており、数値的なコミットメントや改善が要求されている。

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

属人的なタスクがある状態を効率的だと解釈して改善をしない。

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

コードレビューガイドラインを満たさないコードを自動的に検出・補正する各種Linterやフォーマッタなどのツール群を整備しており、ソースコードを変更する誰もが使うことができるか。

プロダクトの半分以上のモジュール/クラスファイルに対して、ユニットテストが存在しているか。

テスト自体が複雑になって、長期間メンテナンスされていない。

バッチ、ジョブ、プロシージャに対する冪等な設計ガイドラインが存在しており、再送によって整合性が担保できるようなシステムになっているか。

開発速度（デプロイ頻度）を低下させるようなセキュリティルールが、施行されていて現況に合わせたアップデートが行われていない。

自社サービスやメディアをスマートフォン用のWebサイトまたはアプリとして提供しているか。

POSや業務システム上のアクセス記録/操作履歴を構造化されたフォーマットでリアルタイムにデータレイクへ保存しているか。

音声・動画・文章といった従来構造化できなかったデータソースも事業利活用のために収集しているか。

データ収集に関するプロジェクトが存在しないか、進捗していない。

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

事業価値と実現可能性の両面を同時に仮説検証できるようなプロジェクト管理(PoCとプロトタイプ作成)を行っているか。　

電話やメールでの対応に対して、柔軟な対応をしすぎてしまい自動化の阻害要因になっている。

直近、半年以内になんらかのユーザーインタビューを行っているか。

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

一度のプロトタイピングで、中止や製品化を判断してしまう。

ユーザー調査（何が課題かの発見）とユーザビリティテスト（使い心地が良いか、どのような印象を抱いたか）を区別せず同時に行ってしまう。

プロダクトへの要求をユーザーストーリーなど開発チームと合意したバックログアイテムの単位で明文化し、その優先順位をつけることができているか。

ソフトウェア開発作業を行う場所で、自由にインターネットを使うことができない。（たとえば、SNSをつかわせないなど）

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

専門職向けのジョブ型人事制度があり、管理職と同等かそれ以上の給与で従事しているメンバーが存在するか。

新入社員向けカリキュラムが、自社内でしか通用しないノウハウに特化したものとなっている。

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

デジタル技術を活用した経営変革を担う担当役員（CDO等）が存在するか。