翔泳社から出版されている「プロジェクトマネジメントの基本が全部わかる本」を読みました。
プロジェクトマネジメントって、やるべきことが多岐にわたるし、プロジェクトによって対応を変えないところもあったりして、型を作るのが難しいですよね。
自分も前々職ではプロジェクトマネジメントというか、プロジェクトマネジメントに近いことというか、多くの人と共同でシステム開発に取り組む業務をしていました。
（自信を持ってプロジェクトマネジメントと言えないところに、すでにプロジェクトマネジメントの曖昧さが現れてますね…）
チームで開発を進めるうえで「プロジェクトマネジメントを理解しておくことで、スムーズに開発を進められるのでは？」と考え「プロジェクトマネジメントの基本が全部わかる本」からプロジェクトマネジメントを学んでみることにしました。
- プロジェクトマネジメントってどうやって進めればいいかわからない…
- なんとなく進め方は理解しているけど、言語化できるほど腹落ちできていない
- 一通りプロジェクトを進めることはできるけど、部分的に見れば不安なところがある
上記のような思いを抱えている方はぜひ一読してみるのが良いです。
プロジェクトマネジメントについて体系的に解説されているので、きっと何か学びになるものが得られるでしょう。
プロジェクトマネジメントに対する型を身に付けた
前々職でプロジェクトマネジメントをするにあたって、研修や教育のようなものはありませんでした。
上司や先輩の背中を見て育て！というような感じで、基本的な仕様書の書き方こそ教われど、発注してからの動きは見様見真似で何が正しいか手探りだったというのが思い出です。
プロジェクトマネジメントはプロジェクトによって異なるからそういうもの。
勝手にそういう認識でいましたが、結果人によって進め方や認識が異なり、プロジェクトの成否は属人的になっていました。
この「プロジェクトマネジメントの基本が全部わかる本」では、著者がプロジェクトマネジメントの現場を渡り歩く中で、さまざまなプロジェクト、プロジェクトマネージャーに出会い、プロジェクトマネジメントの教育不足を実感したとありました。
そのような経験から「プロジェクトマネジメントの基本が全部わかる本」がプロジェクトマネジメントを体系立てて学ぶ書籍として生まれたそうです。
そういった背景があったからか、これまで上司や先輩の背中を見て学んださまざまなことが「プロジェクトマネジメントの基本が全部わかる本」では言語化されていました。
「そうそう、そういう動きが必要だったな―」と感じることや「あれはそういうことだったのか…」と腹落ちすることが多く、改めてプロジェクトマネジメントの「型」を身に付けられました。
「あった方がいいと思う」を「必要だ」と言い切れるようになった
業務を進める中で「今回のプロジェクトはこれがあったからうまく進んだよな」「これがなかったら大変なことになっていたな…」と感じるものがいくつかありました。
自分の記憶には残っているものの、いざプロジェクトマネジメントを進めるとなったら抜け落ちそう、忘れそうな部分もしっかり記載されていました。
プロジェクトマネジメンを行う上で「プロジェクトマネジメントの基本が全部わかる本」を見返しながら進めることで、安心してプロジェクトを進められそうです。
- 要件定義ではbefore/after（AsIs/ToBe）を作成する
- リリース計画書を作成する
といったことが「プロジェクトマネジメントの基本が全部わかる本」には書かれていましたが、現在の実務ではあまり行われているのを見たことがなく、自分は行ったほうがいいよな…と感じていることでした。
いずれも作ろうとすると、それなりに時間がかかるものたちです。
これまではなんとなくあった方が自分が安心するからという理由で作ろうと考えていたのですが、「プロジェクトマネジメントの基本が全部わかる本」にも書かれていたという根拠があることで、時間がかかったとしても自信を持って作成すべきと言えるようになりました。
「プロジェクトマネジメントの基本が全部わかる本」から「あった方がいいと思う」と感じていたものを「必要だ」と言い切れる後ろ盾を得ました。
プロジェクト終了後を意識できるようになった
我々エンジニアは事業部側の担当者の要望を確認し、要件に落とし込み実装・リリースすることが多いと思います。
プロジェクトはリリースしたら終わり。
それ以降はたまに事業の報告を聞いて、なんとなくリリースしたものが事業にどのような影響を与えたかを把握するにとどまっていました。
「プロジェクトマネジメントの基本が全部わかる本」ではプロジェクトを事業にどう結びつけるかというところまで解説されていました。
リリース後の固定費・変動費から損益分岐点がどうなるかを把握すること、ファネルモデルを作って事業として成長させていくこと、そういったプロジェクトに対する事業部側の目線を得られたことも大きな収穫でした。
エンジニアでも固定費に関与する部分はあるので、事業を一層成功に導きやすくするために、リリースして終わりではなく、リリース後も継続的に改善できる部分を探していけるようになりたいです。
やるべきことをきちんとやる
「プロジェクトマネジメントの基本が全部わかる本」を読むことで、これまで「なんとなく」がたくさんあったプロジェクトマネジメントの進め方に対して、一定の根拠を持つことができました。
特に3つの事柄について、今後プロジェクトに携わる際には必ず取り組むようにしたいと考えています。
1. 要件定義においては AsIs / ToBe を明確にする
要件定義において ToBe を整理することはしっかり行われています。
しかし、AsIs の確認をおろそかにした結果、想定外の影響を及ぼしてしまうということをたびたび目にしてきました。
AsIs の整理も行うことで、安定したプロジェクト進行を目指したいです。
2. 設計のドキュメントを作成する
アジャイルソフトウェア宣言では以下の一文があります。
包括的なドキュメントよりも動くソフトウェアを、
よく勘違いされている気がするのですが「ドキュメントよりも動くソフトウェアを」ではないんですよね。
現在の業務でも設計に関しては資料を作ったり作らなかったり。
「包括的なドキュメントよりも動くソフトウェアを」なので、一定量のドキュメント作成はアジャイルでも必要とされているはずであり、「プロジェクトマネジメントの基本が全部わかる本」においても設計書の必要性は書かれていました。
自分に都合よく捉え、楽な方に流されるのではなく、将来的に必要となるものはしっかり整えてプロジェクトに取り組んでいきたいです。
3. リリース計画を作成する
リリース計画は前々職では必須だったものの、ふりかえると転職してからは作らないこともあったと思われます。
計画していないと、やるべきことをやり忘れたり、トラブルが発生したときにパニックになることを実感しています。
リリース計画はしっかりと作り、できればリリース計画に沿ったリハサールも行っていきたいです。
「プロジェクトマネジメントの基本が全部わかる本」にもリハーサルによってタイムテーブルに無理がないか、ヌケモレがないかを把握しやすいとあり、自分としても身に覚えがありました。
手間はかかるものの、やることによる安心感は大きなものです。
事業を意識する
これまでは漠然と事業に対してどのような影響があるかを眺めていることが多かった気がします。
「漠然と」見ていた理由は、自分たちの開発が費用対効果のどこに影響を及ぼすかが明確になっていなかったため。
今後はリリースが売上や費用のどこに効くのか、リリースした結果どうなったのかをウォッチしていければと思います。
そうすると、事業への貢献を感じやすくなり、業務に対するモチベーションを高められそうと考えています。
何事もモチベーション高いほうが成長につながりやすいですからね！
この記事では「プロジェクトマネジメントの基本が全部わかる本」を読んで得た、プロジェクトマネジメントの進め方、抑えどころを紹介しました。
これまで「なんとなく」で進めてきたプロジェクトマネジメントに対して一定の根拠を得ることができました。
根拠を得ることで「やった方がいい」と思っていたことも「必要だ」に昇格できたものもありました。
事業に対する視点も得られ、プロジェクトマネジメントを進めるためのノウハウ以外にも得るものがあり良かったです。
序盤、座組が全てみたいに書かれている部分があり「座組はコントロールできないんだよな…」と読むモチベーションが低下した部分もありましたが、最終的には読み切って良かったと感じています。
「プロジェクトマネジメントの基本が全部わかる本」について、まだまだ紹介できていない部分も多いです。
プロジェクトマネジメントに対して不安を持っている方や、体系的にプロジェクトマネジメントを学んでみたい方はぜひ一度読んでみてください。
