設計不良なソフトウェアの現場で起きていること

設計不良なソフトウェアの現場では、共通して起きることがあります。

変更を入れようとすると、「どこまで影響するのか分からない」という声が上がる。

それでも、プロジェクトは止まりません。

  • スケジュールは既に決まっている
  • 調整は簡単には認められない
  • 技術的制約を解消するための時間も取れない

結果として、「今の構造のまま、なんとか実装してほしい」という判断が下されます。

この時点で、プロジェクトはすでに消耗戦に入り始めています。

影響範囲が見えないまま進む実装

影響範囲が分からない状態では、エンジニアは慎重になります。しかし、慎重に考えれば考えるほど、時間は足りません。

  • 安全に直したい
  • でも期限がある
  • 設計を整理する余裕はない

その結果、選ばれるのは「期限内に動く可能性が高そうな実装」です。

設計的には無理があると分かっていても、他に選択肢がないため、応急処置的な実装が積み重なっていきます。

ここで言う「影響範囲がわからない」とはどういう状態か

ここで、この記事で使っている「影響範囲がわからない」という言葉の意味を、少しだけ整理します。

これは単に、

  • 調査が足りない
  • エンジニアの理解が浅い

という話ではありません。

影響が 大きすぎて、複雑すぎて、人間の脳の仕組み的に追いきれない という状態を指しています。

どこを変更すると、

  • どの画面に
  • どの機能に
  • どの状態に

影響するのか。

それを一人のエンジニアが頭の中で安全にトレースできない。これが「影響範囲が見えない」状態です。

実装完了後に始まる、本当の消耗戦

スケジュール上は、実装は一度「完了」します。しかし、その後に不具合が多発します。

影響範囲を把握できないまま実装している以上、これはほぼ必然です。

  • 想定外の画面で不具合が発生する
  • 特定の操作順でのみ再現するバグが出る
  • 修正すると別の箇所が壊れる

不具合対応という 予定外の作業 が発生し、本来進めるはずだったタスクは後ろ倒しになります。

エンジニアは長時間労働になり、管理者はスケジュールを組み直すことになります。

誰も得をしません。

なぜこの状況は繰り返されるのか

この問題は、エンジニアの努力不足ではありません。むしろ、責任感の強いエンジニアほど無理をします。

しかし、

  • 影響範囲が見えない設計
  • 技術的負債を返すための時間や構造がない

これが変わらない限り、結果も変わりません。

エンジニアは「疲れたから」辞めているわけではない

長時間労働が続くと、「エンジニアが疲れて辞めた」と説明されがちです。

しかし実際には、

  • 頑張っても状況が改善しない
  • 技術的負債が解消される兆しが見えない
  • 消耗戦が続く未来が想像できてしまう

こうした 構造的な行き止まり を感じた結果として、プロジェクトを抜ける決断をしているケースが多いのではないでしょうか。

エンジニアが定期的に入れ替わる現場では、個人の忍耐力やモチベーションではなく、

  • 影響範囲が見えない設計が放置されていないか
  • 技術的負債を解消するための構造や仕組みが存在するか

といった点を、疑うべきだと考えます。

設計の役割は「人間が判断できる状態」を作ること

設計の役割は、コードを綺麗にすることではありません。

  • 影響範囲を把握できるようにする
  • 変更に対して判断できる状態を作る
  • 段階的な改善を可能にする

設計とは、 人間が無理なく考えられる状態を作ること です。

消耗戦を終わらせるために

設計を軽視すれば、短期的にはスピードが出ているように見えるかもしれません。しかしその代償として、現場は確実に消耗していきます。

設計不良による消耗戦は、エンジニアも、管理者も、プロダクトも疲弊させます。

設計はコストではありません。 消耗を防ぐための投資 です。