敏腕PMブログ

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

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


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

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


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

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

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

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

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

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

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

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

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

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


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

開発案件がスタートするときにいつも考えるのが、
・ウォーターフォールでいくか
・アジャイルでいくか
・それぞれの中間でいくか
という開発手法の部分です。

以前から「アジャイル開発」という言葉には罠があると考えていました。
その罠というのは、
「細かな改善を加えていくのでウォーターフォールに比べお客様満足の高いシステムができる」
というものです。（完全に主観ですが。。）

ただし、アジャイルで開発する成功パターンの必要条件というものも
僕の中で考えがあって、それは
・お客様の要望をプログラム実装イメージまで仕様を決める人間がすぐに落とせること
・開発者がお客様の業務要件まで深く理解してシステムを実装できること
・開発者が一般的な開発者と比較し、10倍以上の高い生産性を持っていること
です。

上記条件が揃わないと、
・永遠にお客様の要望を取り入れ続けるけどシステムは永遠に完成しない
というお客様にとっても、開発側にとっても、残念な結果をもたらすと思っています。

社内のエンジニアにそのような話をしたら、「アジャイル宣言」を教えてくれました。
-「人と人の対話」 を　「プロセスとツール」 より優先する
-「動作するソフトウェア」 を　「包括的なドキュメント」 より優先する
-「顧客との協調を」 を　「契約交渉」 より優先する
-「変化への対応を」 を　「計画の遂行」 より優先する

すごくまとまっていて、本当にそのとおりだー、という衝撃を受けました。
でもやっぱり、罠があるよなーと再認識しました。

—

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

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

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

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

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

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

—

さて、今日は弊社の社員にブログに書いてほしいネタを聞いてみました。
そこで出たお題が「仕事に取り掛かる上で何を考えて始めるのか」です。
これ、重要ですね。

ではズバリ何を考えているかですが、
その仕事で「成果が出た」状態はどんな状態かを考える、ですね。
・売上が上がった
・コストが下がった
・お客さんが喜んでくれた
・次のフェーズの契約が取れた
等々色々とあるのですが、自分の中で「成果」を定義します。

その次に、成果を80点、100点、120点の3段階くらいに分けます。
・80点 ⇒ 必ず達成しなければならない成果
・100点 ⇒ お客様に喜んでもらえる成果
・120点 ⇒ お客様に驚かれる成果
のイメージです。

もちろん狙うは120点です。
80点と100点の違い、100点と120点の違いはどこから来るかと言うと
ちょっとした気遣いだったり、自分のがんばりだったり、メンバーの協力だったりします。
いかによく考えて行動したか、ともいえます。

プロジェクトが終わったときにお客さんが
100点の成果だったら拍手をしてくれます
120点の成果だったらスタンディングオベーションをしてくれます
一度スタンディングオベーションを味わうと、必ずもう一回味わいたいと思います。
オーケストラやオペラの出演者の気分ですね。

120点の成果は成功体験となり、1度成功体験を得た人は、また次の成功体験を
得るためにがんばります。
同じやり方では満足できず、またさらに創意工夫を持って仕事に取組みます。

といったことを考えて、仕事に取り掛かってます。
自分だけでなく、メンバーにも成長してもらうには、
成功体験を得てもらうのが一番いいと思います。

—

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

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

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

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

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

—

・相手の言っていることが理解できない
・こちらの意見が伝わらない
・勘違いされてしまった
等々の「ミスコミュニケーション」は日々起こるものです。

特にお互い知り合ってから歴史が浅いと起こりますね。
「あの人とは価値観が違うから仕方がない」
とあきらめるのは簡単ですが、仕事だとそうも言ってられません。

ミスコミュニケーションをなくしていくことも
プロジェクトマネージャーの重要な仕事の一つです。

僕がよくミスコミュニケーションに出会ったときに考えるのは、
なぜ自分と相手の考え方が違うのか？
という部分です。
目の前の議論で意見が食い違っていても、その事象だけに絞るのではなく、
もっと範囲を広げて原因を探ります。

・幼少期の体験
・家族構成
・経験してきた会社のカルチャー
・今までの仕事スタイル
・仕事とプライベートのバランス
・モチベーションの源泉
等々ざーっと思い浮かぶ部分を挙げて、相手が「なぜその考えや行動に至るのか」
を探ります。

