敏腕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というデザインコンサルティング会社が用いている製品開発プロセス、その背景にあるデザイン思考という考え方がキーワードになる気がしています。

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