そんなドヤれる経歴はありませんが、それっぽく”プロジェクトマネジメントとは”を語ってみる試みです。
「ほーん」くらいのノリで見てもらうことを想定しています。
プロジェクトとは
そもそもプロジェクトとは何でしょうか。定義としては現状からあるべき姿へ移行するための複数の業務と捉えることができます。
例えば「ECサイトを構築して販路を増やし客単価を上げる」「煩雑な事務業務を整理整頓し業務効率を上げ生産性の高い業務へリソースを割り当てる」などがプロジェクトとして定義できます。
プロジェクトは会社の特定の部門だけで行われることもありますし、部門を横断して行われることも少なくありません。
また、社内だけでなく外部ベンダーや専門家を巻き込んで行うものもあるでしょう。
目的と目標の違い
似たような言葉ですが、目的と目標は明確に異なります。
プロジェクトにおいては目的とは最終的な到達点であり、目標はそのプロジェクトで達成すべき基準になります。
やっぱ一緒じゃね…？って感じですが、例えば「ECサイトを構築して販路を増やし客単価を上げる」プロジェクトの目的は客単価を上げることであり、目標は一人あたりいくら上げるのか、というイメージです。
ここで注意すべきは「ECサイトの構築」や「販路を増やす」というのはあくまで手段だということです。ECサイトを作ったからゴール、販路を増やしたからゴールではないということです。
プロジェクトにおいてはこの目的と目標の設定が最も重要な要素となります。
プロジェクトの特性を理解する
どんな業界でも、どんな業種でも、どんな種類のプロジェクトでも概ね下記要素が全てのプロジェクトにおいて適用することができます。
- スタートとゴールが決まっている
- 不確定な要素が多い
- 異なる立場のメンバーが多数参加し分業して関わる
小規模なプロジェクトの場合、不確定な要素が少なかったり関係する人も少数だったりと、大なり小なりはあるにしてもこの３点はどんなプロジェクトにも言えると思います。
スタートとゴールが決まっている
どんなものにも始まりがあり終わりがあります。
ザッと羅列すると、構想→企画→見積り→決裁→計画→要件定義→設計→実装→テスト→リリース→保守というような感じです。
中には前後する要素もありますが、だいたいこんな流れでプロジェクトが進行していきます。
不確定な要素が多い
プロジェクト構想、または開始時点では不確定な要素が多いです。
たとえば、企画時点では具体的な実装方法などは不確定なことが多いでしょう。
（それでも見積り取らないとダメなのでたいへんなのよ…）
当初の計画通りプロジェクトが進むとは限らず、また以前に似たようなプロジェクトを経験していたとしても、全く同じ結果になるとは限りません。
かつ、比較的長期間になるプロジェクトも多いため、プロジェクトの目的と目標からできるだけ乖離しないよう不確定要素を時間とともに排除していく必要があります。
異なる立場のメンバーが多数参加し分業して関わる
経営層や経営企画部門が構想や企画をし、計画や要件定義は外部ベンダーやコンサルが行い、実装とテストは開発会社が、リリースは部門が確認し、保守はベンダーと社内で行う…などなど、それぞれのフェーズで関係する人物が大きく変わることも多いです。
スタートアップや一人社長の会社であったとしても、何かしらプロジェクトとして進めるためには外部の力が必要になることもあるので、そうなると複数名で担当分けして進めていく必要があります。
プロジェクトマネージャーとは
そこで必要になってくるのがプロジェクトマネージャーの存在です。
プロジェクトマネージャーはプロジェクトにおいて部門や社内外に関わらず一気通貫してプロジェクトに参加し管理監督する立場と言えます。
小さいプロジェクトではプロジェクトマネージャーというものをハッキリと設置しなくても成功することも多いですが、全社的な取り組みや複数部門または複数ベンダーが関わるなど、中規模程度のプロジェクトにおいてはプロジェクトマネージャーを設置することはある意味必須でしょう。
プロジェクトマネージャーはプロジェクトのフェーズごとに最適な人員配置を行い、一つ一つのタスクの進捗管理をしながら、期日通りにプロジェクトの目的と目標を達成するために日々運営しなければなりません。
そして、それらリスクマネジメントを適切に行いながら、メンバーに対し「良いものは良い、悪いものは悪い」と言える立場になる必要があります。
何か知らんけど怒ってばかり、焦ってばかりは論外ですが、問題が発生したときにキチンと指摘しない、是正しないのも問題ということです。（それは優しさとは言わない）
結局このあたりはメンバーとの関係性も重要になるので、コミュニケーションスキルに長けた人がプロジェクトマネージャー向きとも言えます。
プロジェクトマネージャーに求められるスキル
様々な要素がありますが、ここでは大きく３つ上げたいと思います。
- 全体を俯瞰して見れる
- 責任感を持って課題解決できる
- 人に仕事を任せることができる
プロジェクトの内容や特性によって求められるスキルは変わりますが、どんなプロジェクトにおいても通用するのはこの３点かな～と…。
ぶっちゃけ、高度なプログラムコードが書けるエンジニアあがりとか、ものすごい有利な条件でモノが売れる営業マンあがりでもプロジェクトマネジメントができるかどうかは全く別モノです。
全体を俯瞰して見れる
プロジェクトマネージャーはプロジェクトにおける様々なフェーズでいろんな人と関わりながら管理監督する必要があります。
つまり、プロジェクトの目的と目標を達成することを常に意識しながら全体像をよく見ておく必要があります。
ある部分で問題が発生した場合、関係する部門はどこなのか、この先の影響度など判断し決断する必要があります。
問題ではなくても、日々のタスクの優先度を考えるときにその対象者だけでなく、続きのタスクのどの部分にどう影響するかなど、常に全体最適を意識して行動する必要があります。
責任感を持って課題解決できる
全ての意識決定に責任を持つことも重要です。
例えば開発が遅延している場合、開発者のせいにするのではなくどうすればリカバーできるのか考え行動することが重要です。
何が問題だったのかしっかりフィードバックし、是正していく柔軟さと応用力が必要です。
責任転嫁ばかりして人のせいにするプロジェクトマネージャーの下では誰も働きたくないでしょう…。自らがタスク管理しているという意識を持ち、課題が発生したら真っ先に行動することが大事です。
人に仕事を任せることができる
プロジェクトマネージャーに最も重要な要素と言っても過言ではないのが、人に仕事を任せることです。
先ほどの責任感と相反するような感じかも知れませんが、「自分がやらねば」の精神を間違うと自分自身のタスクが膨大になり、その結果全体を見ることが難しくなって対応が遅れ、リスクが膨大になってプロジェクトが失敗する…ということも考えられます。
普段の業務においても先輩後輩でよくありガチなのが「自分でやったほうが早い」からと言って後輩に仕事を任せないパターンです。
確かに”その”タスクにおいては早く終わったかも知れませんが、次に同じようなタスクが来たときに後輩は経験していないので”また”自分でやったほうが早い、となります。
これではずっと先輩（＝経験者）がやることになって楽になりませんし、後輩はずっと未経験者になります。まぁ背中を見て育てってのもある程度あるかも知れませんが…やっぱ経験させるのが一番でしょう。
こと、プロジェクトマネジメントにおいてはそれぞれ専門分野があるので、全てのタスクにおいて「プロジェクトマネージャーがやったほうが早い」ということはないかも知れません。
しかし、それでもある程度の経験者がプロジェクトマネージャーをしていることが多いので、ついついメンバーの業務を奪ってしまうことをしているかも知れません。
メンバーに仕事を任せ、遅れそうとかクオリティが低い場合にアドバイスやフォローを行えるのがベストでしょう。
ちなみに、そんな余裕もないようなタイムスケジュールで組まれているプロジェクトはそもそも失敗だと思います…。
まとめ
プロジェクトマネージャーとは何モノなのか、どんな人が適性なのかをツラツラと書いてみました。
ある業務ですごく優秀な人がプロジェクトマネジメントも優秀か、と言われればそれは別の話です。もちろん優秀な人も多いですが、考え方や仕事に対する捉え方が異なるので、一概にそうとは限りません。
また、プロジェクト内容やジャンルによっても様々なため、求められるスキルや経験も異なると思います。
今回書いた内容はそれらジャンルに関わらずプロジェクトをマネジメントする上でのポイントをまとめてみました。
コレが正解とか間違っているとかではなく、参考程度に思っていただければな、と…。
コメント