【後編】プロジェクトマネジメント勉強会

※この記事は、「【前編】プロジェクトマネジメント勉強会」の続きとなります。

炎上を予防するために気をつけていること

大津：
例えば、エンジニアリングの経験があまりない発注者の場合、プロダクトオーナーと発注者の間での初期の握りが甘いと後々大変になるケースがよくあると思います。逆に握り方がうまいと、プロジェクトの進捗が悪くなってきても、後からきちんと対処できる場合もある。

経験者の方の中で、こういったプロジェクト開始時に気をつけていることがあれば教えていただけますか。

Aさん：
たとえ人間関係が良好であっても、ドキュメント化は絶対に手を抜かないというのが、炎上させない方法だと思います。空中戦を防ぐためにも、ドキュメントに落とし込んで握っていくことが重要です。

あとは、エンジニア経験がなく、細かい開発の機微がわからない方に対しては、こういうことを今やっているというのを説明できるような資料を作っておくのが一つの予防策になると思っています。

Cさん：
画面設計をいくらやっていても、開発周りの知識がない方から見ると出来上がりの印象がだいぶ違う。なので、実際に動くものを触ってもらわないと意見が出てこないし、そもそもイメージが十分についていないものを作るときには、触ったタイミングで要望が変わることが多々あるので、なるべく早く作って頻繁にアウトプットするほうがいいと思います。

議事録で話しの経緯を逐一残すというのは、ケンカするときのためでもあるので（笑）。本来であれば、いま手元で出来上がってるものをずっと互いに合意しつつ、それをブラッシュアップしていくというのがメインだと思います。なので、大きなプロジェクトでない場合は議事録をしっかり取るのは工数がもったいない側面もありますね。

場合によってはPMがQAを担うことも多々

E：
開発する立場になってから、品質管理の部分について悩んでいます。追求しすぎるとQA（Quality Assurance）になってしまうし、かといってQAするほどの専門スキルはない中で、品質担保について何をもってよしとするのかという点を伺いたいです。

A
私も悩みどころです。ITディレクターやPMとして入っていながら、実装フェーズやテストフェーズにおいては、ほぼQAのようなことをしているときもあります。

特にQAがオフショア側にある場合には、そもそもQAチームが要件を理解してない時がある。そうなってくると、一番要件を理解しているのが、ITディレクターやPMっていう日本側の発注側になってしまうので、そういった面でバランス的には崩れているけれど、QAに近い動きをするということもあります。本来であれば細かい仕様の各パーツの動きなどはあまり見たくないのですが、見ざるを得ないときはありますね。

E：
ありがとうございます。単体テストまではいかずとも、QAの見ている粒度によってはわりと細かい粒度でも確認しているということでしょうか？

A：
そうですね。単体レベルの指摘をあげることもあまり珍しくはないですね。発注先のクオリティによっては、向こうでは結合テストまで終わっていると報告を受けたので、こちらで受け入れテストをやっているにも関わらず、単体レベルで問題が出てくるということも割とあります。

スケジュールが遅れそうな時のリカバリー

大津：
最初から最後まで完全にうまくいくプロジェクトというのは少ないと思うのですが、スケジュールが遅れそうな時はどうリカバリーしていますか？

遅れの理由にもよるとは思いますが、そのような状況になった時にまずはどういうところに目を向けるかなどを教えていただきたいです。

C：
リカバリー方法というのは、その場合によると思うのですが、前提としてリカバリーする方法の選択肢って、プロダクトやシステムそのものの仕組みをどこまで知ってるかによるんですよね。なので、プロマネの立ち位置の人間は、プロジェクトリーダーと同じくらいプロダクトを理解したほうがいいなと思います。

A：
エンジニアは基本的にフルで動いているというのが大前提なので、まずはお客さんに謝罪してリスケを提案しますかね。そして、人を何人か増やしてリカバリープランを作って、ここぐらいには収まりそうですというのを色んな関係者に交渉して合意してもらう。

ただ、そのシステムについて全然知らない人をたくさん追加しても、結局エンジニアの時間を取ってしまって開発効率が落ちるというのが短期的にはありえるので、リスケと人を入れるということのバランスも重要だと思います。

大津：
やはりユーザーにリスケを提案するというのが最初なんですか？

A：
そうですね。ユーザー側は当然怒りますが、リスケをせずにスケジュールを押し込んで、毎日開発チームに夜11時まで動いてもらったら、結局開発チームがフラフラになって品質が低下するので、頭を下げながら言葉を選びながら、どうにか説得していくという感じですかね。

大津：
やっぱり頭を下げられる性格の人じゃないとPMは勤まらないってことですね。

A：
そうですね。友人に「PMやITディレクターの仕事の1/3くらいは謝罪だよ」って、冗談を言うくらいです（笑）。発注側だけではなく、開発チームに残業してでもお願いしますとお願いすることもあります。色んな方に頭を下げながら進めていくっていうのは割とありますね。

PMのキャリアを掴み取るためには

F：
Aさんの最初の話で、最終的にPMになるキャリアパスを描きながらSEをしていた、当時から上司にはPMにチャレンジしたいと話していたと思うのですが、僕はもともとPMになりたいと思っていたわけではなく、最近ふとPMを目指したいなと思ったわけです。

そういう場合のPMの目指し方をお聞きしたいです。

A：
いきなり大きい仕事は任してもらえないと思いますが、小さいプロジェクトが立ち上がりそうなときに、PMをやってみたいと手を上げてみるのはいいかもしれないですね。上司との関係性もあるかもしれませんが、任せてもらえる可能性はあると思います。

大津：
Cさんは今まで部下にマネジメントを任せたこともあると思うのですが、その時はどういう人に任せようと思いますか？

C：
基本的にプロマネって色んな所を見るので、性格的には「細やかな人」は合うかなと思っていますね。

ただプロマネはコストがかかるので、100~300ぐらいの会社じゃないとそのポジションを置けないと思います。なので、そこの企業がどれだけのプロジェクトを抱えているかによってチャンスの数も違うかなとは思います。

大津：
PMの経験を積みたいのであれば、PMのようなポジションがちゃんと確立されていて、プロジェクトがたくさんあって、且つPMの役割を必要としているところに入るのが、一番経験を得られやすいかもしれませんね。

まとめ

ご参加していただいたE3メンバーのみなさま、ありがとうございました！
今後もこういった勉強会を積極的に開催していく予定なので、ぜひご参加ください。