もう仕事に追われたくない！自分起点で楽しく働くための自己管理術

はじめに

仕事に追われる日々から解放され快適に楽しく働くことができる環境を実現するためには、自己管理が重要です。ここでいう「仕事に追われず快適に楽しく働ける状態」とは、自分自身で意思決定を行い、仕事の進行を自らコントロールする能力を身につけることを意味します。
多くのエンジニアは仕事の量や複雑さに圧倒され、自分のペースで仕事を進めることができないという状況に直面しています。しかし、自己管理スキルを身につけることでこれらの課題を乗り越え、より自分起点な働き方が可能になります。
この記事では、よく起きがちな問題とあわせて自己管理を強化するための具体的な方法を示します。

1. 他の人から見て何をやっているかわからない問題

• 主要なポイント
  • 「あれってどうなってます？」って聞かれていませんか？
    これを頻繁に聞かれる場合、確実に何やっているかわからない人だと思われています
    タスクの状態は、必ず聞かれる前にこちらから状況共有するのが鉄則です
• 具体的な例やエピソード
  • 何をやっているのかわからないことがなぜ問題なのか
    • 何をやっているのかわからない場合、以下の問題が潜んでいる場合があります
      • 進捗が悪いままタスクを抱え込んでしまっているかもしれない
      • タスクのゴールを勘違いしてしまっているかもしれない
      • 他の人と同じタスクを重複して取ってしまっているかもしれない
  • なにかボトルネックがある場合は早期に気づいて、チームとしては解消に動きたいです
    • 抱え込んでしまうと、チームとしての課題発見・対応が遅れてしまい問題が大きくなってしまうことがある
      • NOTE: なぜ報告が遅れてしまうのか
        「タスクが遅れそうです」と報告することで、「遅れそうなことが確定する」から、チームに迷惑をかけたくないがために遅れを確定させたくないという気持ちがはたらきます
        「今は少しうまくいっていないけど、もう少し頑張れば取り戻せるはず！」と考えれば損失（遅れ）から目を背けることができるので、報告よりもタスクを優先してしまうことが多くあります
        あなただけではなく全人類にこの損失確定回避バイアス（今名付けました）がかかっているので気にすることはありません
        （僕も今損失確定を回避するために、夜遅くにこの記事を頑張って書いています）
        遅れることが確定するギリギリまでタスクを持ち続けて「やっぱり間に合いません」と言うと、上司やチームメンバーとしてはリカバリーできる手段がかなり限られてしまいます
        信頼を大きく損ねてしまうので注意しましょう
  • タスクの進行状況が不明瞭なのは、バッチ処理の進行状況を確認できない状況に似ています
    • 例
      • 良くないバッチ
        僕: このバッチは30分くらいで終わるやろ（バッチを叩く）
        バッチログ: ...
        僕: 様子はわからんけどまぁ動いてるやろ
        バッチログ(2時間後) : ...
        僕: あれ、なんか問題あった？！ちゃんとログ吐いてたらもっとはやく気づけたのに・・・
      • 良いバッチ
        僕: このバッチは30分くらいで終わるやろ（バッチを叩く）
        バッチログ(10分後): 120件中10件処理おわったで！
        僕: あれ、30分で終わる想定だったけどこのままいくと2時間くらいかかりそうだなぁ...それなら処理を高速化してみるか
        僕: 30分かけてバッチ高速化完了！いやー最初の10分で重いことがわかったから、時間を無駄にせずに対策できたわ〜
    • 解説
      良くないバッチの例では問題を早期発見できていないので、何も対応ができませんでした
      一方良いバッチは、10分で想定と実態のズレを検知できたので、高速化してみるという手段でリカバリーできました
      報告を早期にすることはまさにこのためで、締切間際に「間に合いません」と言われても打つ手がないのです
      まだ時間が多く残っている状態であれば、多くのリカバリープランが残されていることが多いです
      これが周りからみた「助けやすい状態」です
      「このタスクって方向性ややり方ってあってるのかな」と不安があるときほど共有を増やして、助けてもらいやすい状態を維持しましょう
