「仕事が速い人はテクニックを持っている」。速さの話は、たいていここから始まります。ショートカットキー、タスク管理術、時短ツール。手数を増やせば速くなる、と。
ぼくもそう信じて10年弱、効率と生産性を追いかけてきました。ぐうたらなので、怠けるために誰よりも効率を追う。そういう人格です。
ところが、上司から「明日から3倍の速さで仕事しろ」と言われた年。本当に3倍速を達成したとき、効いたのはテクニックではありませんでした。効いたのは、手が止まっている時間を消したことです。
そして3倍速を手に入れた2年後、ぼくは土日にぶっ倒れました。速さには、はっきりと副作用があります。
この記事は、速さの正体・速くする方法・速さの代償・10年後の再定義を一本にまとめた記録です。先に結論を書くと、速さは上げるものではなく、使いこなすものでした。
「仕事のスピード」の正体——何が速さを決めているのか#
仕事のスピードは単一の能力ではありません。着手・処理・はまらない力の3つに分解でき、その下にコスト意識という土台が敷かれています。
速さは3つに分解できる#
仕事の速さを決めているのは、次の3つです。
- 着手の速さ やると決めてから手が動き出すまでの時間
- 処理の速さ 手が動いている間に出るアウトプットの量
- はまらない力 手が止まっている時間の短さ
世に出回る時短テクニックのほとんどは、2番だけを扱っています。タイピングを速くする、ショートカットを覚える、テンプレートを用意する。どれも「手が動いている間」の話です。
しかし仕事の総時間を左右するのは、1番と3番のほうがはるかに大きい。ぼくの実感では、この2つで7割は決まります。
着手の速さについては、行動が早い人と遅い人に4つの決定的な違いがあります。
- なりたい姿 早い人は超具体的、遅い人はぼんやりか、そもそも無い
- 考える範囲 早い人は無駄がない、遅い人は無駄に広い
- 判断の視野 早い人は広い、遅い人は狭い
- 覚悟の決め 早い人は早い、遅い人は遅い
ここで驚いたのは、4つのうち3つが「考え方」の話だという点です。手を動かす速さは1つも入っていません。行動の遅い人は、どうにもならないこと、つまり存在しない答えをいつまでも探し続けています。
コスト意識という土台#
3つの速さを底上げするのは、テクニックではなくコスト意識です。自分のアウトプットにいくらかかっているかを知ると、時間の使い方が変わります。
月収20万円の人が1ヶ月に20営業日働くとして、1日あたり1万円。1日8時間なら時給1250円です。
この時給で計算すると、10分で書いた日報メールは約200円になります。10人を集めた30分のディスカッションは6250円。作成1時間＋レビュー0.5時間×2回の設計資料なら2500円です。
なんだそのくらいか、と思った方もいるでしょう。ところが、この計算は正しくありません。
もしその人が月80万円で客先に派遣されているなら、客から見た時給は5000円です。日報メールは200円ではなく800円になります。
10人の会議は6250円ではなく25000円。のべ2時間の設計資料は2500円ではなく10000円です。8時間かけた設計書なら、コストは40000円に達します。
差額の60万円は、管理部門の人員や自社システム、不動産や備品、研修や人材募集に回っています。つまり自分の月収を基準にすると、自分のコストを4分の1に見誤ります。
この計算をやるまで、ぼくは会議の30分を「30分」としか認識していませんでした。25000円と言われた瞬間、「念のため呼んだ」系の参加者を削る手が動きます。
コアメンバー3人だけにすればコストは3分の1。速さの動機は、根性ではなく金額から生まれました。
なぜあなたの仕事は速くならないのか#
仕事が速くならない最大の理由は、テクニックの不足ではありません。手が止まっている時間、つまり「はまっている」時間が長いからです。
原因は手数ではなく「はまる時間」#
驚くべき速度で高い品質のアウトプットを出し続ける人には、共通点が1つあります。「はまる」時間が極端に短いこと。
この見方は、2009年に小野和俊さんが書いた「プログラマーの開発速度は『はまる』時間の長さで決まる」から借りています。ぼくは大学院でソフトウェア工学を研究していました。
ソフトウェア工学とは、ソフトウェアをいかに上手く・早く・安く作るかを扱う学問です。品質・納期・コストを追う手法とプロセスの研究、と言い換えてもいい。
コンサルタントの仕事を始めてから、あることに気づきました。コンサル仕事のベストプラクティスと、ソフトウェア開発のアイデアがよく似ているのです。先輩からもらったアドバイスの多くが「なんか聞いたことある」でした。
はまらない状態がどれほど強いかは、体験でしか説明できません。平成28年、某クライアントのデジタル戦略策定プロジェクトでのこと。役員への最終報告の直前に、知人でプロジェクトリーダーのA氏からレスキュー隊として呼ばれました。
聞いたのは、大体の経緯と方向性、過去資料のありかだけ。それも口頭です。あとは2、3日で検討の全体像と、個別論点における示唆やアクションプランを整理しきりました。その間、ほぼまったく手が止まりません。資料を書き続ける感じでした。
では、人はどこで「はまる」のか。知的生産の現場では、次の6つに傾向が集中します。
- 言葉の定義が不適切 用語の解釈がずれ、各所で誤解と手戻りが発生する
- 「とりあえず」書いた資料 後工程で必ず混乱の原因になり、修正コストが跳ね上がる
- 「何かがおかしい」まま続行 違和感の直感はたいてい当たっている
- フレームワークに振り回される 当たりを付ける前に型へ当てはめようとして進まない
- フレームワークの理解が浅い 「つくり」を知らないので他の課題に応用が効かない
- アセットの存在を知らない 既に議論され尽くしたことを一から作り直す
この6つを並べて気づくことがあります。全部、作業を始める前と、違和感を覚えた瞬間に潰せるものだという点です。タイピングを速くしても、1つも解決しません。
特に4番は根深い。頭で考えて当たりを付ける前にフレームワークを引っ張り出し、5ミリ方眼紙の前で腕を組んで首を傾げるパターンです。
フレームワークが本領を発揮するのは、仮説を持っている人に対してのみ。仮説のない人にとっては、検討速度を遅くする混乱要因でしかありません。
集中の阻害要因#
はまる時間を短くする直接の手段は、集中力です。ぼくが実験した限り、効いたのは環境を削ることと、集中していない自分に気づくことでした。
思考の集中力を高めるために、ぼくはまず3つの煩悩源を叩き切ります。
- 五感を切る 視覚と聴覚から、動くものと気になる音を消す
- ネットを切る スマホは見える場所に置いておくだけで無意識に集中力を奪う
- 時間を切る 「このトピックはXX分」と決め、時間がきた時点の結論を成果物にする
3番目には裏づけがあります。二八の法則、つまり8割の成果は2割の労力で生まれるという経験則です。
思考もほぼ同じで、最初の2割の時間でゴリッと考えた結果が、多くの場合その時点の最善解になっています。残りの8割で解が変わるなら、それは単なるインプット不足。
環境を削る一方で、自分の行動そのものを操作する実験もしました。認知行動療法（CBT）のアイデアを使った「儀式化」を、約2ヶ月間検証したものです。集中している時の行動を意図的に取り、集中していない時の行動を意図的にやめる。それだけ。
結果、効果があったのは「紙に手書きで文字や図を描く」と「ホワイトボードで人と議論する」の2つだけでした。姿勢や目線、頭の中の整理状況は、集中の結果であって原因ではなかったのです。ここは完全に見込み違いでした。
むしろ効いたのは逆方向、集中していない時の行動リストのほうです。極端なマルチタスク、頻繁なメールチェック、歯を噛み締める、首がこわばる。ヒゲを触り抜く、片ひじをつく、足を組む、呼吸が浅い、キーボードの打鍵音がいつもより大きい。
目の前の仕事をつまらない、意味がないと感じている自分に気づいたときも同じです。これらが出た瞬間に「あ、今集中していない」と客観視できるようになりました。おかげで、集中しないままダラダラ過ごす時間がほぼ消えています。
ただし限界もあります。本当に疲れている時、精神が消耗している時には効きません。集中力の維持に必要なリソースがそもそも足りない状態を、気持ちで埋めることはできないのです。
実際に3倍速にした方法——実験の記録#
3倍速は魔法ではなく、基本技の組み合わせでした。段取り・ベストプラクティス・合意プロセスの3段で、2倍→2.5倍→3倍と積み上げています。
3倍速の核心手法#
3倍速の正体は、次の3段積みです。きっかけは上司の一言でした。夕方過ぎ、とあるプロジェクトの現場で「明日から今の3倍の速さで仕事してよ」と。冗談きついっす、と返しても「NAEくんならできるって」で会話は終わりました。
業務命令なのでやるしかありません。むげに「無理っす」と言うのもかっこ悪い。仕事の早さを3倍にするとは、締め切りを1/3にするということ。やり方を変えるしかないと腹をくくりました。
- 段取りを考え尽くす 解決すべき課題（イシュー）とゴール、そこへ向かうアプローチの2点を先に決める
- ベストプラクティスを愚直に実行する 自分のこだわりが成果とスピードに貢献しないなら即座に捨てる
- コミュニケーション・オーバーヘッドを極小化する キーパーソンをつかまえ、その時点版の資料でフィードバックをもらう
1番で2倍、2番で2.5倍、3番で3倍。積み上げの内訳はこうなります。
1番のポイントは、最初は前提つきの仮説で構わないという点です。仕事を始める段階ですべてを見通すのは無理ですから、間違っていたらその時点で方向修正すればいい。
合言葉は「すべての仕事には意味がある」ではありません。「意味がある仕事しかしてはいけない」という勢いで組み立てます。
2番で効果が高かったのは、アウトプットする前に頭の中でイメージを精緻化しておくことでした。タイピングや作図は、頭で考えるスピードに比べるときわめて遅い。頭の中で固め切ってから一発で作るだけで、全体の時間が縮みます。
そして3番。これが一番効きました。パレートの法則は仕事効率でも成り立ちます。品質の80%は20%の時間で出るのです。20%くらいの時点で大筋の合意が取れれば、残り80%の時間は省略できます。
さらに、状況が許せば承認フローそのものをすっ飛ばします。メンバー合意、リーダー合意、ディレクター合意という段取りがあるなら、早い段階で直接ディレクターに持っていく。
失礼であろうが、結果がついてくればどうせ誰も文句を言いません。神経を図太く持って当たりに行くだけです。
時間の設計#
手法だけでは3倍速は続きません。時間そのものを設計対象にして、はじめてスピードが定常運転になります。
実をいうと、ぼくは時間管理が下手くそでした。時間を管理する≒スケジュールを立てる、ということが具体的にイメージできなかったのです。「30分でこれをやる」と言われても、「30分って何センチ？」という変換をしないと肌感覚で理解できない。
理由をひもといて行き着いたのが、自分が右脳優位だからでは、という仮説でした。うさうさ脳診断でいう「うう脳」、インプットもアウトプットも右脳優位です。診断自体はオカルトかもしれませんが、ぼくには納得のいく裏づけでした。
そんなぼくを救ったのが、『すべては「単純に!」でうまくいく』（2003年出版）にあった一節です。
「時間を、箱庭のようにデザインしよう」
持ち時間を1つのスペースとして認識し、分割して3Dの時間割を作ります。庭のこっちは30分後、あっちは1時間後、というように。一本の時間軸で済む人には余計に面倒でしょうが、ぼくにはこちらのほうが考えやすかったのです。
箱庭の各ステージには、将来の自分を配役していきます。30分後の空間にいる自分はどこにいて、何が終わっていて、どんな気分なのか。ToDo管理がやること（How）を扱うのに対し、配役は目指す状態（What）に注目します。
この配役は「未来の自分に仕事を振る」という行いと同じです。未来の自分を他人だと思って、指示を出す。すると今の自分がやるべきことは、指示出しだけになります。
面白いのは、指示を出そうとすると自分の段取りの穴が見えることです。「15:00までに例のプレゼン資料の枠だけ作っといて。ストーリーはよしなに組んどいて」では、30分後の自分は動けません。よしなにって何だよ具体的に言えよ、となります。
仕事は本来、SIPOCがはっきりしていないと成立しません。前工程の人（Supplier）から何か（Input）を受け取る。処理して（Process）、後工程の人（Customer）に成果物（Output）を渡す。そういう流れです。
事前条件と事後条件が揃っていない指示は、指示の体をなしていません。相手が未来の自分でよかった、と何度も思いました。
ただし注意点が1つ。単なる先送りにしないことです。タスクは全体の作業計画やマイルストンと紐付いているので、身勝手に送っているといつのまにか〆切りに囲まれます。
最後に、地味ですが効いたのがToDoリストの置き場所です。ぼくが試した結果のベスト3はこうなりました。
- 外付けディスプレイ 8インチのAndroidタブレットをUSB接続してサブディスプレイ化する
- A5ノート 常に目に入るが、フロー型の使い方の中にストック型のToDoページが埋もれる
- PCのメインディスプレイ ウィンドウ切り替えが面倒で、だんだん見なくなる
A5ノートは完全に失敗でした。付箋を貼り、背表紙側に書き、いろいろ工夫しましたが駄目。「ToDoリストが見たい！今！」というときにページを探してめくるハードルが、チョモランマより高く感じたのです。そのくらいぼくは面倒くさがりです。
1位の外付けディスプレイにも制約はあります。一定のスペースが要るので、カフェや狭いデスクでは使えません。ToDoの内容が常時オープンになるため、セキュリティへの配慮も必要になります。
なお、ここまでの方法論はほぼ自前で組み立てたものでした。後から「実践！ タイムマネジメント研修」を読んで、自分の考えた方法論以上にキレイに言語化されているのを見て驚きました。巨人の肩の上に立てていなかったわけです。
特に刺さったのが「仕事がノッてくるまで30分かかる」は思い込みだ、という指摘。業務改善コンサルタントが実際に観察すると、はじめの5分くらいでも十分に捗っているのだそうです。たかが5分、されど5分。積み重ねれば1時間分の仕事になります。
速さの副作用と限界——3倍速のその後#
3倍速を手に入れると、そのぶん確実に何かを失います。ぼくが払った代償は、期待値の暴走と、体調不良と、環境への過剰最適化でした。
3つのデメリット#
3倍速の副作用は3つあります。自分への期待値、周囲からの期待値、そして身体です。
- 自分への期待値が上がりすぎる 「本気を出せば3倍速で走れる」という自己認識が生まれる
- 周囲からの期待値が上がりすぎる 血反吐を吐いて達成した期限が、相手の当たり前の期限になる
- やりすぎると倒れる 界王拳と同じ、時間限定で戦闘力をブーストするドーピング技
1番の罠は、自分の状態によっては3倍速が難しいという事実にあります。風邪などの物理的な不調、気分の落ち込みなどの心理的な不調。どうあがいても届かない日はあるのです。
にもかかわらず「自分はいつでも3倍速できる」と思い込んでいるとどうなるか。自己認識と実際のパフォーマンスのギャップで、必要以上にヘコみます。ただでさえ体調不良で凹んでいるところに、追い打ちがかかるのは結構つらい。
2番はもっと厄介です。仕事を振ったほうは、アウトプットと期限しか見ていません。期限より前倒しでブツが出てくれば、「そっかこのくらいのスパンでできるのか」と安易に認識されます。振られた方が血反吐を吐いていたとしても、です。
すると、血反吐を吐いて達成した期限が相手の当たり前になり、同じ振られ方が今後末永く続きます。3倍速にするだけで期待値コントロールをおろそかにすると、消耗するのは自分だけ。
3番は身をもって学びました。手持ち案件の佳境が重なって「常時3倍速」を1週間続けた結果、体調不良に見舞われて土日ぶっ倒れていたのです。1日8時間、絶え間なく3倍速で走り続けるのは無理でした。
筋トレと同じで、修行として基礎体力が鍛えられる側面はあります。しかしオーバーワークはNG。マラソンと同じく、ペースを保つことが長い目では効きます。
過剰最適化のライン#
速さのもう1つの代償が過剰最適化です。目の前の環境に自分を最適化しすぎると、環境が変わった瞬間に役立たずになります。
最適化とは、使っているツールや方法論に特化した効率化手法を適用すること。ショートカットキーを覚える、在庫管理アプリの使い方に習熟する、愛用のカバンに特化した収納を決める。
効率を求めるうえでは、最適化はきわめて強い方法です。ショートカットキーなしでExcelを使うなんて、遅すぎて考えられません。
しかし最適化には、ツールや方法論への依存という側面があります。ぼくの会社貸与PCはWindows機で、プライベートのPCはChromebookです。OSもアプリも違うので、仕事で身につけた効率化がまったく流用できませんでした。
Excelのショートカットキーは熟知していても、Googleスプレッドシートでは使えない。いつものテキストエディタの便利機能がないと文書作成がはかどらない。
自分のPCスキルがどれだけWindows+MS Office環境に最適化されていたか、という話です。
硬直するのは個人だけではありません。大学でテニスサークルの幹部をやっていた時代、これまでの風習や練習方法を抜本的に見直す機運が高まったことがあります。無駄が目につき、改善しないとメンバーの不満がたまるのが目に見えていたからです。
日夜幹部同士で話し合って案を組み上げたところ、立ちはだかったのが上級生でした。言い分はただひとつ、「なぜ変える必要があるんだ」。
過度に最適化されたルールやオペレーションを組み替えるのは骨が折れました。先代幹部たちの説得も含めて、正直、二度とやりたくない。
同じ構造は組織にもあります。COBOLで組まれた30年もののメインフレーム機が事業の核となるデータを管理している、という状態です。新しい事業展開の際、そのポンコツが技術的ボトルネックになります。
では、超えてはいけないラインはどこか。目的や方法に特化せず、ひとつ上の抽象的なレベルにとどめることです。
包丁1本ですべての下ごしらえを終わらせられる人は、皮むき器がなくても困りません。皮むき器に依存している人にはできない芸当です。
ExcelでもGoogleスプレッドシートでもR言語でもデータ分析ができる人がいます。ツールの使い方によらない、本質的かつ抽象的な知識を持っているからこそです。
判定の目安は3つ。
- ツールに依存していないか 別のツールでも同じ成果を出せるか
- ルールが目的化していないか 組織の手順を守ること自体が目的になっていないか
- スタイルに固執していないか やり方への愛着が成果とスピードを上回っていないか
3つ目のスタイルへの固執は、他人から借りたやり方でも起こります。ライフハックは一般法則のようでいて、書いた人の主観が色濃くにじむからです。
他人の速度術がそのまま自分に効くことは、めったにありません。早起きも瞑想も運動も、メリットを説く記事とデメリットを説く記事が普通に並んでいます。
だからこそ、自分の悩みの根っこを正確な言葉にするところから始めるしかありません。ドンピシャのライフハックが見つかることはまれ。ほとんどは、自分で料理しないと自分のものになりません。
10年後の現在地——速さの定義が変わった#
3倍速から10年近く経った今、ぼくの中で速さの定義そのものが変わりました。作業の速さは、もう主戦場ではありません。
速さとは「判断できるまでの時間」#
今のぼくにとって、仕事の速さとは判断できるまでの時間です。手が動く速さではなく、決められる状態に到達するまでの時間を指します。
振り返れば、3倍速の3手法のうち効果が大きかったのは段取りと合意プロセスでした。どちらも作業ではなく判断の話です。はまる時間の6つの原因も、全部が判断の前段で潰せるものでした。着手・処理・はまらない力のうち、処理だけが浮いていたわけです。
行動の早さは、正しい戦略があってはじめて価値になります。ドイツの軍人クルト・フォン・ハンマーシュタイン＝エクヴォルトはこう言いました。
もっとも避けるべきは愚かで勤勉なタイプで、このような者にはいかなる責任ある立場も与えてはならない
考えすぎて動かないのは論外です。だからといって、考えなしに行動だけ起こすのも考えもの。走り出すのがいくら早くても、正しい方向と逆を向いていれば、それは害であり損失でしかありません。
ベロシティはAIに任せる#
作業そのもののベロシティは、もうAIに任せたほうが早い。人間側で重要なのは、むしろ質です。
調査も、資料の骨組みも、コードの下書きも、ぼくが手を動かすより速く出てきます。かつて「頭の中でイメージを固め切ってから一発で作る」ことで稼いでいた時間短縮は、まるごと外部化できるようになりました。
正直に言うと、これはちょっと悔しい発見でした。10年かけて鍛えた処理の速さが、数年で相対的な価値を落としたわけですから。3倍速の実験で積み上げた資産の一部が、静かに目減りしていくのを見ている感覚です。
だからこそ、人間側に残るのは「何を作るか」と「その判断は正しいか」の部分になります。速さの土俵は、処理から判断へ移りました。ぼくはそう受け止めています。
速くしてはいけない仕事#
速くしてはいけない仕事があります。人の感情が絡む仕事です。
仕事の根幹が人であることは、AIが入っても変わりません。人はただの歯車ではなく、感情を持っています。メンテナンスが必要ですし、方向転換には心の準備がいります。
承認フローをすっ飛ばす技は、資料の合意には効きます。しかしメンバーの納得には効きません。「決まったので明日から変えます」で気持ちよく動ける人間はいないからです。
パレートの法則も同じ。品質の80%は20%の時間で出ますが、人の納得の80%を20%の時間で作ることはできません。心が動く速度は、こちらの都合では決まらないのです。
3倍速を覚えたてのころ、ぼくはここを混同していました。速く回すことがあらゆる場面で正義だと思っていたからです。合意はショートカットできても、納得はショートカットできない。この違いに気づくまでにしばらくかかりました。
まとめ：速さは上げるものではなく、使いこなすもの#
仕事の速さは、着手・処理・はまらない力の3つに分解できます。世のテクニックが扱う「処理」は、そのうちの1つでしかありません。
速くならない最大の原因は手数ではなく、はまっている時間の長さでした。言葉の定義、「とりあえず」の資料、違和感の放置、フレームワークへの依存と理解不足、アセットの見落とし。6つの原因はすべて、作業の前段にあります。
3倍速そのものは、段取り・ベストプラクティス・合意プロセスの3段で作れます。ただし自分と周囲の期待値が暴走し、常時3倍速を1週間続ければ土日にぶっ倒れる。目の前の環境に最適化しすぎれば、環境が変わった瞬間に動けなくなります。
そして10年後、ぼくの中で速さは「判断できるまでの時間」に変わりました。処理のベロシティはAIのほうが速く、人の感情が絡む仕事だけは速くしてはいけない。
速さは、上げるものではなく使いこなすものです。どこで3倍速を出し、どこで絶対に出さないか。あなたの仕事のうち、速くしてはいけないものはどれでしょうか。
