トップダウンかボトムアップか: ホワイト ペーパー

このホワイト ペーパーは、マイクロソフトの「From the trenches」コレクションの一部です。プロジェクト管理、ポートフォリオ管理、およびタスク管理について説明し、それらに関連するトップダウンとボトムアップの経営慣行を比較しています。

このホワイト ペーパーの Word 版をダウンロードするには、「トップダウンかボトムアップか: ホワイト ペーパー (Project Server 2010)」を参照してください。

その他のホワイト ペーパーについては、「From the Trenches」のホワイト ペーパーを参照してください。

トップダウンかボトムアップか

「当社にはプロジェクト管理が必要であり... それはポートフォリオ管理のことであり... 実際にはタスク管理であり... 要するにそれらすべてが必要だ」といった叫びにも似た声をよく耳にします。混乱の原因であるのは、これら 3 つの概念の定義が存在しないことではなく、それらが似ていることです。

IT 業界に長年従事してきた当社では、技術的な視点から物事を見る傾向がありますが、場合によってはこれがあまり役に立たないことがあります。ポートフォリオ管理、プロジェクト管理、タスク管理からデータを見ると、非常に似かよったものに見えることがあります。3 つすべてに、ID フィールド、説明フィールド、および開始/終了日を使用すれば、これら 3 つすべてをリンクするのは当然のことです。

しかし、3 つの概念は同じではありません。

これら 3 つの概念を 1 つずつ検討していきます。類似点を見つけることは簡単ですが、3 つの視点には根本的な違いがあります。

ポートフォリオ管理 - トップダウン アプローチ

「ポートフォリオ管理」という言葉は、さまざまな意味で使用されますが、おそらく最も一般的な意味は、プロジェクトの選択と優先順位付けです。その原理は、最終的には組織の全員に影響を及ぼしますが、プロセスは上級エグゼクティブにとって大きな関心の対象となります。管理には、利用できる総予算などの制約が当初から伴い、「この金額で何を達成でき、何を達成する必要があるか」という質問に答える必要があります。ポートフォリオ管理プロセスが十分に成熟していれば、この分析には新しいアイデアだけでなく既存のプロジェクトも含めることができます。

複数プロジェクトの進捗状況を示すダッシュボード

ポートフォリオの選択と優先順位付けのプロセスを実施するには、企業を動かすのはどのようなビジネス上の基準であるかという問題に管理で対処し、新規および既存のプロジェクトの検討で考慮される測定基準に関して事前に合意する必要があります。投資収益率 (ROI) を重要な経営指標にする必要があるのかという問題がありますが、通常は、顧客満足度や従業員の定着への影響または戦略的目標との調整を考慮する必要があります。重要な経営指標が何であれ、管理では、どのようにすればプロジェクトでこれらの目標を前倒しで実現できるか、およびどのようにすれば各プロジェクトが、コストが発生する可能性のある代替の構想と匹敵しうるかを視野に入れて、各プロジェクト構想を比較検討する必要があります。

比較検討は、人の頭の中で行った場合でも高度な分析を要するプロセスであり、プロジェクト ポートフォリオ管理ソフトウェアを使用する場合でも、当然として高度な分析を要します。ソフトウェアでの分析がレポートまたはビュー形式で提供されたとしても、優先順位に関する最終決定が行われる場面では、必ずといっていいほど、経営陣レベルの監督がある程度行われます。それが完了したら、各プロジェクトの管理担当者に最終結果を伝える必要があります。こういった決定の効果は、資金を供給するプロジェクトと資金を供給しないプロジェクトの区別、優先順位が高いリソースを使用可能にするプロジェクトと使用可能にしないプロジェクトの区別、スケジュールを進めるプロジェクトと遅らせるプロジェクトの区別を行えることです。

プロジェクト管理 - トップダウンとボトムアップ

プロジェクトが承認されると、プロジェクトはまったく別の領域に移行します。ここで、プロジェクト スケジューリングの古典的な見方が明確になり、プロジェクトが承認される前に業務上の正当な理由に記載した事項を、実際に構築する必要が生じます。

プロジェクト マネージャーは、プロジェクトの範囲と成果物の観点から考察を開始します。プロジェクト マネージャーは、ソフトウェアであれ、占有の準備ができている建物であれ、作成する必要がある最終生産物を理解します。また、そのプロジェクトの主要な段階を考慮し、作業分解図を作成する場合があります。

グラフ内に図示されたプロジェクトの主要なフェーズ

