第三者的な立場を活かして“組織間のコミュニケーション改善”を担う組織　LINEがテクニカルプログラムマネージャーを専門組織化している理由

欧米テック企業にも見られる職種、テクニカルプログラムマネージャー（TPM）

横道稔氏（以下、横道）：テクニカルプログラムマネージャーという仕事について、ご存じの方も初めて聞いた方もいろいろいらっしゃるかなと思うので、前段の知識を簡単に私からお話しします。

TPM（テクニカルプログラムマネージャー）ですが、世の中にある定義を少しだけ引用させてもらっています。これは「Indeed」ですね。海外で求人を出しているIndeedはさまざまな職種の定義を記事にしているのですが、そこから抜粋しているものです。

英語の記事ですが、1行目をパッと見てみると、「会社にある複数のプロジェクトをoversee……ちょっと適切な日本語が難しいですが、監督する役割ですよ」と書いてあります。テクニカルプログラムマネージャーが必要な理由は、「ビジネスにはテクノロジーを使ったプロダクトや、ソリューションが必要になってきているからだよ」みたいなことが書いてあります。

もう1つ、GoogleでもTPMを置くことがあるというのは、比較的よく知られています。Googleだけではなく、さまざまなビッグテックがTPMの職を置いていることがあります。その中の求人ディスクリプションを1つ取ってきました。これもスライドの上のほうに「エンジニアリングプロジェクトをエンジニアリングの専門性を持ってリードしますよ」とTPMの役割が書いてありますね。

そういうものを踏まえながら、LINEの中ではどう定義しているか。LINEの中の定義ですが、スライドの下に書いてある英語が原文です。翻訳したものを上に書いているのですが、LINEにおいては「TPMというのはテクニカルプログラムマネージャーのこと」「一般的な責任は以下である」と、2行ぐらいで簡潔に書いています。

1つ目に「プロジェクトマネジメントと、テクノロジーやIT産業に関する能力、専門性を持って、プロジェクトやプログラムのスムーズな遂行を行う」ということが書いてあります。2つ目に「開発プロセスを継続的に最適化し、改善する」というようなことが書いてありますね。

「プログラム」という言葉は、先ほどのものにも出てきたのですが、これが何を指しているかというと、プロジェクトマネジメントの用語において出てくる言葉で、組織の中でマネジメントされているプロジェクトの集合です。複数のプロジェクトを統合して、まとめるようなものをプログラムと呼ぶことが多いのですが、そのことを指しています。

プロダクトマネージャーやプロジェクトマネージャーとの違いとは？

そのため、テクニカルプログラムマネージャーはプロジェクトマネージャーと何が違うのか？　みたいな話がよくあります。このあと少しお話ししますが、すごくざっくり言うと、（テクニカルプログラムマネージャーは）プロジェクトマネージャーという範囲の中に入る職種だと捉えてもらうとわかりやすいんじゃないかなと思います。その中でよりテクニカルな専門性、エンジニアリングの専門性を強く使って開発チームと密に連携をしたりする職種ですね。

もちろんこのTPMに限らず、世の中のさまざまな職種は「必ずこういう役割分担になるんだ」「こういう役割定義になるんだ」と、決まってはいないと思います。その時々のプロジェクト、プロダクトチームによって微妙に差異が出てくると思いますが、それはTPMでも同じかなと思います。なので、プロジェクトの中で、どういう役割範囲だったのか？　みたいな話も今日のパネルディスカッションの中で話せればと思っています。

なので、ざっくりの理解としてはプロジェクトマネジメントの1つと考えてもらいながら、その中で、エンジニアリングのバックグラウンドや専門性を活かしてプロジェクトマネジメントを行うような職種である。さらにプログラムなので、プロジェクトを複数束ねるようなものをマネジメント対象にすることが多い、というのがこの職種の特徴になります。

一つひとつの白い丸がありますが、これはプロダクト開発において必要になる主要な仕事自体をざっくりと取り出しています。

