童話でわかるプロジェクトマネジメントを読んでみて

現場でのプロジェクトってどうしたらうまく回るのか？自分自身が体系的にPMについて学んだことがありませんでした。

今実際にマネジメントをしていなくても、今マネジメントをする人でも、一旦は目を通して読んでみたら良いんじゃないかなと思うような本でした。

童話としてプロジェクトの進め方が学べるので非常に読みやすかったです!

なので特に良かったなあと思えた部分に関してまとめてみます!

大切だと感じたこと

特にプロジェクトの初めはこの動きができるようになる必要があると思っています。けどなかなかできない!

はじめにイメージを聞いてそれに対して実装進めていくのは危険信号。
常に認識の齟齬はないのかをはじめは丁寧にすり合わせながら進めていく必要があると思うんですよね。

自分が関わるプロジェクトでも、気がついたら開発側が一人歩きしちゃってイメージがbizとdevでズレちゃうなんてありました。

でもbizだけのイメージをそのまま反映させるのは悪手なのでは?
おそらく開発ならではの視点とかがあると思うので、その場合はこのように考えたらどうか?など意見を出してお互いに納得いく形に整えていく必要があると思っています。

どうしてもステークホルダーが最終の決定権を持っていると思うので、最初に認識を合わせながら進めないとマズイですよね…

プロジェクトの方向性をはっきり決めるために、自分がなんのためにそのアクションを取るのかというのは常に考えるべきですね。

そもそものゴール、方向性が違った場合にはその行動の意味は全くなくなります。

これはPMとか関係なく、働く上で大切だと思いますよ
この行動をとった根拠は何なのかというのは常に言語化できるのが良いかと!

プロジェクトでは、トラブルや想定外のことなんて日常茶飯事ですよね?

だとしたら、それを極力予測して発生させないように対策を練ったり、事前に潰しておく必要がありますね。

自分自身ここのリスクを洗い出すということに関してはめっちゃ難しいと思っていて、今のことを考えるんじゃなくて、自分が頭の中で開発していって今何が足りていなさそうかなどを考える必要がありそうかなって思っています。

でもこれがめっちゃむずいですよね

なんとなくは理解していたけど、体系的にどんな理由で何を作成するのかとかが正直わかっていなかったです。

どんな作業が必要そう?まで要件を聞き出せたら次にWBS(work breaking structure)を作成する。

作成したら、これは一つ一つの作業を全て洗い出して、漏れがないか確認するためにやることなので、全て満たされているかを確認する必要がある。

他にも漏れがないかどうかを確認する必要があるんです

というようなことを自身で感じましたー

もうちょっと色々あるが、大きく気になったのは↑でした。