ProjectLibre Desktop · はじめに
サンプル プロジェクトを作成する
プロジェクトの骨組み、リソース、タスク、依存関係、割り当てを順に作成し、最後に計画を評価する、実践的なプロジェクト計画の作成手順です。
この流れに沿って、ProjectLibre の新しいインターフェースの影響を受ける部分だけを書き換えていきます。「ProjectLibre を使ってプロジェクト計画を作成する方法を理解する一番の近道は、これから示すような現実的な例を見ていくことです。この例は単純ですが、プロジェクト管理者が(ProjectLibre を使って)実行可能なプロジェクト計画を立てるときに行う、典型的な手順を段階的に示しています。」この例があなたのプロジェクトにぴったり当てはまることはおそらくないので、この例を手直しするか、自分のプロジェクトにより合うよう独自に組み立て直すとよいでしょう。ただし、基本的な手順はそのまま当てはまるはずです。
ここで扱うサンプル プロジェクトには、比較的少数の前提を置いています。
- ProjectLibre は前節で説明したとおりにインストールと設定が済んでおり、実際に使えるプリンター(または PDF Creator のような疑似プリンターだけでも)に接続されています。
- このサンプル プロジェクト「New Shower」は、6 か月間続くマーケティング施策です。
- プロジェクト管理者を含め、フルタイムの人材リソース 3 名が New Shower に割り当てられています。
- New Shower に予算の制約はありません。組織はこの取り組みを全面的に後押ししていますが、スケジュールは非常に重要であり、6 か月以内に完了させる必要があります。
- 必須の完了日は、開始日から 6 か月以内です。
ステップ 1: プロジェクト計画の骨組みを作成する
最初のステップは、プロジェクトの基本パラメータを決めることです。アナリストは、6 ページから説明したとおりに ProjectLibre でこのステップを始めます。この流れは図 4 と図 5 ですでに見たとおりです。ここでは新しいプロジェクトに「New Shower」という名前を付け、図 5 の上に示した一番上の行に入力します。図 16 のように開始日も入力します。デフォルトで選択されている「フォワード スケジュール」のチェックを外すこともできます。そうすると終了日を選択でき、必要なタスクを入力した後、ProjectLibre が終了日から逆算してスケジュールを組んでくれます。この方法は、「New Shower」のように必須の完了日が決まっていて、それを必ず守らなければならないプロジェクトに向いています。図 16 のようにデフォルトのままチェックを入れておき、必要なタスクを入力して完了日をソフトウェアに計算させるほうが、おそらくやや一般的でしょう。ただし、このサンプルでは必須の完了日を確実に満たすため、「フォワード スケジュール」のチェックを外すことにします。この変更により、このサンプルは元の例と少し異なるものになります。自分なりの学習用サンプルを作る際は、自分の組織の事情を踏まえ、自分のニーズに合う ProjectLibre の機能を使ってください。前提と制約を書き出しておくことは、システムの要件を策定し、磨き上げ、検証していく作業によく似ています。プロジェクトに名前を付けるダイアログ ボックスのメモ欄は、こうした制約や前提の一部を書き留めておくのにちょうどよい場所です。

「OK」をクリックすると、図 6 で示したものと同じ空白のガント チャートが、新しいプロジェクト名を添えて開きます。
ステップ 2: プロジェクトのリソースを特定する

次のステップは、利用できるリソースを特定し、名前を付けることです。New Shower ではすべてのリソースが人材リソースなので、ProjectLibre 内のナビゲーションについて説明した段落で挙げたいずれかの方法で「リソース」のスプレッドシートに移動すれば、必要な情報をすべて入力できます。このスプレッドシートに移動する一番よい方法は、一番上の行で「リソース」を選び、2 行目の左側にある「リソース」アイコンをクリックすることです。この 2 つの操作で、図 17 のスプレッドシートが表示されます。

「リソース」スプレッドシート(図 17)の左側部分は、そこに保持できる情報のごく一部にすぎません。ほかにどんな情報を保持できるかを見るもう一つの方法は、図 18 のようにこのウィンドウの下のバーを使って右にスクロールすることです。スプレッドシートのこの右側には、列の見出しが示すとおり、単価やカレンダーなどの情報を保持できます。

このスプレッドシートのセルに入力する値は決められた形式に従う必要があり、従っていない場合は図 19 のようなエラー メッセージが入力の不整合を警告します。こうしてこのスプレッドシートは、プロジェクトに使える人材・物的リソース双方について、中心となる情報源になります。

