敏腕PMブログ

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

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

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

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

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

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

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

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

—

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

–

今日は人材育成についてのお話です。

プロフェッショナル仕事の流儀というテレビ番組で
前回はヤクルトの宮元選手がゲストでした。

ヤクルトのキャプテンであり、
日本代表のキャプテンでもあります。
星野JANPANのキーマンですね。

そんな宮本選手の流儀として
「背中と口で引っ張る」というのがありました。

「背中だけ見せても言わないと分からないことがある。
だから僕は言う。」
というスタンスです。
かなり共感しました。

キャプテンなので、プレーで周りにアピールすることはもちろん、
気を抜いた選手には厳しい激（言葉）が飛びます。

プロジェクトメンバーに対して僕は、
言われたら分かる = 言われないと分からない
と思っているので、積極的に言うようにしています。
（アドバイスの場合もあれば、注意事項の場合もあります）

それが相手にとっても自分にとってもHAPPYだからです。
どうせ気づくんだったら、
１年後に気づくより、今日気づいたほうがいいですから。
しかも言われたら気づくんですから。

人材育成の観点から考えると、人間は
①言わなくても分かる人(1割)
②言われたら分かる人(8割)
③言われても分からない人(1割)
の3パターンに分けられると思っています。(注：割合は単なる感覚です)

僕は②のパターンの人が”人材育成”の対象だと考えています。
②⇒①へ自分が誘導できたらとても強力なチームが作れます。

なので僕の人材育成についてのスタンスは
・俺から盗め！
ではなく、
・俺のノウハウ全部伝えるから１日でも早く成長して！
です。

１歩間違うとただの”過保護”なので、
相手との最適な距離を見つけることが大事ですけどね。

–

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

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

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

–