今、捨てる方法――開発者を迷子にさせないために

この記事が語ること

開発の現場では必ず「捨てるべき対象」が発生する。
捨てるための割り切りや勇気といった精神論ではなく、それを組織的にマネジメントすることの重要性について論じる。
これは、後に続く開発者を迷子にさせないために必要な考え方でもある。

後始末は必ず発生する

技術的負債、不要なモジュール、古いドキュメント、放置された環境。
廃棄・整理の対象は時間とともに積み上がるものだ。

こういった負債の返済は、サービスを継続していく上では必須の要素だ。
つまり、重要なのは、「やるかやらないか」のレイヤーではない。
「どう捨てるか」 の方法論である。

整理し、捨てることは重要な開発業務の一部だ。
この認識を持たなければ、プロダクトライフサイクルの管理はおぼつかなくなるだろう。

"放置"を放置してはいけない理由

放置対象が積み重なると、判断が重くなり、事故リスクや仕様・ドキュメントの不整合が発生する。
これはプロジェクト構造を詰まらせる直接の原因となり得る。
つまり、「放置されたもの」は、リスクマネジメントの観点から計画的に破棄する必要がある。
これはまさに技術的負債が生む実害の中心を指し示している。

• 技術的事故

  • 古い設定ファイルが残り、本番環境が誤った設定で起動
  • 使われていないクラウドサービスやVMが課金を生み続ける
  • 切り捨てられなかったAPIが残り、意図せず呼ばれて障害発生

• 運用の迷子

  • "最新版"ドキュメントが複数存在し、どれを参照すべきか不明
  • 破棄予定のモジュールがレビュー対象に紛れ、工数が無駄になる
  • 退職者が残した未整理環境がブラックボックス化

• 意思決定の遅延

  • 「残す？捨てる？」の判断が毎回ゼロから議論になる
  • 破棄候補が可視化されず、優先度の議論ができない
  • チーム内で判断基準がバラバラになり、後工程で衝突が起きる

エンジニアであれば、少なくともいずれかは誰しも直面したことがあるはずだ。

技術、運用、意思決定、といった領域において、いずれは重くのしかかってくる。
目をそらしていても、必ずいつかツケは回ってくる。

"放置"を放置するのは、もうやめよう。
その代わりに、"計画的に放置" することとしよう。

計画的な放置

このような態度、テクニックを、筆者は
破棄マネジメントと呼んでいる。

これは、捨てるという行為そのものを設計・管理するスキルである。

このスキルは、単なるタスク管理やIssue運用とは異なる。
それらは「作業を進める」ための仕組みだが、このスキルが扱うのは、
「なぜ今は捨てないのか」「いつ捨てる判断をするのか」
という意思決定そのものである。

まず、破棄するということについて、判断の軸の例を挙げたい。

• 価値の消失
  対象が現行要件に対して価値を持たない
• 依存関係の断絶
  参照元がなくなった・仕様変更で役割が消えた
• 維持コスト > 残存価値
  更新・保守の手間がメリットを上回る
• リスクの顕在化
  放置すると事故・混乱・誤用につながる可能性が高い

こういった判断テンプレートを提示することで、「捨てる／残す／保留」の意思決定が組織単位で可能になる。

次に現場で用いるべき考え方の例を挙げる。

• コード管理

  • 脳内でピンを打つ
    怪しい個所を一時的に頭の中でマーキングしておき、必要なら後で形に残す
  • コードコメントで破棄条件を明記
    そのコードを残す理由、破棄予定日などを記す
    暫定対応などを仕込んだ場合に効果的
  • 静的解析
    場合によっては、参照されていないコードの洗い出しなどに使用できる。
  • Issue化（可視化）
    すぐに判断がつかないものは懸念として吐き出しておくことで後で役に立つ
    チーム全体で追跡可能となる

• ドキュメント管理

  • 棚卸の時間を確保
    管理すべき対象をあらかじめ少数に絞り込んでおくことが重要
  • 最終版以外は破棄対象としてチェック
    文書の最新版が常に分かるようにすることがゴール

• チーム管理

  • 破棄判断の責任者・担当を明確化
    これにより「誰が最終判断を持つか」がチームで明示される
  • 破棄対象をチームで共有
    認識齟齬を防ぎ、思わぬ事故を回避する
  • 破棄したことを評価する文化を持つ
    正しい破棄は評価される、という認識を持たせる
    主にマネジメント層がこの文化を醸成する役割を担う

その場ですぐに取捨選択するわけではなく、候補として扱い、優先度や判断対象として管理する。
これが"計画的に放置する"ということだ。

とはいえ、実際にはその場でどう扱うべきか、判断に迷うこともあるはずだ。
そういった場合はとりあえず保留とすることを勧めたい。
本来の業務に影響が出るほど、この工程に認知負荷をかけるべきではないからだ。

レイヤー別のポイント

経営層に求められることは、技術的負債それ自体がコストであり、その負債の破棄にもコストがかかる、という認識を持つことだ。
負債の発生を抑え込む、という考え方は、机上の空論だ。
"放置"が発生するのは現場の構造上、必然なのだ。

マネジメント層に求められることは、破棄を業務の一環だと認識すること。
プロダクトライフサイクルを念頭に置いた計画を組めば、自然とここに帰結する。
そして、誰が責任者かをチームに明示し、職務として与える。

現場層に求められることは、個々のモジュールでの実践だ。
古い構造やドキュメントを眺め、「捨てる／残す／保留」のラベル付けや判断基準を示す。
とりわけ重要なことは、Issue化するなどして外部化し、追跡可能な状態にすることだ。

この方法論の価値

いつ崩落してくるかわからない負債に怯えるのではなく、印をつけ、くさびを打ち込んでいく。
これがこのスキルの核心となる処理だ。

先述の例に照らして言えば、具体的な恩恵として、

• 新メンバーが触る前にIssueを確認し、地雷を回避
• 状況確認した担当者が不在でも、判断材料が文章として残っている

などがあるだろう。
この例では、自分で判断しなければならない範囲が狭まり、自分で推測する必要がない。

人が消えても判断は消えない。
ここに価値がある。

判断意図やタイミングが明示され、後工程で迷子になることがなくなる。
不要なものを計画的に整理することで、構造が詰まらず、意思決定も効率化される。
チーム全体で知見を共有することで、後戻りや無駄な議論も減る。
このスキルを意識することで、作る→整える→捨てるというサイクルを意識した思考が身につく。

これらはどんなエンジニアにとっても価値がある。

負担が向かう先

現場のポイントはシンプルだ。

• 捨てる対象を選ぶ
• いつ／どのように捨てるかを明示する
• チームで共有し追跡可能にする

この3点を軸にすることで、思わぬ事故や、構造の詰まり防止に寄与する。

開発とは、作るだけでは完結しない。
持続可能で安全なプロダクトにするためには、破棄の決断も必要になる。

未来の負荷を減らし、事故や手戻りを未然に防ぐ。
これは、現場で働く全ての開発者にとって高い価値になる。

しかしながら、「あとで処理する」という判断は、実質的には 「誰かに処理させる」 という宣言でもある。
その判断によって、処理の責任は未来へと移動する。
その"誰か"が未来の自分や後任であることを、そのとき私たちはすでに、選んでいるのだ。