PMBOKはどう使えばいいか

PMBOKの第1版はB5サイズで、本文は126ページと用語解説は44ページの少し厚い薄い本だ。

それが第6版になるとA4サイズになり、目次と図表の索引で30ページ近く割くようになった。本文は530ページを超え、紙で読みたいと思うようなものではなくなった。

 

プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)

プロジェクトマネジメント知識体系ガイド PMBOKガイド 第6版(日本語)

 

 

PMI会員であれば、ベネフィットとしてPDF版を入手できるのでPDF版一択である。紙媒体はどうやらコピー対策で可読性がとても酷い状態らしいとamazonの書評で多数書き込みされている。

第2版である2000年版で既に厚く大きいサイズになり、当時から手を余したものだ。

読み物としてのPMBOK

第2版あたりからとても読みづらい本となった。第1版は別に意味、誤訳で読みづらいと聞いたことがあるがそれほど気にならなかったのは、第2版が出る直前で買い、ろくに読んでいないからかもしれない。

知識体系であるから目次も知識エリアごとに統一されており、これが返って読みづらくしている。

体系のツリー構造図、概念から始まり、プロセスのインプット、ツールと技法、アウトプットを繰り返し説明する。プロセスのデーターフロー図は1つの知識エリアに多数含まれるプロセスがあることを証明しているようなものだ。

システム開発を上手くやりたいなら、プロジェクトマネジメントとシステム開発の運営を理解できる本を読んだ方がいい。

 

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう!?

アプリ開発チームのためのプロジェクトマネジメント ?チーム駆動開発でいこう!?

 

 

課題ログ

目次の中に課題ログと言う項目がある。いわゆる課題管理であり、本文と課題管理で管理したい項目が列挙されている。

箇条書きの項目を見る限り、実際に課題管理に使いたい項目よりは少ないのはPMBOKが業種を横断してプラクティスを集め、それらからどの業界でも使えるように共通項を抜き出したからだろう。

それでも、プロジェクトマネジメントの経験のないエンジニアが課題管理で(最低限の)課題管理をしようと思ってPMBOKを読んだとしたら、これで管理項目は作れるだろう。

統合変更管理ツール

統合変更管理での統合変更管理ツールを読むとPMBOKが何であるか片鱗を知ることができるのではないか。考え方としなければならないことの説明が書かれている。

2000年代に日経BPあたりがPMBOKを流行らせたとき、PMBOKがプロジェクトを成功に導く銀の弾であるかと飛びついた経営者達は現場にPMBOKを導入することを求めた。現場はこれでどうしろと言うのだと思ったに違いない。

それはその通りで、日頃から書いているようにPMBOKは器でしかない。考え方だけだ。前述の課題ログのように項目が記載されているだけでもマシなのだ。

テーラリング

PMBOKは体系であるから、業界を問わずプロジェクトとして事業をする業界に適用できるように作られている。

結果、共通項だけになるのはもちろん、体系であるかこそ冗長に書かれる。それをPMBOKではプロジェクトマネジメントを行う側のプロジェクトに合わせてテーラリングを行うことを求めている。

この辺りの考えは標準化をするときと同じである。

品質

EOF2019あたりでも品質のことについて言及があったようだが、エンジニアが開発プロセスでプロジェクトの要求事項を製品なりサービスなりが備えられていることを担保してくれれば、そもそも品質マネジメントなど必要はない。

 

IT業界の病理学

IT業界の病理学

 

 

それができないから、品質マネジメントの切り口で、尺度を定め、データを収集し、分析し、品質の監査を行うのである。

繰り返せば、開発プロセスで品質を考慮しないケースで失敗を繰り返すから、知識体系として品質マネジメントを入れているのである。そうもしないと品質のリスクからプロジェクトが失敗しかねない。

QCDのQはQualityであり、3つの1パーツでしかない。

どう使えばいいか

システム開発においてPMBOKをどう使うか。

それはシステム開発のプロセスから得られるデータや情報に対して、PMBOKの観点でプロジェクトが期待するように進捗しているかをモニタリングする仕組みとして使う。

プロジェクトをモニタリングしたいメッシュで情報を持っていなければならないから、システム開発側では情報を要求される単位で持たなければならない。

言い換えれば、システム開発とプロジェクトマネジメントのインタフェースを決め、そのインタフェースで得られる情報でプロジェクトをコントロールする仕組みを作ればいい。

 

 

 

 

AI上司の部下になったら

ところで昨日とか仕事を邪魔する上司的なタイトルの記事を見かけたので、いい上司と仕事をしたことが何のだなと可哀想な気持ちになりつつも、であればそろそろAIに理想の上司とやらをやってもらうサービスを作ったらいいじゃないかと思ったりするのだがどちらかのServicerで提供してみてはどうだろうか。

AI上司ならいつも笑顔で、ポジティブで、能力を引き出してくれるだろう。

その代わり、AI上司は部下を観察して必要なアドバイスをするた情報を多く必要とするだろうから、常時カメラ、マイク、行動ログなどあらゆる業務上のログをとるかもしれない。

