yosuke_fujii

# 1. 担当した業務・こだわった点 自社プロダクトのAndroidアプリにおいて、リードエンジニアとして機能開発および内部品質・アーキテクチャの近代化を主導しつつ、EM/リーダーとしてフルリモート開発組織のマネジメントとプロセス改善を推進しました。 ## 【領域1：大小さまざまな機能開発とプロダクトの継続デリバリー（事業・プロダクト貢献）】 - どのような問題があったか: 建設ドメイン特有の複雑な業務要件（オフライン動作、大容量図面・写真の描画処理等）に対し、並行開発が増えるにつれて仕様齟齬やコードコンフリクト、デグレーションのリスクが増加していました。 - なぜ今まで未解決だったか: 短期的な機能デリバリーが優先され、Android固有の制約やライフサイクルを上流の仕様策定段階で擦り合わせるプロセスや、機能間で共通化された設計パターンが確立されていなかったためです。 - なぜその解決方法をとったか: 仕様策定の上流フェーズからビジネスサイド・デザイナーと連携し、Androidの制約を踏まえた現実的かつ最適な仕様へチューニングを実施。さらに、影響範囲を局所化する疎結合な設計パターンを展開しました。 - 具体的な成果・インパクト: 手戻り工数を大幅に削減し、複数機能の並行リリース時におけるデグレーション発生を抑制。ビジネスサイドとの合意形成スピードが向上し、品質を担保した高速なデリバリーサイクルを確立しました。 ## 【領域2：内部品質の抜本的向上とアーキテクチャの近代化（技術リード）】 - どのような問題があったか: 長年の機能追加に伴う技術的負債により、アプリのクラッシュフリー率が約79%と低迷。OS新仕様（Android 15、Edge-to-Edge等）への追従遅延や、機能追加時の保守性低下が深刻化していました。 - なぜ今まで未解決だったか: 既存コードの依存関係が複雑に絡み合っており、一括での刷新はリリース停止やバグ混入のリスクが高く、日々の開発の中で根本的な改修に着手できていませんでした。 - なぜその解決方法をとったか: 開発を止めずに安全に負債を解消するため、「機能開発と並行した段階的リファクタリング戦略」を採用。Firebase Crashlyticsのログ分析に基づく優先度付け、E2Eテスト自動化・CI/CD改善によるデグレ防止網の構築、Jetpack Composeへの段階的移行ロードマップを策定・遂行しました。 - 具体的な成果・インパクト: **クラッシュフリー率を79%から99%超へと大幅に改善・維持**。アプリの安定稼働によりストア評価とユーザー体験を向上させました。また、テスト自動化によりQA工数を削減し、OSアップデートにも迅速に追従できる強固なコードベースを構築しました。 ## 【領域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）として広く参照可能にし、自社のみならず業界全体の技術プレゼンス向上に貢献しました。