「問題の順位」の術 - PART2

見えない問題

いくつもの問題が「現象」として現れているとき、そのうちどれとどれが関係があるかとか、ある現象が実は別の現象の「原因」であったということがわかればラッキーです。原因の方から先に解決していけば最短時間で問題が解決するからです。しかし、いくら原因と現象について注意を払っていても、本当は見えないところに原因があるのかもしれません。必ずしも原因が現象として現れるとは限らないからです。

見えないところにある原因は（まだ）問題になっていないのでそのまま放っておいて、現象の方だけ直接修正してしまえば実害はないような気がするかもしれません。しかし原因を取り除いておかないと、将来的に同じ原因の現象が発生するかもしれないので、今現在無害に見えても何とかすべきでしょう。

ですから、たくさんくの問題が浮上したときにやらなければならないことは、それらの問題の現象のうちどれとどれが関係がありそうか見当をつけて、それらに共通の（もしかしたら今は目に見えないところに潜んでいるかもしれない）原因を見つけだすことです。と言ってしまえば簡単そうですが、これが簡単ではないのです。たぶん、決まったやり方も存在しません。勘とか経験がものをいう世界です。

しかも、すでに述べた通り、原因とは単なる妥協点です。「これが原因ということにするといろいろ解決するので、そうしましょう」というだけのことです。原因にはそのまた原因があるからです。だとしたら、もうエンジニアの個人的な才能に期待するよりないでしょう。実際、1つの問題を修正するための方法がいくつも存在することはよくあるし、優秀なエンジニアほど修正方法がいくつもあるということに気付くのです。直し方をいくつも見つけることができれば、どこを直すのが良いか、つまりどこが「原因」かを選ぶことができるのです。

もしかしたら、こういう考え方は受け入れ難いかも知れませんね。原因は確固たるものであるべきだという考え方の方が安心感がありますから。でも、ちょっと幻滅するかも知れませんが、物事がうまくいかない理由なんて頭をひねればいくつでも見つかるものです。

ところで、「問題の原因は隠れているものだ」と初めから心得ておけば、実際に問題が起こった時に役立つ判断材料をあらかじめ随所に埋め込んでおけるかも知れません。たとえばログ出力は顕著な例です。上手なログメッセージは、問題の原因究明に威力を発揮します。ですから、そういう気持ちを込めてログを埋め込むようにしましょう（これは面倒くさいので、私自身もついサボってしまいがちなのですが）。

最後の問題

さて、このようにして問題を原因の方から順序よく解決していくと、最後に残るのは小さな問題ばかりということになります。物分かりの悪い上司だと「なぜこんな小さな問題がいくつも、しかも最後まで残っているんだっ」などと立腹するでしょうが、ぜんぜんそれで良いのです、はい。小さな問題など、いくつ束になっても結局小さな問題なので、どうってことなく片づくのです。小さな問題が10あるより、たった1つの大きな問題の方がタチが悪いのです。例えて言うなら、可視光線をいくら浴びても平気だけれど、紫外線は少量でも日焼けするのに似ています。・・・似てないか。

ともかく、目の前の小さな問題に翻弄されてはいけません。たとえ簡単に直せそうに見えるバグでも、安直に直すとあとでまずいことになる場合があるのです。まずは原因をつきとめるのです。そして原因をつきとめるということは、「どこら辺りを原因ということにしましょうかねぇ」という風に、ちょうど良い妥協点を見つけることなのです。

パソコンを分解したり組み立てたりしたことはありますか？やってみるとわかるのですが、たいがいのパソコンは同じような部品でできています。同じように、ソフトウェアも部品で構成することができます。