2024.02.28
短期間のイテレーションを繰り返して成果物を作り続けていくアジャイル開発。なぜアジャイル開発は短期間で開発を行うのでしょうか、ここでは品質という切り口で、アジャイル開発の本質について解説していきます。アジャイル開発の概要についてはこちらのコラムをご参照ください。
また、ここで解説する内容は、XP（eXtream Programing）なども含めて、いわゆるアジャイル開発手法と呼ばれるものに共通の考え方ですが、用語などについてはスクラムフレームワークのものを使用しています。スクラムについては、巻末に記載しています参考文献の『スクラムガイド』をご参照ください。
- もくじ
1．アジャイル開発の考え方
アジャイル開発の考え方としては、「QCDを固定して扱う」「Sを調整する」という2つがあります。この考え方はウォーターフォール開発の考え方と大きく異なります。まず、この考え方を理解することが、アジャイル開発を理解するための第一歩だといってもいいでしょう。
それでは詳しく見ていきます。
1-1 「QCD」を固定して扱う
アジャイル開発が短期間で開発を行う理由はなにか。結論から言いますと、アジャイル開発では 「品質（Quality）、コスト（Cost）、納期（Delivary）は固定のものとして扱う」 というのが基本的な考え方だからです。
より正確にいうと、固定するとは、制御しやすいサイズや目標を設定する、ということです。
1-2 「S」を調整する
QCDの項目はそれぞれ細かいコントロールを行うことが非常に困難です。なので、アジャイル開発ではコスト（C）と納期（D）に関してはイテレーションの期間を短期間で固定し、その期間で『完成』させられる実装範囲の分量を見積もって開発していきます。
この、「実装範囲」をスコープ（Scope）と呼び、QCDにSを加えた QCDS をプロジェクトのリソースの要素として管理していこう、というのがもう一つの考え方です。
このスコープはイテレーションの開始時に調整します。そして品質（Q）に関しては、イテレーションの中で達成するべき品質の目標を事前に定め、テストなどを通じてそれを達成させて初めてその機能が『完成』した、とします。
2．ウォーターフォール開発の懸念点
ここまでの内容を読んで、「いや、ウォーターフォール開発でもコストや納期は決まってるし、実装範囲なんて最初に決まっていてコロコロ変えられるわけがない。それにテストを実施して品質を確認、改善していくじゃないか。どこが違うんだ」と思う人もいらっしゃるでしょう。
それはまったくその通りです。しかし、ウォーターフォール開発の場合、開発期間が長きに渡ることも多いので、実際の工数と見積もった工数の際が広がりやすくなります。
この章で詳しく解説します。
2-1 開発期間が長いほど工数の見積もりに差異が出やすい
ウォーターフォール開発の場合、開発期間が長期間に及ぶことが多いため、開発工数や期間の見積もりに不確定な要素が入り込みやすくなります。
このことは、「不確実性コーン」（『アジャイルな見積りと計画づくり』p.27）と呼ばれる図で表すことができます（図1）。この図は、見積もりから完成まで時間が経てば経つほど、実際の量との差異が大きくなる、ということを表しています。
工数や期間の見積もりにズレが生じるとどうなるでしょうか。たとえば、見積もったリソースの分量が不足していたため、設計や実装の時点で予定よりも工数が多くかかってしまったり、期間が延びてしまったりといった事態に陥りやすくなります。（余談になりますが、見積もりのズレには多く見積もってしまう、過剰見積もりもあるかもしれません。ただその場合、是非はともかくとして、あまり問題にはなりません。パーキンソンの法則で言われているとおり、「余裕はあればあるだけ使ってしまう」ことが多いからです。）
見積もりのズレのほかに、開発範囲や仕様が変更された場合もまた、手戻りが発生してしまうため、コストや納期が影響を受けます。
そういった見積もり誤差や仕様変更などによって、設計や実装の期間が伸びたり工数が超過しまうと、後工程の期間や工数が短縮されてしまいます。
端的にいうと必要なテストがリソース不足で実施できなくなり、バグが残存してしまう、つまり品質が確保できなくなってしまうわけです。
設計や実装期間の締め切りを延ばしたり人員を追加したりする、つまりコストや納期を変更することで対応するというのは、リリースタイミングや予算があらかじめ外的要因で決められていることが多いため、細かい調整を都度実施する、といった柔軟な対応はほぼ困難です。
ここまでの話をまとめますと、 コストや納期は外部からの影響や不確実性によるズレが生じやすく、それでいてそれらを調整することは簡単にはできません。その結果、品質が確保できなくなってしまいます。
2-2 リリースできる品質になるまで対応必須の事態に
開発した製品の品質が、リリースできないほど悪い場合に、どのようになるかというと、バグがなくなるまで終われない、となってしまいます。リリースできなければ、投資したリソースの回収は全くできず、使った分が丸ごと損失になってしまうため、追加でリソースを投入してでも回収する必要があります。
ただし前述の通り、QCDのリソースは細かい調整が利きません。そのため、「リリースできる品質になるまでは、とにかくいくらかかってもいいから頑張れ！」という方向に進みがちです。（もちろん、実際にいくらかかってもいいわけではありません。追加投資に見合ったリターンが得られないのであれば、そのプロジェクトは中止という決断を迫られることもあるでしょう。）
プロジェクト期間の延伸や、残業、休出対応といった、いわゆる炎上案件の発生につながってしまうわけです。炎上しているプロジェクトというのはリソースの管理が正常にできていないという状態です。
こうなってしまうとプロジェクトを軟着陸させることが非常に難しくなります。メンバーも疲弊し、収益も赤字、評価もされないという非常に残念な事態になってしまいます。
ここで注意しておきたいのは、ここまでの話はあくまでも可能性の話で、ウォーターフォール開発であれば必ずこのように炎上する、破綻する、などと言いたいわけではありません。きちんと管理できているプロジェクトではこういうことは起こりにくいでしょう。
弊社バルテスではウォーターフォール開発のテスト業務も数多く行っています。そこでは、「コストや納期はコントロールが難しい。だから、第三者検証のプロとして、卓越したテスト技術やノウハウをもって、与えられたリソースの中で最大限の品質を確保していきます」という考え方をもって日々の業務をしています。
たとえば、ウォーターフォール開発のように開発フェーズを分けてプロジェクトを進める場合、各開発フェーズの終了時に仕様書インスペクションなどのレビューを実施し、次のフェーズに進めるかどうかをきちんと判断していくというのがベストプラクティスです。
成功するウォーターフォール開発の場合は、そのレビューをいかに確実に、効果的に実施するかに腐心します。
言い換えれば、計画、見積りとのズレをなるべく早期に、こまめに発見、解消することによって、QCDの劣化を食い止める、という考え方です。
ウォーターフォール開発における、仕様書インスペクションとQCDの関係については、こちらのコラムをご覧ください。
3．開発期間を短くし見積もりの際を減らす「アジャイル開発」
ウォーターフォール開発に対して、アジャイル開発での考え方は、開発期間を短くすることで、見積りとのズレが発生する可能性自体を無くそう、減らそうという発想である、ということになります。冒頭に申し上げた、「QCDを固定する」という考え方をもって不確実性に対抗していきます。本章でもう少し細かく解説していきます。
3-1 荒ぶる四天王とは
「QCDを固定する」ということは、変更をしないということでもあります。
アジャイル開発は「要求の変更はたとえ開発の後期であっても歓迎します」（※「アジャイルソフトウェア開発宣言」より）などと謳っているのに、ここだけみると矛盾しているように見えます。
これについては、冒頭で説明した通り、QCDに加えて実装範囲（Scope）を追加して、そこで吸収します。
QCDにこのSを加えたQCDSというのが、タイトルにある「荒ぶる四天王」です。この表現は、『アジャイルサムライ』という書籍が出典です。四天王には一番の小物がいる、というのが定説（？）なので、そいつを相手にしようということだと解釈できます。くだけた表現ですが、分かりやすい表現です、よね？
荒ぶる四天王QCDSのうち、唯一Sのみが柔軟なコントロールが可能です。コントロールとは具体的には「どれだけの量を」「どこから」実装していくのかというのをイテレーションのたびに考える、ということです。イテレーションは短期間で終了しますので、見直しのタイミングも何度も訪れます。前節でベストプラクティスとして言及した、「計画、見積りとのズレをなるべく早期に、こまめに発見、解消する」と、実は同じことをやっていることになります。
しかも、動作するソフトウェアで実際に検証することができる、というも大きな利点となります。
固定した期間の中でどれだけの機能を実装するのか、その量を一定にすることを、アジャイル開発では目指していきます。そして、実装する機能の優先順位を柔軟に変更し、その時に必要な機能、重要な機能から実装し、実際に動作するソフトウェアを開発することで、顧客の要求にタイムリーに対応していこう、という考え方が、アジャイル開発の本質です。
そこを理解せず「一週間でやればアジャイルなんでしょ」「ドキュメントを作らないでソフトウェアだけ作るのがアジャイルなんでしょ」などというのは、まさに木を見て森を見ず、ということになるわけです。
3-2 アジャイル開発のリソースの考え方
アジャイル開発でのリソースの考え方をまとめます。
- コストや納期は制御が難しいので、なるべく小さな単位で、見渡せる範囲で制御する。つまり、タイムスパンを固定したイテレーションの中でこなしていく。
- 品質についても、そのイテレーションの中で達成するべき目標をさだめ、それをクリアすることで実装機能の『完成』とみなす。
- 1回のイテレーションの中ではQCDは変更しない。ただ、イテレーションごとに振り返りを行い、目標を見直すことは行う。
- イテレーションで実装する範囲をイテレーション開始時に見積もって開発を行う。
- イテレーションの実施中は実装範囲の追加や変更を行わない。ただ、イテレーション開始時の見積もりでは、その時点での重要度、優先度によって実装範囲を柔軟に定める
アジャイル開発が、なぜ短期間のイテレーションを繰り返すのか、という基本的な考え方についてここまで解説してきました。最後に、アジャイル開発で品質をどう確保するのかという点について、スクラムフレームワークでの考え方を紹介します。
4．スプリントごとに見直す「完成の定義」
ここまで見てきた通り、アジャイル開発では、品質の確保も含めてイテレーションの中でケリをつけていきます。
4-1 チームで作成する「『完成』の定義」
スクラムフレームワークでは、このことを 「『完成』の定義」 と呼んでいます。今回完成、という言葉に『』をつけて書いてきました。なぜかというと、この『完成』がすなわち即リリースできるレベルの完成であるとは限らない、ということを表しているからです。これについては別の機会に補足説明しようと思います。
「『完成』の定義」はプロジェクト開始時にチームメンバーで作成します。そして、毎スプリント（イテレーション）ごとに見直します。たとえば、プロダクトバックログアイテム（実装する機能などのこと）に対して、以下のような「『完成』の定義」を定めたりします。各プロダクトバックログアイテムに対して、これらをすべて満たしていることが『完成』である、とするわけです。
- 実装するべき機能が定義され、すべて実装されていること
- 機能テストが設計され、実装され、すべて実行されていること
- スプリント中に発見した不具合について、すべて修正済みか、対応が決定済みであること
- 修正済みの不具合は再テストが完了し、修正が確認できていること
なんとなく当たり前のような項目が並んでいますが、スクラムにおいて、プロダクトバックログアイテムはスプリント終了時に『完成』したか、そうでないかでしか評価しません。
たとえば、この項目は50%完成、のようなステータスはありえません。「『完成』の定義」を満たしていなければ、そのプロダクトバックログアイテムはスプリントで『完成』しなかった、とみなします。
たとえ、テストが1項目しか残っていなくても、未対応の不具合が1件だけであっても、です。完成しなかったプロダクトバックログアイテムは、次のスプリントで1から作り直すことになります。(実際には、1項目であれば残業などでスプリント内で処理してしまうことが多いでしょうし、作り直しになったとしてもある程度流用が効くものもあるでしょう。ここではルールの話であるととらえてください。ただし、ルールである以上厳密に運用する必要もあります。)
つまり、品質も含めた、『完成』のハードルを越えたか越えていないかで判断することによって、作りこむプロダクトの品質を確保していく、ということになります。
4-2 定義を満たしても品質が低いなら分析して見直す
「『完成』の定義」を満たしていても品質が良くない、ということもあるかもしれません。たとえば、先ほどの項目はすべてパスしたが、リリース後に不具合が見つかってしまった、ということもありえます。
そういう場合は逆に考えましょう。なぜ、その不具合を見逃してしまったのかを分析し、スプリント内でそれをチェックしてつぶせるような「『完成』の定義」にしていけばいいのです。つまり、この「『完成』の定義」はスプリントを繰り返すごとに進歩していきます。より正確に言うと、品質をより向上させるため、あるいは生産性を上げるためにスプリントごとに見直していきます。
別の例を挙げて説明します。あるスプリントで、不具合修正の再テストが間に合わず、そのプロダクトバックログアイテムが『完成』しませんでした。使用していた上記の「『完成』の定義」では、機能テストや再テストのやり方を規定していません。そのスプリントの振り返りで、チームメンバーで話し合った結果、修正確認テストを省力化するために、下記の内容を「『完成』の定義」に追加しました。
機能テストが自動テストのテストコードとしてすべて実装され、自動テストが定期的に実行されていること
これを追加することによって、自動テストを行う必要が出てきます。ひとつのバックログアイテムを完成させるまでに必要な作業量は増加するかもしれませんし、技術的に難しいこともあるでしょう。それが要因で、しばらくはベロシティ（スプリントで実装する機能の量）は減少したり、安定しなくなるかもしれません。しかし、品質を確保しつつ生産性を上げていくためにチームが必要である、と考えて追加した項目です。
その効果は表れるでしょうし、仮に表れなければ別のやり方を考えて実践すればいいだけのことです。
生産性を向上させるために作業量を増やす、というのは一見矛盾しているように見えます。ただし、この場合は自動テストを実装するコストの方が、手動で機能テストや、不具合修正後の再テストをするコストよりも少ない、と判断されたわけです。自動テストを導入する場合は、費用対効果をきちんと分析して導入することが大切です。
このように考えて、品質を確保しつつ改善を続けていくことがアジャイルの考え方です。
おわりに
ここまで、アジャイル開発の品質に対する考え方を、「QCDS」（荒ぶる四天王）と「『完成』の定義」という概念を通じて説明していきました。アジャイル開発の根底に流れる重要な要素であり、きちんと理解することが必要であると考えます。
具体的にテストをどうするのか、という点や、アジャイル開発につきもののテストの悩みについては、また別の機会に説明していきたいと思います。
参考文献
- アジャイルサムライ ーー達人開発者への道 Jonathan Rasmusson 著 西村直人・角谷信太郎 監訳／近藤修平・角掛拓未 訳
- アジャイルな見積りと計画づくり 価値あるソフトウェアを育てる概念と技法 Mike Cohn[著] 安井力、角谷信太郎[翻訳]
- スクラムガイド (https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf#zoom=100)
- アジャイルソフトウェア開発宣言 (https://agilemanifesto.org/iso/ja/principles.html)
