UltimateAgileStories iteration2の記事です。

1. 1
アジャイル風の開発で集中を実現する
阪井 誠(@sakaba37)
1. はじめに
アジャイル開発のイテレーション管理を準委任プロジェクトに導入した事例を
報告します。アジャイル開発ではすべてのプラクティスを実行したほうが良いと
言われる場合もあり、そのことがアジャイル開発の技術を導入する障壁になるこ
ともあるでしょう。この事例では、他のアジャイル開発のプラクティスは導入せ
ずに、イテレーション管理のみを導入しました。導入時に開発者にイテレーショ
ン管理の効果は説明しましたが、それ以外のトレーニングを実施しないでイテレ
ーション管理を実践しました。
準委任契約においては契約による歯止めが効きにくいので、顧客の要望をその
まま受け入れてしまいがちです。場合によっては開発中の作業に割り込む形で、
無秩序に、際限なく、受け入れてしまうことになって、プロジェクトが混乱して
しまうこともあります。開発チームから見れば、
良かれと思って実施したことが、
結果的に喜んでもらえない事になり、お互いに不幸な結果になってしまいます。
しかし、もし要望を受け入れなければ、顧客が開発のリスクを受け入れているに
も拘らず、顧客の望むプロダクトはリリースが完了して次の開発が完了するまで
実現されないことになってしまいます。
紹介するプロジェクトではイテレーション管理を導入した結果、顧客に対して
短い間隔でリリースを順次実施しながらも、要望を受け入れることが可能になり
ました。また、開発者は仕様変更による混乱とその負担を避けることができ、イ
テレーション管理の導入はメンバーに好評でした。
この記事では、まず「アジャイル開発」という言葉の問題とプラクティスの事
例の重要性を説明し、イテレーション管理、プロジェクトの事例と結果について
説明します。
2. 「アジャイル開発」の問題とプラクティスの事例の重要性
「アジャイル開発」とは何か？その質問の答えは多種多様です。マインド、価
値の実現、アジャイル宣言の実践、プラクティスの実践など、色々な答えがある
でしょう。
このように意見が別れるのは、「アジャイル開発」という言葉が従来の開発法
のアンチテーゼと捉えられているからかもしれません。その意見を述べる人が属
している組織で「プロジェクトの問題をアジャイル開発ならなんとかしてくれる
1

2. 2
に違いない！」「アジャイル開発でこう変わった！」という思いがどこかにあっ
て、アジャイル開発の様々な側面を映し出してしまうのかもしれません。
このことは、アジャイル開発をバズワード化しかねないと思っています。一つ
の言葉で表せないということは、明確な実態を伴わないということとあまり変わ
らないからです。もちろん、アジャイル開発にはプラクティスがありますので、
それぞれ「どのようにする」という実施法は明確です。しかし、アジャイル開発
は単純な原理ではなく、あるプラクティスを他のプラクティスと共に使うことで
より効果を発揮するような、非常によく練られた「工夫の塊」のようなプロセス
です。個々のプラクティス間に依存関係があることから、プラクティスと共に全
体をどのように実践すれば良いかなど、アジャイル開発の基本的な内容と応用的
な内容が合わせて語られることも多いようです。
もちろん、なるべくそのまま実践してアジャイルの良さを感じることが重要だ
という意見だけでなく、徐々に進めなさいという意見もあります。しかし、現実
問題として徐々にプラクティスを導入した際の成功体験の報告はあまりありませ
ん。特に、特定のプラクティスを実際のプロジェクトに導入する際に、どのよう
に利用すれば良いかということに限定すると、 あまりにも少ないと感じられます。
そこでこの記事では、アジャイル開発のプラクティスを部分的に実践した事例
を報告します。類似の過去の事例としては川端さん （@agilekawabata）らと執筆
1
した、不完全な XP 開発でのプラクティス評価の論文 があります。 この記事で報
告するプロジェクトは、さらにプラクティスを限定し、アジャイル開発のプラク
ティスの一つであるイテレーション管理のみを導入したものです。
3. イテレーション管理
今回導入したプラクティスはイテレーション管理です(この言葉はプラクティ
スの名称としては正確ではないかもしれませんが、より実態を表す表現として使
用しています)。
具体的には、 週間もしくは2 週間にリリース期間を固定化して、
1
その期間に収まるように仕様の範囲を決めました。それと共に、リリース中に仕
様の変更を行わないようにしました。ここでは、まず一般のアジャイル開発でど
のようにイテレーション管理が行われているかを説明し、次に今回のプロジェク
トに導入する際にどのように考えたのかを説明します。
アジャイル開発ではイテレーション(あるいはスプリント)と呼ばれる期間を繰
り返して開発をします。この期間は通常1～4 週間程度とされ、その期間に収ま
るように実装する仕様の範囲(スコープ)を決めます。イテレーションの期間は週
1
O.Kobayashi, M. Kawabata, M.Sakai, E. Parkinson, "Analysis of the interaction between practices for
introducing XP effectively," ICSE'06, 2006.
http://sakaba.cocolog-nifty.com/PDF/SS2004XP.pdf (日本語) など
2