でも、人間の上司にはうんざりしているなら拒否権はない。

それとAIが上司のポジションになるのだから、エンジニアはずっとエンジニアで管理職になるキャリアパスは閉ざされる。残るはエンジニアのプロとしてのキャリアパスだけだ。

経営者→AI上司→|(超えられな壁)|→エンジニア。

こんな組織体制図になるのだ。

5年も持たないだろう、こんな組織は。

そうそう、業績評価も楽しみだ。

今まで定性的な自己評価でも通って評価されていたとしたら、AI上司には通じない。定量的で成果を数字で、論理的に貢献度を説明しなければ、理解できないと突っ返されてしまう。

なにぶん、理想の上司としてAIに学習させるのであるから、理想ばかり要求する上司になることは確実だ。

さてダメな上司とAI上司とどちらがマシなのだろう。

 

 

プロマネになる資質を持っているかどうかを判別する問いかけ

あるメンバが割とレベルの高い業務改善のリーダをやっている。客観的に見ていて、少し不安を感じている。

基本的には本人はwillを持っているし、多分できるだろうと楽観的に言っているので介入をするつもりはないのである。文化的にwillを持つエンジニアにはプロジェクトをリードを委ねる。

とは言え、不安を感じているのでそのモヤモヤ感を払拭したく、帰り際に声を掛けて雑談ぽく会話をする。

雑談の狙いは業務改善の実現可能性である。

では何でそれを検証するかと言えば、頭の中にどれだけ段取りや中間生産物を含むアウトプットのディティールを持っているかを確かめられれば個人的には『まあ、できるんではないかな』と思える。

見切れるかと言う観点で感触を得ることは大事なのである。

 

それで会話をするのであるが、全くもってスッキリしない。段取りは考えているが一つひとつの段取りのディティールやアウトプットがモヤっとしている。

例えば調査をするためのアプローチを決め打ちしているようなのだが、アプローチは他にもある。それぞれのメリデメを踏まえた上で意思決定しなければ、やり直しになる。

付き合わされる方のコストやマインドを考えることも必要である。

なんとなく雑談をしていて、エンジニアは想定していなかったアプローチを選択することによる導入コスト、つまりヒヤリングする対象者へのちょっとした教育コストを嫌がっているのではないかと思えてきた。

 

他にもある。段取りのディティールがモヤっとしていることは結局、解消できなかった。こうやろうと思っていると言うこれもwillと言えばwillなのだが、どう聞いても何度か聞き直しても手戻り前提、作業を詰め切るところは先送りにしか聞こえない。

 

プロマネをやると言うことは、目的の成果を期日までに完成させると言うことだ。

 

  • 目的の完成イメージを共有できないエンジニアはプロマネは向いているだろうか
  • 目的を構成するはずのパーツを段階的に作るなら、パーツをいつまでに作ると言う意志を説明できないエンジニアにプロマネは向いているだろうか
  • パーツの作り方をわかっていないエンジニアにプロマネは向いているだろうか

 

表現を変えればプロジェクトの組み立て、アーキテクチャをデザインできるかどうかが判別のキーなのではないかと思うのであるがおかしなことを言っているだろうか。

 

 

 

他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)

他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)

 

 

 

プロジェクト・チキンレース

プロジェクトマネージャをやり始めたころの経験談を少し違う切り口で。

要点

  • 遅れているとは言いたくない
  • プロマネ自身でスケジュールをクラッシュさせる

エンジニアが進捗を遅れていると言いたくないのと同じようにプロマネも進捗を遅れているとは言いたくない。

エンジニアはプロマネに進捗の予実を報告するが、そこであるがままに報告されないと認知できないから、結果的に予実の較差を孕んだままプロジェクト全体として報告する。

プロマネは顧客にプロジェクトの進捗と遅れていれば対策を示す。大切なことは、予実を把握していて、プロマネが対策を打ってあると顧客にあれこれ言われる前に宣言することである。

先手必勝。

遅れている、何もしていないとわかると、誰でもが思うように、対策をしないのか、どうして起きたのか、横並びでプロジェクト内の点検は必要ないか、など後ろ向きな指摘が出て、そこにリソースを割かざるを得ない状況になってしまう。

プロマネが遅れていないと言いたくないのは、余計なことをしたくないからであるし、実際、余計なことをやれるリソースもない。そんなリソースがあるなら他に回したい。

プロマネも人の子であるから、いい格好をしたい。

プロジェクトをやっていれば、顧客と毎週のように進捗や課題を確認していれば、あれこれちょっとしたことをやって欲しいとお願いされる。

最初に、要望を受け入れるときのプロセスを明示しておいて、要望を双方で吟味し、それに係る全ての費用を請求するようにしておくことがプロマネの仕事でもある。

追加でない、もともと顧客の分担の仕事の進捗遅れもままある。

実はこれもリスクである。

「いつまで待ってもらえますか」

と聞かれるとプロマネなので即答しなければ全体の進捗を押さえていないと思われてたらどうしようと頭をよぎる。

