#開発PM勉強会「プロジェクトマネジメントの「コツ」を知ろう」への質問へなんでも答えてみた
はじめに
sweeep CTOの平下です。先日開発PM勉強会主催のこちらでLTとパネルディスカッションさせていただきました（当日は百数十名参加いだいた模様）。
その際にたくさん質問いただいたので、その回答をtweetしたものをまとめます（#開発PM勉強会タグでtweet。いくつか加筆修正も）。以下内容です。
- 開発手法編
- 組織編
- その他質問編
- 勉強会参考資料
- 最後に悩めるPMへ
開発手法編
プロジェクト管理ツール
Q: フリーの有用なスケジュール・タスク管理ツール？
A: フリーだとNotionやTrelloでしょうか（フリーだと制限有）。
ただ、開発規模や人数が増えるとカンバン方式ではツラくなってくるので、有料のJiraやBacklogなどがオススメでしょうか。弊社ではBacklog使用しています。
KPT：Keep/Problem/Try
Q: KPTの振り返りで心掛けてることあれば聞いてみたいです。
A: ProblemやTryを深堀りする質問をします。
たとえば、
P:ムダな会議が多い→T:会議をなくす、ではなく、
なぜムダだと感じているのか？議論が発散していると感じている→Agendaを事前に用意する、というTryに変えるなど。
コミュニケーション
Q: RPGのようなバーチャルオフィスシステムを利用されておりましたが、こちらはサードベンダーのプロダクトでしょうか。
A: gather townというバーチャルオフィスでGather社が提供するWebサービスです（25人まで無料）。
クラスメソッドさんの紹介記事。
ステークホルダーとのコミュニケーション
Q: お客様向けに、進捗をうまく表現するコツ？（何個か遅れているタスクがあっても、将来までみこすと大したことない）
A: プロジェクト全体のバッファー有スケジュールをベースに話をします。
プロジェクト全体のバッファーを積んでおき、個々のタスクのどれか遅れてもそのバッファーで吸収し全体では遅れていないと説明します。ここのタスクにバッファーを積んでしまうとこれが難しくなります。
ステークホルダーの期待値コントロール
Q: 炎上しないコツ？
A: ステークホルダーの期待値をコントロールします。
ステークホルダー密にコミュニケーションをとってQCD期待値をこまめにすり合わせます。Q:思っていたのと違うを避ける、C:予実が乖離、D:まめな進捗連絡など。とくにめんどうだな、と思うステークホルダーほどまめにコミュニケーションをとったほうがよいです。
プロジェクトのKPI
Q: PMとしてのKPIてどんなものがあるか？
A: 定番はQCDでしょうか。
Q: たとえば、テストケースや消化件数やバグの抽出率、C:プロジェクトコストの予実、D:スケジュールの進捗など。
開発見積
Q: PMとして把握できない・指示できない開発スキルを、どのように指示したり見積もったりすればよいか？
A: プランニングポーカーを実施します。
メンバーのスキルは一様でないので、プランニングポーカーを実施し、工数見積の精度を上げたり、アサインを調整したりします。
品質管理
Q: 仕様変更を乱発し品質が低下。
A: 設計書を作成・更新し、検証をまわします。
イチから作成は難しいかもですが、変更仕様書とかDB設計などできるところから作成し、それに基づいたテストケースを充実させて検証をまわすようにします。
組織編
PM育成
Q: 社内でPMを育てる場合はエンジニアにこだわる必要もないのでしょうか？
A: 開発PMということであればエンジニアの方が向いていると思います。
タスクの詳細化/見積/品質/コミュニケーションなどエンジニアの方が優位だとは思います。その他のPMでしたらエンジニアにこだわる必要はないです。
PMアサイン
Q: PMに向いている人？
A: 飲み会幹事得意な人。
ステークホルダーのスコープ (あれが食べたい、や好き嫌い）をコントロールしつつ、Q:飲み会の質/C:予算/D:スケジュールを調整し、場の一体感を作れる人。
そして、飲み会幹事もPMも大変だけど、そこに喜びを見いだせる人。
プロジェクトメンバーを集める
Q: プロジェクトのメンバーをどう集めますか？
A: リファラルor採用でしょうか。
知り合いに声をかける、または外から採用します（エージェント、媒体など）。または上司にかけあって人を動かしてもらいます。
プロジェクトメンバーと関係構築
Q: プロジェクトメンバーと関係を築いていくために、最初にやったことがいいことはなんでしょうか？
A: プロジェクトキックオフ。メンバーの顔と名前を覚える。誰か味方を見つけます。
プロジェクトキックオフをまずはしたほうがよいでしょう（プロジェクトの目的・スコープ、体制、コミュニケーションプラン、etc）。メンバーの顔と名前を覚えます。そのうち誰かひとり味方を見つけて、フォロワーになってくれるとぐっとやりやすくなると思います。そして最初の3か月くらいはこれまでの前例を否定しないで踏襲しつつ、3か月〜少しずつ自分色に変えていきます。
メンバーのモチベーション
Q: メンバーのモチベーションが上がらない場合は、どうすればよいでしょうか？
A: 1on1でヒヤリングしてすり合わせていきます。
1on1でやりたいこと、なりたいことを聞いて、会社の方針↔開発の方向性↔個人の希望をすり合わせていきます。すべて実現できないかもしれないが努力をします。
メンバーのスキル格差
Q: メンバーのスキル格差をどう埋めるか？
A: メンターをつけなす。
メンターをつける、または、スキル高い人同士で切磋琢磨させる、というのもよくやります。
プレイングマネージャー
Q: プレイングマネージャーで気をつけること？
A: タスクを抱え込みすぎないことです。
自身がボトルネックにならないように、振れるタスクは振ってしまいます。丸投げではなくハンズオンや定期Watchして、期待値を下回るならフォローする必要があります。マイクロマネジメントにならない程度で。
リーダーへの権限委譲
Q: リーダーにどこまで任せる？
A: 人事・コスト以外など責任の取れる範囲でしょうか。
基本任せます。リーダー自身で判断し、できるかぎり実行してもらいます。
その他質問編
PM資格
Q: 資格はIPAとPMPどちらがオススメ？
A: PMPの方が認知度あると思いますが、3年毎の更新が大変です。IPAはワンタイムでよいので。
あと、PMBOKはやはりオススメです。最初は抽象度高く何を言っているかわからなかったのが、プロジェクト終えて読み返すと学びがあります。updateせねば。。
PM経験振り返り
Q: 過去の自分にアドバイス？
A: プロジェクトは一度やりきってみましょう。
プロジェクトはよいときもあれば炎上するときもありますが、一度やりきることで自信になるので、トライしましょう。
オフショア開発
Q: テレワークでのオフショアのマネジメント？
A: 設計書の充実、実際のものを見せて齟齬がないようにします。
オーラルのコミュニケーションだけだと齟齬が発生するので、設計書の充実や実際の画面なりモックなど提供し、齟齬がないようにします。
勉強会参考資料
一緒に登壇しためけさんのまとめ記事はこちらです。
私の発表したスライドです。
最後に悩めるPMへ
勉強会へたくさん参加いただき質問をたくさんいただいて、PMのみなさんはこれほど悩んでいるんだな、という感想を持ちました。中には炎上するプロジェクトのPMをアサインされて苦しい思いをしている方もいらっしゃると思います。
私も外資のメーカー時代に難しい顧客のプロジェクトへアサインされ、会社では上司から激詰めされて厳しい状況に追い込まれたことがありました。
相当追い込まれていてメンタルやられる寸前でしたが、「アホらし。いざとなったら会社やめよう。」と開き直ってからは炎上していたプロジェクトが徐々に落ち着いていきました。
自身の健康やメンタルより大事なプロジェクトなどありません。
炎上しているプロジェクトで一時的に追い込まれることはあると思いますが、その状態が数か月続くようでしたらとっとと逃げ出すのが得策です。ただ、人間追い込まれすぎると逃げ出す、という選択肢を思いつかなくなりますのでそこだけ注意です（参考までに書籍のリンクを貼っておきます）。
まとめ
今回は#開発PM勉強会でいただいた質問への回答をtweetしたものをまとめました。なかなか時間中にすべて回答するのは難しいのでtweetで回答して、それをまとめてみました。
今後もいくつか勉強会でLT予定ですので、いただいた質問に答えられる範囲で答えていこうと思います。
Discussion