敏腕PMブログ

振り返りとフィードバック

admin — Mon, 27 Sep 2010 01:28:39 +0000

こんにちは、村瀬です。

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

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

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

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

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

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

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

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

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

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

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

継続は力なり、です。

では、また！

プロジェクトはニ度完成させる。

admin — Tue, 21 Sep 2010 07:42:51 +0000

こんにちは、浅田です。

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

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

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

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

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

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

それでは、また。

最初のスタンプ

admin — Thu, 09 Sep 2010 03:41:33 +0000

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

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

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

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

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

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

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

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

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

ではまた！

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

成長の大前提

admin — Fri, 03 Sep 2010 09:35:41 +0000

こんばんは、村瀬です。

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

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

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

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

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

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

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

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

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

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

では、また。

優れたプロジェクトマネージメントツールとは

admin — Fri, 27 Aug 2010 14:42:19 +0000

こんばんは、浅田です。

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

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

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

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

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

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

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

コストと機能のトレードオフ

admin — Wed, 11 Aug 2010 06:52:34 +0000

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

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

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

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

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

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

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

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

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

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

ではまた！

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

もしサッカーの代表監督がドラッカーの『マネジメント』を読んだら

admin — Wed, 14 Jul 2010 02:35:37 +0000

村瀬です。こんにちは。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

では、また。

PMと営業の境目とは

admin — Fri, 09 Jul 2010 11:26:52 +0000

こんばんは、浅田です。

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

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

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

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

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

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

それではまた。

“最適解”はいずこ…

admin — Sun, 27 Jun 2010 17:07:17 +0000

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

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

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

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

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

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

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

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

ではまた！

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

見積もりにない要望を受けたら・・・？

admin — Wed, 09 Jun 2010 11:15:44 +0000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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