WBS作成のための活動をご紹介し、カレーの作り方をテーマにWBSの作成を実践しました。
PMBOKでは、WBSを作成するために以下の活動を実施し、スケジュールを立て進捗を管理できるレベルまで分解します。
分解したスケジュールを立て進捗を管理できるレベルである最下層の構成要素をワークパッケージと言います。
PMBOKはプロジェクト管理に関する知見を体系的にまとめたガイドブックであり、プロジェクトマネジメントの世界標準となります。PMBOKには、プロジェクト管理に必要なプロセスが定義されており、その中ではプロジェクト管理の目的を「プロセス管理によるQCDの達成」と定義しています。
プロジェクトで達成すべきゴールは、Quality（品質）、Cost（コスト）、Delivery（納期）の3つです。これまでのプロジェクト管理では、QCDの管理にのみ焦点が当てられていましたが、QCDの管理のみではプロセスを管理することができず、結果的にQCDも満足できません。このため、PMBOKではプロジェクト管理のプロセスを10の知識エリアと5つのプロセス群に体系立てまとめられています。
プロジェクトマネジメントに求められる10個の知識を指し、「品質」、「コスト」、「納期」に加え、「スコープ」、「資源」、「コミュニケーション」、「リスク」、「調達」、「ステークホルダー」、さらにすべてを取りまとめる「統合管理」で構成されています。
今回は、10の知識エリアの中でスコープに関する知識をまとめているプロジェクト・スケジュール・マネジメントに焦点を当て、関連記事で作成しているWBSを元にスケジュール作成を行っていきます。
プロジェクトで定義したスコープを元に計画するものの一つがスケジュールです。プロジェクト・スケジュール・マネジメントの目的は、プロジェクトのスコープに定義されたアウトプットを、いつ、どのように作成するかという、プロジェクト全体のスケジュールを作成し、管理をすることです。 期限の決められているプロジェクトに対して求められる成果を達成するために必要な活動です。
プロジェクトの立ち上げの際に定めたプロジェクト憲章やプロジェクトマネジメント計画書等を元にスケジュール・マネジメント計画書を作成し、スケジュールを管理するプロセスを定義します。そのスケジュール・マネジメント計画書に従って、プロジェクトを期間内に確実に完了させるスケジュールを作成します。
スケジュールを作成するために、アクティビティを定義します。PMBOKでは、アクティビティとは、「プロジェクトの過程において実施されるべくスケジュールに組み込まれた個々の作業のこと」と定義されています。WBSで要素分解したワークパッケージとアクティビティの違いについては、以下のように考えると区別しやすいと思います。
PMBOKでは、スケジュールを作成するためには、次のプロセスが必要と定義されています。
それぞれのプロセスについてもう少し詳しく見ていきましょう。
まず、ワークパッケージを完了するために遂行すべき具体的な作業をリスト化します。WBSで要素分解したワークパッケージを元に完了するために必要な作業をまとめアクティビティ・リストを作成します。アクティビティ・リストには、ワークパッケージに紐づくアクティビティの名前の他に、作業内容、アクティビティの前後関係、期間等の情報もまとめます。
アクティビティ・リストを作成したら、アクティビティ間の順序付けを行います。アクティビティの順序を設定する際のテクニックとしては、アロー・ダイアグラム法やGERT、プレシデンス・ダイアグラム法がありますが、今回はプレシデンス・ダイアグラム法についてもう少し詳しくご紹介します。
プレシデンス・ダイアグラム法（Precedence Diagramming Method）とは、プロジェクトのアクティビティの依存関係に注目し、論理的順序関係を図式化していく技法です。アクティビティをノードと呼ばれる四角い枠で表現し、ノード間を線でつないで作業順序を表すことから、Activity-on-Node（AON）とも呼ばれます。
PMBOKでは「スケジュール・モデルを構築するための技法のひとつで、アクティビティをノードで表記したもの。」と定義されています。
プレシデンス・ダイアグラム法では、アクティビティ間の関係を以下の4種類の依存関係を用いて表現します。カッコの中は略称ですが、Fは"Finish（終了）"を、Sは"Start（開始）"の頭文字です。意味が分かっていると覚えやすいと思います。
前のアクティビティが終了したら、後のアクティビティを開始する関係です。最も一般的な依存関係となります。
前のアクティビティが終了したら、後のアクティビティを終了してよい関係です。例えば、「記事のチェック」というアクティビティは、「記事の作成」より先に終わることはありません。記事の作成と並行してチェックが始まり、記事の作成が完成したのちにチェックも完了となります。このように前のアクティビティが終わることによって、終了するアクティビティの関係です。
前のアクティビティが開始したら、後のアクティビティも開始してよい関係です。
前のアクティビティが開始したら、後のアクティビティを終了してよい関係です。例えば、新しいウェブサイトのサービス開始まで、現在のウェブサイトのメンテナンスを続けなければならないようなケースが該当します。
アクティビティの前後関係の定義に加えて考えなくてはならないのが、前のアクティビティと後のアクティビティの間の時間を表す「リード」と「ラグ」です。
「リード」は、後のアクティビティの開始を前倒しできる時間を表します。前のアクティビティと後のアクティビティを重ねられる（並行して作業できる）期間です。
「ラグ」は後のアクティビティの開始を遅らせる時間を表します。前のアクティビティが終わってから後のアクティビティを始めるまでに待たなくてはならない期間です。
このようにプレジデンス・ダイアグラム法やリードとラグといった技法を用いてアクティビティ間の順序を設定します。
アクティビティの順序が決まったら、今度はそのアクティビティの所要時間を見積ります。PMBOKでは、「資源カレンダー」や「アクティビティ資源の見積り」といった資源や調達のマネジメント・プロセスのアウトプットを用いて、アクティビティに必要な資源の種類と量を特定し、その資源をもってそれぞれのアクティビティを完了するのに必要な作業期間を見積ります。プロジェクトにアサインできる人、設備が、いつ、どのくらいの期間アサインできるかを特定して、アクティビティにかかる時間を見積るということです。
作業を見積る際に使われる方法が、類推見積り、パラメトリック見積り、三点見積り、ボトムアップ見積りといった技法になります。
過去の類似開発プロジェクトを参考に見積りします。過去の類似プロジェクトでの開発期間や予算、資源を参考にする経験に基づく算出方法です。他の見積り方法に比べて短時間、かつ安価に見積もることができるのがメリットですが、過去の情報の記録の精度や当時との環境の差等により、正確さには注意が必要です。
パラメトリック見積りは、過去のデータをベースとして、さらに変数を使ってプロジェクトやアクティビティのコストや予算、期間を見積る技法です。
例えば、おにぎりを10個作成する時間を見積る場合を考えてみましょう。過去に10個を30分で作成したという実績があった場合、１個につき必要とする時間は3分となります。実績を元にしたおにぎりにかかる時間は、「おにぎりの所要時間 = 3分 × おにぎりの個数」で求められます。この計算式にあてはめると、おにぎりを100個作るためには300分（5時間）かかると計算できます。
このように、過去のデータを使って式を組み立て、期間やコストを見積るのがパラメトリック見積りです。過去の類似開発プロジェクトがない場合でも、過去の同アクティビティのデータから見積りができることがメリットです。
三点見積りは、プロジェクトのコストや期間を楽観値、最可能値、悲観値の三つの視点から見積る技法です。三点見積りは、三角分布とベータ分布で算出方法が違います。
三角分布：（楽観値＋悲観値＋最頻値）÷3
ベータ分布：（楽観値＋悲観値＋最頻値×4）÷6
三つの視点から見積もるため、正確性が高まることがメリットです。一方で、楽観値、最可能値、悲観値の差があまりない場合は、一点で見積る他の技法と差は出ず、手間だけがかかることになります。
ボトムアップ見積りは、WBSに含まれている各アクティビティの期間やコストを見積り、それを集計して全体の期間やコストを見積ります。ひとつひとつのアクティビティを見積もった結果を集計するため、正確の高さがメリットとなりますが、時間がかかることがデメリットです。
このようにご紹介した見積り技法を用いて、各アクティビティの所要期間を見積ります。アクティビティを定義し、順序、所要期間の見積りができたら、いよいよスケジュールの作成に入りますが、今回は、ここまでのスケジュールを作成する準備のプロセスを実践してみたいと思います。
それではここまでご紹介したスケジュールの作成を行うための準備のプロセスである「1.アクティビティの定義」「2.アクティビティの順序設定」「3.アクティビティの所要時間の見積り」を実際にやってみましょう。テーマは「カレーを作る」です。関連記事で作成しているWBSをインプットとしてアクティビティを定義していきます。
WBSをブレークダウンした最下位レベルの成果物を生み出す作業項目であるワークパッケージを、ワークパッケージを完了するために必要な作業であるアクティビティに分解していきます。例えば、「1.2.1 肉の準備」であれば、「水分をふき取る」「筋を切る」「塩を振る」「胡椒を振る」といったアクティビティに分解できそうです。
同様に他のワークパッケージもアクティビティに分解していきます。分解の際に、その時点で詳細化するのが難しい要素は、その時点で分解できるまでで留めておきます。WBSの要素分解の時にもご紹介したローリング・ウェーブ計画法、段階的詳細化の考え方です。今回は、調理前の「材料準備」「下ごしらえ」に注力したいと思います。
ワークパッケージを分解し、アクティビティが定義出来たら、アクティビティ識別子やアクティビティ記述、先行アクティビティといったアクティビティ属性も記述していきます。
iQUAVISは、ワークシートというデータの抽出条件を設定し、その条件に従ってデータに関連する属性を一覧表にする機能があります。ロジックツリー形式では複数のアクティビティ属性を記載できるスペースが限られ、アクティビティが増えてくるとロジックツリーが縦長になり一覧性にも難が出てくるため、ワークシート機能を使ってみます。ワークシートを使ってアクティビティ属性をまとめます。アクティビティ名のほか、アクティビティ識別子やアクティビティ記述といったアクティビティ属性を埋めていきます。
アクティビティ属性が記述出来たら、今度はアクティビティの順序設定を行っていきます。順番に進めていくアクティビティなのか、並行して進められるアクティビティなのか、前のアクティビティと後ろのアクティビティの関係を定義していきます。
例えば、「1.1.1 食材を買う」のアクティビティには、「豚肉を買う」「人参を買う」「玉ねぎを買う」「卵を買う」「ルーを買う」がありますが、アクティビティ記述を参考にすると同じスーパーで買うことになっています。そうなると買い物かごに入れる順番はあるにせよ、会計は最後に一緒に済ませることになるので、アクティビティの終了は一緒です。
このようなケースは、プレシデンス・ダイアグラム法の「終了 - 終了関係（FF）」（iQUAVISでは、「終了以降に終了」）として依存関係を定義します。
同様に他のアクティビティも前のアクティビティと後ろのアクティビティの関係を考えながら依存関係を定義します。依存関係を定義する際に加えて考えなくてはならないのが、前のアクティビティと後のアクティビティの間の時間を表す「リード」と「ラグ」です。前のタスクと後のタスクを重ねられるのか、前のタスクが終わってから後のタスクを始めるまでに待たなくてはならないのかを検討します。
例えば、「1.2.1 肉の準備」のアクティビティである「水分をふき取る」は、「1.1.1 食材を買う」のアクティビティである、「豚肉を買う」が終了したのちに開始することができる「終了 - 開始関係（FS）」（iQUAVISでは、「終了後に開始」）にあたりますが、豚肉を買ったらすぐにその場で下ごしらえができるわけではなく、調理場に移動が必要です。そういった前のタスクが終わってから後のタスクを始めるまでに待たなくてはならない期間は、ラグとして時間を設定します。
逆に前のタスクと後のタスクを重ねられる、アクティビティとして重複してよい場合は、リードとして期間を設定しましょう。iQUAVISでは、その感覚をプラス、マイナスで期間を設定しますが、負のリードは、正のラグと同じ意味になります。
アクティビティ間の依存関係、リードとラグを設定出来たら、アクティビティの所要時間を見積ります。所要時間を決める際には、類推見積り、パラメトリック見積り、三点見積り、ボトムアップ見積りといった技法を用いて見積もりますが、今回は類推見積で過去のカレー作成のプロジェクトの実績を元に期間を算出することとします。
iQUAVISでは検索条件を設定して、その条件に合ったプロジェクトを検索することができますので、同種、同規模のカレー作りプロジェクトを検索してみます。検索結果を見ると「カレー作り_2022」プロジェクトが参考にできそうなので、このプロジェクトを参考にして期間を設定することにします。
ワークシートで作成したアクティビティ・リストに期間の項目を追加して一覧表示できるようにしました。実際のカレー作りの時間軸とは異なりますが、ご容赦ください。
所要期間の見積りが出来たらスケジュールの作成準備が完了となります。このあとは、実際のカレンダーに照らし合わせてスケジュールを作成します。スケジュールの作成の際には、クリティカル・パス法などの分析技法や資源（リソース）をコントロールして日程を決めていきます。
ここまで弊社のiQUAVISを用いて作業を行いました。iQUAVISはISIDが開発した「開発の見える化」をコンセプトとしたツールです。根拠のある計画立案と先手のマネジメントを実現するプロジェクト管理機能の「業務の見える化」、検討経緯・影響連鎖を明らかにする「技術の見える化」、ヌケモレのない技術課題抽出と意思決定を支援する「判断の見える化」、3つの見える化によって「開発の見える化」を実現します。
本サイトにiQUAVISの紹介ページや操作体験のワークショップ等をご用意しておりますので、ぜひご覧ください。
入社以来長らくPLM「Teamcenter」を担当し、お客様のPLM導入による設計・製造データ管理の最適化を支援。現在はPLM担当時の経験を活かし、iQUAVISを用いたお客様のプロジェクト管理、製品の成り立ちの見える化、不具合未然防止活動を支援。2019年にPMPを取得。
