プロジェクトマネジメントを始めたい

資料

プロジェクトマネジメント実践講座を読んだ

内容は大変丁寧な感じでモチベーションと具体的な例を上げつつPMの重要性、あと必要な各種書類や仕事の詳しい日本語による解説という感じ。 それなりにページ数あるけど圧縮したら15ページ+図表くらいで収まる気がする(チートシートほしい) モチベーションを十分理解している人は安心して読み飛ばしていいと思う。

個人的な感想

  • PMでは「納期を守る」という感覚が一番大事っぽい

  • やたらExcelを推してくるのは逆に言えばまともなツールが他にないのだろうなぁ

  • リスク管理についても書いてあってなるほどと思った(リスクを先に想定しておくのは難しいけど大事っぽい)

  • モチベーションの説明がわかりやすい

  • プロジェクトの発足と仕事を作って人に割り振る時のマネージャーの動き方について主に書いてる感じ

読んでる時はもっと色々思ったはずだけど読んでから時間経ちすぎて忘れた

個人的に気になった方法論

「PMの話」っていうと結構マネージャーの動き方とか仕事の仕方的なものを指すこともあるんだけど(サイクルはこまめに回しましょうねとかそういう) 自分が欲しいのは方法論なのでそっちについてちょっとまとめておく

WBS & ガントチャート

各node Xに対しXを作るのに必要なもの/作業を子nodeに置いた高さ4のfin. branching treeをWBSと呼ぶ(めちゃくちゃかっこいいなこの説明って思ったけど誰にも伝わらないと思う)。 WBSに実際のスケジューリングを与えるものをガントチャートという。

これらを作るのは自然なことなのだけど、問題は実際の作業の間には依存関係があることで、これを上手く管理するのは結構難しい。

基本は依存関係に沿ってトポロジカルソートして作業を進めればよいがそういうことが簡単にできるツールって意外と少ないよな 本ではExcelって言ってたが果たして

重要度-時間分割

これはスクエニの資料の方にあった話で、各作業に 重要度: 高/中/低 および かかる時間: 大/中/小 をそれぞれ割り振って3x3のボードに配置する。 手を付けるべき作業によい感じに優先順位を割り振るときに便利そう。

スケジューリング

各作業に対して締め切りを(最速見積もりと最遅見積もりの2点見積もりがいいらしい)割り振る。 その上で、要素成果物Yに対して作業X1..Xnが必要な場合、Yにかかる見積もり時間はX1..Xnの依存グラフのpathの中でもっとも合計時間が長くなるpath(クリティカルパスという)の合計になる。

当たり前ではあるけど、クリティカルパスを常に意識することは重要で、そこが一番足をひっぱるので納期に一番影響しやすい。

それと作業や成果物を諦めるという選択を行う場合、それに依存している全ての作業を切り捨てられるので全体にかかる時間もかなり変わってくるはず。 個人でやるなら人間の数は変えられないので成果物を捨てる判断が割と必要になる気がする(最初のプロジェクトが夢見がちなだけ説)

個人趣味プロジェクト運用論

PMを学びたいと思ったのは自分一人でプロジェクトを回す時にマネジメント能力足りなくておじゃんになるのが多いからだったのだけど、 まぁ世の中のPM論はほぼチームかつ仕事でやること前提なのでそのままでは使えないってことも結構ある。

ので自分が趣味プロジェクトでPM真面目にやるならこうしたい的な話

締め切りは時刻でなく時間

本でもたいていのtodo管理ソフト的なのでも大体何時何分が締め切りってなってることが多いんだけどこれはリアル生活に影響を与えすぎるので 時間で(何時間、みたいな)見積もりを立てるべきだと思う。

その上で日何時間、週何時間作業して概ね納期はいつ、というのを考えるべき。これは多分PMではなくライフマネジメント的なところ。

WBS & ガントチャート

