ソフトウェア開発とプロセス品質 ～アジャイルアプローチに必要なメトリクスと落とし穴～

本コラムで示したとおり、私たちはソフトウェア開発における品質を以下の3つに分類している。

(表：3つの品質)

プロセス品質は製造過程における品質を指し、正しいプロセスで開発すれば正しいプロダクトができるという仮説に基づいている。
プロセスを設計するのは人間だが、状況の良し悪しを把握し、適切な評価や判断をするためには定量データ(メトリクス)の収集とモニタリングが不可欠である。
収集したデータ＝ファクト(事実)に基づいて状況を判断し、プロダクトゴールへと導いていくことはマネジメントの基本の一つである。

従来型の開発アプローチでは、品質を表すメトリクスとして「テスト密度」「バグ密度」「レビュー指摘密度」などが使われることが多い。
単位規模あたりのテスト件数やバグ件数、レビュー指摘件数を表すもので、「これくらいの規模(量)があるから、これくらいのテストケースや欠陥があるはずだ」という考え方である。

開発言語や開発フレームワーク、新規開発か既存改修かによって補正は必要だが、過去の統計と比較して閾値を超えていればプロセス上の問題があるかもしれない、と見直すきっかけになり得る。
問題があることがわかったら「品質強化」という名目で再レビューや再テストをすることも考えられる。
まさにレビューやテストプロセスが妥当かどうかを判断するためのメトリクスといえよう。

しかし、もしあなたの組織でこのような指標をアジャイル開発におけるテストでもそのまま適用しようとしているなら、ちょっと待ってほしい。
アジャイル開発の普及に伴い、SaaSやPaaSの利用、API連携やマイクロサービスなどシステムアーキテクチャーやコードのスタイルが大きく変わった。

また、アジャイル開発は短い期間でプロダクトを改善しつづける開発アプローチである。
アーキテクチャーやイテレーションの期間をとってみても従来の開発と大きく異なるアジャイル開発に、同じ指標をあてはめられるはずがない。

つまり、従来型の開発アプローチのメトリクスをそのまま当てはめるのではなく、アジャイル開発に適したメトリクスや評価方法を取り入れなければならないのである。
そして、「マネージャーやQAがプロダクトの良し悪しを判断するため」だけではなく「アジャイルチーム自身が自分たちの活動を評価して改善をつづけるため」へと、メトリクスの使われ方が変化していることも加えておく。

アジャイル開発の現場では、開発フレームワークの一つである「スクラム」を採用することが多い。
スクラムの教典である「スクラムガイド」で定義されているスクラムイベントは、「透明性」に基づいて「検査」と「適応」をするために行われる。

【参考】[スクラムガイド2020 日本語版]

「透明性」とは、すべてがオープンであり共有されていること。
つまりいまのチームやプロダクトの状態が見える化されていることであり、「検査」とは、ゴールに向かっているかどうかを確認すること。
つまりいまの状態が正しい状態にあるかを確認してギャップを見出すことである。

最後に「適応」とは、ゴールに向かって調整をすること。つまり問題があれば解決し、よりよくなるように改善することだ。

スクラムイベントに当てはめると、
* スプリントプランニングでは、チームの過去の実績(ベロシティ)に基づいてスプリントでできることを確認し、スプリントの計画を調整する。
* デイリースクラムでは、バーンダウンチャートを使ってスプリントゴールを達成できるかを確認し、その日以降の計画を調整する。
* スプリントレビューでは、単にインクリメントのデモをするのではなくプロダクトゴールに対する現在の状況を確認してプロダクト開発の計画を調整する。
* そしてスプリントレトロスペクティブでは、いまのチームやプロセスなどの状態を確認して改善をつづける。

このように、「透明性」「検査」「適応」に対応するためには、主観だけではなく客観的な定量データ(メトリクス)が不可欠なのだ。
また、メトリクスは取りつづけなければチームやプロダクトの状態の変化に気づくことができず、継続的な改善を維持することもできない。
その結果、ゴールへの道を走っているのか道から逸れているのかがわからず、最後は主観を頼りに人力で何とかしようという状態に陥ってしまうことが少なくない。

参考までに、アジャイル開発で使われるメトリクス(主にプロセス品質に関わるもの)をいくつか示す。
詳しくは、書籍「アジャイルメトリクス」などを参照されたい。

