開発現場

設計不良なソフトウェアの現場で起きていること 影響範囲が見えないまま進む実装 ここで言う「影響範囲がわからない」とはどういう状態か 実装完了後に始まる、本当の消耗戦 なぜこの状況は繰り返されるのか エンジニアは「疲れたから」辞めているわけではない 設計の役割は「人間が判断できる状態」を作ること 消耗戦を終わらせるために 設計不良なソフトウェアの現場で起きていること 設計不良なソフトウェアの現場では、共通して起きることがあります。 変更を入れようとすると、「どこまで影響するのか分からない」という声が上がる。 それでも、プロジェクトは止まりません。 スケジュールは既に決まっている 調整は簡単には認められない 技術的制約を解消するための時間も取れない 結果として、「今の構造のまま、なんとか実装してほしい」という判断が下されます。 この時点で、プロジェクトはすでに消耗戦に入り始めています。 影響範囲が見えないまま進む実装 影響範囲が分からない状態では、エンジニアは慎重になります。しかし、慎重に考えれば考えるほど、時間は足りません。 安全に直したい でも期限がある 設計を整理する余裕はない その結果、選ばれるのは「期限内に動く可能性が高そうな実装」です。 設計的には無理があると分かっていても、他に選択肢がないため、応急処置的な実装が積み重なっていきます。 ここで言う「影響範囲がわからない」とはどういう状態か ここで、この記事で使っている「影響範囲がわからない」という言葉の意味を、少しだけ整理します。 これは単に、 調査が足りない エンジニアの理解が浅い という話ではありません。 影響が 大きすぎて、複雑すぎて、人間の脳の仕組み的に追いきれない という状態を指しています。 どこを変更すると、 どの画面に どの機能に どの状態に 影響するのか。 それを一人のエンジニアが頭の中で安全にトレースできない。これが「影響範囲が見えない」状態です。 実装完了後に始まる、本当の消耗戦 スケジュール上は、実装は一度「完了」します。しかし、その後に不具合が多発します。 影響範囲を把握できないまま実装している以上、これはほぼ必然です。 想定外の画面で不具合が発生する 特定の操作順でのみ再現するバグが出る 修正すると別の箇所が壊れる 不具合対応という 予定外の作業 が発生し、本来進めるはずだったタスクは後ろ倒しになります。 エンジニアは長時間労働になり、管理者はスケジュールを組み直すことになります。 誰も得をしません。 なぜこの状況は繰り返されるのか この問題は、エンジニアの努力不足ではありません。むしろ、責任感の強いエンジニアほど無理をします。 しかし、 影響範囲が見えない設計 技術的負債を返すための時間や構造がない これが変わらない限り、結果も変わりません。 エンジニアは「疲れたから」辞めているわけではない 長時間労働が続くと、「エンジニアが疲れて辞めた」と説明されがちです。 しかし実際には、 頑張っても状況が改善しない 技術的負債が解消される兆しが見えない 消耗戦が続く未来が想像できてしまう こうした 構造的な行き止まり を感じた結果として、プロジェクトを抜ける決断をしているケースが多いのではないでしょうか。 エンジニアが定期的に入れ替わる現場では、個人の忍耐力やモチベーションではなく、 影響範囲が見えない設計が放置されていないか 技術的負債を解消するための構造や仕組みが存在するか といった点を、疑うべきだと考えます。 設計の役割は「人間が判断できる状態」を作ること 設計の役割は、コードを綺麗にすることではありません。 ...

当時のプロジェクト状況 技術的には明らかに課題が見えていた それでも、抜本的な改善をしなかった理由 私が選んだ技術的判断 この経験から学んだこと 当時のプロジェクト状況 以前関わっていたプロジェクトは、多重下請け構造になっており、私自身は二次受け企業と業務委託契約を結んでいました。チーム内には三次受け、二次受け、一次受けのメンバーが混在しており、Android のテックリードは一次受け企業に一人だけという体制でした。 そのテックリードは複数チームを横断して担当しており、勤務地も異なっていたため、1年間一緒に仕事をしたにもかかわらず、対面どころかオンライン会議で直接会話したこともありませんでした。技術的な判断は基本的にその方に集約されており、私は設計の最終決定を主導できる立場ではありませんでした。 技術的には明らかに課題が見えていた コードベースを見ていて、技術的な課題は比較的はっきりしていました。ホーム画面に相当する Activity は肥大化しており、多くの責務を抱え込んでいました。Fragment に分割することで、見通しや保守性が大きく改善できる状態だったと思います。 また、ドメインロジックやユースケースは一応共通化されていたものの、副作用が多く、どこかを修正すると別の箇所に影響が出やすい構造になっていました。本音を言えば、設計を見直し、腰を据えて整理したいと感じる場面は何度もありました。 それでも、抜本的な改善をしなかった理由 ただ、そのような改善は、実装者一人の判断で進められるものではありませんでした。Fragment 分割やドメイン設計の見直しは影響範囲が広く、他社のテックリードとの合意形成が前提になります。 さらに当時は、設計以前に対処すべき問題が数多く存在しており、プロジェクト全体として常に余裕がない状況でした。その中で大きな構造変更を提案し、進めることは、技術的には正しくても、プロジェクトとしてはリスクが高いと感じていました。 「重要だと分かっているからこそ、今はやるべきではない」 そう判断せざるを得ない状況だったと思います。 私が選んだ技術的判断 最終的に私は、抜本的な構造変更は行わないという判断をしました。その代わり、既存の設計を前提としたうえで、自分が責任を持てる範囲に改善を限定し、変更による影響を最小化することを重視しました。 ここでの判断は、「何を実装するか」ではなく、「何をやらないかを決めること」だったと捉えています。設計を理想形に近づけることよりも、プロジェクト全体を不安定にしないことを優先しました。 この経験から学んだこと この経験を通じて、技術的な判断はコードの中だけで完結するものではないと強く感じるようになりました。設計の正しさだけでなく、その設計を実行できる組織構造や権限、合意形成のコストまで含めて考える必要があります。 良い設計を思いつくことと、それを実際に推し進められることは別の話です。その違いを理解し、今やるべきことと、あえてやらないことを切り分けることも、エンジニアの重要な役割だと思っています。 技術判断は、コードの外にもある。このプロジェクトは、そのことを強く意識するきっかけになりました。