「バグゼロ＝良いチーム」とは限らない。チームの「プロセス品質」可視化の記録
はじめに
こんにちは！グロービスで学習管理システム「GLOPLA Solution」のQAエンジニアをしているカロリーナです。
突然ですが、みなさんのチームでは「品質」をどのように定義していますか？
「バグが少ないこと」「仕様通りに動くこと」はもちろん重要です。しかし、アジャイル開発において、それだけで「私たちのチームは良い開発ができている」と胸を張って言えるでしょうか？
今回は、私たちが取り組んでいる 「品質の可視化」 について、特に 「プロセス品質」 に焦点を当ててご紹介します。
なぜ「品質」を可視化するのか
もともと私たちのチームは、大きな障害もなく、表向きは「品質が良い」と言える状態でした。しかし、ふと立ち止まったときに思ったのです。
「バグが出ていないのは、たまたまではないか？」
「私たちは、胸を張って『最高のチームだ』と言える根拠を持っているだろうか？」
「真に誇れるチームでありたい」。
そう考えた私たちは、感覚的な「良さ」に頼るのではなく、品質を客観的な指標で可視化し、評価できるようにしようと決意しました。
3つの品質と「プロセス品質」
可視化にあたり参考にしたのが、システム品質の国際規格である ISO/IEC 25000シリーズ（SQuaRE） です。この規格では、品質を大きく以下の3つに分類しています。
- プロセス品質: 目的達成のために適切な活動が行われ、改善されているか
- 製品品質: ソフトウェア自体が持つ特性（機能性、信頼性など）
- 利用時の品質: ユーザーが使用した際の体験価値（有効性、満足度など）
これらは相互に影響し合っています。「良いプロセスが良いプロダクト（製品品質）を生み、それがユーザー体験（利用時の品質）につながる」という関係性です。
私たちは現在、この3つ全ての可視化に取り組もうとしていますが、今回はその土台となる 「プロセス品質」 の計測についてお話しします。
AIと共に定義した「6つの柱」
しかし、ISO規格には「アジャイル開発における最高のプロセス」の具体的なチェックリストまでは載っていません。
そこで私たちは、「アジャイル開発においてプロセス品質が高いチームとはどのような状態か？」 をAIにも手伝ってもらいながら言語化し、独自の評価軸として以下の6つの柱を定義しました。
- 顧客満足度の向上: ステークホルダーと密に連携できているか
- 自己組織化と自立性: 心理的安全性があり、助け合えているか
- 継続的な改善やチャレンジ: 振り返りが機能し、新しい挑戦をしているか
- 透明性と可視化: 情報はオープンか、不都合な事実も共有されるか
- 適応性と柔軟性: 変化に柔軟に対応し、技術的負債に取り組めているか
- 品質へのコミットメント: 「完成の定義（DoD）」を遵守しているか
ここまでの準備期間は、実に1年近く。「なんとなく」を脱却し、チーム独自の基準を作り上げるのは、それほど骨の折れる作業でした。
実際のチェックリスト（一部抜粋）
「6つの柱」を具体的にどう計測しているのか、私たちが実際に使用しているチェックリストから、いくつか設問を抜粋してご紹介します。
| カテゴリ | 設問の例 |
|---|---|
| 品質へのコミットメント | チームには、プロダクトの品質を保証するための明確な「完成の定義（Definition of Done）」があり、全員がその内容を理解し、遵守している。 |
| 適応性と柔軟性 | チームは、将来の変更を容易にするため、技術的負債の返済やアーキテクチャの改善といった活動に計画的に時間を使っている。 |
| 自己組織化と自立性 | このチームでは、自身の意見や懸念、失敗を気兼ねなく表明できる雰囲気（心理的安全性）がある。 |
| 透明性と可視化 | 現在のスプリントゴールと作業状況は、タスクボードなどで常に可視化され、チーム全員が最新状態を把握できる。 |
これらを含む約30問に対し、チーム全員が回答します。
泥臭い運用と、計測結果の変遷
運用は、3ヶ月に1回のサイクルで回しています。
全メンバー（PO、開発、QA、デザイナー）が、独自のチェックリストに回答します。回答は「どちらでもない」を排除した6段階評価です。
ここでは、実際の計測結果と、そこから生まれたチームの議論の一部を紹介させてください。
【第1回計測】 突きつけられた「現実」と「強み」
記念すべき第1回目の計測結果（2025年6月）は、チームの現状を残酷なほど正直に映し出しました。
全体の結果
設問別の結果
-
強み：透明性と助け合い
- 「スプリントの状況可視化」は5.25点、「役割を越えた協力体制」は5.08点と高得点を記録。「困ったら助け合う」文化が根付いていることが数字で証明され、これはチームの自信になりました。
-
課題：「完成の定義」と「技術的負債」
- 一方で、「完成の定義（DoD）の理解・遵守」は3.00点と低い結果に。
- 「技術的負債への取り組み」も3.50点でした。
▼ チームでの議論：なぜ低かったのか？
この結果を受けて、私たちは膝を突き合わせて話し合いました。そこで出てきたのは、メンバーの率直な「本音」でした。
- DoDについて: 「そもそもDoDがどこに定義されているか分からない」「人によって品質基準の認識がバラバラだった」
- 技術的負債について: 「負債があるのは分かっているが、機能開発が優先されて後回しになっている」「可視化されていないので、POに説明しにくい」
議論を通じて、 「基準がないから迷う」「見えないから直せない」 という根本原因が特定されました。
そこで私たちは、以下の改善アクションを決定し、3ヶ月間実行しました。
- 完成の定義（DoD）を明確にし、そこにおける各メンバーの責任と役割も定義して認識を揃える
- 技術的負債をチケット化し、スプリントに組み込む
【第2回計測】 改善の兆しと新たな気づき
そして迎えた3ヶ月後、第2回目の計測です。
結果は、私たちが踏み出した一歩の正しさを証明してくれました。
全体の結果
設問別の結果
- 完成の定義（DoD）： 3.00点 → 4.33点 （+1.33）
- 技術的負債への取り組み： 3.50点 → 4.64点 （+1.14）
課題だった2項目で、劇的なスコアアップを達成したのです。
▼ チームでの議論：なぜ改善したのか？
第2回の振り返りでは、スコア向上の要因について以下のような声が挙がりました。
- 「DoDを作ったことで、迷ったときの判断基準ができた。PR（プルリクエスト）の質も上がった気がする」
- 「技術的負債のリファクタリングを実施できたことで、開発しやすくなった実感がある」
- 「『心理的安全性』のスコアがさらに上がった（4.67→5.09）。言いにくいことも言える雰囲気が、改善を加速させたと思う」
もちろん、「まだDoDの運用が定着しきっていない」「もっと自動テストを増やしたい」といった新たな課題も見つかりましたが、それは 「次のステージの悩み」 です。少なくとも私たちは、自分たちのプロセスを自分たちでコントロールできる感覚を掴み始めていました。
まとめ：プロセス品質の計測を始めて
「プロセス品質」の計測は、チームにとっての健康診断のようなものです。
健康だと思っていても、数値を測れば「実は運動不足（技術的負債）」だったり、「特定の栄養素が足りない（共通認識の欠如）」ことが分かります。
そして何より重要なのは、 「測定は対話のきっかけに過ぎない」 ということです。
第1回の議論で「DoDがない」という事実に全員で向き合わなければ、第2回の改善は決して生まれませんでした。数値を見て一喜一憂するのではなく、「なぜその点数なのか」を話し合い、泥臭く改善のアクションを積み重ねる。そのプロセス自体が、チームを強くしてくれます。
「なんとなく良さそう」なチームから、「数値と根拠を持って良いと言える」チームへ。
もし皆さんのチームが「今のままでいいのかな？」と感じているなら、まずは自分たちなりの「品質」を定義し、測ってみることから始めてみてはいかがでしょうか。
Discussion