今回のインタビューは、「プロダクトマネージャー(以下、PM)」「デザイナー」「エンジニア」という3つの役割で構成する、Pivotal Labsでの開発チーム編成パターンに沿ってまとめている。これら3つの役割とチーム編成の詳細については、本稿の《前編》を参照してほしい。
PM〜プロダクト開発に集中できる環境がベスト
お話をうかがった方
- NJC Team Finches(新ビジネス企画開発本部)Matsushimaさん
- Pivotal Labs Yuiさん
――Pivotal Labsで開発を行うことになった経緯を教えてください。
Matsushimaさん:私が所属するTeam Finchesは、新しい製品を考えて作るのがミッションです。Pivotal Labsへ来る前、あるデザインコンサルティングファームと事業のシード――どの分野でどのようなソフトウェアを作るか――を検討しました。そこで「野菜や果物などの生産者である農家と、流通を担う卸業者とが共同利用して、利益を最大化するシステム」というコンセプトができあがったんです。
それではと、そのMVP(Minimum Viable Product)を作り、具体的に製品化していこうという流れになったのですが、Team Finchesは昨年4月に立ち上がったばかり。それまで社内でゼロから新しい製品を作った例もなく、アジャイル開発のノウハウはありませんでした。NJCが自前でやるのは難しい。だから、アジャイルで新規開発するノウハウを持った会社さんといっしょに作っていくことも検討しだした時、デザインコンサルティングファームからご紹介があり、Pivotalといっしょにプロジェクトをやりましょうという話になりました。
――初めてやってみていかがですか。
Matsushimaさん:3月の中旬から来ているのですが、常に新しいことに接している感じ。行ったことのない地下ダンジョンを進んでいる感覚ですね。弊社にはプロジェクトマネージャーという役割はあるけれども、プロダクトマネージャーという役割や職種はありません。プロダクトマネージャーというものをペアを組んで一から学ばせてもらっています。
Team Finchesに移る前は、既存事業などをバージョンアップしたり販促計画を立てたりしていました。同じ製品に関わる仕事をしていたもののアプローチは全く逆。何もないところから作り出す現在の仕事は本当に新鮮です。ビジネス的なところだけじゃなくて、ユーザーインタビューをしたり、そこからデザイナーと一緒に機能に落としていったりするのも、すごく楽しいです。
――ペアリングする相手の方には、どのように教えていますか。
Yuiさん:ゴールは「ゲストチームの方が自社に帰ってからも、ここで学んだことを活かしてプロダクトを作り続けていける」ことです。そのため、プロジェクトの期間が数か月ある中で、最初のうちはかなりやってみせて――みなさんやったことのないことをしているので――考え方を伝えるのですけれど、途中からいっしょに考えていく割合を増やしていきます。最終的にはペアの方にリードしてもらって、私たちは端で見ていてフィードバックだけするようにしています。
――3つの役割の中で、PMの方が一番変化するように思いますが?
Yuiさん:そんなことはないですね、3つの役割ともかなり守備範囲が広いので。PMはビジネス戦略的なことを考えることから、デザイナーとともにユーザーリサーチ、仕様の検討とそのエンジニアへの展開までやります。デザイナーも、ユーザーリサーチ、ユーザー体験設計、画面などのデザイン、ブランディングまで、やはり守備範囲が広いです。またエンジニアもバックエンド、フロントエンド、オペレーションまでフルスタックでやります。だから、どの役割でも全部に精通している人はPivotalにもいないですし、ゲストチームにも一部はやったことあるけどという方が多い。プロジェクト開始時とプロジェクト終了時での成長の幅は、3つのどの役割でも大きいのではないかと思います。
――NJCさんは協調性の高い方ばかりですが、万が一我の強い人ですとペアリングがうまくいかないような気がします。
Yuiさん:おっしゃるとおり、NJCのみなさんは学習に対する姿勢や、一緒にやっていこうという協調性という面で、とてもすばらしい方ばかりです。だからプロジェクトの進みが良いですし、やっていて楽しくてさらに進みが良くなるという好循環になっています。
一方で、学習する姿勢や協調性という部分のコーチングから始めなくてはいけないケースもあります。自分の中にある根拠や前提だけを信じている方には、「でもそれって今この状況でも正しいのかな」と質問したり、前提を書き出したり話したりしながら、「それって本当に正しいんだっけ?」と改めて確認します。そして、それが正しくない場合には「じゃあ、どうしたらいいんだっけ?」と問いかけていきます。
特に、PMが主に使っているリーンスタートアップという考え方は、プロダクトに限らずいろんなことに対して、自分が持っている思い込み、仮説、前提を洗い出し、その中で重要なものから検証していくもので、この思い込みを洗い出すという作業を、いろんな場面――進め方、プロセスも含め――においてやろうと。そうして細かく振り返って、うまくいっていないのであればどう変えるかを考えて、小さいサイクルを回しながら進めていきます。
とはいえ、各自の専門性や知識でそれが正しい部分、いい部分というのはやはりあります。それらは私たちも学びつつ、どうしたらより良い状況が作れるかについてアイデアや知恵を出し合っていけると、「いっしょにやっていこう」というマインドセットになると考えています。
――PMはやはりペアでやるのがベターだと思いますか。
Yuiさん:PMの場合、ペアでやるのはイネーブルメント[1]のためという側面が大きいですね。実は、弊社のプロダクト開発部門において、PMがペアという例はあまりありません。とはいえ、誰かに相談できる、必要であればみんなにアイデアを出してもらったり、意思決定をサポートしてもらったりするという形は変わらないので、そういう意味ではデザイナーとペアを組んで進めるというのでも変わらないと思います。他のPMに相談したり意見をもらったりするというのも、日ごろから頻繁に行っています。それらもなくて、完全に一人だとちょっと大変だと思いますね。
――システム納入先(ユーザー企業)に対する折衝などはPMが担っているのですか。
Matsushimaさん:今回のプロジェクトでは、ユーザー様が弊社と古くからお付き合いのあるところということもあり、私の上司がアポ取りやさまざまな調整事をやってくれています。聞くところによると、そういったことはPMが担当するプロジェクトもあるらしいのですが、特にBtoBですとアポ取り一つでも根回しが必要になるなど手間がかかります。そうするとプロダクトに集中できない時間が発生しますから、とても助かっています。
――渉外担当はPMとは別にいたほうが作ることに集中できますね。
Yuiさん:他のプロジェクトでは、そこをチームの誰かが担うケースが多いのですが、それですと渉外など開発以外の仕事で週の半分くらいの時間が飛んだりします。ユーザー企業様側との「こういうふうにやっていきたいです」とか「いつごろまでにこういう進み方ができそうです」といったお話を上長の方にお願いできているのは、大変ありがたいです。PM、デザイナー、エンジニアというプロダクト開発の中心チームがあり、その周りに渉外をはじめ、営業、マーケティング、サポートといった担当がいて、それらが1つのチームという認識で動くことができたらすごく良いと思います。
注
[1]: Enablement。アジャイル開発の経験を積み、自分たちで実践できる力を付けていくこと。