はじめに

あなたは、ソフトウェアの品質に満足していますか？
関係者の方とやりとりをする中で、アジャイル開発を採用した場合、従来に比べ品質がおろそかになるイメージがある、もしくはなったという声をしばしば聞くことがあります。詳しく話を聞くと、どうやらこのようなイメージを生んだ背景として、アジャイル開発に携わる関係者が概念を誤って解釈したまま開発を進めてしまっていたようでした。

こんな言葉を聞いたことはありませんか？

アジャイル開発はけっして上記のように品質をおろそかにするものではありません。今回の記事ではアジャイル開発を進める中で実際に立ち会ったケースを参考にしながら、アジャイル開発の概念や原則を再確認し、品質との関わり方を考えていきたいと思います。

ソフトウェアにおける品質とは

まずアジャイル開発抜きで、一般的なソフトウェアにおける品質の定義とは何かを考えてみたいと思います。ソフトウェア品質について、ソフトウェア開発の人類学者であるジェラルド・ワインバーグは、その著作『ワインバーグのシステム思考法』^注1にて「品質とは誰かにとっての価値である」と定義しています。この「誰か」というのは、ソフトウェアの利用者や運用者、その他のさまざまなステークホルダーが該当します。彼らの思うさまざまな価値こそがソフトウェア品質と考えられ、ソフトウェアの開発者はこれを品質要求として具体化していくのです。
品質要求を具体化する際に、ステークホルダーが感じる価値を、それぞれが独自の言葉、観点、基準でやりとりするのでは混乱が生じてしまうことがあります。
そのような行き違いを回避するために「共通言語」といえる規格が整理されています。現在では多様化する価値に合わせてJIS X 25010が品質モデルとして定義され、おもに要求どおりに作れたことを確認する「製品品質モデル」と、利用者にとって価値があるかどうかを確認する「利用時の品質モデル」が定義されています。

アジャイルにおける品質とは

冒頭で登場した、アジャイルにおけるソフトウェア品質に関する悪いイメージは本当でしょうか？アジャイル開発における品質についての方針を、「アジャイルソフトウェア開発宣言^注2」および「アジャイル宣言の背後にある原則^注3」から確認していきたいと思います。
アジャイル開発ではその活動の目的を「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」と定義しています。顧客にとっての価値とは、前節で述べた品質要求と置き換えることができます。すなわち、アジャイル開発では、顧客と同じ目線で品質要求を具体化し、それを満たした品質の高いソフトウェアを提供していく必要がある、ということです。もちろん、顧客にとっての価値とはいつまでも同じままではありません。アジャイル開発ではその点について価値とは不確実であり変化していくものとして考えており、その確認のために「動くソフトウェアを、2～3週間から2～3ヵ月というできるだけ短い時間間隔でリリースします」と定義し、短い単位で価値の確認が必要であると述べています。
また、「動くソフトウェア」というキーワードが出てきました。アジャイル開発では価値の確認について「動くソフトウェアこそが進捗の最も重要な尺度です」と、「動くソフトウェア」での確認を原則としています。
ただし、ドキュメントを作らないわけではない点に注意してください。ソフトウェアの複雑な処理や動作の網羅性を、スクラムチーム全員が共通理解を持って、継続的に開発していくためにはドキュメントが必要になるはずです。この点についてアジャイル開発では「包括的なドキュメントよりも動くソフトウェアを」と記載しており、「動くソフトウェア」のために必要なドキュメントは従来どおり作成しますが、たとえば、顧客の価値に結び付かないドキュメントは優先順位が低いとされています。

アジャイル開発現場での品質との付き合い方

アジャイル開発現場で想定されるケースをもとに、品質との付き合い方を確認していきたいと思います。ここではスクラムを利用したプロジェクトを例にしています。

どうやって品質の共通理解を得るか？

スプリントレビューの場にて。

