投稿者: 依田 智夫

AIサマリー:
この記事では、PMBOK第7版がタスク・マネジメントにもたらす意味について詳述しています。特に、新しいパフォーマンス・ドメインと開発アプローチ、ライフサイクルの重要性が強調されています。また、バリューデリバリー・システムの概念を理解し、業界や契約形態にかかわらず価値創出を目指すことが重要であると述べています。

この記事（３／３）では、プロジェクト・マネジメント知識体系ガイドの2.3　開発アプローチとライフサイクル・パフォーマンス・ドメインについて説明し、タスク・マネジメントにもたらす意味を考えてみます。

開発アプローチとライフサイクル・パフォーマンス・ドメインの主要な概念と用語

このパフォーマンス・ドメインの効果的実行の結果として得られる成果は、以下の2点であるとされています。

• 開発アプローチ
• プロジェクト・ライフサイクル

プロジェクト・ライフサイクルは、プロジェクト・フェーズの連なりのことですが、プロジェクト・ライフサイクルについて以下の2点が強調されています。

• ビジネスの活動と利害関係者のバリュー（価値）をつなぎ続けること
• プロジェクト成果物を生産するために必要なデリバリー・ケーデンスと開発アプローチを容易にするものであること。

つまり、プロジェクト・フェーズとは、単なるアクティビティのグループ化であってはならないということです。
デリバリー・ケーデンスのケーデンスとは聞きなれない言葉ですが、Wikipediaによれば、技術用語として「回転数・歩数（通常一分当たりの回数で示す）」という意味があるとされていて、音楽とも関係がありそうです。そうなると、デリバリー・ケーデンスとはデリバリー（納品）の間隔・リズムということになります。アジャイル開発、反復型開発、リーン生産方式、そうした概念からの影響があるのでしょう。

ケーデンスを含めて、このパフォーマンス・ドメインに係る用語が定義されていますので、これらも日本語訳で紹介します。

用語の定義

成果物
ユニークで検証可能な製品、結果、あるいはサービス遂行の能力など、プロセス、フェーズ、プロジェクトの遂行によって生産すべきもの

開発アプローチ
製品、結果、サービスをつくり出す、あるいは発展させるためにプロジェクト・ライフサイクルを通じて用いられる方法。主な例として以下を紹介しています。

• 予測型（ウォーターフォール型）
• ハイブリッド型
• 適応型

ケーデンス
プロジェクトを通じて実施されるアクティビティのリズム。例として以下を紹介しています。

• 単一デリバリー
• 複数回デリバリー
• 定期的デリバリー

プロジェクト・フェーズ
特定の成果物を目的とする、論理的に関係するアクティビティの集まり

プロジェクト・ライフサイクル
フェーズの連なり

上記した用語の内で、最も厚みを持った用語は、開発アプローチでしょう。その選択には様々、考慮すべき点があります。ここでは、その考慮すべき点が、3つの観点で分類されています。①製品、サービス、結果、②プロジェクト、③組織という3つの観点です。詳述はしませんが、PMBOK第7版を入手して、これらの考慮すべき点から、自分が関係するプロジェクトにふさわしい開発アプローチはどんなものか考えてみると良いでしょう。また、これらの概念と用語を実際にどのように組み合わせてプロジェクト・ライフサイクルをつくり出すのか理解できるように、コミュニティーセンター設立というわかりやすい事例が説明されています。（下表参照）

求められる計画への複合的視点

これまで3回にわたって、PMBOK第7版を概観してきましたが、大きく変化したポイントの一つは、この記事（３／３）で紹介した開発アプローチとライフサイクル・パフォーマンス・ドメインであると筆者は考えます。そこで説明されているのは「プロジェクト計画への複合的視点」とも言えるものです。
これまでプロジェクトの計画に対しては、大雑把に言って、二つのとらえ方がありました。一つは、製造や建設・エンジニアリングのような業界を中心とした、「一度立てた計画は守らなければならない」というもの。もう一つは、ソフトウェア業界、あるいはコンサルティング業界などを中心とした、「計画は立てるが、実際にはやってみなければどうなるかはわからない」というものです。

