PMBOKってなーに?
https://gyazo.com/44516dc5d2a98c2d05ca699f58281587
◆もくじ
はじめに
エンジニアがプロジェクトマネジメントを学ぶということ
PMBOKとは
知識エリアを順番に見ていく
まとめ
◆はじめに
プロジェクトマネジメントの知識体系であるPMBOKがどんなものか知る会
知識エリアをざっくり解説
プロジェクトに参加したことがあればたぶんわかる
マネジメントの経験は気にしない
PMは
「プロジェクトマネジメント」だったり
「プロダクトマネジメント」だったりするけど
ここでは「プロジェクトマネジメント」
プロジェクトマネジメント:終わることが目的
プロダクトマネジメント:(プロダクト、サービスが)終わらないことが目的
◆エンジニアがプロジェクトマネジメントを学ぶということ 1
エンジニアもプロジェクトマネジメントについて知っておいてほしい
suima.icon私も今はマネジメントもやってるけど勉強はマネジメントやる前から始めたよ
「マネジメントやりたくない!ずっとエンジニアでいたい!」はOK
でもプロジェクトマネジメントについて知らなくていいってわけじゃないですよね?
例:
英語しか喋れないオフショアメンバを統率しなきゃいけないマネージャ
あなたはユーザと日本語でやり取りした内容を英語にしてメンバに伝えなきゃいけない
そんな中でメンバが「ニホンゴ チョットナラワカル」ってなったら…?
めっちゃ助かりますよね?そんな感じです
◆エンジニアがプロジェクトマネジメントを学ぶということ 2
自分ひとりだけで何かを簡潔することは少ないはず
ひとり情シスは… hikariare.icon
ひとりでやるとしても自分がやってることを客観的にマネジメントできると強い
考え方・観点・視点を知るだけでも結構変わる
PMの取り組みの意味や目的がわかる
◆PMBOKとは 1/2
A Guide to the Project Management Body of Knowledge
プロジェクトマネジメント知識体系ガイド
ぴんぼっく
プロジェクトマネジメントに関するノウハウ、手段、ベストプラクティスなどの知識体系
国際的に標準とされている
最新版は第6版(アジャイルについても触れられているらしい)
BABOKとかSABOKとかもあるよ
BABOK : Business Analysis
SABOK : Strategy and Analysis
◆PMBOKとは 2/2
47のプロセスを10の知識エリアと5のプロセス群に分類している
知識エリア × プロセス群のすべてにプロセスがあるわけじゃない
プロセス:ツール・技法に対する入力と出力がある
ITILとかのプロセスの考え方と同じ
名前の通り「ガイドブック」
◆5つプロセス群×10の知識エリア
https://gyazo.com/6d53c53a232c3ca26f89e2811008ceee
◆5のプロセス群 1/2
https://gyazo.com/8a00df9186092ec912b02803dc9e8fef
1 立上げプロセス群
何しようか
2 計画プロセス群
どうしようか
3 実行プロセス群
実際にやってみる
◆5のプロセス群 2/2
https://gyazo.com/8a00df9186092ec912b02803dc9e8fef
4 監視・コントロール・プロセス群
うまくいってるか(計画通りか)
整合性が取れているか
5 終結プロセス群
PJ終了の手続き
◆10の知識エリア 1/5
1 統合マネジメント
それぞれの管理が同じ目的を目指しているか
バラバラになってない?
2 スコープマネジメント
どこまでやる?
◆10の知識エリア 2/5
3 タイムマネジメント(スケジュール管理)
予定通り?遅れてない?
4 コストマネジメント
予算内?今いくら使ってる?
◆10の知識エリア 3/5
5 品質マネジメント
品質目標は?
どう担保する?そのために何をする?
テストした結果は?
6 人的資源マネジメント
人・能力足りてる?
◆10の知識エリア 4/5
7 コミュニケーションマネジメント
誰と連絡とればいい?いつとればいい?
ドキュメントはどうする?
会議体は?
8 リスクマネジメント
リスクは何?対応する?
そのための備えは?
◆10の知識エリア 5/5
9 調達マネジメント
調達計画、引合計画
外部から調達することはあるか
契約管理
10 ステークホルダーマネジメント
権限持ってる人は誰?
影響受ける人は誰?
※コミュニケーションマネジメントから独立したらしいよ
◆まとめ
つまみ食いできるプロジェクトマネジメントのフレームワーク
ちょっとでも学ぶと「あれはこれだったのか」感があるかもね
知ってるとヤバそうなPJが察知できる(かもしれない)
マネジメントがちゃんとしていればエンジニアは気にしないで動けることが増える
@余談 IPAのPM試験
暗記内容は比較的少ない
午後1は「〇〇に関する次の記述を読んで設問に答えよ」の「〇〇」を意識して読まないと思考が発散する
午後2しんどい
「PMっぽさ」「リアルさ」が大事
論述の中ではおそらく一番書きやすい(少なくともSTよりは)
2019.01.30 の主な質疑+余談
エビデンスの残し方 みたいなのはコミュニケーションマネジメント?
エビデンスは品質マネジメントだと思います
どういうエビデンスを残したら品質が担保できてると言えるだろうか という観点なので
エンジニアはプログラミングだけやってたらだめ?
担当する作業としてはプログラミングになるかもしれませんが、プロジェクトとして、チームとして動いているものであれば知っておくと便利です
指示の意図や目的がわかるようになったり、問題を共有するときの共通の考え方として役立ちます
PMBOKはウォーターフォールモデル用?
ウォーターフォールモデルでも使えますが、専用というわけではありません
アジャイルのような繰り返し構築していくスパイラルモデルでも、ひとつひとつのプロセスや作るものに対する視点、観点は共通するものだからです
BPはマネージャにならないよね(だから勉強してもねぇ…)
組織、現場にも寄りますが部分的に任せてもらえることはあります
プロジェクトが複数のチームに分割されていたり、そのチームがさらに分割されていて(ユニットと呼んでいました)、その中のリーダーはプロパーじゃないこともありました
マネージャとしてではなく補佐的な役割とかだと立場関係なく「わかってる人」であれば任せてもらえるのではと思います
自身がマネージャにならなくても「プロジェクト全体のことを考えて動ける開発メンバー」は重宝されると思いますし、私がマネージャだったらメンバーにほしいです
色々な企業のマネージャとお仕事してきましたが、企業によってPMさんの性格が違うと感じています。(中略)本人の資質以外にも、企業文化の問題もあると考えていますが、どう思いますか?
基本的には本人の資質だと思っています
(特に日本では)役職的に地位が高い人がPMをやる傾向にあるので、どんな人が評価されるか(=企業文化)に依存するのではと思います
役職者には「組織マネジメント」の力が求められる(はず)のに対し、PMには「プロジェクトマネジメント」の力が求められるので、そこを同一視してしまってるのだと考えています
マイクロマネジメントつらい
マイクロマネジメント=細かく指示を与えて担当者が自分で決めることができる範囲が非常に狭い(=裁量がない)状態
ずっとマイクロマネジメントされるのは非常につらいですね…
(コメントより)新卒とか初心者にはマイクロマネジメントもよさそう
段階によって徐々に裁量を与えていくのがいいですね
SL理論(Situation Leadership理論)という考え方があるので参考にしてみてください
PMBOKはマネージャにはいいけどメンバーには少し重い(学習コストが高い)よね
簡易版 PMBOK lite 作ります!
他にも、沢渡さん、湊川さんによる「マンガでわかるプロジェクトマネジメント」の構想が…?
すでにそのタイトルの本があるっぽい…