(表：アジャイルメトリクスの例) 

メトリクスは、基準値(目標値)を定めて基準値からのズレによって評価することが多い。

しかし、最初に想定した基準値を見直す必要が出てくることもあるだろう。
なぜなら、このプロダクト開発は後にも先にも同じものがなく、メトリクスを評価する基準となり得るのは直近の開発実績のみだからである。

QA活動においてもメトリクスは欠かせないものである。
アジャイル開発とQAに関する文献も多くあり、QA界隈で有名な2つの文献を紹介する。

* QA to AQ(Quality Assurance to Agile Quality)
　2014年 Joseph Yoddr氏やRebecca Wirfs-Brock氏が中心となってまとめたもの。
　アジャイル開発において効率的かつ効果的に品質保証を進めるために有用な実証済みのパターン集。
　4つのカテゴリと23のパターンを提唱している。

* Agile Testing Condensed
　2019年 Janet Gregory氏とLisa Crispin氏によるアジャイル開発におけるテストの考え方。
　テストマニフェストが印象的。

いずれもアジャイル開発におけるQAの考え方やプラクティスについて書かれたものであり、共通しているのは「Whole-Teamアプローチ※1」「見える化」「自動化」だ。

※１　従来型の開発アプローチでは開発とQA、インフラ、デザインなど専門チーム(部門)が分業して開発を進めるが、アジャイル開発ではプロダクトのデリバリーに関わる全員が一つのチームの一員として開発に取り組む。

各分野の専門家が集まり、専門分野でリーダーシップを発揮しながらもチーム全員がプロダクトに対する責任をもつのだ。この考え方を「Whole-Team」アプローチという。(Whole-Teamアプローチについては本稿では割愛する。)

なるほど、たしかにアジャイルのマインドの一つには「透明性(＝すべてをオープンにする、共有する)」をいっているし、開発効率をよくしたりメトリクスを収集するために自動化は有効な手段である。
従来の「専門チームの分業制」ではなく「オールラウンドなチーム」がアジャイルチームなのだ。
【参考】[アジャイル開発においてQAはいらないのか？]

だが、単純に書かれている通りに実行すればよいというものではないことを警告したい。
もちろん、この考え方自体を否定するつもりはないし、私たちも多くの知見をいただいている。
考え方やプラクティスの本質を捉えることが重要なのであり、そのうえでプロセスや仕組みを構築するということであろう。

そして、最終的に物事を判断するのはチームであり一人ひとりのメンバーなのである。
ここでは「一つ読み間違えると、期待とは異なる結果が待っているかもしれない」ということをいいたい。

アジャイル開発においては、自分たちのやり方をよくするためにプロセス品質の改善が強く推奨されている。

スクラムにおけるスプリントレトロスペクティブは、プロセス品質を改善するための活動の一つだ。
また、開発・テスト、リリースなどの効率化のために自動化やツールを導入している現場も多い。
ツールを使うことで実績データも自動的に蓄積される。

しかし、蓄積したデータを活用しているだろうか。また、データを活用せず人力で何とかしようとしてはいないだろうか。
ここでは、現場でよく見かけるパターンを見てみよう。
そして、解決のヒントを次章に示す。

CIツールを使ってビルド～テストを自動化した。
エラーが起きればすぐにわかるし、飛躍的に生産性が向上したからみんなハッピー。
ところがいざフタを開けてみると、本番環境で障害が多発してみんなアンハッピーに…

ツールにはレポート機能がある。参考書に書いてあったメトリクスも集めている。
でも、よくわからないからバーンダウンチャートくらいしか使っていない。
上司から「で、このプロダクト開発はうまくいっているのかい？」と聞かれて答えられず…

当社のプロジェクト管理基準にあるメトリクスを収集した。
閾値の範囲内に収まるように、レビューもテストもした。
レビューやテストにかける時間が増え、生産性が上がるどころか下がってしまった…

週次や月次の報告会議に向けて、WBSやレビュー表、課題管理表などからマクロや手作業で集計する。
多くの場合、会議直前でドタバタと報告資料をつくらざるを得ない。
なぜなら、管理表のフォーマットや記載ルール、更新期限を決めても守らないチームがいるからだ。

