ランニングしながらAudibleで聴いた本の感想です。
本のまとめというより、自分が心に残ったことを3つだけ書いてます。
とりあえず思ったことをメモするのが大切と思い、なるべく30分以内で書き上げています。
読んだ本
プロジェクトマネジメントの基本が全部わかる本
橋本 将功 (著)
プロジェクトマネジメントの本です。といっても、PMBOK的な内容というより、プロジェクト「あるある失敗」を踏まない方法が紹介されています。
「これからの時代の基礎」的な内容が図解で抑えられており分かりやすかったです。
個人的には新しい内容というより知っている内容が多かったです。ただ、こういう基礎的な内容を忘れると落とし穴にハマるケースもあります。
そういう意味で、主語が大きいタイトルですが、それに見合った良い本だとは感じました。（個人的満足度２／３、一般的なおすすめ度２．５／３）
心に残ったこと
馴れ合い型組織より戦友型組織を目指す
チームには2種類あり、コミュニケーションが活発で仲も良い「馴れ合い型」と、コミュニケーションは適度で、成果に重点を置く「戦友型」があるとのことです。
前者は、日本では昔からある「メンバーシップ型」、後者は「ジョブ型」ともニュアンスが近いです。
仕事上のチームは、もちろん戦友型（ジョブ型）を目指すべき、とのことでした。
さらに、タスクをアサインするときは、そのメンバーが「ジョブ型の志向を持っているか？」を見極めるべき、とのことでした。
ちょっと残酷ですが、メンバーシップ型の人に、個人に紐づいた重要な仕事をアサインするのは注意が必要、ということです。
この「タスクをアサインする前にメンバーの志向を考える」という点は、個人的に新しい概念でした。
アジャイル（スクラム）開発はメリットばかり強調されるが、本当は難易度が高い
変化の激しい・答えのない時代に、ウォーターフォールとの対比で、アジャイル（スクラム）開発のメリットが強調されます。
スクラム開発では、小さい開発サイクルを回して、製品の完成度を高めていくという手法で、変化に柔軟・答えがなくても回せる、というように見えます。
しかし、「スクラム開発ではメンバー1人1人に高い能力が要求されるので、本当は難しい」とのことでした。
マネージャー含め、メンバー全員が優秀なチームで何かを開発するのであれば、スクラム開発は問題ありませんが、ほとんどの場合そうでないと思います。
対処法として、スクラム開発に似せて「試作品を作る」というステップを間に挟んだウォーターフォール開発も検討すべきとのことでした。
要件定義が一番山場
「プロジェクトにおいて後から要求が増えるのは、ラーメンを頼んでおいて、後から餃子を追加するようなものである」という例えがありました。
また、「プロジェクトの失敗は後から取り戻すのが難しい」ということも強調されています。
実際のプロジェクトでも、開発途中での要望変更や、要件が曖昧に書かれていたせいで予期せぬ対応が必要になり納期遅延となるケースが多いと思います。
そのため、「要件定義が一番山場で、ここがPJの成否を決める」とのことでした。
また、要件定義は、要求（〜したい）と要件（〜する）を明確に分けるべき、とのことでした。
さらに、「顧客が望むものが、欲しいものとは限らない」とのことでした。（これは有名な絵がありますが・・・）
デザイン思考の考えを用い、まずは共感したうえで解決策を考える、というのが重要なのかなと個人的に思いました。