20年SEとして働いてきて分かった、仕事を頭の中だけで抱え込まない技術

仕事が重いと感じることがあります。

やることはある。
期限もある。
自分が担当していることも分かっている。
それでも、なぜか仕事がずっと頭の中に残り続ける。

「あれは大丈夫だったかな」
「まだ何か確認が足りないかもしれない」
「このまま進めて、本当に問題ないのだろうか」
「誰かに相談した方がいい気がするけれど、うまく説明できない」

そういう状態になると、仕事をしている時間だけでなく、仕事をしていない時間まで重くなります。

私は2006年4月に就職してから、SEとして20年ほど仕事をしてきました。今はLinuxディストリビューションの開発にも関わっています。

その中で思うようになったことがあります。

仕事が重くなるのは、能力不足だけが原因ではない、ということです。

もちろん、知識や経験が足りなくて苦労することはあります。確認不足で手戻りになることもあります。もっと早く相談すればよかったと思うこともあります。

でも、今振り返ると、それだけではありませんでした。

不明点を頭の中だけで抱えていた。
不安を不安のまま置いていた。
判断を一人で抱え込んでいた。
前提や優先順位や完了条件が曖昧なまま進めていた。

そういうものが積み重なることで、仕事はどんどん重くなっていたのだと思います。

仕事を頭の中だけで抱え込まない。

これは、私が20年SEを続ける中で少しずつ身につけてきた、大事な仕事の進め方です。

仕事を抱え込んだ結果、私は一度現場を離れることになった

私が入社してから8年ほど担当していた仕事では、判断や調整をそのまま任せきれないと感じる状況がありました。

お客様にとって困る進め方になってしまうのではないか。
このまま言われた通りに進めると、あとで問題になるのではないか。

そう感じることがありました。

だから私は、できるだけ自分たちで何とかしようとしていました。作業指示をそのまま待つのではなく、自分を含めたメンバーで考え、判断し、進めようとしていました。

当時は、それが必要なことだと思っていました。

お客様に迷惑をかけたくない。
現場を止めたくない。
自分たちで何とかしなければいけない。

そう思っていました。

でも、その結果、私はかなり多くの仕事を抱え込むことになりました。

開発もする。
複数のお客様の保守もする。
問い合わせにも対応する。
判断もする。
調整もする。
足りない部分は残業や休日出勤で埋める。

そういう進め方を続けていました。

そのときの私は、いろいろな仕事を抱えるのが当たり前だと思っていました。SEの仕事とはそういうものだと思っていたところもあります。

でも、今振り返ると、明らかにキャパオーバーでした。

ちゃんと仕事をこなすために必要なリソースが足りていませんでした。人も、時間も、判断の分担も足りていませんでした。

めいっぱい頑張った結果、私は体調を崩し、担当していた仕事から離れなければならなくなりました。

離れられて安心した気持ちもありました。
でも同時に、自分が途中で潰れてしまったことで、いろいろな人に迷惑をかけてしまったという思いもありました。

この経験は、今でも私の中に残っています。

仕事は、一人で全部を背負えばよいものではありません。
頑張れば何とかなることもありますが、頑張り続ければ壊れてしまうこともあります。

だから私は今、仕事を頭の中だけで抱え込まないことを大事にしています。

仕事が重くなるのは、作業量だけが原因ではない

仕事が重いとき、最初に思い浮かぶのは作業量です。

やることが多い。
期限が近い。
担当範囲が広い。
割り込みが多い。

もちろん、それも大きな要因です。

でも、仕事が重くなる原因は、作業量だけではありません。

分からないことが多すぎる。
誰に確認すればよいか分からない。
何が決まっていないのか分からない。
どこまでやれば終わりなのか分からない。
どれを優先すればよいか分からない。
本当にこのまま進めてよいのか分からない。

こういうものを頭の中だけで抱えていると、仕事はかなり重くなります。

手を動かしていない時間にも、仕事のことを考えてしまいます。
一つ作業していても、別の仕事が気になります。
何かを終わらせても、まだ終わっていない感じが残ります。

これは、単に作業が多いからではありません。
頭の中に置きっぱなしになっているものが多すぎるからです。

だから私は、仕事が重いときほど、頭の中にあるものを外に出すようにしています。

書き出す。
問いにする。
相談する。
前提を確認する。
優先順位を見る。
完了条件を見える形にする。

