フェーズごとに“やり切る細部”を変える　〜動画アプリ iOS/Android リニューアルを危機ゼロで完遂したプロジェクト設計術〜 by 野瀬田　裕樹

10年運用された動画プレイヤーアプリ（iOS/Android)の全面リニューアルを、入社直後の状態から立ち上げ、iOS→Androidの二段階で約2年で完遂しました。
特徴は、プロジェクト中に目立った危機や炎上が一度も起きなかったことです。
本セッションでは、その理由を「フェーズごとに集中すべき細部を変える設計思想」として一般化して紹介します。

まず事前準備フェーズでは、事故を起こさない土台作りに全振りしました。
全画面デザイン・内部のデータ構造・API仕様を最初に読み解くことでドメイン知識を獲得し、それを元に事前に技術的なリスクを排除しました。
見積もりはSLOC・画面単位・感覚値の3軸で整合を取り、「最悪自分一人で最後までやり切れる」まで段取りを固めました。
CI/Lint/初期設計もこの段階で仕上げ、“事故が起きない世界線”を先に作りました。

進行フェーズでは、価値の源泉を「チームの成長と自律性の向上」に置き換えました。
初期は認知負荷が高いため学習負荷を意図的に抑え、キックオフを複数回行ってプロジェクトの全体像を浸透させました。
中盤、振り返りで出た課題に対応する形で勉強会やPRの口頭共有などを導入しました。
また、開発の計画では類似領域をまとめて開発するよう計画することで、認知負荷を減らしスプリントごとにフォーカスする領域が発散しないよう集中の原則に徹しました。

終盤フェーズでは品質改善に全振りしました。
VoiceOverやアナリティクスなどの非機能対応を開発後半に計画し、お触り会で仕様理解と品質を同時に高め、警告ゼロを維持するCIと組み合わせることで、QAフェーズに入る頃には“勝てる状態”が完成していました。

本セッションでは、この「フェーズごとにやり切る細部を変える」アプローチを、段取り・チーム成熟・品質戦略の3軸で解説します。

■ 対象の聴衆
アプリ開発プロジェクトを主導するEM、テックリード、PM

■ 得られる知見

• フェーズごとに“やり切る細部”を切り替えるプロジェクト設計方法
• チーム成熟度に応じてプロセスを進化させる“守破離マネジメント”の実践手法
• スプリントの発散を防ぐための、集中の原則に基づく開発計画の作り方
• 終盤フェーズで品質の天井を上げる、非機能要件×お触り会の品質戦略