つい、もう1週間なら、などと約束してしまう。

これもプロマネがいい格好をしようとしたからである。

 

プロマネは内心、行けるかな、行けるよな、とスケジュールの限界に挑戦するチキンレースを始めてしまうのだ。

 

結果、何が起きるかといえば、エンジニアのスケジュールを前から潰してしまう。

これも冷静に考えれば、エンジニアのスケジュールを確保すべく、後続工程の作業の一部をバーターするかプロジェクト費用の追加を打診すべきである。

柔軟な対応としては、1-2日までなら良いがそれ以上は無理だと言うべきことである。

良い格好をしようとするとプロマネ自身でスケジュールをクラッシュさせて壊してしまう。

 

 

 

 

 

ガーっと全部作ってしまう

 

もし仕事で(仕事でなくてもいい)アウトプットをぼんやりとしかイメージをできておらず、どう手をつけるか悩んでいるなら、最後まで勢いでガーっと全部作ってしまうのがいい。

どうせ進捗していないのだから、細かいことは気にしない。どうせディティールなんてわかっていないのだから、それは飛ばして最後まで作ってしまう。

ポイントは、ガーっと、全部、最後まで。

一度書いてみれば、それが欲しいものか、欲しいものでないか自分で判断できる。

最後まで作ったものが頼まれたものなら、これが欲しかったかを現物で確かめられる。

ほら、なんかそんなシステム開発手法があった気がするけど、それ。

細々とあちらこちら気にしていたら進みは遅くなる。

いつまで経っても手に入れられない。

だから、ガーっと全部作る。

細かいことはあと。

一度、全部作って、眺める。

早い。

 

 

 

 

マネージャとしてやっている10のコミュニケーション

プロマネをやったり、マネージャをやったりしていて、経験的にか本か何かで知ったこともあるかもしれないが、無意識にやっている10のコミュニケーション。

 

  1. 笑顔で応える(スマイルはプライスレス)
  2. 話を聞く(聞いてから相談のポイントに沿って考える)
  3. 理解できなことは教えてもらう(自分の専門以外できる人は専門家)
  4. willを持っていれば裁量を渡す(基本は全面的に渡しヤバそうなときは助ける)
  5. 段取りを教えてもらう(作業の抜け漏れを知る)
  6. 基準を教えてもらう(開始基準、完了基準などを知る)
  7. マイルストーンが設定されちるか見る(期限に終わるリソースを揃えているかを見る)
  8. 出来たら一緒に喜ぶ(嬉しいー)
  9. 犯人探しをしない(トラブルの原因は作業プロセスのデザインにある)
  10. 自分で知りたいことは自分から聞きに行く(呼びつけない)

 

 

リングフィット アドベンチャー -Switch

リングフィット アドベンチャー -Switch

 

 

 

 

 

毎日ブログを書くことの弊害

今いま、かなりプロジェクトの佳境に入っている。御多分に洩れず、数多の担当業務に対してプライオリティ、優先順位づけをして自分のリソースを割り当てているため、フォーカスしない業務は劣後する。ときどき誰か、上司か同僚が劣後した担当業務を思い出すのできっぱりと『それは後』と返すことで納期の延伸を図っている(現状、それで回避はうまくいっている)。

当然であるが、佳境のプロジェクトは大きな問題もなく進捗している。大きな問題もないが、そのプロジェクトとルーチンワークと差し込みのワークとがあるため、常時リソースは天井に張り付いているような状況である。

ところで、ずっと気にかけていることがあり、自分の仕事としてやらなければと思っていることがある。これは前述の数多の担当業務というよりはポジション的にしなければならないことだと認識している。しているが結果、数多の担当業務と同じように劣後している。

その代償は、いわゆる社員満足度調査の数字に現れている。

マネージャとして担当業務を持つこと自体、事業会社であれば当然である。ただチームの仕事の予実を数字や報告で眺めるのが仕事ではない。ではないが、チームに対するいくつかのことに対してリソースを割かなければならない。

その意味では、マネージャの仕事をしているかというと担当となってしまっているのでマネージャの仕事の一部をしていないことになる。

これまで、エンジニアは自分のリソースを全部作業で埋めてはいけないと書き残してきた。なぜなら、作業に落とし込む前の考える時間を取らないとクリエイティビティなアイデアを考え出すことも、新しいアプローチを考えることも、それを実践することもできないからである。

このブログは30分スプリントのイメージで時間枠を少しだけ気にして書いている。書き始めるまでの題材を決めるのに時間を取られるのが従来からの問題であることに変わりはないが、そのくらいの時間を枠に書いている。

なぜ書き続けるかというと、当初は書くことに対する素振り的な位置付けであった。その目的は達成されたのであるが、習慣として身についたのでこれをやめる勇気を持てない。やめてしまうと書けなくなってしまわないかとか、つまらないことだが連続記録を止めてしまうということも割と大きい。

さてさて、どうしたものか。

 

 

 

リングフィット アドベンチャー -Switch

リングフィット アドベンチャー -Switch