なお、コントロール バーの一番上の行で「ビュー」を選び、2 行目の「リソース」ビューのブロック(「ガント」アイコンのある「タスク」ビューのブロックのすぐ右)にある「リソース」アイコンをクリックしても、リソースのスプレッドシートにたどり着けます。
さらにアナリストは、「リソース」スプレッドシートでリソース名を左クリックし、そのリソース用のダイアログ ボックス(図 20)に入力することでも、個々のリソースの特性を指定できます。場合によっては、こちらの方法のほうが便利です。この入力方法は、スプレッドシートに直接入力するより効率よく、整理しやすいことがあります。見てのとおり、これらの各タブと、メモ用の広いスペースのおかげで、リソースの入力内容をプロジェクトに合わせてさまざまに調整できます。このダイアログ ボックス上部の各タブを順に見て、この代わりの入力方法がプロジェクトにとってなぜ役立つのかを詳しく見ていきましょう。

まず「全般」タブ(図 21)をよく見ると、プロジェクトのリソース データベースに属する各リソースについて、多くの詳細を追加できることがわかります。特定の作業グループ、連絡先情報、資材の説明、さらには(フレックスタイムが必要であれば)個人用の作業カレンダーや、RBS 識別子のような通常の識別子まで指定できます。

「コスト」タブでは、アナリストは任意のリソースについて、有効日ごとの個別の労務単価を細かく設定できます。実際、5 つのサブタブ(A~E)があり、アナリストは 1 人のリソースに対して 5 種類の異なるコスト単価を設定することもできます。また、あるタブの左列にある適切な「有効日」で単価を引き上げるだけで、リソースに「昇給」を与えることもできます。

「リソースの使用可能時間」タブ(図 23)には、リソース データベースを詳しく設定するためのほかのオプションがあります。このタブには、このリソースの利用上限を設定する項目もあります。この上限は通常、このリソースを使用できる時間の最大割合で設定します。
「タスク」サブタブ(図 24)には、リソース データベース内の各担当者について行われたすべての割り当てや担当作業の一覧が表示されます。各列には、リソースごとのタブの各ページで、タスクごとの割り当てに関する詳細(たとえば開始日と終了日)が表示されます。
最後に「メモ」サブタブを図 25 に示します。言うまでもなく、その主な役割は、記録しておきたいリソースの特性を書き留めるスペースを用意することです。そのため、文章での説明やその他のメモを書き込める余白が十分に取られています。


ステップ 3: プロジェクトの大まかなタスクを特定する

この「New Shower」サンプル プロジェクトは、組織がかつて無事に完了させた別のプロジェクトとよく似ているものと想定します。このプロジェクトは、ほとんどすべてのプロジェクトと同じように、開始、調査、契約、開発、立ち上げという 5 つの一般的なタスクで説明できます。これらの一般的な呼び名は、望ましいほど明確に内容を言い表してはいませんが、上位レベルのタスクを分類する大まかな枠組みにはなっています。そこでアナリストはより具体的なタスク名を入力しますが、それぞれがこの一般的な区分にあてはまることがわかります(図 26)。ここまでのタスク バーがすべて赤色になっている点に注目してください。この赤色は、すべてのタスクがクリティカル タスクになっていることを意味していますが、この分析段階ではまだ意味を持ちません。作業を終えるころには、クリティカル パスは赤色、クリティカルでないタスク バーはすべて青色になりますが、プロジェクト計画を立てるこの段階でクリティカル パスを特定するのは、まだ早すぎます。
ステップ 4: タスクの依存関係を特定する
一部のタスクは、ほかのタスクが完了するまで開始できません。つまり、後のタスクは、それより前のタスクが完了してはじめて開始できる、という依存関係にあります。この「New Shower」の例では、ベータ テストが終わるまでアプリケーションを世界に向けて売り出せないこと、そしてアプリケーションの開発が終わるまでベータ テストを始められないことは明らかです。そしてもちろん、ほかのどのタスクよりも前に、(キックオフ ミーティングの開催に表される)開始承認が必要です。こうした依存関係は図 27 のとおりです。

