[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます
適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

855users がブックマーク コメント 84

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

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

855 users note.com/mtx2s

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページ

記事へのコメント84

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

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

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

その他
teasquare
まんまサプライチェーンの制約理論では?

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

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

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

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

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

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

その他
lycolia
製造以外にも工数を割ればいいと思うが稼働率をKPIにすると開発者の負荷が厳しくなったり、品質がおざなりになる気はする。ここにはないが危険稼働率という言葉もあるようだ

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

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

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

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

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

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

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

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

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

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

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

その他
m_h
学びがある

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

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

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

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

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

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

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

その他
kita-tuba
あるある

その他
assaulter
TOC?

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

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

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

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

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

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

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

その他
sugawara1991
単純に物量で規定されたスループット指標を追求すると応答レイテンシと両立しがたくなる問題

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー
アプリのスクリーンショット
いまの話題をアプリでチェック!
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

usersに達しました!

さんが1番目にブックマークした記事「エンジニアの稼働...」が注目されています。

気持ちをシェアしよう

ツイートする

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

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

ブックマークしたユーザー

  • igatea2025年03月27日 igatea
  • nana_iwamoto2025年02月20日 nana_iwamoto
  • lycolia2024年09月12日 lycolia
  • Ran3502024年07月30日 Ran350
  • chibahiro2024年05月01日 chibahiro
  • John_Kawanishi2024年04月02日 John_Kawanishi
  • chuwb2024年02月27日 chuwb
  • igrc2024年02月14日 igrc
  • youko032024年02月09日 youko03
  • hamaco2023年11月04日 hamaco
  • takashabe2023年10月30日 takashabe
  • iseebi2023年10月14日 iseebi
  • rockname2023年09月08日 rockname
  • kasahi2023年08月21日 kasahi
  • kyo_ago2023年08月02日 kyo_ago
  • techtech05212023年07月30日 techtech0521
  • mohri2023年07月15日 mohri
  • vine_hate2023年07月14日 vine_hate
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

同じサイトの新着

同じサイトの新着をもっと読む

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /