敏腕PMブログ

プロジェクトには、お客様側に「プロジェクトオーナー」という人がいます。
大抵、お客様の会社の社長や役員、事業部長がオーナーですね。

でもこのプロジェクトオーナーって、ほとんど現場には出てきません。
週次の定例会にはほぼ出ない、月一の報告会にもほぼ出ない。
現場からは見えないところで決済の承認だけをしていることもしばしば。

でも最終的に説得しなければならないのが、このプロジェクトオーナーだったりするのです。
で、そもそも会って話ができないので説得ができない。
ではどうやって説得すればいいのか？

会えなくても説得できる方法を考えるんです。
僕はよく、オーナーまで伝わるような資料を作って
現場担当者に託します。
「これ、渡しておいていただけますか」
と言って、現場担当者がオーナーに褒めてもらえるような内容も
盛り込んで渡します。

具体的には提案書、要件定義書、プロジェクト結果報告書、等々の資料をオーナーさんを
読み手と考えて書きます。
オーナーさんは、現場でしか見えない情報を「わかりやすく」「簡潔に」まとめた資料を好みます。

オーナーさんがその資料を気に入ると、いろんな人に回してくれます。
資料は一人歩きするものです。
だから一生懸命作らないといけない、機能する文章を書かないといけない、

以前２５歳くらいで”ITコンサルタント”を名乗っていたら、
「お前らみたいな若造に何ができるんだよ！」と言われたことがありました。
なかなか認めてもらえないので、自分達の仕事をありのままに表現する資料を作りました。
それがきっかけでお客さんと円滑に仕事が進むようになりました。

うまいこと資料を一人歩きさせる技術を身につければ、
プロジェクトをコントロールしやすくなります。

資料に関して「考えて、書いて、一人歩きさせて、反応を見て」という
PDCAをずーっと回し続けるのです。

—–

4月なので新人研修真っ只中の会社も多いのではないでしょうか。
弊社でも社会人としてのマナーから業務オペレーションまで、
現在急ピッチで教育が進められています。

今回は成長する人としない人の違いについてです。

過去すさまじい速度で成長する人を色々と見てきましたが、
「伝えたことを素直に実行する人は成長が早い」
ですね。

これは教育する側になって気づいたことですが、
伝えたことを伝えたとおりにやらない人が多いです。
あえて「やらない」と書いたのは「できない」ことではないので。

僕が最初に見せる例を見てそのままやればできるはずなのに、
途中から自己流のやり方をまぜて最終的にはできなくなる。
資料作成でも商談の進め方でも同じ。

最初から自分オリジナルを出そうとして失敗する。
一足飛びに成果を狙おうとして陥るワナです。

知識や経験、センスがなくても、言われたことを言われたとおりに
実行する人が、成長が早い人です。
特に社会人になって間もない人に言えます。

「言われたことだけやってればいいんだよ！」
という言葉は少々言い方はきついですが、本質も含まれていると思います。

以前このブログで書いた、
・プロジェクトマネージャーも守（しゅ）・破（は）・離（り）
・はじめはモノマネから
も併せて読んでいただければ幸いです。

–

最近久しぶりに機能別の開発スケジュールを作成しました。
いつもは開発する本人に作成してもらいますが、
今回は短期でたくさんの機能開発が求められたので、
自分でざーっと引きました。
※なぜいつもは本人に作成してもらうかは別途書きます。

で、スケジュール作成のときのポイントを。
機能開発で、「検索・更新・削除」の3機能を3日で仕上げる場合を例にします。
縦軸に機能を、横軸に日付をとった場合に、

◆パターンＡ：1日1機能
・検索機能　－
・更新機能　　－
・削除機能　　　－

◆パターンB：3日で3機能
・検索機能　－－－
・更新機能　－－－
・削除機能　－－－

というスケジュールパターンが想定されますが、
どっちが良いスケジュールでしょうか？

僕はBのほうが良いスケジュールだと考えています。

