Global Knowledge Japan

グローバルナレッジ PM道場
ホーム > グローバルナレッジ PM道場 > PMBOKⓇガイド入門

【PMBOK®ガイド入門】第29回:WBS作成プロセス その1

前々回のコラムで「要求事項収集プロセス」前回のコラムで「スコープ定義プロセス」の内容をお伝えしました。これら2つのプロセスで、プロジェクトの要求事項とスコープ(※) は明確になっているはずです。
※プロジェクトで作り上げる成果物を含め、プロジェクトでやること全てをスコープと言います

しかし、それだけでは具体的な作業に着手することはできません。スコープを管理可能なレベルまで分解する必要があります。管理可能なレベルとは、「ここまで分解しておけば、スケジュールを立てて進捗管理ができる」とか、「ここまで分解しておけば、適切な要員をアサインできる」といったレベルです。

たとえば、「現在は紙で起票し手渡しで回覧している稟議書を電子化する」というプロジェクトがあったとします。
これを実現するためには、まず現状把握をしなければなりません。現状把握をするためには、最低でも「現在使用している稟議書の一覧」「現在の業務フロー」あたりは必要になるのではないでしょうか。
さらに現在の業務フローが部門ごとに異なっているのであれば「総務部の業務フロー」「営業部の業務フロー」「経理部の業務フロー」といった具合に、部門ごとの業務フローが必要になってきます。
ここまで分解した時点で、「管理可能である」と判断したなら、そこまでで分解を止めれば良いわけです。なお、分解した最下層のことを「ワークパッケージ」と呼びます。

このようにして、プロジェクトで実施することを管理可能なレベルまで分解したものをWBS(Work Breakdown Structure)と言います。Work=お仕事を、Breakdown=分解して、Structure=構造化したものが、WBSです。構造化するというのは、言い換えれば「見える化」するということです。上述の通り「管理可能なレベル」まで分解しているので、分解した末端のワークパッケージは、誰にとってもその内容が分かりやすいものになっていなければなりません。

<推奨コース>
【PDU対象】プロジェクトマネジメント(前編) ~しっかりした計画作り・PMBOK(R)Guide第5版対応~
このコースでは、WBSを含むプロジェクト計画の全体像を学びます。特に重要なWBS、スケジュール、コスト、リスク等については講義だけでなく、演習を通じてしっかりと学ぶことができます。

執筆:横山 昇 [PMBOKⓇガイド入門][2017年8月 9日配信]

【PMBOK®ガイド入門】第28回:スコープ定義プロセス

前回のコラム(第27回:要求事項収集プロセス) で「要求事項収集プロセス」の内容をお伝えしました。このプロセスでプロジェクトの要求事項は明確になっているはずです。
今回お伝えする「スコープ定義プロセス」では、「要求事項を満たすためにどのような成果物を生成するのか」を明確にします。

成果物の姿を明確にするやり方は、成果物によって最適な方法があります。たとえばオンラインショッピングのためのショッピングサイトを構築するプロジェクトであれば、ショッピングサイトの画面デザイン案を複数提示し、それを元にイメージを固めていく、といったやり方があるでしょうし、工業製品であれば、手にとって形や使い勝手を確認できるモックアップを使って製品の形状を固めていく、といったやり方があるでしょう。

プロジェクトで作り上げる成果物を含め、プロジェクトでやること全てが「スコープ」ですが、「スコープ外」のこと、すなわち「このプロジェクトでは実施しないこと=除外事項」もこの段階で明確にしておく必要があります。

こういった点についてきちんとコミュニケーションを取れていないと、プロジェクトの終了間際になって「これは当然やってくれると思っていたのに」「いや、それはそもそもやることに含まれていなかった(あるいはそちらでやってくれると考えていた)」という、思わぬ認識齟齬が出てきてしまう恐れがあります。


<推奨コース>
【PDU対象】要件定義のためのコミュニケーション術 ~要望・要件を引き出すヒアリングのポイント~
情報システム構築の要ともいえる要件定義においては、システム知識や業務知識そのものに加えて顧客や情報システム担当者との効果的なコミュニケーションを図ることが重要です。本コースでは、要件定義をスムーズに進めるために必要なスキルについて解説し、コミュニケーションにポイントを絞った演習を行います。

執筆:横山 昇 [PMBOKⓇガイド入門][2017年7月12日配信]

【PMBOK®ガイド入門】第27回:要求事項収集プロセス

前回のコラムで「スコープ・マネジメント計画プロセス」の内容をお伝えしました。このプロセスで、「どのように要求事項を収集するのか?」を明確にしているはずですので、それに従って要求事項を収集するのが、今回ご紹介する「要求事項収集プロセス」です。

要求事項を収集する方法はいくつもあります。一般的な方法としては「インタビューをする」「アンケートを取る」といったものが挙げられます。
そうして収集した情報は、いつでも取り出したり、参照したりすることができるよう、整理しておく必要があります。整理するやり方の一つとして、このプロセスのアウトプットの一つである「要求事項トレーサビリティ・マトリックス」があります。トレーサビリティとは、トレースとアビリティが合わさった単語なので、言うなれば「要求事項を追跡することができるようにするための表」ということになります。

もう少し具体的に言うと、要求事項の起点から、要求事項を満たす成果物に至るまでを結び付ける表のことです。たとえば、WEBのショッピングサイトを構築するプロジェクトで、「24時間365日オープンとする」という要求事項があったとします。それが設計書やインフラ設備にそれがきちんと反映されているかを、要求事項トレーサビリティ・マトリックスを使って確認する、という使い方をします。

<推奨コース>
【PDU対象】要件定義のためのコミュニケーション術 ~要望・要件を引き出すヒアリングのポイント~
情報システム構築の要ともいえる要件定義においては、システム知識や業務知識そのものに加えて顧客や情報システム担当者との効果的なコミュニケーションを図ることが重要です。本コースでは、要件定義をスムーズに進めるために必要なスキルについて解説し、コミュニケーションにポイントを絞った演習を行います。

執筆:横山 昇 [PMBOKⓇガイド入門][2017年6月14日配信]

【PMBOK®ガイド入門】第26回:スコープ・マネジメント計画プロセス

今回から、計画プロセス群×プロジェクト・スコープ・マネジメント知識エリアの説明に入ります。ここには、4つのプロセスがあります。最初は「スコープ・マネジメント計画プロセス」になります。

このプロセスでは「スコープをどのように定義し、どのように確認し、どのように管理するか」を明確にします。もう少し具体的に申しますと、「プロジェクト・スコープ・マネジメント知識エリアにおける、それ以降のプロセスをどのように進めていくのか」を明確にします。
このプロセスの後に、「要求事項収集プロセス」「スコープ定義プロセス」「WBS作成プロセス」という3つのプロセスが続きます。これらをどう進めていくか、すなわち

  • どのようにして要求事項を収集するのか? - インタビューするのか?アンケートを取るのか?
  • スコープをどのように定義するのか? - 関係者全員が同じ成果物イメージを描けるようになるために、どのような進め方が有効なのか?
  • WBSはどのように作成するのが良いのか? - 過去に作ったWBSを参考に作れば良いのか?あるいは1から作る必要があるのか?
といったことを、この段階で決めておくわけです。

さらには、
  • 成果物の受け入れをどのように進めるか?(スコープ妥当性確認プロセス)
  • スコープが際限なく広がってしまうのをどのように防ぐか?(スコープ・コントロール・プロセス)
といった点まで明確にしておきます。

これらを計画の初期段階で明確にしておくことが、後々プロジェクトをスムーズに進めていくための一助になります。

<推奨コース>
【PDU対象】PMBOK(R)Guide第5版概要 ~プロジェクトマネジメントのグローバル・スタンダードを学ぶ~
このコースでは、PMBOK(R)Guideで定義されている47プロセスを網羅的に学習します。その中で、今回お伝えしたスコープ・マネジメント計画プロセスを含む、それぞれのプロセス間の関係性を確認することができます。

