敏腕PMブログ

村瀬です。こんにちは。

先週末、約１ヶ月に渡って行われたサッカーワールドカップ南アフリカ大会が、全て終了しました。
試合時間が深夜だったので、遅くまで起きて試合を観た次の日に、会社で眠い目をこすりながら仕事をしていたという方も多いのではないでしょうか。

さて今回のワールドカップ、最終的にはスペインの劇的な初優勝で幕を閉じたわけですが、同時にチーム「マネジメント」の重要さがよく表れた大会でもあったと思います。
象徴的だったのが、前回準優勝ながらグループリーグで敗退したフランスと、そして限りなく低い前評判を覆して決勝トーナメント進出を果たした我らが日本代表です。

フランスは当時世界ランキング9位の強豪国であり、グループリーグの突破は確実視されていましたが、選手と監督との確執からチームが崩壊し、結局1勝も挙げられずに南アフリカを去りました。
一方日本代表はと言うと、ワールドカップ本番前の強化試合で4連敗、前評判も最下位から2番目という惨憺たる状況でしたが、結果2勝1敗という素晴らしい成績で決勝トーナメントへと勝ち進みました。

この２つのチームの命運を分けたものは何でしょうか？

・・・そうです、「監督」です。
（もちろんそれだけではありませんが、何か１つを挙げるとすれば、やはり監督でしょう。）

世界9位の実力を持ちながら、監督と選手が対立し、グループリーグ最下位に終わったフランスは、その実力の何分の一も出すことができませんでした。
そのフランスに個々の能力では劣る日本が見事に決勝トーナメントへと勝ち上がったのは、持てる実力以上の力を発揮したからに違いありません。

この事実は、監督の「能力」が、これほどまでにチームのパフォーマンスを左右し、結果を変えてしまうことを意味しています。

では、監督の「能力」とは何でしょう。戦術でしょうか、状況判断でしょうか、指導力でしょうか。

どれも間違いではありませんが、私がこれが一番大切だと思っています。


「選手から信頼され、『この人のためにがんばろう』と思ってもらえること。」


プロジェクトのマネジメントでも同じことが言えると思います。

私も、『この人のためにがんばってやろう』、と少しでも思ってもらえるようなPMでありたいと、常々思っています。
 

さてここからは余談ですが、

もしフランス代表のドメネク監督がドラッカーの『マネジメント』を読んでいたら・・・ひょっとして違う結果になっていたのではないでしょうか。

そして日本代表の岡田監督はというと・・・・・・ワールドカップ前にドラッカーの『マネジメント』を読んでいたのかもしれませんね。

では、また。

こんばんは、浅田です。

ソフトウェア開発という仕事に関わっていると、
PMと営業の仕事の境目が非常にわかりにくく感じることがあります。

PMであっても、営業であっても、
プロジェクトの成功のために、
全力を尽くすという方向性は同じです。
なかなか境目をつけるのが難しいのですが、
あえて境目をつけるとすれば、
PMは製品としてお客様を満足するための仕事をするのに対して、
営業は感覚的にお客様を満足するための仕事をするのではないかと思います。

完全なパッケージ製品でないタイプのソフトウェアという商品は、
実際にソフトウェアが完成するまでどんなソフトウェアになるか、
目で確かめることが難しいものです。

ソフトウェア開発というものは、お客様からすると、
パソコンを家電量販店で買う感覚よりも、
美容室で髪の毛を切る感覚に近いのではないでしょうか。

美容室でお客様に満足してもらうためには、
お客様がどんな髪型を希望しているのかというのを感覚的に認識を合わせることと、
その希望通りの髪型に髪の毛を切る技術が必要になります。
ソフトウェア開発に当てはめると、
前者の感覚的な認識合わせが営業の役割で、
後者の技術的な仕事がPMの役割ではないかと思います。

自分がPM向きなのか、営業向きなのかを考えてみるときの、
一つの参考になれば幸いです。

それではまた。

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

皆さんは、こんな会話をした経験はありませんか？

「大橋さん、あの機能開発終わったんですけど、もうちょっと頑張りたいんです。」
「どうしたの？要求されている仕様や性能は満たしてるよね？」
「もっと、エレガントなやり方があるんじゃないかと思うんですよ…」

エンジニアとして、より良いプログラム、アルゴリズムへのこだわりは理解できます。
しかし要件を満たしている中でこの希望にOKを出すには、次の前提条件が必要であることに気づいていますか？

1. より良い方法が存在する
2. より良い方法に到達することができる
3. より良い方法で得られるメリットが、それに到達するコストより大きい

