プロジェクトマネジメントの最近のブログ記事

昨今、プロジェクトマネジメントの重要性が強く言われています。プロジェクトマネジメントは、計画を達成するためのマネジメントに焦点を合わせています。しかし、プロジェクトマネジメント方法を導入したけど、プロジェクトが失敗することが多のも事実です。そして、コミュニケーションの方がプロジェクト成功には重要であると、強調されることも多くなってきました。一概にコミュニケーションが重要であると頭では分かっていても、どのように実践すればコミュニケーションを活性化できるかということが分かりません。

そこで、プロジェクトファシリテーションの登場です。

プロジェクトファシリテーションは、チームメンバーの間に協調的な雰囲気を作り、協同作業を遂行させることに焦点を当てています。

プロジェクトマネジメントは、計画の作成と実行を中心としたマネジメントであり、プロジェクトファシリテーションは、状況の変化に対応し、チームが協力し合って創発的に成果を出していく、「リーダーシップ･コラボレーション型」の新しいマネジメントであると言うことができます。

重要なことは、両者が対立する考え方ではなく、補完し合う関係であると言うことです。プロジェクトマネジメントが、ハードスキルが中心であるとすれば（厳密にはそうではありませんが）、プロジェクトファシリテーションは、ソフトスキルが中心だと言うことができます。自動車は4輪が共同して動くことで前進するように、プロジェクトマネジメントとプロジェクトファシリテーションが両輪となり、プロジェクトを推進していかなければなりません。

PMP試験基本問題集のPDF版に加え、新たにePub版が登場しました。

EPUB（イーパブ）は、電子書籍の規格の1つで、米国の電子書籍の標準化団体の1つであるInternational Digital Publishing Forum（IDPF、国際電子出版フォーラム）が普及促進している公開された仕様の電子書籍用ファイル・フォーマット規格です。「EPUB」は"Electronic PUBlication"の意味を持ち「epub」「ePub」などと表記される場合もある。そのオープン性と単純さから、対応する電子書籍のハードウェアやアプリケーションソフトウェアは多く、英語圏での標準規格となりつつあります。（ウィキペディアEPUBより。）

今回のePub対応により、iPhone、iPadや、Androidなどのスマートフォン、タブレットで使用可能となります。従来のPDF版よりは、ePub版の方が、格段に操作性が良くなりますので、スマートフォンを所有して、PMP受験を目指している方は、こちらをご活用ください。

ご購入は、supreme123.com PMP試験　基本問題集－ePub版よりお願いします。

PMBOK第4版対応のPMP試験 基本問題集を販売することになりました。これは、弊社のPMP受験対策講座の実践編で使用されている問題集です。

この問題集は、PMP受験対策のため、プロジェクトマネジメント知識体系ガイド（以下、PMBOK）第4版を既に読まれている方で、PMP受験のための勉強をしている方を対象に、PMBOKの理解度を測る目的で作成されています。

すべての問題は、PMBOKに掲載されている内容から同じ言葉、文章を用いて作成されています。従って、理解度、暗記度を測るには最適な問題集です。PMP試験には、この基本問題集のような暗記系の問題のほかに、状況に応じた応用問題などが出題されますので、この基本問題集だけではPMP合格は難しいです。

問題の解答は、各章の後半に載せてあります。解答は、該当するPMBOKのページ番号と、セクションの内容が記述されていますので、PMBOKがなくても理解することができます。しかし、不正解の問題は、PMBOKの当該ページを当たり、理解を深めることが肝心です。

受験直前までには、基本問題集の最低90%の正解率を確保するまでがんばってください。

今回の変更点は、第3版への変更のような大きな変更はありません。プロセスレベルの変更は、以下の通りです。プロセス内のインプット、ツールと技法、アウトプットに関しては、細かな変更がありますが、ここでは主要な変更だけをリストアップしておきます。ただし、それらの日本語はまだ公開されていないので、英語版を見て、勝手に翻訳しています。

統合マネジメント： プロセス数が7個から6個に削減されています。

• プロジェクト憲章作成の中で、プロジェクト選定基準がツールと技法から削除されました。
• プロジェクトスコープ記述書暫定版作成が削除されました。
• プロジェクト終結が、プロジェクトやフェーズの終結に変更されました。

スコープマネジメント：　プロセス数が1個削除され、1個追加されています。

• スコープ計画が、要求事項定義に変更されました。アウトプットとして、要求事項文書（Requirements documentation）と要求事項マネジメント計画書（Requirements management plan）です。

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プロジェクトで、品質とは、どのような意味があるでしょうか。

バグのないシステムを作る？
ユーザーの要求水準を満たす？
発生した課題がすべて解消される？