CONTENT
ここから
Flutterで画面や機能を実装したら、そこで終わりではありません。
アプリは、作ったあとに必ず確認する必要があります。
画面は表示されるか。
ボタンは正しく動くか。
保存はできるか。
使う人にとってわかりやすいか。
そして何より、最初に考えた要件定義、基本設計、詳細設計の通りに作れているか。
ここを確認することが大切です。
GeminiやChatGPTなどのAIを使うと、コードを作るスピードは上がります。
しかし、AIが作ったコードが、必ず自分の設計通りになっているとは限りません。
画面は動いているように見えても、必要な機能が抜けていることがあります。
逆に、最初に作らないと決めた機能が勝手に追加されていることもあります。
だから、最後は自分で確認します。
アプリ開発では、作ることと同じくらい、確認することが大切です。
テストとは何か
テストとは、作ったアプリが正しく動くかを確認する作業です。
難しく考える必要はありません。
自分が作ったアプリを、実際に使う人の気持ちで操作してみます。
出席管理アプリなら、次のように確認します。
アプリを開く。
授業を選ぶ。
学生一覧を見る。
出席、遅刻、欠席を選ぶ。
保存する。
欠席者を確認する。
出席率を見る。
この流れの中で、思った通りに動くかを見ます。
もし、ボタンを押しても反応しない場合は、修正が必要です。
保存したはずの情報が消えてしまう場合も、修正が必要です。
画面がわかりにくくて、どこを押せばよいかわからない場合も、改善が必要です。
テストは、エラーを探すだけではありません。
使いやすさを確認する作業でもあります。
まず要件定義を満たしているか確認する
最初に確認するのは、要件定義です。
要件定義では、今回のアプリで作るものと作らないものを決めました。
その内容と、実際に作ったアプリを見比べます。
たとえば、要件定義で次のように決めていたとします。
学生一覧を表示する。
出席、欠席を選べるようにする。
選んだ出席状態を保存する。
欠席者を確認できるようにする。
この場合、実際のアプリで次のことを確認します。
学生一覧は表示されているか。
出席ボタンはあるか。
欠席ボタンはあるか。
ボタンを押すと状態が変わるか。
保存できるか。
欠席者を確認できるか。
ここで大切なのは、「なんとなく動いている」ではなく、「要件として決めたことができているか」を見ることです。
逆に、今回は作らないと決めた機能も確認します。
ログイン機能は作らない。
通知機能は作らない。
QRコード機能は作らない。
このように決めていたのに、AIが出したコードに複雑なログイン機能が入っている場合は、今回の目的から外れているかもしれません。
アプリは、機能が多ければ良いわけではありません。
要件定義で決めた範囲に合っていることが大切です。
基本設計を満たしているか確認する
次に、基本設計を確認します。
基本設計では、アプリ全体の形を決めました。
どんな画面が必要か。
画面同士はどのようにつながるか。
どんなデータを扱うか。
誰が使うアプリなのか。
これらと、実際に作ったアプリを見比べます。
たとえば、先生向けの出席管理アプリで、基本設計を次のように決めていたとします。
ホーム画面。
授業一覧画面。
学生一覧画面。
出席入力画面。
集計画面。
この場合、実際のアプリで次のことを確認します。
ホーム画面はあるか。
授業一覧画面はあるか。
授業を選ぶと学生一覧画面に進めるか。
学生一覧から出席入力ができるか。
保存後に集計画面で確認できるか。
画面の流れが自然か。
また、扱うデータも確認します。
学生名は表示されているか。
授業名は表示されているか。
日付は必要に応じて表示されているか。
出席状態は正しく扱えているか。
欠席理由を扱う設計なら、入力や表示ができているか。
基本設計は、アプリ全体の地図です。
地図と違う道に進んでいないかを確認することが、テストでは重要です。
詳細設計を満たしているか確認する
次に、詳細設計を確認します。
詳細設計では、画面ごとの細かい動きを決めました。
ボタンを押したら何が起きるか。
入力欄には何を入れるか。
空欄のときはどうするか。
保存したら何を表示するか。
エラーが起きたらどう知らせるか。
これらを、実際に操作しながら確認します。
たとえば、出席入力画面で次のように設計していたとします。
出席ボタンを押したら、状態が「出席」に変わる。
欠席ボタンを押したら、状態が「欠席」に変わる。
保存ボタンを押したら、入力内容を保存する。
保存できたら「保存しました」と表示する。
保存できなかったら「保存できませんでした」と表示する。
この場合、実際にボタンを押して確認します。
出席ボタンを押す。
表示が出席に変わるか見る。
欠席ボタンを押す。
表示が欠席に変わるか見る。
保存ボタンを押す。
保存完了の表示が出るか見る。
入力が足りない状態で保存する。
注意が表示されるか見る。
詳細設計の確認では、1つ1つの操作を丁寧に見ます。
画面が表示されているだけでは不十分です。
使う人の操作に対して、アプリが正しく反応しているかを確認します。
AIで作ったコードは必ず自分で確認する
GeminiやChatGPTを使って実装した場合でも、最後の確認は自分で行います。
AIは、コードを作る手助けをしてくれます。
エラーの原因を説明してくれることもあります。
修正案を出してくれることもあります。
しかし、AIは自分の授業の目的や、自分が書いたメモの意図を完全に理解しているわけではありません。
そのため、次のようなことが起きる場合があります。
必要な機能が抜けている。
画面の名前が変わっている。
最初に決めた画面の流れと違う。
使っていない機能が追加されている。
コードは動くが、自分の目的とは違う。
見た目は良いが、操作しにくい。
このような状態を防ぐために、設計メモとアプリを見比べます。
AIで作ったから完成、ではありません。
AIで作ったあとに、自分で確認して、必要なら直す。
ここまでが実装です。
テストするときの確認項目
出席管理アプリをテストするときは、次のような項目を確認します。
画面の確認
必要な画面が表示されるか。
画面の名前や内容がわかりやすいか。
文字が小さすぎないか。
ボタンが押しやすいか。
スマートフォンで見ても崩れていないか。
操作の確認
ボタンを押したら反応するか。
画面移動が正しくできるか。
戻る操作ができるか。
入力した内容が画面に反映されるか。
間違った操作をしてもアプリが止まらないか。
データの確認
学生名が正しく表示されるか。
出席状態が正しく変わるか。
保存した内容が残るか。
集計結果が正しいか。
欠席者だけを表示する場合、正しく絞り込めているか。
エラー表示の確認
入力が足りないときに注意が出るか。
保存に失敗したときにメッセージが出るか。
データが空のときに、わかりやすい表示が出るか。
設計との確認
要件定義で決めた機能が入っているか。
基本設計で決めた画面があるか。
詳細設計で決めた動きになっているか。
今回は作らないと決めた機能が混ざっていないか。
このように、テストでは「動くか」だけでなく、「設計通りか」も確認します。
使いやすさを確認する
アプリは、正しく動くだけでは十分ではありません。
使いやすいことも大切です。
たとえば、出席管理アプリが正しく動いていても、次のような状態だと使いにくくなります。
ボタンが小さくて押しにくい。
学生名が見つけにくい。
出席と欠席の違いがわかりにくい。
保存できたかどうかわからない。
画面移動が多すぎる。
必要な情報が下の方に隠れている。
先生が授業中に使うアプリであれば、短時間で操作できることが大切です。
イベント受付で使うアプリであれば、迷わず処理できることが大切です。
学生が使うアプリであれば、自分の情報がわかりやすく表示されることが大切です。
使いやすさは、利用者によって変わります。
だから、最初に決めた「誰のためのアプリか」を思い出しながら確認します。
他の人に使ってもらう
できれば、自分以外の人にもアプリを触ってもらいます。
作った本人は、どこを押せばよいか知っています。
だから、自分では使いやすいと思ってしまうことがあります。
しかし、初めて使う人は迷うかもしれません。
たとえば、友達に次のようにお願いします。
このアプリで出席を入力してみてください。
欠席者を確認してみてください。
授業を選んでみてください。
保存してみてください。
その様子を見ながら、どこで迷っているかを確認します。
説明しないと使えない部分があれば、画面を改善する必要があります。
良いアプリは、説明が少なくても使い方が伝わります。
改善する
テストをすると、直したいところが見つかります。
それを改善します。
改善とは、アプリを少しずつ使いやすくすることです。
たとえば、次のような改善があります。
ボタンを大きくする。
表示する文字をわかりやすくする。
出席、欠席、遅刻の状態を見分けやすくする。
保存後にメッセージを出す。
欠席者だけを見られるようにする。
画面の順番を整理する。
入力項目を減らす。
エラー表示をわかりやすくする。
改善するときも、何でも追加すればよいわけではありません。
要件定義、基本設計、詳細設計に戻って考えます。
この改善は、最初の目的に合っているか。
この機能は、本当に必要か。
使う人の困りごとを減らせるか。
作らないと決めた範囲を超えていないか。
このように確認しながら改善します。
AIに改善を相談する方法
改善するときも、GeminiやChatGPTを活用できます。
ただし、ただ「もっと良くして」と聞くと、必要以上に大きく変わってしまうことがあります。
AIに改善を相談するときは、目的をはっきり伝えます。
たとえば、次のように聞きます。
Flutterで出席管理アプリを作っています。
現在、学生一覧画面に出席ボタンと欠席ボタンがあります。
困っていること：
ボタンが小さく、スマートフォンで押しにくいです。
守ってほしいこと：
画面構成は大きく変えないでください。
今ある機能は消さないでください。
初心者にもわかるように、最小限の修正にしてください。
改善案と修正コードを提案してください。
別の例です。
Flutterで出席管理アプリを作っています。
現在、保存ボタンを押しても、保存できたかどうかがわかりません。
やりたいこと：
保存できたら「保存しました」と表示したいです。
保存に失敗したら「保存できませんでした」と表示したいです。
現在のコード：
【ここにコードを貼る】
既存の画面デザインを大きく変えずに、必要な部分だけ修正してください。
AIに改善を相談するときは、次の情報を入れるとよいです。
今できていること。
困っていること。
どう改善したいか。
変えてほしくないこと。
現在のコード。
このように伝えると、自分の設計から外れにくくなります。
修正したらもう一度テストする
改善したら、もう一度テストします。
修正すると、別の場所が壊れることがあります。
たとえば、ボタンの見た目を変えたら、押したときの動きが変わってしまうかもしれません。
保存処理を直したら、集計表示が変わってしまうかもしれません。
そのため、修正したあとには必ず確認します。
修正した部分は正しく動くか。
前に動いていた部分は壊れていないか。
設計通りの動きになっているか。
使いやすくなっているか。
改善は、直して終わりではありません。
直したあとに、確認するところまでが改善です。
提出前に確認すること
提出前には、次の内容を確認します。
要件定義の確認
必ず作る機能は入っているか。
できれば作りたい機能を無理に入れすぎていないか。
今回は作らない機能が混ざっていないか。
最初の小さな完成形は達成できているか。
基本設計の確認
必要な画面はあるか。
画面の流れは自然か。
扱うデータは合っているか。
利用者に合った画面になっているか。
詳細設計の確認
ボタンを押したときの動きは合っているか。
入力ルールは守られているか。
保存後の表示はあるか。
エラー時の表示はあるか。
実装の確認
アプリは起動するか。
画面は崩れていないか。
エラーは出ていないか。
スマートフォンで操作できるか。
メモの確認
どんな困りごとを解決しようとしたか書いてあるか。
どんな要件にしたか書いてあるか。
どんな設計にしたか書いてあるか。
どこまで実装できたか書いてあるか。
どんなバグが出たか書いてあるか。
どう改善したか書いてあるか。
まだできていない部分が書いてあるか。
完成していない部分があっても問題ありません。
大切なのは、どこまで考えて、どこまで作り、何を確認したのかがわかることです。
テスト結果をメモに残す
テストした内容は、メモに残します。
たとえば、次のように書きます。
テストしたこと：
学生一覧画面で、出席ボタンと欠席ボタンを押して確認した。
結果：
出席ボタンを押すと、状態が「出席」に変わった。
欠席ボタンを押すと、状態が「欠席」に変わった。
問題：
保存ボタンを押しても、保存できたかどうかがわかりにくかった。
改善：
保存後に「保存しました」と表示するようにした。
次に直したいこと：
欠席者だけを表示できるようにしたい。
このように書いておくと、アプリを作る流れがわかりやすくなります。
提出物としても、考えた過程が伝わります。
この節のまとめ
アプリは、作っただけでは完成ではありません。
テストと改善を通して、使いやすいアプリに近づけていきます。
テストでは、ただ動くかどうかを見るだけではありません。
要件定義で決めた機能を満たしているか。
基本設計で決めた画面や流れになっているか。
詳細設計で決めた動きになっているか。
これらを、自分で確認する必要があります。
GeminiやChatGPTを使って作った場合でも、最後に確認するのは自分です。
AIで作りっぱなしにしない。
設計と見比べる。
実際に操作する。
使いにくいところを見つける。
必要な部分を改善する。
この流れを行うことで、アプリは少しずつ良くなります。
今回の出席管理アプリも、完成度だけでなく、考えた流れ、確認した内容、改善した内容が大切です。
作る。
試す。
直す。
もう一度確認する。
この繰り返しが、アプリ開発の大切な流れです。