執筆:横山 昇 [PMBOKⓇガイド入門][2017年5月17日配信]

【PMBOK®ガイド入門】第25回:プロジェクトマネジメント計画書作成プロセス

今回からいよいよ計画のプロセス群に入ります。PMBOK(R) Guide第5版の計画プロセス群には、24のプロセスがあります。今日はプロジェクト統合マネジメントの知識エリアにある「プロジェクトマネジメント計画書作成プロセス」についてお話しします。

このプロセスでは、「すべての補助の計画書を包括的なプロジェクトマネジメント計画書に統合」します。補助の計画書とは、「スコープ」「タイム」「コスト」といった各々の知識エリアからアウトプットされる計画書です。また「特定の知識エリアのみに依存するものではないが、計画時に決めておくべきもの」についても、このプロセスで作成します。その代表例が「変更マネジメント計画書」です。

プロジェクトには変更が付き物です。「変更がないプロジェクトはない」と言われることがあるほどです。従って、計画段階で変更をどう取り扱うかを決めておかないと、プロジェクトに大きな影響を及ぼす可能性があります。たとえば、プロジェクトマネジャーのあずかり知らぬところで勝手に機能追加、変更等が行われるようなことがあると、プロジェクト全体が大混乱に陥る可能性があります。そうならないための決め事、たとえば「変更要求書のフォーマット」「変更を受け付ける窓口」「受け付けた変更の審査手順」などを、この変更マネジメント計画書で明確にしておく必要があります。

<推奨コース>
【PDU対象】PMBOK(R)Guideベースのプロジェクトマネジメント計画書作成
このコースでは、PMBOK(R)Guideに記述されている各種マネジメント計画書を1種ずつ作成し、更に統合することで漏れのない整合性のとれたプロジェクトマネジメント計画書作成を目指します。

執筆:横山 昇 [PMBOKⓇガイド入門][2017年4月12日配信]

【PMBOK®ガイド入門】第24回:ステークホルダー特定プロセス

PMBOK(R) Guide第5版の立上げプロセス群には、前回ご紹介した「プロジェクト憲章作成プロセス」以外にもう一つプロセスがあります。それが今日ご紹介する「ステークホルダー特定プロセス」です。

このプロセスでは、「ステークホルダーを特定し、プロジェクトに対するステークホルダーの利害、影響を分析」します。ステークホルダーの定義については、第11回および第12回に記載してありますので、そちらをご覧ください。

プロジェクトの体制図に出てくる人だけがステークホルダーとは限りません。たとえば、体制図には入っていないのですが、やたらとプロジェクトに口をはさみたがる役員がいた場合、その役員の発言がプロジェクトに思わぬ影響を及ぼすことも起こりえます。そのような場合、その役員と対等な立場にいる別の役員を味方につけておくことで、過度の干渉を防ぐことができるかもしれません。
このように、ステークホルダーを明らかにしたうえで、プロジェクトへの影響を分析しておくことが、このプロセスで実施すべきことです。

PMBOK(R) Guide第5版では、特定、分析した結果を「ステークホルダー登録簿」という形でアウトプットするよう定義しています。さすがにそこまで実施するのは難しいかもしれませんが、プロジェクトの当初に「あの役員は要注意人物だな」とか、「技術畑出身の役員だから、技術に関してはごまかしがきかない、慎重にいこう」とかいった対応を、プロジェクトの主要メンバー間である程度認識合わせをしておくことが重要です。

<推奨コース>
ステークホルダーマネジメントの定石として、PMBOK(R) Guideでは「ステークホルダーを特定し、分析した上で、ステークホルダーにどうなってほしいかを明確にし、そうなってもらうためにどのようにステークホルダーマネジメントをしていくか(ステークホルダーとどうお付き合いをしていくか)を決める」というやり方を提示しています。とは言っても、PMBOK(R) Guideはあくまで「ガイド」であり、具体的な手法まではあまり触れていません。このコースは、PMBOK(R) Guideの記述になぞらえつつ、具体的にどうすべきかを演習やロールプレイを通じて学ぶコースです。


執筆:横山 昇 [PMBOKⓇガイド入門][2017年3月14日配信]

【PMBOK®ガイド入門】第23回:プロジェクト憲章作成プロセス

今回のコラムから、いよいよPMBOK(R) Guide5版で規定している47個のプロセスについて、1個ずつ言及してまいります。まずは「プロジェクト憲章作成」プロセスです。

 

簡潔に申しますと、このプロセスは「プロジェクト実施の承認を得る」ためのプロセスです。プロジェクトを実施するには、人、金、時間等、多くのリソースが必要になります。従って、組織の中でそのプロジェクトを実施しようと考えたら、まずは組織の承認を得なければなりません。そのためのプロセスがこのプロジェクト憲章作成です。

 

憲章の「憲」が、「憲法」の「憲」なので、何か大仰なものに感じられるかもしれません。しかし、たとえ部分的にでもプロジェクトの立ち上げから携わったことのある方なら、組織の承認を得るための社内手続きを進めたことがあるのではないでしょうか。あるいは、先輩社員や上席者が手続きを進めるのを手伝う、あるいは見聞きしたことがあるのではないでしょうか。具体例を申しますと、「プロジェクト実施の承認を得るため、所定の手続きに沿って稟議をまわす」というのは、まさしく「プロジェクト憲章作成」プロセスに該当します。

 

プロジェクトの承認を得るにあたっては、皆様が所属されている組織(会社、事業部、部門等)のルールがあると思いますので、それに従って進めて頂くのが最善です。ご参考までにPMBOK(R) Guide 5版では、プロジェクト憲章に記述すべき内容として、以下のような項目を挙げています。(以下、PMBOK(R) Guide5版に記載されている内容から、著者が特に重要だと認識しているものを抜粋します。)

 

 プロジェクトの目的または正当性

 測定可能なプロジェクト目標と関連する成功基準

 ハイレベルの要求事項

 前提条件と制約条件

 要約マイルストーン・スケジュール

 要約予算

 

推奨コース

PMC0117G

PDU対象】【現場体験型】PMと営業のための企画・提案力 ~プロジェクト成功の鍵~

上記コースは、ケーススタディにより、プロジェクトの企画・提案段階に潜む失敗要因を認識します。その上で、プロジェクトマネジャーあるいは営業がビジネスの重要局面において、プロジェクト管理技術・営業活動技術の重要点を踏まえた行動を取れるようになることを目指します。重要点の講義とケーススタディ・演習で構成されたコースです。


執筆:横山 昇 [PMBOKⓇガイド入門][2017年2月14日配信]

【PMBOK®ガイド入門】第22回:プロジェクトマネジメント・知識エリア

前回のコラムでは、10個のプロジェクトマネジメント・知識エリアのうち、前半5個についてお伝えしました。今回は後半5個についてお伝えします。

 

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

プロジェクト・チームを組織し、マネジメントし、リードするためのプロセスから成ります。たとえば、プロジェクトの計画段階で組織体制(組織図)を明確にし、実際にプロジェクトの成果物を作成していく段階になったら、チームとして機能するよう、「モチベーションをキープする」「コンフリクトを解消する」といった対応が必要になります。


【プロジェクト・コミュニケーション・マネジメント】

プロジェクト情報の生成、収集、配布、保管、検索、最終的な廃棄等を適切かつ確実に行うプロセスからなります。たとえば、「会議体の運営ルールや情報の伝達ルールを決める」というのはこの知識エリアで実施すべき事項になります。それだけでなく、情報の伝達が上手くいかないのであれば、伝達の仕方を変える、たとえば「メールベースではなく対面での情報伝達をメインにする」といった対応が必要になります。


