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