向こう10年戦える基盤を。システムリプレイスPJの全貌(基盤構築フェーズ編)

自己紹介

株式会社Schooの福嶋淳一です。
現在は、PjM/PLとして、システムリプレイスのプロジェクトリードを担当しています。

Schoo Advent Calendar 2025の10日目の記事です。

記事の概要

2024年12月より、弊社の中核プロダクトであるschoo.jp(※1)のシステムリプレイスプロジェクトが進行中です。私はこのプロジェクトにおいてプロジェクトリーダーという役割を担当しています。

そこで得た経験を元に、

• プロジェクトの進め方
• その中で得た学びや気づき
• 成功したこと
• 失敗したこと

について書いていきます。

出来るだけ実施したことを具体的かつ網羅的に書いた上で自分自身の感じている良かったこと/悪かったことについてざっくばらんに書いていきたいと思います。

※1 Schoo（schoo.jp）のサービス紹介

Schoo（schoo.jp）は、創業時から運営を続けているSchooの中核プロダクトです。

https://schoo.jp/

主な特徴は次の通りです。

• 生放送 - 「一生、学べる学校」というコンセプトのもと、365日、授業をライブ配信しています。コメント欄を通じて、講師と受講生、あるいは受講生同士が一体感を持って学びを深めることができます。オープン会員（無料会員）でも参加可能です

• アーカイブ - ライブ配信された授業はアーカイブされ、いつでも後から視聴できます（一部例外あり）。これはプレミアム会員（月額制会員）限定のサービスです

• Schoo for Business - 企業が従業員の学びを促進するために、Schooのアーカイブを活用できます。従業員はビジネスプラン会員として、プレミアム会員と同等のサービスを受けられます。また、企業はSchooのコンテンツを用いた社内研修を従業員に受けさせることも可能です

参考: エンジニア向け紹介資料

システムリプレイスを行う背景

主な背景は、以下の通りです。

• システムの老朽化
• メンテナンスの困難化
• サイト応答性の悪化

本来であれば、

• サポート期限が迫るバージョンを使っている → 新しいバージョンへの置き換え
• 性能が悪化している → 性能改善の実施

といった対応を行うべきでしょう。しかし、運用が長期になるにつれ、投じるコストに対して得られるリターンが少ないという課題感が顕在化してきました。また、メンテナンスが困難であるため修正にかけるコストが大きく、結果として施策の実行スピードが低下しているという実情がありました。

システムリプレイスを行うと決めた理由

弊社として、

• セキュリティリスクの払拭
• 根本解決を行い、性能面での抜本的な改善を図る
• 開発負荷を減らし、市場のニーズに素早く応える

が最も求められる重要な局面だと捉えました。そのための手段として、システムリプレイスが最も適切だと判断しました。

また、サービスの成長には、ビジネス面だけでなく、技術面でも時代の潮流に合わせたシステム運用を行うことが、向上心の高い優秀なエンジニアの採用という観点からも不可欠だと考えたことも、リプレイスを行う決め手の一つとなりました。

今のSchooサービスに適したフレームワークを改めて比較検討し、今後の未来を見据え、以下のような技術選定を行いました。

技術選定の背景は、今回の記事のテーマとは逸れるので、過去に私が登壇した際の資料を参考にして頂けますと幸いです。

システムリプレイスPJの目的

大目的

システムリプレイスプロジェクトは、以下の点を大目的として進めました。

• セキュリティリスクの払拭
• サイト応答性の改善
• システム品質の向上
• 変更容易性の高いシステムの構築

向こう10年耐えられるシステムを作るため、「次世代プラットフォームの構築」を目指し、全メンバーでシステムリプレイスに取り組みました。

システムリプレイスの進め方

組織体制

規模の大きい改修となるため、システムリプレイスのプロジェクトチームを編成し、以下の役割を定めてプロジェクトを進めていきました。
プロジェクトリーダー (PjL)である私とアプリ開発者 (Dev)6名が他のロールの皆さんの協力を経て開発を進めていきました。

ロール	詳細
プロジェクトオーナー (PjO)	・経営との接続 ・ステークホルダーへの説明
プロジェクトマネージャー (PjM)	・プロジェクトの進行管理 ・プロジェクト課題の把握・検討 ・チームビルディング ・PjL, アプリ開発メンバーの指導・支援・育成
プロジェクトリーダー (PjL)	・アプリ開発者としての役割を含む ・開発の進行管理・推進 ・技術課題の把握・検討 ・チームビルディング
プロダクトマネージャー (PdM)	要件定義
デザイナー	・フロントエンドデザイン指定
アプリ開発者 (Dev)	・開発環境準備 ・設計 ・工数見積もり ・開発 ・デバッグ ・リリース準備
リードアーキテクト (LA)	・アプリ開発者としての役割を一部含む ・標準化の推進
インフラ開発者 (InfraDev)	・インフラ設計 ・インフラ構築

