【プロジェクトマネジメント】17_おまけ

おまけ

WBS&スケジュール表を Excel で作成しようとしたのですが、色々と実現したい機能が不可能っぽいことに気が付いて、ものすごく不便なものになってきたので途中でやめました。何に使うにも中途半端で不便なのですが、文字と罫線と偶数行の色のバランスなんかが気に入っています。不便だけどかわいいやつなので、恥ずかしくもなく Excel データをアップすると共に、その制作過程をメモしておきたいと思います。

»WBS&スケジュール表を Excel で作成しようとしたけど、なんか色々と無理っぽいのであきらめた中途半端なデータ（作成 by 大森）をダウンロードしてみる

1. 色を作成します

「環境設定 > 色 > 標準の色」で、これから使用する色をあらかじめ作成しておきます。

• 曜日の背景色用
  R:242,G:242,B:242（#f2f2f2）
• 偶数行の背景色用
  R:242,G:246,B:248（#f2f6f8）
• 罫線の色用
  R:182,G:202,B:220（#b6cadc）
• 文字の色用
  R:74,G:98,B:145（#4a6291）

2. 基準になる年月日を入力します

A1、D1、F1のセルにそれぞれ、任意の年、月、日を入力する

3. 先ほど入力した年月日をもとに、カレンダーのもとになるデータを作成します

I1のセルを選択 =DATE(A1, D1, F1) を入力して、「セルの書式設定（command+1）」で、表示形式 > 分類:日付にして、種類を適当に選択する。

4. カレンダーを自動作成するための準備をします

J1のセルを選択

=SUM(I1+1)

を入力して、同じく「セルの書式設定（command+1）」で、分類:日付にして、種類を適当に選択する。

5. 必要なだけコピーします

K1から右のセルは、J1からオートフィルでコピーしておきます。

6. カレンダーの月を作成します

I2のセルを選択

=MONTH(I1)&"月"

を入力して、月を表示します。

J2から右のセルは、I2からオートフィルでコピーしておきます。

7. カレンダーの曜日を作成します

I3のセルを選択

=WEEKDAY(I1,1)

を入力して、曜日を表示します。が、曜日ではなく数字がでます。

「セルの書式設定（command+1）」で、表示形式 > 分類:ユーザ定義を選択して、種類に「aaa」と入力すると曜日が表示されます。

J3から右のセルは、I3からオートフィルでコピーしておきます。

8. カレンダーの日付を作成します

I4のセルを選択

=DAY(I1)

を入力して、日付を表示します。

J4から右のセルは、I4からオートフィルでコピーしておきます。

9. 土日だけ色を変更します

command+Aですべてのセルを選択して、「書式 > 条件付き書式」で、条件1に

数値が

=OR(WEEKDAY(I$3)=1,WEEKDAY(I$3)=7)=TRUE

