ローカルDBを Realm から Room へ移行します 🔜

Androidエンジニアの斎藤です 👨‍💻

まずはじめにタイトルを見て「Realm を? 2025年に?」と思った方、私も思います。

とはいえ私自身 Realm を触ったのがこの会社が初めてだったのですが Realm の第一印象は特に悪くなく、Roomが出る前の SQLiteDatabase に比べたら選択肢として間違ってなさそうな気もします。

しかし Realm 特色などを理解せずに利用することで予期せぬバグを生んでしまうこともわかりました。

そんな困りごととどのように解決したか（まだしていない）を共有できればと思います。

はじめに

今や Realm を使っているプロダクトはAndroidでは珍しいかと思います。現在でも大半は Realm を使っており一部新しい機能は Room で実装されています。

フォトラクションでは2017年から開発されモバイルアプリとしては歴史が長く、それに加えてさまざまな理由から未だにRealmは残り続けています。

しかし、とある問題が発覚してからようやく重い腰を上げて全てRoomに置き換えようということになりました。

今回はそのとある問題について紹介しRealmをより深く掘り下げていければと思います。

前提条件として既存アプリの現状の設計は過去に公開した記事の通りになっています。

（一部異なるところもありますが大体はこのようになっています）

https://kojichu.photoruction.com/entry/adcale20221209

https://kojichu.photoruction.com/entry/adcale20211215

とある問題について

まずは発生した現象から。

ある Realm からデータを取得する時に、古いデータが取得されることがありました。

しばらく原因不明でしたが、根気よく調査してみると Realm の読み込みはスナップショットベースであることがわかりました。そしてデータ読み込み時に明示的に最新のデータを取得する場合は realm.refresh() を行うことが必要だと。

しかし、そもそもスナップショットベースってなんでしょうか。Realmは他のDBと何が違うのでしょうか。

Realmの設計哲学

Realmは内部的に MVCC（Multi-Version Concurrency Control） を採用しています。

これは一言で言うと：

• Realmインスタンスは「ある時点のDB状態（スナップショット）」を表す
• 書き込みは新しいバージョンを作り、読み込みは各スレッドのスナップショットを使ってロックなしで並行処理可能
• Realmインスタンスはスレッドごとに独立し、最新の状態を使いたければ明示的にrefresh()する必要がある

つまりRealmは「時点固定の読み込みと書き込み分離」が原則で、データは常に「瞬間的な静止画」を見ているイメージです。

ということは refresh を呼ぶだけでいいのですが、これを実装するにあたって更なる疑問が出てきました。

一方でアーキテクチャの常識：関心分離と状態隠蔽

フォトラクションでは記事にある通りRepository層を設けて関心分離と状態隠蔽を行っています。

元となったクリーンアーキテクチャやDDDの考え方では、

• Repositoryはデータソース（DB）からのデータ取得を抽象化し、変更の検知や状態管理は上位層に任せる
• Repository内部の状態（キャッシュやタイミング）を外に漏らさず、いつでも「最新の状態を返す」ことが理想
• さらに複数Repositoryの連携でトランザクションや状態整合性を保ちたい

このため、Repositoryは単純な「CRUD」以上の責務を持たず、状態更新の管理はControllerやUseCaseに委ねることが多いです。

フォトラクションでも「CRUD」以上の責務は ViewModel に委ねています。

しかし、この最新状態保証とRealmのスナップショット設計の相性が悪いのです。

衝突点：Realmのスナップショット設計は「最新状態保証」と相性が悪い

Realmは「スナップショット＝状態固定」なので、

• Repository単位で呼び出されると、その時点の状態を返すだけになりやすい
• 他スレッドで更新されても、そのRepositoryのRealmインスタンスは更新されない（refresh()しない限り）
• Repository単体では「最新状態が保証されているか」がわからず、どこでrefresh()すべきかの判断ができない

つまり、

RealmのMVCCは「明示的な更新管理」が必須である一方、Repositoryはそれを隠蔽・分離したいというアーキテクチャの要求と相反する

という構造的な問題を生みます。

今回のケースでは書き込みによって新しいバージョンを作成したが、読み込みは古いバージョンのデータを見ていた。そしてこれを解決するには明示的に読み込み時に refresh() することです。

では RealmObject を取得する Repository クラスの関数全てに refresh() を記述すればいいのでしょうか。

Realmのrefresh()問題とそのコスト

refresh() は Realmインスタンスのスナップショットを最新に切り替える処理です。

• これを呼ばないと他スレッドの変更は反映されない
• しかし頻繁に呼ぶとパフォーマンスに影響する可能性がある（特に大量の更新がある場合）

このため、

• 「どこで」「どのタイミングで」「誰が」refresh()を呼ぶかはアプリ設計の重要課題
• Repository単位で呼ぶと責務が混ざり、呼ばないと最新を見られず、どちらもデメリット大

一般に Realm における refresh() のコストは小さいですが、以下の条件によって変動します：

コスト要因	説明
差分の大きさ	書き込み後の変更量が大きいほど、バージョン間の更新にかかる処理は重くなる
保持中の RealmObject の数	オブジェクトが多いほど、参照整合性のための更新コストが発生
古い Realm インスタンスを長く保持している場合	トランザクションログのサイズが大きくなり、GCや refresh の負荷が上がる

フォトラクションの場合、差分同期という仕組みを利用していますが、建設BPOサービスも行っておりこれによって大量の納品データが格納させると突然巨大なデータが降ってくることがあります。

この時 refresh() のコストが著しく高くなる可能性があります。

以上が発生した問題です。

対策の方向性

1. 上位レイヤーでrefreshを管理する

   UseCaseやViewModel層でrefresh()を一括管理し、Repositoryは純粋にデータアクセスのみを担当する。

