複雑なソフトウェアを使わずに複数のプロジェクトを管理する方法
複数のプロジェクトがどのように進んでいるかを把握するには、各プロジェクトの次のマイルストーン、現在のステータス、進捗の根拠、次のアクション、担当者、およびブロッカー（障害）を表示する共有の一覧表を1つ作成します。定期的なスケジュールで更新し、すべてのプロジェクトで同じステータス定義を使用します。チームが最新の状態を維持でき、簡単に見つけられるのであれば、ホワイトボード、スプレッドシート、またはシンプルなドキュメントで十分です。\n\nこのガイドは、進行中のいくつかのプロジェクトを調整し、何が動いていて、何にリスクがあり、どこで決定やフォローアップが必要かを見極める必要がある人を対象としています。すべてのタスクを詳細に追跡することではなく、有用な横断的プロジェクトビューを構築することに焦点を当てています。
下すべき意思決定から始める
フォーマットを選ぶ前に、その概要表で答えを出したい質問を書き出します。例えば、次のマイルストーンに向けて順調に進んでいるプロジェクトはどれか？今週注意が必要なものはどれか？ある人が他のプロジェクトの完了を待っている状態になっていないか？自分自身の判断が必要なものは何か？などです。
これらの質問があることで、概要表の焦点を絞り続けることができます。すべてのタスク、メモ、会話を追加してしまうと、プロジェクト横断の全体像が埋もれてしまいます。詳細なタスクリストは実際に作業が行われる場所にとどめておき、概要表はプロジェクト間の調整に役立つわずかな事実を示すために使います。
この区別は実践的なものであり、プロジェクト管理の厳格なルールというわけではありません。Atlassianのプロジェクトステータスレポートガイドでは、進捗状況、今後の作業、課題やブロッカーを報告することを推奨しています。複数のプロジェクトにおいては、それらの項目を一目で並べて比較できる程度に統一することが有効な拡張アプローチとなります。
1ページのプロジェクト概要を作成する
プロジェクトごとに1つの行またはカードを作成します。出発点として、次の項目を使用してください。
プロジェクト名と目指す成果、次に確認可能なマイルストーンと目標日、現在のステータス、何が変わったかを示す根拠、次のアクションと担当者、ブロッカーや依存関係、そしてその行が最後に確認された日付を記録します。どのプロジェクトでも項目の順序は同じにしておきます。
マイルストーンは、「下書きをレビュー担当者に共有した」や「イベント会場が確定した」など、他の人から見ても完了が客観的に認識できる内容にする必要があります。「進捗を出す」はチェックポイントにはなりません。プロジェクトの次の決定や納品にとって重要なマイルストーンを選択してください。些細なタスクを長く並べると、概要表が読みにくくなります。
Kanban Universityによるかんばん方式のガイドでは、作業とそのワークフロー内の動きを可視化することが、目に見えにくい作業を理解しやすくする方法として説明されています。シンプルな概要表は、その考え方をプロジェクトレベルで適用したものです。現在の状態と作業がどこで滞留しているかを示します。完全なかんばんシステムを導入する必要はありません。
誰もが一貫して適用できるステータスラベルを使用する
色分けされたラベルは、全員がその意味を理解して初めて役に立ちます。概要表の横に短い定義を書き、プロジェクト全体の漠然とした印象に対してではなく、「次のマイルストーン」に対して適用します。例：
順調（On track）：次のマイルストーンは目標期日までに達成される見込みであり、現在それを脅かす未解決の問題はない。
注意（Watch）：マイルストーンに影響を与える可能性のある特定の懸念事項があるが、次のステップは特定されている。
中断/ブロッカー（Blocked）：特定された問題、決定、または依存関係が解決されるまで、進捗を進めることができない。
これらのラベルは作業上の提案規約であり、公式の標準ではありません。概要表を更新または利用する人たちと合意を形成してください。プロジェクトに「注意」のマークが付いている場合は、その理由と「順調」に戻すためのアクションを記載します。「中断」の場合は、必要な支援と誰がフォローアップするかを明記します。説明のないラベルは、深刻な問題と些細な不確実性を同じように見せてしまうおそれがあります。
大きく異なるプロジェクト間で「進捗率（パーセンテージ）」を主要な指標として扱うことは避けてください。「80%完了」という言葉は、デザイン、イベント、研究調査ではまったく意味が異なる場合があります。日付の入ったチェックポイントと観察可能な根拠を示すことで、閲覧者はより具体的に状況を解釈できます。これは実践的な比較を行うための選択であり、パーセンテージが一切役に立たないと主張するものではありません。作業を一定の基準で測定できるプロジェクト内であれば役立つ場合もあります。
負担の少ない更新ルーティンを設定する
概要表は、その情報が最新であるかどうかが分かって初めて機能します。プロジェクトの変化のスピードに合った更新リズムを選んでください。多くの小規模グループにとって週1回の確認は妥当な出発点ですが、動きの遅い取り組みであれば頻度を減らし、変化の速いプロジェクトであれば頻度を増やす必要があります。Atlassianもステータスレポートガイドの中で、プロジェクトの複雑さやステークホルダーのニーズに合わせてステータスレポートの頻度を選択することを推奨しています。
更新ごとに、各プロジェクトの担当者に次の4点を確認してもらいます。
1. 次のマイルストーン、目標日、または担当者に変更はあったか？
2. 前回の確認以降、目に見える形で完了した作業は何か？
3. ブロッカー、新たな依存関係、または必要な意思決定はあるか？
4. 次のアクションは何か、そしてそれはいつ再確認されるか？
更新日を記録します。ある行が最近確認されていない場合は、「未更新」とマークするか、そのステータスを最新のものとして扱う前に担当者に確認してください。これにより、古い「順調」ラベルが最新の評価であるかのように見えるのを防ぎます。日付が変更された場合は、変更の理由や決定を短いメモに残します。そうしないと、度重なる期日変更の理由を後から解釈することが困難になります。
更新のためのミーティングを行う場合は、例外事項や調整事項に焦点を絞ります。事前に各行に目を通しておき、議論の時間は、進行が阻害されている作業、マイルストーンのリスク、依存関係、複数のプロジェクトに影響を与える選択肢に充てます。日常的な進捗は、すべてのタスクを口頭で説明しなくても記録に残せます。これは概要表の目的に基づく効率化の提案であり、特定のミーティングの長さがすべてのチームでうまくいくことを保証するものではありません。
プロジェクト間の依存関係を見つけ出す
個々のプロジェクトは順調に見えても、同じ人員、意思決定、会議室、機材、またはレビューの時間を奪い合っている場合があります。あるプロジェクトが別のプロジェクトからの成果物を必要としている場合は、依存関係を追加します。提供側と受領側の双方、および重要な期日や条件を記録してください。例えば、「ウェブサイトの公開には、5月12日までにイベントプロジェクトからの最終的なイベント詳細が必要」といった形です。
その後、概要表をざっと見て、重複している担当者や日程がないか確認します。同一人物が同時に期日を迎える複数のネクストアクションを担当していたり、あるプロジェクトの決定の遅れが別のプロジェクトのマイルストーンを狂わせたりする場合は、その競合を可視化し、優先順位や修正計画について合意を取ります。これこそが、個別のプロジェクト報告よりも1つの概要表が優れている点です。約束や依存関係を1か所で比較できます。Project Management Institute（PMI）のポートフォリオプロセスでも同様に、プロジェクト横断の目録をすべてのタスクで埋めるのではなく、大枠のマイルストーン、ステータス、プロジェクト間の相互依存関係を記録します。ここでのコンパクトな形式は、それを小規模グループ向けに編集・適応させたものです。
担当者が決まっているからといって、依存関係が解決されたと思い込まないでください。予定されている引き渡しを記録し、それが実際に行われたときに確認します。順序や日程が不確実な場合は、その旨を明記してください。暗黙の約束よりも、可視化された不確実性のほうが議論しやすくなります。
使い続けられる最もシンプルなフォーマットを選ぶ
並べ替え可能な行、日付、フィルター、または多数のプロジェクトにわたるコンパクトなビューが必要な場合はスプレッドシートを使用します。グループが同じ場所で作業しており、カードをステージごとに移動させる利点がある場合はホワイトボードを使用します。更新内容が主に短い文章の要約であり、プロジェクト数が少ない場合は共有ドキュメントを使用します。
これらはフォーマットのトレードオフであり、特定の製品を推奨するものではありません。グループがアクセスし、理解し、更新できる最もシンプルな選択肢を選んでください。ソフトウェアを追加する前に、実際に何が機能していないのかを問い直してください。ステータスの比較が難しいのか？更新が遅れているのか？依存関係が見えていないのか？新しいツールはコラボレーションやリマインダーに役立つかもしれませんが、それ自体が不明確なマイルストーンや欠如したオーナーシップを明確にしてくれるわけではありません。
プロジェクトごとに異なる専門的な詳細が必要な場合は、それらを既存の作業記録に残し、実用的な範囲で概要表からリンクまたは参照するようにします。プロジェクト横断のビューは、一目で把握できるコンパクトさを維持すべきです。大幅に横に広げる必要がある場合は、一部の項目が同じ問いに答えていないか、あるいはプロジェクトレベルのメモに含めるべきものではないかを確認してください。
具体例
あるコーディネーターが、コミュニティイベント、ウェブサイトのリニューアル、月刊ニュースレターの3つのプロジェクトを担当しているとします。その概要表は次のようになります。
例：コミュニティイベントは「注意」。候補となる2つの会場がまだ予約できていないため。担当者は5月12日の会場決定マイルストーンに向けて5月8日までに空き状況を比較する予定。ウェブサイトのリニューアルは「順調」。ドラフトページがレビュー担当者に届いたため。5月15日のレビューに向けて5月10日までにコメントが集まる予定。月刊ニュースレターは「中断」。最終原稿に確定したイベント詳細が必要なため。担当者は5月9日の原稿マイルストーンの前に、5月7日までに詳細を請求する予定。
これらは説明のための記入例であり、実際の報告結果ではありません。この概要表によって「ニュースレターはイベントの詳細に依存している」という依存関係が可視化されます。また、「ニュースレターに間に合うようにイベントの決定が下せるかを確認する、あるいはニュースレターの計画を調整する」という有益な次の行動も見えてきます。ステータスの色だけでは、懸念の理由も必要な調整も分かりません。
このアプローチにより多くの構造が必要になるとき
多くの人が同じ作業を更新する場合、プロジェクトに複雑なスケジュールや予算がある場合、アクセス権の制御が必要な場合、あるいは決定や変更の記録が重要な場合には、1ページの概要表では足りなくなることがあります。その場合でも簡潔な横断的サマリーを維持することは可能ですが、詳細な情報については、より構造化されたシステムとより明確な責任分担が必要になる可能性があります。
小さなポートフォリオであれば、まずは少数の項目から始め、ステータスの定義に合意し、一定のリズムで同じマイルストーンを確認してください。概要表が、注意すべき点を見極め、次のアクションを調整するのに役立っているなら、それは役割を果たしています。もし誰も使わないのに記入するだけの形式的なレポートになってしまったら、簡素化するか、答えるべき問いを変更してください。