「なるほどそういう考え方の人もいるんだなー」
の連続ですね。
これをずっと続けていくと自分が歳を重ねるごとにより多くの人を理解できるようになる
気がしてちょっと未来が楽しくなります。

–

口頭によるコミュニケーションは会話のキャッチボールです。
僕は小学生の頃ソフトボールをやっていました。
キャッチボールのときは、相手の胸にボールを投げるよう教わりました。

コーチとキャッチボールをしていて、コーチの頭の上にボールを投げてしまったときには、
「頭の上じゃない、胸だ」という言葉と共に、
コーチはグラブを頭の上から胸まで動かします。
どれだけ僕が投げたボールが目的の場所と違っているかを示すためです。

それを見て僕は、あと50センチ下のほうに投げなければ、と気づくわけです。
で、何が言いたいかというと、
会話のキャッチボールでど真ん中（胸）にボールが来なかった場合には、
どれだけずれているかを相手に伝える必要があります。

前回の赤色、紫色、赤紫色のたとえ話を例に出すと、
赤紫色を相手に伝えたいのに、相手は赤色と紫色の2色をイメージしていた場合には、
「あなたのイメージしている色は赤色と紫色なのですが、
僕が伝えたいのは、赤色50%、紫色50%を混ぜた色なのです。」
と伝えるわけです。

①まず相手が何をイメージしているのかを伝えて、かつ
自分が相手のイメージを理解できていることを伝える
②次に自分のイメージと相手のイメージがどれだけ違っているかを伝えて、
その違いを無くすためにはどうすればよいかを伝える
これが僕が考える会話のキャッチボールです。

相手の想いを理解する⇒違いを定義する⇒違いを埋める言葉を選ぶ
こんなイメージですね。
これを繰り返すと次第に胸から胸へボールが渡されるようになります。

—

昨日はあるプロジェクトのリリース日でした。
そこで今日はリリースにまつわるお話を。

「徒然草」の中に「高名の木登り」という話があります。
師匠と弟子が出てくるのですが、師匠は弟子が木の高いところに
上っているときには何も言わないのですが、
木から降りてきてもう安全な状態になったときに、「注意せよ」
という指示を出します。

「安全な状態になったときに油断するから、気をつけよ」
という師匠から弟子への教えです。

プロジェクトにも同じことが当てはまります。
リリース当初はプロジェクトメンバーも気を張っているので、
作業も丁寧に行います。

これがリリース後1ヶ月も経つと、
・作業中にデータベースのレコードをうっかり消してしまったり
・1ヶ月蓄積されたデータが不整合を起こすことが発覚したり
・機能追加したら元のプログラムがデグレしたり
ということがよく起こります。

気の緩みや集中力の欠如が原因です。
なので僕はリリース当初よりかは、メンバーの気が緩む可能性のある
1ヶ月後くらいが一番緊張します。
（何か起こるのではないか？と思っています。）

木登りもプロジェクトも同じですね。

–

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

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

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

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

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

–

基本的にはプロジェクトマネージャーは楽天主義がいいと思います。
心の中ではつらいことや悩みがあっても、お客様やメンバーには
見せない、というのが重要だと思います。

ただし、PMはプロジェクトの「リスクコントロール」はしなければなりません。
リスクがあるにも関わらず、「大丈夫大丈夫」と言っているようでは、
メンバーのほうが不安になりますので。

リスクに臆病になりすぎてもだめだし、リスクを察知できなさすぎてもだめ。
微妙なさじ加減が難しいところです。

僕はいつも提案書を作るときや、お客様との打合せの前には
「本当にこれでいいのか？」という視点で自分の作ったものや、行動を
客観的に見直すことをやってます。
それを勝手に「健全な不安」と名づけてます。
（本来の使い方として正しいかは分かりませんが）

例えば、「システムが動かないのではないか？」という考え方って非常に重要で、
それがあるからこそテストをきっちりやろうという発想になり、
スケジュールを立て、実行していくんだと思います。

なので、気持ちは楽天的だけど、頭の中には健全な不安を持っている、
というのがPMとしてバランスの取れた状態と考えています。

–