アジャイル トランスペアレンシー ~アジャイル開発における透明性の確保について~

第2回 イテレーション設計における透明性

この記事を読むのに必要な時間:およそ 3 分

「Agile Conference tokyo 2009」開催のお知らせ

「Agile Conference tokyo 2009」12月8日(火)開催本カンファレンスは,400名規模のアジャイル開発事例を持ち,世界No.1のアジャイル開発の企業として名高いThoughtWorks社からスピーカーを招いて,最新の大規模アジャイル開発について講演していただきます。

詳細は→ http://gihyo.jp/event/2009/agile

はじめに

本連載では、⁠透明性」というキーワードで、アジャイル開発について説明していきます。第二回目は、顧客の視点からの透明性について考えます。

開発の状況をこまめに報告したり、コミュニケーションを円滑にして、情報の漏れや行き違いを防ぐことが大切です。その為にもっとも直接的で効果的な方法は、成果物(特に動作するソフトウェア)を実際に見てもらうことです。要求仕様へのフィードバックとして成果物を頻繁に顧客に提供し、実際に使ってもらうことで、要求仕様との適合性を検証するのみならず、要求仕様そのものの検証をしてもらうことが可能となります。

このような開発者から顧客へのフィードバックを如何にして有効なものとするかについて今回は整理してみましょう。

イテレーション

アジャイル開発では、こまめに顧客のニーズの変化を要求仕様として反映させていくことを説明しました。しかし、一般的には要求仕様がコロコロと変わることは良いものとは考えられていません。開発効率や品質面に与える悪影響が許容できないほど大きくなる可能性があるからです。

その為、短く期間を区切り、その間での作業内容は事前に明確にしてから作業に入るという繰返し型の開発スタイルをとります。 この作業期間のことを、イテレーションと呼びます。アジャイル開発プロセスに分類される開発手法であっても、それぞれで呼び名やイテレーションの途中の仕様変更にたいする柔軟性に違いはありますが、短い開発期間を繰り返すという点では共通しています。

そして、イテレーションの最後には当該イテレーションにおける成果物をリリースします。顧客がこの成果物を検証することで、顧客は開発の実際の進捗度を確認することができますし、要求仕様が正確に成果物に反映していることを確認できます。また実際に機能の一部を使ってみることで、要求仕様そのものの検証が行えます。

もちろん、イテレーションの最中にも要求仕様の細部の調整で頻繁に情報交換を行います。その過程で要求仕様の見直しといった効果は発生します。しかし、実際にモノを見て動かしてもらうことは、システムの詳細を知らなくてもその利便性を判断できますので、フィードバックの意味は大きく異なるでしょう。

このように開発期間を短期間のイテレーションで区切るということは、開発者から顧客へのフィードバックのタイミングを決定するという重要な意味を持ちます。この実際の成果物というフィードバックを受けて、顧客は開発の状況を正確に把握することができます。また実際に成果物を使ってみることで、本当のニーズと要求仕様の間のギャップの検証が可能となるのです。

イテレーションの設定は、開発者が勝手に行ってよいものではなく、顧客が積極的に関与し、主体的に決定していくべき重要な決定事項です。

それでは、どのくらいの長さが最適なイテレーションの長さなのでしょうか?イテレーションの長さは、アジャイル開発手法の中でもまちまちです。現実には、規模やチームの熟練度等様々な要因を考慮して決定する必要があります。ここで言えるのは、イテレーションの長さが短いほど、フィードバックの頻度が増えますので、⁠透明性」が高くなるということです。つまり、短いイテレーションほど、基本的には好ましいと考えて下さい。

二段階のリリース

しかし、イテレーションを短い期間に設定するには、様々な困難が伴います。もっとも大きな要因は、リリースの問題です。上述のように、開発者は、各イテレーションが終わると、顧客に成果物をリリースして確認をしてもらうこととなります。現実問題として、イテレーションを一週間に設定することは可能でしょうか?何をもってリリースとするか? というリリースの定義次第になるでしょう。

