かけた時間=成果ではない


私が過去に在籍していた会社の話ですが、残業撲滅を掲げて、定時退社を義務化している会社があったんですが、数名の社員は定時に退社こそするものの場所をかえて業務を続けるという事態になってたらしいです。

たぶん「人件費削減」とか「生産性の向上」とかが目的なんだろうけど、こういうのって形だけ義務化してトップダウンで押し付けてもうまくいかなくて、目的や考え方、文化といったようなものをちゃんと伝達しないとダメなような気がします。ぼく自身も「ダラダラした長時間労働は悪」で「休日出勤はセルフマネージメントの敗北」だと考えているし、それを必ずメンバーに伝えるようにしています。

とはいえ何かに没頭して働き続けてしまうことや、達成したい目的に向かって脇目をふらず走って行くことの否定するつもりはないです。自分もそうなることよくあるし。だけど何でもかんでもやればいいってもんじゃないよねーってことはちょっと言いたいです。

時間=成果という錯覚

0008442813E-849x565

IT業界の人にとって「かけた時間と成果は直結しない」なんて、言うまでもなく当たり前のように理解されていることだと思いますが、でもこれって案外行動に反映されていないように思えます。

例えば、何か成し遂げたいことがあるとして、それを達成するためにがむしゃらにやって行こうと考えたとします。すると真っ先に行動に現れるのが「とにかく多くの時間を作業にあてる」ってなっちゃいませんか。そうやって多くの時間を投資していくことで、成果を出しているという「安心感」を得ようとしていませんか。

この「安心感」というのが非常に中毒性が高いクセ者で、成果に関係なく時間を費やしていないと安心出来なくなってきます。ぼく自身もよくこれに陥ってしまうことがあるので、そうならないように仕組みで回避しようとしています。

「成果」を明確にさせるためにやっていること

まず「成果」が曖昧なのが一つの原因だと考えました。だから成果を計画するアプローチをとっています。

シンプルにプロジェクト単位で考えていきます。普段は小規模プロジェクトがメインなので大規模の場合に応用できるかは知らない。

まずプロジェクト全体の計画をたててそれを最終的な成果とし、可能な限り具体的に計画します。どのようなスパンのプロジェクトでも必ず3ヶ月以内で一区切りにします。なぜかというと計画が大きくなればなるほど、ズレが大きくなってしまうからです。ズレが大きくなっていくと焦ってきて次第にがむしゃらに目の前の作業をこなすようになってきがちです。

3カ月におさまらない計画は分割します。成果物を実現するのにトータルどれくらいかかるか、ではなく、3カ月という期間を固定してその中でどこまでできるか、という風に考えます。成果物トータルで計画すると、大半の場合ムリが入り込んでしまうからです。

その次にイテレーションという手法をとって一週間のタスクを明確にし、作業可能な具体的なレベルまで落とし込みます。同じように、その一週間の最終日までに翌一週間の計画し、これを毎週継続し続けます。我々はプロジェクト管理ツールRedmine, PivotalTrackerやGithubなどを活用しています。

Pivotal-Tracker-Stacked

一週間の計画を踏まえて、更に毎朝その日消化すべきタスクを計画します。このとき絶対に達成できないような計画を立てないように注意します。で、ここがコツなんですが、1日分のタスクが終了したら、他のことをやろうとせずにすぐに帰るようにします。あえて他のメンバーの作業も手伝わないようにしています。

ちなみに一日の計画はTodoistというナイスなTODO管理アプリを使っています。これすごいいい。

ja.todoist.com/

早く終われば早く帰れるという仕組みなるので、自然と効率化の努力をしていく方向に力がかかります。計画にそったアウトプットを出しているので進捗が遅れるということもありませんし、一週間単位で実行可能な計画をしているので、突発的に必要以上に負荷がかかることもありません。

このように大きい単位から小さい単位まで分解し明確にしていくことで、一日単位の「成果」の曖昧さを排除することができ、時間を投資することで得られる「安心感」の呪縛から逃れることが出来ると考えています。

とは言え考えていた程簡単ではないですが。大事なのは、問題があれば仕組みは改善し続けていくこと。生産性の向上に妥協しないこと。

で何する?

生産性を上げて、うまく時間をやりくり出来るようになってどうしたいかって?
そうですね、もっとプログラミングしたいです。