「整える時間」を先に置いたら、その日のうちにちゃんと進んだ話

朝、開発の画面を開いたとき、抱えていた Open の Issue が 22 件ありました。

22 という数字は、それだけで重たく感じます。
「どれから手をつけよう」と一瞬止まる。
一番気になっているものはあったので、そのまま手をつけてもよかったんです。

でも、私はその日、先に「整える時間」を置きました。

まず棚卸し、を選んだ理由

Claude Code に投げて、Issue を 3 つの観点で見てもらいました。

すでに実装が済んでいて close できるもの。
本文と現状がズレているもの。
別 Issue だけど一緒に解いた方が早いもの。

返ってきたのは、思っていたより穏当な結果でした。
全部を最新化しないと進めない、というほどではなかったんです。

統合できるものが 2 セットあって、それだけ片付けたら 22 件が 20 件になりました。
本文のズレは、そのうち触る Issue に着手したときに書き直す方が筋がいい。
同じ整合性確認を二度やる必要はありません。

棚卸しは「軽く済ませて、本線に戻る」で十分でした。

整えてから進める、を選んだ日

22 件を眺めていたときと、20 件を眺めているときで、頭の中の重さが違いました。

数字は 2 件しか減っていません。
でも、「全部が同じ重さの 22 件」と感じていた状態と、「20 件のうち今選んでいるのは 1 件」と分かっている状態は、全然違うんです。

整えた後の方が、選んでいる自分が見える。

そのまま、一番気になっていた #130 (広告ブロッカーで書込が止まったときに、ユーザーに静かな警告を出すやつ) に入りました。

実装途中で、Chrome ウェブストアのポリシーに引っかからないかを確認したり、二段で検出する方が取りこぼしが減ると判断したり、検証できない部分は深追いせずに進めたり。
小さい判断をいくつも積み重ねました。

夜には、その Issue が close されていました。

Open 20 件 → 19 件。

整える時間と進める時間は、対立しない

「整える時間」というと、何かを生み出していない時間のように見えます。
Issue を眺めて、まとめて、消す。
実装が 1 行も進んでいない時間。

ただ、その日に分かったのは、整える時間を 30 分置いた方が、その日に進む量はむしろ多くなるということでした。

22 件のまま手をつけたら、たぶん #130 の途中で「これって統合した方がよくないかな」と思ったり、「これって本文と違うことやってない？」と途中で立ち止まったりしていたはずです。
手を動かしながら整理する作業は、片方が片方を邪魔して、両方が遅くなる。

先に整える。
整え終わったら、整えたものに従って進む。

順番をひっくり返さない。

「全部を最新化しよう」とは思わない

棚卸しの大事な学びは、「全部やる」と決めなかったことかもしれません。

本文がズレている Issue は何件かありました。
でも、それを今全部書き直すと、棚卸しが半日仕事になります。
そして書き直したところで、その Issue を実装するときにはまた状況が変わっているはずです。

「整える」を「完璧にする」と読み替えてしまうと、整える時間が暴走します。

軽く整えて、進む。

進んでいる途中で、また整える瞬間が来たら、その時に整える。

それくらいの距離感の方が、結局は進みます。

順番をちゃんと選んだから着地できた

その日の終わりに思ったのは、「順番を選んだから着地できた」ということでした。

22 件のまま突進していたら、たぶん #130 は途中で止まっていたか、close まで届かなかったと思います。

途中で迷うたびに、Issue 一覧に戻って「あれ、これ別 Issue とくっつけられない？」「これ本文書き直さなくていい？」と気を取られたはずだから。

朝に 30 分整える。
その後は決めたことに従って手を動かす。

その日は、それだけのことでした。

派手な進捗ではないけれど、「整えてから動く」を選んだことで、ちゃんと夜にひとつ着地していました。

整える時間が、ものを前に進めるんだなと、思いました。

かなえ

個人開発を応援する非エンジニア

婚約破棄をきっかけに、29歳で未婚の母になると決めました。
不安と向き合いながら、10年かけて働き方を少しずつ作り変えてきた40代です。

AppSheetやGASを独学で覚え、いまはAIを使った個人開発を毎日続けています。
個人開発を応援する非エンジニアとして、等身大の試行錯誤や、子育て・自立・副業のことを、正直に記録しています。