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 / 森 正和

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

活動 ≒ 事業＋コミュニティ＋育成（エンジニア、学生） ● 北九州市立大学 教授級非常勤講師「プログラミング論」 ● 北九州高等専門学校 特命教授 コンピュータ研究部指導員 ● ラジオ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」発足人 ● 独立行政法人 中小企業基盤整備機構 コンサルタント

Elixirで会員制Webアプリを20分で構築・改造するライブ 「ElixirConf Mori」で検索してください (YouTube検索でも) 海外ElixirConfでライブコーディング登壇 (YouTubeも) https://www.youtube.com/watch?v=t5TT0-mI2O4

Bright：エンジニアやPM、デザイナーを評価/採用/育成

目次 01 PM／リーダーがいない？… 03 04 02 PMスキルを学ぶのは難しい？ PMBOKを実務版に組み替えた より具体的なPMスキルは…

7 PM／リーダーがいない？… 01 7

● この数年、「人手不足」が叫ばれ、その中でも特に、PM (プロジェクトマネージャ) やチームリーダーが全く足りて いないようです ● 最近は、PMやリーダーが調達できていないにも関わらず、 「開発メンバーは既に集めたよ」みたいな、宇宙猫が見えて しまうような案件も増えており、 カヲス過ぎる現況かと思います ● なんで、こんなことになって いるんでしょう？ PM／リーダーがいない… 01

● Ａ「いいえ、『タダのスキル』です!!」 ○ 「OJTで習得できる」という思い込みに、真の問題がある ■ PMを任命する人にも、PMに任命される人にも… ● そもそも、PMに求められる数多くのスキルを明確に認識して いない人が多過ぎる？ ○ その結果、PMを「何でも屋」と勘違いしている… ■ これに近い体験をされたことある方、手を挙げて! ○ 認識していたとしても曖昧な解釈や「コミュ力」任せで、 本来、PMが果たす「役割」と「学ぶ事項」を理解してない ● 一方、PMを教える教本やスクールにも欠陥がある ○ 「PM」と一括りにし、クラス分けと、レベル基準が無い Q1「PMやリーダーは経験量だよね？」 01

● Ａ「それも大事ですが、それだけではダメです!!」 ○ 野生の勘でこなす領域は、せいぜい10%程度に留めないと ■ 裏返せば、大半は、科学的かつ再現性あるアプローチに ● 中でも、「メンバーのスキル評価」はPJ遂行に大きな影響 ○ 各人のスキルを把握することで、チームの強弱が見える ■ チームのどこに弱点があるか分かれば、対策が打てる ■ 調達のヒントも得られる ○ しかし、こうしたことを1on1で補うと… ■ 凄まじい工数負荷が発生してしまう ■ 成長がトレースできないケースも多い ● こうした活動を「記憶」と「勘」に頼ると、PM自身の調子の 良し悪しでPJの成否が揺れてしまい、再現性が低下する Q2「PMやリーダー、野生の勘が大事!!」 01

● Ａ「はい、絶対的に必要です!!」 ○ 技術でシステム作るのにソレ無かったら、ただの調整さん ■ この当たり前を見逃すから、PJが普通にトラブる… ● Microsoftは30年以上前、コーディングできない人 をマネージャに据えるのを禁止 (GAFAなども類似) ● 持たない場合、凄まじく面倒な工夫が必要 (認識あるかな？) ○ ａ）エンジニアの意見を鵜呑みにせず、ロジックで弾く ※ロジックは、すぐに反感も生むので「いなす技」も必要 ○ ｂ）設計やコードの間違いを検出する手順を確立する ※どうやって？… ○ ｃ）顧客に「タダのお守り」をしていると気付かせないw Q3「PMやリーダーに技術力、必要？」 01

● PdMやPO、EM、VPoEなどと同様、そもそも高度な役割です ○ 「何となくチーム率いるコミュ力あるから出来るよね？」 ■ いやいや、ムリです ● そもそもPMを任命する人がPMを分かっていない… ● これに近い体験をされたことある方、手を挙げて! そもそもPM、テキトーで済む訳、無い!! 01

● WFだろうが、アジャイルだろうが、〆切に間に合います ● メンバーを無理やり稼働させて…なんてことは、一切ありません ○ そもそもメンバーの力量に依存してPJ立上げしてる時点で負け ● ウチは下記「7段のファイアウォール」で絶対にPJを焦がさない ①PJ立上げ① ○ 当初仕様と追加仕様の厳密な見積／変更管理 ＋ 確実な追加工数請求 (支える交渉力) ②PJ立上げ② ○ 2名程度欠けても成り立つスケジューリングとメンバー選定 (無風なら利益率30～50%) ③PJ立上げ③ ○ WBSに現行仕様のキャッチアップもタスク化 (内製負担にしない) し、顧客を説得 ④体制 ○ 見習いベテランメンバーをバランスし、全PJに育成を敷き、利益率もコントロール ⑤CCPM ○ メンバー各人にバッファを持たせず、PJでバッファコントロールを行う ⑥鼓舞 ○ 「やりたいPJタスク」と「PJ外でもやりたいこと」を聞き、オーナーシップ付与 ○ 業務委託／社員の区別無く実施 → 30～60%はPJ中に叶う ⑦最終手段 ○ メンバー全員がコケても、私1人＋他PJ余剰でどうにかできるコントロール PMがちゃんと機能したらPJはこうなる 01

