開発プロセスの基礎

要件定義編

5.デスマーチと要件定義

　なぜ、そのようにプロジェクトがデスマーチ化するのでしょうか？
　プロジェクトがデスマーチ化する原因は単純です。「バグ」がいつまでたっても取れないんです。
　そして、もっとも深刻なバグは「仕様バグ」、つまりは"設計"の工程での"要件定義"にまず問題があるのです。
　その問題とは、"曖昧な要件定義を行なった"という事です。それではどうすれば、"曖昧な要件定義"を行なわないようにできるのかについて述べていきます。


5_1.要件定義の際の心構え

　そもそも要件定義というものは、顧客の曖昧な仕様を明確にする作業と言えます。つまり、「何が出来て、何が出来ない」のかをはっきりと顧客に示す必要があります。そのためには、顧客との要件定義の場に出席する前に、自分達の持っているスキルやリソースの限界を知っておく必要もあります。その限界は決して「ムリをしない事」が前提条件になります。当たり前のようですが、実際には、この前提条件は意外な程、守られていません。
　また、もう一つは「見切り発車しない事」です。「たぶんこの技術を使えば実現できるだろう。速度もきっと問題になるほど遅くはならないだろう。」「社内だけで使うアプリケーションという話だし、見た目はこんな感じでも大丈夫だろう。」そんな根拠の無い期待は、破られる運命にあります。

　ここである1例を挙げてみます。
【例】
　とあるSEが顧客に対して要件定義を行いにいきました。SEは顧客の要望を聞き、自社のツールを使って要望を実現しようと考えました。しかし、SEはそのツールの知識が少ないにもかかわらず、自分で要件定義をまとめて設計書を起し、その内容を開発部署に渡しました。開発部署はその設計書をもらった時点で、SEがまとめた要件というものは、使用するツールで実現するには一部無理があると解っていましたが、「なんとか出来るだろう」という曖昧な感じで、開発を進めました。そして顧客とのテストの時、その「なんとか出来るだろう」部分のみがバグを引起してしまい、大変な問題となってしまったのです。

　これは極端に酷い1例ですが、このような事は実際に起こり得る事です。「曖昧で不安だなぁ」と感じるような項目が要件定義にあれば、その不安はまず的中してしまいます。

　そのため、要件定義ではいかに曖昧な設計箇所をなくしていくかと言う事になっていきます。

5_2.モックアップを使用した要件定義

　ここで説明する技法は、いくつもある要件定義の技法の中での１例に過ぎません。が、GUI系のシステムを作成する時には威力を発揮します。この設計技法は、筆者らが案件で使用した際、一番効率がよく且つ、細部に亘る仕様を詰めて行く事ができました。
　モックアップを使用する要件定義のメリットは、まず顧客に対してシステムのイメージを湧かす事が出来る点にあります。元来、顧客は漠然としたイメージしかなく、そのイメージの元で折衝を持ったとしても、後々になってから「こうじゃなかった」とか「イメージと違う」という話になってしまいます。
　そしてその後々というのが、下流工程のテストの段階になって顧客が初めてシステムに触れるときになるのです。最初(設計)の段階でこういった事が出てくるのはある意味システムを開発するにあたって嬉しい事になります。それを導きだすのが、モックアップを使用するという事になるのです。
　多分、みなさんはこのモックアップは、単なる模造品でしかないため、無駄な労力と思うでしょう。しかし、本当はそんな事はありません。なぜならそのモックアップは再利用する事ができるのです。なぜなら、モックアップの定義は『外見を実物そっくりに似せた模型』となっています。ということは、Web系であればきちっとHTMLで作成し、ブラウザで見る事ができること、それ以外でも、システム開発で使用するGUI系言語でモックアップ作成が要求されます。
　しかも、要件定義の段階で顧客が特に気にするのは見栄えの点です。その見栄えが顧客の意図している物と合致すれば、次の工程である開発でそのモックアップを再利用することが可能になり、延いては開発工程での工数の削減にも繋がる事になります。

6.終わりに

　今回の話をまとめておきます。
　開発プロセスの最初の本質は、「曖昧さの無い要件を顧客と合意する」ことです。

　ウォーターフォール型でも、モックアップなどを作ることで、曖昧さを減らすことが出来ます。また、スパイラル型などの新しい開発プロセスは、開発中にある程度動くものを何度も顧客に見せ、顧客から要件を得る機会を作ることで、段階的に曖昧さを減らしていけます。