読書日記　『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』

タイトルに惹かれて、少し古い本ですが、読みました。私が、遅くとも４０代の時にこの考え方に出会えたなら、私のエンジニア人生も大きく変わったかもしれないと思った内容です。本当に素晴らしい内容なので、全ての分野のエンジニアの方は必読の一冊ではないでしょうか。

では、なぜそう思ったか、紹介したいと思います。

 

☆タイトルと著者について

---

わかりやすいタイトルで、エンジニアは時間に追われているのが常でが、どういったノウハウがあるのか気になった。著者が米マイクロソフト本社でWindows95の開発に携わった伝説のプログラマーらしいが、日本人でそのような有名な人がいたのか？興味が出てきました。

エピソード；WINDOWS95開発に秘められたドラマ

Windows 95開発にあたり、チームが2つあり、博士が何人もいる天才集団”カイロ”と対照的な”シカゴ”というグループが競っていました。カイログループは、アーキテクチャと呼ばれる設計の基礎から構築することを始めていましたが、いくら時間があっても開発完了の見通しがつかない状態でした。

一方、3,500個のバグがありながら全体イメージがつく試作品として、とにかく動くものをシカゴグループは作っていました。双方の主張と抗争が激しくなった際、シカゴグループの代表として中島さんがビルゲイツの前でプレゼンをすることによって、どちらを採用するか決着をつけることになりました。

中島さんのプレゼンを見たあと、１時間もしない間に最終決定の場で、開口一番、「カイロプロジェクトはキャンセルする」とビルゲイツが言いました。カイロプロジェクトキャンセル、それはすなわち、4年にわたってカイロが開発していたOSをなかったものにするという意味です。その一瞬で、400人を超える大所帯のカイロを解散することを決めたのです。“光速”と言っても過言ではない迅速な意思決定を経て、中島さんグループのOSがWINDOWS 95として世にリリースされました。まさにドラマです。

このエピソードに触れるだけでもこの本を読む価値はあると思います。

 

☆時間を制するために

---

全体像を把握する

パソコンや携帯電話で、よくアップデートの推奨がされるが、なんで頻繁に？と疑問をもっていたが、この本を読むと理由が少しわかりました。

Windows95の開発をしていたときは、ともかくスピードが重視されていた。リリース前には3500個ものバグがあったという。しかし、予定通りに発売するため、バグを残したまま発売に至った。ソフト開発の場合、修正したプログラムコードによってまた新たなバグが発生するために、時間をかけて修正しても、バグの数は減らず、開発時間とバグの数は飽和するため、それゆえ、先にリリースし、発売後に修正を続けるというのが、ソフト屋さんの常識だそうです。

多少のバグを残したままでも「プロトタイプ(試作品)」を制作すると、周りの人も全体のイメージを固め、企画を通りやすくなるし、設計上では気付かないミスが発生した場合の、対応が早くなるそうです。

覚えておくべきことは、細かいことは気にせず、全体像を描いた方が無駄なプロセスを省くことができる。

☆ロケットスタート時間術

---

スタートダッシュとマルチタスク禁止が鍵

この本は単なるノウハウ本ではありません。全体を通して、「自分のタスクを必ず期限内に終わらせる」という強い思いが理解できれば、あとの部分は、自分が採用するかどうかは二の次だと思います。

まずはスケジューリングの段階で、指定された時間の2割を使って仕事に全力で取り組み、全体にどれだけの時間がかかるのかを調査する。次に、仕事が終わらない原因の9割を占める「締め切り間際のラストスパート」を防ぐため、一気にスタートダッシュをかける。もしも、10日で仕上げるタスクであれば、2割に当たる2日間で8割終わらせるつもりで取り掛かる。

たとえば、最初の2日間は最大の能力を発揮させるように集中する。集中力を上げるには、マルチタスクを放棄する必要がある。事例として、仕事中にメールに気を取られると、メインの仕事の効率が落ちてしまう。やるべき仕事は、メールを早く返すことではなく、仕事を終わらせることだ。よって、最初時間はメールや電話を無視し、可能な限り会議への出席も避ける。さらに、脳の疲れを取るためは、適度な仮眠が効果的で、数十分の昼寝をし、自分に合った仮眠時間を探すことを著者は薦めている。このように、ロケットスタート時間術の真髄は、集中力を保ち、全体をみわたせる、「余裕」を生み出すことにある。