「テクニカルプログラムマネージャーはオーケストラの指揮者」　メンバーの多様性を活かし、良いハーモニーを作るTPMの難しさとやりがい

プロジェクトがうまく進まない・何からスタートしていいのかがわからない…TPMが求められる場面

横道稔氏（以下、横道）：入社した時から「このプロダクトです」と決まって入るというよりは、それぞれの組織から依頼があって、プロダクトやプロジェクトに入るというやり方をしていると思います。

なので、そこの依頼の期待値によって、やはり役割が変わってくるんだろうなと思うのですが、どういうプロジェクトが多いんですか？　大井さん、いかがですか？　なんかちょっと言いにくいなとかがあるかもしれませんが（笑）。

大井宏友氏（以下、大井）：やはりものすごくたくさんの人がサービスに関わっている、あるいはグローバルでさまざまな人たちと1つのプロダクトを作っているので、進め方や文化の違いなど、いろいろな理由でうまく進まない状態に陥っている時がけっこうあるんですよね。そういった時にリクエストが来ることがわりと多いと思います。

あともう1つあるのは、本当に新規の立ち上げのケースですね。何からスタートしていいのかがわからないぐらいの時に一緒に入って進めましょうというケースの2つが多いですね。

横道：なるほど。谷川さん、なにか違いはありますか？

谷川能章氏（以下、谷川）：そうですね。歴史に応じて変わってきた面もありますが、昔は、私たちも組織のスタンスをあまり明示できていなかった、認知されていなかったというのもあって、大井さんと同じような依頼のされ方や期待値が多かったと思いますね。

横道さんが組織を立ち上げてから時間が経って、社内での認知も広がってきたこともあり、ETD室はスポットで入ってくるけど契約終了があるよという前提で、ここの問題を解決してほしいんだと切り出して相談が来るのが最近ではけっこう増えてきている印象ですね。

とはいえ、いわゆる燃えているプロジェクトや、社内で重要なプロジェクトはとにもかくにも猫の手を借りたいような状態で、まさにTPMのロールを担ってくれというシーンもやはりあるとは思っています。

横道：その1つ前におっしゃった「切り出されてくる」というのは、どういうタイプのものが多いんですか？　

谷川：例えばよくあるのは、マネージャーが忙しくてあまり現場を回せていない。あと最近多いのは、組織のミッション、ビジョンをあまり明確にできていなくてマネージャーたちが困るという状況に対応すべく、ワークショップを通じてミッション・ビジョンを明確にするというのを手伝ってくれませんかというのも多いですね。

横道：なるほど。ありがとうございます。大井さんのところにちょっと戻る感じですが、やはり大きなグローバルで価値提供をしていたり、ステークホルダーがそこそこ多いプロダクトに対して、コミュニケーションの面で最初にしっかりとハブになってあげるというところが多くのケースで必要になる感じですかね。

大井：そうですね。そのケースがわりと大半かなと思いますね。

横道：「まずはとにかくWBSを引くんだ！」という印象を持っている人もいるかもしれませんが、そうではなくてわりとコミュニケーションの正常化というところなんですかね？

大井：そうですね。それぞれの話を聞いて、整理したり可視化したり、そういったところからスタートすることが多いですね。WBS以前にそういう感じかなと思います。

谷川：私のイメージでは、行ったり来たりする感じですね。WBSを作る途中で、「ここのコミュニケーションがうまくいっていないじゃん」と発見することもあると思うので、WBSをおいそれとそう簡単には作れないという課題があります。

大井：WBSを作るためにいろいろな人の話を聞かなきゃいけない感じですよね。

谷川：そうですね（笑）。組織に課題があったこのチームは、なんかやりにくそうだみたいなところも見えてきたりするのはよくあるケースですね。

後回しになりがちな課題解決を担うことが多い

横道：その時にプロダクトマネージャーとどういう役割分担をすることが多いですか？　「プロダクトマネージャーがそこをやったほうがいいのでは？」みたいなこともあり得るのかなと思うのですが。

谷川：これは私の観測範囲ですが、プロダクトマネージャーはメチャクチャ忙しいんですよね（笑）。企画とかデザインとか、クリエイティブなことをやるだけでも手が足りない。もちろんLINEの中でもチームを形成していることは多いのですが、チームを形成したとしてもやはりその開発チームとのコミュニケーションだったり、プロセスづくりだったり、プロジェクトチームの課題解決だったりというところは、やはり後回しになりがちなところだと思います。

