PMになったら最初にやることは何か？
学校のテストに満点はありますが、仕事では満点が何点かわかりません。
システム開発プロジェクトはQCDの達成を目指しますが、それを合格点と考えたとしても、クライアントによってもプロジェクトメンバーによっても満点の点数は異なります。
PM自身が何点満点を目指すか、何をしたら点数が減っていき、何を達成したら満点となるかを考えること、それをプロジェクトメンバーに打ち出すこと、それがPMになって最初にやることです。
PMはプロジェクトの基準
システム開発プロジェクトの品質は、PMによって大きく変わります。
クライアントや業界によっても品質基準は異なり、社会インフラである金融や通信ではとても高い品質を求められます。金融のプロジェクトにいた人が、製造業のプロジェクトに参画したら、あまりに緩さに驚くと思います。高い品質基準の業界で働くエンジニアにとって普通だと思っていたことは、他の業界では普通ではないのです。
システム開発プロジェクトで作成する要件定義書や基本設計書などの成果物は、クライアントレビューの前に開発チーム内でピアレビュー、チームリーダーレビュー、PMレビューといくつかの段階を踏んで品質が高められます。この時にPMのレビューが緩いと、その下のチームリーダーのレビューはもっと緩くなり、その下のメンバーはさらに緩くなります。この連鎖は怖いもので、大規模プロジェクトになるとピラミッド体制の階層が増えて末端メンバーの割合が高くなるため、プロジェクト全体の品質レベルは極端に下がってしまいます。
仮にPMとクライアントの満点認識が100点で一致していたとしても、PMが90点で妥協してしまえば、その下のチームリーダーは90点を目指すことになり、そこから妥協すると80点、これが繰り返されると末端のエンジニアでは60点くらいを満点と考えてしまいます。100人のプロジェクトでは7割くらいが末端のエンジニアなのでプロジェクト全体では65点満点となり、クライアントが考える品質基準には到底満たない結果になってしまうのです。
こうならないために、PMは120点満点くらいを目指すことで丁度良いのです。PMのレビューは厳しいとチームリーダーから思われることでチームリーダー自身が行うレビューも厳しくなり、プロジェクト全体としてなんとか品質基準を維持できるのです。
PMの妥協は、プロジェクト品質低下の始まりです。
システム開発の合格点
納期が遅れたり予算以上に費用がかかったりと、システム開発プロジェクトはまともに導入できないものと、企業の経営層には思われています。
だいぶ昔、予算を超過し納期も守れないのでリスケの相談をした際にクライアント責任者から「現場ユーザーの要望を聞き過ぎて複雑で難しいものを作ってしまい、だから予算も納期も守れないのではないか」と言われたことがあります。
例えば100点満点に対して120点をとったとしても、それは褒められる結果ではなく余計な20点となることがあります。システム開発プロジェクトでは、クライアントの計画や目的を逸脱してまで合格点以上の点を取ることは、むしろ不合格なのです。
世の中的にクライアントの言いなりのベンダーやPMは不評ですが、ビジネス的にも不合格です。合格点を取るためには、クライアントの意見やリクエストにNOを言うことも必要で、PMは合格点とは何かを常に強く意識してユーザーと対峙しつつ推進していかなければなりません。
QCDの約束を守ることがクライアントの期待値だとすると、守れて普通の評価です。QCDを守った上で期待値以上の何かを提供して合格評価となるのです。
PMマインド
PMの考えや基準がプロジェクトメンバー全員に認知されることによって、同じ到達点に向かってプロジェクトを進められます。PMは、最も身近な働き方モデルであることを意識するべきです。メンバーに言い聞かせるのではなく、見られることでPMの考えがチームに浸透するのです。
成功に導くことが出来るPMに共通する特徴を６つ紹介します。
①言い訳をしない
言い訳をしても結果は変わりません。プロジェクトマネージャーの作業は多岐にわたり忙しいことが日常なので、忙しい中で考え進めることが当たり前に求められます。PMが忙しさを理由にしたら、メンバーも忙しさを理由に遅延していきます。
②準備に厳しく結果を責めない
内部レビューはリハーサルです。内部レビューを厳しく行うからユーザーレビューがうまく行くのです。ユーザーレビューの結果が良くなかったら、それは内部レビューが甘かったためであり、レビューした人の責任、突き詰めればPMの責任です。自分のケツは自分で拭きましょう。
③誰よりも中身を理解している
PMが表面的な管理をしていると、チームリーダーも同じように表面的になります。この連鎖の行きつく先は末端のエンジニアになって、設計も開発もテストも中身の責任は全て現場に押し付けることになります。
PMが中身を見なければ、高い品質を維持することは出来ません。
④放置しない
窓割れ理論はあらゆる行動に波及します。PMが雑に説明をしていれば、現場のメンバーも雑になっていきます。誤植や分かりにくい表現など些細な誤りを放置してはいけない最たる人は、PMです。
⑤即断即決
PMがぐずついていたらプロジェクト全体がぐずつきます。遅延の対策、課題の対応方法などメンバーからの相談には即座に回答できることが大切です。即断即決をするから頼りになる存在として認められ、タイムリーに相談が来るのです。相談しても良いリターンがなければ、現場から見放されていきます。
⑥汚れ役を率先する
クライアントからの無茶な依頼やマネジメントからの計画外の作業指示をメンバーへ横流しすることは最悪です。誰もやる余力がなければ、PM自身でやるか、無理なら断るべきです。現場が困っているのに助けないのも最悪ですが、火に油を注ぐような行動をしたら誰もついてきてくれません。
苦しい時の考え方
負ける勝負はしない、苦労したくない、大変な開発プロジェクトには関わりたくない、このような考えは理解しますし、出来ればその方が良いに決まっています。
ですがシステム開発プロジェクトは、大変なことがない方が珍しいです。
もし大変な状況に入り込んでしまったら、頑張る必要はあるけれど無理して体調を壊すのは絶対に避けなければなりません。PMは、その責任感から頑張り過ぎてしまうこともあり、頑張りと無理のさじ加減は難しいです。
大変な局面になった時に頭の中で大変大変と思っていると、どんどん気持ちが辛くなっていくので、せめて気持ちだけでも切り替えるために「これは、チャレンジだ」と思うようにするのも考え方のひとつです。「神様も大変なチャレンジを与えてくれたなぁー」と思えば、苦しいことが挑戦に変わり、少しは前向きな気持ちを持てるようになります。
大変な状況に直面しても逃げ出さず、かと言って真正面からぶつかり砕けてもいけないので、上手く向き合うのもPMの大切なマインドのひとつです。
数字より人間性
数値で管理することだけをPMの仕事だと思っているクライアントがいますが、それは大きな間違いです。
システムの全体設計や要所の作りなど中身にもがっつり入り込むことでPMの拘りがシステムの芯となり、その芯を軸にしてメンバーと一緒に進めていくことで一貫性のあるシステムが出来上がるのです。中身に入るからこそPMの人間性が見え、信頼関係が生まれます。数字だけの管理では人間性は見えませんし、そのような人を信頼することもありません。
まとめ
前後編にわたってマインドについて書いてきましたが、結局は、気持ちであり、信念であり、仕事への向き合い方だと思います。
プロジェクトマネージャーは、職人芸でもなくスペシャルなスキルが必要なわけでもありません。ある程度の経験は必要ですが、ただただどうしたらゴールに到達できるか懸命に考えて進めていくだけです。だからこそマインドが大切なのだと思っています。
効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！
