敏腕PMブログ

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

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

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

–

プロジェクトマネージャーの仕事は基本的にはマネジメントですので、
設計や開発といった実作業はメンバーに依頼することになります。

ただ、この依頼の仕方によってプロジェクトの状況は大きく左右されます。
依頼するスキルとでも呼びましょうか。

僕も毎日誰かに仕事を依頼してますが、たまに依頼の方法を失敗することがあります。
具体的な失敗例としては、
・メールで依頼した結果、了解を伝える返信メールが見当違いのものになっていた
が代表例ですね。

相手は了解したつもりなのですが、こちらが依頼したこととは全く違うことを了解してしまっています。
すぐメールの返信が来る場合にはそれほど被害が大きくないので問題はないのですが、
作業に入ってしまった後のメールが見当違いの場合はもったいないですね。

こういうときは依頼の仕方が悪かったといつも自省します。
大抵の場合、依頼するときの言葉が足りていないんですね。

ではこういう状況が起こらないようにするためにはどうすればよいのでしょう？
言葉を補って丁寧に伝える、という方法もあるのですが、時間は有限です。
メールで依頼内容を最初から最後まで詳しく書く時間がいつもあるとは限りません。

そこで、僕の場合は「目的を伝える」ことを意識しています。
”なぜこの依頼をするのか”を最初に伝えます。
そうすると依頼したほうとされたほうの距離はぐっと近くなります。

「日報を書いて」と漠然と依頼するより
「課題と進捗を管理したいから日報を書いて」と依頼したほうが、
日報を書くほうにとっては内容を決めやすいのです。

“仕事を依頼するときにはまず目的から伝える”
小さな心がけですが、大きな結果の差を生むこともあります。

–

パレートの法則ってご存知ですか？
80対20の法則と言うこともあります。

例えば、
・売上の8割は、全従業員のうちの2割で生み出している
・仕事の成果の80％は、費やした時間の20％から生まれる
のように

“重要な20%が結果の80%を占める”という法則です。
意外にこれがプロジェクトマネジメントに生かせるんです。

例えば要件定義のフェーズでは、
お客様は要望に優先度を付けずにどんどん伝えてきます。
その中にはそれを満たさなければ業務が成り立たなくなるものから、
無くてもそれほど問題はない要望まで様々です。

そんなとき、パレートの法則で言う重要な20%を探します。
木にたとえると、要件が
・木の幹にあたる「重要」レベルなのか
・木の枝にあたる「普通」レベルなのか
・木の枝の先の葉っぱにあたる「補足」レベルなのか
この重み付けをして上位20%の重要な要件を深堀りします。

テストフェーズでは不具合がてんこ盛りになってくることがありますが、
例えばECサイトだと
①商品をショッピングカートに入れられない
②会員規約のページで文章の折り返し位置がおかしい

という2つの不具合があった場合、①はかなり重要な不具合で、
②は対応優先度の低い不具合になります。
①のような重要な上位20%の不具合の修正が完了すれば、サイトは8割
完成、という発想は稼動を目前にしたフェーズでは有効です。

・締め切りが迫っているとき
・仕事が山積みでどうしようもなくなったとき
・あれもこれもと欲張ってしまいそうなとき

ぜひとも「パレートの法則」を思い出していただければと思います。

–