アジャイル開発による品質改善の事例

ソフトウェアテストで著名な秋山さんがSQIP分科会で細谷さんの講演をTwitterでログ公開されていたのでリンクしておく。
内容がとても為になると思う。

【元ネタ】
日科技連 ソフトウェア品質 第6回特別講義 「アジャイル開発での品質向上への取り組み」 - Togetter

【1】ここでのアジャイル開発は、Scrumをベースとした開発のようだ。
つまり、要求をプロダクトバックログに一覧化するプロダクトオーナー、プロダクトバックログを元にスプリント単位で開発していくチーム、プロダクトオーナーとチームを側面支援するスクラムマスターの3つの役割がある。

「品質の問題が発生する要因として、『階層構造＋オーバーコミット』がある。オーバーコミットはスコープとコストに矛盾がある状態です。上の階層から実行部隊に矛盾が落ちてくる。この矛盾を上に上げて解消するためのロスがある。」という細谷さんの指摘は鋭い。

プロダクトオーナーが要求をまとめても、納期や工数の観点から、決められた納期までにリリース可能な要求の数には限界がある。
実際の現場ならば、リリース可能な要求の数はとても少ないだろう。
なのに、特に日本人は責任感が強すぎるために、残業や休日出勤してまでも、自分たちが制御できる範囲を超えた要求をコミットしようとしてしまう。
そのしわ寄せが、製品の品質劣化という症状として現れる。

細谷さんの回答としては、「『階層構造＋オーバーコミット』の問題を解消する方法としてスプリントがあるのではないかと考えています。優先順位を立てて、現場が、工数的にできる分だけにスコープを絞り開発をしていく。『甘いんじゃないか』という見方もあるかもしれないが、トータルとして効率が良くなるという考え。」で進めているらしい。
その考え方はとても現実的。

Scrumを実践した場合、リスバーガーのたとえ話のように、本来は顧客が取るべきリスクを開発チームが引き取って、製品自身の品質を劣化させて納品してしまうことはしない。

細谷さんの過去の発表も参考になる。

アジャイル開発でソフトウェアの品質を高める方法 － Publickey

【2】また、「アジャイル開発ではプロセスと型を大事にしています。自分たちが狙った品質を作ることができるプロセスになっているかを常にケアすることが大切です」という細谷さんの指摘もうなずける。

Scrumにおけるチームの自己組織化は、チームのメンバー自身が日々の活動のフィードバックを受けて、自分たちで問題を解決していく。その活動をスクラムマスタが支援する。
プロセスとしては、ペアプロや小規模リリースなどのプラクティスがあるだろう。型としては、自動テストや継続的インテグレーションのような技術があるだろう。
それらを自分たちチームのコンテキストに合わせて、製品の品質を向上させるために使う。

CEGTestという原因結果グラフのツールを使って、デシジョンテーブルを作って、自動テストケースとしてプログラムに取り込む手法を使ったという話も興味深い。
製品の仕様を原因結果グラフで書き表せるだけの技術力があれば、仕様を細かなレベルまで理解できているはずだし、単体テストケースの作成にも役立つだろう。
結果として、プログラムの複雑度が20以下になったという点も興味深い。

ソフトウェアテスト技法ドリルの感想: プログラマの思索

複雑度と単体テストケース数の相関関係: プログラマの思索

【3】アジャイル開発のドキュメンテーションに関しては、「ドキュメントの話題に移ります。ドキュメントについて『いつ』『誰の』役に立つのだろう？ と考えることが重要です。開発のため、テストのため、保守のため？？」と問題提起している。

「実装のため・保守のため・合意形成（契約、投資価値判断）のため、、、そのドキュメントは何のための情報ですか。それをしないとどんな問題が起こりますか。短期的・長期的視点で考える必要があります。」と。

この考え方については以下の記事を読んだ方が早い。

アジャイル開発におけるドキュメンテーションの実際(1) ―― 本当に必要ですか？ そのドキュメント｜Tech Village （テックビレッジ）　／　CQ出版株式会社

【4】「（第三者品質保証組織がアジャイルにどう関与したらよいかという質問に対して）スクラムマスターの支援をするのが良いと思います。どういう計測（実感含む）をして品質の確認をするのかについて相談に乗ってあげてください。」という指摘は納得できる。
QA部隊は、リリース判定の権限も持つので、どうしても開発部隊と衝突しやすい。
むしろ、QA部隊は手を出さず、開発部隊を側面から支援する役割の方がうまくいくのでは、という指摘。

【5】細谷さんの講演では、事前に参加者を4人のグループに分けて質問内容をPostItに書き出してもらい、タスクボードにToDoで貼りつけた後、講演後にPostItの質問が解決されたかどうかをチェックする仕組みで話されたらしい。
「参加者が講義に主体的に取り組む効果と、付箋を元にプレゼンを動的に組み立てることによる満足度向上（後から質問をもらっても手遅れになる）を図る手法らしい。」が目的だそうだが、参加者のフィードバックを早めに受け取れるし、それゆえに参加者の満足度も高まる利点もあるだろう。
そう言えば、AgileTourOsaka2012でも、講演かんばんを使っていたのを思い出す。

アジャイル開発と品質改善は、古くて新しいテーマ。
品質をどうやって担保するか、という問題は、今後も探ってみる。