エンパワーメント（権限委譲）

今日は、権限委譲について。


前に「PMは社長のようなものだ」と書きましたが、

経営でもチーム運営でも大事なのがこの「権限委譲」です。


ダメPMの典型は、「責任だけ押し付けて、権限は渡さない」です。


失敗するとメンバのせい。

でも、進め方やスケジュールなどを決めたり、指示をしたりするのはいつも自分。


それでは、メンバも萎縮して、いい仕事などできるわけがありません。


そうではなく、メンバに

「このチームはお前の好きなように運営していいぞ」

とか

「お前の好きなように設計してみろ」

などとある程度大きな部分を任せることが大事です。


ここで、注意は「権限委譲は丸投げではない」ということです。

任せても、知らん振りをしてはいけません。

きっちり状況を把握しておく必要があります。


権限を委譲することを怖がるPMもいます。

自分の仕事や存在価値が無くなってしまうように錯覚するからです。


しかし、権限を委譲するからこそPMが必要なのです。


こんな本があります。


高木 善之

地球大予測〈2〉オーケストラ指揮法


オーケストラは、プロの集団です。

そして、演奏をする際には、自分のパートの楽譜しか持っていないそうです。

それをまとめ上げて、全体で素晴らしいハーモニーを作り出すために指揮者が必要と

書いてありました。


PMも同じです。


任せるところはドンと任せ、各パートがうまく連携するようにリードする。

それがPMの仕事だと思います。

誠意あるPM

久しぶりの投稿です。


今日は、PMと誠意について書いてみたいと思います。


誠意がPMに必要とはどういうことか。


例えば、プロジェクトがスケジュールより3日遅延したとします。


この場合、

「顧客に報告して、リカバリプランを建てる」

というのが正しい方法だと思います。


が、たまにこれを顧客から隠そうとするPMがいます。


で、遅延に遅延を重ねた結果、隠し切れなくなって、

顧客に話したときには数週間の遅延になっていたりします。


すると、顧客はどうなるか。

当然、信頼感を失います。

そして、「任せておけない」と必要以上のプレッシャーをかけてきます。


そのプレッシャーを受けたPMは、

現場に数割増しのプレッシャーをかけることになります。


この結果、最も割を食うのは現場のエンジニアです。


「PMが隠してリカバると言ったのに、結局こうなってんじゃないか」

とストレスを貯めた状態で、プロジェクトをさらに加速させる。

そんなの、うまくいくはずがありません。


もう一例。


プロジェクトの後半に、定義した以外の要件が顧客から出てきました。


しかし、顧客は

「確かにAさんには要件に入れるように言ったはずだ」

と言っています。

Aさんに確認すると、果たしてそうでした。


しかし、PMは

「要件定義書に載っていないのだから、やる必要はない」

と言って、顧客と交渉し出しました。


現場では、交渉の間もちろん実装は進んでいません。

そして結局、交渉した結果、やはり要件漏れということで実装することに。


早めに手をつけていれば最小限に抑えられた遅延が、

交渉を行った結果、さらなる遅延を引き起こしてしまいました。


この2つの例は、必ずしも1つの原因から起きているわけではありません。


しかし、大きな問題の1つは

「PMが誠意ある対応をしなかった」

ことだと思います。


こういった態度は、顧客やメンバに必ず伝わります。

そして、信頼関係にヒビが入ります。


その結果、

顧客とコミュニケーションがうまく取れなくなったり、

メンバがモチベーションを落としたりと、

プロジェクトに悪い影響が出てしまいます。


PMは、信頼関係とモチベーションを維持するため、

誠意を持って、プロジェクトを運営していくことが大事だと思います。



続・PMはビジョンを描く

（昨日、投稿したつもりだった記事が投稿されていませんでしたので、書き直します。）


前回の記事に在外邦人さんから鋭い指摘をいただきました。

よって、今回も「ビジョン」について書いてみたいと思います。


前回の最後に、ビジョンの例として、


「お客様が使って仕事の効率が倍になるシステムを、納期の1ヶ月前に完成させる！」


というのを挙げました。


これは、ご指摘のとおり、ちょっと勢いに任せて書いてしまったところがあります。

反省しております。


ただ、なぜこれを書いたか、など、色々と補足させてください。


まず、ビジョンは、プロジェクトメンバの脳にピン！とイメージできるものでなければいけません。


イメージが湧かないビジョンを掲げても、メンバのモチベーションが上がるどころか、PMの求心力に悪影響が出かねません。


