今、担当している仕事のひとつが、製品で使われる共通コンポーネントをインストールするためのフレームワーク作りのお手伝い。
私は直接のオーナーではないので、ドキュメントをレビューし、i18n（国際化）の観点で問題がないかをチェックするのが主な仕事。
し・か・し・・・、この仕事、ちっとも容易じゃない！！
コンポーネントの数が多すぎるのと、ほとんどJavaテクノロジーに依存しまくり。もちろんC++で作られた製品向けのフレームワークもつくらなければならないけれど、MDACやMFCや.NET Frameworkなどマイクロソフトの技術に関することがドキュメントから欠落している・・・。その理由は、マルチプラットフォーム向けのフレームワーク作りだったりするから、Solaris、HP-UX、AIX、Linuxも考慮しなければならない。個人的には、UNIXやLinuxのインストーラは嫌いです。日本語環境だとシェルのLANGが違うだけでインストールが失敗するケースが多いから。また特定のシェルに依存したスクリプトを使われて、そのシェルがプラットフォームに入っていなかったらどないすんねん・・・。
ぼやきは、とまらず・・・うーん、そんなにうまくまとまるものかなぁ。
個人的には共通コンポーネントのインストールフレームワークを作る前に、国際化を視野に入れた製品インストーラの基本フレームワークを作るべきだと考えています。
そうなると、製品の要求仕様を作る段階からインストーラの仕様をきちんと決めるべきで、既存コンポーネントに関してはどうインストールすべきかがきちんと決まるはずだと思います。
問題なのは、カスタムで作成した製品の配置(Deployment)で、これも要求仕様を作る段階で配置モデルができているべきだと思います。
単純にWebアプリケーションだけの話しなら配置は数箇所のサーバだけで済むので配置モデルが作りやすいと思いますが、マネージメントソフトウェアのような多段階の分散アプリケーション、特に多数のエージェントが存在し、エージェントから収集したデータを集約するサーバが複数存在して、その集約データをさらに集約するサーバがいて・・・といった類の製品になると配置モデルは簡単なようで結構難しいです。理由は、処理を実行するマシンとネットワークとその間を流れるデータ量に応じてパフォーマンスを簡単に見積もれないからです。インストールはできても動作しない、という笑えない問題は多々あります。
話しはもどり、経験上、インストールと配置を考えずに作られた製品のインストーラはメンテナンスするのが困難で、もちろんローカライズになるとぐちゃぐちゃな状況になります。
ちょうど昨年末にインストーラのローカライズで苦労したので、あの惨劇（大げさな・・・）を繰り返さないようにするにはどうしたらいいんだろう、って考えていると、ちっとも頭が回らなくて、ちっとも進捗が見られず、困った状態です。締め切りがタイトでないのが唯一の救いなのですが、インストーラはできるだけ簡単にしたいです。
し・か・し・・・、EULA(使用権許諾契約書)に同意しないとインストールしてはならないコンポーネントは、対話的にユーザの同意をもらう必要があります。それをコンポーネント個々にやらなければならないとすると、非常にインストールの作業が面倒になってしまいます。もっともEULAをきちんと読んでいるユーザがどれだけいるかといえばかなり少ないことが予想されます。ましてやEULAが英語だったりすれば、日本のユーザはほとんど読まないでしょう。そうなると、EULAを翻訳することになるわけですが、翻訳した結果、文字数が多くなってしまって、インストーラのテキストボックスに収まりきらない、なんて馬鹿げた話に陥ることがあります（実話）。
コンシューマ向けはインストールを簡単にして、エンタプライズ向けは、ハードウェアにソフトウェアをバンドルして販売するモデルにするのが一番簡単な解決策かも。そうすれば、エンタープライズ向け製品のインストーラできめ細かい設定をごちゃごちゃ作りこむ必要はなくなると思うのに・・・。
＃ あー、すべて.NET Frameworkで出来ていればこんなことで悩む必要なんかないのに・・・（現実逃避）