敏腕PMブログ

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

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

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

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

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

—–

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

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

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

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

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

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

—

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

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

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

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

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

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

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

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

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

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

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

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

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

—

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

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

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

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

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

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

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

–

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

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

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

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

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

–

やさしさには
①甘いやさしさ
②厳しいやさしさ
の２つがあると思っています。

たとえ話で説明します。
幼稚園の運動会でかけっこの途中で園児が転んだとします。
園児が自分ひとりでは立ち上がれず、ワンワン泣いているときに
①すぐに走っていって助けてあげる保母さん
②自分の力でゴールまで走りきってほしいと思って助けてあげない保母さん
前者は甘いやさしさで後者は厳しいやさしさだと思います。

プロジェクトメンバーが困っているときに、
すぐに助言をして解決案を出すのは甘いやさしさ、
自分の頭で考えて解決案を出してもらい、わざと助言しないのが厳しいやさしさ、
だと思っています。

社内で気難しいと言われている人が、本当は一番やさしさのあふれた人だったりします。
プロジェクトマネージャーにとってやさしさは必要不可欠なものなのですが、
その使い方には気をつける必要があります。

–

以前メンバーからこんな悩みを相談されたことがあります。
「どの選択をするのが正しいか分からないんです」
その悩みの内容がなんだったか忘れてしまったのですが、
僕が聞いたときも「そりゃわからんわ」という選択でした。

というのも、どの選択が正しいかなんて、その時点では分からないものだと思うのです。
・どの会社に入るのか
・ばりばりエンジニアを突き進むのか、マネジメントの道を歩むのか
・起業するのか、社員のままでいるのか
これらの選択に対し「正しい」答えはなくて、「正しい選択だったことにする」努力はできます。

新卒採用のときに学生の方にはよく伝えるのですが、
入社する会社を決めたときには、
・自分の決断に責任と自信を持つこと
と伝えています。
その決断が正しかったという人生を歩んでほしいので。
エスキュービズムへの入社を決めた人にも、残念ながら辞退された方にも
僕は同じことを思います。

正しい選択なんて誰もわからないので、
選択が正しかった、と言えるように努力する。
これが今日伝えたかったことです。

–

すごーく知識が豊富で頭の回転が速い人と話をすると、
こっちがついていけなくて、「？？？？」となることがあります。
「あー、理解できなくてごめんなさい」と感じちゃいます。

でも自分も知らず知らずのうちに伝えたいことだけ
伝えて終わっていて、相手は「？？？？」状態のことが
あるかもなー、とも思います。

誰でも自分が得意な領域と不得意な領域があるので、
分からない（理解できない）状態というのは当然あると思っていて、
それは伝える側にも責任があると思う今日この頃です。

「何で分からないの？」という姿勢ではなく、
相手が「分からないことを分かる(理解する)」

自分が分からない側になることもあるので、
そのときの気持ちを忘れずにいきたいと思います。

もうこの歳になるといきなり天才にはなれないですから。
分からない自分のことを分かる、ってのも大切です。

–

今日は具体的なメンバーマネジメントのお話です。

例えばプロジェクトメンバーが複数のタスクを抱えていて、
全ての期限が今週末だとします。

僕はそのメンバーの進捗を確認するときに、わざと今取り掛かっていない
他のタスクに関して、
「あのタスク今どうなってる？」
と質問をすることがあります。

その意図は「全体を見てタスクを進めているか」を確認するためです。
もしメンバーが、
今取り掛かっていないタスクを気にかけながら、進めているのであれば、
全体が見えているのでプロジェクトマネージャーとしては安心です。
質問に対して、「あっ、忘れてました！」となるのは危険です。

２つの仕事(A,B)がある場合に途中経過として、
A:100%,B:0%の状態よりも
A:50%,B:50%の状態のほうが望ましいと思ってます。
プロマネの立場としてはゴールまでの計算をするときに、0%というのは
リスクが多すぎて怖いものです。

前者の状態が多い人はシングルスレッドタイプ、
後者が多い人はマルチスレッドタイプと呼ぶことに
していますが、一緒に仕事をしているとどちらのタイプにメンバーが属しているのかが
見えるようになります。

シングルスレッドの人に対しては、わざと他のタスクを意識してもらって、
マルチスレッドの方向へ誘導する、というマネジメントは頻繁に行っています。

—