リプレイス方針

移行方式

弊社におけるシステムリプレイスでは、段階移行方式を採用しました。段階移行方式であるため、旧システムと新システムの併用期間が存在します。

ちょうど2025年9月に一部移行が完了しましたが、移行は各ディレクトリ（≒ページ単位）で実施しました。移行対象とした部分については、できる限り旧システム側の追加開発、保守、運用を停止するよう、関係する各種チームに連携した上で進めました。

なぜ段階移行方式なのか

• 事業優先度を鑑み、目下の施策は継続的に推し進めたい
• 一方で、先ほどもお伝えしたように、中長期の観点からシステムリプレイスは推進したい

という2つの理由のためです。

開発手法

今回のシステムリプレイスについては、ハイブリッド開発の手法を取り入れました。

ハイブリッド開発とは、開発手順を一つひとつ確認しながら工程を進める「ウォーターフォール型開発」と、仕様や設計の変更を前提として厳密な仕様は決めずにイテレーション（反復）を繰り返す「アジャイル開発」という二つの開発手法の利点を組み合わせたものです。

出典: ハイブリッド開発とは何か？ “アジャイル型”との違いや推進体制を解説

背景としては、以下の要因がありました。

• 新システムにおける土台構築の規模が大きいこと
• 技術的な実現可能性や技術検証などをじっくり行う期間が求められたこと

PJ走りだし(2024年12月-2025年2月/期間: ３ヶ月)

概要

システムリプレイスに限らず、様々なプロジェクトの走りだしは、何から着手すべきか迷うことが多いのではないでしょうか。まるで白いキャンバスの上に絵を描き始める時が一番迷うように感じるかと思います。

色々迷いはありつつも、以下の三点をテーマとして進めてきました。

• 構想を描くための材料を集めること
• システムの全体構成をメンバー全員で描くこと
• プロセスを整備し、メンバー全員が迷わず動けるような基盤を整理すること

大事にしてきたこと

PJ走りだしの期間に限らず、「メンバー全員が一つの目標に向かい、役割や経験によらず協力をし合えるチームを作りたい」という思いがありました。

そのため、プロジェクト全体を通して以下の点を重視しました。

• プロジェクトの大目的を見失わないこと
• プロジェクトのボトルネックとなる人を作らないこと

今回、システムリプレイスに関わってくれたメンバーは、多様な経験やバックグラウンドを持った方々で構成されています。

例えば、バックエンドのエキスパート、フロントエンドのエキスパートなど、技術的バックグラウンドの異なる方がいます。それぞれのメンバーのバックグラウンドに依存した進め方をしてしまうと、プロジェクト進行のリスクになりかねません。

そのため、

• Mob Designing（=モブプログラミングのように、全員で設計を行うこと）
• 役割や経験を活かしつつ、各々の領域を積極的に超えてもらうよう促す

などを積極的に行ってきました。

何をしたか

構想を描くための材料を集める

• 要件の明確化と認識合わせ

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • 大目的を見失わないようゴールを明確にすることで、チーム全体で1つの目標に向かえる状態を作れるようにするため
  • やったこと
    • プロジェクト要件の読み合わせ
      • プロジェクトのゴール
      • プロジェクト成功/失敗
      • やること/やらないこと
      • プロジェクトメンバーの役割 etc,,
    • 機能要件/非機能要件の読み合わせ

• 走り出しの期間に何をやるのか整理

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • 走り出しで複数のメンバーが同じ作業を行ってしまいムダが発生することを防ぐため
  • やったこと
    • 走り出しの期間のゴールを設定
    • ゴールに向けて必要なタスクの認識合わせ

• 影響範囲の明確化

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • 思わぬ影響がないかを明確にし、あと工程でのリスクを低減するため
    • 概要レベルで各システムがどのような責務でどういったこと処理が行われているか概要を知り後の開発に活かすため
  • やったこと
    • 既存システム調査
      • 既存システムの構成はどうなっているか
    • 改修対象ページの仕様調査
      • 改修ページにおける概要レベルのシーケンス図作成
      • 既存テーブルの調査
    • 認証認可周りの調査

• 既存システムの課題把握

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • 既存システムの根深い問題は何かを解像度高い状態にし、既存課題や過去の失敗を明確にし、全体設計に活かすため
  • やったこと
    • システム全体を俯瞰してどういった問題があるか
    • リプレイス対象箇所においてどのようなことがボトルネックになっているのかを調査
    • なぜボトルネックになっているのかを分析

システムの全体構成をメンバー全員で描くこと

