アジャイル開発におけるプロジェクト成功の定義 - アート・オブ・アジャイル デベロップメント -

ようやく電車でPDFを読む環境ができたのでオライリーで購入した「アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE)」のPDFを読み初めました。

アジャイル開発では勝手なやり方をせずに数ヶ月は続けるように書かれているものの、どのようにプラクティスを選択追加したかが書かれているなど、現実的な内容が書かれています。

数年前の本ですが、アジャイル開発を考え直す良い機会になっています。まだ、読みだしたばかりですが、「成功の定義」がアジャイル開発と従来の開発の本質的な違いではないかと思っています。

この成功の定義を除くと、アジャイル開発は従来の開発と対局というよりも、その延長線上にあるのではないかとも思っています。

本の内容とは少しずれますが、私なりに考えた従来の開発法の仕組みをの延長線上にアジャイル開発のある事を説明して、成功の定義に触れたいと思います。

開発標準

義務的に捉えがちな開発標準ですが、本来は良いプロセスを示すことで、それを現場が身につけて、組織的に改善することを目的としています。

アジャイル開発では、これを繰り返しのリズムで実現しています。開発標準でもトレーニングや経験が必要なように、アジャイル開発では日々の繰り返しや開発の繰り返し(イテレーションまたはスプリント）のリズムによって、開発プロセスを身につけて経験を蓄積します。

メトリクスの収集

プロジェクトでメトリクス(定量的なデータ)を収集する目的は、状況を把握することです。開発規模やレビューの指摘件数、障害数などを収集する事で、予定通りプロジェクトが進んでいるか、特殊な状況が生じていないかを確認します。

アジャイル開発ではバーンダウンチャートのほか、タスクボードやカンバンバードなどによる見える化、繰り返しの中でのレビューによって状況を把握します。

テーラリングと計画の変更

テーラリングはプロジェクト固有の状況に合わせて、標準プロセスに定義されたやり方を変える事です。テーラリングはプロジェクトの最初にプロセスを変更して計画を立てますが、開発中に計画を変更する事もあります。障害が想定よりも多いなど、異常なメトリクス値が得られた場合は、テストやレビューの追加など、計画を変更します。

アジャイル開発では、繰り返しの中でふりかえりを行って改善策を検討します。次の繰り返し作業の最初に行われる計画ゲームの中で、改善策を組み込みます。

フロントローディング

フロントローディング とは、後の工程で発見された問題を、早期の発見や対策を可能にすることです。障害の原因を取り除けるようにチェック項目の追加、静的解析ツールや自動テストの導入、などがあります。もちろん、実装しなければ分からない、実現可能性や性能、ユーザビリティ、などはプロトタイプを作成して確認します。

アジャイル開発では繰り返しの単位で実装と動作確認をします。漸増的に実装することで確認を後回しにしません。こうして、確認された部分を増やしていきます。

いずれにしろ大切な事

このように考えると、従来の開発法とアジャイル開発は対立的というりも、発展的に見えてきます。仕組みを関連づけて考えれば、理解が深まって適用範囲が広がるのではないでしょうか？

ソフトウェア開発の問題に対する従来法の仕組みがアジャイル開発の仕組みに発展したと考えた場合ても、変わらないものもあります。ソフトウェア開発で大切なのは、技術力、モチベーション、コミュニケーション、など、チームの力を示すものです。チームで開発する場合には、考慮しないといけません。

技術力を除いたものはアジャイルマインドと呼ばれ、体系化されたものはプロジェクトファシリテーションと呼ばれます。仕組みだけでなく考え方も大切なものです。従来法でも大切にする人は大切にするし、アジャイル開発の仕組みだけを強制しても身に付かないものだと思います。

プロジェクトの成功

アート・オブ・アジャイル デベロップメントを読んでいると、従来の開発法との違いを明確に分けるものが載っていました。それはプロジェクトの成功の定義です。

従来、ソフトウェア開発の目標はQCD（品質、コスト、納期）とされてきました。品質は本来はライフサイクル全体で評価すべきですが、リリース時には基準を満たしている事の確認しかできません。そこで、基準を満たした後のリリース時に予算と納期を守る事がプロジェクトの（ひとまずの）成功とされてきました。

しかし、この本の６ページには

「アジャイル手法では、価値を提供することとコストを削減することを重視して成功を達成する」

とされています。従来の「品質」と「納期」が「価値の提供」に置き換わっています。

暗黙のWin-Winから「価値の提供」へ

「価値の提供」は、従来の開発でも意識されていました。しかし、それはWin-Winの関係と呼ばれているもので、開発側だけが利益を得るのでも、顧客だけが利益を得るのでもなく、顧客に利益のある形で開発というビジネスを行うものと考えられていました。

かつて高機能なソフトウェアを開発する場合、品質、特に信頼性の確保が困難でした。品質問題によって納期が守れなくなる事が多く、とにかくソフトウェアの信頼性を高める事が重要でした。信頼性の高いソフトウェアをリリースする事が、その後のクレームによる保守コストを低減し、Win-Winの関係を実現すると考えられていました。

時代は変わり、高機能なソフトウェアの開発が比較的容易になり、テストの自動化や実装優先と組み合わせる事で、早い時期から利用可能な動くソフトウェアを提供する事が容易になりました。

すると、動くソフトウェアが得られるだけではビジネスに勝てなくなり、顧客のビジネスにとってより価値のあるソフトウェアの実現が求められるようになりました。つまり、ソフトウェアの品質に求められるものが、「信頼性」からROIの「効果」に変わりました。

あたり前を実現するのはアジャイル開発だけではない

このように考えるとアジャイル開発は時代の変化にあわせて、暗黙的なゴールだった「あたり前のゴール」を明示したと言えるでしょう。変化するビジネスの中では、開発対象のスコープを変化できるアジャイル開発は、顧客の価値の創造に向いているでしょう。

しかし、本当にアジャイル開発でないと実現できないかと言うと、そうでもないと思います。

組み込みソフトウェアの世界では、ソフトウェアのダウンロードが可能なものが増えてきましたが、やはり一定期間のスコープ（仕様）の凍結が必要な場合も多いでしょう。

また、法律に関わるソフトウェアなど仕様が明確なものは、段階的な開発は可能ですが、スコープの変更はある程度計画できる範囲に限定されるでしょう。

そのような分野では、Win-Winの関係が成り立たないかというと、そうでもないでしょう。顧客の価値を無視して契約だけを守る最低限のソフトウェア開発や、仕様変更はいっさい受けない頑固なソフトウェア開発、では仕事がなくなるからです。

従来の開発方法をベースにした場合でも、チーム開発の大切なことを守り、顧客に価値を提供するために、現場では色々と工夫されているでしょう。

チケット駆動開発でも、「[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発」に書いたように、色々と工夫できると思います。

まとめ

アジャイル開発と呼んでも怒られないような開発もする事もありますが、アジャイル開発をしてるかと聞かれると「していない」と答えています。

アジャイル開発は目的でないし、プラクティスを厳密に守ろうとしていないからです。しかし、アジャイル開発が大切にしている価値観には共鳴できる事が多く、常に意識しています。この本にある成功の定義は、ソフトウェア開発とは一体何かを説明してくれています。

有名なアジャイル開発の方法は良くできたパッケージです。そのまま適用できるなら、それなりの効果が期待できます。しかし、適用が難しくカスタマイズして利用したい場合やプラクティスだけを利用したい場合もあるでしょう。その場合は、アジャイル開発の仕組みを、良く理解していないとうまくいきません。

この本は典型的なXPだけではなく、カスタマイズされた現実のアジャイル開発の方法が書かれています。注意深く読み進める事で、よりアジャイル開発の理解を深められると思います。