敏腕PMブログ

こんばんは、村瀬です。

みなさんは、「成長に必要な条件」というと何を思い浮かべるでしょうか。

環境でしょうか。
機会でしょうか。
指導者でしょうか。
それともやはり、向上心でしょうか。

私が、これらと同じくらいか、あるいはそれ以上に大切だと考えているもの、それは
『尊敬力』です。

尊敬力とは、自分よりも他者の優れている点を認め、敬うことのできる力だと考えています。
（「謙虚さ」と言い換えてもよいと思います。）

私は、自分以外の全ての人に、何かしら自分より優れている点があると思っています。
（逆に、「私はあの人には全ての面で勝っている！」なんてとても言えませんよね。）

人は、他者を見下してしまうと、ほんの少しでも見下してしまうと、その瞬間、もうその相手からは何も学ぶことができなくなってしまいます。

これは、その人から学ぶ機会を、自分を成長させる機会を自ら放棄しているに等しいことです。

ひとを見下すのはとても楽なことです。
なぜなら、そうすることで自分の優位性を、存在価値を確認することができるからです。
しかしこれに慣れると、常にひとを見下していなければ、自分を保てないようになってしまいます。

こうなるともう、成長どころではありませんよね。


あなたの『尊敬力』はどうですか？尊敬力が、あなたを大きく成長させてくれるはずです。

では、また。

こんばんは、浅田です。

ポジティブな人というと、前向きで自分に起こる出来事を
プラスに考える人というイメージがありますが、
中には自分に起こる出来事を自分の都合の良いように解釈して、
自分に甘い人がいます。

例えば自分が大きなミスをした時に、
それを大した問題ではないと都合よく解釈してしまうと、
自分に甘い人間になってしまいます。
逆に、自分がしたミスを活かして、
それを何のチャンスにするのかを考えて、
改善できるような人は非常にポジティブな人ではないかと思います。

さらにポジティブな人は、自分と一見関係のないような出来事も、
それを自分の成長のチャンスとして、自分事として考えて、
成長の材料にしてしまうような人だと感じます。

日々の何気ない出来事も自分に甘ければ何とも感じないけれど、
そこから何かを学ぼうとする姿勢で過ごすと、
勉強材料になる出来事がたくさんあることに気づきます。

本当にポジティブな人というのは、
目の前に起こった出来事を前向きに考えるというよりも、
普通にしていると、目に見えないチャンスを、
チャンスにしてしまう人なのではないかと思っています。

それではまた！

 

今回からこのブログに参加することになった浅田です。
よろしくお願いします。

早速ですが、本題にはいります。

自分が得意とすることには２つのパターンがあります。。
(1)初めから得意だったこと。
(2)初めは全然できなくて得意になれたこと。

自分が一人のプレーヤーとして働く場合は、
(1)のパターンが当てはまる職種の方が、
活躍できる場合が多い。

逆に自分がマネージャになるなら、
(2)のパターンが当てはまる職種の方が、
活躍できる場合が多いのではないかと思います。

例えば、あまり努力せずにスーパー営業マンになれた人が、
マネージャになり、管理職になったとたんに、
活躍できなくなるケースが非常に多いです。
これは自分が簡単にできるようになったことは、
人にそれを転写することが難しいため、
チームメンバが育たないことが主な原因です。

一方で、まったく売れなかった営業マンが、
売れる営業マンになった場合は、
売れない時の気持ちも理解できるし、
売れるようになるには、どういうステップを踏むべきなのかを
人に説明することができるため、
チームメンバーが成長するので、
チーム全体の業績がよくなるという傾向にあります。

社会に出ると自分が得意でない仕事を任されることも多い。
仕事を初め優秀な周りのメンバと比較して、
劣等感を感じてしまうこともあるかもしれません。
でもそんな時は、
「その仕事が得意になれれば、
その分野で優秀なマネージャになれるチャンスがある」
という気持ちで仕事に取り組めれば、
仕事が面白くなるのではないかと思っています。

 

こんにちは。癒し系PMの大橋です。

プロジェクトの中にはうまく行くものと、あまりうまく行かないものとあります。ではその成功／失敗の原因にはどのようなものがあるでしょう。能力？運？難易度？努力？

例えば、こんな話を聞いたことがあるのではないでしょうか？

今回のプロジェクトは成功した…それは運が良かった、簡単（難易度）だったから。
今回のプロジェクトは失敗した…それは自分に能力が無かったから。

え！？自分と同じですって？
実はこれ、最悪のパターンといわれています。4つの原因は、次のように分類できます。

自分の問題…能力　努力
外部の問題…運　難易度

ここで先の考え方をもう一度見てみると、成功は外部の原因、失敗は自分が原因としていますね。これでは成功しても自信は付きませんし、失敗した場合は「自分はダメだな…」となり、落ち込んでしまいます。

ではどのように捉えると良いのでしょう？

今回のプロジェクトは成功した…それは自分の能力があったから。
今回のプロジェクトは失敗した…それは自分の努力が足りなかったから。

こう考えれば、成功したときには自信が高まりますし、失敗しても「次はもっとがんばるぞ！」と前向きになれます。実は、社長など成功者にはこのパターンの考え方をする方が多いという調査結果があります。（あの中田英寿氏もそうらしい！）

でも自分の能力って…ちょっとナルっぽいですか？その場合は、やはり成功の原因も努力と捉えてみてはどうでしょう。「がんばった甲斐があった！」って、周りから見ても気持ちがいいですよね。

成功も失敗も、全ては経験であり、成長の糧です。ちょっとの考え方の差で、あなたの、そしてチームメンバーの成長スピードが変わってきますよ。

