属人化は、反転する

このところ、開発環境の見直しを続けています。複数のAIエージェントを扱うためにherdrを導入し、長く使ってきたJetBrains IDEからVS Codeへ移行しました。

環境を変えると、最初は確実に遅くなります。ショートカットを覚え直し、設定を移し、これまで無意識にできていた操作にも立ち止まる。それでも、単なる道具の置き換えではなく、日々の作業そのものを見直す機会になると考えました。

その一つが、デプロイ作業です。

デプロイを「ポチッとな」で動かす

これまでは、ターミナルを開き、対象のプロジェクトや環境を確認し、必要なコマンドを入力していました。作業自体は難しくありません。しかし、頻度が低いコマンドほど細部を忘れます。オプションを調べ直したり、履歴から以前のコマンドを探したりする小さな中断が発生します。

そこで、型チェック、テスト、データ確認、デプロイなどの定型作業をVS CodeのRun Taskに登録しました。今は一覧からタスクを選べば実行できます。いわば「ポチッとな」でデプロイできる状態です。

これは高度な自動化ではありません。コマンドを覚えて入力する作業を、名前の付いた操作に置き換えただけです。それでも、何を実行すべきか判断し、正確に入力するための認知負荷は減ります。入力ミスも起こりにくくなります。

小さな改善ですが、一人で設計、実装、テスト、リリース、運用まで担当していると、この種の小さな切り替えコストは無視できません。

チーム開発では、特定の人の環境でしか動かない仕組みは問題になります。誰でも同じ手順を実行でき、担当者が変わっても作業を継続できることが重要です。そのため、手順の標準化やCI/CDへの集約が求められます。

一方、一人開発では事情が異なります。利用者も運用者も基本的に自分だけです。全員にとって平均的に使いやすい仕組みを用意するより、自分の操作習慣や思考の流れに合わせた方が速い場合があります。

一般的な開発環境ではなく、自分にとって摩擦の少ない開発環境を作る。これは、言い換えれば「属人化による最適化」です。

属人化という言葉には、通常は否定的な響きがあります。しかし、属人化そのものが悪いわけではありません。人数や引き継ぎの可能性を無視して属人化することが問題なのであって、最初から一人で運用するものを一人向けに最適化することには合理性があります。

ただし、何でも開発環境の中に閉じ込めてよいわけではありません。

VS Codeのボタンを押さなければデプロイできず、裏で何が動いているか分からない状態にすると、便利さはそのままブラックボックス化につながります。エディタを変えたときやCIへ移行したいときに、仕組みを一から作り直すことになります。

そこで、実際の処理は npm script やシェルスクリプトとして定義し、VS Code のタスクはそれを呼び出すだけにするのがよいと考えています。

この構成なら、VS Codeは処理を隠す箱ではなく、既存のコマンドに使いやすい入口を付けるランチャーになります。自分向けに操作を最適化しながら、仕組みの再現可能性は残せます。

属人化してよいのは操作方法であって、処理の成立条件ではない。この線引きは、一人開発でも重要だと思います。

一人開発では他人への引き継ぎがなくても、未来の自分への引き継ぎは発生します。

半年間触らなかったプロジェクトを再開すると、細かな手順や判断の背景は驚くほど失われています。そのとき、以前の自分だけが理解できる設定や、ターミナルの履歴にしか残っていないコマンドは、他人が作った不透明な仕組みとほとんど変わりません。

Run Taskのように操作へ名前を付けておくことは、単なる時短だけではなく、未来の自分への簡単なドキュメントにもなります。「本番へリリースする」「型を確認する」「データを検査する」といった目的から処理を選べるため、コマンドの詳細を忘れていても作業を再開できます。

ただし、その名前を押したときに何が実行されるかは、コードとして読める状態にしておく。この二つを両立させることで、現在の自分にも未来の自分にも扱いやすい環境になります。

将来、開発者が増えたり、リリース頻度が上がったりすれば、個人向けのタスクをCI/CDへ移す必要が出てくるかもしれません。しかし、まだ存在しないチームを前提に、最初から組織向けの仕組みを作る必要はありません。

重要なのは、後から移せる形を保つことです。実処理がCLIで再現できれば、今はVS Codeから実行し、必要になった時点でCIから呼び出せます。入口を変えるだけで済みます。

一人開発では、標準化しすぎることにもコストがあります。設定を一般化し、文書を整え、誰でも使える仕組みにする時間は、プロダクトを作る時間と競合します。将来の可能性に備えすぎると、現在の速度を失います。

だから、今の人数に合わせて最適化しつつ、出口だけは塞がない。それくらいがちょうどよいと考えています。

一人開発の環境は、自分専用で構いません。ショートカットも、画面構成も、タスクの入口も、自分の思考と操作に合わせてよい。そこで得られる速さは、チーム開発における標準化とは別の種類の強みです。

ただし、便利さの裏側にある処理は、いつでも確認でき、別の入口からも実行できるようにしておく。

属人化は許容しても、ブラックボックス化はしない。

短期的には、環境の移行や設定に時間を使うため、開発の進捗は落ちます。それでも、設計からリリースまでを一人で担う以上、自分が迷わず動ける環境を整える効果は長く続きます。

これは単なるエディタの乗り換えではなく、自分の開発工程を、自分のために組み直す作業なのだと思います。