例えば野球のピッチャーが「最小の努力で勝ちたい」といったとして、
プロのピッチャーであればそれは最小の球数、最小失点で四死球を与えず勝利するということを意味するだろう。そのために猛烈に練習し、相手を研究し、試合に向けてコンディションを高めてくるだろう。しかし万年草野球ピッチャーは少しでも楽な練習をし、弱い相手と当たることを祈るだろう。
プロジェクトマネージャーでも同じこと。
効率よくプロジェクトを完了させたいと誰もが言うが、優れたPMは精度の高いプランを作り、プロジェクト運用ルールを定義し、リスクをコントロールし、プロジェクト全体の効率を高めるために努力を惜しまないのに対し、2流以下のPMは自分の作業量を減らすことを効率と呼ぶ。
最小の努力で成功するには、多大な努力が必要だ。矛盾しているようだが、衆目に触れない部分での努力を惜しんでいては、ここぞという場面で炎上するのは野球もプロジェクトも同じだろう。
2014年6月20日金曜日
【連載】ステアリングコミッティの役割と責任 - ３
<前記事からの続きです
ステアリングコミッティとプロジェクトマネージャーのコミュニケーションについてはいろいろな形があるでしょうが、一般的には次のようになると思います。
定例ステアリングコミッティミーティングは定期的に持つミーティングで、プロジェクト運営に関わる問題・課題解決の決定や情報共有を行います。
フェーズレビューミーティングは各フェーズの結果を確認し、フェーズの終了と次フェーズへの進行可否を決定します。ゲートミーティングやマイルストーンミーティングとも呼ばれます。
いずれも公式のミーティングですので、事前にステアリングコミッティとプロジェクトマネージャーによって準備をしておく必要があります。
非公式のコミュニケーションについては割愛しますが、日常のコミュニケーションによって情報共有や信頼醸成を行います。
以上、長々と書いてきましたが、ともすれば軽視されがちなステアリングコミッティの役割と責任について理解が進んでいけばよいと思います。
ステアリングコミッティとプロジェクトマネージャーのコミュニケーションについてはいろいろな形があるでしょうが、一般的には次のようになると思います。
- 公式：
- 定例ステアリングコミッティミーティング
- フェーズレビューミーティング
- 非公式のコミュニケーション
定例ステアリングコミッティミーティングは定期的に持つミーティングで、プロジェクト運営に関わる問題・課題解決の決定や情報共有を行います。
フェーズレビューミーティングは各フェーズの結果を確認し、フェーズの終了と次フェーズへの進行可否を決定します。ゲートミーティングやマイルストーンミーティングとも呼ばれます。
いずれも公式のミーティングですので、事前にステアリングコミッティとプロジェクトマネージャーによって準備をしておく必要があります。
- チェアマンとプロジェクトマネージャーは、会議の前に議題と内容について同期しておきます
- プロジェクトマネージャーは最低5営業日前までに議題と内容をステアリングコミッティに送付しておきます
- ステアリングコミッティは内容を精査しておきます
- 判断のポイントとなる部分を確認しておきます。何か疑問がある場合は、会議の前にプロジェクトマネージャーに質問しておきます。
非公式のコミュニケーションについては割愛しますが、日常のコミュニケーションによって情報共有や信頼醸成を行います。
以上、長々と書いてきましたが、ともすれば軽視されがちなステアリングコミッティの役割と責任について理解が進んでいけばよいと思います。
■連載
【連載】ステアリングコミッティの役割と責任 - ２
＜前記事からの続きです
チェアマンの責任はSCミーティングをリードするだけに留まりません。チェアマンはプロジェクトオーナーやプロジェクトマネージャーと常に接し、効果的な運営を行うことに責任があります。例えば・・
特に重要なのが最後の「プロジェクトの成功への責任(Accountability:結果に対する責任、説明責任)」です。プロジェクトマネージャーは通常プロジェクトの成功への責任(Responsibility:何かをする責任)がありますが、Accountabilityはありません。
例えばプロジェクトマネージャーが新しい勤怠管理の開発を依頼され、それを依頼通りに納品すれば責任を果たしたことになりますが、それがビジネス上有益であるかどうかについての責任はありません。その責任を持つのはチェアマンとなります。
このように、ステアリングコミッティのチェアマンあるいはメンバーとなるには、それに見合う役割と責任の自覚、そして行動が必要となります。
＞次記事：ステアリングコミッティとしての役割と責任の自覚
チェアマンの責任はSCミーティングをリードするだけに留まりません。チェアマンはプロジェクトオーナーやプロジェクトマネージャーと常に接し、効果的な運営を行うことに責任があります。例えば・・
- プロジェクトマネージャーの任命(および解任)
- ステアリングコミッティが最高の状態で機能するようリードする
- ステアリングコミッティメンバーが最新のプロジェクトの情報を得ていることを確認
- プロジェクトオーナーとステアリングコミッティメンバーのコミュニケーションを確保
- ステアリングコミッティーミーティングでの決定
- 積極的なプロジェクトへの関与とプロジェクトマネージャーのサポート
- ライン組織が活動を実行し、ビジネスニーズに応じて結果を提供していることを確認
- プロジェクトの成功への責任(Accountability)
特に重要なのが最後の「プロジェクトの成功への責任(Accountability:結果に対する責任、説明責任)」です。プロジェクトマネージャーは通常プロジェクトの成功への責任(Responsibility:何かをする責任)がありますが、Accountabilityはありません。
例えばプロジェクトマネージャーが新しい勤怠管理の開発を依頼され、それを依頼通りに納品すれば責任を果たしたことになりますが、それがビジネス上有益であるかどうかについての責任はありません。その責任を持つのはチェアマンとなります。
このように、ステアリングコミッティのチェアマンあるいはメンバーとなるには、それに見合う役割と責任の自覚、そして行動が必要となります。
＞次記事：ステアリングコミッティとしての役割と責任の自覚
■連載
【連載】ステアリングコミッティの役割と責任 - ２ (当記事)
【連載】ステアリングコミッティの役割と責任 - １
大規模なプロジェクトを実施する際にステアリングコミッティが組織されることがあります。
ステアリングコミッティはプロジェクトに関わる部門や企業の責任者を集め、それぞれの立場から利害官営や連携、情報伝達を行い、プロジェクトマネージャーを（上位レベルから）サポートし、現場レベルで解決できない問題の解決を図り、またプロジェクトのフェーズレビューに於いては次フェーズへ進んでよいかの判断を行います。実質、プロジェクトマネージャーにとって最も重要なステークホルダーと言えます。
ステアリングコミッティはプロジェクト運営にかかわる非常に重要な存在ですので、そのメンバーはプロジェクトを正しく理解し適切な関わりを持つことが求められます。組織によって異なるでしょうが、ステアリングコミッティの役割をいくつか挙げてみます。
おわかりでしょうか？ただ報告を受けて承認をするだけではなく、意外とアクティブに動かなければならないですね。また、ステアリングコミッティの中でもチェアマンはさらに重要な役割があります。
＞次記事：チェアマンの責任
ステアリングコミッティはプロジェクトに関わる部門や企業の責任者を集め、それぞれの立場から利害官営や連携、情報伝達を行い、プロジェクトマネージャーを（上位レベルから）サポートし、現場レベルで解決できない問題の解決を図り、またプロジェクトのフェーズレビューに於いては次フェーズへ進んでよいかの判断を行います。実質、プロジェクトマネージャーにとって最も重要なステークホルダーと言えます。
ステアリングコミッティはプロジェクト運営にかかわる非常に重要な存在ですので、そのメンバーはプロジェクトを正しく理解し適切な関わりを持つことが求められます。組織によって異なるでしょうが、ステアリングコミッティの役割をいくつか挙げてみます。
- プロジェクトの方向性、目的、ビジョンを示す
- プロジェクトリソースの確保
- 投資対効果の確保
- プロジェクトやステークホルダーへの動機付け・鼓舞
- プロジェクト運営の大方針を示す
- プロジェクトフォローアップとコントロール
- 組織に対し、プロジェクトとその決定の推進
- ステアリングコミッティミーティングでの意思決定
- その他、プロジェクトマネージャーのサポート
おわかりでしょうか？ただ報告を受けて承認をするだけではなく、意外とアクティブに動かなければならないですね。また、ステアリングコミッティの中でもチェアマンはさらに重要な役割があります。
＞次記事：チェアマンの責任
■連載
【連載】ステアリングコミッティの役割と責任 - １ (当記事)
2014年6月16日月曜日
段階的コスト見積り
プロジェクトコストを見積もる際、立ち上げ時にいきなり詳細な見積りをしてコミットしてしまうことは、よほどリスクの少ないプロジェクトでない限り避けるべきですが、実際には営業担当が売り込み時に口約束レベルで言った価格でプロジェクトを納めるよう強要されることもあるのではないでしょうか？そこまでひどくなくても、プロジェクト初期に出した数字が独り歩きし、プロジェクトの詳細が見えてきて追加コストが必要なことがわかってもコスト変更がほぼ不可能、という話はよく聞きます。
これではお互い不幸になります。受注側は常にコストオーバーランの脅威にさらされますし、その結果多めの見積りを出しがちになります。また、言質を取られまいと、曖昧な説明をすることになります。発注側は根拠不明の高額な見積りに驚くことになりますが、交渉しようにもコスト構造が不透明なため「安くしろ！」としか言えなくなります。
通常、下図のように概要見積りから詳細見積りへと落とし込み、適切なタイミングでコミットするかと思います。
実際には上図のようなカーブではなく、フェーズレビュー等のタイミングで次フェーズ以降のコストをどの程度の精度で見積もるか、という決め事になっていくかと思います。下に例を示します。
この例では、各フェーズのレビューのタイミングで、次フェーズ以降のコストを２つの観点（次フェーズ期間中のみのコストと、プロジェクト全体のコスト）と、プロジェクト終了後の保守費用という観点で見積もっています。
セルの色は、
薄い水色：概算見積り
濃い水色：精度を高めた見積り（しかしコミットしない）
青地に白文字：詳細見積り（コミットする）
となっています。
前提として、
・詳細設計フェーズまでは発注側の判断でプロジェクトを中止できる（そのためフェーズ毎のコストのみコミット）
・詳細設計フェーズ開始前にプロジェクト全体のコストをコミットし、正式に契約する
・保守費用見積りは受注側の責任
としています。
上の表はあくまで一例で、前提条件によって大きく変わってくると思いますが、プロジェクトが進むに従い詳細化され、十分に詳細化された時点でコミットされるのだ、という共通認識を受発注側双方で持つことが重要です。
これではお互い不幸になります。受注側は常にコストオーバーランの脅威にさらされますし、その結果多めの見積りを出しがちになります。また、言質を取られまいと、曖昧な説明をすることになります。発注側は根拠不明の高額な見積りに驚くことになりますが、交渉しようにもコスト構造が不透明なため「安くしろ！」としか言えなくなります。
通常、下図のように概要見積りから詳細見積りへと落とし込み、適切なタイミングでコミットするかと思います。
実際には上図のようなカーブではなく、フェーズレビュー等のタイミングで次フェーズ以降のコストをどの程度の精度で見積もるか、という決め事になっていくかと思います。下に例を示します。
この例では、各フェーズのレビューのタイミングで、次フェーズ以降のコストを２つの観点（次フェーズ期間中のみのコストと、プロジェクト全体のコスト）と、プロジェクト終了後の保守費用という観点で見積もっています。
セルの色は、
薄い水色：概算見積り
濃い水色：精度を高めた見積り（しかしコミットしない）
青地に白文字：詳細見積り（コミットする）
となっています。
前提として、
・詳細設計フェーズまでは発注側の判断でプロジェクトを中止できる（そのためフェーズ毎のコストのみコミット）
・詳細設計フェーズ開始前にプロジェクト全体のコストをコミットし、正式に契約する
・保守費用見積りは受注側の責任
としています。
上の表はあくまで一例で、前提条件によって大きく変わってくると思いますが、プロジェクトが進むに従い詳細化され、十分に詳細化された時点でコミットされるのだ、という共通認識を受発注側双方で持つことが重要です。
2014年6月13日金曜日
「ソフトウェア高信頼化 先進的な設計・検証技術の適用事例報告書 2013年度版」が公開されています
2014年5月30日、独立行政法人情報処理推進機構のホームページ（http://www.ipa.go.jp/index.html）にて、ソフトウェア高信頼化 先進的な設計・検証技術の適用事例報告書 2013年度版が公開されました。
http://www.ipa.go.jp/sec/reports/20140530.html
ソフトウェア開発における先進的な取組み事例が多数紹介されています。
以下、情報処理機構ホームページからの引用です。
「ソフトウェア高信頼化 先進的な設計・検証技術の適用事例報告書 2013年度版」
（2014/6/13アクセス）
http://www.ipa.go.jp/sec/reports/20140530.html
ソフトウェア開発における先進的な取組み事例が多数紹介されています。
以下、情報処理機構ホームページからの引用です。
| 概要 社会生活になくてはならない製品・システムにおいて、ソフトウェアが重要な位置付けとなるにつれて、その信頼性の確保が重要視されます。 IPA/SECでは、ソフトウェア高信頼化の活動の一環として、ソフトウェア開発における先進的な取組み事例を数多く調査・収集しています。 それらの事例を広く紹介・共有することで、我が国のソフトウェア開発水準の向上や、製品・システム利用者の安全・安心につなげることを目的に、ソフトウェア開発プロセスのうち、最近開発手法が充実してきた「設計」、および「検証」の工程に着目して事例を取りまとめました。 |
| 本報告書の特徴 先進的な取組みや手法は、実際の開発現場で十分な効果を得るためには、それらをただ導入するだけではなく、工夫やノウハウが必要になります。 本書は、様々な業界分野にわたる事例において、実際の開発現場で効果が得られるような工夫がされている事例を、IPAが培ってきた知見をもとに取りまとめて収録しています。 本書の特徴は以下のとおりです。 設計・検証を中心とした開発手法について、様々な業界分野の適用事例24件を収録 先進的な技術を中心とした適用事例を掲載しており、開発現場における最新の技術動向に対応 開発現場のリーダーなど、第一線で活躍されている技術者などの協力のもとに事例を収集し、事例ごとに詳細な情報を掲載 単なる技術論に限らず、開発手法の徹底方法、開発者の教育方法などについても掲載 これにより、これまで導入方法が不明であることや、効果が見えにくいなどの理由により、手法の導入をためらっていた場面において、導入の一助となるものと考えています。 |
「ソフトウェア高信頼化 先進的な設計・検証技術の適用事例報告書 2013年度版」
（
類型見積り
類型見積りは、プロジェクトの初期段階など、詳細情報が乏しい段階に概算見積りを出すために使われる手法です。過去の類似プロジェクトの規模やコストから類推されたりします。
短時間で見積もりできますが、いかんせん精度が低いためPMからするとあまり頼りたくない見積り手法ですが、発注側からすれば類型見積りや係数見積りといった概算見積りはポートフォリオ管理やプロジェクトの実施を決定する際に必ず必要となるものなので、現実には逃げられないと言えるでしょう。
しかしこの類型見積りですが、注意しなければ本当に的外れな数字が出てきます。
最近担当した２つのプロジェクトも、コンサルタントやIT営業担当が出してきた見積りはあまりに実コストと乖離したものでした。
１ 見積額が低すぎたケース
とある工場の部品受発注システム導入プロジェクト。既に海外で実績のあるシステムを日本に展開する。また、同じ会社の他工場で、そのシステムを導入した経験あり。
結果→プロジェクトにかかったコストはコンサルタントが行った類型見積りの３倍。
なぜ３倍もかかったか？
コンサルタントは、「同じ会社の他工場でのシステム導入に掛かった実コスト」をそのまま見積りとして出してきました。なぜなら今回のプロジェクトも95%同じシステムを導入し、同じサプライヤーに対して部品を受発注するため、同じくらいのコスト（あるいは経験があるからより低い）で出来ると考えていました。
しかしコンサルタントは重要なポイントを見落としていました。それは、前回のプロジェクトは新規工場に対して行ったものであるのに対し、今回のプロジェクトは既存の工場に対しての導入であるということです。
新規工場であれば、既に実績のあるシステムの導入は簡単です。実際やったことは日本のサプライヤーの登録と、会計システムとの連動、端末の導入及びトレーニングだけだったそうです。
しかし既存工場への導入となると話は別です。既存工場の設備は必ずしも新システムの設計とマッチしませんので、ギャップを埋める必要があります。また、多くのレガシーシステムとのインターフェースも再構築が必要です。データ移行、システム移行もビジネスに悪影響を与えないよう行うのは簡単ではありません。また、従業員への周知やトレーニングもより慎重に行わなければなりません。経験則からして、既存システムの置き換えは新規システム導入の3倍かかると言われていますが、今回もその通りになりました。
実際には私がPMに任命され、コンサルタントから概算見積りの説明を受けた時点で3倍かかる旨を伝え（キレられましたが・・）、その後の詳細見積りでもその通りの数字となり、契約前の集中セッションでなんとか理解いただけたので、プロジェクトとしてはコストオーバランは避けることが出来ました。
２ 見積額が高すぎたケース
次に担当した消費税率変更（5→8%）にともなう販売システムの改修プロジェクトでは、既にIT側からの見積りが出ている状態で、業務側（発注側）も了承している段階で業務側のPMとなりました。
結果→ITコストは見積りの1/3
なぜそんなに安く？
（以降、金額は適当）業務側は来たるべき消費税率変更に備え$1 mil.準備していました。どういうわけかその金額を知っていたIT側はいろいろ予備費を積み、$0.8 mil.を見積額として提示してきましたが、業務側としては予算内なのでこれを受け入れました。結局IT側の予備費を使わせることなく$0.26 mil.で完了したためみんなハッピーだったのですが、そもそもの$1 mil.が高すぎたのが大幅な乖離の原因となっています。この金額は対象システムの数とこれまでの経験から情報システム部門が導いたものですが、5を8に変えるだけの改修であればシステムの数より帳票とインターフェースの数を見るべきでした。
（ちなみに、IT側が事前に予算を知っていたというのは通常良くないですが、他の事情もあり、この会社の場合必ずしも悪とはいえません。）
このように類型見積りは大幅な誤差を生み出すことがあります。ほんの些細なパラメータ（新規 or 置き換え、システム数 or 帳票数）を変えるだけで数倍の違いが出てきます。これらパラメータをどれだけ正確に捉えられるかが、類型見積りの成否を左右すると言えるでしょう。
短時間で見積もりできますが、いかんせん精度が低いためPMからするとあまり頼りたくない見積り手法ですが、発注側からすれば類型見積りや係数見積りといった概算見積りはポートフォリオ管理やプロジェクトの実施を決定する際に必ず必要となるものなので、現実には逃げられないと言えるでしょう。
しかしこの類型見積りですが、注意しなければ本当に的外れな数字が出てきます。
最近担当した２つのプロジェクトも、コンサルタントやIT営業担当が出してきた見積りはあまりに実コストと乖離したものでした。
１ 見積額が低すぎたケース
とある工場の部品受発注システム導入プロジェクト。既に海外で実績のあるシステムを日本に展開する。また、同じ会社の他工場で、そのシステムを導入した経験あり。
結果→プロジェクトにかかったコストはコンサルタントが行った類型見積りの３倍。
なぜ３倍もかかったか？
コンサルタントは、「同じ会社の他工場でのシステム導入に掛かった実コスト」をそのまま見積りとして出してきました。なぜなら今回のプロジェクトも95%同じシステムを導入し、同じサプライヤーに対して部品を受発注するため、同じくらいのコスト（あるいは経験があるからより低い）で出来ると考えていました。
しかしコンサルタントは重要なポイントを見落としていました。それは、前回のプロジェクトは新規工場に対して行ったものであるのに対し、今回のプロジェクトは既存の工場に対しての導入であるということです。
新規工場であれば、既に実績のあるシステムの導入は簡単です。実際やったことは日本のサプライヤーの登録と、会計システムとの連動、端末の導入及びトレーニングだけだったそうです。
しかし既存工場への導入となると話は別です。既存工場の設備は必ずしも新システムの設計とマッチしませんので、ギャップを埋める必要があります。また、多くのレガシーシステムとのインターフェースも再構築が必要です。データ移行、システム移行もビジネスに悪影響を与えないよう行うのは簡単ではありません。また、従業員への周知やトレーニングもより慎重に行わなければなりません。経験則からして、既存システムの置き換えは新規システム導入の3倍かかると言われていますが、今回もその通りになりました。
実際には私がPMに任命され、コンサルタントから概算見積りの説明を受けた時点で3倍かかる旨を伝え（キレられましたが・・）、その後の詳細見積りでもその通りの数字となり、契約前の集中セッションでなんとか理解いただけたので、プロジェクトとしてはコストオーバランは避けることが出来ました。
２ 見積額が高すぎたケース
次に担当した消費税率変更（5→8%）にともなう販売システムの改修プロジェクトでは、既にIT側からの見積りが出ている状態で、業務側（発注側）も了承している段階で業務側のPMとなりました。
結果→ITコストは見積りの1/3
なぜそんなに安く？
（以降、金額は適当）業務側は来たるべき消費税率変更に備え$1 mil.準備していました。どういうわけかその金額を知っていたIT側はいろいろ予備費を積み、$0.8 mil.を見積額として提示してきましたが、業務側としては予算内なのでこれを受け入れました。結局IT側の予備費を使わせることなく$0.26 mil.で完了したためみんなハッピーだったのですが、そもそもの$1 mil.が高すぎたのが大幅な乖離の原因となっています。この金額は対象システムの数とこれまでの経験から情報システム部門が導いたものですが、5を8に変えるだけの改修であればシステムの数より帳票とインターフェースの数を見るべきでした。
（ちなみに、IT側が事前に予算を知っていたというのは通常良くないですが、他の事情もあり、この会社の場合必ずしも悪とはいえません。）
このように類型見積りは大幅な誤差を生み出すことがあります。ほんの些細なパラメータ（新規 or 置き換え、システム数 or 帳票数）を変えるだけで数倍の違いが出てきます。これらパラメータをどれだけ正確に捉えられるかが、類型見積りの成否を左右すると言えるでしょう。
【連載】プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ３〜
<前記事からの続きです。
サマリー
つまるところ、ボトムアップ見積りはカレンダーの上で行う必要があるのです。いつからいつまで（From～To)、誰が、いくらで（単価）、どのくらい（ワークロード）プロジェクトに参加するのかを計算して、初めて現実的な数字が出てくるのです。PMの責任はリソースをアサインしている期間、彼・彼女達が最も効率よく稼働するよう適切に作業を組み立てることなのです。もちろん、従来の要素分解は必要です。適切に作業を組み立てるためにはどんな成果物を作り、どんな作業が必要で、どのように関連しあっているのかを理解しておく必要があります。
PMBOKでは、コスト見積りのインプットとして「スコープベースライン（WBS含む）」や「プロジェクトスケジュール」が定義されており、さらにプロジェクトスケジュール作成のために「資源カレンダー」や「アクティビティ所要時間見積り」等がインプットとして定義されているので、WBS、作業時間、リソースのカレンダーを使ってバランスよく見積りなさい、ということなのでしょう。
では、WBSは無用？
前述のとおり、適切に作業を組み立てるためにはどんな成果物を作り、どんな作業が必要で、どのように関連しあっているのかを理解しておく必要がありますので、WBSは依然有用、プロジェクトの進行に合わせて管理されるべきです。が、どの程度管理をすべきかはクライアントの要求レベルも考慮して決めると良いでしょう。通常、クライアントが欲しいのは完璧に要素分解され、各要素のコストが完全に管理されていることではなく、トータルとしてのQCDFが満たされているということなのではないでしょうか？
見積りツールについて
これらのことはMS Projectを使えば実現できますが、標準ビューのガントチャートだけではうまくいきません。それは、MS Projectは「タスクにリソース（人）を割り当てる」ことが基本となっていますが、カレンダーを基本とした見積りの場合は「リソース（人）にタスクを割り当てる」ことが基本となるからです。Task UsageやResource Usageのビューを使えばなんとかなりますが、MS Project 2010では正直もう一歩、という感じです。
結局私の場合、WBSと各作業にかかる時間の見積り（アクティビティ所要時間見積り）までMS Projectで行い、それを基に各リソースのカレンダー作成、コスト見積りからレポート作成までをExcelで行っています。いきおい、WBSは比較的ハイレベルのもので、あまり頻繁に更新する必要のないものとなります。詳細WBSは各リーダーや担当に任せ、カレンダーに定義された期間とワークロードで作業してもらうようにしています。このあたりのことは別記事で書きたいと思います。
もしEVMでの管理を行うならさらにいろいろ考慮すべきことがあります。例えば、どの粒度で作業報告をしてもらうか等です。この報告粒度より細かいレベルでのEVM管理はできませんが、その粒度が会社によって固定されていることがあります。これもまた別記事で書きたいと思います。
■連載
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - １〜
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ２〜
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ３〜 （当記事）
サマリー
つまるところ、ボトムアップ見積りはカレンダーの上で行う必要があるのです。いつからいつまで（From～To)、誰が、いくらで（単価）、どのくらい（ワークロード）プロジェクトに参加するのかを計算して、初めて現実的な数字が出てくるのです。PMの責任はリソースをアサインしている期間、彼・彼女達が最も効率よく稼働するよう適切に作業を組み立てることなのです。もちろん、従来の要素分解は必要です。適切に作業を組み立てるためにはどんな成果物を作り、どんな作業が必要で、どのように関連しあっているのかを理解しておく必要があります。
PMBOKでは、コスト見積りのインプットとして「スコープベースライン（WBS含む）」や「プロジェクトスケジュール」が定義されており、さらにプロジェクトスケジュール作成のために「資源カレンダー」や「アクティビティ所要時間見積り」等がインプットとして定義されているので、WBS、作業時間、リソースのカレンダーを使ってバランスよく見積りなさい、ということなのでしょう。
では、WBSは無用？
前述のとおり、適切に作業を組み立てるためにはどんな成果物を作り、どんな作業が必要で、どのように関連しあっているのかを理解しておく必要がありますので、WBSは依然有用、プロジェクトの進行に合わせて管理されるべきです。が、どの程度管理をすべきかはクライアントの要求レベルも考慮して決めると良いでしょう。通常、クライアントが欲しいのは完璧に要素分解され、各要素のコストが完全に管理されていることではなく、トータルとしてのQCDFが満たされているということなのではないでしょうか？
見積りツールについて
これらのことはMS Projectを使えば実現できますが、標準ビューのガントチャートだけではうまくいきません。それは、MS Projectは「タスクにリソース（人）を割り当てる」ことが基本となっていますが、カレンダーを基本とした見積りの場合は「リソース（人）にタスクを割り当てる」ことが基本となるからです。Task UsageやResource Usageのビューを使えばなんとかなりますが、MS Project 2010では正直もう一歩、という感じです。
結局私の場合、WBSと各作業にかかる時間の見積り（アクティビティ所要時間見積り）までMS Projectで行い、それを基に各リソースのカレンダー作成、コスト見積りからレポート作成までをExcelで行っています。いきおい、WBSは比較的ハイレベルのもので、あまり頻繁に更新する必要のないものとなります。詳細WBSは各リーダーや担当に任せ、カレンダーに定義された期間とワークロードで作業してもらうようにしています。このあたりのことは別記事で書きたいと思います。
もしEVMでの管理を行うならさらにいろいろ考慮すべきことがあります。例えば、どの粒度で作業報告をしてもらうか等です。この報告粒度より細かいレベルでのEVM管理はできませんが、その粒度が会社によって固定されていることがあります。これもまた別記事で書きたいと思います。
■連載
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - １〜
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ２〜
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ３〜 （当記事）
【連載】プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ２〜
<前記事からの続きです。
ボトムアップ見積りは成果物や作業を分解し、それら要素ごとに必要なリソース量を見積もって積み上げる方式です。一見もっとも確実で精緻な方法に思えますが、これだけでは実際多くのことを見落とします。
例えば、あるシステム導入プロジェクトに於いて、ネットワークの敷設（ケーブルやルーターの設置、設定を含む）が必要だとして、下記の作業および工数が見積もられたとします。
・ネットワークの概要設計（7人日）
・詳細設計（10人日）
・ケーブル工事（8人日）
・ルーター設定（3人日）
・疎通テスト（1人日）
・パフォーマンステスト（1人日）
これで合計30人日ですね。この30人日に（根拠不明の）予備を加算してお仕舞い、となります。しかしこれは実際のリソースの配置が考慮されておらず、また将来のコストコントロールの仕組みとの整合性もありません。
リソース配置の観点から
モチベーション維持やチームビルディング、契約管理を考えると、一定期間纏まった、ワークロードに波の無いアサインが望ましいです。作業がたまたま連続していれば良いですが、通常作業と作業の間には待ち時間（ラグタイム）があります。このラグタイムをどのように扱うかしっかり考えておかねばなりません。
システム導入プロジェクトの場合、通常アプリケーションの開発も伴うので、そちらの進捗と合わせる必要もあり、概要～詳細設計までは一気にできたとしても、ケーブル工事まで数か月の間が空くかもしれません。その間、プロジェクトはネットワークの担当者を完全にプロジェクトから外すでしょうか？コストがもったいないから外す！というなら、その人はプロジェクトの本質を理解していないでしょう。もしあなたが飛び石のようにプロジェクトにアサインされたら、あなたはプロジェクトの一員となりきれるでしょうか？
また、プロジェクトに変更は付き物です。ネットワークの詳細設計が終わっても、要件の変更やアプリケーション開発に伴って出てきた問題によりネットワーク設計の変更が必要になることもあり得ます。それらの変更に対応するため、詳細設計からネットワーク工事の間も、担当者がプロジェクトに参加し続けておく必要があります。ただプロジェクトべったりである必要はなく、ワークロードの10%(週に4時間)でも良いので変更管理委員会や週次会議に出席してもらい、設計に変更が必要なら対応してもらう、という関わりを維持してもらえばよいでしょう。もしこの期間が3か月なら、4時間ｘ12週＝48時間（6人日）となりますね。これは上記のWBSには出てこなかった要素ですが、カレンダーを使えば見えてきます。またこれは決して予備などではなく、予定され、実施されるべき作業です。優れたPMならこれすらWBSの要素として抽出できるかもしれませんが、WBSだけで明確な成果物を伴わない作業を全て抽出し、工数まで見積もるのは困難と言えるでしょう。
コストコントロールの観点から：コストの見積りは常時アップデートされなければならない
全ての成果物や作業を始めから見積もれることなど現実にはあり得ず、完了時予測コストも常に変化します。プロジェクトが進むにつれ出てくる細々とした予定外作業もこなしていかねばなりませんが、WBSベースの見積りをしている場合、常時変更を取り入れ、将来の予測コストをタイムリーに出し続けることがいかに困難であるか、実際にチャレンジした経験のある方ならお分かりになると思います。追加作業が既存のWBS要素に当てはまるのか、追加要素なのか、どのレベルなのかの判断すら難しい、あるいは”やってられない”ことも多いですよね。結果当初作られたWBSの更新をあきらめ、コスト見積りの予測も感覚で行われていくといういつものパターンに陥ります。こうなってしまうと、コストコントロールのみならず、スケジュールコントロール、品質コントロールも失われていると言えるでしょう。
しかしどんな作業も”いつか”、”誰かが”行うのであれば、それをカレンダーに書き込むことは可能でしょう。そしてその作業が担当者のワークロードに影響を与えるならそれを計算すればよいですし、影響を与えない程度のことであればコストも変わらないと言えるでしょう。実際、小さな追加作業くらいでコストは変わりませんが、WBSで管理していると細々と追加、再計算することになり、むしろ現実と乖離していくことすらあり得ます。それに、何かが追加になる陰で、不要になる作業もあるのです。あなたは、そんなことまで管理できますか・・？
>> 続きは後日
■連載
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - １〜
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ２〜 (当記事)
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ３〜
ボトムアップ見積りは成果物や作業を分解し、それら要素ごとに必要なリソース量を見積もって積み上げる方式です。一見もっとも確実で精緻な方法に思えますが、これだけでは実際多くのことを見落とします。
例えば、あるシステム導入プロジェクトに於いて、ネットワークの敷設（ケーブルやルーターの設置、設定を含む）が必要だとして、下記の作業および工数が見積もられたとします。
・ネットワークの概要設計（7人日）
・詳細設計（10人日）
・ケーブル工事（8人日）
・ルーター設定（3人日）
・疎通テスト（1人日）
・パフォーマンステスト（1人日）
これで合計30人日ですね。この30人日に（根拠不明の）予備を加算してお仕舞い、となります。しかしこれは実際のリソースの配置が考慮されておらず、また将来のコストコントロールの仕組みとの整合性もありません。
リソース配置の観点から
モチベーション維持やチームビルディング、契約管理を考えると、一定期間纏まった、ワークロードに波の無いアサインが望ましいです。作業がたまたま連続していれば良いですが、通常作業と作業の間には待ち時間（ラグタイム）があります。このラグタイムをどのように扱うかしっかり考えておかねばなりません。
システム導入プロジェクトの場合、通常アプリケーションの開発も伴うので、そちらの進捗と合わせる必要もあり、概要～詳細設計までは一気にできたとしても、ケーブル工事まで数か月の間が空くかもしれません。その間、プロジェクトはネットワークの担当者を完全にプロジェクトから外すでしょうか？コストがもったいないから外す！というなら、その人はプロジェクトの本質を理解していないでしょう。もしあなたが飛び石のようにプロジェクトにアサインされたら、あなたはプロジェクトの一員となりきれるでしょうか？
また、プロジェクトに変更は付き物です。ネットワークの詳細設計が終わっても、要件の変更やアプリケーション開発に伴って出てきた問題によりネットワーク設計の変更が必要になることもあり得ます。それらの変更に対応するため、詳細設計からネットワーク工事の間も、担当者がプロジェクトに参加し続けておく必要があります。ただプロジェクトべったりである必要はなく、ワークロードの10%(週に4時間)でも良いので変更管理委員会や週次会議に出席してもらい、設計に変更が必要なら対応してもらう、という関わりを維持してもらえばよいでしょう。もしこの期間が3か月なら、4時間ｘ12週＝48時間（6人日）となりますね。これは上記のWBSには出てこなかった要素ですが、カレンダーを使えば見えてきます。またこれは決して予備などではなく、予定され、実施されるべき作業です。優れたPMならこれすらWBSの要素として抽出できるかもしれませんが、WBSだけで明確な成果物を伴わない作業を全て抽出し、工数まで見積もるのは困難と言えるでしょう。
コストコントロールの観点から：コストの見積りは常時アップデートされなければならない
全ての成果物や作業を始めから見積もれることなど現実にはあり得ず、完了時予測コストも常に変化します。プロジェクトが進むにつれ出てくる細々とした予定外作業もこなしていかねばなりませんが、WBSベースの見積りをしている場合、常時変更を取り入れ、将来の予測コストをタイムリーに出し続けることがいかに困難であるか、実際にチャレンジした経験のある方ならお分かりになると思います。追加作業が既存のWBS要素に当てはまるのか、追加要素なのか、どのレベルなのかの判断すら難しい、あるいは”やってられない”ことも多いですよね。結果当初作られたWBSの更新をあきらめ、コスト見積りの予測も感覚で行われていくといういつものパターンに陥ります。こうなってしまうと、コストコントロールのみならず、スケジュールコントロール、品質コントロールも失われていると言えるでしょう。
しかしどんな作業も”いつか”、”誰かが”行うのであれば、それをカレンダーに書き込むことは可能でしょう。そしてその作業が担当者のワークロードに影響を与えるならそれを計算すればよいですし、影響を与えない程度のことであればコストも変わらないと言えるでしょう。実際、小さな追加作業くらいでコストは変わりませんが、WBSで管理していると細々と追加、再計算することになり、むしろ現実と乖離していくことすらあり得ます。それに、何かが追加になる陰で、不要になる作業もあるのです。あなたは、そんなことまで管理できますか・・？
>> 続きは後日
■連載
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - １〜
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ２〜 (当記事)
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ３〜
【連載】プロジェクトコストの見積り 〜ボトムアップ見積もり編 - １〜
プロジェクトコストの見積りを作る際、どのように行っていますか？PMBOK的にいくなら、類型見積り、係数見積り、ボトムアップ見積りまたは三点見積り等の手法を組み合わせて・・となるでしょうか。
類型見積りと係数見積りはプロジェクト開始前あるいは初期に大枠を捉えるためのものですので精度は高くなくても構わないですし、PM自身ではなく情報システ ム部や外部コンサルタントがそれらの見積りを行うこともあるかと思います。PMとして注力すべき見積りはより詳細で精度の高い見積り（ボトムアップ見積 り、三点見積り等）です。当記事ではボトムアップ見積りについて、実際の経験も踏まえて詳細に見ていきたいと思います。
ボトムアップ見積り時に考慮すべきこと
コストコントロール可能な形式であること：
ボトムアップ見積りを始めとした詳細見積りは一度見積もって終わり、というものではありません。プロジェクトの具体的な作業が見えてきた時点で一度詳細見積りを出し、 それを基に契約が行われることが多いでしょう。しかしいざプロジェクトが始まってからもコストは常に監視され、大きなかい離が発生しそうなら早急に手を打 つようにしなければなりません。所謂”コストコントロール”ですが、そのためには詳細見積りと実績が比較可能であり、かつ現状に合わせてアップデート可能 で、プロジェクト終了時点でのコスト予測が可能な仕組みを作っておく必要があります。
契約方式、チームビルディング等も考慮に入れる：
特にITプロジェクトではプロジェク トコストの大半が人のコストとなることがよくあります。人を配置した時点でコストが発生するわけですから、作業だけでなく契約方式、チームビルディングや トレーニング等も考慮に入れておかなければ、無駄なコストを垂れ流すことにもなり得ます。
>> 続きは後日。
■連載
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - １〜 （当記事）
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ２〜
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ３〜
類型見積りと係数見積りはプロジェクト開始前あるいは初期に大枠を捉えるためのものですので精度は高くなくても構わないですし、PM自身ではなく情報システ ム部や外部コンサルタントがそれらの見積りを行うこともあるかと思います。PMとして注力すべき見積りはより詳細で精度の高い見積り（ボトムアップ見積 り、三点見積り等）です。当記事ではボトムアップ見積りについて、実際の経験も踏まえて詳細に見ていきたいと思います。
ボトムアップ見積り時に考慮すべきこと
コストコントロール可能な形式であること：
ボトムアップ見積りを始めとした詳細見積りは一度見積もって終わり、というものではありません。プロジェクトの具体的な作業が見えてきた時点で一度詳細見積りを出し、 それを基に契約が行われることが多いでしょう。しかしいざプロジェクトが始まってからもコストは常に監視され、大きなかい離が発生しそうなら早急に手を打 つようにしなければなりません。所謂”コストコントロール”ですが、そのためには詳細見積りと実績が比較可能であり、かつ現状に合わせてアップデート可能 で、プロジェクト終了時点でのコスト予測が可能な仕組みを作っておく必要があります。
契約方式、チームビルディング等も考慮に入れる：
特にITプロジェクトではプロジェク トコストの大半が人のコストとなることがよくあります。人を配置した時点でコストが発生するわけですから、作業だけでなく契約方式、チームビルディングや トレーニング等も考慮に入れておかなければ、無駄なコストを垂れ流すことにもなり得ます。
>> 続きは後日。
■連載
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - １〜 （当記事）
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ２〜
プロジェクトコストの見積り 〜ボトムアップ見積もり編 - ３〜
登録:
投稿 (Atom)