なぜこの本を読んだのか
いくらかぶりの本をたくさん読みたい期が来たので最近はよく本を読んでいる。
普通にKindleなど電子書籍プラットフォームで普段は購入しているんだけど、ここ1年ぐらいaudible.co.jp を契約して使っている。
Audibleで配信されているタイトルは限られているのでもう読みたい本はあらかた読んでしまっていたので、次は普段読まなそうな本も読んでみることにした。
この本は2016年に発刊されたタイトルであるんだけど、SNSでフォローしているような身近なソフトウェアエンジニアが何人か薦めていたのもあって気になってはいた。
なぜこの本を読んでいなかったのか
正直この本は書影だけ見て誤った方向に釣られていた。全然中身も確認せずに
「なぜ、あなたの仕事は終わらないのか。それはスピードが遅いからである。マイクロソフト(権威)でWindows 95を開発した著者(権威)の教えに従い。この本を読んでハイスピードで仕事をこなす術を学び、ビジパとしてハイパフォーマンスを発揮して出世して年収を上げようスタンフォードマッキンゼーハーバード(語尾)」
——こんな読者向けだろうなとたかを括っていた。
そして僕は簡素な語彙や表現で読み砕きしやすいように編集されたビジネス新書とか自己啓発書みたいなジャンルを全体的に軽んじている傾向があるので、なんかこの本も同じジャンルに入れてしまってスルーしていたようだった。
どんな内容か
本書は著者が自身の経験から編み出した「ロケットスタート仕事術」を解説する本である。
ロケットスタート仕事術は要約すると「スケジュールの前半2割の期間で8割の進捗を出すのを目指すように時間を使うと見積りどうりに仕事が完了できる」というもので、前半に完了を寄せることをロケットスタートと表現しているようだ。
これはアジャイル開発が目指す所に似ているな〜というのが最初の感想だった。しかし本書の中にはアジャイル開発への参照はないし著者の経験は2000年以前のキャリアが中心になっているので、経験則から同じ地点に自力で辿りついているのだとしたら感心するばかりである。
アジャイル開発に近しい話をしているが本書では、組織やチーム・プロジェクトマネジメントの話ではなく個人のタスクの話に焦点が置かれている。そこが明確に区別できそうな点である。
またアジャイル開発の取り扱う範囲は非常に広いので、ここでは単に見積りや計画づくりの一部の具体的なプラクティスは似てくるよねという話をする。
スパイク
本書に出てくるテクニックで、見積りに自信がない時は調査期間を設け、その期間内に8割の完了を得られたら見積り期間を5倍にして確定する(得られなかったら見積りを修正する)。というものがある。
これはエクストリームプログラミングのスパイクと共通している。自分は見積りできる状態になるまで着手する、と理解している。
不確実性の高い作業から先に始める
リスクのありそうな作業は後回しにせずに前半に集中して「ロケットスタート」するという記述が登場する(反対にリスクの少ない作業は後半に落ち着いて行う)。
プロトタイプ
プロトタイプで目に見える成果を作ってフィードバックを得る話が出てくる。著者の場合はWindows 95のグラフィックシステムのデモがこれにあたるようだ、
まず終らせる
最初に顧客に価値を届けて、そこから改善をするというのが多数のバグがある状態で出荷されたWindows 95の成功譚として語られている。
アジャイルではないけど "Done is better than perfect" にある。ただこの言葉は有名だから単にネタ元なのかもしれない。
www.wired.com
遅延評価勉強法
6章では英語学習を例に「必要になった段階で実践するために学習する」という方法が解説されている。
これは僕と同世代の人(Web2.0ブームがあった頃)は心当たりがあるかもしれないけど遅延評価勉強法で示されている方法に近いと思う。
lukesilvia.hatenablog.com
ただ自分の中ではもう少し抽象的に理解していて物事にボトムアップで挑むかトップダウンで入るかという問題だと思っているけど。
以下の記事ではデメリットにも触れられていて確かにそうだと納得した
medium.com
僕としてはボトムアップもトップダウンも両方やればいいと思うけど、対象に興味持つ・関心を失う・飽きる・ダルいけどモチベ上げる。という部分のコントロールが一番難しいもんにゃんねぇ〜と日々思っている。
「ここで界王拳を発動します」
集中力の深さを「N倍界王拳を使う」というドラゴンボールZ比喩で説明している。
このため本書には「ここで20倍界王拳を使います」「まだ2倍界王拳でいいでしょう」など界王拳という言葉が100回ぐらい出てくる。
ビジネス書かと思ったらいきなり情緒的な文章が続いてちょっと面白い。「さぁ、はやくおめえらも超サイヤ人になって」
(c)集英社
シニアとジュニアの視点の違い
時間管理に失敗する例として何人かのジュニアなプログラマーのエピソードが出てくる。
それを読んでいたら考えさせられることがあったので書いてみる。
(前提として)自分で締切を決める→期限に間に合わず失敗。どの例もこんな感じだ。
僕らはみんな昔はジュニアやマジュニアだったので、この失敗する側の心理状況も理解できる。
それはジュニアの限られた経験の範囲の視点から見ると誠実な仕事の成果というのは「依頼された仕事を可能な限り短納期で実現する」という部分に重きが置かれていることにある。
なので楽観的見積りが採用され、悲観的見積りは不誠実であるか能力不足であるかのように受け取ってしまう。
一方シニアになってくると不確実性を減らして組織の計画をコントロールするのが誠実という価値観になってくる。
本書で出てくる見積りについての心構えはこのシニア視点寄りではあるけど、期間内の完了を担保することに最適化したらしたでデメリットもある。
見積り法則に「おぼろげながら浮かんできた工数の3倍」などの係数Nを持っているシニアは多い。本書に出てくる「2:8の法則」も係数の一種である。
問題は見積り→成否のフィードバックを繰替えすうちに期間が上振れして、見積り精度としては悪化していくが、しかし期限は守られるので下方修正するインセンティブがなくなるというものである。
こうなると仕事が終わるけど期待値より遅い。遅いけど計画どうりに進行することが良しである。「ベンダーがボタンを追加するのに2ヶ月かかります*1」という状況になる。
正しく完了する遅い仕事を改善するために、技術的負債解消に活路を見出し、クリーンアーキテクチャ、ドメイン駆動設計、リライトプロジェクトなどに時間が使われることもある。
ICとしては、もし見積り精度を正すための適切なフィードバックをもらう機会のない大企業のシニアだったら本人は順調に業務をこなしていると思い込んでいるけどまわりからの評価は仕事しない窓際おじさん(性別は問わない)枠になっているかもしれないし、スタートアップだったら短期計画のみ成功し製品や組織は成長しないという死を迎えるのかもしれない。
最終的な成否は結果をビジネスで判断することになるから、世の中で「ビジネスや経営が分かるエンジニア」が求められる背景にはこのような事情があるのではないか。知らんけど
著者がプログラマーとして仕事術を身に付け、独立した後にそれを方法論として確立するまでの過程が3章の実体験のエッセイパートで描かれる。
僕にとって著者の中島さんの印象は、ブログLife is beautiful*2の管理人であり、初代Node.jsのPromise実装にコールバック関数の修正パッチを送った直後にPromiseごと削除されたことで有名なmasuidriveさん*3と共同でPhotoShare *4というInstagramのようなSNSをiPhone3Gの頃に作っていた人で、最近はメルマガを発信しているからブログでの更新は見かけなく、あまり過去の経歴を追ってみたことがなく、インターネットより前の世代でグラフィカルインターフェイスに専門があるプログラマーなんだなぐらいに思っていたので、本書のストーリーで補足できてよかった。
Windows開発秘話といえばNTの闘うプログラマー *5であり、伝説のプログラマーといえばデビッド・カトラーだよなという印象であったが本書はリリースできないCairoに業を煮やして9xチームに移る話なので、闘うプログラマーと時間軸の違う別視点なのかと思うけどそういえば闘うプログラマーを読んだのも結構前なので内容をよく覚えてない。
Windows 95を開発するチームに在籍してGUIのプロトタイプのデモをしたりポインティング操作の開発を手掛けた。というような部分が描かれていた。
ちなみに本の帯の「マイクロソフト伝説のプログラマー」の伝説の部分についてはは「コードレビュー担当者の候補が側に居ない時は架空の清掃員・ジョーがレビューしたと書いておく」という行動を繰替えしていたのが伝説になっていた。とネタ明かしされていた。
サトシシについてはたまにウェブメディア上で編集されたインタビュー記事などで「Windows 95の父」「右クリックを作った」「ゲイツとやりあった」等の誇張表現を見かけてほんまかいなと思っていたが、本書で見られるエピソードは抑え目であることからあれはメディア側のPVハックか何かなんですかね(謎である)