【プロジェクト・リスク・マネジメント】

リスクとは、「もし発生すれば、プロジェクト目標にプラスやマイナスの影響を与える不確実な事象あるいは状態のこと」と定義されています。このリスクをマネジメントする、すなわちリスクの洗出し、分析、対応計画の立案、状況の監視等を実施するプロセスからなります。もう少し具体的に言うと、リスクを洗い出し、対応の優先順位を決め、発生しても困らないように対策を立てておく必要があります。そして「起こるかどうかは分からない」のがリスクなので、プロジェクト期間中は「発現の兆候がないか」等、監視を続ける必要があります。


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

作業の実行に必要なプロダクト、サービス、所産を外部から購入または取得するプロセスからなります。もう少し具体的に言うと、プロジェクトの遂行に必要な人、物を「どこから」「どのように」調達するかを決定し、必要なものが納品されるよう、外部のパートナーを適切にリードしていく必要があります


【プロジェクト・ステークホルダー・マネジメント】

ステークホルダーを特定、分析し、効果的に関与させるよう、適切にマネジメントするプロセスからなります。ステークホルダーにどう相対していくかは、プロジェクトの成否を決める重要なファクターの1つです。この知識エリアは、PMBOK(R)Guide5版で新たに追加されました。ステークホルダー・マネジメントの重要性が高まっていることを示しています。

 

推奨コース

PMC0096G

PDU対象】PMBOK(R)Guide5版概要 ~プロジェクトマネジメントのグローバル・スタンダードを学ぶ~


このコースでは、全てのプロジェクトマネジメント・プロセスを網羅的に確認していきます。PMBOK(R)Guideの概観と、11つのプロセスで何をすべきなのかといった詳細を学習したいという方に最適なコースです。


執筆:横山 昇 [PMBOKⓇガイド入門][2017年1月17日配信]

【PMBOK®ガイド入門】第21回:プロジェクトマネジメント・知識エリア

まず前回のコラムでお伝えした内容を簡単に復習しておきましょう。

【1】 PMBOK®ガイド第5版では47のプロセスが規定されている。

【2】それらのプロセスは5個のプロジェクトマネジメント・プロセス群と10個のプロジェクトマネジメント・知識エリアに区分けされる。

【3】もう少し具体的に言うと、横5(プロセス群)×縦10(知識エリア)のマス目の中に、47のプロセスが配置されている。


前回のコラムでは、5個のプロジェクトマネジメント・プロセス群についてお伝えしました。今回は10個のプロジェクトマネジメント・知識エリアのうち、前半5個についてお伝えします。

 

【プロジェクト統合マネジメント】

プロジェクトにおける要求事項を満たすために不可欠な、統一、集約、明確化、統合的な処置を行うプロセスから成ります。たとえば、変更を受け付ける窓口を一本化したり(変更マネジメントの一部)、成果物の版管理の仕方を明確にしたり(コンフィギュレーションマネジメントの一部)・・・といったことができていないと、プロジェクトが混乱に陥り、要求事項を満たせなくなってしまう恐れがあります。


【プロジェクト・スコープ・マネジメント】

プロジェクトを成功させるために必要な全ての作業を明確にするためのプロセスから成ります。たとえばプロジェクトにおける除外事項や、責任分界点を定めておかないと、プロジェクト関係者間で認識齟齬が起こり、思わぬ作業漏れが出てしまう恐れがあります。


【プロジェクト・タイム・マネジメント】

プロジェクトを所定の期間内に完了させるために必要なプロセスから成ります。実現可能なスケジュールを立てるのはもちろんのこと、どのように進捗管理を行うのかを明確にしておかないと、遅れの発見が遅れて、プロジェクトの進捗に悪影響を及ぼす恐れがあります。


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

プロジェクトを承認済みの予算内で完了させるために必要なプロセスから成ります。「トータルでいくらかかるのか?」を明確にしておくのはもちろん重要ですが、「いつ、どのくらいコストが出ていくのか」を明確にしておかないと、コスト超過に陥ってしまう恐れがあります。


【プロジェクト品質マネジメント】

品質方針、品質目標、品質に対する責任等を決定するプロセスから成ります。たとえば出来上がった成果物に対してテストを行ったとしても、その結果を判断する基準(品質目標)がなければ、成果物の出来の良し悪しを判断することが困難になってしまいます。



推奨コース

PMC0096G

PDU対象】PMBOK(R)Guide5版概要 ~プロジェクトマネジメントのグローバル・スタンダードを学ぶ~

 

このコースでは、全てのプロジェクトマネジメント・プロセスを網羅的に確認していきます。PMBOK®ガイドの概観と、11つのプロセスで何をすべきなのかといった詳細を学習したいという方に最適なコースです。


執筆:横山 昇 [PMBOKⓇガイド入門][2016年12月12日配信]

【PMBOK®ガイド入門】第20回:プロジェクトマネジメント・プロセス群

前回、前々回のコラムではPMBOK®ガイドで規定されているプロセスの概観に関して述べてきました。その中でお伝えしてきたように、PMBOK®ガイド第5版では47のプロセスが規定されています。

そして、それらのプロセスは5個のプロジェクトマネジメント・プロセス群と10個のプロジェクトマネジメント・知識エリアに区分けされます。もう少し具体的に言えば、横5(プロセス群)×縦10(知識エリア)のマス目の中に、47のプロセスが配置されています。

今回のコラムでは、プロジェクトマネジメント・プロセス群についてお話しします。


プロジェクトマネジメント・プロセス群とは、「立上げプロセス群」「計画プロセス群」「実行プロセス群」「監視・コントロール・プロセス群」「終結プロセス群」から成ります。それぞれのプロセス群の位置付けを以下に記述します。

 

【立上げプロセス群】

プロジェクトの初期段階、主としてプロジェクトの承認を得るプロセス群です。2個のプロセスがあります。


【計画プロセス群】

プロジェクトで実施することを計画するプロセス群です。たとえば「WBSを作成し、それを元にスケジュールを立て、コスト見積りを行う」のはこのプロセス群で実施する内容です。全部で24個のプロセスがあります。


【実行プロセス群】

計画に従って実作業を行っていくプロセス群です。全部で8個のプロセスがあります。


【監視・コントロール・プロセス群】

主として、計画通りに実施できているかを「見張っている」プロセス群です。たとえば「進捗状況を確認するため、進捗会議を実施する」というのは、このプロセス群の中にある「スケジュール・コントロール」で実施すべき内容です。全部で11個のプロセスがあります。


【終結プロセス群】

プロジェクトの最終局面です。主に成果物の移管が行われます。全部で2個のプロセスがあります。移管は、システム開発等のIT分野においては、本番移行、本番稼働、本番カットオーバー・・・といった言葉で呼ばれることが多いです。

 

推奨コース

PMC0096G

PDU対象】PMBOK(R)Guide5版概要 ~プロジェクトマネジメントのグローバル・スタンダードを学ぶ~


このコースでは、プロジェクトマネジメント・プロセス群を「立上げプロセス群」から「終結プロセス群」まで、順番に確認していきます。PMBOK®ガイドの概観と、11つのプロセスで何をすべきなのかといった詳細を学習したいという方に最適なコースです。


執筆:横山 昇 [PMBOKⓇガイド入門][2016年11月11日配信]

【PMBOK®ガイド入門】第19回:プロジェクトマネジメント・プロセス その2

前回のコラムでお伝えした通り、プロジェクトのプロセスは大きく以下の2つに分けることができます。

 

プロジェクトマネジメント・プロセス

プロダクト指向プロセス

 

前回の繰り返しになりますが、PMBOK®ガイドで規定しているのは前者です。

そしてPMBOK®ガイドの最新第5版には、全部で47のプロセスが規定されています。

