PMとしての成果の出し方 – なぜプロジェクトは遅れるのか –

なぜプロジェクトは遅れるのか。この問題へのアプローチはさまざま人たちが取り組んできたと思います。今回は、私がこれまでやってきたプロジェクトマネージャー(PM)としての振る舞いを紹介していきます。

本題に入る前に、私のプロファイルについて少し触れておきます。

私は、文系出身で社会人になるまでは、HTMLも知らない(書けないではなく)ようなずぶの素人でした。エンジニアとして就職をしたわけでもなかったですし、始めはエンジニアとしてではなくビジネスサイドで仕事をしていました。その後、プログラミングを学びエンジニアとして仕事をするようになりました。主にRuby on Railsを活用してのアジャイル開発をするようなスタイルでしたので、ここではアジャイル開発のプロジェクトを前提として話を進めていきます。

なぜプロジェクトは遅れるのか

さっそくですが、プロジェクトが遅れる原因について考察をしていきましょう。

さまざまな要因によって、プロジェクトが遅れるという現象は発現します。メンバーが優秀であったとしても、難易度が低かったとしても、概ねこの現象は起こってしまいます。プロジェクトに参画するメンバー全員が避けたい事象であるにも関わらず、です。

原因1 開始当初と状況や仕様が変化する

プロジェクトの途中で、仕様はほぼ必ずといっていいほど変化します。これは、プロジェクトが遅れるよく言われる要因でしょう。また、仕様の変化によってもたらされる開発工数の増大を事前に予測することも難しいです。

原因2 ビジネスサイドとエンジニアサイドでの情報ギャップがある

ビジネスサイドからに要望は、前提知識が必要なことが多く、エンジニアサイドが完全に理解するのは難しいことがあります。また、ビジネスサイドからの要望は、ソリューションのうちの一つでしか無い場合もあり、効率的な開発を阻害することもあります。

顧客を大切にと言ってる会社であればあるほど、マクロ的な視野ではなく、顧客の担当者が思いついたソリューションをそのまま要望上げやすいです。これは営業マンが未熟だからではなく、エンジニアとビジネスサイドでは情報にギャップがあるためです。また、立場が異なるが故に、同じ事実を見たとしても視点が異なり、別の世界を見てしまうのです。

原因3 エンジニアは楽観的である

私が接してきた中で、概ねエンジニアの人は楽天的でプロダクトを作ることに対して真摯に向き合ってくれていることが多いです。そもそも、エンジニアにかぎらず、仕事をする上で意図的に自分の成果を下げるということをする人はそう多くないはずです。その為、早く開発を終えようというポジティブなバイアスがかかった見積もりをしがちです。悪くいうと、きっとこれくらいで自分ならできるだろう・自分はこれくらいできるんだと知ってほしいという、淡い期待・希望的観測で見積もりをしてしまうのです。

原因4 プロジェクトとはそういうものである

これは経験則でありますが、緩めの期限を設定し、仕様の変更が比較的少ないようなプロジェクトであったとしても、プロジェクトは遅れてしまいます。これは、プロジェクトという物の性質なのではないかと思います。アサインされているメンバーは、目標に合わせて開発を行っていくため、スケジュールに余裕があれば、本来やらなくても対して問題にならないような付加的な機能や、やらなくてもよいようなリファクタリング、無駄に凝った設計をしていまう傾向があるからではないかと考えています。

これらの要因が相互依存的に発生し、プロジェクトは遅れていくのだと思います。

PMとしての振る舞い方

まず、私はPMをやる上で、なにもしなければプロジェクトは必ず遅れていくのだと肝に命じています。その上で、どのようにプロジェクトを円滑にかつ効率的に進めていくためにどうすればよいのかを考えています。

プロジェクト内で、具体的に何が起こるのかは予測は難しく、起こってからでないと把握もできませんが、プロジェクトを進める中でプロジェクトがどうなるのかを理解しておくことはとても重要です。つまり、遅れの直接的な要因を事前に特定することは出来ないが、どういった事象が発生するとどうなるのかという一般的なことを理解しておくということです。これによって、ハインリッヒの法則ではないですが、問題発生のアラートを検知し事前に対応をすることができるのです。

ビジネスサイドの成果にコミットする

まず、そもそもどういった課題があってその背景は何で、なぜこの開発が必要なのかをPMが必ず理解しておくことがとても重要です。というのも、上述したとおり、仕様は必ず変化します。その際に、正しい理解をしていれば、なぜその変化が起こったのかを正確に把握することができます。

ビジネス課題が変化したのか、背景情報に漏れがあったのか、背景そのものが変化したのかなど、変化の原因を正しく把握します。 もしかすると、よりよい実現の仕方が他にあるかもしれませんし、その仕様変更自体がいらないものかもしれません。

PMやエンジニアは、開発の成果にコミットするのではなく、ビジネスサイドの課題解決にコミットをするべきです。そうしないと、永遠に続くような仕様変更や追加開発に対応し続けなければならないかもしれません。

100点を目指さない

プロジェクトに対してポジティブな影響を及ぼすエンジニアは、100点の開発を1つする人ではなく、65点の開発を10個する人です。そもそも、完璧な要件定義などありえず、PDCAを回してみないと判断などできません。その上で、要件定義段階の100点を目指していく意味はほとんどありません。であれば、100点ではないが合格点をとれるプロトタイプを数多く量産していったほうが、ビジネス課題の解決に対してポジティブな影響を及ぼします。

期限がゆるいと100点を目指すべく完成度を磨いていってしまいます。期限に余裕が出て、100点を目指そうとしているエンジニアを見かけたら、必ず他の機能開発などにアサインをして、合格点ぎりぎりの機能をより多く開発するようにします。

こういった振る舞いをするために、PMはそもそも合格点がどこにあるのかを把握しておく必要があります。ですので、ビジネスサイドの要望を深掘りして正しく理解しておくことが大切なのです。

ノーという力

私の大好きな本でに「インテル経営の秘密」という経営本があるのですが、その中に、

一つの約束をするたびに、何かそれ以外のことを約束する機会を喪失するのである

という言葉があります。

まさにその通りだと思います。プロジェクトに置き換えると、追加の機能開発をするということは、他の既存機能のブラッシュアップに当てる時間を奪うことや他の新規機能を開発する時間を奪うということを意味しています。

そこで、PMは仕様の変更や追加開発の要望に対して、是非ノーと言いましょう。もちろん、先程のとおり、ビジネス要望を正しく理解していることが大前提です。イエスというのは大変に心地がよく、自分ならば、このチームならば、実現可能だろうという自信や信頼の現れでもありますが、そのことによって、本当に実現するべきものが失われるのであれば本末転倒です。正しい理解に基づいたノーを提案することが、プロジェクトの成功に寄与するのです。

最後に

今回は、見積もりのテクニック論やメンバーのマネージメントの仕方、ビジネス要望の理解の仕方などのミクロな話はしませんでした。もちろん、こういったところにも、細かなノウハウはたくさんありますが、その辺りは、また別の機会に。


この記事を書いた人
三角 勇紀
三角 勇紀
代表取締役 COO
シングラー株式会社 代表取締役 COO。同社にて、競り負けない採用を実現する人材分析サービス「HRアナリスト」を開発。「ユーザーにとって意味のあるプロダクトを」をモットーに、エンジニアの育成・採用にも従事。文系出身のRailsエンジニア。

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

お仕事をお探しの方へ

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)