Evansステージングサーバでのシステムテストに入ってから、自分の書いたコードに問題が見つかり、それを知らせるメールかテストマネージャから届く、そんな経験はプログラマなら誰もがしていると思います。そのメールを見た時にプログラマか最初に思うことは、「すぐにそっちへ行って直させてくれ。どこが悪いかはわかっているから」ではないでしょうか。「プログラマがステージングサーパを触ってもいいじゃないか」そう考えるのは一見、間違ってはいないように思えます。大局的にとらえるとやはりそれは間違いなのです。Webシステム開発プロジェクトの環境は、次のようにアーキテクチャ分割されているのが普通です。統合テストを手動、あるいは自動で行う開発サーバ品質保証(QA)チームや顧客が受け入れテストを行うステージングサーバ本番環境もちろん、実際にはこれですべてではなく、他にもソースコード管理(SCM)や問題管理システム(ITS)などのサーバやサービスなどが色々と関わるのですが、おおまかには上のとおりと考えていいでしょう。上記のように分割されている場合、開発者は(たとえ上級開発者であっても)決して、開発サーバより後の環境に触れるべきではありません。開発の大半は、開発者のローカルマシンで行われます。開発者はローカルマシン上で自分に合ったIDEや仮想マシンを利用し、その他にも独自のツールを使うなど個々に工夫して、良いコードをさくために最善を尽くします。SCMへチェックイン後は(自動であれ手動であれ)開発サーバに配備させて、そこで必要に応じてテスト、修正を行うことになります。そのテストにより、全体が問題なく機能するか確認するのです。ここで注意すべきなのは、チェックイン以降は、開発者は基本的にはプロジェクト進行の「傍観者」になるということです。コードをパッケージングして、QAチーム向けのステージングサーバに配備するのは、ステージングマネージャの仕事です。開発者が開発サーバより後の開発環境にアクセスすべきではないのと同様、QAチームおよび顧客は、開発サーバ上のものには手を触れるべきではありません。受け入れテストが出来る状態が整ってからリリースし、配備するのです。「開発サーバ上のシステムをちょっと見てくださいませんか?」と顧客に頼んではなりませ人そのプ口ジェクトでコードを書いている人間が1人だけであれば話は違ってきますが、普通は他にもコーディングをしている人がいるはずです。全員が「いつユーザに見られても大丈夫」という状態でいるとは限りません。開発サーバとステージングサーバの両方にアクセスでさるのは、リリースマネージャだけにすべきです。どんなことがあっても、開発者は本番環境に触れてはなりません。問題が起きた場合でも、それを修正するのは基本的に運用チームの仕事であり、仮に開発者が修正にあたるにしても、それは運用チームからの依頼であるべきです。修正をSCMへチェックインした後で、彼らがSCMからパッチを作成して運用するのです。私がプログラマとして経験した中でも「最悪」と言える事件は、誰か(まあ、それは私、なんですが。)が、この「必ずSCMへのチェックインしてSCMからパッチを作る」というルールを守らなかったために起きたものでした。システムのどこかが壊れても、本番環境でそれを修理しようなどと考えてはいけません。プログラマが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。