例えば、プロダクトマネジメントと呼ばれるような行為があり、それにオーバーラップするかたちで、例えばUXのデザインとかUIのデザインとか、いわゆる広義のデザインがあったり、エンジニアリングを使ってそれを実現していくというものがあったり、それぞれとオーバーラップするかたちでプロジェクトマネジメントの要素もあると思います。

ちなみにこれは、丸の大きさに意味はないので、イメージとして捉えてください。その中でTPMは、（スライドを示して）特にこの3つの領域をオーバーラップすることが多いので、ここに位置付けられています。

つまり一番は、プロジェクトマネジメントの領域をやることであり、それのエンジニアリング部分との橋渡しをするような職種であり、なおかつプロダクトマネジメントとも橋渡しをするような、（スライドを示して）このあたりのちょうど間かつ、プロジェクトマネジメントに寄ったところに存在している職種とイメージをしていただけるといいかなと思っています。

プロジェクトマネージャーやプロダクトマネージャーとの違いは何か？

プロジェクトマネージャーやプロダクトマネージャーとの違いは何？　というのが疑問として湧いてくるかもしれません。プロジェクトマネージャーについては今お話したとおりですね。広義にはプロジェクトマネジメントを多くやりますが、その中でもやはりエンジニアリングをつなぐ部分であったり、エンジニアリングのバックグラウンドを活かしてプロジェクトマネジメントをするというところが1つの違いかなと思います。

プロダクトマネージャーとの違いですが、プロダクトマネージャーはどちらかというとプロダクトマネジメントをやることであって、TPMはプロダクトマネジメントをサポートしたり、一部を担うことはありますが、決してそこをメインにしている職種ではないので、多くのケースでプロダクトマネージャーとに協業してそのプロダクトを作ったり、プロジェクトを進行したりすることが多いかなと思います。

なので、オーバーラップするところもありますが、うまく役割分担していく職種になるかなと思います。

LINEのファミリーサービスの企画・開発に広く関わり、サービスを成功に導く「テクニカルPM室」

横道：前段としての説明はこのあたりにして、実際の話に入っていこうと思います。先ほど自己紹介でお二人の組織名など紹介していただきましたが、お二人が所属しているのは、あるプロジェクトの中にある組織とか、あるプロダクトチームの中にある組織というよりは、CTOの下にぶら下がっているような組織だと思います。一種の特徴を持った組織だと思うので、そこも前提情報として少し説明をしてもらえればなと思っています。では大井さんからお願いします。

大井宏友氏（以下、大井）：私が所属しているテクニカルPM室は、（スライドを示して）このような組織の目的を持っています。このあと説明しますが、LINEのファミリーサービスの企画・開発に広く関わり、関係者との合意形成をリードし、サービスを成功に導くというのを役割としています。また最近では、サービスに限らず、組織やサービスを横断したプログラムに関しても広く関わっていくという取り組みを始めています。

LINEファミリーサービスはどういうものか。LINE社がみなさんに提供しているサービスは多種多様です。一番有名なのは、スライド左上のコミュニケーションアプリとしての「LINE」ですが、そのほかにも広告をやっていたり、「LINE NEWS」というサービスを提供していたり、「LINEギフト」というサービスがあったり、LINE社はさまざまなサービスを提供しています。

（スライドの）真ん中がテクニカルPM室のTPMが担当するサービスです。主にコミュニケーションをするのはプロダクトマネージャーや、開発者や、エンジニアですが、そこの間に立って橋渡しをしています。

LINEのファミリーサービスは、LINEのプラットフォームを使って提供しているので、実はサービスを開発・運営するためにLINEのプラットフォームの人たちと密にコミュニケーションを取っています。もちろんLINEのコミュニケーションアプリのみなさんとも一緒に仕事をしています。

また、LINEの場合、別の本社組織としてリーガルとかセキュリティなどがあるので、そちらの人たちともコミュニケーションを取ることもあります。同じファミリーサービス同士の連携も昨今増えてきているので、他のサービスのPMやエンジニアとも会話することもあり、「いろいろな人たちとの橋渡しをするハブ」みたいな感じで仕事をしていることが多いです。