エンジニアの立場からすると、1.は“勘”でそれが存在すると分かるでしょう。しかし2.や3.については判断を誤って、つい熱を入れすぎてしまうことが多いようです。

2.を少ないコストで達成するためのサポートをしたり、3.のコストとメリットのバランスに目を向けられることが、敏腕PMへの第一歩と思います。

多くの場合“最適解”は存在せず、より良い成果やエンジニアの満足はコストとのトレードオフであることを忘れずに。

ではまた！

参考文献：林 千晶, 高橋 宏祐 『Webプロジェクトマネジメント標準 PMBOK(R)でワンランク上のWebディレクションを目指す』技術評論社 2008年

こんにちは。今回からこのPMブログに参加することになった村瀬です。

どうぞよろしくお願いします。


自分もそうですが、お客様の声を直接聞く立場で案件に携わっていると、お客様から見積もりに含まれていない要望を頂くということがよくあります。

これはプロジェクトマネージャーとしては、要件定義段階でお客様の要望を把握しきれなかったということで反省しなければならないのですが、やはり画面を見てみないと、あるいは実際に使ってみないとわからないことというのはあるもので、致し方ない面もあります。


さて、ではこのような場合にどう対応するのか、という点は、プロジェクトマネージャーにとっては非常に慎重な判断を求められる場面だと思います。

なんでもかんでも安請け合いすればプロジェクトメンバーに無理を強いることになりますし、かと言って「見積もりに含まれていないから」と杓子定規に断っていては、お客様の信用を失いかねません。

今の私はこう考えています。

『がんばれるかぎり、なんとかお客様の要望に応えたい！』と。

これには私がキャリアをSIerでスタートしたことも関係していると思いますが、自分は今のところ“お客様寄り”のスタンスであると自覚しています。
（エンジニアのみなさんからブーイングが聞こえてきそうですが・・・当然限度はありますよ！）

私がこう思う理由は、結局のところ我々の生産活動の最終目的が、お客様の満足だと考えているからです。お客様は、満足の対価としてお金を支払ってくれます。少しがんばって要望に応えることによって、次のおシゴトにつながる可能性だってあります。

そしてまた、最近の「もしドラ」のヒットで再ブームが到来中のドラッカーもこう言っています。

『「われわれの事業は何か」との問いに答えるには、顧客からスタートしなければならない。』

お客様は神様とまでは言わないのですが、みんなをHAPPYにしたい、でも誰かを一番に考えなければならない・・・としたら、

やっぱりお客様が最優先になるのだと、私は思っています。


参考文献：P・F. ドラッカー 『マネジメント - 基本と原則 [エッセンシャル版] 』ダイヤモンド社 2001年

こんにちは、輪湖です。

私は、これまでプロジェクトマネジメントというものを、（お恥ずかしながら）すごく荒っぽくいうと次のような認識で捉えていたと思います。
プロジェクトの全部を一人でやるつもりなんだけど、それだとコストがかかりすぎるので、チームに助けてもらう。だから、メンバーのスキルや興味に応じて、タスクに分解して、アサインし、その残った部分を自分がやる。もしメンバーの中でそのタスクをできなかったら、最後は自分が巻き取る。全てを引き受け、ハブとなり、自分の責任下でやる、そんなスタンスでいた気がします。それでやりきった時は、達成感と共に評価もされてきたように思います。

それは、自分の任された領域が小さい時にはワークしていました。でも、（今から思えば当たり前ですが）その領域がいろいろな面で自分の扱えるレベルを超えたあたりから、それが回らなくなってきて、失敗を経験しました。そのことは、結構ショックでしたが、同時に少し謙虚になることを学んだ気がします。

そして、その限界を抱えながらも、これから成長していくに当たって、私自身は今後次のテーマ（問い）を追って行きたいと思っています。以下は、あくまでも問いに過ぎませんので、解は今のところありません。悪しからず。

・プロジェクトの規模と変化にいかに対応するか
例えば、旧東京三菱銀行、旧UFJ銀行の合併の際のシステム統合プロジェクトは、総費用2500億円、開発工数11万人月、技術者はピーク時で6000人が投入されたといいます。このプロジェクトのPMは、何をしていたのか。何をどこまで把握すべきで、どこからは把握しなくても良いのか。チーム体制は？、スケジュール感は？、コミュニケーションは？、、、数え上げれば山ほど聞きたいことはありますが、「規模」によって増す複雑度にいかに対応していくか、想定外のトラブル/課題という「変化」にいかに対処していくか。それはこれまでも考えてきたことですが、よりスケールするやり方を考えなければと思っています。

