プロジェクトマネジメントを初めてやる時に失敗する４つの勘違い
プロジェクトマネジメントをやろうとしている方もやりたいと思っている方も、初めてPMになった時必ずと言っていいほど躓く事があります。
PM系記事を見ると、ポイントを端的に並べているものが多いですが、実際にその通りにやったところで失敗するので、「今回はなぜ失敗するのか？」を
中心に書いてみたいと思います。その失敗するポイントをおさえる事で成功に近づけるはずです。
私はSIerでPMを長い事やっていましたが、下記４点を曖昧にしたものは必ず後で苦労するはめになっていました。
開発のプロジェクトマネジメントというと、開発のプロセス管理者のように感じられがちですが、プロジェクトマネジメントはプロジェクトのマネジメントが仕事になるので、プロジェクトの成功に責任を持つという大前提の勘違いがあると危険です。
１．プロジェクトの目的や目標は与えられるものだと思っていると失敗する
一般的なクライアント（社内だとなおさら）RFPが出てくることはまず無いと思います。
PMが明確にするのは、コストやスケジュール、ましてやクライアントの担当者が言っている”夢”のヒアリングではありません。
そもそも最初に出てきたプロジェクトの目的は概ね見当違いな事が多いです。
- 市場調査していない
- 思い付きで始まっている
- 途中から目的が変わったものが伝わってきている
- 担当者と決裁者の意見が擦り合っていない
などなど、紆余曲折してからPMの所に来るものなので、そのまま鵜呑みにして進めるとあとあと痛い目にあいます。
なので、最初に行う事はこのプロジェクトのオーナーが誰であるかです。
また、プロジェクト規模にもよりますが、否定権を持っているプロジェクトのオーナーと話せる状態になっていないとちゃぶ台返しにあったりします。
自身がプロジェクトマネジメントという役割で入るのであれば、先ずは誰が決裁権を持っているのかを把握する所から入ります。
次に、その決裁権を持ている人が（概ね忙しい）プロジェクトにどれほど関与するか把握しましょう。
忙しく、関与もあまりしないのに決裁権を持っているような状態はちゃぶ台返しが3回ぐらいあると思ってください。
その場合は、どこまではこちらで決めていいのかを擦り合わせます。
画面設計にまで口を出すけど忙しいのでたまに来ては文句を言って帰っていくようなパターンは絶対に上手くいきません。
決裁者が何を気にするのか、どこに重点を置いているのかが分かれば、そこだけ抜き出して決裁者に決めて貰う場所を用意すれば忙しい人も時間を取りやすくなりますし
こちらとしても、その点については合意が取れている前提で進められるので安心です。
２．人がたくさんいればプロジェクトが進むと勘違いしていると失敗する
人が増えれば増えるほど、情報共有が複雑になり、全体ミーティング後に個別ミーティングを開き、個別ミーティングを集めた評議会が開かれ…という事になりかねないです。
プロジェクトマネジメントをする場合、気を遣うのは人の配置です。
- 誰が何をいつまでにするのか（させるのか）
- 誰と何があれば、それは可能なのか
- 何と何が連結する必要があるのか
優秀な技術者をたまたまアサインできたとして、それで万事うまくいく事は決してありません。
優秀なエンジニアと評価されている人が、”何において優秀なのか”を知ってください。
良く忘れがちなのか、インフラ構成・デプロイ方法・アーキテクチャ選定・URIルール・データバックアップ方法を決め忘れる事です。
社内で優秀なエンジニアの中に、上記を包含して考えられる方がどれほどいるでしょうか？
フルスタックエンジニアに位置付けられた人にどれだけ上記の仕事をプロジェクト開始直後に振出ができているでしょうか？
言語選定・フレームワーク選定・DB選定辺りは結構把握できているのですが、上記はよくよく忘れた結果動き出しがぎこちなくなることがあります。
また、セキュリティの要件も初期の頃に握っておくべきでしょう。個人情報の取得があるからSSLにするといった安直なものではなく、
社内でどう活用されるのかも考えた場合、DB設計やインフラ設計・アーキテクチャにも関わってきます。
そして優秀な企画者がスケジュールを守るとは限らないという事も忘れないでおきましょう。
最上思考に捕らわれてリーンスタートアップが出来ない人や、ドッグフーディング開発が理解できない人もまだまだいます。
目的に応じて企画者側もスケジュール管理しないと何度でも最上に向けてやり直せると勘違いされてしまいますよ。
最後に、人がたくさんいても人はタスクを明確にされないと動きません。過剰に人が居ると人は役割を全うしなくても誰かがやるだろうという思考になります。
珍しく人が潤沢にいる場合は、全員にタスクを割り当てマイルストーンを設定し、忘れがちな非機能要件を見落とさずにいましょう。
３．プロジェクトマネジメント＝進捗管理と報告だと勘違いしていると失敗する
これは当たり前の話ですが、プロジェクトマネジメントというのは開発のスケジュールを立てたり、進捗確認をするのが仕事ではありません。
プロジェクトを成功する為に必要なプロセスとして進捗管理を行い、課題の早期発見をする為に行うものなので、それが仕事だと勘違いしないようにしてください。
進捗管理は期間的には長いですし、開発あるあるネタがたくさん転がっているので、殊更この辺にフォーカスを当て気味ですが、
実際にはプロジェクトマネジメントの仕事の大部分は開発前に8割がた終わっているもので、残りは進捗管理を行いながら適宜出てきた問題に対処する事になります。
また、プロジェクトで出てきた問題に対し即座に解決する能力が求められます。
要件定義・設計までは机上の空論に過ぎません。現場で初めて見える問題は大量にあります。
- 想定していた機能がフレームワークでは使いにくい
- ミドルと言語の相性が悪い
- 使おうと思っていたパッケージでは対応できない要件が増えた
- 出来上がった画面が重い
- 設計通りに作れない状況がある
- デザインが想定と違う
などなど。
開発が最高速度で開発を継続的に行う為に出てきた問題は片っ端から潰していく必要があります。
解決方法も多数あり、調整・交渉・選定変更・人員追加といった各種パラメータをチューニングする事で対処可能です。適宜使い分けをしましょう。
この時にさらに注意をするのであれば”ゼロサム交渉はしない”という事です。
「これをやると、これは出来ない」という交渉は誰でも出来る安直で頭の悪い交渉方法です。※だって言われなくたってわかるでしょう。
交渉の相手方は探ってきているのです。あなたの力量を。十分に勘案し最大限リスクを抑えながら疲弊し続けない交渉術を身に付けましょう。
また、解決方法次第では、エンジニアからも信頼され、決裁者からも信頼される事があります。
複数回良い解決方法が見つけられると、権限が増えたり交渉せずとも言い値で決裁者を動かす事が出来るスキルも身に着けられるでしょう。
４．メンバーが想定通りに動くと勘違いしていると失敗する
配置されたメンバーの力量を測り、適切な配置をし、進捗管理を行っても上手くいかない事があります。
ここがプロジェクトの最も難しいポイントで、人をコントロールするのは難しいという事かなと。
- 進捗報告は虚偽が含まれる
- 人は楽天的に考えがち
- 例えば、自分が作業に入る時には必ず事前のデータがあり、選考しているメソッドや共通メソッドが用意されているものだと仮定して動きます。
- 事前にCPM図を用意するなど相互関係をはっきりさせる事と、テストデータの用意など作業に必要な作業時間をスケジュールに盛り込めるかどうかがカギになります。
- 1日8時間20日働かない
- 風邪をひく
- モチベーションが上がらない
- 他人の質問や問題に引っ張られる
- 人は何かにつけて予定通りに進めないものです。
ざっと４点とは言ったものの、ふたを開けるとなかなか面倒な事が多く、とはいえこの辺はしっかり押さえておかないとプロジェクトは成功できません。
もちろんこれらが完璧であっても失敗する事やデスマーチになる事もあります。
それでも、正しく開発する為に重要なポイントだと思うので、しっかり押さえておくと良いでしょう。
最初に書きましたが、プロジェクトマネジメントはプロジェクトの成功に責任を持つ仕事です。
開発は上手くいったけどプロジェクトは失敗したというのはあってはならない事ですし、責務を果たせていないと言えるでしょう。
エンジニアの延長上、プログラマ→SE→PL→PMといったキャリアステップの1部ではなく、エンジニア→責任者という役割の変更になるので、
これからPMを目指す人も今PMとして失敗している人も、このスタート位置を間違えないようにして欲しいと思います。
何よりも、エンジニアが疲弊しないプロダクト開発にできるかどうかはプロジェクトマネージャにかかっています。
CPM（クリティカルパスメソッド）について
作って満足しがちなCPM
CPM（クリティカルパスメソッド）というのをご存知でしょうか？
エンジニアでリーダー経験があると分かると思いますが、頭の中でやっている人多いですよね？
この機能を作ってからこれを作ろう。これは時間が空いた時にやろう。
みたいなものを図式化したものになります。
その際に、最短経路と最遅経路を考え、クリティカルパスになるものをブラさないように管理する方法です。
もう少し細かく言うと、ウィークリンクなどもあり、「これとあれができたら、ここで結合」といった内容は
2軸が交差する点なので気を付けるポイントだねーというのが分かります。
CPMを作るメリット
大きくは２点。
- スケジュールの中の重要度が見える為、スケジュール調整がしやすい。頭の整理がしやすい。
この辺はまあ見てわかる通り、遅れちゃいけないものといつやってもいいものがハッキリするので、
毎度毎度頭の整理をしなくても見れば分かるようになる。
- 共通認識が取りやすい
メンバーにお願いする時にもCPMを共有しておくことで、自身が作業するに辺り、前に誰がいて、後ろに誰がいるのか分かります。
このおかげで「まあ1日ぐらい遅れても…」という甘えが使えなくなりますし、相互協力体制が築きやすいというのがあります。
また、危険ポイントの後ろの作業者に強い人を入れておくことで、後ろの人（責任感が強く能力が高い）は自分の作業に遅れが出ないように
前の人の作業に気を配ります。
そうする事で自身の作業に手戻りや不明点が無いようにする為なわけですが、自動的に協力体制が組めます。
CPMは作って終わりではない
プロジェクトを進めて行くとクリティカルパスが変わる事や大幅に変更される事もあるでしょう。
一度作ったCPMを変えられないものだと思っていませんか？それだとプロジェクトは成功しないでしょう。
プロジェクトは生き物です。期間によって使える交渉術も変わってきます。
最初はコスト削減の為に人員追加などもってのほかと言われていても、作業中に事業成長が見込める事や市場ニーズの高まりが見えると
決裁者はブーストしたがります。
そういうタイミングでしっかり交渉できれば、人員追加ができ、クリティカルパスを（多少コストが掛かっても）折る事ができます。
また、あまりプロジェクトを回したことが無いエンジニアがPMになると、A→B→C→Dというwebシステムの流れをそのままCPMにしてしまいますが、
実際にはデータの種類で同時に進められるものデータの相互関係や機能の被り方によって同時並行開発が可能な部分はままあります。
CPMを使って共通認識とし、相互協力体制を築きやすいプロジェクトにできます。
プロジェクトマネジメントを牛丼に例えるならば
そう、それは注文を受けてから提供するまでの全てを管理する業務に等しい。
できれば深夜の牛丼屋に入って確認して頂けると分かるが、フロアリーダーが全ての注文を把握し、メンバー（海外の）に指示を出しつつ、
自らは難易度の高いメニュー調理をし、時にはテーブルを拭いたり、水が足りないか確認したりと目まぐるしく動いているだろう。
だれも、椅子に座り報告を待ちお金の管理だけをしている人はいない。
現場の生産効率を高め続けるのがプロジェクトマネジメントという職種なのだから。
行動力は一つのアビリティ
プロジェクトの立ち上がりから、開発前半戦に向けて少人数で始める為、そこでのエンジニアスキルが重要になる。
プロジェクトマネジメントするものが、ベース開発をする事も往々にしてあるが、この時に起こした行動を、その後も続けた場合立ち行かなくなる。
プロジェクトが中盤に差し掛かる前、できるだけ前半戦の時に、プロジェクトマネジメントは開発から抜け、管理（人・コト）にシフトし、
非機能要件や要件の変更に柔軟に対応できるよう準備をするべきだ。
行動力＝開発力ではなく、行動力はフェーズに合わせて動き方を変える力である。
重要なのは対人スキル
プロジェクトマネージャーはWBS/ガントチャート、EVM、CPMなど管理手法を使い、当初見積もり計画の妥当性と進捗把握をし続ける仕事だと思っているだろうか？
プロジェクトマネジメントで重要なのは、個・チーム・組織において役割を明確化し、ビジョンを統一し、メンバーの能力を最大限引き出すことにある。
その為に出来るだけ管理業務を楽にする為、各種ツール群があるだけである。
特に、リソースの配置や役割明確化などにおいて、卓越した対人スキルが求められる。
小さいプロジェクトであれば、強いエンジニアが引っ張るという所謂プロジェクトリーダー的な役割さえあれば、システム基盤開発からプロダクトを載せる所まで一気通貫で行う事が出来る。
スタートアップのCTOがプロジェクトマネジメントしていると豪語するのは、本質的な役割自体が「スタートアップ」というものに包まれ、メンバーも盲目的に動き出すからであって、役割を担っていないからである。
これが大規模になればなる程、先行きの不透明さやビジョン浸透などに力を注ぎ一致団結した状態をキープする事が重要になる。
プロダクトマネジメントとの棲み分け
企業によっても違うと思うが、事業部があるような会社の場合、企画職・営業職からプロダクトマネージャになる事が多いのではないだろうか。
それは、プロダクトマネージャが「製品ライン」「顧客満足」「利益」に責任を持つ仕事を担っており、このエントリーでいうプロジェクトマネージャは
あくまでもエンジニアを束ねたプロジェクトマネジメントという位置づけにしている。
プロジェクトには期間と期限があり、プロダクトを統括する人は、マーケット市場・顧客・自社優位性などからいつ何をリリースすべきかを設計する。
また、プロダクト全般における、運用設計・営業・デザインなど幅広い事が多い。
一方、エンジニアのプロジェクトマネージメントは、作るべきものを期間・期限内でいかに効率よく作り上げるかに注力する。
では、プロジェクトマネージメントは、市場や顧客のニーズを知らなくてよいのだろうか？
優れたプロジェクトマネージャは、プロダクトマネジメントの領域も戦う事が多い。
なぜなら、プロジェクトの出来栄えがプロダクトの生命線であり、プロダクト＝プロジェクトになる事が多いからである。
また、有益な情報は常に現場から吸い上げる必要があるとするならば、プロジェクトマネジメントが市場を知らずに答える事はできない。
企画立案され、要件がほぼ決まった状態から入るプロジェクトマネージャは、単に上流SEでしかなく、そこにエンジニアの進行管理を付け加えただけである。
■
開発のプロジェクトマネジメントという職種を希望するに辺り、いくつかのポイントがある
