第2回 チーム開発の落とし穴を埋める開発環境の整理術

 開発環境の未整理状態は開発工程全体に悪影響を及ぼす要因ともなる。例えば、要求仕様書の管理ミスで、大事な機能を実装し忘れたり……。刻々と変化する開発環境を整理し、開発工程全体に秩序をもたらすにはどうすればいいか。そのノウハウを伝授する。第2回は、チームでソフトウェアを開発するときに起きるさまざまな問題の解決策を提示する。(アットマーク・アイティ編集局)

» 2004年10月15日 12時00分 公開
[田中友子(SourceForge 技術担当),VA Linux Systems Japan(株)]

問題:作業が重複する/ほかの人の作業を上書きする/ファイルを変更するときに、関連ファイルを変更し忘れる

 自分1人でソフトウェアを開発しているのであれば、個々の機能が実装されている場所や実装方法は頭の中に残っています。従って作業が重複したり、実装した内容を異なるもので上書きしてしまったり、ということは起こりにくいでしょう。

 しかし、複数の開発者と一緒に1つのソフトウェアを開発する場合、自分の知らないところで、知らない実装がどんどん行われています。新しい機能を1つ追加しようとしても、適切だと思われる場所にほかの開発者による実装があり、これを変更しなければならなくなる場合もあります。 この作業を安易に行ってしまうと、ほかの開発者の作業を抹消してしまったり、関連する個所を変更し忘れてしまったり、ということになりかねません。また、ほかの開発者の作業内容を把握し切れず、同じ機能を異なる実装方法で実装してしまうことも起こり得ます。

 似たような話として、テスト期間中のバグ修正の話があります。テスト期間中に報告されてきた不具合をその都度修正するような方法を取ったとします。するとテスト半ばで発見された不具合修正中に、すでに終わったテストに影響するような変更をしてしまうという可能性も否定できません。このときは、もう一度影響するテストを実行して、デグレードを起こしていないか確認しないと、潜在的な問題を残したまま出荷してしまうことになります。

 これらの問題は、共同開発時の開発者間のコミュニケーションや情報共有が不足していることが根本的な原因として挙げられます。ほかの開発者が行っている作業をお互いに確認しつつ、その作業に悪影響を与えないように気を付けながら自分の作業を進めることができれば前述の問題は起こりにくくなるわけですから。逆に、コミュニケーションが徹底されていない場合、各開発者が正しいと思っているものや方法がばらばらになってしまうのです。

 ただ、開発者全員が、自発的にほかの開発者全員が行っている内容を把握するのは根本的に不可能です。そこで必要なときに必要な情報を把握できるようにしておくという考えが生まれます。作業の対象や、作業方法、状況の確認方法、伝達方法を定めて、全員がそれに従って開発を行うという方法です。ここではこの改善方法について提案していきます。

ソフトウェア構成管理ツール、バージョン管理ツールの導入

 世の中にはソフトウェア構成管理ツールやバージョン管理ツールと呼ばれるツール(以降、バージョン管理ツール)があります。これらは近年のソフトウェア肥大化に伴い急速に普及しつつあります。いずれのツールも共通して、最低限次のような機能があり、各開発者の作業が互いに悪影響を及ぼさないように、またお互いの作業を確認できるようにサポートしてくれます。

  1. 変更の排他制御:1つのファイルを同時に複数の開発者が変更してしまうのを防ぐ
  2. 変更履歴の保持:変更を行った人、日時、差分などの情報を保持する
  3. 過去の状態の取得:任意の時点または特定の意味をもつファイル群を取り出す

 まず簡単にバージョン管理ツールの説明をします。

 バージョン管理対象のファイルはすべてリポジトリで一括管理されます。各開発者は変更したいファイルをリポジトリの中から取り出します。この操作は一般的にはチェックアウトと呼ばれます。取り出したファイルに対して変更作業を行い、変更が終わったらリポジトリの中に変更後の内容を登録します。この操作は一般的にはチェックインと呼ばれます。

ALT バージョン管理対象のファイルはすべてリポジトリで一括管理される

 この一連のチェックアウト/チェックイン操作で、そのファイルについて新しい「版」ができます。チェックアウト/チェックインを繰り返すとその都度、新しい版がリポジトリ内部に作られていきます。この版のことを一般的にバージョンまたはリビジョンと呼び(ここではバージョンとします)、各バージョンには自動的にシーケンシャル番号が割り当てられるようになっています。

 ここで、前述の3点について、それぞれの仕組みを説明します。

(1)変更の排他制御

 チェックインをするときは、そのユーザーのチェックアウトからチェックインの間に別のユーザーのチェックインがなかったか確認できます。別のユーザーがチェックインしていた場合は、そのユーザーの変更内容を確認してからでないとチェックインできないようになっています。

ALT 変更の排他制御

 このような仕組みで、同じファイルへの複数ユーザーによる変更は解決できます。

(2)変更履歴の保持

 チェックインが行われたときには、新しく作成されたバージョンの付加情報として、チェックインを行ったユーザー名/日時/任意のコメントが記録されます。任意のバージョン間の違いやその間の変更の履歴を確認することもできますので、少なくともファイルの特定の個所が問題を起こしたときなどに、その個所が誰によっていつ追加されたのかということは確認できるようになります。

(3)過去の状態の取得

 最新のバージョンでビルドなどに問題があり、正常にできていた状態に戻したいような場合も、バージョン管理ツールを使っていれば過去の任意のバージョンのファイルを取り出せます。日時を指定して取り出すこともできますし、特定の目的(例えばリリース)で使用されたファイル群に目印をつけておいて目印をもとに取り出すこともできます。

 どのバージョン管理ツールでも最低限行えるこの3点については、ツールなしで同じ運用を行うのはかなり難しいです。方法はもちろん、全開発者がその方法に忠実に行うようにすることや残っている記録が正しいものかどうかを保証することを考えなくてはなりません。開発者や関係者全員が間違いなく同じ最新のファイル群に対して作業をしていることを確実にするためにも、バージョン管理ツールを導入する価値はあるでしょう。

ソフトウェア構成管理ツール、バージョン管理ツールの活用

 さて、最低限の排他制御ができていても、作業の重複や作業忘れを防止することにはなりません。例えば、同じ機能を実装することを考えても、方法は何通りかあり、その方法によっては同じファイルではなく別々のファイルを変更する場合もあるからです。つまり、開発者間の作業を効率よく分担し、互いの作業に悪影響を与えないように開発を行っていくためには、単なるファイル個々の物理的な変更管理ではなく、変更を意味的に管理することが大切になってきます。ここでは、過去の変更と将来の変更の2点に絞って考えていきます。

(a)過去の変更の意味的な管理:変更理由・変更内容・変更対象(検索できること)

 過去に行われた変更について、行った開発者・日時・対象個所だけでなく、変更が行われた理由・目的を、チェックイン時にコメントとして入力するなど、把握できるようにしておくことが大切です。例えば、ソースコードのある個所を読む場合でも、何も情報がない場合と、その個所が機能Aの実装のために追加されたという情報がある場合とでは、その後の作業効率が違います。

 また、ほとんどのバージョン管理ツールでは、変更履歴やチェックインコメントを検索できます。変更内容に関わる言葉をキーワードとしてほかの実装箇所や実装時期を検索できれば、変更内容の理解にかかる時間が短くなるのはもちろんのこと、追加作業の影響範囲も予想できますし、その個所を応用して機能A′を作成することもできます。

(b)将来予定している変更の管理:変更目的・担当者

 本当の意味で作業の重複を防ぐには、変更の目的となる予定作業が明示されていて、各予定作業の担当者および優先度が決められていることが効果的です。逆に、このような予定作業の管理がなされていないと、各開発者は1つの作業を進めるたびに、やるべき作業の確認、優先度の再確認、すでに実装されていないかの確認などに時間をかけなくてはならなくなります。ここでいう予定作業というのは、設計工程であれば要件そのものか要件を具体化した項目になるでしょう。

 上記の2点に書かれていることを総合すると、バージョン管理ツールを使うときには、次のようなルールを順守することで、無駄の削減/開発効率の向上を期待できるようになります。

  • あらかじめ個々の作業を明示しておくこと
  • 各予定作業には、識別用番号、担当者、優先度、作業内容を決めておくこと
  • チェックアウト/チェックインは1つの予定作業単位で行うこと
  • チェックインを行うときには、必ず、作業目的・理由を付加情報として入力すること。予定作業に対する作業のチェックインであれば、その予定作業の識別用番号などを入力すること

 また、このような環境の上で開発を行うことによって、開発者同士が同じものに対して開発を行っていることを確実にし、互いに入力した情報を確認し合うことによってコミュニケーション・情報共有を高めていくことができるのです。

著者プロフィール

田中友子

 VA Linux Systems Japan (株)、SourceForge 技術担当。米国製構成管理ツールやコラボレーションウェアの日本語化作業およびテクニカルサポートに従事。



Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