第27章 ウォーターフォールプロセスを使いこなす
先回りして手を打つ
この章では、大多数の製品開発チームが今もなお踏襲しているウォーターフォールプロセスについて見ていこう。
ウォーターフォールプロセスは、誕生してから30年以上経っていて、私も含め、エンジニアからもプロダクトマネージャーからもしょっちゅうこき下ろされているものだというのに、今でもソフトウェア製品を作るためにいちばんよく使われている手法である。
製品開発にウォーターフォールプロセスを使っている、と公言するのはダサいと思われるようになって久しい。それでも、Successive Refinement、SDLC、Phase-Gate、Stage Review、Staged Contracts、 Milestone-basedなど、呼び方はさまざまあるけれど、ウォーターフォールプロセスを使い続けるケースは多いのである。
この章では、ウォーターフォールを使ったアプローチの主な弱点について詳しく見ていく。そして、何よりもまず、ウォーターフォールで製品開発を成功させる確率を最大限まで高めるためには、プロダクトマネージャーは何をしなければならないかについて議論する。
一般原則
従来からのウォーターフォールプロセスは、概念としては実にシンプルなものだ。
1. 工程ごとの開発
ソフトウェアは、一連の工程 (フェーズ) を通して開発される。それぞれの工程は、要求仕様の文書化、ユーザーエクスペリエンスデザイン、上流工程としてのアーキテクチャの設計、下流工程としての詳細設計、コーディング、テスト、運用、というように明確に定義される。
2. 工程のレビュー
それぞれの工程は、その工程からの成果物のレビューで終了し、その工程の完了確認、次の工程への明確な移行、と続く。
ウォーターフォールモデルは、形式にこだわらずに使うこともできるし、アメリカ国防総省の標準2167A (のちに 498) のように、厳格な形式に従って適用することもできる。標準2167A とは、多くの文書による成果物とともに、開発プロセスのすべての手順について、すさまじく細かいところまで記述したものである。
その一方で、ウォーターフォールモデルの主流となっている使い方では、形式にこだわらずに、より一般化されたシナリオで利用することもできる。そのシナリオとは、こんな感じだ。マーケティング部門のだれかが市場の要求を収集して、技術部門に手渡す。技術部門は、スケジュールを立てて、アーキテクチャデザインにとりかかり、それから、もっと複雑な部分の詳細設計をやる。その後、実装、テスト、そして多くの場合ベータ版へと進み、最終的な正式版のリリースにこぎ着ける。
ウォーターフォールを使ったアプローチには深刻な限界があることについては、この後すぐに議論するが、まずその前に、長く使われてきたこのプロセスの主な特徴を認識しておくのがいいだろう。
• 経営陣は、このプロセスだと、予測ができる (と感じられる) 点を高く評価している。そうよくあることではないけれど、大規模で複雑なソフトウェア開発プロジェクトですら、かなり正確なスケジュールを作ることは可能だ。ただ、これは、完全かつ正確に要求仕様と必要な技術を理解していること、そして、仕様の変更が発生しないことを前提としている。反復型 (イテレーション) のアプローチでは、何回繰り返すことになるのかよくわからないので、経営陣は不安に思うようだ。
• プロセス全体にわたって、成果物が出てくる。多くの人たち、つまり、上司、顧客、それに一部のエンジニアまでもが、緻密で完璧な書類とデザインの図面を見ると、安心するのである。そういうものがあると、こうした人たちは、プロジェクトの完了に向けてどのぐらい進んだかを測定して、プロジェクトの状況をきちんと調べたような気になれるのだ。(ただ、その確信に根拠があるのかどうかを実証する方法はない。紙に書かれたものは、ソフトウェアとは違って、実際に動かしてみることができないからだ。) 立派な仕様書や書類があるだけで、多くの人は、根拠もないのに安心してしまうという過ちを犯してしまう。
プロダクトマネジメント上の問題点
ウォーターフォールプロセスには、よく知られている問題点がたくさんあるのだけれど、それらは、プロダクトマネージャーの立場からも特に憂慮すべきことでもある。
• 妥当性の確認が遅過ぎる
ウォーターフォールでいちばん犠牲にされていることとして挙げられるのは、通常、プロセスがほとんど終わる頃になるまで、実際に動かせるソフトウェアが存在しない、ということだ。そのため、資金の大部分が投資されてしまってからでないと、ソフトウェアが使いものになるのかどうかの見通しがほとんど立たないのである。
プロダクトマネージャーは、費用のかかる設計や実装の工程に入る前に、製品のプロトタイプを作ってターゲットユーザーで試しておくようにしなければならない。こうすることで、製品開発部門に最終的に手渡される仕様には、確実に、ターゲットユーザーできちんと検証した製品について記述することができる。
同じように、技術的に大きなリスクがある場合には、実際のアーキテクチャデザインと実装を始める前に、(エンジニアリング部門が) そうしたリスクをよく調査して、実現可能性に不安があるなら取り除いておくべきである。製品開発チームは、先に進む前に、製品仕様書がユーザーの手元に届けることができるようなものを描けていることを確認しておく必要がある。
• 変更は費用のかかる破滅的な行為である
前の段階から決まっていることに変更を加えると、大量の作業を見直してやり直さなければならなくなるので、開発プロセスを危うくして、面倒な作業と費用がぐんと増えることになる。その上、コーディングとテストの工程では、要求仕様やアーキテクチャに問題点が見つかることがよくあるけれど、それによって開発プロセスが大幅に遅れて、面倒な作業が増える可能性がある。
プロダクトマネージャーは、常に顧客とユーザーの声を代表していなければならないので、どうしても変更が必要になるときもある。変更を先送りすることでかかる費用には、修正のための追加リリースの費用も含めなければならないという点は、ぜひ指摘しておきたい。次のバージョンのリリースまで変更を先伸ばしにした方がいい場合もあるけれど、方針変更というのは、遅いよりも早い方が費用は少なくて済むことが多い。
• 市場に反応してしまう
ウォーターフォールを使ったアプローチでは、いろいろな書類作成が必要であることや、工程から工程へと移行するというプロセスの性格上、かなり多くの管理部門的な作業が必要になる。その結果、ソフトウェアに比較的小さな変更をするだけでも、ずいぶんな時間がかかってしまうことになる。
このため、プロダクトマネージャーには、最初のうちから売れる製品となることを検証できた仕様書に仕上げなければならない、という余計なプレッシャーがかかることになる。でも、これによって何が起きるかと言えば、プロダクトマネージャーは、製品をリリースした途端に、できるだけ急いで、製品開発チームといっしょになって、方向転換のために骨を折らなければならなくなるのである。
まとめ
実際にウォーターフォールプロセスを使うとどうなるかを見てきたが、これで、アジャイル開発手法であるスクラムや XP といった別の手法に変えたい気になるのももっともだ、とおわかりいただけただろう。
多くの点で、ウォーターフォールプロセスは、理想的ではあるけれどおめでたいとしか言いようがない考え方を象徴している。それは、人は、すべての主要な問題を予測することができて、要求仕様を完璧に理解できる、ということだ。もしそういう状況なのであれば (ふつうはうんと小さいプロジェクトに限られるけれど)、ウォーターフォールを使ったアプローチは、品質の高い実装を可能にする合理的な方法となり得るだろう。
残念ながら、製品ソフトウェアでは、そういうことはめったに起こらない。実際にどうなるかというと、仕様の変更のために製品は計画より遅れて発売され、いったん現実のユーザーがそのソフトを目にして使い始めると、問題を修正するために、費用と時間をかけて追加のリリースをやらなければならなくなる。
とは言うものの、製品開発をやる会社では、製品開発プロセスというのはだいたい社内に深く根を下ろしてしまっているので、プロダクトマネージャーにできることと言えば、せいぜい、起こり得る問題を確実に避けるぐらいのである。いちばん大切なことは、まず、要求仕様を決めて設計をする工程で、真の製品を見つけ出すこと、つまり、価値があって、使いやすくて、実現性のある製品を定義することに精力を傾けることである。そして、その次に、実装の工程に移る前に、(プロトタイプを作り、実際のユーザーとテストすることによって) 製品の仕様を検証することである。これをやれば、みんなの感動を呼び、みんなに買ってもらえる製品を定義できる確率を高めるだけでなく、製品開発チームにとっては大幅な時間と費用の節約にもなるのだ。
Inspired日本語版 