テストが通っても、実機では最後まで操作できなかった

今日は、開発中の学習アプリで、入力練習にヒントとお手本を見る機能を追加しました。

ただ、今回いちばん印象に残ったのは新機能そのものではありません。

自動テストでは問題がなかったのに、自分のスマートフォンで確認すると、

画面の一番下までスクロールできない。

という問題が見つかりました。

今回は、その原因を切り分けながら修正した記録です。

課題：間違いは分かっても、直し方が分からない

これまでの練習は、

入力する。
正しいか確認する。
間違っていれば直す。

というシンプルな流れでした。

でも、

「間違っているのは分かった。でも、どう直せばいいか分からない」

という状態もあります。

そこで今回は、

まず自分で考える。
必要ならヒントを見る。
それでも分からなければお手本を見る。

という段階を追加しました。

判断：答えを見ても、自動で正解にはしない

ここで決めたのは、

お手本を見ることと、正解することは別にする

ということです。

答えを見ても、入力欄が自動で書き換わったり、正解扱いになったりはしません。

最後は自分で入力を直して、もう一度確認します。

また、問題を切り替えたり、画面を回転したりしたときには、開いていたヒントや答えを閉じるようにしました。

便利にしても、考える工程まで自動化しないためです。

実際にやったこと：前回の続きから再開

今回はゼロから作り直したわけではありません。

前回までに実装していた正誤判定について、残っていた実機確認をチェックポイントから再開しました。

空欄の状態。

不一致の場合。

表記の違い。

入力を直した後の再判定。

問題を切り替えたときの状態。

画面回転後の入力保持。

などを確認しました。

途中では、検証用に入力した文章がスマートフォンのキーボードによって別の文字へ変換されることもありました。

ここでも、

入力したつもりではなく、実際に何が入力されたかを見る

必要がありました。

結果：必要なときだけ助けを出せるようになった

修正後は、

自分で入力する。
正誤を確認する。
必要ならヒントを見る。
お手本を見る。
入力を直して再確認する。

という流れが使えるようになりました。

ただし、自由に書いた文章をAIが何でも添削する機能ではありません。

あらかじめ登録したお手本や別解と比較する仕組みです。

失敗：テストは成功。でも最後のボタンへ届かない

実機でヒントとお手本を同時に開くと、画面が長くなり、一番下の操作ボタンまでスクロールできない問題が見つかりました。

最初はスクロール部分の実装を疑って修正しました。

でも、直りませんでした。

そこで同じ場所を何度も触るのをやめて、

アプリが要求している画面の高さと、実際に表示できる高さ

を比較しました。

すると、アプリ側が実際より大きな表示領域を前提にしていることが分かりました。

高さの扱いを修正すると、最後までスクロールでき、末尾のボタンも操作できるようになりました。

再利用できるルール

今回の開発から、今後にも使えそうなルールを3つ残しました。

① テストが通っても、実機で最後まで操作する。

特にスクロール、キーボード、画面回転は、コードだけでは分かりにくい部分があります。

② 最初の修正で直らなければ、同じ場所を何度も直さない。

実際の端末の状態を測って、原因を切り分ける。

③ 中断した作業は、完成済みの部分からやり直さない。

チェックポイントを残して、未確認のところから再開する。

最近は、開発ログが単なる記録ではなく、

次の作業を効率よく再開するための仕組み

にもなってきました。

次にやること

今回の入力練習については、予定していた確認まで完了しました。

次は、この練習に音声再生を組み込む予定です。

一方で、画面読み上げや、さまざまな表示条件での確認などはまだ残っています。

全部できたとは言わず、

作る → テストする → 実機で触る → 違和感があれば測る。

この流れで、少しずつ完成度を上げていきます。

#AIプロジェクト日記 #Codex #AIエージェント #個人開発 #アプリ開発

関連する開発記録
今回と同じく、「今ある機能を作り直さず、別の使い方へ広げた」開発はこちらです。
→「ひとつの教材を、『使う場面』からも選べるようにした」