敏腕PMブログ

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–

皆さん、仕事の標準化ってされてます？
おそらく企業に勤めている方なら気づかないうちに
標準化された業務の中にいるとは思います。

プロジェクトにおける標準化の一般的な定義は、
「誰がやってもある程度同じ結果が得られるようにすること」
くらいに僕はとらえています。

標準化することのメリットは、大きく分けて
①品質向上
②コスト削減
です。

①品質向上について
例えば議事録やスケジュール表、課題管理表といった、
どのプロジェクトにおいても必要なドキュメントテンプレートは、
全社で統一することが「標準化」です。

これによって、今まで上記ドキュメントを作ったことがない人でも、
テンプレートに沿って作成することで、一定の品質が保てます。

②コスト削減について
①の例で言うと、標準化されたドキュメントテンプレートがあると、
ドキュメントのフォーマットを考える「時間」が少なくなります。
既にあるものを使えますので。

プロジェクトではほぼ時間=コストなので、時間を少なくすることで
コストを同時に削減しているのです。

ただし、標準化には落とし穴があります。
標準化されているからといって、それを鵜呑みにしてはいけないということ。
標準化はあくまでも「標準」であって、「絶対」ではありません。

プロジェクトの状況によって、標準化されたものを都度応用していく
必要があります。

最後に、僕が考える標準化の本当の意味を書きます。
それは、「本来業務に注力できること」です。

お客様はドキュメントのフォーマットがどうだとか、ほとんど気にしていません。
その中に書かれている内容を非常に気にされています。

プロジェクトではその内容を深く考える必要があります。
その考える時間を確保するために「標準化」があるとも言えます。

「標準化して努力しなくても品質が保ててコストも削減できた！」
ではなく、
「標準化して本来考えるべき内容に時間を使うことができた！」
が標準化の本当の意味なのです。

–

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

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

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

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

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

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

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

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

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

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

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

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

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

–

要件定義フェーズの目的は何でしょうか？
要件定義書を作成することでしょうか？
いえ、「要件を定義すること」、これが目的です。
(当たり前ですね。)

要件定義書は要件を定義する(目的)ための
「手段」です。

実際のプロジェクトでは、
目的と手段が入れ替わっていることがよくあります。

-課題を解決するため(目的)の会議なのに、会議を開く(手段)だけで
満足して課題解決は先送り
-品質を上げる(目的)のためテストなのに、テスト仕様書の作成(手段)に
時間を取られ、テストをする時間が取れていない

世の中でも
キャリアアップしたい(目的)ので資格のスクールに通う(手段)が、
スクールに行くこと自体が目的になってしまっている。
という状況も見受けられます。
この状況に陥らないためには、常に目的を意識するしかありません。

・何のためにドキュメントを作るのか
・何のための打合せなのか、何を決めればよいのか
をひたすらまず考える。
そして何が「目的」で何が「手段」かを自分で定義する。

プロジェクトマネージャーはメンバーに「目的」を伝えるのも
重要な仕事です。
最初はどうしても手段が目的化してしまいますから。
「それって目的？」「それって手段？」
こんな会話がプロジェクト内で起こるといいなーと思います。

と、ここまでが本日お伝えしたかったことです。
ここからはちょっと補足です。

キャリアアップ > 資格取得 > スクールに通う
といった流れの場合、目的と手段は入れ子構造になります。

・キャリアアップ(目的)のために資格を取得する(手段)
・資格取得(目的)のためにスクールに通う(手段)
・スクールに通う(目的)のためにお金を貯める(手段)

なので本当は状況によって目的は手段にもなり得るのです。
だからこそ、大事なのは状況に応じて「目的は何か？」
を考え続けることです。

–