はじめに
入社以来5,6年の間、ほとんど一つの案件にアサイン比率100%で取り組んできました。たまに10%くらいのアサインもありましたが、それくらいなら気合で乗り切れました。気合です。「人間最後は気合でどうとでもなるもんです。」そんな考えが跡形もなく打ち砕かれた半年の思いを取り留めもなく書きます。
勘違い pt1: 気合でなんとかしようとするな
今の私は3つくらいのプロジェクトに参加していて、だいたい50%, 30%, 20%くらいのアサイン比率です。こういうアサイン比率のとき「どうやって働くか」っていうのがより重要になると思います。4月時点のわたしの武器は「気合」しかありませんでしたが、例えば日を分けて「今日はA案件、明日はB案件」と日ごとに区切って一日をフルで1つの案件に割り当てるとか、一日の中で時間を割り当てて（あるいは測定して）いい感じにするとか。これらのやり方にはかなり個人の得手不得手が絡むので模索して見つける他ないと思います。4月時点では張り切っていたのでTogglで時間を測定しつつ、「お、そろそろこっちやっちゃおうかな♪」みたいな具合でした。ただ、私のような人間は（想像に難くないですが）Togglは大概押し忘れます。計測系のアプリで一つデータを間違うとシッチャカメッチャカになってモチベが一撃で失われるので4月下旬にはやめてました。
Togglで心折れた私の頭の中に奇案が浮かびました。「せや！気合でなんとかしたろ！結局時間測定なんていらんかったんや！仕事は終わらせたもん勝ちや！」振り返ってみると、この決断は素人がエベレストに普段着で行くくらい無謀でした。終わらないタスク、どころかなかなか進まないタスク。それによって生じる焦燥感。そして更にスタックしていくという悪循環。そもそもなんで、こんな奇妙な判断になったか。仕事で一つの案件しかしていないと、目の前のタスクさえ捌ければ最悪仕事は回ります。それこそ気合でなんとかなることもしばしば。（たまにならずに爆散する）そのような習慣が染み付いた結果、思考としては「アウトプットを出してなんぼ」という方向に傾いて行きました。
「なんとかしてアウトプットを」。今でもたまに頭を掠めますが、何かを実装しているときに「まず最低限レベルのコードを書いて要件を満たそう」という動きをすることがあります。これは期限に間に合わずリリースもできないレベルの事態を回避するための習慣でした。なにも最低限レベルのコードをレビューに出すつもりはありません、そこからブラッシュアップはして品質を上げてからレビューには出す。こういった流れです。この働き方事態が悪とまで言い切れる証拠が僕にはないですが(結果的に期限内に品質が担保されているコードが出てればいいと思うので進め方までは否定したくない)、複数案件でやるときに私の場合は悪手でした。
勘違い pt2: アウトプットは想定より下がる
話を進める前にもう一つ私がしていた勘違いを紹介します。4月より前の私の一日のアウトプット量が100だとしたとき、4月からの複数案件でどれくらいアウトプットできるだろうかということです。理想としては比率通りに、50%, 30%, 20%のアウトプットが日々できればいいですがさすがの私も「スイッチングコスト」なるものがあることは伝え聞いてました。「スイッチングコスト？まぁ消費税くらい掛かるとして、45%, 27%, 18%くらい？いや、もう少し掛かるかもな。よし、なんでもいい気合だ」
ここでスイッチングコストについて同僚のGeminiに聞いてみました。
1. 認知的オーバーヘッド（思考の切り替え）
これが最も大きなコストです。脳が新しいタスクに必要な文脈（コンテキスト）を読み込み直すために費やす時間です。
- 集中力の損失: 以前の案件の思考パターンから抜け出し、新しい案件の独特なルール、用語、目標を思い出すための時間。
- 文脈の再構築: 「今からA社の案件をやるから、A社の環境、仕様書、最近のバグ、次期リリース目標を頭に入れ直そう」という作業。
2. 環境的なオーバーヘッド（ツールの切り替え）
物理的・技術的な環境を切り替えるためにかかる時間です。
ここにある「文脈の再構築」が一番の曲者でした。改めて考えると、エンジニアのアウトプット量というのはそれほど多くないと私は思います。例えば、一週間掛かったPRがあったとして差分が200~300行くらいだったりすることもザラにあります。それらの行数分のコードを書くことが大変というより、それに至るまでの思考、検討、試行プロセスこそが仕事の大半を占めている。ざっくりですが、たぶん業務時間の8,9割くらいはコードを書いてません。比率で割ると、一日中コードを書けずコードというアウトプットが出せなかったとしても仕方ない日が出てきそうなものです。そんな中アウトプット、というよりもコードに取り憑かれていた私は理想と現実の乖離に薄々気が付きつつもひたすらコードを書いて貢献しようとしていました。
「なんとか気合で今日結果を出そう」としても次の「まだ何も今日結果を出していない」案件が2つも待ってます。必死にやって次の案件にこぎつけたのに「今日まだ進捗0の人」として開始する悲しさを感じつつ働く羽目になります。これがなかなか精神的にきつい。
実装者として入っている以上、実装に関するコンテキストを理解して進めようとするとどうしても一見簡単な実装でも裏取り含めて時間がかかる。ここのコストは小さくできないので確実にアウトプットはめっちゃ減ります。
勘違いを正して
というわけで、コードの固執するのをやめました。コードを書こうとする気持ちを多少抑えて働く。なんとなく思うんですが、コードを書くのは楽しいから非効率でも書いてしまうんですよね。退屈だけど20minで終わるタスクを自動化するために1hコード書きたくなる気持ち。ここまで読んだあなたなら分かりますよね。それをちょっとやめました。
具体的に取り組んだ内容は、Obsidianに3案件分の見出しを用意して、チェックリストを業務時間を比率で分割して、それをさらにポモドーロの1セットごとに分割して用意します。
## Project X - [ ] Set1 - [ ] Set2 - [ ] Set3 - [ ] Set4 - [ ] Set5 - [ ] Set6 - [ ] Set7 ## Project Y - [ ] Set1 - [ ] Set2 - [ ] Set3 - [ ] Set4 - [ ] Set5 ## Project Z - [ ] Set1 - [ ] Set2 - [ ] Set3
おもむろにポモドーロを開始するわけですが、ルールがあります。Set1ではコードを書きません。願わくば2も書きません。スイッチングコストを吸収しつつ、コードリーディングと設計と検討をひたすらやります。3,4くらいから書けそうなら書きますが飛びつかず慎重にやります。コードを書くのは楽しいですが、現実I/Oが伴って負荷が高くなりやすいです。コードを実行すれば待ちが発生したり、実行手順を手動で踏まないといけませんしその結果バグがあったらまたコードの戻って直して実行してを愚直に繰り返すループになりやすいです。コードを実行しなければ歩い程度書いてもいいかもですが、安直に実行するのは危ういです。コードやテストを実行して待っている間にバグを見つけて「あ！」となった事が人生で1000回くらいありますが、それを事前に無くす感じです。「いける」と思ってから1,2個くらいは良くなる所が大概見つかります。
またポモドーロにすることで、一日の掛けて良い時間がパッと見でわかるので案件ごとに着地点を考えながら作業しやすいです。1セット終わったらやったことと次やることをまとめて休息を挟みます。進捗を祝いましょう。
## Project X ... - [x] Set3 Made some changes on widgets and confirmed that Notebook works as I expcted 🎉 - [ ] Set4 Check if XXX is changed when foo() is called ...
自分の頭の中で理解したり検討したりしたことを書き出すことで、物事が進んでいることが把握できる安心感があります。 「困難は分割せよ」という言葉の通り、はじめから一日の時間の割り振りが決まっているとそれに関する脳内のリソースが一掃されます。またObsidianでDailyNoteに書いていると昨日との比較もでき、前回と次回のタスクが一目瞭然でスイッチングコストは減ります。そのうえでコンテキスト理解の時間をルールを課して取ることで生産性は改善しました。
おわりに: 現在の感覚
目標を「いかにアウトプットを提供するか」から「いかに与えられている時間の中で質よく働けたか」にシフトする感覚です。そしてこのやり方に変えてアウトプット量は減ってないと自分では感じています、むしろ増えている気がする。またコードに対する自信も以前より感じます。なにより気持ちよく働けています。至った結論、取り組み内容はシンプルですが良い経験をさせてもらってるなと感じます。(現在進行系)あとはこの時間の中でできるパフォーマンスの質を上げていくことをひたすら頑張ります。