それぞれのとらえ方には理由があります。前者の業界では、一般に契約金額も高額で、参加するプロジェクト関係者も多く、「一度立てた計画が守られない」事態など、発注者としては考えたくもありません。後者の業界では、発注者側がプロジェクト開始時に要件を明確に提示することができないことが多く、そうした場合には、最初に立案した計画通りのシステムの完成を約束することなど、受注者としてはどうしてもできない相談ということになります。そして、これらプロジェクトの計画に対する二つのとらえ方にしたがって、それぞれの業界は、請負契約と準委任契約（ソフトウェア業界でのSES契約を含む）を選択してきたと言えます。

しかしながら、PMBOK第7版は、「価値」に立脚すれば、プロジェクトの契約はこれらの二つに一つの選択しかないという「法律的」ステレオタイプから脱却できると教えてくれます。（価値と言う考え方も、従来なら顧客価値という言葉が使われたものですが、PMBOK第7版では積極的には使われておらず、「利害関係者の価値」に置き換わったと考えられます。カーボンニュートラルやSDGsなど、地球環境やサステナビリティーといった全体的な価値が重視されるこれからの社会に向けた配慮がそこにはあるのだと思います）　さらに、契約が法律的ステレオタイプから脱却できるのならば、その導入部である営業、そしてマーケティングについてさえ、ステレオタイプから脱却できるということになります。それは、価値に立脚することが、計画への複合的視点を許容し、むしろそれを積極的に求めてくるからです。計画への複合的視点とは、「どのような成果物（商品、製品、サービス、支援）がどの時点で、どのように必要とされるかを複合的にとらえることです（PMBOK第7版で説明されている用語ではありません）。その結果、導かれる特定フェーズの業務が一つの契約の範囲内に収まっている保証はなく、その必要性もありません。

価値に立脚すれば、製造業といえども、適応型開発アプローチによる複数回デリバリー（ケーデンス）が意味を持つかもしれません。また、いまや恐竜扱いになっている予測型（ウォーターフォール）によるソフトウェア開発ですら、受注側・発注側両者を含む利害関係者全体の価値につながると積極的にいえる場合があるでしょう。

タスク・マネジメントにとっての意味

最後に、PMBOK第7版が、当サイトVisiWork（ビジワーク）のテーマであり、テレワーク時代を迎えて関心の高い、タスク・マネジメントにもたらす意味について述べたいと思います。

タスク・マネジメントの第1歩はタスクの列挙です。しかしながら、タスク・マネジメントの導入が始まっても、この第1歩の段階で、疑問の声が上がることがあります。例えば、製造業ならば、「変更が多く、先を見通してタスクを登録することなどできない」とか、ソフトウェア開発プロジェクトでは、「アジャイル開発なのでウォーターフォール型のようなタスクの管理は意味がない」などなど。

しかし、ここでPMBOK第7版が説く、バリューデリバリー・システムについて思い起こすべきです。業界や契約形態を問わず、プロジェクトでは、発注者と受注者、両者が協力して、一生懸命価値を創出しようとしているはずです。つまり、バリューデリバリー・システムを動かしているのです。その時に、先を見通す必要がないでしょうか。

人が組織で作業している以上、数週間、数か月の業務は、予測ができているはずです。そしてそれが予想の通りに進むように組織全体で支援すること、予想通りいかなかった場合、それがなぜであるかを検証できるための可視化がなされていることは、収益性や生産性向上のために必須の要件であると思います。
自社には向いていないのではないかというフィーリングだけでタスク・マネジメントの導入をあきらめることはとても残念なことです。自社のバリューデリバリー・システムを見極めて、タスク・マネジメントを活用することが求められています。

以上3回にわたって、PMBOK第7版とそのタスク・マネジメントにとっての意味について書きました。これだけの示唆に富むPMBOK第7版が11月には日本語版で読むことができることが楽しみです。

PMBOK第7版がタスク・マネジメントにもたらす意味とは？（１／３）
PMBOK第7版がタスク・マネジメントにもたらす意味とは？（２／３）
PMBOK第7版がタスク・マネジメントにもたらす意味とは？（３／３）

この記事に関する質問やご意見がありましたら、当サイトお問い合わせページまでお寄せください。

