敏腕PMブログ

主婦がスーパーで野菜を買うときには、
どのスーパーで野菜を買うのが最もお得かを計算しています。

なぜ主婦がこれをできるかというと、
・野菜の適正価格を知っているから
・複数のスーパーで比較・検討できるから
です。

ではIT業界(システム,WEB)はどうでしょう。
ホームページを制作したいときに、依頼する人は
・ホームページ制作の適正価格を知っている
・複数の会社を比較・検討できる
と言い切れるのでしょうか。

IT業界はまだまだ業界の年齢が浅く、
適正な価格を利用者が判断できるまでに至っていません。
現在でもなお
・昔からお付き合いのある会社に毎回頼む
・営業担当がいい人だったからその会社に頼む
といった話があります。

野菜は自分の目で選べるのに、システム開発会社は選べないのです。
それだけＩＴ業界で適正価格っていうのは難しいのです。
弊社はそこにメスを入れました。

・ITをそれほど分からない依頼者が、適正な価格で発注できるように
・実力のある会社が、適正な価格で受注できるように

そんな想いをこめて、弊社では「BBPlanet（びーぷら）」を運営しています。
http://it.bbplanet.jp/

最近リニューアルも行い、より依頼者と受注者でのコミュニケーションが
取りやすくなりました。

僕はIT業界の「世直し」だと思ってます。

—-

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

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

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

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

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

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

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

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

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

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

—-

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

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

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

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

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

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

—

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

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

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

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

–

以前は「結果論」と「結果が全て」の２つは
全く違うことだと思っていました。

イメージとして、
■結果論 ⇒ 終わってからこじつけで理由を考えて結果を正当化するイメージ
( どちらかというと悪いイメージ )
■結果が全て ⇒ 過程(プロセス)は関係なく結果を出した人が正解というイメージ
( どちらかというと良いイメージ )
のような感じでとらえていました。

でも最近はその考えが変わってきて、
「結果論」と「結果が全て」は結局同じことなのでは？と思うようになりました。

なぜそうなったかというと、テレビで会社経営者のインタビューを見たり
著名な方の本を読んでみると、確かに言っていることはもっともなのですが、
「同じ方法で失敗した人もいるのでは？」
と同時に思ってしまうのです。

これはオリンピックで金メダルを取った人が何を語っても「やっぱりすごい！」
とマスコミから評価されるのですが、星野JAPANのように結果を残せなかった場合、
「選手村に入らず五つ星のホテルに泊まるとはなにごとだ！」
とバッシングがされます。

結果が全てだし、でも結果論でもあるよなー、と思ってしまいます。
言い方を変えると、結果を出さなければ全てが言い訳っぽく聞こえてしまうし、
結果が伴うと、言っていることの説得力が増します。

プロジェクトの進め方にも
要件定義⇒設計⇒開発⇒テスト⇒リリース
といった王道の進め方がありますが、
「結果が全て」の視点に立つと、最後のリリースが問題なく実施できればOKとなります。

そして成功したらそのプロセスを大いに再利用し、「結果論」を語りながら次も成功させればいい。
失敗したら言い訳せず成功するにはどうすればいいか、を突き詰めればいい。

世の中結局は「結果論」であふれていて、王道なんて存在しない、
と考えると、プロジェクトマネジメントにも幅が出ると思っています。

–

「強かさ」
これ、何と読むか分かりますか？
僕も最初漢字でこう書くのは知らなかったのですが、
「したたかさ」と読みます。

辞書で意味を調べたところ、
１ 粘り強くて、他からの圧力になかなか屈しないさま。しぶといさま。「世の中を―に生きる」「―な相手」
２ 強く、しっかりしているさま。「―な後見役」「―な造りの家」
３ 強く勇猛であるさま。
だそうです。

プロジェクトマネージャーは”したたか”でないといけないですね。
ここでのしたたかは辞書どおりの「強い」にプラスして、
「しぶとい」「一筋縄ではいかない」というイメージも含みます。
時にはステークホルダーとのハードな交渉を強いられる場面もありますので、
そういうときには、ポジティブさや責任感だけではなく、したたかさ
という部分が重要になってきます。

ビジネスの場では「いい人」だけでは成り立ちません。
外部と折衝する仕事は「したたかな」人間なら安心して任せられます。
なかなか伝えるのは難しいのですが、重要な要素だと日々感じます。

私が以前いた会社では、「明るく、元気に、したたかに」
というスローガンがありました。
よく考えられているなー。と思います。

—–

コミュニケーションについてはいろいろ考えるところがあるので
まだまだ書きます。
前回は「前提を合わせる」重要性について書きました。

相手に合わせるためには、自分は相手よりも受け入れる
幅が広いことが必要だと思います。

たとえ話をしましょう。
Aさん、Ｂさん、Ｃさんの3人が、ある花を見たときにその色を
Ａ：赤色
Ｂ：紫色
Ｃ：赤紫色
と答えたとします。

