途中の仕様変更が難しい？ 原始的な開発手法に潜んでいるリスクとは ｜第七回「システム開発のウォーターフォールって何？」

システム開発の手法のひとつである「ウォーターフォール型開発」は、最も原始的でわかりやすい開発手法です。システム開発の現場ではよく用いられていますが、業務システム開発においてはデメリットが大きいとシステムコンサルタントの島田さんは言います。では、どのようなデメリットがあるのか、業務システム開発にはどのような手法が合っているのか、詳しくお伺いしました。

原始的な手法にも穴がある

——まず、「ウォーターフォール型開発」とはどのような開発手法になるのでしょうか。

いろいろな開発手法がありますが、ウォーターフォール型開発は1番原始的な手法になります。名前のとおり、滝のように上から下へ段階的に開発が進められていく開発手法です。

第五回「システム開発の工程ってどんなの？」でも説明しましたが、システム開発をする際は最初にお客さまが開発会社に要望を伝え、開発会社は要件定義書を作成します。

その要件定義書をお客さまのほうでよく確認していただき、その内容で問題なければ判子を押していただく。それで要件定義が完成することになり、次の段階へと進みます。

お客さまが仕様書に判子を押されたら「次のフェーズへ進んでも大丈夫」ということになりますので、ひとつのフェーズが終わったら二度とそのフェーズには戻りません。

——だから“滝”なのですね！ 水は下流へと流れるので、上流（前のフェーズ）には二度と戻れないと。

そうなんです。それがウォーターフォール型開発の特徴です。フェーズを明確に区切って進めていき、各フェーズで問題等が発生した際はその都度話し合い、お客さまに確認してもらいます。「設計→確認→次のフェーズへ進む」という流れがウォーターフォール型の基本です。

——つまり、お客さまに確認してもらいOKをいただかないと次のフェーズには絶対に進めないというわけですね。

はい。たとえば、実装フェーズでお客さまに確認してもらうためのレビュー会というものがあります。そこでお客さまに不具合や相違点を洗い出してもらいますが、その回数が“1〜2回まで”決まっていたらその回数以上は行いません。

また、レビュー会で気になるところがあれば、お客さまは開発会社へ伝えることができます。けれども、それがフェーズの途中になると、開発会社へ言うことはできません。

——ウォーターフォール型開発だと、発注側はフェーズの途中で“やっぱりこうしてほしい”と言うことは絶対にできないのでしょうか？

基本的に言えないと思ったほうがよいかと。そこが“言える”となると、それはもはやウォーターフォール型開発ではなくなります。

フェーズの途中で発注者側が要望を言えない理由としましては、すべての開発会社に当てはまるわけではありませんが、ウォーターフォール型開発を行っている開発会社は多重請負（※）の構造になっているケースが多いからなんです。

お客さまが途中で思いついて「こうしてほしい」と言うと、それを関係するすべての下請け会社に伝え、場合によっては契約内容の見直しまでする必要が出てきます。

その分、余計に手間がかかってしまうのでウォーターフォール型開発を用いる際は、発注側は確認の段階で入念にチェックする必要があります。

（※発注者から委託された業務を下請け会社へ委託し、さらに別の下請け業者へ委託していくこと。）

業務システム開発にはおすすめできない理由

——ウォーターフォール型開発に向いているケースはありますか？

予算が決まっていたり、作りたい内容が固まっていたりするなど、シンプルなシステムを開発するケースです。

たとえば、間に人間が介在せず、サーバー同士でデータの送受信を行うようなシステムは、だいたいシンプルな作りで固まっていますし、実装を開始してから“ここはやっぱりこうしたい”ということが発生しないので、そういうシステムはウォーターフォール型開発が向いています。

ただ、基本的に一般的な業務システムではウォーターフォール型開発でシステムを開発するのは難しく、お客さまにとってメリットはほとんどないのが正直なところです。

確かに、ウォーターフォール型開発は未だによく使われている開発手法ですので、しっかりと仕様書を読んだり、要件をきちんと伝えたりすれば「いいものができる」と思われる方は多いですが、そのように思い込まれていると痛い目にあってしまいます。

——なぜ痛い目にあうのでしょう？

通常、システムにしたいもの＝要件というものは、作る前に細かいところまで見通すことができません。

また、開発会社もお客さまもシステムの完成体を想像しながら話をするので、それぞれが別のものを見ている可能性もあります。

さらに、お客さまと開発会社ではシステム開発のゴールが違います。

——ゴールが違うとは？

お客さまのゴールはいろいろと調整しながらシステムを理想の形にしてもらうことで、開発会社のゴールは早く納品して売上代金を回収することです。

お客さまからするとかなり高額な費用をかけるので「きっと良いものになる」と思われがちですが、それぞれ違うゴールを見ていることが問題となり、うまくコミュニケーションを取ることができず、システムが理想の形にならないケースもあります。