その中には「WBS作成」「スケジュール作成」といった、プロジェクトに携わったことがある方であれば、多かれ少なかれご経験があると思われるプロセスもあれば、「コミュニケーション・マネジメント計画」「ステークホルダー・エンゲージメント・マネジメント」のように、具体的にどのようなことを行うのか、ちょっとイメージが沸きにくいプロセスもあります。


もちろん、「どのようなプロジェクトであっても、PMBOK®ガイドに定められている47のプロセスを一律に適用しなければならない」ということではありません。

ここから述べることは筆者の私見ですが、あくまでガイドですので、いわば「旅行のガイドブック」と同じです。旅行のガイドブックを購入したとして、そこに載っている全ての名所・旧跡を訪ね歩いたり、そこに載っている全ての美味しいお店に行ったりする・・・のは難しいのではないでしょうか。どうしても行きたいところを最優先にし、そうでないところは時間に余裕があれば行く、といったような判断をなさるのではないでしょうか。


それと同様、PMBOK®ガイドに関しても、「今回のプロジェクトではこのプロセスは念入りにやらねばならない」「このプロセスは実施しない」という判断があって当然だと考えますが、読者の皆様は如何でしょうか?

 

推奨コース

PMC0096G

PDU対象】PMBOK(R)Guide5版概要 ~プロジェクトマネジメントのグローバル・スタンダードを学ぶ~

 

このコースでは、PMBOK®ガイドで規定している47のプロセスを1つずつ確認していきます。PMBOK®ガイドの概観と、11つのプロセスで何をすべきなのかといった詳細を学習したいという方に最適なコースです。


執筆:横山 昇 [PMBOKⓇガイド入門][2016年10月14日配信]

【PMBOK®ガイド入門】第18回:プロジェクトマネジメント・プロセス その1

プロジェクトのプロセスは、大きく以下の2つに分けることができます。

 

プロジェクトマネジメント・プロセス

プロダクト指向プロセス

 

上記のうち、PMBOK(R)ガイドで規定しているのは前者であり、「どのようなプロジェクトであっても汎用的に利用することができる」ものになります。代表的なプロジェクトマネジメント・プロセスの例として「WBS作成」「リスク特定」といったものが挙げられます。これらは、「どのようなプロジェクトであっても実施しておくべきである」ということは、容易にご理解頂けると思います。たとえば新しいお菓子を作るプロジェクトであっても、新しいビルを建築するプロジェクトであっても、「WBSを作って作業内容を管理する」「リスクを洗い出す」ことは、プロジェクトを成功させるためには非常に有益です。


それに対してプロダクト指向プロセスは、「プロダクトの仕様を決めたり、製造したりするためのプロセス」であり、そのプロジェクトで産み出そうとしているものによって異なります。たとえば、新しいお菓子を作り出すプロジェクトであれば「フレーバーの決定」というプロセスがあるかもしれませんが、ビル建設のプロジェクトではおそらく無いでしょう。反対にビル建設のプロジェクトでは「耐震強度の検査」というプロセスがあるかもしれませんが、お菓子を作るプロジェクトではおそらく無いでしょう。

 

推奨コース

PMC0108G 【PDU対象】プロジェクト・マネジャーのためのリスク・マネジメント


プロジェクトを成功させるため、リスク・マネジメントプロセスを実践するのは非常に重要です。このコースは、講義と演習の比率が概ね50:50になっており、演習ではシステム構築を題材として、リスク・マネジメント計画の作成からリスク特定(リスクの洗い出し)、リスク分析、リスク対応計画等々、PMBOK(R)ガイドで定められているプロセスを一通り体験していただくことができます。

 


執筆:横山 昇 [PMBOKⓇガイド入門][2016年9月16日配信]

【PMBOK®ガイド入門】第17回:プロジェクト・フェーズ

皆様が実施されるプロジェクトでも、「フェーズ」という言葉をよくお使いになると思います。たとえば、「最初に要件定義フェーズ、それが終わったら次は外部設計フェーズ・・・」といった形でマスタースケジュールを作成することもあるのではないでしょうか。

フェーズとは「マネジメント、計画、コントロールしやすいように論理的に分割したプロジェクトの区分」と定義づけられています。


ここでご注意頂きたいのは、プロジェクト・フェーズとPMBOK®ガイドに定義されているプロジェクトマネジメント・プロセス群は異なるという点です。上述の通り、要件定義フェーズというのは、多くの方にとってなじみのある言葉ではないかと認識しています。


一方PMBOK®ガイドには、要求事項収集というプロセスがあります。要求事項収集プロセスでは、ステークホルダーのニーズを明確にする必要があります。一見すると、要件定義で実施すべきことと似ていますが、要件定義以外のフェーズでも、要求事項収集プロセスを実施する局面はあり得ます。

とえば、システムテストフェーズにあたって、「ユーザがどのようなテストを実施することを望んでいるか」に関してすり合わせを行うことがあるかと思います。これも「ステークホルダーのニーズを明確にする」という行為にあたり、要求事項収集プロセスを実践している、ということができます。

 

<推奨コース>

PDU対象】要件定義のためのコミュニケーション術 ~要望・要件を引き出すヒアリングのポイント~ (CNC0036G)

ユーザの要望、要求を引き出すためには、システム知識や業務知識そのものに加えて顧客や情報システム担当者との効果的なコミュニケーションを図ることが重要です。本コースでは、要件定義をスムーズに進めるために必要なスキルについて解説し、コミュニケーションにポイントを絞った演習を行います。


執筆:横山 昇 [PMBOKⓇガイド入門][2016年8月17日配信]

【PMBOK®ガイド入門】第16回:プロジェクト・ライフサイクルその2

前回のコラムで記述した通り、ウォーターフォール型開発の弱点の1つとして
「手戻りが発生した場合のコストがプロジェクトの終りに近づくほど大きくなる」
という点があります。

IT特有の「最終的な成果物のイメージを開発側とユーザ側とで共有することが
難しい」という事情もあり、「プロジェクトの最終局面で仕様変更が多発し、
結果的に失敗プロジェクトになってしまった」という話もよく耳にします。


こういった課題に対する抜本的な対応策として、開発のライフサイクルを変えて
しまうというやり方があります。たとえば、アジャイル型開発に切り替えるという
やり方です。昨今はクラウド技術の急速な発展に伴い、かなり大規模なシステムの
開発であってもアジャイル技法を活用する、といった話もよく耳にします。


前回のコラムで記述した通り、PMBOK®ガイドで言及しているライフサイクルには、
「予測型ライフサイクル」
「反復型ライフサイクル、漸進型ライフサイクル」
「適応型ライフサイクル」
の3種があり、アジャイル型開発は「適応型ライフサイクル」1つとして定義されます。


「何をもって適応型ライフサイクルと呼ぶか?」という定義は様々ですが、PMBOK®
ガイドでは、反復型ライフサイクル、漸進型ライフサイクルが、
「繰り返すフェーズの中で追加要求を実現していく」とされているのに対し、
適応型ライフサイクルは「
反復型ライフサイクル、漸進型ライフサイクルを
さらに急速に繰り返すもの」
と位置付けられています。


<推奨コース>
【PDU対象】アジャイル ワークショップ
上記でお伝えした「適応型ライフサイクル」の1つであるアジャイル開発の中でも、
特にスクラム技法の基礎を一通り習得する、集中ワークショップです。
演習を通じてアジャイル開発の本質についての「気づき」を得る機会が多く設けられています。

執筆:横山 昇 [PMBOKⓇガイド入門][2016年7月22日配信]

【PMBOK®ガイド入門】第15回:プロジェクト・ライフサイクルその1】

「プロジェクト・ライフサイクル」という言葉を聞いても、今一つピンと来ない方もおられるかもしれませんが、「ウォーターフォール」あるいは「アジャイル」という言葉は耳にされる機会が多いのではないでしょうか。

