とある居酒屋でのA氏との会話の続き。ソフトウェアの生産性と品質を向上する手段として、工学的なアプローチが欠かせないとする論に対して、A氏はその必要性を認めつつ、「現在のソフト工学は机上の空論」と一刀両断に切り捨てる。大学の研究室で行われている工学的手法の研究は、システム開発の現場で何が起こっているかを反映できない。ロジックはどのように組み立てられ、プログラムがどのように積み上げられるか、どの時点で機能や性能がチェックされるのか。そこから「べき」論が生まれ、実践に耐えうる手法が確立する。A氏流に言うと「事件は現場で起こっている」のだ。（佃均（ジャーナリスト）●取材／文）

「ぬるま湯」から出る覚悟

プロセス管理では限界

　これまでのシステム開発では、ユーザーが求める機能や性能を整理した要求定義書をもとに、技術的な要件を要求仕様書にまとめる作業を「上流工程」と総称する。概要設計とも称される。概要設計が終わると詳細設計に入り、予想されるプログラム規模と機能、性能を勘案してプロジェクトチームが編成されていく。

　「要求定義書をユーザーが書けない、という問題はずっと大きい。また、プログラムを書けないプログラマという現実はもっと深刻だが、とりあえずそれは棚上げにして──」

　居酒屋の喧騒の中でA氏は声を荒げた。

　「チームごとにプログラムを作り始める。それぞれにチームリーダーがいて、進捗状況を管理しているわけだ。ところが全体の進捗状況は誰も正確に把握していない。というか把握できない。その結果、チーム間に行き違いが生じる。行き違いが分かったときには、もう手遅れ」

　失敗プロジェクトが起こるのは、多くがこのような事情による。行き違いを修正する「手戻り」が発生し、システム開発は停滞せざるを得ない。しかも一度作ったプログラムを手直しする際に「漏れ」が生じやすい。システムの規模が大きくなるほど、どこにどのようなプログラムが組み込まれているのかが分からない。その解決策として1980年代に提唱されたのが「リポジトリ」の設定だった。

　「誰がいつ、どんなプログラムを作ったのか。そのデータをデータベースに登録して管理するのは有効な手段だが、事後の検証にしか使えないケースが多い。つまり有効なのは静的な解析やメンテナンスのプロセスだ。システム開発の前向きプロセスで、動的な解析を行うには別の方法がいる。これまでのプロセス管理法には限界がある」

実測データからルールを

　実はそこをカバーするものと注目されているのがEASEと呼ばれる手法だ。エンピリカル・アプローチ・トゥー・ソフトウェア・エンジニアリングの略。システム開発の現場で発生したデータを一元的に収集・蓄積し、必要に応じて分析することができる。90年代に米国で提唱され、日本では5年ほど前から奈良先端科学技術大学院大学、大阪大学などで実用化に向けた研究が行われている。

　EASEで収集するのは、プログラムそのものではない。プログラムを作ったという記録、そのプログラムのコードボリューム、プロジェクトチームや技術者の間でやり取りされたメールの件数などが対象だ。開発環境として用意されたすべての端末がEASEサーバーに接続され、端末の操作ログが自動的に記録されていく。

　ただデータを収集・蓄積するだけでは用を成さない。管理用に分析ツールが必要になる。分析ツールは開発プロジェクトの時間経過に応じてデータを時系列にグラフで表示する。例えば、プログラム作成が始まり、リポジトリに登録されると、ソースコードの規模が増加する様子が時系列のグラフで階段状に表示される。ある一定のレベルに達すると修正やデバッグが行われ、それに伴うプログラムの削除によって階段のレベルが下がる。開発現場での作業と時系列のグラフを突き合わせることで、現場でどのような作業が進んでいるか、遅滞の有無、コードレビューやデバッグの必要性などが把握できるようになる。

コードクローンを検出する

　「この手法を使うと、なぜ急激にソースコードの量が増えたのか、なぜコード量が減ったのか、などをチェックできる。コード量が増えていないのは夏休みだったからだ、と分かればプロジェクト管理者も発注者も納得できるじゃないか」

　NTTソフトウェアが全社規模での採用を決めたほか、文部省が主導するEASEプロジェクト（リーディングプロジェクトe－Society基盤ソフトウェアの総合開発データ収集に基づくソフトウェア開発支援システム）がスタート、経産省系の情報処理推進機構（IPA）も積極的に取り組んでいる。IPAソフトウェア・エンジニアリング・センター（SEC）が開始した「EMP（Empirical Project Monitor）ツール検証プロジェクト」がそれだ。

　プロジェクトの進捗状況や品質管理はEASE手法で対応するとして、一方ではレビューやデバッグによって発生するソースコードの修正漏れという問題も解決しなければならない。ソースコードを読めないプログラマが増加していることを考えると、こちらのほうがより大きな課題かもしれない。

　「プログラムのソースコードを解析するツールが20年以上前に作られた。それを応用して、いまはソースコードの類似性を検出するツールが提供されている」

　組み込み系に長く従事してきただけに、A氏はそのような情報に精通している。産業技術総合研究所の神谷年洋氏が開発した「CCFinderX」というツールが知られている。プログラムのソースコードを碁盤状に表示、縦軸と横軸の項目が合致する度合いで類似性を識別するものだ。類似性が高いソースコードは「クローンコード」と呼ばれる。クローンコードが検出されれば、理論上、相当量の修正漏れが防止できるはずだ。

　「ソフト技術者に大きな負荷を与えず、発注者にも大きな変更を要求しないで済む。市開発の現場と結びついた工学的な手法といっていいんじゃないか」

　A氏の話は、なるほどと思うことが少なくない。だがEASE手法を前向きプロセスに適用するには、実証データを積み重ねて、そこからルールを読み取らなければならない。プロジェクト管理者には、何がポイントなのかを気づく能力も求められる。

　「当面は、企業内でプロジェクト・マネジメントに適用することからスタートだ。外注管理にも応用できそうだが、外注さんは嫌がるだろう」

　ソフト業界の認識は「ソフトウェア開発の実情が可視化されることは重要」で一致している。だがEASE手法では開発用端末がすべて管理されるのだ。すると外部委託先が何をやっているか、何人が開発に従事しているかまで分かってしまう。二重、三重の下請け構造、品質管理への取組み状況が白日の下にさらされる。

　「ぬるま湯に浸かっていたいソフト会社やソフト技術者は、抵抗感を持つだろう。だが可視化、見える化というのは、ぬるま湯から出ることを迫ることでもある」

　受託開発型のSIerに、その覚悟はあるだろうか。