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つ削除されている。追加されたプロセスは次の通り。あとプロジェクト憲章をどう展開させるか(4.7)も興味あり。プロセスは増えただけでなく、プロセスの順番と構成に注力している(chap.3)。フローチャートやシーケンス図(?)もどきを使って、プロセスの順番や構成を解説している。相変わらず「そんなキレイに分けられるかぁ?」と言いたくなるが、その順番は妥当。PMOの役割や、PMとの違いについての説明が増えている。amazonでは見当たらなかったナリ。ボランティアの皆さま、がんがってくださいまし。このblogではマターリと紹介しようかと。私の「読み」なので誤読&バイアスがかかっている模様。(0)Tweetスコープを可視化する一般に、WBSやビジネスプロセスのチャート化により、スコープを洗い出すことは可能。「スコープとそうでないものの境界線をものすごくはっきり持つ」ということです。ここまでがスコープ、という範囲が重要だと思います。詳細度は段階的に詳細化すれば良い、ということですnicknickさんの「スコープをみているだけでうまくいく」より引用。UMLのユースケース図と同じ考え方ナリ。「ゆーすけーすずって何?」という方、百聞一見、これとかこれを見るとイメージが湧くだろう。ユースケース図に触れたとき衝撃を受けたのが、この「外枠」。枠の中がシステムで実現するべきことで、枠の外側はシステムの外。ユースケース図を書くとき、この外枠を最初に書き、次に枠内にシステムの名前を書く。システムの外からシステムに関わるものを「アクター」と呼ぶ。アクターは、「経理係長」というロールとなる場合が多いが、「顧客管理レガシーシステム」といったシステムでもOK。アクターは、システムの中の業務「ユースケース」と線で結ばれる。線が外枠と交差している→そこにインタフェースが発生している。実はこの枠、省略しても良いのだが、意識してこの枠を書くようにしている。お客さまに説明するときも「さりげなく」使っている。UMLに疎いお客さまでも「システムの外/内」の概念を直感的に知ってもらえる。さりげなく「外/内」を切り分けて説明することで、お客さまの脳に刷り込みできることがウレシイ。「この業務は外からデータを持ってきてやるんですよね~」とか言いながら、「データを持ってくる主体」をアクターにしてしまう。このユースケースはシステムでやるのか/システムの外なのかがハッキリする。システムの外の業務はユースケース図に書かない←鉄則そのシステムで実現する業務そのシステムに関わる主体これを一枚化したものがユースケース図。従って、「スコープ」という語を聞くとユースケース図の外枠を連想する。PMにとってUMLは強力なツールだと思う。(1)TweetKKDとは「根性根性ど根性」だと思っていた罠たまにはPMP関連の優れたサイトの紹介を。「はい、私もPMPですが。PMP対策というより、むしろPMP持っている人向け。「PMP取得したけれど、仕事ぶり何も変わっていない」という人は読むとよいかもー。PMBOKを体系づけた説明はなく、プロジェクトマネジメントの実践現場からPMBOKを考察している。PMBOKを理解していることが最低ライン。いって初心者お断りではない。マネジメントの壁に行き当たっていたり、デスマプロジェクトを止めるべきなんじゃぁ...とお悩みのチームリーダーが読むと、きっと「気づき」が見つかる。指示されなければ何もしない請負先(最強PMP軍団)KKD大好きの上司(これこそ最強)「現実・・・」からの引用。身につまされること多し。ドライbutプロならではの見解はリンク先を熟読すべし。読んでて「何をアタリマエなことを」と思った人は実は私。そのアタリマエなことがちゃんとできていないことについて、二重に身につまされることになる...1→スコープが決まってからスタートしたプロジェクトってやったことありませんが何か?2→指示しても動かない最凶軍団の場合。ぜんぶこっちでやっておきますから。従って契約更改はありませんので引継ぎ資料を念入りに作成しておいてくださいね」3→上司のKKDは根性根性ど根性~としか読めない(ホントは経験・勘・度胸)もちろん分かっているつもり。プロフェッショナルを目指すのなら、最初に、かつ、最大に変わらなければならないのは、わたし自身であることを。(0)Tweet新幹線改修プロジェクト41億人。この40年で東海道新幹線が運んだ人数。走った距離は15億キロ。地球<->太陽を5往復したことになる。全国的な広がりを見せ、台湾新幹線は来年開通予定だ。700系をベースとした輸出車両が海を越えている。700トンの車両が一日何百回と超高速で行き来する。これほど酷使される土木建造物は無い。パンタグラフや線路は日々のメンテナンスで対応可能だが、橋梁やトンネル、高架といった「取り外しのできないもの」はそうはいかない。15年間で5000億円を積み立てる計画を同省に申請した。いう下世話なツッコミはおいといて、プロジェクト概要は次の通り。トンネル)前提条件:新幹線を止めないこと日本の大動脈ともいえる新幹線。神業ともいえるダイヤ。その血管が詰まることは、日本経済の心筋梗塞に等しい。トップスピードの新幹線を見たことがあるなら分かるはず。どんなに目の良い列車見張員でも逃げ切れない。橋梁やトンネルなど複線化の効かないものはスライド工法が必要になる。新幹線並の秒きざみとは言わないが、工事は分刻みの対応を迫られるに違いない。始発列車も700トンの超高速だから。当然のことながら、JR東海の子会社は皆メンテナンス用の整備会社。この工事を実施するためには専門の会社を設立するところから始まる。「目的」はハッキリしているが、手段やノウハウはまるでないはず(このプロジェクトはまさに前代未聞)。従って、実費償還契約になるだろう。ゼネコンは部外者なので、今後は「プロジェクト」という視点から見守っていきたい。余談だが、「動脈列島」という小説がある。新幹線を転覆させるテロリストの話。30年前のお話だがおもしろいよ。ニッポンの誇りだと思う。(0)TweetPROBANKプロジェクトPROBANKとは富士通が開発した次世代基幹系システムのパッケージ・ソフトウェアの名称。solutionの略で「プロバンク」と読む。地方銀行をターゲットとした勘定系システムを再構築、1999-2000にかけて、東邦銀行など多くの導入契約を次々と結んだ。北日本銀行などが契約解消を発表する。開発が難航し、稼動開始が遅れると富士通から通告があったからだと言われている。富士通の目算は、最初のユーザーである東邦銀行と「PROBANK」を作り、並行して他の銀行にも売っていく、というものだった。肝心の東邦銀行との開発が計画どおりに進まなかった。「遅れを挽回するため、東邦に優秀なSEを総動員した。(0)Tweet第13章:プロフェッショナル責任ここでは、プロフェッショナル責任をまとめます。イラク復興プログラムオフィス(*注1)ではないし、ましてやファンタシーモナーオンライン(*注2)の略でもない。PMOの立場は、「プロジェクトチーム」と比較すると分かりやすい。プロジェクトチームは、新商品やシステムの開発といったプロジェクトの遂行・損益に対し責任を持つPMOはプロジェクトマネジメントの手法・運用に際してのみ責任を持つPMOという部門化によって、PMノウハウを集めやすくなったり、PMキャリアという新たな出世コースもできる。現場のコーチングやメンター制でしか培うことができない「プロジェクトマネジメント能力」を集約できることは、経営者にとっては魅力的だろう...実現すれば、ね。2004.05.21プロジェクトは終わった。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。