見えない物は認識できないということについて考えてみる

最近のお仕事でちょっと思うところがあったので。

森博嗣氏のエッセイで記憶に残っているエピソードにこんなのがあります。

オーディオマニアの友人に、「セレクタを作っている」と話したところ、「それは、相当のめり込んだマニアが手を出す物だ」と指摘されてしまった。最初に観測方法を確立してから次のステップへ進むという手順は、確かに工学的あるいは研究的なスタンスかもしれない。

[2007年1月28日(日), MORI LOG ACADEMY 6]

MORI LOG ACADEMY 6 (ダ・ヴィンチブックス)

そうなんだよね。これ、観測できない物は認識できないという当たり前のことを書いているだけなんだけど、実は作業としては意識してできていないことが多いと思うのです。普段の生活においては、やった結果がそのまま目に見えることが多いから…というせいもあるのかもしれないけど。ただ、お仕事として、しかも情報システムとか作っている物が実体として目に見えにくい物を扱うときにはこれじゃいけない…というのは意識しないといけないなと。

例えばどんなことだろう? 最近あったのは、某システムの構築プロジェクト、計画とかそういう段階で、マイルストーンをおいてもうちょっと細かく詳細化したスケジュールを見たときの話。自分はネットワーク周りの設計とかで入っていました。で、スケジュール見ていくと、ネットワーク部分の設計構築とかやって、当然障害テストとかやるわけですよ。冗長化してある部分が切り替わるかどうかとか。そこは良いのだけど、問題は、監視系のシステムがその時点で構築中(稼働していない)というスケジュール。

実際の情報システムにおいて、「障害が起きている」ことをどう認識するかというと、当然、システムの利用状況とか発生したイベントとかを監視しているシステムがあって、そいつが問題となる事象をキャッチすることで何かが起きたことを知るわけです。しかるに、障害試験をやっているときに、監視系のシステムがまだ存在していないということはどういうことか。少なくとも本番同等の状況で事象を確認することができないということなんだよね。監視系で障害イベントをキャッチできないとどうなるかというのを考えてみるとその問題がわかりやすい。監視系で問題が「観測できない」と、システム運用者あるいは管理者は、利用者からの怒りの電話で呼び出されてそのときになって初めて問題があることを知り、あわてて対応を開始する羽目に陥る、というわけです。くわばらくわばら。

例に挙げた、システム構築と障害試験という話で考えると、もちろん障害試験でネットワーク機器に直接触れるのだから、問題が起きたこと、系が切り替わったこと、あるいは復旧させたこと、というイベントを確認することはできるわけだ。でもそれは、本番では通常やらないオペレーションなんだよね。カットオーバーした後は、ちゃんと本番で使う監視系のシステムで発生したイベントがキャッチできること、想定したとおりにアラートが起きること、というのが見えなければあまり意味がないのですよ。

そんなわけで、構築までならまだいいけど、障害試験をやるのは監視周りが動くようになってからにしてくれと言うわけですよ。正規の観測手段が整っていないのにやっても二度手間になるから。あと、監視系の構築担当者は、自分が作ったものが正しく動くかどうかを確認しなければいけない…監視系の試験をしなければいけないわけで、どうやるかというと、やっぱり監視対象で何かしらイベント起こすんだよね。イベント起こすって、要は障害起こす、というようなことが含まれるわけで、個別にやるのはただの二度手間。だったら、監視対象側の障害試験をやり、事象を発生させ、正規の観測手段で観測できることを確認し、監視系のテストも兼ねる、というのをやるのが一番効率がよい。先に観測する手段と予想される結果を用意してから、問題となる事象に対してどう動くかを確認すべきですよね、と。

……これ、意外とそういうこと考えないで、各システムの担当者がそれぞれ独自に動いちゃったりするんだよね。あげく「このときってどういう Trap 飛ぶのか教えてくれ」とか後から言ってきたりして、オマエそれこっちの障害試験の時に言ってくれれば全部まとめてデータ採れたのに何で今頃言うんだよ、とか…(この場合は、監視系やってる人にそういう話をあげられない方も悪いということだ。) もうちょっと言えば、SIer で、システム全体の設計構築運用までやりますよ、とか謳っておいてこのザマなのかと。結局、内部的には縦割りになっていて全然連携できていないよねー、なんてのが見えちゃうと、あーあって感じになるんだよね。

…話がずれてきた気がするので戻すと、やりたいことがあって、どうにかしてやる方法を考えて、実装してみて、作ってみた物がやりたいことを達成するかどうかを確認しなければいけないわけだ。

一般的に、新人君とかにやりたいことを説明して、じゃやってみて、ってお願いすると、まず方法に意識が向かう。どうやってやるかにとらわれていて、やりたいことは何だったのか、それをどうやって保証するのか、というところに目が行かない。進捗や結果を確認すると「やれました」で終わってしまう。それだけじゃないよね。「どうやってやったか」はもちろん必要なんだけど、「やりたいことに対してどのくらいできているか」「それをどういう方法で実証・確認したのか」という点がないと、自分の仕事を裏付けることができない。見えるようになっていない物は見えない。大切なのは

• やりたいことを実証するために「見えるようにすべき物は何か」を考えること
• それを「どのように見えるようにするか」を考えること

なのじゃないかと思ったりするわけです。

ちなみに、森氏の話を冒頭で引用しましたが、その後はこう続いています。

「それだけの金を出すなら、普通はスピーカを買う」とも言われた。

まあ、何でもそう思い通りにやれるわけじゃないから、多少前後したりオーバヘッドが発生しようともやらなきゃいけないこともあるんだけど。それでも、やったことを保証すること、その裏付けを残すことを忘れると、仕事を後からひっくり返されるわけで。自分の身を守るためにも、こういうこと考えつつ進められるようにしておかないとイカンと思ったりしたのでした。