Notionでタスクの一元管理をしてみた

この記事はレコチョク Advent Calendar 2025の20日目の記事となります。

はじめに

レコチョクでAndroidアプリ開発をしている瀬川です。
今年は業務でライブハウスに訪問させていただき、インディーズアーティストの方々のライブを観覧する機会がありました。
ライブハウスでのライブ観覧はあまり経験がなかったのですが、間近で見るインディーズアーティストの方々が放つ熱に刺激を貰い、自分のモチベーションアップに繋がる非常に良い経験ができました。

そんな近況の中、先日DroidKaigiに初参加してきました。
都合上1日しか参加できなかったですが、セッション・ミートアップ（開発者とランチを食べながら歓談）・企業ブースなど様々楽しませていただきました。
その中で特に印象に残ったものが、Flutterからネイティブへの挑戦と学び - 評価1.6から4.0への道のりになります。
1つのアプリが何をどう改善して、アプリ評価を向上させていったか具体エピソードも交えて非常に学びがあり、評価向上の裏にあったのは、技術力以上に チームビルディングの再構築が鍵だったという点に驚かされました。

• ドキュメントの一元管理（SSOT｜信頼できる唯一の情報源）
• タスクが人に閉じていた状況を解消し、こまめな情報共有を生む仕組みづくり
• オフィスアワーの実施
• 疑問や相談を気軽に投げられる Slack チャンネルの運用
• iOS / Android チームが一緒にレビューし、継続的なフィードバックループを作る

など、アプリ評価を上げるための解決策として実施したチームビルディングをいくつか紹介されていましたが、中でも【タスクの一元管理】と【タスクが人に閉じない環境】が大事だと感じました。

そこで今回は、【タスクの一元管理】と【タスクが人に閉じない環境】をNotion を使って再現してみましたので紹介します。

なぜNotionを選択したか

タスクを一元管理できるツールは様々ありますが、今回は【タスクの一元管理】や【タスクが人に閉じない環境】を考える中で、今回は「今だけでなく、今後どう活用できるか」という視点も含めてツールを選びました。
Notionを選んだ理由としては、日々業務で使用している管理ツールがNotionであることと、カスタマイズ性に優れていてユーザーのニーズに柔軟に対応できるという点からです。

「タスクの一元管理」ができる環境を構築

一元管理の軸となる概念は、Flutterからネイティブへの挑戦と学び - 評価1.6から4.0への道のりでも紹介されていたSSOT（信頼できる唯一の情報源）となります。
そのため参照するタスクは重複がないかつ、その中で必要な情報が含まれていることを意識しました。
ここでは一元管理かつ、見たい情報が表示されているような環境を構築するために、どのようにNotion のデータベース（DB） を活用をしたか紹介していきます。

タスクDB / リリースDB を作成する

今回はアプリ開発を想定しタスクをリリース(親)・タスク(子)に分け、下記項目が確認できるようDBを構築しました。

リリースDB

• 開発期間
• タスク(内訳)
• タスク数
• タスク工数
• 進捗率

タスクDB

• カテゴリー
• 担当者
• 工数（人日）
• リリース
• 優先度
• 救難信号
  • 後述で解説しますが、詰まっているタスクを可視化するためのチェックボックス項目となります
• ステータス

プロパティの活用

それぞれに必要な項目はNotionデータベースの機能であるプロパティを使用して設定しました。

使用したプロパティ例

選択

使用項目

• カテゴリー(タスクDB)
• 優先度(タスクDB)

ステータス

使用項目

• ステータス(タスクDB)

日付

使用項目

• 開発期間(リリースDB)

リレーションプロパティ

ここでは一元管理を構築する上で便利だったリレーションプロパティについて紹介していきます。
リレーションプロパティを活用することで、データベース同士をお互いに参照させ合うことができます。

設定方法

①プロパティで「リレーション」を選択

②リレーション対象を選択

③リレーションを追加

使用項目

今回は下記項目の作成に使用しました。

• リリースDB：タスク(内訳)

  • 目的：「そのリリースに含まれるタスク一覧」を表示する

• タスクDB：リリース

  • 目的：「どのリリースに紐づくタスクなのか」を表示する

使用イメージ

動画のようにリレーションを設定したことで、タスクDのリリース項目でリリースDBに設定しているデータを選択することができます。
そして【version 1.0.0】を選択すると、version 1.0.0のタスク（リレーションプロパティ）内に「タスクD」が紐づき表示されます。
これによりどのリリースにどんなタスクがあるのか一目で分かる状態を作ることができました。

ロールアッププロパティ

続いてリレーションに続き、一元管理を構築する上で重要だったロールアッププロパティについて紹介していきます。
ロールアップはリリースDBに紐づいているタスク工数の合計値を表示するなどの、別データベースのプロパティを参照＆計測できる機能となります。

設定方法

今回は該当リリースに紐づいているタスクの総工数を算出するよう設定します。

①プロパティで「ロールアップ」を選択

※DBの別項目でリレーションプロパティを設定している必要があります。

②対象のリレーションを選択

③参照したいプロパティを選択

④集計方法を選択

⑤総工数の算出

タスクA〜Dに設定されている工数の合計が表示

使用項目