プロダクトオーナー「この画面、表示が完了するまでの時間が今までに比べて倍以上がかかるんですが、なんでですか？」
開発チーム「表示する情報が多く時間がかかってしまっているんです」
プロダクトオーナー「遅いことは気にならなかったんですか？」
開発チーム「表示完了までの目標時間はプロダクトバックログに書かれていないので考慮してませんでした。もし表示速度を速くするなら、おそらく次のスプリントはこの対応で埋まってしまうと思います」
プロダクトオーナー「え、でもこれでは使い物にならないので表示速度を速くしてください」
開発チーム「わかりました。今後の機能も同じ性能が必要な場合、ほかのプロダクトバックログアイテムも再見積もりしないといけないです」
プロダクトオーナー「わかりました。見積もりの結果がでたら教えてください。スケジュールを調整します……」

● どうすることが望ましいか

今回のケースでは、プロダクトバックログアイテムについてプロダクトオーナーと開発チームの認識があっておらず、開発チームは性能改善、プロダクトオーナーはスケジュール調整が必要になってしまいました。もしかしたらこのような性能要件以外にも、セキュリティなどその他の品質要求にも漏れがあるかもしれません。
このような品質要求の漏れをなくすためにどのようにすることが望ましいか考えます。まず、スクラムガイドでは、プロダクトバックログはどのように定義されているでしょうか。

プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の唯一の情報源である。

プロダクトバックログがスクラムチームが目指す価値を記載する唯一のものであることがわかります。この管理にはプロダクトオーナーが責任を持ち、プロダクトに求める価値を定義して開発チームに伝え、開発チームは価値を「インクリメント」として利用可能なプロダクトに具体化します。今回はこのインクリメントの内容についての認識がプロダクトオーナーと開発メンバーでずれてしまっていました。
ここで注意したいのは、インクリメントを作成する際にはプロダクトオーナーの求める価値に加えて、「完成の定義」を満たす必要があることです。プロダクトオーナーの求める価値は顧客の立場で記載され、「システム、ビジネスロール」として「ゴール／要望」がほしい。それは「ビジネス価値」のためだ、というようなユーザーストーリーとして記載されることが多く、品質要求にまで言及しているプロダクトバックログはほとんど見たことがありません。そのため、スクラムガイドではプロダクトの品質基準として「完成の定義」を作成し、これを満たす必要があると定義しています。
完成の定義は、ソフトウェアとして求められる品質要求を定義し、スクラムチームでインクリメントについての共通認識を持つために利用されます。また、完成の定義は開発が始まる前までに準備し、品質要求に問題点がなかったかどうかをスプリントレトロスペクティブで検査し、改善が必要な場合はまた次の開発前に適応する、としていくと良いでしょう。品質要求を漏れなく定義するためには、JIS X 25010に定義される品質モデル（表1）や、組織で定義されている品質要求を用いるとよいでしょう。

表1 JIS X 25010システム・ソフトウェア製品の品質モデル

※ 出典：つながる世界のソフトウェア品質ガイド SQuaRE品質モデル活用リファレンス編 第5章 利用時の品質 品質特性表
https://www.ipa.go.jp/files/000055008.pdf

また品質要求を詳細化した結果、当初の計画以上に見積もりが大きくなってしまいスコープやスケジュールの調整が必要になることもあります。このような場合にはトレードオフスライダー（図1）を利用することで意思決定がしやすくなります。事前に顧客と予算、納期、スコープ、品質といったトレードオフの関係にある要素に対して、あらかじめ優先順位を設定してもらうことで意思決定が必要になった際の取捨選択の基準として活用できます。
これらをうまく利用することでスクラムチームとして共通認識を持った品質要求を実現できるでしょう。

図1 トレードオフスライダーの例

品質は誰が責任を持つべきか？

デイリースクラムの場にて。