このときCさんはＡさんＢさんよりも色に対して細かく判断しています。
ＡさんＢさんが12色入りの色鉛筆を持っていて、
Ｃさんは24色入りの色鉛筆を持っているイメージです。

僕はＣさんのような人を「メッシュが細かい人」と定義しています。
そういう人は会話をしていても、少しのずれに気づいてそれを訂正
できるので、自然と前提を相手と合わせられるのです。

メッシュを細かく持つためには、いつも「定義」に注意するといいですね。
・SaaSとASPの違い
・ハウジングとホスティングの違い
・要求と要件の違い
といった似ているようで異なるものに注意していると、自然と細かな定義ができていきます。
それは必ずコミュニケーション能力向上に通じます。

—–

以前、プロジェクトの状況を判断するヒント でプロジェクトの状況を
メンバーからの質問で判断する、ということを書きました。

今回は第２弾です。
プロジェクトマネージャーが実際にプログラミングを行うことはまれだと思います。
普通は要件定義や設計で、その後の実装はメンバーに任せるのが一般的です。

でも、システムはプログラムで動いていて、そのプログラムは最終的には0か1かの世界です。
プロジェクトマネージャーがいかにすばらしい設計をしても、
システムがバグってしまうと全てが水の泡になります。

最後はやっぱりエンジニア頼みなんですね。
でもエンジニア任せではダメです。
いつでもシステムの品質に目を光らせなければなりません。

そこで、状況判断のヒントですが、それはバグの内容で判断するというものです。
僕はRedmineというバグトラッキングシステムを使っているのですが、
バグが発生し、解決し、終了するサイクルが全てメールで飛んでくるので、
今どんなバグが出ていて、どこでメンバーが手こずっているのか、が
メールを読んでいるだけで分かります。

１つのメールを読むのが２秒くらいなので、１００件あっても２００秒しかかかりません。
重要なバグや、仕様にかかわる部分はメールを読んだ瞬間にRedmineにアクセスして、
メンバーへ仕様を伝えることができます。

「いいバグが出始めたな」とか「このレベルのバグが出ているようではまだまだだな」とか、
１人でいろいろと状況を判断しています。

なので、質問とバグ、これがプロジェクトの状況を判断するヒントですね。

–

・情報共有とは具体的にどうすることか
・顧客視点にはどうしたらなれるか
・責任感とはどこから生まれるのか

これらの問いに対する一つの答えが、「他人事を自分事に」することだと思います。
アートディレクター、佐藤可士和さんの本で出てきた言葉です。

社内で朝礼や会議があるのは、情報を共有するためで、
それは他の人がやっていることを、自分も知る、考える必要があるから。

顧客の視点に立つということは、顧客が抱える課題を解決するために、
もし自分がお客様と同じ状況に置かれたらどうするか、を考えること。
正論だけでは通用しなかったり、社内政治まで考えるべきときもある。

責任感の強い人は、自分に与えられた仕事は完璧に仕上げ、
かつ他人から頼まれたことも手を抜かず高いOUTPUTを出す。

プロジェクトの現場でいうと、
・メンバーはリーダーのことを自分事に
・リーダーはメンバーのことを自分事に
考える必要があります。
(双方向の理解が不可欠)

特に忙しいとき、頭にかっと血が上ったとき、
は合言葉にするとよいと思います。

他人の大変さ、というのが自分のことのように分かる仕組みを
プロジェクトマネージャーが作れるとよいですね。

–

プロジェクト開始前には通常「営業フェーズ」があります。
基本的にはプロジェクトマネージャーではなく、営業担当者が
お客様とどのようなプロジェクトにするのか、の大枠を決めます。

プロジェクトマネージャーはある程度 ”案件化” する可能性が
高まってきた時点で、営業にも関与します。

ここで注意しないといけないのが、“見積り”ですね。
営業担当者は仕事がほしいあまり、安い金額で提示してしまうことがあります。
もしくは口頭で値引いてしまうとか。

プロマネの重要な仕事として「見積りチェック」というのがあります。
これはプロジェクトが始まる前にやる仕事ですので、
自分で営業案件にアンテナをはっておかないと、関与するタイミングを逃します。

営業担当者⇔プロジェクトマネージャー　の接点は
見積書になります。
２人で相談してコンセンサスが取れれば強力なタッグですね。
逆に全く接点がなければ、コミュニケーション不足で
プロジェクト開始当初からつまずく場合があります。

PMとしては「営業がこんな安い金額で受注したから利益が出ない」
営業としては「せっかく受注したんだから、この金額で利益出せ」
というような互いの考え方の違いから溝ができてしまいます。

プロジェクトマネージャーも営業に無関心であってはなりません。
プロジェクトを成功させるには、開始前からの準備が必要です。
”見積書”が営業担当者との接点なので、積極的に見積りチェックを行いましょう。

–