連載
NAgileで始める実践アジャイル開発

第5回 常時結合のススメ

常時結合を実践するためには前述のCCNETを導入するだけでは難しい。なぜかというとチーム全体で取り組まなければいけないテーマだからだ。そこで実践するために必要なことや注意すべきことを6カ条にまとめておいた。

常時結合を実践するための六箇条： 其の一. ソース・コード管理システムを利用すること 其の二. ビルドを自動化すること 其の三. テストを自動化すること 其の四. 単体テストが正常に通過することを確認してからチェックインすること 其の五. 一度チェックアウトしたコードは遅くてもその日のうちにチェックインすること 其の六. 問題が発生した場合はすみやかに解決すること

壁に貼っておくことだ。

う、また来ましたか（汗）。あの、それぞれについて解説をいただけないでしょうか。

よかろう。では其の一からいくぞ。先ほどの常時結合が必要な理由でも出てきたが、ソース・コード管理システムは分かるな？ ソース・コードのバージョン管理を行うソフトウェアのことで、.NET開発の場合、Visual SourceSafe（以降、VSS）や Visual Studio 2005 Team Foundation Serverのソース・コード管理機能、オープンソース・ソフトウェアであるSubversionやCVSなどの選択肢がある。特に使用するソフトウェアによって同一ファイルの編集に対する考え方が違うので、そこに注意するとよいだろう。

考え方ですか？

そうだ。例えばVSSの場合、1つのファイルを複数の開発者が同時に編集することは基本的に許さないが（※VSSの設定を変更し、同時に編集することも可能）、Subversionの場合は1つのファイルを複数の開発者で同時に編集することも可能だ。

なるほど、ソース・コード管理の基本となっている考え方が違うのですね。ソース・コード管理システムならすでに利用していますが、なぜ常時結合に必要なのですか？

ひと言でいうと、変更を戻すことが可能になるからだ。もし自分が行ったコードの変更によってほかのコードに悪い影響を与えている場合でも、常時結合を行うことでそれを検出できるようになる。そのような場合は、影響の範囲や問題の深刻度を判断し、最悪の場合、ソース・コード管理の機能を利用して前のバージョンに戻すことができる。なので、ソース・コード管理に関しては常時結合に必要と考えるよりは、ソフトウェア開発の基盤として当然あるべきものとして考えるのがよかろう。

なるほど、そういうことなんですね。

其の二はそのままだな。常時結合を行うと、1日何回もコードを結合しビルドを実行する必要が生じる。よって、そのたびに手動でビルドを行うというのはあり得ないことだ。ビルドを安全に、素早く実行するためにもビルドの自動化は重要となる。できればプロジェクト開始時点でビルドの自動化を行い、自動ビルドのスクリプトを常時結合の環境に組み込むとよいだろう。

いわれてみると当たり前のことですね。ということは、其の三も常時結合を行ううえで、毎回テストを手動で行うことはあり得ないということですね。

そのとおりだ。さすがに前回でビルドの自動化について学んだだけはあるな。

ふふふ、勉強しましたから

テストの自動化については繰り返しになるが、テスト駆動開発を行うことでテスト・コードが生成されるので、それを実行すればよい。滝はテスト駆動開発を頑張って続けているようなので、いますぐに常時結合を始めても大丈夫だろう。

はい。頑張ったかいがありますね。

其の一から三までは、常時結合を始めるための前提条件ともいえることだ。常時結合を始める場合は、これらを優先的に実施して行うように。残りは常時結合を実践するうえでの心構えだ。続けていくぞ。

はい、お願いします。

其の四も読んだままだな。開発者はまず自分の開発マシンで単体テストを行い、テストが正常に完了したコードをソース・コード管理システムへチェックインするということだ。

これは、信頼できないコードをチェックインするなということですよね。

そういってもよいだろう。例えば、ある開発者がバグを含んでいるコードをソース・コード管理システムへチェックインし、ほかの開発者がそのコードを呼び出したとする。呼び出されたコードが期待する振る舞いをしてくれなかった場合に、それが呼び出した方からはバグなのか仕様なのか判断がつかないことも多い。その際に、呼び出した側で期待される振る舞いとなるように、補正を行ってコードを記述してしまう、となるともう最悪だ。問題がどんどん複雑化していき、最終的には影響範囲が分からないので修正できないコードとなってしまうからな。従って、単体テストを行わずにチェックインするという行為は、同じチームのほかの開発者に対する背信行為といってもよいぐらいの危険な行為なのだ。