そうやって、頭の中にある重さを、扱える形に変えていく。

これが、仕事を抱え込みすぎないための第一歩だと思っています。

ToDoの前に、不明点を書き出す

仕事が進まないとき、私は以前、とにかくToDoを書こうとしていました。

やることを洗い出す。
順番を決める。
期限を書く。
一つずつ消していく。

これは正しい進め方に見えます。

でも、ToDoを書いているのに仕事が軽くならないことがあります。むしろ、ToDoが増えるほど、しんどくなることがあります。

その原因は、やることではなく、分からないことを抱えたままにしているからかもしれません。

たとえば、システム移行の仕事なら、作業前に分からないことがたくさんあります。

移行対象はどこまでか。
本番データ量はどのくらいか。
検証環境と本番環境に差分はないか。
必要な権限は足りているか。
失敗したときに戻せるのか。
誰が最終判断をするのか。
移行後に誰が確認するのか。

こういう不明点が残ったままToDoだけを書くと、仕事はあまり軽くなりません。

「移行作業をする」
「手順を作る」
「確認する」

そう書いても、その前提が分からなければ進めにくいからです。

だから私は、ToDoの前に不明点を書き出します。

何が分かっていないのか。
誰に確認すればよいのか。
何が決まれば進められるのか。
自分で調べれば分かることなのか。
誰かが判断しないと決まらないことなのか。

これを書くだけで、仕事の見え方が変わります。

仕事が進まない原因は、やる気や能力ではなく、不明点が多すぎることかもしれません。

不明点を外に出すと、次の行動が見えてきます。

調べる。
確認する。
相談する。
判断を依頼する。
リスクを共有する。

頭の中でぼんやり重かったものが、少しずつ仕事として扱える形になります。

不安は、書き出すと問いになる

仕事をしていると、不安になることがあります。

このリリース、大丈夫だろうか。
この仕様、あとで揉めないだろうか。
このまま進めて、誰かが困らないだろうか。
自分だけが抱えている情報はないだろうか。

私は、不安を感じること自体は悪いことではないと思っています。

むしろ、SEの仕事では大事な感覚です。

リリース前の違和感。
仕様の曖昧さ。
手順の抜け漏れ。
関係者との認識のズレ。

そういうものに気づけるから、失敗を未然に防げることがあります。

ただ、不安を頭の中に置いたままにすると、だんだん苦しくなります。

不安は、気づきとしては役に立つ。
でも、抱え続けると自分を押しつぶす。

だから私は、不安をそのままにせず、書き出すようにしています。

「このリリース、大丈夫かな」

このままだと、ただ漠然と怖いだけです。

でも、書き出すと問いに変えられます。

何が確認できれば、大丈夫と言えるのか。
失敗するとしたら、どこで失敗しそうなのか。
手順は誰かにレビューしてもらったか。
切り戻し方法は決まっているか。
関係者への連絡は足りているか。

問いになると、次の行動が見えてきます。

確認する。
相談する。
記録する。
手順を見直す。
リスクを共有する。

不安を消そうとしなくてもいいと思います。
不安は、なくすものというより、扱える形にするものなのかもしれません。

複雑な仕事に強い人は、不安を感じない人ではなく、不安を問いに変えられる人なのだと思います。

困る前に、少しだけ相談しておく

相談は大事です。

困ったら相談する。
分からなければ聞く。
問題があれば共有する。

これは正しいと思います。

ただ、実際には、困っているときほど相談しにくくなることがあります。

疲れている。
焦っている。
何から話せばいいか分からない。
自分でも状況を整理できていない。
相談したら怒られるのではないかと思う。
相手の時間を奪うのが怖い。

そういう状態になると、相談そのものが重くなります。

相談するにも力がいります。

状況を整理する。
相手を選ぶ。
何を聞きたいのか考える。
自分の考えを言葉にする。
相手の反応を受け止める。

これだけでも、かなりエネルギーを使います。

だから私は、完全に困ってから相談するのではなく、困る前に少しだけ話しておくことが大事だと思っています。

まだ問題になっていない。
まだ止まってはいない。
まだ大きな判断が必要なわけではない。

でも、

「少し気になっている点があります」
「もしかしたら、ここが後で問題になるかもしれません」
「今はまだ大丈夫ですが、念のため共有しておきます」
「このあたり、少し危ないかもしれません」

