PMBOK3とPMBOK2000の違い

PMBOK 3rd Editionをぼちぼちと読み始めている。ボリュームはPMBOK2000の1.5倍ある(400頁)。1996年に初版、2000年に2版、そして2004年に3版と版を重ねてきたPMBOK。オンナであれWindowsであれ、3番目から具合がよくなってくるといえるし、PMBOK3も同じに違いない。ダイターン3やザンボット3と同じように、PMBOK3も無敵になるといいねっ。

一言で言うと「隙が無くなった」。2000版はツッコミどころ満載で「書いた奴ぁ現場知らないね」と毒づいていたけれど、3版は隙なし。あやふやにぼかしているところが無い。語句の統一性(動詞-目的語)や明確さと具体性を追求している分、わかりやすい英語になっている。不得手な私でも分かる(スピードは出ないけれど)。難しい言い回しや語句は減っている。言い換えると翻訳ソフトとの親和性が高いベタな文になっている。

PMBOK2000→PMBOK3の改訂にあたり以下の部分を拡張しているという。


  • プロジェクトマネジメントプロセス
  • 立ち上げプロセス
  • 終了プロセス

重要度の高いところを拡充しました、ということが良く分かる。「始めよければすべてよし」と「終わりよければすべてよし」というやつ。

プロジェクトライフサイクルとプロダクトライフサイクルの違いを明確にしてある。「プロダクトライフサイクル⊃プロジェクトライフサイクル」なカンジ。「新製品を開発する」プロジェクトは、できあがったその製品を「売りさばく」プロセスを含まない。一方、「新製品開発→売る→フィードバック」となっているプロダクトライフサイクルは、プロジェクトライフサイクルを含んでいるといえる。

プロセスの数は39→44に増えたそうな。7つ追加され、2つ削除されている。追加されたプロセスは次の通り。


  • プロジェクト憲章の展開(sec4.1)
  • スコープ記述書の作成(sec4.2)
  • プロジェクトのモニタリングとコントロール(sec4.5)
  • プロジェクトの終結(sec4.7)
  • WBSの作成(sec5.3)
  • アクティビティリソースの見積もり(sec6.3)
  • プロジェクトチームのマネジメント(sec9.4)

WBSの重要性を強調しておきながら、その作成プロセス(5.3)無かったのねorz このへん未読なので楽しみ~ あとプロジェクト憲章をどう展開させるか(4.7)も興味あり。プロセスは増えただけでなく、プロセスの順番と構成に注力している(chap.3)。フローチャートやシーケンス図(?)もどきを使って、プロセスの順番や構成を解説している。相変わらず「そんなキレイに分けられるかぁ?」と言いたくなるが、その順番は妥当。

PMOの役割や、PMとの違いについての説明が増えている。Project Management Office って世の風潮という奴なのか? 組織がそんなにキレイに割れないだろうとは思うのだが、まぁハヤリモだし…

そういや、和訳版が同時刊行と噂されていたけれど、出ているのかな? amazonでは見当たらなかったナリ。ボランティアの皆さま、がんがってくださいまし。このblogではマターリと紹介しようかと。あくまで私の「読み」なので誤読&バイアスがかかっている模様。

| | コメント (0) | トラックバック (0)

スコープを可視化する

一般に、WBSやビジネスプロセスのチャート化により、スコープを洗い出すことは可能。その際たいせつなことは、

「スコープとそうでないものの境界線をものすごくはっきり持つ」ということです。詳細度ではないです。ここまでがスコープ、という範囲が重要だと思います。詳細度は段階的に詳細化すれば良い、ということです

nicknickさんの「スコープをみているだけでうまくいく」より引用。UMLのユースケース図と同じ考え方ナリ。「ゆーすけーすずって何?」という方、百聞一見、これとかこれを見るとイメージが湧くだろう。

はじめてユースケース図に触れたとき衝撃を受けたのが、この「外枠」。枠の中がシステムで実現するべきことで、枠の外側はシステムの外。ユースケース図を書くとき、この外枠を最初に書き、次に枠内にシステムの名前を書く

