教育支援アプリの開発・保守10年間の軌跡 | EdTech事例

プロジェクト概要 — 10年間の教育支援アプリ開発を振り返る

2014年にスタートした本プロジェクトは、小学生向けインタラクティブ学習アプリと幼児向け早期教育支援システムの開発・保守を行う長期プロジェクトです。10年以上にわたり継続的に開発・運用を続ける中で、技術の変遷、ユーザーニーズの変化、そして数多くの困難と学びがありました。

本記事では、EdTech（教育テクノロジー）プロジェクトの長期運用における技術的・運用的な知見を共有します。これから教育系アプリの開発に取り組む方や、長期運用プロジェクトに携わるエンジニアにとって参考になれば幸いです。

システム構成の全体像

現在のシステムは、以下の3つのコンポーネントで構成されています。

学習アプリ（iOS/Android）: 小学1年〜6年の算数・国語・理科を対象としたインタラクティブ学習アプリ。ゲーミフィケーション要素を取り入れ、楽しみながら学べる設計
管理画面（Web）: 教材コンテンツの登録・編集、学習データの分析ダッシュボード、ユーザー管理を行う管理者向けWebアプリケーション
保護者向けアプリ（iOS/Android）: お子さんの学習進捗をリアルタイムで確認できるコンパニオンアプリ。週次レポートのプッシュ通知機能付き

ピーク時の月間アクティブユーザー数は約12,000人。累計の学習ログデータは3億件を超えています。

10年間の技術スタック変遷

10年間で技術スタックは大きく変化しました。各時期の選定理由と移行の背景を振り返ります。

第1期（2014〜2016年）: Objective-C + UIKit

プロジェクト開始時、iOS開発の標準言語はObjective-Cでした。UIKitとCore Dataを使い、オフラインファーストのアーキテクチャで構築しました。

言語: Objective-C
UI: UIKit + Storyboard
データ: Core Data（ローカル）+ REST API（同期）
サーバー: Ruby on Rails + PostgreSQL（AWS EC2）

第2期（2016〜2019年）: Swift移行 + Firebase導入

2016年にSwift 3がリリースされたタイミングで、Objective-CからSwiftへの段階的移行を開始しました。新機能はすべてSwiftで実装し、既存コードは優先度の高い部分から順次書き換えていきました。この移行には約2年を要しました。

同時に、バックエンドをRailsからFirebaseに移行。リアルタイムデータベースの導入により、学習進捗のリアルタイム同期が可能になりました。

言語: Swift 3→4→5（段階的移行）
UI: UIKit（プログラマティックUI + 一部Storyboard）
バックエンド: Firebase（Realtime Database, Authentication, Cloud Functions）
分析: Firebase Analytics + BigQuery

第3期（2019〜2022年）: SwiftUI導入 + データ分析強化

2019年のiOS 13でSwiftUIが登場しました。しかし、初期バージョンのSwiftUIは安定性に課題があったため、まず設定画面や保護者向け画面など、比較的シンプルなUIから導入を開始しました。学習画面の中核部分はUIKitのまま維持し、UIHostingControllerで部分的にSwiftUIを組み込む「段階的導入」アプローチを採用しました。

UI: UIKit（学習画面）+ SwiftUI（設定・保護者向け）
アーキテクチャ: MVVM + Combine
データ分析: BigQuery + Python（学習データ分析パイプライン）

第4期（2022年〜現在）: SwiftUI中心 + AI活用

iOS 16以降、SwiftUIの安定性と機能が大幅に向上したため、新規画面はすべてSwiftUIで開発しています。学習画面の一部もSwiftUIに移行中です。さらに、蓄積された学習データを活用したAIレコメンデーション機能の開発を進めています。

UI: SwiftUI（中心）+ UIKit（レガシー部分）
AI: Core ML（オンデバイス学習推薦）+ サーバーサイドモデル
バックエンド: Firebase + Supabase（管理画面の一部を移行中）

iOS SDKの破壊的変更への対応

10年間でiOSは6から17+まで進化し、数え切れないほどの破壊的変更がありました。特にインパクトが大きかった変更と対応を記録します。

iOS 9: App Transport Security（ATS）

すべてのHTTP通信がHTTPSに強制されるようになりました。バックエンドのAPI、教材コンテンツ配信サーバー、外部連携APIすべてのSSL対応が必要でした。

iOS 13: SceneDelegate + ダークモード

アプリのライフサイクル管理がAppDelegateからSceneDelegateに変更されました。また、ダークモード対応が事実上必須となり、全画面のカラースキーム対応を行いました。教育アプリとしては、目に優しいダークモードは保護者から好評でした。

iOS 14: App Tracking Transparency（ATT）

ユーザートラッキングに明示的な許可が必要になりました。Firebase Analyticsの設定変更と、広告IDに依存しないアトリビューション方法への切り替えが必要でした。

iOS 15: 通知の集約表示

通知の表示方法が変更され、従来のプッシュ通知の開封率が低下しました。学習リマインダーの通知を「時間指定の配信」に設定し、ユーザーの注目を集めやすい形に対応しました。

iOS 17: ウィジェットのインタラクティブ化

「今日の学習」ウィジェットにインタラクティブ機能を追加し、ウィジェットから直接学習を開始できるようにしました。

技術的負債の管理と計画的リファクタリング

10年続くプロジェクトでは、技術的負債の蓄積は避けられません。しかし、計画的に管理することで、プロジェクトの持続可能性を保つことができます。

技術的負債の分類

私たちは技術的負債を4つのカテゴリに分類し、それぞれに対応方針を定めています。