WBSなんて分かればいいので構造化文書なら何でも(markdownかorgあたり)いいってなるが、その後ガントチャートに起こすことを考えるとちょっと考えたほうがいい。 ガントチャートでは締め切り(2点見積もり)を設定した上でそれを時期順に並べ、依存関係が簡単に分かるように図示するという作業が必要になるので結構難しい。

依存関係は単に枝分かれならともかく合流(作業XとYが終わって初めてZに取り掛かれる、みたいなやつ)があるので構造化文書でこれを図示するのは厳しい。 個人的にはテキストで依存関係を明示して(各作業の親作業を登録しておいて)dotとかでグラフ化したものを印刷して机に貼っとくとかするのが最強なのでは説がある。

作業の流れを把握するにはグラフ化されたものが欲しいけど、完了報告&修正とか入れるならテキストでどうにかしたいという欲もあり色々大変。

あと上では構造化文書っていったけどredmineみたいなやつでもいい気がする。あれってどうなんだろ、個人で使うにはめんどくさくならないかな。

スケジューリング

自分はよく作業をボトムアップで見積もるけど、その前に「プロジェクトそのものに飽きる」という悲しい問題があり、それを考えると納期は個人趣味プロジェクトでも確かに存在する。 そういう視点が今までなかったのでよくプロジェクトがエターナってたけど、プロジェクトに飽きる前に最低限の完成形までもっていくというのが実は一番大事なのでは説がある。

ということを考えると、プロジェクトに飽きるまでのおよその時間を納期としてスケジューリングを組み、成果物の中で最もプロジェクトに貢献するところを最短で完成するルートをどうにか手に入れるということをしていくとよさそう。

企画論

自分は飽きやすい上に、しかし進捗があるとやる気が出る、完成形が見えてくると失速するなどの大変厄介なモチベーションを味方に付けて戦う必要があるので、どうしてもプロジェクトを動かし始めてから納期の変更や成果物の修正、必要があればいくつかの作業を切り捨てたりみたいなことが起きると思うのだけど、まぁそれは致し方がないと思う。 実際に仕事でこれだともっとちゃんと現実的な企画にしろって怒られるところだと思うのだけど、PMについて調べたり色々考えてもやっぱりこの状態(モチベーションが変動しやすいせいでプロジェクトが順調に進まぬ問題)は特殊な環境だと思うのでその分PMが難しいけど大事になってきそう。

こういうのをどうにかするのが企画の方法論かもしれない？ いやそう思って色々調べたんだけどあんまり有用な情報はなかった。

感想というかなんというか

企画論にせよPM論にせよ、基本的に方法論はあんまり確立されてないっぽいということが本を読んだり色々調べたりしてよりはっきりしてきた。 もちろん書類の名前とか作り方とかそういうのはしっかりあるのだけど、常識的な予算と常識的な納期の下で、チームメンバーのやる気がゼロでも絶対遂行できる魔法のマネジメントなんてものはないのだろう(そんなものがあったら今頃みんな使ってると思う)。

プロジェクトは生き物ってマジっすねみたいな感想になった。

本を読む前はもっと明確な手順に沿ってやってるのかと思っていたのだけれど意外とみんな雰囲気でやってる状態なのねという感じ。 いや仕事でやる場合は普通は過去のプロジェクトの時のやつとかそういうのが参照できるから汎用的方法論があんまり必要にならないような気もする。しょうがない。

本を読んでから結局一度もPM論が役に立ってないので、次なんかやるときは学んだことを使って何かやってみたい。 やってみて上手くいったらちゃんとまとめて後から参照できる形で残しておこうと思います。

PMのレベルを上げるためのマネジメント練習ドリル的なの欲しい。 Haskellの99problemsみたいな感じで、セッティングだけされたプロジェクトがあって自分で手を動かしながらプロジェクトを完成に導くみたいなやつ。 いや本当に欲しいかな。わからん。

久々に何が言いたいのか全くわからない記事が出来た。

最近は、PMBOKを手元に置いておきたいんだけど、自分が欲しいことが載ってるのかわからないしノリで買うには高いので迷っている毎日です。