ウォーターフォールも、アジャイルも、プロジェクト・ライフサイクルの1つです。

予測型ライフサイクル」の代表例がウォーターフォール型開発、「適応型ライフサイクル」の代表例がアジャイル型開発、ということになります。PMBOK®ガイドでは、この2つのほかに「反復型ライフサイクル、漸進型ライフサイクル」を定義しています。

予測型ライフサイクルでは、早い段階でスコープ、スケジュール、コストを確定させます。そしてまさしくウォーターフォール、すなわち滝のように上から下に順を追って実施していきます。要件定義書ができたら、それを元に外部設計を行い、外部設計書ができたら、それを元に内部設計を・・・という具合にプロジェクトが進行していきます。

皆様の中にもご経験のある方が多いのではないかと思いますが、このウォーターフォール型では手戻りが発生した場合のコストが、プロジェクトの終りに近づくほど大きくなります。システムの試験運用(フィールドテスト)をユーザに実施して頂く段階になって、ユーザ要望を正しく取り込めていないことが判明し、設計からやり直すことになってしまった・・・という苦い経験が筆者にもあります。

<推奨コース>

ウォーターフォール型開発をはじめとする予測型ライフサイクルにおいては、とりわけ最初の段階で計画をしっかり立てることが重要になります。

このコースでは、WBS作成、スケジュール作成、予算設定、リスクの洗出しなど、プロジェクトの計画段階で実施すべきことを、講義と演習でしっかりと学習して頂くことができます。講義と演習の割合は大体50:50程度となります。


執筆:横山 昇 [PMBOKⓇガイド入門][2016年6月24日配信]

【PMBOKⓇガイド入門】第14回:プロジェクトの成功

突然ですが、「プロジェクトの成功」とは何によって判断されるべきものでしょうか。

プロジェクトとは、何らかの目的があって実施されるものですから、当然その目的が達成できれば成功、そうでなければ失敗ということになります。但し、その目的を達成するためには、きちんとした計画を立てなければなりません。

PMBOK®ガイドでは、プロジェクトの成功は「最終のベースライン」に基づいて判断されるべき、と述べています。ベースラインとは、承認された計画のことです。よって「計画通りに実施できれば成功」ということになります。但し、計画はプロジェクトの途中で変更されることがあるので、「最終の」と付け加えているわけです。

PMBOK®ガイドでは、スコープ・ベースライン、スケジュール・ベースライン、コスト・ベースラインの3つのベースラインを定義しています。従って、やるべきこと(スコープ)を、期間と予算を守って実現できれば、成功ということになります。

また、繰り返しになりますが「最終の」も重要なポイントです。たとえば、プロジェクトの途中でスケジュールが変わったのに、それを計画表に反映していない状態では、プロジェクトの状況を把握するのが困難になります。そうなってしまうと、ベースライン通りにプロジェクトを終えることができるか、誰も判断することができなくなってしまいます。



<推奨コース>

プロジェクトにあたって「計画を立てる」ことの重要性は言うまでもありませんが、変更された内容をきちんと計画に落とし込むことも同じくらい重要です。たとえば、スコープ(プロジェクトで実施すること)が変わったのであれば、その影響を見極め、スケジュールや予算の消化状況にも反映しなければなりません。

こちらのコースでは、プロジェクトの実施局面で必要不可欠な変更管理およびベースラインの改定に関する実践的なスキルを、講義とグループワークを通してしっかり学習して頂くことができます。講義と演習の割合は大体50:50程度となります。


執筆:横山 昇 [PMBOKⓇガイド入門][2016年5月30日配信]

【PMBOKⓇガイド入門】第13回:プロジェクト・ガバナンス

日常で見聞きすることが多くなった「ガバナンス」という言葉ですが、辞書を引くと「管理」「制御」「支配」「統治」といった和訳が並びます。

プロジェクト・ガバナンスは、ステークホルダーの期待や、組織の戦略目標を満たす意思決定を可能とするフレームワークを提供します。

フレームワークとは、たとえば、「成果物の受入基準」「プロジェクトの意思決定プロセス」「プロジェクト・マネジャーの権限を越える予算、スコープ、品質、スケジュールの変更のレビューと承認のプロセス」などが挙げられます。

これらは、プロジェクト毎に決めるというよりはむしろ、部門や会社などの組織である程度決まっていて、プロジェクトの側は明示的あるいは暗示的にそれに従っている、ということの方が多いのではないでしょうか。

「フレームワークに従ってプロジェクトを進めていけば、成功に導くことができる可能性が高い」という共通認識をプロジェクト・マネジャーとその上司とで共有できていれば、何か問題が起こったとしても、それに従って迅速に解決することが可能となります。



<推奨コース>

「今回のプロジェクトは成功したが、次は成功するかどうか分からない」という状態では、プロジェクト・マネジャーは安心してプロジェクトに取り組むことができません。

常にプロジェクトを成功させるため、プロジェクト・ガバナンスを活用できるような環境を整える必要があります。

このコースは、プロジェクトの実態を的確に把握するための仕組み、正しい認識を得る手順を理解することに重点を置いています。

ケース・スタディと相互レビュー、実践局面での対応を問うテーマ演習を通して、プロジェクトにおけるプロジェクト・マネジャーの上司の役割の重要性を体得して頂くためのコースです。

執筆:横山 昇 [PMBOKⓇガイド入門][2016年4月25日配信]

【PMBOKⓇガイド入門】第12回:ステークホルダー(その2)

【PMBOKⓇガイド入門】第11回:ステークホルダー(その1)はこちら


ご存知の方も多いかと思うのですが、PMBOK®ガイドは1996年以降4年に1回改定されます。現在の最新版は2012年に刊行された第5版です。

第4版から第5版へ改定される際に、ステークホルダーの定義も変更されています。第5版では、ステークホルダーは以下のように定義されています。

「ステークホルダーとは、プロジェクトの意思決定、アクティビティ、成果に影響したり、影響されたり、あるいは自ら影響されると感じる個人、グループ、または組織である。」

第5版で変更になったのは「自ら影響されると感じる」が入った点です。

すなわち、「影響を受けるかもしれないと感じている」人やグループもステークホルダーとして定義しています。「実際には影響を受けなかったとしても」です。

なぜ、このように定義が変更されたのでしょうか?

皆様の周囲に、自分に関係あるなしに関わらず、やたらと首を突っ込みたがる人はいませんか?そういった方が、組織の中で権力を持っていて、(実際には関係が無いにも関わらず)「自分にも関係があるかもしれない」と考えて、プロジェクトの抵抗勢力に回ってしまったとしたら、如何でしょうか?プロジェクトの成否に大きく影響すること間違いありませんよね。このようなことが起こり得るので、PMBOK®ガイド第5版では、ステークホルダーの定義に若干の変更が加えられています。


<推奨コース>

ステークホルダーマネジメントの定石として、PMBOK®ガイドでは「ステークホルダーを特定し、分析した上で、ステークホルダーにどうなってほしいかを明確にし、そうなってもらうためにどのようにステークホルダーマネジメントをしていくか(ステークホルダーとどうお付き合いをしていくか)を決める」というやり方を提示しています。

とは言っても、PMBOK®ガイドはあくまで「ガイド」であり、具体的な手法まではあまり触れていません。

このコースは、PMBOK®ガイドの記述になぞらえつつ、具体的にどうすべきかを演習やロールプレイを通じて学ぶコースです。

執筆:横山 昇 [PMBOKⓇガイド入門][2016年3月28日配信]

【PMBOKⓇガイド入門】第11回:ステークホルダー(その1)

皆様は「ステークホルダー」という言葉を聞いて、真っ先にどなたの顔を思い浮かべますか?

