IT業界の実態と属人化のメリット(良い点)をあえて考えてみる
IT業界の実態と属人化のメリットをあえて考えてみる
誤解しないで欲しいのは、私が『属人化』を賛美するつもりは、決してないという事である。
私は、現場仕事も、システム開発の現場実態も、何も経験したことがないくせに、したり顔で「属人化は悪だ」、「属人化は排除しなければ社員が不幸になる」と、言っている管理者や経営者が、あまりにも多くいる事が、許せないだけだ。
役員の椅子に座って現場を知らないアナタ。
絶対、わかって言ってないだろう。
どんな事柄にも、良い点と、悪い点があるものだ。
どんな事柄にも、だ。
IT業界の実態の例としてある企業の業務システムのトラブル対応を考えてみる
上図に示したように、ある企業の業務システムにおいて、夜間バッチ処理が、予期せぬDB障害で異常終了してしまった。
夜間はシステムの内容は何も知らない運用部門（しかも派遣で集めた人員）しかおらず、連絡を受けた担当SEも何も判断できず…
「バッチ処理はそのまま停止したままにして、DB環境についてはサーバーのセットダウン・アップによる再起動で様子を見る。詳細な対応はSEメンバーが出社する翌朝以降に対応する」
…という、最低限の措置を取った。
よくありそうな話である。
手を動かさないステークホルダー(例えば顧客とか)が多いと現場はコミュニケーションに忙殺され回らなくなる
夜間のうちに連絡が取れたSEメンバーの何名かは、朝8時前には出社して、情報収集から始める。
上図にも示したが、運用開始以降、十数年間、一度も発生した事がない場所だった。
そもそも、そのサブシステムについて、何をしているシステムなのか、どういう処理をしているのか、といった基本的な事を、ほとんどのメンバーが知らなかった。
かねてからの人員削減の波や、現場を無視した人事ローテーション等によって、そういった既存システムに関する知識を持った人は年々居なくなって行くのである。
システム保守チームのリーダーは、それでも発生した状況を整理し、他のシステムや、何より"顧客の業務影響"を"早急に"把握して、顧客に伝えなければならない。
こういう状況では、各処理ごとに存在するシステムの設計書などは、あまり役には立たない。
もっと全体像を捉えなければならないからである。
DB障害はすぐには原因はわからないが、再起動で問題なく動作している事は確認できた。
DBから返されたメッセージを見ると、いきなりDBサーバープロセスがダウンしてしまったようだった。
ひとまず、DB障害の原因追究は、DBインフラの部隊に後でログを送付して、必要ならばメーカーにも送付してもらっての対応となるだろう。
取り急ぎでは、AP側のバッチ処理の復旧が優先となる。
朝イチの電話で、顧客側の担当者に、リーダーから昨夜からの状況を伝える。
「DBのプロセスが落ちた」と言っても、まったくの素人である顧客にはなかなか伝わらない。
「データやAP側の問題ではない」という事を強調し、まずはリカバリを急ぐ事になった。
そこに、たった一名ではあったが、このサブシステムを十数年前に開発した時、メンバーとして関わった事があるAさんが出社した。
Aさんがトラブル対応に首をつっこみ、「ここの処理からバッチ処理を昨夜時間として流し直せばうまくいくはずだ」という見解と、そもそも「ここの処理が何をしているか」、「業務にどのような影響があるのか」を、ざっくりではあったが、リーダーに伝えられた。
開発から十数年も経過しているため、詳細な部分までは記憶が定かではなかったり、そもそも、彼が知らないうちに保守改良等で仕様が変更されている可能性はあった。
だが、大まかでも「何をしているシステムか」、「どんな業務影響がありえるのか」を、把握できる事は大きい。
詳細な部分は、それこそピンポイントで設計書やプログラムを調べれば良い事なのである。
上記のような点を、ひとまず文書としてまとめて、顧客側や運用部隊などのステークホルダー（関係者）に伝える必要があった。
しかし、リーダーの電話は鳴りっぱなしである。
障害が発生したシステムの顧客部門の担当者はもちろんだが、データ連携先の顧客部門が、非常にうるさい。
「バッチ処理を再処理すると言うが、それで上手く行く『保証』はあるのか」
…などと言っている。
今回はインフラ障害（DB障害）なのだ。
これまで十数年間も落ちたことがない場所で、プログラムの入れ替えもしていない。
状況からは、「データやAP側」が原因である可能性は低い。
なので、DBが正常に動いているのなら、再処理で上手く行く可能性が高い。
…といった、常識的な事が顧客側担当者には、なかなか伝わらない。…というか、顧客側も担当者が納得できないのではなく、後ろでその上司がギャーギャー言っているのだろう。
ステークホルダーへの状況説明のメールは、けっきょく、リーダーではなく、Aさんが直接書くことになった。
リーダーは、いろいろな作業をするメンバーへの指示や、ステークホルダーからの連絡対応に忙殺されてしまい、とてもAさんから情報を聞き取って理解し、それを文書化する、という行為は不可能だった。
連携先のシステムは特定の時間に起動されるようになっていて、相手側との調整もいろいろ必要となったが、初動が比較的早かったため、トラブルの拡大は防ぐことができた。
ここにAさんが居た場合と居なかった場合とを考えてみる
「ここに現行システムを知っているAさんが居るのがいけない」
経営者たちはしたり顔で言うだろう。
彼のような者が居るから、こうしたトラブル時にも、彼に仕事が振られ、けっきょく、ますます属人化が進行してしまう、と。
彼のような者が居なければ、イヤでも知識を持たないメンバーが、現存するドキュメントやプログラムなどを調べるなどして、何とか対応し、結果として、知識が拡散される、と。
その考え方は、まったく現場のメンバーの苦労をわかっていない。
自分が何も知らない、昔の誰かが開発したシステムについて、顧客側からは「君たちはシステム屋なんだから知っていて当たり前だろう」と言う目で見られながら、トラブル対応というような『時間に追われる』作業を強いられる。
これが、どれほどの強大なストレス源となるか。
それが、まったくわかっていない。
まぁ、こうした仕事が、システム保守というものではあるのだが、こういう状況ばかりが続くと、本当に心が折れる。
こういう無茶振りの仕事にも、向き不向きがあるので、どんなに均等に割り振ろうとしても無理が出る。
そうなると、小さな属人化が発生し始める。
そして、属人化の負のスパイラルが発生して、知識を途中まで溜め込んだメンバーが辞めてしまったりする。
そして、更にわかっていない事は、ドキュメントやプログラムを調べれば、有識者よりも時間はかかるだろうが、同じような成果を出せるはず、という幻想だ。
ここで、管理者や経営者が想定する「時間はかかるだろう」というのは、せいぜい１日～２日だ。
違う。まるでわかっていない。
上記の、Aさんがリーダーに示したような見解を、知らないメンバーがドキュメントやプログラムから導き出すには、何週間も、もしかすると何ヶ月もかかる。
「障害が発生してしまいましたが、開発したときの有識者は既に離散しておりまして、申し訳ありませんが、復旧（解決とまでは言っていない）には１ヶ月のお時間が必要です」
このように顧客に言って良いというならば、そうしようではないか。
これが言える管理者や経営者が居るのか？ …ということである。
仮に。
仮にそう言えたとしても。
何週間も、何ヶ月もの間、トラブル対応という異常な仕事をやり続ける事は、どんな人間にも無理なのだ。
絶対に心身ともに壊れてしまう。
大切なことは、如何にして、「属人化の負のスパラル」を最小限に抑えるか、である。
そして、トラブル対応などといった、属人的な知識が必要、かつ、活用される場では、思いっきり属人化された知識を活かすのだ。
そういった対応の中で、属人化したメンバーに、ある程度機転の効く若手をつけるなど、育成面での工夫はどんどん行うべきだ。