開発チーム「バグがたくさん見つかってこのスプリントでは対応しきれません。次のスプリントでいいでしょうか？」
プロダクトオーナー「諦めないでほしいです！開発チームで責任をもってスプリントバックログを計画しましたよね？　その達成に向けて努力してほしいです。まだスプリントの途中なのですから、残業すればやりきれますよね？」
開発チーム「確かにそうですね！気合を入れて頑張ります！」

● どうすることが望ましいか

このケースでは、開発チームはデイリースクラムで日々の計画の見直しをしており、このスプリントではいくつかの不具合を積み残すことをプロダクトオーナーに打診しました。これに対して、プロダクトオーナーは開発チームの責任であると主張し、対応を迫っています。
開発チームは責任をとって対応しきる必要はあるのか、また不具合はどのように管理していくと良いのか、それぞれ考えてみたいと思います。

● 開発チームは責任をとって対応しきる必要はあるのか

開発チームが果たすべき責任は、スクラムガイドから抜粋すると、「完成の定義を忠実に守ることにより品質を作り込む」「スプリントの計画（スプリントバックログ）を作成する」と定義されています。前者については、完成の定義に基づいて不具合を発見できているようですので問題がなさそうです。後者はどうでしょうか。不具合などの問題が発生したことで時間が取られ、予定していたインクリメントがスプリント内で完成しそうになくても、計画どおりやりきる責任はあるのでしょうか。
スプリントバックログについては、スクラムガイド内の「スプリントプランニング」の項目にて説明されていますが、開発チームのスプリントバックログの計画の達成には言及していません。あくまで、「プロダクトバックログアイテムの実現方法について専門家としての責任をもって計画すること」、また、「その計画の達成には過去の成果に基づく経験主義による改善を続けること」を伝えています。もちろん顧客満足のためベストを尽くす姿勢は大事ですが、アジャイル開発は継続可能な開発でなければなりません。一時的に無理をしてその後の生産性や品質に影響が出ては元も子もないです。
スクラムチームがこのことを理解し、話し合いのうえでスプリントの中でどこまで進めるか考えることが大切です。

● 不具合はどのように管理していくべきか

開発の中で想定外の問題が発生し計画したスプリントバックログが消化しきれないこともあるでしょう。しかし、プロダクトオーナーの立場で考えれば、予定していたタイミングでインクリメントをリリースできないことは、ビジネスに対して影響を与えお客様の競争力を下げてしまうことにつながります。プロジェクトマネジメントの観点から不具合の発生は事前に見込んでおくことが望ましいです。
図2はバリー・ベーム氏が1981年に発表した「不確実性コーン」のグラフです。これはソフトウェアの完成までに要したソフトウェア開発コストの実績が、見積もり時の何倍であったかを示しています。企画フェーズなど、ソフトウェアの構想段階では、1/4から4倍までコストにブレがあり、開発の後半に行くにつれ、ブレが収束していきます。不具合の発生も「不確実性」の一要素です。アジャイル開発においてもこの考えは当てはまります。スプリント計画に活かしていくことでスプリント内でインクリメントが完成できないリスクを軽減できるはずです。
筆者の現場でこの不確実性コーンを活用する際のやり方を紹介します。まず、スプリント計画でタスクを作業時間で見積もるときは、不確実性を考慮せず作業が滞りなく完了する前提を置きます。すべてのタスクの作業時間の合計に対して、不確実性コーンを参考に、バッファの係数をかけます。仮に見積もった作業時間の合計が50時間で、係数が1.5だとすれば、75時間になり、この時間がスプリント内に収まれば実現可能と言えます。この係数は、スプリントの実績をもとに調整していってもよいでしょう。

図2 不確実性コーン

※ 出典： Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981

品質報告が求められたら？

スプリントレビューにて。