横道：ありがとうございます。役割分担については、またあとでお話を聞かせてもらいたいと思います。

チームとプロダクトのデリバリーのプロセスをより効果的にする「Effective Team and Delivery室」

横道：谷川さんの組織もご紹介いただいていいですか？

谷川能章氏（以下、谷川）：Effective Team and Delivery室という、ちょっと取っつきにくい名前ですが、チームとプロダクトのデリバリーのプロセスをより効果的にするための改善活動や変革の支援をしている組織になります。

Effectiveというのは、いかにユーザーにより大きな価値を早く届けるかというところを追求することだと思っています。その効率性や生産性だけを求めることではないと考える中で、さまざまな支援をしています。右の絵にありますが、現場で開発をしているその開発のリーダーたちに寄り添って、改善を支援することが多いですね。

仕事の仕方としては、特定の組織から依頼を受けて支援をしたり、社内横断的な取り組みをしたりすることがあります。CTOの直下にEffective Team and Delivery室（ETD室）があり、その配下に2つチームがあります。

そのうち1つがLean & Agile Teamです。これはリーンやアジャイル開発の専門性を持つチームです。もう1つ、Delivery Management Teamというのがあって、こちらにテクニカルプログラムマネージャーという職種の人たちが在籍しています。

（スライドを示して）これがETD室が今やっている仕事ですね。情報量が多いのでかいつまんで説明すると、メインの仕事は、チームやプロジェクトの変革、改善の支援です。補助的にやっている仕事は（スライドの）右のほうですね。支援をより効果的にするための活動に取り組んでいます。（スライドの）左のほうは、変革と改善の支援なので、プロジェクトに入ってプロセスを改善したり、アジャイル開発のやり方を指導したり、コンサルティングをしたりということをやっています。

関わり方を下に書いていますが、コンサルティング、コーチング、ファシリテーションをすることが多いです。対象も依頼のあった特定の組織だったり、LINE全体におけるプロセス改善だったりします。

コンサルティング、コーチングの支援活動を効果的にするために、社内に広く改善事例の発信したり、実践的ガイドを作ったり、トレーニングやツールを作って提供したり、そのツールを使える人を育成したり、社内コミュニティの運営をしたりしています。

社内には人事やCTO officeなど、横断的に改善をする組織があるのですが、そのような組織と協業して、社内横断的なプロセス改善の施策を実施しています。

ハブになるのではなく「私たちが改善をする」

（スライドを示して）これはETD室が仕事をする上で大切にしている価値観ですね。チーム・プロジェクトの改革／改善の支援においては、私たちがTPMというロールをもって、プロジェクトのハブになるというよりは、どちらかというと「私たちが改善をする」。もしくは自律的な組織づくりをしたり持続的な仕組みづくりをしたりする、というのが私たちが大事にしている価値観です。

なので、本当の理想を言えば、将来的に私たちが消えてなくなっても組織がうまく回っているという状況を実現するための支援をしたいなと思っています。（スライド）右側の支援をより効果的にするために、より多くの部署や組織が参考にできる汎用的で実践的なガイドを作ったり、より広範囲で変化の大きなツールを提供しようとがんばっています。

私たち自身がプロジェクトマネージャーとしての役割を担うのではなく、教育、コンサルティング、仕組みづくりなど、変革を支援するための取り組みをしています。私の組織は以上です。

横道：私の視点から2つの組織を見ると、大井さんのテクニカルPM室は、比較的直接ハンズオンのTPMとして入って、そのプロジェクトを成功に導くというのをメインの仕事にしていて、谷川さんのETD室は、どちらかというと少しコンサルタントやコーチのような入り方をしてTPMを育てつつ、その過程の中でご自身もTPMをやるというような、ちょっと棲み分けの違いが会社の中であるのかなと思っています。

両方ともCTOに並んでいますが、経路の違いがある中で2つの組織が補完関係というかたちで活動をしているような印象を持っています。

谷川：ありがとうございます。

TPMをなぜ専門組織化しているのか？

