Hatena::ブログ(Diary)

牛丼マネジメント このページをアンテナに追加 RSSフィード

2018-06-13

プロジェクトマネジメントを初めてやる時に失敗する4つの勘違い

プロジェクトマネジメントをやろうとしている方もやりたいと思っている方も、初めてPMになった時必ずと言っていいほど躓く事があります。

PM系記事を見ると、ポイントを端的に並べているものが多いですが、実際にその通りにやったところで失敗するので、「今回はなぜ失敗するのか?」を

中心に書いてみたいと思います。その失敗するポイントをおさえる事で成功に近づけるはずです。

私はSIerでPMを長い事やっていましたが、下記4点を曖昧にしたものは必ず後で苦労するはめになっていました。

開発のプロジェクトマネジメントというと、開発のプロセス管理者のように感じられがちですが、プロジェクトマネジメントプロジェクトのマネジメントが仕事になるので、プロジェクトの成功に責任を持つという大前提の勘違いがあると危険です。

1.プロジェクトの目的や目標は与えられるものだと思っていると失敗する

一般的なクライアント(社内だとなおさら)RFPが出てくることはまず無いと思います。

PMが明確にするのは、コストやスケジュール、ましてやクライアントの担当者が言っている”夢”のヒアリングではありません。

そもそも最初に出てきたプロジェクトの目的は概ね見当違いな事が多いです。

  • 市場調査していない
  • 思い付きで始まっている
  • 途中から目的が変わったものが伝わってきている
  • 担当者と決裁者の意見が擦り合っていない

などなど、紆余曲折してからPMの所に来るものなので、そのまま鵜呑みにして進めるとあとあと痛い目にあいます。

なので、最初に行う事はこのプロジェクトのオーナーが誰であるかです。

また、プロジェクト規模にもよりますが、否定権を持っているプロジェクトのオーナーと話せる状態になっていないとちゃぶ台返しにあったりします。

自身がプロジェクトマネジメントという役割で入るのであれば、先ずは誰が決裁権を持っているのかを把握する所から入ります。

次に、その決裁権を持ている人が(概ね忙しい)プロジェクトにどれほど関与するか把握しましょう。

忙しく、関与もあまりしないのに決裁権を持っているような状態はちゃぶ台返しが3回ぐらいあると思ってください。

その場合は、どこまではこちらで決めていいのかを擦り合わせます。

画面設計にまで口を出すけど忙しいのでたまに来ては文句を言って帰っていくようなパターンは絶対に上手くいきません。

決裁者が何を気にするのか、どこに重点を置いているのかが分かれば、そこだけ抜き出して決裁者に決めて貰う場所を用意すれば忙しい人も時間を取りやすくなりますし

こちらとしても、その点については合意が取れている前提で進められるので安心です。


2.人がたくさんいればプロジェクトが進むと勘違いしていると失敗する

人が増えれば増えるほど、情報共有が複雑になり、全体ミーティング後に個別ミーティングを開き、個別ミーティングを集めた評議会が開かれ…という事になりかねないです。

プロジェクトマネジメントをする場合、気を遣うのは人の配置です。

  1. 誰が何をいつまでにするのか(させるのか)
  2. 誰と何があれば、それは可能なのか
  3. 何と何が連結する必要があるのか

優秀な技術者をたまたまアサインできたとして、それで万事うまくいく事は決してありません。

優秀なエンジニア評価されている人が、”何において優秀なのか”を知ってください。

良く忘れがちなのか、インフラ構成・デプロイ方法・アーキテクチャ選定・URIルール・データバックアップ方法を決め忘れる事です。

社内で優秀なエンジニアの中に、上記を包含して考えられる方がどれほどいるでしょうか?

フルスタックエンジニアに位置付けられた人にどれだけ上記の仕事をプロジェクト開始直後に振出ができているでしょうか?

言語選定・フレームワーク選定・DB選定辺りは結構把握できているのですが、上記はよくよく忘れた結果動き出しがぎこちなくなることがあります。

また、セキュリティ要件も初期の頃に握っておくべきでしょう。個人情報の取得があるからSSLにするといった安直なものではなく、

社内でどう活用されるのかも考えた場合、DB設計やインフラ設計・アーキテクチャにも関わってきます。

そして優秀な企画者がスケジュールを守るとは限らないという事も忘れないでおきましょう。

最上思考に捕らわれてリーンスタートアップが出来ない人や、ドッグフーディング開発が理解できない人もまだまだいます。

目的に応じて企画者側もスケジュール管理しないと何度でも最上に向けてやり直せると勘違いされてしまいますよ。

