大規模システム構築と小規模システム構築の大きな違い(その1)

「小規模システムの構築」と比べて「大規模システムの構築」はなんだかものすごく高度で難しい印象を持つかもしれません。しかしどちらが高度で難しいかと問われればそれぞれ作業内容が大きく異なりどちらとも言えない気がします。そこで今回は両者どのように作業内容が違うためどちらが高度で難しいと言い切れないのかを考えてみたいと思います。

【小規模システムは全てを自分でやらないといけないので難しい】
小規模サイトの場合は担当者が自分一人しかいないということがよくあります。しかし例え小規模であっても押さえなければならないポイントは大規模サイトのそれとは大きく差がないと言えるため、実は広く深い知識と経験が必要なのが小規模システムの構築と言えそうです。

例えばいわゆる一般的な2階層式(=WEB+DB)WEBサイトをリリースするとします。この場合に必要な知識は例えばサーバ、OS、WEBサーバ、セキュリティ、ネットワーク、SSL、メールなどなど。これらを一人だけで一通りこなすというのはある意味高度で難しいと言えます。

【大規模システムは全体の構成を考えるのが難しい】
一方、大規模サイトの場合は担当者が数名でかつ予算がそれなりに用意されている場合が多いです。この場合自分はある特定の部分だけ担当すればよいので気が楽です。また手厚いベンダーのサポートを受ける予算があるので、何か問題に突き当たったときにいちいち検索して調べなくてもベンダーに連絡しておけばすぐに回答が帰ってきます。このことは実は自分自身が高度な技術を持っていなくてもある程度なんとかなってしまうことを意味します。

ただし大規模システムの場合、システムを構成する要素が多くて何をどう組み合わせるのか設計するのが難しいと言えます。また小規模システムと比べて購入するハードウェアが非常に高価な場合が多いので、何を購入するかの選定が非常に難しいです。例えばネットワーク機器を購入する場合、メーカー毎にどのような違いがあり、どのような機能差があり、パフォーマンスはどうで、実績はどうで、拡張性はどうで・・・等々、気にすべき要素が多くて非常に悩みます。

【結論】
思うに、小規模システムの構築は職人技の世界なのに対して大規模システムの構築は意思決定の世界な気がします。つまり、小規模システムの構築では担当者の知識と経験が全てなのに対して、大規模システムの構築では担当者を誰にしてどのベンダーを選定してどの機器を採用して等々、大半の時間を選ぶという作業に費やすことになります。

この機会にインフラエンジニアである皆さんがどちらの世界を目指そうとしているのかをちょっと考えてみても良いかもしれません。

SharePoint Server2007について思うこと

Microsoft社のマーケティングのせいか、SharePoint ServerはNotesやサイボウズのように使えるグループウェアであると勘違いしている人も多いと思います。でも実際は「HTMLを知らなくてもサイトを構築できるWebベースのコラボレーションツール」という言い方が正しい気がします。

SharePointの概要はこうです。システム管理者から1枚のWEBサイトが提供されると、そこにWEBパーツと呼ばれる様々なパーツ(掲示板、スケジュール管理、ドキュメントライブラリ、Wiki、アンケート等々)を自由に貼り付け自分達が使いたいようなサイトを構成することができるというものです。そう、Google Sitesのようなものです。SharePointを使うとグループ内の情報共有が進み業務効率化が図れます。

ただしSharePointには大きな弱点が3つほどある気がします。

1.マーケティング戦略のせいかありとあらゆる機能を盛り込みすぎで、概念や用語が難解です。本を読んで全貌を理解してから取り組もう、なんて思っているとすぐに挫折します。しばらく使ってみてようやくなんとなく概念がわかってくる、というツールが気がします。

2.バグなのか仕様なのかわからないが、とにかく変な挙動が多いです。システム管理者から見て、当然こうなってこうやればいいだろうという勘がことごとく裏切られることが多いです。修正パッチも多いですが、機能が多いためか修正パッチを適用すると今度は他の問題が出てくるなんてことも。とにかくシステム管理者泣かせです。

3.InternetExplorerやOfficeと組み合わせると出来ることが増えますが、それ以外の環境だとできることが制限されます。例えば掲示板にupされたドキュメントをOutlookでメールのように読み込むことができたり、Explorer ViewというモードにするとWEB画面がExplorerのようなデザインになり大量のファイルをDrug&Dropできるようになったります。

総評。ユーザから見たらそれなりに使いやすいツールだと思います。しかしシステム管理者は地獄を見るツールです。次回バージョンアップ時はもっとシンプルで扱いやすいシステムに生まれ変わることを期待したいと思います。

Exchange Server2003と2007の比較

以前Exchange Server2003と2007を比較検証してみたことがあります。その結果、当時の私はExchange2003を選定しました。無論現在は状況が変わっているかもしれませんが、今回はその当時の状況を思い出しながら記してみたいと思います。

【パフォーマンスは概してExchange2007が上】
Exchange Serverは概してメモリをたくさん積めるほうがパフォーマンス的に有利です。そういう意味で、32bit CPUしか対応していない2003より、64bit CPUに対応している2007のほうが概してパフォーマンスが上です。

【管理のしやすさは断然Exchange2003が上】
管理のしやすさというと漠然としてますが、個人的な印象では2003は管理画面が直感的でシンプルなのに対して、2007は凝りに懲りすぎて何が何だかわからないという印象を受けました。2003だとある程度サーバ管理に慣れている人であればマニュアルを読まなくてもなんとなく設定でき、かつ運用時に内部の挙動もなんとなく把握できます。

