はじめに
- 受託開発でアジャイルをやろうとすると品質評価どうするの？という話になることが多い。
- 品質について今もって答えは見つけられてないし、なんかずっと悶々とし続ける気もしてる。
- これは違うなと感じてることや、現時点の自分なりの考えを整理しておく記事。
悩み
受託ウォーターフォールでの品質
私の周りの現場では「品質」＝「不具合のなさ」として、開発ベンダーとして保証せよ、みたいな話をよく聞きます。
ウォーターフォールとはいえ、同じアーキテクチャーで同じ開発プロセスで、実装機能が異なる案件を複数やって積み重ねていけば、ある程度統計的な判断もできるので、「今回の案件」と「過去の案件」を比較しながらある程度の結論を出すことはできます。
よくあるのは以下のような部分を整理して「課題」を洗い出し、その課題を対処するような活動をすることがありました。
- レビュー
- 指摘分類の偏り
- ケース
- ケース密度
- 不具合
- 埋め込み工程の偏り
- 検知工程の妥当性
- 不具合密度
- 横串的な見方
- 担当者による偏り
- 時期的な偏り（PJ前半と後半など）
なおこれはあくまで統計的な判断ができるので機能する部分はあると思っていて、何でもかんでも機能するとは思ってないです。
あと、個人的にはそもそも「不具合のなさ」の保証は非常に難しく、できたとしても労力に合わないと思っています。
アジャイルにしたときの課題・悩み
分析自体には振り返って良いものにする部分では価値があると思っています。
ただ、少なくとも「外部の基準値を策定して評価する」ってのはアジャイルでは困難になりやすいと思っています。
数字だけで評価することを考えた場合、以下あたりが難しさとして出てくると思っています。
- 設計書レビューの分析
- 設計書に対するレビュー指摘などを分析していたが、そもそもテストまでやり切るので、設計書のレビュー指摘を分析する価値がさほどない。
- 設計工程終了時点で分析していたのは、不具合を後続工程に流出するのを防ぐためであって、そもそもテストまでして確認できるなら、レビュー分析はしなくても良い。
- ケース・不具合の分析
- ウォーターフォールなどの案件ではIPAなどがケース密度を提示しており、それを基準に統計的に判断が可能だが、アジャイル案件の統計がまだ出てなくて基準にできる指標がない。
- アジャイルでは部分的な機能だけで判断することになり、そのテストケース量が妥当なのか評価が難しい。
- 統計値があったとしても、そもそもアジャイルはシステム開発現場それぞれで形が異なる可能性が高く、統計値として機能するか怪しい。
スクラムの定義だったり、周りの人から聞いたPJとしての「品質」の取扱
概ね以下のような立て付けになっているように見えています。
- Doneの定義：出荷に必要な条件をステークホルダーと合意しておく。品質的な条件もここに定義する。（概ね、「定めたテストプロセスの完遂」「全ての不具合が修正済み」など）
- スプリントレビュー：PO・ステークホルダーに実物をみてもらう。品質的な部分（絶対に機能として落とせない部分など）を含めて見てもらう。
- 定期的な振り返り：PJ初期はズタボロだったとしても、定期的な振り返りによって開発者にノウハウが蓄積されることで、どんどん品質がよくなっていく。
間違ってないんだけど、「品質は保証できてるのか！？」って詰められた経験からすると、この説明だけで顧客が納得するイメージが湧かないというのはちょっとあるなぁ、って思ってた。
ただ最近は、割と最近は顧客側のこの主張って不安から来てるんだと思っていて、こちらがちゃんと根拠持って説明すればいい気がしている。
「不具合をゼロにはできない」ってところからちゃんと丁寧に対話を繰り返していけばなんとなく道は開けていく気がするなぁという感覚を持ち始めてる。
世の中の話
個人的に一番しっくりきてる「品質」の定義
特に10スライド目のこれ
ソフトウェアは「皆で考え抜いて納得感を共感すること」によって品質を保障する
- 決して、何かを盲目的に遵守したり、基準を決めて守らせたり、規格認証を取得したり、膨大にテストすることではない。
当然、納得感の出し方として規格認証を取る、ってアプローチはありえると思ってる。
ただ、規格認証さえ取れば品質に納得感が出るかというと、そうじゃないケースは多いと思ってる。
ここを顧客とどこまで会話してすり合わせられるかな気がしてる。
事例とか
- アジャイルで品質という観点でメトリクスをどう使うか、どう使われているかの概要が知れる。
- スライド数も少ないのでざっと見てもらうのがいいかも。
- 一番記憶に残ったのはダッシュボード。開発者に自動的にリアルタイムにフィードバックする仕組みって大事だよね。
- アジャイルで言われている品質保証の戦術的なものを解説してくれてる。
- シフトレフトとかシフトライトとか言ってピンと来ないなら一回見た方が良いかも。
- メトリクスのサンプルがいくつか載ってる。
- ちょっとした解説も載ってるので良い。
その上で自分が考えたアイデアの話
いずれも顧客提案したものの実現には至ってないもの。（供養のためにあげておく）
「品質保証」を求められた場合の動き
そもそも「品質」の捉え方を変えてもらう
ここにある通り、関係者が合意する「品質」を語り合って見つけようとする活動が重要。
少なくとも、最終的に出来上がったものを評価することだけを指して「品質評価」という扱いにしていては、一生満足することはないと思う。
そもそも品質をどのように作り込んでいくか、どのように検証していくのか？というプロセス含めて、このPJとしてどうやって品質要件を達成していくのかを合意していく必要がある認識。
PJ独自基準を策定し、リリースサイクルを回しながらその基準をブラッシュアップし続ける。
サイクリックにリリースができるなら、色々基準を決めてその基準だとどうなるのかを試し続ければ良いと思ってる。
テストケース密度を上げよう/下げようとか。
サイクリックにリリースできる利点をうまく使うやり方。
よくあるケース密度や不具合密度などを基準にしてもいいし、残業時間などを測定してみても面白いと思ってる。
無理させた状況で作ったものにはやっぱり不具合も多く混入してる印象あるし。
「検証したい範囲が検証できていること」を確認するアプローチ
検証してない部分からは不具合は出る。でも、検証した範囲内であれば不具合は潰し込めるはずなので、本番に行ってから不具合は出ない。
（なお、本番環境特有の事象やタイミング障害などは検証範囲外として扱うしかない）
上記前提が共有できた上で「検証したい範囲が検証できていること」を確認することができれば良いよね？というアプローチ。
ケースレベルでの合意
何を検証するのか具体的にケースレベルで合意していく。
丁寧だが時間がかかるし、網羅性という観点ではわかりづらさは残る。
観点レベルでの合意
以下例に着想を得たアプローチ。
以下のようなのを描いています。
- テスト観点レベルで顧客と合意する。
- 各機能でケースとテスト観点を紐づけて、観点網羅されていることをスプリントレビューなどで確認するようにする。
観点レベルで合意しようとすると、やや抽象的な表現になるため、合意自体が難しくなるとは思ってる。
ある程度システムに慣れてるお客さんじゃないと難しい気はしてる。
モデルを作っての合意
端的にいえば「VSTeP使ってはどうか」という話。
観点から具体ケースまで話ができるし、図式化されることで網羅性もわかりやすく納得感も生まれやすい気がする。
難点はいきなり全部導入しようとするとすっごく難しそうというところ。
部分的に徐々に導入するのがいい気がする。
本質的な品質の向上
品質ダッシュボード
上記にもあるけど、やっぱり自動的に開発者にフィードバックできる仕組みは必要。
何をメトリクスとして取得して開発者にフィードバックするかは考える必要がある。
開発者に早くフィードバックして早く軌道修正することが大事。
そういう意味でも品質の見える化は重要。
メトリクス
色々あるけど個人的には以下あたりが重要だと思ってる。
- jUnitレベルのカバレッジ：100%は無駄なテストの作成につながるので、ほどほどで良いと思う。70〜80%あたりとか。ここを重視するんじゃなくて、データバリエーションが十分に検証されているのかを重視すべきだと思ってる。
- Cyclomatic複雑度：コードがネストしすぎてないかチェックできる。ある種の読みやすさの指標。いくつかの指標があるので、それを参考地として見えるようにしておくのはありだと思う。CircleCIとかで出力できる。
- 重複率：同じコードがどれくらい出てくるか。0にした場合、機能間の結合が大きすぎて修正しづらくなるので、ほどほどを目指すことにはなる。CircleCIとかで出力できる。
- 不具合数・出方：現時点の傾向を把握するのに使うイメージ。一定の件数を超えたら分析するなどがいいかもしれない。逆に出なさすぎるのもちょっと変。
- ビルドの成功率：ビルドプロセスが安定しているかなどを評価できます。ビルド自体に問題を抱えていると、機能実装のテストが十分に行われなかったりする。
- 技術的負債：CircleCIなどが自動的に検出してくれるものとかでも見ておくと良い。
いずれも「この閾値を超えたら合格」というものではなく、あくまで参考指標でしかない。
何をまずいと感じるかはPJごとに見極めていくしかないからこそ、初回PJとして何を目指せばいいのか分かんないのが悩ましいところ。
感覚としては以下のようにアプローチしていくのがいい気がしている。
- しばらくありのままの状態を観察する（特に基準値などは定めない）
- ある程度スプリントを回して数字が溜まってきたら、数字を見て気づきをえる。（このPJにどのような課題がありそうかを分析してみる）
- 改善アクションを打ってみて、数字がどう変わるか見る。
- 数字があまり変わらない、ないしは実感としての品質とメトリクスが乖離している場合は、別のメトリクスを導入してみる。
- エンドレス
要は、「特定の品質を目指す」というよりは「今よりも良くしていこう！」みたいなメトリクスの使い方がいい気がする。
開発プロセス
別に特別な話はないけど、結局はここな気がしてる。
どのように品質を作り込んでいくのか
結局は、技術者のスキル・経験値をどのように高めていくのか？
- 勉強会
- 振り返りの仕方（品質的な観点を入れてもらうなど）
どのように品質を検証するのか
単体テストではどこまで何をみるのか？結合テストでは？
システムテストって何するの？
など。
まとめ
- アジャイルな品質って、今の状態を見える化して、開発者に即時フィードバックできる仕組みを作り、今よりも良い品質に上げていくことを指すんだと思うよ。
- ただ、「一定の品質であること」を求めたくなるのが普通だと思ってるよ。
- だからこそ、品質に何を求めているのか関係者集まってすり合わせるのが良いよ。
- 品質ってのは最後に評価するものじゃなくて、徐々に作り込むものだし、徐々に評価するものなので、トータルでどうするかという話をするのが良いと思うよ。
次回予告
本記事は、2022アドベントカレンダー「受託アジャイル」の記事です！他にも興味あれば見てってください。
次回は、個人的なサーバントリーダーシップの解釈と示し方です。
以上です。