【読書memo】プロジェクトマネジメントの基本が全部わかる本
通読したので、個人的に重要と思った点及び現在の自身の状況を踏まえつつコメントを残す
1章:
- プロジェクトはスタートとゴールが決まってる
- プロジェクトは不確定要素が多い
- 全体感の共有が足りないとうまくいかない
- 関係性構築がうまくできていない。
- 全体を俯瞰して「優先対処が必要な課題はなにか？」に取り組む人が所謂マネージャという人。
- PMが人と金、PdMが人とモノを管理するイメージ。
2章: 交渉
- コミュニケーションに抵抗はないが、交渉技術はまた別の話だと思うから注意したい。
- 交渉って結構精神面でハードな場合が多い。
- QCDバランスを取りながら調整しないといけなくてまぁ難しいよね
- 自分がマネジメントするエンジニアもそうだけど、顧客とのヒアリングは定期的に行っていくの大事
- 同期・非同期/言語・非言語コミュニケーション手段は適切に。心配ないと思うけど。
- 議事録で証拠を残す
- 仲の良さと信頼関係は別物。人がやめていく場合は信頼関係が構築できてない〜と書かれていたが、人がやめるのは今の時代色々複合的なのでなんとも。。。
3章: タスクマネジメント
- ジョブ型とメンバーシップ型。今の時代は前者がプロジェクトにとってふさわしい。アジャイルとかまさにこういうのでまわしていかないとだよね。
- モチベの低いメンバーがいる場合はすぐに上に報告らしい。わからんでもない。
- 「やってみないとわからない」と判断するエンジニア、これ経験値が低いかやる気がないです。はい。
- 基本的にタスクは「期間」じゃなくて「工数」で考えると良い。
- タスクの依頼の仕方は、背景や理由を説明する。信頼関係構築にも忠誠にもつながる
- 毎日進捗確認するのいいね。で、報告する側も正しく報告するの大事ね。
- 特定個人にタスクをふると遅い場合があるが、これは個人の問題ではなくやり口の問題。こちらでなんとか誘導してあげるべき。
FYI: ガントチャート
- タスクの抜けが発生しやすい
- 締切直前にやり切るみたいなやり口でやられる可能性が高い。結構やりがち。
4章: プロジェクト計画
- 必須条件を決めていくような形。
5章: 見積もり
- いつ見積もりを実施するかで精度が当然変わる。
- 概算見積と詳細見積もりの使い分け。
- 概算ってあるけど、ちゃんと根拠もってやれよ？(悪癖)
- 炎上理由として見積もりがおおざっぱすぎたとかいうのはよくある話。
6章: 契約
7章: 要件定義
- QCDに影響を及ぼすかどうかは、ここで5割決まるとか
- 要求と要件って言葉は覚えておきたい。混在して理解しているから使い分けるべき。
- ビジネス要件がめちゃくちゃ軽視されがちだけど、PMのスコープではあるからマジ大事。
- 市場調査、競合調査
- ビジネスモデル
- KPIツリー
- KPIの可視化だね。
- ペルソナ設計
- プロダクト利用者を想定しながら進める手法
- ユーザーヒアリング
- ペルソナに該当するユーザに予めヒアリング。予めどんなペイン、ニーズがあるか確認する方法。インタービューだね。
- カスタマージャーニーマップ
- ユーザーストーリーマップ
業務フローとかはtoBなシステムだとマストで考えるよね。
図示して進める合意を得るのは正しい。だけどパワポ使うんじゃねぇとのこと。Cacooやdraw.ioを使うほうが好ましい。
- ToBeとAsIsみたいな考え方は知らなかった。覚えておこう。
8章: デザイン
- 割愛
9章: 設計
- あるべき姿や構造・構成を決めていく作業
- この章の設計書のページは丸暗記しておいてもいいかもね。結構難しいし、自分で書いた設計書は情報が最小限で構成されてる。引き出しの少なさが原因なので知っていてほしい。
10章: テスト
- 7原則があるよってことを知っておこう。これを頭に叩き込めてたらOK
11章: リリース
- リリース計画を毎回立てていることはわかっているのでOK。意図や背景までわかるといいね。
12章: 保守・改善
- 損益分岐点がこんなところでもでてくる
- 投資した費用を売上が超えてくる点がそれ。黒字ってやつ。
- ファネルモデルは知っておこう
感想
- 課長からカツアゲした本なんだけど、結構いい本。読みやすかった。
- 明らかに情報が
