ツールに振り回されないための考え方

エンジニアコミュニティにいると、毎月のように「最強のツール」が登場する。

新しいエディタが出た。新しい AI コーディング補助ツールが出た。新しいタスク管理アプリが話題になっている。それを見るたびに「試してみようか」という気持ちになる。

以前の私は、かなりの頻度でツールを乗り換えていた。Vim から VS Code へ、VS Code から Cursor へ、メモはNotionに、いや Obsidian に、やっぱりシンプルなメモアプリに……。

あるとき、「ツールの乗り換えに使った時間で何か作れていた」と気づいた。

ツール探しが「仕事をしている感」を生む

新しいツールを試すのは楽しい。設定を整えて、自分好みにカスタマイズして、生産性が上がった気分になる。

でも、これは「仕事をしている感」を作っているだけで、実際のアウトプットには繋がっていないことが多い。

私はあるとき1日かけて VS Code の設定をカスタマイズした。拡張機能を入れ直して、ショートカットを設定して、テーマを調整して。「これで作業効率が上がった」と思ったが、コードは一行も書いていなかった。

ツール最適化は手段であって目的ではない。当たり前のことだが、ツールを触っているときは忘れてしまいがちだ。

新しいツールを使い始めて、思ったほど生産性が上がらないと、「このツールが合っていないのかも」と感じることがある。

でも多くの場合、問題はツールではなく、ツールへの習熟度だ。

今使っているツールで本当に困っているか、を問い直してみる。「なんとなく新しい方が良さそう」「有名な人が使っているから」という理由でツールを変えても、慣れるまでの摩擦コストが発生するだけだ。

エディタにせよ、タスク管理にせよ、ある程度使い込まないと本当の価値はわからない。浅く広く試すより、深く一つ使う方が生産性は高い。

だからといって、ツールを変えることが悪いわけではない。

問題は「なんとなく変える」こと。正当な理由があれば、乗り換えは有効だ。

私が今もっているツール変更の基準は以下の3点だ。

1. 今のツールで解決できない具体的な問題があるか

ただの不満ではなく、特定の作業フローが機能しない、という具体的な問題があるとき。

2. 乗り換えコストを上回るメリットが見込めるか

移行に1週間かかる場合、それを回収できるだけの改善があるか。

3. 乗り換え後の自分のワークフローをイメージできるか

「なんとなくよさそう」ではなく、具体的にどう変わるかが見えているか。

この3点を満たさないなら、乗り換えは見送る。

ツールに振り回されているとき、往々にして「何を作りたいか」が曖昧になっている。

目的がはっきりしていれば、ツールは問題にならない。ハンマーがなければドライバーで叩けばいい、という話ではないが、普通の目的であれば今あるツールで十分なことがほとんどだ。

私が講師をしているとき、「何のツールを使えばいいですか？」という質問をよく受ける。私はいつも「今使っているものでいい。それより何を作りたいかを教えて」と返す。

道具の話を先にすることは、目的の話を後回しにすることだ。

エンジニアリングの格言に “Don’t fix what ain’t broken”（壊れていないものを直すな）というものがある。

ツールに関しても同じだ。今のツールが十分に機能しているなら、変える必要はない。

私は今、エディタを VS Code で使っている。Cursor の方が AI 補助が優れているのは知っている。でも今のワークフローで不満がないので、しばらく乗り換えるつもりがない。

何かに「慣れている」という事実は、それだけで価値がある。ツールを覚えるコストはゼロではないからだ。

ツールは私たちを助けるためにある。私たちがツールに仕えるためではない。