タイトル【WindowsオフィスでWebObjects】実はWindowsソフトにがんじがらめになっているのでは？カテゴリーWindows, WebObjects
作成日2001/1/30 11:27:27作成者新居雅行
新しく、上記のようなシリーズを開始する。これは、1つのシステム導入事例だと考えていただきたい。結論的には、WebObjects 4.5を業務システムに利用するのだが、Direct to Webを使うことになる。理由などは追々、説明することにして、現状の分析から入ってみることにしよう。だが、WebObjectsを選択したのがベストかどうかは難しい判断だ。世の中、理想的な環境なら、優劣もはっきりしやすいが、現場レベルのどさくさの中では、あれもこれも同じようにメリットとデメリットがある。だが、よく雑誌などで紹介されるようなシステム導入事例は、どれをとってもスマートに物事を解決している事例ばかりである。もちろん、そうした事例から学ぶべきところは多いとは思う。だけど、本当に苦労するところがそうした立て板に水を流すような事例紹介では、やはりどうしても書きにくいということもある。この一連のシリーズは、具体的にはMDOnlineを発行しているローカスでのシステム構築につなげることを目的に、その経過を書いていきたい。いろいろなバランスを考えると言えばかっこがいいが、泥臭い理由も登場するかっこの悪い事例紹介になるかもしれない。でも、多くの事例はそうした側面があるものだというのもやはり事実ではないだろうか。現実に目をつむらないという路線で行きたい。

うちの会社でも、例にもれず、筆者以外はみんなWindowsを使っている。出版とゲーム開発を主業としているが、デスクトップで動いているのはWindowsマシンだ。しかも、Windows 98が主流である。当然の結果として、各種の業務データベースは、Accessを使って構築してきた。20人程度の会社なので、パフォーマンス的にはちょっとなところもあるが、全員が常時データベース接続するわけではないので、コストや管理面も考えてデータベースサーバは導入していない。ファイル共有でAccessのデータベースファイルを複数のユーザが開けるという状態で使っている。さらに一時期は積極的にノーツを使ったこともあるのだが、ノーツの利用は近い将来に使わなくする。ノーツはとてもいいソフトなのだが、管理にお金がかかる。逆に言えばお金をかければすごいメリットが生まれるが、お金をかけないとちゃんと使えないのである。
ところで、Accessというのは便利なようで難くせのあるソフトでもある。ソフトのバージョンの進行がどうもうまくいかないのだ。たとえば、新しいバージョンのAccessが出たとする。もちろん、旧バージョンのデータベースファイルを新しいバージョンに変換する機能はある。だが、エラーが出てうまく行かない場合どうするか？　もちろん、システム開発に詳しい方なら、スキーマとデータを分離して、再構築すればいいはずだと即座に答えられるだろう。しかしながら、開発要員をかかえていないので、そんなことに時間はかけられないし、その間、業務が止まる。安全策は、「旧バージョンを使い続けること」になる。そうした技術的な問題もさることながら、20人以上でパソコンの台数はその2倍近くになると、「それじゃあAccess 2000を使いましょう」では済まない。そんな簡単に、全員のデスクトップのコンフィグレーションを変えることはできない。ディレクトリサービスでどうこうなどと夢のような世界もあるそうだが、小さな会社で運用要員もいないようなところでは、まさに夢でしかない。現実は管理の行き届かないクライアントがあちらこちらにネットワーク接続されているという状態なのである。ディレクトリサービス、データベースサーバ…なかなか魅力的な響きだ。大きな会社ではそうしたものに数百万、数千万円かける価値は確かにある。なぜかと言うと、定型的な業務が山のようにあるからだ。だが、うちの会社のように、出版やゲーム開発となると、非定型な業務がむしろ中心で、その都度システム開発をやっていては会社はつぶれてしまう。だが、情報技術を使って効率化するという必要性も高い。だけどお金がない。こうしたジレンマを脱出する方法を日々模索するというのは、同じような小さな会社の共通の課題ではないだろうか。
もっとも、ごく最近にこれじゃあどうしようもないということで、Access 2000に「せーのぉー」でアップグレードするということを断行した。それまではものによってはAccess95のファイルもあったりして、混乱は続いていたのである。

まず、こうした事情を見ただけでも、模範的とは決していえないどころか、むしろ間違いだらけのシステム構築の事例だと思われるかもしれない。だが、何も知らずにやっているわけではないのは理解していただきたい。どうしてこうなるかというと、突き詰めればコストの問題になる。うちの会社でもネットワークエンジニアを抱えていたこともあったが、それが結果的に問題を複雑にしたと言えるだろう。誰かがソフトが起動しないとか、ネットワーク接続がうまくいかなかったとしよう。すると、そのエンジニアが、どうやら駆け付けてちょいちょいと操作をして、ほーらうまくいった…という対応をしていたようなのだ。これは、単にその場しのぎでしかない。結果的に、トラブル対策に対するノウハウも蓄積されなければ、システム上の問題点も露にならず、のちのちに思い掛けないところでつまづくという結果になってしまう。例えば、サーバを再起動しても、必要なサービスが立ち上がっていない…きっと、その場しのぎでコマンドを入れていたのだろうということが想像できる。
大体そこまで話せば予想はつくとは思うが、何のドキュメントも残さず、エンジニアは会社を去ることになる。また、諸般の事情もあり、20人規模の会社で専任エンジニアを配置するほどの余裕もないというのは当然のことだ。その他いろいろあって、結果的に、筆者が、なぜか在宅勤務にもかかわらず、ネットワーク管理者ということになってしまった。かといって取締役会のメンバでもないので、CIOでもない（これは情報化予算はないということを意味する）。そこで考えたことは、部署ごとに権限を渡してしまい、最低限のシステム管理をすることしか対処できないだろうということだ。さっそく、部署ごとにネットワーク管理者を決めてもらい、定期的に会議を持つことで情報を共有して問題を話し合い、何とか荒れ地を整地したと思うところまでは漕ぎ着けたという感じだ。権限を部署レベルに落とすことで、手続きは簡素化される。その部署ごとにやることは他の部署には干渉しないようにする工夫は最初から講じてあるので、喜びも悲しみも部署ごとに管理することになる。また、外注ながら内勤してもらっているエンジニアに実際的な運用をまかすなどして、日々の業務に対応している。
システムのお守は、基本的には部署ごとに、そして結果的にはひとり一人がやらないといけないという状況を作ったのである。そうなると、理想よりもコストだ。というのは、社員には誰一人としてシステム管理選任者はいないわけで、当然ながら通常の仕事を何かしらかかえている。さらに言えば、余裕のあるやつが出ているというほど、小さな会社は甘くはない。その上に、システム管理をしないといけないわけで、それはそれは大変だ（もっとも、ネットワーク管理者も怠慢だと言われればそれまでなんだが）。だから、腰をすえてじっくり開発するということはよほどのことがない限り、誰もできないのである。結果的に理想は見えていても、より時間がかからず、また、コスト負担も低いもので解決せざるを得ない。苦労してフリーソフトを使うのなら、何万円程度ならさっさと購入するのが効率的…だけど、何十万はまず出ない…という感じと言えばいいだろうか。
つまり社員一人一人に勝手にさせるという点での混乱が出ないかと思うかも知れない。もちろん、それはあるだろう。だけど、その一方で、今までシステム要員にまかせきりだったことを自覚して、積極的に関与するメンバも出てきている。積極的な人が動きやすく、自由にできるように、場を提供するのが、こうした状況でのネットワーク管理者としての責務だと考えている。プラスマイナスを考えれば、自分ではプラスがより強くなったかと評価している。
（続く）
関連リンクローカス