敏腕PMブログ

皆さん、山本五十六さんってご存知ですか？
昔の海軍の軍人さんなのですが、以下の有名な言葉を残しています。
「やってみせ　言って聞かせて　させてみせ　ほめてやらねば　人は動かじ」

確かに口だけのリーダーの言葉なんて聞かない人が多いでしょう。
手本を見せられて初めてリーダーを信頼し、自分もやる気になると思います。
ポイントは、「ほめてやらねば」ですね。
誰だってほめられたいものです。

プロジェクトマネージャーのようにメンバーを統率する立場になると、
本当に人を動かすのは難しいなー
と思うようになります。

自分がメンバー時代には気が付かなかった、リーダーの苦労も
身にしみて分かるものです。
「あのときあのリーダーも大変だったんだろうなー。」
という感想を持つことになります。

①まず自分がやる
②やり方をメンバーに伝える
③メンバーができたときはほめる
プロジェクトマネージャーは①～③をいつも意識すべきですね。
②は多いと思うのですが、まず①です。そして③も忘れずに。

—–

最近お客様やプロジェクトメンバーをはじめ、
いろんな人から質問をされることが多いのですが、
いつも相手に確認したいと思うのが
「どこまで理解できているのか？」
という部分です。

全体を10とすると、9まで理解できていてあと残り１なのか、
全く理解できてなくて0の段階なのか、
それをまず説明してほしいなーと思います。

それによって言い回しや説明にかける時間、
そのときに説明したほうがいいのか、別の時間を確保して
説明の機会を設けたほうがいいのか、
いろんなパターンがあります。

あまりにも質問の数が多いと、個別に回答するのが
煩雑になるので「質問確認会」
を開催する場合もあります。

「何を知りたいのか」はだいたい僕も質問されたら分かるのですが、
「どこまで理解できているのか」は言われないと分かりません。

質問をするときは相手の時間をもらうので、
「自分が理解できている範囲をまず伝え、その後に質問をする」
を心がけましょう。

—

社会人になってからマネジメントに関わる本をいろいろと読みましたが、
中でもドラッカーさんはやっぱりいいこと言うなーと感じます。
企業の内部で起こるあらゆる状況を的確に表現し、
読み手にいつも行動する指針を与えてくれます。

実は社会人１年目のときも読んだのですが、まーったく意味がわかりませんでした。
最近は自分がプロジェクトマネジメントにどっぷりなので、
現場で起こることと紐付けながら本を読むので、理解できる幅が大きく広がりました。

一番記憶に残ってかつ実感として共感できたものが、マネージャーの定義です。
「マネージャーには、 命令する権限 ではなく、 貢献する責任 がある」
というものです。

プロジェクトマネージャーは
メンバーに命令する権限なんてないのです。
メンバーと協力してプロジェクトの成功に貢献する責任があるのです。

マネジメントという言葉には、「管理」「権限」というイメージがあるかもしれませんが、
なかなか「貢献」という言葉は出てこないなーと思いました。

でもこれって本当に的を射た表現で、世の中のマネージャーには全て貢献の責任があります。
社会人になってメンバーと仕事をするようになると痛いほどよく分かります。
また、マネージャーの定義が間違って捉えられている場合が多いことにも気づきます。

「管理職」っていう言葉がだめなんでしょうね。
「貢献責任職」くらいがいいなと思います。
—

開発案件がスタートするときにいつも考えるのが、
・ウォーターフォールでいくか
・アジャイルでいくか
・それぞれの中間でいくか
という開発手法の部分です。

以前から「アジャイル開発」という言葉には罠があると考えていました。
その罠というのは、
「細かな改善を加えていくのでウォーターフォールに比べお客様満足の高いシステムができる」
というものです。（完全に主観ですが。。）

ただし、アジャイルで開発する成功パターンの必要条件というものも
僕の中で考えがあって、それは
・お客様の要望をプログラム実装イメージまで仕様を決める人間がすぐに落とせること
・開発者がお客様の業務要件まで深く理解してシステムを実装できること
・開発者が一般的な開発者と比較し、10倍以上の高い生産性を持っていること
です。

上記条件が揃わないと、
・永遠にお客様の要望を取り入れ続けるけどシステムは永遠に完成しない
というお客様にとっても、開発側にとっても、残念な結果をもたらすと思っています。

社内のエンジニアにそのような話をしたら、「アジャイル宣言」を教えてくれました。
-「人と人の対話」 を　「プロセスとツール」 より優先する
-「動作するソフトウェア」 を　「包括的なドキュメント」 より優先する
-「顧客との協調を」 を　「契約交渉」 より優先する
-「変化への対応を」 を　「計画の遂行」 より優先する

すごくまとまっていて、本当にそのとおりだー、という衝撃を受けました。
でもやっぱり、罠があるよなーと再認識しました。

—

お客様はプロジェクトメンバーがどれだけがんばっているのか、
というのはなかなか分からないものです。
働いている拠点が違っていたりして、WEB制作やシステム構築の現場の実態は
リアルには想像できないですから。

「メンバーが提供している価値をお客様へ最大限アピールする」
部分はプロマネの腕の見せ所と考えています。
実力以上にアピールする必要はありませんが、
正しく自分のチームを評価してもらうことは重要だと考えています。

たとえば、、
・お客様のためにメンバーが夜遅くまで対応をしていたり
・お客様からの要望を上回る結果をメンバーが出したり
・お客様のミスをメンバーが自発的にフォローしていたり
というような縁の下の力持ち的なメンバーって必ずいますよね。

その努力、がんばりってそのままにしておくとあまりお客様には
伝わらないものだと思っています。
そこはプロマネがきっちりメンバーのかげの努力を伝えられるように
ならないといけません。

メンバーにとってお客様からの感謝の声が一番のモチベーションの源泉です。

メンバーのがんばりをお客様へアピール
↓
お客様から「ありがとう」をたくさんもらう
↓
メンバーへお客様からの声をフィードバック
(もしくはお客様と交流する場をセッティング)

このサイクルを回し続けるとどんどんいいプロジェクトになります。
長期的な友好関係はこのようなサイクルから生まれます。

–

仕事を「やらない(Don’t)」のと「できない(Can’t)」は見た目には
分からなくても大きな違いがあります。

プロマネの立場からすると、
・できるけど“やらない人”には責任のある仕事を任せられない
・やりたくても“できない人”にはなんとかできる方法を教えたい
と考えます。

仕事を依頼した場合に、その人には十分な時間もあるし、能力もあるから
お願いしているのに、遠まわしに「やりたくない」オーラを感じることがあります。
できないではなく、自分が興味あることしかやらないタイプです。

一方、がんばっていろいろ調査して、試行錯誤しているんだけど、
「できない」場合もあります。
そんなときは手を差し伸べたくなります。

「やらない」と「できない」の大きな違いは、今後の成長度合いに大きく関わります。
幼い頃、親から「何でも残さず食べなさい」と教育された方は多いかと思いますが、
それと似ていて、「やらないと言わずに何でもやりなさい」とプロマネ視点では考えます。
それが本人の成長につながると思っているので。

–