敏腕PMブログ

昨日はあるプロジェクトのリリース日でした。
そこで今日はリリースにまつわるお話を。

「徒然草」の中に「高名の木登り」という話があります。
師匠と弟子が出てくるのですが、師匠は弟子が木の高いところに
上っているときには何も言わないのですが、
木から降りてきてもう安全な状態になったときに、「注意せよ」
という指示を出します。

「安全な状態になったときに油断するから、気をつけよ」
という師匠から弟子への教えです。

プロジェクトにも同じことが当てはまります。
リリース当初はプロジェクトメンバーも気を張っているので、
作業も丁寧に行います。

これがリリース後1ヶ月も経つと、
・作業中にデータベースのレコードをうっかり消してしまったり
・1ヶ月蓄積されたデータが不整合を起こすことが発覚したり
・機能追加したら元のプログラムがデグレしたり
ということがよく起こります。

気の緩みや集中力の欠如が原因です。
なので僕はリリース当初よりかは、メンバーの気が緩む可能性のある
1ヶ月後くらいが一番緊張します。
（何か起こるのではないか？と思っています。）

木登りもプロジェクトも同じですね。

–

若手メンバーに仕事を任せる場合によくあることなのですが、
「まだ私にはできません」
「もう少し成長してからでお願いします」
という返答をもらうことがあります。

僕は「なんてもったいない！！」
と思います。
まだちょっと早いくらい、重々承知しています。
でも挑戦させてみたいのです。それを乗り越えて成長してほしいのです。

基本的に仕事を任せる場合には、「できそうだから任せます」
ただし、前提があって、「ちょっと背伸びしたら」という枕詞が付きます。
「ちょと背伸びしたらできそうな仕事を」任せて、苦労して乗り越えてもらって、
成長してもらいたいのです。

特に20代、30代は自分の能力が「足りてないことを恐れない」
気の持ち方が重要だと思います。
プロジェクトマネージャーも同じで、
・大きい規模だからできない
・お客さんが気難しいからできない
というのではなく、今の自分ではできるかわからないけど、
それでもやってみる、という気概がほしいものです。

僕も新しい仕事に向かうときには
「今回はちょっとやばいなー」と思うことは多いですが、
いざ走り出してみると、いろいろな作戦を練って解決していけるものです。

–

プロジェクトをやってると、たまーにですが、
“もうどうにもならん“という状況になります。
にっちもさっちもいかなくなる、というやつですね。

普通は課題があると、解決策を洗い出して、
まずは自分達で精査して、
それでも解決策が1つに絞り込めなければお客様に
判断を委ねる。
という形を取ります。

社内メンバーで解決しなければならない課題は、
できるだけ情報を社内で共有して、
プロジェクトメンバー以外からもアイデアをもらって、
最終的な決断をしていきます。

でも、上記手順を取ったとしても、妥当な解決策が見つからないときがあります。
例えば、データを全部消してしまい、かつバックアップも取っていなかった場合
なんていうのは、エンジニアの方だったら一度くらい経験しているのではないでしょうか。

パニックになると、冷や汗流していろいろと言い訳を考えたりするのですが、
大抵後からつじつまが合わなくなり、自分で自分の首を絞めることになります。

私もこれまでいろいろと窮地に追い込まれて来ましたが、
もうだめだ、解決案が思い浮かばない
状況になったときの、方針だけは明確にしてあります。

それは、、、、「正直」です。
正直に状況を全て話す。
ダメモト、怒られて当然、の状況で、それでも正直に話す。

短期的な逃げではなく、長期的な視点で解決策を探すと、
最後は「正直」という解が導かれる。
これは私の経験則ですが、結構同じ事を考えている
プロジェクトマネージャーは多いのでは？と思っています。

–

・情報共有とは具体的にどうすることか
・顧客視点にはどうしたらなれるか
・責任感とはどこから生まれるのか

これらの問いに対する一つの答えが、「他人事を自分事に」することだと思います。
アートディレクター、佐藤可士和さんの本で出てきた言葉です。

社内で朝礼や会議があるのは、情報を共有するためで、
それは他の人がやっていることを、自分も知る、考える必要があるから。

顧客の視点に立つということは、顧客が抱える課題を解決するために、
もし自分がお客様と同じ状況に置かれたらどうするか、を考えること。
正論だけでは通用しなかったり、社内政治まで考えるべきときもある。

責任感の強い人は、自分に与えられた仕事は完璧に仕上げ、
かつ他人から頼まれたことも手を抜かず高いOUTPUTを出す。

プロジェクトの現場でいうと、
・メンバーはリーダーのことを自分事に
・リーダーはメンバーのことを自分事に
考える必要があります。
(双方向の理解が不可欠)

特に忙しいとき、頭にかっと血が上ったとき、
は合言葉にするとよいと思います。

他人の大変さ、というのが自分のことのように分かる仕組みを
プロジェクトマネージャーが作れるとよいですね。

–

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

–

昨年の流行語で ”KY(空気読めない)”
というのがありました。

否定語が流行語になるのは残念だなー。
どうせなら肯定的な言葉が流行すればいいのに。
と思っていました。

プロジェクトマネジメントにおいて、空気を読むことは
非常に重要です。

・会議の場でお客様の顔を見て、満足度を察知する
・開発メンバーの顔を見て、ストレス度合いを見抜く

論理的思考力とかコミュニケーション能力については、
マネジメントの教科書にたくさん載っているのですが、
・空気を読む
・気が利く
というのは、なかなか文章による説明が難しく、
これまで語られてこなかったと感じています。

でもこういったほんのちょっとの気遣いが、プロジェクトの成功を
左右するといっても過言ではありません。

気が利くプロジェクトマネージャーは、お客様への説明資料を作るときに
・重要ポイントは太字にする
・前回からの変更点は赤字にする
・文字だけでなく図や絵を入れる

気が利くエンジニアは、コーディングをするときに
・プログラム行数が長い場合はクラス(メソッド)に切り出す
・メンテナンス性を考えてコメントを付ける
・仕様の抜け漏れは事前に設計書で確認する

“少しの気遣い大きな違い”です。
空気読めない（KY）よりも、気が利く（KK）が
流行語になればいいですね。

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–