BiTT開発事業部テクニカルディレクターのなつきです。
だんだん暑くなってきたので、冷やし中華みたいなタイトルにしてみました。タイトルの通り、この記事のテーマは「プロジェクトマネジメント」です。
普段の業務でそれっぽいことをしているのに、今までちゃんと学んだことがありませんでした。この度、やっと手をつけ始めたのですが、心に刺さる教訓がたくさんあったので、それらをざっくりまとめたいと思います。
目次
プロジェクトマネジメントとPMBOK
プロジェクトマネジメントって、文字通りプロジェクトを管理することでしょ？ スケジュール管理とかスケジュール管理とかスケジュール管理とかのことでしょ？ とりあえず手当たり次第やるしかないじゃん。
そう思ってました。PMBOKの存在を知るまでは。
プロジェクトマネジメントは、それ自体が1つの分野として確立されています。そのノウハウや手法を体系立ててまとめたものが、PMBOK （Project Management Body of Knowledge）です。
1987年にアメリカの非営利団体PMIがガイドブックを発表してから徐々に浸透し、現在ではプロジェクトマネジメントの世界標準になっています。PMBOKに基づいたプロジェクトマネジメントの資格もあるみたいですよ。知りませんでした。
挫折、そして一筋の光
ということでPMBOKの本を適当に手にとってみたんですが、なんか難しい言葉が多い。カタカナ多いし、全然ピンとこない……ウワァーッ。ほんとに日本語で書いてあります？ 全然読めませんけど。残念ながらちょっとレベルが高すぎました。はい解散解散………。
と自暴自棄になっていた折、たまたまくまさんがおすすめのPMBOK入門本を紹介してくださったので、読んでみました。
（以下、こちらの書籍のことを「PMBOK入門本」と称します）
めちゃくちゃ初心者に優しい。わかりやすい。生理食塩水くらい脳に浸透してくる。知っている童話が例え話になっているため、抵抗感なくどんどん読めます。面白くて一気に読了しました。
PMBOK入門本から得た教訓
「PMBOKまとめてみた！」と言えたらかっこよかったんですが、かろうじてスタートラインに立っただけの輩ができることではありません。
というわけで今回は、普段の業務と照らし合わせながらPMBOK入門本を読んだ中で、特に響いた教訓をリストアップすることにしました。
見切り発車は失敗のもと
PMBOK入門本では、「プロジェクト」 を下記のように定義しています。
決められた期間内に、今まで誰もやったことがない、新しいプロダクトやサービスなどの成果物を作る業務
ルーティンワークとは違い、プロジェクトには不確実性の高いことばかりが待ち受けています。見切り発車したら、途中で脱線事故を起こす可能性が高いのは明らか。
「計画をたてないのは、失敗する計画を立てているのと同じ」ということわざがあるそう。耳が痛いです。
計画をしっかり立てることで、リスクを減らし、プロジェクトを進めることに注力できます。とはいえ、プロジェクトマネジメント初心者にとっては、「計画を立てること」自体、とても高いハードルです。PMBOKの理解を深めつつ、普段の業務で実践していきたいと思います。
チームメンバーに対し適切に役割を与える
役割分担がしっかり決まっていないと、誰にアサインすべきか分からない宙ぶらりんのタスクが生まれやすくなります。このタスク、誰がやるんだっけ？ 誰に聞けばいいんだっけ？ よくわかんないから、まあいいか。そうしていつしか忘れ去られているタスク、ないですか？ 正直あるあるですよね。
プロジェクトマネージャーは、チームメンバーのスキルや適性を踏まえつつ、役割分担する必要があります。単に作業を分担するのではく、それぞれの得意分野を持ち合って、効率よくプロジェクトを進めようというスタンスです。
頭ごなしに作業を割り振るのではなく、その役割を担うことでどんなメリットがあるのか、何が得られるのかをメンバーに伝えることも大切です。役割分担を行うことで、各メンバーは自分のやるべきことが明確になり、タスクに取り掛かりやすくなるという利点もあります。
チームメンバーのモチベーション管理もプロジェクトマネジメントの重要なファクターのひとつなのです。
行動を計画する際は曖昧な表現を避ける
PMBOK入門本に、行動を計画する際のNGワードというのが列挙されていました。
- 行動を計画する際のNGワード
-
- 把握する
- 確認する
- チェックする
- 調整する などなど
正直いって、私、日常的によく使ってます……。ごめんなさい……。言われてみれば、なにをもって完了なのかハッキリしない言葉ですね。これらのNGワードを使うと、作業範囲も工数も読みづらいし、誤解が発生することも。
以後、気をつけます！
「気をつける」もダメですかね、 すべてが疑わしくなってきました。
反省の際は「なぜ」だけではなく「何」を意識する
失敗の原因を探るとき、「なぜ？」を追求することは有効な手段です。
しかし、「なぜ間違えたのか？」ではなく、「何が間違えさせたのか？」という問いにすると、プロジェクトの体制の問題が見えやすくなります。原因は人ではなく、システムの方にあるという考え方です。たしかにその方が、次に生かしやすいですよね。
私が現在携わっているプロジェクトでは、反省会を月に一度行っています。よかったことや問題点を話し合い、問題点に対しては解決案を出し合います。この反省会の大原則として掲げているのが、「決して人を責めないこと」です。何か問題点を挙げる際は、システムの問題として提起しようということです。
改めて大事な原則であることを認識しました。
問題はみんなで解決する体制を作る
誰かがプロジェクトの問題を見つけたとき、その問題は発言者が解決する流れになってしまいがちです。問題共有したのに、結局誰からも協力を得られないと、ちょっとネガティブな気持ちになりますよね。
自分の仕事だけに集中していられたら一番楽かもしれないですが、そうするとチームのコミュニケーションが疎かになっていき、モチベーションも下がります。
チームの誰かが問題を抱えこむことは、プロジェクトの進捗にも影響します。問題に対し一丸となって解決するチームになるためには、そうなるようなシステムやルールを作ることがまず必要です。
また、常にチームで問題を迅速に解決しようとする文化を醸成するために、「問題ないことが問題」という意識をメンバー全員が持つことが重要です。
それと、チームで問題を解決できたときには、みんなで喜ぶことも大切だそうです。アットホームなチームを目指しましょう。
まとめ
まだまだたくさんの学びがありましたが、ひとまず以上です。大変良い刺激になりました。
全体的に人間関係やコミュニケーションの話が多かったのが意外でした。たしかに、不確実なことばっかりのプロジェクトマネジメントのなかでも、人間が一番不確実ですもんね。Team Geekの内容に通じるところがあるなと思いながら読みました。
また、弊社ではプロジェクト管理ツールにAsanaを使っているんですが、PMBOK入門本を読むと、改めてどの機能も理にかなってるんだなと思いました。もっとPMBOKの理解を深めたら、そういったツールもさらに有効活用できるかも？ という期待が持てました。
さいごに
いかがでしたでしょうか？ PMBOKについてもっと知りたい方は、ネット上にもたくさん情報がありますし、上記で挙げた本は初心者に大変おすすめです。
「プロジェクト」とは、「決められた期間内に、今まで誰もやったことがない、新しい成果物を作ること」です。それでいうと、きっとどんな職種でもプロジェクトマネジメントのスキルは必要だし、仕事だけでなくプライベートにも活かせそうです。ガチガチにPMBOKにはめ込もうとするのは現実的ではないですが、その考え方やノウハウを取り入れることは非常に有益です。
今思えば、2年前に挙げた結婚式なんかは、もうれっきとしたプロジェクトでした。あのときの私がPMBOKを知っていたら、前日の夜までムービー作成することにはなってなかったかもしれない。人生がそもそも「幸福」を目指す壮大なプロジェクトですものね。人類みんなプロジェクトマネジメント勉強すべきでは？
などと偉そうなことを言っておりますが、これからも継続して勉強していきたいと思います。最後まで読んでいただき、ありがとうございました。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
