CONTENT
ここから
基本設計でアプリ全体の形を決めたら、次は詳細設計に進みます。
詳細設計とは、画面ごとの細かい動きを決める作業です。
基本設計では、どんな画面が必要かを考えました。
ホーム画面。
授業一覧画面。
学生一覧画面。
出席入力画面。
集計画面。
このように、アプリ全体の地図を作りました。
詳細設計では、その1つ1つの画面について、さらに具体的に考えます。
ボタンを押したら何が起きるのか。
入力欄には何を入れるのか。
何も入力されていないときはどうするのか。
保存に成功したら、どんな表示を出すのか。
保存に失敗したら、どんなメッセージを出すのか。
画面を開いたとき、最初に何を表示するのか。
このような細かい動きを決めていきます。
詳細設計は、実装に入る前の「動きの確認」です。
ここを丁寧に考えておくと、Flutterで作るときに迷いにくくなります。
詳細設計は「この画面で何が起きるか」を決める作業
アプリの画面は、ただ表示されているだけではありません。
使う人がボタンを押したり、文字を入力したり、画面を移動したりします。
その操作に対して、アプリは反応します。
たとえば、出席管理アプリで「出席」ボタンを押したとします。
そのとき、アプリは何をすればよいでしょうか。
出席状態を「出席」に変える。
ボタンの見た目を変える。
学生の記録を更新する。
保存ボタンを押せるようにする。
必要であれば、出席人数を更新する。
このように、1つのボタンを押すだけでも、アプリの中ではいくつかの動きが発生します。
詳細設計では、この動きを先に考えておきます。
「なんとなく作る」のではなく、「こう操作したら、こう動く」と決めてから実装します。
画面ごとに役割を確認する
詳細設計を始める前に、まず画面ごとの役割を確認します。
出席管理アプリであれば、次のように整理できます。
ホーム画面
アプリを開いたときに最初に表示される画面です。
授業一覧へ進む入口や、今日の出席状況を表示します。
授業一覧画面
どの授業の出席を管理するのかを選ぶ画面です。
授業名、日付、時間などを表示します。
学生一覧画面
選んだ授業に参加する学生を一覧で見る画面です。
学生名、学籍番号、現在の出席状態などを表示します。
出席入力画面
学生ごとに出席、遅刻、欠席を選ぶ画面です。
必要に応じて、欠席理由やメモを入力します。
集計画面
出席人数、欠席人数、遅刻人数、出席率などを確認する画面です。
ここで大切なのは、1つの画面に役割を詰め込みすぎないことです。
画面の役割が曖昧になると、動きも曖昧になります。
まずは、「この画面では何をするのか」をはっきりさせます。
ボタンを押したときの動きを決める
詳細設計で特に大切なのが、ボタンを押したときの動きです。
アプリでは、多くの操作がボタンから始まります。
出席管理アプリなら、次のようなボタンが考えられます。
出席ボタン。
遅刻ボタン。
欠席ボタン。
保存ボタン。
戻るボタン。
授業を選ぶボタン。
集計を見るボタン。
それぞれのボタンについて、押したら何が起きるのかを決めます。
たとえば、出席入力画面では次のように整理できます。
出席ボタンを押したとき
選んだ学生の状態を「出席」に変更する。
画面上の表示を「出席」に変える。
出席ボタンを選択中の見た目にする。
遅刻ボタンを押したとき
選んだ学生の状態を「遅刻」に変更する。
必要であれば、遅刻時間を入力できるようにする。
画面上の表示を「遅刻」に変える。
欠席ボタンを押したとき
選んだ学生の状態を「欠席」に変更する。
必要であれば、欠席理由を入力できるようにする。
画面上の表示を「欠席」に変える。
保存ボタンを押したとき
入力された出席状態を保存する。
保存できたら「保存しました」と表示する。
保存できなかったら「保存できませんでした」と表示する。
このように、ボタンごとの動きを先に決めておくと、実装するときに考えることが整理されます。
入力するときのルールを決める
アプリには、文字や情報を入力する場面があります。
出席管理アプリなら、次のような入力が考えられます。
欠席理由。
遅刻理由。
メモ。
授業名。
学生名。
日付。
入力欄を作るときは、ただ入力できるようにするだけでは足りません。
どんな入力なら受け付けるのか。
空欄でもよいのか。
文字数の制限はあるのか。
間違った入力をしたときに、どう知らせるのか。
このようなルールを考える必要があります。
たとえば、欠席理由の入力では、次のように決められます。
欠席を選んだ場合だけ、欠席理由を入力できる。
欠席理由は空欄でも保存できる。
ただし、長すぎる文章は入力できないようにする。
入力されていない場合は「理由なし」として扱う。
別の例として、授業名を入力する画面なら、次のように決められます。
授業名は必ず入力する。
空欄のまま保存しようとしたら、注意を表示する。
同じ名前の授業がある場合は、日付や時間で区別する。
このように、入力のルールを決めておくと、使う人が迷いにくくなります。
エラーが起きたときの表示を決める
アプリでは、うまくいかない場面もあります。
保存に失敗する。
必要な入力が足りない。
データが読み込めない。
学生一覧が空になっている。
ネットワークにつながらない。
このようなときに、何も表示されないと、使う人は困ってしまいます。
そのため、詳細設計ではエラー表示も考えます。
たとえば、保存に失敗した場合は、次のように表示できます。
「保存できませんでした。もう一度お試しください。」
出席状態が選ばれていない場合は、次のように表示できます。
「出席状態を選択してください。」
学生一覧が空の場合は、次のように表示できます。
「学生が登録されていません。」
エラー表示で大切なのは、使う人が次に何をすればよいかわかることです。
「エラーです」だけでは不十分です。
何が起きたのか。
次にどうすればよいのか。
この2つが伝わるようにします。
保存するときの流れを決める
出席管理アプリでは、保存の流れも重要です。
出席状態を選んでも、保存されていなければ記録として残りません。
そのため、保存ボタンを押したときに何が起きるのかを決めておきます。
たとえば、次のような流れです。
出席状態を選ぶ。
保存ボタンを押す。
入力内容を確認する。
問題がなければ保存する。
保存できたら完了メッセージを表示する。
必要であれば、集計画面を更新する。
保存に失敗したら、エラーメッセージを表示する。
このように、保存の流れを整理しておくと、実装しやすくなります。
また、保存したあとにどの画面へ移動するかも考えます。
そのまま出席入力画面に残るのか。
学生一覧画面に戻るのか。
集計画面へ移動するのか。
使う人にとって自然な流れを考えることが大切です。
画面を開いたときの最初の状態を決める
詳細設計では、画面を開いた瞬間の状態も考えます。
たとえば、学生一覧画面を開いたとき、何が表示されているべきでしょうか。
学生全員が一覧で表示される。
まだ出席状態が選ばれていない学生は「未入力」と表示される。
すでに保存済みの学生は、前回の出席状態が表示される。
読み込み中なら「読み込み中」と表示される。
学生がいなければ「学生が登録されていません」と表示される。
このように、画面を開いたときの状態を決めておくと、作るべき表示が明確になります。
アプリは、操作したあとの動きだけでなく、最初に見える状態も大切です。
最初の画面がわかりにくいと、使う人は何をすればよいのか迷ってしまいます。
出席管理アプリの詳細設計例
ここでは、先生向けの出席入力画面を例にして、詳細設計を整理します。
画面名
出席入力画面。
画面の目的
先生が学生ごとに出席状態を記録できるようにする。
画面に表示するもの
授業名。
日付。
学生一覧。
学生名。
学籍番号。
出席ボタン。
遅刻ボタン。
欠席ボタン。
保存ボタン。
現在の出席状態。
画面を開いたときの状態
選んだ授業の学生一覧を表示する。
出席状態が未入力の学生は「未入力」と表示する。
すでに記録がある場合は、保存済みの状態を表示する。
出席ボタンを押したとき
対象の学生の出席状態を「出席」に変更する。
表示を「出席」に変える。
遅刻ボタンを押したとき
対象の学生の出席状態を「遅刻」に変更する。
必要であれば、遅刻メモを入力できるようにする。
欠席ボタンを押したとき
対象の学生の出席状態を「欠席」に変更する。
必要であれば、欠席理由を入力できるようにする。
保存ボタンを押したとき
入力された出席状態を保存する。
保存できた場合は「保存しました」と表示する。
保存できなかった場合は「保存できませんでした」と表示する。
エラー時の表示
出席状態が1つも選ばれていない場合は、「出席状態を選択してください」と表示する。
学生一覧が空の場合は、「学生が登録されていません」と表示する。
保存に失敗した場合は、「保存できませんでした。もう一度お試しください」と表示する。
このように整理すると、出席入力画面で何を作ればよいのかがはっきりします。
Flutterで実装するときにつながること
詳細設計で決めた内容は、Flutterで実装するときにそのまま役立ちます。
たとえば、画面に表示するものを決めておくと、どんなWidgetが必要か見えてきます。
学生名を表示する。
出席ボタンを置く。
欠席理由の入力欄を作る。
保存ボタンを置く。
エラーメッセージを表示する。
これらは、FlutterではWidgetとして作っていきます。
また、ボタンを押したときの動きを決めておくと、処理を書きやすくなります。
出席ボタンを押したら、状態を出席に変える。
欠席ボタンを押したら、欠席理由の入力欄を表示する。
保存ボタンを押したら、データを保存する。
このように、詳細設計はコードを書く前の準備になります。
設計があると、実装中に「次に何を作るのか」がわかりやすくなります。
今日のメモに書くこと
自分のメモ帳に、次の内容を書いてください。
1. 詳細設計する画面
まず、どの画面の動きを考えるか決めます。
例。
出席入力画面。
学生一覧画面。
授業一覧画面。
イベント受付画面。
2. その画面の目的
その画面では、何をできるようにしますか。
例。
先生が学生ごとに出席状態を記録できるようにする。
受付担当者が参加者を受付済みに変更できるようにする。
3. 画面に表示するもの
その画面には何を表示しますか。
例。
学生名。
学籍番号。
出席ボタン。
欠席ボタン。
保存ボタン。
現在の出席状態。
4. ボタンを押したときの動き
それぞれのボタンを押したら、何が起きますか。
例。
出席ボタンを押したら、状態が出席に変わる。
保存ボタンを押したら、入力内容を保存する。
戻るボタンを押したら、前の画面に戻る。
5. 入力のルール
入力欄がある場合、どんなルールにしますか。
例。
授業名は空欄にできない。
欠席理由は空欄でもよい。
メモは短く入力する。
6. エラー時の表示
うまくいかなかったとき、どんな表示を出しますか。
例。
保存できませんでした。
出席状態を選択してください。
学生が登録されていません。
7. 保存後の動き
保存したあと、画面はどうなりますか。
例。
そのまま画面に残る。
学生一覧に戻る。
集計画面へ移動する。
この節のまとめ
詳細設計は、画面ごとの細かい動きを決める作業です。
基本設計でアプリ全体の形を決めたあと、詳細設計では1つ1つの画面について具体的に考えます。
画面を開いたときに何を表示するのか。
ボタンを押したら何が起きるのか。
入力欄には何を入れるのか。
保存したらどうなるのか。
エラーが起きたら何を表示するのか。
これらを先に決めておくと、Flutterで実装するときに迷いにくくなります。
アプリは、ただ画面を並べるだけでは完成しません。
使う人の操作に対して、わかりやすく反応する必要があります。
詳細設計は、その反応を決めるための大切な準備です。
ここまで考えられると、いよいよFlutterで画面や機能を作る準備が整ってきます。