WBSもそうですね。WBSに落とし込むまでの仕事でけっこう忙しいというのがあるので、そこがTPMの出番かなと思いますね。もちろんプロダクトマネージャーがやっている組織もあります。

横道：そこ（組織）のサイズによっても、どこまで担えるかが変わってくる感じですかね。

谷川：そうですね。

横道：例えば会社によっては、開発リードっぽい人がプロジェクトマネジメント的なことをやるケースもあると思いますが、そういう人との役割分担はどんな感じになるんですか？　大井さんはいかがですか？

大井：確かにファミリーサービスの中にも、開発リードがスケジュールなどをやっているケースもありますが、開発リードの役割は企画を技術的に実現させるというところなので、どのように実現するかを開発リーダーが考えて、それをいつやるか、きちんと進行しているかという時間軸的なところをTPMが担うかたちで分担することが多いかなと思います。

横道：なるほど。ありがとうございます。例えば全プロダクト、全プロジェクトにTPMがいるわけではないと思うのですが、複雑性が増したり、サイズが大きくなったりで、プロダクトマネージャーと開発リーダーの両方の手が回らない時いうよりは、もう少し時間をかけるべきところがある時に入るケースが多そうに感じましたね。ありがとうございます。

あとは少し別ですが、アジャイルなどの文脈で「PjMはいらないのでは？」みたいな話も挙がったりすることもあると思います。そういうのに対してはなにか思いますか？　その中でもTPMが果たせる役割というのはなにかありますか？

谷川：やはり、先ほど横道さんがおっしゃったように組織の規模感に応じて変わってくるのかなと思っています。アジャイルな組織、より小さなチームでクイックに開発しようというキーワードがあったりしますが、そういう小さな範囲で済む規模だと、もしかしたらTPMはプロダクトオーナーだったり開発リーダーだったりが担えるかもしれないです。

やはり組織が大きくなってくる、もしくはステークホルダーが多くなってくると、開発リーダーはより開発に集中する、プロダクトオーナーはよりプロダクトマネジメントに集中するためにTPMがいたほうがいいと選択するのもありじゃないかなと思いますね。

横道：ありがとうございます。谷川さんの組織は別で、アジャイルコーチもいたりするので、そことうまく両立している感じですかね。

企画開発ワークフローを整理して可視化

横道：では次のトピック、それぞれ担当しているプロダクト／プロジェクトについて。プロダクトやプロジェクト自体の説明というより、その中でのissueに対してどう問題解決をするのかという話ができればなと思っています。このあたりは大井さんに、プロダクト説明のところは簡単に、ご自身のやられている課題の話をしていただいてもいいですか？

大井：1つの例として「LINEミニアプリ」というサービスの事例を紹介したいと思います。LINEミニアプリは、飲食店に勤める方々が自分のサービスをLINE上に無料で公開できるWebプラットフォームです。

お店で行列待ちをする時があると思いますが、そういうものの整理券システムとか。レストランや居酒屋で自分のスマホから注文できるテーブルオーダーとか。あとはスタンプカード、デジタル会員証みたいなものをLINE上で実現できるサービスになっています。

これは世界地図のアジアの地図です。実はいくつ拠点があるかわからないのですが、日本、韓国、台湾、ベトナム、タイにそれぞれ企画、開発チーム、QAのチームが分散している状態です。この人たちと一緒に1つのLINEミニアプリというプラットフォームを作りあげています。

これに私たちが入ったのは2022年4月でした。サービスとしては3年目になるんですかね。入った時はこんな状態でした。とにかくカオスな状態で、プロジェクトがなんとなく進行できているという状態でした。

複数のチームが企画・開発に携わっています。彼らはミニアプリの専門チームではなく、それぞれがLINEプラットフォームの特定の機能を企画・開発しているので、複数のチームがそれぞれのバックログを持っていて、それぞれの開発プロセスや、開発サイクルを持っているという状態でした。ミニアプリとしては、それらを束ねて一貫性を持ってプロダクトをローンチしなければならないという課題がありました。

まだこれは取り組みの途中ではありますが、とりあえず最初にやったのは、ミニアプリとしてのプロダクト企画開発ワークフローを整理して可視化することです。また、開発の時にはBug Tracking Systemを使ってタスクを運用しているので、そのルールもきちんと定義して、他チームが同じような理解で進行管理ができるようにしました。

