BLOG
チーム品質診断マップ 1.0 - 現場で見てきた「品質が低い」チームの状態と対策
2026/3/11
多くのチームは「品質が低い」と言われますが、
実際にはチームの状態は段階的に変化します。
このnoteでは、私が現場で見てきた品質状態を
13段階の進化モデルとして整理しました。
このnoteに書いてあることは、すべて自分が実際に目の当たりにしたチームの姿です。その時々の状態を観察し、それに応じて、対策を考えて改善を実施してきました。
インシデント対応に追われて機能開発ができないチーム。チェックリストを増やし続けるのに何も変わらないチーム。仕様を誰も把握していないまま実装が進むチーム。
「品質が低い」と一言で言っても、チームの状態はまったく違う。そしてそれぞれに、ちゃんと名前をつけられることがわかってきていて、それを整理しました。
チームがどんな状態なのか、品質が低いとはなんなのか、このnoteを利用してもらえると嬉しいです。（随時改訂予定）
品質ヘルスチェックリスト（レトロスペクティブ用）
🔥 インシデント・バグ
インシデント対応に追われて、機能開発がほぼできない
バグが出るたびに「なぜこうなった？」が誰にもわからない
同じようなバグが繰り返し起きている
リリース直前に大きな認識のズレが発覚する
レビューはやっているが、根本的な原因に届いていない
📋 品質改善の取り組み
品質を改善しようとしているが、何も変わらない
チェックリストを増やしたのにバグが減らない
プロセスを厚くするほど、チームが疲弊していく
🗺️ プロダクト理解
仕様が言語化されておらず、誰もプロダクトの全体像を把握していない
DBの構造や既存挙動が属人化しており、チームで共有されていない
「え、ここってこういう挙動だったの？」が頻繁に起きる
コードリーディングからしか仕様を追えない
🧪 テスト
テストを誰がやるのか決まっていない
デプロイ後に初めてバグが見つかる
テストの全体像が誰にも見えていない
テストは特別なスキルが必要・QAに頼むものだと思っている
QAへの依頼コスト・待ち時間が大きい
「テストをどうすれば良いかわからない」という状態
🗣️ チームのコミュニケーション
改善の声が個人の中で止まっており、チームに届いていない
「言っても変わらない」という諦めの雰囲気がある
朝会が進捗共有の場になっており、困りごとが出てこない
特定の人しか発言しない
📄 仕様・チケット
仕様書が文章のみで、読み手によって解釈がバラバラ
「なぜこの機能が必要か」がチームに届いていない
「実装」「テスト」という作業名のチケットが横行している
チケットを見ても、誰のための何かがわからない
長生きしているチケットがたくさんある
仕様が決まっていないのに実装が始まっている
🤝 職種間の連携
「伝えた」と「伝わった」がずれている
仕様の決定プロセスがエンジニアに見えない
開発が始まってから「そういう意味じゃなかった」が起きる
開発者がつまらなそうにしている・当事者感がない
🧭 共通認識
仕様の「決まっている・決まっていない」が誰にも見えていない
「今どこ？」が分からなくなる瞬間がある
議論が枝葉に広がり、何を決めているのかわからなくなる
検討していなかったところでバグが起きる
チームごとにやり方がバラバラ
🏗️ 組織・構造
複数プロジェクトのかけもちで認知負荷が高い
構造的な問題なのに、個人の頑張りで解決しようとしている
チームの強みや状況が案件アサインに反映されていない
運用チームと機能開発チームが分断されており、現場の声が届かない
チェックが多いカテゴリが、今のチームの「症状」です。
チームの中のレトロスペクティブで、それぞれを眺めてみて投票、Next Actionに繋げると良いと思います。
Phase1. 前提
Lv.0: Chaos 予期せぬインシデントが多発している
チームの状況
インシデントが多発し、機能開発がほぼできない状態
テストは外部QAに完全依存しており、開発者はテストをしない
品質 ＝ バグがない、という表面的な認識にとどまっている
どこから手をつけるかもわからない混乱状態
レビューはやっているが、根本的な原因に届いていない
対策・アプローチ
品質のティーチング
「あなたたちが言っている品質って何？」を問う
現状の棚卸し
インシデントの傾向・頻度・原因を可視化する
ポストモーテム
起きた不具合を責任追及ではなく構造として解剖する
After
「なんとなくやばい」が「ここが問題だ」に言語化できる
インシデントの傾向・原因がチームで共有されている
「品質とは何か」をチームで定義できるようになる
Phase2. 認知
Lv.1: CheckList Trap 品質向上を取り組んでいるのに変わらない
チームの状況
品質改善の必要性は芽生えているが、打ち手がプロセスの肥大化にとどまる
チェックリストの追加・テストの強化など、表面的な対策が中心
特急プロジェクトが立ち上がるが、うまく機能していない
「何かしなければ」という焦りはあるが、根本に届いていない
対策・アプローチ
現在地の診断
Lv.0〜12のどこにいるか、どこが複合かをチームと確認する
全体の思想を共有する
品質は後工程のチェックではなく、作り方に溶け込むものだと伝える
小さな成功体験を作る
1つのチケットだけ完成の定義を書いてみる
ポストモーテムの継続実施
不具合の構造的な原因を一緒に見る
After
チームが自分たちの現在地を把握している
「プロセスを厚くする」ではなく「作り方を変える」という方向性が共有されている
1つのチケットに完成の定義が書かれるようになる
Lv.2: Lost Product プロダクトの全体を把握できない
チームの状況
仕様が言語化されておらず、誰もプロダクトの全体像を把握していない
DBの構造や既存挙動が属人化しており、チームで共有されていない
コードリーディングからしか仕様を追えない状態
対策・アプローチ
仕様の見える化
DBの姿・実際の挙動を記録・言語化する
実際に動かして身体で覚える
開発者が自分のプロダクトを隅から隅まで触る（お触り会・バグバッシュでOK）
以前のバージョンとの差異を検知できる状態を作る
After
プロダクトの全体像がチームで共有されている
以前の挙動と新しい挙動の差異をチームで検知できる
開発者が自分のプロダクトを隅から隅まで語れるようになる
開発者が自分のプロダクトを知ることが、すべての品質活動の前提になる
Phase3. 行動
Lv.3: Test Void テスト・品質の所在がチームにない
チームの状況
テスト設計がなく、誰が何をテストするか個人任せ
デプロイ後に問題が発覚することが多い
テストの全体像が誰にも見えていない
案件の受け入れ条件が不明で、デプロイ後に謎の仕様が発覚
対策・アプローチ
全体テストを設計し、全員が実行可能な状態を作る
デプロイ即叩く体制を構築する
並走テスト
開発と同時にテストが回る仕組みを作る
After
テストの全体像がチームで見えている
デプロイ後すぐに問題を検知できる
開発と並走してテストが回り始める
Lv.4: Silent Team チームから改善の声が出ない
チームの状況
改善の声が個人の中で止まっており、チームに届いていない
「言っても変わらない」という諦めの雰囲気がある
スクラムイベントが形骸化している（朝会＝進捗共有、レトロ＝ただやるだけ）
特定の人しか発言しない状態
対策・アプローチ
スクラムイベントの刷新
各イベントの目的と期待アウトプットを定義する
朝会を進捗共有から困りごと共有に変える
不満のタネをレトロスペクティブで拾い、チームの声にする
「自分たちで変えられる体験」を小さく作る
After
個人の不満がチームの課題として扱われるようになる
「言えば変わる」という体験がチームに生まれる
レトロで出た意見が次のスプリントに反映されるようになる
プロセスではなく、変えられるという体験の蓄積が文化の芽になる
Lv.5: Test Anxiety テストは何をしていいかわからない
チームの状況
テストは特別なスキルが必要・QAに頼むものという思い込みがある
QAへの依頼コスト・待ち時間が大きい
「テストをどうすれば良いかわからない」という状態
対策・アプローチ
ストーリー単位の受け入れテストを導入する
モブ・ペアテスト（ドライバー／ナビゲーター形式）で知見を共有する
最初は自分が作って伴走し、徐々に手放す
「QAいらない」ではなく「自分たちでもできる」という拡張として伝える
After
メンバーが自分でストーリー単位の受け入れテストを書けるようになる
テストへの心理的障壁が取れ、単体テストの延長として捉えられるようになる
QAがより価値の高い仕事に集中できるようになる
テストへの心理的障壁を取り除くことが最大のレバレッジ。単体テストの延長として位置づける
Lv.6: Spec Gap 仕様がチームに伝わっていなくて認識がズレる
チームの状況
PRDや仕様書が文章のみで、読み手によって解釈がバラバラ
「なぜこの機能が必要か」がチームに届いていない
PdMはスクラムイベントにほぼ参加しておらず、請負開発の様相
開発者がつまらなそうにしている
対策・アプローチ
文を図に変換する（フロー・ユースケース図）
「なぜこの機能が必要なの？」を問い、ユーザーの背景を引き出す
仕様を分解して、チームで並走できる粒度にする
After
仕様が認知できる形で共有され、チームが同じ絵を見て話せるようになる
「なぜ作るか」がチームに届き、開発者が当事者として動き始める
仕様をチームで並走できる粒度に分解できるようになる
翻訳者として機能することで、PdMとエンジニアの対話が始まる
Lv.7: Task Factory 「実装」のようなチケットが1スプリント以上生き残る
チームの状況
「実装」「テスト」という作業名のチケットが横行している
誰のための何の価値を届けるかがチケットから見えない
チームが作業をこなす状態になっている
対策・アプローチ
チケットのフォーマットを変える：「〜が〜で、〜ができるようになる」
チケットを書く時点で価値を考えざるを得ない構造を作る
After
チケットに「誰のための何か」が書かれるようになる
チケットを書く時点でユーザー視点で考える習慣が生まれる
「作業をこなす」から「価値を届ける」への意識が変わる
言語を変えることで思考が変わる。フォーマットが思考の型になる
Lv.8: Product Wall 仕様はPdMが決めてくれるものになっている
チームの状況
PdMがチームの外にいて、仕様を一方的に「渡す」関係になっている
「伝えた」と「伝わった」がずれている
仕様の決定プロセスがエンジニアに見えない
対策・アプローチ
PdMを朝会に巻き込む
どの仕様が決まっていて、どこが疑問点かをリアルタイムで共有する
「伝える」から「伝わる」コミュニケーションへ設計し直す
After
PdMとエンジニアが同じ場で仕様を確認し合えるようになる
疑問点がリアルタイムで解消されるようになる
「伝えた・伝わってない」による仕様バグが減り始める
Phase4. 文化醸成
Lv.9: Visibility Void チームが今どこにいるか誰もわからない
チームの状況
仕様の「決まっている・決まっていない」が誰にも見えていない
実装の前提条件がバラバラに管理されている
「今どこ？」が分からなくなる瞬間がある
対策・アプローチ
全体マップの作成
仕様の現在地を全員が把握できる一枚のボードを作る
ラフ案でたたき台を作り、PdMとエンジニア、ステークホルダーの対話を生む
決まったこと・決まっていないことを可視化する
After
仕様の現在地が全員に見える状態になる
ラフ案をたたき台にした対話が自然に生まれるようになる
「今どこ？」と聞かれても全員が同じ答えを返せる
全体マップは「作るもの」ではなく、チームの変化の結果として自然に生まれるもの
Lv.10: Discussion Confuse 議論が迷子になる
チームの状況
議論が枝葉に広がり、何を決めているのかわからなくなる
「ひとりでも今どこ？となったら危険」な状態が起きる
情報がPdMからエンジニアへ一方通行で、不具合の温床になっている
対策・アプローチ
状況に応じた手法の使い分け
ユーザーストーリーマッピング・実例マッピング・課題の駐車場
相互に情報流通する仕組みを作る
全員が「今どこにいるか」を把握できる状態を維持する
After
議論が発散しても、状況に応じた手法で収束できるようになる
情報がPdMとエンジニアの間で双方向に流れるようになる
着手前に仕様の曖昧さをチームで潰せるようになる
不具合の起こり方は明確。検討していたが漏れた、そもそも検討していなかった。どちらも情報の一方通行から生まれる
Lv.11: Protocol Fragment チームごとにやり方がバラバラ
チームの状況
チームごとにやり方がバラバラで、PdMの認知負荷が高い
先走って実装してしまうことがある
仕様を書くことと完成の定義を作ることが別作業になっている
対策・アプローチ
各チームの良いやり方をレトロスペクティブで抽象化し、共通プロトコルにする
仕様を書くこと＝完成の定義になる状態を作る
反復横跳び（仕様を固めてから実装）が自然に回るようにする
After
どのチームも同じ共通プロトコルで動けるようになり、PdMの認知負荷が下がる
仕様を書くことが自然に完成の定義になっている
先走り実装がなくなり、仕様が固まってから実装が始まるようになる
プロセスを人の上に敷くのではなく、みんなで創ったから「私たちのもの」になる
Lv.12: Context Overload プロジェクトを兼務しすぎて認知負荷が高い
チームの状況
複数プロジェクトのかけもちで認知負荷が高い
コンテキストの混乱からヒューマンエラーが起きている
チームの強みや状況が案件アサインに反映されていない
対策・アプローチ
ストリームアラインドチームへの再編（プロジェクト単位→コンテキスト単位）、WIP制限を設けることでフロー効率を目指す
強みと成長方向に基づいて案件を流す
チームの状況をもとに案件交渉ができる仕組みを作る
After
コンテキストが揃ったチームで動けるようになり、認知負荷が下がる
強みや成長方向に合わせて案件が流れるようになる
チームの状況をもとに案件交渉ができるようになる
品質は技術の問題ではなく、伝達・構造・認知の問題でもある
Lv.13: Unreachable Value チームが顧客に触れる事ができない
チームの状況
品質文化は根付いているが、まだ完璧ではない
外部の力なしに改善を回し続けられるかが問われる
運用チームと機能開発チームがまだ分断されている場合がある
対策・アプローチ
チーム自身が課題を発見し、ブラッシュアップし続ける仕組みを育てる
運用チームと機能開発チームを統合し、運用の文脈を開発に直接フィードバックする
外から与えられたプロセスではなく、自分たちで進化させていく
After
チームが自分たちで課題を発見し、改善を回し続けている
運用の文脈が機能開発に直接フィードバックされている
誰かがいなくても品質文化が維持・進化し続けている
あなたのチームはどのLvにいましたか？
チェックが多かったカテゴリから、一緒に現在地を整理するところからはじめます。 お気軽にDM・ご連絡ください。
無料診断はこちら