イテレーション開発のノウハウ

イテレーション開発とは、動くレベルのシステムを少しずつ提供していく手法です。考え方によっては従来の保守開発に近い手法とも言えます。イテレーション開発をすればリスクが少なく高い品質のサービスを提供できる、と言われていますが自分の周りでは必ずしもそうではないようです。「何度も動くシステムをお見せして確認していました。」というプロジェクトがあったのですが、開発後半に要件の漏れや齟齬が大量に発覚し大きなトラブルになってしまいました。これから実際に発生した事例を確認しながら、どうしたらイテレーション開発を成功させることができるか考えてみましょう。

顧客の操作確認が無かったケース

あるプロジェクトでは、イテレーションごとにお客様から意見や課題を指摘しもらっており順調に推移しているように見えました。しかし、リリース1カ月前に数多くの要件漏れや矛盾が発覚しリリース延期となってしまいました。開発側のリーダーは「何度も確認しOKだったはず」と主張していましたが、お客様は「矛盾や漏れが多くこのままでは受け入れできない。正しい要件を提示できていなかったかもしれないが、開発ベンダーなら気づくべき」という主張で結局リリースを延期せざるを得なくなってしまいました。確かに内容を確認すると誰でも気づきそうな漏れや矛盾が多々ありました。

実はこのプロジェクトでは、レビュー時に開発担当者が動くシステムにアクセスしてデモを見せていただけでした。確かにイテレーション開発で動くシステムを作り続け実際に動かしていたのですが、操作する人が開発者だけではその効果はほとんどありません。お客様自身にアクセスしていただき操作していただかないと矛盾や漏れには気づきにくいものです。

キーマンへの確認

いくつか自分が担当した案件で、開発後半に大きな要件変更を受けざるを得なくなったことがあります。影響範囲が大きい機能については開発前半に何度も確認したのですが、開発後半になって「やっぱりNG」となったことが何度かあります。これは担当のお客様が「OK」と言っても、お客様側のキーマン(上司)の方から「NG」とされたケースでした。「以前OKとしていたから変更要求は受けられない」というプロジェクトもあるかもしれませんがそれではイテレーション開発の価値が半減です。必要な変更要求は受け付けますが、影響範囲の大きい対応はお客様にとってもデメリットです。できる限りキーマンの方を見極め、早期から確認していただく努力が必要です。

イテレーションが長いケース

最近では1週間から2週間、長くても1カ月のイテレーションが推奨されています。以前、2カ月のイテレーションを全部で3回繰り返すというプロジェクトに参加したことがあります。そこでは、1回目のイテレーションではデータベースの接続とテストに問題があることがわかりました。2回目では新たにフレームワークの問題が発覚しました。3回目では大きな問題は起きず生産性は上がったのですが、1回目、2回目のイテレーションではほとんどまともに動くシステムにはなっていなかったため、開発チームはかなり苦労をすることになってしまいました。もし短いイテレーションなら3回目以降から生産性が上がり、開発後半で無理な作業をせずに済んだはずです。

テストが自動化されないケース

イテレーション開発は動くシステムを継続的にメンテナンスしていく手法とも言えます。開発経験が長い人ならわかると思いますが、動いているシステムを修正すると思わぬデグレードが発生するものです。デグレードを防ぐためイテレーション開発ではテストの自動化を導入すべきです。あるプロジェクトではテストの自動化をせずイテレーション開発をしていました。イテレーション回数を重ねるごとに想定外の障害が数多く発生し、テストの進捗がかなり悪くなっていました。テストチームが障害を発見し開発チームが障害を修正していたのですが、修正が終わるとさらにバグが増えるという悪循環でした。それでもなんとかリリースしていたのですが、リリース後にかなり稚拙な障害が多く発生し、お客様には「これでは受け入れできない」とまで言われてしまいました。手動でのテストには限界もあります。コストや期間が足りないのであれば余計にテスト自動化が必要です。

ドキュメント修正が大変なケース

イテレーション開発ではイテレーション後に仕様が変更されることがよくあります。本来なら仕様が変わるたびにドキュメントに反映しなければいけないのですがやはり問題があります。「ドキュメントを変更するために時間をとられてしまい生産性が悪くなる」「そもそもドキュメントを書かなくなる」といった問題が生じます。また、ドキュメントを書かないと一体何が正しいのか開発側でもよくわからなくなることがあります。お客様ですら「この仕様はなぜこうしたんだろう」などと悩むこともしばしばです。ドキュメントは動くシステムに比べれば維持管理にコストを掛けるべきではありませんが無いと困るのも事実です。ドキュメントを簡易に維持管理するには前回の、「ドキュメントを最新に保つ効率的な管理方法とは?」を参考にして下さい。

変化を受け入れられないケース

「イテレーション開発なのだから要件変更はいつでも無償で受けてくれるんですよね」と言われたことがあります。もちろん要件変更は受けますが、何も捨てずに全てを受け入れ続けることは不可能です。多くのプロジェクトでは、「すでにFixしているので変更要求は受け入れられない」としてしまっているようです。それが本当に顧客満足につながるかはよく考えなければなりません。Fixしているからではなく何を優先するのか、そして何を犠牲にするのか(機能、リリース時期、予算など)を相談しながら進めていく必要があるのです。この部分については、次回お伝えしたいと思います。

最近の取り組み

実は最近自分が担当するプロジェクトではイテレーションという概念はありません。常時開発、常時リリースという概念で動いています。簡単に言うと、常に動くシステムを維持しながら追加の開発をしているイメージです。お客様との連携は、大雑把に言うと「現在どこまでできているか」「あとどれくらいで全てが完成するか」の2点です。

お客様からフィードバックがあればその内容を確認し、優先度についてお客様と都度認識を合わせます。この方法のメリットは通常のイテレーションより管理コストが少なく、かつ都度お客様の優先度の高い要望から順次対応していくことができる、という点にあります。一見無計画のように見え、以前のシステム開発では絶対にNGとされていた手法です。しかし、以前より開発を取り巻く環境が進化したことにより、比較的誰でも簡単に計画を変えながら実装を継続することができるようになってきたと感じています。ただこの手法はまだご紹介するには経験が足りません。ノウハウが溜まったらどこかでご紹介できればと思います。

まとめ

イテレーション開発を上手に適用すればリスクを少なく、高い品質のサービスを提供できます。しかし失敗しないイテレーション開発をするには以下に注意を払う必要があります。

• 常時お客様が操作できる環境を用意し、継続的に使用していただく
• できる限り意思決定者(キーマン)の方にも操作して確認していただく
• イテレーション回数は多く、期間は短くする
• テストを自動化する
• ドキュメントは簡易に変更できる仕組みを利用する
• 要件変更は、機能削減など合わせて優先度を決定していく

次回は、「捨てる技術IT編」と題して、不要な機能を削減していく考え方をご紹介したいと思います。

執筆者紹介

川上文夫

パッケージベンダーのグループマネージャーとして複数プロジェクトのPM、PLを兼務。要件定義からプログラミング、テスト、運用を担当している。数多くのプロジェクトのリーダーとして20年のキャリアがあり、オフショア開発の経験も豊富。独自プラクティスに軽量議事録、朝会Wiki、設計実装並列手法などがある。アジャイル系コミュニティにも所属し、記事の執筆やワークショップ登壇など精力的に活動を続けている。