この観点からすると、ご指摘のとおり、「仕事の効率が倍になる」はイメージしにくいかもしれませんね。


そして、ビジョンは、プロジェクトによって、全く異なるものです。


あるプロジェクトで絶大な効果を発揮したビジョンを、別のプロジェクトに持っていっても、全く意味が無いと思います。


よって、ビジョンは押し付けではなく、最終的にメンバの合意が取れたものでなければいけないと考えます。


もちろん、最初の案をメンバから出させるようでは、PMの存在意義が薄くなってしまいますので、叩き台くらいは作る必要があるでしょう。


しかし、最後はメンバ全員が賛成してくれるようなビジョンを決めるのが理想です。


一方、ビジョンは、ある程度インパクトがあって、ハードルが高いものである必要があります。


ビジョンによって、メンバのチャレンジ精神を喚起し、奮い立たせなければいけません。


通り一遍で何の感想も持たないようなものや、すぐにクリアできそうなものでは、ビジョンを掲げる意味がなくなってしまいます。


あと、ビジョンに数字を入れる必要は必ずしもないと思います。


数字を入れたものは、「目標」と呼んでビジョンと別に管理した方がよいでしょう。


数字は、環境の変化などで変えなければいけない局面が出てくる可能性があります。


しかし、ビジョンはプロジェクトが続く限りは、不変であるべきです。


（プロジェクト終了の定義も、事前にしておくべきだと思います。

これについては、また別の機会に書きます。）


最後に。


>>在外邦人さん


また色々とご指摘下さい。

PMはビジョンを描く

さて、今日からは「PMに必要なもの」について考えてみたいと思います。


もちろん、管理能力とか管理ノウハウは、あって当然。

前回書いたように、「PMは社長」なのですから、チームを経営しなければいけません。


その1つ目として、今日は「ビジョン」を挙げます。


「プロジェクトには、ビジョンが必要」というのは、よく言われていると思います。


しかし、その「ビジョン」の内容が狭く捉えられていると感じます。


例えば、


「このプロジェクトの納期は、xxxx年x月だ」


これは目標であって、ビジョンではありません。


「このシステムは、こんな構成で、それぞれがこんな処理をする」


これは設計であって、ビジョンではありません。


ここで、「ビジョン」の定義。


「ビジョン」とは、

「プロジェクト活動内で判断をする時に、その大前提となるもの」

「そのビジョンに向かって、メンバが一丸となれるもの」

です。


つまり、


･そのシステムをどのようなものにしたいか

･プロジェクトをどのように運営していくのか

･何を優先しなければいけないのか


こういったことがビジョンには含まれている必要があります。


「プロジェクトが成功した時の姿」とも言えるかもしれません。

その姿を描けずに、プロジェクトの成功はありえないのです。


では、ビジョンの一例。


「お客様が使って仕事の効率が倍になるシステムを、納期の1ヶ月前に完成させる！」


どうですか。燃えてきませんか。

PMに必要なもの

今日からは、「PMに必要なもの」について考えていきたいと思います。


前回書いたとおり、PMは数字の管理だけやっていていいわけではないと思います。


以前、@ITにこんな記事がありました。


「プロジェクトマネージャは社長」


その記事には、こんなことが書かれていました。


つまり、プロジェクトを1つの企業と考えると、プロジェクトマネージャは経営者なのである。プロジェクトマネージャとは、決して進ちょくを管理するだけの人ではなく、要員とお金の管理をするだけでもない。経営者の意識を持ちプロジェクトを成功に導く、それが真のプロジェクトマネージャの姿であると筆者は考えている。


そのとおりだと思います。


経営者と同じマインドで、経営方針や部下のモチベーションなどを長期的に考えて、プロジェクトを「経営」していく。


PMには、そういったことが求められると思います。


ここで、数字の管理以外に、私がPMに必要だと思っていることを挙げます。


（1）ビジョン

（2）リーダーシップ

（3）動機付け

（4）権限委譲

（5）誠意


これらについて、明日以降詳しく書いていきたいと思います。

今のプロジェクト管理はここがおかしい

今まで、プロジェクトが遅れる理由を見てきました。


ここで、私の立場を明らかにしておきたいと思います。


現在、「プロジェクト管理」には様々な手法やツールが提供されています。


しかし、そこで管理すべきとされているものとは。


･スケジュール管理

･進捗管理

･リソース管理

･コスト管理

･品質管理