システムの外からシステムに関わるものを「アクター」と呼ぶ。アクターは、「経理係長」というロールとなる場合が多いが、「顧客管理レガシーシステム」といったシステムでもOK。アクターは、システムの中の業務「ユースケース」と線で結ばれる。線が外枠と交差している→そこにインタフェースが発生している。

実はこの枠、省略しても良いのだが、意識してこの枠を書くようにしている。お客さまに説明するときも「さりげなく」使っている。UMLに疎いお客さまでも「システムの外/内」の概念を直感的に知ってもらえる。

さらに、さりげなく「外/内」を切り分けて説明することで、お客さまの脳に刷り込みできることがウレシイ。「この業務は外からデータを持ってきてやるんですよね~」とか言いながら、「データを持ってくる主体」をアクターにしてしまう。

このユースケースはシステムでやるのか/システムの外なのかがハッキリする。システムの外の業務はユースケース図に書かない←鉄則

  そのシステムで実現する業務

  そのシステムに関わる主体

これを一枚化したものがユースケース図。従って、「スコープ」という語を聞くとユースケース図の外枠を連想する。PMにとってUMLは強力なツールだと思う。

--

| | コメント (0) | トラックバック (1)

KKDとは「根性根性ど根性」だと思っていた罠

たまにはPMP関連の優れたサイトの紹介を。

「はい、私もPMPですが。」のご紹介。PMP対策というより、むしろPMP持っている人向け。「PMP取得したけれど、仕事ぶり何も変わっていない」という人は読むとよいかもー。PMBOKを体系づけた説明はなく、プロジェクトマネジメントの実践現場からPMBOKを考察している。PMBOKを理解していることが最低ライン。

だからといって初心者お断りではない。むしろ、マネジメントの壁に行き当たっていたり、デスマプロジェクトを止めるべきなんじゃぁ…とお悩みのチームリーダーが読むと、きっと「気づき」が見つかる。

  1. スコープが決まらずにプロジェクトが始まってしまっているという事実
  2. 指示されなければ何もしない請負先(最強PMP軍団)
  3. KKD大好きの上司(これこそ最強)

「現実・・・」からの引用。身につまされること多し。

少しドライbutプロならではの見解はリンク先を熟読すべし。読んでて「何をアタリマエなことを」と思った人は実は私。そのアタリマエなことがちゃんとできていないことについて、二重に身につまされることになる…

1→スコープが決まってからスタートしたプロジェクトってやったことありませんが何か?

2→指示しても動かない最凶軍団の場合。「ええ、結構です。ぜんぶこっちでやっておきますから。従って契約更改はありませんので引継ぎ資料を念入りに作成しておいてくださいね」

3→上司のKKDは根性根性ど根性~としか読めない(ホントは経験・勘・度胸)

もちろん分かっているつもり。プロフェッショナルを目指すのなら、最初に、かつ、最大に変わらなければならないのは、わたし自身であることを。

--

| | コメント (15) | トラックバック (0)

新幹線改修プロジェクト

41億人。この40年で東海道新幹線が運んだ人数。

走った距離は15億キロ。地球<->太陽を5往復したことになる。しかも新幹線は東海道だけではない。山陽、東北、上越と全国的な広がりを見せ、台湾新幹線は来年開通予定だ。既に700系をベースとした輸出車両が海を越えている。

700トンの車両が一日何百回と超高速で行き来する。これほど酷使される土木建造物は無い。パンタグラフや線路は日々のメンテナンスで対応可能だが、橋梁やトンネル、高架といった「取り外しのできないもの」はそうはいかない。

【東海道新幹線に1兆円】

JR東海は東海道新幹線の大規模改修に総額 1兆1070億 円かかるとして、国土交通省が創設した「新幹線改修引当金制度」に15年間で5000億円を積み立てる計画を同省に申請した。

[共同通信2002-08-23]

残りの6000億円はどうするんだろ? という下世話なツッコミはおいといて、プロジェクト概要は次の通り。

  期間:2018年4月-2028年3月
  予算:1兆1070億円
  目的:東海道新幹線の改修(鉄橋、高架、橋梁、トンネル)

  前提条件:新幹線を止めないこと

日本の大動脈ともいえる新幹線。神業ともいえるダイヤ。その血管が詰まることは、日本経済の心筋梗塞に等しい。これまでの、夜間メンテナンスや応急処置とは大きく異なり、動いている昼間も含めた工事を行う…? ありえない。トップスピードの新幹線を見たことがあるなら分かるはず。どんなに目の良い列車見張員でも逃げ切れない。

