いろいろなプロセス ～V字モデルとスクラム～
異なる前提
さて、写真撮影を制限時間内に終え、撮影した写真を提出しました。ところが、顧客は写真に満足しません。提示された写真から推測して、撮影されたと思う場所に赴いて撮影した写真です。「提示された写真と同じ角度から写真を撮影する」という目的は果たしたはずですが、顧客は求めていたものと違うと言います。なぜでしょう？
実は、顧客の目的は「人に喜びを与える写真を集めた展示会をすること」にあったのです。顧客は過去の経験に基づきいくつかの「昔の写真」を提示しました。顧客の知る限り、それらの写真は素晴らしいものだったのです。同じ場所で撮影すれば、素晴らしい写真が撮れるものと思っていました。しかし、現実は変わってしまいました。同じ場所で撮影した写真の風景は展示会にそぐわないものになっていました。
システム開発でも同様のことが起こっています。顧客は過去の経験からシステムのあるべき姿を想像して要求をだしています。それに基づきシステム仕様を考え、システムを開発します。しかし、システム仕様どおりに作ってもエンドユーザーの満足を得られない場合があります。ユーザーのニーズは時と共に変化しているのです。
スクラム
エンドユーザーの満足を目的として考えられている反復型のプロセスモデルとしてスクラムが挙げられます。ウォーターフォール型では、要求定義から実装までを一度だけ行う前提でプロセスが考えられています。一方、スクラムをはじめとする反復型では、要求定義から実装までを繰り返し行う前提でプロセスが考えられています。
スクラムの流れを先ほどの写真撮影のゲームで例えてみましょう。
【ステップ1】
まず1ヶ月で撮影する枚数を決めます。提示された写真から1ヶ月に撮影する枚数の写真をピックアップし、顧客の価値観を理解します。どういった写真が素晴らしいと価値を感じるか理解するわけです。
【ステップ2】
次に、撮影場所をざっくりと決めます。大体この辺りならば期待する写真を撮影できるだろうと当たりをつけます。
【ステップ3】
大体の撮影場所を決めたら、移動手段の検討に移ります。移動手段の検討は、ウォーターフォール型の場合と同じです。
【ステップ4】
そして、移動して、撮影します。撮影は移動しながら様々な場所で行います。撮影場所を調整しながら、最も素晴らしい写真が撮れる場所を探すのです。
以上を1ヶ月で行います。1ヶ月の終わりには、撮影した写真を顧客に見せ、期待するような写真を撮影できているか確認をしてもらいます。OKとなる写真もあれば、NGとなる写真もあります。NGとなっても、何がNGなのかを具体的に知ることができます。この過程で顧客との価値観を共有していきます。
そして、次の1ヶ月がはじまります。流れは先ほどと同じですが、顧客との価値観の共有が進んでいます。また、現地に赴き撮影した経験により、効率的に撮影をするコツを身につけています。前月より効率よく行うことができるのです。
図6は各ステップとＶ字モデルの対応づけです。まず、要求定義の内容が異なることが見てとれます。
スクラムでは、システム仕様を守ることより、ビジネス価値を最大化することに焦点を定めています。そのため、要求定義に該当するステップ1では、価値観の理解を行います。基本設計に該当するステップ2においても、厳密なシステム仕様を定義することなく、大まかなシステム仕様を考え、設計に移ります。詳細設計に該当するステップ3では、Ｖ字モデルと同様のことを行います。実装に該当するステップ4では、試行錯誤が行われます。顧客もどういったシステム仕様が良いのか分かりませんので、実行結果を見て調整します。
|
|
| 図6：ゲームとＶ字モデルの対応（スクラム） |
おわりに
システム開発のプロセスを具体的に説明すると複雑になってきます。そのため、今回は写真撮影のゲームを例に説明することにしました。いかがだったでしょうか。プロセスには意味のあるつながりがあります。Ｖ字モデルやスクラムなどのプロセスモデルからは、工程のつながりが見づらい場合があります。写真撮影のゲームの例から、工程の意味とつながりを実感できたなら、意図することは果たせました。
|
|
| 図7：ゲームとシステム開発の対応（スクラム） |
皆さんのプロジェクトの目的は何でしょうか？「顧客に提示された写真と同じ場所の写真を撮影すること」でしょうか？「人に喜びを与える写真を撮影すること」でしょうか？はたまた、それ以外の目的でしょうか？
そして、どのような流れで目的の写真を撮影するでしょうか？マイルストンを設定することは決して難しいものではありません。写真撮影のゲームを行う時に行動を順序立てるように、システム開発でも行動を順序立てるということです。練習がてらに写真撮影のゲームを試してみるのも良いかもしれません。
今回は、マイルストンの例をご紹介しました。次回は、様々なプロセスに現れるパターンをご紹介します。
◆◇◆◇ コラム：誤解されたウォーターフォールモデル ◆◇◆◇
ウォーターフォール型開発プロセスモデルの提唱者は、ウィンストン・ロイスとされています。1970年にロイスが発表した論文 "MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS" でウォーターフォール・モデルが示されたと言われていますが、この論文には「ウォーターフォールモデル」という記述はありません。文中に示されたフェーズの流れ図から命名されたようです。
この論文では、このやり方のリスクを取り除くために次の5つの対策が示されています。
- プログラム設計を最初に行う
ソフトウェア要求フェーズと分析フェーズの間に予備的なプログラム設計フェーズを挿入する - 設計を文書化する
- 同じことを２回行う
- テストの計画、管理、監視を行う
- 顧客を巻き込む
1.はプロトタイプ開発やアーキテクチャ評価を先行させること。3.は開発を繰り返し行うこと。ですから、反復型開発プロセスモデルに通じます。
このようにロイスの提唱したプロセスはフィードバックループを含んだもので、後戻りを許さないというイメージからは遠いものになっています。フィードバックループの欠落したウォーターフォールモデルが定着したのは、米国防総省の規格書がきっかけのようです。
時は過ぎて、ウィンストン・ロイスの子息であるウォーカー・ロイスが、父親の提唱したモデルに大きな欠陥はないことを踏まえて、その発展系として反復型開発プロセスモデルを示しました。1998年に "Software Project Management: A Unified Framework"（邦題「ソフトウェアプロジェクト管理 21世紀に向けた統一アプローチ」）という著書にまとめられ、ラショナル統一プロセス（RUP）となります。
ウィンストン・ロイスとウォーターフォールモデルの名誉回復と言いたいところですが、残念ながらウォーターフォールモデルに対する誤解は根強く、解消することは難しいようです。
（株式会社SRA：土屋 正人）
【参考文献】
- トム・デマルコ／ティモシー・リスター『ピープルウェア 第2版』日経BP社（2001）
