アジャイル開発の品質管理技法（後編）検証と考察

アジャイル品質管理技法の検証と考察

ここでは、中編で述べた品質管理技法を具体的に検証します。

対象プロジェクト

対象プロジェクトは、SoR領域をアジャイル開発するプロジェクトです。
メンバー数は10名前後です。

SoR領域とSoE領域はデータ連携があり、SoEのプロジェクトからは新たな要求が随時発生します。

検証結果

対象プロジェクトが重ねた反復のデータから、チケットライフサイクルと以下3点との連動性を観測しました。

リードタイムと手戻り

1点目は、手戻りとリードタイム（L/T）です。

この折れ線グラフ、横軸はアジャイル開発における反復期間です。
青線は完了チケット数を示しています。
また、赤線は平均リードタイムで、緑線はそのリードタイムの標準偏差を示しています。
完了チケット数（青）は、概ね一定数で推移していますが、平均リードタイム（赤）とそのバラツキ（緑）は、ピークが二か所検出できます。
このピークは長いリードタイムのチケットが存在することを意味します。

長いリードタイムのチケットの内容をみると、多数の手戻り履歴を確認することが出来ました。

障害発生とチケット着手待ち時間

2点目は、障害発生と着手待ち時間です。

横軸はアジャイル開発における反復期間です。
各反復のチケット着手待ち時間を、箱ひげ図で表してみました。
赤の折れ線は平均待ち時間です。
箱ひげ図内の太線は中央値です。開発期間の後半（つまりグラフの右側）で、中央値が底にベタ付きしています。
ベタ付き、つまり多くのチケットの着手待ち時間がゼロです。これはチケットの即日発券、即日着手を意味します。

着手待ち時間がゼロのチケットの内容をみると、障害／考慮漏れを起因とするものでした。

チケット着手待ち時間についてもう少し観察するために、チケットライフサイクルの積上げ図（下図）を見てみます。
横軸は経過日数、縦に各チケットを積み上げています。

着手タイミングは赤と橙の境目です。
下方のチケットは赤と橙の境目すなわち着手タイミングが縦に揃っており、同時に計画的に発券されていることがうかがえます。
一方、上方のチケットは境目が乱れています。乱れはチケットの随時発券着手を示しています。

この箱ひげ図の中央値が底にベタ付きしているのは、即日発券、即日着手という、予期しないチケット発券が頻発していることを示しています。つまり、障害発生によるプロセスの乱れを示しているといえます。

品質とチケット発券時期

最後、3点目は品質安定とチケット発券時期です。

チケットライフサイクル図を長期間積上げてみました。

品質安定期を拡大して見てみます。
赤の左端、赤と青の境目がチケットタイミングです。

品質安定期には、発券タイミングは比較的揃っており「しゃっきり」とした形状が観察できます。
この時期のチケットを観察すると、仕様改善による微小な変更、微小な随時発券／即日着手があるのみでした。

対して、品質異常期を見てみると、

発券タイミングに乱れが目立ち「べっとり」とした形状が観察できます。
この時期のチケットを観察すると、障害発生や手戻りが多発していました。

チケットライフサイクルの連動性

チケットライフサイクルと（つまり開発プロセスの在り様、あるいはソフトウェアのつくり方と）、手戻りや障害発生といった品質の連動性を3点観測することができました。

定量的なデータから、品質の変動をうかがい知ることができた。といえます。

検証に対する疑問

しかし、ここでいくつかの疑問があります。

オノマトペ

擬音語や擬態語といったオノマトペを、品質管理にふつうに使う人たちが多くいるようです。
人の生命にかかわる、ハードウェア・ソフトウェアの仕様として使われています。
計測された数値ではなく、視覚や聴覚など人の感覚を言葉で表現して正常時と異常時の違いを判別しているのです。

定量的な評価

この項の検証では、グラフを目視しての判断を実施しました。 しかし、中編では、こう述べました。

実態を探る糸口を見つけることしかできないのです。
指標値は再点検の目安でしかありません。指標からは、なにか想定外の起きている可能性を検知することしかできないのです。判断するための指標では決してないのです。
再点検、つまり一つずつちゃんと見るための目安でしかありません。

統計的品質管理とはそういうものです。ウォーターフォールもハードウェアもそうです。
指標値（品質メトリクス）が、既定範囲に収まっているかどうかで品質の良し悪しを判断することはできません。

それぞれのプロジェクト・チームが、それぞれの技術、それぞれのプロセスで開発するアジャイル開発は、指標も、プロセスも、人それぞれ、チームそれぞれであることが、自然です。

考察

なぜチケットライフサイクルと品質の連動性が観測できたのか？
以下の3点が必要条件だと考えます。

比較データの正確性

1つ目は、比較データの正確性です。
これに必要なことは、

• ライフサイクルイベントが明確に規定されていること
• 機能設計能力と試験（ソフトウェアテスティング）能力によって適切なチケット粒度が保てること

です。

データ取得の容易性

2つ目は、データ取得が容易であることです。

• チケット管理ツールによって、チケットステータスの変更イベントすなわちライフサイクルデータを容易に採取できること
• ステータス変更の入力が開発サイクルの一環であること、つまり、データ入力自体が開発プロセスに内包／ビルトインされていること

データの可視化

最後3点目は可視化です。

• グラフ化によって、第三者からも確認が容易であること
• オノマトペなどによって、直感的認識が共有しやすいこと

です。

残された問題

ここまで述べた品質管理技法が適用できないチーム・プロジェクトが存在します。

チケット粒度

チケット粒度が粗く不揃いなチーム・プロジェクトには適用できません。
その解決には、適切な粒度を保つための

• 機能設計能力
• 試験（ソフトウェアテスティング）能力が必要です。

正確な入力

データの正確な入力もこの技法の適用には必要です。

• 真摯で誠実な開発者
• クラフトマンシップに溢れたリーダー
• 真偽を見極められるマネージャー

といった正直さと正直さを維持し続ける人の態度が必要です。

検証対象プロジェクトで連動性が観測できたのは、組織の根底にある「組織文化や風土」が原因ではないか？組織文化や風土が、彼ら開発者やリーダー、マネージャー資質を醸したのではないかと考えます。

残された問題を解決するには、

• 品質管理技法の適用可能なチケット粒度を保てる設計／試験能力
• 正直な入力をふつうにできる組織文化や風土

の2点が、必要です。

品質説明の要諦

アジャイル開発の品質説明の勘所はいったいどこにあるのか？
それは、以下の2点に尽きます。

• 品質と連動する代用特性を見つける。
• 代用特性をウォッチしていつもと違う変化を捉える。

中編でソフトウェアメトリクスは代用特性であると述べました。しかし、品質と連動する代用特性はプロジェクトごとに異なります。
品質と連動性の高そうなメトリクスにあたりをつけて観測し、代用特性であることを検知すること。
そして、その代用特性を継続的にウォッチしていつもとは違う変化を捉えることが重要です。

代用特性に変化が見られた場合には、当該時期のチケットやソースコードを注意深く観測し、変化の原因を見極め、適切に対応することが必要です。

「品質と連動する代用特性をウォッチして変化を検知し対応する」

これは、アジャイル開発に限らず、ウォーターフォール開発でも同様です。
アジャイル開発とウォーターフォール開発の違いは、比較データや代用特性がそれぞれ異なるだけです。

ウォーターフォール開発での品質説明となにか異なる点があるでしょうか？
もし異なると感じたのであれば、それは、「慣習によって意味を忘れてしまっている」のではないでしょうか？