仕事が進まないとき、私はToDoではなく不明点を書き出す

はじめに

ToDoを書いているのに、仕事が進まない。
むしろToDoが増えるほど、仕事が重く感じることがありました。

20年近くシステム開発に関わってきましたが、振り返ると原因は作業量だけではありませんでした。

「分からないこと」を抱えたまま走ろうとしていたのです。

複雑な仕事を前にすると、私は以前、とにかくToDoリストを作っていました。

やることを洗い出す。
順番を決める。
期限を書く。
担当を決める。

一見すると、とても正しい進め方に見えます。

でも不思議なことに、ToDoを書けば書くほど、仕事が重く感じることがありました。

リストは増える。
終わっても、また次の作業が出てくる。
いつまでたっても終わらない感じがする。

振り返ると、原因は作業量だけではありませんでした。

「分からないこと」を抱えたまま走ろうとしていたのです。

20年近くシステム開発に関わってきて、今はこう考えています。

仕事が進まない原因は、ToDoが足りないことではなく、
「分からないこと」を頭の中に抱えたままにしていることかもしれない。

この記事で伝えたいことは一つです。

複雑な仕事を抱え込まない第一歩は、ToDoを増やすことではなく、不明点を外に出すことです。

頭の中にある不安を、確認できる問いに変える。
それだけで、仕事は少し進めやすくなります。

ToDoを増やしても、仕事が軽くならないことがある

複雑な仕事には、たくさんの情報があります。

何を作るのか。
誰が使うのか。
どこまで対応するのか。
誰に確認すればいいのか。
何がまだ決まっていないのか。
失敗したら何が起きるのか。

こういうものが頭の中に残ったままだと、作業をしていない時間も、ずっと仕事のことを考えてしまいます。

「たぶん大丈夫だと思うけど、本当に大丈夫だろうか」
「これは誰に確認すればいいんだろう」
「ここ、あとで問題にならないかな」

この状態でToDoリストだけを増やすと、さらにしんどくなります。

ToDoリストは「やることの量」を見せます。
でも、仕事が詰まっている原因が不明点にある場合、ToDoを増やしても不安は減りません。

むしろ、「まだこんなに残っている」と感じて、余計に疲れてしまうことがあります。

私が先に作るのは、不明点リスト

私自身、複雑な案件になると、頭の中だけで整理しようとして失敗したことが何度もあります。

考えているつもりでも、実際には同じ不安を何度も思い出しているだけだったりします。

だから今は、なるべく早い段階で「分からないこと」を外に出すようにしています。

複雑な仕事に向き合うとき、私はまず「不明点リスト」を作るようにしています。

不明点リストとは、名前の通り、分かっていないことを書き出すリストです。

これはToDoではありません。
「やること」ではなく、「分からないこと」です。

不明点リストの具体例

例えば、システム移行の仕事なら、こんな形で書き出します。

システム移行案件の不明点リスト

【技術】
□ 移行に使うAPIは本当に利用できるのか
□ 必要な権限は足りているのか
□ 本番データ量はどのくらいあるのか
□ 検証環境と本番環境に差分はないのか

【仕様】
□ 移行対象の範囲は確定しているのか
□ 例外データはどう扱うのか
□ 移行後に誰が確認するのか

【人】
□ 最終判断をする人は誰か
□ 利用者への説明は誰が行うのか
□ 関係部署への連絡は必要か

【リスク】
□ 失敗したときに元に戻せるのか
□ バックアップはあるのか
□ 作業が遅れた場合、何に影響するのか

こうやって書き出すと、仕事の見え方が変わります。

頭の中にあった不安が、確認できる問いになります。
誰に聞けばよいかが見えてきます。
先に潰すべきリスクが分かってきます。

私にとって、ToDoリストは終わらない感じがして疲れることがあります。
一方で、不明点リストは、分からないことが一つずつ減っていく感じがあります。

この違いは、かなり大きいです。

不明点は4つに分けると扱いやすい

不明点を書き出すとき、私はだいたい次の4つに分けて考えます。

1. 技術の不明点

API、性能、権限、データ量、環境差分などです。

例えば、

