はじめに
本連載では、
開発の状況をこまめに報告したり、コミュニケーションを円滑にして、情報の漏れや行き違いを防ぐことが大切です。その為にもっとも直接的で効果的な方法は、成果物(特に動作するソフトウェア)を実際に見てもらうことです。要求仕様へのフィードバックとして成果物を頻繁に顧客に提供し、実際に使ってもらうことで、要求仕様との適合性を検証するのみならず、要求仕様そのものの検証をしてもらうことが可能となります。
このような開発者から顧客へのフィードバックを如何にして有効なものとするかについて今回は整理してみましょう。
イテレーション
アジャイル開発では、こまめに顧客のニーズの変化を要求仕様として反映させていくことを説明しました。しかし、一般的には要求仕様がコロコロと変わることは良いものとは考えられていません。開発効率や品質面に与える悪影響が許容できないほど大きくなる可能性があるからです。
その為、短く期間を区切り、その間での作業内容は事前に明確にしてから作業に入るという繰返し型の開発スタイルをとります。 この作業期間のことを、イテレーションと呼びます。アジャイル開発プロセスに分類される開発手法であっても、それぞれで呼び名やイテレーションの途中の仕様変更にたいする柔軟性に違いはありますが、短い開発期間を繰り返すという点では共通しています。
そして、イテレーションの最後には当該イテレーションにおける成果物をリリースします。顧客がこの成果物を検証することで、顧客は開発の実際の進捗度を確認することができますし、要求仕様が正確に成果物に反映していることを確認できます。また実際に機能の一部を使ってみることで、要求仕様そのものの検証が行えます。
もちろん、イテレーションの最中にも要求仕様の細部の調整で頻繁に情報交換を行います。その過程で要求仕様の見直しといった効果は発生します。しかし、実際にモノを見て動かしてもらうことは、システムの詳細を知らなくてもその利便性を判断できますので、フィードバックの意味は大きく異なるでしょう。
このように開発期間を短期間のイテレーションで区切るということは、開発者から顧客へのフィードバックのタイミングを決定するという重要な意味を持ちます。この実際の成果物というフィードバックを受けて、顧客は開発の状況を正確に把握することができます。また実際に成果物を使ってみることで、本当のニーズと要求仕様の間のギャップの検証が可能となるのです。
イテレーションの設定は、開発者が勝手に行ってよいものではなく、顧客が積極的に関与し、主体的に決定していくべき重要な決定事項です。
それでは、どのくらいの長さが最適なイテレーションの長さなのでしょうか?イテレーションの長さは、アジャイル開発手法の中でもまちまちです。現実には、規模やチームの熟練度等様々な要因を考慮して決定する必要があります。ここで言えるのは、イテレーションの長さが短いほど、フィードバックの頻度が増えますので、
二段階のリリース
しかし、イテレーションを短い期間に設定するには、様々な困難が伴います。もっとも大きな要因は、リリースの問題です。上述のように、開発者は、各イテレーションが終わると、顧客に成果物をリリースして確認をしてもらうこととなります。現実問題として、イテレーションを一週間に設定することは可能でしょうか?何をもってリリースとするか? というリリースの定義次第になるでしょう。
例えば、品質チェック部門による障害系のテストを全てパスしなければリリースはできないというルールがあるとします。品質チェック部門に成果物を渡して、仕様に基づいてテスト項目を作成してもらい、テストを実施し、結果報告を受け・
一方で、リリース要件が緩い場合には、どうでしょうか?リリースに必要なコストは少なくなりますので、比較的短いイテレーションでリリースすることが可能です。リリースに取られる工数が少なくなりますので、短いイテレーションであっても十分な作業時間を確保できるからです。短いイテレーションで頻繁にフィードバックを受けることのできる反面、各イテレーション毎の成果物の品質レベルを落とすことになります。
このようなトレードオフの問題は、二段階のリリースで解消します。
まず、各イテレーションの終わりのリリースを、簡易リリースとここでは呼ぶこととします。これは、比較的緩い要件で頻繁にリリースします。そして、開発期間の最後のリリースを本リリースと呼ぶことにします。これは納品であったり、製品の製造であったりしますので、厳密な要件を満たさなくてはならないのが通常です。
つまり、開発当初から本リリースまでの本リリース期間を、各イテレーションで分割し、イテレーション毎に簡易リリースを繰り返すといったプロセスになります。
これにより、途中のイテレーションの間では比較的ゆるい要件でどんどんリリースしてしまうけれど、本当のリリースの品質は落とさない。といったことが可能になります。本リリース前には、簡易リリースとの間の品質のギャップを埋める作業が必要となります。必然的に最終イテレーションは、本リリース専用のリリースプロセスとなることでしょう。
簡易リリースの要件
イテレーション期間の設定が重要な検討事項であることは前項にて説明しました。その期間の決定をする為には、簡易リリースの要件を決めることが必要となります。簡易リリースの要件は、イテレーションの長さに大きな影響を与えるからです。 その点について、少し踏み込んでみます。
まず、成果物を満たすべき機能と品質の二軸で表現することにします。機能を横軸にします。具体的には機能一覧の項目数で表します。イテレーションを繰り返す度に横軸は増えてゆきます。縦軸を、品質とします。具体的には本リリースにおける要件の充足度合で表します。本リリースの際には、縦横最大に伸びた四角形になるでしょう。
上記の図で、緑の箇所がイテレーション毎に実装される部分です。また黄色の箇所は、最終イテレーションであるリリースプロセスで充足される部分です。問題は、簡易リリースに求める縦軸の要件です。ここでは、簡易リリースウォーターマークと呼ぶことにします。
例えば、外部リソースとの接続を伴わない単体レベルの正常系テストとしましょう。簡易リリースウォーターマークとしては、そこそこ低いレベルに設定されます。このような低いレベルのウォーターマークでは、普通にTDDを実践していれば問題なくクリアできますので、リリースコストは相当に低いです。その為、1イテレーションで追加可能な機能は増えるでしょう。またリリースコストが低いので、イテレーションサイクルを短く設定することができます。
逆に、簡易リリースウォーターマークが高い場合には、簡易リリースコストが高いことを意味します。1イテレーションで追加可能な機能は減ることになります。また簡易リリースコストを消化にそれなりに時間がかかりますので、イテレーションの期間は簡易リリースコストの消化期間以下には短縮することはできなくなります。
イテレーション設計
このように、簡易リリースウォーターマークの決定が、イテレーション期間とリリース可能な製品インクリメントの機能数に影響を与えることが分かりました。
それでは、どのようなバランスで簡易リリースウォーターマークとイテレーション期間を決定すればよいのでしょうか?
それは、テストツールや、採用するフレームワーク、メンバーのTDD の熟練度、システム特性等など、多くの要因を受けて変動します。特に、自動化テストの網羅範囲に大きく影響を受けます。イテレーションを重ねる度に実施するテストが増えてゆきますので、自動化されていないテストの実施まで簡易リリースウォーターマークに含めてしまうと、簡易リリースのコストが許容できないほどに膨れ上がるリスクがあるからです。
DB接続やSocket接続等の外部リソースの利用まで自動化できる場合には、それなりに高いレベルに簡易リリースウォーターマークを設定可能です。更に受け入れテストや障害テストまで自動化が進めば、簡易リリースウォーターマークはほぼ天井すれすれにまで達することが可能となります。
簡易リリースウォーターマークが低いというのは、何を意味するでしょう。それは、ある機能において、天井まで達しない部分のリスクを先送りしていることを意味します。テストしていれば発見できた致命的なバグがあるかもしれません。開発者は、バグの検出・
簡易リリースウォーターマークは、透明性を顧客に対して提供するという意味で、高ければ高いほど好ましいのです。
開発者の目指すところ
顧客に対する透明性を最大化するように開発者側はふるまうべきです。つまり、イテレーション期間を極力短くできるようにする。簡易リリースウォーターマークを極力高くできるようにする。といった命題が指標となるでしょう。アジャイル開発の様々な工夫と経験で改善は可能です。
このベクトルさえ共有してあれば、あとは実際の設定は現場の実情に合わせて関係者が合意できる点で着地すればよいでしょう。
大切なことは、テストの自動化を進めるなどチームの能力を高めて、イテレーション期間を維持したまま、可能な限り高い簡易リリースウォーターマークを実現できるようにすることです。その上で、顧客に透明性に対するバランスの選択の余地を与えることです。
多少、リスクを負ってでも、より早く機能の横軸を伸ばすことを望む顧客もいるでしょう。逆に、多少機能追加のスピードが落ちたとしても、追加機能に対するリスクが少ない、高めのウォーターマークを選好する顧客もいることでしょう。
最終的に透明性のレベルを決めるのは顧客です。開発者は、イテレーション設計に顧客を巻き込み、顧客の望みをかなえるべく調整を繰り返す。そこにアジャイル開発の本質があるのです。