ステークホルダー「発生したバグの原因分析はしていますか？」
開発チーム「はい。発生したバグはすべて原因を分析し、必要に応じてプロセスやルールを改善し、再発防止に努めています」
ステークホルダー「ところで、1キロステップ ^注4あたりのバグは何件発生したか教えてもらえますか？」
開発チーム「えっと……、正確に把握できていないですが、だいたい1キロステップでバグは3件ぐらいだと思います」
ステークホルダー「会社のルールで報告対象になっているのに、把握できていないのですか？それに、1キロステップあたりのバグは10件ぐらい出ないとおかしいですよ。網羅性が足りないんじゃないですか？基準内ではないのでその理由も一緒に報告お願いしますね」
プロダクトオーナー「ルールがあったことを知りませんでした。次のスプリントでは改善します」

● どうすることが望ましいか

やや極端な例ではありましたが、このケースでは、スプリントレビューでのステークホルダーの指摘から、新たな報告が必要になってしまい、完成の定義が増えてしまいました。ステークホルダーは組織のルールで決まっているため報告するように求めてきましたが、このような場合どう進めていくことが良いのか考えてみたいと思います。
「アジャイル宣言の背後にある原則」では「シンプルさ（ムダなく作れる量を最大限にすること）が本質です。」と言及されているように、何よりも顧客の価値に直結しない作業や機能を減らしていくことが原則です。上記のやりとりを見る限り開発チームは不具合に対して本質的な対策が打てているようです。組織のルールとして、ステップ数に基づいた品質管理が義務付けられていますが、本当にその基準が顧客の価値のために必要かどうか、スクラムチームであらためて考えてみてはどうでしょうか。
また、組織のルールはその背景まで確認するとよいでしょう。その結果必要でないと判断した場合には、スクラムマスターの責務として組織に対して働きかけていくべきです。簡単なことではありませんが、顧客の価値のために高い理想を持って取り組んでいきましょう。

品質に問題あり。どうテコ入れする？

ソフトウェアをリリースしたある日。

ステークホルダー「こないだリリースしたシステムだけどさ、ユーザーから、バグが多くて使い物にならないってクレームが来てるぞ！」
プロダクトオーナー「申し訳ありません。開発チームと相談します」
ステークホルダー「いや、もういい。今の開発チームはそのままでいいから、別でテストチームを立ち上げて、そのチームにバグつぶしをさせる」
プロダクトオーナー「わかりました。たいへん助かります」

● どうすることが望ましいか

頑張ってリリースしたシステムの品質に問題があってユーザーからクレームが入り、バグの対応や組織内の説明に追われたという経験は、誰しも少なからずあるでしょう。
このケースでは、ステークホルダーの一存で、バグを発見して修正するためのテストチームを開発チームとは別に立ち上げようとしています。クレームが来ている状況であれば、この対応はしかたがないのではないか、と思う方もいるかもしれません。短期的に見れば、このテストチームがバグをたくさん発見し対処することで、一時的に品質は向上しそうです。
しかし、その後はどうでしょう。開発チームはこれまでと変わらないプロセスで、機能を追加したり変更したりするたびにバグを作り続け、テストチームはバグ対応を続けるでしょう。そして時間が経てばシステムは複雑になり、テストチームでは対応しきれなくなるほどのバグが発見されるかもしれません。
前述のとおり、開発チームは品質を作りこむ責務を負っています。アジャイルでは、「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」とあります。品質の責務を他チームに任せてしまった開発チームが、価値あるプロダクトのために良いアーキテクチャ・要求・設計を生み出せるでしょうか。
品質に問題があるのなら、まずは品質を透明化して開発チームに問題意識を持ってもらい、品質向上のための改善を促していくことが必要だと考えます。

おわりに

繰り返しになりますが、アジャイル開発は、従来型開発と同等かそれ以上に、品質を重視していることがわかったと思います。「品質」と聞くと耳をふさぎたくなる方も多いかもしれませんが、本来は品質を何より重視しているのがアジャイルです。顧客視点を持ってより価値の高いソフトウェアを作ろうとするマインドが品質向上への第一歩です。

アジャイルコラム記事一覧

https://www.intellilink.co.jp/column/agile-devops.aspx