敏腕PMブログ

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

—

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

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

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

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

–