Posted on

【システム開発プロジェクト炎上診断】 ~ ⑥PM編

正月に3つの目標を立てて1年間過ごすことを10年以上続けています。
目標と言っても読書を年間100冊など簡単なものですが、プライベートなことなので甘えも出てしまい、3つとも達成したことは過去に1、2回しかありません。
システム開発は、プロジェクト開始前に計画を立てて、その計画に基づいて進めていくものですが、1年先、長ければ2、3年先のゴールということもあり、計画を綿密に立てたとしても目標を達成することはとても大変です。
仕事柄なのか職業病なのか目標を設定し計画を作ることは好きな方ですが、それでもプロジェクトの計画策定はとても難しいと、いまだに思います。
今回は、プロジェクトの炎上にPMがどのように関係しているか、PMの仕事とスキル、PMが作るべきドキュメントなど解説していきます。

プロジェクトマネージャーの仕事は3つだけ

システム開発のプロジェクトマネージャーは、システム全体を設計して、完成までの計画をたて工程を管理していく推進の責任者です。
プロジェクトマネージャーの仕事は、簡単に言ってしまえば、計画策定、推進管理、対策検討の3つだけです。


①計画策定
最初の難関であり最も難しいのが、計画策定です。
受験勉強で志望校に合格する目標に対して1日の時間割を1年先まで考え、風邪をひいてしまった時のリカバリなども考え現実的な計画を立てることと同じです。受験勉強であれば目標を下げることは自己責任で自由ですが、クライアントから受託したプロジェクトではそうはいきません。1年先の計画を1日単位で決めることはプライベートでも困難ですが、システム開発プロジェクトでは、これを一個人ではなく10人、100人、多ければ1,000人くらいの集団の活動として計画を立てなければならないのです。
予知能力があるか、よほど想像力に長けた人か、あるいは豊富な知識とPM実績のある人でないと計画策定は困難です。
計画策定を簡単と考えている人は、そもそも計画自体が甘いものになっているか、計画の重要性に気が付いていない人で、そんな人にPMを任せたら確実に炎上します。


②推進管理
計画を鏡として実績を評価し、遅れていたら計画通りに戻すためにリカバリする。これはあくまで計画が正しいことが前提となります。もしかしたら計画が間違っていることもありますし、ざっくりした計画であれば遅れに気が付くこともできません。計画通りに進めることに躍起になっていると、気が付いたら迷子になっていたり、気が付かないまま間違った方向へ突き進んでいたり、なんてことにもなります。
計画通りに進める、計画との乖離を把握する、間違いに気が付いたら起動修正をかける、このような活動が推進管理です。
日々の実績を把握することを管理だと思っている人にPMは務まりません。状況に応じて計画を見直し、当初設定したゴールを目指して推進する力こそPMに必要なスキルです。


③対策検討
推進していく中で課題や壁にぶつかることは必ずあります。そんな時、解決策を考え、決断するのもPMの大事な仕事のひとつです。
解決方法のアイデアは、PM自信がいくつも出せなければいけませんし、現場のメンバーに出してもらったとしても、どの案を採用するかはPMの判断です。そのためには様々な課題に対する対応方法の引き出しを多く持っている必要があり、また状況に応じて正解を考えることが重要です。考える力と決断力がなければ壁を上ることは出来ません。

あくまでPMOは補佐役

PMOの仕事は、主に推進管理です。PMが立てた計画との乖離を把握することが主な仕事であり、計画を立てることも、遅延の対策を考えることも、出来ないあるいはやらないことがほとんどです。
問題のあるプロジェクトの対策としてPMOを強化することがありますが、PMO強化で効果を発揮するのは、PMが相応しい能力を持ち得ている場合だけです。そもそもPMの能力が足りていないところにPMOを強化したところで、まったく意味はありません。PMOは、あくまで補佐なのです。
逆に言えば、PMの3つの仕事である計画策定、推進管理、対策検討をできるPMOがいたら、その立場にいるだけで実質はPMということになります。この場合、体制上のPMは置物となっているはずです。

PMが作るべきドキュメントは2つ

プロジェクトマネージャーは推進の責任者なので、システム全体を理解して、完成までの道筋を把握していなければなりません。そのためにPMが作るべきドキュメントは2つあります。PMOやチームリーダーに作らせてPMがレビューをするという形でも良いですが、自分で作ることで気付きもあるので、やはりPM自信で作るべきだと考えます。


①システム全体図
システムの完成予想図を作れないと話になりません。
作れます、作ったことがありますと言う人でも、コンポーネントの粒度がバラバラであったり、サブシステムを繋ぐ線があちこち交差していたり、見るも苦しいものだったりします。
システム全体図は、完成イメージとしてプロジェクトの最後までほぼプロジェクトに関わる全ての人の目に触れ共通理解のために利用されるので、正確なことはもちろん、わかりやすいことが重要です。見た目の美しさも含めて、分かりやすさを追求したシステム全体図を描ける能力は必須です。
PMがゴールをイメージできていなければ、プロジェクトチームで一つのゴールを目指すことは困難です。


