ソフトウェア品質はプロセスコントロール

プロジェクトマネージャ若しくはマネージャとしてのソフトウェア品質
いつだったか、仲間内で勉強会をしているときにソフトウェアの品質管理の話になって、どうも話の内容が腹に落ちない。アジャイルを話すとき、エクストリームプログラミングを話しているのかスクラムを話しているのか、いったい何を話しているのかから合わせていかないと話がズレまくり、と同じようなデジャブ感になっていく。
ソフトウェアに限らないが、品質管理とは、

“プロダクトに備わるフィーチャ、つまり機能が意図したとおりに備わっていることをコントロールすること”

である。

プロジェクトマネージャ若しくはマネージャの立場なら、コードは標準化に沿っていればよく、決してエレガントである必要はない。なにより、バグがないことが第一の要求事項となる。しかし、ソフトウェアという無形プロダクト故の持ったり、触ったり、匂いを嗅ぐことができない、現物で品質を確認することができないという特性から、ソフトウェアのバグは“ゼロ”にはできないと暗黙知としてリスクを受容しているのが実際のところだろう。
ソフトウェアの品質を“意図したとおりに備わっているか”をコントロールするための検証である試験も本来であればもう少し、

“期間として確保させたい”

のに、ソフトウェアのリリース時期やコストの観点から、開発チームに

“暗黙の期待”若しくは“圧迫の期待”

として要求しているのが現実だろう。

間違った品質管理
ワタシの周りだけだと思いたいが、ソフトウェアの品質管理の話題を持ち出すと、「余裕がなくてやっていません」は今は棚上げしておくが、「試験をした結果のバグの検出数」の話をする人が少なくない。上述した、

“プロダクトに備わるフィーチャ、つまり機能が意図したとおりに備わっていることをコントロールすること”

ところから話がスタートしない。バグが試験で出ないことに話が行く。このような、「試験で検出したバグ数が少なかった」ことが大切だと話すプロジェクトマネージャのプロジェクトにアサインされているなら、試験方針が適切でなければ、バグは潜在的に潜んでいると思っていたほうがよく、可能であればさっさとそのプロジェクトから、別のプロジェクトに移った方が良い。

また、工程で検出したバグの種別を分類し、試験報告で傾向を報告だけしか活用していないプロジェクトとも品質の観点から言えば、次工程に不良を作り込む危険性が高い。

ソフトウェア品質はプロセスコントロール
なぜ、ソフトウェアはプロセスコントロールと言うのだろうか。ソフトウェア開発は、段取りに沿って作るものだ。それがウォーターフォールであれば無論だし、アジャイルのスクラムであっても、スプリント計画レビューでdeliverableを定義し、“Doneの定義”で何をどこまでやるかチームで共有する。たとえ一人でソフトウェアをビルドするとしても段取りは考える。

ソフトウェアに対して、プロダクトオーナが求める“要求仕様”が、ソフトウェアに備わっていなければ、そのソフトウェアは受け入れられないから、“要求仕様”を備わるようなアクティビティをせざる得ない。それが品質管理であり、品質を保証するアクティビティなのである。
通常、ソフトウェア開発は工程を踏むから、その工程ごとに“要求品質”が維持されているかを確認する。なぜ、工程都度確認するかは、最終工程になって品質を確認し、“要求仕様”の欠落が発見したのでは、顧客のビジネス価値の逸失になるからである。

では、工程の最後に品質を確認すればよいのかと問われれば、それだけでは不十分である。なぜなら、先の最終工程で確認して“要求仕様”の欠落を検出したのと同じ情況であって、工程の最後で発覚したということは、最悪、その工程を“やり直し”せざる得ないことになりかねないからである。

ではどうしたらよいか。

理想は、例えば試験行程中、当週の試験結果を分析し、次週にフィードバックすることだ。ソフトウェアの品質は、人が作るモノ故に“属人”的に傾向が発現する。それは、あるエンジニアが作成した“試験仕様”に品質の不良があることを意味するし、あるエンジニアが作成したフィーチャに不良が潜在していることを意味する。
試験仕様の観点で言えば、deliverableとしての“要求仕様”をどのように検証するか試験方針なり、試験の手法をプロジェクトとして決め、顧客と試験計画として合意の上、プロジェクトメンバに試験仕様として実装させる他ない。ここで大切なことは、プロジェクトメンバが執筆する試験仕様に対して、

「がんばって」
「ちゃんとやって」
「やったよね」

ではいけない。それは、deliverableにアカウンタビリティを持つプロジェクトマネージャやマネージャの発言ではない。期待をコントロール、マネジメントしなければならない。それが、プロジェクトマネージャやマネージャのミッションなのだから。
プロジェクトマネージャやマネージャが一つひとつの試験仕様を確認せよと言っているのではない。それは、プロジェクトの規模に依るが、エンジニアのリーダを置けるならそのリーダに試験計画に沿ってレビューと確認をさせればよいのであって、その確認された結果を“再鑑”することで、プロジェクトメンバのアクティビティに対して保証すればよい。これも、“再鑑”したと形式的にサインするのでは意味がなく、レビュー対象の試験仕様の抜取検査も合わせて実施するくらいのプロジェクトマネージャ自らのリソースをつぎ込むことを覚悟してかかる必要がある。
もし、それをしなければ、バグが出たとき、何倍もの自らのリソースをつぎ込むことを悪魔と約束したのだと心に刻んでおくことをわすれないように。

試験結果の傾向を短かいスパンで把握する意味には、人がdeliverableを作る時点で俗人化していると知ることがある。エンジニアは機械ではないから、同じエンジニアが作るフィーチャにもばらつきが出るし、エンジニアが違えばそれは当然のことだ。それを暗黙の期待で縛ろうとするから無理があるのであって、

そんなものだ

という観点に立てば、何をしなくてはいけないかわかるだろう。当該工程終了時に初めて傾向を見るのでは遅いのだ。それをするならリスクを受容して、腹を決めてからにすること。
プロジェクトマネージャやマネージャとして、意識して“再鑑”していれば、どの機能に不良があったか、それは誰かをトレースできるのである。それはプロジェクトマネージャやマネージャだけしかわからないことではない。ただ、プロジェクトメンバ全員に刷り込むことも可能ではあるが、その労力は果てしない。
つまりその工程内のスパンで傾向を検知することで、どのフィーチャやエンジニアにプロジェクトとしてプロジェクトマネージャやマネージャのリソースをつぎ込めばよいのかが知ることができるし、プロジェクトとしてアクションすればよいのか知ることができるのだ。