敏腕PMブログ

昨年の流行語で ”KY(空気読めない)”
というのがありました。

否定語が流行語になるのは残念だなー。
どうせなら肯定的な言葉が流行すればいいのに。
と思っていました。

プロジェクトマネジメントにおいて、空気を読むことは
非常に重要です。

・会議の場でお客様の顔を見て、満足度を察知する
・開発メンバーの顔を見て、ストレス度合いを見抜く

論理的思考力とかコミュニケーション能力については、
マネジメントの教科書にたくさん載っているのですが、
・空気を読む
・気が利く
というのは、なかなか文章による説明が難しく、
これまで語られてこなかったと感じています。

でもこういったほんのちょっとの気遣いが、プロジェクトの成功を
左右するといっても過言ではありません。

気が利くプロジェクトマネージャーは、お客様への説明資料を作るときに
・重要ポイントは太字にする
・前回からの変更点は赤字にする
・文字だけでなく図や絵を入れる

気が利くエンジニアは、コーディングをするときに
・プログラム行数が長い場合はクラス(メソッド)に切り出す
・メンテナンス性を考えてコメントを付ける
・仕様の抜け漏れは事前に設計書で確認する

“少しの気遣い大きな違い”です。
空気読めない（KY）よりも、気が利く（KK）が
流行語になればいいですね。

–

「この会議は本当に必要か？」
この問いは会議の質を意識するために非常に重要です。

・お客様との定例会議
・社内メンバーとの情報共有会議
・社外デザイナーとの打合せ
・インフラベンダーとの打合せ
等々、プロジェクトマネージャーは色んな会議に呼ばれます。
さらに複数のプロジェクトに関わっていると、これが２倍、３倍になっていきます。

週1回の定例会議がある場合でも、僕はよくお客様やメンバーに、
「来週の会議は無しにしましょう」と提案します。

それは会議が面倒くさいのではなく、議題が少ないからです。
お客様も各人が貴重な時間を割いて会議に参加されます。
メールや電話で終わらせるほうがお互いに有意義だと思います。

最近の僕の挑戦は、
1時間の会議内容を、1本のメールに込められないか？
です。

これをやりだすと、会議に参加するより自分の席でメールを書いているときが
一番仕事がはかどります。（プロジェクトが前に進んでいると感じます）
複数の人とほぼタイムラグなくやり取りができ、文章によるコミュニケーションなので、
記録にも残り、言った言わないでもめることもありません。

将来的には1度もお客さんと対面式の会議は行わず、
要望を全て満たす完璧なシステムを作ってみようと
ひそかに野望を抱いています。

”会議室を予約するより会議質を考えることが仕事”
明日から会議室のドアに張り紙をしてはいかがでしょう？

–

以前こんな言葉を聞きました。
「提案書を書いたことがないから、書けないです。」
せっかく上司から提案書作成を依頼されているのに、
自分からチャンスを逃しています。

たぶん自信がなくて、自分が書いても良いものが書けない
といった不安があるのでしょうが、
上司からするとそんなことどうでもよい。
新しい仕事を任せて成長の機会を与えています。

仮にミスをしてもそれほど大きいことはありません。
大抵上司はリスクヘッジしているものです。
できなくても提案書は誰かが書きます。

どこかでこんな言葉を聞きました。
“自分が克服できないレベルの課題は与えられない”
言い方を変えると、今抱えている課題は必ず解決できる
レベルのものである。

エンジニアにはエンジニアが解決すべき課題が与えられ、
プロマネにはプロマネが解決すべき課題が与えられ、
社長には社長が解決すべき課題が与えられます。

エンジニアにいきなり経営戦略を考える、という社長が
取組むべき課題は与えられません。

“経験がない、だからやらない”
ではなく
“経験がない、だからやる”

個人や企業の成長において、大切なマインドだと思います。

–

守・破・離（しゅ・は・り）とは、江戸時代の茶匠川上不白の言葉だそうです。
武道や伝統芸能の世界でよく聞く言葉です。

◆守破離の定義
守⇒「師匠の教え、型を守り、習熟すること」
破⇒「師匠の教えを完璧にマスターした後、ほかの流 派の教えを請い、習熟すること」
離⇒「自分の体の中でいろいろな流派を熟成させた結果、自分なりの流派を作り出すこと」

昨日書いた ”はじめはモノマネから” は、「守」にあたります。
プロジェクトマネージャーになるまでの成長過程も、守・破・離です。

◆プロマネに至る守・破・離
守⇒「他人のモノマネをしてスキルを積んでいく段階」
破⇒「モノマネしたスキルを応用して自分で試行錯誤する段階」
離⇒「試行錯誤した結果、自分に最適なマネジメント方法を確立する段階」

“はじめはモノマネから” ですが、 “いつまでもモノマネ” ではダメです。
師匠の技を盗んだ後は、師匠を追い越し、自立しなければならないのです。

「教えて下さい」の質問フェーズから、
「この方法はどうですか？」の提案フェーズに移り
「自分で考えてやってみます」の自立フェーズに至る

僕も昔は先輩プロジェクトマネージャーから、
「早く成長してくれ。同じ目線でプロジェクトの課題に対して議論したい」
と言われていました。