組織の人材育成・チーム育成が 課題に登りやすいですが…

まず課題を抱えているのは… 育成されるべきは… チームメンバーの方では無く PM／リーダーの方だった(ToT)!! (あと任命する人もついでに)

16 PMスキルを学ぶのは難しい？ 02 16

● 「実務とまるで違うので、全く 役に立たない？…」 ○ 立ち上げがすっからかん ■ 契約やNDAはどこに？ ■ 契約形態の打診は？ ■ 見積提示は？ ■ 体制図は？ ○ 計画もすっからかん ○ 実行もすっからかん ○ 監視・管理もすっからかん ○ 終結もすっからかん ○ これで一体、どうしろと… 「よし、PMBOKを学ぼう!!」 02

「なら、情報処理技術者PM試験だ!!」 02 ● 「基礎知識と論述は勉強になるけど、やっぱ実務と違う…」 ○ PMBOKよりは実務寄りなものの、網羅性が全く充分で無い ○ どちらかと言えば、PM試験はスタート地点でしか無い

実務に紐付いたスキルが 既存のマネジメント題材では 知ることも出来ない現実…

20 PMBOKを実務版に組み替えた 03 20

● PMBOKの「知識エリア」と 「プロセス」の軸はそのままで 中身のスキル50個近くは、全て 換装しました ● その上で、PJ規模毎に各実務の プロセスや成果物をクラス分け しました ● 結果、下記のようなスキル群に ○ クラス1…208スキル ○ クラス2…166スキル ○ クラス3…37スキル 知識エリアとプロセスに実務を紐付ける 03

● Ａ「いいえ、『タダのスキル』です!!」 ○ 「OJTで習得できる」という思い込みに、真の問題がある ■ PMを任命する人にも、PMに任命される人にも… ● そもそも、PMに求められる数多くのスキルを明確に認識して いない人が多過ぎる？ ○ その結果、PMを「何でも屋」と勘違いしている… ■ これに近い体験をされたことある方、手を挙げて! ○ 認識していたとしても曖昧な解釈や「コミュ力」任せで、 本来、PMが果たす「役割」と「学ぶ事項」を理解してない ● 一方、PMを教える教本やスクールにも欠陥がある ○ 「PM」と一括りにし、クラス分けと、レベル基準が無い Q1「PMやリーダーは経験量だよね？」 03

Bright：PMのクラスが規模で3分割され、レベルも3段階 ● 「Bright」でPMスキルのクラス／レベルを判定できます ○ PMBOKの知識エリアとカテゴリをベースにしていますが、 プラクティスは全取っ替えしています (PMBOKは微妙…)

● Ａ「それも大事ですが、それだけではダメです!!」 ○ 野生の勘でこなす領域は、せいぜい10%程度に留めないと ■ 裏返せば、大半は、科学的かつ再現性あるアプローチに ● 中でも、「メンバーのスキル評価」はPJ遂行に大きな影響 ○ 各人のスキルを把握することで、チームの強弱が見える ■ チームのどこに弱点があるか分かれば、対策が打てる ■ 調達のヒントも得られる ○ しかし、こうしたことを1on1で補うと… ■ 凄まじい工数負荷が発生してしまう ■ 成長がトレースできないケースも多い ● こうした活動を「記憶」と「勘」に頼ると、PM自身の調子の 良し悪しでPJの成否が揺れてしまい、再現性が低下する Q2「PMやリーダー、野生の勘が大事!!」 03

Bright：メンバーのスキルが宝石箱のように並んで見える

● Ａ「はい、絶対的に必要です!!」 ○ 技術でシステム作るのにソレ無かったら、ただの調整さん ■ この当たり前を見逃すから、PJが普通にトラブる… ● Microsoftは30年以上前、コーディングできない人 をマネージャに据えるのを禁止 (GAFAなども類似) ● 持たない場合、凄まじく面倒な工夫が必要 (認識あるかな？) ○ ａ）エンジニアの意見を鵜呑みにせず、ロジックで弾く ※ロジックは、すぐに反感も生むので「いなす技」も必要 ○ ｂ）設計やコードの間違いを検出する手順を確立する ※どうやって？… ○ ｃ）顧客に「タダのお守り」をしていると気付かせないw Q3「PMやリーダーに技術力、必要？」 03

Bright：技術スキルもPMスキルと同じように把握できる

この後、Brightをお楽しみください

29 より具体的なPMスキルは… 04 29

● 「Bright 呑みながら」でググってください ● PMやリーダーとして楽しくやってきたい／覚えたい方はぜひ ● プロジェクト運営の突っ込んだ質疑応答やディスカッションも 3/14：次は若手リーダーから聞いてみる 04

That’s all for my talk Thank you very much