2. リアクティブ設計を採用する

   RealmのasFlow()や通知機能を使い、データの変化を監視して自動で最新化を反映する。

   → これで明示的refreshが不要になり、MVCCの設計を活かせる。

3. RealmProviderやラッパーを設ける

   Realmインスタンス生成とrefresh管理を一括する抽象レイヤーを設けて、複数Repositoryでの状態管理を一元化する。

我々の決断としては 4. の Realm を諦める。になりました。

理由としてはどれも修正コストが高く、このコストを払うならRoom移行した方がいいのではという結論でした。

細かいところでは、フォトラクションはリレーションが多いプロダクトなのでSQLテーブル結合を View テーブルで表現した方がシンプルであったり、Realmの部分一致ロジックに不満があったり、あるのですが大きな理由としては今回の問題が一番大きな理由です。

終わりに

Realmは強力で高速なDBであることは間違いないと思います。

しかし、スナップショットベースのMVCC設計は、一般的な関心分離アーキテクチャとぶつかりやすいことを理解しておく必要がありそうです。

今回は Android と Realm について言及しましたが、 他のスナップショットベースのMVCC設計データベースと何かの組み合わせでも起こりうることなので頭の隅に入れておくといいかなと思いました。

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

Android15対応時のEdge-to-Edgeを回避する

Androidエンジニアの藤井です。今回は、既存アプリのターゲットをAndroid 15に更新した際のEdge-to-Edge回避について、社内で対応した事例も交えて紹介します。

はじめに：Android 15とEdge-to-Edgeの現状、そして既存アプリの課題

Android 15の登場により、アプリのEdge-to-Edge表示は、より多くのアプリで標準的な振る舞いとして推奨されるようになりました。これにより、アプリのコンテンツがシステムバー（ステータスバーやナビゲーションバー）の背後にまで広がり、より没入感のあるユーザー体験を提供できるようになります。

しかし、既存のAndroidアプリをAndroid 15（API Level 35）をターゲットに更新する際、このEdge-to-Edgeの強制的な適用が、予期せぬUIの崩れやレイアウトの問題を引き起こすことがあります。特に、多くのカスタムビューや複雑なレイアウトを持つアプリでは、システムバーとコンテンツの重なりによって、ボタンが隠れたり、重要な情報が欠けたりといった問題が発生しがちです。

私が担当するプロジェクトでも、API Levelを34から35に上げた際、Android 15のテスト端末で一部の画面においてEdge-to-Edgeによる画面表示の崩れが発覚しました。このような状況下で、既存のUIデザインとユーザー体験を維持しつつ、迅速にAndroid 15に対応するために、私たちはEdge-to-Edge表示を意図的に回避する選択をしました。本記事では、その具体的な対応策と、Android 15で新たに導入されたandroid:windowOptOutEdgeToEdgeEnforcement属性の活用について詳しく解説します。

---

Edge-to-Edge回避のアプローチ：android:windowOptOutEdgeToEdgeEnforcementの活用

Android 15では、開発者がEdge-to-Edgeの強制適用からオプトアウトするための新しい属性が導入されました。それがandroid:windowOptOutEdgeToEdgeEnforcementです。この属性をtrueに設定することで、Android 15以降のシステムが適用しようとするEdge-to-Edgeレイアウトの強制を回避し、従来のシステムバーがコンテンツの上に描画される挙動を維持することができます。

これにより、過去のAndroidバージョンでWindowCompat.setDecorFitsSystemWindows(window, true)などを用いて行っていたシステムバーの処理と連携しやすくなり、既存のレイアウトを大きく変更することなく、Android 15への対応を進めることが可能になります。

---

具体的な実装と対応詳細

プロジェクトでEdge-to-Edgeを回避するために行った具体的な対応は以下の通りです。

1. テーマへのandroid:windowOptOutEdgeToEdgeEnforcement属性の追加

まず、styles.xml（またはthemes.xml）に、各Activityに適用するテーマを定義し、その中にandroid:windowOptOutEdgeToEdgeEnforcement属性を追加しました。

<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:tools="http://schemas.android.com/tools">
    <style name="Theme.MyApp" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="android:windowOptOutEdgeToEdgeEnforcement" tools:targetApi="upsideDownCake">true</item>
        </style>

    <style name="Theme.MyApp.FeatureA" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="android:windowOptOutEdgeToEdgeEnforcement" tools:targetApi="upsideDownCake">true</item>
        </style>

    <style name="Theme.MyApp.FeatureB" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="android:windowOptOutEdgeToEdgeEnforcement" tools:targetApi="upsideDownCake">true</item>
        </style>

    <style name="Theme.MyApp.Dialog" parent="Theme.MaterialComponents.DayNight.Dialog">
        <item name="android:windowOptOutEdgeToEdgeEnforcement" tools:targetApi="upsideDownCake">true</item>
        </style>
</resources>

ポイント:

• tools:targetApi="upsideDownCake": この属性はAndroid 15 (Upside Down Cake) 以降で有効な属性であることを示し、それ以前のAPIレベルをターゲットにしているビルドでコンパイルエラーになるのを防ぎます。
• プロジェクトでは、特定の画面や機能に特化したテーマ（例: Theme.MyApp.FeatureA、Theme.MyApp.FeatureBなど）にもこの属性を追加しました。これにより、アプリ全体で一律にEdge-to-Edgeを回避するだけでなく、必要に応じて細かく制御することが可能になります。

2. AndroidManifest.xml でのテーマの適用

