この記事はリンクアンドモチベーション AdventCalendar2025 の25日目の記事です。

ご挨拶

こんにちは。
リンクアンドモチベーションでバックエンドエンジニア3年目の中島です。
現在は、プロダクトの継続率を高めるための機能改善プロジェクトにて、設計〜QA・BugFixまで幅広く担当しています。

はじめに

当時の自分は、開発スピードを上げるために
「拾えるタスクは拾い、すぐに返す」ことを最適解だと思っていました。

でも振り返ると、その姿勢は結果として
スイッチングコストを増やし、集中力を削ぐ原因にもなっていました。

そこで自分の中の問いを変えました。
「いかに早く拾うか」ではなく、「そもそも拾わなくていい形にできないか」。

この記事では、その問いに行き着くまでの過程と、
実際に「拾わなくていい前提」を作った事例（test-prof の自動化）をまとめます。

当時の判断：スピードを優先するという選択

私が所属するチームのミッションは、
継続率を高めるため、ユーザー価値を向上させる開発をスピード感をもって届けることです。

その中で、当時の自分は
「まずはスピードを優先しよう」という判断をしていました。

具体的には、

担当が決まっていないタスクを引き取る
できる限り即確認・即レスを心がける
依頼や確認があれば、作業の途中でも一度止めて対応する

といった行動を意識していました。

実際には、

リリース失敗時の原因確認
Sentryエラー検知時の調査
インシデントの恒久対応
定期的な計測・確認作業
データ出し依頼

など、さまざまなタスクを引き受けていました。

「さっと拾って、さっと返す」
当時はそれがチームへの貢献につながると信じていましたが、他の選択肢もあるという視点を十分に持てていませんでした。

気づけばスイッチングコストが積み上がっていた

こうした状態が続く中で、
ある日ふと強い疲労感を覚えました。

振り返ってみると、原因は明確でした。

並行タスクが増え、常に「何かが残っている」感覚がある
一つのタスクを終えても、次に意識を切り替えるのに時間がかかる

何かの途中でも割り込まれ、その都度対応する。
その積み重ねが、スイッチングコストを膨らませていたのだと思います。

それでも当時は、

「とはいえ、チームとしては対応する必要がある」
「きっとチームの負荷軽減にはつながっているだろうし、これでいいはず」

と考え、チームの安定を優先して「拾う」行動を続けていました。

足りなかった視点：「目的立脚」

振り返りの中で、もう一つ気づいたことがあります。
それは 「目的立脚」の視点が十分ではなかった という点です。

タスク単位でも、背景を深く理解しないまま着手してしまい、
結果として手戻りが発生することもありました。

「タスクは目的を理解して進めるべき」
これは当然の話ですが、意識すると確かに改善はありました。

ただ、それでも
スイッチングコストそのものは解消されませんでした。

目的立脚は作業の「質」を上げますが、
並行タスクが多いという問題は残ったままだったのです。

問いを変える：「いかに早く」から「そもそも」へ

そこで、「目的立脚」の視点を踏まえつつ、
改めて問いを見直しました。

これまでの問い
いかに早く拾って、手戻りなく、早く完了させるか？
変えた問い
そもそも、拾わなくていい形にできないか？

スイッチングコストを減らすためには、早く対応する努力だけではなく、
対応が発生しにくい前提を作ることが必要だと考えるようになりました。

実践例：test-prof の運用を「拾わなくていい形」にする

まず手を付けたのが、テストが遅い原因を可視化するツール（test-prof）の運用です。

このツールは、Rubyのテストでどこが時間を消費しているかを把握するために使っています。

ただし、

1回の実行に10〜20分
平均を取るために3回実行
結果整理まで含めると約1時間

という、定期的に発生する手動作業でした。

「手動前提」を外し、仕組みで回す

そこで、この作業を自動化しました。

毎月1日に自動でテストを実行
test-profを3回実行して分析
過去データとの差分を計算
結果をまとめて保存
Slackで通知

人が

実行しにいく
結果をまとめる
共有する

という前提を外し、意識しなくても回る状態を作りました。

もちろん、この仕組み化に1人日ほどの工数は必要でしたが、継続的な割り込み対応を減らす投資だと判断しました。
その結果、手動作業がほぼ0になり、「思い出して対応する」割り込みが消えることで、集中すべき開発に時間を投資しやすくなり、結果としてチーム全体の負荷も下げられました。

「拾う」から「仕組みで回る」へ

今回の取り組みは一例ですが、大きな学びがありました。

手動でやる前提を外せないか
確認の手間を減らせないか

こうした問いを重ねることで、

とにかく拾う状態 → 仕組みで回る状態

に少しずつ近づいていきます。

成果を出すための土台として、必要な即対応は残しつつ、
仕組みで回る領域を増やしていくことが重要だと感じました。

おわりに：今、仕組みで回すことを選択肢に入れてみる

もし今、

自力で回している作業
毎回「ちょっとした確認」が必要な作業

があるなら、こんな問いを立ててみてください。

そもそも、自動化・省力化できないか？
本当に今の形である必要があるか？
変えたいことがあるなら、今ここで仕組みに寄せられないか？

個人の工夫や善意で回っている「ちょっとしたアクション」こそ、
無理なく継続できるように仕組みに寄せられる余地があるのかもしれません。

それを当たり前にすることでスイッチングコストが減り、
本来向き合うべき課題に、きちんと時間を投資できるようになります。

この文章が、誰かにとって
「自分のやり方を見直すきっかけ」になれば嬉しいです。

余談：今回の取り組みを書いてみて

過去に自分が書いた記事で紹介していた test-prof を、
今回あらためて自動化し、その内容を記事としてまとめられたのは感慨深かったです。
（参考）過去記事はこちら：