はじめに：なぜ「1画面」にこだわるのか
こんにちは、TransMedia Tech Labに所属しているB1の秋山知輝です。
開発プロジェクトやデータ分析コンペ（Kaggleなど）、大学の課題……。複数のプロジェクトを抱えていると、こんな状況に陥りがちではありませんか？
- スケジュールはGoogleカレンダー、タスクはToDoアプリ、資料はローカルフォルダ……とツールを行き来するコストが高い。
- 「あのコンペの提出ファイル、最新版はどこだっけ？」と探す時間が発生する。
- 全体像が見えず、目の前のタスクに追われて納期直前に焦る。
これらを解決するために、Notionのデータベース機能を活用し、「Task（やるべきこと）」→「Schedule（日程）「Document（資産）」の3つを1ページで完結させるダッシュボードを構築しました。
今回は、実際に私が運用している画面をベースに、データベース設計の意図と構築のポイントを詳しく解説します。
全体構成：情報の重要性で階層を分ける
作成したダッシュボードは、情報の重要性に合わせて上から順に3つのセクションで構成しています。
-
上段：Schedule（長期視点）
- プロジェクトのマイルストーンやコンペ期間など、数日〜数ヶ月スパンの予定。
-
中段：Task（短期視点・フロー情報）
- 今日〜今週やるべき具体的な作業。完了したら消し込む（アーカイブする）もの。
-
下段：Document（ストック情報）
- 分析結果、仕様書、提出ファイルなど、後から参照し続ける資産。
この「上から下へ視線を動かせば、プロジェクトの全てが把握できる」レイアウトが重要です。
詳細解説 1. Schedule：タイムラインで期間を可視化する
ビューの選択：タイムラインビュー
多くの人はカレンダービューを使いがちですが、プロジェクト管理には 「タイムラインビュー」 を強く推奨します。
- 理由: カレンダーでは「点（その日）」しか見えませんが、タイムラインなら「線（期間）」が見えます。「コンペ終了まであとどのくらい余裕があるか」「期間が重複しているプロジェクトはどれか」が直感的に把握できるからです。
運用のコツ
- 期間の設定: プロパティには「Date（日付）」を使用し、開始日と終了日を含めます。
- 依存関係の意識: 大きなマイルストーン（例：中間提出、最終締切）をここに配置し、逆算して中段のTaskに落とし込みます。
詳細解説 2. Task：迷いをなくすプロパティ設計
タスク管理で最も重要なのは 「次に何をすべきか、一瞬で判断できること」 です。そのために、以下のプロパティを設定しています。
必須プロパティ構成
| プロパティ名 | 種類 | 設定・意図 |
|---|---|---|
| タスク名 | Title | 具体的なアクション（例：モデル構築、データ前処理） |
| ステータス | Status | 「未着手」「進行中」「完了」の3状態で管理。カンバンビューへの切り替えも容易です。 |
| 担当者 | Person | チーム開発時は必須。個人の場合も「自分」を割り当てることで責任感を持ちます。 |
| 期日 | Date | ここに入れた日付でソートし、締め切りが近い順に並べます。 |
| Competition name | Select / Relation | 最重要ポイント（後述）。どのプロジェクトのタスクかを識別します。 |
| 優先度 | Select | 「高・中・低」を設定。 |
ビュー設定の工夫
データベースは「すべて」を表示するとノイズになります。私は以下のフィルターをかけたタブを作成しています。
-
「今日やる」タブ:
期日が今日または以前（期限切れ） のタスクのみ表示。 -
「進行中」タブ:
ステータスが進行中のものだけ表示。
詳細解説 3. Document：フローとストックの分離
なぜTaskと分けるのか？
よくある失敗が「タスクのページ内に、成果物ファイルを貼って完了にしてしまう」パターンです。これだと、タスクが完了済み（アーカイブ）になった瞬間、その資料は検索の彼方に消えてしまいます。
このようにデータベースを物理的に分けることで、ナレッジが確実に蓄積されます。
Documentデータベースの活用法
- 分析ログ: 「○○モデルのハイパーパラメータ調整結果」など、試行錯誤の履歴を残す。
- 参照リンク: 論文のURLや、参考にした技術記事のクリップ。
- 提出物: 最終的なコードやスライドのPDF。
作成日時 と 最終更新日時 の自動プロパティを入れておくと、「いつのファイルだっけ？」という混乱を防げます。
プロジェクトを横断管理する「タグ付け」テクニック
このダッシュボードの肝は、全データベースに共通して存在する Competition name（またはProject Name） というプロパティです。
方法A：セレクト（Select）プロパティを使う（初級編）
スクリーンショットにあるように、Kaggle のようなタグを作って管理します。手軽ですが、タグの名前が変わった時に全修正が必要です。
方法B：リレーション（Relation）を使う（上級編）
個人的におすすめなのは、別途 「Detabase」という親データベース を作成し、そこからリレーションを貼る方法です。
-
DetabaseDBを作成（項目：Space Titanic, 家計簿アプリ開発, etc...） -
Schedule,Task,DocumentDBから、DetabaseDBへリレーションを貼る。
こうすることで、「Detabase」のページを開くだけで、そのプロジェクトに関連するスケジュール、残タスク、資料が自動的にフィルタリングされて表示される仕組み（Linked Database）が作れます。プロジェクト数が増えてきたら、ぜひこの構成に移行してみてください。
おわりに
Notionは「何でもできる」からこそ、最初は迷ってしまいます。しかし、今回紹介した 「スケジュール・タスク・ドキュメント」の3層構造は、どのようなプロジェクトにも応用できる普遍的な型です。
まずはこの構成を真似して作ってみて、自分のワークフローに合わせてプロパティを増減させてみてください。
「探す時間」をゼロにして、本来やるべき「創る時間」を最大化しましょう。
Discussion