• 対策（初歩）
  • 分報を徹底する
    • 分報とは
      分報とは、日報の分単位バージョンです
      日報は1日に1回ですが、1日に1回だと共有のタイミングが遅すぎることから、分単位で共有していこう！という考え方で生まれたものが分報です
      ただし、僕は1分単位でつぶやかないといけないとは思っていません
      最大1時間までの幅で、作業内容やこれからやること、困っていることなどをTwitter(X)に書くように吐き出していきましょう
      慣れてきたら思ったことをどんどん吐き出していくのがおすすめです
      参考: 入社一ヶ月の分報戦記（Ubie）
    • どうやるのか
      • 30分に1回、今までやったこと、次にやることを書いてslackのtimesチャンネルまたはチームのチャンネルに投稿しましょう
        同じ作業内容が3回つづいたら、想定よりタスクが遅れていることをチームに報告するなど、できるだけ機械的に判断できるようにしておきましょう
        慣れてきたらWorking Out Loud （常にアウトプットしながら物事を考える思考様式）をやっていくのもおすすめです
      • 例: 分報の書き方
        やったこと
        xxチケットにて、migrationファイルを生成してテーブル作成のPullRequestを作った (PullRequestのリンク)
        次にやること
        xxチケットにて、xx modelに処理を追加する
      • コツ
        できる限り具体的に書くとより助けてもらいやすくなりますし、自分のタスクがなにかに中断されても復帰しやすくなります
        commitの粒度を細かくして、できるだけGitHubのリンクで共有できるようにしておくとより良いと思います
    • なぜやるのか
      • 分報は自分の進捗をチームに可視化し、必要なサポートを受けやすくするために不可欠です
      • 全人類に損失確定回避バイアスがかかっているので、損失確定回避バイアスから逃れる仕組みづくりが重要であるためです
        • もし"同じ作業内容が3回つづいたらチームに報告する" ができなくても、分報を書き続けていればチームの誰かが「大丈夫ですか？」と声をかけてくれるかもしれません
      • NOTE: 分報はタスクのゴールを勘違いしている場合も早期発見に繋がる可能性を高めます
        例えば、今からチームでサンドウィッチをつくりましょう！となりました
        チームメンバーはハムや食パンなどを買っています
        ところが自分だけ餅米を買っていたらどうでしょうか？
        チームメンバーから「え、なんでサンドウィッチ作るのに餅米買ってるの！？」とツッコまれますよね
        タスクが見えている場合は買うタイミングで気付けます
        しかしタスクが見えにくい状態だと、下手したら餅をつき始めて気づくなんてこともあります
        分報を徹底することで、「今から餅米買うぞ！」を大声で言ったらツッコミが入って軌道修正してもらえる可能性を高めます
        なので、分報はチームメンバーからみてわかりやすく書くことを心がけましょう
    • Tips: 途中でも共有しましょう
      • タスクが100%終わってなくてもガンガン共有しましょう
        20%しか終わっていなかったとしても、「現状20%くらいの完成度ですが確認してもらえますか」と前置きした状態での共有であれば全く問題ありません
• 対策（発展）
  • タスクを引き受けた瞬間に、これからの作業イメージや完了後の状態を共有する
    • どうやるのか
      • タスクを引き受けたときにやっておきたい確認例
        • なぜこの仕事をやるべきなのか
          • 「改めて確認ですが、この仕事をやる理由はxxであってますか？」
        • タスク完了後にどういう状態になっていてほしいか
          • 「この仕事が完了したらxxという状態になっている想定ですがあってますか？」
        • 進め方の確認
          • 「xxの箇所にデータ不整合があるかもしれないという調査タスクを進めるにあたって、進め方の確認させてください
            まず半日程度かけて〇〇と△△という調査をする予定で、それでも解消しなかったらXXをしようと思っています
            半日の調査結果次第で動き方が変わる可能性が高いので、半日調査時点で状況共有させてください
            この進め方・共有のタイミングで問題ないでしょうか？」

2. ポジションを取らないことで、他の人に意思決定を委ねてしまう問題

• 主要なポイント
  • エンジニアの仕事で最も価値が高いものは、ポジションを取り「意思決定する」ことです