次に、AndroidManifest.xml内で、Edge-to-Edgeを回避したい各Activityに対して、上記で定義したテーマを適用しました。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools">

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:supportsRtl="true"
        android:theme="@style/Theme.MyApp"> <activity
            android:name=".MainActivity"
            android:exported="true"
            android:theme="@style/Theme.MyApp.NoActionBar" tools:targetApi="35">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <activity
            android:name=".FeatureAActivity"
            android:label="@string/feature_a_title"
            android:theme="@style/Theme.MyApp.FeatureA" /> <activity
            android:name=".FeatureBActivity"
            android:theme="@style="Theme.MyApp.FeatureB" /> </application>
</manifest>

このように、AndroidManifest.xmlで適切なテーマを適用することで、Android 15の端末であっても、各画面が意図した通りのレイアウトで表示されることを確認しました。

---

Android 15対応におけるその他の考慮事項：16 KBページサイズデバイスへの対応

今回のEdge-to-Edge回避以外にも、Android 15への対応で新たに考慮すべき点があります。それは、Android 15以降でサポートされる16 KBのページサイズを使用するように構成されたデバイス（以下、16 KBデバイス）への対応です。

標準的なAndroidデバイスのメモリページサイズは4 KBですが、Android 15では一部のデバイスで16 KBページサイズが採用される可能性があります。これは、デバイスのメモリ管理効率向上を目的としたもので、ほとんどのアプリには直接的な影響を与えません。しかし、アプリでネイティブコード（JNIやNDKを使用するコード）を扱っている場合、この16 KBページサイズに起因する問題が発生する可能性があります。

具体的には、ネイティブコードが4 KBのページサイズを前提としたメモリ管理やアライメント処理を行っている場合、16 KBデバイス上でクラッシュしたり、パフォーマンスが低下したりするリスクがあります。

現時点では、私たちのプロジェクトではこの16 KBデバイスへの対応はまだ完了していません。今後は、ネイティブコード部分を詳細にレビューし、16 KBページサイズ環境でも適切に動作するよう修正を加えていく必要があります。

---

注意点とトレードオフ

今回の対応は、既存のアプリのUIを迅速にAndroid 15に適合させるための効果的な手段でした。しかし、このアプローチにはいくつかのトレードオフが存在します。

• 既存UIの維持 vs. 最新のUIトレンド: Edge-to-Edgeを回避することで、既存のUIの一貫性を保つことができますが、Androidが推奨するより没入感のある体験からは逸れることになります。将来的には、Edge-to-Edgeに対応したデザインへの移行も視野に入れる必要があるかもしれません。
• 開発コストの削減: 短期的な対応としては、UIの大きな手直しが不要となるため、開発コストを抑えることができます。
• 長期的なメンテナンス: Androidのバージョンアップに伴い、Edge-to-Edgeに関する振る舞いがさらに変更される可能性もあります。

---

まとめ：今後の展望

今回のAndroid 15への対応は、android:windowOptOutEdgeToEdgeEnforcementという新しい属性を活用することで、既存アプリのUIを維持しつつ、迅速に最新のAndroidバージョンに対応できることを示しました。特に、複雑なレイアウトを持つ既存アプリにとっては、このオプトアウト機能は非常に有用な選択肢となるでしょう。

しかし、この属性は将来的に廃止される(※)ため、今回の対応はあくまで暫定的なものと認識しています。今後は、よりモダンなUI設計への移行を視野に入れ、Edge-to-Edgeを前提としたレイアウト調整や、WindowInsetsの適切な取り扱いに関する恒久的な対応を計画していく必要があります。 ※ https://developer.android.com/about/versions/16/behavior-changes-16?hl=ja#edge-to-edge

また、Edge-to-Edge対応だけでなく、16 KBデバイスへのネイティブコードの対応など、Android 15への移行には複数の側面での検討が必要です。まずは今回の対応によって、ユーザーに安定した体験を提供しながら、今後のUI/UX戦略と技術的な課題にじっくりと取り組む時間を確保することができました。

---

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

Android 開発で Cursor 使ってみた感想 👀

Androidエンジニアの斎藤です。

弊社ではAIの活用による開発を推進しています。社内でこれについてのガイドラインなどのドキュメントも作成しており（ここではお見せできませんが 😢）、社員、業務委託も含めて全ての開発者が利用することができるようになっています。

具体的には GitHub Copilot / Devin / Cursor の3つ利用して開発しています。

これらはチーム毎に段階的に利用開始できるのですが、先月から Cursor が利用可能になったことでAndroid開発でも使っていこうとなりました。

そこで実際に使ってみた感想を紹介させていただきます 🙇‍♂️

また、今回は Cursor と既存実装のリファクタリングについてで、新規実装についてはまた別の機会に紹介させていただきます。お楽しみに！

既存コードのリファクタリング

まず小さく一部のデータ取得処理のリファクタリングからCursorを使ってみることにしました。

既存処理の課題として Realm のデータ操作を独自 Util クラス RealmUtils で操作している処理があり、これについて少しずつRepository クラスに移行する計画を立てて実施しています。

今回のリファクタリングでは RealmUtils.updateUser() を UserRepository.updateUser() に移行することをゴールとし、これを Cursor を使うことでどれくらい効率よくできるかを試しました。

必要なアクション

リファクタリングに必要なアクションは大まかに分けて下記4つになります。

• 同等な関数の検索。
  • RealmUtils.updateUser() と同等のDB操作が既存の Repository に存在しているかどうか。
• 同等な関数の実装。
  • RealmUtils.updateUser() と同等のDB操作が既存の Repository に存在していなければ、その関数と同等のDB操作を関連するリソースの Repository に追加する。
• 旧処理の削除。
  • RealmUtils.updateUser() を削除する。
• 参照の修正。
  • RealmUtils.updateUser() の参照を Repository に変更する。

雑な注文

まずは雑に注文を投げてどんな反応か見てみます。

プロンプト 💬 

RealmUtils.updateUser() をリポジトリ化してください。

