プロジェクトの全体運営を経験できる人は少ない。優秀な人材でも、実際に体験しないと分からない
itpjstudy
プロジェクト全体運営のノウハウは、プロジェクトを安全確実に進めていくために不可欠です。しかし、意外にそれを学ぶチャンスは少ないのが実情です。一方で、若手・中堅の頃は、そのことに気づいていないことが多いです。
若手や中堅の頃に販売チームのリーダなどをやって、うまく回せたときなどは、「自分は誰よりもプロジェクト管理がうまくできる！」と思ったりしがちです。ただ、自際には、仕事がうまく回せるように、上の人がお膳立てをしてくれていて、それに気づいていないことがよくあります。
プロジェクト全体運営を経験できるポジションは限定的
下記は、ERPプロジェクトでよく見られる体制図です。このケースは、計42名が参画するプロジェクトです。
さて、この中でプロジェクトの全体運営を本格的に経験できる人は、誰になるでしょうか。このケースでは、42名のうち、3名しかいません。
- プロジェクトリーダ
- 業務・アプリチームの全体リーダ
- PMOチームのリーダ
プロジェクトメンバのほとんどは、日々の現場タスクを遂行するのに専念しており、プロジェクト全体の運営には原則関わりません。大きな計画立案や見直しは、プロジェクトのマネジメントメンバが担当するのが一般的です。
プロジェクトのマネジメントメンバだけが担うタスクの例
- プロジェクト全体スケジュールの見直し
- コスト超過への対応、追加予算の獲得
- 役員会への説明
- プロジェクト人材の調達 など
このように、プロジェクト運営をの経験を積める人達というのは、大変少ないです。数百人規模の大きなプロジェクトであっても、同じです。プロジェクトの全体運営は、数人のマネジメントメンバだけで行っています。大規模プロジェクトの運営ノウハウも、限られた人達にだけ溜まっているのです。
若手・中堅の頃は、見えている範囲が限定的
さて、次に、若手・中堅の視点では、見逃しがちなものについて、少しお話します。
ここでは、販売チームのチームリーダを取り上げます。この事例では、販売チームのチームリーダを取り上げます。販売チームは、非常に困難だと言われていた業務プロセスの改革に成功し、さまざまな人からの評価もピカイチです。
リーダ
非常に難しい改革を成功させた。
しかも、業務・アプリ全体リーダやプロジェクトリーダの力も、ほとんど借りずにやり遂げた。営業担当役員などのマネジメントととも、忌憚なく話せる間柄。
他のチームがなぜ苦労しているのか、理解できない。自分が担当すれば、もっとうまくできるはず。プロジェクト全体のリードも、自分ならできると思う。
すごいですね。ここまでできると、ある種の全能感を持っても仕方がないと思います。実際、将来、この人は大変優れたプロジェクトリーダになる可能性が高いと思います。でも、今すぐには、難しいです。
なぜか。体制図をもう一度見てみましょう。
そもそも、体制や役割上、チームリーダがプロジェクト全体を見通すことは難しい構造になっている
答えは一目瞭然。チームリーダが見えている範囲が限定的だからです。また、管理している範囲も限られています。
一般的な役割分担
| 販売チームの リーダ | 業務・アプリ 全体リーダ |
|---|---|
| 販売領域のみ | すべての業務・アプリ領域 |
| 3名のみ管理 | 30名近くを管理 |
| 日々の進捗・課題管理 | 管理プロセスそのものを定義・提供 |
| 自チームの業務遂行に専念 | すべてのチームに対して責任あり |
| 原則コスト責任なし | コスト調整・予算確保の責任あり |
各チームのチームリーダの立場からは、プロジェクト全体がどのように運営されているかは、あまり見えません。それは、プロジェクト体制の構造・役割分担から来るものであり、いかんともしがたいところがあります。
そのため、上位のポジションに昇格し、立場が変わってはじめて、「あ、上の人達は色々やっていたんだ」と気づくことになるのです。
ポジションが上がって出会う発見・試練
先ほどの販売チームリーダの例で、続けて説明します。これまでの功績が認められて、業務・アプリチームのリーダに昇格しました。さっそく、いろいろな試練にあっているようです。
試練その１ 自分の目の届かないところで問題が起きる
生産チームの進捗が大きく遅れているみたいだ。
生産チームの人達は、全然報告を上げてこないから、実態がよく分からない。でも、細かく聞き込みに行く時間もない。どうしよう...
販売チームだけでチームが小さいときは、わざわざ聞きに回らなくても、自然と状況が分かりました。30名以上ともなると、そうもいきません。
試練その２ 計画やルールを定義・提供しなければならない
これからシステムテストフェーズに入るから、テストの進捗資料フォーマットを準備しないといけない。
そういえば、これまでは、いつも誰かが用意をしてくれていた。どうやれば良いんだっけ...
計画やルールなどについては、たいていPMOやテスト事務局などが、チーム横串で作成します。そのため、個別のチームでは、取り組んだことがないのが普通です。
試練その３ 様々なチーム事情が絡み合った状況を相手にしなければいけない
プログラム開発が遅れているから、ステアリングコミッティの役員たちへ状況説明しなければならない。
でも、遅延の理由もいろいろだ。販売チームは仕様変更、購買チームは技術的課題、インタフェースチームは、そもそも設計ができていない。開発メンバの人数不足もあるし、色々な要素が交じり合っているから、簡単には説明できないよ...
ひとつのチームという限られた範囲であれば、問題状況も比較的シンプルなことが多いです。一方で、様々な領域が絡んだ問題を、分かりやすく説明するのは簡単ではありません。どのように分かりやすく見える化するか、どう解きほぐして問題解決するかは、ポジションが上がれば上がるほど、必要になってくるスキルです。
これまでお話をしてきたように、プロジェクト全体の運営ノウハウを身に着ける機会は限定的です。近年は、プロジェクトの大型化も進んでおり、メンバに限らず、チームリーダですら、大きな組織の中の歯車化が進んできていますので、全体運営ノウハウを学ぶ機会はますます希少になってきています。
そして、その「なかなか学べない」ことについて情報発信していこうというのが、ITプロジェクト研究会を立ち上げた理由でもあります。いろいろなトピックについて、情報提供していきたいと考えています。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