・複数のプロジェクトをいかに扱うか
マネージャー陣を束ねるような立場になると、複数のプロジェクトをマネージする必要があると思います。その時、プロジェクトをポートフォリオ的に考え、何をどう評価するのか、全体最適の視点から、いかにリソースを配分していくか。これは、未経験ですが面白い挑戦だと思います。

・何がプロジェクトから新しいモノを生み出すのか
しっかりとした計画に基づき、決められたモノをいかに着実に遂行していくか、それも一つだと思います。ただ、一方で、集団の中からいかにクリエイティブなモノを生み出していくか。そこにもノウハウや仕組みがあるような気がします。そのプロセスに必要な人材は？、スキルは？、役割は（マネージャーという役割は必要なのか）？、コミュニケーションは？、、、、そのプロセスは従来の「マネジメント」という概念の範疇では扱えない気がして、今すごく興味があります。糸口は、IDEOというデザインコンサルティング会社が用いている製品開発プロセス、その背景にあるデザイン思考という考え方がキーワードになる気がしています。

皆さんは、どんな問いを立てているのでしょうか？
ぜひ教えてください！それでは、また。

こんばんは、浅田です。

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

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

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

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

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

それではまた！

 

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

皆さんはチームで複数の意見から1つを選択する場合、どのような手法を使っていますか？多数決、を思い浮かべる方は多いと思います。

『多数決＝民主的＝チームの意見』という構図ですが、これは正しい捉え方でしょうか？

例えば5人のメンバーがいて、多数決でチームの意見を決めるとします。A案に3人、B案に2人となった場合、A案が採用されます。しかし、A案に同意しているのは5人のうちの3人で、残りの2人は違う意見を持っています。過半数が同意と捉えることもできますが、およそ同数の人たちは同意していないのです。

ここから分かるとおり、多数決はチームの半数の意見を無視する可能性があり、緊急性のある場合を除き採用すべきではありません。（多数決の代名詞、選挙では選挙日に必ず決定を下す必要があるため、この方法が合理的なのです。）

ではどうすればいいでしょう？可能な限りチーム内で意見を検討し、チーム全体で合意を取るのが理想です。その際には期限をもうけ、もしも期限までにチームで合意に達しない場合には、PMであるあなたが判断を下します。

“PMによる判断”は民主的ではありませんが、チームの半分を無視する多数決より、よほど納得のいく場合が多いのです。もちろん事前に、このプロセスで進めることに合意を取ることを忘れずに！

ではまた！

参考文献：ロバート・B・チャルディーニ 『影響力の武器―なぜ、人は動かされるのか』誠信書房 1991年

こんにちは、輪湖です。

プロジェクトマネジメントという仕事は、極論すれば、無秩序の中に秩序を創り出すことだと思っています。
どう扱っていいか分からないような複雑な問題に対して、（無理やりにでも）枠をはめ、ある軸で分解し、整理し、タスク化し、担当者をアサインし、スケジューリングする。PMは、その問題をどう認識し、どう切って、どう対処するか、その判断力が問われ、その分解したタスクを計画通りに遂行することが求められます。
私は、様々な方法論や手法をベースにしつつも、この料理の仕方にある種のクリエイティビティがあると思い、そこにこの仕事の面白さを感じています。

一方で、プロジェクトは生き物であると言われることがあります。生き物＝流動的であるという意味でその通りだと思います。
プロジェクト中にも、顧客の要求は変わり、メンバーのモチベーションは上下し、想定外の問題は起きます。計画は予定通りに進むことに越したことはありませんが、そうは行かないのが現実です。そんな困難な場面、刻々と変化する状況にどのように対処するか、PMはこういったことへの対応能力も必要だと感じるようになりました。また同時に、この能力はこれまでのPMスキルセットではカバーできない領域なのだとも感じています。

このことを、ジョン・コッターは、次のように表しています。
「マネジメントは複雑性に対処し、リーダーシップは変革を推し進める」

「変化」への対応、それはもはや「マネジメント」ではなく、「リーダーシップ」であるとの指摘です。リーダーシップとは何か、これを理解し、体得するには自分もまだまだ精進が必要ですが、PMは、テクニカルな知識・スキルだけでなく、もっと全人格的なモノだと思い、また気を引き締めたところです。

[参考文献]
Amazon.co.jp： MBAリーダーシップ: グロービス・マネジメント・インスティテュート, 大中 忠夫: 本

Amazon.co.jp： リーダーシップ論―いま何をすべきか (ダイヤモンド・ハーバード・ビジネス経営論集): ジョン・P. コッター, John P. Kotter, 黒田 由貴子: 本

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

ではまた！

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