MS(Microsoft)も、最初から長時間労働を忌避していた訳ではない。
これまで述べたように、ジタバタしているプロジェクトに取り組み、再び機能するようにすることがMicrosoftでの数年に渡る私の任務だった。どの場合でも、チームメンバー達は、はるか彼方に遠ざかってしまった出荷期日に何とか到達せんと、死にもの狂いで週7日全部を長時間労働にあてていた。(中略)
私が信任のリーダーに就任した最初の日の最初の行動は、長時間労働に終止符を打つこと、そしてスケジュールが遅れた原因の究明に乗り出すことに決まっていた。私は夕暮れにさしかかると廊下を回り、人々を叩き出す。「さぁ、帰った、帰った。余暇を楽しんできてくれ」。
プログラマ達はこう抗議する。「帰れないよ。この機能が遅れてるんだ」。
「かまわないさ」私は言う。「チーム全体が１年近くも異常としか言いようのない時間働いてきたんだ。それだけ努力してきてもプロジェクトはいつもスケジュールに遅れてきたわけだろう。このプロジェクトを調整するのは長時間労働じゃないってことだ。何か根本的な間違いがあるんだよ。見つけて修正しなくちゃならないようなね。長時間労働を続けたってその問題を見つける役には立たないんだ。家へ帰ってゆっくり休んでくれ。明日はまず問題を探すことから始めよう。」(中略)
しかしそれから数週間が過ぎると、私は本書のここまで７つの章で説明してきたすべての戦略をプロジェクトに適用していた。(中略)１，２ヶ月たいへんな思いをして、チームは最初のマイルストーンにたどりついた。予定どおりにである。しかも、週に80時間も働かなかったのにだ。彼らはやっと勝利を手に入れたのである。続く数ヶ月間、新しい作業技術が習慣となっていくにつれ、それらのマイルストーンへの到達はますます容易なものになっていったのである」。
デバッギング ザ デベロップメント プロセス―理想的な開発工程を目指して (マイクロソフトプレスシリーズ) Steve Maguire
より抜粋
聡明な人々による改善・改革の積み重ね。
