「現状のソフトウェア開発は間違っていないか？」（プロセス編）：ソフトウェア開発の匠（3）（1/3 ページ）

匠Lab 代表取締役の萩本順三氏が、既存のソフトウェア開発プロセスにメスを入れる！

[萩本順三，匠Lab]

萩本　「皆さんは、ソフトウェアを開発するときに、どのようなプロセスを踏んでいますか？」

多くの人たち　（シ〜ン）

萩本　「例えば、最初に要件定義をし、基本設計をして、詳細設計に進むとか」

何人か　（自信なさげに手を挙げる……）

　これは、講演での筆者の質問に対するお客さまの一般的な反応である。最近では、開発者が開発のプロセスを意識しなくなっている気がする。第2巻では、開発者に開発プロセスを意識させる試みを通じて、匠（たくみ）の技を見つける手掛かりを探してもらう。

ウォーターフォール開発とは

　今回は、中規模・大規模開発で使われている開発プロセス「ウォーターフォール開発」を改めて考える。ウォーターフォール開発とは、名前のとおり工程（フェイズ）が滝のように流れる開発手法である。つまり、上流工程で作業をしっかり進め、後戻りしないことを“お約束”としている。しかし、実際にはどんどん後戻りすることを常とする不可解な開発方法である。

　ウォーターフォール開発のイメージを図1に示す。ここで示す工程名は、別の名前で呼ばれていたりもする。例えば基本設計や詳細設計が、外部設計、内部設計というふうにだ。名前ではなく、上流工程が終わらない限り下流工程を始めない開発が、ウォーターフォール開発なのである。

　ウォーターフォール開発は、多くの問題を抱える手法だ。しかし、IT業界では、いまだにこのやり方がメジャーなのである。ウォーターフォール開発がメジャーであり続ける限り、IT業界はどんどん無価値化していくと私は考えている。どうしてメジャーであり続けるか、そして、なぜそれがIT業界をダメにするのかといった理由は後で書くことにする。

図1　ウォーターフォール開発

ウォーターフォール開発の失敗

　ここでは、まずウォーターフォール開発の失敗例をいくつか取り上げ、その中からウォーターフォール開発の問題点を整理していく。

失敗例その1　「要件定義が終わらない」

　ユーザーから要求を聞き出し、システム要件に落とし込んでいくのが要件定義だ。要件定義が終わらないかぎり基本設計に移れない。しかし、要件定義がいつになっても終わらない。その理由として、ユーザーからうまく要求を引き出せないことがある。そもそも今回のシステム開発でユーザーが具体的に何をやりたかったか、どんなものをIT化すればよいのかがはっきりしない。3カ月と予定されていた要件定義工程はすでに１カ月オーバーしてしまっている、しかもユーザーが満足するような要件定義書がいまだにできていない。

失敗例その2　「設計工程の無駄」

　オープン系の開発でウォーターフォール開発を行っている。設計工程は、基本設計、詳細設計に分かれている。基本設計では、要件定義に基づき、主に画面などユーザーがシステムを利用するうえで意識する部分を設計し、詳細設計では、それをプログラムにつなげるための詳細なフローを記述することになった。

　ところが、実装（プログラム）工程に移った段階で、基本設計や詳細設計で書かれたドキュメントが使い物にならないという事実が判明した。結果的に、それらのドキュメントはほとんど使われず、要件定義を基に再設計を行った。このプロジェクトのリーダーであるAさんは次のようにぼやく。

　「またいつものパターンだね。上流工程屋さんの成果物はほとんど使えないよ」

失敗例その3　「使われないシステム」

　徹夜を繰り返し、ようやくテスト工程を終え、いよいよユーザーの受け入れ検査が始まる。実際にユーザーに使ってもらうこの段階で、ユーザーから厳しい意見がどんどん出てくる。プロジェクトリーダーのAさんは、まあいつものことと思いつつ、要求仕様どおりという一点張りで逃げつつ、ある部分はユーザーからの要求を聞き入れるという方法で逃げ切ることにした。

　しかしAさんにふと次のような疑問がよぎる。

• 「このシステム、本当に使ってもらえるのだろうか？」
• 「お客のお荷物になるものを苦労して作り出しているのでは？」
• 「自分たちの仕事は価値をもたらしていないのでは？」

ウォーターフォール開発の歴史

　ウォーターフォール開発プロセスは、開発プロセスの基礎知識と考えるとよい。ウォーターフォール開発は、旧来のCOBOL/PL?などを使ったメインフレーム開発で主流の開発プロセスだった。1980年代から始まり、現在でも使われている。昔は、それぞれの企業が独自の開発手法（ウォーターフォール開発がベース）を用意していた。当時の開発者は、その開発手法をしっかり勉強して開発を行うというのが常識だったのだ。

　このころの開発者は、設計する前にしっかりと要件定義をしていたし、実装する前にきちんと設計をしていた。つまり「要件定義とは何か」「設計とは何か」ということを学んでいた。

　このようなウォーターフォールの開発スタイルは、メインフレーム開発では比較的うまくいっていたように思うし、筆者もメインフレームでのCOBOL言語を使った開発では、しっかりと要件定義を行い設計すれば、ほとんど実装ができるという感覚を持っていた。