実行結果 🤖

引用部分が Cursor の回答です。実行に表示される具体的なコードは掲載できないので省略しています。

検索結果から、UserRepository に updateUser() メソッドを追加するのが適切だと判断しました。

✅ 同等な関数の検索

✅ 同等な関数の実装

次に、RealmUtils.java の updateUser() メソッドを削除します：

✅ 旧処理の削除

これで、updateUser() メソッドを UserRepository に移動し、RealmUtils から削除することができました。

実行結果の評価 🔍

• 同等な関数の検索。
  • 同等の関数はないので検索結果は ⭕。ただし検索しているかどうかは不明。
• 同等な関数の実装。
  • 実装は概ね良し。ただ private のプロパティを参照しようとしてコンパイルエラーに🔺 。
• 旧処理の削除。
  • ⭕。削除するだけなので。
• 参照の修正。
  • ❌ 。このステップ自体がありませんでした。要件に無いのでそれはそうですね。

追加で参照の修正を雑に依頼しました。

プロンプト 💬 

呼び出し側のコードも修正してください

実行結果 🤖

引用部分が Cursor の回答です。実行に表示される具体的なコードは掲載できないので省略しています。

呼び出し側のコードを修正していきます。まず、CreateUserFragmentViewModel.java を修正します：

次に、UpdateUserFragmentViewModel.java を修正します：

これで、updateUser() メソッドの呼び出し側のコードを修正しました。主な変更点は以下の通りです：

実行結果の評価 🔍

• RealmUtils の代わりに UserRepository を使用するように変更
  • こちら呼び出す Repository 名が間違っており解決できずコンパイルエラーに ❌ 。自身で作成したにも関わらず Repository 名を忘れてしまったようです。これは文脈が失われてしまったからでしょうか。
• 各クラスのコンストラクタで UserRepository を注入するように修正
  • 🔺。ベストプラクティスっぽい動きでいいですね。ただ残念ですがフォトラクションは独自のDIコンテナーを利用しており、今回のケースもそちらを利用するようにしたいです。注文に加える必要がありますね。
• メソッド呼び出しを新しいリポジトリクラスのメソッドに変更
  • ⭕ 。ヨシ。

❌ と🔺のところを手で修正したところ私が想像していたコードになりました。

プロンプトと呼んでいいものかというくらい雑な注文でもこれくらいサクッとやってしまいました。

ではもう少し詳細な注文をするとどうなるでしょうか。

少し丁寧な注文

新しいチャットで下記を注文しました。

プロンプト 💬 

RealmUtils.updateUser をリポジトリ化してください。
RealmUtils.updateUser と同等の処理が RLMUser テーブルを操作している Repositoryにあるか探して、なければ RLMUser テーブルを操作している Repository に updateUser 同等の処理を追加。
RealmUtils.updateUser を削除。
RealmUtils.updateUser を呼び出しているコードを新しく作成したRepositoryの updateUser に変更。
Repositoryのコンストラクタインジェクションはしないで、 PhotoructionApplication.container から対象の Repository を取得すること。

実行結果 🤖

引用部分が Cursor の回答です。実行に表示される具体的なコードは掲載できないので省略しています。

これで、以下の要件が満たされました：

1.✅ RealmUtils.updateUserをリポジトリ化

2.✅ RLMUserテーブルを操作しているRepositoryにupdateUser同等の処理を追加

3.❌ RealmUtils.updateUserを削除（クラス自体が@Deprecatedのため、将来的に削除予定）

4.✅ RealmUtils.updateUserを呼び出しているコードを新しく作成したRepositoryのupdateUserに変更

5.✅ Repositoryのコンストラクタインジェクションはせず、PhotoructionApplication.containerから対象のRepositoryを取得

実行結果の評価 🔍

• 1.✅ RealmUtils.updateUserをリポジトリ化
  • 🔺。前回同様 private のプロパティを参照しようとしてコンパイルエラーに。これは実装がJavaで参照がKotlinということで起きてそうな問題です。現実装がAIフレンドリーではないのかもしれないです。
• 2.✅ RLMUserテーブルを操作しているRepositoryにupdateUser同等の処理を追加
  • ❓ 。^と同等の処理ですが質問を雑に並べてしまったのでこのような結果出力になった？構造化は必要そうですね。
• 3.❌ RealmUtils.updateUserを削除（クラス自体が@Deprecatedのため、将来的に削除予定）
  • ❌ 。これは実行ログを見ても謎なのですが何故か削除できなかったようです。参照自体がまだあったから？
• 4.✅ RealmUtils.updateUserを呼び出しているコードを新しく作成したRepositoryのupdateUserに変更
  • ⭕ 。問題なく変更されている。
• 5.✅ Repositoryのコンストラクタインジェクションはせず、PhotoructionApplication.containerから対象のRepositoryを取得
  • ⭕ 。注文の甲斐あって期待通りの呼び出しになっています。

概ねうまくいきましたがステップ3.で不要になったコードの削除に失敗しているようです。

どうしても一発でいきません。さらに詳細な注文にするとどうなるでしょうか。

より丁寧な注文

Cursor には context にコードのファイルや .mdcファイルを追加することができ、AIアシスタントがこれを参照してタスクを実行してくれます。

そこで今回は RealmUtils.java をcontextに追加してみました。

プロンプト 💬 

[概要]
RealmUtils.updateUser をリポジトリ化してください。

[詳細]
1.RealmUtils.updateUser と同等の処理が RLMUser テーブルを操作している Repositoryにあるか探して、なければ RLMUser テーブルを操作している Repository に updateUser 同等の処理を追加。
2.RealmUtils.updateUser を呼び出しているコードを新しく作成したRepositoryの updateUser に変更。
3.RealmUtils.updateUser を削除。

