組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
夢と色でできていない @0721_summer 社長からの全体周知メールで、「今日から外を移動するときはマスクを二重につけることにしました（ウイルスカット率は99%×99%＝98.01%）」って書いてあって、若干下がってるのが草だった。自分で書いてて何かおかしいと思わなかったのか。 2021-01-20 12:20:19
Q．29歳のシステムエンジニア（SE）です。先月から休日出勤続きで、今月も平日残業はもちろん、休日出勤が多くなりそうです。顧客に提示した見積もりと一致する受注プロジェクトなら残業はないはずだと不思議に思っています。要員計画は、月20日で160時間働く前提になっています。入社以来、全てのプロジェクトにおいて残業がありました。SEやプログラマーなどITエンジニアは残業が多いと割り切っていますが、つらいときがあります。残業が常態化している状態は、明らかにおかしいです。 残念ながら質問にあるプロジェクトは、最初から残業が当然という要員計画です。1人月を「1日8時間、月20日で160時間働く前提」としています。月の就労日数が平均20日だとすると、これでは順調なプロジェクトであっても必ず残業が発生します。 さらに、要件定義の見直しによる仕様変更やシステムトラブルが重なったときは、過重労働（長時間残業）
ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。 プロジェクトチームを高速道路を走る車と考えてみよう。交通密度（人的リソースの利用率）が高いと、小さな衝突事故が車の流れにすぐ影響する。車の流れを大幅に遅らせてしまうか、完全に止めてしまう。交通密度が100％でなくてもこうした影響がある。すなわち、道路の利用率が70％以上に達すると交通渋滞が発生し始める。 ITプロジェクトリソースも同様だ。通常、担当者を働かせすぎてしまうと逆効果となり、パフォーマンスが下がってミスが増えてしまう。Gartnerの調査では、
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく｜mtx2s
社長からの全体メールで「マスクを二重につけることにしました（ウイルスカット率は99%×99%＝98.01%）」と届いた
ITエンジニアはつらいよ、「1人月160時間」の要員計画では常に残業が発生
ITプロジェクトチームの過負荷を防ぐためにやるべき4つのこと