チームメンバー全員で定期的にカジュアルにコミュニケーションをとる場がある（ランチ、ディナー、レクレーション等）

チームメンバーの行動/発言を明示的に承認行為をおこなう習慣があるか。（成果ではなく行動したこと自体に対して、拍手する・感謝を述べるなど）

心理的安全性を仲の良さと捉えて、事業のための意見ではなく、仲良くすることが目的化しているため、意見を封殺してしまう。

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

どのチームタスクであるか曖昧な仕事が発生したあとに、事後検証（ポストモーテム）が行われず都度話し合いで解決している。

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

デプロイ工程が自動化されておらず、本番反映に1時間以上かかっていたり、特定の時間帯しかできないなどの制約事項がかかっている。

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

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

自動テストとスキーマ定義の存在しない外部システムとの依存関係が１０ケース以上存在しており、機能開発の影響範囲を特定できない。

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

OSSのライブラリやミドルウェアを使用する際、それらの脆弱性情報を自動的モニタリング・警告・パッチ適用するための仕組みまたはサービス等を利用しているか。

オンライン上で、顧客は自社のサービスを契約したり購入したりできるか。

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

意思決定者は、データの読み取り方や統計の基本的な知識について研修トレーニングを受けているか。

簡単なデータ集計であっても、エンジニアを経由しなければ取得できない。

継続的再学習のためのモニタリングと、自動的なモデルのアップデート等の効率的な保守を実現するための仕組みを導入しているか。

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

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

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

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

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

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

少なくとも四半期に1回以上の戦略仮説に向けたサービスプロトタイプを作成しているか。

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

プロダクト開発に関わる従業員一人あたり年間12万円(月額1万円)以上の教育研修予算があるか。

採用したい人材の基準を明確化したJob Description（求人票）が存在し、現場エンジニアとともに表現を見直すためのワークフローが整備されていて、直近一ヶ月以内に更新されているか。

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

自社システムの戦略(競争領域・非競争領域の定義)を明確化しており、競争領域のプロダクト開発を内製人材でコントロールできているか。

IT予算の過半をソフトウェア資産として計上し、予算決裁のためにリードタイムの長い（１ヶ月以上かかるような）意思決定フローを挟んでいる。