【アプリ設計】単なるTodoではなくチーム型タスク管理アプリとして考える

このページで学ぶこと

このページでは、今回作るアプリを「ただのTodoアプリ」ではなく、チーム型タスク管理アプリとして考える理由を整理します。

Todoアプリとは、やることをメモして完了チェックするアプリのことです。

チーム型タスク管理アプリとは、複数人でタスクを共有し、誰が担当するか、誰が編集できるか、誰が見るだけなのかまで管理するアプリのことです。

今回のアプリでは、ただ「タスクを追加する」だけでなく、

誰がログインしているのか
どのチームに参加しているのか
どのタスクを見られるのか
誰が編集できるのか
誰が削除できるのか

まで考えます。

ここが、実務アプリらしいポイントです。

---

この教材の進め方

この章では、次の流れで学習します。

完成コードを使う
↓
一部分だけ変更する
↓
保存する・実行する
↓
画面の変化を見る
↓
次のステップへ進む

今回のページでは、まだ深くコードは書きません。

その代わりに、「なぜこのような設計にするのか」を先に理解します。

設計とは、アプリを作る前に、画面・データ・機能の関係を整理することです。

設計が分かると、コードを見たときに迷いにくくなります。

---

単なるTodoアプリとは何か

まず、単なるTodoアプリを考えてみます。

Todoアプリでは、主に次のようなことをします。

タスクを追加する
タスクを一覧で見る
タスクを完了にする
タスクを削除する

たとえば、次のようなイメージです。

□ 買い物に行く
□ 宿題をする
□ メールを返信する

このようなアプリは、学習用としてはとても分かりやすいです。

ただし、実務アプリとして考えると、少し足りない部分があります。

---

Todoアプリだけでは足りない理由

実際の仕事や学校のグループ作業では、タスクは1人だけで管理するものではありません。

たとえば、学校イベントの準備を考えてみます。

会場を予約する人
ポスターを作る人
先生に確認する人
当日の進行表を作る人
SNSで告知する人

このように、複数人でタスクを分担します。

すると、次のような問題が出てきます。

困ること	例
誰のタスクか分からない	この作業は誰が担当？
勝手に削除されると困る	重要なタスクを誰かが消してしまう
見るだけの人も必要	先生や上司は確認だけしたい
チームごとに分けたい	開発チームと営業チームを分けたい
ログインが必要	誰が操作したのか分かるようにしたい

このような問題を解決するために、今回のアプリでは「チーム型」にします。

---

チーム型アプリとは何か

チーム型アプリとは、複数人が同じ場所に参加して、データを共有するアプリです。

今回でいう「チーム」とは、タスクを共有するグループのことです。

たとえば、次のようなチームを作れます。

開発チーム
営業チーム
学校イベント準備チーム
制作進行チーム

それぞれのチームには、メンバーがいます。

メンバーとは、そのチームに参加しているユーザーのことです。

開発チーム
├ 山田太郎
├ 佐藤花子
└ 鈴木一郎

そして、チームの中にタスクがあります。

タスクとは、やるべき作業のことです。

開発チーム
├ メンバー
│  ├ 山田太郎
│  ├ 佐藤花子
│  └ 鈴木一郎
└ タスク
   ├ ログイン画面を作る
   ├ Firestore接続を確認する
   └ メンバー追加画面を作る

このように、「ユーザー」「チーム」「メンバー」「タスク」を分けて考えるのが、今回のアプリ設計の基本です。

---

今回のアプリで登場する大事な単語

ここで、初めて出てくる単語を整理しておきます。

単語	一言説明
ユーザー	アプリを使う人
ログイン	自分が誰かをアプリに伝えること
チーム	タスクを共有するグループ
メンバー	チームに参加しているユーザー
タスク	やるべき作業
権限	その人が何をできるかのルール
owner	チームの所有者
admin	管理者
member	一般メンバー
viewer	見るだけの人
Firestore	Firebaseのデータベース
データベース	アプリの情報を保存する場所
コレクション	Firestoreでデータをまとめる箱
ドキュメント	Firestoreで1件分のデータを入れる箱

今はすべてを暗記しなくて大丈夫です。

このあと何度も出てくるので、少しずつ慣れていきます。

