【30】そのコードに触れてはならない！

カル・エヴァンス（Cal Evans）

　ステージングサーバでのシステムテストに入ってから、自分の書いたコードに問題が見つかり、それを知らせるメールがテストマネージャから届く、そんな経験はプログラマなら誰もがしていると思います。そのメールを見た時にプログラマか最初に思うことは、「すぐにそっちへ行って直させてくれ——どこが悪いかはわかっているから」ではないでしょうか。

　「プログラマがステージングサーバを触ってもいいじゃないか」そう考えるのは一見、間違ってはいないように思えます。しかし、大局的にとらえるとやはりそれは間違いなのです。なぜでしょうか。

　Web システム開発プロジェクトの環境は、次のようにアーキテクチャ分割されているのが普通です。

　もちろん、実際にはこれですべてではなく、他にもソースコード管理（SCM）や問題管理システム（ITS）などのサーバやサービスなどが色々と関わるのですが、おおまかには上のとおりと考えていいでしょう。上記のように分割されている場合、開発者は——たとえ上級開発者であっても——決して、開発サーバより後の環境に触れるべきではありません。開発の大半は、開発者のローカルマシンで行われます。開発者はローカルマシン上で自分に合った IDE や仮想マシンを利用し、その他にも独自のツールを使うなど個々に工夫して、良いコードを書くために最善を尽くします。

　SCM へチェックイン後は（自動であれ手動であれ）開発サーバに配備させて、そこで必要に応じてテスト、修正を行うことになります。そのテストにより、全体が問題なく機能するか確認するのです。ここで注意すべきなのは、チェックイン以降は、開発者は基本的にはプロジェクト進行の「傍観者」になるということです。

　コードをパッケージングして、QA チーム向けのステージングサーバに配備するのは、ステージングマネージャの仕事です。開発者が開発サーバより後の開発環境にアクセスすべきではないのと同様、QA チームおよび顧客は、開発サーバ上のものには手を触れるべきではありません。あくまで受け入れテストができる状態が整ってからリリースし、配備するのです。たとえば「開発サーバ上のシステムをちょっと見てくださいませんか？」と顧客に頼んではなりません。そのプ口ジェクトでコードを書いている人間が 1 人だけであれば話は違ってきますが、普通は他にもコーディングをしている人がいるはずです。全員が「いつユーザに見られても大丈夫」という状態でいるとは限りません。開発サーバとステージングサーバの両方にアクセスでさるのは、リリースマネージャだけにすべきです。

　そして、たとえどんなことがあっても、開発者は本番環境に触れてはなりません。問題が起きた場合でも、それを修正するのは基本的に運用チームの仕事であり、仮に開発者が修正にあたるにしても、それは運用チームからの依頼であるべきです。そして修正を SCM へチェックインした後で、彼らが SCM からパッチを作成して運用するのです。私がプログラマとして経験した中でも「最悪」と言える事件は、誰か（まあ、それは私、なんですが……）が、この「必ず SCM へのチェックインして SCM からパッチを作る」というルールを守らなかったために起きたものでした。たとえシステムのどこかが壊れても、本番環境でそれを修理しようなどと考えてはいけません。