[留意点]
- Repositoryのコンストラクタインジェクションはしないで、 PhotoructionApplication.container から対象の Repository を取得すること。

実行結果 🤖

引用部分が Cursor の回答です。実行に表示される具体的なコードは掲載できないので省略しています。

このタスクを実行するために、以下の手順で進めていきます。

1.まず、RLMUserテーブルを操作しているRepositoryを探します。

2.該当のRepositoryにupdateUserメソッドを追加します。

3.既存の呼び出し箇所を特定し、新しいRepositoryのメソッドに変更します。

4.最後に古いメソッドを削除します。

手順は良さそうです 👀

まず、RLMUserテーブルを操作しているRepositoryを探しましょう。

次に、RealmUtils.updateUserを呼び出している箇所を探します：

まず、CreateUserFragmentViewModel.javaを修正します：

次に、UpdateUserFragmentViewModel.javaを修正します：

最後に、RealmUtils.javaからupdateUserメソッドを削除します：

これで、以下の変更が完了しました：

1.UserRepositoryにupdateUserメソッドを追加

2.CreateUserFragmentViewModelとUpdateUserFragmentViewModelで新しいRepositoryのメソッドを使用するように変更

3.RealmUtilsからupdateUserメソッドを削除

変更内容を確認してください。問題がなければ、これらの変更を適用してリポジトリ化を完了させることができます。

実行結果の評価 🔍

1. UserRepositoryにupdateUserメソッドを追加
   • ⭕ 。
2. CreateUserFragmentViewModelとUpdateUserFragmentViewModelで新しいRepositoryのメソッドを使用するように変更
   • ⭕ 。良さそうです。
3. RealmUtilsからupdateUserメソッドを削除
   • ❌ 。コードを削除が苦手。

やはりコードの削除に失敗します。

プロンプト 💬 

updateUserメソッドを削除してください。

実行結果 🤖

引用部分が Cursor の回答です。実行に表示される具体的なコードは掲載できないので省略しています。

RealmUtils.javaからupdateUserメソッドを削除します。

申し訳ありません。もう一度試してみます。

申し訳ありませんが、ファイルの編集がうまくいかないようです。これは、ファイルの内容が予想と異なる可能性があります。もう一度、ファイルの内容を確認して、正確な位置を特定しましょう。

ファイルの内容を確認したところ、updateUserメソッドは1077行目から1087行目に存在していることがわかりました。もう一度、このメソッドを削除する試みを行います。

以下、謝罪と失敗の繰り返しで削除はできませんでした。ファイルロックがかかっている可能性があったので事前にAndroid Studioを終了して試しましたが結果は変わりませんでした。

まとめ

今回小さなリファクタリングを例に挙げましたが、他にも試行していたのでその結果をまとめです。

よかったところ👍

• 小さなリファクタリングであれば雑な注文でもそれなりにやってくれる。
• 今回は紹介しませんでしたが、まっさらな新規実装であれば問題なく実装してくれる。

気をつけるところ 🤔

• Android Studio との併用。
  • 既存コードの修正においてはなかなか一発で決まらないので、手直しするときに使い慣れた AndroidStudio から修正することが多かったです。
• プロンプトの作り方。
  • まだまだ使い始めなのでこれからより良いプロンプトを作成するための勉強が必要と感じました。
  • 一発で決まらない時は都度修正してもらうよう再注文するのですが、この注文回数が増える毎に初回に定義した前提がどんどん抜けていく現象によく見舞われました。この辺りも使い方にコツがあるのかもしれません。

私たちが改善するところ 💭

• コンテキストを小さく保つ。
  • 修正するファイルが多かったりファイル自体が大きいと露骨に精度が悪くなる気がします。
  • できるだけ小さい単位に作業を区切った方が精度が良くなりました。ただ、この辺りもプロンプトの工夫で改善できるのではと期待しています。
• Project Rulesの作成。
  • プロンプトだけでは限界がありそうなのでアプリの既存コードの設計やルールなどを記載した .mdcファイルを追加することでより精度を上げていきたいです。
  • Project Rules はチームで取り組んでいけそうだなと感じました。
• デファクトスタンダードに合わせる。
  • できるだけデファクトスタンダードに合わせた実装をすることでよりスムーズに実行してくれそうです。
  • 実際今回の例でAIが独自のDIコンテナを理解できず、コンストラクタインジェクションをしていましたが、こう言った手戻りがなくなりそうです。（Project Rules に記載することでカバーできるかもしれませんが）
  • お気づきかもしれませんがフォトラクションは未だにいくつか Java ファイルが残っているのでこれらをKotlinにコンバートすることでも改善するかもしれません。

まだまだ使い始めなのでうまく使いこなせている気はしませんが、これからどんどんチームで感想やTipsを共有して生産性を向上させていきます 💪

こういった環境で開発していきたい方、ぜひ一緒に働きましょう 🎵

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

Androidチームの変遷

Androidエンジニアの藤井です。

今回は私が入社して以降、現在に至るまでのAndroidチームの変遷について振り返って行きたいと思います。

現在、Androidチームは社員・業務委託合わせて計4名と副業で支援いただいている1名のメンバーで開発しています。

※ 副業のメンバーも業務委託では有るのですが、ここでは週4日〜5日のメンバーと月16時間前後で関わっていただいているメンバーとで区別させていただいています。

そこに至るまでのチームの変遷を振り返っていきつつ、振り返っていく中でAndroidチームを

「メンバーが自走してプロダクト課題に向き合うことができるチーム」

にしていくために、どのような取り組みを行なってきたかを紹介できればと思います。

目次

• 2023年半ば：Androidエンジニアが1名に
• 2024年：チーム立て直し期
  • 業務委託メンバーの参画
  • 社員が2名に
