子の急な発熱で、その日に予定していた本業以外の作業がすべて吹き飛ぶ日が月に1〜2回はある。結論から書くと、私はこの日を「取り返す日」にしようとするのをやめた。取り返そうとするから焦り、焦るから判断を誤る。今回は、発熱当日に何をどう止め、翌日以降どう立て直しているか、その手順を書く。

目次

発熱当日にまずやること

朝、子が発熱していると分かった瞬間にやるのは、その日の予定の「全消し」ではなく「仕分け」だ。私は次の3段階で判断している。

  1. 本業(FDE): クライアントとの打ち合わせが入っていれば、可能な限りリスケを依頼する。事前に日程を動かせる余地があるかを確認しておくのが前提で、当日連絡でも受け入れてもらえる関係性を普段から作っておくことが重要だと感じている
  2. 複業4事業のうち「締切があるタスク」: たとえばafflowの投稿予約や、storeforgeの注文対応など、期日を動かせない作業だけをリストアップする。これだけは看病の合間の数分ででも処理する
  3. それ以外すべて: 「今日やる予定だったが期日はない」タスクは、その場で今日のリストから外す。翌日に回すのではなく、いったん存在ごと視界から消す

この仕分けにかける時間は5分もかけない。迷っている時間があるなら、まず子のそばにいた方がいい。

「取り返そうとしない」判断基準

発熱2日目以降、看病をしながら「昨日できなかった分を今日で取り返そう」という発想が一番危険だと考えている。理由は、看病中の集中力は平常時の半分以下で、無理に詰め込んだタスクの質が落ちるからだ。質の落ちた状態でafflowの記事を書いても、storeforgeの商品ページを作っても、後で手直しが必要になり、結局トータルの時間はむしろ増える。

そこで私は「取り返す」ではなく「止まった期間をなかったことにする」という基準に切り替えている。具体的には次のように考える。

  • その週の複業の目標を達成できなくても、翌週に単純に繰り越す。前借りではなく仕切り直しとして扱う
  • 看病中に多少でも手が空いた時間があれば、新しいタスクには着手せず、止まっていたタスクの「再開しやすい状態」を作ることだけに使う。次に座ったときすぐ手が動くようにメモを残す、程度の作業に留める
  • 本業のクライアントワークだけは別枠で考える。複業は繰り越せても、本業の信頼は繰り越せないので、優先順位は常に本業が最上位

この基準を持つ前は、発熱が明けた直後の週に無理な巻き返しをして、結局本業の集中力まで落ちるという失敗を何度かした。取り返そうとする発想自体が、次の失敗の種になっていた。

事業を複数持っていることが緩衝材になる

発熱による停止の影響を実際に受けにくくしているのは、複業を4事業並行している構造そのものだ。前回までの記事で書いた通り、事業ごとに検証フェーズやボトルネックが異なるため、1つの事業が丸ごと止まっても他の事業への影響は限定的になる。

たとえば発熱期間中、aerial-earth-studioの動画レンダリングが数日止まっても、それは「積み上げ型」の作業なので後から再開すればいい。一方でafflowの投稿は、予約投稿の仕組みを事前に作ってあるおかげで、看病期間中も配信自体は止まらない。1つの事業に全リソースを賭けていたら、発熱のたびに事業全体が完全停止していたはずだ。複業を並行する理由の1つに「体調不良への耐性」を挙げていなかったが、実際に運用してみて、これは想定以上に効いていると感じている。

立て直しのチェックリスト

発熱が明けて子の体調が戻ったら、次の順番で立て直している。これは実際に毎回使っている手順そのものだ。

このチェックリストの肝は最後の1点で、止まっていた事業を優遇して配分を歪めないことだと考えている。歪めた配分は次の発熱でまた崩れ、毎回イレギュラー対応に追われる悪循環になる。

まとめ

  • 発熱当日は「全消し」ではなく「本業→締切ありタスク→それ以外」の3段階で仕分けし、判断に時間をかけない
  • 看病中は「取り返す」のではなく「止まった期間をなかったことにする」基準に切り替える。前借りの発想は質の低下を招く
  • 複業を複数事業並行しているおかげで、1つの事業が止まっても他への影響が限定的になり、体調不良への耐性として機能している
  • 立て直し時は平常時の配分に単純に戻すことを優先し、止まっていた事業を優遇して配分を歪めない

次回は、この仕分けと立て直しを支えている、複業タスクの「期日の有無」をどう事前に設計しているかを書く。

Twitterでフォローしよう

おすすめの記事