エンジニアのタスクは９割が重要ではない話

「タスクが多すぎる」 このセリフを言った（思った）ことがないエンジニアはまずいないと思います。 チケットは積み上がり、 Slackや問い合わせチャットは鳴りやまず、 カレンダーは会議で埋まり、 気づけば「今日は何も進んでいない」という日が量産されている事でしょう。 そのタスク、本当に必要なタスクなんですか？ こう聞くと、「いや、でもやらなきゃいけないし・・・」と答えるエンジニアが多いのも事実。 この罠とも言える、タスクの山状態は、「アイゼンハワーマトリクスという思考術を使うといい」という話を聞いたので、ご紹介したいと思います。

アイゼンハワーマトリクスという“仕分け機”

この話をする上で避けて通れないのが、ドワイト・D・アイゼンハワーの名を冠したアイゼンハワーマトリクス。 このフレームワークはタスクを「重要(important)」と「緊急()Urgent」の2軸で分類する、いわば思考の仕分け機である。 ポイントはシンプルなんですが、まあまあ残酷なんですよこれが。 人は“重要”ではなく“緊急”に反応するということがわかります。 例えば、突然の障害対応や上司からの「ちょっといい？」は、ほぼ無条件で最優先になる。 一方で、設計の見直しやスキルアップのような“重要だが緊急ではないもの”は、いつでも後回しにされる。 そして、自分の一日は、「緊急だけど重要ではないもの」と「なんとなくやっているだけのもの」で埋まっていることに気がつくんです。 ここで冒頭の仮説に戻ると、エンジニアのタスクは9割が重要ではない。 これは誇張でもなんでもなく、むしろ体感に近い人も多いはずじゃないでしょうか。

なぜ重要でないタスクに支配されるのか

ではなぜ、そんな状態になるのかというと、理由は単純で、「重要ではないタスクのほうがやりやすい」からなんですよ。 重要なタスクというのは、大抵の場合、重いし、しんどいことの方が多い。 抽象度が高く、正解がなく、すぐに成果が出ない。 設計改善やアーキテクチャの見直し、技術選定などは典型例。 やるべきだと分かっていても、手をつけるにはエネルギーがいるという事なんですね。 一方で、重要ではないタスクは軽いし何も考えなくていいことが多い。 返信すれば終わるチャット、 ちょっとした修正、 場を埋めるための会議。 これらは達成感すら伴う。 「今日も仕事したな」という錯覚を簡単に作り出す。 （実際は何もやってないことの方が多いのに） つまり、人は「簡単に終わる仕事で満足感を得る」ことで、本当に重要な仕事から逃げていると考えてもいい。 そして怖いのはここからだ。 “重要だけど緊急ではないタスク”を放置し続けると、ある日突然“緊急かつ重要な状態”に昇格する。 技術負債はある日爆発し、未学習の領域は急にキャッチアップを要求される。 健康は突然壊れ、人間関係は気づいた時には修復困難になる。 未来の自分が、過去の自分のツケを払わされる構造がここにあるんです。

重要な1割にどう向き合うか

ではどうすればいいのかというと。 答えはシンプルだけど難しい。 「重要だけど緊急ではないこと」を先にやるしかないんです。 これは根性論ではなく、構造の問題なんですね。 意識しない限り、人は必ず緊急タスクに流される生き物。 だからこそ、意図的に時間を確保しないといけない。 例えば、カレンダーにあらかじめブロックを入れる。 会議よりも先に“考える時間”を予約する。 Slackやチャットなど（スマホやメールなども）を閉じる時間を作る。 そういった小さな設計が、重要な1割を守ることにつながる。 逆に言えば、それをやらない限り、9割の“重要ではないタスク”に一生を消費することになりかねないんですよ。 少し乱暴に言えば、 タスクが多いのではなく、重要なタスクが少なすぎるのだ。

あとがき

ここまで読んで、「いや、自分のタスクはちゃんと重要だし…」と思った人もいるかもしれない。 でも安心してほしい。 この記事を書いている自分も、さっきまで仕事のチャットの通知を眺めながら「これ大事そうだな」と思っていたんですから。 そしてふと気づく。 この記事を書くこと自体、“緊急ではないけど重要なこと”だったのではないかと。 つまり何が言いたいかというと、 このブログを書いている間にも、いくつかの“緊急そうな通知”を無視しているわけである。 そしてたぶん、それらの9割は重要ではないから後回しでも全然OKと考える自分。 …と、ここまで書いたところでスマホが鳴った。 さて、これはどの象限だろうか。 アイゼンハワーマトリクスで思考してみるとしよう。