---

今回のアプリの全体設計

今回のアプリは、大きく分けると次の4つでできています。

ユーザー
チーム
メンバー
タスク

それぞれの役割は次の通りです。

要素	役割
ユーザー	アプリにログインする人
チーム	タスクを共有する場所
メンバー	チームに参加している人
タスク	チーム内で管理する作業

この4つを組み合わせることで、チーム型タスク管理アプリになります。

---

画面とデータの関係

アプリ設計では、画面だけでなく、データとの関係も考えます。

今回の画面とデータの関係は次のようになります。

画面	使うデータ
ログイン画面	Firebase Authentication
新規登録画面	Firebase Authentication、users
トーク一覧画面	teams
タスク一覧画面	teams、tasks、members
メンバー管理画面	members、users
タスク作成画面	tasks
メンバー追加画面	users、members

Firebase Authenticationとは、Firebaseのログイン機能のことです。

users、teams、members、tasks は、Firestoreに保存するデータのまとまりです。

このように、画面ごとに「どのデータを使うのか」を整理しておくと、コードが理解しやすくなります。

---

Firestoreの保存イメージ

Firestoreでは、データをコレクションとドキュメントで保存します。

コレクションとは、同じ種類のデータをまとめる場所です。

ドキュメントとは、1件分のデータです。

今回の保存構造は、次のようになります。

users
  └ uid

teams
  └ teamId
      ├ members
      │   └ uid
      └ tasks
          └ taskId

少し分解して考えます。

users/{uid}

これは、ユーザー1人分のプロフィールです。

teams/{teamId}

これは、チーム1つ分の情報です。

teams/{teamId}/members/{uid}

これは、あるチームに参加しているメンバー1人分の情報です。

teams/{teamId}/tasks/{taskId}

これは、あるチームの中にあるタスク1件分の情報です。

uid とは、Firebase Authenticationがユーザーごとに発行するIDです。

teamId とは、Firestoreがチームごとに作るIDです。

taskId とは、Firestoreがタスクごとに作るIDです。

IDとは、データを区別するための名前のようなものです。

---

なぜteamsの中にmembersとtasksを入れるのか

今回の設計では、members と tasks を teams の中に入れています。

teams/{teamId}/members/{uid}
teams/{teamId}/tasks/{taskId}

これは、チームごとにメンバーとタスクを分けたいからです。

たとえば、開発チームと営業チームがあったとします。

開発チーム
├ メンバー
└ タスク

営業チーム
├ メンバー
└ タスク

このように分けることで、開発チームのタスクと営業チームのタスクが混ざりません。

実務アプリでは、「どのデータが、どこに所属しているのか」をはっきりさせることが大切です。

---

権限を入れる理由

今回のアプリでは、メンバーごとに権限を持たせます。

権限とは、その人が何をできるかを決めるルールです。

たとえば、全員が自由に削除できると困ることがあります。

重要なタスクを間違えて削除する
他の人の作業内容を勝手に変更する
見るだけの人が編集してしまう

そこで、今回のアプリでは4つの権限を用意します。

権限	できること
owner	すべての操作ができる
admin	メンバー追加、タスク編集、タスク削除ができる
member	タスク作成、タスク編集ができる
viewer	見るだけ

ownerとは、チームを作った人や一番強い管理者のことです。

adminとは、チーム運営を手伝える管理者のことです。

memberとは、通常の作業メンバーのことです。

viewerとは、閲覧だけできる人のことです。

このように役割を分けると、実務アプリに近づきます。

---

画面上の制御とデータ側の制御

権限管理では、2つの考え方があります。

画面上でボタンを隠す
Firestore側で書き込みを禁止する

画面上でボタンを隠すとは、たとえばviewerには「タスク作成ボタン」を表示しないことです。

Firestore側で書き込みを禁止するとは、画面を無理やり操作されても、データベース側で保存を拒否することです。

データベースとは、Firestoreのようにデータを保存する場所のことです。

ここで大事なのは、ボタンを隠すだけでは完全ではないということです。

本当に守るには、Firestore Security Rulesも必要です。

Firestore Security Rulesとは、Firestoreのデータを誰が読めるか、誰が書けるかを決めるルールです。

