「やれやれ,システムなんて作るもんじゃないね。取材する方は気楽でいいよなあ。今から思えば記者をやってた方がよっぽど楽だった」・・・。安い焼酎のフタをひねりながら,I君はこう切り出した。彼のチームはこの秋,私の勤める出版社でIT関係の新WWWサイトを立ち上げた。かわいそうな彼らはこの半年,慣れぬ仕事でさんざん痛い目にあってきたようだ。

 一杯飲みながら,ようやく一息ついた彼の愚痴を聞いてやるのが私の役目。今日は私と一緒に,彼の苦労話と失敗談に(そしてほんのちょっぴり自慢話にも・・・),付き合ってあげていただきたい。眼の肥えた読者の皆さんにはあまり参考にならないかもしれないけれど,少しでも共感していただける部分があれば幸いである。

--トラブル続きで大変だったな。稼働直後は“遅い,つながらない”って,ユーザーから苦情が殺到したそうじゃないか。

 うん,あのトラブルの原因はネットワーク,具体的にはサーバーへのアクセス回線がボトルネックになっていたことだ。性能については十分に準備したつもりだったよ。開発をお願いしたMソフトウエアのTさんは,データベースやJavaプログラムを徹底的にチェックしてくれたし,俺もHTMLレベルのチューンは自分でやった。ただ,ネットワークだけはヨソにお任せで,正直言ってブラックボックスにしてた。ところが,予想を超えるアクセスで,回線がパンクしちゃった。

--ちょっと見通しが甘かったんじゃないの? 大いに反省すべきだな。でも確かに,WWWシステムのボトルネックはいろいろなところに潜んでいるから,予測と原因究明が難しいという話は取材先でもよく聞くよ。トラブルの原因はすぐに分かったの?

 稼働直後は問題は表面化しなかった。稼働の日は,Tさんと前の晩から泊まり込みでね,午前0時に本番稼働したときは「やったー」って感じで2人で抱き合っちゃったよ。それまでJava実行環境のバグやらなんやらで,いろいろ胃の痛む思いをしてきたからね。

 Tさんは一晩中ずっとログとにらめっこしてくれたが,朝の8時ごろまでは何の問題もなかった。これは楽勝だな,と思ってたらとんでもない。9時ごろからアクセスが増えてくると,急激にレスポンスが落ちてきた。

 おかしいおかしい,と思いながらサーバーの状況をモニターし続けたけど,メモリーもプロセサも十分に余裕がある。変だな,どうもネットワークじゃないか,なんて言い合いながらネットワークやサーバーの状態をモニターし続けて,やっぱりネットワークだ,と結論を出したのが昼過ぎだったかな。その後,ネットワーク環境を改善して問題は解決したんだが,解決するまでは,お客様にはご迷惑をおかけして本当に申し訳なかったと思っている。

--Java実行環境のバグ,というのはどんな話?

 「俺たちのサイトはサーバー・サイドでJavaを多用している。Bean(JavaBeans仕様準拠のソフト部品)やJSP(JavaServer Pages)だ。これらがバックエンドのコンテンツ・データベース,顧客管理データベースと連携して様々なサービスを提供する,という仕掛けなんだ。

 Java実行環境として,ある製品Aの最新バージョンを使っていたんだが,これに不具合があった。稼働まで1カ月を切った8月20日過ぎてから,テスト中に妙なエラーが頻発するようになった。「同時アクセス・ユーザーが多すぎます」といった内容のメッセージを出して,そのリクエストを受け付けなくなるんだ。ところが実際に動いているスレッド数を調べても,設定した上限値にはまったく達していない。TさんがOSまで含めて,いろいろとチューニングをしてくれたがどうにもならない。米国のWWWサイトで調べてみると,実は向こうでも同じ時期に同じ問題があちこちで起こっていた。

--そのWWWサイトに解決策が載っていたの?

 いや,これという回避策はなかった。しかも,その時点でベンダー側はまだ,それをバグとは認めていなかった。さすがのTさんもがっくりしてたな,あのときは。9月5日くらいまで,あの手この手を試してくれたんだが,結局だめだ。いよいよ打つ手がなくなったんで,俺たちは思いきって別の製品Bにリプレースすることにした。

--リプレースはうまくいったのか?

 アプリケーションの移行自体はうまくいった。プログラムの修正はほとんど必要なかった。その辺はさすがにJavaだな。ところがここで新たな問題が起こった。実は俺たちのシステムは,ある社内システムとの連携処理が前提になっているんだが,これがうまくいかなかった。両システムとも同じ製品Bを使っているんだけど,バージョンの違いで連携ができなかった。詳しく話すと長くなるのでやめとくけど,やっぱりJavaも製品の実装レベルでは,まだいろいろと問題があるな。

