イテレーションを回せばアジャイルか？失敗事例から考える

ITベンダとして、主にウォーターフォール型のプロジェクトに参画していますが、最近は「アジャイルアプローチを取り入れて…」という触れ込みのもと、最初に要件定義を行うのではなく、イテレーションを回し柔軟に変更を受け入れるという進め方をするプロジェクトが増えました。そのうちの一つで体験した失敗が、タイトルの疑問に繋がりました。具体的にどんなことをして、何がダメだったのか、シェアします。

何をやったか

私が参画したプロジェクトでは、初めに要件定義を行い、その後の変更は受け入れず開発を進めるのではなく、要件定義、設計、開発、テスト、レビューからなるイテレーションを回し、柔軟に変更を受け入れる、という進め方をしました。スケジュールとしては下記の様なイメージです。

スプリントを取り入れたプロジェクトの進め方

完全なスクラムではなく、あくまでアジャイルのプラクティスの一つとしてイテレーションを回すことを取り入れているだけですが、確かに1ヶ月のスプリント期間で、設計、開発、テスト、レビューを繰り返し、段階的ににシステムがよくなっていくように見えます。

何が問題だったか　対エンドユーザではなく対カウンターパートとレビューを実施していた

しかし、実際には、この進め方には問題がありました。

スプリントを取り入れたプロジェクトの進め方

実は、このスケジュールにおける「レビュー」とは、実際のシステムを使うユーザではなく、作る側であるユーザ企業側のカウンターパートと共に行っていました。そして、ユーザが実際にシステムに触るのは、3ヶ月後の「ユーザートレーニング・引継ぎ」のタイミングでした。この進め方は、確かにITベンダ側とカウンターパート側の間においては、認識齟齬の解消や変更要求の受け入れを素早く行うことができます。しかし、エンドユーザ（市場）の反応という最も重要で、かつ予測が難しいものに対して、まったく対策ができていなかったのです。

そして、ユーザトレーニングを行った結果、カウンターパートとのレビューでは出てこなかった多くの指摘が上がり、かつウォーターフォールと違い変更要求を柔軟に受け入れるという進め方にしてしまったがために、プロジェクトを延伸させてリリースが遅れる、という判断になってしまいました。

*このやり方の罪なところは、カウンターパートと進めているときはクイックに要件を取り込めているので、お互いに「うまく進んでいる」と感じてしまうところです。しかし実際は、市場の反応という最大の不確実性を一切減らせていなかったのです。

*なお、そもそも完全なアジャイルであれば、プロジェクトの計画段階で納期を約束することができないため、「延伸」や「リリースが遅れる」という言葉自体が適切ではないと思いますが、今回は悪い意味でのハイブリッド型にしてしまっているためこれら言葉を使っています。

どうすべきだったか　スプリントレビューにエンドユーザを呼ぶ

根本的な話をすれば、そもそも初めから中途半端なことをせず、完全なスクラムを実践すべきだったなどありますが、ひとまず今回の進め方をできるだけ変化させないという前提のもとだと、スプリントレビューに必ずエンドユーザを呼んで頂くべきでした。

さらにこの進め方は、ITベンダ側としてはもう一つ別のメリットがあります。それは、クライアント社内のエンドユーザ（多くの場合は事業部門）とカウンターパート（多くの場合はIT部門）の力関係を知ることができます。あまりないですが、カウンターパートが力を持っている場合は、基本的にカウンターパートと合意して進めていけば問題ないことがわかります。一方で、（ほとんどの場合はそうですが）エンドユーザが力を持っている場合は、カウンターパートだけと合意しても後でひっくり返されるリスクが高いことがわかります。

まとめ

アジャイルにおけるイテレーションは、市場・エンドユーザの反応を確認し、こまめに方向修正（スクラムの言葉を借りると「検査と適用」）をするためのものです。そのため、カウンターパートだけとイテレーションを行っても無意味で、最終的なエンドユーザを必ずレビューに呼ぶような進め方にすべきです。

以上です。

補足: エンドユーザを呼んだ場合に想定される問題

補足として、エンドユーザを呼んだ場合に想定される問題についても考えておきます。

カウンターパートだけでなく、エンドユーザをレビューに呼んだ場合、レビューのたびに変更を求められ、決められた期間内（上記の例の場合は3スプリント）で、リリース可能な状態にできない可能性があります。

ウォーターフォールではこの問題に対し、要件定義フェーズで要件を出し切り、それをもとにスケジュールを立てた上で後続フェーズをはじめ、後続フェーズでは要件の変更を受け入れない（ただしユーザから見たシステムの価値を犠牲にして）ことで解決しようとします。

しかし、今回のように変更を柔軟に受け入れるが納期は決まっている、という進め方をしている場合、この問題が起こることは避けられません。これに対しては、カウンターパートがオーナーシップを持ち、要件の優先度付けを行っていくしかないでしょう。事前に要件に対する優先度付けの基準を明確にし、ユーザに説明してからレビュー会を始めるなどの工夫をすることで、リスクを減らすことはできます。