学習アプリ開発の進め方/やり方/流れや方法/手法/工程/手順

学習アプリ開発は、学習目標を決め、教材と操作の試作を確かめてから実装へ進むのが基本です。工程は企画から公開後の改善まで進み、各工程で決めることと、次へ進む前の確認事項があります。最初に作るのは機能一覧ではなく、学習者が問題を解き、解説を読み、復習するまでの体験です。

学習目標と利用場面の決定

企画書に残す項目として対象者、利用場面、到達目標を並べた図
三つの項目をそろえると、出題形式を考えやすくなります。

「誰が何をできるようになるか」の書き方

出題形式を選ぶには、目標を行動の形で書いておく必要があります。たとえば、「英語を学べる」を、接客で使う短い表現を聞き取り、場面に合う返答を選べるところまで具体化します。

企画書には、学習内容とあわせて利用条件も残しておきます。利用条件を書いておかないと、音声や通信が使えるかどうかを、開発の途中で決め直すことになります。

  • 対象者:年齢、前提知識、ひとりで操作できる範囲を設定します。
  • 利用場面:通学中、自宅、教室など、音声や通信を使える条件。
  • 到達目標:受講後に解ける問題や、実行できる行動の例。

一回の学習時間は、企画の段階では仮説として置いておきます。短くすれば続くとは限らないため、試作を使った観察で適切な分量を確かめます。

成果を測る指標の選定

学習内容を理解したかを知るには、起動回数より、演習の完了や単元別の正答を見る必要があります。そこで、一定期間後の再挑戦も含めて、記録する項目を分けて設計します。

初回と復習時の問題が同じだと、答えを覚えた影響が結果に混ざるおそれがあります。そのため、数値を学力の向上と直結させず、何を測った結果なのかを説明できるようにしておきます。

ポイント

目標は「誰が何をできるようになるか」まで書き、利用場面や測る指標と結びつけておきます。迷ったら、その目標から出題形式を一つ選べるかを基準にします。

教材と学習記録の要件

実装前に決める出題条件、採点条件、編集条件、既存システムとの境界を示す図
教材の扱いとデータ連携の境界を一緒に確認できます。

実物の教材を使った必要な機能の抽出

まず、問題、正答、解説をひと組用意して、登録から受講までをたどります。選択式だけでなく、画像や音声を含む教材があれば、そのサンプルも確かめておきます。

教材担当者と開発担当者は、次の三つを合意しておきます。

  • 出題条件:順番や再出題の扱いを決め、制限時間と途中再開の仕方も定めます。
  • 採点条件:複数正解や部分点の扱いを決め、未回答と講師による採点の有無も定義します。
  • 編集条件:下書きや公開予約の扱い、修正履歴の残し方、公開前の確認者。

正解を修正したとき、過去の成績まで変えるかは、実装の前に判断しておきます。教材の版と回答時点の記録が必要なら、その分をデータの設計に含めます。

既存システムとの境界の決定

学校や企業に学習管理システムがある場合は、会員情報と成績のどちらを正本にするかを決めておきます。また、二重登録を避ける方法と、同期に失敗したときの処理も必要です。

ADLのxAPI導入解説では、学習活動の記録をLRSへ送る構成が示されています。

採用する場合は、「対応済み」と書くだけで済ませず、送信する活動、識別子、受信側での表示を実データで確かめます。ただし、すべての学習アプリに必要な仕組みではありません。

ポイント

教材の出題、採点、編集の条件と既存システムとの正本の決め方は、実装の前に合意しておきます。後から変えると過去の成績の扱いまで影響するため、先に決める項目です。

試作による学習の流れの確認

一単元の試作で開始、回答、復習の順に確認する流れ図
学習体験を通して、迷いが生じる場面を見つけます。

一つの単元を最初から最後まで通す試作

最初の試作では、画面をすべて作るのではなく、一単元の学習を完結させます。説明を聞かなくても開始できるか、誤答の後に次の行動を選べるかを観察します。

一単元を通して試すと、学習者が迷いやすい場面が見えてきます。確認する場面を絞っておくと、直すべき理由が明確になります。特に、開始、回答、復習の三つで迷いが出ないかを見ます。

  • 開始:ログインや教材選択で、学習の前に迷わないかどうか。
  • 回答:ボタンの押し間違いと、問題の内容が分からない状態の区別。
  • 復習:間違えた問題に戻り、解説を確認できるかどうか。

操作に迷った箇所は記録しておき、本人の感想だけで評価しないようにします。教材の難しさと画面の問題は分けて直し、必要なら同じ課題で再確認します。

動く単位での開発範囲の区切り

会員画面だけ、管理画面だけと分けて作ると、学習できる状態は後ろへずれ込みます。そこで、教材登録から回答結果の保存までを先に接続し、その後に問題形式を増やします。

進行中の確認会では、仕様書との差分、未決事項、次の検証対象を記録します。また、追加したい機能が学習の成立に必要かを判定し、次期版へ回すものを分けます。

ポイント

試作では一単元を開始から復習まで通して確かめ、教材の難しさと画面の問題を分けて直します。開発範囲に迷ったら、学習が一通り動く単位で区切るのが目安です。

採点・端末・公開後の運用の試験

正常な回答以外のケースの確認

正解が表示されるかを見るだけでは、受け入れを完了できません。そのため、中断や教材変更が起きても、回答履歴と成績が説明できるかを確かめます。

試験データには、想定される学習の中断や更新を含めておきます。そのうえで、次の三つの場面を試します。

  • 通信断:送信の途中で切れても、回答が消えたり二重登録されたりしないか。
  • 再開:アプリを終えたあとや別端末で再ログインしたあとに、続きから戻れるか。
  • 教材修正:設問を差し替えたあとも、過去の回答を正しく参照できるか。

講師や保護者が使う画面では、閲覧できる受講者の範囲も試します。受講者画面が完成したことを理由に、運営側の確認まで省かないようにします。

審査準備と改善担当の決定

ストアへ提出する前に、審査用アカウントと教材を用意しておきます。Appleの審査前チェックでは、審査に必要なアクセス情報の提供が示されています。

子ども向けの場合は、対象年齢と配信区分に合う条件も確認します。提出直前の変更を避けるため、企画の段階でも現行のガイドラインを参照します。

公開後は、教材の誤りとシステム障害の連絡先を分けておきます。そのうえで、離脱箇所や誤答の偏りを見て、教材の改訂と操作改善のどちらが必要かを判断します。

ポイント

受け入れは、正解が出るかだけでなく、中断や教材変更の後も回答履歴と成績を説明できるかで判断します。公開後は、誤答の偏りを見て、教材の改訂と操作改善のどちらが要るかを決めます。

まとめ

学習アプリの開発は、目標の設定、教材の要件の整理、試作、実装、試験、改善の順につなげていきます。各段階で実物の教材と学習記録を使うと、抽象的なまま決めてしまうことが減ります。

着手するときは、対象者の説明、代表的な一単元、到達目標を用意してください。この三点から最初に完成させる学習体験を決めると、開発範囲を判断しやすくなります。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。