「書式 > パターン」から、【1】で作成した曜日の背景色（R:242,G:242,B:242[#f2f2f2]）を選択します。

10. セル全体の偶数行を色変更します

次に、条件2に

数値が

=MOD(ROW(),2)=0

「書式 > パターン」から、【1】で作成した偶数行の背景色（R:242,G:246,B:248[#f2f6f8]）を選択します。

11. 文字を入力します

WBS、アクティビティ名、備考などのテキストを入力します。

12. 罫線の色を変更します

command+Aですべてのセルを選択して「セルの書式設定（command+1）」で【1】で作成した罫線の色（R:182,G:202,B:220[#b6cadc]）に変更します。

13. 文字の色を変更します

command+Aですべてのセルを選択して「セルの書式設定（command+1）」で【1】で作成した文字の色（R:74,G:98,B:145[#4a6291]）に変更します。

14. 1行目のセルを非表示にします

1行目のセルを全て選択して、右クリックから 「表示しない」を選択します。

【プロジェクトマネジメント】16_最後に

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

最後に

本書では、スケジュール管理などのプロジェクト管理ソフトとして FastTrack Schedule が紹介されています。Win版／Mac版の両方が用意されていて良さそうですが、もしMac版のみでよければ個人的には Omni Plan（オムニプラン） をオススメしたいです。まずはインターフェースがキレイなこと。作ったスケジュールはiCal形式で書き出せるので、iCalとの連携もバッチリです。体験版も用意されているので、仕事は美しくしたいという方はぜひお試しを！

あと、最後にメモしておきたいことをちょっろっと。

優れていることを明確にする（変えないもの＝優れているところ）
Webサイトのリニューアルを行う場合などに、悪いところばかりを見つけようとしますが、まずどこがいいのか、優れているのかというポジティブな面をしっかりつかむところから始めないと、せっかく今まで築き上げてきた優位性や差別化ポイントを捨ててしまうという大きな損失を被ることになります。

【プロジェクトマネジメント】15_スコープ・その3、統合・その4

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

スコープ検証、プロジェクトの終結

プロジェクトマネジャーがプロジェクトを終結させる前に求められる作業は、もともとの計画に立ち返ることです。プロジェクトチャーターや品質計画などに立ち返り、そこに記載されていた内容がもれなく実現されているかをしっかりチェックするのです。

プロジェクトの終結には4つのタイプがあります。

• 定常業務／保守運用へと発展（付加）
  定常業務へと発展するケースです。期限が決まっていて独自の内容をもつものをプロジェクトと呼びます。そうでない継続的な作業は定常業務ということになります。
• プロジェクトの完了（消滅）
  プロジェクトが全て完了し、クライアントに受け入れられるケースです。2次開発が発生するような場合は、また新たにプロジェクトが立ち上がったことになります。理想的なプロジェクト終結のひとつです。
• プロジェクトの統合（統合）
  他のプロジェクトや組織に統合されてしまうケースです。
• 途中で終結（欠乏）
  資金や資源の消滅などにより、プロジェクトが未完のまま終結してしまうケースです。何となくなし崩しで終わってしまわないように、「プロジェクトが終わった」というコンセンサスをメンバー間で共有しておくようにしましょう。

プロジェクトの終了過程は、次回への改善につなげるための大切な振り返りポイントです。次のような作業の実施が必要です。

• 最終成果物を納品する
• 契約書に書かれている内容が正式に納品されていることを保証するドキュメント（検収書）をクライアントから受け取る
• 請求書を発行する
• プロジェクト報告書を作成して全メンバーに配布する
• ステークホルダーにプロジェクトの満足度を確認する（フィードバック）
• プロジェクト情報を大切なナレッジ（プロセス資産や教訓）として保存する

特に大切だと思われるのが、プロジェクトの過程で得た数々の教訓（レッスンズ・ラーンド）をとりまとめることです。プロジェクトメンバーが分散する前にミーティングをもってヒアリングを行い、「うまくいった作業」や「失敗した作業とその原因」「次回改善すべき事項」などを文書化しておきます。また、実行プロセス中に随時教訓をためていくことも可能です。レッスンズ・ラーンド（アウトプット）は、次のプロジェクトのインプットになります。

【プロジェクトマネジメント】14_タイム・その2

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

クラッシングやファスト・トラッキングでスケジュール短縮を図る

スケジュールの進捗を把握する際に重視すべきなのがクリティカルパスとマイルストーンです。致命的な遅延を防ぐためにも、他のアクティビティ以上にクリティカルパスの進捗を把握する必要があります。マイルストーン単位でプロジェクトに節目をつけ、スケジュールに0％
→50％→100％などのステータスを加え、メンバー全員でスケジュールを把握することも効果的です。

スケジュールの遅れを是正する有効な手段として、クラッシング、ファスト・トラッキング、資源平準化があります。

• クラッシング
  クリティカルパス上のアクティビティにリソースを追加し、作業の期間短縮を図る方法です。それまでひとりだったコーダーをふたりに増やすといった措置がこの手法になります。ただし、人数を倍にしてもパフォーマンスが機械的に2倍になるわけではありません。また、クリティカルパス上にあるタスクに対して行使されなければスケジュール短縮には結びつきません。この方法はコストの増加につながります。
• ファスト・トラッキング
  もともとは順列（FS）に並んでいた2つのアクティビティを同時進行で進めて納期短縮を図る方法です。例えばデザインとコーディングを同時進行させたり、仕様書が確定する前にデザインに着手したり、動作チェックを制作側とクライアント側で同時に行うなどです。その後の大きなトラブルも生みかねないリスクもあります。
• 資源平準化
  メンバーのスキルや作業に当てられる時間などを考慮して、タスクの割り当てを最適化する方法です。例えばスキルの高いメンバーをクリティカルパス上の重要なタスクに割り当てる、ひとつのタスクを分割して重要な部分をスキルの高いメンバーに、それ以外を他のメンバーに割り当てるなどです。つまり、作業の遅れをスキルで調整するわけです。

スケジュール遅延の事実や理由は何らかの形で明文化して残しておきます。ただし、遅れが発生してからリマインドするのではなく、「○日に提出いただく予定の原稿準備はいかがでしょう？原稿提出が遅れてしまいますと、デザイン着手がその分ずれてしまうため、ご協力よろしくお願いします」などと、事前に働きかける姿勢が大切です。

【プロジェクトマネジメント】13_人的資源

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

プロジェクトチームの編成と育成

実行のフェーズで行わなければならない重要な項目に、プロジェクトチームの編成と育成があります。人財管理（人は材料ではなく財産である）の見地から、各人が得られるスキルを考慮したキャリアマネジメントの視点も重要になってきます。

役割分担の表記方法には階層型、マトリックス型、テキスト型などの形態がありますが、Webプロジェクトで使いやすいのはマトリックス型です。責任分担マトリックス（RAM／Responsibility Assignment Matrix）とも言われ、誰がどのタスクに対してどういう責任があるのかを明確にするための表です。

よく使われるRAMのひとつがRACIチャートです。各メンバーをResponsible（実行責任）、Accountable（説明責任）、Consulted（相談対応）、Informed（情報提供）、の4種類の責任に分担するものです。

チーム編成ができたら次に取り組むのがチームの育成です。PMBOKに記述してあるチーム育成の4つのプロセスは以下です。

• 成立期（フォーミング／Foaming）
  メンバーが招集され、プロジェクトの目的が伝えられます。
• 動乱期（ストーミング／Storming）実際の作業がスタートする段階で、メンバーの対立が最も生まれやすいのもこの段階です。メンバーは特定のジャンルのプロフェッショナルであり、独自の仕事のやり方やプライドを持っています。プロジェクトの目的やそれぞれの任務をしっかり理解してもらい、チームを次の段階に導いていかなければなりません。
• 安定期（ノーミング／Norming）
  チームはようやく協調性のある集団になってきます。チームがプロジェクトに対するモチベーションを共有し、お互いに仲間意識を持ち始めるのがこの段階です。
• 遂行期（パフォーミング／Performing）
  チームの生産性が最も高くなり、プロジェクトの目的達成に向けて一丸となって邁進（まいしん）できる段階です。めんばー間の信頼関係もほぼ盤石（ばんじゃく）になります。チームの完成系です。

チームのパフォーマンスを高めるには、コロケーション（物理的に同じ場所で作業をすること）が必要と言われてきました。しかし近年では、ネットを利用して対面でのミーティングなしでチーム運営を図るバーチャルチームに注目が集まっています。メーリングリスト、Web上のプロジェクトスペース、IP電話やSkypeを利用したテレビ電話などです。

プロジェクト体制図のサンプルはこちらで公開されています。

»課題管理表
（テンプレート by ロフトワーク CC BY）

【プロジェクトマネジメント】12_総合・その3

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

プロジェクトの実行と監視

立ち上げと実行のフェーズが頭を働かせる段階だとすれば、ここからは手を動かす段階です。人的リソースなども投入され、プロジェクトのコストが大きく発生するのもこの実行フェーズです。

実行のフェーズでは、プロジェクト・マネジャーの仕事の90％はコミュニケーションであると言っても過言ではありません。プロジェクトの進行状況や見通しなどを、問い合わせがある前にクライアントに伝え、安心感を与えるよう心がけなくてはなりません。情報を伝える場合は、先方の感情的、文化的、知識的背景を踏まえることも必要です。こちらから送った情報は、必ずしも相手に伝わった情報ではありません。
同時に、聞く技術も求められます。相手の言いたいことをしっかりと受け止め、疑問点を明確にし、相手の表現が曖昧な場合でも会話を通じて一緒に適切な結論を共有するといった、能動的に聞くスキルが必要です。

実行・管理コントロールフェーズにおいて最も重要なのが、統合変更管理です。変更管理を行ううえで大切な作業フローは以下の通りです。

• プロジェクトメンバーが変更要望を上げるときのルールを作る
  要望を上げるためのルールを決めておかないと、ある人は電話で、ある人は個別メールで様々な変更の要望を上げるようになってしまいます。
• 要求されている変更の承認を行う
  クライアントからの要求であったとしても、すべての変更を必ず実行しなければならないわけではありません。変更すべきかどうかは、プロジェクトの目的に応じて判断されることになります。その変更によってスケジュールやコスト、品質への影響、変更によってリスクがどれだけ増えるかといった分析（インパクト分析）を行います。
• 承認済み変更だけを実施する
  どんなに小さい変更でも、承認プロセスを無視して個別対応してはいけません。すべての変更要望とその対応履歴は変更管理ログとして文書化し一元管理するようにします。また、仕様書などへの反映も忘れずに行います。

課題管理表のサンプルはこちらで公開されています。

»課題管理表
（テンプレート by ロフトワーク CC BY）

【プロジェクトマネジメント】11_総合・その2

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

プロジェクトの全体像を公式化する

ここまでで、コスト算出、品質計画、スケジュール作成など、プロジェクトのための様々な分析や計画がひと通り終わりました。この計画プロセスは、プロジェクトマネジメント計画書と補助計画書の発行をもって、いったん完了します。

プロジェクト・チャーターが、プロジェクトのWhy（目的や要求事項）を定義する文書、プロジェクト・スコープ記述書がWhat（納品物）を定義する文書だとすれば、プロジェクトマネジメント計画書はHow（実施方法）を定義する文書です。「何のために」「何を」「どのようにして」の3つのポイントが出揃うことによって、プロジェクトの全貌が明らかになるわけです。

プロジェクトマネジメント計画書に必要な項目は以下です。

• プロジェクト名
• プロジェクトの背景、ニーズ
• プロジェクト・スコープ
• 納品する成果物、要素成果物
• プロジェクト期間、ローンチ予定日、マイルストーン
• コミュニケーション・マネジメント
• プロジェクト体制図
• 変更管理の方法
• 制約条件、前提条件

正式な計画書が作成できたら、ステークホルダーとフェイス・トゥ・フェイスのミーティングを行います。ミーティングの目的は、実行段階で行うべき作業内容の共有化です。特に実行プロセスで発生する変更の取扱いについての意識の共有は必須です。

【プロジェクトマネジメント】10_タイム・その1

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

精度の高いスケジュールを作成する

スケジュール作成時にまず考慮すべき要素に個々の作業内容（アクティビティ）があります。そのアクティビティにどの程度の時間を割くかを考えることで、全体のスケジュールが決まってきます。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）の連続のような、時間的にまったく遊びがない最長の作業の連なりがクリティカル・パスで、逆に言えば、この連なりの作業を遅らせなければ、全体のスケジュールが延びることはないわけです。

»WBS&スケジュール書
（テンプレート by ロフトワーク CC BY）

【プロジェクトマネジメント】09_コスト

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

見積のコツ

見積金額とともに提示すべき重要な情報として、見積の根拠（見積方法）、前提条件と制約条件、見積の精度があります。

▼見積の精度

• 超概算見積
  本当にザックリとした見積です。見積額の制度は−50％から＋100％の間に設定されます。例えば10万円なら、5万から20万の間で増減する可能性があることになります。備考欄には「※現時点での概算となります。−50％〜＋100％程度、費用が変動する可能性があります。最終仕様時に改めてお見積いたします」などと記載しておきます。
• 概算見積
  相見積や発注が確定する前のタイミングで使用されることの多い見積です。RPFや資料、打ち合わせでの情報をもとにつくる、比較的ブレの少ない見積です。見積額の制度は−25％から＋50％の間に設定されます。例えば10万円なら、7.5万から15万の間で増減する可能性があることになります。
• 確定見積
  プロジェクトが進む中でスコープやスケジュールにも変更・修正が起こるため、見積額は−5％から＋10％の増減が許容されます。例えば10万円なら、9.5万から11万の間で増減する可能性があることになります。ただし、スコープが変更になっても金額は固定というケースが実際には多いです。

▼見積の手法

クライアントは大まかな費用を把握しようとしているのか、相見積をとろうとしているのか、正式な契約を前提としているのかということを把握したうえで使い分けます。

• 類推見積
  プロジェクトのスコープの精度が粗いときや見積を急いでいるときなどに有効な手法です。過去の類似プロジェクトをベースに、現在のプロジェクトにあわせて調整して算出します。「トップダウン見積」とも呼ばれます。
• ボトムアップ見積
  個々のアクティビティについてコストを算出し、金額を算出する方法です。クライアントとのミーティングで作業内容や行程、単価、数量、ページ数などをできる限り正確に盛り込みます。細かくブレークダウンすればするほど、見積の精度は高くなります。手間は掛かりますが、概算見積や正式の契約のための見積ではこの手法が用いられます。

▼コストダウンの具体的な方法

無理なコストダウンはプロジェクトの破綻の原因になります。スコープやタイム、品質など、ほかの制約条件とバランスをとりながら、プロジェクト目的達成のために最善の調整がされなければいけません。

• 見積を早い段階で具体化する
  見積の作成時に不確定要素があると、どうしても変動リスクを上乗せしてコストの算出をせざるをえません。逆に、必要な成果物や作成内容が具体的であれば実際の作業価格に近づきます。クライアントからできるだけ具体的な情報を引き出すことで、見積時に低コストを提案できます。
• 汎用技術を活用し、カスタマイズを最低限に抑える
  特殊なカスタマイズが必要な案件では、工数が格段に増えてしまいます。コスト増につながる部分をできるだけ汎用的な仕様に変えることを提案することで、低コスト化が図れます。
• コンテンツをクライアントに用意してもらう
  サイトに掲載する文言や素材などをクライアント側で用意してもらうことで、制作工数を減らすことができ、コストダウンにつながります。ただし、クライアントから提供されるコンテンツのクオリティが低い場合、成果物の品質も引っ張られてしまうため、事前に品質レベルの確認と品質を維持するための対策は必要です。

• 物販サイトなどにおけるレベニュー・シェア導入
  サイト制作を定額請負ではなく、共同事業契約にし、収益に応じた利益を分割する制度です。運営後の利益から制作費を回収するので、コストを調整することが可能になります。また、プロジェクトの成功に向けたモチベーションをクライアントと制作側でより強く共有することができます。

約束した予算内で作業を完了させるためにも、あらかじめコンティンジェンシー予備費（余分の予算）を確保しておくことが重要です。

【プロジェクトマネジメント】08_調達

「Webプロジェクトマネジメント標準」を元に、自分自身が理解しやすいような形で要約メモしておきたいと思います。

調達と契約書

発注者（クライアント）の視点で、調達や発注、契約（業務委託契約書など）に関する必要事項をまとめます。

• 納品成果物
  納品物として記載されているものに過不足はないか
• 著作権
  著作権の扱いに問題はないか
• 取引条件
  発注金額と変更に関する条件はどうなっているか
• 瑕疵（かし）対応
  納品物に重大な欠点があった場合の対応をどうするか。対応をしなければならない期間（瑕疵担保期間）の設定は適切か。

納品物を「ドキュメント一式」「マニュアルなどを含む」という表現が発注側と制作側の認識のズレを生み出し、トラブルの元となる場合があるので、プロジェクト・スコープ記述書で明確にした成果物スコープを明記することが大切です。

一般的に、契約は２つのタイプに大別できます。

• 定額契約（一括請負契約）
  成果物に一定の固定価格を支払う契約タイプで、一般的なスタイルです。発注側にとっては合意した一定金額で手に入る一方、制作側はリスクを負うことになります。制作コストがかさめばそれだけ利益が少なくなりますが、逆に効率よくプロジェクトを進行して制作コストを抑えることができればその分利益は膨らみます。
• 実費償還契約（コスト契約）
  実コスト分を制作会社に支払う（償還する）契約タイプです。ページ原価やライセンス料などプロジェクトに使われる直接費と、マネジメント面に使われる間接費に分類されます。