ＩＴシステム開発プロジェクトにおいて、プログラミング作業を外部に発注することは以前からよく行われてきました。最近ではオフショア開発と呼ぶ海外の会社に発注するかたちも珍しくありません。

これら外注したプログラムについては、ソースコードの管理まで含めて外注先に依頼することが多いようです。

しかし、ソースコード管理を外注先だけに任せきってしまうと、いろいろと困ったことが起こる可能性があります。

例えば

• 外注先がプログラムを改修する時に、間違って古いバージョンのソースコードを使って作業したことに気がつかず、そのままリリースしてしまったためデグレ(※1)が発生し顧客に損害を与えてしまった。
  


• 外注先が潜在バグを発見したものの、発注元には報告せず、別件の修正時にこっそり修正した。
  ところがこの潜在バグの修正作業によって別のバグを引き起こしてしまった。
  発注側は修正があったことを知らなかったためこの件に関連した動作確認は行っていなかった。
  また、情報がなかったため、障害の切り分けに長時間かかってしまった。
  

・・・といったなかなかキビシイ事態を招いてしまいます。特にソフトウェアの保守段階で問題になることが多いようです。

これらはソースコードに関してブラックボックス化している、つまり発注側がまったくコントロールができていない状態であることに起因しています。

一旦ソフトウェアがブラックボックス化してしまうと、その品質を維持していくためには、修正リリースのたびにシステム全体のリグレッションテスト(※2)を行うしかなくなりますので、膨大なコストと期間が必要になってしまいます。

しかし、コスト面の制約からシステム全体のリグレッションテストを毎回行うなんてとてもできないので、結局ソフトウェアの品質については外注先のレベルに依存せざるを得ないという情けない話になってしまいます。

何か問題が起きるたびに、外注先を呼びつけては品質改善策についての報告を求める、といった場当たり的な対応しかできないのでは、悲しいですよね。

とはいえ、全てのソースコードを自社内のバージョン管理ツール(※3)で完全にメンテナンスし、外注先には必要なファイルのみ更新させるというのでは、自社開発と変わらない管理コストがかかってしまいますし、発注側の担当者からは、そもそもプログラミング言語なんて分からないからソースコードのチェックなんてとても無理、という声が聞こえてきそうです。

今回は、最小の手間で必要な効果を得られる外注プログラムのソースコード管理について考えてみたいと思います。

実は、発注側が以下の項目さえ正確に把握できれば、ソースコードをあるていどコントロールすることは可能です。

1. システムを構成する各ソースコードのファイル単位での機能（役割）と生成されるバイナリモジュールとの対応関係


2. 各ファイルのバージョン（各ソースコードに埋め込む）とバージョン管理ツールにコミットしたリビジョン


3. 修正した内容（バグ、機能追加）について変更したファイルと修正後バージョン
   


4. 各ソースコードファイルのリリース毎の差分
   

バージョン管理ツール自体は、外注先で管理してもらってかまいません。発注側がリリースファイルを受け取る時に、変更についての結果情報を提供してもらうだけでよいのです。

上記の情報から、リリースに含まれる改修内容と、改修したファイルの関連性が把握できますので、不当な変更が含まれていないかをチェックできます。

また、ファイルの差分にバージョンの新旧が表示されますので、外注先が修正前バージョンを間違っていないことを確認できます。

なによりも、発注側がこのような管理を行っていれば、外注先もいい加減なソースコード管理ができなくなります。

そして、これらの結果として、例えば、「今回のリリースはここの部分的な修正だけだからリグレッションテストはこの範囲でよい」といった的確な判断が可能になり、品質についての漠然とした不安がなくなります。

プロジェクトマネージャの精神衛生上も非常によいという訳です。

さて、実際にこれらの各項目を正確かつ効率的に管理するには、運用ルールの確立とツールが必要になります。

ここでは、弊社でサービスを提供しているProot（プルート）インシデント管理システムを例に、具体的な運用方法を説明してみたいと思います。

まず、プログラム修正の契機となるバグ発生や仕様変更要求を「インシデント管理票」「障害連絡」または「仕様変更依頼」シートで投稿します。
これが発注側から外注先への修正依頼となります。
シートの種類（テンプレート）は運用ルールによって適宜決定します。

外注先は、プログラムの修正が必要な場合は、リポジトリからソースコードを取出して修正作業を行います。

テストが完了したならば、発注元に作業が完了したことを報告し、ファイルをリリースしますが、その前にリポジトリにソースコードのコミットを行います。（これでコミット漏れを防ぐことができます）

コミットを実施すると、リポジトリのリビジョンが確定しますので、そのリビジョン番号をリリースファイルと一緒に報告します。使用するテンプレートは「リリースファイル」です。

これにより、リリースファイル毎にリビジョン番号が記録されますので、前回のリリースと今回のリリースでリビジョン間の差分(diff)を取得すれば、ソースコード上でどのような変更が行われたかを正確に把握することができます。

発注元は、リリースされたファイルを使用して動作確認を行い、問題がなければインシデントをクローズし、ユーザにファイルをリリースします。

上記運用例では、外注先がプログラムをリリースするときは、リビジョン単位でリリース情報を投稿するものとしています。

リリースするバイナリファイル自体は、添付ファイルにしてもよいですし、ファイル共有サーバのパスを記録するだけでもよいでしょう。（Prootではテンプレートは運用にあわせて自由に変更できます）

１件のファイルリリースには、複数のインシデントが含まれるのが普通です。改修作業はまとめて実施する方が効率がよいからです。

投稿された「インシデント」と「リリースファイル」は関連リンクで関連付けます。これにより、どのリリースでどのインシデントが解決したのかを相互に知ることができます。

発注側は、差分ファイルをレビューし、修正前後のバージョンが適切か、修正箇所が修正内容と関係ない箇所に及んでないことを確認します。
プログラミング言語の知識がない場合は、外注先に差分ファイルを元に修正箇所の説明をしてもらうとよいでしょう。

また、Prootには投稿をフォルダに格納する機能もありますので、バイナリファイル単位でフォルダを作成し、関連する「リリースファイル」をいれておくことにより、各モジュールのリリース履歴を一覧することができるようになります。

以上、Prootインシデント管理システムを例に外注プログラムのバージョン管理についてご説明してきましたが、皆さんのプロジェクトではこのような運用がきちんとされていますでしょうか？

うちはそこまで管理する必要はないなあ、と思われた方も、しかしまったくコントロールがないというのは確かにまずいな、と感じていらっしゃるのではないでしょうか？

大切なのは、各組織の運用にあわせた適切なレベルの管理を行うことです。あまりに厳格なルールを作っても管理倒れになるだけです。

もし外注プログラムのバージョン管理について検討してみたいということでしたら、Prootインシデント管理システムには無料お試しサイトもありますので、是非一度お試しください。
Prootインシデント管理システムのサイトはこちらです。

※1)デグレード(degrade)。ソフトウェアに改善を加えた結果、前より悪くなることを指します。

※2)プログラムを修正したことにより、何らかの悪影響が引き起こされていないかを確認するテスト。修正の影響範囲が不明な場合は、システム全体の機能をテストする必要があります。

※3)ファイルの変更履歴を管理するシステムで、リポジトリと呼ばれるディレクトリに各ファイルの情報を格納しています。CVS、Subversionなどがあります。

イラストは、ソザイヂテン http://www.sozaijiten-business.rash.jp/ を使用しています。