開発作業の「自動化」と聞いて，正直，うんざりする人もいるだろう。「思った通りの成果物なんてできやしない」「ソースコードの中身がブラックボックス化してしまう」「費用や教育といったツール導入の負担が大きい」――。自動化にはこうしたいくつもの不安やリスクがあるためだ。

　だが一方で，生産性と品質のさらなる向上を目指し，企業トップやバックオフィス部門は自動化を強く推し進める。現場では渋々自動化に取り組むが，やはり失敗してしまう。「自動化なんて夢のまた夢，もう自動化はコリゴリだ」。そんな風に思うのも，当前と言えば当然である。

　では自動化は悪か，と言えばそんなことはない。人間がやる作業をきちんと自動化できれば，それは素晴らしいことだ。自動化は作業の効率化・迅速化や，成果物の均質化といった大きなメリットがある。開発プロジェクトでは様々な作業が発生し，「猫の手も借りたい」と本気で思う現場はいくらでもある。そんな現場を自動化で救うことができたら，それこそ夢のような話だ。

　そこで記者は，日経SYSTEMSの3月号で「自動化」をテーマにした特集を企画・担当した。自動化の“狙いどころ”が必ずあるはずと考えたからだ。実際，画面生成を自動化できる「Struts」や，テスト・スクリプトの作成や単体テストを自動化できる「JUnit」は，開発現場にも根付きつつある。こうしたツールはすべての開発作業を自動化できるわけではない。画面開発やテストといった一部の作業に限定している。この“限定”こそが，現場における自動化のヒントになると考えた。

狙いどころは三つの作業

　ユーザー企業やベンダーなど数十社に取材すると，自動化で成果を上げている現場は意外にあった。ただし機械化された工場ラインのごとく，仕様が決まればあとは勝手にモノが出来上がる，なんて自動化はどこにもない。自動化で成功している現場は適用範囲をやはり限定。それも人間のある作業に着目して自動化していた。その作業とは，「確認」「引き継ぎ」「判断」の三つである。これらの作業は自動化に伴うリスクが低いうえに，生産性や品質に直結するので自動化の効果も大きい。以下では，これら三つの作業に分けて，自動化の具体例をいくつか紹介しよう。

狙いどころ（1）　確認作業

　確認作業の自動化は，設計書のレビューやバグの発見・通知など，現場における「異常」を検知するものである。例えば富士通のある現場では，画面やデータに関する設計書のレビューを自動化している。あらかじめ用意したAccessのテーブルに，プロジェクトで従うべきデータ項目辞書を登録。そのうえで，基本設計書を作成したExcelシート上のマクロ・ボタンを押すと，設計書と辞書のデータ項目を自動的に照合。もし辞書に存在しないデータ項目があれば該当個所にマークを付ける。逆に辞書と照合できたデータ項目については，関連する型や桁数などを辞書から設計書に自動転記する。これでデータ項目のレビューを不要にした。

　ウルシステムズでは，Javaベースのスクリプト言語「Ant」を使い，モジュールをビルドした時のコンパイル・エラーを自動検知・通知するツールを自作した。その名も「さらし者システム」。1時間おきに自動的にビルドし，エラーが発生するとその内容とエラーを発生させた開発者名をメンバー全員にメールで通知する。バグを発生させた開発者が文字通り「さらし者」になることで，バグに対するメンバーの意識が高まり，バグが激減したという。

狙いどころ（2）　引き継ぎ作業

　プロジェクトでは多くの場面で，人から人，成果物から成果物へと情報を引き継ぐ。この引き継ぎこそが伝達ミスや解釈ミスを招く元凶となる。そこで人と人，成果物と成果物の間の“つなぎ目”をなくすというのが，引き継ぎ作業の自動化だ。

　不動産会社の駐車場管理システムを開発したNECソフトのある現場では，プロトタイプのHTMLソースから画面設計書への情報の“引き継ぎ”を自動化した。具体的には，HTMLソース中の<title/>や<foam/>，<input/>といったタグを参照し，画面設計書のExcelシートに自動転記するものだ。転記ミスをなくしたほか，全部で120ある画面の設計書の作成工数を半減させたという。

　物理テーブル定義書と実テーブルの不整合に悩んでいたSBIイー・トレード証券では，両者のギャップを埋める自動化に取り組んだ。物理テーブル定義書の内容をExcelシート上に入力すると，テーブル作成用のCREATE文が所定のセルに自動作成される。担当者はこのCREATE文をデータベース用の開発支援ツールの画面上にコピー＆ペーストし，実テーブルを作成。その後の改修などで設計書と実テーブルの間で不整合が出た場合，別の自作ツールを使って実テーブルの情報を自動抽出し，元の物理テーブル定義書に自動転記させる。これにより不整合を解消したほか，テーブル作成や調査の工数を8割以上削減できたという。

狙いどころ（3）　判断作業

　三つ目の作業は「判断」である。これは，経験や勘を伴う設計やコーディング作業の「判断」をツールにやらせようというものだ。作業プロセスがブラックボックス化する恐れがあるが，先人の知恵やベテランのノウハウをツールに取り込むことで回避できるようだ。

　日立製作所の産業・流通部門では，システムの対象となるデータソースと，種類（照会系，帳票出力系，画面入力系，バッチ入力系）を選ぶだけで画面，ロジック，DBアクセスのソースコードを自動生成するツールを自作した。過去のプロジェクトの傾向や先人の知恵などから，画面遷移やボタン処理，DB操作のパターンを四つに分類し，そのパターンに基づいてコードを生成するものだ。設計・実装作業の多くの判断をツールに任せたのがポイントである。

　野村総合研究所で証券システムの開発・運用を担当する現場では，機能テスト用のテスト・スクリプトを自動生成するツールを自作した。市販のツールで操作ログを記録しても，生成されたテスト・スクリプトに汎用性がなく，何度も操作ログを記録する作業に追われていたためだ。一部のベテランは画面遷移や入出力データが変わった場合，汎用性のないテスト・スクリプトを一部修正して流用していた。だがそのノウハウを他のメンバーに広めるのはスキル的に難しい。そこでベテランのノウハウをツールに実装。ツールを使うと一度記録したテスト・スクリプトを「操作」と「データ」「画面単位」に切り離す。そのうえで，別途作成した実行用のランチャを使うと，画面遷移や入出力データが変わっても，一度作成したテスト・スクリプトを流用して機能テストを実行できる。

周辺作業こそ自動化の狙いどころ

　各事例の詳しい説明は日経SYSTEMSに譲るが，ほとんどのケースは多くの現場でも実践できる内容だろう。注目したいのは，自動化の対象は決して開発作業の本流と呼べる作業ではないことだ。見方を変えれば“周辺作業”の自動化と言ってもいい。

　ただし周辺作業と言っても，侮ることはできない。プロジェクトではむしろ，周辺作業の方が多いからだ。取材で訪れた多くの現場も，こうした周辺作業の自動化によって確かな成果をつかんでいる。ここでは「確認」「引き継ぎ」「判断」を紹介したが，このほかにも自動化できる作業はあるだろう。これらを自動化し，人はその分，業務ロジックの検討など本来やるべき作業に集中する。これが，取材を通じて感じた今ドキの自動化の姿である。