どんな状況でも成果を出せる人、どんなに頑張っても成果には届かない人

仕事をや何かを一生懸命頑張っているのに、なかなか成果につながらない

一方で、

同じような仕事をしているはずなのに、着実に成果を積み上げていく人がいる

この違いは、能力や経験、努力の量だけで説明できるものなのだろうか？と、現場で仕事をしていてよく思う。

---

ひとつ、感じていることがある。

成果を出せる人と、なかなか成果が出ない人の差は、頑張り始めた瞬間ではなく、頑張り続ける過程で広がっていく ということ。

しかも厄介なのは、成果が出ない人も、決してサボっているわけではないこと。

むしろ、本人なりに真剣に取り組んでいることも多い。

その２つは、「何が違うんだろうね？」って会話になったので、
個人的主観だけれど、結構真理ついてるなぁ〜と、思うところを書き殴ってみる。

1. 「頑張っている」と「前に進んでいる」は全く異なる

仕事をしていると、努力そのものが評価される場面は少なくない。

• 時間をかけて調べた
• 資料を作った
• コードを書いた
• 何度も修正した。

どれも大切なこと。

ただし、仕事の目的は、努力することではない。
学ぶことでもない。成長することですらない。

• 問題を解決すること
• 必要なものを完成させること
• 期待された成果を出すこと。
• ゴールまで、着地までやり遂げること。

ここを取り違えると、努力しているのに成果が出ないという状態に陥る。

例えば、ある作業に30時間かかると見積もったとする。

成果を出す人は、まずその30時間の根拠を考える。

• 何を実現する必要があるのか
• どこに難しさがあるのか
• 目的は何か
• 既存の仕組みを利用できないか
• もっと簡単な方法はないか
• 何を確認すれば、見積もりの精度が上がるか
• 目標工数と、現実的な落とし所は どの辺りだろうか

と。

今からの道のりを見つつ、その先の１ヶ月後、再度同じ作業があった場合の、負荷軽減など。

成果を出し続ける人は、実は初手から考えることや視点の広さが違う。

一方で、成果につながりにくい人は、与えられた作業を30時間かけて完遂することに意識が向きやすい。

それで、合格だ！と思ってる節すらある。

もちろん、最初の見積もりが外れることは誰にでもある。
問題は、見積もりが外れたことではなく、外れた理由を次に生かせるかどうか。

30時間かかった仕事を、次は15時間でできるようにする。

これも立派な成果である。

同じ30時間を何度も繰り返すだけなら、経験を積んでいるはずなのに、仕事の進め方は変わっていないことになる。

2. 成果を出す人は、作業より先に構造を見る

複雑な仕事ほど、目の前の作業を始める前に、全体像を把握することが重要だったりする。

例えば、システム開発で何かを変更するとき。
成果を出す人は、変更対象のコードだけでなく、その変更がどこに影響するかを考える。

依存関係はどうなっているのか。既存の機能との整合性は取れるのか。権限や設定に漏れはないか。リリース時に何が起きるのか。

つまり、個別の作業を、システム全体の中に位置づけて考える。

これができると、実装する前に問題を発見できる。
未経験であっても、一切予備知識がなくても、ある程度まで行ける。
（ある程度まで行ける経験となる）

行き着くところ、どんなものにも応用できる、一定の普遍的な思考が身につく。

反対に、作業単位でしか考えられないと、実装が終わってから関連する設定の漏れに気づいたり、別の機能への影響が判明したりする。

その結果、修正が増え、確認が増え、当初の見積もりから遠ざかっていく。
そして、本人は忙しくなる。
忙しいからこそ、視野も狭くなる。

周囲から見ても、頑張っているように見える。
しかし、仕事全体としては、必ずしも前進しているとは限らない。

作業を速く進める能力と、仕事全体を速く終わらせる能力は、別物。

これはエンジニアに限った話ではない。

• 営業なら、個々の商談だけでなく、顧客の意思決定プロセスを見る。
• マネージャーなら、個々のタスクだけでなく、チーム全体のボトルネックを見る。

どの仕事でも、部分最適に集中するほど、全体最適から遠ざかることがある。

全体最適の視点がないと、結果… 1+1をずっとやり続ける。
かけ算に気付けない。

結果、積み上がる結果も ずっと、変わらず横ばいのまま。
歴が長くても、成果を出せない人は、この視点がない。
そういう人をよく見る。

勿体ない。

3. 分からないことに対する向き合い方

仕事をしていれば、知らないことや分からないことに必ず直面する。

ここで、また差がつく。

成果を出す人は、分からないことを放置せず、分からない範囲を特定しようとする。

