スパイラル型開発モデル

最近よくウォーターフォール型モデルと対比して用いられるのが、スパイラル型開発モデルです。「ウォーターフォール型開発を何度か繰り返すもの」と思ってもらえば結構です。

Figure 1. スパイラル型開発モデル

ウォーターフォール型では最初から完成品を目指して必要な機能すべてを分析してから次に設計に移ります。そして後戻りは許されません。しかし、大規模なシステムでは一度ならず後戻りしたくなる事があります。だからスパイラル型モデルでは、まず簡単に作ってみてそれで動作を確認してからさらに完成度を上げていくという形式をとります。

最初に作るソフトは「プロトタイプ」と呼ばれます。このソフトは実行速度がとても遅かったりエラーが頻発したり細かい部分ができていなかったりしますが、一通りの動作の流れを確認できるものにします。こうしたプロトタイプをしばらく使ってみて問題点を洗い出してから、それを修正した次のバージョンを作ります。これを何回か繰り返すことでソフトを完成品に近づけていきます。スパイラル型モデルでも分析があって設計といった開発の手順は変わりません。ただそれを何回も繰り返すというだけのことです。だから、1周するまでの開発手順はウォーターフォール型モデルと何ら変わりがありません。

ということからも、スパイラル型モデルはウォーターフォール型の「拡張」と言えるでしょう。しかし、むやみにスパイラル型モデルを推奨する「信者」のおかげで間違った認識がされていることがよくあります。

ウォーターフォール型よりスパイラル型の方がいいか？

「ウォーターフォール型開発は時代遅れで、これからはスパイラル型開発だ」というキャッチフレーズをよく聞きます。ある意味でこれは間違ってはいません。なぜなら、スパイラル型というのはウォーターフォール型に代わるものではなく、ウォーターフォール型の拡張だからです。ウォーターフォール型開発モデルすら知らない人は、まずは開発工程の基本を勉強して下さい。ウォーターフォール型開発ができなければスパイラル型開発はできません。

ウォーターフォール型に対するスパイラル型の利点は「開発工程を何度も繰り返す事」です。しかし、「開発工程」の意味をよく知らないままこのメッセージを受け取ると、「次回またやるんだから仕様分析なんかいい加減でいいじゃん」と間違った認識を持ってしまいます。そんないい加減な仕事の積み重ねでよいソフトウェアが作れるはずもありません。

ウォーターフォール型に対するスパイラル型の欠点もまた「開発工程を何度も繰り返す事」です。つまり開発に時間がかかるのです。「スパイラル型」は両刃の剣です。流行に乗って形式だけ学ぶのではなく、その精神を学び取らなくてはなりません。

スパイラル型は「創造と破壊」だ

スパイラル型の開発モデルについて間違えてはいけないのは、スパイラル型の方針は「機能を少しずつ足していく」のではなく「作っては壊す」であるということです。「開発の一周目では入力部分だけを作って、二周目では出力部分も加えよう」なんていうのはスパイラル型開発とは言いません。これは開発工程なんてもののなかった昔に逆戻りです。なぜ開発工程が必要なのかを覚えているでしょうか？部分部分を先に作ってからつなぎ合わせようとしてもうまく行かないから、先に全体を見越して設計をしなければいけない、というのが開発工程の教えでした。それを忘れてしまってはいけません。

ウォーターフォール型に熟知していない人がスパイラル型開発を始めると、何度か設計変更とプログラムの変更を繰り返し、プログラムが完成した時点で「やった！開発サイクルをぐるぐる回してやっと完成した！」といってそこで開発を終えてしまいます。これは間違いです。プログラムが完成した時点でやっと開発の「一周目」が終わったのです。あなたがぐるぐる回していたのは開発サイクルではなく、昔ながらの試行錯誤のサイクルだったのです。これでは開発工程のなかった昔と何ら変わりがありません。

スパイラル型では、開発のそれぞれのサイクルはウォーターフォール型で行います。ウォーターフォール型で開発し、完成品が出来たと思った時点でやっと一周目が終了です。そしてそれは横に置いといて、2周目としてまた新たなウォーターフォール型の開発が始まります。完成品が出来たと思った時点が二周目の出発点なのです。

