敏腕PMブログ

以前メンバーからこんな悩みを相談されたことがあります。
「どの選択をするのが正しいか分からないんです」
その悩みの内容がなんだったか忘れてしまったのですが、
僕が聞いたときも「そりゃわからんわ」という選択でした。

というのも、どの選択が正しいかなんて、その時点では分からないものだと思うのです。
・どの会社に入るのか
・ばりばりエンジニアを突き進むのか、マネジメントの道を歩むのか
・起業するのか、社員のままでいるのか
これらの選択に対し「正しい」答えはなくて、「正しい選択だったことにする」努力はできます。

新卒採用のときに学生の方にはよく伝えるのですが、
入社する会社を決めたときには、
・自分の決断に責任と自信を持つこと
と伝えています。
その決断が正しかったという人生を歩んでほしいので。
エスキュービズムへの入社を決めた人にも、残念ながら辞退された方にも
僕は同じことを思います。

正しい選択なんて誰もわからないので、
選択が正しかった、と言えるように努力する。
これが今日伝えたかったことです。

–

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

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

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

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

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

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

—

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

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

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

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

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

—

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

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

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

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

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

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

–

弊社の採用ページがリニューアルオープンしました！
http://recruit.s-cubism.jp/career/detail/pm.html

相手を理解するためにはまず自分を伝えることが大事。
会社もまずは自分達の仕事をより正確に伝えなければなりません。

最近はプロジェクトの数がどんどん増えてきていて、規模も大きくなってきました。
プロジェクトマネージャーを積極募集中です。
ポジティブ、責任感、チャレンジ精神
のある人はどんどん採用していきたいと思います。

”刺激しあえるメンバーと、ワクワクするような仕事を”
これが僕のモットーですね。

知識や経験が価値を持たない時代、
自分がどこまで通用するかを確かめたい人、
ぜひ応募していただければと。

—

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

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

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

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

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

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

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

–

世の中”マネージャー”という肩書きを持つ人は、忙しい人が多いと思います。
・本年度予算を達成するために数字を作っていく、営業マネージャー
・モチベーション高く働け、かつ成果の出る現場を作る、人事マネージャー
・会社の財務数値を根拠に経営陣へ改善点を提案する、財務マネージャー

そして、
・プロジェクトの成功へ向け品質、予算、納期を管理する、プロジェクトマネージャー
(プロジェクト成功の定義は6/18の記事をご参考に)

僕はマネージャーの忙しさには、２種類あると思ってます。

１．先手型 ： 未来に成果を上げるため、今から仕掛ける(仕込む)仕事で忙しい
２．後手型 ： クレーム対応や雑務処理に追われて忙しい

なので肩書きが”マネージャー”の方が「最近忙しいんだよねー」
と言っているのを聞くと、自然と「先手型？」「後手型？」と考えてしまいます。

自分自身に対しても、作業量が多くなってくると、これって「先手型？」「後手型？」
と確認して、後手型になっていないかチェックしています。
作業していること＝仕事していること　ではないので。

先手を打つ、率先して行動する、という意味で、”プロアクティブ”という言葉があります。
行動指針であり、マネージャーが持つべき視点、だと思います。

–

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

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

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

—

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

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

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

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

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

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

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

–