大規模開発だからこそツールで標準化する

　住友電気工業は、SPL（Software Product Line）の考えに基づき1999年から複数のWebアプリケーションで共通する部分をできる限り部品化し、アプリケーション開発自動化を実践してきた（その成果は、部品組立型のWebアプリケーション構築ツール「楽々フレームワーク」として外販している）。主に部品化しているのは画面遷移の部分だ。業務で使うWebアプリケーションの画面遷移は照会、登録、変更、削除など共通するものが多い。従来、これらを共通部品として再利用すれば、各アプリケーションで個別にコーディングする必要がない。テストも自動化し、シナリオで約1000件、項目で約1万件をカバーするようにした。これらの取り組みにより、住友電気のアプリケーション開発自動化はかなり進んだ。実際、アプリケーションのコード数は平均164行と一般の1割ほどでしかない。そのため開発生産性は極めて高い。1人時当たりのファンクションポイント（FP、大きいほど機能が複雑）は0.33と一般の3～5倍に達している。

　基幹システムに付き物のバッチ処理は、往々にして機能追加やシステム連係によってどんどん肥大化し、性能や保守性が悪化するものだ。B社は基幹システム再構築に当たり、バッチ自動生成ツール「ODIP」（販売：インテリジェントモデル）を採用し、バッチ開発を一から見直した。ODIPでは、バッチ処理の入力、加工、出力をメタデータで定義する。複雑化しやすいバッチ処理フローを見える化でき、最適化しやすい。B社では実際、バッチ処理の入出力数が減った結果、プログラム量も圧縮できた。開発生産性（1人当たりのFP）は従来比4～5倍にまで高まり、3割近くのコスト削減を成し遂げたという。

　最後に紹介する採用事例は、メガバンクによる勘定系システム統合・刷新。究極の大規模プロジェクトである。富士通のアプリケーション開発自動化ツール「Interdevelop Designer」を使い、日本語設計書からソースコードや単体テストの仕様書・データが自動生成されるようにした。その最大の目的は標準化にあった。膨大な数の開発者が参加する大規模プロジェクトで“属人性”を許していると品質は安定せず、共同作業もスムーズにいかない。結果として無駄な作業が生まれ、開発生産性は下がる。確かにツール活用の前工程として、業務用語やコード、メッセージなどシステム内情報を一元管理するデータ辞書への情報登録は大変な作業だが、いったん辞書が整備されれば、属人性排除の効果は大きい。片山氏は「こうしたツールは経験豊富な開発者から疎まれるが、IT部門は何が重要かを考えてほしい」と話す。

採用前に使い込んでツールの真価を見極める

　6つの事例では、各社がそれぞれ別のアプリケーション開発自動化ツールを使っている。現状、デファクトスタンダード製品があるわけではなく、自社に合ったものを選ばないといけない。片山氏は「選択ポイントは多く、どのポイントを重視するかはユーザー企業それぞれ」と前置きした上で、賢い選び方を紹介する。ある企業は複数のベンダーからアプリケーション開発自動化ツールを検証用に借り、それらで稼働中の本番アプリケーションと同じものを開発し、開発現場の声をフィードバックして購入するツールを選んだ。やはり使い込んでみないと真価は分からないと判断したからだ。

　単体アプリケーションの開発だけでツールの使い勝手を判断すると見誤るかもしれない。アプリケーション開発自動化ツールは製品によって処理ロジックをより重視するか、データモデルをより重視するかの違いがある。あくまでも単体レベルでの開発生産性（処理ロジック）を求めるか、単体同士をつなぐ大規模展開（データモデル）を視野に入れているかで、おのずと選ぶ製品は違ってくるという。

　紹介した事例を見ても分かるようにアプリケーション開発自動化は広がっており、大規模開発への適用も始まっている。片山氏は「IT部門の中では依然、『ソースコードがないのはあり得ない』『ベンダーにロックインされる』『開発者のスキルが磨かれない』などと、自動化ツールに対する抵抗は強い。自分たちに求められているのは何なのか、合理的に考えてほしい」と訴える。アプリケーション開発の在り方を根本から変える決断の時は目前にあるようだ。

今回の事例で採用されている自動化ツール（出典：ガートナー、2016年3月）