• 2025年：現在とこれから
• まとめ

2023年半ば : Androidエンジニアが1名に

Android チームのメンバー内訳

社員：3名 -> 1名
副業メンバー：3名

詳細は省きますが、私が入社して約半年余り経った頃、Androidチームのメンバーの退職により、チームの社員が私一人になってしまいました。

副業で入っていただいているメンバーは3人いたのですが、フルタイムで参画してもらっているわけでは無いので、実質Androidチームのメンバーが一人になってしまったという形になります。

当時を如何にして乗り越えたか

当時はiOS・Android合わせてモバイルチームとして動いてはいたものの、リリースフローを触れるAndroidエンジニアが私一人になっており、アプリ自体も技術課題が多くプロダクトの価値提供に集中できない状況でした。

それらの事情を鑑みてPdMと相談した結果、Androidの機能開発自体を遅らせて、技術課題の解消を優先させるなどの措置が取られました。

また、副業で入って頂いているメンバーの提案により毎日1時間、通話によるPRの対面レビューとペアプログラミングを行う取り組みを始めました。 この取り組みはペアプログラミングから後述のモブプログラミング(モブプロ)に名称を変えて今でもAndroidチームの文化として続いています。

※ 尚、この取り組みはペアプログラミング・モブプログラミングと呼称していますが、厳密には一般的なそれとは少し異なることをここで明記しておきます。

チーム体制についても、それまでモバイルチーム全員でスクラムイベントを行なってきましたが、スクラムイベントの進め方自体にも課題が残っていたこともあり、デイリー以外のスクラムイベントはiOS・Androidそれぞれのチームで行う方針に変わっていきました。

2024年：チーム立て直し期

業務委託メンバーの参画

社員：1名
業務委託：0名 -> 2名
副業メンバー：3名 -> 2名

2024年初頭、Androidチームに業務委託のメンバーが2名参画しました。

2名とも経験があるエンジニアではあるものの、参画してすぐはプロダクトの開発に慣れて貰うことを優先したため、スプリントのサイクルとは別でカンバンを作成し、既存のバグチケットの改修を依頼していました。

その後、業務委託メンバーの2名もバグチケットの改修の中で出てきた疑問点などを吸い出すために前述のモブプロの時間に参加してもらう様になりました。

社員が2名に

社員：1名 -> 2名
業務委託：2名
副業メンバー：2名 -> 1名

業務委託メンバーがプロジェクトに慣れてきた頃、新たに社員メンバーが入社しました。 クラッシュフリー率改善の記事を執筆した斎藤さんです。

この時期は業務委託メンバーもバグチケットの改修だけでなく、機能開発や改善にも注力できるようになり、斎藤さんが入社したことでAndroidのリリース出来るメンバーが増えたことで、チームとしても一気に強化されてきました。

具体的には以下のような取り組みでチーム開発を進めてきました。

• モブプロ
  • 朝10時にモブプロの時間で相談したいことを各自Slackに投稿
  • 相談事があれば、相談事の解決を優先
  • なければPRのレビューを行い、早めに終われば解散
    • この取り組みにより、それまで溜まりがちだったPRが消化されやすくなった
• Slackのリマインダで11時にリリースモニタリングを投稿するようにしてメンバー各自でチェックする仕組みを導入
  • CS・CREからのエスカレーションを早い段階で収束に向けていくことにも寄与
• 週次で検知したクラッシュレポートの棚卸し
  • 内容によっては直近のスプリントで対応するものもあれば、その時のスプリントで優先して対応
• MagicPod の導入
  • テストの失敗を対応するようにしてからリリース後の障害が発生しにくくなった
  • リグレッションテストの効率化にも寄与している
• Jetpack Compose を採用
  • 機能開発で新規に作る画面には導入する方針にしている
  • これにより開発体験も向上している

これらの取り組みの結果、Androidチームはそれまでと比較して安定したベロシティでスプリントの開発ができるようになりました。 また、個人的な見解ではありますが、チームとしての雰囲気も課題に対してチームで向き合う空気が出来ている気がしています。

特に印象的だったエピソードとして、ある日AndroidアプリでHotfixのリリースが必要な障害を検知した際、チームの各メンバーで収束に向けて調査担当・関係各所への連携担当など役割を分担して、問題対チームで動けていたなと実感した出来事がありました。

他にもプロダクト価値提供を止めることなく技術課題の改善を日々積み上げる動きが出来ていたりと、手前味噌ではありますが、良いチームになってきたのではないかと感じています。

2025年：現在とこれから

社員：2名
業務委託：2名
副業メンバー：1名

今年に入ってからはチームメンバーの顔ぶれもほぼ変わることなく、変わらずチームとして成果を出し続けている状況です。

その一方で、チーム内外ともに新たな課題が見えてきているので、変わらずチームとして向き合いつつ、チーム開発の文化も徐々にAndroidチーム外にも広げていけたらと思います。

まとめ

少しばかり長くなってしまいましたが、私から見えているAndroidチームの変遷について紹介させていただきました。

これまでのチームの移り変わりの中で当社のAndroidチームは良いチームになりつつあります。

これは、これまで行なってきた取り組みの結果と、その取り組みを提案したり進めていく事ができるチームメンバーに恵まれたからだと思っています。

また、Androidチームのメンバーはリモートのチームでチーム開発を進めていくうえで日々のコミュニケーションの積み重ねと愚直に課題と向き合うことを大切にしてきた事が繋がっているんだと考えています。

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

Photoruction Labo Demo Dayの様子~1年間の集大成~

BPOチームでエンジニアをやってますkazuです🦌

2024年4月からスタートした開発イベント「Photoruction Labo」。チームや個人の関係性を深めることを目的に、8名のメンバーが集まり、各チームに分かれて開発を進めてきました。気づけば、あっという間の1年。本記事では、その1年間の集大成となる様子をお届けします✨

