敏腕PMブログ

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–

皆さん、ゴルフはされますか？
ゴルフって、精神力が試されるスポーツなんですね。
その点でプロマネとの共通点も多いと思います。

先日全米オープンでタイガー・ウッズが優勝しました。
そのときのインタビューを紹介します。

———————————–
Q.最後のパットはどうでしたか？
→自分はただカップのボール二個半右を狙って、集中して打てた。
あとはもう運を天に任せるような気持ちだった。
なぜならコントロールできるのは自分のストロークだけだからね。
(by タイガーウッズ)
———————————–

“コントロールできるのは自分のストロークだけだからね”
これを聞いたとき、深いなーと思いました。

プロジェクトの現場では、自分にはコントロールできない
ことが山ほど起こりえます。

・社長の一言でプロジェクト方針が大きく変わるかもしれない
・メンバーがインフルエンザで1週間寝込むかもしれない
・システム稼動の日に大地震が来るかもしれない

プロジェクトマネージャーは、自分は何をどこまでコントロールできて、
どこからはコントロール不可能な範囲か、の境界を意識すべきだと思います。
そしてコントロール可能な範囲で最適解を探し続ける。

最後の最後はウッズが言うように
“あとはもう運を天に任せるような気持ち”
になるのです。
特にシステムカットオーバーの前日なんてそんな気持ちですね。

システム稼動を8月に予定している僕も、
自分にコントロール可能な部分を
自分ができる精一杯の方法で進めていこうと思っています。

そしてもう全てやり尽くした、
という状況で、運を天に任せようと思っています。
今はまだまだやることたくさんあるんですけどね。

—

・朝決められた時間までに出社する。
・出社したら「おはようございます」と挨拶をする。
・挨拶をされたら挨拶で返す。

当たり前のことを書いてみました。
でも必ずできている訳ではないことを書いてみました。

年間通して無遅刻の人の割合ってどれくらいなのでしょう？
寝坊した、忘れ物を取りに帰った、電車が混んでいた、等々
遅刻の原因は至る所にひそんでいます。

でも会社の規則では遅刻しないことが「当たり前」。

世の中当たり前のことを当たり前に実行するって
すごく難しいことなんだと思います。

ダイエットでも
・食べる量よりも消費する量を増やす
という「当たり前」が実際は難しいんでしょう。

プロジェクトマネジメントも当たり前の積み重ねです。

・議事録は打合せ翌日の午前中には提出
・会議資料は事前にメールで送付
・スケジュール通りに開発を完了

それくらいできてるよ、と言われそうですが、
議事内容が正確に抜け漏れなく書かれている議事録は、
なかなかお目にかかることはありません。(本人調べ)
真っ赤に添削することもしばしばです。

ここで注意しないといけないのが、「当たり前」のことは
・人によって
・プロジェクトによって
・プロジェクトマネージャーによって
変わります。

プロジェクトマネージャーは、プロジェクトの「当たり前」
を定義する立場にあります。
もちろん、自分ができてもないことを「当たり前」とメンバーに
伝えることはできません。

プロジェクトマネージャーをはじめとし、
メンバー全員が当たり前のことを当たり前にできれば、
非常に強いチームができると思ってます。

算数も基本問題が解けなければ応用問題は解けない。
当たり前のことを当たり前に行うことが、
プロジェクト成功へ向けた第一歩と考えています。

–

みなさん、ビジネス書は読まれますか？
ビジネス書にはブームがあります。

会計ブーム、レバレッジブーム、勉強法ブーム、HACKブーム、
といろいろありますが、
一時期ロジカルシンキング(論理的思考力)、仮説思考
といった思考ブームがありました。

本日はその中から「仮説思考」についてお話します。

仮説思考というのは、誤解を恐れずひとことで言うならば
「結論から先に考える」ということです。

常に先を見なければならないプロジェクトマネージャーにとって
必須の思考だと思います。

具体的な事例で説明しましょう。

最近ECサイト構築の要件定義を1ヶ月かけてみっちりやりました。
要件を理解し、定義するにはいくつも質問しなければなりませんが、
忙しいお客様の貴重な時間を無駄にしないよう、
少ない質問で全ての疑問を解消したい、
そんなことを考えていました。

質問に至るまでの過程には2つあります。
①疑問レベル(なんでだろう？)
↓
②仮説レベル(答えはおそらくこうではないか？)

お客様に質問をするときに①のレベルでするのか、②のレベルでするのかは、
雲泥の差があります。

①のレベルで質問すると、お客様はこちらがどこまで分かっているのか、
を判断できません。
ですので回答に困ってしまったり、回答が長くなってしまいます。

②のレベルで質問すると、こちらの理解度がお客様に伝わり、かつ
間違っている場合にはその「仮説」に間違いがあるので、
なぜそこに間違いがあるのかを訂正してくれます。
回答が明確で、短くなり、時間を無駄にしません。

最短のルートで、最適な答えが返ってくる、
これが仮説を持った質問をする効用です。

「仮説思考」は戦略コンサルタントが使う上級テクニックではなく、
日々の作業効率を上げる誰でも使える道具です。

ぜひまずは質問から仮説思考を取り入れてもらいたいです。
お客様の反応が変わりますよ。

–