3. 3
単位に固定されることが多いようです。 特にタイムボックス管理2と言われる方法
では、より細かな時間割のような単位に分けて管理することで、イテレーション
の期間を厳密に管理します。アジャイル開発では、ウォーターフォール型開発の
ように段階的な工程ではなく、繰り返しの開発で常に価値を提供できるように(す
べてのイテレーションとは限りませんが)継続的に繰り返しリリースを行います。
リリースが複数ありますので、開発中に生じた変更要求に対してそれを受け入れ
ることが容易になります。「カンバン vs スクラム実践ガイド3」によると、かん
ばんはイテレーション中の変更を許しますが、スクラム開発ではイテレーション
中の変更を基本的に許さない原則になっています。
今回のプロジェクトでイテレーション管理に注目したのは、定期的なリリース
によって顧客に価値をあたえつつ、開発者を変更による混乱から守ることができ
る点です。従来のウォーターフォール型に準じた開発ではリリース回数が少なく、
成果物を利用できるまでに多くの変更要求が出てしまいます。もちろん、成果物
ができてから変更要求に対応するという選択肢もあります。しかし、実際には手
戻り作業が生じてしまうことや、成果物の提供が遅いことで最初のリリースまで
になんとか変更を済ませて欲しいという要望が出てしまい、リリースまでに変更
要求を取り込まざるを得なくなってしまいます。そこで、短いイテレーション期
間で順次リリースできれば、短期間を理由にイテレーション期間中の変更を待っ
てもらうことで、スクラムのようにそのイテレーション（スプリント）の開発に
「集中」できるのではないかと考えました。
4. 事例
紹介するプロジェクトは、複数のソフトウェアが同時に開発されるシステムの
一部で、サーバアプリの基盤となるソフトウェアの開発です。このような複数の
ソフトウェアで構成されるシステムの開発では、仕様をあらかじめ決めて並行開
発を進めないといけない場合が多いので、これまでアジャイル開発が導入される
ことはありませんでした。しかし、実際には開発を進めるうちに問題が発生し、
様々な追加の仕様や要望が出てきます。このため、長期的な計画で開発を進めて
いても、多くの仕様変更によってプロジェクトが混乱してしまいがちです。そこ
で、仕様変更のリスクをある程度考慮して一括の請負契約を結び、大きな仕様変
更があれば別途精算することで、変更の抑止や調整をする方法をとっていました。
しかし、今回は当初から多数の変更が予想されていたこともあって、準委任契約
で開発することになりました。
2
連載 Web 2.0 時代のソフトウエア開発手法 第22 回 “時間割”を作り，タイムボックスを意識して作業す
る http://itpro.nikkeibp.co.jp/article/COLUMN/20061010/250333/
3
カンバン vs スクラム実践ガイドhttp://www.slideshare.net/kompiro/kanban-vs-scrum-2425317
3