アジャイル開発では、コミュニケーションを通してみんなで合意する。
和を重んじることが大切である。
なぜなら、アジャイルマニフェストにそう書いてあるからだ。

チーム全体がなかよしこよしで和気あいあいとコミュニケーションできればよい。
それが「心理的安全性が高い」状態だからだ。

自動化やテストのツールを導入すると、たくさんのレポートがチャットに流れ込んでくる。
私は開発者である、開発作業に集中している。自分が出したエラーに対処はするがそれ以上はやらない。
なぜなら、それはスクラムマスターやQAの仕事だからだ。

マネジメントは、あるべき姿と現実とのギャップを埋めながらゴールに向かっていく活動だ。

プロセス品質を改善することは、よりよいプロダクトを生み出す原動力となる。
これは、従来型の開発でもアジャイル開発でも同じであって、違いはマネジメントのアプローチだろう。

従来型の開発アプローチでは、初期にすべての要求を確定し、計画通りに進めるようにコントロールする。
品質についても同じだ。計画を変更するには、途方もない労力と複雑な手続きを要する。できればやりたくないのが本音だろう。(現実はそうもいっていられないのだが…)

一方、アジャイル開発では、要求は変わっていくものであり、反復的に調整を繰り返しながらゴールへと向かう。
品質も同じように調整を繰り返すのだ。

そのためにはリアルタイムにいまの状況を把握し、将来を予測することが求められる。
この違いを踏まえたうえで、上記のアンチパターンに対する解決のヒントを示す。

アンチパターン「メトリクスとってますよ」は、プロダクトゴールの達成ではなく自動化やツールの導入が目的となってしまった例だ。
たしかに、ツールを利用することで、人力でおこなうよりも効率は上がるしミスも減るだろう。

ここで、もう一度ツール導入の目的に立ち返ってみたい。
一つは、適切なユーザーに適切なタイミングで適切なプロダクトを届けることである。
もう一つは、リアルタイムに現在の状態をデータ(メトリクス)として収集し、分析・評価してプロダクトゴールに向かってチームの計画を調整することだ。

ツールの導入は、単に作業を効率化するだけではなく、改善活動と切っても切り離せない。
アジャイルなQA活動そのものである。そうなれば、報告会議直前にドタバタと資料作成に追われることもなくなる。

なぜなら、報告すべき定量データは自動的に収集されているからだ。
先に示したアジャイルメトリクスの例のうち「バーンダウンチャート」や「ベロシティ」は多くの方がご存じだと思う。

ここでは「サイクルタイム」を例にあげてみよう。
サイクルタイムは、ある一連の作業(例えばプロダクトバックログアイテムの着手から完了まで)にかかる総時間を表す。
純粋な作業時間に加え、次のタスクに移るまでの待ち時間や作業の切り換えにかかるオーバーヘッド、手戻りなどの時間が含まれている。
これを見える化することによって改善のポイントが見えてくるのである。

作業そのものの時間を短縮するのは限界があるが、プロセスを改善することで待ち時間や手戻り時間を減らすことができる。

また、サイクルタイムからサイクル効率(サイクルタイムに占める作業時間の割合)を算出してみる。
サイクル効率が高いほど待ち時間が少ないことを表しているはずだ。

このサイクル効率を時系列で見ると、チームが安定しているかどうかが見えるようになる。

サイクルタイムは、単に開発能力を表すだけでなく、品質問題による手戻りや作業の待ち時間、作業切り換えのオーバーヘッドなど品質や開発プロセスの結果が見えるものだ。
チームの開発能力が安定しているかが確認でき、「安定している」「徐々に短くなっている」ことがよい傾向だとされている。

一方、サイクルタイムが長い、バラつきが多い、もしくは悪化傾向にあれば、品質や開発プロセスに問題があると考えることができるのだ。

メトリクスは現在の状況を把握し、時系列で捉えると将来を予測することもできる。
メトリクスは「なぜ(目的)」「何を(対象)」「どのように(収集方法、評価方法)」を決めて収集することが重要だ。
教科書的に収集するのではなく、「目的」が大事である。そして、データを蓄積して何からのアクションにつなげることがメトリクスの活用なのである。

また、基準値(目標値)は固定したものではなく、必要に応じて見直しても構わない。
収集するメトリクスを追加してもよいし、意味がないことがわかれば測定をやめてもよい。それもプロセス改善の一つである。