このくらいで、先に場に出しておく。

それだけでも、本当に問題になったときの動きが変わります。

相談は、答えをもらうためだけにするものではありません。
自分の頭の中にある負荷を、少し外に出すためのものでもあります。

相談は、弱さではありません。
仕事を一人で抱え込みすぎないための工夫だと思っています。

雑なメモで、頭の外に作業台を作る

私は仕事中、手元にノートとペンを置いています。

頭の中に浮かんだことは、どんどんメモします。

きれいに書こうとはしていません。
自分が読めればいい。
キーワードだけでもいい。
あとで思い出すきっかけになればいい。

仕事が複雑なときほど、私はメモを雑に書きます。

なぜなら、複雑な仕事では、頭の中だけで処理しようとするとすぐにいっぱいになるからです。

別の相談が来る。
確認したいことが増える。
急ぎの判断を求められる。
会議に呼ばれる。
別の話題が同時に入ってくる。

そういうとき、全部を覚えておこうとするだけで負荷になります。

メモは、きれいな記録のためだけにあるのではないと思っています。

私にとってメモは、考えるための作業台です。

頭の中だけで考えていると、同じところをぐるぐる回ることがあります。

あれもやらないと。
これも確認しないと。
でも何から聞けばいいんだろう。
何が分かっていないんだろう。

そう考えているうちに、何も進んでいないのに疲れてしまうことがあります。

でも、メモに出すと少し変わります。

並べられる。
消せる。
分けられる。
順番を変えられる。
後で見返せる。

これは決まっている。
これはまだ決まっていない。
これは確認すれば進む。
これは今すぐ考えなくていい。

そうやって見える形にすると、仕事の重さが少し変わります。

メモを書くことで、頭の中に空きを作る。
その空きがあるから、次のことを考えられる。

私は、そういう感覚でメモを書いています。

「たぶん大丈夫」を確認の入口にする

経験を積むと、「たぶん大丈夫」と思う場面が増えます。

前もこれでいけた。
ざっと見た感じ問題なさそう。
過去にも似た対応をしたことがある。
大きな影響はなさそうに見える。

こういう感覚自体は悪いものではありません。

むしろ、経験から危なそうなところや大丈夫そうなところを見分けられることは大事です。

ただ、「たぶん大丈夫」をそのまま確定にしてしまうと危ないです。

私自身、「前もこれでいけたから大丈夫だろう」と思って進めたあとで、本番環境だけ条件が違っていてヒヤッとしたことがあります。

検証環境では問題なかった。
過去にも似た対応をしたことがあった。
だから今回も大丈夫だと思っていた。

でも、あとから見ると、確認できていないことが残っていました。

だから私は、「たぶん大丈夫」と思ったときほど、その中身を見るようにしています。

何を見て大丈夫だと思ったのか。
何をまだ見ていないのか。
前回と今回で違う条件はないか。
失敗したらどこに影響するのか。
誰が判断すれば大丈夫と言えるのか。

「たぶん大丈夫」は、安心して終わる言葉ではありません。
確認を始める合図だと思っています。

確認は、人を疑うことではありません。
自分を責めることでもありません。

仕事を安全に前へ進めるための作業です。

決まっていないこと、前提、優先順位を見る

仕事が止まっているとき、作業が足りないのではなく、判断が止まっていることがあります。

仕様が決まっていない。
優先順位が決まっていない。
誰が判断するのか分からない。
どこまでやるのか決まっていない。
例外時の扱いが決まっていない。

こういう状態のまま無理に作業を進めると、あとで手戻りになることがあります。

大事なのは、決まっていないことを自分のToDoにしないことです。

仕様を決める。
優先順位を決める。
リリース範囲を決める。

そう書いても、自分に決定権がなければ進みません。

そのときに必要なのは、自分で抱え込むことではなく、決めてもらえる形に整理することです。

仕様の未決定点を整理して、判断者に確認する。
優先順位を決めるための選択肢を出す。
初回に含める候補と、後回しにできる候補を分ける。

そうすると、仕事は少し動き出します。

また、手戻りを減らすためには、前提を見ることも大事です。

何を作るのか。
誰が使うのか。
誰が決めるのか。
どこまでを今回やるのか。
何をやらないのか。
追加するなら、何を後回しにするのか。

特に大事なのは、「何をやるか」だけでなく、「何をやらないか」です。

