敏腕PMブログ

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

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

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

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

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

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

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

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

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

—-

あけましておめでとうございます。
本年もどうぞPMブログをよろしくお願い致します。

今回はプロマネからちょっと外れて営業のお話。
毎年１月から３月は多くの企業が来期の予算取りをする季節です。

B向けサービスを展開する弊社も、1～3月が営業のがんばりどきです。
営業を担当していると、「受注できる確率ってどれくらい？」
と上司から聞かれることってあると思います。

報告は数値で、と以前このブログでも書きましたが、
「結構受注できそうです」なんて言っても比較検討ができないので、
受注確率はやはり数値で報告すべきものと思ってます。

この確率についてなのですが、
受注確率はどこまで高くても50%
というのが僕の考えです。

これはかなりの経験則も入っているのですが、
・絶対受注できると思ってたのに、寝返られた
・コンペで勝ったけど方針変更で案件自体が消滅した
なんて話が自分も経験してますし、周りでもたくさん起こってます。

なので「ほぼ受注できそう」、と思っていても僕の場合は確率MAX50%です。
こうしておくことで、１つの案件に依存しないようになりますし、
仮に何か不可抗力によって受注できなくても精神状態も安定します。

僕が80%を付けるのは、継続案件であとは決裁権限者がはんこを付くだけ状態
くらいですね。

魅力のある提案書を書き、どこよりも投資対効果が高い見積りを提示し、
お客様から信頼を得られた状態でも確率50%なので、あとは運です。
運にまかせられるまで準備をすることが営業ではとても大切。

今年も運がいいといいな、と思う仕事はじめです。

—

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

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

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

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

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

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

—

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

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

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

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

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

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

—

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

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

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

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

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

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

–

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

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

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

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

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

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

–

プロジェクトをやってると、たまーにですが、
“もうどうにもならん“という状況になります。
にっちもさっちもいかなくなる、というやつですね。

普通は課題があると、解決策を洗い出して、
まずは自分達で精査して、
それでも解決策が1つに絞り込めなければお客様に
判断を委ねる。
という形を取ります。

社内メンバーで解決しなければならない課題は、
できるだけ情報を社内で共有して、
プロジェクトメンバー以外からもアイデアをもらって、
最終的な決断をしていきます。

でも、上記手順を取ったとしても、妥当な解決策が見つからないときがあります。
例えば、データを全部消してしまい、かつバックアップも取っていなかった場合
なんていうのは、エンジニアの方だったら一度くらい経験しているのではないでしょうか。

パニックになると、冷や汗流していろいろと言い訳を考えたりするのですが、
大抵後からつじつまが合わなくなり、自分で自分の首を絞めることになります。

私もこれまでいろいろと窮地に追い込まれて来ましたが、
もうだめだ、解決案が思い浮かばない
状況になったときの、方針だけは明確にしてあります。

それは、、、、「正直」です。
正直に状況を全て話す。
ダメモト、怒られて当然、の状況で、それでも正直に話す。

短期的な逃げではなく、長期的な視点で解決策を探すと、
最後は「正直」という解が導かれる。
これは私の経験則ですが、結構同じ事を考えている
プロジェクトマネージャーは多いのでは？と思っています。

–

今日はちょっとした「気づき」のお話です。

仕事ができるようになるためには、
「まずは量をこなせ、それから質を考えていけ」
というメッセージを見かけます。

サイバーエージェントの藤田さんも、著書の中で、
若いころはまず量をこなすことに専念した、
と言っていました。

最近の僕も仕事量が以前よりは増えてきたので、
量をこなしている状態が続きました。
ただし、量をこなすからといって、これまでの仕事の質を落としたくないので、
質を保ったまま量をこなそうという状態が続きました。

「量は増えているけど質を保つ」ということは、実質的には質が上がっていることに
なります。（単位時間当たりの作業の質が上がっている）

なので、“量をこなす”ことは、質を考えながら続けていると、おのずと“質を上げる”
ことにもつながるんだなー、と最近気づきました。

今までは、
・量を追い求めるんだったら質は落とさなければ
・質を求めるから量は少なく
といったような量と質のトレードオフの考え方を心のどこかに持っていた気がしますが、
最近の仕事の中で考え方が変わってきました。

「量をこなし続ける先に、質の向上がある」
僕の量から質への転換の解釈です。

—

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

–