yosuke_fujii

# 1. 担当した業務・こだわった点 自社プロダクトのAndroidアプリにおいて、リードエンジニアとして大小さまざまな機能開発・プロダクトの近代化（技術的負債の解消）を主導しつつ、EMとしてフルリモート開発組織のマネジメントおよびプロセス改善を並行して担当しました。 ##【領域1：大小さまざまな機能開発とプロダクトの継続改善】 - 目的（目指した姿）: ビジネスサイドや他職種と緊密に連携し、ユーザー価値を高める新機能開発や改善案件を、スピードと品質を両立させてデリバリーし続ける状態。 - 考え方: 個々の案件を単発のタスクとして捉えず、プロダクト全体の整合性と今後の拡張性を常に意識した設計・仕様策定を行う。 - 取り組んだ活動: 大小無数にある機能追加・改善案件において、仕様策定の上流工程から参画。Android固有の制約をビジネスサイドにフィードバックしつつ、最適な実装方針を策定。 - 直面した問題と工夫: 開発が並行する中でコードのコンフリクトやデグレーションのリスクが高まった際、影響範囲を最小限に抑える設計パターンの共通化をチーム内に展開し、安全な並行開発を可能にしました。 ## 【領域2：内部品質の向上とアーキテクチャの近代化（技術リード）】 - 目的（目指した姿）: OSのアップデートや新しい技術スタックに迅速に追従し、開発ベロシティを落とさない健全なコードベースを維持する。 - 考え方: 技術的負債の解消は単なる自己満足ではなく、将来の機能開発スピードを最大化するための投資である。 - 取り組んだ活動: Android 15への移行・OS新仕様（Edge-to-Edge等）への追従対応を主導。また、レガシーなUIコンポーネントからJetpack Composeへの段階的な移行・リファクタリング計画を策定・遂行。 - 直面した問題と工夫: 大規模プロダクト特有のレガシーコードや依存関係の複雑さに対し、一気に刷新するのではなく、機能開発と並行して安全に移行できるロードマップを作成し、バグを出すことなく近代化を推進しました。 ##【領域3：フルリモート環境における組織マネジメント（EM面）】 - 目的（目指した姿）: メンバーが孤立せず、チームの体制変更や過渡期においても、高いモチベーションとベロシティを維持して自走できる組織。 - 考え方: フルリモート環境だからこそ、意図的なコミュニケーションの場づくりと、心理的安全性の確保が組織の成果に直結する。 - 取り組んだ活動: リモートチームの融和を目的としたチームビルディング（オフラインイベントの企画・運営等）の主導。体制変更に伴う開発プロセスの再調整や、メンバーのスキルに合わせたタスクマネジメント。 - 直面した問題と工夫: 組織の体制変更期におけるメンバーの不安やベロシティの低下リスクに対し、1on1での丁寧なフォローと、スクラムプロセスの柔軟なチューニングを行うことで、リリースサイクルを崩さずにチームを安定させました。