理由は以下
・スケジュールは予定と実績を管理します。
1日毎に管理するより、ある程度まとまった単位で管理したほうが
開発者も管理者もラクです。（毎日進捗確認っていやですよね？）

・開発は後半のほうが慣れてきて効率が上がります
なので1日目は調子が悪くても、2日目、3日目で十分挽回ができます。
より実際に近いスケジュールがBなのです。

・Bの場合、開発順は開発者が自由に選択できます。
検索機能から作るより、更新機能を先に作ってそのデータをもとに
検索機能を作ったほうが効率は良いです。

・ある機能開発で煮詰まっても、他の機能開発に手をつけられる状態
にしておくことで、遅れを最小限にとどめられます。
スケジュールってあるとそれに従うので、Aのパターンだと初日は検索機能だけしか
やらない可能性があります。

以上、お役に立てれば幸いです。

—

・お客様からメンバーがクレームをもらった
・開発の進捗が思うように進んでいない
・お客様がなかなか要件を決めてくれない

プロジェクトでは色んな問題が発生します。
誰のせいだとか、何が悪いのかといったことを考えるのではなく、
僕はいつも「自分が原因では？」と思うようにしています。

なぜかというと、他人のせいにしたり、自分以外を原因にすると、
解決策の範囲が狭くなります。
（だって自分ではどうにもできないですから。）

言い方を変えると、自分が原因であれば、解決策は自分の中にあるんです。
そうなると自分の行動を変えることができる、問題を解決するきっかけを
自分から産み出すことができる。

マインドが変われば行動が変わる
行動が変われば結果が変わる

実際には自分が１００％悪いなんてことはないのですが、
心の持ち方一つでポジティブな解決策が見つかるものです。

会社の業績だって悪ければ最終的に責められるのは社長ですが、
社員が原因を自分の中にあると考えられる会社は、
内部から業績改善の芽が必ず出ます。

—-

最近ものすごく判断とか決定とかをする機会が多くなってきていて、
未知の領域の仕事も入ってきているので、考える時間が増えてます。

最適な判断とか、最適な決定ができるよういつも心がけているのですが、
正解って100個の問題があったら100通りあると思っていて、
本やネットで調べれば解決するものではありません。

ちょっと話を脱線しますが、「経営戦略を問いなおす」という本があります。
簡単に要約すると、”経営戦略とはなに？”という疑問に大学教授の著者が
データを用いながら明快に回答します。

その本のなかで、経営戦略は「経営者の主観に基づいた特殊解」という結論になります。
社長の事業観、経験、度胸が優れた戦略を導く、としています。
戦略は最終的には人に宿る、という意見ですね。

机上の空論ではなく、大学教授らしく事実（データ）に基づき論理的かつ
一般人にもわかりやすい言葉で書かれています。
ぜひ一読をオススメします。

で、話がそれましたが、プロジェクトマネジメントも
「PMの主観に基づいた特殊解」だと思うのです。
だからPMは知見を広げなければならないし、考えなければならないし、
自分で一般解ではなく特殊解を導かなければならないのです。

メンバーから相談を受けたときに、その相談に対する直接的な
アドバイスはできますが、最後にするアドバイスは
「常に考え続けろ」になります。

これは導く答えが常に「特殊解」だから。

その時に得られる解はその時だけのもの。
また別の時期に同じ課題に直面したら、解は違うかもしれない。

正解を欲する人には、特殊解であることを添えて伝えるようにしています。

—-

最近お客様やプロジェクトメンバーをはじめ、
いろんな人から質問をされることが多いのですが、
いつも相手に確認したいと思うのが
「どこまで理解できているのか？」
という部分です。

全体を10とすると、9まで理解できていてあと残り１なのか、
全く理解できてなくて0の段階なのか、
それをまず説明してほしいなーと思います。

それによって言い回しや説明にかける時間、
そのときに説明したほうがいいのか、別の時間を確保して
説明の機会を設けたほうがいいのか、
いろんなパターンがあります。

