今回の変更点は、第3版への変更のような大きな変更はありません。プロセスレベルの変更は、以下の通りです。プロセス内のインプット、ツールと技法、アウトプットに関しては、細かな変更がありますが、ここでは主要な変更だけをリストアップしておきます。ただし、それらの日本語はまだ公開されていないので、英語版を見て、勝手に翻訳しています。
統合マネジメント： プロセス数が7個から6個に削減されています。
スコープマネジメント： プロセス数が1個削除され、1個追加されています。
2008年12月31日にPMBOK第4版が公開されました。第4版のドラフトが2008年1月に公開され、ドラフトに対する意見を反映しての変更です。現在のところ、英語版しか全内容が網羅されていません。各国語版は、2009年3月31日に公開される予定です。日本語版は、第1部のフレームワークと用語集が翻訳されています。
これにより、PMP試験は、2009年6月31日まではPMBOK第3版をベースに行われ、それ以降はPMBOK第4版をベースに行われます。
データ復旧プロセスの評価 で以前にもお伝えしましたが、日経SYSTEMS 3月号の特集1「プロジェクトの記録を残そう－完了報告書の作り方」で弊社プロジェクトマネジメントテンプレートが紹介されました。
今回紹介されたのは、全てのテンプレートではなく、プロジェクト終結キットに入っているプロジェクト完了報告書です。ただし、誌面に紹介されているイメージは、ほんの1部分ですが。
それと私のインタビュー内容も記事内容に含まれています。3月号の24～25ページあたりにそれが載っていますので、日経SYSTEMSがお手元にある方はご覧ください。
また、PDFファイルとして配布可能かどうかを日経BP社に問い合わせしようと考えていますので、了解が得られたら、その準備をしますので、ご期待ください。
追記：記事内容がITProサイトに掲載されました。記事内容は、プロジェクトの記録を残そうをご覧ください。
いよいよ、大詰めを迎え、プロジェクトのカットオーバーとなりました。
カットオーバーするためには、当然、最後の大きな作業を行わなければなりません。
そうです。データ移行です。
データ移行には、大きく分けてマスタデータとトランザクションデータの2種類あります。
プロジェクトが佳境に入り、ある程度の成果物ができました。その成果物の検収を受ける段階になって問題となるのが品質です。
PMBOK流に言うと、品質とは、ユーザの要求仕様に合致していることを言います。品質マネジメントに、品質保証と品質コントロールというプロセスがあります。
品質保証とは、品質計画で定められた手順、基準どおりに行なわれているかどうかをチェックすることです。品質コントロールとは、品質計画で決められた目標水準に達しているかどうかをチェックし、達していなければ改善することを意味します。
つまり、品質保証は、正しく行なわれているかどうかを見ること、品質コントロールは、要求水準に達しているかどうかを見ることです。
この2つのプロセスを通して、プロジェクトで正しいことが行なわれているようにすることを品質マネジメントと定義しています。
しかし、本当でしょうか？
プロジェクトコミュニケーションについて、考えたことがありますか？
当然、あるぞ！と答えが返ってきますよね！
PMBOKでは、コミュニケーション計画を立て、それに基づいた情報配布を行い、実績報告をして、ステークホルダーマネジメントをするというプロセスで説明されています。
しかし、最近、もっと違うことがあるのではないかと思い始めています。
プロジェクトマネジメントテンプレートを改定し、販売を開始しました。名称も、Workflow@ProjectManagementという長ったらしいものから、【 PM123 】と変更しました。プロジェクトマネジメントを123...と簡単にできるという意味をこめています。また、価格も改定しました。
詳細は、PM123 - プロジェクトのマネジメントをご覧ください。
いきなり、質問です。
あなたは、他のチーム、メンバーが行なっていることを把握していますか？
小規模なプロジェクトでは当然把握できていると思います。しかし、複数のチームが編成され、中規模、大規模になればなるほど、他のチームが行なっていることが見えなくなってきます。
これを避けるために進捗会議などが持たれるのですが、それでも週1回程度です。他のチームと連携した作業をする場合は、頻繁にミーティングを持たなければなりません。
キックオフも終わり、プロジェクトが軌道を進み始めました。プロジェクトが計画通りに進むかどうかは、プロジェクトチームにかかっています。
プロジェクトマネジメントの技法だけを活用してもプロジェクトは成功しないことは、皆さんもご存知の通りです。リーダーシップ不在では、プロジェクトはうまく行きません。
プロジェクトマネジャーの仕事の大半が、コミュニケーションだといわれています。仕事の60%～90%程度までがコミュニケーションだといわれています。
計画フェーズについて私の考えを書いてきましたが、ここらで、計画フェーズは終了し、これから実行フェーズに入って行きたいと思います。
実行フェーズに入ると計画したことを実行に移すわけですが、ここからが、プロジェクトマネジメントの本番です。
最初は、キックオフを行なわなければならないのですが、キックオフで明確にしなければならないことは、何でしょうか。
ITプロジェクトでは、なぜか、しっかりとしたリスク計画を作っていません。言葉では、リスク、リスクといっていますが、明確にリスクを定義しているプロジェクトにお目にかかったことがありません。
私自身も、やはり、明確に文書を作成して管理した経験はありません。プロマネをしながら、状況を判断して、次にこんなことが起こるのではないかと予測をつけて、それが起こらないように対策を講じるだけです。
KKD（勘、経験、度胸）という昔から言われているプロジェクトマネジメントの真髄（？）に頼っているだけです。
一般的に言えば、品質とは、成果物に対する品質と、プロセスに対する品質の2種類あります。品質といえば、成果物に対する品質ばかりに目が行きがちですが、プロセスの品質を保つことも重要なポイントです。
ITプロジェクトで、品質とは、どのような意味があるでしょうか。
バグのないシステムを作る？
ユーザーの要求水準を満たす？
発生した課題がすべて解消される？
「先生、質問があります。こんなに詳細な計画を立てるのに、なぜ、失敗するITプロジェクトが多いのですか？」
私が非常勤講師をしている北海道大学大学院生から授業の最後で、投げかけられた鋭い質問です。
皆さんは、どう回答しますか？
今日は、一連のプロジェクト計画作成をお休みして、この質問について、考えてみたいと思います。
東証で、システム障害が起こり、売買ができなくなる事態が発生しました。8月には、ジャスダックでもシステム障害で、同様の事態となりました。
最初ニュースを聞いたとき、やはり、「どこが作ったシステム化？」という疑問がすぐに浮かびましたが、名前を公表された富士通さんには、同情します。
別に富士通さんの肩を持つわけではありませんが、この対応に相当の費用をかけなければならない事態に追い込まれていると推測します。
どんなに完璧なシステム構築をしても、100%バグのないシステムは存在しません。あらゆるテストを行なっても、稼動後に、想定外のものが出てきます。
重要なことは、バグの原因を作った者を特定することではなく、障害が起こったときに、どう対応するか、予め計画しておくことです。これは、リスク管理の一部でもあります。
リスク管理については、後日書くとして、今回は、予算作成です。
スケジュールを作成すると同時並行で、各アクティビティに必要な資源を見積もらなければなりません。
特に大きなものが、プロジェクトメンバーです。
必要なプロジェクトメンバーのスキル、必要技術等を列挙し、当てはめていきます。
必要なメンバーを確保できない場合もありますので、代替案を作成するのは言うまでもありません。
確保できるかどうかで、スケジュールも変更されますので、作成したスケジュールは、今時点では、暫定版であると考えてください。
また、必要メンバーの役割、責任を明確にしなければなりません。
OBS （Organizational Breakdown Structure, 組織ブレークダウンストラクチャ）を作成し、プロジェクト内での位置づけを明らかにします。
