エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s

組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ

[turanukimaru]

マネージャーが思い切って「タスクをこなすよりもレビューをしろ」と言わないと解決しない問題。クリティカルパスのレビューはタスクとして割り振っても良い。あとペアプロはクソコードを防止してはくれないぞ。

[ledsun]

「ザ・ゴール」と一緒ですよね。ボトルネック以外のリソースの稼働率の高さはスループットに寄与しない、どころか悪影響を与える。

[genhou]

だから、稼働時間単位での工賃算出は嫌なんだよ。成果物に対する報酬額にしろ。発注者が欲しいのは成果物であって、エンジニアの稼働量ではなかろう。当方、フリーランスエンジニア。

[teasquare]

まんまサプライチェーンの制約理論では？

[kamezo]

編プロで末端管理職だった頃、部下から上がってるもののチェックとクライアントや外注先の対応で１日が終わり、夜しか自分の作業ができず、一度出社すると３日帰れなくなってたのを思い出した。もちろん辞めた。

[ikedas]

稼働率での管理は、管理スキルが低くても、それっぽく出来ちゃうから人気なのよね。タスクの切り分けとか平準化とか長期戦略の立案とか育成計画とかは、現場やメンバの資質を正しく理解していないと出来ないから。

[OrientHistory]

これは製造業の生産管理でも似た話を読んだことがあるなあ。

[napsucks]

CSMA/CDのようだ。利用率が増えるとコリジョンが増えてパフォーマンスが悪化する。

[kamm]

な、長い。余裕を持たせていると課題にすぐ取り掛かれる、余裕が無いスケジュールはむしろ遅れるって事かな

[sysjojo]

パソコン使ってるとき、CPU目一杯ブン回したら、余計に遅くなるってみんな知ってると思うけど、人ならブン回しても回ると思うIT屋の不思議。

[mohri]

“追求すべきは、フロー効率を高めてリードタイムを短くし、フローのスループットを高め続けること”

[okbm]

コメントにザ・ゴールって書いてたけど、まさしく

[diveintounlimit]

斜め読みしたけど、大企業的なマッチョな考え方だな

[pascal256]

人間のコンテキストスイッチはめちゃ重いしね。あと大体スケジューラの性能も期待出来ないからなー

[digo]

稼働率を下げて出来た待ち時間の有効利用法として、技術的負債の返済にあてる、ってのはどうだろう。

[syu-m-5151]

リソース効率とフロー効率のトレードオフについての不思議な関係

[zu2]

製造業と一緒だよね。 cf. https://brevis.exblog.jp/22236990/

[and_hyphen]

エンジニアに限らないよね。どこでもいえる

[twotiger]

コードレビューって非効率だよね。みんなやりたがらなくて、それで更に遅れがちになる

[REV]

ある程度忙しくなると、「スケジュールを他部署と調整」とか「行列客の対応」とか予想外（でもないか）の作業が増えて、要するに"自動車の交通量が一定を越えると渋滞モードに相転移し処理能力が低下"するのね。

[yoiIT]

人月商売の場合、能力が低くて120％稼働しないとタスクをこなせない人と、能力が高くて50％稼働でタスクこなせる人がいたときに、能力低い方が稼げたりする矛盾がある。それを解消しないとこの問題は無くならない。

[houyhnhm]

稼働率はKPIなんですが、KPIなんで、という話。高ければいいというものでもなく。

[m_h]

学びがある

[kondoly]

稼働時間は白い箱ではなくて主業務のほかに報告や確認、準備等あるのでは。移動時間を車で運転させるとほぼロスになるけど新幹線を使えばむしろ休憩になるみたいなタスクを埋める中身にもよるかと。

[NOV1975]

最後に書いてあるように、この手法を突き詰めると結果的に最適化されて稼働率が極限まで高まるかもしれない。依存性の高いつよつよエンジニアがいたりするとその人寝込むとフロー止まりそうだけど。

[kawabata100]

マルチタスクは生産性上がらない、個々人が余裕ある方が組織がよく回るって、どの本でも書かれてるんやけど。それぞれの会社でフル稼働と半稼働、2/3稼働どれがいいのか実験してみなはれ→自分の目で確かめろ

[ngsw]

Webエンジニアの稼働をあげるために、それらをまとめるPJやPdのMgr/リーダを増やしたくなるし、稼働は常にあげたくなるのでなにかしらの仕事が割り振られ、遅滞する(し「人手不足だ！」という採用活動に走りがち)

[kotetsu306]

単にレビュー工数が目標期間内の見積もり工数に入ってなかっただけでは。稼働率の高さは効率の良さから来てるんじゃなくて、タスクが溢れてるせい

[Flume]

1日3-4時間くらいしか働きたくないでござる。

[nabinno]

「ゴール -> リソース -> プロセス -> ルール」という順で全体を見渡してボトルネックを潰していくという話かなと。部分最適化はあかんよね。

[moromoro]

方針ちゃんと決めてBOM

[kita-tuba]

あるある

[assaulter]

TOC？

[makbai]

面白いが、分量が多いと内容理解が遠のく、ところから議論を始めた方が良いかも

[sabinezu]

これを理解できる経営者はごく一部でほとんどは強制されないとやらない。数値化も難しいしな。

[mventura]

分かりやすい。ガントチャートはマルチタスクしてると混乱する。人的リソースが見えないというか。カンバンに待ち表示があると滞りが見えて理解しやすそう。確かに製造業であるなと改めて。

[sonots]

フロー効率の話。古典「ザ・ゴール」でも話されている

[rin51]

「ザ・ゴール」で言ってた制約理論

[dorapon2000]

“待ち領域に最もチケットがたまっているステージが、カンバンボード全体のフローを遅くするボトルネックです。チームは常に、ボトルネックにたまったチケットを消化することを優先すべきなのです。”

[mogella]

オーバークックも稼働率を上げれば上げるほど料理の提供が遅くなっていく！