読書感想文「プロジェクトマネジメントの基本が全部わかる本」橋本将功著
正直大半は知っていること、既に実践していることばかりでした。なのに、この本に出会えてとても良かったと思っています。そんな事を感想文として書き連ねます。
会社の勉強会の課題図書になったので読みました。
1. 読む前の期待と読後の大雑把な感想
エンジニアになって2年半。プロジェクトマネジメント的な立ち回りも増えて来たので、何かの参考になればと朧げながらに思っていただけで、あまり期待していませんでした。
でも読後の今、この本に出会えてとても良かったと思っています。僕は多分知識はなるべく体系的に得たいタイプだと思っているのですが、この本は体系的にまとまっていていい感じでした。
本書に書いてある内容の大部分は正直、既に知っていたり、実践しているものでした。でもそれらのことを明文化してくれて、自分の理解が抜けていた部分を補ってくれて、さらに全体を体系的に整理してくれたという意味で、僕にとってはとても価値のある本だと思いました。
今、ちょうど新入社員がプロジェクトの進め方で悩んでいるのですが、本書をぜひ薦めたいです。そして僕自身、もっと早く出会いたかったなと思います。
また、この基礎を会社の全員が持っていたら、強いだろうなと思いました。その意味で、会社の勉強会の課題図書になったというのは幸運なことなのかもしれません。
一つだけ、ネガティブな感想を書きます。枝葉末節な話ですが。
本書中に「日本では今でも金を払う方が偉いと思ってる人はたくさんいます」「上意下達の考え方が根強い日本」と、日本の商習慣を否定的に表現している部分があります。私はこれらには全く同意できず、それってあなたの感想ですよね？と思ってしまいました。昭和あたりに書かれた本なのかと思って見たら、初版2022年11月8日だった。
2. 特に印象に残った箇所
本書中で引っかかったこと、実践したいと思ったことを挙げていきます。引用ではありませんので念のため。
プロジェクトマネージャーは責任感が強いため何でも自分でやろうとしがち（p40）
僕の場合、責任感に加えて、経験値を積むために自分でやりたい！と思ってしまうこともあります。気をつけたいです。
80点維持できればかなり優秀なプロジェクトマネージャー（p52）
完璧主義に気をつけよう。多少のミスでクヨクヨしていると、引け目に感じすぎて交渉で不利になりますよ、という文脈でのアドバイス。僕は完璧主義のきらいがあるので、楽になる言葉。
コミュニケーションで会話の内容は7%？（p58）
アメリカの心理学者アルバート・メラビアンの研究（1971年）によれば、コミュニケーションで人が受け取る情報は、会話の内容である「言語の情報」が7%、声のトーン、口調などの「聴覚情報」が38%、ジェスチャー、表情などの「視覚情報」が55%とのこと。
ガントチャートは抜け漏れに気づきにくい（p82）
つい先日ある案件でガントチャートでスケジュール立てていて、抜け漏れがあったので共感できる。各タスクのサブタスクまできちんと明確にして、チーム内で共有すべきだった（p90も）。
もっとも、これをやっていればその僕の失敗が防げたかは正直わからないが。
QCDの優先順位を明確化する（p109）
これが今回の一番の気づきかもしれないです。Quality、Cost、Delivery、プロジェクトにはどれも大事だけど、どれが一番大切なのか、どういう優先順位なのか、明確にしてコンセンサスを得るというのが大事。そうすればプロジェクトが進んでいって困難な状況になっても、より柔軟に対応できる。
このパートを読んですぐにプロジェクトの進め方に迷える新人に「この本に書いてあったんだけど、今回のプロジェクトはQCDどれが大事だと思う？」ってやってみた。
工数見積もりのバッファを持とう（p131）
人は工数は厳しめに算出しがちなので、自分が見積もった工数にプラスして出そうというのは社内でも聞いていました。メンタリストDaiGoさんも人は作業の見積もりを少なく見積りがちなので気をつけようと言っていたと記憶しています。これから勇気を持って、工数を（適切に）多めに出す後ろ盾を得られて良かったです。
ビジネスの要件を固める（p158-）
これ整理できて良かったです。毎回全部やる必要もなく、またプロジェクトによっては追加するものも出てくると思いますが。
市場調査
競合調査
ビジネスモデル
KPIツリー
ペルソナ想定
ユーザーヒアリング
カスタマージャーニーマップ
ユーザーストーリーマッピング
ユースケース
業務フロー
グロース設計
UI /UX
システム要件（p165-）
これも整理できて良かったです。
アーキテクチャ
機能要件
画面遷移図
シーケンス図
ER図、テーブル定義書
API
データ移行
非機能要件
対応デバイス
安定性
冗長性
セキュリティ
コンプライアンス
テスト（p224-）
これも。
ユーザビリティテスト: 使いやすいかどうかチェック。利用者に近い人に触ってもらうのがいい。実施タイミングが難しい、プロトタイプ出来た段階で見た目を見てもらい、実装進んだら、画面遷移や機能を見てもらうというやり方も。
クリエイティブチェック: 情報、画像など。
単体テスト、結合テスト: 実装タスクのサブタスクもしておくといい。ただしでかいやつは切り出して単体の課題とするとよい。
リグレッションテスト：プログラムを改修したときに他に影響が及んでないかを確認する。
総合テスト（シナリオテスト、システムテスト）：画面ごと、処理、機能などの単位に分けてテストケースを記載し、一定のシナリオに沿って複数人で分担して行うのが一般的。全ての実装が完了した後に行うことが多い。
連携テスト（システム間テスト）：別システムとの連携動作確認。
負荷テスト
脆弱性テスト
受入テスト（検修）
3. 最後に
この本をベースに自分もしくは会社で、プロジェクトマネジメントのテンプレートというマニュアルというかみたいなのを作れたらなと思いつつ、忙しくて結局やらない未来も見えつつ。
いや、僕にサポートだなんて...僕にお金渡されても楽器に使ってしまうので、、、あなたのお金はあなたのために使ってくださいw