複雑なプロジェクトほど、やることは増えやすいです。
「ついでにこれも」
「せっかくならここも」
「将来的にはこれも」

どれも悪い話ではありません。

でも、スケジュールにもリソースにも限りがあります。
何かを増やすなら、何かを後ろに回す必要があります。

優先順位も同じです。

仕事が多いとき、全部が重要に見えることがあります。
全部が急ぎに見えることがあります。
全部を自分で何とかしないといけない気がすることがあります。

でも、全部を同じ重さで抱えると苦しくなります。

期限が近いもの。
人を止めているもの。
手戻りが大きくなりそうなもの。
確認だけ先に出せるもの。
今は見ておくだけでよいもの。
今日はやらなくてよいもの。

それぞれ重さは違います。

優先順位が自分だけで決められないなら、相談してよいと思います。

「AとBが同時に来ています。どちらを先に進めるべきか確認したいです」

このくらいでも、十分相談になります。

全部を頭の中だけで抱え込まない。
決まっていないこと、前提、優先順位を見える形にする。

それだけで、仕事は少し進めやすくなります。

完了条件が見えない仕事は、頭に残り続ける

作業はしているのに、終わった感じがしない仕事があります。

修正した。
確認した。
連絡した。

でも、これで終わりと言ってよいのか分からない。

そういう仕事は、手を動かしていない時間にも頭の中に残ります。

「あれで大丈夫だったかな」
「まだ何か必要だったかもしれない」
「誰かに確認した方がよかったかな」

仕事が終わらないと感じるとき、作業量だけが原因とは限りません。

どこまでやれば終わりなのか。
誰がOKを出せば完了なのか。
何を確認すればよいのか。
何を今回は含めないのか。

そういう完了条件が曖昧なままだと、作業が進んでも仕事を手放しにくくなります。

特にSEの仕事では、作業の完了と仕事の完了がずれることがあります。

コードを書いたら終わりなのか。
テストまで終わればよいのか。
レビュー反映まで含むのか。
リリース後の確認も必要なのか。
ドキュメント更新や関係者への連絡も含むのか。

ここが曖昧だと、「まだ何か残っているかもしれない」という感覚が続きます。

だから私は、仕事が重く感じるときほど、完了条件を見るようにしています。

「ここまで対応すれば完了でよいですか」
「確認はこの範囲まででよいですか」
「このケースは今回は対象外でよいですか」
「誰のOKが出たら完了と考えればよいですか」

こうやって、終わり方を見える形にしておく。

完了条件が見えると、仕事は少し手放しやすくなります。
終わりが見えると、途中で止めたときにも再開しやすくなります。

仕事を終わらせるために必要なのは、作業を増やすことだけではありません。

何をもって完了とするかを確認することも、仕事を頭の中だけで抱え込まないための大事な工夫だと思っています。

途中で止めても、再開できる形にしておく

仕事は、いつも最後まで一気に進められるとは限りません。

急な問い合わせが来る。
会議に呼ばれる。
別の対応を優先する。
判断待ちになる。
疲れて、一度手を止める。

そういうことは普通にあります。

中断は失敗ではありません。
実務では、中断されることを前提にしておいた方がよい場面もあります。

ただ、何も残さずに作業を止めると、戻ってきたときに困ります。

どこまでやったっけ。
何を確認していたんだっけ。
次に何を見る予定だったっけ。
何がまだ決まっていなかったんだっけ。

再開するときに、まず思い出すところから始めることになります。

これは地味に疲れます。

だから私は、作業を途中で止めるときは、再開できる形にしておくことが大事だと思っています。

ここまでやった。
次に見ること。
まだ確認していないこと。
判断待ちのこと。
気になっていること。
今は保留にしたこと。

全部を書けなくても、「次はこれを見る」だけで十分です。

次はエラーログを見る。
設定ファイルの差分を確認する。
レビューコメントの3つ目から再開する。
検証環境で再現するか確認する。
明日はここから見る。

この一行があるだけで、未来の自分はかなり助かります。

仕事を中断しないように頑張るだけではなく、中断しても戻れるようにしておく。

それも、仕事を頭の中だけで抱え込まないための工夫だと思っています。

疲れているときほど、大事な判断を急がない

疲れているときは、判断が少し雑になりやすいです。

