プロジェクト・マネジメントってなんだっけ？【中村の技術図書室】
開発は基本的にプロジェクトの中で回ってるけど、 そもそもプロジェクト・マネジメントってなんだっけ？だったり、 PMってどんなことしているか？ってのは、 コードを書いている中ではあんまり意識していない世界だなぁと。
そんな時、PM経験者の人に「体系的にプロジェクト・マネジメント学ぶならどんな本が良いですか？」 って聞いた時に出てきたのがこの一冊。
- 作者:G・マイケル・キャンベル
- 発売日: 2015/03/21
- メディア: 単行本（ソフトカバー）
まだまだ読みすすめている段階なので、 第一章あたりの気になった点などをまとめられればと思ってます。
そもそも、「プロジェクト」って何？ってのが書いていて、あぁ、確かにってなった。
プロジェクトは通常、社内外のニーズに対処するためにスタートします。(p.28)
例えば、接客をよりスムーズにするためのシステムだったりとか、ナレッジをまとめて出したいとか。 これもっと、良くしたいって思った時に、プロジェクトってできているなぁと。
あと、プロジェクトのゴールってなんだろう？と思うことも最近多く、それもばしっと書いてありました。
プリジェクト・マネージャーがそもそものビジネス・ニーズを理解していなければ、 プロジェクトは成功するでしょうが、理解していなければ、成功はしません。 プロジェクト成否の判断は、長期的には、プロジェクトそのものの目標の達成度合いだけでなく、 ビジネス全体の目標達成や、プロジェクトが目指すビジネス価値の実現の可否によって成されるのです。（p.37）
実際、ビジネス・ニーズを意識しないで、仕様通りに開発する時もあるけど、 知っておいかないと、プロジェクトの成功、ビジネスの成功には近づけないなぁとしみじみ思う。
「よし、スタートとゴールはわかった。それを決めればええんやな！」ってなったけど、 明日PMになったら？とか想像すると、多分できないだろうから、PMについても見ていく。
PMってのは、マネジメントとリーダーの2つの役を演じる必要があるようで、 マネジメントは多分、何かを管理するんだろうなぁってのは分かるけど、リーダーってのはまじでわからない。
「リーダーシップを発揮してください」なんて言われても、 めっちゃ牽引すればええんですか？とか モチベーションを上げるような何かをする？とか。 わからん！！ってなることが多いなぁと考えてた。
この本だと、リーダーとしては、3つの役割があるとのこと。
- 対人関係の役割
- 情報提供の役割
- 意思決定の役割
対人関係は、
リーダーとして認められるには、正直で、有能で、信頼が置け、 とっつきやすい人と思ってもらわなければなりません。（p.46）
ってなっていて、ハードルたけぇってなった。 イメージ、おもろい人で、めっちゃ仕事できる人ってことかな。 尊敬できる先輩って、たしかにそんな人が多かった気がする。
情報提供は、
関係者に最新情報を提供する必要があります。（p.46）
で、たしかに！ってなった。 まじで情報が提供されない時の不安感は尋常じゃない。
意思決定は、
プロジェクトを前進させるため、プロジェクトの書くプロセスで、大小様々な意思決定をします。（p.46）
ってなっていて、これは、そうだよなぁと。 誰も意思決定しなかったら、飽和状態で何も進まないことなんて多々あるし。 意思決定する時の歪みも、対人関係に関わる部分で、なんとか緩和しないとチームがガタつくこともありますよね・・・。
より具体的な資質として書いてあったのは、PMの7つの資質で、 単にコードを書いているだけだと、絶対身につかない資質ばかりなので意識して身につけていく必要があるなぁと。
- PMの7つの資質（p.47 - 50）
- プロジェクトへの情熱
- 変更管理の能力
- 曖昧さへの耐性
- チーム育成と交渉力
- 顧客第一の志向
- ビジネスの優先課題の堅持
- 業界と技術の知識
あと、気にしないといけないなぁと思った部分が、第4章のプロダクトマネジメントの10の知識エリアです。
- 10の知識エリア
単純に作業をするエンジニアであったとしても、テストコードを書いたり、 チーム間でのインターフェース調整などをするはずなので、知識エリアを気にしながら 自身ができそうなラインを見てみる必要がありそうですね。
いつ、誰がPMになってもおかしくないこの時代だからこそ、 何をみて、どう動くかが大切だなとあらためて思いました。
