できる人ほど、すぐ手を動かさない
目次
仕事が速い人は、手を動かすのも速い。ずっとそう思っていました。
でも、世界トップクラスのエンジニアを間近で見た人の記録を読むと、話が逆でした。彼らは、着手が遅い。正確に言うと、打ち始める前に止まっている時間が長い。
米マイクロソフトの牛尾剛さんは、『世界一流エンジニアの思考法』でこう書いています。一流は頭の回転が速いから速いのではない。手を動かす前に、事実を確かめ、仮説を持ってから動くから速い。
私はここで一度、自分の仕事を思い返しました。詰まったとき、私はまず「とりあえず」何かを試していた。設定を変える。コードを直す。検索して出てきたものを貼る。動けば安心する。
その安心こそが、遅さの正体でした。
「速い人」ほど、いきなり打たない
牛尾さんの同僚に、ポールという人がいます。
牛尾さんのプログラムが動かず、本人はあれこれ試して直そうとしていた。ポールは違いました。いきなり手を動かさない。最初のログを1つだけ見て、頭の中で仮説を立て、それを確かめるクエリを1つだけ書く。それで根本原因をズバリ指し示した。
たとえば、料理で味が決まらないとき。塩、砂糖、酢を次々足していけば、いつか合うかもしれません。でも何が効いたのかはわからない。次も同じ手間がかかります。ポールがやったのは、まず一口なめて「酸味が足りない」と当たりをつけ、酢だけを足すことです。
牛尾さんは、この思いつきの試行錯誤を「悪」と言い切っています。強い言葉です。ただ、理由を聞くと腑に落ちました。あてずっぽうは時間を食う。おまけに、何も学べない。だから次も同じ場所でつまずく。
ここに、生産性の勘違いがあります。
私たちは速さを「作業量」で測りがちです。たくさん打った、たくさん試した、だから進んだ、と。でも実際に効いているのは、やり直しの少なさです。手戻りが1回減れば、その分まるごと速くなる。着手前の数分は、あとで消える数時間を買っているんです。
しかも手戻りは、足し算では効きません。掛け算で効きます。方向がずれたまま2時間進めば、失うのはその2時間だけではない。ずれに気づいて戻り、正しい道で作り直す時間まで乗ってきます。
だから、ずれるほど後半が重くなる。着手前の見立ては、この掛け算のスイッチを最初に切る作業です。
できるプログラマとできないプログラマの差は25倍あると言われます。指の速さで25倍にはなりません。差がつくのは、無駄なやり直しをどれだけ生まないかです。
理解は「あとで」効いてくる
もう1つ、意外だったこと。
一流ほど、理解に時間をかけます。しかも「頭がいいから速く理解できる」のではない。牛尾さんは、どんなに優秀な人でも理解には時間がかかる、と繰り返します。
たとえば、牛尾さんの若い同僚2人は、新しいプロジェクトの複雑な構造をつかむために、社内の解説ビデオを10回は見ていた。わからないところで止め、メモを取り、また戻る。
すぐに書き始めれば速そうに見えます。でも、構造があいまいなまま書いたコードは、あとでほどけて手戻りになります。
牛尾さんは「理解」を3つで定義しています。人に説明できる。何も見ずに使える。別の場面に応用できる。この3つがそろって初めて、本当に理解した状態です。検索して貼りつけただけの知識は、どれも満たしていません。
面白いのは、記憶にも同じことが起きる点です。牛尾さんは、記憶力が悪いと感じる原因の多くは「理解の浅さ」だと言います。構造をつかんで自分の言葉にできたものは、何度も調べ直さずに済む。
逆に、浅いまま覚えたものは、そのつど検索に戻ります。この「調べ直し」も、小さな手戻りです。理解は、未来の自分が同じことを引き直す回数を減らしてくれます。
だから一流は、コードを書く前に短い設計メモを書きます。デザインドキュメントと呼ばれるものです。数ページで、何をどうつくるか、なぜその形かを言葉にする。書いているうちに、自分の理解の穴が見える。穴は、手を動かす前に埋めたほうが安い。
ここで1つ、条件をつけます。
理解に投資するとは、情報を無限に集めることではありません。むしろ逆です。牛尾さんの方法は、事実を1つ確かめて仮説を立てる、という軽いものです。
全部を調べ尽くしてから動くのは、別の遅さを生みます。狙うのは網羅ではなく、動く前に「筋の良い見立て」を1つ持つことです。
手を動かす前に、狙いを合わせる
理解を優先する、と聞くと、地味で遅い働き方に思えるかもしれません。でも実務では、ほんの小さな確認から始まります。
『Google流 疲れない働き方』で、ピョートル・フェリークス・グジバチさんはこう勧めています。上司や顧客から依頼が来たとき、すぐ動き出さない。まず「いつまでに、何がほしいのか」を確認する。
これは着手前の理解と、同じ話です。
たとえば、資料を頼まれてすぐ作り始める。3時間かけて仕上げて出すと、「そこまでは要らなかった」と言われる。よくある光景です。求められている水準を先に合わせておけば、この3時間はまるごと消えずに済みました。
もう少し視野を広げても、同じ構造が見えます。
『どんな業界でも記録的な成果を出す人の仕事力』で、伊藤嘉明さんは「小さな話」の前に「大きな絵」を見ろと言います。目の前の製品や競合を細かく比べる前に、そもそも何が起きているのかを俯瞰する。
全体の見立てがずれたまま細部を詰めても、あとで全部やり直しになります。
個人の仕事も同じです。タスクに飛びつく前に「これは何のためか」を一度上から眺めると、進む方向を間違えにくい。
急がば回れ、という言葉があります。精神論に聞こえます。でも中身は、手戻りコストの引き算です。回った分より、やり直さずに済んだ分のほうが大きい。それだけの、そろばんの話でした。
「わかったつもり」を疑う
では、明日から何を変えるか。
誤解：詰まったら、まず何か試してみる → その一手が当たる保証はありません。外れたら、また別の一手。試行錯誤は動いている感じがするだけで、時間だけが減ります。
正しいアプローチ：手を止めて、事実を1つ確認する → ログ、エラー文、依頼の背景。何でもいい、確かな事実を1つ拾う。そこから「たぶんこうだ」を1つ立てて、それだけを試す。
もう1つ。
誤解：早く成果を出すため、理解は後回しにする → 浅いまま進むと、応用が利かず、同じ壁で毎回止まります。結局それが一番遅い。
正しいアプローチ：着手前に、人へ一言で説明できるか自問する → 説明できないなら、まだ理解していない。書き始める前に、設計メモを数行だけ書いてみる。穴が見えたら、そこが今日の理解すべき場所です。
行動に落とすなら、2つでいい。
1つ、依頼を受けたら着手の前に「求められている水準と期限」を一言だけ確認する。2つ、詰まったら「試す」より先に、「事実を1つ、仮説を1つ」紙に書く。
どちらも数分です。その数分が、あとの数時間を守ります。
おわりに
速い人は、速く打つ人ではありません。やり直さない人です。
理解にかけた時間は、消えたように見えて、手戻りが減るという形でこっそり返ってきます。だから、まず小さく試す前に、まず正しく理解する。
急がば回れは、気合ではなく、引き算でした。
この記事で参考にした本
『世界一流エンジニアの思考法』牛尾剛 → 試行錯誤は悪、事実を1つ確かめて仮説を立てる、理解の3要素。着手前に止まる働き方の原典です。
『Google流 疲れない働き方』ピョートル・フェリークス・グジバチ → 依頼に即応せず「いつまでに、何を」を先に確認する。着手前の要件合わせが手戻りを防ぐという実務の型。
『どんな業界でも記録的な成果を出す人の仕事力』伊藤嘉明 → 小さな話の前に大きな絵を見る。全体の見立てがずれると、細部ごと作り直しになる。
合わせて読みたい
「とりあえずやってみよう」で1日が終わる人へ 着手の速さと成果は別物です。この記事の「まず理解してから動く」を、日々の一歩目にどう落とすかがつかめます。
『400のプロジェクトを同時に進める 佐藤オオキのスピード仕事術』──「スピードを上げれば質が落ちる」という常識を覆す、デザイナーが実証した仕事の本質 速さと質はトレードオフではない。やり直しを減らすことが本当の速さだという本記事の結論を、別の職種から裏づけてくれます。
ピョートル・フェリークス・グジバチ『Google流 疲れない働き方』── 頑張っているのに疲れ果てるあなたへ 本記事で引いた「即応する前に期待値を合わせる」の元になった1冊。集中とエネルギーの設計まで通して読めます。