新人PMだった君へ

 

初めてする行為に失敗はつきものだ。
それは、これから始まる作業への見通しがつかずとんちんかんなことをしたり、
これまでの成功体験やメタファで物事をみるからだったり、原因はいろいろだ。

そして、失敗も人それぞれだろう。
でも、失敗を知っていることで、同じ轍を踏まないようにすることができるくらいに
人間は優秀だと思う。

同じ失敗をしないように、失敗談を贈ろうと思う。

新人PMだった君へ贈る言葉。

言葉の使い方に敏感になろう

クラウドへの「ファイルアップロード」と「ファイル登録」という言葉が合ったと
しよう。
君は、その2つは同じ言葉と思っている。

でも、その言葉を話している人はどうだろうか?
君にその言葉を使ってくる人は、

ファイルアップロードは、単にファイルアップロードする
ファイル登録は、アップロードに加え、情報タグを付与する

と思っているかもしれない。
必ずしも君が思っている言葉と、相手の使っている言葉の意味が同じだとは限らな
い。
特に似た意味の言葉を一括りににしてまとめてしまうのは危険だ。

確実に定義を押さえ、共有していこう。

安請け合いしないこと

新しくPMになった君は熱意に燃えているかもしれない、
顧客の役に立つ素晴らしいシステムを作りたいと思っているかもしれない。

要求事項を合意した後に、顧客から新たな要望が出た場合
君はなんとかして答えてあげたいと思うだろう。

でも、安易に引き受けてはダメだ。
今回は、君一人のプロジェクトではないはず。
チームメンバを守るのも

君がやるから構わないだろうって?
君がやることで、君に仕事がボトルネックになる可能性もある。
第一、君の仕事は直接作業をするのでなく、実担当者に仕事を割り振り、スムーズに働いてもらうように働きかけることではなかったか。

もう一度、自問して欲しい。
本当にその作業は引き受けねばならないのかを。

安請け合いして1次的に好感度が上がったとしても、
結局約束が守れないようなことがあれば、期待値を上げている分、失望は高くなる。

安請け合いはしないこと(その2)

納期にも影響がなく、作業量も少なく、簡単な作業だということで、引き受けるって?
ちょっと立ち止まって考えて欲しい。

例えば、システムの動作検証を顧客システムで行う場合には、簡単なツールを作れば終わりかもしれない。
でも本当にそうか想像力をかきたてよう。

  • ツールの設置を助けて欲しいと頼まれるかもしれない
  • ツールがウボかなければサポートが必要かもしれない
  • 使い方や注意事項をまとめたドキュメントの提出をもとめられるかもしれない

そんなことはないって?

上記は実体験に基づく注意事項だ。

 

決め事は、優先度をつけよう

洗いだした作業(例えば、顧客との仕様決めのためのリスト確認)は、全部できるかもしれないけれど
全部できないことのほうが多いと思う。

優先度をつけよう。
優先度をつけることは、PJの何が大事なことかを決めて、意識することだ。

根拠有る優先度をつけて、そこから決めていこう。
また、優先度を顧客と合意してそこさえ対応できれば
顧客の最低限必要な要求に答えられるはずだ。

顧客用の成果物には、100倍気を配ろう

社内やチーム用の成果物は、スピード優先でまずは80~90%の出来を目指すべきだろう。
誤字修正やより良い言い回しができるに越したことがないが、何もないよりはマシだろう。

一方で、(言い方は悪いが)顧客の中にはシステム的なことよりも、誤字や構成にこだわる人がたくさんいる。
こういった顧客に、あらだらけのドキュメントを見せるのは、信頼関係構築に非常にNGだ。

できるだけ気を配ろう。
できるだけ気を配るのだから、当然時間もかかる。
いつもより多めに時間がかかるので、見越して見積もりをしよう。

ボトルネックを見極めよう

がんばりすぎてしまうのはよくあることだ。
がんばることはいいことだけど、もしかして君が頑張っている横で空いている人はいないかな?

空いている人がいるってことは、君の仕事がボトルネック(それが終わらないと次の仕事に移れないような仕事)
になっていないかな?

確認してみよう。そして、本当にボトルネックならば、素直にお手伝いを頼もう。

余談だけど、ボトルネックはいろいろ変わってくから、常に目配せをしよう。

段階的スケジュール詳細化のすすめ

はじめに全体を見通すことで、

とにかく証跡を残すこと

言ったこと、考えたことはドキュメントにしよう。
そんなに肩肘張らなくても大丈夫。社内のチーム向けであれば
wikiやmarkdown等のカジュアルなドキュメントで十分だ。

また、電話した内容や口頭で話した内容も
「さっきのことってこういうことだよね。あってますよね」
とくどいくらい確認をしましょう。

相手は、君のことを回りくどいやつだ、とかめんどくさいやつだな
と思うかもしれないけれど、なぁなぁであとで困るより100倍ましだから。

メンバーは自分より優秀だと思うな、信用するな

新人PMのチームに、上級アーキテクトやシニア級のエンジニアがアサインされることはまれだろう。
好き嫌いはあるけれど、よくあるやつあh,エンジニアがそこそこできてきたやつを新人PMにアサインする
パターンだ。このチームには、そこそこもできないメンバーがアサインされることが多い。

メンバーは自分より、圧倒的に優秀だと思え

先ほどのことと矛盾するけれど、たいていのメンバーはなんらかの分野で君より「圧倒的」優秀だ。
PMは単なるロールにすぎない。メンバーは君のおもちゃじゃないし、奴隷でもない。

尊敬し敬おう。
依頼するときは、きちんと敬意をもって接しよう。
そして、きちんとお礼を言おう。

h3. リスク管理✕リスク管理✕リスク管理

メンバーだって人間だ、サボったり休んだりもする。
特に、インフルエンザや慶法など、予期せず長期にやすむことだってある。

いざというときは、PMが責任をとるんだ。
だからこそ、作業内容や状態くらいは、正確に把握しよう。

相場をしり、相場で見積もる

 

相場と言っても値段のことだけをいっているのではない。
世の中には相場が存在する。そういった相場はIPAにまとめられていたり、簡単な公式になっていたりすることがある。

自分の見積もり値を、相場で確認してみよう。もしかすると、とんでもなくずれているかもしれない。

わからなければ上級PMに聞いてみると良い。

 

例:2人月の仕事は、2ヶ月では終わらない。2.3ヶ月くらいはかかる。1.ヶ月を切ることはほぼできない。

 

健康的に、新しいことを楽しもう

なにはともあれ健康第一でやろう。
確かに、初めてのPMはうまくいかないことが多くて、いらいらすることも多々あるかもしれない。

体調を壊しては元もこもない。
頑張ろう、そこそこに。

失敗しても死ぬわけじゃない、殺されるわけじゃない。
それくらいの間隔で、距離感でいいんだと思う。

  • このエントリーをはてなブックマークに追加
  • Pocket

この記事へのコメントはこちら

メールアドレスは公開されませんのでご安心ください。
また、* が付いている欄は必須項目となりますので、必ずご記入をお願いします。

内容に問題なければ、下記の「コメント送信」ボタンを押してください。