プロジェクトの完了に必要な論理的手順のクリティカル パスが設計されます。プロジェクト マネージャーは、作成されるスケジュールの説明も行う想定であることも認識して、プロジェクトにおける幅広い技術顧問に相談します。プロジェクト マネージャーは、各タスクを調べ、タスクをプロジェクトの段階と、最終的にはプロジェクト自体にまとめることで、プロジェクトのボトムアップ図を作成します。この時点で、プロジェクト マネージャーは、スキル、部門、または場合によっては指名して、リソースの割り当てを開始することもあります。リソースには、関連するコストが存在する場合があります。タスクの期間を計算した結果、必要なリソース、およびその金額により、プロジェクトのボトムアップ見積もりが得られます。

ここまでは問題ありません。

プロジェクトのガント チャート ビュー

しかし、プロジェクト ポートフォリオ選択プロセスのトップダウン アプローチを調べれば、そこにもコストが存在します。実際、プロジェクトの見積もりコストは、経営陣がプロジェクトを承認したときに考慮した業務上の正当な理由の一部であったのです。プロジェクトのボトムアップ見積もりが、技術顧問の統合された専門知識から手に入るのであれば、重役室でのプロジェクト選択で、経営陣は何を使ったのでしょうか?

これは鋭い質問です。組織によっては、プロジェクトの業務上の正当な理由を作成するために、プロジェクト部門からの大まかな見積もりがプロジェクトに与えられます。また、ポートフォリオ プロセスでプロジェクトを検討する前に、完全なボトムアップ見積もりを作成する組織もあります。これらのアプローチ両方における問題は、組織の労力です。完全な見積もりには多くの労力を要する場合がありますが、プロジェクトではまだ労力への資金供給に関して承認が得られていません。そのため、多くの組織では、管理者の誰かが、プロジェクトのコストに関して単純に推測を行います。

したがって、外見上は完全に統合されているプロセスでも、解決できないジレンマがわずかに存在することがあります。見積もりの実施に費やされる作業と、プロジェクトに時間を費やすことができるようするプロジェクトの選択の、どちらを先にすべきでしょうか?

さらに、ボトムアップ見積もりがポートフォリオ選択プロセスの見積もりと一致しない場合はどうなるのでしょうか? 見積もり金額が低ければ、通常問題は発生しませんが、ポートフォリオ選択の担当者が見積もった時間内または予算内に作業を完了できない可能性が高い場合は、矛盾が存在することになります。

読者の方は、上級管理者を再招集して問題を議論するのが当然であると考えるかもしれませんが、考えるほど簡単ではない状況が多く存在します。

まず第 1 に、ポートフォリオ選択の委員がプロジェクト管理のスタッフであることはめったにありません。上級プロジェクト管理スタッフのメンバーは、ほとんどの場合、ポートフォリオ選択の委員に含まれますが、グループ自体は通常、時間を合わせて全員が集合することは困難な最上級の経営陣です。第 2 に、選択の委員は不規則に会合する場合があるため、あるプロジェクトの一致しないコストの悪影響すべてを見積もりと対比して議論するために委員を再招集することは、難題になることがあります。最後に、プロジェクトの適切なスケジュールと予算の内容に関して上級経営陣の推測が完全に間違っていたという知らせを上級経営陣に伝えなければならないことは、キャリアを高める戦略にはならないという企業文化が、一部存在します。

タスク管理 - ボトムアップ アプローチ

タスク管理について考える際には、操作面に偏って考える傾向があり、そのため、毎日の問題と Outlook などの製品に行き着くことが多くなります。

タスク リストの参照

現時点では、個人または小規模チーム メンバーのレベルの問題に取り組んでいますが、文脈に応じたタスクは認識していません。認識しているのは担当しているタスクか、チーム メンバーに担当するよう依頼したタスクです。これでは分析ビューにはなりません。実行すべきタスクが存在し、また個人がタスクの実行を約束しているのです。

タスク管理は、中核においては非常に単純です。担当者がタスクを実行し、完了したら、タスクの実行を割り当てた人物にタスクの完了を通知します。このためのすべての機能は、既に Outlook に搭載されています。

類似したデータの悪影響

「外見も鳴き方もアヒルのようであれば、それはアヒルに違いない」ということわざがあります。これはアヒルについては成り立ちますが、タスクベースのデータでは必ずしも成り立ちません。

