レベル: 初級 Cameron Laird (Cameron@Lairds.com), Vice President, Phaseit, Inc.
2002年 6月 01日 一般にプログラム作成が非常にバランスの悪いものになるのは、1つには、エンド・ユーザーが使ってみたときに、どんな結果になるのかを軽視するためです。出来のよい便利なプログラムを作成することには力を注ぎますが、そうしてできたプログラムをユーザーの手に渡す段になると、われわれソフトウェア開発者は全く不得手です。今月は、Cameronが、この問題に対処するための技術的な解決策を解説します。
皆さんの組織は、皆さんの1週間分の時間、15ヵ月に相当する開発時間、あるいは $385,000のライセンス料といった多額の費用を、なにがしかのソフトウェアに投資しています。そのソフトウェアは、デモ用に用意したホストでは立派に動作します。ところが、エンド・ユーザーがそれを利用しようという段になると、不満が生じます。なかなかインストールがうまくいかない、機能設定 (configuration) がよくわからない、再現できないがデータが消失する、はたまたプログラムが何もしない、といった不満です。
何か根本的なところに間違いがあるのですが、非常によく起こることです。コンピュータ関連のこういう側面に、私は「配備 (deployment)」という名前を付けています。配備とは、みなさんの上司やお客さんが画面上に表示されているソフトウェアを見て「これは良いですね」と言ってから、エンド・ユーザーが電話やメールで「こういうのを期待してたんですよ」と言ってくるまでの間に起こるすべてのことです。
基本的には、短い期間のできごとです。配備は、アルゴリズムの理論やネットワークの負荷分析とか、あるいは資格の取得といったこととは違い、奥深い問題ではありません。しかしながら、業界としては、全体的に、配備を軽視し、全うに扱うことがなく、配備には過小な投資しかしてきていません。その結果は案の定です。ソフトウェア開発の中で最も激しい無駄の多くが、この配備がらみなのです。今月の「サーバー・クリニック」では、みなさんが自身の作業をどうやれば改善できるのかについて説明していきます。
具体例
まずは、配備がどんなことなのかの共通「認識」を得るために、例を1つ示しておきます。化学の分野の技術者と共同で、セメントの固まり方をコンピューターでシミュレートするという面白いソフトウェアを開発してきていたとします。二人とも、開発サーバー上でのソフトウェアの動作には非常に自信をもっています。非常に広い範囲の環境条件や土地の条件などを処理するソフトウェアになっています。すばらしいことです。
しかし、他の技術者にこのソフトウェアを使ってみてもらうと、思っていたほどスムーズには事が運びません。インストールされていたCやQtのランタイム・ライブラリーに少し差異があったため、変な結果が出、プロセスが異常終了するといったことまで起こります。何人かは、インテル・ベースのLinuxではなく、AXPベースのLinuxを走らせています。一人の研究者は、すべて /varをルートにしてインストールしなければならず、/usr/localには何もインストールできないという組織に勤めています。
ありがたいことは、このワークグループの誰もがLinuxを利用しており、インストールのためスウェーデンや南アフリカまで赴く必要がないという点です。困ったことは、リモート・ログイン出来るとしても、プログラムを1回配信するのに平均30分以上かかるということです。やがて、プログラムのインストールにかかる合計時間は、最初のバージョンを実装するのに費やした時間よりも長くなってしまうでしょう。
これが本当に恐いのは、これが一般的なことであるということです。情報技術 (IT) の文化は、そうした不幸な事態を甘受するのを常としてきました。インストールは、しくじりやすく、エラーが起こりやすいものだと、われわれは考えています。
しかし、そのように考える必要はありません。以下では、これを改める方法を説明します。
配備の原則
すぐにインストール支援プログラムに飛び付かないこと。役に立つものも多数ありますが、十分に理解して使うというのが肝要です。
そして一番重要なことは、コンピューティングのほとんどの局面がそうであるように、良い配備は良い分析から始まるということを理解しておくことです。上の例で事をうまく進めるためには、以下のような明快な要件に即してコーディングを行うよう、自分を律することです。
- アプリケーションは、1個のイメージで移植やインストールのできるものでなければならない。
- アプリケーションは、glibc 2.2～2.2.5を装備したインテル・ベースのどのLinuxでも稼働するようになっていなければならない。
- アプリケーションは、Qtなど他のライブラリーを必要とするものであってはならない。
- アプリケーションは、初期登録時にIP接続が可能でなければならない。
- アプリケーションの要件の中で満たされないものが検出された場合には、コンソールに診断メッセージをはっきりと表示し、整然と終了すること。
- などなど．．．
そのような記述された要件を実践に移すために、私は、最初から、実行可能なインストール・プロシージャーを用意したいと思います。Extreme Programmingの手法に従うプログラマーたちは、テストすべきアプリケーションを実装する前にテストを記述するという話 (詳しくは、参考文献を参照) を少し思い起こしてみてください。同様に、私は、そうしたテストを行う前に、少なくとも簡単なインストール・プログラムを作成するようにしています。私は、復旧ツール・セット (regression suite) にインストール・プログラムを用意していますので、開発内容の任意のバージョンを、いつでも顧客のマシンに、問題なく、かつ安いコストで移すことができます。
この点では、私は少数派です。数多くの組織が、フロントエンドの分析、設計、トレーニング、およびその他の開発関係の要素には多大な金額を投資しますが、コンパイラーやクロス・コンパイラー、ライセンス・マネージャーやその他の配備を支援するためのツールの調査にプログラマを派遣するのは開発サイクルの終わり間際だったりします。私の知るかぎり、それぞれのやり方の利点についての正式な調査はありませんが、このコラムで提示できることは、いろいろな選択肢について明らかにすることです。私自身、作業を行ってみて、最初から配備計画を組み込んでおくことが可能であることがわかりました。私は、経験から、このようにしたほうが良いと確信しています。方法を選択する場合、これまでの成り行きから選択するのではなく、明確なものを選択しましょう。
配備のあらまし
一般的な管理の原則 (計画し、詳細分析を行い、費用と利益とを比較する) と同様、配備にも、それなりの考え方がいろいろとあります。以下では、それについて触れてみたいと思います。
万能のインストール・プログラムはない
配備は、5、6人程度のモバイル環境の技術者にソフトウェアを納品する場合もあれば、1つのビルの中に設置された1800台のデスクトップに納品する場合もあれば、世界中の300人のエンド・ユーザーに納品することもあります。また、同じハードウェアを使うグループに納品する場合もあれば、すべてのホストが異なるということもあります。
何か1つの配備システムで、こうしたすべての状況に完璧に対応できると考えてはいけません。でも、あきらめることもありません。最初予想していた以上に大きい問題かもしれませんが、ほぼ確実に解決可能な問題なのです。ここでの障害の1つは、組織がそうした問題を解決する場合に、単純化した答を出させようとすること、それも、ときには問題が明らかになる前から単純化して考えようとすることです。
ときどき、熱心な信奉者が、Javaとか、ダイナミック・リンク方式とか、ソフトウェア蓄積ツール (software depots) とか、構成管理用ソフトウェアを使うことで、あるいは、こうしたものとは別の技術的な芸当を適用することで、配備の問題は解決できると結論付けることもあります。しかし、いずれも汎用的なものではありません。すべて、利点もあればコストもかかります。少し、共有オブジェクト・ライブラリーについて考えてみることにしましょう。あるサーバー上に79個のアプリケーションがあり、不備のあるシステム関数printf() を使っているという点で、どのアプリケーションも欠陥を備えていたとします。ダイナミック・リンク機能を利用すれば、Cのランタイム・ライブラリーを1個更新するだけで、79個全部のアプリケーションの国際化機能 (internationalization) を修正することができます。しかしながら、この方法に依る場合、すべてのアプリケーションが同じバージョンのライブラリーを使用するか、少なくとも新しいプロシージャーでライブラリーのバージョンを管理するようにする必要があります。悪くすれば、エンド・ユーザー向けに用意したインストール・プロシージャーで、アプリケーションの実行ファイルを管理するとともに、そのアプリケーションが使用している共有オブジェクト・ライブラリーまで管理しなければならないことにもなります。これは、まさしくMicrosoft Windowsのアドミニストレーターが「DLL地獄」と呼んでいる組み合わせの複雑さのようなものを招くことになります。
更新の問題
みなさんがまじめに配備要件をコーディングで対処しようと考えるなら、とくに更新の問題に注意を払うべきです。みなさんのソフトウェアがインストールされているホストを更新すると、どんなことが起こるでしょうか。いまインストールされているものが、別のバージョンのものだったらどうでしょうか。同じ1台のホスト上の異なるユーザーごとに、別々のバージョンを使用できるようにするのでしょうか、それとも、そのマシン全体で1個のバージョンしか使えないようにするのでしょうか。
プログラム、データ、構成
配備やインストールの問題を考えるときの有意義な考え方は、以下の3つの側面から捉えるというやり方です。
みなさんが、ワード・プロセッサー・アプリケーションの担当だったとします。このアプリケーションを問題なくインストールするには、以下のことを行う必要があります。
- プログラムを適切な場所に正しく配置すること。
- ユーザーがこれまで編集してきた文書が失われないようにすること。
- ユーザーが構築している動作環境、フォント、マクロ、表示色、その他の文書をまたがって使われる便利な機能を認識すること。
インストール支援プログラムがまれにしか「まともに」利用できない理由の1つは、更新を行う際、これら3つの側面のそれぞれについて別々のライフ・サイクルを考えなければならない点にあります。
いかに大変そうに見えたとしても、そのような要件を開発の早い段階で把握しておくほうが、はるかに効果的であるということを肝に銘じておいてください。
ファイル・システムの活用
では、このように困難がいろいろと待ち受けている中で、どうやれば問題なく成果をあげることができるのでしょうか。まずは、ものごとを単純化することです。ほとんどの開発で、私は、グループIDとかシグナル処理など2次的な問題について高度なことは実現しないことにしました。多くのサイトは、これらのことを合理的に管理していませんし、そうしたサイトのやり方を「修正」しようとしても、顧客の不満を募らせ、さらには自分自身の不満も募らせることになるだけだからです。
配備に最も関係してくるモデルの1つが、ファイル・システムのモデルです。したがって、これを活用しましょう。欠点があったとしても、ファイル・システムのユーザー・インターフェースは、ほとんどのエンド・ユーザーにとって少なくともなじみのある部分です。インストールには、単体の (ダイナミック・ライブラリなどを付随することのない) 実行ファイル、もしくは自分自身を1個のディレクトリーにアンパックするイメージを使うのが良いと私が強く主張しているのは、このことによります。このような単純なやり方にすることで、ユーザーは、製品がインストールされたのかどうかを把握でき、またアンインストールやバックアップの方法を理解できることになります。
単純なファイル・システム指向のインストールを好むということから、商業製品のインストーラー、自己解凍方式のバイナリー・バンドル、「スクリプト化文書」、「仮想ファイル・システム (VFS)」といった配備技術も私の好むところとなります。スクリプト化文書とVFSは、それぞれ、そのだけでコラム記事を書けるだけの大きなテーマです。今回は、簡単に定義し、詳しく知りたい方のためにオンラインの参考文献を掲げておくだけとし、将来この「サーバー・クリニック」のコラムでこれらのテーマが詳しく解説されるのをお待ちいただくことにしたいと思います。
スクリプト化文書
「スクリプト化文書 (scripted document)」とは、独立系コンサルタントのJean-Claude Wipplerが自分で考案したファイル・フォーマットに付けた名前です。彼は、アプリケーションを、アプリケーションとは独立したプラットフォームに固有な実行コードと、プラットフォームとは独立なアプリケーションに固有な「スクリプト化文書」の2つの部品に分けて供給します。スクリプト化文書には、実行コード、ユーザー・データ、および保存のための方法がバンドルされます。少なくとも私が行っている配備作業の多くでは、このスクリプト化文書が便利です。スクリプト化文書は、コピーが可能で、Linux以外のオペレーティング・システムにでもコピーすることができ、名前の変更や削除やバックアップなども、ファイル・システム内の普通のファイルと同様に行うことができます。と同時に、従来のアプリケーションであれば、あちこちにインストールしたファイルやディレクトリーに散在させるような情報を、スクリプト化文書はすべてカプセル化します。
「サーバー・クリニック」で次回このテーマをとりあげるまでは、以下の参考文献に掲げたスクリプト化文書に関するいくつかの私のメモでも読んだいただければ幸いです。それまでは、配備が正しく実践すべき重要な問題であり、そのために、まず最初に行うべきことは、要求条件を文書化することである、ということを頭に入れておいてください。
みなさんが直面している具体的な配備の問題は、どんなことでしょうか。ディスカッション・フォーラムに参加してみてください。誰か他の読者や私の意見が役に立つかもしれません。
参考文献
- 悲しいかな、配備について書かれた文献はほとんどありません。Windowsオペレーティング・システムに固有な話として配備の問題を取り上げている書籍が何冊か刊行されていますが、一般的なテーマとして取り上げた有益な参考文献は、まだ存在しません。今回紹介したことの他にも、構成管理、要件分析、テスト、システム管理、ユーザー・インターフェースといったテーマについての入門書に目を通しておくのがよいでしょう。たとえば、先月の「サーバー・クリニック」で取り上げたThe Practice of System and Network Administration は、「ソフトウェア蓄積サービス (Software Depot Service)」について1章を割いており、より微妙な点で配備に関係してくる、もっと分散的ないろいろな問題についても触れています。
- Cameronのスクリプト化文書についての個人的なメモ (personal notes on scripted documents)には、配備に関する氏のプロジェクトがいくつか紹介されています。
- "The Jericho Itch" は、昨今のインストール方法の悲惨な状況についてJean-Claude Wipplerが語るぼやき言です。
- 高品質のソフトウェアを製作する方法については、Extreme programming (developerWorks、2001年4月) をお読みください。
- CameronがこれまでdeveloperWorks に寄稿した「サーバー・クリニック」のコラムは、以下のとおりです。
- developerWorks のLinuxゾーンには、他にもLinux関係の記事が多数掲載されています。
著者について  | 
| | Cameronは、Phaseit, Inc. の常勤のコンサルタントです。オープン・ソースなどの技術的なトピックについて、数々の執筆や発言を行っています。Cameronのメール・アドレスはclaird@phaseit.net です。 |
記事の評価
| 