②各種計画書
要件定義の進め方や総合テストの計画書など主要な工程の計画書は、プロジェクトマネージャーが作るべきです。PMが作るべき理由は、ひとつには計画策定自体がPMの仕事であること、もう一つが計画書はその工程が始まる前に作成しクライアントと合意するものであるため、かなり先を見通す必要があるからです。目先のことに注力していると後手後手になり、推進が苦しくなってしまいます。PMは2つくらい先の工程を見ていることが大切で、そのためにも各種計画書はPM自信で作るべきだと考えます。
どのような段取りで、どんなスキルが必要で、何人のエンジニアをどのように配置していくかを、かなり前段階で考えることによって先手を打つことができるのです。
PMが忙しくて計画書作成に手が回らない状況は、もはや炎上しかかっています。

提案時に軽視されるPM選定こそが炎上の始まり

SIerがシステム開発プロジェクトを提案する際、マネジメントが提案書をチェック、承認してクライアントへ提出されますが、費用や計画に比べてPM選定はあまり重視されていないと感じます。
システム開発プロジェクトにおけるPMの重要性は高く、プロジェクトの成否に大きく関わってくることを知っているにも関わらず、提案時のPM選定は緩いです。
能力を評価しないで後はよろしくなんてことは、企業の役員選びではあり得ない事ですが、よほど注目度の高い案件でもない限りPMの任命は結構適当に行われています。
提案の時点で稼働が空いている人の中から任命しなければならないという事情も理解はできますが、マネジメント自身がそのように成長してきたからか、あるいは失敗した時に全責任をPMに押し付けたいのか、はたまたPM選定をしている時間がないのか、いずれにしてもPM選定に対する評価や承認が甘すぎるため、問題を引き起こすのです。
提案時だけ優秀なPM経験者がスケジュールを立てて、体制と見積り工数をチェックしたとしても、それは優秀なPMの計画です。凡人PMには優秀なPMが作った計画で推進することは困難ですし、逆に凡人PMが作った計画は優秀PMからしたら甘くて使いものになりません。他人が作った計画で良しなに推進してくれというのも困った話です。

プロジェクトとPMの性格マッチング

経験値やスキルも大切ですが、見落としがちなのはキャラクターです。
プロジェクトの特性やクライアントの性格に合ったPMを充てることは重要です。
例えば、お金を扱うシステムであれば正確性が大事ですし、個人情報を扱うシステムであれば機密性も大切です。ボリュームが不明なC向けの新規サービスであれば、割り切りやスピードが重要になってきます。
正確性が大事なシステムであれば、きっちりしていて日頃から凡ミスの少ない几帳面な人が良いですし、機密性には慎重な性格が合い、割り切りやスピードには多少雑でも切った張ったができるアグレッシブな性格が良いです。
プロジェクトの特性と真逆の性格のPMを任命したことでミスマッチを起こし、苦労しているプロジェクトをいくつも見てきました。正確性が大事なシステムを作ろうとしているのに雑でアグレッシブなPMや、スピード重視なのに時間をかけて几帳面に仕事するPMは、能力以前にクライアントがイライラして衝突を起こします。
経験値やスキルが多少足りなくても、最悪プロジェクトの特性とPMのキャラクターが合っていれば、なんとかなる可能性はあります。

イラスト:プロジェクトマネージャーの仕事は3つ

①計画策定


②推進管理


③対策検討

炎上診断チェックリスト(⑥PM)

⑥-1.実績
・プロジェクトマネージャー経験があるか
・プロジェクトマネージャーが作るべき成果物を言えるか
⑥-2.経験
・扱うソリューション、言語、OS/MWのプログラミングと設計の経験があるか
・設計書の体系とテンプレート作成の経験があるか
・テスト方針と計画書作成の経験があるか
⑥-3.性格
・PMに向かない性格(断れない、見栄っ張り、優柔不断、自分目線)ではない
・プロジェクトの特性にあった性格か
・クライアントのキーマンやカウンターの性格を知っているか
⑥―4.体力
・過去2-3年で実質的な病欠は数日程度しかない
⑥-5.能力
・ビジネス感度は高いか(今まさにクライアントが気にしている事を3つ言える)
・構造的理解と説明ができるか(全体でxx、いくつに分類され、それぞれ何本)
・レビューでクライアント同等に指摘ができる知識とスキルを持っているか
⑥-6.稼働
・実質的に100%プロジェクトに稼働がさけるか(社内のイベント幹事や分科会への参加などはない、あっても断ることが出来る)
⑥-7.指導力
・メンバーへの指示は、必ず5W1Hをもって行っているか
・次のチームリーダー候補やPM候補を見定めているか
⑥-8.マインド
・マネジメント、クライアント、開発メンバーの大切にする順番を付けられる
⑥-9.考え方
・PMとして最も大切な役割を3つ言える(道筋付け、問題回避、自走など)
⑥-10.信頼関係
・クライアント責任者との関係性は良好か(プライベートも含めて)
・クライアント責任者とホットラインを得ているか

効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください!