More than 5 years have passed since last update.

VCS入門：4章 VCSのみでの限界

Last updated at 2016-03-18Posted at 2013-10-16

4章 VCSのみでの限界

さて、VCSを使うと、それだけでハッピーになれるかというと、世の中そんなに甘くありません。例えツールを使っていても、協調作業（コラボレーション）を行うには、各人が好き勝手していては上手くいくはずもありません。

そんな世界をまた少し覗いてみましょう。

VCSを導入したあなたのチームは、しばらく何の問題もなく開発を続けていました。

そんなある日、何日か前に行った仕様変更で、影響があった成果物を調査してほしいという依頼を受けました。何でも、どうやらその仕様変更で、他の機能の動作が少しおかしくなっているらしいのです。

あなたは早速VCSの機能を使って、リポジトリの変更履歴を見てみました。

日時	コメント	作業者
4/14 13:31	○○機能に△△処理と××処理を追加した。ついでに□□のバグを修正	斎藤京子
4/14 11:55	昼休み前のコミット	田中一郎
4/14 10:35	コンパイル失敗するけど、原因が分からないので一応コミット	高橋太郎
4/14 10:14	hoge.csファイルにdoFugaメソッドを追加	田中一郎
4/13 18:01	4/13日分コミット	鈴木花子
...	...	...

履歴を見ると、メンバーは好き勝手にリポジトリに反映しているようです。そのため、目的の仕様変更に関連する記述がなかなか見つかりません。

30分ほどして、ようやく目的の履歴を見つけました。が、今度は一度に色んな変更、追加、削除を、いっぺんに行っていることが分かりました。

仕方ないので、その履歴をPC内の作業フォルダに取り込んで再現した後、変更箇所を一つ一つ確認していかなければなりませんでした。

VCSを使えばハッピー・・・なはずでしたが、どうやらVCSを使った「だけ」では、そうはならないようです。

問題を整理してみると、リポジトリへの反映時に次のようなことが起きているようです。

日時	コメント	作業者
4/14 11:55	昼休み前のコミット	田中一郎
4/13 18:01	4/13日分コミット	鈴木花子

作業の区切り ではなく、「帰る前」、「休憩前」といった 時間の区切り で、リポジトリに反映しているケースです。

このケースでは、本来関係ないもの、中途半端なものが、その履歴に含まれてしまう懸念があります。そのため、後で履歴を参照する際にノイズにしかなりませんし、メッセージを見ても何もわかりません。

日時	コメント	作業者
4/14 10:14	hoge.csファイルにdoFugaメソッドを追加	田中一郎

こちらは「とりあえず」よりは、一見幾分マシのように思えます。

しかし、実際のVCSを履歴を見ると「どこをどう直したか」は簡単に分かります（例では省いています）。

反面、「何故」変更したか、「何のために」変更したかについては、履歴からではわかりません。したがって、履歴を調べる為の情報としては、あと一歩足りません。

日時	コメント	作業者
4/14 10:35	コンパイル失敗するけど、原因が分からないので一応コミット	高橋太郎

このケースは一番避けなければならないやり方です。

なぜなら、「動かない」ものが成果物として管理されてしまうため、例えば他の人がテストをしようとしてもできない、といったチーム全体の問題に発展してしまう可能性があるためです。

日時	コメント	作業者
4/14 13:31	○○機能に△△処理と××処理を追加した。ついでに□□のバグを修正	斎藤京子

このケースはこれまでで一番マシではあります。何を行ったかも明確です。

しかし、「複数の変更」を一度に反映していると、その履歴で行われたファイルの変更が、「どの」変更によるものなのかが分からなくなってしまいます。そのため、上のシミュレーションで行ったように、手作業でファイル変更を切り分ける必要があります。

VCSは便利ですが、あくまでツールです。ツールは人の作業を補助はしてくれますが、それだけではうまくいきません。ましてやシステム開発はチームで行うものです。2人以上がコミュニケーションを取るには、最低限のルールが必要です。

このことを言い換えると、VCSはルールと対になって初めてその真価を発揮する、ということです。

そこで、まずは最低限作業フォルダーの内容をリポジトリに反映する際のルールを決めましょう。先ほどの良くない例を見れば、守るべきルールが見えてきます。それが次のルールです。

これらのことから、VCSのVersion（バージョン、版）とは「ファイル単位の改訂内容」を表すのではないことがわかると思います。Versionとは「作業単位の変更内容」を表すのです。このことを忘れないようにしてください。

そして、上記ルールに従って考えると、「一言で何をやるのか表せる単位で作業を区切って、リポジトリに反映する」ことが重要です。一言で表せないのならば、それは行おうとしている作業が大きすぎるのです。こんなときは、より小さな単位に分けて作業を行えないか考えてみましょう。

なお、この考えはやむなく共有フォルダーで管理しなければならないようなときでも大事な考えです。作業単位で考えることで、バックアップを取るタイミング≒作業の開始前後と考えることができ、多少は管理がしやすくなります。

さて、ここではリポジトリへの反映時のルールだけを定めました。しかし、開発には様々な要因が絡むものです。次の章ではそういった要因を管理するための考え方について説明していきましょう。