あとは複数チームがそれぞれ別のBTSプロジェクトを持っているので、ミニアプリのチケットだけを抽出して一覧化することで、みんなに「ミニアプリは今こういう進行状況だよ」と同じ方向を向けるように、この半年ぐらい取り組んでいます。ようやくスタート地点に立てたかなという感じで、日々改善を続けている状態です。

言語が異なるメンバーとは密にコミュニケーションを取ることでスムーズにスタートできた

横道：ありがとうございます。先ほどすごい数の拠点とチームの話が出てきましたが、すごくいろいろなチームが関わってくる中でどうコミュニケーションをしていくんですか？　絨毯爆撃的にみんなに連絡を取っていくんですか？　それともトップダウンでなにかルールを適用したりしているんですか？

大井：ミニアプリとして作って提案して、フィードバックもらいながら進めていったというのが実際のところなのですが、思ったよりみなさん受け入れてくださって、本当にスムーズにプロセスがスタートできたという印象だったんですね。

もう数えきれませんが、まずはそういった人たちがそれぞれがどういったプロセスで仕事をしているかを把握するのに一番時間をかけてやってきたという印象がありますね。

横道：そもそもですが、言語の壁というか、言語が違う中でどうやってコミュニケーションをするんですか？

大井：LINEの場合、通訳の組織が社内にあるので、日韓の通訳や日英の通訳さんを入れて、タイ、台湾、ベトナムと会議を進行しています。Slackなどのドキュメンテーションは英語でドキュメンテーションをするのですが、Slackについては機械翻訳のBotがLINE社内に存在しています。それを使ってコミュニケーションしている感じです。

その翻訳Botを使ったコミュニケーションも、だんだん慣れてくると翻訳Botが正しく翻訳してくれるように人間が合わせて日本語を書くみたいなスキルがゲットできるので、そういったものを駆使して丁寧にコミュニケーションをしている感じですね。

横道：TPMは、いろいろな人と現地の言葉でコミュニケーションができないといけないというわけではないということですね。

大井：そうですね。残念ながらそういう人がほとんどいないというのが、私たちの組織の現状です。

横道：わかりました。先ほど、一つずつの箱、チームみたいなところとも話していくというお話がありましたが、そこのコンタクトポイントに連絡を取って話を聞いていくという感じなんですかね。

大井：そうですね。できるだけDMにならないように、たくさんの人が存在するSlackチャンネルの上で相談事やコミュニケーションをすることは心がけています。

横道：ありがとうございます。私も日本国内だけで仕事をしている期間が社会人生活の中で長かったのですが、なかなか想像がつきにくいところではあるかもしれませんね。他の国にもTPMはいるんですか？

大井：全部ではないですが、ミニアプリが関わっているところで言うと、「LIFF」とか、そのあたりのいくつかのコンポーネントにはTPMがいます。その場合は、彼らを中心にコミュニケーションを取っています。

横道：日本以外にもTPMがいたり、TPMの組織があったりするのでそっちがやることもあれば日本側がやることもあれば、両方やることもあります。いろいろな拠点にTPMがいるので大きなプロダクトだとそこで連携したりする感じですよね。

大井：そうですね。

プロジェクトに入る上で大切なのは“信頼貯金”　信頼獲得のための武器とは？

横道：冒頭で、TPMはどちらかというと第三者的に入るとお聞きしました。一方でよくわからないやつが「プロジェクトはこうしていくんだ！」と突然入ってくる印象を持たれてしまうこともあると思いますが、そこはいかがですか？

難しさはありますか？　あるとしたらそれをどう越えているのかを、まずは大井さんに聞いていいですか？

大井：おっしゃるとおり、そこが最初の鍵だなと思っています。こういうミートアップをやっているぐらいなので、TPMが何をしてくれる人なのか、みんなの共通認識がなかなかつきにくいと思うんですね。そういう中に入っていくので、まずはいかに早く信頼貯金を獲得するかが大事なのかなと思っています。

「この人はこういうことをしてくれる人なんだな」と理解してもらう、認識してもらうことで、仕事がどんどんやりやすくなっていくと感じています。僕は、とにかくすぐにアクションすることを心がけています。

Slackだったら即レスするとか、何気ない会話に頼まれていないのに雑に絡んでいくとか、そういったこともします。信頼はギブ＆テイクと言いますが、ギブ10回に対してテイクを1回もらえればいいほうだと思っているので、とにかく自分からアクションして、いろいろなことをしてあげるとだんだん信頼貯金が貯まっていって、いろいろなことがやりやすくなっていくのかなと思って仕事をしています。

