弊社PMの頭の中を大解剖！PMに求められることとは。

広報の藤原です！

今回インタビューするのは、

技術推進本部第６GroupでGroup Managerを務める中村駿哉さんです！

▼ プロフィール
名前：中村 駿哉（なかむら しゅんや）
入社：2016年4月
所属：技術推進本部 第 ６Group
役職：Group Manager
趣味：登山、温泉、バンド活動

中村さんは現在、PMとしてお客様のDXを推進するべく、

ミャンマーメンバーと一緒にチームで開発に携わっています。

あらゆるプロジェクトでエンハンス開発を進めてきた中村さんが感じる、

PMに求められることとはなにか？

いま、PMにやりがいを感じながらもどこかうまくいかないと悩んでいる方、

これからPMを目指していきたい方の１つのアンサーになれば嬉しいです！

ぜひ最後までお読みいただければと思います！

エンハンス開発と自社サービス。２つの側面からの学びが、PMとしての基礎を作った。

藤原：本日はよろしくお願いします！

まずは中村さんの経歴についてお伺いしたいのですが、

新卒で入社されて、どんなプロジェクトに携わっていたんですか？

中村：最初は金融系の現場で、アプリケーションのエンハンス開発をしていました。

そこでHTMLからバックエンドのAPIまで一通り触りました。

藤原：バックとフロントのどちらも担当されていたんですね！

そこでの経験が今のPM業務と繋がっているんですか？

中村：そうですね、技術的にというよりは、大規模なエンハンス開発のなかで、

システムは作って終わりではないという考え方が身につきました。

当たり前だけど、やっぱりシステムは使われてる期間の方が長いんです。

エンハンス開発では、ユーザーの要望に合わせた機能追加や、

外的要因によるシステムの統合などを担当していて。

同時にシステムエラーの調査、暫定対応の報告やワークアラウンドなどに

裁量を持ってやっていたところもあり、動いてからが全てだなと思うようになりました。

あとは経験でいうと、2018年ごろの自社サービスに携わった経験も大きいです。

藤原：TeamTechを用いたチームワーク測定ツール、FiveStarやStarTeamですね。

▽TeamTechの詳しい内容はこちら

中村：そこではPdMとして要件定義から設計までのフェーズを経験して。

そのプロダクトがユーザーに与える価値の本質まで考えられたのは良かったです。

PMはクライアントから要件を聞いた時に、その背景にあるものを知ることが必要になってきます。

背景を踏まえた設計や体制を考えられるのは、この経験があったからこそだと思っています。

あと反省点で言えば、プロダクトをスケールできなかったことです。

本来は限られた工数のなかで、常に集中と選択をしなければいけないんですが、

当時はスキル不足もあってそれができず、その反省が今のPMに繋がっている部分もあります。

藤原：なるほど。

そういった経験が今に繋がっているんですね。

ナレッジ共有と個人の成長が、チームの成長スピードを加速させる。

藤原：そこから今のプロジェクトに携わってこられたと思うのですが、

中でも特徴的なのはミャンマーのオフショア開発を取り入れたプロジェクトでPMをされているところですよね。

中村：はい。日本側のメンバーが10名ほど、ミャンマーのプログラマーも入れると30人ぐらいですかね。

そこで複数のプロジェクトの全体統括をしています。

開発体制の提案や各プロジェクトの進捗確認、

クライアントや開発チームの技術相談窓口をしています。

藤原：まさに様々なバックグラウンドのあるチームを統括されているんですね。

そんなチームで働くという楽しさや価値は、どんなところですか？

中村：いろんなプロジェクトが同時に動いているので、

プロジェクトを横断して連携できたときが、チームで働く楽しさかなって思ってます。

今のプロジェクトもすでにリリースされているサービスのエンハンス開発になるんですが、

お互いにナレッジを共有しあって業務効率化を実現し、

より高い品質を提供することが求められると考えています。

それが個人としてもチームとしても成長につながるし、

クライアントにとってより大きな価値を提供できる。

まさにチームで働くことの価値だなと感じています。

例えば、ミャンマー側の開発チームとはブリッジSE（以下、BSE）がやり取りしてくれているんですが、

このプロジェクトで初めてBSEを経験するメンバーも多いんです。

そういった時にすでにBSE経験の長い他のプロジェクトメンバーが

ナレッジを共有することで、全体的な成長スピードも上げていけるということです。

PMとしてのコミット力、それがプロジェクトの成功を左右する。

藤原：まだまだ成長途中ということですが、

今後現場で実現していきたいことはありますか？

中村：まさに先ほど話していた情報共有にも繋がるのですが、

属人化を徹底的になくしていきたいです。

一流のクライアントワークは、

明日から別の担当者が作業することになっても、プロジェクトが滞らないことだと考えています。

オープンでクリーンな情報連携をしていきたいです。

中村：クライアントワークをしていく中で、メンバー１人１人が情報連携の意識を持つ。

その仕組みをつくることが、PMとして求められることだと思うんです。

PMが「仕組みをつくる」ことに対してどれだけコミットできるかが、

長期的にプロジェクトの成功を左右します。

藤原：「仕組みをつくる」ほかにもコミット力が求められる場面はあるんですか？

中村：はい。

クライアントと開発チームを繋ぐことです。

クライアントや開発メンバーと向き合って、声を聞くことが必要です。

マネージャーになるとコーディングをしなくなる人が多いと思います。

そうすると、開発者の声が届きにくくなるんです。

「細かい仕様は分からないけど、できるだろう」という判断をしてしまう。

一方でクライアントとは、背景を理解せずに要件だけを聞いて、プロジェクトを進めてしまう。

こういった状況だと結果的にうまくいかないことが多いです。

クライアントとはそのサービスやシステムが生まれたきっかけ、

ビジネスの今後の展望を共通認識として持っておき、

その上でメンバーとそれぞれの技術レベルの把握や仕様の伝達を行う。

それがプロジェクトの本質を掴む近道になると思っています。

１人の成長では限界がある、だからこそチームで一緒に作っていける人へ。

藤原：最後に、シアトルでPMをするならどんな方が合っていると思いますか？

中村：自分の成長も大事ですけど、

その視座をチームという目線で考えられる人だと思います。

最初のステップとしては「自分がスキル伸ばして成果を出せば、自分の価値が上がる」でいいと思います。

そういう人が集まれば、プロフェッショナル集団として強いです。

でもチーム開発で、その価値をさらに大きくしていこうとすると「仕組みをつくる」作業が必要になる。

ひとりでなんでも完結できる人はほとんどいないので、

開発システムのテンプレート化、ワークフローの仕組み化が必要不可欠です。

そういった仕組みを一緒に作っていける人、

そういうことを考えるのが好きな人が合っているのかなと思います。

藤原：それが結果的にお客様への高い価値提供にも繋がるということですね。

そこに一緒に挑戦、そして成長していきたいですね！！

まとめ

今回のインタビューを通して、

「サービスは作って終わりではない」というPMとしてベースになる考え方に加えて、

・一流のクライアントワークとして仕組みをつくる

・クライアント・メンバーそれぞれと向き合い、コミットしていく

ということが、チームでプロジェクトを成功させるPMにとって求められることだということがわかりました！

中村さん、ありがとうございました！

・クライアントへの価値提供を常に追い求め続けたい方

・個人の成長だけでなく、チームとしても成長していきたい想いのある方

ぜひ一度カジュアルにお話ししましょう！

最後までお読みいただきありがとうございました！