仕事が遅い人ほど「全部整理してから動く」をやめるべき理由

 

「網羅的かつ多角的な視点で整理してから進めたい」「情報が十分に揃ってから上司や顧客に見せたい」。

仕事を丁寧に進めようとする人ほど、このように考えがちです。しかし実務では、完璧に整理してから動こうとするほど、着手や意思決定が遅れ、結果として成果につながらないことがあります。

重要なのは、最初から完成度100%を目指すことではありません。重要なことを先に見極め、仮説を置いて動き、フィードバックを得ながら改善することです。

この記事では、「まず重要なことを見極める→動く→改善する」という仕事の進め方と、資料作成・会議・情報収集などで実践するための具体的な方法を解説します。

「あらゆる角度から検討してからでないと動けない」「情報が揃ってからでないと人に見せられない」。これは一見すると慎重で丁寧な仕事の進め方に見えますが、実務ではこうした完璧主義が仕事のスピードを落とすことがあります。

例えば資料作成で、全体構成を完璧に固めようとしてなかなかスライドを書き始められない。関係しそうな情報をすべて集めてから考えようとする。一度で完成版を作ろうとして、細部の表現やデザインに時間をかける。こうした状態は珍しくありません。

問題なのは、丁寧に考えることそのものではありません。重要な論点が定まっていないまま、完成度を高める作業に時間を使ってしまうことです。

仮に10枚の資料をきれいに作っても、相手が知りたいことが「結局、A案とB案のどちらを選ぶべきなのか」であれば、その問いに答えられなければ価値は高まりません。

成果を出すために必要なのは、最初からすべてを理解することではなく、「今回、本当に答えるべき問いは何か」「どこが意思決定のボトルネックになっているのか」を早い段階で見極めることです。

もちろん、全体像を考える必要がないわけではありません。大切なのは、全体を完璧に整理してから重要なポイントを探すのではなく、まず重要そうな論点を仮置きし、それを検証するために必要な範囲で全体を見るという順番です。

実務では、すべての情報が同じ重要度を持っているわけではありません。成果や意思決定を左右するポイントは、限られた一部の論点に集中していることが多くあります。

そのため、最初に考えるべきなのは「何を調べるか」ではなく、**「何を明らかにしなければならないか」**です。

最終的な成果から逆算する

まず、「この仕事で最終的に何を決めるのか」「何を成果として出すのか」を確認します。

例えば新しい施策を検討しているのであれば、最終的な意思決定は「どの施策を実行するべきか」かもしれません。その場合、必要な論点は「各施策の効果はどの程度か」「実行コストや難易度はどう違うか」「どの施策が最も目的達成に寄与するか」といったものに絞られてきます。

最終成果から逆算すると、「知っておいた方がよい情報」と「意思決定に本当に必要な情報」を分けやすくなります。

相手が引っかかっている点を見る

会議や顧客とのやり取りでは、相手の反応に重要な論点が隠れていることがあります。

「顧客が最後まで納得していなかったのはどこか」「意思決定者が何度も質問していたポイントは何か」「議論が止まった原因は何だったか」と考えてみます。

同じ質問が繰り返される、ある数字だけ細かく確認される、特定の前提で議論が止まる。こうした場面は、そこが重要な論点である可能性があります。

「違和感」を問いに変える

仕事をしていると、「何かおかしい」「この説明では納得できない」と感じることがあります。そこで終わらせず、「なぜこの数字だけ他と違うのか」「なぜこの施策だけ成果が出ていないのか」「なぜ現場と経営層で認識が違うのか」と問いに変えてみます。

漠然とした違和感を、答えられる問いに変えることが、重要な論点を見つけるうえで有効です。

情報収集の効率を大きく左右するのが、「何を知りたいのか」が明確になっているかどうかです。

問いがないまま情報を集め始めると、関係しそうな資料を大量に読み、何を探していたのか途中で分からなくなりがちです。情報は増えているのに、結論にはなかなか近づきません。

一方で、問いが明確であれば、必要な情報も自然に絞られます。

例えば、「売上が落ちている原因は、新規顧客の減少ではないか?」という仮説を置いたとします。すると、新規顧客数の推移を見る、既存顧客の売上と比較する、新規顧客が減少した時期を確認する、その時期に何が変わったかを調べる、といったように調査すべき内容が具体化します。

つまり、仕事を効率よく進めるには、

問い → 仮説 → 必要な情報 → 検証

という順番が有効です。

「とりあえず資料を全部読む」のではなく、「この仮説を確かめるには、何を見ればよいか」と考えるだけで、情報収集の効率は大きく変わります。

