「日本のオフショア開発は“悲惨”の一言に尽きる。伝えるべき成果物の構成品目を適切に管理していないのが大きな問題」――。サイクスの宗雅彦社長（写真）は9月7日，ソフトウエア開発者向けイベント「X-over Development Conference 2007」で「ソフトウエア構成管理」の重要性をこう訴えた。
ソフトウエア開発では，要件定義，基本設計，詳細設計，コーディング，テストというプロセスを踏む。その流れの中で，開発に携わる多くの人に関連する情報を正しく伝えなければならない。だが「オフショア開発では言語や文化が違う，開発拠点が分散しているなど，コミュニケーションを取りづらい環境が揃っている」（宗氏）。海外のエンジニアとの間にブリッジSEが入ることも，情報の伝達をより難しくする原因だと宗氏は語る。
伝えるべき情報が膨大かつ複雑に
宗氏はさらに，一種の“コミュニケーション不全”を引き起こす問題として，伝達すべき情報が膨大かつ複雑化している点にも言及した。「オフショア開発ではソフトウエアの規模が大きくなり，大規模がゆえに複雑になる。当然，修正による影響範囲も拡大。それらを確実に関係者に伝えるのは容易なことではない」（宗氏）。
そのうえで宗氏は，現場で陥りやすい例を次のように挙げた。まず開発者のAさんとBさんがあるコンポーネントを共有する場面。Aさんが修正した個所をBさんに迅速に伝えていない問題が起きやすい。「多くの場合，Bさんは自分が開発した部分が動かないことでAさんの修正に気付く」（宗氏）。だが，そこに辿り着くまで膨大な手間と時間を費やすことになる。
メンバー同士が互いのコンポーネントを破壊し合う問題もあるという。例えばあるコンポーネントを共有フォルダに置き，AさんとBさんがそれをローカルにコピーして作業をする。このときAさんとBさんが別々の個所を修正して同時に元のフォルダに戻したらどうなるか。先に共有フォルダに戻したコンポーネントは上書きされ，後に戻した部分の修正しか反映されない。
構成管理の仕組みを現場に
こうした問題を解決するために宗氏が提案するのが「ソフトウエア構成管理」の実践だ。宗氏は1962年に米国の軍需産業で構成管理が誕生した経緯をひも解き，「規模がどんどん大きくなるソフトウエアは，過去のハードウエアと同じ歴史を辿っている」（宗氏）と説明する。
ソフトウエア構成管理とは，ある時点の成果物の構成品目（構成アイテム）を識別できるマネジメント基盤のこと。要件定義書から基本設計書，詳細設計書，ソースコードと，開発プロセスを通じて構成品目をひも付けし，トレーサビリティを確保する必要もある。
ただし宗氏は「構成管理ツールを導入するるのがソフトウエア構成管理の実践ではない」と警鐘を鳴らす。「プロジェクトに参加するすべての関係者がソフトウエア構成管理のポリシーや手続きを理解することが不可欠」（宗氏）。
まずは先人の「パターン」に習う
とはいえ，構成管理の実践は一朝一夕にはいかない。そこで宗氏は「パターン」の活用を推奨する。パターンとは，ある状況の問題を定義し，それに対する解決策を示したもの。構成管理に関するパターンには，Steve Barczuk氏らがまとめた「構成管理パターン」がある。宗氏は「まずはこれを参照し，先人の知恵に習うのが近道」と強調する。
例えば構成管理パターンには，「メインライン」と呼ぶパターンがある。成果物のマージとブランチ（分岐）にかかる作業をなるべく減らすために，どのようにコードライン（成果物の集まり）を管理すべきかを示したものだ。「プライベート・ワークスペース」というパターンでは，コードラインをどうやって最新の状態に保ち，矛盾が生じないように変更を加えるのかを示している。
パターンのメリットは解決策を示していることだけではない。「構成管理を実践するに当たって現場でぶつかる問題を整理している点も大きい」と宗氏。まずは現場で差し迫っている問題をパターンから見つけ出し，そこから取り組んでみてはどうか」と，会場に詰め掛けた受講者に呼び掛けた。
