努力に頼らず成果を出そうとして消耗していた自分が「頑張り方を考え直す」きっかけになった1つのこと

※この記事にはアフィリエイトリンクを含みます。

導入：仕事は終わってるのに、ずっと疲れている

仕事をサボっているわけではない。

むしろ、かなり真面目にやっている。

それなのに、なぜかずっと疲れている。

• 手を抜いていないのに余裕がない
• 仕事は終わっているのに達成感がない
• 「もっと頑張らないといけない気がする」だけが残る

エンジニアだと、この状態はわりと“あるある”です。

• 見積・調査・レビュー・会議、全部に同じ熱量で向き合って消耗する
• 割り込みが積み重なって「深い作業」が毎日溶ける
• 重要じゃない対応まで全力で拾って、肝心の設計が薄くなる

成果を出したい気持ちはある。

でも頑張るほど消耗していく。

そんな違和感を抱えたまま仕事をしていました。

結論：努力量を増やす前に「力の使いどころ」を決める

私は一度、「頑張り方」を考え直すことにしました。

努力量を増やすかどうかではなく、そもそも、どこに力を使うべきか。

その前提を見直す、という意味です。

※「切り分け方が分からない」と感じた人は、先にこの記事を読むと早いです。

なぜ消耗していたのか：全部を“同じ重要度”で扱っていた

今振り返ると、原因はシンプルでした。

• 目の前の仕事に全部同じ力で向き合っていた
• 「やる価値があるか」を判断していなかった
• 頑張ること自体が正解だと思っていた

結果として、重要度の低いことにも全力を使っていた。

これでは、どれだけ誠実でも消耗します。

私が最初に変えたのは1つだけ：「これは頑張る価値があるか？」

私が最初に変えたのは、たった1つです。

「これは、頑張る価値のある仕事か？」

この問いを、すべての作業に挟むようにしました。

• 力を入れるべき仕事
• 最低限で済ませる仕事
• そもそも今はやらなくていい仕事

を、意識的に分けるようにしました。

エッセンシャル思考の要点：鍵は「仕組み化」と「バッファ」

ここからの整理に役立ったのが、『エッセンシャル思考』です。

私の理解では、本質はこの2つでした。

1) 仕組み化：努力で頑張るのではなく「勝手に回る形」を作る

頑張るのをやめる、ではなく、

頑張らなくても回る仕組みに寄せていく。

例（エンジニアなら分かりやすい）

• 毎回悩む見積→テンプレ化してブレを減らす
• 調査が沼る→「現象→仮説→切り分け→結論」の型を固定
• レビューで差し戻る→指摘パターンをチェックリスト化して先に潰す

2) バッファ：予定通りに進まない前提で“余白”を組み込む

仕事は、与えられた時間いっぱいに広がりやすい。

だから最初から不測の事態込みで予定を組む。

• 予定がズレるのは異常ではなく“通常運転”
• バッファはサボりではなく「破綻しない設計」

今日からできる：ミニ実装（どれか1つだけでOK）

やることを増やすと壊れるので、どれか1つで十分です。

✅ ミニ実装チェックリスト（1分で選ぶ）

• □ 仕組み化：よく出る作業をテンプレ化する（見積/調査/報告のどれか）
• □ バッファ：見積・計画の最後に予備（例：20%）を足す
• □ 優先順位：今日のタスクを「全力/最低限/今やらない」に仕分ける

ポイントは「完璧にやる」ではなく、

力の配分を“設計”することです。

頑張り方を考え直すヒントになった1冊

この「頑張り方を考え直す」という視点を、言語化する助けになったのが、この1冊でした。

※解決策ではなく、考え直すための材料として読んでいます。

『エッセンシャル思考 ― 最小の時間で成果を最大にする』

• 向いている人
  • 頑張っているのに余裕がなくなりがちな人
  • 忙しさと成果が結びついていないと感じる人
• 向いていないかも
  • 即効性のあるテクニックだけを求めている人

紙（楽天ブックス）

エッセンシャル思考　最少の時間で成果を最大にする [ グレッグ・マキューン ] 価格：1,760円（税込、送料無料) (2026/1/17時点)

次に読む：切り分け方が分からない人向け

もし

「頑張り方を考え直す必要は分かったけど、どう切り分ければいいか分からない」

と感じたら、次の記事が役に立ちます。

思考を整理するための土台をまとめた記事

仕事がつらいエンジニアが最初にやるべきは転職でも努力でもなく「整理」だった話

仕事がつらいエンジニアが最初にやるべきは転職でも努力でもなく「整理」だった話

2026.1.19

結論 仕事がつらいと感じたとき、 最初にやるべきことは環境を変えることでも、自分を追い込むことでもありません。 「何が、どのレイヤーでつらいのか」を整理することでした。 次にやるこ...

技術力があっても評価されない理由は「論点のズレ」だったと気づいた話

技術力があっても評価されない理由は「論点のズレ」だったと気づいた話

2026.1.19

結論 技術的に正しいことをしているのに評価されない原因は、 能力不足ではありませんでした。 相手が見ている論点と、自分が説明している論点がズレていただけでした。 まずこの順で話す：...

仕事と人間関係で消耗していた自分が「考え直す」きっかけになった1冊

仕事と人間関係で消耗していた自分が「考え直す」きっかけになった1冊

2026.1.19

※本記事はアフィリエイト広告（楽天アフィリエイト）を含みます。 紹介している書籍・サービスは、私が実際に読んで/使って有用だと感じたものを中心に選んでいます。 結論 仕事や人間関係...

まとめ：消耗の原因は努力不足ではなく「配分未設計」だった

消耗の原因は、努力不足ではありません。

どこに力を使うかを、一度も立ち止まって考えていなかった。

それだけでした。

まずは、頑張り方を考え直すことを許す。

そこからで十分です。

次の記事へ

仕事がつらいエンジニアが最初にやるべきは転職でも努力でもなく「整理」だった話

2026.1.19

結論 仕事がつらいと感じたとき、 最初にやるべきことは環境を変えることでも、自分を追い込むことでもありません。 「何が、どのレイヤーでつらいのか」を整理することでした。 次にやるこ...