技術的判断

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