敏腕PMブログ

・プロジェクトマネジメントスキルを高める
というのは抽象的ですが、

・コミュニケーションスキルを高める
・問題解決スキルを高める
・ドキュメント作成スキルを高める
というのは具体的です。

抽象的：わかりにくいが適用範囲が広い
具体的：わかりやすいが適用範囲が狭い

言い換えると、
抽象論：分野を飛び越えて適用が可能
具体論：その分野にしか適用できないことが多い

社長の話ってぼんやりしていると思いません？
それは抽象論で考えているからです。
そのほうが広く思考できるから。あらゆる状況に対応できるからです。

たとえ話でお話します。

マクドナルドの社長は元アップルの社長でした。
Macからマックへ、と当時言われました。
社長業は最終的に利益を出して永続的な仕組みを作る
という仕事(抽象的)なので、問題なくできるのでしょう。

これに対し、マクドナルドでハンバーガー作ってる人が
アップルでiPhoneの開発はできない(具体的)といえば
ご理解いただけるでしょうか。

このブログも、伝えたいことが抽象的なので、できるだけで
たとえ話を使って具体論で伝えるようにしています。

思考は抽象的に、伝え方は具体的に
を心がけています。

オバマ大統領がなぜ選挙に勝てたのか。
民主党がなぜ圧勝したのか。
ここには共通項があると思ってます。

どちらもキーワードに隠されています。
オバマさんの場合は「Change」
民主党の場合は「政権交代。」
どちらも政策うんぬんではなく、まずは「変わる」という
共通認識を国民に植え付けたのです。
「変わらなきゃ！」と国民を煽ったとも言えます。

その共通認識があって始めて個別の政策が理解されます。
自民党と民主党の政策の違いを明確に言える人って
有権者の中でも相当少ないと思います。

でも政権が交代する、なんとなく交代したほうがいい、という認識は
大勢の人が持っていたからあの結果につながりました。

人に話を聞いてもらうには土壌が必要です。
コミュニケーションでは前提を合わせることがまず重要と
このブログでも書きました。

自分のやりたいこと、相手にやってほしいこと、
それらを個別に伝えるのではなくて、
まずは全員の共通認識を醸成するのです。

それがないと
「あれ？あの人何言ってんの？(ぽかーん)」
ってなこともあります。

プロマネはみんなの前に出て共通認識につながる言葉を
発するべきなんです。
必ずできますよ。
オバマも言ってるじゃないですか、
Yes , We Can.

–

ロール＝役割　モデル＝規範（ひな型）

ロールモデルとは、行動の規範となる存在　お手本のことです。
もう少し簡単に言うと、「あの人みたいになれればいいな」
と思える、先輩、上司、同僚のことです。

ロールモデルは身近な人だけとは限りません。
歴史上の人物、過去の偉人、業界の有名人などなどさまざまです。

今はパナソニックになりましたが、以前松下電器産業の経営を立て直した
中村邦夫社長は、課題にぶつかったとき、判断に悩んだときは
「松下幸之助ならどう考えたか」という発想をしたそうです。
これもひとつのロールモデルだと思います。

人間誰しも長所、短所というものがありますので、全人格を認めて
受け入れるのは難しくて、ロールモデルもその観点からすると
なかなか見つからないかもしれません。

これを書いている僕も最近尊敬する人は自分の父親くらいで、
あとはロールモデルはそれぞれの人のパーツパーツを組み合わせて
目標到達地点のようなイメージにしています。

営業ではこの人、プロマネではこの人、アイデアの出し方ではこの人、
という感じで分野別にロールモデルを決めています。
もちろん、過去お仕事を一緒にした人を思い出しながら日々の
仕事を進めていく、といったことを自然としています。

仕事ができるようになりたい！
もっと多くのことを吸収したい！
このような欲求にはロールモデルを分野別にたくさん作るのがオススメです。

そしていずれは、
「あなたをずっとロールモデルにしてました」
なんて言われる日が来ると最高ですね。

–

世の中「絶対に成功する」プロジェクトなんてなくて、
成功する確率を限りなく100%に近づける努力を地道に行います。

