Technical Debt

はじめに 1. 影響範囲が読めないコードの例 2. 仕様とコードの因果関係を分かりやすくする 3. 開発者にとって怖いのは「影響範囲が読めないコード」 4. 良いコードとは「変更の影響範囲が読めるコード」 はじめに 「とりあえず動くものを作る」。 ソフトウェア開発では、どうしてもこの誘惑があります。 目の前に要件があり、それを満たすために必要なAPIを調べ、コードを書き、動作確認をする。テストも通った。これで完成です。 しかし、その実装が半年後、1年後も安全に変更できるとは限りません。 私は最近、ソフトウェア開発において特に避けるべきなのは、単に「バグのあるコード」や「複雑なコード」ではなく、 変更したときの影響範囲が読めないコードを書くこと なのではないか、と考えるようになりました。 そして、そのようなコードが生まれる大きな原因の一つが、 仕様や利用する技術の仕組みを十分に理解しないまま、目の前の要件を満たす実装をしてしまうこと なのではないかと思います。 1. 影響範囲が読めないコードの例 例えば、ECサイトに「購入金額が1万円以上なら送料無料」という仕様があったとします。 目の前の要件を満たすだけなら、注文処理の中に、 if (totalPrice >= 10_000) { shippingFee = 0 } のような処理を追加すれば十分です。 実際に動作しますし、テストも通るでしょう。 ところが、しばらくして仕様が変更され、 「1万円以上でも、一部の商品は送料無料の対象外とする」 となったとします。 すると、先ほど追加した処理を変更する必要があります。 さらにその後、 「会員ランクがゴールド以上なら、5,000円以上で送料無料」 という仕様が追加されたらどうでしょうか。 最初は注文処理の中に直接書いた条件が、次第に複雑になっていきます。 if (totalPrice >= 10_000) { shippingFee = 0 } else if (isGoldMember && totalPrice >= 5_000) { shippingFee = 0 } さらに商品ごとの例外が追加され、キャンペーンが追加され、地域による違いが追加され……。 最初は「数行追加するだけ」だった実装が、いつの間にか、 「送料の仕様を変更したら、どこに影響するのか分からない」 という状態になってしまいます。 ここで重要なのは、最初の実装が間違っていたとは限らないことです。 その時点では、要件を満たしていたかもしれません。 問題なのは、目の前の要件だけを見て実装した結果、後から仕様との関係を追いにくくなってしまったことです。 2. 仕様とコードの因果関係を分かりやすくする では、どうすればこのような状態を防げるのでしょうか。 一つの方法は、 仕様に存在する概念やルールを、コード上でも分かる形にすること だと思います。 先ほどの例なら、「送料」という単純な値を注文処理の中で直接変更するのではなく、 注文 ↓ 送料を計算する ↓ 送料無料条件を判定する ↓ 送料を決定する という仕様上の流れが、コードからも読み取れるようにします。 ...

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

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