PMとして開発プロジェクトを円滑に進めるには正論だけではいけない

PMとして開発プロジェクトを進めていく際には、WBSに代表されるような工程表を用意して、各タスクに担当メンバーを割り当てて、滞りなく工程が進んでいるのかチェックしていきます。

スムーズに開発が進めばよいのですが、工程を進めていく中であらゆるトラブルが発生するのが、システム開発の常であります。

PMとしてはそうしたトラブル対応も含めて、円滑にプロジェクトを進めていく器量が求められるわけですが、今回は正論を振りかざすだけではプロジェクトは円滑には進まないという話をしていきたいと思います。

前提：ルール無用というわけではない

まずPMとしてプロジェクトチームを統率し、チームとして機能させる以上、開発を進めていく上でのルール策定は必須です。

例えば打合せ議事録の顧客承認を徹底することや、仕様凍結の方法や凍結後の変更手順、社内のドキュメント類の申請フローなどなど。こうしたことをルールとして徹底しておくことで、マネージメントにかかる手間が軽減され、PMは個別の事案対応に時間を割くことができます。

ですから本記事で「正論だけではいけない」とは言いつつも、前提としてチームを機能させるためのルールは必要になりますので、その点を勘違いなさらぬようお気をつけください。

あくまで正論だけではいけないというのは”個別の事案対応において”ということです。

理詰めで追求しても改善は生まれない

プロジェクトメンバーの個別事案で問題が発生した際に、しばしば理論詰めで原因説明から対策案までを追求するマネージャーを目にします。

しっかりと因果関係を明確にして再発防止に努めるという観念では間違った行為ではありませんし、それで是正されるのであれば、理詰めで追求するにも意味があると言えます。

ただこうした正論を振りかざす行為に関してですが、”一つのプロジェクトをマネージメントしていく”というケースにおいては、個人的にはあまり感心しません。

理想ではなく現実を受け入れろ

現実問題として開発プロジェクトを観察すると、トラブルを起こしがちなエンジニアは危機感が足りなかったり報連相ができなかったりと、なにかと下手な問題を起こしがちなものです。

結局は担当SEの能力値に偏りは発生してしまいますし、一朝一夕で有能なSEへと変貌することはありません。そしてプロジェクトメンバーを入れ替えることができない以上、限られたメンバーでどうにかしてプロジェクトを遂行していくしかありません。

そこでPMに求められるのは、メンバーの能力値や特性を見極めて、担当作業と責任の分配をすることです。とにかく現実を受入れて、今いるメンバーで最善を尽くすにはどうするべきかを考えるのがPMの仕事です（社員やSEのレベルの底上げはPMではなく会社の役割）。

時と場合によっては、プロジェクト内で定められたルールを超越した、特例措置を講じていくこともPMとしての手腕の見せ所。

とにかく”理想と現実は異なる”ことを第一に理解しなければなりません。頭の良いPMほど仕組みで解決しようとする傾向があるので要注意といったところ。

正論攻めでは士気は高まらない

PMには「チーム全体の士気を高める」という役割もあります。プロジェクトも佳境を迎え、辛い局面になればなるほど、士気という目には見えない・数字にも表せない要素が大事になってきたりするものです。

だが正論を振りかざして仕組みばかりに依存したマネージメントを行っていては、なかなか士気を高めていくことができません。なぜなら何か問題が発生したときには、仕組みを犯した者が悪く、仕組みを敷いた者の責任は問われないという構図ができあがってしまうから。

ですがPMとしてメンバーを引っ張っていくのであれば、最後は自分が責任を取るという気概ぐらい持ち合わせてほしいものです。それにそうした気概はメンバーに伝わりますし、一体感という良い空気もできあがることになります。

正論攻めばかりでトラブルに対処してメンバーを追求していくだけでなく、時には大胆さをもってチームを統率していくことが、チームの雰囲気作りという点でも大事になることを理解しておきたいものです。

 

おわりに

正論やルールを否定するわけではありませんし、前提としてルールを遵守してプロジェクトを進めることは言うまでもありません。

ただ規模の大きいプロジェクトになればなるほど、理詰めや正論固めだけでは円滑なプロジェクト推進が難しくなっていきます。空気を読むこと、責任を抱えること、士気を高めることなどを意識して、時に大胆に、時に慎重にプロジェクト引っ張っていけるPMとしての姿を目指していきましょう。