武道も伝統芸能もプロジェクトマネジメントも、根底に流れる思想は似ていますね。

–

「学ぶ」の語源って知ってます？
「真似ぶ（まねぶ）」なんです。

プロジェクトマネジメントスキルを付けるには、
“モノマネ力”がものすごく必要だと思います。

スポーツ選手や歌手は、キャリアに関係なくある程度の
素質やセンスがものを言う世界で、若手がベテランを追い越す
シーンがしばしば見受けられます。
仕事で言うと営業職というのも上記に近いですね。

これに対しマネジメントというのは、コツコツと知識やスキルを
積み上げていく職人系の分野だと思います。
新人は上司の職人芸を盗まなければなりません。
若いころはまずは毎日モノマネをすればいいんです。

・時間管理術
・顧客折衝の方法
・読んでいる本
・ユーモアのセンス
等々、上司のマネできる部分はどんどんマネして自分のものにしていく。

「上司と自分は仕事の内容が違うから」
なんて言っている暇はありません。
1年も経つと会社には新人が入ってきますから、自分もその日から上司です。

若手料理人の仕事が最初は皿洗いでも、
お店が閉まってから大将の包丁さばきをまねして
食材切っている人は、成長スピードが違うでしょう。

・プログラマー時代に先輩エンジニアのソースコードをマネする
・プログラマー時代に先輩SEの設計書を見て研究する
・SE時代にPMがお客さんと交渉する会議に同席させてもらう

モノマネ力 = 吸収力 です。
先輩、お客様、同僚からスキルをビュッフェ形式でモノマネしていく。
プロジェクトマネジメントスキルの身につけ方は、
はじめはモノマネからでよいと思います。

–

プロジェクトマネージャーはいつもプロジェクトの状況を
敏感に察知・判断しなければなりません。

例えば週1回の定例ミーティングで各メンバーから
進捗状況を報告してもらう、というのも状況を判断する１つの手段です。

でも進捗がよくないと、リスクや遅れている原因を隠してしまうことがあるんですよね。
故意ではなく、自然とそうなるものです。

そこで、僕がやっている状況判断のヒントをご紹介します。
主に設計フェーズではこれをよく使いますね。
それは、”メンバーからの質問内容で状況判断する” というものです。

設計中に疑問が出ると、僕によく質問が来るのですが、
最初のほうは本当の初歩の初歩レベルの質問が来ます。

だんだん仕様が分かってくると、中級レベルの質問に変わります。
僕としては、「お！結構いいところまで理解しているな」
と思うわけです。

最後のテストフェーズなんかになると、僕が気づかないレベルくらいの
超上級な質問が飛んでくることがあります。
僕としては、「ここまで深い質問するんだから、モジュールの品質も安心だな」
となるわけです。

実際に質問が高度な人と、初級な人のモジュール品質は、その通りの差がつきます。
自分でソースコードを見たり、テストをするといった時間がなかなか取れなくても、
質問内容から大体のシステムの品質は察知できるものです。
なのでテコ入れが必要な部分もある程度アタリをつけられます。

大事なのは、
・メンバーから質問しやすい環境を作っておくこと
・積極的に質問させること
ですね。
対面、メール、電話等を使って、いつでも質問が集まる環境作りは、
プロジェクトマネージャーの大事な仕事だと思っています。

いつも忙しそう、つらそうな雰囲気を出しているプロマネの方は、
質問がとてもし辛いのでご注意を。

–

昨日は“仕事を依頼するときにはまず目的から伝える”という
ことを書きました。

今日は立場が逆の場合で、
仕事を依頼されるときの心がけです。

プロジェクトマネージャーはお客様から仕事を依頼されます。
プロジェクトメンバーはプロジェクトマネージャーから仕事を依頼されます。

依頼された仕事の結果を報告したら
「依頼したものとは違うんだよねー」
と言われたこと、ありませんか？

依頼されるほうにも原因があると思っています。
依頼される側の心がけを書いておきます。

①目的の確認
⇒依頼されるほうからも目的を確認するようにしましょう。
「目的は何ですか？」という質問ではなく、
「目的はXXXですよね？」くらいがトゲがなくていいですね。

②期限の確認
⇒依頼するほうは急いでいる場合もあるので、
「いつまでに仕上げればよいですか？」と聞きましょう。
1時間後、1日後、1週間後くらいのレベルでOKです。

③Outputイメージの確認
⇒これが一番大事なのですが、仕事を依頼された瞬間にOutputをできるだけイメージしましょう。
ドキュメント、プログラム、デザイン何を依頼されても、最終的には
・どのような形式で
・どのようなレベルで
その仕事を完了させればよいのかを確認します。
紙やホワイトボードを使ってより具体的にOutputイメージの刷り合わせを行うのも効果的です。

実際の作業に入ってから仕事が完了するまでに、2回は報告すると良いですね。

・完成度40%程度で1回目の確認
⇒これは方向性がずれていないかの確認です。
仕事の依頼者へ安心感を与えることもできます。

・完成度80%程度で2回目の確認
⇒これは最終仕上げ前の確認です。
仕事の依頼者から細かな要望が聞きだせると共に、
クオリティを一気に引き上げることができます。

いかがでしょう？
「依頼したものとは違うんだよねー」
と言われる割合が減れば幸いです。

–