モダンPMへの誘い 〜 アクティビティの期間とは、そもそも何か？
- スマートなプロジェクト組織になるためには
スマートな（賢い）人とは、自分の現状を把握し、過去から学び、未来を予測・構想でき、そして事実とデータに基づいて判断する人のことである。それゆえスマートな組織とは、(1)自らの過去のデータと知見を蓄積し、(2)現状をモニタリングし、(3)ビジョンと予測に基づく計画を立て、(4)客観的事実とデータから決断を下せるような組織、をいう。これは会社組織に限らず、官庁とか大学とかサークルの集団などでも同じである。
現在・過去・未来、そしてデータ。これが「賢さ」の4条件であるならば、プロジェクト遂行の組織も、きちんと過去データを蓄積できるようになっている必要がある。過去のプロジェクトはどんなスコープだったのか、どれくらいのリソースと工数を投入し、スケジュールはどうだったのか。当初の計画とどれくらい違ったのか。追加変更はどうだったのか。こうしたことが記録され、データ化され、できればデータベース化されているのが、賢いプロジェクト組織の姿であるはずだ。
プロジェクト組織ではたいてい、ガントチャートによるスケジュールを作る。最低限、これらが記録され保存され、できればインデックス化されていなけれれば、スケジュールの分析や比較などおぼつかない。ウチじゃ、ちゃんとしているって？ たいへん結構です。
そして、そのガントチャートは、当然ながら最初の計画時点のものだけではなく、完了時点での実績が記入されていなければならない。それではじめて、プロジェクトを構成する主要なアクティビティの所用期間と、スコープや作業ボリューム、リソース投入量などといった要素の関係が比較できるようになるからだ。
- アクティビティが「終わった」とは、いつ言えるのか
ところが、この比較分析が、じつは簡単ではないことが多い。なぜか。それは「アクティビティの完了」のタイミングが、しばしば曖昧で、人によりブレるからだ。主要なプロダクトが出た時点ですっぱり完了、となっているものもあれば、延々とクローズされずに下流側の問題解決まで引っ張られるものもある、といった調子である。
どうしてこうなるのか。理由は簡単だ。「アクティビティの完了」を判定する条件、すなわち完了条件（英語で Exit conditionとも呼ぶ）が、組織内で明確になっていないからだ。
プロジェクトのアクティビティは基本的に、なんらかの成果物＝アウトプットを生み出すための活動だ。それは設計書のような中間成果物かもしれないし、納品する最終成果物の一部かもしれない。ときには、具体的な成果物は定まらないが、ある種の状態になることで完了する場合もある。たとえば、サーバのインフラに、パッケージソフトをインストールして完了とか、逆にサーバを完全に初期化しクローズして完了、とか。
そして、その完了状態は、重要なものであれば顧客・主要ステークホルダや、プロジェクト・スポンサーなどの承認を得る必要がある場合もある。もちろん、プロマネやチーム内での承認で済む場合も多い。
- アクティビティがだらだらと続く状態を避ける
もしもアクティビティが完了したら、ふつうはその仕事に割り当てていたリソース（主に人だが、占有する道具や場所も含む）をリリースして、別の仕事にあてられるようになる。これがあるから、組織内での完了条件の明確化が大事なのである。
そして、アクティビティにまだ細かなフォローすべき作業が残っている場合は、残務リスト（「パンチ・リスト」）への移行を行う。すなわち、アクティビティ自体は完了し、残務をリストに登録して個別に追いかけるようにするのである。パンチ・リストへの移行が明確になされないために、アクティビティ自体をオープンな状態のまま、いつまでもだらだらと続けている組織も少なくない。
したがって、成果物が（たとえば）スコープを数量的に95%カバーし終わったら、とか、パンチ・リストの残件がBランク以下のものだけである、とか、いった基準を決めておくことが望ましい。
もう一つ、アクティビティがだらだら続く理由は、会計的な入出金のアカウントのクローズに関わるものだ。外部リソースを使ったりする場合、追加請求交渉が終わらないとクローズできない、と会計部門から言われたりする。これはしかし、いささか本末転倒で、コスト管理はプロジェクト・マネジメントのためにあるので、その逆ではない。
- アクティビティはいつ「始まった」のか
そして、アクティビティの始まりについても、同様に開始条件を明確にすることが望ましい。ふつう、成果物をアウトプットするためには何らかのインプットが必要である。それはマテリアルとして部品資材かもしれないし、何らかの設計情報などかもしれない。
そして、リソース（働く人と場所・機械設備・ツール類）が割り当てられないと、仕事ができない。とくに、働く人びとについては、同種の技術・技能をもったメンバー（あるいは複数の異なる機能を担う人たちからなるチームのような、リソースの「セット」）を割り当てる必要がある。
これらがそろってはじめて、アクティビティは着手可能になるのである。そしてアクティビティの期間の長さを論じる際には、「着手可能」から「完了」までを比較しなければ、意味が無い。
図は、ずっと以前の記事「仕事の最小単位－－アクティビティの構造を学ぶ」 にあげた図を少しだけ敷衍したものだ。アクティビティとは成果物をアウトプットするための活動で、そのためのインプットがあり、実行するためのリソースが必要である。そしてマネジメントからの指示と報告という「ハンドル」のようなものが付随する。
言いかえると、ガントチャートにおける「アクティビティ」とは、次の3条件を満たさなければならない：
(1)アウトプットとしての成果物があること。あるいは、何らかの具体的『状態』が規定されていること。つまりアクティビティの終わりを判定できる「完了条件」が明確であること(2)インプットとしての材料や情報があること。あるいは着手できる『状態』があること。つまり、アクティビティの着手可能を判定できる「着手条件」があること(3)同種のリソース（あるいは複数の異なる機能を担う人たちからなるグループのような、リソースの「セット」）をアサインする必要があること
こうした共通理解があって、はじめてプロジェクトの過去から学べる「賢い」組織が生まれるのである。
＜関連エントリ＞
「仕事の最小単位－－アクティビティの構造を学ぶ」 https://mgt-technology.info/13992804/ (2011-01-16)
「モダンPMへの誘い 〜 一本道プロジェクトとガントチャートの基本を考える」 https://mgt-technology.info/33686836/ (2025-06-18)