「ＰＭＢＯＫとプロジェクトマネジメントの基礎知識」勉強会のしゃべった内容

※ アクセスありがとうございます。本エントリーは一年程前に書いたものであまり良い説明ではないので、よろしかったら「社内勉強会「プロジェクトマネジメント勉強会（PMBOK概要）」で喋った内容」を御覧ください。あっちのほうがスライドもついていておすすめです。

1/15(金)に社内でプロジェクトマネジメントとPMBOKに関する勉強会をやりました。

今回の勉強会で作った資料は全部公開するつもりだったので、自分で決めたことに従って公開します。

以下のズラズラと書かれたテキストがまさにそれです。

スライドはいろいろ問題がありそうな画像をつかったためだせませんが、しゃべった内容はほぼすべて台本形式で作成したので、下記で書かれていることが勉強会でしゃべった内容のそのままです。

このテキストを公開することで、もし目にした方からご意見をいただけたらすごく嬉しいです。

間違いの指摘などでもありがたい限りです。

■　タイトル

ＰＭＢＯＫとプロジェクトマネジメントの基礎知識

■　導入パート

コンセプト①「この勉強会には新しい知識はありません」

この勉強会を通じて、皆さんは新しい知識を得ることはありません。

全て、みなさんの頭の中にある情報です。

それは実際のプロジェクトを通じて、もしくは書籍やWebの記事を読んで、みなさんが経験や知識としてすでにもっているものです。

だからこの勉強会では突然、世の中をひっくり返すような新しい概念や手法が身に付くわけではありません。

最初に断っておきます。

では何なのか？

それは皆さんが経験や知識としてもっている情報を再整理することがこの勉強会の目的です。

プロジェクトマネジメントに関する知識を棚卸ししましょう。

みなさんは無知ではありません。

未経験者でもありません。

IT業界で数年生きてきた、人によっては10年前後かそれ以上やってきたすばらしい技術者です

。

自信をもってください。

しかし経験は時として偏りを生みます。

また人それぞれ、経験は違っているので共通の知識にはなり得ません。

子供の頃、たとえば入学式や卒業式、修学旅行といった体験は大枠で共通点があってもディティールは違います。

仕事はもっと違っています。違っているのである程度の共通認識を作ることが大事です。

今日はそのためにPMBOKを使います。PMBOKについては後で説明します。

頭の中にある情報を整理整頓して、効率よく効果的に使えるための手助けをします。

今日の勉強会が終わる頃、みなさんは明確にプロジェクトマネジメントに対して一定の自信を持つことができます。

またプロジェクトマネジメント計画書や見積もりについて、正しいコンセプトで策定することができるようになります。

少なくとも数十人月レベルのプロジェクトであれば対応できます。

しかしそれは、先ほども言いましたが元々みなさんがもっている経験であったり、知識であったり、スキルであったりします。

今日の私の役割はドラゴンボールの最長老のようなものだと思ってください。

みなさんの潜在能力を引き出します。

コンセプト②「集中してください」

短時間でみなさんの潜在能力を引き出しますので、みなさんはこの勉強会の時間中は、この勉強会に集中してください。めいっぱい集中してください。

集中してほしいので今日は資料をお配りしません。

必要だと思えばメモを取ってください。

もし資料がほしい方は、勉強会が終わった後、個別でお申し出ください。

今日使ったスライドはもちろん、この勉強会の台本や、参考資料や参考資料のリストも差し上げます。

だからこの勉強会では私の話と、みなさんからでる話、そこから生まれる対話に集中してください。

コンセプト③「わからない単語はその場で質問してください」

たとえば私が「スコープクリープ」と言ったとします。

「スコープクリープって困っちゃうよね」とか。

スコープクリープ、みなさんわかりますか？

分からない方は正直に手を挙げてください。

はい、結構です。

別に今、手を挙げてもらう必要はまったくなかったのですが、こういったときは遠慮なく聞いてください。

ただし「○○の場合もあると思うんですけど、それはどうですか？」といった質問は、そのセクションが終わるか勉強会の終わりに行ってください。

もしかするとその○○の場合はもうちょっと後のコーナーで解説をするかもしれません。

コンセプト④「私はウソをつきます」

今日、ここで紹介するエピソード、手法、プレゼンテーションの資料、パワーポイント、これらは業務外の時間で身銭を切って用意しました。

恩着せがましいですが、すごい努力をしました。

その努力の成果をみなさんにただでお伝えするのはなんだかくやしいので、私はウソをつきます。

だから鵜呑みにしないでください。

疑ってください。

みなさんの頭の中で、私の言うことが果たして本当なのか検証してください。

また今は「本当とされている」ことが時間がたつことで「本当じゃないこと」になるかもしれません。

たとえば、プロジェクトマネジメントの世界では長らく「計測できないものは管理もできない」と信じられていました。だから何が何でも定量化なり数値化しないといけないと考えられてきました。

私もそう思ってました。

ところが現実はそうではありません。

何日かかるか分からない作業も完全にアンコントロールになることはまれだからです。

これは最近、ソフトウェア開発、プロジェクトマネジメントの大家であるトム・デマルコも認めていて過去の自分が間違っていたことを告白しました。

でもデマルコはわざとウソをついたわけじゃあり

ません。

当時はそのように考えられていたのです。

そして実際に経験を積み重ね知見を増やしていくことで必ずしもそうではないことを発見したわけです。

だからみなさんも今日の私の話を疑ってください。

本当かどうか検証を試みてください。

そしてウソ以前に間違いも言うことを知っておいてください。

間違っていたらごめんなさい。

■　PMBOK概要

PMBOKとは

PMBOKはプロジェクトマネジメントの知識体系、Project Management Book of Knowledgeの略です。

すでに第4版まででていますが、今日は第3版をベースにお話します。

尚、私が知る限り、大して調べてないですけど、第3版と第4版は大差ありません。

って説明しようとしたら図版の見やすさや説明の詳細度が結構違っていました。

でも全体の構成は大きくは変わっていません。

PMBOKとはPMI、プロジェクトマネジメント・インスティチュートが編纂をした知識体系です。

なぜこのようなものが生まれたのかというと、プロジェクトマネジメントのスキルや手法が非常に属人的だったことがあります。

人によってやり方がずいぶん違っていたんです。

また人間とは非常に良くできたもので、違う人がやっても同じような失敗をするんです。

過去に学ぶことをしていないと面白いくらい、同じ失敗をします。

そういったこともあるので、どういったプロジェクトでも共通して適応できそうな手法や考え方をまとめています。

非常に分厚い本ですが、全部読んで全部覚える必要はありません。

構造はいたってシンプルです。

今日一日でPMBOKの心を理解することが可能です。

心が理解できれば、あとは実地なり、もうちょっと自分で調べてみるなりで身に付きます。

大丈夫です。

なんなら一言でPMBOKを説明することもできますが、それやっちゃうとこの勉強会が終わっちゃうので今は言いません。

Project

プロジェクトとは何か

プロジェクトってなんでしょうか。

プロジェクトとプロジェクトじゃないものにはどのような違いがあるのでしょうか。

