yosuke_fujii

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

## 開発初期から方針転換によるアプリ作り直しまで - 技術選定の為にクロスプラットフォーム技術導入検討のために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と一致させていたので、対応にはそこまで苦戦しなかった。 - 案件の性質によってはフロー効率を重視するためにモブプロ・ペアプロの導入を試みた。 ## 成果・実績（定量・定性効果） - **リリース初期のパフォーマンス問題の早期収束** - リリース前後に多発したパフォーマンス不満や不具合に対し、場当たり的な修正ではなくデータベースやコードの挙動を実測ベースで特定。ボトルネックを速やかに解消することで、リリース初期の致命的なシステムハングやクラッシュのバグを早期に収束させ、サービス継続不可能な最悪の離脱リスクを未然に食い止めました。 - **GitHub Flow導入によるリリース手戻りの撲滅と週次配信の定着** - ブランチ運用とバージョニングの明確なルール化により、リリース時のコードコンフリクトや先祖返りによる手戻り工数を大幅に削減。開発ベロシティを最大化させ、ビジネス施策の高速検証に不可欠な**「週1回の定期アップデート・リリース（デリバリー成功率100%）」**の運用体制を完全定着させました。 - **プラットフォームを跨いだチームリードによる予定通りのサービスローンチ** - Android/iOS間でアーキテクチャ思想を統一したことで、相互レビューやiOS側のタスク巻き取りが機能する状態を構築。ローンチ直前のコアメンバー離脱という不測の事態においても、開発スピードを落とさず【スケジュール遅延0】でサービスローンチを達成しました。 - **外部への技術発信を通じた採用広報への貢献** - プロジェクトで得た知見（初期開発やパフォーマンス改善）を「ARAP Osaka」等の外部勉強会で積極的に登壇発表。技術プレゼンスを高めることで、自社のエンジニア採用における母集団形成や広報活動に間接的に貢献しました。