二周目の開発でもまた「要求分析」から始めます。そして要求仕様書を「新たに」作成します。「新たに」という部分に注意して下さい。一周目の要求仕様書の修正ではありません。新たに作るのです。開発が二周目に突入したら、それは一周目とは全く切離して別プロジェクトのように考えなくてはなりません。二周目は一周目の修正ではありません。一からまた同じものを作り始めるのです。一周目の成果は参考にしてもいいですが流用してはいけません。

プロトタイピング

完成品と同じ機能を持っているが様々な制限を無視して作られたものを「プロトタイプ」といいます。カタカナ言葉で言うと何だか新しい概念のようにも見えますが、要するに日本語でいう「試作」のことです。例えば自動車の試作品と言えば、実際に走ることができて所定の性能を出すことができるけれどもコスト度外視だったり内装がなかったり1日に1回部品交換が必要だったりするものです。ソフトウェアでも同様に、膨大なHDDやメモリが必要だったり動作が遅かったりエラー処理が完全ではないかもしれないけれどちゃんと予定通りの作業ができるものを言います。

スパイラル型開発というのはまさにこの「試作」の作業です。一周目では機能を実現する事だけを目的にして製作し、それで動作を確認してから二周目で作り込みを行います。そして「試作」というからには完成品と同じ機能を持っているものでなくてはなりません。「この試作車はエンジンだけでブレーキはついていません」なんて状態では困るわけです。

開発対象に制限が多い場合には試作の作業もピンとくるでしょう。例えば組み込み機器では、対象となるプログラムは遅いCPU上で少ないメモリで動作しなくてはいけません。場合によっては開発言語としてアセンブラしか使えないというような事もあります。こうした場合、まずPC上でVisual Basicか何かで動作を確認できるものを作り、場合によってはPCに直接機械をつなげて実際に動かせるようにします。そこで動作を確認してその後で組み込み機器のCPU上で動くプログラムを開発するのです。

こういった制限のないオーダーメイドのソフトウェアではとかく「プロトタイピング」の意味が混乱しがちです。これは例えば「カスタムカー」に対する「試作車」の関係だと思えばいいでしょう。位置付けがよくわからなくなるのはもっともです。そして、そんな時には「そもそも試作は必要なのだろうか？」と自問してみて下さい。「プロトタイピングは何が何でも絶対やった方がいい」という教条主義には陥らないようにして下さい。

一周目はいい加減でいいか？

「スパイラル型開発では一周目はいい加減な作りでいい」という意見も見かけます。一周目はどうせ捨ててしまうのだから、と。これはある意味そうなんですが、これが免罪符となって開発自体が手抜きになってしまうと何のためにやっているのかがわからなくなります。

エラー処理をきちんとやる必要はないとか、テストを徹底的にやる必要はないとか、体裁のいいマニュアルを作る必要はないという意味では手抜きでもかまいません。しかし仕様分析や設計は最終版を作る気持ちで手をかけてやらないといけません。そして、これらがきちんとできていればその他の問題は取るに足らない問題です。

開発の一周目から重要な機能はすべて実装していなくてはなりません。手を抜けるのはヘルプやショートカットのようにあってもなくてもあまり困らないものだけです。一周目でできたプロトタイプはすぐにそのまま実際の用途に使えるものでなくてはなりません。「要求や仕様には使ってみないとわからない面がある」というのがスパイラル型開発をする理由でした。だから使ってみることができなくてはいけません。

例えばソフトウェアの入力部分だけを作って、出力部分を作らずに一周目を終えたとします。するとおそらく「おっ、いいねえ。このまま続けてよ」と言われるでしょう。そして調子良く出力部分も作って使ってもらって始めて「今年の表しかリストアップされないのでは困る。過去のものも出力できるようにしてくれ」と言われるでしょう。その時もし入力部分にそもそも「年」の概念がなかったら、入力部分は一から作り直しになってしまいます。これでは何のために入力部分だけを作ってチェックしてもらったのかわかりません。