横道：ちなみに私からもう少し補足をすると、LINEにいるTPMがすべてここに属しているわけではありません。各プロダクトやプロジェクトの中にも専任のTPMがいます。そういった人たちがいながら、なおかつ専門組織としてTPMを集めた組織をCTO室の下に作っているかたちになります。ここはなんでこういう構造を取っているんですかね？　大井さん、組織の意図について教えていただけますか？　

大井：もともとはLINEファミリーサービスを担当するTPMということで、位置づけしたのですが、TPMとしてそのプロダクトに入っていくと、同じ役割をしている人は基本1人になりますよね。エンジニアがたくさんいる中で、TPMは1人という感じだと思います。

そうすると、ノウハウが獲得できにくくなります。他のサービスが何をしているかが見えにくくなるというのが1つあるので、組織化することでTPMとしてのノウハウや知見を溜めて、他のサービスへ転用するという動きを比較的しやすくするために専門組織にしています。

もう1つ、先ほど丸がたくさんある絵が出てきましたが、TPMは立場的にさまざまな役割の人とちょっとずつ関わりながら仕事をしているので、若干中立性が求められる立場になるのかなと思っています。組織を別に分けることで、中立性がより担保しやすくなるのかなと思って組織を分けています。

横道：ありがとうございます。ここのところは谷川さんも大井さんと概ね一緒なのかなと思っていますが、なにか補足はありますか？

谷川：そうですね。やはり第三者的な立場で改善をしていくことで、現場からありがたがられることも多いと私も仕事をしていて感じています。他の組織の人が見てくれるというのは1つのメリットとしてあるのかなと思いますね。

横道：ありがとうございます。そうですね。ある意味レポートラインではない人は、言いにくいことも言えちゃうところもあって、それまで現場の中でちょっと見過ごされていたり、蓋されていたものに切り込んでいくところで顧客のメリットになっているところはありますね。

LINEのTPMの役割パターンとは？

横道：ではいよいよ、より本題的なところに入っていければと思います。TPMとして実際にプロジェクトやプロダクトに入る中で役割分担のパターンがいろいろあると思うんです。

主にそのTPMという役割は、どういうところを中心にやっている職種ですか？　特に先ほども出てきたPMやエンジニアとの線引きみたいなところとか、逆にオーバーラップするところとか、そういう観点も交えながら「こういうのが多い」とか「こういう場合もある」とか、そういうのをいくつか聞かせていただいてもいいですか？　では谷川さんからいきましょうかね。

谷川：そうですね。基本的にプロジェクトマネージャーがやる仕事を期待されることは多いです。例えば『PMBOK』に書いてあるようなステークホルダーマネジメントや、リスクマネジメントやタスク管理。これは『PMBOK』に載っていませんが、タスク管理を期待される一方で、そのふりかえりをやって、プロセスの改善のきっかけを作ったり。

他の職種の方々とエンジニアの方々を巻き込んでプロセスの改善のきっかけを作っていくことを求められているわけではありませんが、先ほど大井さんが言ったように中立的な立場を活かして組織間のコミュニケーション改善の役割を担うことがけっこう多かったりしますね。

横道：ありがとうございます。大井さんもいかがですか？　

大井：実際に入ってみると、そういうコミュニケーションのところは、私たちが入ったほうがうまくいくなと思う時が多いです。入る時に実際にリクエストされることとして、1つはプロダクトのプロダクトサービスを作っていく上で、いつ・何を・どういう段取りで作っていくのか、スケジュール決めをリードすること。

これは、わりとどんなサービスでも求められますが、エンジニアが作るものを具体的にイメージできるように企画者と一緒に企画書を考えるなどの役割を持っているケースもあります。

あるいは、先ほどスケジュールを決めて進行管理をするという話をしましたが、それよりは本当にチーム間や組織間のコミュニケーションが課題だから、そこにもうどっぷり間に入って本当にハブとなってコミュニケーションしていくという役割が落ちていたりなど、わりとバラエティ豊かだなと自分の組織を見ていて思います。

横道：ありがとうございます。

（次回へつづく）