GUIソフトが主流となった現在ではウォーターフォール開発モデルなどやっているのは日本のIT会社だけのようです。ビジネス環境変化の速い現代において、スピード感に乏しく要件追加・変更に伴う追加請求で高額となり易いのがこの特徴です。
ソフトウエア開発モデル
ウォーターフォール開発モデルとは
ウォーターフォール開発モデルとは、水が高いところから低いところに流れ落ちるように、「要件定義」「基本計画」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」と一方向に、決して戻らずに進める手法です。
私の知る限り、ソフトウエアが産業として生まれるころから製造業や建築の世界の開発モデルを持ち込み、ソフトウエアもこの開発モデルで開発されているものです。
製造業や建設は物理的に構築していくため、ある程度工程が進んでから変更が有った場合に非常に影響が大きく、費用が高価なものとなるため途中工程での多少の手直しは有ったとしても、絶対に工程を戻ることはない前提なのです。
現代のソフトウエア開発モデル
特にGUIソフトが主流となった現代のソフトウエア開発では、世界最大のソフト会社であるマイクロソフトでも、使っていない古い開発モデルです。ソフトの画面はお絵かきソフト的にその場で簡単に画面を作成出来て、画面を作成すると同時にデータベースのテーブルも作成されます。
後は、裏の仕組み・ロジックを書けばいいのです。先ず画面から作成して、テストをする。ユーザーテストをすると、開発者が想定していなかったような使い方をされたり、ボタンを押されたりしますので、その時の動きやエラー処理を追加していきます。
この様な開発手法であるアジャイル開発モデルやDevOpsと言う手法・開発モデルが現在の殆どの世界的なIT会社がやっている開発の進め方です。
現代のソフトウエアは画面が中心になっていますので、知識のないユーザの操作を最初から全て想定して要件を作成することが不可能なのです。
日本のIT開発の現状
日本ではウォーターフォールが主流
それがなぜか日本のIT会社では今でも当然のようにウォーターフォールモデルで開発が進められています。それには、下記のような様々な理由があると思いますが、何れにしても日本のIT会社側の勝手な都合のようにしか思えません。
- IT会社に丸投げのため、業務要件を整理できる人間がIT会社に必要となり、更にベンダー・ロック・インの状態になる
- 前の工程で決めたことを覆すと、ユーザ企業の責任だとして、追加費用を請求し易い
- 大規模なシステム開発では、ある工程が終了すると要員を次工程の要員に順次入れ替えていけるため、単純にその工程のスキルだけ覚えさせれば初心者でも直ぐに使える人材に出来る
- 全体の開発スケジュールが何年にもなり、高額請求し易い
- オブジェクト指向やマイクロサービスによりソースコードのライブラリや部品の組み合わせで、日に100回でも開発・テスト出来る時代に技術・スキル的にキャッチアップ出来ていない
特にメインフレームと言われる大型コンピュータが中心であった基幹系システム（会計、製造、物流、購買・販売など）の開発では、今でもほぼこのウォーターフォールモデルで開発が進められています。
メインフレームの時代は、１画面100万円などと画面の枚数やトランザクション処理・プログラムの本数・ステップ数などを基準に見積をしていましたので、その名残ではないでしょうか。
その手法でしか出来ない、と口裏を合わせているのか、当人たちも思い込んでいるのか、もしくは、そもそも外の世界を知らないのか。
何れにしても、経産省のモデル契約でも基本的にはこのウォーターフォールモデルを前提としているように見えますし、日本特有です。
開発だけでも請負に
IT会社との基本的な契約の形態には３種類があります「請負契約」と「準委任契約」、そして「派遣契約」です。言葉が判りにくいのですが、
- 完成責任を負っている契約：請負契約
- 単なる稼働提供のみを約束：準委任契約
と考えればシンプルです。派遣契約はユーザー企業がプロジェクトの全ての責任を負って計画から進捗・課題管理など全てを進めるやり方ですので、日本ではあまり見られないやり方ですが、欧米では普通です。
そして、IT会社は技術的な支援としてエンジニアを派遣し、ユーザー企業の指揮命令系統の中でプロジェクトを進めます。
多くの日本のSI（システム・インテグレータ）は上記の「準委任契約」しか基本的に受け入れません。なぜなら、完成責任を負って開発をすると言う事は、もしバグ等のミスがあれば全て自社がかぶることになりリスクが高いからです。
本来であれば、ウォーターフォール開発モデルで開発する業務要件、外部連携などの条件が確定すれば、後はプログラム内部の開発のみであり、そこで何か問題があれば全てIT会社の責任のはずです。
本来、プログラム開発フェーズは少なくとも「請負契約」にすべきで、上のリンクの「経産省のモデル契約」でも開発部分は基本的に請負としています。書面上な「準委任契約」と書いてあったとしても、訴訟になれば「実態がどうであったか」が問われますので、その辺りをよく理解した上で進められることをお勧めします。
その辺りをご説明をこちらでしていますので、参照下さい。⇒ IT訴訟での注意点
ウォーターフォール開発が非合理な理由
開発している間に陳腐化する
なぜこのウォーターフォール開発が非効率とされ、既に世界の巨大ソフトウエア企業では採用されていないかをご説明していきたいと思います。
先ず、最初に業務要件を確定してから実際にそのシステムを使い始めるまでに1年、長ければ２，３年を要するため、使い始めるころには既に業務が変わっていたり、ビジネス環境が変化してしまうのです。
ビジネスの環境変化は更に早くなっていますし、私の経験したプロジェクトでは、あるパッケージソフトをベースに開発を進めていたところ、テストが終了し使えるようになる前に次のバージョンが発売され、そのパッケージソフトのライセンス元の保守期限が切れてしまいました。
世の中の流れに対して圧倒的に遅いのです。アメリカの大手ソフトウエア会社は、設計をシリコンバレーで実施し夜中にインドで開発し、朝アメリカで出来たプログラムをテストする24時間体制で開発を進めます。
これは最近の話ではなく、インドのIT企業が育てきた90年代からこうなのです。
ユーザー企業は最初に要件を出せない
システム開発に関して丸投げ体質できた日本の企業は、自社内で現場から業務要件を収集し整理することが出来ない会社が殆どになってしまっています。
また、仮にパッケージソフトウエアを元にした追加開発であったとしても、必要な機能の説明をいくらされても全ての機能を最初に抽出し、文書に定義することは不可能です。
ここでもウォーターフォール開発モデルはIT会社に都合が良く出来ています。業務要件を一旦整理しフェーズの終了段階で内容確認のサインさせるのが一般的です。しかし、ソフトウエアは形が無いものですから、ユーザー企業側がソフトウエアが出来て目に見えるようになる前にイメージし、自分達が必要としている機能が網羅されているか理解することが難しいのです。
したがって、基本設計、外部設計、内部設計、コーディングと工程が進んでくると、単体で画面など見れるようになって来ます。これをユーザに見せると、イメージが違う、この機能が足りない、と始まります。これは即追加費用請求の対象となり、開発費用は膨れ上がっていくのです。
現代のIT開発のあるべき進め方
クラウドを前提にしたアジャイル開発が時代にマッチ
最近では、クラウド上にパッケージソフトが導入されていて、ボタン一つで契約して直ぐに使えるSaaS（ソフトウエア・アズ・ア・サービス）と言われるクラウドサービスが主流になりつつあります。
ERPなどの基幹システムでは、今使ているシステムからのデータ移行などが必要となるため、その場でとはいきませんが、それでも圧倒的に早く使えるようになりますし、何より大規模なデータセンターもサーバーのハードウエアも所有する必要が無いのが大きなメリットです。
ユーザーライセンスを基準とした契約と、CPUやハードディスク等のコンピュータリソースを使った分だけ支払う従量課金の契約とがあります。
多少の制約はありますが、追加開発も可能ですので殆どの企業は今後クラウドサービスのほうを選択していくのではないかと考えています。
むしろ、そうならなければ日本企業は外国の競合に対して圧倒的なスピード感で太刀打ちできないでしょう。
パッケージベース
日本の、特に製造業の方と話していると、よく言われる事に
自社は大企業で現場業務が特殊だからパッケージソフトをそのままは使えない、スクラッチで一から開発する必要
がありますが、どうもそれらの製造業の方は下からの積み上げ型のイメージが強く、時間をお金に換算する概念が非常に薄いようです。これだけの巨大製造業なのだから、システム開発に2年3年かけても、今後数十年変わらないだろう、という幻想を持っているのでしょう。
そもそもERP等の基幹システムは欧米のベストプラクティスと言われる業務のやり方を受け入れることで、パッケージ自体に手を入れずシンプルに即使えるようになる点がメリットです。
ERPを導入する過程で肥大化した自社の業務を見直し、あるべき清流化ｓだれた業務に見直していく過程にこそ価値があるのです。 ⇒
RPA・AIを活用しアドオン開発をしない
ERPなどのパッケージソフトウエアをベースとして、これまでのように大量のアドオン（追加）開発をするのではなく、シンプルにほぼ素の状態で使うのが良いかと思います。
自社に必要だから、ビジネス上の効果があるから、と経営トップが意思決定したのだから一刻も早く実行に移し、効果を刈り取る、時間を買う感覚が必要ではないでしょうか。
そして、これまでERPの中に開発をしていた以下のような機能を止め、RPAやAI機械学習などを使って自動化するのが将来に向けて良いのではないかと考えられます。
- 画面追加
- システム間を繋ぐ
- テスト
