責任回避かチキンレースか　～仕事で失敗をするありがちなパターン

　まだ僕がＩＴ業界で働き出して間もない頃の話だ。僕は客先に常駐する形である開発のプロジェクトに参加していたのだけど、スキル不足だった事もあって、がむしゃらにただ目の前の自分の作業に追われる日々を過ごしていた。

　だから全体の事になんかまったく意識は回っていなかった。しかし、そんな中でも“何かこのプロジェクトはおかしい”と感じてはいたのだった。

　僕がそのプロジェクトに参加した頃には上流工程は既に終わっていて、僕はある機能のプログラミングを引き継いでいた。だからある程度は既にプログラミングされていたのだけど、そのソースを読んでいて奇妙な点に気が付いた。

　「あれ？　似たような共通のユーティルクラスが複数あるぞ？」

　“ユーティルクラス”というのは、汎用的で便利な処理を行ってくれるプログラミング部品の事で、例えば文字型を数値型に変換したり、日付型の日を一つ進めたりといった処理をそこに書いておけば、いちいち個別に実装しなくても、そのユーティルクラスを呼び出すだけでそれら処理を行ってくれる。だからもちろん一つあれば充分のはずだ。何故、複数あるのだろう？

　腑に落ちなかったのだけど、とにかく「あるのだから使えば良い」とそのうちの一つを僕は使ってみたのだけど、実際に動かしてみたらなんと上手く動かないものがあった。つまり、バグがあったのだ。仕方ないので、正常に動くものを探すか、それが面倒なら自分で作るしかなかった（勝手に他の人が作った部品を弄るのは憚られたのだ）。そして、その過程で僕はどうしてそんな事になってしまっているのかを悟った。

　「このプロジェクト、共通部品の作成担当がいないんだ……」

　自分で作成すると余計な仕事が増えるし責任も負ってしまうから誰もやりたがらない。それで皆は誰かが作るのを待っている。結局は「これ以上待っていたら、仕事が間に合わない」と、そのチキンレースに負けた人が作成する事になるのだけど、その人が真面目に仕事をしない場合もあり、だからその所為でバグがあったりもする。そして、バグがあったり、そもそもその部品がある事を知らなかったなら、同じ部品を誰かがまた作ってしまい、結果として似たような共通の部品がたくさんできてしまう事になる。

　はっきり言って、その現場の共通部品はカオス状態だった。その現場には、三ヵ月程しかいなかったから本当に問題になる前に逃げられたのだけど、その惨状は当時の僕に鮮烈な印象を与えた。僕が去った後、あれは一体どうなったのだろう？　多分、誰かが物凄く苦労したのじゃないかと思うのだけど。

　そのプロジェクトを去ってからも、僕はどうしてそのような事になってしまったのか考えていた。

　そして、「誰も仕事の責任者がいなかったからだ」という結論に達した。“プログラミングの作成者”じゃない、“責任者”だ。作成自体は他の人に任せても良いのだから。責任者がいないから誰も管理できなかったのだ。共通部品担当者がどんな部品が必要かを把握して作成するか作成を依頼し、どんな部品があるかを資料にしておけば、そのような事態にはならなかっただろう。バグがあったら、その責任者が何かしら対処していただろうし。

　僕はその後も様々な開発現場を巡ったのだけど、似たような状態になりそうな危険な兆候を感じ取る事が度々あった。

　誰かがその仕事をやらなくてはならない。しかし、誰の担当なのか責任が明確になっておらず、結果的に放置されてしまう。

　責任回避かチキンレースか。

　ただ、放置し続ければ、プロジェクト全体が困った事態になるのは目に見えている。

　だから、

　「あの……　この仕事、誰がやるのですか？　誰かが進めないと困った事になりますよ」

　僕はミーティングなどの席で問題提起をするように心がけるようにした。そして責任者がちゃんとした人なら、それで予防ができる場合も多かった。

　これはこの業界に入った初めの頃に、そのような問題を抱えたプロジェクトを経験できたお陰と言えるかもしれない。

　――ただ、

　「なら、君が担当してくれない？」

　問題提起をすると、そのままそれが自分の仕事になってしまうケースもとても多かったのだけど。

　こういう傾向は、日本の悪しき労働慣行だろうと思う……。だから誰も問題提起をしたがらないのだろうなぁ。

　ま、それで自分の評価は上がるのだけど。