システムインテグレーターとして社外のお客様を相手にしている方は、お客様の意思決定者かもしれません。社内のシステム部門で働いている方は、普段お話をしているユーザ部門の現場マネジャーかもしれません。

ステークホルダーというと、つい自分よりも立場が上の方を連想しがちですが、そういった方々だけがステークホルダーではありません。

プロジェクトにおけるステークホルダーとは、「プロジェクトの利害関係者である」とまずは押さえて頂きたいと思います。

従って、お客様やユーザ部門だけでなく、委託先、自社メンバーはもちろんのこと、プロジェクトによっては社内のPMO的な役割を担う部門や法務部門もステークホルダーに名を連ねることになります。


また「利害関係者」とある以上、プロジェクトによって不利益を被る人もステークホルダーに含まれることがあります。

たとえば、「社内業務効率化プロジェクト」を実施する場合、そのプロジェクトによって今まで自分が担当してきた仕事を失う可能性がある方々が出てくることもあります。そういった方々も含め、ステークホルダーと上手く渡り合っていくことが、プロジェクト成功の鍵の1つであることは言うまでもありません。



<推奨コース>

「ステークホルダーマネジメントで相手にするのは人なので、厳密な計画を立てても意味が無い」とお考えの方も多いかと思います。

しかしPMBOK®ガイドでは、ステークホルダーをきちんと特定した上で、その分析を行い、どのように対処していくかを最初に計画する必要があると述べています。

このコースでは、PMBOK®ガイドをベースとしてステークホルダーマネジメントの理論を学び、その上で演習やロールプレイを通じて、学んだことを自分の過去の経験に置き換えて内省をして頂くことができます。これらを通じて、これまで現場で「何気なく」実践していたことを、ご自身の中で体系化して頂くための一助となるコースです。


執筆:横山 昇 [PMBOKⓇガイド入門][2016年2月22日配信]

【PMBOKⓇガイド入門】第10回:組織のプロセス資産

皆様の会社には、プロジェクトマネジメントを実践する際の標準的な手法はありますか?

また、これまでのプロジェクトから得た教訓を次回のプロジェクトに活用していますか?

PMBOK®ガイドでは、こういった標準や教訓を「組織のプロセス資産」という言葉で呼んでいます。初めてプロジェクトをリード、あるいはマネジメントする立場に就いた時には、こういった標準や教訓は非常にありがたい拠り所になりますよね。しかし慣れてくると、こういった標準や教訓に従ってプロジェクトを進めることに煩わしさを感じる局面もあるかもしれません。

「組織のプロセス資産」は、一度作ったらそれで終わりという代物ではありません。プロジェクトでそれらを使ってみて、「ここは変えるべきではないか」「これは今の時代には古すぎて役に立たない」といった気づきがあれば、改定をすべきです。

プロジェクト・マネジャーを助けてくれるはずの「組織のプロセス資産」が陳腐化し、やらされ感だけでそれらを使うようになってしまっては本末転倒です。プロジェクトを成功させるのはもちろん重要ですが、「組織のプロセス資産」をブラッシュアップしていくことも同じくらい重要です。そうすることで、プロジェクトマネジメントの手法がより洗練されたものとなり、ひいてはプロジェクト成功の確率を高めることができます。


<推奨コース>

プロジェクトで得た知見を汎用化し、別のプロジェクトに活かすことができるようにすることは、組織運営の観点から非常に重要です。組織運営を行う立場に就き、プロジェクト・マネジャーを指導する立場におられるかたはご受講をご検討ください。PMOや品質保証の立場から、プロジェクトに携わる方にもお薦めです。



キャリアアップにつながるIT資格対策トレーニングを多数取り揃えています。

certifications_main.png


執筆:横山 昇 [PMBOKⓇガイド入門][2016年1月12日配信]

【PMBOKⓇガイド入門】第9回:組織構造

突然ですが、皆様はどのような組織構造の中でプロジェクトを担当されていますか?

強力な権限を持ち、予算や要員をある程度までなら自由に動かせる立場でプロジェクトを動かしている方もおられるでしょうし、あまり権限はなく、部門長の監視のもと限られた予算や要員でプロジェクトをやりくりしている方もおられるかと思います。今日は、プロジェクトに影響を及ぼす組織構造 (「機能型」「マトリックス型」「プロジェクト型」) についてお話ししたいと思います。

まず読者の皆様の中で多いのが、「機能型」「マトリックス型」の組織構造の中でお仕事をされている方ではないでしょうか。

「機能型」とは、ラインの部門長の下でいくつかのプロジェクトが実施されているイメージになります。その場合、プロジェクトマネジャーの権限は非常に限られており、どちらかというと調整役を担うような形になります。

「マトリックス型」とは、必要な要員を様々な部署から集めてプロジェクトを実施するイメージになります。そうなると「機能型」よりもラインからの独立性は高くなり、プロジェクトマネジャーの権限は大きくなります。

「プロジェクト型」とは、ラインの部門長=プロジェクトマネジャーになるイメージです。規模の大きなプロジェクトを実施する場合、そのプロジェクトを推進するための部門が新たに創設され、プロジェクトに取り組んでいくことがあります。この場合、プロジェクトマネジャーの権限は「機能型」「マトリックス型」よりもはるかに大きくなります。


<推奨コース>

「機能型」の小規模プロジェクトでも、「プロジェクト型」の大規模プロジェクトでも、チームに活力が無ければ、プロジェクトの成功は難しいと言わざるを得ません。チームを活性化し、メンバーの力を最大限に引き出したいとお考えの方はぜひご受講をご検討ください。

実践的な演習を通じて、チームマネジメントの勘所を会得して頂くことができます。


<グローバルナレッジのプロジェクトマネジメントトレーニング>
グローバルナレッジは、PMI®登録教育プロバイダー(REP)として資格取得対策コースをはじめ、PMP®認定対応コースを提供しています。


執筆:横山 昇 [PMBOKⓇガイド入門][2015年12月14日配信]

【PMBOKⓇガイド入門】第8回:組織の文化

プロジェクトを成功に導くための重要な要素の1つとして、「プロジェクトに影響を与える組織の文化を正しく理解しておくこと」が挙げられます。

特にオフショア開発を担当された方の中には、「文化の違い」に戸惑われた経験をお持ちの方もおられるかもしれません。

以前ほどではありませんが、諸外国から「日本人は働きすぎだ」と批判を受けることがあります。この労働時間も文化と言えるのではないでしょうか。

海外に限らず、国内の委託先企業にお仕事を依頼する場合でも、自社との文化の違いに面食らった経験をお持ちの方もおられるのではないでしょうか。

特に、初めて一緒にお仕事をするような場合には、相手企業の仕事の進め方、作業環境等を可能な限り事前に把握しておくことが、委託先企業と良い関係を構築し、最終的にプロジェクトを成功に導く重要なポイントとなります。


<推奨コース>

講義と演習を中心とした2日間のコースです。「外注計画」「委託先企業の選定」「契約」はプロジェクトの外注管理における最重要ポイントです。これらについて体系的に学習したいという皆様におすすめです。

皆さまのご受講、講師一同お待ちしております。

執筆:横山 昇 [PMBOKⓇガイド入門][2015年11月 9日配信]

【PMBOKⓇガイド入門】第7回:プロジェクトマネジメント知識体系

第1回のコラム 【PMBOKⓇガイド入門】第1回:PMBOK®ガイドの目的 でPMBOK®ガイドがどのような目的で作成されているのかをお伝えしました。少しだけ復習をしておくと、その目的は以下になります。

●良い実務慣行と一般に認められているプロジェクトマネジメント知識体系を特定する
 こと
●プロジェクトマネジメントに関する共通用語を提供すること