• プラットフォーム設計/システムアーキテクチャの決定

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • システムの全体構成を明確にし、各レイヤーのアーキテクチャ設計ができる土台を作る
    • 新システム/旧システムの互換性を担保するためのイメージをつけておくため
  • やったこと
    • 認証認可の方針を決める
    • システムの全体構成を決め、シーケンス図に起こす
      
    • ログ設計などをどうするか など

• 各レイヤーのアーキテクチャ設計(≒プログラムアーキテクチャ)を実施

  なぜやるのか・やったことの詳細

  • 前提
    • システムの基盤(インフラ)については、常にある仕組みを流用するのでアプリケーションレベルの話が中心
  • なぜやるのか
    • 詳細設計以降の実開発にスムーズに入れるようにするため
    • 実開発を進める前に技術的な検証だったり、リスクをできるだけ潰して手戻りを防ぐため
  • やったこと
    • 検討事項の洗い出し
    • 技術スタックの検討(フレームワーク/ライブラリなど)
    • アーキテクチャ設計
      • 技術スタック
      • 品質設計、テスト戦略の策定
      • レポジトリ構成
    • POCの実施

• 基本設計(全体)

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • プラットフォーム設計/アーキテクチャ設計に基づき、どのレイヤーでどういった開発が必要かイメージし、開発ボリュームがどれくらいになりそうか目処を立てるため
  • やったこと
    • それぞれの画面でどういった実装が必要か/どういったAPIが必要かを図式化しながら整理をしていく
      
    • 各種APIのI/F・エンドポイント・入出力の定義を実施
    • バッチ処理一覧や処理フロー定義の作成

• 非機能要件設計

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • シフトレフトの考えに則り、どのように非機能要件をクリアしていくか、どのようなリスクが出てきそうかを明確にすることで非機能面での手戻りを防ぐようにするため
  • やったこと
    • 性能設計
      • どういったテストをどこで実施するのかを明確にする
      • 何ができていれば非機能要件をクリアできたかを明確にする
    • セキュリティ設計
      • 要件時点で考えるべきことの整理
        • 資産保護 / 内部組織 / 人的資源観点で考えることはあるか
      • 設計工程で考えるべきことの整理
        • アーキテクチャ観点で考えるべきことは何か
        • インフラ観点で考えるべきこと
      • 製造工程で考えるべきことの整理
        • セキュアプログラミングの観点
        • ライブラリ関連の脆弱性の観点
      • テスト工程で考えるべきこと
        • インジェクション/認証の不備など
        • データ可視性の観点(見せてはいけない人にデータを見せてないかなど)

• 課題管理(≒リスク管理)

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • 基本設計段階で潰せる課題/リスクに対して対処できているかの確認し、今後大きな手戻りや問題が発生しないかのモニタリングするため
  • やったこと
    • 要件定義/基本設計で実施しているものについて、開発をこのまま進めて問題なさそうかの認識合わせをPjMと実施
      

• 基本設計をベースにした作業見積もりの実施

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • プロジェクト全体の開発がどれくらいに終わるか見通しを立てるため
  • やったこと
    • 各種APIのI/F・エンドポイント一覧から作業ボリュームを出す

プロセスを整備し、メンバー全員が迷わず動けるような基盤を整理すること

• 開発プロセスの整備

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • プロセスやルールを整えメンバーが迷わず仕事を進められる状態を作るため
  • どんなことをしたか
    • 過去の開発の進め方の反省点を聞き込み
    • 開発フロー(MTGの体制/レビュールールetc)の整備し図に起こす
      
      

• チームビルディング

  なぜやるのか・やったことの詳細

  • なぜやるのか
    • 自己理解/他者の理解を深めることで関係構築をし、心理的安全性を高めることで、技術的な懸念や課題を早期に発信・相談し合える土壌を整え、メンバー全員が大目的を見失わず開発を進められるようになるため
  • どんなことをしたか
    • 価値観カードを使ったワークショップを実施し、お互いの人となりを知る機会を作る
    • キックオフを実施して、プロジェクトを進めるとき大事にしたい価値観を整理する

振り返り(チーム全体の観点)

良かったこと

• 特定のメンバーがボトルネックにならないような取り組み

  • 何をしたのか
    • システムのコアとなる設計はを全メンバーと同期的にMob Designingにて実施
    • 基本設計フェーズにおけるレビューは、基本的に全てのメンバーで行った
    • 新しい技術は一部のメンバーでPOCを実施してもらったが、その後勉強会を実施し知識の平準化を図った
  • なぜ良かったのか
    • 知識の平準化を行うことで、各々の得意領域ではない部分においても積極的にサポートができるきっかけになった
  • デメリット
    • 全メンバー同期的に行うので、発言量がメンバーによってムラが出てきてしまう
    • 短期的な時間的なコストは大きい
    • 途中からレビューする数が膨大になったのでその点は、バックエンド/フロントエンドエンジニア毎に作業分担を行なっていくようにした
  • メンバーからの声
    • 自分の主戦場の範囲外の領域を担当することで、話す機会を多く作ることができ関係性を深める機会になった

