アジャイル?アジャイらない?

多くの開発チームにとってアジャイル開発は魅力的なものです。いろんな参加者と議論を戦わせてビシバシと計画を立てながら、熱く、あるいは淡々と最高のシステムを作り上げていく。なんと素敵なことでしょうか。一方、運用に慣れが必要なため導入に苦労している組織が多いのも事実。ちまたの記事は「どうやってアジャイル開発を導入するか」で盛り上がっています。プロジェクトマネジメントの総本山であるprojectmanagement.comでも、「Agile」がそれだけで一つのカテゴリになっているほどです。

さて、私たちIMJの事業は、多くのユーザー企業さまに発注をいただいてシステム開発を行う、いわゆる「受託」がメインです。プロジェクトの予算は厳しく制限されており、そのかわりプロジェクトが目指すべきゴールが明確に設定されます。エベレスト登山のようなもので、ここにアジャイルらしさが入り込む隙はほとんど無いように思えます。「1合目まで登ってみたら思いのほか大変だったので、目的地を高尾山に変更します」と言ったところで意味がありません。ゴールはエベレスト山頂なのです。「やるべきこと」が明確な状況でアジャイル開発を導入したとしても、あまりアジャイルのうま味はありません。

急いで付け加えますが、「アジャイルは受託に向かない」と主張したいわけではありません。ビジネス要件が不明瞭であれば採用を検討すべきですし、実際私たちの社内でも、スクラムの方法論を部分的に借用して上手くいっているプロジェクトは数多くあります。
いずれにせよ、私たちの場合はプロジェクトのゴールとマイルストーンが最初に提示されることが多いため、開発チームの意識はおのずとアジャイルよりも「昔ながらのウォーターフォール開発」に向かいやすくなる、ということです。

流れ流されウォーターフォール

改めて説明するまでもありませんが、ウォーターフォール開発は「一度工程が進んだら戻らない」という極めて単純明快なルールで運用されるモデルです。立派な開発プロセスの一つであり、正しく運用している企業も多いと思いますが、受託がメインの私たちにとってはこれも難しい選択肢になります。

まず、最初の工程である要件定義が完璧に終わることがめったにありません。必ずなにか課題が残るか、後から課題が判明します。本来ならその時点でスケジュールを延ばすべきですが、ユーザー企業さまの都合もあり、大抵の場合リリース日はそのままです。その結果起こるのが、「要件定義が終わってないけど設計を開始します」――いわゆる「さみだれウォーターフォール」です。要件定義に限らず他のすべての工程で同じことが起こります。
もちろんこれで結果的にうまくいくことも多いのですが、仕様変更の可能性がいつまでたっても排除できないためリスクが高まり、プロジェクトの成否が「いちかばちか」になってしまう可能性があります。

お客さまの業務に直結するシステムを作る以上、品質を「いちかばちか」に頼るわけにはいきません。なにか策が必要です。とはいえ、本格的なウォーターフォールほどじっくり仕様を決める時間はないし、でもアジャイルほどの臨機応変さが適切かというとそうでもない――これが今の私たちを取り巻く状況です。まさに「ウォーターフォールに短しアジャイルに長し」といったところ。
そこでスポットが当たるのが、一見ウォーターフォールのようで、アジャイルの健全性も兼ね備えた「Wモデル開発」です。

Wモデル開発

というとちょっと大げさな紹介になってしまいますが、特別なことはまったくありません。Wモデルを一言で表すと「できるだけ早くテストケースを作る」だけです。
Wモデルの骨格はウォーターフォール(V字モデル)ですが、それに対応するようにテストのプロセスが重なります。これが2つのV字が重なっているように見えるため、Wモデルと呼ばれています。

図を見ると分かるように、それぞれの開発工程に平行するようにテストケースが作られていきます。大変シンプルなアイディアなので、ほとんどのプロジェクトに適用できますし、導入するのに特別なトレーニングも必要ありません。
さて、このWモデルによってどんな利点が生まれるのでしょうか。

WEBシステム開発に関するお問い合わせ

本件に関するご相談やご質問など、こちらからお問い合わせください。
https://www.imjp.co.jp/contact/