• 具体的な例やエピソード
  • 「ポジションを取る」とは？
    • 選択肢にA,Bがあるときに、「僕はxxという理由でAが良いと思います」と主張を明確にすることです
  • なぜポジションを取る必要があるのか
    • ポジションを取って初めて、チームメンバーや上司から「なんでそれを選んだんですか？」「xxの観点って考えられてますか？」などフィードバックをもらうことができます
      このフィードバックに対して1つ1つ説明をしていくことで、自分がわかっていること・わかっていないことが明確になります
  • NOTE: ポジションを取ることで初めて脳が動く
    • 僕のポジションを取るときと取らないときの頭の中はこんな感じです
      • ポジションを取るとき
        僕: （AかBか決めたいな）
        僕: （Aがいいかな）
        脳: （本当に？どれくらいAがいいの？）
        僕: （A:60, B:40くらいでAがいいなぁ）
        脳: （なんでAってBより20多いの？どういう要因？）
        僕: （20多い理由はxxだからかな・・）
        僕: xxという理由でAが良いと思います
      • ポジションを取らないとき
        僕: （AでもBでもどっちでもいいな）
        脳: ...（思考停止）
    • 人はなにかを決めるときに損をしたくないというバイアスが働くので、その瞬間に脳が動きます
      Amazonでポチる瞬間、Uberで食べたいものを選ぶ瞬間、松屋で券売機を押す瞬間に実はみんなポジションを取っています（理由を聞かれることはありませんが）
• 対策（初歩）
  • 「xxという前提だったら、yyという理由でAがいいと思いますがどう思いますか？」という形で、余白を残しつつ理由や根拠を明確にして主張することで、他のメンバーからのフィードバックを受け入れやすい形で提示しましょう
• 対策（発展）
  • 何も意見を持たない相談ではなく自分の意見を含めた提案にすることで、組織としての意思決定スピードを大幅に上げることができます
    （もちろん全くわからない場合は無理に提案する必要はないです）
    • 上級
      • 「自分はxxという理由でAにしようと思っていますが問題ないですか？」→承認者「問題ないです！」
    • 中級
      • 「自分はxxという理由でAが良いと思いますがどう思いますか？」→承認者「この観点が足りないので考慮をお願いします」
    • 初級
      • 「どうすればいいですか？」

3. 遠慮して質問しないことで、ドメイン知識（業務知識）が身につかない問題

• 主要なポイント
  • 初期に自分が納得するまで質問しないと、後で議論についていけなくなります
• 具体的な例やエピソード
  • なぜ気をつけるべきか
    • 質問を遠慮してしまうことで重要な業務知識の習得が遅れ、結果として開発効率が低下します
    • 新しくプロダクトに関わるタイミング、新しいプロジェクトに関わるタイミングの一番最初こそがなんでも聞けるタイミング
      「N年もいるのにこんなことも知らないんですか？」と思われるとつらいですね
  • プロダクトに関わる初期や、プロジェクト初期ほど納得するまでしつこく質問しましょう
    • なぜやったほうがいいか
      • 議論はいくつもの前提の上に成り立っている
        • 前提となるドメイン知識を持っていないと、濃い議論ができない
• 対策
  • 特にわからないものがないと感じても、「xxという理解で合ってますか？」と自分の理解があっているかを確認しましょう
    頭の中でわかった気になるのと、声に出して確認するのとは大きな違いがある
  • NOTE: 「チームの時間を自分の理解のために使ってもらうなんて気が引けるなぁ」という人へ
    自分ばかりが質問しつづけていると、チームの時間を奪っているような気持ちになりますよね
    「早くチームに貢献したい」と思う気持ちもわかりますが、1,2年後にしっかり返せばいいんです
    僕は遠慮し続けて何も質問しない人よりも、不器用でもいいからとにかく理解しようとする人のほうが応援したくなります
  • NOTE: 初期に質問できてなかったなと後悔している人へ
    最も質問しやすいのは初期ではありますが、もし現時点で議論についていけていないのであれば今から少しずつでも質問・確認しましょう
    ドメイン知識を頑張って得る行動で支払ったコストは中期的に、確実に回収できます

おわりに

まとめると以下のアクションはやって損はないものなので、もしやっていないものがあれば試してみてください

1. 作業を見える化するために分報を徹底する、作業イメージを予め確認する
2. ポジションをとって意思決定の主体を自分にし、「自分はこう思いますがどう思いますか？」という言い方にする
3. 遠慮せずに質問し、理解の確認をすることでドメイン知識を獲得する

付録

書ききれなかったけど大事な考え方