エラーを制するものがシステムを支配できるんだっ！って思いを仕込んでみるテスト

SEなLog 会社にて

自分の仕事をしながらではあるが、どうしてもやらなければならないことがある。
後輩教育である。

後輩を育てないことには、自分に仕事が集中して降りかかってくるので、
なるべく仕事量を分散するためにも、後輩教育は欠かせない。
「おばちゃん、仕事があるのは助かるけど、たくさんはしたないねん」というのが、本音ベース。(^^;)

私達、システムエンジニアとかプログラマとかがいるような職場では、
大きな仕事の流れがざっくりと書くと、

　顧客へ「システム作りませんか？」と提案
　　　または
　顧客から「こんなシステム作ってほしいんだけど」というお願い
　　　　↓
　顧客の要望を引き出すためのインタビュー
　　　　↓
　顧客へ「こんなシステムを作りますよ」というレビューをして受発注
　　　　↓
　システムの開発
　　　　↓
　顧客側のシステムの受け入れ(場合によってはシステム操作の教育)
　　　　↓
　システムの維持・運用

という流れになっている。
このうち、お願いの部分や受発注の部分なんかはめちゃくちゃ期間の短い仕事で、インタビューや開発はその次に長い仕事、一番最後のシステム維持・運用の部分が一番長い期間…それまでに費やされてきた期間など、すぐに吹き飛んでしまうほどの長期間、行われる。
維持・運用の期間は、開発の期間なんかと比べたらべらぼうに長いのだ。
長いのだけれども、なるべくやることは少ない方向であるほうがいい、そんな期間であったりもする。(^^;)

で、システム開発というのは、システムエンジニアやプログラマが一番頑張る部分であり、システム維持・運用を如何に楽にできるかという使命を持ってあたらなければならない部分だったりする。

でも、この「システム維持・運用を如何に楽にできるか」というのが、実は結構難しかったりする。
システムの維持をするためには、システムが正常に稼動し続けなければならなくて、仮に、障害が起こってしまった場合には、早急に復旧しなければならない。
この状況を実現するには、

  • システム上で起こりえる状況をすべて洗い出しておく
  • すべての状況に対して、正常に稼動するための方法を決めておく
  • どうしても正常に稼動できない場合にはどうして正常に動かないのかのヒントをどこかに表しておく

の3つをきっちりしておかなくてはならない。
この「状況の洗い出し」やそれに対する「対応策」。
コレを見つけて設定するのが、非常に厄介で難しい作業であったりする。

人間は、都合のいい方法を考えるのが比較的得意な生き物だと思う。
システムエンジニアや、プログラマだって人間なので、システムの設計や構築を自分の都合のいい用に作ったりするのが結構得意だったりするものだ。
このときの「自分に都合のいい」とは、自分が「楽にシステムを作れる」方向にベクトルが向いていることが非常に多い。
そして、「楽にシステムを作れる」というベクトルは、「システムの維持・運用を楽にする」というベクトルと、同じ方向を向いているかというと、実はぜんぜん違う方向に向いていたりするのである。

だから、まず、システムを作りはじめのころに、「システムの維持・運用を楽にする」のベクトルになるべく近い形で、「楽にシステムを作れる」方法を選んでおく必要がある。
コレがステップ1。

次に、先に書いたように、「すべての起こりえる状況」を洗い出し、その状況に合わせてシステムに肉付けをしていく。
具体的には、「想定している範囲の正しいデータをこのように扱おう」がステップ1で作られているはずなので、

  • 想定している範囲の正しいデータを扱おうとしたら想定外の動作をした場合
  • 想定していない範囲のデータがやってきたのでそれなりの扱いをした場合
  • 想定していない範囲のデータがやってきたのでそれなりの扱いをしたかったが想定外の動作をした場合


の3パターンを加えてやればよい。
これらの処理は異常処理と呼んだり、例外処理と呼んだり…状況の発生の仕方によって呼称は変わるが、要は「エラー」の状況を制御する処理である。
コレがステップ2。

…
ここで、ステップ2でやらなければならないことが、ステップ1から単純計算で3倍分増えていることに気がついていただきたい…。(^^;)
そりゃ、こんだけ仕事が増えたら、…しかもやりたい方向じゃなければ、やりたくはないワナ。(^^;)

でもね、システムは長く動いていたほうがいいものだし、万が一おかしくなってもそれなりに間違わない方向で動くほうが良い。
そして、とまらないほうが良いし、とまったとしてもとまっている時間が短いほうがいよい。
システムがおかしくなったりとまったり…という状況は、要はエラーの状況。
だから、

　「エラー」の状況を望ましい状況に制御してやる

ことで、システムの維持・運用が楽になるといえる。

…
つらつらと書いたが、コレをいちいち後輩に全部説明して、納得させなきゃならないのである。
納得してもらわないと、あとが大変だから…。

まずはステップ1から、後輩に仕込む。
詳細設計書を元に、自分でクラス図を作ってもらった。
(クラス図を作ってもらっているのは、後輩が「Javaで作りたい」といったから。ちなみに、私はスクリプト形の言語で作ってもらおうと思ってますた。)
案の定、自分だけが考えやすい作りかたをしてきたので、そこからシステム維持・運用を考慮した「思想の修正」と何故そうするのがよいかを、ちょっとずつ仕込んでいく…そういう日々が、もうしばらく続きそうです…。