レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

ルールメーカーの生産性は、96倍

人は往々にして、ルールを拡大解釈して

わざわざそれに縛られていることで生産性を落としていることがよくある。


システム開発の世界では特に顕著だと思う。

今日、僕は一緒に仕事をしてくれているPGさんの仕事を96倍早くこなした。


あらかじめ断っておくと、このPGさんはまじめで優秀だ。

彼を槍玉に挙げたいわけじゃなくて単なる例だと思ってほしい。



一つ保守っぽいタスクがあって、彼はそれの対応をしていた。

どういう内容かといえば、

「あるシステムの内部エラーが発生したときに

共通のエラー画面に飛んでいない。」

というもの。

このタスクは、僕らが新規で作っている機能に関わる保守対応であり

これの解決も顧客要件の一つなんだ。



僕の見積もりでは0.5人日。

それでも多いぐらいだと思っていた。

global-exceptionsに設定してやればいいだけだろうと。(Strutsベースなのです)


しかし、今日そのPGさんから、

「この対応時間がかかりそうです。あと2日ください。」という報告を受けて驚いた。


「いったいどうして!」と僕は聞いた。

2日といえば、16時間=960分だ。


彼は言った

「Exceptionをcatchしていないところが大量にあって、どうしても力技になってしまうんです。」


僕は、なぜglobal-exceptionsに書かないのかと聞いた。

そしたら、global-exceptionsの記述場所に「触るな!」と書いてあり、

他の人もglobal-exceptionsについては変更した形跡が無いからだという。 


僕は、

「触るな」というのは「触らなくていい」ということだと解釈した。

必要なときは触ればいい。と読み取れる。

システムでcatchされていない例外がglobal-exceptionsでさえ受け止められていないのは

問題であるから「触るな」といわれても、「触るべき」なのだ。

問題にもなっていない例外を全てcatchするようなやり方は、全く流行らないやりかただ。


彼に指示して、global-exceptionsを変更してもいいかどうかをリーダーに聞きに行かせた。

しばらくして帰ってきた彼は「global-exceptionsを変更しても良いそうです」と戻ってきた。

この対応は10分で終わり、950分の工数が浮いた。




ルールは、秩序を保つために必要だ。

しかし、できる人ほどルールを破る。

というよりも、ルールの本質を見抜いて、

自分の正論でルールを変える。



僕がお世話になった、某上場企業の主任さん(このブログを見ているらしい)も

典型的なルールメーカーだ。


変なルールにとらわれず、自分が正しいと思うことで判断するから判断が早い。

一方、常にルールブックを参照しに帰らないと判断できない人も居る。


仕事の出来は、一目瞭然だ。ルールメーカーの主任さんの案件は

どんなに困難に見えても、そうそうトラブらない。


ルールメーカーの主任さんは、ヒラのときからとんでもなくデカイ案件のPMに手を上げて

やりとげた。周りの主任や課長さんたちも、怖気づいて手控えた案件だった。

そんなことで、その当時ヒラだったこのルールメーカーさんの下に、

何人もの課長や主任が従っていた。面白いもんだ。



ルールブック崇拝の人は、安全パイの案件でも大トラブルにしてしまう。

こまったもんだ。



ルールメーカーな主任さんは、どんどんルールを捻じ曲げて新しいルールを作っていく。

新しいルールが上手く機能するので、秩序は保たれる。


ルールなんて、先に決めたものが必ずしも正しいわけじゃない。

”本質的に正しい”ものが”正しい”のであって、

正しいルールに新たに気づいたなら、それを採用すればいい。

しかし、新しいルールの採用にコストがかかるなら、控えるのもいい。



どちらにせよ、ルールを絶対視しないところに、ルールメーカーの特徴があり、

ルールを作れるから、仕事上の発想を阻害しない。

発想力は、100のツールや100の開発プロセスにも勝る生産性を生む。


上場大企業のSIerさんにも、こういう面白い人がいるんだと思わされた。

本人も読んでるから、ちょっと褒め気味でかいたけど、

この人、ド変態なのが玉に傷だ。