それに対して2007はマニュアルを読み込んでも何がなんだかさっぱりわからないところから始まります。設定する箇所もよくわからないし、運用時の内部の挙動把握もどうやったらいいのかよくわかりません。2003と比べて無論使いこなせればものすごい管理ツール群なのでしょうが、使いこなせなかったので宝の持ち腐れでした。そう、2007は2003とまるっきりアーキテクチャーやGUIが異なるのです。

こう書くとわけがわからないかもしれませんが、試しに評価版を入手してご自身でインストールしてみたら違いがすぐにわかるので納得してもらえると思います。

【文字化けはExchange2003のほうが少ない】
メールといえば文字化けはとても重要です。通信する全てのMTA&MUAがRFCに準拠しているだとか、送受信する相手とは日本語しかやり取りしないという状況であれば文字化けは起きにくいのでしょうが、残念ながら平気でRFC違反しているMTA&MUAは多いし、送受信する相手は日本人だけとは限りません。そんなわけでいろいろなパターンを検証したのですが、当時はQuoted-Printable問題のためかExchange2007のほうが文字化けが起きやすいようでした。今は違うかも。

当時いろいろ検証したときのメモ書きがあったので載せてみます。(詳細は忘れました。間違ってたらごめんなさい)

・2007では送信時SubjectのEncode方式をQuoted-Printableにされてしまう。このためWILLCOM PHSにメールを送ると化ける。(注: SP1で解消されたという噂あり)

・2007ではHeaderのCharsetと本文の文字コードが一致しないメールを受信すると化ける。(明らかに送信側の問題だが2003では何故か化けない)

・2003ではUnicodeの処理が正しくないため文字化けが起こることがある。(詳細不明)

・2003/2007共Subjectの長さが76byte以上のメールを受信すると化ける。(RFCでは本来Subjectが75byte以下としているので問題なし)

・2003/2007共①㈱㎝などベンダー固有文字に対応していないメールを送受信すると化けることがある。(仕方ないのかも)

・2003/2007共送信時中継するMTAによって化けることがある。(古いMTAだと7bitが基本なので、8bitが前提のUTF-8などでメール送受信すると8bit目が失われてメールが化けることがある。JISで送れば問題なし)

【まとめ】
2003は素直な作り、2007はいろいろ高度なことをやろうとしたがうまくまとめきれなかった、という印象を受けました。そういった意味ではサポート切れ期間が2007より短いことを除けば2003のほうがお勧めです。

ただマイクロソフト製品の場合、技術革新を起こした直後の製品は使いづらいものの次のバージョンで問題点を解決してくるので、多分Exchangeの次のバージョンは高性能でかつ使いやすいものになることでしょう。

社内ブログを導入しよう

最終回の@IT連載記事が掲載されました。タイトルは「社内ブログを導入しよう」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/16/01.html

さて、この連載では16ヶ月に渡り社内情報システム担当者が遭遇する一通りのことを身を削って書いてきました。ご興味のある方はバックナンバーもご覧ください。皆さんの業務の参考になれば幸いです。

情シス業務アウトソーシングの秘訣

今月分の@IT連載記事が掲載されました。タイトルは「情シス業務アウトソーシングの秘訣」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/15/01.html

ちなみにこの連載は来月最終回の予定です。

会議室を効率的かつ便利な空間にする

今月分の@IT連載記事が掲載されました。タイトルは「会議室を効率的かつ便利な空間にする」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/14/01.html

ワークフローシステムの賢い導入法

今月分の@IT連載記事が掲載されました。タイトルは「ワークフローシステムの賢い導入法」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/13/01.html

社内システムでのデザインについて

社内システム（業務支援システム、各種管理ツールなど）のデザイン（設計という意味ではなくて、グラフィック的な意味で）は概してとてもひどいです。私は大企業とベンチャー企業という両極端の企業形態での勤務経験がありますが、どちらも似たようなもので顧客向けでない社内システムなんかに貴重なデザイナーの人的リソースを費やすなんてもったいない、という感じです。

多くの場合、要件定義に沿ってプログラマーがシステム開発をします。デザインはといえば、開発を進めるために取り合えず適当に組んでおいたデザインが、そのままの形でリリースされてしまうという感じです。なんとも寂しい感じがします。

この状況を回避するためには次のような方法が有効かなあと考えています。それはデザイナーが社内基本デザインテンプレートを用意しておくことです。基本テンプレートがあればプログラマーはそのテンプレートを組み込んで社内システムのデザインを行っていきます。社内基本デザインテンプレートを用意するのはデザイナーにとって面倒な作業ですが、1度作っておけばその後の社内システムに皆組み込まれるので長い眼で見たら良いことではないかなあと思うのですがいかがでしょうか。

なお蛇足ですが、社内基本デザインテンプレートには外枠だけでなく、各種ボタン（登録、キャンセル、戻る、進む、OK、NG、承認、却下、ログインなどなど）も用意しておくとより良いです。

TV会議システムを導入する前に考えること

今月分の@IT連載記事が掲載されました。タイトルは「TV会議システムを導入する前に考えること」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/08/01.html

現実的でバランスの良い冗長化について考える

今月分の@IT連載記事が掲載されました。タイトルは「現実的でバランスの良い冗長化について考える」です。

http://www.atmarkit.co.jp/im/cop/serial/kanrisha/07/01.html