• このAPIは本当に使えるのか
• 必要な権限はあるのか
• 本番データ量に耐えられるのか
• 検証環境と本番環境に差分はないのか

といったものです。

技術的な不明点は、早めに確認した方が安全です。
後から分かると、作業全体の前提が崩れることがあるからです。

2. 仕様の不明点

何を作るのか。
どこまで対応するのか。
例外パターンをどう扱うのか。
優先順位は何か。

仕様が曖昧なままだと、作業しているつもりでも、あとで大きな手戻りになることがあります。

「たぶんこうだろう」で進めてしまうと、後から認識違いが見つかることがあります。

3. 人の不明点

誰が決めるのか。
誰に確認するのか。
誰が使うのか。
誰に影響があるのか。

システム開発では、技術よりも「誰に確認すればよいか」が分からないことで止まることがあります。

逆に、確認先が分かるだけで、仕事が一気に進み始めることもあります。

4. リスクの不明点

失敗したら何が起きるのか。
戻せるのか。
期限に間に合わない場合どうするのか。
どこまで影響が広がるのか。

作業手順を考える前に、失敗したときのことを先に見るようにしています。

特に移行作業や本番環境に関わる作業では、
「うまくいく手順」だけではなく、
「うまくいかなかったときに戻せるか」
を確認しておくことが大事だと思っています。

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

不明点を書き出して分類すると、「なんとなく不安」が少しずつ具体的になります。

不安なままだと、頭の中で大きくなります。

でも、書き出すと少し変わります。

「大丈夫かな」ではなく、
「APIの利用条件を確認する必要がある」になる。

「なんか危なそう」ではなく、
「ロールバック手順が未確認」になる。

「誰かに聞かないと」ではなく、
「最終判断者を確認する」になる。

不安は、頭の中にあると不安のままです。
でも外に出すと、確認できる問いになります。

この変化が、複雑な仕事を進めるうえで大きいと感じています。

全部を一度に解決しようとしない

不明点リストを作ったら、全部を一気に解決しようとはしません。

先に見るのは、後から分かると手戻りが大きいものです。

次に、自分だけでは判断できないもの。
そして、実際に試してみないと分からないもの。

複雑な仕事ほど、完璧な計画を最初から作ろうとすると苦しくなります。

まず不明点を出す。
大きなものから確認する。
必要なら小さく試す。
結果を見て、次を決める。

この方が、私には合っています。

最初からすべてを決めようとするより、
分からないことを一つずつ減らしていく方が、結果的に仕事は前に進みます。

頭の中で抱え続けること自体が負荷になる

複雑な仕事は、技術的に難しいだけではありません。

頭の中で抱え続けること自体が、かなり負荷になります。

「あれも考えないと」
「これも確認しないと」
「でも何から聞けばいいんだろう」

こういう状態が続くと、判断力も落ちます。

焦っているときや疲れているときほど、不明点を不明点として扱えず、なんとなく進めてしまうことがあります。

だから私は、なるべく早く外に出すようにしています。

頭の中に置き続けるのではなく、文章にする。
箇条書きにする。
必要なら図にする。
人に見せられる形にする。

それだけで、仕事を一人で抱え込んでいる状態から少し抜けられます。

まとめ

仕事が進まないとき、やる気や能力の問題だと思ってしまうことがあります。

でも実際には、分からないことが多すぎて、頭の中で処理しきれなくなっているだけかもしれません。

そんなとき、私はToDoを増やす前に、不明点を書き出します。

ToDoリストは、仕事の量を見せるもの。
不明点リストは、仕事を前に進めるための足場を作るもの。

複雑な仕事を抱え込まない第一歩は、すべてを頭の中で整理しようとしないことだと思います。

分からないことを、外に出す。
見える形にする。
一つずつ確認していく。

それだけで、仕事は少しずつ前に進められるようになります。

20年近くシステム開発をしていますが、今でも複雑な仕事は苦手です。

だからこそ、頭の中だけで整理しようとせず、不明点を外に出します。

複雑な仕事に強い人は、全部を覚えている人ではなく、
「分からないことを見える形にできる人」なのかもしれません。

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

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

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

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

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