## 開発初期から方針転換によるアプリ作り直しまで - 技術選定の為にクロスプラットフォーム技術導入検討のためにReactNativeやXamarinの調査を行ったが、メリットよりもデメリットのほうが大きいと判断してAndroid・iOSそれぞれネイティブで開発する方針に決定した。 - Androidアプリ開発自体はこのプロジェクトに入るまで未経験だったが、当時チームを組んでいたモバイルアプリエンジニアからノウハウをキャッチアップしながら開発を行っていた。 - 当時はMVPアーキテクチャを採用していたが、モデル層がデータを扱うロジックと密結合になってAPI仕様の変更に耐えきれないという問題が、サーバーサイドとのつなぎ込み時に浮き彫りになったため、APIのRequest/Responseを扱う層とアプリ内のデータを扱う層に分離することで対処していた。 - この時期の開発についての発表資料: https://speakerdeck.com/syousa1982/apurikai-fa-chu-xin-zhe-ga-androidapuriwozuo-tuteiruhua ## アプリ作り直しからサービスローンチまで - ビジネスサイドによる大規模なサービスの方針転換があり、そのために開発中のサービスを1から作り直す事になった。 - 作り直しが決まった時に当時読んでいた本(※) の影響でAACを使用してMVVMで開発する方針に切り替えたいと進言したことにより、アーキテクチャの見直しを行うことになった。 - ※ 当時読んでいた本: Androidアプリ設計パターン入門, WEB+DB vol106 - チームメンバーとペアプロしながらMVVMをベースに「API仕様の変更にも対応しやすくDIを使用して各層が疎結合であること」を目指してアーキテクチャを模索した結果、MVVMとCleanArchitectureでアプリを設計していくことになった。 - アプリを作り直すことになるまではチームメンバーからキャッチアップしながら作っていたが、アーキテクチャを選定を決めた後はチームメンバーがiOSアプリの開発に専念し、私自身はAndroidアプリの開発をメインで担当することになった。 - サービスローンチ間近にメンバーの入れ替わりが発生し、ほぼ同時期に新メンバーが増えてベテランメンバーが抜けたことにより、新メンバーに対する技術面のフォローを行っていた。 - 具体的にはタスクの割り振りや進捗について密にコミュニケーションを取っていたり、iOSのメンバーに対してもコードレビューに参加するなどの動きをしていた。 ## サービスローンチから運用開始初期 - サービスローンチ前後にアプリのパフォーマンス問題が発覚したため、実際に計測を行って原因箇所を洗い出し解決した。その当時のことについては発表資料をまとめて社外で発表した。 - https://speakerdeck.com/syousa1982/arap-osaka-1 - ローンチまでの反省を活かし開発体制を整えるためにスクラム開発を導入することになり、1週間ごとにスプリントを回し、スプリント毎にアプリのアップデートをリリースする体制になった。 - 1週間毎のリリース体制に対応できるようにするために、アプリのバージョニングルールとそれまで最低限のルールしか無かったGitHubのブランチ運用のルールをGitHub Flowをベースに考案し、モバイルアプリ開発を行うメンバーに展開して週に1回のリリースに耐えうる体制を整えた。 - 今後はローンチまでに積み上がった技術的負債を解消するために、まず手始めにAndroidアプリの自動テスト環境の整備を画策している。 ## アプリチームのリーダーに近い立ち位置に - 何度かチームに合う開発体制の模索を行う過程で、アプリエンジニアのリーダーに近い役割を行うことに。 - Androidだけでなく、iOSもコードレビューを行ったりiOSのタスクを巻き取る事が増えて来た。 - iOS特有のUI実装の仕組みやiOSでしか使ってないライブラリの使い方などキャッチアップの必要があったが、大枠のアーキテクチャはAndroidと一致させていたので、対応にはそこまで苦戦しなかった。 - 案件の性質によってはフロー効率を重視するためにモブプロ・ペアプロの導入を試みた。 ## 成果・実績（定量・定性効果） - **リリース初期のパフォーマンス問題の早期収束** - リリース直後は突貫開発の影響によるパフォーマンス不足で致命的なハングアップやクラッシュ等の課題が多発していましたが、データベースやコードの挙動を実測ベースで特定しボトルネックを解消。結果として、致命的なバグの発生頻度を対策前と比較して約80%削減し、最悪のユーザー離脱リスクを食い止めました。 - **GitHub Flow導入によるリリース手戻りの削減と週次配信の定着** - 導入前は最低限のブランチルールしかなく、コンフリクトや先祖返りによるリリース手戻りが月4〜5件発生していましたが、GitHub Flowベースの運用とバージョニングルールを徹底。導入後はリリースに起因する重大なデグレーションの手戻りを月1件以下にまで削減（約80%削減）し、週1回の定期アップデート・リリース体制を完全定着させました。 - **プラットフォームを跨いだチームリードによる予定通りのサービスローンチ** - ローンチ直前にコアメンバーの離脱という組織的リスクが発生しましたが、Android/iOS間でアーキテクチャ思想を事前に統一させていた強みを活かし、相互レビューやiOS側のタスクを迅速に巻き取る体制を構築。新メンバーのオンボーディングと並行しながらも、開発スピードを落とさず「スケジュール遅延0日」で予定通りのサービスローンチを達成しました。 - **外部への技術発信を通じたエンジニアコミュニティへの貢献** - プロジェクトで得た知見（初期開発やパフォーマンス改善）を、関西のモバイルエンジニア向け勉強会などの社外コミュニティにて発表資料としてまとめて共有。当時の発表内容は公開資料（Speaker Deck）として広く参照可能にし、自社のみならず業界全体の技術プレゼンス向上に貢献しました。