敏腕PMブログ

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

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

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

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

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

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

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

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

–

今日はちょっとした「気づき」のお話です。

仕事ができるようになるためには、
「まずは量をこなせ、それから質を考えていけ」
というメッセージを見かけます。

サイバーエージェントの藤田さんも、著書の中で、
若いころはまず量をこなすことに専念した、
と言っていました。

最近の僕も仕事量が以前よりは増えてきたので、
量をこなしている状態が続きました。
ただし、量をこなすからといって、これまでの仕事の質を落としたくないので、
質を保ったまま量をこなそうという状態が続きました。

「量は増えているけど質を保つ」ということは、実質的には質が上がっていることに
なります。（単位時間当たりの作業の質が上がっている）

なので、“量をこなす”ことは、質を考えながら続けていると、おのずと“質を上げる”
ことにもつながるんだなー、と最近気づきました。

今までは、
・量を追い求めるんだったら質は落とさなければ
・質を求めるから量は少なく
といったような量と質のトレードオフの考え方を心のどこかに持っていた気がしますが、
最近の仕事の中で考え方が変わってきました。

「量をこなし続ける先に、質の向上がある」
僕の量から質への転換の解釈です。

—

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

僕の社会人１年目はプログラマーでした。
先輩社員が設計して、僕がプログラミングとテストをする。
仕様が分からなければ都度先輩社員に確認する。
スケジュール管理もその先輩が行ってました。

そのときよく考えていたのが
「自分だったらスケジュール管理はこうする」
「自分だったらお客さんとの交渉はこうする」
といった、シミュレーションでした。

先輩のマネジメントスタイルがいやだとかいう意味ではなく、
“もっとうまくやる方法があるのでは？”
ということをいつも考えていました。
トヨタの”カイゼン”のようなイメージです。

実際にその先輩と同じ立場になったときに初めてその
先輩の苦労が分かりました。
メンバーのモチベーションとかお客さんの要望とか、
いろいろコントロールしなければならない立場になってやっと。

ただ、「自分だったらこうする」ということを常に考えていたので、
ある程度先輩の疑似体験ができていて、
あらゆる決断の場面でそれほど迷いませんでした。

今でもよく自分がお客さんの立場だったらこうするだろうなー、
というのは仕事をしながら考えることがあります。

PGはSEの仕事を、SEはPLの仕事を、PLはPMの仕事を
「自分だったらこうする」
という観点で観察しておくのがよいと思います。

–

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

–