--裏側ではずいぶんドタバタしてたんだね。

 うん,稼働まで10日を切っていたからね。このときはさすがにもうダメかと思ったよ。ところが不幸中の幸いというか,なんとも皮肉なことに,製品Bを発注した次の日に製品Aのベンダーがパッチを送ってきたんだ。もっとも,そのときはまだ正式なパッチでなかったので予定通り製品Bでいくことにしたが,さっき話した事情で製品Bはあきらめざるを得なくなった。やむなく製品Aにもどって,このパッチを当ててみた。そうしたらうまく動いたんだ。幸い,カットオーバーまでにこれが正式なパッチとしてリリースされた。今は製品Aで問題なく動いている。

--それで,製品Bはどうしたの?

 うん・・・,今のところ使っていない。

--結構高かったんだろ?

 ・・・まあね・・・。

--始末書ものだな,そりゃ。

 そんなにいじめるなよ。製品Aの枯れたバージョンを使えばよかったじゃないか,って言いたいんだろう? だけど,俺たちの仕様を満たすためには,多少リスクを冒しても最新バージョンを使わざるをえなかったんだ。

 ああ,それにしても,あのパッチがあと2日前に出てたらなあ・・・。

--技術面だけでも,ずいぶんいろいろトラブルがあったんだな。

 そうだな。ここまで話してきたのは,主にインフラの話だけど,そのほかにもいろんな問題があったよ。でも,言い訳じゃないが,問題が起きるのは仕方ないと思っている。今まで誰もやったことのないタイプのWebサイトだからね。コンテンツ・データベースがあり,顧客管理データベースがあり,それらがJSPやBeanを介して有機的に結合して・・・なんてサイトはそんなにないだろ?

 どんな問題が起きるかをすべて事前に予測するのは,残念ながら不可能だと思う。もちろん問題を予測することは大事だけど,いざ問題が起きたときに,それを理詰めで,すばやく解決できる体制があるかどうか,がもっと重要だね。

 例えば先々週だったかな,データベース・サーバーのCPU負荷が急激に上がり,これと連携するWWWサーバー(httpd)が頻繁にダウンする,というトラブルが発生した。そのときのTさんのトラブル・シューティングは,横で見ていて感激したね。ログを追跡して,何がダウンのトリガーになっているかを突きとめ,そのときに実行されているSQLを解析し,さらにデータベースのインデックスを張りなおしてこのSQLがプロセサにかける負荷を下げて・・・。1時間半で問題を見極め,それから1時間で完全に復旧させた。

 稼働から1カ月はこうしたトラブルがいろいろあったけど,Tさんが地道に一つずつ問題をつぶしてくれたおかげで,今はどうにか安定して動いている。

--いろいろな企業のシステム構築事例を取材していても思うことだけど,システム作りの基本はやっぱり「人」だね。

 今回はそれを実感したよ。俺たちのサイトは,Javaとリレーショナル・データベースが基盤技術になっている。もちろん,それがなければ俺たちが作りたかったサイトはできなかったのだけど,でも,こうした製品・技術がありさえすれば実現できたのか,といえば答えはノーだ。製品・技術という要素がシステム構築に果たす役割は,実はそんなに大きくない。それよりも,創造力と問題解決能力を備えた人をどうやって探し,チームに加えるか。それがサイト構築の成否を握るとつくづく思った。

--お前の出番なんかほとんどなかったんじゃないか?

 その通り。俺は,こういうサイトを作り,こういうサービスを提供し,それを基にこういうビジネスをやりたい,という絵を書いただけだ。しいて言えばもう一つは,その絵を実現してくれる人物を探したことだな。

 でも,その絵がモノになっていくプロセスは本当に刺激的で楽しかった。俺たちが絵を描いてTさんに渡す。Tさんがそれを設計図のレベルに仕立ててくれる。その設計図を一緒に見ながら,じゃあ,こんなこともできるし,やってみると面白そうだね,と話が進んでいく・・・。ああ,システムを作るって,ビジネスを創るってことなんだよなあ,なんてね。そんな高揚感があったよ。

--なんだ,記者の方がよかったとか言って,結構楽しくやってるじゃないか。でも気を抜くのはまだ早いぜ。お客さんの本当の評価が決まるのはこれからだからな。まあ今日はこのくらいにして,最後にサイトの発展を願ってもう一度乾杯しよう!

 ・・・ところでお前のやってるサイト,なんて名前だったっけ?

(井上 望=IT Proサイトマネジャー)