photo AC
ソフトウェア開発から始まった「アジャイル」は、いまやプロダクト開発にとどまらず、ビジネス全般のアプローチとして定着しつつある。書籍『アジャイルに困った時に読む本』では、15年、50案件以上のアジャイル開発の経験を持つ著者がさまざまなヒントを公開。「理屈」や「理想」だけではない、多くの開発現場で実践してきたからこそ見えてきた「現実」に役立つアジャイルの極意を紹介している。
ウォーターフォールとアジャイルのハイブリッドは難しい
「ハイブリッド」という言葉には「2つの選択肢のいいところ取り」のイメージがあります。そのため、アジャイルを始めるときに、いきなり今までのウォーターフォールと違うやり方を取り入れるのに不安を感じる人は、「ウォーターフォールとアジャイルのハイブリッド」という考え方に安易に飛びつきがちです。ですが、安易に混ぜると大きな落とし穴が待っています。やってはいけないハイブリッドの例を3つ挙げましょう。
（1）理解不足型ハイブリッド
アジャイルマニフェストの「計画に従うことよりも変化への対応を」や、アジャイル宣言の背後にある原則の「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます」という言葉を中途半端に理解して、「変化には対応する」「要求の変更はたとえ開発の後期であっても歓迎する」というところだけをウォーターフォールに取り込もうとする人たちがいます。
すると、「要件定義の通りに実装する」のに加えて「仕様追加は無制限に受け入れる」開発チームにとっては悪夢のような状況に陥ります。当然仕事は積まれ放題で要求は止まらないのに、アジャイルだから追加費用は出さないよ、と言われてしまうことさえあります。結果、まともに動くプロダクトはできず、開発チームは疲弊して、皆が不幸になってしまいます。
（2）実装フェーズ専用型ハイブリッド
実際に2013年頃に一部の大手SIerが「ハイブリッドアジャイル」として提供していたサービスで、ソフトウェア開発の要件定義・設計・開発・テストのフェーズのうち、要件定義と設計という仕様決定フェーズをウォーターフォール、決まった仕様の実装フェーズである開発とテストをアジャイルで実施するというものがありました。
とはいえ、設計までできてしまって仕様が固まっている（その後の変化がない）のであれば、後はその通りに実装すれば良いので、アジャイルを取り入れる意味はありません。そこに中途半端にアジャイルを入れてしまったため、状況に合わせて設計書の見直しが頻発し、できあがった成果物の品質がボロボロになって結局うまくいきませんでした。
そうなってしまったのは、アジャイルを自動テストツールやテスト開発メソッドなどのツールを導入する実装フェーズ専用の技法であると考える誤解があったからだと思います。実際のところアジャイル開発では「フェーズ」という概念そのものが不要なのですが、あえて言うならユーザーストーリーリストの方向性決定フェーズ（仕様決定フェーズ）に当たる「要件定義」と「設計」をアジャイルで行い、実装フェーズをウォーターフォールで行うのであれば、意味はあったかもしれません。
（3）レイヤー分離型ハイブリッド
これもソフトウェア開発でやってしまいがちなのが、「ユーザーの要望で変更要求が頻繁に発生する画面周りを含むフロントエンドの設計はアジャイル」「データベース設計など変更が発生しないバックエンドはウォーターフォール」にするハイブリッドアジャイルです。一見、合理的に見えますが、バックエンドがウォーターフォールなので、両方の開発が完了するまでフロントエンドとバックエンドを結合して動かすテストはできません。
そして、テストをしないまま開発したフロントエンドとバックエンドを接続しても、必ずエラーが出てうまくいかないものなのです。先にバックエンドをウォーターフォールで完成させてから、フロントエンドの開発をアジャイルで行うのであれば良いのですが、同時進行ではうまくいきません。
そもそもウォーターフォールとアジャイルは全く逆のアプローチであり、組み合わせるのが非常に難しいもの同士です。両方に精通した人が要所要所で組み合わせればハイブリッドも有効ですが、「いきなりアジャイルは難しいから」という理由で安易な折衷案を取り入れるのは、かえって良くない結果を招きます。