･変更管理

･リスク管理


もちろん、これ以外にもありますが、主に語られるのはこのようなものです。


これらは、当然管理されるべきものです。

しかし、このような数字や書類上の管理だけでは、不十分だと私は思っています。


･どのような開発手法を採用するか

･どのようにメンバのモチベーションを上げるか


この2つも同じくらい重要だと思っています。


しかし、このあたりはプロジェクトマネージャの裁量に委ねられています。


SEからすると、たまたま自分の属したプロジェクトのPMが意識が高ければラッキー。

そうでなければ、デスマーチの可能性が高いということになります。


これでは、SEはいつまで経っても楽になりません。


そこで、プロジェクトマネージャはどうあるべきか。

そして、今後採用すべき開発手法は何か。

さらに、どのようにメンバのモチベーションを上げるか。


最後に、どうしたらプロジェクトマネージャ依存から脱け出せるか。


これらについて、今後考えていきたいと思っています。

学生症候群＆エンジニア症候群

最後に、始めに挙げた理由以外の「プロジェクトが遅れる理由」を紹介しておきましょう。


まず、「学生症候群」。


これは、あるタスクをプロジェクトメンバが担当したとします。


その期限は、バッファを入れて5日後。

でも、頑張れば3日で終わりそう。


そんな場合、そのメンバはいつそのタスクを（真剣に）始めるか。


答えは、そう。3日目からです。


学生の時の「テスト勉強」に似てますね。

ギリギリにならないと始めない。


次に、「エンジニア症候群」。


これは、例えばメンバが前出のタスクを初日から真剣にこなして、

3日目で完遂したとします。


では、彼はPMにそのことを報告するでしょうか。


答えは「No」です。


ここで、彼がプログラマであれば、自分の書いたプログラムをより完璧なものにしたいと考えます。

そして、ロジックをいじったり、度を越えた異常系テストを行い、結局そのタスクが終わるのは5日目になります。


これが、「エンジニア症候群」です。


これらの理由で、各タスクはバッファを組み込んであるにもかかわらず、

期限目いっぱいまで作業に使われます。

そして、何らかの理由であるタスクが遅れると、それはすなわちプロジェクトの遅延に直結するのです。


このあたりの考え方は、

「クリティカルチェーン」

「ザ・キャッシュマシーン」

の両書に詳しく書かれていますので、ご参照下さい。


E・ゴールドラット, 三本木 亮
クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
リチャード・クラフォルツ, アレックス・クラークマン, 三本木 亮
ザ・キャッシュマシーン

メンバが離脱する

プロジェクトが遅れる理由。

最後は「メンバの離脱」です。


これについては、直接的な理由ではないと考えています。


つまり、メンバが離脱する原因があったのだと思います。


もちろん、病気や怪我、女性であれば結婚や出産など、

突発的な理由はあるかもしれませんが、ケースとしては稀でしょう。


それよりも、


･残業や徹夜が多くなったことによる肉体的疲労

･プレッシャーによる精神的ダメージ


などが原因となっているケースがほとんどだと思います。


つまり、うまく運営されているプロジェクトでは、このような問題が発生することはほぼないんじゃないでしょうか。

エンジニアの質が悪い

プロジェクトが遅れる理由。

今日は「エンジニアの質」について、です。


エンジニアといっても、社員か協力会社かによって分かれると思います。


協力会社の場合。

単価をケチった結果、力量の低いプログラマがアサインされてしまった。

というケースがありますよね。


ここで重要になるのが、メンバ選定の判断基準です。

月数万円をケチった結果、最終的にプロジェクトが遅れてしまうと、この損失は数倍～数十倍になります。

そのリスクを考えた場合、赤字にならない範囲で、ある程度単価が高くても優秀なプログラマを確保する必要があります。


単価が高いのに、力量が低ければ･･･それはもう交代してもらうしかないですね。


社員の場合。

単純に「力量が低い」と言ってしまうのは問題があります。


社員を育成し、その能力を最大限に引き出すのも、PMの重要な仕事です。

それをやらないで、書類上の管理しかしてないのに、「能力が低い」と言う。

これは、「自分は怠慢だ」「自分の能力が低い」と言っているのに等しいのです。

（もし可能なら、協力会社も教育できるとベストですね。）


教育したのに、仕事の質が悪ければ･･･それはもう交代してもらうしかないですね。


「エンジニアの質が悪い」という愚痴。

これを言う前に、それを改善する努力をする必要があります。