ときどき思い出そうとして忘れてしまうのでメモ
- 廃止: そもそも、それ、やんないでよくね?
- 削減: 削ってもよくない? 粗くしてもよくない?
- 容易化: もっと早く、もっと簡単でよくない?
- 標準化: ルール化、マニュアル化できない?
- 計画化: いつ、何をするか先読みできない?
- 分業分担: 分業化・集中化・外注できない?
- 同期化: 待ったり、催促したり、調整したりとか、なくせない?
- 機械化: 手書きとかやめられない? 自動化できない?
ハンス・ゼークトの組織論の
- 有能な怠け者は司令官にせよ
- 有能な働き者は参謀にせよ
- 無能な怠け者も連絡将校か下級兵士にせよ
- 無能な働き者は銃殺せよ
に通じる。
人はつい、「おっ、これ自動化しちゃおうか!」と、スクリプト書いたりマクロ書いたりしてしまいがちなものだ。自戒も含めて。しかしこれは、まず最初に検討すべき「そもそもやんなくてよくね?」を飛ばして「自動化しよう」に取り組んでしまうことなので、無駄かもしれない。それどころか、仲間や後継に対し、保守しなければいけないものを増やしてしまうことで、負担を増やしてしまうかもしれない。
実際には、ここまで短絡的に、直情的に、考えなしに自動化に取り組んでしまうケースは少ないかもしれない。しかし、2つの不均衡により「ついうっかり自動化」が起こりうる。
ひとつは、機械化するコストの低下だ。1970年代に業務を機械化しようと思ったら、数千万円のミニコンピュータと人員の投下が必要だっただろう。1980年代だったら、パソコンPC-9801あたりの導入のため数十万円の決済を書くことになる。2000年代以降、社員全員にパソコンはゆきわたり、当たり前のようにMicrosoft Officeなども入っていて、本屋で買ってきた入門書を片手にExcelを開けば、VBAの編集画面はすぐそこだ。自動化の入り口へのコストは見かけ上なくなっている。昼休みのあとのいち社員の思いつきレベルで「ついうっかり自動化」の釜の蓋が開いてしまうことになる。
もうひとつは、「廃止」にはメタレベルの知識と判断と権限が必要なことだ。タスクを止めるのは案外難しい。携わる人間が複数いたり、社外にもステークホルダーがいたりすると、現場だけでは判断する材料や視野が足らず、決断する権限がなく、各種調整を実行する執行権も難しかったりする。トップダウンand/orボトムアップが豊かに営まれている組織ならさておき、このあたりにも不全があったりすると、とりあえずの日々の業務のミクロな改善として、現場の一等兵による「目先だけの自動化」が生まれやすくなる。
Perl言語の作者Larry Wallは、プログラマに必要な3つの悪徳として「怠惰」「短気」「傲慢」を挙げている。
怠惰 = ラクになるためなら技術的な手間は惜しまない
短気 = 高速化や改善への努力を惜しまない (ダメなモノには我慢できねえという短気)
傲慢 = 品質に反映される自尊心
しかしこのうち「怠惰」「短気」は、あくまでもプログラミングにおける美徳であって、さらにもう一段うえの、そもそもそれをやるべきかの判断においては、美徳ではない。
上に引いたハンス・ゼークトの組織論における怠惰の美徳は「有能な怠け者は司令官にせよ」、つまり「1. 廃止: そもそも、それ、やんないでよくね?」にまず気がつくことを指している。このメタレベルで考えると、プログラマ美徳の怠惰と短気は、プログラミングというスコープにおいては美徳であるが、もう一段うえの、プログラマ、あるいはエンジニア、あるいはいち組織員としては、あまり美徳でない。「1. 廃止」を飛ばして「8. 機械化」にばかり夢中になり、あげくは技術的負債を増やしているものがいたら、「無能な働き者は銃殺せよ」のセクションが待っているかもしれない。
追記。ECRSも。
ECRSとは、業務改善を実視する上での、順番と視点を示したものである。ECRSは、Eliminate(排除)、Combine(結合と分離)、Rearrange(入替えと代替)、Simplify(簡素化)の英語の頭文字を選択したものである。業務の改善においてECRSを適用すると、改善の効果が大きく、過剰や過小な改善も避けられ、さらに不要なトラブルも最小になることが知られている。