• 何が分かっていて、何が分かっていないのか。
• どこを調べれば答えが見つかるのか。
• 仮説を立てるために、どんな情報が必要なのか。

そして、調べた結果を自分の理解に変えていく。

一方で、分からないことを曖昧なままにして、先に進めてしまう人もいる。
とりあえず動くものを作る。とりあえず資料を完成させる。とりあえず詳しそうな人に聞く。
短期的には、それでも仕事が進んでいるように見える。

しかし、根本的な理解が不足していると、少し条件が変わっただけで対応できなくなる。
自分で判断できないため、また誰かに聞く。
似たような問題が起きても、以前の経験を十分に生かせない。

人に聞くのが恥ずかしい、自分ができないことを認められない人は、AIに聞く。
インプットも分からない人なので、AIもそれっぽいことしか言わない。
AIのアウトプットも理解できないので、そうなんだ！となる。

結果、スパゲティな資料で、分かりにくいだけのメモのような、
ツギハギだらけのものしかできない。

当然、バグを生む。指摘を受ける。トラブルを起こす。
そしてまた、AIに頼って…

この繰り返しが、すぐに大きな差を生む。

ここで大切なのは、最初から何でも知っている必要はないということ。
むしろ、知らないことを認め、必要な知識を身につけられる人のほうが、長期的には強い。

知らない自分を受け止められるか？と、そのままの自分をよしとしないだけ。
知らないこと自体は問題ではない。知らないことを、知らないままにしておくことが問題だと思う。

知らないうちは、任せられる訳がない。
知ろうとしないうちは、超えられる訳がない。

そして、分かっていない人が分かっている人にすぐに追いつける訳がない。

4. AIを使っているのに、成果が上がらない理由

最近は、AIを使えば、コードも資料も設計書も短時間で作れるようになった。

これは非常に大きな変化だと思うし、効率も圧倒的に上がる。

個人的にも、無人でシステム構築を何個もさせている。

使いこなせると、ほぼ何もせずに設計〜構築、運用ですら簡単に可能になる。

ただし、AIを使うことと、AIによって成果を出すことは同じではない。

例えば、AIに設計書を作らせたとする。

成果を出す人は、出力された設計書をそのまま成果物とは考えない。

• 要求を満たしているか
• 前提条件は正しいか
• 実現できない機能が含まれていないか
• 例外ケースは考慮されているか
• AIが余計な実装を加えてないか

こうした点を確認し、必要に応じて当たり前に修正する。

AIの出力を、仕事を進めるための材料として使うだけ。
AIに任せても、考えることを放棄しない。

一方で、AIが生成したものを、そのまま完成品として扱ってしまう人がいる。
本当にいるので、ビックリするけど。

• 見た目は整っている
• 文章も自然
• コードも一見すると動きそうに見える。

しかし、中身が間違っていれば、後工程で問題になる。
場合によっては、AIを使わなかったときよりも、誤りの発見や修正に時間がかかる。

何より、その担当者が自分で説明できない。

AIで楽している訳じゃなく、本人では対応できないから任せる他無くなっているんだと思って見てる。
そして、AIでやったな、と分かってしまう。

資料やコーディングを自身で対応した場合、必ず説明ができる。

• こう考えた
• だから、ここはこうした

前提・経緯・判断・結果を、自分で苦労した場合は必ず持っているので、
レビュアーの問いには、必ず答えらえる。

これはAIに限った話ではない。

• インターネットで見つけた情報
• 詳しい人から聞いた話

でも同じだと思う。

情報を集めることと、その情報が正しいと判断できることは違う。
データは正しくても、加工された情報は 正しいとは言えないケースもある。

便利な道具を使いこなせるかどうかは、道具を操作する技術だけでは決まらない。
その出力を評価できるだけの理解があるかどうかで決まる。

GIGO

今更になって、これか。
と、改めて感じるのは、こういった人たちのAIのアウトプットを見る時。

AIの進化によって、この差はむしろ広がる可能性がある。

知識や判断力のある人は、AIによって生産性をさらに高められる。
自分自身、これまで２−3個が限界だったマルチタスクも、
平気で6-8個並行できる。

反対に、出力の正しさを判断できない人は、間違いを大量に、しかも高速に生み出してしまうことがある。

速く作れることと、正しいものを作れること。
この2つは、分けて考えなければならない。

そして、自分がどちら側なのか？正しく認識しておく必要があると思う。

5. 指摘されたときに、何を持ち帰るか

仕事で指摘を受けることは、誰にとっても気持ちのいいものではない。