これまでのLaboの内容については、こちらをご覧ください↓↓↓

kojichu.photoruction.com

kojichu.photoruction.com

kojichu.photoruction.com

kojichu.photoruction.com

kojichu.photoruction.com

※ここに、これまでのLaboの記事

Demo Dayを開催した理由

各チームは、「新しい技術を学びたい」「業務をもっと効率化したい」「社内の人とのつながりを深めたい」など、それぞれの想いを胸に、1年間プロダクト作りに全力で取り組んできました。

みなさんの頑張りをどうせなら社内の皆さんにも見てもらいたい。そして、Laboの活動を通じて得た学びや成果を共有したい。そんな想いから、今回のイベント「Demo Day」を企画することにしました。

Photoruction Labo Demo Day

当日は、運営の挨拶から始まり、これまでのやってきたことを振り返りながら、各チームどんな開発を行なってきたかを説明して、デモの時間を作りました。

運営からの挨拶

まずは、運営メンバーであるCREリーダーのよしきさんから挨拶👏

開発合宿として淡路島にいったり、シェアオフィスを借りてお寿司を食べたりしてるチームもありました🍣

最終的に20人ほどいました😳

各チームの紹介

各チームが開発してたプロダクトはこんな感じです！

day1チーム

VRを用いてオフィスを再現したプロダクト

fracchi

モバイルを活用した日記アプリ

シヨウワカール

Photoructionのプロダクトに関する仕様を回答するAIチャットbot など

各メンバーに「大変だったことは？」と聞いてみたところ、やはり多くの声が挙がったのは「本業との時間のやりくり」でした。

普段の業務では、プロダクトオーナー（PO）があらかじめ「何を・どこまでやるか」を決めてくれます。しかしLaboでは、自分たち自身がPOであり、同時にエンジニアでもあります。そのため、限られた時間の中で「何をやるか」「何をやらないか」を自ら判断する必要があり、こうした体験ができるのもLaboの醍醐味ではないかと思います✨

Demoの時間

day1

day1チームは、VRを用いてオフィスを再現しました🏢

実際の様子はこちら↓↓↓

UnityもBlenderも、Webエンジニアにとって縁のない代物でこれの扱いがとても難しい😭

そして直角のものを再現するのは比較的簡単ですが、曲線を再現するのが難しかった…

ただ当日は、皆さんからの反応も良く割と再現できてたようなので安心しました笑

fracchi

これは、fracchiのデモの様子👀

fracchiチームは、Webとモバイルの両方で開発を進めていましたが、発表直前まで謎のビルドエラーに悩まされていたそうです。最終的にはギリギリでビルドに成功し、なんとか間に合ったとのこと（笑）

シヨウワカール

シヨウワカールは、このようにphotoructionの仕様について質問をするとそれに対して回答をしてくれるチャットボットを開発してました🤖

こちらは、実際にslack上で質問を投げることで回答してくれるのですが、社内での実用性が高いということで、継続して開発をすることで社内システムとして動かせるようにしようということになり、かなりの収穫がありました！

Laboのこれから

Demo Dayを終え、第一期 Photoruction Labo はひとまず終了となりました🎉

まずは「1年間しっかり継続すること」「その中で成果を出すこと」を目標に運営してきたので、無事に最高の形で締めくくることができて、本当に嬉しく思います。

中でも印象的だったのは、参加メンバーから「携わったプロダクトや技術に対して、より興味を持てるようになった」との声があったこと。Laboを企画して本当によかったな、と心から感じました😭

会社としてもこのLaboを“技術研究の場”としてさらに盛り上げていきたいという想いがあり、第二期 Photoruction Labo の開催が決定しました🙌

今年はAIブームの真っ只中ということもあり、ここからサービスに活かせるようなプロダクトが生まれるかもしれません…！？！

Photoructionでは、これからも新しい技術にどんどんチャレンジしていきます。少しでも気になる方は、ぜひ以下からカジュアル面談をお申し込みください！

これからも応援よろしくお願いします🙇‍♀️

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com

Androidチームがクラッシュフリー率を改善した話 💪

Androidエンジニアの斎藤です。

私が所属するAndroidチームとしての取り組みとその成果について紹介させていただきます。

Androidチームの課題への向き合い方や雰囲気など感じていただければと思います 🙇‍♂️

はじめに

クラッシュフリー率について

クラッシュフリー率はアプリがクラッシュせずに正常に動作したユーザーやセッションの割合を示す指標のことで、アプリの品質を図る上で1つの指標となっています。

一般的なアプリのクラッシュフリー率は分かりませんが、私自身が過去に関わってきたAndroidアプリと比較すると低い数字でした。

フォトラクションアプリの状況

またチーム目標としてはクラッシュフリー率の向上を目標としていましたが、これに対する具体的なアクションはあまりありませんでした。

フォトラクションアプリは2017年から開発されたものでJavaコードが残っていたりします。 加えて別会社の業務委託によって追加された機能などもあり全ての機能を網羅的に理解できる人はチームにはいない状況でした。それらのコードがクラッシュする時もあり調査が進まないこともありました。

改善に向けて

改善に向けた具体的なアクションとして下記のことにチームで取り組みました。

クラッシュの棚卸し

Androidチームは毎日決まった時間に1時間ほどのチームミーティングを設けています。毎週火曜日にチームで Crashlytics を見て新しいクラッシュがないか、増加していないかを見ることにしました。

まず発生したクラッシュのスタックトレースを見て、その場で発生箇所のコードを全員で見ます。 発生原因と修正箇所の目処が立ったらクラッシュのメモ欄に記載しておきます。

