溜池随想録 #10 「反復型開発プロセス」 （2010年3月）
米国防総省のIT調達標準
ウォーターフォール・モデルが、業界に深く浸透した原因の一つは、1980年代に米国の国防総省が、ウォーターフォール・モデルとドキュメント重視のアプローチをIT調達の標準としたからである。それが、DOD-STD-2167と呼ばれるものである。
しかし、国防総省はウォーターフォール・モデルが内包している問題に気付き、90年代半ばに開発工程を何度も繰り返してソフトウェアの完成度を高めていく反復型開発を推奨するようになった。
たとえば、94年12月に新しいソフトウェア開発の標準として反復型の開発を推奨するMIL-STD-498が定められ、The Journal of Defense Software Engineeringの95年4月号に掲載された”Changing from DOD-STD-2167A to MIL-STD-498”では、ソフトウェア開発はウォーターフォール・モデルだという先入観を取り除くように促している。
さらに、2000年には、国防総省の調達手続きを定めた調達手順書DoD 5000.2 において、ソフトウェアを調達する場合、プロジェクト・マネージャは反復型開発プロセスである ”spiral development process” を採用することが義務化している。
スパイラル／インクリメンタル／イテレーティブ
ここで注意しなければいけないことが一つある。それは、一般に反復型と言われている開発手法にはさまざまなものがあるという点である。ここでは、スパイラル・モデル、インクリメンタル・モデル、イテレーティブ・モデルを取り上げる。
一般にスパイラル・モデルと呼ばれる手法は、ウォーターフォール・モデルにおける(1) 要求定義、(2) 設計、(3) コーディング、(4) テストの各工程を繰り返すものである。
また、インクリメンタル・モデルは、全体のシステムを独立性の高いモジュール（機能）に分割し、そのモジュール毎に設計、コーディング、テストを行い、徐々に機能を追加して全体を完成させるモデルである。
一方、イテレーティブ・モデルは、インクリメンタル・モデルのように機能毎に完成させていくのではなく、システム全体の開発を繰り返して徐々に完成度を上げていく繰り返し型の開発モデルである。
一般的に、インクリメンタルとイテレーティブはスパイラルに含まれると定義されることが多い。しかし、上記のイテレーティブをスパイラルと呼び、スパイラルとインクリメンタルを合わせてイテレーティブとする専門家もいる。
反復する範囲の問題
反復型開発プロセスで重要なポイントは、どのプロセスを反復するかにある。ウォーターフォール・モデルを採用した場合でも、現実を見ると、プロジェクトの末期には、設計、コーディング、テストのプロセスを何度も繰り返すことが多い。もちろん、当初から計画された反復ではなく、一種の手戻りなのだが、実際には反復しないとシステムが完成しないのである。
開発現場における反復は、一般的に要求定義のプロセスは含まない。なぜなら、要求を聞き出す相手である顧客が現場にいないからである。しかし、ソフトウェア開発プロジェクトにおける大きなトラブルの原因の多くが要求仕様にあることを考えれば、ソフトウェア開発工程の最初（要求定義）から最後（ユーザによる受入テスト）までを繰り返す必要がある。要求定義を固めてから、設計、コーディング、テストの工程だけを繰り返したのでは、要求仕様の誤りによるトラブルを未然に防ぐことはできない。
事例：佐賀市の基幹システム
反復型開発プロセスを用いた有名な事例に、佐賀市の基幹システム開発プロジェクトがある。対象業務は、印鑑登録、住民基本台帳管理、土地課税や住民税などの税事務、高齢者福祉などの福祉業務、国民健康保険、米の生産調整などの農政業務、給与業務など多岐に渡っている。開発は、サムスンSDSが約8.7億円で受託した。
サムスンSDSは、まず適当な業務を選んで「プロトタイプ」を開発し、次に一度すべてのシステムを開発し、市職員のチェックを経て、再度すべてのシステムを開発（修正・機能強化）するという手法を採用した。つまり、要求定義→設計→コーディング→テストという工程を2度繰り返すというスパイラル型の開発手法である。サムスンSDSは、この佐賀市の基幹システムをわずか1年3カ月で開発している。
後日、韓国に出張した時、韓国の二大SIerであるサムスンSDSとLG CNSを訪問し、ソフトウェア開発プロセスについて質問したところ、韓国では、ある程度大きな情報システムはスパイラル型で開発するのが一般的だという回答が返ってきた。
次回は、アジャイルソフトウェア開発を取り上げる。