これは現場へのヒアリングでも同じです。「最近の業務について教えてください」と広く聞くより、「承認に時間がかかっているのは、どの工程ですか?」「この作業が遅れる最大の原因は何ですか?」と聞いた方が、必要な情報を得やすくなります。

大切なのは情報量を増やすことではなく、意思決定に必要な情報へ最短距離でたどり着くことです。

重要なポイントをある程度絞ったら、次は早く形にします。ここで重要なのが、**「仮説を置く→動く→フィードバックを得る→修正する」**という考え方です。

整理が100%終わってから動くのではなく、一定の仮説を持った状態でまずアウトプットを作り、そこから精度を高めていきます。

例えば資料作成であれば、最初から完成版を作る必要はありません。「結論はおそらくAである」「理由は大きく3つありそうだ」という仮説を置き、タイトルと主要メッセージだけを書いたラフな資料を作ります。

その段階で上司や関係者に「この方向性で合っていますか?」と確認できれば、方向性が違っていても修正コストは小さく済みます。反対に、確認せずに20枚の資料を完成させた後で「そもそも論点が違う」と言われれば、大きな手戻りになります。

会議設計でも同じです。最初から完璧なアジェンダを作るのではなく、「今回決めるべきことはこの2点ではないか」と仮置きし、関係者と確認しながら調整する方が効率的です。

**完成度を上げてから確認するのではなく、方向性を確認してから完成度を上げる。**この順番を意識するだけでも、仕事の進め方は大きく変わります。

ただし、「とりあえず何でもいいから動けばよい」という意味ではありません。何も考えずに作業を始めれば、かえって手戻りが増えることもあります。

重要なのは、仮説を置いたうえで、小さく動くことです。

情報収集なら、「まずこのデータを見れば仮説を確認できそうだ」と考えてから調べる。資料作成なら、「結論はAではないか」と仮置きして、まず骨子や1枚のラフを作る。会議なら、「今回決めるべきことはこの2点だ」と仮置きしてアジェンダを作る、といった具合です。

つまり必要なのは、「完璧に考えてから動く」でも「何も考えずに動く」でもありません。考える範囲を絞り、仮説を持って早めに動くことです。

早く形にする最大のメリットは、早くフィードバックを得られることにあります。自分一人で長く考え続けるより、ある程度のラフ案を作って関係者に見せた方が、重要な前提の間違いに早く気づける場合があります。

実務では、自分の頭の中だけで精度を上げ続けるより、一度外に出してフィードバックを得た方が、結果として早く質の高いアウトプットに到達できることが多いのです。

実際の仕事では、次の5ステップで考えると実践しやすくなります。

1. 最終的に何を決めるのか確認する

「この仕事が終わったとき、何が決まっていればよいのか?」を最初に考えます。目的が曖昧なまま作業を始めないことが重要です。

2. 最も重要な問いを仮置きする

「その意思決定のために、最も明らかにすべきことは何か?」を考えます。最初から完璧な問いである必要はありません。

3. 仮説を置く

「おそらくこうではないか」という暫定的な答えを置きます。仮説があることで、何を調べ、何を作ればよいかが明確になります。

4. 最小限のアウトプットを作る

いきなり完成版を作らず、資料なら骨子や1枚のラフ、分析なら主要な数字、会議ならアジェンダ案など、方向性を確認できる最小単位まで形にします。

5. フィードバックを得て修正する

「仮説は正しかったか」「問いはずれていないか」「追加で何を確認すべきか」を見直し、必要に応じて修正します。

このサイクルを回すことで、最初から完璧を目指すよりも、結果的に速く質の高いアウトプットに到達しやすくなります。

まとめ

仕事のスピードを落とす原因の一つは、「完璧に整理してから動こう」とすることです。

重要なのは、全体を完璧に理解する前にまず重要な問いを見つけ、その問いに対する仮説を置き、必要な情報だけを集めること。そして完成版をいきなり作るのではなく、方向性を確認できる小さなアウトプットを早めに作り、フィードバックを得ながら修正することです。

「全部整理してから動く」のではなく、「重要なことを見極めて、まず動く」。

もちろん、思いつきで動くわけではありません。仮説を持って小さく動き、早く確かめることが大切です。

次の仕事で「全部整理してから始めよう」と思ったときは、一度だけ立ち止まってみてください。

「今、最も重要な問いは何か?」

「それを確かめるために、最初に何を一つやればよいか?」

この2つを考えて動くだけでも、仕事のスピードと質は大きく変わります。

タイトルとURLをコピーしました