犯罪的なコミットエンドランを防ぐには

それは、暗くなってからのことです。チームはこのイテレーションで作る新しい機能セットの最後の部分を完成させようとしており、あなたは室内にリズムのようなものを感じていました。しかし、ジョンは少し急いでいました。彼はデートの時間に遅れていたので、がんばって自分のコードを完成させ、コンパイルし、チェックインして出て行きました。数分後、赤ランプが点灯しました。ビルドできなくなったのです。

ジョンは自動テストを実行する時間がなかったので、コミットエンドランを決めていきました。結果、チームメンバー全員を立ち往生させたのです。状況は暗転し、リズムは失われました。バージョン管理システムに更新をかけると、ローカルマシンにも動かないコードが送られてくることを誰もが知っていました。この日は、間近に迫ったデモのために、実行すべきインテグレーションが大量にありましたが、これによって、大幅な中断が入りました。誰かが時間を割いてジョンがかけた更新を元に戻さなければ、インテグレーションを実行することはできません。ジョンは、チームの流れを止めたのです。

これは残念ながらよくある話です。流れを止めるコミットエンドランはまさに犯罪です。デベロッパーが自分の作業時間を切り詰めようとして、同僚の時間を無駄にさせるなど、まったく無礼なことです。しかし、どこの職場でも、このようなことが起きています。なぜでしょうか。それは、システムをビルドしたり、テストを実行したりするのに時間がかかりすぎるからです。

ここは、システム・アーキテクトであるあなたの出番です。あなたは、デベロッパーたちの力を引き出せるような柔軟性の高いアーキテクチャーを作るために力を注ぎ、彼らにテスト駆動開発などのアジャイルの手法を教え、継続的インテグレーション用のサーバーをセットアップしたはずです。そこまでしたのなら、どんな形であれ、同僚の時間を潰し、流れを止めるようなことは絶対に認められないという文化を育てるべきです。

そのためには何よりもまず、自動テストができるよう健全なアーキテクチャーを作らなければなりません。これでデベロッパーたちの態度が変わるのです。テストが素早く実行できるなら、デベロッパーたちはもっと頻繁にテストを実行するようになるでしょう。これ自体もよいことですが、ビルドを止めるようなコードを放置して同僚に迷惑をかけることもなくなります。

テストが外部システムに依存していたり、データベースアクセスを必要とする場合には、ローカルマシンではモックやスタブ、最悪でもインメモリーデータベースを使うようにリエンジニアリングしましょう。そして、ビルドサーバーにはテストをゆっくり実行させるのです。コンピュータを待たなくて済むようにしなければ、デベロッパーたちは近道を狙って、結局別の問題を起こすようになってしまいます。

時間を割いて、仕事が早くできるようにシステムを作りましょう。そうすれば、流れが良くなり、独りよがりな仕事をする理由がなくなるので、最終的には開発のペースを上げることができます。モックを使い、シミュレーターを作り、依存関係を減らし、システムを小さなモジュールに分割し、その他何でもできることをしましょう。コミットエンドランを決めてやろうなどと思う理由さえなくしてしまうのです。