プロジェクト指向データの、次の 3 つのレベルを検討します。

  • ポートフォリオ レベルでは、プロジェクトと、通常はそのプロジェクトの下位の段階があります。段階情報には、コード番号、説明、期間、開始日、および終了日が含まれる場合があります。

  • プロジェクト レベルでは、プロジェクトと、プロジェクトの下位のタスクがあります。タスク情報には、コード番号、説明、期間、開始日、および終了日が含まれる場合があります。

  • タスク管理レベルにはタスクがあります。タスク情報には、コード番号、説明、期間、開始日、および終了日が含まれる場合があります。

これらは同じように見えますが、実際には、データの視点により、各レベルの一般的なレコードは、それぞれまったく異なる目的に対応します。

私は、「Outlook との往復で、ポートフォリオ ビューからプロジェクト ビューにデータを移動できますか」と質問されることが多くあります。

その質問に一言で答えれば、「はい」です。

しかし当社では、技術的なアドバイスをする際に、「方法は教えずに、理由を教えてください」と自分自身に言いきかせるようにしています。

  1. 問題を明確にするため、次のような例を想像してください。完全に統合された環境を作成し、スケールの先端にはポートフォリオにより編成されたプロジェクト リストを用意します。これらのプロジェクトを選ぶだけでなく、さらに統合を進め、EPM システムから稼働中のプロジェクトに対してプロジェクトが有効にされた後、プロジェクトに従います。このために、既に利用可能である機能を使用して、統合したシステムのポートフォリオ側からシステムのプロジェクト側にプロジェクトと段階の定義を移動します。外見上、データは同じです。

  2. この EPM システムでは、トップダウンからプッシュされたポートフォリオ定義に由来するオリジナルの段階を使用して、より詳細な定義を作成します。こうすることで、プロジェクトを更新した時点でポートフォリオ システムでサマリーを更新できます。多くのタスクを作成して多くのリソースを割り当て、リソースの平準化の分析を実行して多くのプロジェクトにまたがるキャパシティを確定します。

  3. また、リソース割り当てを使用してタスクをプッシュし、Outlook タスクまたはカレンダー イベントとして各ユーザーにデータを割り当てます。ユーザーが「プロジェクト管理システム」にアクセスする必要はなくなり、毎日の予定でデータを確認できるようになります。データは、プロジェクト リストでの表示と同じように表示され、さらなるアップストリームでポートフォリオ ビューにリンクされます。

  4. これらのタスクからの進行状況と Outlook からの稼働状況は、この作業が完了する時点に関する見積もりと共に、個人からプロジェクト管理システムに戻されます。データは、他の 2 つのシステムでの表示と同じように表示されるため、移動は比較的簡単です。

このようなシステムの作成は、現在利用できるツールと、わずかな構成と開発を併用すれば、技術的には非常に単純です。また、そのデモは美しくなります。

定期的にこの種の構造物を依頼されますが、作成できるとしても、作成すべきでしょうか?

タスク レベルで、ある個人が緊急の歯科検診のために午前中不在になり、Outlook を更新し、この午前に空き時間がないと通知したとします。このことはその人にとって悪いニュースですが、プロジェクトに対する波及効果は甚大になる可能性があります。そこでプロジェクト システムは、この午前中に実行されるとスケジュールされていたタスクが今日中には完了しないと計算します。そのタスクは翌日の正午前後にならないと完了しません。プロジェクト システムは、クリティカル パスと、このパスからダウンストリームにあるすべてのタスクを律儀に調べ、それらを 4 時間前方にずらします。おそらく、何百というタスクが影響を受けます。結果として、プロジェクトの終了日を半日遅らせる可能性があります。このプロジェクトに従事する他の担当者は自分のタスクを再調整する必要があり、ポートフォリオ ビュー自体が数ピクセル前方にスライドするため、他のプロジェクトも影響を受けます。

このようなことが現実の時間で生じたとすると、問題はさらに拡大します。何百、何千という人員がその日を通して変更を行い、EPM ビュー、リソースの平準化ビュー、およびポートフォリオ ビューが影響に伴い前後に移動します。

現実では、このような事態は発生しません。まず第 1 に、不運な歯科患者は正午に持ち場に戻り、このクリティカル パスがキャッチ アップされるようにその夜に数時間遅くまで仕事をするだけで、翌日の午前中にはすべてが順調に元通りになるためです。

加えて、データが外見上は同じであっても、まさにこの効果により上記のように統合されることはありません。

データのコンテキスト - 問題となる観点