• 自分では正しいと思っていたことが間違っていた
• 時間をかけた成果物を修正することになった
• 見落としを指摘された
• 想定漏れを指摘された
• 実現性や、現実性の低さを指摘された

そんな経験は誰にでもある。

ここでも、成果を出す人と、なかなか成果が出ない人には違いがある。

成果を出す人は、指摘された内容だけでなく、その指摘が生まれた原因を考える。

• なぜ、この問題を事前に発見できなかったのか。
• どの前提を間違えていたのか。
• 次回、同じ問題を防ぐには何を変えればいいのか。

つまり、修正を単発の作業で終わらせない。

もっと言うと、他責にもしないし、逆に指摘されて良かった！とさえ思う。

一方で、指摘された箇所だけを直して終わりにしてしまうと、同じ種類の問題が別の場所で再発する。
そのたびに修正が必要になり、レビューする側の負担も増えていく。

ここで重要なのは、指摘の数が多いこと自体ではない。

経験が浅ければ、指摘が多いのは自然なこと。
大切なのは、同じ指摘が、時間の経過とともに減っているかどうか だと思う。

一度の失敗から学べることは、ひとつとは限らない。

目の前の修正だけでなく、背後にある考え方まで理解できれば、その学びはほかの仕事にも応用できる。

経験年数だけでは測れない成長の差は、こうしたところに現れる。
逆に、経験が浅くても、専門ではなくても、本質を付ける人もいる。

今の自分を守って、将来の成長を失い続けるか。
将来の自分の為、指摘を感謝するか。
ただそれだけの違いで、1年後には次元が違うほど 差がつく。

ここが弱点の人は、本当に苦労すると思う。

指摘も、相手の時間を貰っているのだから。
その時間コストに見合わないとなると、せっかくの成長する・気付く機会を自ら放棄する。

6. 自分の仕事を、自分で適切に評価できるか

仕事を進めるうえで、上司や同僚からのレビューは重要になる。

だけれど、すべてを他人に確認してもらわなければ品質を保証できない状態では、組織全体の生産性は上がりにくい。
レビューする側にも時間の限界がある。

成果を出す人は、レビューに出す前に、自分で成果物を検証する。

• 要求を満たしているか
• 想定外のケースはないか
• もっと簡単な方法はないか
• 第三者が見ても理解できるか。

そして、自分では判断できない部分を明確にして、レビューを依頼する。

レビューを、単なる正誤判定ではなく、自分の判断の妥当性を確かめる機会として使う。
丸投げではない。

反対に、自分で確認できることまで他人に委ねてしまうと、レビューする側が実質的な作業者になってしまう。

• 作成者が成果物を作る
• レビュー担当者が問題を発見し、修正方針まで考える。

これでは、作業を分担しているようで、実際には負担が一方に偏っている。
そして、レビュー担当者が忙しくなれば、仕事全体が止まる。
そして、そんなレビュー依頼ほど、相手も人。後回しにされる。

この構造を変えなければ、個人がどれだけ努力しても、チームとしての生産性には限界がある。
結果を出せない人は、この相手視点がない。

• 依頼の仕方
• 依頼のタイミング（時間）
• 依頼文

相手が動きやすいようにコーディネートしていないので、求める速度で相手に動いて貰えない。

実は、自身の行動が起因 ってことが大抵。

もちろん、経験の浅い人に最初から完璧な自己レビューを求めるのは無理がある。

必要なのは、いきなり一人でできるようになることではなく、レビューを通じて、自分で確認できる範囲を少しずつ広げていくこと。

最終的に目指すべきなのは、レビューを受けなくてもよい人ではない。
逆に、レビューを求める側になるべきだとさえ思う。

行き着きたいのは、レビューによって品質を高めながら、レビューする側の負担も減らせる人なのだと思う。

7. 成果を出す人は、仕事のやり方そのものを変える

ここまでの内容を振り返ると、ひとつの共通点が見えてくる。

成果を出す人は、目の前の仕事を終わらせるだけではなく、仕事の進め方そのものを改善している。

例えば、

• 毎回同じ確認作業が発生するなら、チェックリストを作る。
• 何度も同じ調査をするなら、調査手順を文書化する。
• 人によって判断が分かれるなら、判断基準を明確にする。
• ミスが繰り返されるなら、注意を促すだけでなく、ミスが起きにくい仕組みを考える。

こうした改善は、すぐに大きな成果を生むとは限らない。
むしろ、目の前の作業だけを終わらせるほうが、短期的には楽なこともある。

しかし、改善を積み重ねれば、同じ仕事をより少ない時間で、より高い品質で実行できるようになる。
ここに、長期的な生産性の差が生まれる。

