生産性を上げすぎるとメリットがデメリットを超えてしまう自体が発生するケース
https://gyazo.com/a660ff2370b70578295d092481b9a6fc
斡旋屋一家の隆盛
こちらの記事の興味深い箇所
CTOになったので、やってみたフルリモートワークでの実験的な施策の紹介
1時期、あるチームの機能開発タスクの生産を上げすぎてしまい、メリットがデメリットを超えてしまう自体が発生しました。
生産性を上げすぎた際の主なデメリット
対応できる件数が増えると質問が発生する件数が増え、チームリーダーへの負荷が高まる
チームリーダーへの負荷が高まると、本来やりたかった改善の施策が滞る
生産性を上げることでエンジニアの忙しさが解消されるのが好ましいが、単純に生産性向上を目標にしてしまうと 生産性を上げれば、上げるほど全体が忙しくなる構成になってしまう
また、機能開発自体は終わりの存在しないものなので、必要以上に生産性を上げ続けるメリットが少ない
利益を目的とする仕事に終わりはないため、生産性を上げ続けると、いつかは労働者の体の限界・メンタルの限界に到達する
メリット
チームの安定感の向上
メンバーの誰か一人に過度な負荷がかからない
デメリット
エンジニアチームにはメリットが大きいが、エンジニアチーム以外からの理解は必須になるので、相互の理解が深まった状態で進める必要がある。
意図的に「生産性を上げない」ことで優れた企業になるのミクロなエンジニアチーム版だ
生産性を上げ続けると、いつか労働者の体の限界に到達する
自分もエンジニアリーダーをやっていた時期があるので分かる。
タスクの依頼・レビュー・動作確認・スケジュール調整など、間接的な工数がリーダーにのしかかる事が多い。
高速でタスクをこなし、「次のタスクを下さい」と言ってくる人がいると頼もしいのだが、その人へのお世話コストもかかってしまう。
頻繁に「なんかタスク無いですか?」ときいて回るぐらい余裕のあるメンバーがいると小回りが効いて良い
というのも書いたことがあるが、トレードオフ
自分でタスクを見つけたりリファクタリングしてくれるなど、「お世話コストが低い人」だとこの問題が軽減される。
これ、体験したことない人には、「生産性上がったら最高だろ?何を言ってるんだ?」という事案になる。
生産性というか、タスク消化数・スピードという目に見えやすい指標に重点を置いてしまうと、全力で有害なアウトプットをしてしまう真面目な人になりかねない
「敢えて速度を落とすことで、ゴールが早くなる」
よくあるマラソンのたとえに近い
「急げ」と言うと遅くなる
まずは始めること、そして、継続することが重要です~低空飛行上等でいこう