これまでは要件定義から総合テストまで全工程をきっちりこなすことが重要だった。ツールを活用すれば詳細設計から単体テストまでを中抜き可能だ。部品の再利用を促進する取り組みも効果が高い。
ウオーターフォール型の開発は、作業工程の手戻りを最小限に抑えることが欠かせない。そこで有効なのは、超高速開発ツールを用いたコードの自動生成だ。製造や単体テストの工程を簡略化でき、その分上流工程である要件定義に時間を割り当てられる。また、設計情報からコードを自動生成できるため、設計者とプログラマー仕様の認識の食い違いによる手戻りを防ぐことができる。
超高速開発ツールの活用事例から工程の無駄取りを把握しよう。
共通部品群からコードを出力
野村総合研究所（NRI）が取り組んだのは、同社が手掛ける金融機関向けの決済系ASPサービス（I-STAR）の画面更新プロジェクトだ。Flashのサポート切れによって378画面をWebアプリケーションフレームワークのAngularを使って刷新する計画だった。ピーク時のメンバーは70人を超える大規模開発である。
プロジェクトは、ウオーターフォール型で開発を進めた。しかし、Angularのような新技術を使った開発は、設計を担当するメンバーが実装に慣れていない。実現できない設計をしてしまい、製造工程時に手戻りが発生することも考えられた。この課題を解決するため、NRIは詳細設計から単体テストまでの工程を極力自動化するという手法を採用した。ウオーターフォール開発のV字型から詳細設計や製造、単体テストの工程を省いたU字型にシフトしたわけだ（図1）。
I-STARサービス群の開発責任者だったNRIの矢野康弘証券ソリューション事業本部証券システム生産技術部長は、「Flashで実装された機能を乗せ換えるので要件定義は完了している。製造や単体テストの工程をいかに自動化するかがポイントだった」と説明する。
そこで、ボタンなどのパーツやロジックなどの処理を共通部品群として開発し、画面定義、遷移情報とともにリポジトリーに格納した。従来、画面設計書に記載する内容をリポジトリーに登録し、登録内容から画面を動的に構築できるツールを作成した。いわば自前の超高速開発ツールに相当する。
矢野技術部長は「基本設計の情報がそのままアプリケーションの実行コードになるため製造工程が不要。共通部品群はテスト済みなので単体テスト工程も削減できる」とそのメリットを説明する。また、共通部品群を使わない処理は基本的に行わないことにした。これにより「基本設計の工程で実装できない設計が排除できる。製造工程で開発が難しいと判明して手戻りが発生するといったことを抑制できた」（同）という。
ただし、画面全てを共通部品群で実装できたわけではない。NRIの岡部雅彦証券コアシステム三部上級システムエンジニアは、「1割ほどはTypeScriptによる作り込みが発生する箇所はあった」と打ち明ける。