逆に、毎回同じ問題に直面し、毎回同じ方法で対処しているだけでは、仕事の量が増えるほど苦しくなっていく。
頑張るほど忙しくなり、忙しくなるほど改善する時間がなくなり、さらに忙しくなる。
これは個人にも、チームにも起こり得る悪循環。

だからこそ、目の前の仕事を終わらせることと、次の仕事を楽にすることを、両立させる必要がある。
面倒くさがり屋の人ほど、こういったところに長けていたりする。

8. どう頑張っても成果が出ない、は本当なのか

ここまで書いてみて。
成果が出ない人には、本人の努力や考え方に問題があるように見えるかもしれない。

それだけで説明できるほど、仕事は単純ではないと思ってる。

• 適切な教育を受けられない
• 必要な情報が共有されない
• 権限がない
• 業務量が多すぎる
• 判断する人が多く、意思決定が遅い。

こうした環境では、本人が努力しても成果につながりにくい。

そもそも、成果を出すための条件が整っていない可能性もある。

また、経験の浅い人が一時的に成果を出せないことと、何年経っても成長しないことは、分けて考えるべきだ。
最初から成果を出せる人など、そう多くはない。
（ただし、そういう人も実在する）

重要なのは、経験を積むなかで、仕事の進め方が変化しているかどうかだ。

• 以前よりも見積もりの精度が上がったか。
• 同じ指摘を受ける頻度が減ったか。
• 自分で判断できる範囲が広がったか。
• より複雑な問題を、少ない手戻りで解決できるようになったか。

こうした変化があれば、成長していると思う。（少なくとも）

一方で、長い時間をかけても、同じ問題が繰り返され、仕事の進め方も変わらないのであれば、努力の方向を見直す必要がある。

それは、もっと頑張れという話ではない。

頑張り方を変える必要がある、ということ。

そして、残念ながら…

どんなに頑張っても成果を出せない人というのは、実在する。

• 向き合うスタンスが違う
• その場しのぎでやり過ごそうとする
• 相手によって態度を変える
• 「分からない」「できない」自分を認められない
• 困った時に、すぐ助けを呼べない
• 自分でどうにかできると思い込んでいる
• 相手が何を求めているか、想像していない

色々タイプはあるけれど。

それでも、決定的なのは 自分の現状を知らず、成果を出せると思っている
そんな人。

そして、任せられる仕事も、新卒でも・素人でもできるようなものばかりになる。

ストレートに表現すると、プロの現場で、プロとして扱って貰えない
そこに、年齢や経験は関係ない。

現場では、成果を出せる人 が必要なのだから。

9. せっかくの努力を成果につなげるために

もし今、頑張っているのに成果が出ないと感じている方がいるなら、努力の量を増やす前に、少し立ち止まって考えてみてほしい。

• 自分は、目的を達成するために仕事をしているだろうか。それとも、与えられた作業を終わらせることに集中していないだろうか。
• 以前に経験した問題から、何かを学べているだろうか。同じ問題を繰り返していないだろうか。
• 自分が作った成果物の品質を、自分で評価できるだろうか。
• 調べたことや経験したことを、次の仕事に生かせる形にできているだろうか。
• そして、今の仕事のやり方は、半年後の自分を楽にしてくれるだろうか。

すべてに「はい」と答えられる必要はないけれど、
大切なのは、自分の現状を適切に把握し、改善できる部分を見つけること

成果を出す人は、必ずしも最初から能力が高かった人ではない。

• 仕事を通じて学び
• 判断の精度を上げ
• 失敗を次に生かし
• よりよい方法を探し続けている

そんな人。

そして、自分を適切に評価できている人。

反対に、どれだけ忙しく働いていても、仕事の進め方が変わらなければ、同じ場所を走り続けることになる。

努力は大切

ただ、努力しているという事実だけでは、成果が出ることは保証されない。

• 頑張ることと
• 成長すること
• 成果を出すこと。

この3つは、似ているようで違う。

だからこそ、自分がどこにいるのかを振り返り、必要ならやり方を変えていく。

それが、努力を成果につなげるための第一歩なのだと思う。

相手は変えられないけれど、自分自身のスタンスや捉え方は、簡単に変えられる。

⸻

もし、なかなか成果が出ずに、行き詰まっている方がいたら、ちょっと参考にして見てほしい
また、これまでに見てきた 成果を出せない人の行動・言動を、現場で見てきた例もそのうち書いてみる。

願わくばーーー

全ての方が、成果を出し続けらえるような、気づきになれば、と思う。