あまりにも質問の数が多いと、個別に回答するのが
煩雑になるので「質問確認会」
を開催する場合もあります。

「何を知りたいのか」はだいたい僕も質問されたら分かるのですが、
「どこまで理解できているのか」は言われないと分かりません。

質問をするときは相手の時間をもらうので、
「自分が理解できている範囲をまず伝え、その後に質問をする」
を心がけましょう。

—

やさしさには
①甘いやさしさ
②厳しいやさしさ
の２つがあると思っています。

たとえ話で説明します。
幼稚園の運動会でかけっこの途中で園児が転んだとします。
園児が自分ひとりでは立ち上がれず、ワンワン泣いているときに
①すぐに走っていって助けてあげる保母さん
②自分の力でゴールまで走りきってほしいと思って助けてあげない保母さん
前者は甘いやさしさで後者は厳しいやさしさだと思います。

プロジェクトメンバーが困っているときに、
すぐに助言をして解決案を出すのは甘いやさしさ、
自分の頭で考えて解決案を出してもらい、わざと助言しないのが厳しいやさしさ、
だと思っています。

社内で気難しいと言われている人が、本当は一番やさしさのあふれた人だったりします。
プロジェクトマネージャーにとってやさしさは必要不可欠なものなのですが、
その使い方には気をつける必要があります。

–

今日は具体的なメンバーマネジメントのお話です。

例えばプロジェクトメンバーが複数のタスクを抱えていて、
全ての期限が今週末だとします。

僕はそのメンバーの進捗を確認するときに、わざと今取り掛かっていない
他のタスクに関して、
「あのタスク今どうなってる？」
と質問をすることがあります。

その意図は「全体を見てタスクを進めているか」を確認するためです。
もしメンバーが、
今取り掛かっていないタスクを気にかけながら、進めているのであれば、
全体が見えているのでプロジェクトマネージャーとしては安心です。
質問に対して、「あっ、忘れてました！」となるのは危険です。

２つの仕事(A,B)がある場合に途中経過として、
A:100%,B:0%の状態よりも
A:50%,B:50%の状態のほうが望ましいと思ってます。
プロマネの立場としてはゴールまでの計算をするときに、0%というのは
リスクが多すぎて怖いものです。

前者の状態が多い人はシングルスレッドタイプ、
後者が多い人はマルチスレッドタイプと呼ぶことに
していますが、一緒に仕事をしているとどちらのタイプにメンバーが属しているのかが
見えるようになります。

シングルスレッドの人に対しては、わざと他のタスクを意識してもらって、
マルチスレッドの方向へ誘導する、というマネジメントは頻繁に行っています。

—

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

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

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

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

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

—

プロジェクトマネージャーは日々決断の連続です。
・お客様から頂く新たな要望を受けるか、受けないか
・システムのカットオーバー時期をずらすかどうか
・人をリリースするか、もう少しいてもらうか

僕も毎日毎日小さな意思決定をし続けています。
プロジェクトは基本的に不確定要素はたくさんあるので、
少ない根拠から自分の中で筋道を立てて考えて、
最後は自分の責任で結論を出さなければいけません。

仕事をしていてよく思うことは、
判断はするけど決断ができない人が多い
ということです。

お客様の担当者の方も、なかなか決めきれない人が多いですね。
・上司に相談しないと、、、
・僕には権限がないから、、、
・資料をもらわないと決められない、、、

メンバーでも
・この仕様だと何パターンも解釈があって実装できません、、、
・資料を作るか作らないかで迷っています、、、
という疑問や迷いを持って作業が前に進まない人もいます。

プロジェクトの現場では、みんな決断を下してくれる人を待っているのでは？
とよく思います。
決断を下す = リスクを自分が取る
ということですから。

プロジェクトマネージャーはいつも決める側にいるべきだと思います。
決断したことに自信と責任を持ち、決めてもらう側の人たちを誘導して、最後は
「ほら、私の言ったとおりでしょ？」
とやってのけると、かっこいいと思います。

–