これで色分けによってクリティカル パスが赤色で示されるようになりました。依存関係のロジックがこのクリティカル パスを示しているのです。このクリティカル パスは今のところ 3 つの要素から成り、クリティカルでない経路はクリティカル パスに影響を与えません。タスクの扱い方にはほかにも細かな点がいくつかあり、それは次のセクションで扱います。ですが、まずはリソースを割り当て、必要に応じて上位のタスクを分解しなければなりません。
ステップ 5: プロジェクトのリソースを適切なタスクに割り当てる
それぞれのタスクには、完了のために 1 つ以上のリソースが必要になるでしょう。垂直のスライダーを右に動かさないと、ガント チャートの一部の列が隠れていることがあります。リソースの名前は「名前」という列に直接入力できます。デフォルトでは割り当てたタスクに時間の 100% が割り当てられますが、このオプションは割り当てのダイアログで変更できます。「名前」欄には複数のリソースを、それぞれのタスクに割り当てる時間の割合とともに直接入力できます。図 28 の上部(黄色の枠)のように、リソース名どうしはセミコロンで区切ります。この図では、プロジェクトに充てる時間の割合はデフォルト値の 100% のままにしています。コマンド リボンの 2 行目(マゼンタの枠)で「タスク使用状況」を選ぶと、割り当てられたリソースの時間数が画面の左下に表示されます。これは、各タスクがどのようにカバーされているかを見るのに便利な方法です。プロジェクト リーダーの時間をほかのタスクに回すために、この時間数を操作したくなるかもしれません。黄色い該当行の時間数を手動で変更して試してみてください。このように変更すると、そのタスクにかかる日数の合計が変わってしまうことが多いので、こうしたリソースの平準化を始めるには、割合を適切に選ぶほうがよい方法かもしれません。この点については、この後すぐにまた取り上げます。

「リソース使用状況」オプション(図 29 の緑の枠)を選ぶと、それぞれの担当者が各タスクでどれだけの負荷を負っているかもわかります。この視点のほうが、各個人の作業の優先順位付けを始めやすいこともあります。この作業の優先順位付けに取りかかると、作業割合を調整していくうちに、ProjectLibre が自動スケジューリングを試みるため、一部のタスクが短縮されることがあります。希望するタスクでのパートタイム作業に対応し、作業負荷を平準化しつつ、希望するスケジュールを維持するには、手動スケジューリングを選ぶ必要が出てくることもあります。この種の作業については、「ヒストグラム」機能の利用とフィルタリング機能を取り上げる際に、改めて詳しく説明します。

ステップ 6: タスクを詳しく分解する

タスクを機敏に分割していけることは、優れたマネージャーに欠かせない資質です。ProjectLibre は、アナリストがこうした作業を行うのを後押しします。複雑なタスクをより単純なタスクに分解することで、タスク同士の関係をよりよく理解でき、必要なリソースを見積もる手がかりも得られます。ほぼすべてのケースで、人員と設備の両方について、必要なときに必要な分だけリソースを使うという考え方をスケジュールに組み込めるようになります。この「New Shower」の例では、図 30 に示す 4 つのタスク分解を行っています。もっと複雑なプロジェクトではさらに多くの分解が必要になるでしょうが、ここではこの単純な例だけで、このプログラムの使い方を示すには十分です。ProjectLibre はインデントによってサブタスクの階層を示している点に注目してください。この機能は、マニュアルの後半でタスクの使い方を改めて取り上げるときに見るように、作業分解構造の作成にもつながっています。
ステップ 7: プロジェクト計画を評価する
代表的なタスクを一通り入力し、いくつかのサブタスクまで書き出せたので、プロジェクト計画はかなり形になってきました。この最小限の構成の中で、おそらく最も重要な情報がクリティカル パスです。この情報は、プロジェクト管理者にとって非常に重要です。こうした入力が済めば、ProjectLibre のスプレッドシート上のリソース情報をもとに、作業負荷の分析と平準化を行えます。この例ではこの情報は最小限にとどめていますが、こうした作業がどのように進められるかを示すには十分です。ほとんどのプロジェクトでは、必要なリソースを洗い出すことが、最も重要であると同時に最も手間のかかる作業の一つです。タスクとサブタスクのレポートは、いつでもその時点のスナップショットとして印刷できます。その後、各タスクの完了率を入力して最新の状態に保てば、進捗状況を示し、スケジュールの達成度を評価できるステータス レポートを作成できます。ProjectLibre をもっとも活かす使い方は、プロジェクトの目標に向けた進捗を継続的に評価するためのツールとして使うことです。