アジャイルの目的

うちの会社の標準開発プロセスはアジャイルじゃなくて思いっきりウォーターフォール。まぁこういう企業はいっぱいあるでしょう…というか、ほとんどの企業がそうなんだろうな。
で、そういう中でアジャイルで開発していると、プロジェクトの状況報告する際に「なんで最初の要件から変更が入るんだ」というツッコミを受ける。つまり「変更=悪」って構図が成り立っているってこと。
確かに最初に決めた要件から何も変更しないでお客様が望んでいるモノがドンピシャで提供できるなら何も問題ない。ただ、それを本気で実現しようとすると多大な要求定義期間が必要となり、設計期間＋コストが必要となる。
お客様だって、設計書だけ見て最終イメージを膨らませて自分たちが望んでいる本当の価値を手に入れるってのは相当判断が難しいはずだ。しかも最近は設計が完了した段階で契約…って形が多いから、自分たちの要件があいまいだったり、本当は必要ないかも…と思っているものをドンドン要件に追加していくことなる。そりゃ「後から要件追加したらお金とります」って言われたらさ、怖いから「とりあえず」って機能を追加しますよ、誰だって。そうして使うかどうかもわからない機能が増え、開発工数が増え、スケジュールが伸びるってことになる。
それでいて最終的にできたものは果たして自分たちが本当に望んだものなのか？それはわからない。
で、アジャイルとなるわけ。どうせ予測してもヒットしないなら、確実な部分をできるだけ早く提供して、その結果のフィードバックを受けながら軌道修正を繰り返して最終目的地を目指していく。プラスのスパイラルを描きながら、要求を取り入れながら、進化をしながらシステムを開発する。それがアジャイル。
変更をドンドン受け入れるってなると、手戻りが発生してコストが大きくなりそうな気もするけど、「変更があるのは当たり前」という視点に立つことで、変化に強いシステムの構造であったり、開発プロセスってのを模索するようになる。実際、テストの自働化なんてのはまさに変化に対応するためのものだよね。変化がないならテストの自動化なんて必要ない。
もちろんアジャイルだから初期の要件定義はまったく必要ありません、または適当でOKですってことには絶対にならない。必要最低限の方向性やコンセプトは必要だし、真剣にプロジェクトの方向性を初期段階で可能な限り検討するのは必須。それがないとコストの予測も立てられないし。パッケージ製品なんかは開発と平行したプロモーション活動も重要なわけだから、「アジャイルなので何も決めないでとりあえずスタートします。もちろんスケジュールも曖昧なので、製品がいつできるかもわかりません」ってのはわがまま…というか単なるお子様発言（このあたりはJoelが色々と言及してたと思うけど）。
じゃあそうなると初期の要件定義はどこまでするのが妥当なの？ってことになり、これが非常に難しい。単なるサジ加減でしかないじゃない？って言われれば確かにそんな気もする。このあたりは今後も真剣に検討する必要があると思う（誰かいいアイデアあったら教えてぇー）。
で、最初の話に戻ると、ウォーターフォールに慣れている人たちにとっては「変更=悪」であり、アジャイルの「変更を受け入れることにより良いものを作る」という思想がなかなか伝わらない。変化を受けようとしているうちのプロジェクトは「悪」ってことになっちゃう。プロジェクトの目的が「当初の計画通りのプロダクトを作る」ならばそれでいいけど、そうじゃないでしょ？投資した結果に対して利益を生み出せる（そういったプロダクトを生み出せる）かどうか、それが目的でしょ？
それが「悪」ではなくて「善」なんだよってことを伝えるのは、やっぱりアジャイルプロセスの結果生み出したプロダクトが、現実に世の中に受け入れられるかどうかにかかっていると思う。その結果で証明して上の人たちを納得させる以外方法はないなぁと。それがうちのプロジェクトに課せられた使命だね。
もっとも上述したお話は、パッケージとかの不特定多数のユーザ向けのプロダクトを開発する場合のお話であって、特定ユーザ向けの開発となるとそうはいかないのが現実でしょう。なんつってもお客様との契約関係があるから。この日本で当たり前となっているお客様と企業間の契約関係がどうにならないかぎり、「初期の要件（契約内容）を計画通りに遂行できるかどうか」がプロジェクトの良し悪しの尺度となっていても仕方がないのかもしれない。