今回はリリースDBの下記項目の作成に使用しました。

• タスク数
  • 目的：「そのリリースに含まれるタスク一覧」を表示する
• タスク工数
  • 目的：「そのリリースに含まれるタスクの総合計工数」を表示する
• 進捗率
  • 目的：「そのリリースに含まれるタスクの進捗率（完了ステータスのタスク数/全てのタスク数）」を表示する

使用イメージ：進捗率

設定内容

リリースDBの「version 1.0.0」では、紐づいているすべてのタスクのステータスから 進捗率を自動計算し進捗バーとして表示することができました。
これによりリリース毎の進捗率を Notion が自動でまとめてくれる運用も同ページで行うことができ、一元管理の環境を構築することができました。

補足

ステータスバーのデザインは【プロパティを編集】から指定することができます。

「タスクが人に閉じない」環境を構築する

一元管理の環境は構築できたので続いて、
タスクが特定の人に依存せず誰が見ても「誰が何を」やっているのか分かる環境 を作ることです。

この環境はチーム運営の属人化を防ぎ、急な休み・異動・欠員があっても業務が止まらないという大きなメリットがあります。

タスクが人に閉じない環境

【タスクが人に閉じない環境】とは以下のような状態と定義します。

• 担当者以外のメンバーもタスク状況を把握できる
• 「どのタスクが進んでいて・止まっているか」がすぐにわかる
• 疑問点/困り事がすぐに共有できる環境

ではNotion DBを用いた一元管理の環境をベースに、タスクが人に閉じない環境を再現したか紹介していきます。

「ボードビュー」でチームの状況を可視化する

Notionのボードビューを活用することで、さまざまな切り口で「誰が何をしているか」を可視化することができました。

設定方法

データベースとの紐付け

①「ボードビュー」を選択

②「既存のデータベースにリンク」で紐付けたいデータベースを選択

ボードで分けたいグループを設定

①「ビューを編集」の「グループ」を選択

②グループの編集

【グループ化】でベースとなるプロパティを選択することができる他、値毎にボードへの表示/非表示を設定することもできます。

ボードビューの活用例

担当者別ビュー

担当者ごとに割り振られているタスクを並べることで「誰がどのタスクを持っているか」が確認することができます。

このボードはタスクDBの【担当者】プロパティをグループに設定しています。
※フィルターで【完了】ステータスのものは非表示にしています

カテゴリー別ビュー

カテゴリー（例：UI / ロジック / バグ）で分けることで、プロジェクト全体でどのようなカテゴリーのタスクがあるか確認することができます。

このボードはタスクDBの【カテゴリー】プロパティをグループに設定しています。
※フィルターで【完了】ステータスのものは非表示にしています

リリース別ビュー

リリース単位でタスクをまとめて見ることができるため、「次のリリースまでにどんなタスクが残っているか」なども確認することができます。

このボードはタスクDBの【リリース】プロパティをグループに設定しています。
※ここでは該当リリースで含める内容を全て可視化できる環境がベストなためフィルターはかけていません。

救難信号ボード：トラブルを抱えているタスクの可視化

タスクが属人化する大きな要因のひとつが、進行が止まっているタスクが担当者の中だけで抱え込まれていることです。

そこで、問題が発生して進めないタスクだけを抽出した救難信号ボードを作成しました。
タスクDBに【救難信号】というチェックボックスのプロパティを用意し、下記動画のように実装に行き詰まっているタスクの【救難信号】をチェックすることで【救難信号ボード】に表示されます。

救難信号ボードがあることで、

• チーム全体が問題をすぐ共有できる
• 周囲がフォローに入りやすい
• 状況が見えるので属人化が防げる

という環境を構築することができました。

補足

誰のどのタスクで遅れているかを確認できる目的として救難信号ボードを作成しましたが、
救難信号プロパティにチェックをつけたら特定のSlackチャンネルに通知がいく仕組みも作成できたらより良い環境になると思います。（今回は割愛）

その他

スケジュールボード

リリースまでの開発スケジュールを確認するために、リリースDBの【開発期間】プロパティを参照した形の「スケジュールボード」 を作成しました。

その他にも【優先度別】など用意したプロパティ毎に〇〇別のボードビューを作成することができるため、ニーズに応じて様々な見せ方ができることがボードビューの強みだと思いました。

完成品

まとめ

Flutterからネイティブへの挑戦と学び - 評価1.6から4.0への道のりのセッションから得た学びをきっかけに、【タスクの一元管理】と【タスクが人に閉じない環境】 を Notion で再現してみました。
どちらも日々意識をしていなければ、タスクが重複していたり管理場所がバラついてしまっていたりと意外と起き得てしまうことかと思います。

今回はこのようにツールを活用し一元管理の環境を構築しましたが、さらにチームに合った運用ルールを設定することでツールを最大限に活かすチームを作ることができると思います。

チームビルディングで同じ課題を持っている方がいれば、是非今回の記事を参考にNotion機能を活用してみてください！

明日のレコチョク Advent Calendar 2025 は21日目「【AIブラウザ】DiaとCometを実際に使って比較してみた」です。お楽しみに！

この記事はレコチョクのエンジニアブログの記事を転載したものとなります。