まずプロジェクトが共通してもっている特徴を考えるとすんなり理解できると思います。

プロジェクトとは何か？

有期性

独自性

段階的詳細化

PMBOKではこの3つがプロジェクトの特性であると紹介されています。

他にもP2Mや書籍によって若干、表現に違いがありますが、まーだいたい似たようなものです。

あんまりマニアックな元ネタをひっぱってきても人と話が合わなくなるので、この3つで覚えてください。

１．有期性

プロジェクトには始まりがあって終わりがあります。

やまない雨がないように、終わらないプロジェクトはありません。

ちょっと違う意味で終わってしまうプロジェクトもありますが、終わりがあることには違いがありません。

２．独自性

プロジェクトは二つとして同じものはありません。

作り出そうとするプロダクトは二つとして同じものはありません。

仮に何かのプロダクトやサービスのパクリ構築プロジェクトだとしても、オリジナルメンバーをそのままでやることはあり得ません。

３．段階的詳細化

個人的な話をすれば、私はこの段階的詳細化という言葉でご飯が何杯でも食べられる自信があります。

これがプロジェクトとは何かを語る上でもっとも重要なファクタであるとすら考えています。

さて当たり前のことを言います。

プロジェクトって始めるときはなんなのかよくわかんないですよ。

終わってみないと分からないことが非常に多い。

それはそうなんです。

独自性のあるプロダクトやサービスを生み出す所為なわけですから、最初から全部が分かっていることはありえません。

やってみないとわからないことが非常に多い。

だからプロジェクトは楽しい。

さてここから脱線します。

脱線予告です。

不確実性のコーン

段階的詳細化を一目見てわかってもらえるグラフが不確実性のコーンと呼ばれるグラフです。

プロジェクトに対してどの程度の工数が必要であるのか、フェーズごとにその振れ幅を表しています。

諸説ありますが、プロジェクト計画時点では最大400%、最小25%ずれるという説があります。

これちょっとすごいですよね。

プロジェクトの性質を多少なりとも理解している組織では、プロジェクトの計画を少なくとも2回に分けることが多いようです。

要件定義から外部設計の完了までと、詳細設計から実装、テスト、納品までですね。

前半を準委任契約、後半を請負契約にすることが多いようです。

この準委任契約と請負契約の特徴は今日の終わりの方で説明します。

なんで終わりの方で説明するのかというと、プロジェクトマネジメントにおいてこの契約形態は重要な制約にはなりますが、実際にはたいした問題ではないからです。

その理由も後々に説明します。

初期時点の見積もりや計画は無駄か？

私こう見えても、過去何回か見積もりやプロジェクトの計画を作ってきました。

当然、一人で作れるはずはないので技術者に協力を頼みます。

そうした際、高確率で言われるのがですね、

「見積もりやったことありません」

「見積もりわかりません」

「見積もりできません」

ですね。

これなんでそういう話になっちゃうんですかね？

脱線してますね。

でもまだ段階的詳細化の話ですよ。これ。集中してください。

そもそも見積もりとは？

はい、じゃあ、見積もりってなんでしょうか？

（質問してみる）

ありがとうございます。

見積もりって正確な意味は

「およそその作業が終わる時期や日数の推測」

とかそんな意味です。

つまり「予想」ですよ。この予想を「予言」と勘違いしている人が非常に多い。

そんなこと誰にもできません。

言い換えると「見積もりは外れます」。これは絶対です。

見積もりや計画にまつわるエトセトラ

外れるんなら、見積もりなんか意味がないじゃないか？

これも非常に短絡的です。

何か物事を行う際に、指標となる何かがあった方が、結果が良くなります。

どういうことでしょうか。

たとえば、、、自動車免許の取得ってどうでしょう。

教習所の今のルールはわかりませんが、取得した単位って半年から一年でリセットされますよね。

つまり締め切りがあります。

締め切り目指して単位を取得し、本番の試験に合格する必要があります。

つまり指標があります。

これがないと、けっこうな確率でだらだらといっちゃうわけですよ。

空いてるときに行けばいいやー、ってノリだと時間が空かない空かない。

時間が自然に空くようなことはないです。

意識的にやってみないと。

プロジェクトも同様です。

目標やその作業のペースの指標はないよりも合った方が絶対に良いです。

ステークホルダーに共通の目標を持たせることが大切で、それがないとプロジェクトがアンコントロールになります。

みんなペースがつかめなかったり、重要度に関する認識の齟齬が生まれます。

なので見積もりは絶対必要です。

それと一緒に計画も絶対に必要です。

外れてもいいんです。

当てようとする行為が大切です。

良い仕事をしたかったら見積もりと計画には口を出せ！

見積もりや計画を立てるということは、先を見通す力を強化することができます。

これはみなさんが自分の仕事をステップアップして給料を上げたいとか尊敬されたいとかの欲があれば必要になるスキルです。

またやりたいことをやろうとするときに、ステークホルダー、つまり利害関係者に説明をする必要があります。

その際、先の見通しの立たない話にのってくれる人なんかいません。

説得力をもつには、そこに見通しがあることを教える必要があるのです。

見積もりのダークサイド

ここで勘違いをする輩がいます。

ただし見積もりや計画をするときに、それがコミットメントであるかどうかを注意深く扱ってください。

これが罠です。

見積もりの暗黒面です。

見積もり＝約束、つまりコミットメントと勘違いをしている人が非常に多いです。

これはある意味、予言の話とも似ています。

こういった勘違いは権力をもった人に多く、見積もりや計画を立てる際は慎重になる必要があります。

できなくなるリスクを十分に考えておく必要があるということです。

また偉い人の中にはこの勘違いを知ってて悪用する人がいるので気をつけてください。

「いついつまでにやるって言ったじゃん、約束まもれよ！」

みたいなノリですね。

しかしビジネスとしてプロジェクトをやると、それは契約という形になります。

これを暗黒面と言い切るのは乱暴な気もしますが、そういった力と戦うためにも、プロジェクトマネジメントの知識を身につけてください。

それはある意味、ジェダイにとってのフォースと同じように、みなさんのよりどころになるモノです。

プロジェクトマネジメントの知識はあなたにフォースのご加護をもたらすわけです。

おかえりなさい

ここで話をもどします。

つまりプロジェクトはわからないことが多いんだけど、計画はたてなくちゃいけないモノだったりするわけです。

矛盾

ある意味、矛盾を内包しています。

段階的詳細化とはこれを一言で言い表していて、最初はわからない。

でもプロジェクトが進むにつれて少しずつわかっていく、つまり探検です。

プロジェクトとは知的な探求行為でもあるわけです。

そう考えると気分的にノッてきませんか？

プロジェクトをすることで、確実に過去の自分が知らなかったモノを知ることができるのです。

知らないで済む方が良いこともあるかもしれませんが、プロジェクトを通じて学んだこと、身に付いたことはみなさんの人生を豊かにしてくれるはずです。

プロジェクトを楽しんでください。そして好きになってください。

プロジェクトマネジメントとはなにか？

ちょっと、まとめっぽい話をしましたが、まだまだ続きます。

