はじめに
アイスタイル Advent Calendar2025 の 24 日目の記事です。
はじめまして。
株式会社アイスタイルで@cosmeアプリの開発を担当している、新卒 Android エンジニアの横井です。
気づいたら配属されて４ヶ月が経っており、学生の時には関われなかったような大きな案件にもたくさん関わらせていただきました。
（そして、同時に沢山の壁にぶつかってきました...笑）
そこで今回は、アプリ開発未経験で配属された自分が初めにぶつかった「アプリの構造」について、備忘録も兼ねて記事にまとめます。
配属されて最初に壁にぶつかったところ
タイトルにもある通り、それは「アプリの構造を理解すること」でした。
初めて案件の内容を聞いた時は、「UI の改修と API 周りの修正をすればいいんだな」となんとなく想像できていました。
ですが、いざ Android Studio を開いてみると、全く手が動きませんでした。
理由はシンプルで、「クラス名が何を表しているのか」「そもそもアプリがどういう構造（設計）で作られているのか」 が、全く分からなかったからです。
そこでまずは、クラス名とそれぞれの役割を理解するところからスタートしました。
アプリ内のクラス名と役割がわからない
まず初めにクラス名でよく見かけたものと、それぞれの役割をざっくり表にまとめてみました。
実際にまとめてみると、今までは何を表しているかわからない暗号のようなものが、意味のある単語として頭に入ってくるようになりました。
| クラス名 | 役割 | 例：記事投稿アプリ |
|---|---|---|
| ~~Activity | 一言で言うと画面そのもの。 最近だとシングル アクティビティ アーキテクチャ（SAA）という考え方が主流みたいなので、自分の中では「何も書いていない真っ白なキャンバス」というイメージです。 |
MainFrameActivity （アプリを起動した時に一番最初に作られる土台的な画面） |
| ~~Fragment | 画面を構成するパーツ。 白紙のキャンバスのような役割をしている Activity の上に色々な Fragment を置いていって、アプリの画面を作っているイメージです。ライフサイクルに合わせてパーツの表示/非表示を切り替える時の処理も Fragment に実装します。 |
NewsListFragment （投稿された記事を表示する要素） HeaderFragment （ヘッダー要素） |
| ~~Screen | パーツごとのレイアウト。 Screen ではレイアウトの内容を、Fragment ではこの Screen の表示/非表示をライフサイクルに合わせて切り替えているイメージです。 |
NewsListScreen （記事リストのレイアウト） HeaderScreen （ヘッダーのレイアウト） |
| ~~ViewModel | アプリ内での UI の状態処理を記述する場所。 「ボタンが押されたら〜」や「受け取った値を元に並べ替えして〜」などのアルゴリズム的な処理はここに実装するイメージです。 |
NewsListViewModel （記事リストがスクロールされる時や記事がタップされた時の処理を実装） HeaderViewModel （ヘッダーにあるボタンなどが押された時の処理を実装） |
| ~~API | HTTP 通信を実際に行う場所。 アプリ内で使う API がまとまっている。 |
ContentsAPI （記事の取得/投稿/削除などに関わる API がまとまっている） AuthorAPI （投稿者情報の取得/編集などに関わる API がまとまっている） |
| ~~Repository | 個別の API を実行する処理を記述。 データの取得・保存、更新の役割をもち、正しく API を実行できた時、エラーが返ってきた時などの場合分けの処理も実装されている。 |
GetContentsRepository （記事内容を取得した時、失敗した時の処理を実装） GetAuthorRepository （著者情報を取得した時、失敗した時の処理を実装） |
| ~~UseCase | 複数の API を使いやすくまとめたり、特定の機能を切り出しまとめたりしたビジネスロジック部分。 システムを使って達成したい「具体的な操作」や「シナリオ」が記述されている アプリの機能＝ UseCase の集合体というようなイメージでいます。 |
GetNewsListUseCase （記事リストに必要な内容と著者情報の取得処理をまとめたもの） |
| ~~Entity | API 実行で受けとった json 形式そのままの値を格納する場所。 |
ContentsListEntity （記事の内容が json 形式で格納されている） |
| ~~Mapper | 受け取った json 形式の値を別のレイヤーで扱いやすいようにマッピングする。 |
ContentsListMapper （json 形式の記事を string 型のリストに変更する） |
| ~~Model | 変換された値を格納する場所。 |
ContentsListModel （string 型のリストに変更された記事の内容が格納されている） |
MVVM やクリーンアーキテクチャがわからない
ここまででクラスごとの役割をざっくり理解し、ようやく実装に取り掛かることができました。
ですが、実際に修正を始めると一箇所直すごとにエラーが連鎖的に発生するという事態に陥りました。
原因はすごく簡単で、クラスごとの役割は分かっても「クラス同士がどう繋がっているか」というアプリ全体の構造が全くイメージできていませんでした。
先輩社員に相談してみたところ、このアプリは MVVM と クリーンアーキテクチャ の設計思想に基づいて作られていることを教えていただきました。
そこでさっそくこの２つの設計思想について勉強を始めることにしました。
MVVM とは
MVVM は、アプリのような UI をもつソフトウェアに使える設計パターンの１つのようです。
アプリの構造を M（Model）-V（View）-VM（ViewModel）の３階層に分けることで、保守性が上がり、テストも容易になるという利点があります。
クリーンアーキテクチャとは
クリーンアーキテクチャは、アプリのメインとなる機能（ビジネスロジック）を中心に考え、UI や API などの処理から独立させる設計パターンの１つのようです。
メインの処理を中心に考えることで、もし画面のレイアウトに変更求められた場合でも機能をそのままにしてレイアウトのみ修正するといったように対応することでき、保守性が上がるという利点があります。
現在のアプリとの関連がわからない
ここまでで、MVVM とクリーンアーキテクチャの概要、そしてそれらを採用する利点について、ざっくりと理解できました。
そこで、次は実際に MVVM とクリーンアーキテクチャの考えと現在のアプリを紐づけるということをしてみました。
MVVM と現在のアプリ構造を紐付ける
まず初めに、MVVM の構造と現在のアプリ構造を紐づける図を作成してみました。
この図を作成したことでアプリの全体像がはっきりしました。
クリーンアーキテクチャと現在のアプリ構造を紐付ける
同様にクリーンアーキテクチャの構造と現在のアプリ構造を紐づける図を作成してみました。
UseCase というビジネスロジックを中心に考えることで、画面などは代替可能な外付けパーツというイメージを持つことができました。
構造を理解して良かったこととまとめ
ここまでが、「アプリの構造」についての自分の理解になります。
まだ浅い知識な部分もありますが、アプリ全体の構造を理解したことで、案件に取り組む際の手順が圧倒的に変わりました。
今まではどこから手を付けていいか分からず固まっていましたが、「UI の改修ならまずは Fragment や Screen から確認しよう」と、自分である程度考えて取り掛かれるようになりました。
ですが、何度も言うようにアプリ構造への理解はまだまだ浅いと思っています。
これからも日々の案件を通して、よりアプリの設計について学んでいきたいです。
最後まで読んでくださり、ありがとうございました。
それではメリークリスマス。そして、良いお年を。