敏腕PMブログ

コミュニケーションについてはいろいろ考えるところがあるので
まだまだ書きます。
前回は「前提を合わせる」重要性について書きました。

相手に合わせるためには、自分は相手よりも受け入れる
幅が広いことが必要だと思います。

たとえ話をしましょう。
Aさん、Ｂさん、Ｃさんの3人が、ある花を見たときにその色を
Ａ：赤色
Ｂ：紫色
Ｃ：赤紫色
と答えたとします。

このときCさんはＡさんＢさんよりも色に対して細かく判断しています。
ＡさんＢさんが12色入りの色鉛筆を持っていて、
Ｃさんは24色入りの色鉛筆を持っているイメージです。

僕はＣさんのような人を「メッシュが細かい人」と定義しています。
そういう人は会話をしていても、少しのずれに気づいてそれを訂正
できるので、自然と前提を相手と合わせられるのです。

メッシュを細かく持つためには、いつも「定義」に注意するといいですね。
・SaaSとASPの違い
・ハウジングとホスティングの違い
・要求と要件の違い
といった似ているようで異なるものに注意していると、自然と細かな定義ができていきます。
それは必ずコミュニケーション能力向上に通じます。

—–

基本的にはプロジェクトマネージャーは楽天主義がいいと思います。
心の中ではつらいことや悩みがあっても、お客様やメンバーには
見せない、というのが重要だと思います。

ただし、PMはプロジェクトの「リスクコントロール」はしなければなりません。
リスクがあるにも関わらず、「大丈夫大丈夫」と言っているようでは、
メンバーのほうが不安になりますので。

リスクに臆病になりすぎてもだめだし、リスクを察知できなさすぎてもだめ。
微妙なさじ加減が難しいところです。

僕はいつも提案書を作るときや、お客様との打合せの前には
「本当にこれでいいのか？」という視点で自分の作ったものや、行動を
客観的に見直すことをやってます。
それを勝手に「健全な不安」と名づけてます。
（本来の使い方として正しいかは分かりませんが）

例えば、「システムが動かないのではないか？」という考え方って非常に重要で、
それがあるからこそテストをきっちりやろうという発想になり、
スケジュールを立て、実行していくんだと思います。

なので、気持ちは楽天的だけど、頭の中には健全な不安を持っている、
というのがPMとしてバランスの取れた状態と考えています。

–

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

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

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

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

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

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

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

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

–

プロジェクトマネージャーは日々決断の連続です。
・お客様から頂く新たな要望を受けるか、受けないか
・システムのカットオーバー時期をずらすかどうか
・人をリリースするか、もう少しいてもらうか

僕も毎日毎日小さな意思決定をし続けています。
プロジェクトは基本的に不確定要素はたくさんあるので、
少ない根拠から自分の中で筋道を立てて考えて、
最後は自分の責任で結論を出さなければいけません。

仕事をしていてよく思うことは、
判断はするけど決断ができない人が多い
ということです。

お客様の担当者の方も、なかなか決めきれない人が多いですね。
・上司に相談しないと、、、
・僕には権限がないから、、、
・資料をもらわないと決められない、、、

メンバーでも
・この仕様だと何パターンも解釈があって実装できません、、、
・資料を作るか作らないかで迷っています、、、
という疑問や迷いを持って作業が前に進まない人もいます。

プロジェクトの現場では、みんな決断を下してくれる人を待っているのでは？
とよく思います。
決断を下す = リスクを自分が取る
ということですから。

プロジェクトマネージャーはいつも決める側にいるべきだと思います。
決断したことに自信と責任を持ち、決めてもらう側の人たちを誘導して、最後は
「ほら、私の言ったとおりでしょ？」
とやってのけると、かっこいいと思います。

–

以前、プロジェクトの状況を判断するヒント でプロジェクトの状況を
メンバーからの質問で判断する、ということを書きました。

今回は第２弾です。
プロジェクトマネージャーが実際にプログラミングを行うことはまれだと思います。
普通は要件定義や設計で、その後の実装はメンバーに任せるのが一般的です。

でも、システムはプログラムで動いていて、そのプログラムは最終的には0か1かの世界です。
プロジェクトマネージャーがいかにすばらしい設計をしても、
システムがバグってしまうと全てが水の泡になります。

最後はやっぱりエンジニア頼みなんですね。
でもエンジニア任せではダメです。
いつでもシステムの品質に目を光らせなければなりません。

そこで、状況判断のヒントですが、それはバグの内容で判断するというものです。
僕はRedmineというバグトラッキングシステムを使っているのですが、
バグが発生し、解決し、終了するサイクルが全てメールで飛んでくるので、
今どんなバグが出ていて、どこでメンバーが手こずっているのか、が
メールを読んでいるだけで分かります。

１つのメールを読むのが２秒くらいなので、１００件あっても２００秒しかかかりません。
重要なバグや、仕様にかかわる部分はメールを読んだ瞬間にRedmineにアクセスして、
メンバーへ仕様を伝えることができます。

「いいバグが出始めたな」とか「このレベルのバグが出ているようではまだまだだな」とか、
１人でいろいろと状況を判断しています。

なので、質問とバグ、これがプロジェクトの状況を判断するヒントですね。

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

–

郵政民営化法案を成立させるためには、
「殺されてもいい」と小泉純一郎さんは言いました。

プロジェクトマネージャーは命までとられることはありませんが、
「嫌われてもいい」くらいの気概は必要だと思います。

お客様と長期的に良好な関係を築くためには、
一時的にはお互いの意見を交換するための衝突も必要です。
顧客に迎合することが必ずしも最善策とは限りません。

弱音を上げるメンバーに対して、手取り足取り教えてあげるのも
一つの方法ですが、時には突き放してみて自分で乗り越える試練を
与えることも必要です。

・なぁなぁになる
・馴れ合いになる
ことは楽ですが、プロジェクトマネジメントの観点から正しいとは言えません。

時にはビジネス上での喧嘩をしたり、
とことん腹を割って話し合ったり、
嫌われてもいいと思って正面からぶつかることも必要です。

プロジェクトマネージャーは日々外部・内部問わず調整力を発揮すべきですが、
調整型人間でいればいいというわけではありません。
時には厳しく厳格な態度、小泉前首相のように凛とした姿勢が求められます。

小泉さんも首相時代は各方面から色んなことで叩かれました。
トップに立つ人は誰かからは嫌われる、叩かれる比率は多くなります。
でも退任してからほとんど悪く言う声は聞かれません。

プロジェクトマネージャーも、信念を曲げず、自分が正しいと思うことを
やり続けていれば、道中いろいろ叩かれたり嫌われたりしても、
必ず最後はHAPPYな結末を迎えられると思います。

「嫌われてもいい。プロジェクトが成功するならば。」
ちょっとかっこよすぎますかね。

–

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–