AIサマリー:
この記事では、PMBOK第7版の重要な変更点とそのタスクマネジメントへの影響を解説しています。第7版はプロジェクト・マネジメント標準と知識体系ガイドに分かれ、バリューデリバリー・システムとプロジェクト・マネジメント原則が強調されています。また、従来の知識エリアがパフォーマンス・ドメインに置き換えられ、プロジェクトの価値創出に焦点を当てています。

PMBOK第7版は、以下の２編から構成されています。

• プロジェクト・マネジメント標準（STANDARD FOR PROJECT MANAGEMENT）
• プロジェクト・マネジメント知識体系ガイド（A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE）

プロジェクト・マネジメント標準

プロジェクト・マネジメント標準は、プロジェクトがその中で運営される枠組みとしてのシステムを記述するものであると説明されています。
第6版以前にも、このプロジェクト・マネジメント標準は独立した扱いになっていましたが、その内容は、PMBOKの本編とも言えるプロジェクト・マネジメント知識体系ガイドのサマリーのような記述内容となっていました。
それに対して、第7版のプロジェクト・マネジメント標準は、かなり趣の異なったものとなっています。その、主な内容は、第2章のバリューデリバリー・システムと第3章のプロジェクト・マネジメント原則です。

第2章　バリューデリバリー・システム

プロセス指向から脱却したPMBOKは、プロジェクトの本来の目的は価値（バリュー）を生み出すことであるとしています。組織内には、ポートフォリオ、プログラム、プロジェクト、製品、オペレーションなど、様々なコンポーネントが存在し、それぞれが個別に、あるいは一緒に用いられることで価値をつくり出します。うまく組み合わせることで、組織戦略に整合したバリューデリバリーのためのシステム（バリューデリバリー・システム）を構成することができます。

このように、PMBOK第6版では、それ以前までの版で主役を務めていた「プロジェクト」が、より大きな枠組みであるバリューデリバリー・システムの中で、他のコンポーネントと同列のものとして相対化されています。この章では、そのシステムの具体的な姿が例示されています。

では、どうすればPMBOKに依拠したと言える行動が可能となるのか。そのよりどころとなるのが、プロジェクト・マネジメント原則です。

第3章　プロジェクト・マネジメント原則

すでに（１／３）で紹介した序文にもあるように、原則ベースは、プロセスベースと比較して、業務遂行における幅広いパラメータ（裁量の余地）を示し、原則の意図から外れていない限り、多くの選択肢が与えられることになります。
以下、これらのプロジェクト・マネジメント原則を日本語訳で紹介します。（１／３）にも書きましたが、これらの日本語訳はこの記事の筆者によるものです。正式の日本語訳は、今後に発行予定のPMBOK日本語版を参照してください。

プロジェクト・マネジメント原則

1. 不断の努力を重ね、丁寧にふるまい、思いやりあるスチュワードたれ（スチュワードシップ）
2. 協力的なプロジェクトチーム環境を創造せよ（チーム）
3. 利害関係者を効果的に参加させよ（利害関係者）
4. 価値に着目せよ（価値）
5. システム相互作用を認識し、評価し、対応せよ（システム思考）
6. リーダーシップ行動を明らかにせよ（リーダーシップ）
7. コンテクストにあてはめよ（テーラリング）
8. 品質をプロセスと成果物に対してつくり込め（品質）
9. 複雑性のかじ取りをせよ（複雑性）
10. リスク対応を最適化せよ（リスク）
11. 適応力と回復力を取り入れよ（適応力と回復力）
12. 変化によって思い描いた未来を達成せよ（変化）

１のスチュワードとは普段あまり使わない言葉ですが、投資の世界でスチュワードシップと言えば、機関投資家（企業）において資産運用受託者と呼ばれる役割のことです。したがって、１は、プロジェクトにかかわる者は、資金が投入された投資としてのプロジェクトを成功させる義務があると言っているのだと思います。

プロジェクト・マネジメント知識体系ガイド

第6版までにあった、10個の知識エリアは、以下の8個のパフォーマンス・ドメインに置き換わりました。それは、以下の通りです。章名の末尾の「パフォーマンス・ドメイン」は省略します：

