ちゃんと血の通ったPM／リーダーをするには？

Transcript

1. 2024/01/18 (Thu) プロマネチョットデキル#1 「PMやリーダーが輝くためには？」 血の通ったPM／リーダーをするには？ ～ これまでのチームワーク論やリーダー論はIT時代に追いつけてない ～ （元題：火を消すのは「PM風」、火を出さないのが本当の「PM」） Dec. 18, 2023 ver 1.0 created . Jan. 18, 2024 ver 1.0 updated. 株式会社DigiDockConsulting 常務取締役CTO Elixirコミュニティ「fukuoka.ex」「ElixirImp」「LiveView JP」オーガナイザ 国際カンファレンス「ElixirConf JP」ファウンダー AIスクール「AIジョブカレ」福岡校開校講師 北九州市立大学 「プログラミング論」教授級非常勤講師 北九州高等専門学校 特命教授 / コンピュータ研究部 指導員 piacere / 森 正和
2. my favotite technologies & implements Twitter / NeosVR / Discord @piacere_ex Github / YouTube / Qiita @piacerex 41年前からプログラマ（職業のそれは28年） PM／PdM／PO歴：26年／18年／7年 アジャイル歴：25年 (eXtreme Programming) 書けるプログラミング言語：158言語 小学4年生でゲームプログラミングを始め、現在も プロダクトとOSSを開発し、事業やコミュニティの 優位性へと転用するエンジニア／3社の経営者／PO 大手企業をメイン顧客として、IT事業／データ分析 ／VR・AR／分散・並行技術／UX・D2C指導を提供 技術コミュニティも複数発足・主催しており、毎月 イベント開催とLT、ライブコーディングをこなす piacere / 森 正和 “piacere” is an Italian word, means “Joy” == == Real Online VR / AR
3. 活動 ≒ 事業＋コミュニティ＋育成（エンジニア、学生） • 北九州市立大学 教授級非常勤講師「プログラミング論」 • 北九州高等専門学校 特命教授 コンピュータ研究部指導員 • ラジオFM KITAQ「Technology Cruising Night」パーソナリティ • 株式会社DigiDockConsulting 常務取締役CTO • ほかIT企業2社経営、技術顧問3社担当 • Elixirコミュニティ「fukuoka.ex」創始者 • Elixir国際カンファレンス「ElixirConf JP」創始者 • 「ElixirImp」「LiveView JP」ファウンダー • AIスクール「AIジョブカレ」福岡校開校者 • Elixirスクール「Elixir |> College」創始者 • 高知県 工業技術センター AI・機械学習 研修講師 • 上級AI開発コミュニティ「IAIFukuoka」発足人 • 独立行政法人 中小企業基盤整備機構 コンサルタント
4. Elixirで会員制Webアプリを20分で構築・改造するライブ 「ElixirConf Mori」で検索してください (YouTube検索でも) 海外ElixirConfでライブコーディング登壇 (YouTubeも) https://www.youtube.com/watch?v=t5TT0-mI2O4
5. Bright：エンジニアやPM、デザイナーを評価/採用/育成
6. 目次 01 PM／リーダーがいない？… 03 04 02 PMスキルを学ぶのは難しい？ PMBOKを実務版に組み替えた より具体的なPMスキルは…
7. 7 PM／リーダーがいない？… 01 7
8. • この数年、「人手不足」が叫ばれ、その中でも特に、PM (プロジェクトマネージャ) やチームリーダーが全く足りて いないようです • 最近は、PMやリーダーが調達できていないにも関わらず、 「開発メンバーは既に集めたよ」みたいな、宇宙猫が見えて しまうような案件も増えており、 カヲス過ぎる現況かと思います • なんで、こんなことになって いるんでしょう？ PM／リーダーがいない… 01
9. • Ａ「いいえ、『タダのスキル』です!!」 ◦ 「OJTで習得できる」という思い込みに、真の問題がある ▪ PMを任命する人にも、PMに任命される人にも… • そもそも、PMに求められる数多くのスキルを明確に認識して いない人が多過ぎる？ ◦ その結果、PMを「何でも屋」と勘違いしている… ▪ これに近い体験をされたことある方、手を挙げて! ◦ 認識していたとしても曖昧な解釈や「コミュ力」任せで、 本来、PMが果たす「役割」と「学ぶ事項」を理解してない • 一方、PMを教える教本やスクールにも欠陥がある ◦ 「PM」と一括りにし、クラス分けと、レベル基準が無い Q1「PMやリーダーは経験量だよね？」 01
10. • Ａ「それも大事ですが、それだけではダメです!!」 ◦ 野生の勘でこなす領域は、せいぜい10%程度に留めないと ▪ 裏返せば、大半は、科学的かつ再現性あるアプローチに • 中でも、「メンバーのスキル評価」はPJ遂行に大きな影響 ◦ 各人のスキルを把握することで、チームの強弱が見える ▪ チームのどこに弱点があるか分かれば、対策が打てる ▪ 調達のヒントも得られる ◦ しかし、こうしたことを1on1で補うと… ▪ 凄まじい工数負荷が発生してしまう ▪ 成長がトレースできないケースも多い • こうした活動を「記憶」と「勘」に頼ると、PM自身の調子の 良し悪しでPJの成否が揺れてしまい、再現性が低下する Q2「PMやリーダー、野生の勘が大事!!」 01
11. • Ａ「はい、絶対的に必要です!!」 ◦ 技術でシステム作るのにソレ無かったら、ただの調整さん ▪ この当たり前を見逃すから、PJが普通にトラブる… • Microsoftは30年以上前、コーディングできない人 をマネージャに据えるのを禁止 (GAFAなども類似) • 持たない場合、凄まじく面倒な工夫が必要 (認識あるかな？) ◦ ａ）エンジニアの意見を鵜呑みにせず、ロジックで弾く ※ロジックは、すぐに反感も生むので「いなす技」も必要 ◦ ｂ）設計やコードの間違いを検出する手順を確立する ※どうやって？… ◦ ｃ）顧客に「タダのお守り」をしていると気付かせないw Q3「PMやリーダーに技術力、必要？」 01
12. • PdMやPO、EM、VPoEなどと同様、そもそも高度な役割です ◦ 「何となくチーム率いるコミュ力あるから出来るよね？」 ▪ いやいや、ムリです • そもそもPMを任命する人がPMを分かっていない… • これに近い体験をされたことある方、手を挙げて! そもそもPM、テキトーで済む訳、無い!! 01
13. • WFだろうが、アジャイルだろうが、〆切に間に合います • メンバーを無理やり稼働させて…なんてことは、一切ありません ◦ そもそもメンバーの力量に依存してPJ立上げしてる時点で負け • ウチは下記「7段のファイアウォール」で絶対にPJを焦がさない ①PJ立上げ① ◦ 当初仕様と追加仕様の厳密な見積／変更管理 ＋ 確実な追加工数請求 (支える交渉力) ②PJ立上げ② ◦ 2名程度欠けても成り立つスケジューリングとメンバー選定 (無風なら利益率30～50%) ③PJ立上げ③ ◦ WBSに現行仕様のキャッチアップもタスク化 (内製負担にしない) し、顧客を説得 ④体制 ◦ 見習いベテランメンバーをバランスし、全PJに育成を敷き、利益率もコントロール ⑤CCPM ◦ メンバー各人にバッファを持たせず、PJでバッファコントロールを行う ⑥鼓舞 ◦ 「やりたいPJタスク」と「PJ外でもやりたいこと」を聞き、オーナーシップ付与 ◦ 業務委託／社員の区別無く実施 → 30～60%はPJ中に叶う ⑦最終手段 ◦ メンバー全員がコケても、私1人＋他PJ余剰でどうにかできるコントロール PMがちゃんと機能したらPJはこうなる 01
14. 組織の人材育成・チーム育成が 課題に登りやすいですが…
15. まず課題を抱えているのは… 育成されるべきは… チームメンバーの方では無く PM／リーダーの方だった(ToT)!! (あと任命する人もついでに)
16. 16 PMスキルを学ぶのは難しい？ 02 16
17. • 「実務とまるで違うので、全く 役に立たない？…」 ◦ 立ち上げがすっからかん ▪ 契約やNDAはどこに？ ▪ 契約形態の打診は？ ▪ 見積提示は？ ▪ 体制図は？ ◦ 計画もすっからかん ◦ 実行もすっからかん ◦ 監視・管理もすっからかん ◦ 終結もすっからかん ◦ これで一体、どうしろと… 「よし、PMBOKを学ぼう!!」 02
18. 「なら、情報処理技術者PM試験だ!!」 02 • 「基礎知識と論述は勉強になるけど、やっぱ実務と違う…」 ◦ PMBOKよりは実務寄りなものの、網羅性が全く充分で無い ◦ どちらかと言えば、PM試験はスタート地点でしか無い
19. 実務に紐付いたスキルが 既存のマネジメント題材では 知ることも出来ない現実…
20. 20 PMBOKを実務版に組み替えた 03 20
21. • PMBOKの「知識エリア」と 「プロセス」の軸はそのままで 中身のスキル50個近くは、全て 換装しました • その上で、PJ規模毎に各実務の プロセスや成果物をクラス分け しました • 結果、下記のようなスキル群に ◦ クラス1…208スキル ◦ クラス2…166スキル ◦ クラス3…37スキル 知識エリアとプロセスに実務を紐付ける 03
22. • Ａ「いいえ、『タダのスキル』です!!」 ◦ 「OJTで習得できる」という思い込みに、真の問題がある ▪ PMを任命する人にも、PMに任命される人にも… • そもそも、PMに求められる数多くのスキルを明確に認識して いない人が多過ぎる？ ◦ その結果、PMを「何でも屋」と勘違いしている… ▪ これに近い体験をされたことある方、手を挙げて! ◦ 認識していたとしても曖昧な解釈や「コミュ力」任せで、 本来、PMが果たす「役割」と「学ぶ事項」を理解してない • 一方、PMを教える教本やスクールにも欠陥がある ◦ 「PM」と一括りにし、クラス分けと、レベル基準が無い Q1「PMやリーダーは経験量だよね？」 03
23. Bright：PMのクラスが規模で3分割され、レベルも3段階 • 「Bright」でPMスキルのクラス／レベルを判定できます ◦ PMBOKの知識エリアとカテゴリをベースにしていますが、 プラクティスは全取っ替えしています (PMBOKは微妙…)
24. • Ａ「それも大事ですが、それだけではダメです!!」 ◦ 野生の勘でこなす領域は、せいぜい10%程度に留めないと ▪ 裏返せば、大半は、科学的かつ再現性あるアプローチに • 中でも、「メンバーのスキル評価」はPJ遂行に大きな影響 ◦ 各人のスキルを把握することで、チームの強弱が見える ▪ チームのどこに弱点があるか分かれば、対策が打てる ▪ 調達のヒントも得られる ◦ しかし、こうしたことを1on1で補うと… ▪ 凄まじい工数負荷が発生してしまう ▪ 成長がトレースできないケースも多い • こうした活動を「記憶」と「勘」に頼ると、PM自身の調子の 良し悪しでPJの成否が揺れてしまい、再現性が低下する Q2「PMやリーダー、野生の勘が大事!!」 03
25. Bright：メンバーのスキルが宝石箱のように並んで見える
26. • Ａ「はい、絶対的に必要です!!」 ◦ 技術でシステム作るのにソレ無かったら、ただの調整さん ▪ この当たり前を見逃すから、PJが普通にトラブる… • Microsoftは30年以上前、コーディングできない人 をマネージャに据えるのを禁止 (GAFAなども類似) • 持たない場合、凄まじく面倒な工夫が必要 (認識あるかな？) ◦ ａ）エンジニアの意見を鵜呑みにせず、ロジックで弾く ※ロジックは、すぐに反感も生むので「いなす技」も必要 ◦ ｂ）設計やコードの間違いを検出する手順を確立する ※どうやって？… ◦ ｃ）顧客に「タダのお守り」をしていると気付かせないw Q3「PMやリーダーに技術力、必要？」 03
27. Bright：技術スキルもPMスキルと同じように把握できる
28. この後、Brightをお楽しみください
29. 29 より具体的なPMスキルは… 04 29
30. • 「Bright 呑みながら」でググってください • PMやリーダーとして楽しくやってきたい／覚えたい方はぜひ • プロジェクト運営の突っ込んだ質疑応答やディスカッションも 3/14：次は若手リーダーから聞いてみる 04
31. That’s all for my talk Thank you very much