敏腕PMブログ

プロジェクト開始前には通常「営業フェーズ」があります。
基本的にはプロジェクトマネージャーではなく、営業担当者が
お客様とどのようなプロジェクトにするのか、の大枠を決めます。

プロジェクトマネージャーはある程度 ”案件化” する可能性が
高まってきた時点で、営業にも関与します。

ここで注意しないといけないのが、“見積り”ですね。
営業担当者は仕事がほしいあまり、安い金額で提示してしまうことがあります。
もしくは口頭で値引いてしまうとか。

プロマネの重要な仕事として「見積りチェック」というのがあります。
これはプロジェクトが始まる前にやる仕事ですので、
自分で営業案件にアンテナをはっておかないと、関与するタイミングを逃します。

営業担当者⇔プロジェクトマネージャー　の接点は
見積書になります。
２人で相談してコンセンサスが取れれば強力なタッグですね。
逆に全く接点がなければ、コミュニケーション不足で
プロジェクト開始当初からつまずく場合があります。

PMとしては「営業がこんな安い金額で受注したから利益が出ない」
営業としては「せっかく受注したんだから、この金額で利益出せ」
というような互いの考え方の違いから溝ができてしまいます。

プロジェクトマネージャーも営業に無関心であってはなりません。
プロジェクトを成功させるには、開始前からの準備が必要です。
”見積書”が営業担当者との接点なので、積極的に見積りチェックを行いましょう。

–

プロジェクトが忙しくなってくると、
「人が足りませーん」
とメンバーが言うことがあります。

僕はいつも、”本当に人が足りないの？”と思います。
・仕事の進め方に問題があるのでは？
・１人１人の生産性が低いのでは？
・簡単なことを難しくしようとしてるのでは？
たくさん疑問が出てきます。

人を増やすと言うことは、
・引継ぎを行うため既存メンバーの時間が取られる
・情報伝達速度が低下する
・お金がかかる
等々色々な問題があります。

ではプロジェクトが忙しくなってきたときに、プロジェクトマネージャーは
何をすべきなのでしょうか。

僕の応えは「仕事を減らす」です。
自分の仕事もメンバーの仕事も意図的に減らす方向に持っていく。

・難しい機能を簡単に実装する方法を考える
・作成ドキュメントを必要最低限に絞る
・お客様にテストを手伝ってもらう

仕事を減らす工夫はたくさんあります。
プロジェクトが終盤にさしかかると要望も増えます、バグも出ます。
なので意図的に仕事を減らさないと、予定通りいかないのです。

”人を増やすのではなく、仕事を減らす”
発想の転換といったところでしょうか。

–

納期が近づいてくると誰でもあせるものです。
最近メンバーから「あと１ヶ月しかないですよー」
という声があがってきました。

僕は、「違う、あと１ヶ月もある」 と伝えました。
メンバーに1ヶ月で何をやるべきか、を伝えるのが
プロジェクトマネージャーの役目です。

”１ヶ月”という期間に意味は無く、そこに意味を与えるのは
自分達です。

追い込まれた時こそマインドはポジティブに、
今できることをコツコツやる。

最後の追い込みは、みんなバグ修正や要望対応への
スピードが格段に速くなります。
「慣れ」とか「成長曲線」っていうのはなかなか侮れません。

スケジュールは守られるためにあります。
学校の宿題も、システムのカットオーバーも、
なんだかんだで最後はギリギリ間に合うものです。

伝えたかったのは、
“ネガティブなイメージをポジティブにとらえ直す”
プロマネは悩んでたらきりがないですから。

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–