開発工程

ソフトウェアはどうやって作るものだか知っていますか?パソコンに向かってプログラムを書くだけではありません。

スパイラル型開発モデル

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プロトタイピング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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