• 2.1 プロジェクト・パフォーマンス
• 2.1 利害関係者
• 2.2 チーム
• 2.3 開発アプローチとライフサイクル
• 2.4 計画
• 2.5 プロジェクトワーク
• 2.6 デリバリー
• 2.7 計測
• 2.8 不確実性

当サイトVisiWork（ビジワーク）のテーマであるタスク・マネジメントに最もかかわりが深い章は2.3 開発アプローチとライフサイクルです。これについては、この記事の続編（３／３）で書きます。

ところで、有名なＷＢＳはどこへ行ったのでしょう。ＷＢＳとはWork Breakdown Structure（ワークブレークダウンストラクチャ）のことで、プロジェクトで実施しなければならない作業項目を精密に構造化したものです。第6版までの「プロジェクト・スコープ・マネジメント知識エリア」で主役の感があったWBSは、デリバリー・パフォーマンス・ドメインでの簡単な記述にとどまっています。
また、EVM（Earned Value Management:出来高管理）は、これも従来型のプロジェクト・マネジメントにおける進捗管理の代表的な手法でしたが、これは計測パフォーマンス・ドメインの中で、カンバンなどと主に説明されています。

続く（３／３）では、上記した2.3　開発アプローチとライフサイクル（パフォーマンス・ドメイン）に着目し、タスク・マネジメントにとっての意味を考えます。

PMBOK第7版がタスク・マネジメントにもたらす意味とは？（１／３）
PMBOK第7版がタスク・マネジメントにもたらす意味とは？（２／３）
PMBOK第7版がタスク・マネジメントにもたらす意味とは？（３／３）

この記事に関する質問やご意見がありましたら、当サイトお問い合わせページまでお寄せください。

AIサマリー:
この記事では、PMBOK第7版がタスク・マネジメントにもたらす影響について説明しています。新しいパフォーマンス・ドメインと開発アプローチ、ライフサイクルの重要性が強調され、複合的な計画視点の必要性が述べられています。また、タスク・マネジメントの導入に際し、バリューデリバリー・システムの概念を理解し、業界や契約形態にかかわらず価値創出を目指す重要性が強調されています。

PMBOKとPMBOK第7版

PMBOKとはProject Management Body of Knowledgeを略したものであり、日本語では、「プロジェクト・マネジメント知識体系ガイド」と言います。PMBOKは、プロジェクト・マネジメント協会 (PMI) が発行しているガイドであり、幅広い分野でのマネジメントに適用されるプロジェクト・マネジメントの基盤を提供しています。

この記事の著者（依田）も、コンサルティングや講演など、いろいろな場面で、これを参照して役立ててきました。プロジェクト・マネジメントにかかわりのある読者であれば、一度はこの名称を耳にしたことがあると思います。また、ガイドを購入し、PMIの講座に出席するなどしてPMBOKについて勉強した人も多いのではないでしょうか。

そのPMBOKが、今年大きく改訂されて第7版となりました。
第7版について調べてみると、これが従来のレベルとはことなる大きな改定であり、当VisiWorkサイトのテーマであるタスク・マネジメントの考え方にも影響があり、その活用を考える上でも大いに参考になると考え、その紹介を3部の記事に分けて書いてみることにしました。

なお、この第7版の状況ですが、PMI日本支部のホームページの2021年07月14日の記事は、米国PMIでは8月1日にリリース、日本語版の書籍リリースは2021年11月と発表しています。
（なお、この3部構成の記事では、PMBOK第7版に記載されている英語の用語を著者が日本語訳しています。正式の日本語訳については、正式日本語版を参照していただきたいと思います）

第7版の変更は大きい

第7版を調べてみてわかったのは、その変化が単に変更箇所が多いというものではなく、まずは大きく構造的に変化しているということです。
ひとつ前の版である第6版は10個の知識エリアと５個のプロジェクトマネジメント・プロセス群、それぞれを縦軸と横軸とする枠組みによって構成されています。その縦軸と横軸は以下の通りです。また、この枠組みは、第6版以前の版においても大きく異なるものではありません：

縦軸