そこまでいっちゃいますか。

いっちゃいますとも。重要なことは、ソース・コード管理システムへチェックインされたコードはチームの開発者間で共有される公式なコードになるということだ。そこを忘れてはならんぞ。必ず自分の開発環境で単体テストが正常に通ることを確認してからチェックインするように。

はい！ 気を付けます。

其の五は、端的にいうと、チェックインを細かく何回も行えということだな。誰にでも経験があると思うが、滝もソース・コードをチェックアウトしっぱなしにして帰ってしまったことはないか？

ぎくっ！……確かに、たまにチェックインを忘れて帰ってしまうことがあります……。

冒頭でも述べたが、常時結合は開発者間のズレを調整するための仕組みだ。ソース・コードを自分の開発環境にチェックアウトしっぱなしということでは、それだけ開発者間の同期を取る間隔が大きくなってしまう。この危険性は冒頭で説明したとおりだ。同様に、ソース・コード管理システムと自分の開発環境との同期も頻繁に行う必要がある。VSSを利用している場合は、明示的に操作を行わない限り、ソース・コード管理システムのサーバと個人の開発環境の同期は行われない。最低でも1日1回は「最新のコードを取得」という操作を行って明示的にソース・コード管理システムと同期を取るようにすることも忘れないように。

以後気を付けます……これって其の四の教えとも関係がありますよね？

よいところに気付いたな。其の四の教えに従って、単体テストも十分に行われたコードを書こうとするとそれなりに時間が必要となる。しかし其の五の教えに従うと、ほかの開発者のコードと頻繁に同期を取るためにチェックアウトしている期間は短い方がよい。確かにこれらは相反しているので、バランスを取る必要があるだろう。

具体的にはどうすればいいのでしょう？

プロジェクトのタスク管理とも関係してくるので少々話が大きくなってしまうが、開発者個人のレベルでは数時間（2〜8時間程度）の単位でタスクを管理し、その単位でコードを編集しチェックインするとよいだろう。もし、チーム・レベルで管理しているタスクの管理が数日（1〜3日）という単位では、常時結合を行う作業の単位として粒度が大き過ぎるので、その場合は各開発者がさらに複数のタスクに分解するとよい。

ふむふむ。

そうすると開発者レベルのタスクは、「顧客クラスの登録メソッドを実装する」などの実装レベルにまでに詳細化できるので、それらを実装し、単体テストを行ってからチェックインを行えばよい。よって、一度チェックアウトしたコードはその日のうちに修正とテストを完了し、チェックインするというのが1つの目安となるだろう。

なるほど、よく分かりました。

ちなみに其の五の教えの中には、帰宅する前には必ずチェックアウトしているコードがないことを確認し、1日の仕事を終えて気持ちよく帰るという意味も含まれている。やり残したことがあってモヤモヤした状態ではアフターファイブも満喫できないからな。

アフターファイブって……その言葉久しぶりに聞きました（苦笑）。

其の六は、もし結合が失敗した場合は直ちにその問題を取り除き、正常な状態に修正するようにということだ。何かしら問題が発生した場合はその場ですぐ解決するようにした方がよい。それを先延ばしにすればするほど問題を解決することが難しくなるからな。これは常時結合を実践するだけでなくプロジェクト管理を行ううえでも大切なことだ。

確かにそのとおりですね。恋愛もこじれる前に何とかした方がよいですもんね。

なんだ、誰かとこじれてるのか？

いや、私じゃなくて一般的な話で。

まあよい。ちなみにラバランプ（パトロールランプ）というものがあるので、それを活用すると問題の発生を速やかに知らせることができる。

パトロールランプ

写真はパトライト社のパトロールランプNHM。

これは、XFD（eXtreme Feedback Device）とも呼ばれてアジャイル実践者に好んで使われているものだ。メールでの通知もよいが、メールはPCの前で作業していないと気付かないからな。日次ビルドのための夜間ビルド結果はメールで通知し、日々の常時結合で何か問題が発生すればラバランプで知らせるというように通知の手段を使い分けるとよいだろう。写真のラバランプは、もともとがネットワーク監視機器なので少々高めだが、USB接続の1万円以下のラバランプも市販されている。滝のために買っておいたから、後でつないでおくように。

いつの間に！！ （笑）はーい、後でやっておきます。