【コード哲学エッセイ】 長く続くプロジェクトで、 やらないことを決める

機能よりも軸を守るという選択

新しい機能が動くたび、僕は小さな高揚を覚えます。
テストが緑になり画面に何かが増え、誰かの「ありがとう」が返ってくる。

けれど、長く続くプロジェクトに関わっていると、別の感情も必ず顔を出します。

「次は、あれも入れたい」
「競合がやってるから、こっちも」
「とりあえずフラグを足しておけば、あとでなんとかなるはず」

足すことは、前向きに見えます。
でも、軸を言葉にしないまま足し続けると、いつかコードもチームも何のためのプロダクトか分からなくなる。

僕が遅れて学んだのは、機能のリストと同じくらいやらないことを決めておく勇気でした。

全部やりたくなる夜

フリーランスとして、複数月〜年単位で同じコードベースに触れていると、関係者も増え、要望も増えます。

「今回だけ、小さな追加で済ませたい」
「この機能がないと、契約が危ない」

どれもリアルなプレッシャーです。
僕も何度も夜遅くまでエディタの前で、「じゃあ、ここに分岐を足そう」と指を動かしてきました。

そのたびに、アプリは賢くなったように見えました。
設定項目が増え、管理者向け画面に隠れたトグルが増え、ドキュメントの対応範囲の欄が太くなる。

できることが増えるほど、プロダクトの顔がぼやけていく。
気づいたときには、「このスイッチ、本当に誰が使うんだっけ？」と自分に問いかけなければならない状態になっていたのです。

やらないことがなかった頃

昔の僕は、やらないことを決めるより、できることを増やすほうが正義だと思っていました。

クライアントの笑顔も、自分のスキルへの評価も、短期的には足した量に比例しそうに見えるからです。

でも、長く続くプロジェクトでは記憶が薄れる。
三年前に「一時的だから」と入れた例外が、いまも本体の奥で息をしている。
名前のついた設計思想がないまま、そのとき都合のよかった答えだけが層になって積もっていく。

リファクタリングや抽象化の話の前に、もっと手前で足りなかったのは、「ここまではやらない」という合意の言葉だったと、いまは思います。

軸は機能のあとからは追いつきにくい

軸とは、派手なスローガンじゃなくてよいと思っています。

💭 このプロダクトは、 誰の、どんな痛みを、まず解くのか
💭 今回のリリースでは、あえて捨てる前提のユースケースは何か
💭 「やらない」ことに、誰が責任を持つか
　　（クライアントと握るのか、自分で宣言するのか）

こういう一文が README の片隅でも、Notion の一行でも、会議のメモでもいい。
書いてあるだけで、あとから来た「それもできるように」に対して、振り子が戻る場所ができる。

機能は、その軸に沿って並べる。
軸が後付けになると、既にある機能の説明に合わせて、都合よく軸を書き換えたくなる。
だから、長く続くプロジェクトほど、足す前にやらないを先に置くほうが、結果的に楽なのです。

僕がいまメモに書いていること

いま、新しい要件を見たとき、僕は機能仕様の前に短い箇条書きを増やすようにしています。

やらない（少なくとも、今はやらない）こと。

「多言語は、今回のフェーズでは対象外」
「この画面では、編集はさせず、参照だけ」
「あの連携は、手動エクスポートで十分と割り切る」

断るのが上手い人の話ではありません。
断り方を言葉にしておくと、あとから来た自分が救われるという未来への手紙に近いものです。

もちろん、前提は変わります。
やらないは永遠の禁止令ではなく、いまの軸にそった優先順位でしかない。
変わったら文書を直せばいい。
大事なのは、何も書かないまま暗黙のやらないだけが増殖しないことだと思っています。

機能より先に境界線を一枚

長く続くプロジェクトでやらないことを決めるのは、冷たい設計者の逃げ道じゃありません。

熱量をどこに集中させるかを選ぶという、かなり情熱的な作業に近いです。

全部をちゃんとやろうとすると、どこもちゃんとにならない。
僕はその失敗を何度か味わいました。

だからこそ、エディタを開く前に、今日は一枚だけ境界線を引く。
機能よりも、軸を守るという選択を未来の僕に残しておく。

同じ長い道のりを歩いている誰かの小さな道しるべになればうれしいです。

ひとりごと

長く続くプロジェクトはマラソンみたいに見えて、実際は何度も折り返しのある山道だと思っています。

そのたびに、もう少しだけ足せばと誘惑される。
僕もいま、完璧には抗えません。

それでも、やらないを一行書くクセだけは手放したくないです。

このエッセイが、あなたのリポジトリかドキュメントのどこかに静かな境界線を一つ足すきっかけになればうれしいです。

あわせて読みたい

▼ 全部共通化で苦しんだあとに読みたいときに

なんでもできる構造が、変更のたびに最初に壊れる現場の話です。
やらないこととあわせて読むと、何を変えやすくするかに集中する感覚がつながります。

▼ 速さと設計のあいだで迷ったときに

目先の実装スピードだけを追うと、軸が後回しになりがちです。
未来の自分を守る設計の考え方が、スコープの決め方にも効いてきます。

▼ 設計を完成品にしすぎないヒントが欲しいときに

設計は固定された正解ではなく、迷いと判断の履歴でもあるという視点です。
やらないことも、同じく更新していい約束だと読み替えられます。

次の一歩を一緒に決める 「作戦会議室」 へ

長期案件では、スコープの擦り合わせや「今はやらない」の言語化が、そのまま心の負担にもつながります。

「フリーランス開発者の作戦会議室」では、クライアントワークの進め方や設計・ドキュメントの実務、個人開発との付き合い方などを具体例ベースで共有しています。
一人で抱えがちな「断り方」「優先順位」を仲間と言葉にしていく場にもなっています。

もしあなたが、機能を足すたびに軸がぼやける感覚を抱えているなら、ぜひ作戦会議室ものぞいてみてください。

ここから先の一歩を、一緒にゆっくり決めていきましょう。

参加する