たぶん大丈夫。
もうこれでいい。
あとで何とかなる。
これ以上聞くのは面倒。
説明する気力がない。

そう思うことがあります。

これは、性格の問題ではないと思っています。
単純に、余裕が減っている状態です。

仕事では、時間や人手をリソースとして考えます。
それと同じように、判断力にも限りがあると思っています。

一日に何度も判断していると、だんだん雑になります。
最初は丁寧に考えられていたことでも、疲れてくると「もうこれでいいか」となりやすいです。

だから私は、難しい判断はできるだけ午前中などの早い時間にやるようにしています。
疲れているときは、時間が遅くなるほど判断を間違えやすくなると感じているからです。

可能であれば、次の日に延期することもあります。

もちろん、仕事なので今すぐ決めなければならないこともあります。
すべてを後回しにできるわけではありません。

でも、急がなくてよい重要な判断まで、疲れた状態で無理に決める必要はないと思っています。

今決めること。
後で決めてもよいこと。
誰かに確認してから決めること。
材料をそろえてから決めること。

それを分けるだけでも、判断は少し落ち着きます。

「今は判断しない」と決めることは、逃げではありません。
雑な判断を避けるための判断です。

疲れているときほど、結論を出すより先に、判断できる状態を作る。

それは、仕事を止めるためではなく、あとから大きく戻らないようにするための工夫だと思っています。

まとめ

仕事が進まないとき、自分の能力だけを責めなくてもいいと思います。
もちろん、勉強が必要なこともあります。
確認不足を反省した方がいいこともあります。
もっと早く相談すればよかったと思うこともあります。

でも、仕事が重くなる原因は、それだけではありません。

ただ、頭の中にあるものが多すぎて、見えなくなっているだけかもしれません。

不明点を一つ書く。
不安を問いにする。
困る前に少し相談する。
雑なメモで頭の外に出す。
「たぶん大丈夫」を確認に変える。
決まっていないことを見る。
前提を確認する。
優先順位を相談する。
完了条件を見る。
途中で止めるときは、次に見ることを一行残す。
疲れているときは、大事な判断を急がない。

一つひとつは、小さなことです。

でも、その小さなことが、仕事を頭の中だけで抱え込まないための助けになります。

仕事は、一人で全部を背負うものではありません。
頭の中だけで何とかしようとしなくてもいい。

分からないことや不安や判断を、自分の中だけで抱え続けるのではなく、書き出す。問いにする。人に相談する。前提を確認する。優先順位や完了条件を見える形にする。

そうやって、頭の中にある重さを、扱える形に変えていく。

それは、楽をするためだけではありません。
仕事を安全に進めるためでもあります。
自分を必要以上に責めないためでもあります。
長く働き続けるためでもあります。

仕事が重くなるのは、能力不足だけではない。
不明点や不安や判断を、頭の中だけで抱え込んでいるからかもしれない。

そう気づけるだけで、少し呼吸がしやすくなることがあります。

頭の中だけで抱え込まなくていい。

仕事は、一人で全部を背負うものではなく、見える形にして、少しずつ進めていくものだと思っています。

明日から試してほしいこと

1. ToDoを書く前に、「分からないこと」を一つ書く。

2. 「たぶん大丈夫」と思ったら、何を確認すれば大丈夫と言えるのかを考える。

3. 仕事を終える前に、「次に見ること」を一行だけ残す。

#創作大賞2026 #ビジネス部門 #仕事術 #エンジニア #SE #システム開発 #思考整理 #働き方 #タスク管理

この記事を読んでくださり、ありがとうございました。
このnoteでは、現役SEとして約20年働く中で感じた「仕事を少し楽にする考え方」を発信しています。

📚 はじめての方はこちら
▶現役SE20年で学んだ「仕事を少し楽にする考え方」

📚 「仕事を頭の中だけで抱え込まない」シリーズ一覧
複雑な仕事を前にしたとき、頭の中だけで抱え込まないために私が意識していることをまとめています。
▶ 頭の中だけで抱え込まないシリーズを見る

📚 「仕事を続けるために、自分を整える」シリーズ一覧
仕事を続けていくために、自分の状態を整える工夫をまとめています。
▶ 自分を整えるシリーズを見る

🎁 SEあるあるグッズ
仕事が少し楽しくなるステッカーやキーホルダーを作っています。
▶ SEあるあるグッズを見てみる