「PMBOK®ガイド」と聞くと、「IT業界のプロジェクトマネジメントのためのもの」という印象をお持ちの方も多いと思います。しかしそうではなく、「多くの業種の、ほとんどのプロジェクトをマネジメントするための標準」として作成されています。

たとえば、PMBOK®ガイドの中に、「WBS作成」というプロセスがあります。WBSとは、Work Breakdown Structureの略です。直訳的に解釈すると「作業内容を、分解して、構造化する(見える化する)」ということになります。その上で、分解した1つ1つの作業に関して、スケジュールを引いたり、コストを見積ったりします。

このようなやり方は、IT業界に限らず、どのような業界のプロジェクトでも有効な技法です。

<推奨コース>
PMBOK®ガイドに関して詳しく知りたいという皆様は、以下のご受講をご検討下さい。
PMBOK®ガイドの内容を2日間かけて受講者の皆様にお伝えする、講義中心のコースです。


皆さまのご受講、講師一同お待ちしております。



執筆:横山 昇 [PMBOKⓇガイド入門][2015年10月13日配信]

【PMBOK®ガイド入門】第6回: プロジェクト・マネジャーの責任とコンピテンシー

「プロジェクト・マネジャーの責任」「プロジェクト・マネジャーに必要とされるコンピテンシー」と言われて、皆様は何を思い浮かべるでしょうか。たとえば、「ニーズを満たす責任」とか、「特定分野のスキル」といったものが挙げられます。

プロジェクトを実施するには、人もお金も時間もかかります。そこまでしてやるからには何かしらの要望=ニーズがあるわけです。プロジェクト・マネジャーはプロジェクトの最高責任者ですから、当然そのニーズを満たす責任があります。従ってプロジェクト・マネジャーは、担当するプロジェクトで扱う領域に関して、ある程度のスキルを保持しておく必要があります。

たとえばIT系プロジェクトのプロジェクト・マネジャーであれば、得手不得手はあるかと思いますが、プログラミング、データベース、ネットワークといったIT分野に関するスキルを保持しておく必要があります。

IT分野でのプロジェクト・マネジメント経験が豊富な方であれば、今までとは違う職場環境で仕事をしたとしても(多々苦労はあると思いますが)、それなりにプロジェクトを率いることができるのではないでしょうか。

実際、システムインテグレーターで業務系ソフトウェアの開発を担当していた人が、メーカーに転職して組込み系ソフトウェアの開発に携わるようになった、といった話を耳にすることもあります。

しかし、今まで全くかかわったことのない領域、たとえばIT系のプロジェクト・マネジャーを担当していた人が、道路建設や発電所建設のプロジェクト・マネジャーとして即戦力として働く、というのはあまり現実的ではありません。

やはり自分の専門領域で経験を積んだ上で、プロジェクト・マネジャーとして活躍する、というのが自然な流れかと思います。

<推奨コース>


プロジェクト・マネジャーに必要とされるコンピテンシーを改めて考えてみたい、という方は、 【PDU対象】プロジェクト・マネジャーのためのコンピテンシー開発 ~業務遂行能力の向上に必要な人格コンピテンシーを身に付ける~ のご受講をご検討ください。人格コンピテンシーの開発を通して、プロジェクト・マネジャーが持っている知識を最大限に活用するための手法を学習します。

執筆:横山 昇 [PMBOKⓇガイド入門][2015年9月14日配信]

【PMBOK®ガイド入門】第5回:プロダクト・ライフサイクル

このコラムの第2回で、プロジェクトと定常業務に関してお話しをさせて頂きました。この2つをお忘れの方は、第2回のコラムをお読みいただいた後、今回のコラムをお読みいただければ幸いです。

今回のタイトルである「プロダクト・ライフサイクル」とは、たとえば新製品の開発に始まり、開発した製品の製造・販売、そして製品が世の中から退場するまでの一連のサイクルのことを表しています。ここでは、皆さんが仕事の合間や休憩時間につまんだりする「お菓子」を例に考えてみましょう。

1.製菓メーカーで、新しいお菓子を開発するプロジェクトが立ち上がる。
2.無事に開発が終わり、工場で生産ラインに載って大量生産が始まる。
3.ちょっと売れ行きが芳しくないので、パッケージを変更する。
4.しかし売れ行きが回復しないので、生産を止める。販売店の陳列棚からも撤去する。

上記のような一連の流れをプロダクト・ライフサイクルと言います。
1.が「プロジェクトである」という点は、読者の皆様も疑いの余地が無いかと思います。見落としがちですが、3.もプロジェクトです(プロジェクトの定義をお忘れの方は、第2回のコラムをご参照ください)。ここではお菓子を例に挙げましたが、製品が世に出された後も改善のためのプロジェクトが実施されることは多々あります。たとえば、ソフトウェアのマイナーバージョンアップや、車のマイナーチェンジなどがこれにあたります。

また、お菓子の例だとあまりピンと来ないかもしれませんが、4で撤収のプロジェクトが必要になることもあります。たとえば、定期購読専門の雑誌を休刊する場合、読者へのお知らせ、返金、あるいは他の雑誌に乗り換えてもらえるよう読者を誘導する、といった対応が必要になります。こういった一連の業務もプロジェクトにあたります。

<推奨コース>

上記の通り新製品の開発以外にも、「プロジェクト」と呼ぶことができるものはたくさんあります。
プロジェクトの進め方に関する標準的な技法を学習したいという方は、下記のコースご受講をご検討ください。

~プロジェクトマネジメントのグローバル・スタンダードを学ぶ~

PMBOK(R)ガイドの内容を2日間かけて受講者の皆様にお伝えする、講義中心のコースです。

執筆:横山 昇 [PMBOKⓇガイド入門][2015年8月 7日配信]

【PMBOKⓇガイド入門】第4回:プロジェクトマネジメント・オフィス(PMO)

唐突ですが、皆様の会社にはプロジェクトマネジメント・オフィス(PMO)に該当する組織はありますか?


プロジェクトマネジメント・オフィス(PMO)とは、「プロジェクトに関連するガバナンスのプロセスを標準化し、資源、方法論、ツール、技法の共有を促進するマネジメント構造」です。

 

キーワードは、「標準化」と「共有の促進」です。


 たとえば、「あるプロジェクトで上手くいった技法を、他のプロジェクトでも汎用的に使えるようにし(標準化)、横展開する(共有の促進)」というのはプロジェクトマネジメント・オフィスの重要な役割です。
プロジェクトマネジメント・オフィスというと、「プロジェクトを側方支援する」といったイメージをお持ちになる方が多いかと思います。しかし、実際にはプロジェクトに対する管理や影響力の度合いにより、様々なタイプがあります。たとえば、以下のようなものです。

 

1.支援型PMO:テンプレート、トレーニングの提供などを行う。


2.コントロール型PMO:支援を提供し、コンプライアンスを要求する。


3.指揮型PMO:プロジェクトを直接マネジメントする。


 

2.の「コンプライアンスを要求」とは、支援内容の強制を意味します。たとえば「テンプレートを提供するので、それを必ず使用しなさい」というのが、コンプライアンスの要求にあたります。コンプライアンスというと、法令順守や企業の社会的責任といった文脈で使われることが多いですが、元の意味は「順守」です。従って、上記の通り「支援内容の強制」という意味になります。


また、ちょっと意外かもしれませんが、3.のようなタイプもあります。たとえば、大規模プロジェクトでプロジェクト内にPMOが設置される場合や、問題山積のプロジェクトにPMOが乗り込んできて直接指揮をとる、といったケースがこれにあたります。

 

<推奨コース>

 

PMOや品質保証の立場からプロジェクトのレビューを行う方向けのコースです。

 

■PMC0118G:【PDU対象】【現場体験型】
       プログラム・マネジャーのためのプロジェクト・レビュー力
       ~PMの上司としてPMを指導する~

 