プロジェクトマネージャーとしては、99%成功すると思っても、
残りの1%が気になり、失敗しないよう対策を立て続けます。

”絶対成功する”と思っているより、心のどこかで”失敗するのではないか？”
という健全な不安を持っているほうがちょうどいいと思います。
石橋を叩いて渡る精神ですね。

ただし、行動や発言は常にポジティブでなければなりません。
PMが心配性すぎるとメンバーが不安になりますので。

作家のおちまさとさんが「ポジティブシンキング＆ネガティブシミュレーション 」
という言葉を使っているのですが、まさにこんな感じですね。
心は明るく楽観的に、でも計画は慎重(ネガティブ)にリスクを最小限に
というのがプロマネに求められる要素ではないでしょうか。

営業するときには「受注できない理由は何か」
システムリリース前には、「想定されるシステムトラブルは何か」
常にネガティブな理由を考えると、それを回避しようとするので、
自然と目標(目的)に近づくことができます。

ぜんぜん緊張しないで望んだプレゼンよりも、
不安が多くて緊張しまくってだからこそ用意周到に望んだプレゼンのほうが
うまくいく確率が高いですね。
これも健全な不安を持つことの効用例です。

—

生まれて初めて本を出版するというお仕事に携わりました。
弊社ではオープンソースのEC-CUBEを使って
ショッピングモールや通販事業者向けの基幹システムを
構築しています。

そのEC-CUBEのカスタマイズノウハウ(Tips)を100個収録した
本を出版することになりました。
今週末には書店に並びます。

EC-CUBE公式ガイドブック　カスタマイズ編
株式会社エスキュービズム
オレンジ岸本　共著
http://ec-cube.ec-orange2.jp/detail/book.html

僕もいくつかのパートを担当しましたが、
ほぼ全て弊社の”オレンジ岸本”が執筆しています。
EC-Orangeというパッケージ名からペンネームをつけました。
純粋な日本人です。かなりEC-CUBEに詳しいです。

ノウハウは蓄積してかつ公開することで、さらに多くのノウハウを
得られると考えています。
このブログも自分で書きながら、再度大切なことに気づいたり、
周りの方からフィードバックをもらって、新たな発見ができます。

このブログも出版の話、、来たらいいな。

IT系のプロジェクトの場合、メンバー構成は一般的に
・PM：プロジェクトマネージャー
・PL：プロジェクトリーダー
・SE：システムエンジニア
・PG：プログラマー
のような体制になります。

さて、ここでクイズです。
PMが1名、PLが3名のプロジェクトにおいて、
PMが急に体調不良で倒れました。
PL3名の誰かがPMに昇格するとなったら、
誰が昇格するでしょうか？
その場合の選定基準は何でしょうか？

答えはほぼどのプロジェクトでも同じで
「PL時代からPMクラスの仕事をやっていた人」
に決まります。
これは人事の普遍的な原理だと思います。

役職の序列にかかわらず、視点を高く持ち一つ上のランクの
仕事をしている人が、引き上げられるのです。

「僕はPGだからSEの仕事はやりません」
ではなく、
「PGの時代からSEの仕事を盗んで身につけよう」
という心構えが大切です。

年功序列はとっくに崩壊していて、本当に実力主義の時代に
なってきたなーと、ベンチャーで働いていてつくづく思います。
今は年功序列の大企業も、変化を余儀なくされるでしょう。
10年後はさらに楽しみな時代です。

特にIT業界は「若さ」が大きな強みです。
経験や年齢が価値を持たない時代だからこそ、
常に上のランクの仕事を意識すべきだと思います。

–

プロジェクトには、お客様側に「プロジェクトオーナー」という人がいます。
大抵、お客様の会社の社長や役員、事業部長がオーナーですね。

でもこのプロジェクトオーナーって、ほとんど現場には出てきません。
週次の定例会にはほぼ出ない、月一の報告会にもほぼ出ない。
現場からは見えないところで決済の承認だけをしていることもしばしば。

