MS Planner and Project Plan3を試した。これはMicrosoft Projectとして長年知られていたものの同等物。
作りたかったのはPMBOKでいうところのWBS、アクティビティリスト、そしてプロジェクトスケジュールネットワーク図。
Project Planでは全て登録する内容が"Task"というカラム名になっているところは少し気になるものの、そこを無視するとすれば、WBSでいうWork（＝成果物）は整理が可能なように思う。
WBSはあくまでWork（＝公式の翻訳としては作業＝そしてこれはいわゆる一般用語としての「作業」の結果の成果物）を管理するもので、その最下層にあるワークパッケージを完成させるために必要なアクティビティは別途アクティビティリストにした上でそこで作業期間や順序を規定する、というのが理屈という整理はできた。
が、それを正面に受け止めて、WBSとは別にアクティビティリストを作り、どの成果物に対するアクティビティなのかをうまくリンクさせながら管理する、というのは現実としてイメージが沸きづらいように思った。
ということで他の事例を書籍やネットでいくつか見てみたものの、結局WBSの最下層（ワークパッケージ）をアクティビティリストに分解するという関係性のためか、そのまま最下層の次の層（＝見かけ上最下層ではなくなるということ）にアクティビティを記載するというのがどうも現実的なのだなと改めて理解した。
となると、Project PlanのPlanとしてまずはWBSを書いてそこにアクティビティを足すという流れ、そこからアクティビティに対して想定期間と依存関係を追加することでネットワーク図（ガントチャート）が表現できるという流れで進めると一旦は良さそうということでわかった。
ここで改めて、そもそもどのようにWBSを作るべきなのか確認して、今更長年の自分のWBSを作る時に持っていた違和感に対する回答を見つけた。
>同一の分割原則をWBSの全層にわたって適用することに何の問題もない。しかし、実務に携わる者の間では、同じWBSに2つないし3つの分割手法を同時に適用する混合手法がより実務的だという意見が多い。（中略）
>WBSを構成する3つの手法のうちのどれが自分のプロジェクトに適しているだろうか。この疑問を解決する前に、WBS分割は科学的行為でないということを知っておくべきである。この作業は企業文化に強く影響され、「仕事をどう進めるか」を決定するトップ・マネジャーの意向に左右される。 [^1]
いつも同じ分割原則で準備をしていたものの、そうするとどうしてもやりづらさというか、使い勝手の悪さに直面していたのだけど、なんだ、いや、そうだったのかと、今更これがいわゆる「実学」なのだと思い出させられた。
なぜわざわざProject Planを契約（2025年10月現在、月払い契約で月6000円弱！）してまで仕事に役立てようとしているかといえば、
・WBSをうまく作り、アクティビティを起こし、それをネットワーク図表現することで関係者と共通の理解で仕事を進めて、課題外在性の負荷を減らしたい
・クリティカルパスを明確にして、遅延の影響を明確にしたい
・ベースラインを設定して、元に対してどのような変更を加える結果となっているのか共通の理解を得たい
という気持ちがあったからだった。
そして自分はいつも上であげたようなWBS作成時の分割の軸に対する違和感を抱えていて、きっと自分のやり方に問題があるので、自己流ではまずい。世の中で最も知られているツールから作法を習得しよう、という魂胆があってのことだった。
が、どうもツールの問題というよりはそもそもどのようにWBSを作るかの理解に対する問題であって、実際にProject Planを使ってみても、代替ツール[^2]が見える環境下でこのライセンス費用を正当化するのはちょっと難しいのではないかという印象。
クリティカルパスの問題とベースラインの問題はまだ解決できておらず、そこももう少し使用感を踏まえながら見る必要があるけれど、1つ目の点は自身のスキルレベルの問題だとクリアにできたのは大きな収穫。
満足したので今日はここまで。それでは。
[^1]: ドラガン・ミロセビッチ (2007), プロジェクトマネジメント・ツールボックス, 鹿島出版会, p.140
[^2]: 例えばGoogle SheetのTimeline Viewという機能は正直かなり便利で、うまくやれば十分代替になると思っている