——ウォーターフォール型開発では、そこが顕著になるのですね。

はい。特に、大きなシステムの開発だと1〜2年と長い期間をかけて作ることになりますので、どんどん状況が変わります。

たとえば、開発期間中に税制が変わり管理すべき項目が増えたなど、状況に合わせてシステムの仕様を変える必要性が出てくるんです。

けれども、ウォーターフォール型開発だとすでに決まっているものを変えることはできません。

開発期間があまり長くないコンパクトでシンプルなシステムを作りたい場合はウォーターフォール型開発でもよいと思いますが、開発期間が1年以上に及ぶ業務システムにはおすすめできない開発手法です。

状況の変化に合わせられるかどうか

——発注側にとってメリットがほとんどないウォーターフォール型開発が、未だに日本でよく使われているのは何か理由があるのでしょうか。

いろいろな理由があると思いますが、リスクを減らすために大手に依頼するお客さまが多いのも理由の1つだと思います。

多くのお客さまが小さい開発会社はリスクがあるからと大手に依頼しますが、大手の開発会社はほとんどが多重請負の構造になっています。

元請けの開発会社から2次請け、3次請け、4次請けと次々と下層の会社に流れていくと、利益もどんどん抜かれていくので、システムに充てられる予算が支払った金額の10分の1以下ということも少なくありません。

——そうならないようにするためにも、発注側はどのような点に気をつければいいのでしょうか。

すべての大手開発会社がウォーターフォール型開発を用いているのかはわかりませんが、業務システム開発については、状況の変化に合わせて対応できる開発手法、そのノウハウがある中堅会社のほうが良いものが出来上がり、費用感も抑えられると思います。

何より1番心の中に留めておいていただきたいのは、1回で完璧な業務システム開発ができることはあり得ないということです。

これは実際にあったことですが、“不満が出てきても1回最後までやりたい”というお客さまの要望で、あえてウォーターフォール型開発で開発し、実際にシステムを動かして出てきた悪いところを次のウォーターフォール型開発で改修するという流れを2〜3回行い、理想に近い業務システムに仕上げたことがありました。

ただ、これはお客さま側にシステム開発に慣れた方がいた非常に稀なケースで、そうそう簡単にできることではないと思います。

なので、お客さまのほうで“最初から思った通りのものにはならない”と肝に命じておいたほうがよいでしょう。

——何回も直しを入れながら、業務システムを作り上げていくことが大切だということですね。

そうですね。また、それをどういう形で行うのか考えることも大切です。先ほどのようにウォーターフォール型開発を数回まわしていく形でもよいですし、当社がラボ型開発という名称で行っているような「準委任契約」という形で行うのもよいかと思います。

——「準委任契約」とはどのような手法になるのでしょうか。

簡単に説明しますと、受託開発契約の一種です。受託開発契約には一括請負契約と準委任契約の2種類がありまして、ここまではずっと一括請負契約についてお話をしてきました。

一括請負契約は、基本的にお客さまから要望をお伺いし、その見積書を作成して開発に入り、納品した時点で支払いが発生します。つまり、「完成した仕事に対して報酬が発生する」契約です。

これはどのような開発手法でも、はじめに見積書を作ってから開発となれば、それは一括請負契約という形になります。

——これまでお話していただいたウォーターフォール型開発も一括請負契約ですね。

一方、準委任契約は「特定の業務に対して報酬が発生する」契約になるので、一括請負契約とは報酬が発生する基準やタイミングなどが異なります。一般的に、月ごとにお支払いただく形になりますので、システム開発のゴールをどんどん変えても問題ありません。

——準委任契約は状況の変化に合わせられる契約ということですね。

そうですね。準委任契約のように、変化を前提としてシステム開発にお金を使う契約の手法もあります。

また、このほうがウォーターフォール型開発よりも開発会社とお客さま両方がやりやすくなると思うんです。

システム開発はその時々の状況に応じてどんどん変わっていくべきものですので、その変化に合わせていろいろと言えるようにしておくとよいかもしれません。

まとめ

第七回「システム開発のウォーターフォールって何？」をテーマにお話してきましたが、いかがでしたでしょうか。

ウォーターフォール型開発は日本でよく用いられているシステム開発の手法ですが、実は発注者側にとってはメリットがほとんどありません。その理由としては、

この4つが問題として挙げられるからです。特に、業務システムは状況の変化に合わせた開発が大切になるため、柔軟に対応できる手法のほうが開発会社も発注会社もやりやすいと言います。

さて、次回のテーマは「システム開発で炎上した時はどうすればいいか？」です。システム開発における“炎上”とはどういう意味なのか、ぜひ見逃しなく！