さきほど分からないものを分かるようにしていく行為、矛盾を内包しているのがプロジェクトであると言いました。

これもある意味、プロジェクトマネジメントの本質であったりします。

ビジネス、エンジニアリング、プロジェクトマネジメントの図

これをみてください。

業務システムやソフトウェアのプロジェクトに必要な知識やスキルをざっくりとわけたベン図です。

プロジェクト三国志と言います。

（ウソです）

ビジネスはプロジェクトを通じて生み出されるプロダクトやサービスを用いて利益を生み出すことが主な目的です。

これはビジネスアナリスト、システムアナリスト、ITストラテジストといった役割の人が考え音頭をとります。

クラスメソッドの場合はお客さまがやることが多いです。

エンジニアリングはそれを実現するための活動全般です。どうやったらそれができるのかを考え現実世界に適応していきます。いわゆるアーキテクトやシステムデザイナーの仕事です。

ビジネスとエンジニアリングは敵と書いて「とも」と読むような関係です。

放っておくとすぐ闘い始めます。

しかし、現実の世界ではビジネスの方が権力をもっていることが多く、エンジニアリングが泣きをみることが多いです。

しかししかし、世界は因果応報、エンジニアリングに泣きを見させると生み出されるプロダクトやサービスが低品質なことが多く、結果的にビジネスも泣きを見ます。

誰得になります。

フォースに調和をもたらす者

プロジェクトマネジメントはこのビジネスとエンジニアリングに調和をもたらし、限られた資源や制約の中でプロジェクトを成功に導くあらゆる活動を指します。

調整役と言ってしまえばずいぶん低くみられるかもしれませんが、これが機能しないと全ての人が泣きをみるプロジェクトになってしまうのです。

そのためには技術に関する知識、ビジネスに関する知識の両方が必要になります。

プロジェクトマネジメントとは、大変だけどやりがいのある仕事なのです。

≪脱線≫

プロジェクトって何？　補足。

プロジェクトって何？　補足。

プロジェクトの3つの特性を説明しましたが、これが組み合わさったり、ブレイクダウンされたりしてもプロジェクトというのか？

ここでたとえ話をしてみましょう。

ちなみに、私個人の考え方としては、さっきからさんざんたとえ話をしていますが、基本的には「たとえ話はムダ話」です。

（例）

目標！　モテリーマンになる！

目標！　モテリーマンになる！

Aさんは29歳男性で都内の情報系学科の大学を卒業し、先輩の紹介で都内のSIベンダーに就職しました。

高校は男子校、大学も女子がほとんどおらず女性との接点がほとんどないまま、男だらけの職場に就職したせいか、彼女いない歴＝年齢です。

このままでは今度の誕生日に魔法使いになってしまいます。

同年代の友人達が家族を築いていく様を目の当たりにし、H×Hも連載再開したので本気をだすことにしました。

ぱっとしない外見をどうにかする

出会いを増やす

女性と話しても挙動不審にならない

でも仕事はこれまで以上にがんばる

これらはAさんに関する話、モノゴトですが、関連性って考えるとどうですか？

外見と出会いと挙動不審の項目は「モテ」化に直結しそうですね。

仕事をがんばるのは必ずしも「モテ」化に繋がるとは言えません。

下手するとモテとは逆になってしますかもしれません。

たとえ話はムダ話なので、これ以上、広がりはしませんが、言いたいことはこういうことです。

（例）イメージ　※必ずしもそうではないが。

　ポートフォリオ

　　└プログラム

　　　　　└プロジェクト

　　　　　　　　└サブプロジェクト

　　　　　　　　　　　└…

つまり「モテ」につながるところはプログラムで束ねられます。

しかしAさんを構成する上で仕事は外せませんので「モテ」と「仕事」はポートフォリオで束ねられます。

かなりまどろっこしい説明をしましたが、要するに、皆さんすでに自分の人生のプロジェクトをマネジメントし、プログラムをマネ

ジメントし、ポートフォリオもマネジメントしているのです。

なぜプロジェクトマネジメントを学ぶのか？

今のムダ話の通り、プロジェクトマネジメントの技術や知識が役に立つのは仕事だけに限りません。

みなさんのプライベートにも応用が利きます。

資格を取ろう、と思ったら勉強をしますよね。

勉強だってやみくもにやるよりは、計画的に足りない知識を順序よく体系的に身につけていく方が効率が良いです。

他にも結婚とかね。

家を買うとか。

人生はプロジェクトだらけです。

あなたをマネジメントするのは誰ですか？

プロジェクトマネジメント知識はどんな仕事にも役立つし、プライベートを含めた人生全般で役に立ちます。

人生は1度きりのモノですし、必ず終わりがありますし、皆さんの人生は皆さん自身のモノであり、未来のことはわかりません。

だからこそ、プロジェクトマネジメントの知識を身につけてください。

ブレイク①

PMBOKとは?

Project Management Book Of Knowledge

PMBOKはとても抽象的で汎用的な内容になっています。

強いて特徴を上げると、計画性を重視することと、インプットとアウトプットを重視することです。

結局、PMBOK単体では現実で役に立つことはあまりありません。

それはPMBOKにも書かれてて、前提条件に「その業務において専門知識を有すること」といったことが書いてあります。

PMBOKの構成要素

ここからはPMBOKの構成要素をご説明いたします。

5つのプロセス、9つの知識領域

PMBOKの構成要素をざっくり説明することこういうことになります。

5つのプロセス、9つの知識領域。

この表現だとすごく硬い、難しい、覚えることがいっぱいある雰囲気がしますが、話は単純です。

集中しつつ、リラックスしてください。

5つのプロセス

PMBOKではプロジェクトのプロセスを5つに分類しています。

・立ち上げ

・計画

・実行

・終結

・監視コントロール

立ち上げ

プロジェクトを公式に認可し、ステークホルダーを特定します。

さらに何を持ってステークホルダー、この場合は顧客がメインになりますが、の期待を満足することができるのか、要求事項を文書化するプロセスです。

この立ち上げフェーズでは、プロジェクトマネジメント憲章という文書をさくせいすることがあります。

計画

作業全体のスコープを確定させ、アクティビティ、WBSを洗い出し、プロジェクトの計画を策定します。

この際、プロジェクトマネジメント計画書という文書を作ることがあります。

ていうか、できれば作ってください。

扱う情報は多岐にわたり、というかプロジェクトに関わる物事のほぼ全部となります。

営業さんを含めプロジェクトマネジャーやプロジェクトリーダーで考えます。

実行

プロジェクトの仕様を満たし、プロジェクトマネジメント計画書に規定された作業を完了するための活動です。

プロジェクトマネジメント計画書に沿って、人と資源を調整し、プロジェクトのアクティビティを統合し、実行します。

プロジェクトマネジメント計画書に従って活動をします。

主にプロジェクトリーダーによる作業指示と進捗管理が該当します。

このプロセスにおいて変更管理をきちんとしないと痛い目にあいます。

終結

プロジェクトの契約上の義務を公式に完結するために、またアクティビティを終了するプロセスからなる。