何のためにスパイラル型開発をするのかを理解していれば、一周目の開発で手抜きしてもいい場所を判断する事は容易なはずです。目的の達成のために必要ない部分を手抜きすればいいという話なのですから。機能の一部だけを実現しようとすると重要な機能ほど実現が難しいのでとりあえず後回しにされやすいものです。それではいけません。重要な機能ほど先に解決しなくてはいけないのです。そのためには「機能の一部だけをとりあえず実現する」というやり方を改めなくてはなりません。

スパイラル型は手間がかかってやってられない

「スパイラル型は手間がかかってやってられない」という感想を持った人はおそらく正しい認識をしています。これは非常に手間のかかる開発方法で、初めての人には無駄とも思える行為を何度も繰り返すものです。だから初めての人にはお勧めできないのです。

これは「ウォーターフォール型開発」でも同じ事が言えます。初めての人はおそらく「なぜわざわざ仕様書なんてものを書かなくてはいけないんだろう？同じ時間をかければプログラムそのものが出来てしまうのに」と思うでしょう。しかしここで一手間かけておくことが重要なのです。同様に、「なぜ手間暇かけて開発したものを一旦捨ててしまって新たに二周目を開発しなくてはならないのだろう？」と思うのももっともなことです。しかしこれもまた重要なことなのです。

「何回も同じ開発を繰り返す」という方法論ではなく「なぜそんな事をするのか」を理解して下さい。これがスパイラル型開発の真髄です。そして自分のプロジェクトでそれだけの手間をかける必要があるかどうかを考えて下さい。手間がかかるのは事実ですし、それに対してそれなりの見返りがあるのも事実です。だから一概に良い悪いではなく、対象のプロジェクトについて手間と見返りのバランスを考える必要があります。

何のためのスパイラル型開発か

さて、そもそも何のために同じソフトウェアの開発を何回もやるのでしょう？それは「やってみないとわからない」事があるからです。そしてそれは特に要求分析や仕様分析といった上流工程で起きるからです。

要求分析の段階では「何をしたいですか？」と、仕様分析の段階では「こんなソフトでいいですか？」と顧客に聞きますが、「うーん、紙の上だけでそんな事を言われてもピンと来ないなぁ」という答えが返ってくることが多くあります。実際に使ってみないとその道具の善し悪しはわからないものです。こんな時「じゃあ一通り作ってみますから、それで一度使ってみて下さい。その上で改めてこのソフトに必要な機能から考えてみましょう」というのがスパイラル型開発なのです。使ってみないとわからないなら実際に使ってみようというのが発想の根本です。

だから一周目の開発の成果は「使ってみることができるもの」でないといけません。すべての機能が揃っていて、それで実際に実務ができなくてはいけないのです。スパイラル型開発が敬遠されるはずのものである事はこれでおわかりでしょうか？実際に実務ができるものを作っておきながら、それを捨ててまた同じものの開発を始めないといけないのです。それは良いソフトウェアを作るには必要な事なのですが、それなりの覚悟も必要です。

しかしこれは決して現実離れしたモデルではありません。実際の世の中では知らず知らずのうちにスパイラル型開発になってしまうことがあります。普通の開発で出来てきたソフトウェアがあまりにも質が悪くて、大モメにモメたあげく一から作り直しになってしまう事が(残念ながら)多々あります。これは知らず知らずのうちにスパイラル型開発をやっているのです。ただ作り直すのが前提になっているというだけで。こういう意味では、「ソフトウェア開発はモメるのが当たり前なのでそれを前提として動いている」という見方をすることもできるでしょう。

とにかく、スパイラル型開発の目的は「要求や仕様がいいかどうかを実際に使ってみて試す」ということです。そしてそのためには使えるものを作らなくてはいけません。

まとめ

スパイラル型開発をすれば品質の良いソフトウェアが出来ます。しかしそれなりに手間もかかります。その両者を天秤にかけて、はたして何回開発サイクルを繰り返せばいいかを考えてください。1回でよいと判断した場合は、それはすなわちウォーターフォール型開発モデルです。