インストールやデプロイに関わる作業というものはどうしても後回しにされ、プロジェクトの終了間際になってから始めることになりがちです。インストールツールを書く作業を丸投げされたリリースマネージャが、その作業を「必要悪」として考えている、などということも珍しくありません。レビューやデモで、デプロイやインストールが一応正しくできていることを確認はするのですが、そのための環境が単なる「間に合わせ」で、適切なものでないことも多いのです。これでは、チームのメンパーは、デプロイのプロセスやデフロイ先の環境などに関してまったく学ぶことができませんし、改善したいときには手遅れということになってしまうでしょう。
インストール/デプロイ作業こそが、顧客がはじめて製品に触れる機会です。この作中自体は簡単なものかもしれませんが、信頼できる(少なくともデバッグしやすい)本番環境を作り上げるための第一歩です。顧客が実際に使うのはデプロイされたソフトウェアです。デプロイの際にアプリケーションが正しく設定できなければ、顧客は本格的に使い始める前に、製品に対して疑いを持ってしまうでしょう。
プロジェクトの最初の段階からインストールプロセスに関する作業を始めていれば、十分な時間を確保し、製品の開発サイクルに連動してプロセスを進化させていくこともできるでしょう。アプリケーションのコードを、あらかじめインストールやデプロイが簡単にできるよう考えて書くこともできます。クリーンな環境でインストールやデプロイのプロセスを定期的に走らせテストしていれば、コードが開発環境やテスト環境に依存したものになるのを防ぐこともできます。
デプロイ関連の作業を後回しにすると、コードが開発環境やテスト環境に依存したものになりやすくなります。それを回避するための対策を講じることは容易ではなく、大変な労力が必要になってしまいます。こう言うと「IDE を利用すればよいのでは」と考える人もいるでしょう。確かにIDEを使えば環境を自在に扱うことができるため、デプロイ作業が少しは楽になるかもしれません。しかし、いずれにしろトレードオフはあるので、それが具体的にどんなものかを早めに知っておくに越したことはないでしょう。
プロジェクトの初期には「デプロイができる」ということよりも、開発者のコンピュータ上でアプリケーションが動作する(一応、正しく動作しているように見える)ことの方に価値が置かれがちです。しかし当然のことながら、ターゲット環境でのデモができるようになってはじめて、ソフトウェアはビジネス上の価値を持ちます。「開発者のコンピュータで一応動作する」という状態から、「デモが可能である」という状態にするまでには、相当な作業が必要になるのです。それなりの理由があってデプロイ作業を後回しにしているのかもしれませんが、よほどの理由でない限り、ともかくデプロイ作業を早い段階から始めるべきでしょう。その方がコストが少なくて済みます。「作業が複雑すぎる」あるいは「不定要素が多すぎる」という場合には、アプリケーションコードを書くときと同じことをすれば良いのです。つまり、デプロイ作業の実験、評価、リファクタリングを必要なだけ行うのです。インストールやデプロイのプロセスは、顧客やプロフェッショナルサービスチームの生産性に大きく影響します。早い段階からプロセスのテストやリファクタリングに取り組み、プロジェクトの進行と連動して作業を進めていくべきです。私たちプログラマはコードのテストとリファクタリングを常に行いますが、インストールやデプロイのプロセス自体もその例外ではないのです。