連載目次
| 回 | 内容 |
|---|---|
| #1 | 企画・課題発見（この記事） |
| #2 | 要件定義 |
| #3 | 設計（データ構造） |
| #4 | データ処理・ロジック実装編 |
| #5 | UI・画面実装編 |
| #6 | テスト・CI/CD構築編 |
| #7 | 開発中に遭遇した技術的問題 |
| #8 | 完成・振り返り |
はじめに
長い文章を覚えるためのWebアプリ「暗記ノート」を作りました。
覚えたい文章を貼り付けると、「暗記」「穴埋め」「キーワード」の3つの見せ方で練習できます。データはブラウザの中（localStorage）だけに保存するので、アカウント登録なしですぐに使えます。
この連載では、企画から完成までの流れを全8回で書いていきます。第1回は、なぜこのアプリを作ろうと思ったのか、何を課題としたのかを書きます。
きっかけ：長い文章が本番で出てこない
面接の自己紹介、発表会、スピーチなど、人前である程度まとまった長さの文章を話す場面があります。こうした場面では、原稿をある程度覚えておかないと、本番で言葉が出てきません。
ところが、暗記アプリを探してみると、英単語や用語のような短いものを覚えるためのアプリがほとんどでした。長い文章をまるごと覚えることに特化したアプリは、あまり見つかりませんでした。
それなら自分で作ろう、というのが出発点です。想定する利用者は、まずは自分自身にしました。
困りごとを書き出す
最初は「文を隠して覚える」くらいしか機能を思いつきませんでした。そこで機能から考えるのをやめ、長文を覚えるときに実際に困っていることを書き出しました。
- 覚えたつもりでも、本番で言葉が出てこない
- どこまで覚えられているか、自分で把握できない
- 一人だと、声に出して練習しづらい
- 練習する時間や気力が続かない
4つとも自分に当てはまりました。以降の機能は、どれもこの4つのどれかを解決するためのものとして考えています。
アイデアを広げる（ラフスケッチ）
困りごとをもとに、機能のアイデアを絞り込まずにすべて書き出しました。この段階では「どれが一番大事か」は決めないようにしました。
| 分類 | アイデア |
|---|---|
| 表示・隠し方 | 文を隠す（全部／一部）、穴埋め、徐々に隠れていく、キーワードだけ表示、詰まったときだけヒントを出す |
| 声に出す | 音声認識で発話チェック、自分の声を録音して聞き返す、お手本の読み上げ、本番シミュレーション |
| 進捗・記録 | 文ごとの習熟度、進捗バー、練習ログ、復習リマインド、苦手な文のブックマーク |
| 継続 | すきま時間モード、連続練習日数の表示 |
| その他 | カテゴリ分け、文字サイズ・ダークモード など |
「アプリが判定しない」と決めた
最初は、このアプリで一番大事なこと（成功のための鍵）を「声に出して言えるようになったかを、アプリが正しく判定できること」と考えていました。音声認識で読み上げを採点するようなイメージです。
しかし考え直してみると、「言えるようになったか」を一番よく分かっているのは本人です。アプリが採点する必要はありません。そこで方針を次のように変えました。
- 成功の鍵：本人が「声に出して言えた」と実感できる練習環境を用意すること
- 音声認識による自動採点は作らない
- 習熟度は、練習した本人が自分で選ぶ（自己申告）
この判断によって、音声認識のような重い仕組みがなくても、アプリの目的を果たせるようになりました。完成版の「未着手／暗記中／習得済み」を自分で選ぶ機能は、ここから来ています。
名前を決める
名前は、覚えやすく、何のアプリかがすぐ分かることを基準に考えました。
英語の候補も出しましたが、日本語のほうが用途が伝わりやすいと考え、日本語で考え直しました。「そらんじる」「暗記帳」「長文暗記ノート」などを経て、最終的に 「暗記ノート」 に決めました。
「長文」を名前に入れる案もありましたが、短く呼びやすいほうを選び、「長文暗記に特化している」ことはトップページの説明で伝えることにしました。
まとめ
- 長い文章を本番で話せるように覚えたい、という自分の困りごとから企画した
- 機能より先に困りごとを4つ書き出し、そこからアイデアを広げた
- 「言えたかどうか」はアプリではなく本人が判断する、という方針にした
ラフスケッチで出したアイデアは、すべてを最初の版に入れたわけではありません。次回は要件定義として、この中から何を最初の版（MVP）に入れ、何を見送ったのかを書きます。