• プロジェクト統合マネジメント
• プロジェクト・スコープ・マネジメント
• プロジェクト・スケジュール・マネジメント
• プロジェクト・コスト・マネジメント
• プロジェクト・品質・マネジメント
• プロジェクト・資源・マネジメント
• プロジェクト・コミュニケーション・マネジメント
• プロジェクト・リスク・マネジメント
• プロジェクト・調達・マネジメント
• プロジェクト・ステークホルダー・マネジメント

横軸

• 立ち上げプロセス群
• 計画プロセス群
• 実行プロセス群
• 監視・コントロール・プロセス群
• 終結プロセス群

この枠組みに、具体的なプロジェクト・マネジメントのためのさまざまな具体的プロセスが配置されて、PMBOK体系が構成されています。
では、このような形で、第7版を概観することができるかというとそれはもはやできません。なぜなら根本的に枠組み自体が変化しているからです。これについては後述します。
では、この構造的変化をもたらした根本的な考え方の変化とは何かというと、それはプロセス指向から、価値指向・システム指向（思考）への転換であると言えます。
その変化の経緯を知るために、序文（Preface）を見てみましょう。以下では、その一部を簡略に引用します：

• PMBOKの改訂から改訂の間に、時代は大きく変わった
  • 組織
  • 技術
  • 従業員

• そんな中でも、変わらず基本的な考え方は残り、総合的な思考は全体を理解するために役立ち、組織が、プロジェクトを固有の結果や成果を実現するための手段と考えていることに変わりはない

• PMIは幅広いステークホルダーとかかわりを持ち、そこからのフィードバックやインプットとして４つのキーポイントが浮かび上がった。
  • PMBOKの信頼性と妥当性を維持する
  • 新しい内容を詰め込むのではなく、PMBOKガイドの読みやすさと使いやすさを改善する
  • ステークホルダーが持つ情報と内容についてのニーズを理解し、実用的な使い道をサポートする精査された補足的内容を提供する
  • これまでの版の構造と内容には一部のステークホルダーにとって継続的な価値があることを認識し、その価値を否定することなく、すべての変化がその価値を強化するようにする

これらのキーポイントの中にPMBOKのある意味で謙虚な反省を筆者は感じます。PMBOKは、冒頭で書いたように、プロジェクト・マネジメントに必要な知識や概念をバランス良く与えてくれる一方で、ここまでやるのかと言いたくなるような冗長性が感じられたのは筆者だけではないでしょう。おそらくPMIによるステークホルダーへの調査・聞き取りでは、かなり辛辣な意見も出たのではないかと想像します。

しかし、それらを改善の手がかりに、今回の第7版のような大幅な変化を成し遂げるPMIのパワーに敬服する思いです。
序文では、このあとに、これまでのPMBOKの主要な改訂が3回あったことが説明されています。３回とは、1996年、2004年（第3版）、2017年（第6版）です。特筆しておきたいのは、このうちの2017年の第6版の改訂です。この版で、始めて「アジャイル」に関する記述が本編に取り入れられました。アジャイル開発や適用型開発に関して拡張が行われたのです。

筆者は、当時この第6版を入手して、PMBOKの中に「アジャイル」が登場したのに気づき、時代の変化を感じたものですが、一方で、PMBOKに今後どうやってアジャイルを取り込むのだろうと考えこんでしまった記憶があります。おそらく第6版あたりで、PMBOKの本質的変化がさけられなくなり、今回の第7版につながったのでしょう。

序文では、主要な変更点の説明が続きます：

• プロセスベースの標準は、有効であるが、プロジェクト・マネジメントはかつてないほど急速に変化しているため、これまでのプロセスベースの方向性をもはや維持できなくなった。
• このままでは、完全な価値提供（バリューデリバリー）の状況を反映できない。
• つまり、完全なバリューデリバリーへの道筋を取り込むことができない。そのために、主要な変化が起きたのである。

主要な変化の一つは、プロジェクト・マネジメントの原則（Principle）に関するステートメント（声明）を選び出し、それら一群の原則ステートメントがプロジェクト管理全体に適用されるという考え方を採用したことです。こうすることで、プロジェクト・チームには業務遂行における幅広いパラメータ（裁量の余地）が示されることになり、また、原則の意図から外れていない限り、多くの選択肢が与えられることになります。

