記事

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

ソフトウェア設計が分かっていても、 Android アプリが作れない理由 Android アプリの設計は「掛け算」で成立する Android OS 固有の制約 Kotlin を「使っている」と「使いこなしている」の差 Jetpack Composeは「 UI 実装」ではなく「設計そのもの」 「設計思想 × Android 文脈」が価値になる 自分の強みについて ソフトウェア設計が分かっていても、 Android アプリが作れない理由 ソフトウェア設計が分かっている人が、必ずしも Android アプリをうまく作れるとは限らない。 これは、 Android 開発を続けてきて、何度も実感してきたことだ。 設計原則を理解している。 責務分離の重要性も分かっている。 それでも、 Android アプリとして形にしようとすると、どこかで無理が出る。 その理由は、単に Android OS の制約が強いから、というだけではない。 Android アプリの設計は「掛け算」で成立する Android アプリの設計は、次の要素が同時に成立して初めて機能する。 Android OS 固有の制約 Kotlin という言語の前提 Jetpack Compose という UI モデル どれか一つだけ分かっていても足りない。 Android OS 固有の制約 まず避けて通れないのが、 OS の制約だ。 ライフサイクルが複雑で、いつ破棄されるか分からない プロセスは OS 都合で突然 kill される バックグラウンド動作や権限には厳しい制限がある これらを無視した「きれいな設計」は、実機上では簡単に崩れる。 Android では、 壊されることを前提に設計する 必要がある。 ...

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

なぜクリーンアーキテクチャはドメインを守るのか はじめに 不変条件とは何か 例 不変条件は「判断」そのものである 不変条件が曖昧だと、設計は壊れる 不変条件をドメインに閉じ込める、という判断 なぜドメインなのか 「ドメインを守る」とは、何を守っているのか UI やインフラに不変条件を置くと何が起きるか まとめ おすすめの関連書籍（無料） なぜクリーンアーキテクチャはドメインを守るのか クリーンアーキテクチャはドメインを守っているが、その本質は「判断」を守ることである はじめに 「クリーンアーキテクチャでは、ドメインを守ることが重要だ」 この説明を、これまで何度も目にしてきましたし、自分でも何となく理解しているつもりでした。 UI から独立させるため フレームワークに依存させないため テストしやすくするため どれも間違ってはいません。 ただ、実務で設計に向き合えば向き合うほど、 それで結局、何が一番大事なのか？ という疑問が残りました。 最近、その答えが少しはっきりしてきました。 クリーンアーキテクチャの本質は、 「判断をどこに閉じ込めるか？」を決める構造である という考え方です。 どの判断は UI に任せてよいのか どの判断はユースケースで行うべきか どの判断は、絶対に外に漏らしてはいけないのか この「判断の置き場所」を曖昧にしたまま設計すると、 責務が混ざり 修正のたびに迷いが生まれ 変更に弱い構造 になっていきます。 では、 絶対に外に出してはいけない判断とは何なのか？ その答えを整理するための言葉が、不変条件 でした。 （不変条件という言葉は、英語では invariant という言葉でよく使用されます） この記事では、 クリーンアーキテクチャを「判断の置き場所」という視点で捉え直し その中で不変条件がどんな役割を持つのか なぜ不変条件をドメインに閉じ込めるのか を、実務の感覚に近い形で説明します。 不変条件とは何か 不変条件とは、 どれだけ仕様や実装が変わっても、絶対に破ってはいけない前提 です。 UI が変わっても API が変わっても DB が変わっても これが壊れたら、そのシステムは成立しない そういう条件を指します。 例 ログインしていないユーザーは、保護された操作をできない 残高は常に 0 以上である 同じ支払いは二重に確定しない これらは ...

アーキテクチャとは 依存関係とは 物理的な依存関係 意味的な依存関係 ドメインとは ドメイン以外 同心円状の図の意味 意味的な依存関係とクリーンアーキテクチャ 具体例 依存関係の逆転が必要なケース 依存関係を逆転させる具体的な方法 おすすめの記事 おすすめの本（無料） クリーンアーキテクチャという言葉はよく聞くけれど、「わかったようでわからない」という人が多いのではないでしょうか？ クリーンアーキテクチャを解説した記事は、探せばすぐに出てきますが、あまり本質について語られている記事は少ないように感じます。 そこで、この記事でそれを簡潔に語っていこうと思います。 アーキテクチャとは まず、そもそも「アーキテクチャ」とは何でしょうか？簡潔に説明したいので、どんどん答えを書いていきます。 目的 壊れにくいソフトウェアを作る チーム内で統一した方針でソフトウェアを作る 実現方法 部品 (※1) 同士の依存関係 (※2) を整える 部品が果たす役割・責務を明確にする (※1) 「部品って具体的に何？」と思われた方は、一旦、クラスだと思っていただければ大丈夫です。 (※2) 後述します。 めちゃくちゃシンプルに書くとこうなると思います。 依存関係とは クリーンアーキテクチャの本質を知るためには、このセクションがめちゃくちゃ大事です！！ 「そんなの知ってるわ」という方も、クリーンアーキテクチャについての理解が「モヤッ」としている方は読んでください。 依存関係には、二種類の依存関係があります。 物理的な依存関係 まずは、物理的な依存関係について説明します。これは、多くの人が最初に思い浮かぶ依存関係の方だと思われます。 すなわち、「どの部品 (クラスなど) がどの部品のことを知っているか」という関係性のことです。 (このドキュメントのサンプルコードは Kotlin で記述させていただきます。ご了承ください。) class A { val b: B } class B { // ... } 上記のサンプルでは、クラス A がクラス B を知っているので、これを「 A が B に依存している」と言います。 これが、物理的な依存関係です。 (超ざっくり) 意味的な依存関係 次に、意味的な依存関係について説明します。ここで、クリーンアーキテクチャの記事でよく出てくる同心円状の図を見て下さい。 (探せばすぐに出てくるのでここには載せません。笑) ...

Zenn で記事を書いていましたが、長期的な執筆活動を見越して、 Hugo + GitHub Pages で、技術ブログを始めることにしました。 このブログでは、 Android / Jetpack Compose 設計・アーキテクチャ 技術的な意思決定（ADR） について書いていきます。