ではまた！

参考文献：津田 秀樹『ジーパンをはく中年は幸せになれない』アスキー・メディアワークス 2009年

皆さんこんにちは！エスキュービズムの大橋です。

今日からPMブログの執筆陣に加わることになりました。3人の中では癒し系のPMとして、皆さんに役立つ情報を提供できたらと思います。

さて、今回のお題は『モチベーション』です。PMのスキルを語るときに、チームメンバーのモチベーション云々というのはよく言われます。でも、モチベーションをAgeる要素って何だろう？最新技術？プロジェクトの規模？そう、なにがモチベーションを高めるかは、人それぞれです。

では逆に、モチベーションをSageる要素って何でしょう？1つには『ストレス』があるのではないでしょうか。

ストレスは『時間的裁量権（時間の自由度）』と『心理的ノルマ（やらされてる感）』に大きく影響される、という説があります。たとえば仕事量はさほど多くなくても、時間的裁量権が少なく心理的ノルマが多い（そのため達成感の得にくい）ウェイターやラインの組立工といった職業はストレスの多い職業といえます。一方、仕事量は膨大なのに、達成感があり時間的裁量権の多い医者や弁護士といった職業は、以外にストレスが少ない職業といわれています。

つまりストレスは必ずしも仕事量に左右されるわけではなく、達成感や時間の自由度に大きく影響されます。

そこで、たとえばエンジニアのモチベーションが下がっているな、と感じたときは、仕事の時間の一部を自分のやりたい勉強に使うことを許したり、早めに帰らせて時間の自由度を増やすことで、結果的にストレスが下がりパフォーマンスを上げることができるかもしれません。

逆に、仕事が終わっても早く帰りにくい（時間の自由度が奪われている）、なんて職場になってたら、危険ですよ！

今回はストレスについての1つの考え方をご紹介しました。こういったメンタルな面は経験も重要ですが、知識量でも大きく対応が違ってくると思います。ぜひ皆さんも、いろんな考え方を学び、実践して、PM力を高めてください。

ではまた！

参考文献：松崎 一葉『会社で心を病むということ』東洋経済新報社 2007年

すごーく技術的に高いレベルのスキルを持っているエンジニアが、
「システムのことは分かるけど、業務は分からないので、、、」
と言って業務仕様を理解しないケースがあります。

・業務仕様の詰めはプロジェクトマネージャーの仕事、
・詰まった仕様をシステムとして実現するのがエンジニアの仕事
という暗黙の前提があるのかもしれません。

でも、
業務仕様を理解しているエンジニアってものすごく強いんです
1人でお客さんと仕様を詰めて、開発までできる。
もう少し大げさに言うと、「構想と具現の両方ができる」

僕は昔プログラミングをしてましたが、今はもうスーパーエンジニアの方々には
到底適わないので、やっぱり実装できる人は強いなーといつも感じます。
さらに業務の奥深くまで理解していたら、鬼に金棒です。

プログラマー⇒SE⇒PL⇒PMとキャリアを重ねていく上で、
必ず技術的な部分だけでなく、お客様の業務を理解しなければならない局面に出会います。
その時にぜひエンジニア魂の強い人は業務から逃げないでほしい。

ITコンサルの世界では必然的にお客様の業務を理解しないといけないのですが、
若いときにバリバリのシステム開発に携わった人は
30代以降ものすごい力を発揮します。
なので、優秀なエンジニアこそ業務から逃げないでほしいのです。

—

お客様は何らかの課題があるので仕事を外部に依頼します。
なのでプロジェクトは課題解決の連続です。
プロジェクトマネージャーは課題解決の責任者です。

課題解決の第一ステップはまず課題を定義することです。
これが意外に難しい。
例えばECサイトをリニューアルしたいお客様の場合、
課題は何かしらあるのでしょうが、
・売上が思うように伸びない
・サイト内で商品が検索しずらい
・そもそもサイトへのアクセス数が少ない
といったように、多岐に渡ります。

忘れてはならないのが、課題は定義しっぱなしではいけません。
課題には必ず解決策がセットになります。
「売上が思うように伸びない」という課題を定義するなら、
「売上げを伸ばす」解決策も提示できなければならない。

弊社で大切にしている言葉で、
・できない理由ではなく、できる理由を考える
というのがあります。
・課題を定義するだけではなく、解決策を考える
というのと同じです。

「○○という理由だから△△ができません」
ではなく、
「○○という課題がありますが、□□によって解決は可能です」
という発想と行動が大事です。

—

若手メンバーに仕事を任せる場合によくあることなのですが、
「まだ私にはできません」
「もう少し成長してからでお願いします」
という返答をもらうことがあります。

僕は「なんてもったいない！！」
と思います。
まだちょっと早いくらい、重々承知しています。
でも挑戦させてみたいのです。それを乗り越えて成長してほしいのです。

基本的に仕事を任せる場合には、「できそうだから任せます」
ただし、前提があって、「ちょっと背伸びしたら」という枕詞が付きます。
「ちょと背伸びしたらできそうな仕事を」任せて、苦労して乗り越えてもらって、
成長してもらいたいのです。

特に20代、30代は自分の能力が「足りてないことを恐れない」
気の持ち方が重要だと思います。
プロジェクトマネージャーも同じで、
・大きい規模だからできない
・お客さんが気難しいからできない
というのではなく、今の自分ではできるかわからないけど、
それでもやってみる、という気概がほしいものです。

僕も新しい仕事に向かうときには
「今回はちょっとやばいなー」と思うことは多いですが、
いざ走り出してみると、いろいろな作戦を練って解決していけるものです。

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

–