※ここでは「サイクルタイム」について述べたが、当然ながらメトリクスはこれだけではない。念のため。

アンチパターン「人力でなんとかしよう」は、アジャイル＝コミュニケーション重視＝よしなにやってくれる　と読み違えた例といえる。

たしかにコミュニケーションは大事である。
Whole-Teamアプローチはチーム全員で責任をとるということでもある。
しかし、間違えないでほしい。私たち一人ひとりはプロフェッショナルなのだ。

各々が高い専門性を発揮してチームをリードし、そして全員で目標を達成するのがアジャイルチームの使命だ。
マネージャー任せ、QA任せ、開発／テスター任せではない。コミュニケーションをとってなれ合いで終わるのではなく、専門家の目で意見し、自分たちで考え行動する「自立した、自己管理できるチーム」といえよう。

ときには意見がぶつかることもあるだろう。
それでチームがギクシャクするのであれば、そのチームはWhole-Teamとはいえない。
心理的安全性が高い状態とは、互いを尊重して認め合うだけではなく、専門家としての知見を存分にいえる環境があることなのだ。

また、一人ひとりがプロダクトゴールに責任をもっていれば、必然的にやることも明確になり自らアクションを起こすことになるだろう。
プロダクトバックログの受入基準や完成の定義、スプリントプランニングとスプリントバックログに曖昧さがある状態にはできないはずである。

このようななかで活動をつづけることでチーム力がアップし、それがプロセス品質の向上につながることを忘れないでほしい。

メトリクスと人力、それぞれのアンチパターンと解決のヒントを述べてきたが、それぞれ単独に取り組んだのでは限界がある。
メトリクスと人力をセットで取り組むことが大事だ。

メトリクスをとる＝どのような戦略に基づいてどのようなメトリクスをとり、どのように評価するか。
それを決めるためにはQAが専門性を発揮する領域である。もちろん、QA以外の人たちの観点で必要だと思うものがあれば提案すべきであり、全員で合意することも忘れてはならない。

メトリクスをとるための仕組みを構築するのはインフラや開発がお手の物だ。
テスターがよりよいテストをするために、開発はアーキテクチャーやプログラム構造をレクチャーすることもあるだろう。
いまのチームやプロダクトの状態をつねにモニタリングしながら改善をつづけていくのは、チーム一人ひとりの高い専門性があってこそ成しえるのだ。

オールラウンドなチームになることによって、ただ居心地のいいだけのチームから一皮むけて、チームもプロダクトも成長をつづけるようになる。
それが冒頭で述べた「Whole-Teamアプローチ」であり、「見える化」「自動化」する意味なのだ。

本コラでは、プロセス品質を切り口にアジャイルをはじめた人が陥りがちな状況とその解決のヒントを示した。

従来型の開発アプローチとアジャイル開発とでは、開発プロセスや品質に対するアプローチが異なる。
複雑な問題に適応するには、いまのチームやプロダクトの状態を知り、そしてゴールに向かって改善をしつづけなければならない。
そのためには、事実に基づいたデータ(メトリクス)が切っても切りはなせないのだ。

また、アジャイルチームは単なる人の集まりではない一人ひとりが高い専門性をもち、従来の分業制(組織のサイロ)の壁をとり払って自立した、自己管理できるチームへと成長をつづける集団なのである。

最後に、もう一度みなさんにお伝えしたいことを繰り返し、本稿のまとめとする。

* 物事の良し悪しを判断するには事実に基づいたデータ(メトリクス)が必要である。
　- 何を知りたいのか、どのように判断するかによってメトリクスを決めよう。
　- メトリクスはとりつづけなければ意味がない。スナップショットではなくトレンドを見よう。全員がいつでも見られるようにしておこう。
　- メトリクスを追加したり不要ならとるのをやめてもかまわない。必要なら目標値(基準値)も見直そう。
　- メトリクスの収集はできるだけ自動化しよう。

* アジャイルチームは、Whole-Teamとして全員がプロダクトに対する責任、品質に対する責任をもつ。
　- ワイワイガヤガヤ、仲良しこよしではない。
　- もう一歩踏み出そうよ、我々はプロフェッショナルなのだから。

本コラムが、みなさんの活動の一助となれば幸いである。