∑考=人

そして今日も考える。

効率化を考える前に楽しみ方を考えよう

この世で最もつまらない仕事は、「穴を掘ってそして自分で掘った穴を埋める」という作業らしい。これを何セットも繰り返すと、著しくモチベーションが低下してしまうようだ。

 

何かの本で読んだが、レゴを使って同じような研究がされていた。一つのチームには、次から次へと新しいレゴのブロックを組み立ててもらい、もう一つのチームには、一度組み立てたレゴを解体してから再び同じレゴを組み立ててもらう。そして各チームに報酬を与える、といった趣旨の比較研究だった。当然ながら、後者の方がモチベーションが低くなり、早く作業をやめてしまった。

 

一般的に人は創造性を発揮できる時、はっきりとした目的がある時にモチベーションが高まるという。上記の例では、全くもって対極であることがお分かりだろう。ひたすら単調作業であり、しかも一度作ったものを自ら壊すことにより目的意識も削がれてしまうからだ。

 

会社において新人に与えられる仕事というのは、これに近しいものがある。私は今のところ、主に設計書の修正を担当しているが、創造的に設計をしているわけではない。上司たちが決めた決定事項をドキュメントに落としこんでいるだけの単調作業である(といっても例年に比べればむしろ羨ましがられるぐらいの仕事だというから驚きだ)。

 

別にただの単調作業であるなら特に苦痛には思わない。ただ、最近になって漸く自分の中に嫌悪感が芽生え始めた。その発端は、一度修正した設計書の再修正を依頼された時である。

 

私の資料作りに問題があったから仕方がない、というわけではない。もちろん、私の資料作りには至らないところもあり、何度も修正を重ねたことは事実である。しかし、一度はOKをもらったドキュメントの再修正を命じられたのだ。それはなぜか。

 

「プロジェクトは生き物だからね。」数ヶ月前、部長が言っていた言葉である。その時の私には、その言葉の本質はわからなかったのだが、今になってみるとその言葉の真意を理解できる気がする。要するに、システム開発のプロジェクトは生き物のように刻一刻と変化していくというメタファーだったのだ。

 

私たちがプロジェクトを進めている間にも仕様は変化していく。一応、要件定義、設計、製造、試験などと工程は分かれているが、そんなものは名ばかりのものだ。実際、今のプロジェクトも、既に詳細(内部)設計工程に入っているにもかかわらず、計画は日々修正されるし、仕様も変わっていく。全てはお客様のために、というわけだ。

 

詳細設計工程時に仕様が変わるということは、変更内容を基本設計書に反映させなければならないということである。最初であれば全然大したことではなかった変更、例えばとある一つの機能の名称が変わるだけでも、ドキュメントの修正箇所は数百ページにものぼる。仕様が変わるとなれば、その影響度は計り知れない。

 

さらに言えば、そうやって一度修正した箇所が結局元に戻ることもある。元の木阿弥。まさに自分で掘った穴を自分で埋める作業とタブる。これははっきり言って、結構辛い。

 

とは言っても、だからやる気が起きないのはしょうがない、と片付けるのは少し早い。例えば、私の場合は、エクセルやワードの使い方の勉強だと思って取り組んでいる。こんな便利な関数があったのか、とか、こんなショートカットキーがあったのか、とか、そういう視点を持って取り組むと色々と発見があって面白い。

 

単調作業を通じて得た知識やスキルを身につけて、前に修正した時よりも断然早く作業を進めることができるようになると、割と達成感もある。(同時に以前はなんて無駄な時間を過ごしたんだとも思う。)もし可能であれば、修正する必要のない箇所(特に見た目)とかにこだわってみるのも面白い。

 

私の場合は、たまたま効率化を考えること自体が一つのモチベーションに繋がるが、そうでない人は自分が楽しくするためにどうすればよいかを一度考えてみたほうが良い。本来、工夫をするのは物事を効率的に進めるためではなく、物事を楽しく進めるためのものだからだ。楽しく作業をすれば、結果的に作業効率が上がることにも気づくだろう。