もう一つの変化は、プロジェクト・マネジメントを、価値を実現するためのより大きなシステムの一部であるとみなすということです。こうすることで、プロジェクト自体に着目するだけでなく、組織が全体として持つ様々な要素や、その環境をも視野に入れ、必要に応じてそれらを改善するといったことも可能になります。
PMBOK第7版は、以下の２編から構成されています。

1. プロジェクト・マネジメント標準（STANDARD FOR PROJECT MANAGEMENT）
2. プロジェクト・マネジメント知識体系ガイド（A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE）です。

続く、（２／３）では、これら２編の章立てを見て、PMBOKの全容を確認してみましょう。

PMBOK第7版がタスク・マネジメントにもたらす意味とは？（１／３）
PMBOK第7版がタスク・マネジメントにもたらす意味とは？（２／３）
PMBOK第7版がタスク・マネジメントにもたらす意味とは？（３／３）

この記事に関する質問やご意見がありましたら、当サイトお問い合わせページまでお寄せください。

AIサマリー:
この記事では、テレワークの生産性を向上させるためのプロジェクト管理の知恵について解説しています。テレワークの長期化は避けられないとし、生産性を向上させるためには、監視よりも仕事の可視化が重要と述べています。また、REDMINEのようなプロジェクト管理ツールを活用してタスクやタイムマネジメントを効果的に行うことで、テレワークの課題を解決する方法を紹介しています。

避けられないテレワーク長期化

コロナウイルスの感染が爆発的に拡大しています。感染の場所は、飲食の場から家庭と職場に移ったと言われていますが、職場については、テレワークこそ効果抜群の感染防止対策です。
ワクチン接種は課題を抱えながらも着実に進展することでしょう。しかし、変異株や新種のウィルスとの戦いは今後も続くと予想され、この効果抜群の感染防止対策であるテレワークの長期化は避けられないものと思われます。

テレワーク長期化は避けるべきものなのか？

テレワークの長期は避けられないと否定的な表現をしました。しかし、テレワークの長期化それ自身は本当に避けなくてはいけないものなのでしょうか。
私（依田）は、全くそう思っておらず、2021年2月12日の日本経済新聞社のシンポジウム「トップが主導する企業のテレワーク戦略 」の講演、「プロジェクト管理の知恵でテレワークの第2ステージへ」の冒頭でもテレワークの効果について述べました。

この図のように、テレワークは、個人、企業、そして社会全体に恩恵をもたらすものであり、コロナ禍の状況にかかわらず、たとえそれが終息しようと、引き続き推進されるべきものであると考えています。もちろんテレワークに課題があるならそれらは解消される必要があります。しかし、DX（デジタルトランスフォーメーション）等の進展に伴って、技術的課題は順次解決され、テレワークはしだいに社会にとって受け入れやすいものとなることは間違いないでしょう。

コロナウイルス対策とは関係なく、テレワークという働き方を人々が歓迎し、その表れとしての人の動きが始まっていることは、最近の新聞記事などからうかがい知ることができます。

• 【書籍・記事ノート】 シェアオフィスを本社に　（日経新聞朝刊 スタートアップ面：2021/8/4）
• 【書籍・記事ノート】 「テレワーク移住」拡大　（日経新聞朝刊 総合2面：2021/8/5）
• ツイッター、在宅勤務を「永遠に」許可へ　新型ウィルス対策で効果実感（BBC News Japan: 2020/5/13）

しかしながらテレワークは、働き方として歓迎されるとしても、その生産性が課題である、と指摘されることがあります。生産性がテレワーク導入前と比較して低下してしまうのならば、「通勤が辛い、もっと時間的な余裕が欲しい」と考えていた個人は歓迎したとしても、収益が求められる企業や組織には歓迎されないことでしょう。

「テレワークの長期化は避けるべき」とか、「コロナが解決したら一刻も早くオフィス再開！」とされる原因は、そこにありそうです。では、どうすればよいでしょうか。

テレワーク環境下での生産性

前述の講演では、以下のスライドを使って、人の監視から仕事の可視化への移行が大切であると述べました。

