敏腕PMブログ

前回のブログで「成功体験」という言葉を使いました。
でもこの成功体験って、体験した人としていない人がいて、
また個人の解釈によっても違うものだと思います。

成功体験を得られる条件としては以下の2点だと思ってます。

１．自分が「やったぞ！」と満足感を得られること
２．他人から「よくやったね！」と賞賛されること

オリンピックのフィギュアスケートにたとえると、
１．満足のいく滑りができた(自分としての「やったぞ！」)
２．金メダルを取って表彰された(他人からの「よくやったね！」)
という感じです。

１だけだと、自分がすごい滑りなのか、普通の滑りなのかが
イマイチわからず、２の金メダルが１を納得させる根拠になります。

仕事でも同じで、自分でやったぞ！と思えるのもすごく重要なのですが、
周りの人（お客様、同僚、社長、家族）から「よくやったね」と言われて
初めて自分がやったことに対する納得感が得られると思ってます。

好きな人に告白してOKがもらえたら、「やったぞ！」と思いますよね？
かつ、周りから「おめでとう！」と言われたらさらにうれしいですよね？
これも一つの成功体験だと思ってます。

人は1度成功体験を得られると、さらに大きい成功体験を求めるように
生まれながらにしてプログラミングされているのではないでしょうか。
なのでスポーツでも、ビジネスでもより大きな成果をみんな求めてがんばるんだと思います。

プロジェクトマネジメントでも、より大きな仕事、より難易度の高い仕事、
よりお客様に喜ばれる仕事、を求めるＰＭは多いのではないでしょうか。
僕もその中の一人です。

–

プロジェクトを行ううえで、知識は多いほうがよいと思います。
・お客様の業界情報、会社情報
・技術トレンド
・プロマネ手法
クライアントに提供できる情報価値が高いほど、プロジェクトマネージャー
の価値は高まるので、本を読んだり人の話を聞いて知識は蓄積すべきだと思ってます。

でも、
知らないほうができることもプロジェクトの世界ではあるんです。

僕の体験談でお話します。
ある大手企業さんに業務改善の提案をしたことがありました。
僕が25歳のときで、相手のオーナーさんは50歳くらい。
ちょうど倍の年の差ですね。

業界知識はもちろん相手のほうが圧倒的に上、
25歳の若造が生意気にコンサルなんて名乗って
生半可な気持ちで改善提案なんかできないのです。

でも何とか提案書を書いて受注までできました。
でもこれはオーナーさんが僕を試すために発注したのです。
やれるならやってみろ、という感じですね。

案の定プロジェクト報告会で１度大きな失敗をしました。
分析が甘いのを見破られ、
「このままじゃお金を払えないね」という痛烈な言葉をいただきました。

そこから必死になってリカバリーをしました。
オーナーさんが知りえない情報を現場をかけまわって集めて、
オーナーさんの視点と現場からの視点を含めて、
改善案を考えてオペレーションレベルまで落とした提案を行いました。

必死さが伝わったのか、最終的にはオーナーさんに納得をいただき、
自分としては仕事で初めて成功体験を得ることができました。

後日上司に聞いたのですが、僕が勝手に受注して勝手にプロジェクトを
進めていくので、気が気じゃなかったそうです。

でも僕はそんなこと知らなかったのです。
このプロジェクトを受注することにリスクがあるなんて知らなかったのです。
だからこそ辛かったけど成功体験を得られたと思ってます。

若いうちはどんどん失敗すればよいと思ってます。
経験が増えると臆病になったり安定志向になりがちです。
僕も知らないことはたくさんあるので、まだまだ武器にしていこうと思ってます。

—-

WEB制作やシステム開発を行う会社では
プロジェクト制で業務が動いています。

プロジェクト責任者 = プロジェクトマネージャー
でプロジェクトを成功に導くための全ての責任を負います。

ただし、プロジェクトは複数立ち上がっていても、最終的に会社の責任者は
社長一人です。

社長は経営の視点から各プロジェクトを評価して、個別プロジェクトの
継続 or 中断、人員投入 or 削減、規模拡大 or 規模縮小　等々の
判断を下していきます。

プロジェクトマネージャーが最適な選択だと思っていても、
経営者の視点からはそれが最適ではない場合があります。

会社は持続的な成長を遂げなければならず、必ず利益を出さなければなりません。
その観点から時にはプロジェクト撤退という苦渋の決断を迫られる場合もあります。

僕はいつも個別最適の総和が全体最適であるとは思っていません。
俯瞰的な立場で見ている人が出す結論は時には残酷です。
でもそれは全体最適の視点だから。

プロジェクトマネージャーをやっていると、会社の判断に納得が
いかないこともあると思います。
そのときに自分の視点を一つ上げて会社全体の最適を考えた
行動ができると、一つ上のプロマネになれると思います。

–

IT関連のお仕事を依頼されるお客様は
常に不安を抱えていらっしゃいます。

たとえば車を買う場合には試乗して乗り心地、ハンドルの感覚、加速度合い
等々を体感して購入を決定できますが、システムになるとそれは
難しくなります。
これから創っていくものを買うわけですから。

形のないものを購入いただく際には、安心感を持ってもらうことが
非常に重要です。
・この会社に依頼して本当にいいのだろうか？
・このプロジェクトマネージャーで本当に大丈夫だろうか？
・このシステムは壊れたり止まったりしないだろうか？

弊社も最近は上場企業や大手EC事業者様向けの
ネットショップ構築のお仕事が多いのですが、安心・安全な
サイトを構築するために、新商品をリリースしました。

その名も「EC-Orange エンタープライズ」
これまで多くのお客様より寄せられた要望をオールインワンの
形でご提供できるようになりました。
http://ec-cube.ec-orange.jp/

会社×プロジェクトマネージャー×システム　= 安心・安全なシステム構築
という図式が成り立てばお客様の満足度は格段に向上すると思います。
–

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

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

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

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

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

たとえ話でお話します。

マクドナルドの社長は元アップルの社長でした。
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業界は「若さ」が大きな強みです。
経験や年齢が価値を持たない時代だからこそ、
常に上のランクの仕事を意識すべきだと思います。

–