■ちょっと立ち読み ＆ 目次
◆フェーズごとに、開発工程とプロセスを割り当てる
次は、開発工程とマネジメントプロセスの対応付けをする必要がある。ここでは、もっとも分かりやすい設計フェーズと開発フェーズについてＮＳプロジェクトの活動を見ていこう。
ＮＳプロジェクトはまず、ＩＳＯのプロセスを羅列してみた。Ｓ社では両フェーズを通しで、
開発準備作業
要件分析
システムアーキテクチャー設計
業務プロセス設計
システム機能設計
システム詳細設計
=======================
ソフトウエア要件分析
ソフトウエアアーキテクチャー設計
ソフトウエア詳細設計
コーティング、単体テスト
ソフトウエア結合テスト
システム統合テスト
システム適合性テスト
というプロセスの流れがある。本来は、開発プロセスは、ＰＭＢＯＫでいうところのプロダクトプロセスであるが、実際には開発マネジメントと称してマネジメントプロセスが入り混じっている。そこで、この整理からはじめる必要がある。
ＮＳプロジェクトでは、Ｙ氏と相談しながら、開発準備作業、要件分析、レビューをマネジメント作業と位置づけ、システムアーキテクチャー設計以降の作業はプロジェクト作業と整理した。つまり、
立ち上げ：開発準備作業
計画：要件分析
実行：（ここでは、プロジェクト作業として各種設計作業が実行される）
コントロール：
終結：システム詳細設計レビュー
という位置づけとした。
これで、マネジメントプロセスの流れは固まった。この流れはＰＭＢＯＫではマネジメントプロセス群であり、さらにこの中に細かなプロセスを定義していく。ここで、アクティビティ１で解説したようなさまざまな問題の解決策を埋め込んでいかなくてはならない。
（2003/09/18号より抜粋）
◆計画プロセス
計画プロセスについては、検討の結果、タスク定義、スケジュール計画、リスク計画、コミュニケーション計画、予算計画で手法を用いることとした。
［１］ＷＢＳ
すでに述べたように計画プロセスではまず、タスクの定義ににＷＢＳとＯＢＳを使う。ＷＢＳを有効に活用していくためには、ＷＢＳ作成原則が必要であるというＹ氏の指摘を受けて、以下のようなルールを作ることにした。
（１）ＷＢＳの第１層はＭＥＣＥにする
（２）個々のワークパッケージのサイズは、プロジェクト期間の１０％程度をめどにする
（３）アクティビティのサイズは進捗会議２回分の期間を前提にする。進捗会議が週１回であれば、１５日程度をアクティビティの期間的な目安とする
（４）ＯＢＳはワークパッケージではなく、責任分担に合わせて作る。結果としてワークパッケージになることが多い
（５）計画変更の手続きをＷＢＳのレベルに応じて決定する
［２］クリティカルパスによるスケジューリング
次に、スケジューリングについて検討した。この部分では、いずれ、ツールの機能に任せてしまうところなので、必要ないという意見もあったが、どういうケースがあるかを検討してから、結論を出そうということになった。
ここで、Ｙ氏がおもむろにホワイトボードにスケジュール変更の分類というタイトルの以下のような表を書いた
（Ｃ１）オーナーの了解が必要なスケジュール変更
・プロジェクトスコープの削減
・プロジェクト終了期限の延期
・要員投入，時間外勤務の導入（予算増額が必要）
・新技術の導入（予算増額が必要）
（Ｃ２）クリティカルパスで可能なスケジュール変更
・負荷超過の原因になっているタスクを余裕期間に移す
・負荷超過の原因になっているタスクを余裕期間を使って引き伸ばす
・前後関係を見直し，着手を早める
・負荷に余裕のあるメンバーに担当を変更する
（Ｃ２）の中には、ツールが自動的に処理してくれるものもあるが、前後関係の見直し、メンバー変更など、現実的によく発生する変更には人間が介在することが多い。そこで、結論として以下のような運用ルールを設定することにした。
・（Ｃ１）についてはプロジェクトだけで判断せず、社内の合意をとった上で、顧客と協議
・（Ｃ２）についてはプロジェクト内の判断にする
・アクティビティ（ワークパッケージ）の前後関係の変更は、プロジェクトの全期間を通じて要員の追加投入をしない範囲で行う
・メンバーの担当変更は、要員計画の際にスキル別のグルーピングをしておき、そのグループ内で行う
［３］リスク計画
次にリスク計画であるが、手法的にはリスクの定量化を行い、リスクの期待値評価をし、リスク戦略に照らし合わせながら、必要な対策を打つ。ここで運用上のポイントになるのは、リスク発生とみなす計画差異の大きさと、リスク戦略、予備費の全体枠の設定方法だ。計画差異については、チームでもっとも経験豊かなＲ氏の意見を尊重し、
・計画差異 １３％
とした。
さらにリスク戦略については、頻度と損失で決める、フィンクマトリクスを使い
（頻度小、損失大）：受容を基本、対策コストが低いものは緩和
（頻度大、損失大）：回避
（頻度大、損失小）：プロセス改善
（頻度小、損失小）：無視
を原則とすることにした。
また、予備費は、現実のプロジェクトでは、現実問題として予備費枠をとることが難しく、予算計画の際のアロアンスで吸収するという運用になった。
［４］コミュニケーション計画
コミュニケーション計画としてまず、議論したのは、進捗報告の方法である。最初の方針で決めたように進捗報告では、ＥＶＭを適用してみることになった。ＥＶＭの計算そのものは、現在、導入ツールの第一候補であるＸ社のＰＭツール「ＰＭプロフェッショナル」に含まれているので問題ない。
問題は運用の中で、タスクの出来高を金銭換算するところだ。ここでは、ＮＳプロジェクトのメンバーがそれぞれの考えがあり、喧々諤々の議論となった。例えば、品質保証担当のメンバーはテスト点数を換算すればいいというし、上流工程が中心のメンバーは機能数を均質化し、機能換算でよいのではないかという意見だった。
Ｙ氏のファシリテーションで議論を尽くし、結果的に以下のような問題点があることが分かった。
・機能にしろ、テストポイントにしろ、どれだけ均質化できるか
・担当者の主観が入る余地のある指標は逆効果
・細かく分析するに足るだけの見積もりの精度があるのか
といった。
この中には、今後改善していかなくてはならないものもあるが、とりあえず、この時点ではアーンドバリューの換算単位をあまり細かく設定することは意味がないという結論に落ち着き、現在の進捗報告のやり方になっている
・未着手 ０
・着手 ０．５
・完成 １．０
とし、これにアクティビティの見積もり金額をかけてアーンドバリューとすることにした。ただし、付帯条件として、アクティビティはＷＢＳで決めた１５日程度というのを正確に守り、アクティビティの工数についても平均化をしていくことにした。
進捗以外のコミュニケーションについては、その種類を定め、会議の種類、および、コミュニケーション用のフォーマットを準備することになった。ただし、そのフォーマットの運用はプロジェクトマネージャーに一任することにした。これは、そのプロジェクトのオーナー（顧客）の性格、メンバーの所属構成（Ｓ社単独の場合、他社が入る場合など）異なるため、あまり、パターン化するとコミュニケーションの硬直化につながるという意見が多かったからだ。
フォーマットについては、
プロジェクトマネージャー養成塾
＞プロジェクトマネージャー養成マガジンプロフェッショナルメニュー
（http://www.infoscape.jp/tms/pm/juku/index.htm の一番下）
にあるので参考にしてほしい。このメニューにアクセスするには以下のユーザＩＤとパスワードが必要（立ち読み版からはアクセスできません）。
さらに、コミュニケーションの問題としては、情報セキュリティの議論がでてきた。各情報の開示範囲である。レッスンラーンドの導入に絡んでくるが、あるプロジェクトでの失敗を別のプロジェクトで教訓にしたいというニーズに基づくものだ。
これについても、かなり議論したが、結論が出なかった。結論の出なかった理由は、これもはやり、相手によるので、一般論としては決めにくいということだった。この問題については、１年後の見直しの際に再検討することとし、現在は、プロジェクトの管理ドキュメントについては、プロジェクト外への持ち出しは禁止という従来の方針からの方針のままで進めることになった。
［５］予算計画
予算計画の策定については、特に運用ルールは必要ないという意見があったが、そんな中でも、資材・経理担当メンバーから予算表のスパンを統一してほしいという意見が出てきた。予算表の単位が２週間のものもあれば、３ヶ月のものもあり、実際の調達作業やキャッシュが発生する時点が読みきれないという苦情に近い意見だった。
プロジェクトマネージャー側からも、予算の管理スパンはプロジェクトの期間によって変わるので、それは難しいという反論が出てきた。
どちらももっともな意見であったが、今回、アクティビティの期間を１５日と決めたので、１５日（半月）単位で、目安となるサブの予算計画を必ず作ることにした。サブの計画という意味は、例えば、１ヶ月のスパンの予算表であれば、努力目標として１５日ごとの計画をできるだけキープするという意味だ。これで、資材・経理担当も、プロジェクトマネージャー担当者も一応、合意した。
（2003/10/02,09号より抜粋）
■９月号（プロセス５） 目次
■アクティビティ１：問題の顕在化と分析
■アクティビティ２：プロジェクトマネジメント導入のための調査
■アクティビティ３：マネジメントプロセスの設計（１）
■アクティビティ４：マネジメントプロセスの設計（２）
■アクティビティ５：手法、ツールの選定（１）
■アクティビティ６：手法、ツールの選定（２）
■アクティビティ７：導入への取り組みと定着
■アクティビティ８：改善し、発展させる
> 2003/09/04 アクティビティ１ 問題の顕在化と分析
◆はじめに
◆Ｓ社の経緯
◆現状の調査
◆分析結果と施策
> 2003/09/11 アクティビティ２ コミュニケーションの計画手順
◆プロジェクトマネジメントの位置づけ
◆問題点の洗い出し（診断）
◆原因の分析
◆プロジェクトマネジメントが解決する課題設定
◆インタビューで確認
> 2003/09/18 アクティビティ３ プロジェクトにおけるコミュニケーションの仕組
み
◆ＰＭＢＯＫのプロセスについて
◆フェーズの設定
◆フェーズごとに、開発工程とプロセスを割り当てる
> 2003/09/25 アクティビティ４ プロアクティブなコミュニケーションの土壌作り
◆開発プロセスとプロジェクトマネジメントプロセスの関係
◆立ち上げプロセス
◆計画プロセス
◆コントロールプロセス
◆実行プロセス
◆終結プロセス
> 2003/10/02 アクティビティ５ 手法、ツールの選定（１）
◆プロセス５前半の復習
◆手法とツール
◆立ち上げプロセスに必要な手法と運用ルール
◆計画プロセス
> 2003/10/09 アクティビティ６ 手法、ツールの選定（２）
◆計画プロセス（前回の続き）
◆コントロールプロセス
◆実行プロセス
◆終結プロセス
> 2003/10/16 アクティビティ３ 導入への取り組みと定着
◆導入の進め方
◆ＰＭオフィス
◆導入
> 2003/10/23 アクティビティ４ 改善し、発展させる
◆いよいよ走り出す
◆Ｋ社プロジェクト（期間５ヶ月、予算３０００万円）
◆Ｔ社プロジェクト（期間６ヶ月、予算１億２０００万円）
◆Ａ社プロジェクト（期間５ヶ月、予算８０００万円）
◆継続的改善