現在のテレワークのスタイルは、人を監視することによって、かえって仕事に没頭することを妨げているのではないかと考えたのです。監視することばかりでなく、力不足が否めない家庭内のデジタル環境で、デジタル技術の多用を強制されるという矛盾した状況もテレワーク環境下において仕事への没頭を妨げているのかもしれません。最近は、仕事の生産性を高めるために、あえてデジタル技術を遮断すべきという意見も出始めています。

要するに、あふれるほどのデジタルツールで見かけのコミュニケーションを増やすことは生産性につながらないのだと思います。今必要なことは、より少ないコミュニケーションで仕事が円滑に進むようにすることではないでしょうか。

「より少ないコミュニケーション」は、「より少ない情報」を意味するわけではありません。むしろその逆で、人が仕事に没頭できるためには、必要な情報は会話的なコミュニケーション以外の手段で豊富に与えられなければなりません。

そのためには、目標、前提、ルール、プロセスをわかりやすくすること、また、いわゆるドキュメント化やモデル化という少し面倒な努力も必要です。この点において、テレワーク環境の課題とプロジェクト管理の目的とが結びつくのです。

プロジェクト管理の知恵とは、目標とそこに至るプロセスのモデル化に価値を見出すことにある

私たちはなぜプロジェクトと言う概念を用いるのでしょうか。
少し古い本ですが、「エンジニアリングPM用語集（重化学工業通信社、1986年）」（第2章プロジェクト・マネジメントの基本概念P24）によれば 「プロジェクトを組んで問題解決をはかることは、

1. 多くの人間や組織が関係し、その相互の密接かつ同時的な共同作業が必要な場合や、
2. 計画に多くの不確定要素があり、計画及び組織の変更の可能性がある場合、あるいは
3. 期間に制約があり、総力を結集した集中的努力が必要な場合などには、特に効果的である」とあります。

しばしば、プロジェクト管理は計画主導の考え方であり、変更の可能性がある場合は、アジャイルなアプローチが必要などと言われますが、上記のように、プロジェクト管理の必要性の理由の中には、変更への対応という目的が初めから含まれいます。

上記の３つの「プロジェクトを組むことの効果」の一つ一つは、まさに通常のテレワーク環境に当てはまるものと言えないでしょうか。

テレワーク環境での生産性が本当に問題になっているのであれば、その理由は対象の業務がこのうちのいずれかのケースがあてはまっているからであると思います。

すくなくとも、テレワークの課題が、家庭のWi-Fi設備の貧弱さや、オンライン会議ソフトうまく使えないと行ったことから生じているのか、 それとも、上記の箇条書きのようなケースを、効果的に支援するツールがないことから生じる課題なのか、を明確に区別しなければ、テレワークの生産性向上は果たせないと考えています。

上記のような効果を持つプロジェクト管理には計画ツールがいくつか存在しますが、例としてそのうちの一つ、WBS（Work Breakdown Structure：ワークブレークダウンストラクチャ）について説明します。

下図は、自動車製造における、自動車のWBSと、自動車開発組織の構造を表しています。プロジェクト管理では、これらをそれぞれ明瞭に定義するのです。そうすることで、人が行う仕事に対して、各部門および自動車の個別の部位との関係が明確に示されることになります。

また、それらの仕事は、その前後関係が、スケジュール・ネットワークの形で定義されます。REDMINEのようなプロジェクト管理ソフトウェアを利用すると、このスケジュール・ネットワークはガントチャートとして示されることになります。

REDMINEのユースケース：CTTM（全社適用型タスク＆タイムマネジメント）

では、REDMINEのようなプロジェクト管理システムを提供すればテレワークの課題は解決するかというと、それだけでは課題解決策として十分ではありません。

テレワーク環境下での課題を解決するために、REDMINEのようなプロジェクト管理ソフトウェアをどのように使うか、つまりユースケースが重要になります。そのようなユースケースの例として、VisiWorkサービスではCTTM（Corporate Task＆Time Management：全社適用型タスク＆タイムマネジメント）を紹介しています。次は、ぜひこちらの記事もお読みいただきたいと思います。

この記事に関する質問やご意見がありましたら、当サイトお問い合わせページまでお寄せください。