敏腕PMブログ

こんにちは、村瀬です。

振り返りとフィードバックは、仕事にはつきものです。

それは１年間の振り返りであったり、プロジェクトの振り返りであったり、工程の振り返りであったりします。

振り返った結果を仕事のやり方にフィードバックし、そのサイクルを繰り返すことの大切さは、今更説明するまでもないですよね。
会社に入って初めての研修で、『PDCAサイクルを回せ！』と習った方も多いのではないでしょうか。

ここで、日々の仕事に目を向けるとどうでしょう。

毎日日報を書いている方もいらっしゃると思います。また、一日の終りに「今日はよく働いたなぁ」とか、「今日は全然集中できなかったな・・」とか感じることのある方も多いのではないでしょうか。

しかし、考えてみると、これだけでは「振り返りとフィードバック」のうちの「振り返り」しかしていないんですよね。

初めの方で、１年・プロジェクト・工程といった単位での振り返りを例に挙げましたが、これらは当然日々の仕事が積み重なったものです。

もし、日々の仕事の中で「振り返り”プラス”フィードバック」を行い、日一日とやり方を改善していくことができたら、それはもう絶大な効果につながるであろうことは簡単に想像できますよね。

やり方はいろいろあると思います。

細かく作業記録をとるのもよいでしょうし、このようなツール(ブラウジングの時間を計測してくれるツールです)を使用してみるのもよいかもしれません。


これを習慣づけることはなかなか簡単ではないと思いますが、チャレンジしてみる価値はあるのではないでしょうか。

継続は力なり、です。

では、また！

こんにちは、浅田です。

システム開発をする際に、最も有名な手法の分類として、
ウォーターフォールモデルと
プロトタイピングモデルがあります。

実際の開発では、どちらの手法でも長所と短所がありますが、
プロジェクトマネジメントとしては、
プロトタイピングモデル
に近い方法でマネジメントを行う方がいいと考えています。

プロジェクトを成功させるためには、
ＰＭが一度プロジェクトのすべての工程を頭の中で、
完成させる必要があり、
その完成した像を何度もブラッシュアップさせて、
本当の完成に近づける必要があると思います。

マネジメントをウォーターフォールで行うと、
途中で難題にぶち当たった際に、
完成までのイメージがないまま、
プロジェクトを進めることになり、
大変危険な状態になります。

プロジェクトマネジメントでは、
はっきりとした道筋でなくとも、
ゴールまでの道筋を必ずＰＭが、
持っておくべきなのではないかと思います。

ＰＭは一度目は自分の頭でプロジェクトを完成させ、
二度目は実際のシステム開発でプロジェクトを完成させる
必要があるのではないかと考えています。

それでは、また。

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

皆さんはガソリンスタンドやレストランで、スタンプカードをもらったことがありますか？10個スタンプを集めると1回無料、というあれです。

このスタンプカード、あらかじめ2つスタンプが押されていることがあります。考えれみれば、10個のスタンプ欄に2つ押されているのと、8個のスタンプ欄を作るのとはゴールは同じです。

でもゴールに達する率は、2つ押されているほうが倍近いという調査結果があります。

これはプラセボ効果の1種で、スタート時点で20%が終了しているのと、ゼロからのスタートとの違いがこの結果を生んでいると考えられています。

つまり、人は短いゴールのスタート地点より、長いゴールの途中まで終わっているほうがやる気が出るのです。

開発プロジェクトには長期にわたるものや、困難な技術課題がいくつもあります。
そんな時、やる気の低下しているメンバーがいたら、チームに押せる最初の2つのスタンプを探してみてください。

「困難な課題だけど、○○案件で一度やってるよね？」

こんな一言が、チームにやる気を与えますよ。
高いハードル、新しいチャレンジも大事です。でも時にはすでに達成している事を探して、ハードルを下げてあげるのも敏腕PMの役割です。

ではまた！

参考文献：チップ・ハース, ダン・ハース『スイッチ！』早川書房 2010年

こんばんは、浅田です。

世の中には、たくさんのプロジェクトマネージメントツールと
呼ばれるものが存在していますが、それをうまく使っている人を
見ることは少ないのではないかと思います。

それはプロジェクトマネージメントでは、
どんなツールを使うか、どんな手法を使うかと
いうよりも根本的に必要なことがあるからだと思っています。

私が考えるプロジェクトマネージメントの能力とは、
プロジェクトの完成までに必要なタスクを
いかに洗い出すことができるかだと思っています。

プロジェクトが厳しくなる大きな原因として、
当初は想定されていなかったことが、
納期間近で発見され、その対応をするため、
スケジュールが遅延することが多いです。

また、単純に一つのタスクに思ったよりも時間がかかってしまう場合も、
そのタスクをさらに細分化して、やることを明確化できれば、
時間の遅延は少ないのではないかと思います。

これは、プロジェクトマネジメントだけでなく、
目標管理でも共通したことであり、
目標までのプロセスがきっちりと細分化できれば、
達成できる可能性が高まるのではないかと思います。

まとめると、プロジェクトマネジメントでは
どんなツールを使うかというよりも、
やるべきことは漏れなく洗い出すことが、
一番大切なのではないかと思っています。

 

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

PMの皆さんの主な仕事に、顧客との開発内容の調整があると思います。
こんな経験、ありませんか？

1. 客先のトップからは、「3月オープン必達だからね」と言われる
2. でも現場担当者と話を始めると機能要望が次から次へ出てきて、開発内容が膨らむ
3. 気が付けば機能が増えすぎて、どう考えても3月に間に合わない ((((;゜Д゜)))

アルアルですって？これって何が悪かったのでしょうか。
現場担当者が要望をどんどん挙げたこと？それを引き受けてしまったこと？

敏腕PMとしては、客先トップの意識がプロジェクトメンバーに共有されていなかったことを問題と捉えるべきです。プロジェクトには、大きく分けて2種類あります。

A. コスト・スケジュール優先のプロジェクト
B. コストよりも、機能の多さや使いやすさ優先のプロジェクト

1.～3.を見てみると、1.で会社トップがスケジュール優先であると言っているのに、2.で現場担当者は機能優先で話をしてしまっています。

ここでPMとして、もう一度トップにコストと機能のどちらが優先か確認し、その意思をプロジェクトメンバーに伝えてもらうべきです。また、コストと品質はトレードオフの関係で、両方を全て実現するのは現実的でないことも共有すべきでしょう。

コスト・スケジュール優先の場合、あまり使わない機能は開発しないといった判断が必要ですが、コストこそが優先であるとプロジェクト全体で意識が統一されていないと話が進みません。

プロジェクトの初めでスケジュールが破綻しかけたら、コストと品質、どちらが優先か確認してみてください。

ではまた！

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

村瀬です。こんにちは。

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

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

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

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