Microsoft ListsでPlannerのように1つのタスクにチェックリスト形式のサブタスクをぶら下げたい――そう考えたとき、「サブタスク列」が見当たらず困った経験はないでしょうか。本記事では、Microsoft Listsに公式のサブタスク機能がない前提で、実務で使える4つの現実的な設計パターンと具体的な作り方を詳しく解説します。
Microsoft Listsには「サブタスク列」が存在しない
まず最初に押さえておきたいポイントは、Microsoft ListsにはPlannerのような「サブタスク専用列」や「チェックリスト専用機能」は標準では存在しないという事実です。
Listsはあくまで「表（リスト）」をベースにした情報管理ツールであり、階層構造やチェックリストは自前で設計する必要があります。見た目がExcelに似ているため、つい「チェックボックス列を追加すればサブタスクになるのでは？」と考えがちですが、以下の課題が出てきます。
- 1アイテム内に複数のサブタスクを柔軟に持たせるのが難しい
- サブタスクごとに担当者・期限・コメントなどを持たせにくい
- タスク単位で進捗集計（完了率など）を自動化しづらい
そのため、「サブタスク列を探す」のではなく、「サブタスクを表現できるデータ構造を設計する」という発想に切り替えることが重要です。
なぜ「サブタスク列」が欲しくなるのか（要件整理）
最適な設計を選ぶために、まずは「なぜサブタスク列が欲しいのか」を整理しましょう。よくある要件は次の通りです。
- 1つのタスクをさらに細かい作業に分割して管理したい
- サブタスクごとに担当者を変えたい（例：資料作成はAさん、レビューはBさん）
- サブタスクごとに期限を設定し、遅延を可視化したい
- 親タスクの進捗率をサブタスクの完了状況から自動計算したい
- Plannerのチェックリストのように「チェックボックス付き」で見やすくしたい
これらをすべて満たそうとすると、単純な「はい/いいえ列」だけでは限界があります。本記事では、現実的な4つのパターンを比較しながら、要件に合った構成を選べるように解説します。
サブタスクを実現する4つのパターン
本記事で扱う4つの代表的なパターンを一覧で比較しておきます。
| パターン | 概要 | 向いているケース | 難易度 |
|---|---|---|---|
| A. 自己参照ルックアップ | 同一リスト内で親子関係を持たせる | 1リストで完結させたい、小〜中規模のタスク管理 | 中（Power Automateで集計すると中〜やや高） |
| B. 別リスト＋ルックアップ | 親リストとサブタスクリストを分ける | 子タスクが大量に発生する、大規模な案件 | 中〜やや高 |
| C. Yes/No列チェックリスト | 固定本数のはい/いいえ列を使う | 単純なチェックリスト、担当者や期限を分けない場合 | 低 |
| D. 製品の使い分け | Planner / Project / Loopなどを併用 | プロジェクト管理色が強い、複雑な計画管理 | ツール選定・連携の理解が必要 |
実務では、A（自己参照ルックアップ）またはB（別リスト）が「王道パターン」になります。Cはお手軽、Dはそもそもツールを変える選択肢です。
おすすめ：同一リストで親子関係を持たせる自己参照ルックアップ
最もバランスがよく、実務でも採用しやすいのがA. 自己参照ルックアップです。1つのリストに「親タスク」と「サブタスク」を混在させ、「親タスク」列で親子関係を表現します。
自己参照ルックアップ構成のイメージ
次のようなリスト「Tasks」を作ることを想定します。
| 列名 | 種類 | 用途 |
|---|---|---|
| タイトル | 既定（単一行テキスト） | タスク名。親タスク・サブタスク共通 |
| 親タスク | ルックアップ（同一リストのタイトル） | 親タスクを指定。親側は空欄、子側は親をセット |
| ステータス | 選択肢 | 未着手 / 進行中 / 完了 など |
| 担当者 | ユーザー | タスクの担当者。子タスクごとに設定可能 |
| 期限 | 日付 | タスクの期日。子タスクごとに設定可能 |
| 進捗率 | 数値（0〜100） | 親タスクの完了率を格納（Power Automateで更新） |
親タスク：「親タスク」列が空欄のアイテム
サブタスク：「親タスク」列に親アイテムを指定したもの
ビュー設計の例
自己参照ルックアップを使う場合、ビューの設計が重要です。代表的なビューは次の2つです。
- 上位タスクビュー：フィルターで「親タスク is empty」にし、親だけを一覧表示
- 親別ビュー：「親タスク」列でグループ化し、親ごとにサブタスクの一覧が折りたたまれて表示されるビュー
「親別ビュー」を使うと、Plannerのカードを開いたときにチェックリストが表示されるイメージに近い形で、親ごとにサブタスクの一覧を見渡せます。
作成手順（自己参照ルックアップ）
- Microsoft Listsで新しいリスト「Tasks」を作成
- 列を追加
- 親タスク：ルックアップ列にし、「このサイトの既存のリスト」→ 自分自身の「Tasks」を指定してタイトル列を参照
- ステータス：選択肢（未着手 / 進行中 / 完了 など）
- 担当者：ユーザー列
- 期限：日付列
- 進捗率：数値列（0〜100、既定値0）
- ビューを作成
- 「上位タスク」ビュー：フィルター条件に「親タスク が空」を指定
- 「親別」ビュー：グループ化で「親タスク」を第一グループに設定
- 「親別」ビューに切り替え、親タスクを登録 → サブタスクを追加し、親タスク列で紐づけ
Power Automateで進捗率を自動計算する
親タスクの「進捗率」をサブタスクの完了状況から自動計算したい場合は、Power Automateとの連携がおすすめです。
基本的なフローのイメージは次の通りです。
- トリガー：アイテムの作成または変更（対象リスト：Tasks）
- 条件分岐：変更されたアイテムの「親タスク」が空でない場合のみ処理（= サブタスクの場合）
- アクション1：親タスクのIDを取得
ルックアップ列「親タスク」から親アイテムのIDを取り出す - アクション2：親IDを条件に、同じ親を持つ子タスクをすべて取得
- アクション3：
- 総数 = 子タスクの件数
- 完了数 = ステータス = 完了 の件数
- 進捗率 = (完了数 / 総数) × 100 を計算
- アクション4：親タスクのアイテムを更新し、「進捗率」列に計算結果を書き込む
このフローを一度作ってしまえば、サブタスクが追加・更新されるたびに親タスクの進捗率が自動で更新されます。管理者が手で進捗率を入力する必要がなくなるため、実務上のミス防止にも効果的です。
自己参照ルックアップ方式のメリットと注意点
| メリット | 注意点 |
|---|---|
| 1つのリストで親タスクとサブタスクを一元管理できる サブタスクごとに担当者・期限・ステータスを持てる ビューのグループ化で親子構造が視覚的に分かりやすい Power Automateと組み合わせることで、親タスクの進捗率を自動化できる | 階層は実質1段階（親–子）までが現実的（孫タスクは複雑になる） フローの設計がやや複雑になりやすい 件数が増えるとパフォーマンスに影響するため、「親タスク」列のインデックス付与が推奨 |
親子1階層で十分なケースであれば、まずはこの構成から始めるのがもっともおすすめです。
別リスト方式：親リスト＋サブタスクリストを分ける
サブタスクの件数が多くなりそうな場合や、親タスクとサブタスクの管理者・利用者が大きく異なる場合は、B. 別リスト方式が有力です。
基本構成
次のようにリストを分けます。
- 親リスト「Tasks」：プロジェクトや大きなタスク単位を管理
- サブタスクリスト「Subtasks」：各親タスクに紐づく細かい作業を管理
| リスト | 主な列 | ポイント |
|---|---|---|
| Tasks | タイトル / 進捗率 / ステータス / 担当部門 など | プロジェクト全体や大きなタスクの粒度で管理 |
| Subtasks | タイトル / 親タスク（ルックアップ：Tasks） / 担当者 / 期限 / ステータス など | 個々の作業単位を細かく管理 |
運用イメージ
- Subtasks側で「親タスク」列をルックアップに設定し、Tasksのタイトル（またはID）を参照
- Subtasksに「親タスクごとのフィルター付きビュー」を作成し、親タスクごとにサブタスクを確認
- SharePointページやTeamsタブで、TasksとSubtasksのビューを並べて表示すると見やすい
こちらも、親タスクの進捗率や件数集計はPower Automateで実装できます。
Power Automateでの親側への集計書き戻し
フローの考え方は自己参照ルックアップ方式とほぼ同じです。
- トリガー：Subtasksのアイテム作成または変更
- 条件分岐：対象アイテムに「親タスク」が設定されている場合のみ処理
- アクション：その親タスクを持つSubtasksアイテムをすべて取得 → 完了数・総数を計算
- Tasksリストの該当親アイテムを更新し、「進捗率」や「サブタスク完了数」などの列を更新
別リスト方式が向いているケース
- 1つの親タスクに数十〜数百のサブタスクがぶら下がる可能性がある
- 親タスクを管理するチームと、サブタスクを実行するチームが異なる
- サブタスク側の列構成・ビュー・権限設定を柔軟に変えたい
- 将来的にPower Appsでフォームをカスタマイズし、親画面に子一覧を埋め込みたい
標準のListsだけでは、「親タスクを開いた画面に自動的に子タスク一覧を埋め込む」ようなUIは弱めです。ただし、Power Appsでフォームをカスタマイズすると、親アイテムフォームの下部にギャラリーで子タスク一覧を表示するといった高度な構成も組めるようになります。
超簡易：Yes/No列を使った固定本数のチェックリスト
C. Yes/No列チェックリストは、機能は限定的ですが「とりあえずチェックリストだけ欲しい」ケースには有効です。
構成イメージ
- 列「サブ1完了」（はい/いいえ）
- 列「サブ2完了」（はい/いいえ）
- 列「サブ3完了」（はい/いいえ）
- …といった形で、必要な本数だけYes/No列を追加
このままだと何のチェックなのか分かりにくいため、列の表示名を工夫したり、列の書式設定（JSON）でチェックボックス風の表示にカスタマイズすると見た目が分かりやすくなります。
メリット
- 設定が非常に簡単（数分で実装可能）
- Power Automateなどを使わなくてもすぐに運用開始できる
- ユーザーから見て「Excelのチェックボックス」に近い感覚で使える
デメリット・制約
- サブタスクの本数が固定で、それ以上追加できない
- サブタスクごとに担当者・期限・コメントなどを持たせられない
- サブタスク名を動的に変えたい場合に対応しづらい
- レポートや集計の柔軟性が低い
「タスク1つにつきチェック項目が3つだけ決まっている」「担当者はタスク単位だけで十分」といった、単純なケースであればこの方式でも十分です。逆に、サブタスク単位の責任や期限を管理したい場合は、AまたはBの構成を選ぶべきです。
「選択肢列＋グループ化」は本格運用には向かない
よくある代替案として、「選択肢列にサブタスク名を並べて、グループ化でそれっぽく見せる」という方法があります。
しかし、この方式は次の理由から本格運用にはあまり向きません。
- 1アイテムに複数のサブタスクを持たせるのが難しい
- サブタスクごとの担当者・期限を持てない
- どのサブタスクが完了したかを集計しにくい
- 「選択肢の追加・変更」が列定義レベルの作業になるため、運用負荷が高い
小規模なリストであれば運用できなくはありませんが、将来的に拡張しにくい構成となるため、最初からAまたはBの方式を採用したほうが長い目で見ると安全です。
Planner / Project / Loopなどとの使い分け
ここまでMicrosoft Listsの中だけでサブタスクを表現する方法を見てきましたが、要件によってはそもそも「Lists以外のツールを使う」ほうが素直な場合もあります。
| ツール | 特徴 | サブタスクの位置づけ | 向いているケース |
|---|---|---|---|
| Planner（タスク） | ボード形式のタスク管理。Teamsとの連携がしやすい | カード内のチェックリストとして軽量なサブタスクを表現 | シンプルなチームタスク管理、軽いToDoレベル |
| Project for the web | ガントチャートや依存関係を持つ本格的なプロジェクト管理 | タスクの階層化（アウトライン）で下位タスクを構成 | 大規模・長期のプロジェクト、工程管理が重要なケース |
| Microsoft Loop | 柔軟なコンポーネントで共同編集が可能 | Loopタスクコンポーネント内でチェックリストやタスクを自由に構成 | アイデア整理や会議メモとタスクを一体運用したい場合 |
| Microsoft Lists | 台帳・一覧型の情報管理に強い | 親子1階層程度のタスク構造や、属性付きのサブタスク管理に向く | タスクを「データベース」として蓄積・分析したい場合 |
例えば、日々の業務タスクや軽いToDoであればPlannerで十分です。一方で、タスク1件ごとにカスタム列（部署、種別、工数、コストなど）を持たせたい場合はListsが得意な領域です。
「サブタスクをListsで無理やり再現するより、PlannerやProjectを併用したほうが全体としてスッキリする」ケースも少なくありません。要件を整理したうえで、ツール選定を行うとよいでしょう。
実務でのシナリオ別おすすめ構成
最後に、よくあるシナリオ別にどの構成が向いているかの一例をまとめます。
| シナリオ | おすすめ構成 | ポイント |
|---|---|---|
| 小規模チームの業務タスク管理 | A. 自己参照ルックアップ | 1リストで完結し、親子1階層で十分なことが多い |
| 大規模プロジェクトでタスク数が膨大 | B. 別リスト方式 ＋ 場合によりProject | Subtasksを独立させることで、パフォーマンスと整理性を確保 |
| 単純なチェックリスト運用 | C. Yes/No列チェックリスト | 担当者や期限をサブタスク単位で分けないなら手軽で十分 |
| プロジェクト計画や依存関係を重視 | Project for the web（＋必要に応じてLists） | ガントや依存関係管理に特化したツールを優先 |
| アイデア出し〜実行までを柔軟に行いたい | Loop ＋ Planner / Lists | 会議メモやタスクを一体化しつつ、最終的なタスクをPlannerやListsで管理 |
運用を安定させるためのTips
- 列名・ビュー名はユーザー目線で分かりやすく
例：「上位タスク一覧」「親別（サブタスク展開）」など、日本語で直感的な名前にすると定着しやすくなります。 - インデックス列を活用してパフォーマンスを維持
親タスクやステータス、期限などでフィルターすることが多い場合、それらの列にインデックスを付与しておくと、件数が増えても快適に動作しやすくなります。 - Power Automateのフローは「最小限から」
最初から完璧な自動化を目指すとフローが複雑になりがちです。まずは「サブタスクの完了率だけ自動反映する」といったシンプルなものから始めると良いでしょう。 - JSON書式設定で「見た目」を整える
進捗率列を進捗バーにしたり、ステータスに色を付けたりすると、サブタスクの状態が一目でわかるようになります。見た目の工夫はユーザーの定着に直結します。 - 階層を増やしすぎない
「親タスク → サブタスク → サブサブタスク…」と階層を増やしすぎると、Listsでは管理が非常に複雑になります。原則1階層に収め、どうしても必要な場合はProjectなど他ツールの併用を検討しましょう。
まとめ：Listsでサブタスクを扱うなら「データ構造の設計」がカギ
本記事のポイントを最後に整理します。
- Microsoft Listsには、Plannerのような「サブタスク専用列」やテンプレートは存在しない
- 実務では、次のいずれかのパターンが現実的
- A. 自己参照ルックアップ：同一リスト内で親子関係を構築（おすすめ）
- B. 別リスト方式：親リストとサブタスクリストを分離
- C. Yes/No列：固定本数の簡易チェックリストとして使用
- D. Planner / Project / Loop：要件によってツールを使い分ける
- サブタスクごとの担当者・期限・完了管理まで行う場合は、AまたはBの構成＋Power Automateによる親の集計自動化が安定した運用につながる
- 軽量なチェックリストで足りる場合は、CのYes/No列でも十分対応可能
- プロジェクト計画や依存関係管理が主目的であれば、Listsだけにこだわらず、PlannerやProjectの活用を検討する
「サブタスク列がないからできない」と考えるのではなく、どのような粒度でタスクを管理したいか、誰がどの情報を見たいかを整理したうえで、最適なデータ構造とツール選定を行うことが、Microsoft Listsを活かしたタスク管理の近道です。
コメント