例えば、品質チェック部門による障害系のテストを全てパスしなければリリースはできないというルールがあるとします。品質チェック部門に成果物を渡して、仕様に基づいてテスト項目を作成してもらい、テストを実施し、結果報告を受け・よほど小規模のソフトウェアで無い限り、毎週のリリースは不可能でしょう。このように厳密なリリース要件を満たす必要がある場合、リリースのコストは相対的に高いものとなります。リリース要件を満たすために必要な工数が増えますので、イテレーション期間中に占めるリリースに要する工数の割合も増大します。その代わりに各イテレーション毎の成果物の品質レベルは向上するでしょう。

一方で、リリース要件が緩い場合には、どうでしょうか?リリースに必要なコストは少なくなりますので、比較的短いイテレーションでリリースすることが可能です。リリースに取られる工数が少なくなりますので、短いイテレーションであっても十分な作業時間を確保できるからです。短いイテレーションで頻繁にフィードバックを受けることのできる反面、各イテレーション毎の成果物の品質レベルを落とすことになります。

このようなトレードオフの問題は、二段階のリリースで解消します。

まず、各イテレーションの終わりのリリースを、簡易リリースとここでは呼ぶこととします。これは、比較的緩い要件で頻繁にリリースします。そして、開発期間の最後のリリースを本リリースと呼ぶことにします。これは納品であったり、製品の製造であったりしますので、厳密な要件を満たさなくてはならないのが通常です。

つまり、開発当初から本リリースまでの本リリース期間を、各イテレーションで分割し、イテレーション毎に簡易リリースを繰り返すといったプロセスになります。

これにより、途中のイテレーションの間では比較的ゆるい要件でどんどんリリースしてしまうけれど、本当のリリースの品質は落とさない。といったことが可能になります。本リリース前には、簡易リリースとの間の品質のギャップを埋める作業が必要となります。必然的に最終イテレーションは、本リリース専用のリリースプロセスとなることでしょう。

画像

簡易リリースの要件

イテレーション期間の設定が重要な検討事項であることは前項にて説明しました。その期間の決定をする為には、簡易リリースの要件を決めることが必要となります。簡易リリースの要件は、イテレーションの長さに大きな影響を与えるからです。 その点について、少し踏み込んでみます。

まず、成果物を満たすべき機能と品質の二軸で表現することにします。機能を横軸にします。具体的には機能一覧の項目数で表します。イテレーションを繰り返す度に横軸は増えてゆきます。縦軸を、品質とします。具体的には本リリースにおける要件の充足度合で表します。本リリースの際には、縦横最大に伸びた四角形になるでしょう。

画像

上記の図で、緑の箇所がイテレーション毎に実装される部分です。また黄色の箇所は、最終イテレーションであるリリースプロセスで充足される部分です。問題は、簡易リリースに求める縦軸の要件です。ここでは、簡易リリースウォーターマークと呼ぶことにします。

例えば、外部リソースとの接続を伴わない単体レベルの正常系テストとしましょう。簡易リリースウォーターマークとしては、そこそこ低いレベルに設定されます。このような低いレベルのウォーターマークでは、普通にTDDを実践していれば問題なくクリアできますので、リリースコストは相当に低いです。その為、1イテレーションで追加可能な機能は増えるでしょう。またリリースコストが低いので、イテレーションサイクルを短く設定することができます。

逆に、簡易リリースウォーターマークが高い場合には、簡易リリースコストが高いことを意味します。1イテレーションで追加可能な機能は減ることになります。また簡易リリースコストを消化にそれなりに時間がかかりますので、イテレーションの期間は簡易リリースコストの消化期間以下には短縮することはできなくなります。

著者プロフィール

設楽秀輔(したらしゅうすけ)

1994年,慶応義塾大学経済学部卒業。エンターテインメント系企業にて経営管理を経験後,システムインテグレータとして金融アプリケーションなどのソフトウェア開発に従事。2007年,株式会社テクノロジックアートに入社し,現在に至る。

テクノロジックアートアジャイル開発グループグループリーダー。認定スクラムマスター。会計士補。

コメント

コメントの記入