納品から請求支払いが該当します。

終結は他のプロセスに比べて、情報量こそは多くありませんが、完了条件を現実的で実行性のある内容にしておかないと、先立つものが先立たなくなってしまう原因になりかねません。

わたしも経験がありますが、特に、納品、検収、請求、支払いサイトについてはしっかりとした確認を行ってください。

そしてプロジェクトのレビューや教訓の文書化なども行います。

そこまでやってプロジェクトです。

監視コントロール

プロジェクトマネジメント計画書で定義されたパフォーマンス目標を達成するため、進捗をチェックし、レビューし、統制する活動です。

プロジェクトチーム外から、プロジェクトの運営について適切であるかどうかチェックすることもあるでしょう。

立ち上げ

計画

実行

終結

監視コントロール

この5つのプロセスはどのような開発プロセスモデルを採用しても必ず内包されています。

順番やバランスは異なりますが、考え方は共通です。

もし慣れないプロセスやその組織独自の手法をやることになったら、各プラクティスやアクティビティがPMBOKで言うところの、立ち上げ、計画、実行、終結、監視のどれに該当するのかさらっと確認してください。

特に立ち上げ時に終結の条件やアクティビティがあいまいになっていること、そうせざるを得ないことがよくあるので、進めながらでもいいから考えてみてください。

＜脱線＞主要な開発プロセスモデルの紹介

ここで主要な開発プロセスモデルの簡単な説明をしましょう。

これらは特徴を押さえておいても良いと思います。

ウォーターフォール

おなじみのウォーターフォールです。ウォーターフォールはその名の通り、高いところから低いところへ水が流れていくところをイメージしています。

作業をフェーズで区切って段階的に進めていくので、手順を理解しやすいことと、この単純さ故に計画が立てやすい

ことがメリットです。

逆にプロジェクトに潜む複雑な問題や、前提が狂ったときへの対応が難しいですが、単純でリスクもすくないプロジェクトには適しているかもしれません。

元祖ウォーターフォール

実は、正しいウォーターフォールは最初から最後までを2回繰り返します。

ウォーターフォール型の開発プロセスを提唱したウィンストン・ロイスは最初そのように発表をしました。

付け加えると30ヶ月の期間があれば、最初の10ヶ月で開発したモノは捨てて良い、と言っていました。

なんとプロトタイピングモデルも含まれていました。

しかし、それが曲解されて、必要以上に単純化されて今のウォーターフォールになりました。

したがって本来は2回です。

UP／RUP

統一ドプロセス、ラショナル統一プロセスは計画重視な面と、柔軟でフレキシブルな面を兼ね備えています。

フェーズごとに作業割合の異なる小さなウォーターフォールを繰り返している、というのが正しいUPです。

よくみかけるのは、ウォーターフォールとごっちゃになっている場合です。

UPのコンサルでも多いらしいです。

実は先ほど紹介したウィンストン・ロイスの息子さん、ウォーカー・ロイスが統一プロセスの策定に関わっています。

スパイラル

繰り返し型、反復型の開発をスパイラルといったり、イテラティブ型といったりします。

たしかその存在はウォーターフォールより古かった、気がします。

アジャイル

アジャイル自体は迅速といった意味です。

動くソフトウェアをなるべく早く顧客にとどけ、顧客の満足度と開発の持続性を優先した開発プロセスです。

スパイラルとの違いは一つのサイクルを短く速く、といったイメージです。

最近は若干、バズ化、宗教化していて、世間的にはうさんくさい扱いを受けることもありますが、アジャイル界隈ではショートサイクルリリース、テスト駆動開発などのプロセスを問わず役立つプラクティスがいくつもあります。

勉強するのも良いと思います。

アジャイル①スクラム

一般的にアジャイルといったらスクラムをさす、は言い過ぎかもしれませんが、アジャイル型の開発プロセスでは標準的なモデルです。

チームは自律的であること。

イテレーションの作業が始まったら、チーム外の人間は口を出さない

スタンドアップミーティングを毎日行う。

原則30日のイテレーション、スプリントとも言う。

イテレーションごとにクライアント主導で適応型の計画をたてる、といった特徴があります。

アジャイル②XP

エクストリームプログラミングはスクラムと並んでアジャイルの代表的なプロセスです。

小規模で頻繁なリリース

シンプルな設計

テスティング

頻繁なリファクタリング

ペアプログラミング

チームでのコードの所有

継続的インテグレーション

持続可能なペース

他

の特徴があります。

ケント・ベックという有名なエンジニアが作り上げました。

XPの主張としてはやるんであれば、XPのプラクティスは可能な限り全部採用しろ。

部分的に採用して失敗してもしらん、というスタンスです。

プロセス偏重

世間には開発プロセスといってもいろんな種類、手法などがあって、どれを採用したら良いのか迷ってしまいます。

そしてどのプロセスもその「万能さ」「優秀さ」を声高にアピールしていて、何を選んでいいのかどんどんわからなくなります。

私もウォーターフォールはもちろん、UP、アジャイル等々、色々と調べてみましたが、ここで思い切って表明しましょう。

This is Buzz

私はプロセスを偏重している人を懐疑的に見ます。

プロジェクトマネジメント自体の品質を上げようとすると、まず最初に開発プロセスの標準化を考えてしまいがちです。

私もはまりました。

記号化する、という意図で使うのはありだと思います。

アジャイルにしてもクラウドにしても。

しかし、それを偏重しすぎたり、それであるから万能だ、みたいに言い切るのはヤバイです。

開発プロセスの標準化について

「プロセス」という上段から入ると収集がつかなくなるか、本当に大切なことを見落としたりします。

もしくは大事じゃない、あるいは不要なものを紛れ込ませることになります。

なぜならプロセスは概念というか、単純な表現すると「順番」です。

ものづくり、順番、材料

順番っていうのは、極端な話、どうでもいいんですよ。

何かものをつくるとき、順番間違えても、やることと材料があっていれば何とかできます。

しかしやることと材料を間違えると絶対できません。

順番だけあっていてもダメなんです。

たとえばですね、

ガンダム

ガンダムのプラモデルを組み立てようとします。

１．頭

２．胴体

３．手

４．足

頭、胴体、手、足の上から順に組み立てる、っていうプロセスを作るとします。

で、これが便利でわかりやすいから、みんなこれでやっていよう、とか言い出したとします。

しかし次のプロジェクトはこれですよ。

ジオング

１．頭

２．胴体

３．手

４．足？

頭、胴体、手、足？

足ないのに足を組み立てる工程があるの？

そもそも色も違うし、大きさも違う。

よく見るとガンダムは手に武器をもってましたけど、ジオングは指先からビームでそうな感じです。

ガンダムと同じ作り方をしたら破綻するのが目に観ます。

　プロセス　　　　　概念。作業手順を抽象化したもの。

　└アクティビティ　論理。動きや振る舞い、活動を表す。

　　└タスク　　　　現実、物理的なもの。人やモノに結びつく。対象物が存在する。

だから、まずはプロジェクトを立ち上げたり計画するときはプロセスよりも「アクティビティ」の洗い出しを優先することが大事です。

