IT 効率化に取り組むのは、「正直、面倒くさい」と感じることはありませんか?
将来的にはラクになるのに。。
「面倒くさい」と感じる理由のひとつに、一時的に効率が下がることがあります。
単純でクリエイティブでない仕事(というか作業と呼ぶ方がよいかも)を人がやる場合、簡単に慣れることができるし、すぐに習得し、作業効率も急速に上がっていきます。
それを仕組み化するとなると、作業を分解し、仕組み化を設計し、プログラミングなどで実装し、テストしてうまく動かないところを修正するといったことが必要で、それをすべて終えてやっと仕組み化が完成します。
こういった仕組み化の流れは、頭を使います。
一方で、すでに習得した単純作業は頭を使わずにできます。
頭にかかる負荷を比べた場合に、単純作業をやり続けるのと、仕組み化するのとでは、単純作業をやり続ける方が魅力的に感じられるのです。
しかし、ラクに流れるこの思考は、長期的には価値をもたらさない受動的な反応です。
まるで、家に帰ったらとりあえずテレビをつけてダラダラと見てしまったり、ダイエット中なのについつい手近にある食べ物を食べてしまうのと同じです。
Perl というプログラミング言語の生みの親である Larry Wall さんの唱える「プログラマーの三大美徳」として、
- 怠慢(Laziness)
- 短気(Impatience)
- 傲慢(Hubris)
があります。
1つ目の「怠慢」に注目してみましょう。
「怠慢」というと悪いイメージがありますが、Larry Wall さんが美徳としているのは、次のような意図があります。
全体の労力を減らすために手間を惜しまない気質。この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、同じ質問に何度も答えなくてもいいように文書を書いたりする。よって、プログラマーの第一の美徳である。
参考: http://itpro.nikkeibp.co.jp/article/Watcher/20061005/250057/
つまり、単純でクリエイティブでない仕事をやることを「面倒くさい」と考える気質です。
仕組みを作ることを「面倒くさい」と思うか、単純作業を「面倒くさい」と思うか、
それはつまり、今ラクをするか、将来ラクをするか、という問いに置き換えられ、どちらを選ぶかで、生涯を通しての生産性が変わり、生涯を通してのラクできる度合いも変わってくるのです。