データを調べる際には、データのコンテキストが非常に重要です。レコード対レコード スキーマからは同じに見える可能性があるデータは、アプリケーションの観点に基づいて、きわめて多様な目的に使用されます。

トップダウン ポートフォリオ ビューでは、投資収益率を最大化するためにリソース配置する場所を戦略的に決定します。当社では、プロジェクト マネージャーが行わない選択を行う場合があります。当社の組織では、既存のスキル セットの完全な範囲外にあるプロジェクトを選択したことがあります。当社はこのようなプロジェクトの実施に関して大きく能力が劣ることを認識していましたが、まさにこのようなスキルを改善する必要があったためにこのように選択しました。投資で得られたものは効率的なインストール環境ではなく、トレーニングを積んだインストール担当者でした。これは分析ビューです。

戦術的プロジェクト ビューでは、当社の人員を最適化し、可能な限り迅速かつ効率的にプロジェクトを完了させる場所に関して、運用面での決定を行っています。プロジェクト マネージャーの視点は、常に将来を向いています。過去に起こったことがプロジェクト マネージャーの興味の対象となるのは、それが将来の観点を改善する場合に限られます。これも高度な分析ビューです。

予定などのタスク管理ビューでは、当社は分析を行いません。予定とは約束のシステムで、特定の時間に特定の事柄を行うことを自分自身や他者に対して約束することです。これは分析ビューに合致する場合もあれば、合致しない場合もあります。

影響を理解せずにこれらの観点とコンテキストを混同すると、混乱の原因になる可能性があります。

トップダウンかボトムアップか

例によって、適切な答えは存在しません。プロジェクト管理システムの一部の側面は、実際に、ボトムアップに由来する必要があります。結局のところ、性質を問わずプロジェクトを構築するのは個人なのです。しかし、一部の決定はまさにトップから作られ、またその必要があるため、必然的にトップダウンになります。

プロジェクト管理パラダイムの各レベルの対象を継続的に区別すれば、これらのシステムの一部を実際に統合する必要があるかどうかの確認作業がより明確になります。あるレベルのプロセスと思考が、別のレベルからの完全な統合による直接のメリットがない場合、統合は最適な対処ではありません。このような統合が現実世界の文脈でどのように機能するか、およびあるレベルの頻度と詳細情報が他方のレベルに価値をもたらすかどうかを大まかに観察することが重要です。

ワークフローを表示するダイアグラム

たとえば、運営委員会が四半期に 1 回だけ会合し、推進するプロジェクトと推進しないプロジェクトに関して大規模な決定を行う場合、プロジェクトのビューを毎日、毎週、あるいは毎月更新するメリットとは何でしょうか?

EPM のリソースの平準化アルゴリズムで、個人の歯科医の予約を実際に確認する必要が生じるのでしょうか? それとも、その個人の大まかな利用状況を把握すれば十分でしょうか?

それでも、個人の予定またはタイムシートの画面に割り当てを直接送信できれば、別のシステムとインターフェイスにアクセスして同じデータを確認する必要がある毎日の数分を節約することになるのでしょうか?

そのため、トップダウンが適切な環境もあれば、ボトムアップが適切な環境もあります。ツールと概念をまとめる前に、自分自身の状況を調べて、これらのツールと概念の統合で適切な配当を払い戻すことができる場面を確認する必要があります。

著者について

Chris Vandersluis 氏は、カナダのモントリオールに拠点を置き、Microsoft 認定パートナーである HMS Software 社の社長であり創業者です。マギル大学で経済学の学士を取得し、プロジェクト制御システムの自動化に 30 年以上携わってきました。PMI (プロジェクト マネジメント協会) の古くからの会員であり、MPUG (Microsoft Project Users Group) のモントリオール、トロント、ケベックの支部の設立を支援しました。Vandersluis 氏が寄稿した出版物には、Fortune、Heavy Construction News、Computing Canada magazine、および PMI の PMNetwork などがあり、Project Times のレギュラー コラムニストです。マギル大学で上級プロジェクト管理を教えており、北米および世界中のプロジェクト管理団体の会合で頻繁に講演しています。HMS Software 社は TimeControl プロジェクト指向型の時間管理システムの発行元であり、1995 年から Microsoft Project ソリューション パートナー企業です。

Chris Vandersluis 氏のメールの連絡先は chris.vandersluis@hms.ca です。

Chris Vandersluis 氏の EPM 関連のその他の記事については、HMS 社の EPM ガイダンスのサイト (http://www.epmguidance.com/?page_id=39) を参照してください。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×