プロセスは先ほども言いましたが概念です。作業手順を抽象化したもの。

アクティビティは論理。。。動きや振る舞い、活動を表す。

タスクは物理的なものです。人やモノに結びつき、時間もわりと明確になっています。また対象物が存在します。

でもこの説明は自信ありません。

アクティビティとタスクの位置関係が。。。判断つかないですね。

立ち上げ

計画

実行

終結

監視コントロール

長々と脱線しましたが、ようは本質を押さえれば、プロセスはそれほど重要ではない、と言いたかったのです。

それはPMBOKの5つのプロセスでも表現されていて、プロセスに関する説明はけっこうざっくりとしています。

そして非常に大切な注意書きが書いてあります。

（～略）

これにより、本書で述べる知識、スキル、プロセスを常にすべてのプロジェクトへ画一的に適用すべきであるといっているわけではない。プロジェクト・マネジャーは常に、プロジェクト・チームと協力して、当該プロジェクトでは、どのプロセスが適切であり、各プロセスをどの程度の厳密さで実施すべきかを決定する責任がある。

（略～）

「これにより、本書で述べる知識、スキル、プロセスを常にすべてのプロジェクトへ画一的に適用すべきであるといっているわけではない。

プロジェクト・マネジャーは常に、プロジェクト・チームと協力して、当該プロジェクトでは、どのプロセスが適切であり、各プロセスをどの程度の厳密さで実施すべきかを決定する責任がある。」

プロセスは大事だけど、本質ではない、ということです。

本質をつかみましょう。

何をやるのか？

やらないのか

なにをやるのか、やらないのか。

これを知るためにアクティビティの洗い出しをします。

そのためにはPMBOKの9つ知識領域がひつようになります、といったところでブレイクです。

ブレイク②

9つの知識領域

はい、続きです。

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

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

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

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

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

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

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

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

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

PMBOKの9つの知識領域はこれらの項目で構成されます。

この9つの知識領域について初っぱなで注意です。

１．さっきも言いましたが専門性はほぼ無視されているので、これらの項目だけではソフトウェア開発のプロジェクトはマネジメントできません。

できませんが、プロセスと同様、特にプロジェクトの計画時にあつかっている情報をこれら9つにマッピングする癖をつけてください。

損はしません。

２．順番がイケてない。

体系的に説明のしようと思うと、確かにこうなっちゃう気もしますが、プロジェクトマネジメントを勉強したことない人にいきなり「統合」とかいっても意味がわかりません。

３．しかし順番なんか関係ないくらいこれらの情報は密結合

何かをいじると多くの部分で変更が必要になります。

だから頭の中でマッピングする癖を付けることが大切です。

では注意を説明し終わったので、これらの特徴や注意点をかいつまんでご説明いたします。

順番は私なりにわかりやすいと思う順番に変えます。

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

スコープとはプロジェクトを成功のうちに完了するために必要なすべてのものといらないモノの情報です。PMBOKのスコープ定義はこれらの活動を通じてマネジメントされます。

スコープ計画

スコープ定義

WBS作成

スコープ検証

スコープ・コントロール

ここで確認ですけど、スコープってなんですか？

ちょっと考えてみてください。

そしてスコープはどのようにして生まれますか？

細かいことは、できればBABOK勉強会かアジャイル勉強会とか企画してやりたいのですが、スコープはユーザーの要求から生まれます。

これをアジャイル的にはフィーチャーと表現したりまします。

フィーチャーはユーザーにとってのソフトウェアの価値を表現したものであり、ユーザーに直接価値を提供するものです。

要求を実現するためにシステムは「機能」を提供するわけです。

たとえばプリンターですが、フルカラー印刷をするのはフィーチャーで、赤インクを装填するのは機能です。

でも赤インクを装填しないとフルカラー印刷はできません。

この位置関係を再認識してください。

そして、ここで「機能スコープ」という概念がでてきます。

この「機能スコープ」を実現するために、設計したり、実装したり、テストしますよね。

これが「作業スコープ」であり、アクティビティです。

そして、その作業がシステム構成上のどこにたいして行われるのか。

これが「システム構成上のスコープ」です。

そして最後に、契約履行と直接的に関わる「成果物スコープ」です。

なんとか設計書だしてください、とかです。

プロジェクトの立ち上げ、計画時は混乱しがちなので、これらに矛盾が生じることがあります。

また作業スコープなんかで漏れがあったりすると炎上案件へ一歩前進します。

小規模案件ならそうでもないかもしれませんが、大規模案件で作業スコープを外すと相当痛いです。

利益なんかも一発で吹き飛びます。

立ち上げ計画時にこれらの矛盾を少なくしていくことも大事ですが、変更時にどうするのかの取り決めも大事です。

変更管理ですね。

お客様が「機能スコープ」を振りかざして「作業スコープ」をないがしろにするようなら交渉が必要です。

そのためにも、これくらいのスコープ分けをしておくべきだと思います。

ところでスコープに関わる用語で「スコープクリープ」ってご存じですか？

「時間、コスト、および資源への影響に対処することなく、または顧客の承認なしに特性や機能（プロジェクト・スコープ）を追加すること。」です。

よかれと思っても独断でそういったことをすべきではありません。

またメンバーがそういった行動をとるのであれば厳重に注意をしてください。

結局、そういった行動を容認することは、プロジェクトにおける決まりをおろそかにしかねなくなり、結果、お客様との約束を果たさなくなるかもしれません。

それともう一つ余談ですが、古代ローマ帝国の国家戦略として「分割して統治せよ」という指針があります。

プロジェクトも同様で、大きすぎるタスクは分割してください。

1タスク10人日なんて言語道断です。

立ち上げ計画時ではその程度でも問題ありませんが、実行時にそれだとヤバイです。

ただし立ち上げ計画時で細かすぎる見積もりをつくると結果としてどんぶりになるので、それもオススメできません。

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

プロジェクト・タイム・マネジメントはプロジェクトを所定の期間内に完了させるために必要なプロセスからなっています。

そしてこれは他の知識エリアのプロセスとも関連します。

スコープはもちろん、リソース、コストに影響し合います。

アクティビティ定義

アクティビティ順序設定

アクティビティ資源見積り

アクティビティ所要期間見積り

スケジュール作成

スケジュール・コントロール

先ほども説明したアクティビティをもとにスケジュールを作成します。

このスケジュール作成の際に注意点がありますが、「人月の神話」という本があって、読んだ方はいらっしゃいますか？

この本の中に「妊婦を9人集めても1ヶ月では出産できない」といった説明があります。

これはプロジェクトでも同様のことが言えて、人を増やしても縮まない限界点があります。

立ち上げ・計画時ではそれを念頭に置いてください。

コミュニケーションの説明の際にも言いますが、ここにも明確に罠が潜んでいます。

ガントチャート

それとここで各種チャートについて説明しましょう。

みなさん、ガントチャート使ってますか？　使ってますよね？

私はガントチャートが好きです。

すばらしい発明だと思っています。

PERT図

PERT図というものがあって、ガントチャートが流行る前によく使われたそうです。

