|
富士ソフトＡＢＣ株式会社 八王子事業所技術調査グループ
色々なアプリケーションを使っていると、思ったように動作しないときがあります。アプリケーションの設定を見てみると、「なんでこんなデフォルト設定になっているんだ！？」と目が点になるような場面がしばしばあります。 ここでは、そういったデフォルト設定にまつわる話題について、少しですがお話します。
１年ほど前、私が参加しているメーリングリストにHTMLメールが１通流れてきました。ポストされてからまもなく、「メーリングリストにHTMLメールを流しちゃだめだよ」といった内容の指摘が、多くのメンバーから返されてきました。何気にメールヘッダーを覗いてみると、”X-Mailer: Microsoft Outlook Express ...”、つまりOutlook Expressでポストされているのです。 HTMLメールは、HTMLメールを解釈できるメーラーでない場合、HTMLが添付ファイルとして扱われたり、HTMLタグがそのまま表示されたりするため、さまざまなプラットフォームのユーザーを対象とするメーリングリストのような場では、ほとんど使用を禁止されています。しかし、どこのメーリングリストでも、HTMLメールを出してしまった人とそれを指摘する人たちのスレッド（中には指摘した人同士の派閥論争にまで発展するスレッド）が１つ２つはあるようです。 ここでふと、どこかの雑誌のメーラー特集に、「Outlook Expressのデフォルトのメール形式はHTML形式」と書かれていたのを思い出しました。他のHTMLメールを調べてみると、案の定、全てOutlook Expressでポストされています。丁度、Internet Explorer 4.x＋Outlook Express 4.xを使うユーザーが急増していったという背景があったので、スキルの異なるユーザーが混在するメーリングリストではこういった問題が起こりやすかったのでしょう。 同時に、ユーザーの中には、デフォルト設定のままアプリケーションを使い始める人が、意外と多いということに気づかされました。
実際に、私自身もよくわからないデフォルト設定に悩まされたことがあります。 学生時代に、Windows NT Server 3.51ドメインコントローラ3台＋Windows NT Workstation 3.51クライアントマシン100台で構成されるドメインを組んだときでした。クライアントマシンには、ユーザーが勝手にアプリケーションをインストールできないようなセキュリティ設定をしておくようにリクエストされたので、適当なクライアントマシンを1台選んでディレクトリのセキュリティ設定を見てみました。すると、システムディレクトリであるWinntディレクトリとSystem32ディレクトリに対して、以下のようなアクセスが許可されていました（Everyoneはコンピュータにアクセスする全てのユーザーを指します）。 ・Winntディレクトリ ... Everyoneに対してフルコントロール権限 ・System32ディレクトリ ... Everyoneに対して変更権限 なんとこの設定は、全てのユーザーがシステムディレクトリにあるファイルを書き換えたり、削除できたりしてしまうという、すさまじいセキュリティ設定です。そのころLinux（Slackware）をWindowsと同時に使用していた私は、この信じ難い事実に直面し、Windows NTのセキュリティになんとなく疑問を感じるようになりました。 それでも、何度か試行錯誤を繰り返しながら、ようやく1台の設定が完了しました。しかし、残り99台の設定を手作業で行わなければならないとわかったときには、すっかりやる気をなくしていました。当時、セキュリティ設定だけを別のリモートマシンにコピーするようなツールはなかったので、毎日8〜10台ぐらいの設定を行い、全マシンのセキュリティ設定が完了するまでには3週間ほどかかってしまいました。 作業を行っている間、何度も「LinuxみたいにTelnetでログインして、chmodとかchown使えればこんなに苦労しないんだろうなぁ...」とぼやきつつ、クライアントマシンの間を走りまわっていました。
会社に入社してから半年たった頃、データベース関連のプログラミングをすることになりました。使用したDBMS（データベース管理システム）は、SQL Server 6.5です。 最初は、レコード数が100〜300件程度の小規模クラスのデータベースを扱っており、この時点では目立った問題はありませんでした。しかし、レコードが50万件程度の中規模クラスのデータベースになると、クエリーの応答速度が一気に悪くなり、以前は正常に動作していた幾つかのクエリーが、実行中にエラーを返すようになりました。 早速、原因の調査にあたり、tempdbの領域が不足していることを突き止めました。tempdbは、複雑なクエリーを実行したり、ソート等を行ったりした場合に、一時的に利用される領域です。デフォルト設定でのtempdbのサイズは、わずか2MByteでした。このあまりにも小さいtempdbは、中規模クラスのデータベースに対しては無力なのだと痛感しました。 また、tempdb以外のデフォルト設定についても調査したところ、SQL Serverで使用可能なメモリサイズも16MByteと少ない値でした。この時気づいたことで、リリースした後に障害対応に追われなくて済んだのは、運がよかったのかも知れません。オプションの設定を変更することで、エラーを出さずにクエリーを実行できるようになりました。 なお、SQL Server 7.0では、tempdbの自動拡張やメモリサイズの自動チューニングができるようになりました。
ソフトウェアの供給元が提供するデフォルト設定は、それなりの重みを持ったファクターであるのだと思います。 例えば、OSやミドルウェアの供給元が、管理者と一般ユーザーがはっきりと区別された環境を提供することで、導入時の管理コストはかなり削減されるでしょう。アプリケーションの供給元が、リリース時点でのインフラやデファクトスタンダードをデフォルト設定に反映すれば、ユーザーは余計な心配をしなくてもよくなります。 ただし、デフォルト設定によって隠蔽された、本来ユーザーが目を通さなければならいような設定は、後にユーザーに注意を促すような配慮も必要でしょう。 また、SQL Server 7.0で実装された、環境設定オプションの自動設定のような機能も、ユーザーがデフォルト設定を気にしなくて済む有効な手段です。 最後に、ソフトウェアを開発する私達のような技術者は、ついついソフトウェア自身の機能の作りこみだけに偏りがちです。しかし、実際にソフトウェアを利用する立場であるユーザーの中には、デフォルト設定のまま使い始めるような人も多いということを忘れてはならないと思います。時間のあるときは、デフォルト設定で十分使いやすいソフトウェアというものをユーザーの立場で考えたり、たまには客観的な目で自分の作ったソフトウェアを見つめ直したりする余裕が必要なのだと私は思います。 |
