オートメーション
色んなところでお勧めされていたので、『最少の時間と労力で最大の成果を出す「仕組み」仕事術』を読んでみた。
相変わらず、書評的なものを書くつもりはなく、感想や思ったことを書いていきたいなあと思う。
仕事の手順や仕組みを構築して、誰にでもできるようなマニュアル、ドキュメントなどを作成することで、効率よくできると言っている。これは、今の僕の業務などに照らし合わせてみるとよくわかる。
僕はプログラマーであるが、一番下っ端ということもあって、全ての時間をプログラミングに充てることはできない。雑用が次から次へと降ってくるからだ。しかし、これらにマニュアルがあるかと言うと、そんなことはない。
最初は、先輩に聞きに行き、わからなくなったり、判断できなくなったら、また先輩に聞きに行くということを繰り返している。この本にも書いてある通り、わからなくなると、作業が止まって、考える。しかし、考えてもわからないから聞きに行くということを繰り返すことになる。これが何回も繰り返されるとはっきり言って、双方にうざくなってくる。最初から、マニュアルがあれば、そんなことはなくなる。
もちろん、全てに完璧なマニュアルがあればいいわけではない*1。先輩に聞きに行くのは、どこかわからないとか、自分の仮説をぶつけたり、コミュニケーション力をつけるための一つの手段でもあるので、全てをドキュメントに託す必要はないが。
しかし、マニュアルがあることで、時間にも余裕が生まれるし、その生まれた時間で、マニュアルに書かれていることなどについて、勉強したり、マニュアルを改善したりする時間が生まれて、次代へと受け継がれて行けば、これほど効率的なものはないのではないかと思うわけだ。
Danさんのブログでもこの本の書評が書かれている*2けれど、プログミングって仕組みであると思う。例えば、あるデータがあってドキュメントに起こしたい場合、ツールを作って必要事項を一カ所に記入して、ボタンを押せばドキュメントが作成されるようなプログラミング。また、製品リリースの時に、バージョン番号や製品番号を変更しなければならないときなど、ボタンを押すと勝手に変わってくれるプログラミングなど。または。。。と挙げれば、きりがなく、プログラミングって最強の仕組みだなあと思う。
プログラミングができなければ、マニュアルやドキュメントで仕組み化を図れば良いと思う。また、ロジなどはプログラミングとかでは難しい*3と思われるので、こういったところには、紙ベースでの仕組みが必要だと思う。
*1:というか完璧なマニュアルなどはない
*2:http://blog.livedoor.jp/dankogai/archives/51019268.html
*3:種類にもよるので一概には言えないけれど、こういったロジ関係でプログラミングができるようになると強いのではないかと思う。もしかしたら、既にあって僕が知らないだけかも
