恐怖の「なぜなぜ分析」IT編

いやいや全くその通り

危険ですよね。物事には原因があるのは間違いないんだけど、そもそもが複合的な要因からなるような問題を根本的な一つの問題に帰結させようとする試みはよくありません。なぜなぜ分析ってのは本来システム（プロセス）を改善するための行為なんだけど…

良くあるパターンとして、どうしても原因は「人」にしか帰結しないのでミスしたやつを止めさせるしか無い（それが超有能だけどたまたま一発やらかしちゃっただけであっても）という悲惨なパターン。原因をプロセスに求めても「リーダーのチェックが行き届いていなかった」になると普通は「工数が足りねーからだろ」ってなるはずが工数が足りないとは口が裂けても言えない（そこに帰結させる「政治的な」メリットがない）ため、泣く泣く優秀なリーダーを犠牲にしてプロジェクト崩壊とかね。極端な話ですが。

ITにおいてなぜなぜ分析をやると本来であれば「工数か単価のどちらかが跳ね上がる施策」にしか帰結し得ないんですよ。で、それに帰結したらその分お金が出てくるかというと、絶対に出てこない。なんでかしらないけどプロジェクトが日を追う毎にチェックリストの項目は増えて工数は加速度的に掛かるようになってそれでも同じ金額、同じ人数で頑張ると負荷が上がってチェックが行き届かなくなって余計に品質が落ちるというね。テストで見つかれば（地獄が繰り返されるとはいえ）まだマシだけど、本番稼働まで発覚しなければ洒落になりません。

いやね、なぜなぜ分析やらなくていいって話じゃないんですよ。やっぱり障害が起きるってことはなにか問題があることを疑うべきだし、改善すべき点は改善すべき。でも、所詮は費用対効果の世界で我々は仕事をしているわけですから、その分岐点を超えてしまうような改善って実質的に意味が無いわけですよ。特に「誰の責任か」を追求するような分析には全く意味が無いと現場としては思います。

でもね、上の上の上の方の人が求めている報告って「で、結局誰が悪いの？」だったりするからたちが悪いんです。

ITシステムでもっとも計測されないのは作業の費用感です。タイプ速度にしたって個人差がありすぎるし、コンパイル待ち時間なんてのもマシンのスペックによって違うし、すげー昔で言うとプログラムシートに手書きでプログラムしたのを渡してしばらくは何も出来ないわけですよね。ITシステムを作るときの作業時間が定量化できないことはいい面もありますが、作業を増やすことによるコスト感も同様に想像ができなくなっている、というのが問題です。

ITシステムが事業の要になっている会社は経営に責任がある立場にIT部門（作業レベルのコスト感あり）出身の人がいないといけませんね。その点が某赤い銀行と某青い銀行の大きな違いなのかもしれません。