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

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

同じ失敗をしないように、失敗談を贈ろうと思う。
（以下、プロジェクトマネージャをPMと略記する）

新人PMになった君へ贈る言葉

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

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

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

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

と思っているかもしれない。

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

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

安請け合いしないこと

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

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

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

いざとなったら君がやるから構わないだろうって？
そういうふうに思うのも無理はない。

でも、君が安易に引き受けた仕事をやることで、それがボトルネックになる可能性もある。
だいたい、君の仕事は直接作業をするのでなく、担当者に仕事を割り振り、スムーズに働いてもらうようすることではなかったかい？

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

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

安請け合いはしないこと（その２）

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

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

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

そんなことはないって？

上記は実体験に基づく注意事項だ。仕事は1つで完結することは少ないのである。

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

見積もった作業、洗い出した作業は、全部できるかもしれないけれど、全部できないことのほうが圧倒的に多い。

優先度をつけよう。
優先度をつけることは、プロジェクトで何が大事なことかを決めて、意識することだ。
優先度がないのは、何も意識できていないことと同義だ。

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

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

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

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

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

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

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

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

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

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

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

はじめに全体を見通してスケジュールを決め、徐々に詳細化していこう。
最初から完璧なスケジュールなんて組めないし、不確定要素があって決めても変わってしまうから。

とにかく証跡を残すこと

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

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

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

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

新人PM（初めて、ないしは初めてに近い）は、エンジニアリングがそこそこできたやつに向けて、ステップアップ的な意味でアサインするパターンが多い。
（余談だが、僕はあまりこのパターンは好きではない。）

そして、新人PMのチームに、上級アーキテクトやシニア級のエンジニアがアサインされることはまれだろう。
大抵は、自分よりもキャリアや経験・スキルの低いメンバーがアサインされる。

基本的に、メンバーにエンジニアリングおまかせなんてことにはならないので注意が必要だ。
おおよその実装方針や、なんならファイル構成は君が決めて、処理だけ書いてもらうなどしておくほうが良いかもしれない。

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

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

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

リスク管理✕リスク管理✕リスク管理

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

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

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

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

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

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

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

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

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

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

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

おわりに

社会人を初めて、業務でプログラムがかけるようになった（と思っていた）当時の自分に向けてのポエム。