となると夜間限定で、厳密な工程管理・時間管理が求められる。橋梁やトンネルなど複線化の効かないものはスライド工法が必要になる。新幹線並の秒きざみとは言わないが、工事は分刻みの対応を迫られるに違いない。始発列車も700トンの超高速だから。

当然のことながら、JR東海の子会社は皆メンテナンス用の整備会社。だから、この工事を実施するためには専門の会社を設立するところから始まる。JR東海はそこと契約を締結するのだろうなぁ… 「目的」はハッキリしているが、手段やノウハウはまるでないはず(このプロジェクトはまさに前代未聞)。従って、実費償還契約になるだろう。ゼネコンは部外者なので、今後は「プロジェクト」という視点から見守っていきたい。

余談だが、「動脈列島」という小説がある。新幹線を転覆させるテロリストの話。30年前のお話だがおもしろいよ。あの頃から新幹線の本質 [ 安全かつ正確無比 ] は変わっていない。ニッポンの誇りだと思う。

ネタ元 : 朝日新聞10/5「超高速の時代」

参考 : wikipedia新幹線

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PMP試験対策の目次に戻る

--

| | コメント (0) | トラックバック (0)

PROBANKプロジェクト

PROBANKとは富士通が開発した次世代基幹系システムのパッケージ・ソフトウェアの名称。PROgressive BANKing solutionの略で「プロバンク」と読む。地方銀行をターゲットとした勘定系システムを再構築、1999-2000にかけて、東邦銀行など多くの導入契約を次々と結んだ。しかし、北日本銀行などが契約解消を発表する。開発が難航し、稼動開始が遅れると富士通から通告があったからだと言われている。

富士通の目算は、最初のユーザーである東邦銀行と「PROBANK」を作り、並行して他の銀行にも売っていく、というものだった。しかし、肝心の東邦銀行との開発が計画どおりに進まなかった。「遅れを挽回するため、東邦に優秀なSEを総動員した。そのため、他の銀行向けのプロジェクトが止まってしまった(富士通幹部)
(選択9月号より)

続きを読む "PROBANKプロジェクト"

| | コメント (2) | トラックバック (0)

第13章:プロフェッショナル責任

ここでは、プロフェッショナル責任をまとめます。まとめというよりも、私の決意になるかな。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

続きを読む "第13章:プロフェッショナル責任"

| | コメント (4) | トラックバック (0)

第12章:プロジェクト調達マネジメント(その4)

ここでは、プロジェクト調達マネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

続きを読む "第12章:プロジェクト調達マネジメント(その4)"

| | コメント (1) | トラックバック (1)

「NTTデータPMO」という試み

PMOとは、恒常組織として企業内のプロジェクトマネジメント業務の品質向上に寄与する部門のこと(Project Management Office)。イラク復興プログラムオフィス(*注1)ではないし、ましてやファンタシーモナーオンライン(*注2)の略でもない。

PMOの立場は、「プロジェクトチーム」と比較すると分かりやすい。


  • プロジェクトチームは、新商品やシステムの開発といったプロジェクトの遂行・損益に対し責任を持つ
  • PMOはプロジェクトマネジメントの手法・運用に際してのみ責任を持つ

PMOという部門化によって、PMノウハウを集めやすくなったり、PMキャリアという新たな出世コースもできる。現場のコーチングやメンター制でしか培うことができない「プロジェクトマネジメント能力」を集約できることは、経営者にとっては魅力的だろう…

実現すれば、ね

続きを読む "「NTTデータPMO」という試み"

| | コメント (4) | トラックバック (0)

第12章:プロジェクト調達マネジメント(その3)

ここでは、プロジェクト調達マネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

続きを読む "第12章:プロジェクト調達マネジメント(その3)"

| | コメント (0) | トラックバック (0)

第12章:プロジェクト調達マネジメント(その2)

ここでは、プロジェクト調達マネジメントをまとめます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

続きを読む "第12章:プロジェクト調達マネジメント(その2)"

| | コメント (0) | トラックバック (0)

より以前の記事一覧