横道：ありがとうございます。社内とはいえ、特に初期こそ見定められているという点で、この人はどれだけやるのかという期待を上回っていくためにアクションしていったり、ギブしていったり、回り込んでみたりみたいなことをしている感じですかね。

メンバー間で価値観やお互いへの期待値の相互理解を促す

横道：谷川さんからも、担当されているプロダクトを絡めながらお話ししていただいてもいいですか？

谷川：大井さんのものとほとんど変わりませんが、とにかくコミュニケーションかなと思っています。キーパーソンと1on1をしたり、「リモート飲み会をやりませんか？」と言って、そのリモート飲み会の中に相互理解のゲームみたいなものをちょっと挟んでみたりしながら、自分が直接関わるであろう2、3人の一番近い関係者にはアプローチをして、まずは自分のことを知ってもらって相手のことも知るというのはよくやりますね。

その時に、「私は今まで他の組織でこういうことをしてきました」という事例を見せていくのは信頼獲得のための動きかなと思っていますね。これはとあるプラットフォーム開発組織の中でやったアクティビティなんですが、SREチームと開発チームの、このコラボレーションがうまくいっていないというのを目の当たりにしました。

なので、お互いのコラボレーションをより良くするために、そもそもお互いがお互いのチームに「期待していること」と「期待していない」こと。「これをやられたらショックだな」とかを意思表明するというアクティビティをやりました。「これは日頃からやっていたのに、実は期待していなかったんですね」というのを気づいてもらうアクティビティをやった時は、そのチームの信頼を獲得できたと実感を得られました。

チーム同士の期待値のすり合わせするアクティビティなんですが、ドラッカー風エクササイズという名前で知られている、個人の期待値のすり合わせをするエクササイズから着想して連携のアクティビティをやったりしました。

（スライドを示して）これも相互理解のやつで、飲み会の席でもよくやるんですが、例えばこのwevox values cardというプロダクトを使ってやった例だと、仕事をする上でこういうことを大事にしているなど、そのチームのメンバー個人の価値観。をシェアし合うカードゲームなんです。

「私は支援が大事だと思っています」というのを会話しながら、それをどう仕事で実現しているかとか、仕事でこういうシチュエーションではこういう行動をするんだとか、話すのも大事ですね。

まだありますね。個人、チームメンバーが大切にする価値観ですね。（スライドを示して）この例だと、谷川は情熱、混沌、貢献を大事にするんだとメンバーに紹介をします。メンバー同士で「谷川さんの貢献というマインドはすごくいいね。じゃあこれをチームの価値観にしようよ」みたいな会話をして、それをそのままチームビルディングにつなげるということも、よく真似される事例で、信頼を集める事例になっているかなと思います。

チームで大切にしたい価値観をチームで選んで、さらにその価値に合った行動はなんだろうとか、この価値観に反する行動はなんだろうとチームで対話をしながら、チームの行動規範やWorking Agreementを作る中でチームのコラボレーションを高めていく、ということもよくやります。

これも価値観に近いですが、仕事をする上でのワークスタイルですね。「私はローコンテキストで伝えられるほうが仕事をしやすいです」とか、この絵に描いてあるキツネはちょっとオマージュしているのですが、とある人の意見ですね。コミュニケーションがハイコンテキスト寄りなのか、ローコンテキスト寄りなのか、アイコンを作って「私はこうです」と意思表明してもらう。

これをチームのメンバーでシェアしようというものですね。これは『THE CULTURE MAP』という書籍から着想を得てやっています。

横道：ありがとうございます。けっこうこういうのは第三者的に入った人のほうが「こういうのをやろう」と言いやすそうですね。

谷川：まさしくそうですね。

横道：中にいる人が「改めてこういうのをやろう」というのはちょっと勇気がいるというか、他意があるのか？　みたいに思われちゃうのが怖いとかがあるので、あとから入った人のほうがしれっと言いやすい。それが成功すれば信頼のチャンスにもすごくなるなと思いました。ありがとうございます。

TPMはオーケストラの指揮者みたいなことをやりたい人におすすめ

横道：では終盤なので、質問はあと1つ、2つという感じなんですけど。ここまでいろいろ、TPMがどういうことをやっているかという話をしてきました。このキャリアのおもしろさをそれぞれからおうかがいしたいなと思っています。大井さんからまずうかがってもいいですか？　なぜそのキャリアにしたか交ぜてもらっても大丈夫です。