でも最終的に説得しなければならないのが、このプロジェクトオーナーだったりするのです。
で、そもそも会って話ができないので説得ができない。
ではどうやって説得すればいいのか？

会えなくても説得できる方法を考えるんです。
僕はよく、オーナーまで伝わるような資料を作って
現場担当者に託します。
「これ、渡しておいていただけますか」
と言って、現場担当者がオーナーに褒めてもらえるような内容も
盛り込んで渡します。

具体的には提案書、要件定義書、プロジェクト結果報告書、等々の資料をオーナーさんを
読み手と考えて書きます。
オーナーさんは、現場でしか見えない情報を「わかりやすく」「簡潔に」まとめた資料を好みます。

オーナーさんがその資料を気に入ると、いろんな人に回してくれます。
資料は一人歩きするものです。
だから一生懸命作らないといけない、機能する文章を書かないといけない、

以前２５歳くらいで”ITコンサルタント”を名乗っていたら、
「お前らみたいな若造に何ができるんだよ！」と言われたことがありました。
なかなか認めてもらえないので、自分達の仕事をありのままに表現する資料を作りました。
それがきっかけでお客さんと円滑に仕事が進むようになりました。

うまいこと資料を一人歩きさせる技術を身につければ、
プロジェクトをコントロールしやすくなります。

資料に関して「考えて、書いて、一人歩きさせて、反応を見て」という
PDCAをずーっと回し続けるのです。

—–

プロジェクトマネージャーには問題解決能力が求められます。
たとえばWEBサイトを運用していると、
「サイトが重たい」
状況が発生する場合があります。

PMは”サイトが重たい”という問題を解決しないといけないのですが、
いきなり
・メモリを増設しよう
・SQLをチューニングしよう
・プログラムロジックを見直そう
というアクションを起こすのはまだ早いです。

なぜなら、まだ問題が定義できていないから。
まずはサイトが重たい原因を特定することが先決で、
解決策をいろいろ考えるのはその後です。

問題の切り分け方として僕が意識するのは
「起きていることの正確な理解」です。

”サイトが重い”という情報だけでは少なすぎるので、さらに
掘り下げて何が起きているのか、を理解します。
殺人事件でいう現場検証ですね。
自殺か他殺か、凶器は？指紋は？目撃者は？
という感じでさまざまなことをヒアリングしたり調査します。

これ、すごく重要で、システムの問題だと思っていたら
誰かがオペレーションミスをしただけ、という運用の問題という
オチもあるので聞き込みはしっかりやります。

サイトが重い場合には
・データベースからレスポンスが返ってきていない
・アクセス集中でサーバの負荷が高い
・不要なループプログラムがメモリを食い尽くしている
といったように、１つの事象からでもさまざまな要因が考えられます。

上記要因は単なる一般論なので、根拠を立てるために
聞き込み結果とシステム基礎数値の面からアプローチします。
プロセス数、CPU使用率、メモリ使用率、アクセス数、等々
事象を理解するための手がかりはシステム側からも取得できます。

たとえば、昨日の100倍のアクセスがあったのならば、それが原因の可能性が高いですし、
メモリが振り切れるまで使われているなら、プログラムのどこかでメモリを大量に喰う処理を
している可能性が高いです。

このようなプロセスを経て問題の原因が突き止められてから初めて、
・アクセスに耐えられるサーバ構成にしよう
・メモリを喰わないようにプログラムを変更しよう
という問題解決のプロセスに入ります。

殺人事件には必ず犯人がいます
システムトラブルには必ず原因があります
人間は嘘をつきますがシステムは嘘をつかないので、
後者のほうが解決しやすいんでしょうねー。

誰だってプロジェクトは予算通りで納期が守られることを願います。
クライアントもプロマネも開発者もデザイナーも。
でも火を噴くんですよねー。
みんなが望んでない方向になぜか行くんです。

で、火を噴かないためにはどうしたらよいか。
・クライアントとの信頼関係を日頃から築いておく
・要件/仕様を明確にするためにドキュメントに落とす
・テストは1人で担当せず、必ずダブルチェックを行う
といったことは大前提(あたりまえ)です。