すぐにわからなそうであればチケット着手のタイミングで子タスクとして調査チケットを作成して詳細な原因調査から始めます。クラッシュに紐づくJIRAチケットがない場合は、このタイミングでJIRAチケットを発行します。

この一連の作業により、今Androidアプリでどのようなクラッシュが発生しているか、問題のコードがどのように実装されているかを知ることができます。 「このバグこの前のアレですかね？」「ですね」みたいな会話ができるようになりました。 問題に対する修正方針がチーム内に共有されることで、新規コーディング時にも同じようなバグをうまなくなります。

クラッシュを修正するチケットをスプリントに差し込む

スプリント(SP)の稼働の10%を目安にクラッシュの改善を積むことにしました。 新機能開発を優先することもあったので、クラッシュ改善がないSPもありましたが、新機能開発がないSPにクラッシュ改善ができたので平均すると10%~20%くらいにできたのではないかと思います。

実績

ここ半年で87％->95%に改善することができました。

加えてこの間に新機能開発を止めることなくできたというのは何よりも大きかったです。

まとめ

• 目標達成には具体的なアクションが必要。
• 問題は根気強く分解してチームで1歩1歩着実に。
• 価値提供はやめない。
• その上でよりスピードを。

直面する問題が大きすぎると全てを捨てて新しく作り直したくなる誘惑にかられると思います。しかし作り直したところでいずれはまた別の問題に直面するはずです。つまるところ問題が一定程度大きくなるとリセットしなければならなくなってしまいます。 チームに求められることは問題の大小に関わらず問題を根気強く分解してチームで1歩1歩着実に進めて顧客に価値提供をし続けることです。 その上でよりそのスピードを高められるように今後もチーム一丸となって進めていければと思いました。

株式会社フォトラクションでは一緒に働く仲間を募集しています

DTOクラスの基本

はじめまして、BPOチームでエンジニアやってますkazuです🦌

最近業務で、DTOクラスを教えてもらったので理解を深めようと思い記事にしてみました。

そもそもDTOクラスとは

DTO（Data Transfer Object）とは、システム間やレイヤー間（例：UIとビジネスロジック、ビジネスロジックとデータベースなど）でデータを転送する時に用いられるオブジェクトのこと。

APIやDBから受け取ってきた生のデータを扱いやすい形に変換して、一貫した形式でアプリケーション内部に受け渡しができる。

特徴

• ロジック（ビジネスロジック、ドメインロジック）を持たない
• プロパティを保持するシンプルなクラス
• 入力値の以上や型揃えの不備を発見しやすくなる

つまり、あくまで「データの運搬がメイン」のオブジェクトで、ビジネスロジックやドメインロジックのような業務ルールや制約などの処理に含まれず、純粋にデータのやり取りを担うことを目的としている。

なぜ、DTOを使う必要があるのか

1. レイヤー間の依存を減らす

例えば、ドメインオブジェクト（エンティティ）をUI層に直接渡すと、UI層で余計なフィールドやメソッドを操作できてしまい、依存関係が複雑になったりする。

DTOを挟むことで、UI層に必要な情報だけを切り出し、UI層とドメイン層の結合度を下げることができる。

2. データのまとまりを担保する

データをひとつのオブジェクトにまとめることで、転送やシリアライズが簡単になり、データの受け渡しを行う関数やAPIの引数/戻り値を整理しやすくする。

3. セキュリティやバリデーションのしやすさ

データチェックやバリデーションをDTOクラスの生成過程で扱いやすくなる。

DTOがよく使われるシュチュエーション

Webアプリケーションのリクエスト/レスポンス

• REST APIで受け取ったJSONデータをDTOにマッピングして扱う
• データベースの情報をDTOにつめてフロントエンドに渡す

マイクロサービス間通信

• マイクロサービス同士が通信する際、ServiceA → DTO → ServiceBのようにデータ転送をする

レイヤードアーキテクチャ

• Presentation層（UI層）
• Application層（ビジネスロジック）
• Domain層（ドメイン）
• Infrastructure層（DBなど）

上記のような間で、Entityをそのまま渡すと密結合になるため、DTOを介して疎結合に保つ。

サンプルコード

class OrgDTO {
  constructor(contents) {
    this.orgId = this.parseIntValue(contents["orgId"]);
    this.email = contents["email"];
    this.name = contents["name"];
  }

  parseIntValue(value) {
    return value ? parseInt(value, 10) : null;
  }
}

function main() {
  // サンプルデータ（外部から取得する想定のデータ）
  const contents = {
    "orgId": "1",
    "email": "aaa@example.com",
    "name": "test"
  };

  // DTOクラスのインスタンスを生成
  const result = new OrgDTO(contents);
  console.log("result", result);
}

main();

例えば、このように入力値の orgId が文字列として与えられる場合、parseIntValue 関数を利用して文字列型を Int 型に変換することができます。このように、生のデータをアプリケーション層で扱いやすい形に整形することで、コードの可読性と保守性を大きく向上させることができます。

また、データの取り扱いに役割を限定することで、ドメインロジックやビジネスロジックとの結合度を下げることができ、システム全体の見通しが良くなります。結果として、その後の処理でデータを扱う際に余計な手間が減り、開発効率が向上しそうです。

まとめ

• DTOクラスは、「データをやり取りするだけ」のオブジェクト
  • ロジックを持たず、転送用フィールドとアクセサだけを持つのが基本
• レイヤー間の依存度を下げ、コードの可読性を上げるために利用
  • 疎結合を保ち、メンテナンス性を高めるのに役立つ
• Webアプリやマイクロサービス、レイヤードアーキテクチャで使われることが多い
  • リクエスト/レスポンスやDBとのやりとりなど

株式会社フォトラクションでは一緒に働く仲間を募集しています

www.wantedly.com