最後に、人がたくさんいても人はタスクを明確にされないと動きません。過剰に人が居ると人は役割を全うしなくても誰かがやるだろうという思考になります。

珍しく人が潤沢にいる場合は、全員にタスクを割り当てマイルストーンを設定し、忘れがちな非機能要件を見落とさずにいましょう。


3.プロジェクトマネジメント進捗管理と報告だと勘違いしていると失敗する

これは当たり前の話ですが、プロジェクトマネジメントというのは開発のスケジュールを立てたり、進捗確認をするのが仕事ではありません。

プロジェクトを成功する為に必要なプロセスとして進捗管理を行い、課題の早期発見をする為に行うものなので、それが仕事だと勘違いしないようにしてください。

進捗管理は期間的には長いですし、開発あるあるネタがたくさん転がっているので、殊更この辺にフォーカスを当て気味ですが、

実際にはプロジェクトマネジメントの仕事の大部分は開発前に8割がた終わっているもので、残りは進捗管理を行いながら適宜出てきた問題に対処する事になります。

また、プロジェクトで出てきた問題に対し即座に解決する能力が求められます。

要件定義・設計までは机上の空論に過ぎません。現場で初めて見える問題は大量にあります。

  • 想定していた機能がフレームワークでは使いにくい
  • ミドルと言語の相性が悪い
  • 使おうと思っていたパッケージでは対応できない要件が増えた
  • 出来上がった画面が重い
  • 設計通りに作れない状況がある
  • デザインが想定と違う

などなど。

開発が最高速度で開発を継続的に行う為に出てきた問題は片っ端から潰していく必要があります。

解決方法も多数あり、調整・交渉・選定変更・人員追加といった各種パラメータチューニングする事で対処可能です。適宜使い分けをしましょう。

この時にさらに注意をするのであれば”ゼロサム交渉はしない”という事です。

「これをやると、これは出来ない」という交渉は誰でも出来る安直で頭の悪い交渉方法です。※だって言われなくたってわかるでしょう。

交渉の相手方は探ってきているのです。あなたの力量を。十分に勘案し最大限リスクを抑えながら疲弊し続けない交渉術を身に付けましょう。

また、解決方法次第では、エンジニアからも信頼され、決裁者からも信頼される事があります。

複数回良い解決方法が見つけられると、権限が増えたり交渉せずとも言い値で決裁者を動かす事が出来るスキルも身に着けられるでしょう。


4.メンバーが想定通りに動くと勘違いしていると失敗する

配置されたメンバーの力量を測り、適切な配置をし、進捗管理を行っても上手くいかない事があります。

ここがプロジェクトの最も難しいポイントで、人をコントロールするのは難しいという事かなと。

  1. 進捗報告は虚偽が含まれる
    1. これは期日通りに完成させるという事以外決めていない時におきますが、人によって完成の粒度が違うという事
    2. Aさんは単体テスト完了で納期通りの事もありますが、Bさんは結合テストまで完了して完成とする事もあります。
    3. 進捗報告のポイントを整理し、何が出来たら何%とするかを決めておくことが必要です
  2. 人は楽天的に考えがち
    1. 例えば、自分が作業に入る時には必ず事前のデータがあり、選考しているメソッド共通メソッドが用意されているものだと仮定して動きます。
    2. 事前にCPM図を用意するなど相互関係をはっきりさせる事と、テストデータの用意など作業に必要な作業時間をスケジュールに盛り込めるかどうかがカギになります。
  3. 1日8時間20日働かない
    1. 風邪をひく
    2. モチベーションが上がらない
    3. 他人の質問や問題に引っ張られる
    4. 人は何かにつけて予定通りに進めないものです。

ざっと4点とは言ったものの、ふたを開けるとなかなか面倒な事が多く、とはいえこの辺はしっかり押さえておかないとプロジェクトは成功できません。

もちろんこれらが完璧であっても失敗する事やデスマーチになる事もあります。

それでも、正しく開発する為に重要なポイントだと思うので、しっかり押さえておくと良いでしょう。

最初に書きましたが、プロジェクトマネジメントはプロジェクトの成功に責任を持つ仕事です。

開発は上手くいったけどプロジェクトは失敗したというのはあってはならない事ですし、責務を果たせていないと言えるでしょう。

エンジニアの延長上、プログラマSE→PL→PMといったキャリアステップの1部ではなく、エンジニア→責任者という役割の変更になるので、

これからPMを目指す人も今PMとして失敗している人も、このスタート位置を間違えないようにして欲しいと思います。

何よりも、エンジニアが疲弊しないプロダクト開発にできるかどうかはプロジェクトマネージャにかかっています。