これは古典で加藤昭吉という人の書いた「計画の科学」で詳しく紹介されています。

また就職試験、SPI、情報処理試験なんかにもかならず登場します。

作業順序を決める、作業順序による制約を理解するために、計画立案時に作成するのが良いようです。

しかし進捗率をぱっと一目で理解するのはちょっとむずかしそうです。

ちなみにこれと似たような目的で使われる図表に特性要因図、魚の骨ダイアグラム、別名、石川ダイアグラムというものがあります。

しかしどれもあまり使いません。

私は仕事で使った記憶がないです。

ガントチャート（再び）

それにひきかえ、ガントチャートはスケジュール計画が分かりやすく可視化されていますし、各アクティビティやタスクの進捗も、進んでいるのか遅れているのかもイナズマ線がわかりやすく表現しています。

作業順序もPERTほど、厳密な表現はされていませんが、MS-Projectでいうところの先行タスクでわかります。

各タスクの作業量がわかり、順序がわかり、進捗までわかる。

ガントチャートは便利です。

でもガントチャートは悪にもなります。

使い方を間違えるとプロジェクトが抱えているリスクを隠蔽します。

まずガントチャートはプロジェクトの総タスク量に対する消化率を見えづらくします。

そして運用の仕方によりますが「進捗率90%」が問題を更に隠蔽します。

進捗率90%の罠

プロジェクトのメンバー、作業者は自分のタスクの進捗率を聞かれると

「90%終わりました。あとは確認と修正だけです」

といった報告をよくします。

頻繁にします。

ていうか聞く度に言います。

しかし

DOUBT!

場合にもよりますが、管理者はこの90%を鵜呑みにしないでください。

絶対90%じゃないと思っていいです。

何故か？

（１）

報告時点では確かに90%かもしれない。ただし残りの10%はそれまでの90%と同じくらい時間がかかったりする

（２）

その日の〆切をごまかすために90%と言うことがある。明日の朝、ちょっと片付ければすぐ終わります、とか。

その日〆切のものはたとえ残り1分で終わるといってもその日のうちに片付けてください。

（３）

そもそも、確認と修正がソフトウェア開発において締める割合をなめて認識している。

もっとも時間を食うのはデバッグです。

よね？

仮にそうでないとしても、仕事全般で時間かかるのは、抜け漏れの確認と要求された品質を満たすための作り込みだと思います。

タスクや作業の完了条件についてはプロジェクトチームないで厳格な取り決めをしてください。

だいたいこうだろう、阿吽の呼吸だろう、と根拠の希薄な相互理解でプロジェクトを進めるのは炎上のもとです。

バーンダウンチャートの話

バーンダウンチャート知ってる人？

バーンダウンチャートはタスク総量を積み上げて少しずつ減らしていくチャートです。

バーンダウンチャートの素晴らしい点はシンプルであることでしょう。

タスク総量と生産性（ベロシティ）と期間の3つのパラメータしかありません。

何が可能で何ができないのかもすぐわかります。

またバーンダウンチャートはプロジェクトリーダーやマネージャーにもよりますが、特殊なツールを必要としません。

Excelで十分です。

Excelですら過剰かもしれません。

ホワイトボードに手書きが望ましいくらいです。

バーンダウンチャートのメリットは以下です。

①タスク総量が把握しやすい。追加、変更による積み上げがすぐわかる。

②ベロシティを管理しているため、ペースを把握しやすい。

　これによってできるできないが可視化されている

バーンダウンチャートを用いたプロジェクト進捗のチェック

バーンダウンチャートを用いたプロジェクト進捗のチェック、具体的にはどうする？

仕様変更や追加なのでタスクが積み上がったら、期日に間に合わせるためには生産性をあげる（人を追加する）か、期日自体を変更する必要があります。

予定通りの生産性がでない場合は早急にその原因を探ってください。

スキル不足もあり得ますが、前提となる条件に齟齬や間違いがあった可能性があります。

生産性が思った以上にでて予定よりも早くタスクを消化しているのなら、、、、

まずは疑ってください。

進捗率90%の罠が潜んでいるかもしれません。

もしそうでないのなら、ステークホルダーに共有をしてください。

私個人の考えとしては、その事実を正直にお客さまに伝えて追加作業を行うべきだと思います。

何故ならそういった信頼の積み重ねがビジネスにおいては非常に重要ですし、そこで得た信頼は本当に困ったときにお客さまのアクションを期待できたりするからです。

あくまで個人的な考えですが、下手に工数をちょろまかして仕事を納めようとすると後々困ったことになりがちなのでオススメましません。

また、バーンダウンの注意点ですが、長々と同じバーンダウンチャートを使うのはオススメできません。

せいぜい1ヶ月程度の長さが良いかとおもいます。

使い分け

ガントチャートは計画立案時には強力なツールです。

各タスクの相関関係を短時間で把握することができます。

バーンダウンチャートはタスク総量とそれに対する生産性（ベロシティ）の関係から、

プロジェクトが期日内に完了することができるかどうかをチェックできます。

私はこの二つを組み合わせて使うことをオススメしますが、どうしても手が回らないので

あれば、バーンダウンチャートの概念を頭の中にたたき込んでください。

管理者の力量に依存するかもしれませんが、頭の中のバーンダウンチャートを元に、

お客さまやメンバーとの交渉を行ってください。

・プロジェクト人的資源マネジメント（リソース）

プロジェクト・チームを組織し、マネジメントし、リードする活動です。

人的資源計画

プロジェクト・チーム編成

プロジェクト・チーム育成

プロジェクト・チームのマネジメント

まず人的資源計画としてリソースヒストグラムを作りましょう。

スコープをもとにタイムでスケジュールを作成するとします。

コスト下げ圧力があると、きっちきちのガントチャートを引いていたりするので、リソースヒストグラムを作ると無理が生じたりします。

工数0.1とかですね。

みなさんのやっている仕事は1日、2日でぱっとはじめてぱっと結果がでる種類のモノか考えてください。

またそういった計画を立てた際、本人や調整を行う人の心理や手間も考えてみる必要があります。

また人的資源マネジメントには計画だけでなく、チームの編成、育成、マネジメントが含まれます。

ここでマネジメントについて、トム・デマルコが良いこと書いていたので引用しましょう。

1 適切な人材を雇用する。

2 その人材を適所にあてはめる。

3 人びとの士気を保つ。

4 "チームの結束を強め、維持する。（それ以外のことは全部管理ごっこ）"

これはデッドラインという本に書かれていたのですが、心の部分の話をしていると思います。

しかし、想いだけあっても伝わりません。

3分の1も伝わりません。

正しく伝えるためには、ましてやビジネスでやっているのであれば、正しい知識が必要になります。

PMBOKはそういうところでも役に立つのです。

という脱線です。

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

アクティビティをだして、スケジュールを作成すれば、かかる人件費はわかるはずです。

これを人月工数に換算して単価をかければコストを算出することができます。

コストは基本的に、人月の集合体とプラスアルファになります。

それとPMBOKでは予備費、コンティンジェンシーを設けることが推奨されています。

