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

チームの不安や不満などを可視化し、吸い上げるための仕組みを持っているか。

目標管理が強く評価制度に結びついているため、ストレッチしたゴール設定をすることが難しくなっている。

相対見積もりの基準となる要件（ユーザーストーリー）が存在し、定期的にアップデートしているか。

スケジュールのバッファ（緩衝期間）が全体計画に対して1/4以下しかもうけていない。

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

継続的インテグレーション環境が存在し、開発者は開発ブランチの全テストをリソース調整することなく、自由に行うことができるか。

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

各APIについて、動作するインタラクティブなドキュメントや管理サービスを持っているか。

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

専門的なアプリケーションセキュリティの知識を持つメンバーが、専任でセキュリティチームにおり、動向や最新情報をもとに自社サービスをレビュー・改善できているか。

開発企画要件の段階で、設計レベルのセキュリティレビューが実施されていない。(Security by Designの未実施)

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

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

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

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

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

インハウスのマーケティングチームに自動化や分析を行うエンジニアがおり、指標や自動化をともに進めているか。

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

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

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

ユーザーインタビューに関して訓練を受けていないスタッフが実施しており、仮説に対して誘導的すぎたり、クローズドクエッションが多くなったりしている。

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

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

行っている業務と部門の役割が一致するように部門のミッションステートメント（業務分掌）を明確に決めて全社に公開しているか。

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

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

業務で利用しているシステムにシステム間連携を目的としたAPIが用意されていない。

継続的なシステム改善のためのプロダクトマネジメント経験者がいない。そのため、開発チームとの関係が受発注構造になっている。（情報子会社問題）

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