技術を追うのをやめたら開発速度が上がった話

新しい技術を追いかけるのをやめたら、逆に開発が進むようになりました。私が決めた「追わない基準」を全部書きます。

去年の今ごろの私は、タイムラインに知らないフレームワークの名前が流れてくるたびに、そわそわしていました。「これ、触っておかないとまずいのでは」。そう思ってブックマークして、週末に少しだけ試して、結局何も作らないまま次の新しい名前が流れてくる。その繰り返しでした。

ブックマークフォルダには、名前だけ知っている技術が50個くらい溜まっていました。触ったのは、たぶん5個もない。残りの45個は、私にとって「知らないことへの罪悪感」を溜めておく箱になっていました。

今年に入ってから、私はこれをやめました。正確に言うと、追いかける対象をかなり絞りました。結果として、手元のプロジェクトが前に進むようになった。この記事では、何を基準に見送ることにしたのか、やめてみて実際に何が変わったのかを、できるだけ具体的に書きます。

全部追いかけていた頃、私は何も作れていなかった

当時の私の週末は、だいたいこうでした。土曜の午前に話題の技術のドキュメントを開く。チュートリアルを写経する。「なるほど、こういう感じか」と分かった気になる。日曜になると別の話題が流れてきて、そっちに移る。

一週間経つと、頭に残っているのは断片だけです。書いたコードはチュートリアルのコピーなので、自分の課題に結びついていない。当然、次に同じ技術を触るときには、また最初から読み直すことになります。

一番まずかったのは、自分のプロジェクトが止まっていたことでした。作りかけのツールがあって、あと少しで人に見せられる状態だったのに、そこには手をつけていない。新しい技術を触っている時間のほうが、なんとなく「成長している感じ」がしたからです。

でも実際には、動くものは一つも増えていませんでした。成長している感じと、成長は別物だったんだと思います。

「追わない」を決めるための、たった一つの質問

やめると決めたとき、何を残して何を切るかで迷いました。全部切ると今度は取り残される怖さがあるし、基準が曖昧だと結局元に戻ります。

そこで、質問を一つだけ用意しました。

「これは、今の私の手が止まっているところを直せるか？」

これだけです。答えがイエスなら、その日のうちに触ります。ノーなら、名前だけメモして見送ります。

たとえば、私は当時、自分のツールのビルドが遅くて毎回1分待たされていました。これは明確に手が止まっているポイントです。だから高速なビルドツールの話が流れてきたときは、その日の夜に移行しました。半日かかりましたが、その後の待ち時間が数秒になったので、一週間で元が取れています。

逆に、新しいUIフレームワークの話題が盛り上がっていたときは見送りました。今のところ、私のUIは不便を感じていない。困っていないものを置き換えても、増えるのは移行作業だけです。

この質問の良いところは、判断が速いことです。以前は「触るべきか」で30分悩んでいたのが、今は10秒で決まります。悩んでいた30分こそが、一番もったいなかったのかもしれません。

一周遅れで触ると、驚くほど楽になる

見送った技術は、忘れるわけではありません。半年から一年くらい経ってから触ります。

これが想像以上に快適でした。理由は三つあります。

一つ目は、情報が整っていること。出たばかりの頃は公式ドキュメントしかなくて、ハマったときに検索しても誰も同じ問題を踏んでいません。半年経つと、日本語の解説記事も、詰まりやすいポイントをまとめた投稿も出揃っています。私が3時間ハマるはずだった問題が、検索して5分で終わります。

二つ目は、破壊的変更が落ち着いていること。初期の頃は、書いたコードが数ヶ月後の更新で動かなくなることがよくあります。少し待つと、APIの形がだいたい固まっている。

三つ目は、そもそも残っているかどうかが分かること。当時あんなに話題だったのに、一年後には誰も話していない技術がけっこうあります。見送っていた私は、その学習コストを丸ごと払わずに済みました。逆に、一年経っても使われ続けているものは、たぶん本物です。そこに時間を使うほうが、確率としては良さそうだと思っています。

やめて空いた時間は、思ったより地味なことに消えた

追いかけるのをやめて浮いた時間で、何かすごいものを作った……という話だと格好がつくのですが、実際はもっと地味でした。

私がその時間を使ったのは、自分のプロジェクトのテストを書くことと、エラーメッセージを分かりやすくすることと、READMEを書き直すことです。どれも新しくないし、話題にもなりません。

でも、この地味な作業をやってから、明らかに開発が速くなりました。テストがあるので、思い切って書き換えられる。エラーが読めるので、原因を探す時間が減る。READMEがあるので、一ヶ月ぶりに戻ってきても自分が何をしていたか思い出せます。

前は「開発が遅いのは、良いツールを使っていないからだ」と思っていました。実際には、遅さの原因のほとんどはツールの外側にありました。同じ調査を何度もやり直していたり、書いたコードを壊すのが怖くて手が止まっていたり。ツールを新しくしても、そこは直りません。

結局のところ、私の開発速度を上げたのは新しい技術ではなくて、自分の環境の摩擦を一つずつ減らす作業でした。地味ですが、効き目は確実です。

この作業には、もう一つ良いところがありました。誰かの話題に乗る必要がないので、自分のペースで進められることです。新しい技術を追いかけているときは、いつも他人の時間軸で動かされている感じがありました。今は、自分が困ったときに自分の手で直す。その順番になってから、開発が生活の中で無理なく続くようになりました。

それでも、私が追いかけ続けているもの

ここまで書くと「もう何も新しいものを触らない人」に見えそうですが、そうではありません。私が今も追っているものは、はっきり決めています。

一つは、毎日使っている道具の変化です。エディタ、言語のバージョン、AIのアシスタント。これらは触っている時間が長いぶん、小さな改善でも効果が積み上がります。リリースノートには目を通します。

もう一つは、考え方が変わるタイプの話題です。個別のライブラリではなく、設計の考え方とか、開発の進め方とか。こういうものは、たとえ使わなくても、自分のコードの書き方に影響が残ります。

そして、実際に触るときは必ず、自分の小さなプロジェクトに組み込むところまでやります。チュートリアルで終わらせない。動くものに入れて、不便なところまで含めて味わう。そこまでやって初めて、その技術が自分にとって必要かどうかが分かります。

追う量を減らしたぶん、一つあたりに使える時間が増えました。前は10個を浅く触っていたのが、今は2個を深く触っている。手応えは、後者のほうがずっとあります。

まとめ：焦りは、情報量ではなく手応えで消える

新しい技術の名前を見て焦る気持ちは、たぶん一生なくならないと思います。私も今でも、少しはそわそわします。

ただ、この一年でひとつ分かったのは、その焦りは情報を増やしても消えないということです。もっと知れば安心するかと思っていたら、知れば知るほど「知らないもの」も増えていきました。

焦りが実際に薄くなったのは、自分の作ったものが少しずつ動くようになってからでした。動くものが手元にあると、外の話題に振り回されにくくなります。

なので、もし今、ブックマークだけ溜まっている状態の人がいたら、おすすめしたいのは一つだけです。今日は新しいものを開かずに、止まっているプロジェクトのほうを15分だけ触ってみてください。それだけで、明日の気持ちがけっこう変わります。

最後に聞かせてください。あなたが「これは追わない」と決めているものは何ですか？ 逆に、これだけは追い続けているものは？ コメントで教えてもらえたら嬉しいです。

この記事が少しでも役に立ったら、スキで応援してもらえると励みになります。フォローしてもらえると、次回もこういう話を書きます。