CONTENT
ここから
要件定義で「作るもの」と「作らないもの」を決めたら、次は基本設計に進みます。
基本設計とは、アプリ全体の形を決める作業です。
少し難しく聞こえるかもしれませんが、やることはとてもシンプルです。
どんな画面が必要か。
画面同士はどのようにつながるか。
どんなデータを扱うか。
使う人は、どの順番で操作するか。
これらを整理する作業です。
要件定義が「何を作るか」を決める作業だとしたら、基本設計は「どんな形で作るか」を決める作業です。
たとえば、出席管理アプリを作るとします。
要件定義では、次のようなことを決めました。
学生一覧を表示する。
出席、遅刻、欠席を選べるようにする。
出席データを保存する。
欠席者を確認できるようにする。
基本設計では、これらを実現するために、どんな画面が必要なのかを考えます。
学生一覧は、どの画面に表示するのか。
出席状態は、どの画面で変更するのか。
保存ボタンは、どこに置くのか。
欠席者は、一覧の中で確認するのか、別の画面で確認するのか。
このように、機能を画面や流れに落とし込んでいきます。
基本設計はアプリの地図を作る作業
基本設計は、アプリの地図を作るような作業です。
旅行に行くとき、目的地だけ決まっていても、道順がわからなければ迷ってしまいます。
アプリ開発も同じです。
作る機能が決まっていても、どの画面に何を置くのか、どの順番で使うのかが決まっていないと、作っている途中で迷いやすくなります。
たとえば、出席管理アプリで次のような機能を作るとします。
授業を選ぶ。
学生一覧を見る。
出席を記録する。
保存する。
この場合、画面の流れは次のように考えられます。
ホーム画面を開く。
授業一覧画面で授業を選ぶ。
学生一覧画面で学生を見る。
出席入力画面で出席状態を変更する。
保存して、授業一覧または集計画面に戻る。
この流れが見えていると、どの画面から作ればよいのかがわかりやすくなります。
基本設計は、実装に入る前にアプリの全体像を確認するための大事な準備です。
まず必要な画面を考える
基本設計で最初に行うことは、必要な画面を考えることです。
出席管理アプリでは、次のような画面が考えられます。
ホーム画面。
授業一覧画面。
学生一覧画面。
出席入力画面。
出席履歴画面。
集計画面。
設定画面。
ただし、最初からすべての画面を作る必要はありません。
要件定義で決めた「最初の小さな完成形」に合わせて、必要な画面を選びます。
たとえば、最初の小さな完成形が「学生一覧を表示して、出席・欠席を選べるところまで」なら、必要な画面は少なくて済みます。
ホーム画面。
学生一覧画面。
この2つだけでも始められます。
もう少し進めるなら、次の画面を追加します。
授業一覧画面。
出席入力画面。
集計画面。
大切なのは、必要な画面を全部並べることではありません。
今回のアプリに必要な画面を選ぶことです。
画面ごとの役割を決める
画面を決めたら、それぞれの役割を考えます。
1つの画面に、たくさんの機能を詰め込みすぎると、使いにくくなります。
反対に、画面を分けすぎると、操作が面倒になります。
そこで、画面ごとに「この画面では何をするのか」を決めます。
たとえば、先生向けの出席管理アプリなら、次のように整理できます。
ホーム画面
アプリを開いたときに最初に表示される画面です。
今日の授業や、出席入力への入口を表示します。
授業一覧画面
どの授業の出席を取るのかを選ぶ画面です。
授業名、日付、時間などを表示します。
学生一覧画面
選んだ授業に参加する学生を一覧で見る画面です。
学生名や学籍番号を表示します。
出席入力画面
学生ごとに出席、遅刻、欠席を選ぶ画面です。
必要であれば、欠席理由やメモを入力できるようにします。
集計画面
出席人数、欠席人数、出席率などを確認する画面です。
先生や管理者が状況を把握しやすくするために使います。
このように役割を分けると、画面設計がしやすくなります。
画面の流れを考える
次に、画面の流れを考えます。
画面の流れとは、使う人がどの順番でアプリを操作するかということです。
出席管理アプリなら、たとえば次のような流れになります。
アプリを開く。
授業を選ぶ。
学生一覧を見る。
出席状態を入力する。
保存する。
欠席者や出席率を確認する。
この流れを考えることで、どの画面からどの画面へ移動すればよいのかがわかります。
たとえば、次のように整理できます。
ホーム画面 → 授業一覧画面。
授業一覧画面 → 学生一覧画面。
学生一覧画面 → 出席入力画面。
出席入力画面 → 集計画面。
集計画面 → ホーム画面。
このように、画面同士のつながりを考えることが基本設計では重要です。
画面の流れが決まっていると、Flutterで実装するときにも、画面遷移を考えやすくなります。
扱うデータを考える
基本設計では、画面だけでなく、アプリで扱うデータも考えます。
出席管理アプリでは、次のようなデータが必要になります。
学生データ。
授業データ。
出席データ。
日付。
出席状態。
欠席理由。
メモ。
たとえば、学生データには次のような情報が入ります。
学生ID。
学生名。
学籍番号。
クラス名。
授業データには、次のような情報が入ります。
授業ID。
授業名。
担当者。
日付。
開始時間。
出席データには、次のような情報が入ります。
出席ID。
学生ID。
授業ID。
出席状態。
記録日時。
欠席理由。
このように、画面に表示する情報の裏側には、必ずデータがあります。
基本設計では、細かいデータベース設計まで完璧に作る必要はありません。
ただし、どんな情報を扱うのかは考えておく必要があります。
利用者ごとに見える画面を考える
出席管理アプリでは、誰が使うかによって、見える画面が変わることがあります。
先生が使う場合。
学生が使う場合。
管理者が使う場合。
イベント受付担当者が使う場合。
それぞれ必要な情報が違います。
たとえば、先生は授業ごとの出席状況を見たいかもしれません。
学生は自分の出席履歴だけを見たいかもしれません。
管理者はクラス全体の出席率を見たいかもしれません。
受付担当者は、来場済みと未受付の人を確認したいかもしれません。
このように、利用者によって画面の内容を変える必要があります。
ただし、最初のアプリでは、すべての利用者に対応しなくても構いません。
まずは、1人の利用者に絞ります。
たとえば、先生向けの出席管理アプリにする。
学生向けの出席確認アプリにする。
イベント受付担当者向けの受付アプリにする。
利用者を絞ることで、基本設計がわかりやすくなります。
出席管理アプリの基本設計例
ここでは、先生向けの出席管理アプリを例にして、基本設計を整理します。
アプリの目的
先生が授業中に、学生の出席状況をすばやく記録できるようにする。
利用者
先生。
必要な画面
ホーム画面。
授業一覧画面。
学生一覧画面。
出席入力画面。
集計画面。
画面の流れ
ホーム画面を開く。
授業一覧画面で授業を選ぶ。
学生一覧画面で学生を確認する。
出席入力画面で出席、遅刻、欠席を選ぶ。
保存する。
集計画面で出席人数や欠席人数を確認する。
扱うデータ
学生名。
学籍番号。
授業名。
授業日。
出席状態。
欠席理由。
記録日時。
最初の小さな完成形
授業一覧から授業を選ぶ。
学生一覧を表示する。
学生ごとに出席、欠席を選べる。
画面上で出席状態が変わる。
このように整理すると、アプリの全体像が見えてきます。
まだコードは書いていません。
しかし、どの画面が必要で、どんな情報を扱い、どの順番で操作するのかがわかるようになります。
これが基本設計です。
Flutterで実装するときにつながること
基本設計で決めた内容は、Flutterで実装するときにそのまま役立ちます。
たとえば、画面一覧を決めておくと、Flutterでどの画面ファイルを作るか考えやすくなります。
ホーム画面。
授業一覧画面。
学生一覧画面。
出席入力画面。
集計画面。
それぞれを別の画面として作れば、整理しやすくなります。
また、画面の流れを決めておくと、画面遷移を作りやすくなります。
授業一覧から学生一覧へ移動する。
学生一覧から出席入力へ移動する。
保存後に集計画面へ移動する。
このような流れが決まっていると、実装するときに迷いません。
さらに、扱うデータを考えておくと、データの型を作りやすくなります。
学生データ
授業データ
出席データ
これらをどのように持つかを考えることで、アプリの中の情報整理がしやすくなります。
Flutterの実装は、基本設計で決めた内容を画面や処理として形にする作業です。
今日のメモに書くこと
自分のメモ帳に、次の内容を書いてください。
1. アプリの目的
このアプリは、何を解決するためのものですか。
例えば
先生が出席確認を短時間でできるようにする。
学生が自分の出席状況を確認できるようにする。
イベント受付で来場者をすばやく確認できるようにする。
2. 利用者
誰が使うアプリですか。
例えば
先生
学生
管理者
イベント受付担当者
3. 必要な画面
どんな画面が必要ですか。
例えば
ホーム画面
授業一覧画面
学生一覧画面
出席入力画面
集計画面
4. 画面の流れ
使う人は、どの順番で画面を操作しますか。
例えば
ホーム画面 → 授業一覧画面 → 学生一覧画面 → 出席入力画面
5. 扱うデータ
どんな情報を扱いますか。
例えば
学生名
授業名
日付
出席状態
欠席理由
6. 最初に作る画面
まず、どの画面から作りますか。
例えば
学生一覧画面
授業一覧画面
出席入力画面
この節のまとめ
基本設計は、アプリ全体の形を決める作業です。
要件定義で決めた機能を、画面や流れに整理していきます。
どんな画面が必要か。
画面同士はどのようにつながるか。
どんなデータを扱うか。
誰がどの画面を見るのか。
このようなことを決めることで、アプリの地図ができます。
基本設計ができると、Flutterで実装するときに迷いにくくなります。
いきなりコードを書くのではなく、まずアプリ全体の形を考える。
これが、使いやすいアプリを作るための大切な準備です。