4. 4
準委任契約をすることで、開発側が仕様変更のリスクを取ることはなくなりま
すし、 顧客側も変更に対する自由度が増しますので、 基本的にはWin-Win の関係
になります。しかし、商品の発売時期は変わりませんので、変更を効率良く受け
入れて開発する必要がありました。また、機材の関係で客先に常駐していたこと
から変更の依頼が比較的容易な状況でしたので、仕様変更をうまく制御する必要
がありました。そこで、イテレーション管理を導入することにしました。
このプロジェクトのメンバーは障害管理ツール trac を用いて、 以前からチケッ
ト駆動開発を行なっていました。そこで今回もチケット駆動開発を実施して、チ
ケット駆動開発の基本ルールである“No Ticket, No Commit !”を守り、コードや
ドキュメントをコミットする際には、必ずチケットの番号と関連付けるようにし
ました。チケット駆動開発は、障害管理ツールの障害票に相当するチケットでタ
スクの管理を行うものですが、 タスクのチケットだけではなく、 仕様変更、障害、
課題などのチケットとも関連付けてコミットしました。関連付けられたチケット
には、詳細な状況の確認や作業を行う上で必要な確認内容等を記載できますので、
なぜそのような仕様やコードの変更に至ったのかを必要な時に確認できるように
なります。
様々な種類のチケットがコミット時に関連付けられているので、チケットは必
ずしもタスクの粒度ではなく、それぞれに適した粒度で発行しています。このよ
うに粒度の異なる様々なチケットを関連付けることを許容しているのは、該当プ
ロジェクトでは経験豊富な 2 名の開発者がメンバーで、従来のWBS 程度の粒度
である1～2 週間程度を上限とするチケットで十分管理できるからです。イテレ
ーションの周期を守れるようにチケットを組み合わせて、1 イテレーションに1
件～数件のチケットを割り当てました。過去のプロジェクトの保守作業が突然入
る場合も時々ありますので、実施期間や担当は厳密には決めませんでした。細か
な進捗を管理するよりも担当者の二人で作業を調整しながら実施する方が、好都
合だからです。
プロジェクトの計画は、1 週間あるいは2 週間ごとにリリース期間を固定化し
て、その期間に収まるように仕様の範囲を順次決めました。不確定要素の多い場
合は 1～2 回のリリース分の計画を立て、ある程度長期的な予想がつく場合には
全体を荒く、直近の1 ヶ月程度は詳細に計画して、開発を進めながら順次再計画
しながら開発を進めました。リリースの計画は常に顧客に開示して、リリース中
に生じた変更要求は次々回のリリース、つまり次回以降のイテレーションで実施
することを基本方針として決めました。
4

5. 5
5. 結果とまとめ
準委任開発の客先常駐プロジェクトにイテレーション管理を導入しました。導
入から約半年が経ちますが、予想以上にうまくいっています。リリース計画によ
ってゴールが明確になり、全てのリリースが守られています。この間に予定外の
リリースは1 度だけで、不具合対策のために緊急リリースを行いました。リリー
ス期間中に変更を受け入れない方法は、作業がやりやすくなったと開発者にも好
評です。いわば、イテレーション期間をクリティカルセクションにして、開発者
のタスクを守ったのです。
アジャイル開発には準委任契約が向いていると言われますが、今回のプロジェ
クトによって、準委任契約にもアジャイル開発風の開発が向いている場合のある
ことが分かりました。そのプロセスは、現在のプロセスを大きく変えることなく
イテレーション管理を導入したものです。イテレーション中に変更を受け入れな
いことによって、開発が混乱することなく、計画的なリリースが可能になって、
開発者は作業に集中することができるようになりました。
アジャイル開発が普及するに従って、認定、検定、標準化といったものが徐々
に増えてきました。それらはアジャイル開発の知識を普及させるうえで、大きな
役割を果たすと思われます。また、それらによって規格化されたプロセスで開発
が行われるようになり、より安定したアジャイル開発が行われるようになるでし
ょう。
しかしその反面、どのようなプロセスが最適であるかを考えることが少なくな
って、柔軟にプロセスが構築されなくなる可能性があります。軽量で変化に柔軟
に対応可能であるという特徴を持つアジャイル開発において、どこまで標準化を
すすめるか、どこまで柔軟に考える組織を追求するか、そのバランスを取ること
が求められると思います。
今回の結果は非常に小規模な一例に過ぎません。しかし、アジャイル開発その
ものではなく、アジャイル開発のプラクティスを適用することで、現状のプロセ
スを改善できる可能性のあることを示しました。今後、このような事例が増えれ
ば、アジャイル開発のプラクティスやその依存関係が明らかになり、多くのプロ
ジェクトにおいて、より最適化されたプロセスを実現できるようになるでしょう。
そして、そのような実践と事例の公開を重ねることで、標準化と最適化のより良
いバランスもやがて明らかになるでしょう。
5