• 振り返りの実施

  • 何をしたのか
    • 2週間に一度チーム内で、技術面/プロセス面における振り返りを実施
    • 明確なアクションプランをきめ、必ず次の振り返りまでにアクションを実施する
  • なぜ良かったのか
    • 明確なアクションプランと期日を決めることで着実に改善の兆しが見えてきた
      • (例)プロセス面: 確認フローの見直しを何度も見直すことで手戻りを防ぐフローを確立することができた
      • (例)技術的側面: テストのあり方を何度も定義し直し、堅牢かつ柔軟性のあるテスト戦略を決めることができた
  • メンバーからの声
    • 振り返ってどんどん良くしていこうという風土が醸成された

改善点

• 技術検証に、より大きな工数を割いた方が良かったかもしれない

  • なぜそう思ったのか

    • ① 実装フェーズの段階で、使用実績のないライブラリの制約に苦しんだり、使い方に迷った場面が多かったように思える
    • ② 認証認可などのいわゆる共通基盤に該当する箇所の開発に苦労したため

  • どうすれば良かったか

    • 代表的なユースケースを1本もしくは複数本選択をし、焦らず以下をしっかり検証することが必要だったと考えております
      • アプリケーション基盤に必要な共通機能を網羅すること
      • アプリケーションの各層が一通り通過する
      • 外部サービスとの連携
      • 初めて使うライブラリ、技術リスクを検証する
        

  • メンバーからの声

    • 1つの機能を一気通貫で試しに使ってみてみることで技術面でのリスクを大きく下げることができる
    • 使ったことないライブラリなどは必ず検証をする工数を別途取るべきであった

振り返り(プロジェクトリーダーである私自身の観点)

良かったこと

• 自らも手を動かし、一次情報を手に入れたこと
  • やったこと
    • 自分が詳しくない技術領域についてキャッチアップを積極的に行う
      • 今回使用した技術であるNuxtやHonoなどの公式ドキュメントを読み漁り自身で手を動かしサンプルアプリケーションを実装する
      • わからないところについてはメンバーを頼り積極的に質問をする
    • 旧システムの修正範囲におけるソースコード/ドキュメントは全てキャッチアップを行う
  • 良かったこと
    • 自ら一次情報に触れることで、技術的/プロジェクトのリスクへの感度を高めることができた

改善点

• バッファなしの見積もりスケジュールが先行してしまった
  • 前提
    • 当初なるべく早くリリースをしていこうという目的のため、一旦バッファなしでスケジュールを立てることになりました
  • 結果どうなったか
    • 厳しいスケジュールになっていき、メンバーに負担を強いてしまった
    • 目先の開発速度を求める結果、内部品質に影響を与えやすい状況になった
  • それに対してどうしたか
    • 問題提起を行い改めて、バッファ込みの見積もり計画の再実施
    • その結果メンバーの負担が軽減できただけなく、品質を考慮した作り込みができただけでなく、概ねスケジュール通りのリリースを達成することができた
  • 学び
    • プロジェクトを管理するものとして、プロジェクトを守るという視点も大前提大事ではありつつもメンバーを守るという視点もプロジェクトを成功させるという上で必要不可欠であることを痛感
      • プロジェクト不確実性のコーンに則り、見積もり誤差はプロジェクトの性質上あることを初期の段階でしっかりネゴシエーションするべき

最後に

振り返りをしながら感じたのは、

• 大目的を見失わず、みんなで頂上を目指すこと(助け合い、特定の人をボトルネックにしない)
• 細かい振り返りの連続とアクションの実行
• 技術的リスクを潰すために時間を惜しまない(=目先の速度よりも中長期の速度)

がとても重要であるということです。

昨今、生成AIをはじめとする様々なツールが台頭し、開発のあり方は劇的に変化しています。しかし、ビジネスの中長期的な成長を見据えたこのシステムリプレイスは、単なる作業の集合体ではありません。

プロダクトの未来を信じ、不確実な課題に対してチームで悩み、合意形成を積み上げていく。このプロセスに宿る「意志」や「熱量」こそが、AIには代替できない、私たち人間にしか生み出せない価値であると確信しています。

我々は、システムのリプレイスは、「単なる技術の置き換え」と位置付けていません。
受け取ったバトンをしっかりと次の世代へ胸を張って渡せるよう、今後10年を見据えた次世代プラットフォームの構築を目指しています。

続編について

基盤構築フェーズ編の続編は開発/実装フェーズ編になります！タイミングを見て公開いたします！

---

Schooでは一緒に働く仲間を募集しています！