プロジェクトマネジメントとは
「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。
プロジェクトを確実に成功させるための道筋づくりがプロジェクトマネジメントであり、その方法を体系化したフレームワークがPMBOK（ピンボック／A Guide to the Project Management Body of Knowledge）です。そのPMBOKをひとつの教科書としながらWebプロジェクトマネジメントのやり方を追求したものといったところです。
今後は「こういうやり方で仕事をするぞ！」とあまり力まないで、その都度プロジェクトにとって必要だと思われるものだけを適用していくことが重要なのだと思います。 例えば、小規模なプロジェクトではわざわざ契約書を作成しないで、見積が契約の代わりになるケースもあります。必要ない項目はバッサリと切ってしまう柔軟性が必要だと思います。新聞を全部隅々まで読まないですよね。なんかそんな感じだと思います。
Webプロジェクトマネジメントと書きましたが、Webに関わらずあらゆる業種に対応できるものだと思います。また、発注する側も知っておいた方がいい情報が満載です。
早速ですが、つかみとしてはバッチリな内容があったので、推敲して引用してみたいと思います。
「我が社は次の事業の柱として人材派遣業に参入することを決定する」
取締役会における役員の合意のもと、社長のこの号令によって新規事業がスタートした。同時にサービスの窓口となるWebサイトの立ち上げ準備が始まり、以前から取引があって信頼できる制作会社に仕事を依頼した。11月末のことである。
Webサイトのオープンは翌年３月。４ヶ月の作業期間というのは、システムが絡む案件としてはタイトなスケジュールだった。しかし社長はなんとか新年度から新規事業をスタートさせたいという強い意向があり、なんとかそれまでに間に合わせる必要があった。
12月、サービスの詳細がなかなか確定せず、作業が本格的に始められないのである。スケジュールを優先することに決めた制作会社は、詳細な仕様が決定する前にシステム開発に着手することにした。
発注側と受注側には信頼もあり、それぞれのモチベーションも高く、「トラブルがあっても一緒に乗り越えよう」そんな意気込みが勝っており、仕様の詳細や追加費用についての話し合いがされていなかった。Webサイトの詳細仕様が決まったのは、１月末のことだった。確定した仕様では、プロジェクトスタート時に描いていたシステム設計を大きく変更し、全体のページ数も大幅に増やす必要があった。これは大変な作業になると判断した制作側は、スケジュールの延期と費用の追加を泣く泣く申し出た。
受注側は、追加費用を払うことには同意したが、プレスリリースもすでに発表済なのでスケジュールはどうしても守りたいと制作側に伝えた。３月のオープンに間に合わせるべく、制作作業は急ピッチで進められた。何とか形にはなったが、もはや余分な時間は一切残されていない。結果として十分なテストを実施しないまま、人材派遣事業サイトをスタートする他なかった。
そうして迎えたオープン当日。恐れていたことが起きてしまった。「登録ページが表示されない」というクレームが大量に寄せられた。さらにその２日後、依頼したはずのキーワード広告が出されていないことが分かった。
サービススタートに備えて大量の広告を打っていた 人材派遣会社の怒りが爆発した。今回受けた被害の代償として、支払う制作費の大幅減税を前提に、制作側にミーティングを打診したのだった----。
発注側はこれまでの経験に基づいて作業を進めたはずで、制作側も制作の方法論をもって制作にのぞんだはずです。しかし、両者が持っていた経験と方法論ではリスクを回避できなかったということです。これは、プロジェクトマネジメント不在が引き起こしたトラブルなのでした。
プロジェクトを正式に発足させる
立ち上げのフェーズでまずやるべきことは、そのプロジェクトが誕生した理由とプロジェクトの目標・目的をしっかり把握することです。
プロジェクトの目標・目的は、６つのプロジェクト誕生の背景を理解することで、おのずと決まってきます。
- 市場の要求
例）ブラウザのバージョンアップへの対処として、コーディング変更を行う。 - 顧客の要求
例）ECサイトでの、顧客からのケータイサイト対応のリクエストに応じて、ケータイ用サイトを立ち上げる。 - 法的な要求
例）JIS X8341-3 仕様でアクセシビリティに配慮したサイトを制作する。 - ビジネスニーズ
例）出版社がケータイノベル市場の成長を見込んで、新たなケータイサイトを立ち上げる。 - 技術の進歩
例）ネット回線の通信速度が高まることをふまえて、より大容量で安価なコンテンツ配信サービスを立ち上げる。 - 社会的ニーズ
例）DRMフリーの音楽配信サイトを立ち上げる。
プロジェクト誕生の背景を理解したら、それを目的・目標に落とし込みます。 目的は最終的に達成すべきもので、目標は具体的なツールの提案や達成期日の設定などの、数値的指標です。
ここで、まずはプロジェクト・チャーターを作成します。チャーターの内容は、プロジェクトが進行するに従って徐々に詳細化していきます（段階的詳細化）。必要な項目は以下です。
- プロジェクトの目的や妥当性
- プロジェクトの背景となるビジネスニーズ
- プロジェクト概要や成果物スコープ記述
- ステークホルダー（顧客）などの期待を満たすために達成すべき要求事項
- 前提条件
- 制約条件
- マイルストーン・スケジュール
プロジェクト・チャーターには必要最低限な項目を記入し、ステークホルダー（顧客）の承認を得ます。
やるべき作業を定義する
ここではプロジェクト・スコープ記述書を作成します。
クライアントの要求の内容、プロジェクトの目標を達成するための納品物、その納品物にどんな機能が備わっているかなどを具体的に記述したものです。
- クライアントの要求をまとめ、プロジェクトに必要なすべての成果物をまとめる
- 前提条件、制約条件を洗い出し、プロジェクトの境界を明らかにする
といったことを行います。それらをまとめる際には、
- 提案依頼書（RFP／リクエスト・フォー・プロポーザル）
発注者が発注先から提案を受けるための文書 - 作業範囲記述書（SOW／ステートメント・オブ・ワーク）
目標や範囲、成果物、メンバーの役割・権限などを記述した文書 - 見積依頼書（RFQ／リクエスト・フォー・クオーテーション）
見積時に出す文書 - 情報提供依頼書（RFI／リクエスト・フォー・インフォメーション）
プロジェクトの必要情報を収集するための文書
などの、クライアントから提出された資料を参照します。
クライアントが考えている、やるべきこと・やらなくていいこと と 制作側が考えている、やるべきこと・やらなくていいことには必ずズレがあります。言及されることのない常識や、当然のことだと思われている要素というグレーゾーンの部分に明確な境界線を引き、プロジェクトのスコープ内容をリストアップします。
プロジェクトスコープ記述書に必要な要素は以下です。
- 最終成果物
プロジェクトが生成すべきプロダクト、サービスの特性を記述。 - 要求事項
プロジェクトの成果物が満たすべき条件や能力を記述したもの。クライアントからの要求も含まれる。 - プロジェクトの境界
プロジェクトの構成要素とみなされそうだけど、納品対象ではないものは除外事項として明確にする。 - 要素成果物
最終成果物を生成するために各プロセスで生まれるアウトプット。デザインの元データやドキュメントなど。 - 成果物受入基準
完成した成果物の受入プロセスとその基準を定義する。 - 前提条件
プロジェクトの前提条件（当然のこととみなされている要素）。前提条件が間違っていた場合の潜在的な影響まで記述する場合もある。 - 制約条件
プロジェクトの選択肢を制限するような具体的なプロジェクトの制約条件をリストアップしたもの（時間やコスト）。
WBSを使ってやるべきことを網羅する
ここでは、プロジェクトスコープ記述書をベースにしてWBS（ワーク・ブレークダウン・ストラクチャー） を作成します。
例えば自動車の開発を「デザイン」と「車体製作」に分けて、「車体製作」をさらに「フレーム」「ギア」「ハンドル」という部品に分けて、それぞれの「部品製作」や「組み立て」に分けていくように、大きな作業を具体的に想定できる単位まで小さく分解（要素分解）して、プロジェクト全体に必要な作業を把握するためのツールです。このWBS（ワーク・ブレークダウン・ストラクチャー）はプロジェクトの作業全てのベースになるものです。
- 作業内容がもれなく網羅されていること
- 作業単位が適切に分解（ブレークダウン）されて分かりやすくなっていること
の２つがポイントですが、「成果物」「時系列」「場所（担当）」など、どのような軸によって作業内容をブレークダウンするかが重要です。おそらく大項目を成果物、中項目を時系列にして、２階層程度に収めるのが一般的で分かりやすいやり方です。
WBS（ワーク・ブレークダウン・ストラクチャー）は、スケジュール管理に使用されることが多いため、各要素にユニークな識別子を割り当てておきます。「1 → 1.1 → 1.1.1」のように階層が分かるようにするのが一般的です。また、予算見積書の識別子と一致していれば会計処理や項目の修正などがスムーズになるメリットがあります。
見落としやすいコミュニケーション問題
まずはステークホルダー（顧客）を知ることです。
- リテラシー度合い
Webに関する理解度や知識 - 組織の構成やプロジェクトへの影響力
クライアントのプロジェクト・チームの成り立ちや影響力、プロジェクト・マネジャーの決裁レベル - 隠れたステークホルダーの存在
社内の情報システムグループ、子会社や親会社、経営層など
コミュニケーション・マネジメント計画書に記載するべき項目は以下です。
- コミュニケーション項目
ステークホルダーに配布する情報 - 目的
情報を配布する理由 - 責任者
誰が配布するのか - 書式／メディア
配布情報の内容や伝達手段（メーリングリスト／プロジェクトスペースなど） - 頻度
情報を配布する頻度（週１回／定例ミーティング後など）
コミュニケーション・チャンネル数＝メンバーの人数×（メンバーの人数−1）÷2
なので、解決策としてクライアント側と制作側でそれぞれコミュニケーションの窓口を決めること。クライアントからメールで質問があった時に、「誰かが答えるだろう」と質問を放置してしまうことも防げる。
オンライン共有ツール・プロジェクト管理サービスなども積極的に使用していくと、コミュニケーションだけでなく、生産性も飛躍的に高めることができる。
リスクをマネジメントする
リスクには、事前に予測できる既知のリスクと予測不能な未知のリスクがあります。- 既知のリスク
例）共有サーバでなぜか正しくアプリケーションが動作しない。 - 未知のリスク
例）担当者が病気でいなくなり、プロジェクトが振り出しに戻ってしまった。
リスク・マネジメントでは、既知のリスクをリストアップします。
次に、現実に発生したときのプロジェクトの影響度の高さ（影響度）と発生確率を軸にして、そのリスクに優先順位をつけます。
優先順位の高いリスクには事前に対策をとります。
- 回避
リスクになりそうな要素をスコープから外す、スケジュールを延期するなど。 - 転嫁
リスクなどを別の事業者に外注する。追加コストが必要になり、二次リスクが発生する可能性もある。 - 軽減
リスクが発生する確率を減らしたり、リスクが発生した際のプロジェクトへの影響を低くする方法です。例えば高いデザイン性を要求される場合には、新規のデザイナーではなく信頼できるデザイナーに依頼したり、デザインチェックの行程をあらかじめ多めに設定しておくなど。
品質は必ず事前に計画する
品質は高ければ高いほど良いという訳ではありません。
小規模なサイトでアクセシビリティ基本方針（JIS X8341-3など）まで立ててしまうのは過剰品質だし、少しでも安く作りたいという依頼でスタートしているのに、高価なアクセス解析ソフトは必要ありません。
品質を高い低いで判断するのではなく、目的・目標に対して適切かどうかという基準で見なければなりません。
品質と等級の違いを把握しておくことが重要です。PMBOKでは以下のように定義されています。
- 品質
あるものの明示された、または暗黙のニーズを満たす能力に関する特性の全体 - 等級
同一の用途を有するが、技術的特性が異なるようなものに対して与えられる区分または順位
例えばトラブルのない飛行機と、整備不良の飛行機では明らかに品質の違いがあります。
ビジネスクラスとエコノミークラスは、等級の違いです。
外部リンク
調達と契約書
発注者（クライアント）の視点で、調達や発注、契約（業務委託契約書など）に関する必要事項をまとめます。
- 納品成果物
納品物として記載されているものに過不足はないか - 著作権
著作権の扱いに問題はないか - 取引条件
発注金額と変更に関する条件はどうなっているか - 瑕疵（かし）対応
納品物に重大な欠点があった場合の対応をどうするか。対応をしなければならない期間（瑕疵担保期間）の設定は適切か。
納品物を「ドキュメント一式」「マニュアルなどを含む」という表現が発注側と制作側の認識のズレを生み出し、トラブルの元となる場合があるので、プロジェクト・スコープ記述書で明確にした成果物スコープを明記することが大切です。
一般的に、契約は２つのタイプに大別できます。
- 定額契約（一括請負契約）
成果物に一定の固定価格を支払う契約タイプで、一般的なスタイルです。発注側にとっては合意した一定金額で手に入る一方、制作側はリスクを負うことになります。制作コストがかさめばそれだけ利益が少なくなりますが、逆に効率よくプロジェクトを進行して制作コストを抑えることができればその分利益は膨らみます。 - 実費償還契約（コスト契約）
実コスト分を制作会社に支払う（償還する）契約タイプです。ページ原価やライセンス料などプロジェクトに使われる直接費と、マネジメント面に使われる間接費に分類されます。
コストを見積もり、予算を管理する
見積金額とともに提示すべき重要な情報として、見積の根拠（見積方法）、前提条件と制約条件、見積の精度があります。
見積の精度
- 超概算見積
本当にザックリとした見積です。見積額の制度は−50％から＋100％の間に設定されます。例えば10万円なら、5万から20万の間で増減する可能性があることになります。備考欄には「※現時点での概算となります。−50％〜＋100％程度、費用が変動する可能性があります。最終仕様時に改めてお見積いたします」などと記載しておきます。 - 概算見積
相見積や発注が確定する前のタイミングで使用されることの多い見積です。RPFや資料、打ち合わせでの情報をもとにつくる、比較的ブレの少ない見積です。見積額の制度は−25％から＋50％の間に設定されます。例えば10万円なら、7.5万から15万の間で増減する可能性があることになります。 - 確定見積
プロジェクトが進む中でスコープやスケジュールにも変更・修正が起こるため、見積額は−5％から＋10％の増減が許容されます。例えば10万円なら、9.5万から11万の間で増減する可能性があることになります。ただし、スコープが変更になっても金額は固定というケースが実際には多いです。
見積の手法
クライアントは大まかな費用を把握しようとしているのか、相見積をとろうとしているのか、正式な契約を前提としているのかということを把握したうえで使い分けます。
- 類推見積
プロジェクトのスコープの精度が粗いときや見積を急いでいるときなどに有効な手法です。過去の類似プロジェクトをベースに、現在のプロジェクトにあわせて調整して算出します。「トップダウン見積」とも呼ばれます。 - ボトムアップ見積
個々のアクティビティについてコストを算出し、金額を算出する方法です。クライアントとのミーティングで作業内容や行程、単価、数量、ページ数などをできる限り正確に盛り込みます。細かくブレークダウンすればするほど、見積の精度は高くなります。手間は掛かりますが、概算見積や正式の契約のための見積ではこの手法が用いられます。
コストダウンの具体的な方法
無理なコストダウンはプロジェクトの破綻の原因になります。スコープやタイム、品質など、ほかの制約条件とバランスをとりながら、プロジェクト目的達成のために最善の調整がされなければいけません。
- 見積を早い段階で具体化する
見積の作成時に不確定要素があると、どうしても変動リスクを上乗せしてコストの算出をせざるをえません。逆に、必要な成果物や作成内容が具体的であれば実際の作業価格に近づきます。クライアントからできるだけ具体的な情報を引き出すことで、見積時に低コストを提案できます。 - 汎用技術を活用し、カスタマイズを最低限に抑える
特殊なカスタマイズが必要な案件では、工数が格段に増えてしまいます。コスト増につながる部分をできるだけ汎用的な仕様に変えることを提案することで、低コスト化が図れます。 - コンテンツをクライアントに用意してもらう
サイトに掲載する文言や素材などをクライアント側で用意してもらうことで、制作工数を減らすことができ、コストダウンにつながります。ただし、クライアントから提供されるコンテンツのクオリティが低い場合、成果物の品質も引っ張られてしまうため、事前に品質レベルの確認と品質を維持するための対策は必要です。 - 物販サイトなどにおけるレベニュー・シェア導入
サイト制作を定額請負ではなく、共同事業契約にし、収益に応じた利益を分割する制度です。運営後の利益から制作費を回収するので、コストを調整することが可能になります。また、プロジェクトの成功に向けたモチベーションをクライアントと制作側でより強く共有することができます。
精度の高いスケジュールを作成する
スケジュール作成時にまず考慮すべき要素に個々の作業内容（アクティビティ）があります。そのアクティビティにどの程度の時間を割くかを考えることで、全体のスケジュールが決まってきます。PMBOKではさらにアクティビティ間の依存関係に注目します。依存関係は3種類あります。
- 強制依存（ハード・ロジック）
「ページデザインができていないので、コーディングが始められない」「CMSサーバへのコンテンツの登録が終わらないと表示確認テストができない」といったように、作業の性質上、順序を絶対に入れ替えられない依存関係です。 - 任意依存（ソフト・ロジック）
「全ページのワイヤーフレームが確定してから、デザイン作業に着手する」「HTMLガイドラインが承認されるまではコーディング作業を開始しない」など、過去のプロジェクトから得た経験や知識をもとにして任意に設定する依存関係です。 - 外部依存
「発注したサーバの納品がまだなので、プログラムをインストールできない」など、プロジェクト内のアクティビティではない要因との依存関係です。
アクティビティの依存関係が把握できたら、次に各アクティビティの論理的順序関係を設定する必要があります。アクティビティの順序関係は、以下の4つです。
- 【1】終了-開始（FS／Finish to Start）
先行アクティビティが完了すると後続アクティビティが開始できる。 - 【2】終了-終了（FF／Finish to Finish）
後続アクティビティは先行アクティビティの完了によって完了する - 【3】開始-開始（SS／Start to Start）
後続アクティビティは先行アクティビティの開始を受けて開始する - 【4】開始-終了（Start to Finish）
先行アクティビティの開始によって後続アクティビティは完了する
この中で現実的にスケジュール作成でもっとも使われるのは【1】、そして【2】です。
スケジュールを組むうえでもうひとつ抑えておきたいのがマイルストーンです（スケジュール書の中では◆と記述）。PMBOKではプロジェクトにおいて重要な意味をもつ時点やイベントと定義しています。マイルストーンのというスケジュールの節目を設定し、スケジュールの遅れや予算の超過やスコープの変更などが発生していないかを確認できるようにするわけです。
納期に直結する一連の作業のつながりであるクリティカル・パスをしっかり認識しておくことが重要です。終了-開始（FS／Finish to Start）の連続のような、時間的にまったく遊びがない最長の作業の連なりがクリティカル・パスで、逆に言えば、この連なりの作業を遅らせなければ、全体のスケジュールが延びることはないわけです。
プロジェクトの全体像を公式化する
ここまでで、コスト算出、品質計画、スケジュール作成など、プロジェクトのための様々な分析や計画がひと通り終わりました。この計画プロセスは、プロジェクトマネジメント計画書と補助計画書の発行をもって、いったん完了します。
プロジェクト・チャーターが、プロジェクトのWhy（目的や要求事項）を定義する文書、プロジェクト・スコープ記述書がWhat（納品物）を定義する文書だとすれば、プロジェクトマネジメント計画書はHow（実施方法）を定義する文書です。「何のために」「何を」「どのようにして」の3つのポイントが出揃うことによって、プロジェクトの全貌が明らかになるわけです。
プロジェクトマネジメント計画書に必要な項目は以下です。
- プロジェクト名
- プロジェクトの背景、ニーズ
- プロジェクト・スコープ
- 納品する成果物、要素成果物
- プロジェクト期間、ローンチ予定日、マイルストーン
- コミュニケーション・マネジメント
- プロジェクト体制図
- 変更管理の方法
- 制約条件、前提条件
正式な計画書が作成できたら、ステークホルダーとフェイス・トゥ・フェイスのミーティングを行います。ミーティングの目的は、実行段階で行うべき作業内容の共有化です。特に実行プロセスで発生する変更の取扱いについての意識の共有は必須です。
プロジェクトの実行と監視
立ち上げと実行のフェーズが頭を働かせる段階だとすれば、ここからは手を動かす段階です。人的リソースなども投入され、プロジェクトのコストが大きく発生するのもこの実行フェーズです。
実行のフェーズでは、プロジェクト・マネジャーの仕事の90％はコミュニケーションであると言っても過言ではありません。プロジェクトの進行状況や見通しなどを、問い合わせがある前にクライアントに伝え、安心感を与えるよう心がけなくてはなりません。情報を伝える場合は、先方の感情的、文化的、知識的背景を踏まえることも必要です。こちらから送った情報は、必ずしも相手に伝わった情報ではありません。
同時に、聞く技術も求められます。相手の言いたいことをしっかりと受け止め、疑問点を明確にし、相手の表現が曖昧な場合でも会話を通じて一緒に適切な結論を共有するといった、能動的に聞くスキルが必要です。
実行・管理コントロールフェーズにおいて最も重要なのが、統合変更管理です。変更管理を行ううえで大切な作業フローは以下の通りです。
- プロジェクトメンバーが変更要望を上げるときのルールを作る
要望を上げるためのルールを決めておかないと、ある人は電話で、ある人は個別メールで様々な変更の要望を上げるようになってしまいます。 - 要求されている変更の承認を行う
クライアントからの要求であったとしても、すべての変更を必ず実行しなければならないわけではありません。変更すべきかどうかは、プロジェクトの目的に応じて判断されることになります。その変更によってスケジュールやコスト、品質への影響、変更によってリスクがどれだけ増えるかといった分析（インパクト分析）を行います。 - 承認済み変更だけを実施する
どんなに小さい変更でも、承認プロセスを無視して個別対応してはいけません。すべての変更要望とその対応履歴は変更管理ログとして文書化し一元管理するようにします。また、仕様書などへの反映も忘れずに行います。
プロジェクトチームの編成と育成
実行のフェーズで行わなければならない重要な項目に、プロジェクトチームの編成と育成があります。人財管理（人は材料ではなく財産である）の見地から、各人が得られるスキルを考慮したキャリアマネジメントの視点も重要になってきます。
役割分担の表記方法には階層型、マトリックス型、テキスト型などの形態がありますが、Webプロジェクトで使いやすいのはマトリックス型です。責任分担マトリックス（RAM／Responsibility Assignment Matrix）とも言われ、誰がどのタスクに対してどういう責任があるのかを明確にするための表です。
よく使われるRAMのひとつがRACIチャートです。各メンバーをResponsible（実行責任）、Accountable（説明責任）、Consulted（相談対応）、Informed（情報提供）、の4種類の責任に分担するものです。
チーム編成ができたら次に取り組むのがチームの育成です。PMBOKに記述してあるチーム育成の4つのプロセスは以下です。
- 成立期（フォーミング／Foaming）
メンバーが招集され、プロジェクトの目的が伝えられます。 - 動乱期（ストーミング／Storming）実際の作業がスタートする段階で、メンバーの対立が最も生まれやすいのもこの段階です。メンバーは特定のジャンルのプロフェッショナルであり、独自の仕事のやり方やプライドを持っています。プロジェクトの目的やそれぞれの任務をしっかり理解してもらい、チームを次の段階に導いていかなければなりません。
- 安定期（ノーミング／Norming）
チームはようやく協調性のある集団になってきます。チームがプロジェクトに対するモチベーションを共有し、お互いに仲間意識を持ち始めるのがこの段階です。 - 遂行期（パフォーミング／Performing）
チームの生産性が最も高くなり、プロジェクトの目的達成に向けて一丸となって邁進（まいしん）できる段階です。めんばー間の信頼関係もほぼ盤石（ばんじゃく）になります。チームの完成系です。
チームのパフォーマンスを高めるには、コロケーション（物理的に同じ場所で作業をすること）が必要と言われてきました。しかし近年では、ネットを利用して対面でのミーティングなしでチーム運営を図るバーチャルチームに注目が集まっています。メーリングリスト、Web上のプロジェクトスペース、IP電話やSkypeを利用したテレビ電話などです。
クラッシングやファスト・トラッキングでスケジュール短縮を図る
スケジュールの進捗を把握する際に重視すべきなのがクリティカルパスとマイルストーンです。致命的な遅延を防ぐためにも、他のアクティビティ以上にクリティカルパスの進捗を把握する必要があります。マイルストーン単位でプロジェクトに節目をつけ、スケジュールに0％ →50％→100％などのステータスを加え、メンバー全員でスケジュールを把握することも効果的です。
スケジュールの遅れを是正する有効な手段として、クラッシング、ファスト・トラッキング、資源平準化があります。
- クラッシング
クリティカルパス上のアクティビティにリソースを追加し、作業の期間短縮を図る方法です。それまでひとりだったコーダーをふたりに増やすといった措置がこの手法になります。ただし、人数を倍にしてもパフォーマンスが機械的に2倍になるわけではありません。また、クリティカルパス上にあるタスクに対して行使されなければスケジュール短縮には結びつきません。この方法はコストの増加につながります。 - ファスト・トラッキング
もともとは順列（FS）に並んでいた2つのアクティビティを同時進行で進めて納期短縮を図る方法です。例えばデザインとコーディングを同時進行させたり、仕様書が確定する前にデザインに着手したり、動作チェックを制作側とクライアント側で同時に行うなどです。その後の大きなトラブルも生みかねないリスクもあります。 - 資源平準化
メンバーのスキルや作業に当てられる時間などを考慮して、タスクの割り当てを最適化する方法です。例えばスキルの高いメンバーをクリティカルパス上の重要なタスクに割り当てる、ひとつのタスクを分割して重要な部分をスキルの高いメンバーに、それ以外を他のメンバーに割り当てるなどです。つまり、作業の遅れをスキルで調整するわけです。
スケジュール遅延の事実や理由は何らかの形で明文化して残しておきます。ただし、遅れが発生してからリマインドするのではなく、「○日に提出いただく予定の原稿準備はいかがでしょう？原稿提出が遅れてしまいますと、デザイン着手がその分ずれてしまうため、ご協力よろしくお願いします」などと、事前に働きかける姿勢が大切です。
スコープ検証、プロジェクトの終結
プロジェクトマネジャーがプロジェクトを終結させる前に求められる作業は、もともとの計画に立ち返ることです。プロジェクトチャーターや品質計画などに立ち返り、そこに記載されていた内容がもれなく実現されているかをしっかりチェックするのです。
プロジェクトの終結には4つのタイプがあります。
- 定常業務／保守運用へと発展（付加）
定常業務へと発展するケースです。期限が決まっていて独自の内容をもつものをプロジェクトと呼びます。そうでない継続的な作業は定常業務ということになります。 - プロジェクトの完了（消滅）
プロジェクトが全て完了し、クライアントに受け入れられるケースです。2次開発が発生するような場合は、また新たにプロジェクトが立ち上がったことになります。理想的なプロジェクト終結のひとつです。 - プロジェクトの統合（統合）
他のプロジェクトや組織に統合されてしまうケースです。 - 途中で終結（欠乏）
資金や資源の消滅などにより、プロジェクトが未完のまま終結してしまうケースです。何となくなし崩しで終わってしまわないように、「プロジェクトが終わった」というコンセンサスをメンバー間で共有しておくようにしましょう。
プロジェクトの終了過程は、次回への改善につなげるための大切な振り返りポイントです。次のような作業の実施が必要です。
- 最終成果物を納品する
- 契約書に書かれている内容が正式に納品されていることを保証するドキュメント（検収書）をクライアントから受け取る
- 請求書を発行する
- プロジェクト報告書を作成して全メンバーに配布する
- ステークホルダーにプロジェクトの満足度を確認する（フィードバック）
- プロジェクト情報を大切なナレッジ（プロセス資産や教訓）として保存する
特に大切だと思われるのが、プロジェクトの過程で得た数々の教訓（レッスンズ・ラーンド）をとりまとめることです。プロジェクトメンバーが分散する前にミーティングをもってヒアリングを行い、「うまくいった作業」や「失敗した作業とその原因」「次回改善すべき事項」などを文書化しておきます。また、実行プロセス中に随時教訓をためていくことも可能です。レッスンズ・ラーンド（アウトプット）は、次のプロジェクトのインプットになります。
管理ツールと、変えないものを見極める視点
本書では、スケジュール管理などのプロジェクト管理ソフトとして FastTrack Schedule が紹介されています。Win版／Mac版の両方が用意されていて良さそうですが、もしMac版のみでよければ個人的には Omni Plan（オムニプラン） をオススメしたいです。まずはインターフェースがキレイなこと。作ったスケジュールはiCal形式で書き出せるので、iCalとの連携もバッチリです。体験版も用意されているので、仕事は美しくしたいという方はぜひお試しを！
あと、最後にメモしておきたいことをちょっろっと。
優れていることを明確にする（変えないもの＝優れているところ）
Webサイトのリニューアルを行う場合などに、悪いところばかりを見つけようとしますが、まずどこがいいのか、優れているのかというポジティブな面をしっかりつかむところから始めないと、せっかく今まで築き上げてきた優位性や差別化ポイントを捨ててしまうという大きな損失を被ることになります。