コスト見積もり

コストの予算化

コスト・コントロール

またコスト・コントロールの手法にEVM（アーンド・バリュー・マネジメント）というモノがあります。

プロジェクトが生み出した価値、使った工数（コスト）、期間をしるためのチャートで、使い方によっては工事進行基準

にも対応できます。

尚、MS-ProjectのEVMは工事進行基準にはなんとなく対応できます。

完全ではないです。

私、これつかったことないので説明はこれくらいで次行きます。

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

品質は範囲が広く、そして重要です。

品質計画

品質保証

品質管理

3行しかありませんが。

しかし品質だけでSQuBOKという品質管理にかんする知識体系がありますし、ISO9001やQA活動などいろいろあります。

またユーザビリティ関することも品質に含めて考えることがあります。

そこまでいくとプロジェクトとはあまり関係ない、というか飲み屋におけるネタになるのでこれ以上は扱いません。

それよりは概念としてすぐに役立つ、そして扱いに困りがちな瑕疵に関する考え方を紹介します。

瑕疵

みなさん、瑕疵の切り分けって明確にできますか？

何が瑕疵で、何が瑕疵じゃないか、ちゃんと説明できますか？

それにはまず、欠陥、バグの分類を知る必要があります。

PMBOKではなくSWEBOKでは次のように紹介されています。

１．エラー

２．フォールト

３．故障

４．間違い

上から順に。

１．エラー　(error)："計算された結果と正しい結果との間に存在する差異"

２．フォールト　(foult)："コンピュータプログラムにおける不正なステップ、プロセス、またはデータ定義"

３．故障　(failure)："フォールトが及ぼす[不正な]結果"

４．間違い　(mistake)："不正な結果をもたらす人のアクション"

それぞれの意味を補足すると、まずわかりやすい「４．間違い」についてですが、これはユーザーの操作ミスによって引き起こされる欠陥（現象といった方が適切だと思うが）であり、運用上の問題です。

「２．フォールト」「３．故障」は場合によってはテスト中、検収中に発見するのは難しいかもしれません。

プログラムレベルの欠陥が紛れ込んで発生するのが希少な場合は実際に使ってみるまで発覚しなかったります。

複数の欠陥が偶然重なり合って呼び起こされる場合もあるでしょうし、ハードウェアの性能向上がもたらす欠陥もあったりします。

個人的には、想定された使用方法の中でおきたフォールトと故障に関しては瑕疵扱いでかまわないと思います。

「仕様通りに動かない」のであれば「エラー」も瑕疵に含まれるでしょうが、これはちょっと考えてほしい。

つまり「"計算された結果と正しい結果との間に存在する差異"」はテストと検収で十分、発見できるはずであるし、できないのであればその方法に問題があると言えます。

言い換えれば検収自体がエラーです。

検証責任は利用者にあります。

あまり強く言いすぎると角が立ちますが、それを念頭に置いて交渉をするときがあるかもしれません。

また検証責任が利用者にあるからといって、開発者側も検証作業を発注者に丸投げするのは良くありません。

作業スコープで合意したテスト範囲はきっちり遂行しましょう。

もしテスト計画に不備があるようなら、その旨を共有しましょう。

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

コミュニケーションは仕事をする上でもっとも大切な事の一つですが、仕事を進める上で最もムダな事の一つでもあります。

なぜムダと言っているかというと、コミュニケーション自体がものをつくるわけでありません。

私の数少ない経験上、コミュニケーション・マネジメントはどこ行っても軽んじられているにもかかわらず、軽んじてしまったがためにプロジェクトに重大なオーバーヘッドを発生させる原因にもなっていると思います。

クライアントが何気なく納品を求めたドキュメントはそのわかりやすい例ですが、日常においても「なんでそんなこと知らないの？」みたいな事は思いの外、時間をムダにするものです。

コミュニケーション計画

情報配布

実績報告

ステークホルダー・マネジメント

コミュニケーションに無理、ムダ、抜け、漏れ、冗長さがないか、根本に立ち返って考えてみるのも悪くないはずです。

コミュニケーションをデザインすることを心がけてください。

コミュニケーションパス

ところで、コミュニケーションパスの求め方を知っている人いますか？

n(n-1)/2

n(n-1)/2です。

これ有名な話で、プロジェクトの人数が増えるときはコミュニケーションの時間も工数も増えます。

当たり前です。

1パスが1日当たり15分ほど時間を使うと仮定すると3人までなら管理者は作業者兼務でいけますが、5人くらいから管理者は管理業務専門になり、10人とかになると管理者を手伝う人が必要なります。

ちなみに1パス15分は楽観値です。

おそらく30分から1時間くらいはかかる可能性があります。

またステークホルダーとのコミュニケーションもバカになりません。

結構、もっていかれます。

定例MTGなんかもそういった活動に該当します。

余談ですが、営業の世界では、上長の下に付けられるメンバーの数は7人程度だそうです。

7人はけっこうがんばってもらう感じ。

できれば5人くらいで勘弁してあげた方が良く、10人は管理しきれないそうです。

この例でもあるように、マネージャー一人で10人も20人も、はてはそれ以上のメンバーを管理する話は無理があります。

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

リスクについて、みなさんどのようなイメージをもっていますか？

きっとネガティブなイメージをもっているんじゃないかと思います。

リスク・マネジメント計画

リスク識別

定性的リスク分析

定量的リスク分析

リスク対応計画

リスクの監視コントロール

リスクはいろんなモノがあれど、取るべき対策は受容、回避、軽減、転嫁の4種類しかありません。

書籍によっては5種類になっていることもあったかとおもいますが、所詮そんなモノです。

リスク管理表を作成して、とるべき対策を記述し、2次リスクまで記述しておけば問題ありません。

パーフェクトです。

それをステークホルダーで共有しましょう。

さて、リスクとのつきあい方を考え直してみましょう。

リスクは回避するだけがつきあい方ではないはずです。

リスクから逃れては素晴らしい仕事はできませんし、成長もありません。

デマルコは「リスクのない仕事なんかするな」と書いています。

私もそうだと思います。

だからこそリスクを支配するための見積もりであり、計画であり、プロジェクトマネジメントであると心がけてください。

リスクを支配する（コントロール）する、という考え方をしてみてください。

あの手この手で熊とワルツを踊ってみてください。

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

これ、つまり私がやっている購買業務ですが、なんで購買・調達をやるんでしょうか。

それは一言で言うと「品質、価格、納期、サービスをトータルとして満たすこと」を目指しているからです。

なぜか。

それはITシステム/ソフトウェア開発において、上記の条件をクラスメソッドだけで賄うのは難しい状況に来ているからです。

いま私たちがやっているプロジェクトは複雑なものをやることがありますし、基幹システムとの連携を求められたり、作業範囲が要件定義からだったりして業務に対する専門知識も求められています。

大規模開発に必要な厳格で独特な作法も必要です。

今後、高度で専門的な技術を要求されることも増えると予想しています。

また当然ですが、開発規模が拡大した場合、実装期間を圧縮するために短期間だけ増やすことも必要になる。