緊急（Hot）: セキュリティ脆弱性、クラッシュバグ。即座に対応
計画的（Planned）: 非推奨APIの置き換え、アーキテクチャの改善。四半期ごとの技術改善スプリントで対応
許容（Acceptable）: パフォーマンスの微小な非効率。影響が顕在化するまで放置可
凍結（Frozen）: レガシーコードで動作しているが触りたくない部分。テストカバレッジを上げてから改修

四半期ごとの技術改善スプリント

各四半期の最終2週間を「技術改善スプリント」として確保しています。この期間には、新機能の開発は行わず、技術的負債の解消、依存ライブラリのアップデート、テストの追加に集中します。

このルールを守ることで、技術的負債が制御不能になることを防ぎ、長期的な開発速度を維持しています。

学習データの分析活用

10年間で蓄積された3億件以上の学習ログは、教育効果の向上に活用されています。

学習曲線の可視化

各単元ごとの正答率の推移を学習曲線として可視化。「この単元でつまずくユーザーが多い」「このゲーミフィケーション要素を追加した後、継続率が向上した」といった知見をデータから得ています。

習熟度推定（IRT: Item Response Theory）

項目応答理論（IRT）に基づく習熟度推定モデルを導入。各問題の難易度と識別力を統計的に算出し、ユーザーの理解度に合った問題を自動的に出題する「アダプティブラーニング」を実現しています。

離脱予測モデル

学習頻度の低下、正答率の急落、アプリ起動間隔の延長といった指標を組み合わせた離脱予測モデルを構築。離脱リスクが高いユーザーには、保護者向けアプリを通じてエンゲージメント施策を提案しています。

アクセシビリティ対応

教育アプリとして、すべての子どもが利用できることは責務です。以下のアクセシビリティ対応を実施しています。

VoiceOver対応

視覚に障害のあるユーザーのために、すべてのUI要素にアクセシビリティラベルを設定。問題文と選択肢の読み上げに対応しています。

// SwiftUIでのアクセシビリティ対応例
Text(question.text)
    .font(.title2)
    .accessibilityLabel("問題: \(question.text)")
    .accessibilityAddTraits(.isHeader)

ForEach(question.choices, id: \.id) { choice in
    Button(action: { selectChoice(choice) }) {
        Text(choice.text)
    }
    .accessibilityLabel("選択肢: \(choice.text)")
    .accessibilityHint("タップして回答を選択")
}

Dynamic Type対応

ユーザーがiOSの設定で文字サイズを変更した場合、アプリ内のテキストも連動して拡大・縮小されます。レイアウトが崩れないよう、柔軟なレイアウト設計を心がけています。

カラーユニバーサルデザイン

色覚多様性に配慮し、正解・不正解の表示には色だけでなくアイコン（丸・バツ）でも判別できるようにしています。

ユーザーフィードバックに基づく継続的改善

10年間で数千件のユーザーフィードバック（App Storeレビュー、アプリ内アンケート、保護者会でのヒアリング）を収集し、改善に活かしてきました。

フィードバック収集の仕組み

アプリ内評価プロンプト: SKStoreReviewControllerを使い、適切なタイミング（単元クリア時など）で評価を依頼
定期アンケート: 学期末に保護者向けアプリでアンケートを配信
ユーザビリティテスト: 年2回、実際の小学生にアプリを使ってもらい、観察とインタビューを実施

フィードバックから生まれた機能

「きょうのもくひょう」機能: 「毎日の学習量がわからない」という声から、日次目標と進捗バーを導入
音声読み上げ: 「まだ漢字が読めない低学年の子に対応してほしい」という要望から、問題文の音声読み上げ機能を追加
保護者ロック: 「子どもがゲーム部分だけ遊んで勉強しない」という課題に対し、学習完了後にゲームがアンロックされる仕組みを導入

App Store審査の変遷と対応

10年間でApp Storeの審査基準は大きく変化しました。特に教育アプリに関連する変更をまとめます。

2016年: App Store審査ガイドラインの大幅改定。メタデータの正確性に関する基準が厳格化
2018年: サブスクリプション型課金の設計ガイドラインが強化。無料トライアル期間と自動更新の説明が必須に
2020年: プライバシーラベルの導入。収集するデータの種類と用途を明示する必要
2021年: App Tracking Transparency。子ども向けアプリでのトラッキングが事実上禁止に
2023年: COPPA（児童オンラインプライバシー保護法）に準拠したプライバシーポリシーの掲載が必須に

子ども向けアプリは、プライバシーとセーフティに関する審査が特に厳しく、リジェクトを経験したことも複数回あります。審査ガイドラインの変更は定期的にチェックし、先回りで対応することが重要です。

まとめ — 長期プロジェクトで最も大切なこと

10年間のプロジェクト運用を通じて、技術的な知見以上に重要な学びがあります。それは「変化を恐れず、しかし変化を計画的に管理する」ということです。

技術は変わり続けます。Objective-CからSwiftへ、UIKitからSwiftUIへ、オンプレミスからクラウドへ。しかし、変化のたびにすべてを作り直していては、プロジェクトは成り立ちません。段階的な移行、技術的負債の計画的な管理、そしてユーザーに価値を提供し続けるという一貫した目標が、10年間の継続を可能にしました。

長期プロジェクトに携わるすべてのエンジニアに伝えたいのは、「完璧なコードベースは存在しない。しかし、継続的に改善し続けるコードベースは存在する」ということです。

教育支援アプリの開発・保守10年間の軌跡 — EdTechプロジェクトの長期運用