スタディと相互レビュー、実践局面での対応を問うテーマ演習を通して、プロジェクトの実態を的確に把握するための仕組み、正しい認識を得る手順を理解して頂きます。


 

執筆:横山 昇 [PMBOKⓇガイド入門][2015年7月13日配信]

【PMBOKⓇガイド入門】第3回:プロジェクトマネジメントとは?

言うまでもないことですが、「マネジメント:management」は、「マネージ:manage」の名詞形です。
「manage」という言葉には本来「なんとかやっていく、なんとかやり遂げる」と意味があります。すなわち、プロジェクトを「なんとかやり遂げる」のがプロジェクトマネジメントということになります。

 

プロジェクトには、人もお金も時間もかかります。何かしら実現したいこと、要求事項がプロジェクトの背景にあるからこそ、人やお金や時間をつぎ込むことができるのです。
たとえば、「新製品を投入して、ライバル社からシェアを奪還したい」とか「オートメーション化を進めて、業務を効率化したい」といった要求事項があるとしたら、その要求事項を満たすために行うのがプロジェクトであり、それをなんとかやり遂げるのがプロジェクトマネジメントということになります。

 

そして、プロジェクトには様々な制約条件があります。
たとえば、自動車の開発であれば、「他社を凌駕するため、従来車の2倍の燃費効率を実現しなければならない」といったスコープ上の制約、「今年中には市場に投入する」といったスケジュール上の制約、「開発にかけられる予算はX億円まで」といったコスト上の制約があります。
これらの制約バランスを取って最適解を見つけ出し、それを実現しなければなりません。これもプロジェクトマネジメントの重要な要素です。


いかがですか。ちょっと考えただけでも、プロジェクトを「なんとかやり遂げる=マネジメントする」のがいかに大変なことかイメージできますよね。
第1回のコラムにも書きましたが、プロジェクトをやり遂げるための良い実務慣行をまとめたものが、PMBOK®ガイドということになります。


 

<推奨コース>

 

プロジェクトを「なんとかやり遂げる=マネジメントする」ために必要な第一歩は、きちんとした計画を立てることです。

 

PMBOK®ガイドベースで、きちんとした計画を作成する手法を学びたい、という方におすすめのコースです。

 

■PMC0100G:【PDU対象】プロジェクトマネジメント(前編)
        ~しっかりした計画作り・PMBOK®Guide第5版対応~」

 

講義と演習を通じて、計画の立て方をしっかりと学習して頂ける2日間のコースです。

 

執筆:横山 昇 [PMBOKⓇガイド入門][2015年6月 8日配信]

【PMBOKⓇガイド入門】第2回:プロジェクトとは?

今回は、プロジェクトの定義に関して考えてみます。

 

そもそも、「プロジェクト」とは何でしょうか?

 

PMBOK®ガイドでは、プロジェクトを定義付けるものとして「独自性」「有期性」という2つの概念を掲げています。


もう少し具体的に言うと、「プロジェクトの結果として産み出されるものは独自であり(=独自性)、かつプロジェクトには明確な始まりと終わりがある(=有期性)」ということになります。
さらに付け足せば、プロジェクトで産み出したものを活用して、定常業務を行うことで様々な利益を得ていくということになります。
たとえば、新製品を開発するのはプロジェクトであり、その製品を工場のラインに乗せて日々製造、出荷、販売していくのは定常業務ということになります。


プロジェクトが、「1回限りの実施」「明確な始まりと終わりがある」のに対して、定常業務は「繰り返しの実施」「明確な終りが予定されていない」ということになります。

 

<推奨コース>


「そもそも、プロジェクトとは何だろう?」というところから考えてみたい方、「プロジェクト要員に任命されたけど、まずプロジェクトとはどんなものか知っておきたい」という方におすすめのコースです。


PM0085CG:プロジェクト・メンバーのためのプロジェクト入門

 

初めてプロジェクトに参画される方向けの1日のコースです。


皆さまのご受講、講師一同お待ちしております。

 

執筆:横山 昇 [PMBOKⓇガイド入門][2015年5月11日配信]

【PMBOKⓇガイド入門】第1回:PMBOK®ガイドの目的

「PM道場」をご訪問頂き、誠にありがとうございます。
今回から新連載「PMBOK®ガイド入門」をスタートします。

このコラムでは、グローバルナレッジの講師が「PMP® BOOT CAMP(弊社のPMP®試験対策講座)」の中でお話ししている内容を、少しずつご紹介してまいります。


PMP®試験対策、PMBOK®ガイドに関する知識の修得、プロジェクトの現場でご活用頂けますと幸いです。

第1回は「PMBOK®ガイドの目的」についてお話しします。
PMBOK®ガイドは、米国に本拠があるPMI®という非営利団体が作成し、定期的に改定しています。PMBOK®ガイドの主な目的は、下記となります。

● 良い実務慣行と一般に認められている、プロジェクトマネジメント知識体系を特定する

良い実務慣行というと何となく大仰な感じがしますが、プロジェクトマネジメントの現場で実際に行っているやり方(慣行)のうち、良いと認められているもののことです。一例を挙げれば「WBSを作成する」がこれに該当します。


● 「プロジェクトマネジメント」に関する『共通用語』を提供する

一例を挙げると、PMBOK®ガイドでは、WBSの最下層を「ワークパッケージ」という言葉で定義しています。すなわち共通用語を提供しています。
PMBOK®ガイドをベースとしたプロジェクトマネジメントを学んだ人同士であれば、所属する部署や会社が異なっていたとしても、「ワークパッケージ」と聞けば「ああ、WBSの最下層のことだな」と共通認識が持て、用語レベルの認識のズレが発生することを抑止できます。
社外との連携がほぼ必須であるITのプロジェクトでは、『共通用語』で話すことができるということは、非常に大きな利点となります。

 
<推奨コース>
PMBOK®ガイドに関して詳しく学ぶことができるコースです。

【PDU対象】PMBOK(R)Guide第5版概要
  ~プロジェクトマネジメントのグローバル・スタンダードを学ぶ~


PMBOK®ガイドの内容を2日間かけて受講者の皆様にお伝えします。

皆さまのご受講、講師一同お待ちしております。

 

 

執筆:横山 昇 [PMBOKⓇガイド入門][2015年4月 8日配信]


ここでは、[ASP]PMP(R)試験対策問題集から毎回1問をご紹介します。

PMP®とは、PMI®(Project Management Institute)が認定するプロジェクト・マネジャーの世界標準資格、PMP®(Project Management Professional)のことです。

[ASP]PMP(R)試験対策問題集 PMBOK(R)Guide第5版・新試験対応 (スマホ対応版)は、PMP®資格試験にチャレンジする方を対象に、効率的に試験準備を行うための自主学習教材です。選び抜かれた500問が入っています。解説付きですので、受験対策にぜひご活用ください。

※本ブログの「PMP®試験問題に挑戦!」は、過去20回の掲載分を公開しています。ご購入は上記のリンク先からどうぞ。




公式Facebookで新着記事をすぐにお届け!



※Microsoft、Windowsは、米国Microsoft社の登録商標です。
※Oracleは、米国オラクル・コーポレーションおよびその子会社、関連会社の米国およびその他の国における登録商標です。
※PMI、PMP、PMBOKは、プロジェクトマネジメント協会(Project Management Institute, Inc.)の登録商標です。
※ITIL®はAXELOS Limited の登録商標です。
※American Management Association は、米国アメリカン マネジメント アソシエーションの登録商標です。
※BOOT CAMP、NEW TRAIN、Glovalueはグローバルナレッジネットワーク株式会社の登録商標です。
※その他このサイトに掲載された社名、製品名は、各社の商標、または登録商標です。

© Global Knowledge Network Japan, Ltd. 2008-2016, All Rights Reserved.
  • Get ADOBE READER