そういった限定的なスキルを持つエンジニアを恒常的に社内に囲っておくことはクラスメソッドにとって負担です。

いつもいつもC++の通信モジュールを開発しているわけではないのです。

「調達」は組織の「核」となる部分を保持しつつ、多様な顧客のニーズに対応するために利用されるものです。

それが購買・調達です。

購入・取得計画

契約計画

納入者回答依頼

納入者選定

契約管理

契約終結

購買・調達では納入業者の選定や決定などを管理します。

それと、PMBOKの不思議ですが、なぜか契約の管理は調達となっています。

（発注者の視点、、、なんだろうか？）

立ち位置によってはそれが当然であることも考えられますし、ちょっと不自然な気もします。

私の意見としては、制約として大きな影響力がある契約を調達に含めてしまうのはちょっとどうかな、と思ったります。

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

最後に、これら8つの知識領域をまとめるのが統合です。

プロジェクトマネジメント計画書の策定につながるわけですが、できればみなさん、書いてください。

面倒くさいとは思いますが、立ち上げ・計画時に分かっていることを書いておくことが大切です。

そしてそれをステークホルダーで共有することが大切です。

プロジェクト憲章作成

プロジェクト・スコープ記述書暫定版作成

プロジェクトマネジメント計画書作成

プロジェクト実行の指揮・マネジメント

プロジェクト作業の監視コントロール

統合変更管理

プロジェクト終結

プロジェクトマネジメント計画書策定の際、気をつけることですが、おそらくいろいろな要素が関連し合い、まとめたり洗い出したりする作業が困難になってくる時期があります。

そういうときは下記の原則を思い出すこと。

インプットとアウトプットに着目し、シンプルに考えること。

○○のインプット

○○のツールと技法

○○のアウトプット

PMBOKはシンプルです。

各知識領域に含まれているプラクティスはすべてこの3段階でできています。

前半でお伝えした、計画性の重視とアウトプットとインプットの重視がPMBOKの心です。

しかし各項目は複雑に関連し合っています。

仕上げに各項目の関連性を整理しましょう。

工数にまつわる概念図

これは私が作ったプロジェクトに関わる概念図です。

正解の時もあるし、これを使用するのがふさわしくないときもありますが、頭に入れておくと結構便利です。

もしくは自分なりの概念図を考えても良いと思います。

するとプロジェクトは経験や勘に依存したよくわからない存在から、整理すればそんなに複雑なことではないことが分かると思います。

実際に現場にいると目の前の作業の難しさや複雑さにとらわれてしまうことがありますが、ちょっと引いてみれば意外とシンプルです。

「プロジェクトをデザインする」という感覚。

http://gitanez.seesaa.net/article/100863956.html

こういった視点でプロジェクトを捉えるのも良いと思います。

そろそろまとめ

そろそろまとめます。

「１対１もオフェンスの選択肢の

　一つにすぎねぇ

　それが わからねぇうちは

　おめーには負ける気がしねえ」

　　　　　　仙道彰（陵南バスケ部）

http://www.great-saying.com/w-slumdunk51.html

仕事から帰る途中、三鷹駅から自宅まで歩いて家の近所のブックオフ前を通りがかったときに思い出したんですが、このセリフはとても良いセリフです。

機能スコープの実装こそがプロジェクトの成功だ、と信じているだけではダメなのです。

プロジェクトを成功に導くためにはありとあらゆることをする必要がありますし、言い換えると、ありとあらゆる手段で成功に導くことができます。

機能スコープの達成が厳しいのであれば、交渉をするべきです。

そもそも機能スコープの達成が厳しいのは何か原因があったはずです。

それを上手くコントロールするには機能スコープに関連する物事がプロジェクト中にどのように変化をしたのか記録をとりステークホルダーで共通認識としてもっておく必要があります。

そしていざというときに上手くプロジェクトをリーディングできるように、ステークホルダーの信頼を勝ち取っておくことです。

ちょっと妄想をしてみましょう。

Q)　サッカーの話。試合終了までのこり2分。3点ビハインド。

　　この時点から得られる最良の結果を残すために、あなたなら何をする？

例１　相手チームと審判と交渉してロスタイムを15分にする

例２　相手チームと審判と交渉して10回連続でFKを蹴らしてもらう

例３　相手チームと審判と交渉して、相手チームのGKは手を使うの禁止

などなど。

他にもあると思いますが、ルールという枠にとらわれない発想がプロジェクトマネジャーやプロジェクトリーダーには必要です。

■　まとめ

普通の人からすばらしい成果

すばらしい人から普通の成果

この話の出典は、正確にはアジャイルジャパン2009というイベントで、プロジェクトマネジメントとはちょっとことなるのですが、なぜプロジェクトマネジメント知識を身につけるのか、といった点で参考になるので最後にご紹介します。

すばらしいビジネスのアイディアや、卓越した技術力を持っていたとしても、プロジェクトをマネジメントする能力がなければいきあたりばったりになりますし、そういった組織は早い内にスケールや持続性で限界がやってきます。

プロジェクトマネジメント知識はそういった問題に整理する手法を教えてくれますし、組織がすばらしい成果を出すための礎になるものです。

ですから、本来なら、プロジェクトマネジメントの知識はプロジェクトリーダーやプロジェクトマネジャーだけが知っていればよいのではなく、プロジェクトチームに入っているメンバーはもちろん、外部組織から関わるステークホルダーすべてが知っておいた方が良い知識です。

今日、集まっていただいたみなさんは少なからずプロジェクトマネジメントについて興味があるのだと思います。

できれば、今日の話はそれほど大きなことではないですが、これまで学んだこと、経験をしたことを、同僚、上司、後輩はもちろん、家族や友人に話してください。

そして得られた気づきを仕事やプライベートに活かしていただけると幸いです。

本日はどうもありがとうございました！

■　参考にした本、影響を受けた本（タイトルのみ）

PMBOK　第3版

PMBOK　第4版

アート・オブ・プロジェクトマネジメント

トム・デマルコの「プロジェクト管理」がわかる本

初めてのアジャイル開発

人月の神話（新装版）

計画の科学

ITプロジェクトにおけるソフトウェア外注管理

ベンダー・マネジメントの極意

プロジェクトマネジメント標準　PMBOK入門

いちばんやさしいPMBOKの本

ソフトウェア見積もり

ソフトウェアエンジニアリング基礎知識体系

ソフトウェア開発へのSWEBOKの適用

リーン開発の本質

アート・オブ・アジャイルデベロップメント

本当に使える見積もり技術

アジャイルな見積りと計画づくり

はじめて学ぶソフトウェアメトリクス

プロジェクトコスト見積もり入門

ピープルウェア

熊とワルツを

ゆとりの法則

デッドライン

御社の営業がダメな理由

プレゼンテーションZen

※このリストだけじゃなく雑誌やムックもあったのですが、手元になくタイトルがおもいだせない（石川ダイアグラムのあたりなど）割愛

※ついでにいうと、このテキストには質疑応答などは含まれていません。補足をすると昨日の勉強会でもっとも価値が高かった時間は質疑応答をしていた時だと思っています。