火を噴くプロジェクトはいきなり噴火するのではなく、たいてい「予兆」
があります。
この「予兆」をプロマネが見抜くことができれば、消火活動へ早く動けます。

火を噴くかどうかの予兆を見極め、すばやく行動するためには、
１．自分なりのマイルストーン
２．自分なりの判断基準
３．上記１と２が満たされなかった場合の解決策
の３つを常に考える必要があります。

具体的に説明をしていきます。
１．自分なりのマイルストーン
例えばプロジェクトの期間が1月1日～3月31日の3ヶ月で、
4月1日にリリース予定の場合、中間の2月15日の段階で
「何がどこまでできていなければならないか」
を予め定義しておくことができます。

3月1日、3月15日といった節目となる日付でも同様です。
このマイルストーンがあれば、機能とスケジュールの両方から
チェックすることで、火を噴く可能性を客観的に判断することができます。

２．自分なりの判断基準
・結合テストでバグが20個以上出たら危ない
・徐々に遅れている開発が今日までに完了しなければ危ない
・中間報告会でクライアントの承認がもらえなければ危ない
といったように、プロジェクトの健康状態を自分なりに判断する基準を
持つべきだと考えています。
この判断をせずに色んなことを先延ばしすると、メラメラと燃える炎が見えてきます。

３．上記１と２が満たされなかった場合の解決策
この３つめが一番大切です。
絶対に火を噴かないと言い切れるプロジェクトなんてありません。
僕もいつか噴くかもしれないと思いながら日々過ごしてます。
ただし、
・火が噴いているのに解決策が思い当たらない
・火が噴き始めたが解決策は準備してある
の２つでは大きな差があります。

解決策はたいてい
・人を投入する、人を入れ替える、人を再配置する
・追加予算を申請する、開発機能を削減する
・スケジュールを見直す
といったように、非常にシンプルです。
（この解決策をクライアントに通すために日頃の信頼関係が超大事！）

火を噴きそうだったけど予兆を見極めて何とか乗り越えた、
という感覚は自分しか分かりませんが、それを感じられたら
火を噴く可能性を低くするマネジメント力はかなりついていると思います。

–

プロジェクトマネージャーは日々色んな人からわがままを
言われる立場にあります。

あえて「わがまま」と書きましたが、これはプロマネ目線であって、
周りから見ると、「要求」や「意見」だったりします。

具体例で挙げると
・クライアントからは「当初の契約金額にこの機能開発も当然含まれてますよね？」
・開発メンバーからは「仕様が固まっていないのでこんなの開発できません。仕様を決めてください」
・上司からは「赤字にならないようにきっちり工数のマネジメントをするように」
と同じタイミングで言われた場合、プロマネは窮地に追い込まれます。

クライアントの要求を飲みすぎると、開発メンバーの負荷が高くなったり工数オーバー(赤字)になります。
クライアントの要求を飲まないと、プロジェクト運営そのものが立ち行かなくなる場合があります。

僕はいつも「全ての人のわがままを受け入れてあげよう」という気持ちでやっています。
実際にはわがままを言っている人はいなくて、それぞれの立場で当然のことを言っている
だけなのですが、「みんなわがままで仕方がないなー。」と思うことにしています。
そのほうが気持ち的にキャパシティを大きく持てるので。

で、結局プロジェクトマネージャーの仕事の大半は調整であって、
・人の話をよく聞いて、何を望んでいるのかを理解する
・理解した内容を関係者に伝え、具体的な行動に落とし込む
みんな自分目線で話をするので、翻訳・通訳といった調整が必要なんですね。

ときには「お願いします！」と頭を下げて、
ときには「それはできません！」と断って、
みんなのわがままが、ある程度通る最適な落としどころを模索します。

おもしろいことに、ある程度わがままをきいてあげると、
そのあとはスムーズにことが運ぶことが多いです。
このあたりは人間の心理なんですかねー。
わがままきいてもらったからしっかり仕事しないと、と思うのでしょうか。

大きなわがままをうまく調整して解決すると
結束力や信頼関係が生まれてきますよ。