どうも、あーみーです。
今回は様々なプロジェクトを通じて「よかったPM、悪かったPM」そして私自身の経験に基づいてしくじりプロジェクトマネージャーを書いていきたいと思います。
※これは過去のPMへのディスリではありません、こういった行動が何故良くないか自戒も含めて記録していこうと思います。
それではいってみよう！！
作業ボリュームを把握する前にスケジュールを引く
いきなりこんなの出る？？？って感じるかもしれませんが 意外といます。
例えば設計書のスケジュールであれば
- 粒度はどのくらいにするか(どこまで書くか）
- フォーマットを決める
- 作業量が分かる
- 機能に合わせてスケジュールを引く
このような形になるかスケジュール優先であれば
- スケジュールを引く
- その中で可能な設計書を顧客と協議する
- フォーマットを決める
- 作業量を割り出して問題あれば再度調整
上記の形になると思います。
この流れを組んでないと過多なドキュメント、コストに見合わない品質管理、可読性や保守性を意識しないソースコード、炎上して稼働MAX！などが完成していきます。
タスクによってコストが掛かるウェイトを理解していない
基本的にタスクの難易度とそれを担当するメンバーのスキル感は理解していると思いますが、それの因果関係を把握していないPMが多すぎます。
| エンジニアスキル/難易度 | High | Low |
|---|---|---|
| High | コスト高/納期も長め | コスト安/納期最短 |
| Low | 出来ない | コスト中/納期そこそこ |
エンジニアスキルと難易度の因果関係は上記の通りです。
この因果関係を分からない為、エンジニアスキルが高/タスクの難易度が高のものについての見積もりが甘い結果になります。
あとはエンジニアスキルが低いメンバーに高難易度のタスクを割り当てしても「出来ない」が正解となります。
そのためこの辺りの因果関係とメンバーのスキルに合わせて、タスクの割り当てを実施していかなければ想定より大幅にズレる事になります。
すべてリーダー任せ
PMが自分自身が統括しているアプリケーションの概要しか分かってない人が多いです…。
例えば〇〇アプリのモジュール××はAPIの連携が必要で、その為の仕様が来ていない等の課題があればそこは話を詰めなければいけない部分です。
（API仕様が公開されているようなモノなら優先度は少し下がりますが、そうでない場合は優先度がグンとあがります。）
優秀なPMは逆に進捗だったり交渉の部分でPMにPLが聴くケースが多いですが、しくじりPMはその逆です。
何でもPLに質問している人や丸投げ状態で依頼している人は要注意です。。
進捗管理ばかりで品質を追わない
プロジェクトの進め方によりますが、ウォーターフォールの開発だと進捗の中間報告でお客様に理不尽な激詰め 問い合わせされるケースが多々あります。
その関係で進捗管理についてシビアなPMは割と多いですが、肝心の品質について説明できる人がいません。。
この辺りはコードについての理解がないのか、システムの全容が把握できてないのかは分かりかねますが、品質が一定のフェーズで担保出来てないと問題を後回しにしてるだけとなります。
この不具合は影響度が少ないのでテストフェーズで直します（なので許してちょ）
この不具合はマズいので次の定例までに修正入れます
みたいな会話もアジャイルではあるあるですが、ウォーターフォールも聞かれてないだけで把握はしておく必要があると思います。
なのでお客様との調整もそうですが、メンバーとの調整も必須となっていきます。
顧客が最も大切にしたいモノを理由込みで言えない
あなたのお客様が一番欲しいものはなんですか？
と言われて分からない人が多いと思います。
大まかに分けると
品質・機能・納期・予算
この4つに分類すると思ってますし、すべてが大事なお客様が多いのも事実です。
ただ、実際にプロジェクトがうまくいかなくなった際にどれを一番に優先したいですか？というのを予め把握しておかないと何かあった際の提案として「頑張ります」しか言えなくなってしまいます。
- 多少のテスト品質（セキュリティ等の重要度高いものを除いて）は落としても仕方ない。
- コストカットの為にこの機能はスモール化するか、機能自体を削るか
- 納期重視ならば運用を想定して、都度リリースに運んでいくのか
これらの選択肢があると無いとでは大分異なりますよね？
そのためにプロジェクトの発足時に把握しておくことが必要になります。
プロジェクトの成功が何かを明示できない
これは請負や自社開発で特に重要になりますが、プロジェクトの成功って何でしょうか？
- 顧客の関係を継続する為に赤字を出してでも完成させる
- 利益を確保するためにアプリを納品する。
- メンバーの教育（未来への投資）に向けて、経験値を積ませる
- 社内のブランディングを高めるため、赤字でも完成させてビジネス上のイニシアティブを確保する
アプリを作ることが必ずしも、ゴールになってはいけません。
アプリを作るのは大前提で、その上に何をしたいのかが決まってない・明示していないPMが非常に多いです。
この辺を伝えていないと社員や協力会社さんのモチベーションがかなり変化し、方向性にズレが生じます。
以上でしくじりPM、俺みたいになるな！を終えたいと思います。
私もPG、PL、PMとして様々な経験をしてきましたが、「うわーーーあーみーはしくじりPMだぁぁぁぁぁ！！！」って思われない様に日々高めていけたらと思ってます！
P.S. コードが書けないPMはヤヴァイ