ID:36575さん

## プロジェクト概要 既存プロダクトは10年以上続く大規模なサービスであったが、全体が密結合構造になっていた。そのため、機能追加や修正時の影響範囲が大きく、開発効率・品質ともに課題が顕在化していた。 また、営業現場からは「機能単位での柔軟な販売（モジュール販売）」を強く求められていたが、現状の構造ではオールインワン販売しかできず、競合とのコンペで失注が発生していた。さらに、顧客からはAndroid対応への強い要望もあり、モバイル領域での技術選定と4ヶ月という超短期での再構築が急務となっていた。 この状況を踏まえ、私はEM／PMの立場として、予算（カネ）枠の前提に基づいた「ヒト（体制・要員）」と「モノ（技術・プロセス）」の最適化に集中。技術戦略の策定から実行計画、必要な体制構築までを一気通貫で推進した。 --- ## 1. アーキテクチャ改善 ### 【課題】 - 既存アプリは機能間が密結合で、小さな修正でも全体に影響。工数増大・デグレの頻発・障害復旧の遅延につながり、ユーザー不信の原因になっていた。 - 顧客ニーズや競合対策として不可欠だった「機能単位でのパッケージ提供」がシステム構造上、事実上不可能だった。 ### 【解決策・工夫点】 - マルチモジュール化を前提としたアーキテクチャの再設計を主導し、機能単位で疎結合にすることで影響範囲を局所化。 - モジュール単位での販売・バージョン管理が柔軟に行える構造を設計し、ユーザー価値（ビジネスの柔軟性）と開発価値（変更の容易性）を両立させた。 ### 【成果】 - 設計段階から「機能単位で展開できる構造」が整い、販売戦略の幅を大きく広げた。 - 機能追加・修正時の影響範囲が縮小され、将来の開発生産性と品質の大幅な改善に道筋をつけた。 --- ## 2. クロスプラットフォーム（Flutter）選定 ### 【課題】 - 現場の端末コストを抑えるためAndroid対応が必須であったが、既存の密結合実装のまま2プラットフォーム（iOS/Android）を個別保守するのはリソース的に不可能だった。 - 現場業務に耐えうる描画パフォーマンスの確保と、事業スピードを担保できる技術選定のシビアな判断が求められた。 ### 【解決策・工夫点】 - React Native / Flutter / 側ネイティブの3軸で、描画パフォーマンス、現場業務への適応性、社内資産（既存iOSメンバーのスキル適合）を評価指標として比較。 - 実装試作（PoC）を行い、性能と開発効率を客観的に評価。事業企画に対して「ユーザー価値」「開発コスト」「リリーススピード」の観点からロジカルに説明し、合意を形成した。 ### 【成果】 - ネイティブに遜色ない描画パフォーマンスを確認し、現場での実用に耐えうる見込みを立てた。 - 1コードベースでiOS/Android双方にモジュールごとの機能展開ができる布石を打ち、リードタイム短縮の基盤を作った。 --- ## 3. 人員調達・体制構築 ### 【課題】 - 10年モノのシステムを、開発期間「4ヶ月」という極めてタイトなスケジュールでリプレイスする必要があったが、社内リソースが圧倒的に不足していた。 - 期間優先のプロジェクトであるため、状況に応じた人員追加の可能性を想定し、新メンバー参画時のコミュニケーションコスト増大による速度低下リスクをあらかじめ排除しておく必要があった。 ### 【解決策・工夫点】 - 技術的難度に見合ったスキル要件を定義し、どのフェーズで何名必要かを「ロードマップ形式」で具体化して経営陣へ提示。 - 将来的な人員追加の可能性（不確実性）に備え、誰がいつ参画してもすぐにキャッチアップしてバリューを出せるよう、開発フローの標準化とドキュメント整備を並行して仕組み化した。 ### 【成果】 - 経営層からの信頼と迅速な承認を獲得し、プロジェクトを「組織的な投資」として正式にスタートさせた。 - **10年以上続く大規模サービスのリプレイスを、予定通り4ヶ月で完遂。** - 実際にプロジェクト途中でメンバーが参画した際も、事前の仕組み化が功を奏し、**チームの開発速度を一切落とすことなく、即座に立ち上がってアウトプットを出せる組織状態**を証明した。 --- ## 4. AI前提の開発スタイル構築 ### 【課題】 - 4ヶ月でのリプレイスとFlutter移行を同時にやり切るには、従来の開発プロセスのままでは開発生産性がボトルネックになることが明白だった。 - 途中参画メンバーのスキル差やレビューコストを組織的に吸収し、高いコード品質と圧倒的なスピードを両立させる仕組みが必要だった。 ### 【解決策・工夫点】 - **Custom Lintによるアーキテクチャの強制（ガードレール）** 標準のLint/Formatterに加え、独自の「Custom Lint」を導入。モジュール間の不正な依存関係を静的解析レベルで自動検知・遮断し、エンジニアの経験値に頼らずシステム的にマルチモジュール構造を厳守させる環境を構築した。 - **仕様共有会からのドキュメント自動生成** 仕様共有会のMTG議事録をベースに、AIを活用して仕様書を自動生成。ドキュメント作成の工数を劇的に削減し、新メンバーの仕様理解を高速化させた。 - **品質保証プロセスの再定義（コード自体の価値の低コモディティ化）** 「コードを書くこと自体はAIで高速化できる」という前提に立ち、人間が注力すべきポイントを「品質保証」へシフト。実装時にPRD（製品要求仕様書）とテストシナリオをセットでAI等に作成させ、実装者自身による厳格な動作確認（実機テスト）を必須化した。 - **Unit Test（C1カバレッジ100%）のルール化** ロジック品質を強固に担保するため、C1カバレッジ（分岐網羅率）100%を必須ルールに設定。AIによるテストコード自動生成と組み合わせることで、エンジニアの負担を最小限に抑えながら高密度な品質管理体制を確立した。 ### 【成果】 - ボイラープレート（定型コード）やユニットテストの作成工数を劇的に削減し、**「4ヶ月での超短期リプレイス」を支える最大の推進力**となった。 - ドキュメント生成やレビューの自動化、ガードレール（Custom Lint）の導入により、新規参画メンバーのキャッチアップコストを最小化。**「人の入れ替わりや追加があっても、開発速度が停滞しない」強固な組織基盤**を実現した。 - 「優秀な個人」のスキルに依存せず、ツールとプロセスによって「最速で最大価値をデリバリーできる」モダンな開発組織のモデルケースを確立した。