どんな作業のマニュアルでも３時間あれば作れる

例えばお客さんから預かってるサーバの監視とか、いつもの道具立て(ウチなら JSP + Struts + Spring + Spring JDBCとか)でWebアプリケーションを構築するとか、そういう「おおよそ決まった手順があるけど、細部は毎回異なる」作業については、マニュアルを用意して担当できる人を増やさなくてはならないのだが、ウチはそういうものの整備が甘い。これは「マニュアルとは何か」の考え方が統一されてないから。

個人的には以下のようなマニュアル観は間違っていると思う。

• 不完全なマニュアルを配られても困る
• マニュアルに書いてある通りにやって問題が起きるぐらいなら、そんなの無いほうがいいんじゃないの
• 書いてある通りにやって問題が起きても作業者の責任ではない。嘘のマニュアルを書いたやつが悪い
• マニュアルとは「書いてある通りに作業するためのもの」なのだから、例外事項がたくさんある作業のマニュアルなんて書けない
• マニュアルがあると、それに頼り切って頭を使わなくなるので、作業者が成長しなくなるのが問題だ

どこが間違っているかというと、こう考える組織では永遠にマニュアルができないから*1。
すると、ノウハウが属人的になって「あの人が居ないと困る作業」が増えていき、ノウハウを知らない人は役立たずになる。
で、ノウハウを知っている人は「何か俺ばっかり忙しいんですけど。あいつら暇そうだけど使えねえし」と被害者意識を持つようになり、知らない人は「俺何も教わってねえもん。聞いてねえもん」となる。これはもう組織のアンチパターン。何のために組織の格好をしているのか分からない。

これでは困るので「知ってる人」からノウハウを引き出して誰でも作業できるようにしたいのだが、知ってる人が「最初から完璧なものを作らなくてはならない」と考えてると話が進まない。そういう人に「あいつ暇そうだからあいつに仕事振りましょうよ」「マニュアルなんて３時間あれば書けますよ」みたいなことを言ったらすごい反発される。「そんな簡単に考えてもらっては困る！トラブったらどうする！」みたいな。でも本当のことだからしょうがないじゃない。

「３時間あれば書ける」というのは、完璧なものが書けるという意味ではなくて、漏れや間違いは毎回の作業担当者が発見次第修正するから、初版なんて３時間で作ればいい、という意味。
トヨタの大野耐一氏がこの辺について核心を突いたことを言っている。

http://blog.livedoor.jp/mind2005/archives/cat_10015449.html
「標準作業というのがあるが、標準というのは、刻々変わっていかにゃ
　おかしいんで、そいつを、標準というのを最善だと思ったらもういかん。
　標準というのは、改善するためのひとつのベースであってね、
　今より悪くなったやつは改悪であり、今より良くなったやつはは改善なんで、
　こんなものは人間がいい加減にきめるんでね、変わっていかねばおかしい。」

この人は冗談で「標準なんて改善の出発点にすぎいなのだから、最初はいいかげんなぐらいがちょうどいい。その方が改善する気になるもの」ということも言っている。
マニュアルにはこの考え方が必要。マニュアルというものを

• 作業実行の度に、担当者が必ず加筆訂正すべきもの
• それがあっても、考えることを放棄できるわけではないもの
• 抜けや間違いがあるので、考えながら手順なぞらなくてはならないもの
• そこに書いてあることと違うことをするのなら、新しい手順の方が効率的であることを証明しなくてはならないもの

と考えて運用すれば、属人的なノウハウが作業の度に徐々に明文化されて、そのうち「知ってる人」の代わりに作業できる人が増えてくる。
まともなマニュアルのある会社はそうやって文書を育てたんじゃないのか。

ソフトハウスで、20代の人より30代の古参の方が忙しそうにしていたら、多分ウチと同じ病気にかかっている。
30代社員が若い人に任せられる仕事を任せていないはずだ。で「考える時間がない」とか文句言っているはずだ。
ウチなんか10時過ぎたら残ってるの全員ｵｻｰﾝだもの。これはやばい。すごくやばい。

*1:マニュアルを書く人間だけがトラブル発生のリスクを負うことになるから