- 作業単位が時間単位・プロジェクト内の細かなタスク単位になってくる。
- 時間でタスクを割り振られてマルチタスクになる。
- タスク細分化のせいで、共有タスク（いわゆる「社内工数」）やタイムシェアリングでのマルチタスクなどの複雑な処理が現れる。
活動の細分化をすると、大きなくくりでの丼な勘定が、細分化容易な物と細分化不可な物に分かれてくる。それ自体は別に良い事でも悪い事でもない。
が、細かなタスクの関連性などに神経がいって、例えば、そもそも午前中は効率が上がらないというのが、まるで「電話のせい」とか原因を「見えるもの」だけに限定してしまいがちである。
人間のサイクルから言って、午前中はわりと作業が捗らない、昼飯の後もそうだったりする。客観的時間と、生理的時間というかまあ仕事上での時間はかなり異なると考えるような事ができにくくなる。
統計元データを見てしまってから、そういう統計的観点からの考察を始めるという順序は、端的に言って「良くない」。ビッグデータの話ではないけども、「まるで見えているかのような資料を見せられると、「ここから」得られる知見から何かを導き出そうとしてしまう」。データドリブンな発想は、しかして、採取出来ない・管理出来ない情報についての推測を塞ぐ事がある。
・・・・・・まあ、そういう大局観を養う気がない人は多いんで、無いよりはマシ、とされやすいんですが。
強引な細分化を推し進めると、データ取得側でこういう事が起こる。
- 適当な配分処理が走る。
- 明確なもの以外の作業が減る。
どちらか、と言いたいが、両方同時に起こる。明確な時間が分かるものとかは優先的にピックアップされ記録される。そうでないものは適当に配分される。足し算として会うように、余裕の有る所に入れられる。
まあ、そういう誘導については、プロジェクトの純粋見積りと提案ベースの見積りを本来区分して割り切るべきだが、純粋見積りなんてアウトプット上不要なんで無視されたりする、なんかのせいで、見掛け上の数値づくりに合わせた作業をする、ビジネスがなりがちではある。
まあ、余裕があればオマケ機能の開発とか言って適当な遊びの仕事も出来る。が、例えばそれを「30%はそういうことで〜」と明確化すると、結局の所ハッキリした仕事についてコスく仕事するようになる。
無論、金にならない仕事をする意味は会社ではないが、金になる仕事の周りの付帯作業は金になる仕事の根拠足りうる所ではある。が、そういう投資をトップダウン的にしか行えない、というのは、それなりにリスクはある。
無論（繰り返すが）、ボトムアップ的な投資は、結局の所転職を目指す人達の支援に使われがちになる欠点もあるのだけど、それにしても、仕事のイメージが「やりがいのある」から「ねばらなないからやってる」になるのは、こういうちまちました所から始まっているんではないかとも思う。
こういう話は、個別から全体への最適化、というような話では抑えづらい。なんだかみんな前提として、「細かく細かくして知恵を使えば統計データだけで上手く仕事を回していける」というような思いがあるように思うのだけど。ビッグデータではないが、「それこそデータに表し辛いものをデータにする工数は半端でないし」、「やたら仕事割振りとかに介入が発生すればそれがまたコスト」である。
そして、さらに、「本来上として管理したいのはざっくりしたプロジェクト」なのに、いつの間にか「中の人の時間管理」が主体になる。それはそれであんまり意味がない。四半期毎にPLをまとめる必要はあるが、だからと言って、四半期の粒度を細かくして末端に管理させるのではなく、切り口はあくまでプロジェクト・タスクというふうにした方が良く、人員計画は正規社員・非正規社員の調整で適当にやれるのでメインに持ってくるべきではない。
粒度を細かくするにも限度があるし、管理しやすいものを管理していくと全くもって管理がずれて効率あがらんね、という事で。