この教材では、まずアプリ側で権限によってUIを変え、そのあとSecurity Rulesでも守る流れで進めます。

---

実務アプリで大事な3つの視点

今回のアプリでは、次の3つをセットで考えます。

画面
データ
権限

画面とは、ユーザーが見るUIのことです。

UIとは、ボタンや入力欄など、ユーザーが操作する見た目のことです。

データとは、Firestoreに保存する情報です。

権限とは、誰が何をできるかのルールです。

この3つをセットで考えると、アプリが一気に実務っぽくなります。

視点	考えること
画面	何を表示するか
データ	どこに保存するか
権限	誰が操作できるか

たとえば、タスク削除を考えると、次のようになります。

画面：削除ボタンを表示するか
データ：どのタスクを削除するか
権限：admin以上だけ削除できるようにする

このように考える癖をつけると、他のアプリにも応用できます。

---

今回のアプリを別ジャンルに応用するなら

このチーム型タスク管理アプリの考え方は、他のアプリにも応用できます。

応用先	置き換える考え方
学校イベント管理	チームをクラスや実行委員会にする
制作進行管理	タスクをデザイン・撮影・納品作業にする
営業管理	タスクを商談・見積・フォローにする
医療チーム管理	チームを部署、タスクを確認事項にする
店舗運営管理	チームを店舗、タスクを日次業務にする

つまり、この教材で学ぶのは「1つのサンプルアプリ」だけではありません。

ログイン、チーム、データ保存、権限という考え方は、いろいろな業務アプリの土台になります。

---

このページで意識してほしいこと

このページで大事なのは、コードを覚えることではありません。

次の考え方を持つことです。

単なるTodo
↓
自分だけのタスク管理

チーム型タスク管理
↓
複数人で使う実務アプリ

1人用アプリから、複数人で使うアプリになると、考えることが増えます。

誰が使うのか
どのチームに入っているのか
どのデータを見せるのか
どこまで操作させるのか

この考え方が、Flutter × Firebaseを学ぶ上でとても役立ちます。

---

ミニ確認問題

Q1. チーム型タスク管理アプリとは何ですか？

回答

複数人でタスクを共有し、メンバーごとに操作できる範囲を分けられるアプリです。

今回のアプリでは、チームごとにタスクを保存し、owner、admin、member、viewerの権限で操作を分けます。

---

Q2. メンバーとは何ですか？

回答

メンバーとは、チームに参加しているユーザーのことです。

同じユーザーでも、あるチームではadmin、別のチームではviewerのように、チームごとに権限を変えることもできます。

---

Q3. なぜ権限が必要ですか？

回答

全員が自由に編集や削除をできると、重要なデータが間違って変更されたり削除されたりする可能性があるからです。

権限を使うことで、見るだけの人、編集できる人、削除できる人を分けられます。

---

Q4. 画面・データ・権限をセットで考えるとはどういうことですか？

回答

たとえばタスク削除なら、削除ボタンを表示する画面、削除されるFirestoreのデータ、削除できる権限の3つを一緒に考えるということです。

実務アプリでは、この3つを分けずに考えることが大切です。

---

このページのまとめ

このページでは、今回のアプリを単なるTodoではなく、チーム型タスク管理アプリとして考える理由を学びました。

大切なポイントは次の通りです。

• Todoアプリは、基本的には1人でタスクを管理するアプリ。
• チーム型タスク管理アプリは、複数人でタスクを共有するアプリ。
• 実務では、誰が担当するか、誰が編集できるか、誰が削除できるかが重要になる。
• 今回のアプリでは、ユーザー、チーム、メンバー、タスクを分けて考える。
• Firestoreでは、users、teams、members、tasks を使ってデータを保存する。
• members と tasks を teams の中に入れることで、チームごとにデータを分けられる。
• 権限には、owner、admin、member、viewerを用意する。
• 権限管理では、画面上の制御とFirestore側の制御の両方を考える。
• 実務アプリでは、画面、データ、権限をセットで設計することが大切。

---

次のページでやること

次のページでは、Firebaseの準備について学びます。

Authentication、Firestore、Security Rulesがそれぞれ何を担当するのかを整理し、今回のアプリのどこで使われるのかを確認していきます。