バイリンガルな人材がゆえに悩むこと
浪川舞氏（以下、浪川）：意外とすぐに使えそうなTIPSがいろいろあって、おもしろかった（笑）。ありがとうございます。次の質問どれにしようかな。
新しい質問で、グローバルメンバーへのファシリテーションをどうしていますか？ 特に日本語を母国語としないメンバーや、文化の違うメンバーがいる話でいうとどうですか。
ちなみにリリーさんのところは、たまたまリリーさんがフランスに住んでいただけで、メンバーがグローバルというわけではないんですか？
岡本リリー氏（以下、岡本）：私は2ヶ月ぐらいフランスにフラフラしに行っていただけで、住んでいたわけではないです。
浪川：フラフラしてフランスにずっといたんですね（笑）。
岡本：当時いた会社では、基本的にはビジネスサイドのチームは日本にいることが多くて、営業は日本のメンバーが多いんですが、ITデパートメントはほぼ全員がリモートです。一番遠いところはイギリスで、あとはロシアやユークレイン（ウクライナ）やインド、タイ、フィリピンとか。アメリカからは採用はしていないのですが、ヨーロッパ圏までタイムゾーンのところは全部カバーしていました。
みんな日本の企業に勤めているという前提条件があるので、日本語で話しているメンバーがいることが当たり前という中で働いているのは、ちょっと特殊なのかもしれないですね。
浪川：うんうん、そうですよね。じゃあ彼らは一応日本語はわかる方ということですか？
岡本：いや、それも本当にさまざまで、わかる人もいるし、まったくわからない人もいます。
浪川：へえ。その場合、ミーティングは英語でしゃべるんですか？
岡本：そうですね。やはりそこにすごく高いハードルがあって、ボトムアップとトップダウンのどちらでも動かなければいけないのかなというのは、そこにいてすごく感じました。
やはり会社としてどうしたいのかをハッキリさせるべきです。これはどこの会社もそうなのかなとは思っているのですが、会社としてどういうふうになっていきたいか、どういう人材を大事にしていきたいのかをハッキリさせてもらわないと、バイリンガルな人材は特に悩みますね。
浪川：確かに、かえって悩んじゃうっていう。
岡本：どっちに合わせてどっちを大事にしていくのかをハッキリしてもらわないといけない。中途半端なファシリテーションをすることが、やはりファシリテートしている人間だったり、言語ができない人をつなぐ役割を必然的に果たさなきゃいけない人間だったりにとって負担になってくるので、そういうものは上に上げますね。会社としてどうしたいの？ というのはけっこう上げるようにしています。
浪川：ああ、確かに。それは会社として決めておきたいですね。
岡本：やはりボトムアップの部分ではできることをやっていく感じになるので、なかなか決まりを決めにくい部分もあるので会社によりますけど。でも私はバイリンガルの人材として採用はされていますが、翻訳をすることが私の業務ではないというのをハッキリしています。
私は時間を使って、そこのプロフェッショナリズムやエクスパティを伸ばしたいわけではなくて、プロダクトマネジメントにもっと時間を割きたいです。
浪川：ふんふん、確かに。
岡本：なので、翻訳業務が増えてきたら「ここまで私がやらなきゃいけないのだったら、翻訳の人を雇ってください」と私は言うようにしてます。
浪川：そうですよね。たぶんこれはオフショアをしている会社のPM（プロダクトマネージャー）の方もたぶん同じような悩みを抱えている人が多いんだろうなと思っています。前に、日々が翻訳で終わるみたいなことを言ってる方がいたので。
そうなってくると、なんの仕事をしているんだっけ？ というふうになっちゃいますよね。
岡本：そうですね、そうですね。
日本人しかわからないネタをアイスブレイクに使わない
浪川：なるほど。ちなみに久津さんは、スーパー悩んでいますとコメントされていますが、今どうしているとかってありますか？
久津佑介氏（以下、久津）：うちも今部門の10パーセントがグローバルメンバーで、全員日本語はある程度は話せるんですが、細かいニュアンス、特に機能や目的など、日本語だと細かなニュアンスが正しく伝わらないことはけっこうあります。
なんの答えもないんですが、一応気をつけているのは、先ほどお話ししたアイスブレイク。日本人がやりがちなのですが、日本人しかわからないネタを使うというのがあります。
浪川：ああ。
久津：例えばCMや、芸能界のこと。そういうのは日本人だけだったらいいのかもしれませんが、「これウケるだろうなぁ」と思っても、やめるようにはしています。
小さなTIPSはあるのですが、根本的なところはまだまだ悩み中です。
浪川：確かにそうですね。難しい問題ですよね。コンプラ的にも、文化として日本では許されている冗談でも、海外だと許されないとかありますもんね。そういうことを知らなくて事故ることはありそうなので、そのあたりは前提知識として持っておきたいです。
その場で意思決定をしないほうがいい時もある
浪川：これもちょっと聞いておきたいです。これは沈黙と真逆の気がしているのですが、意見が割れたり荒れたりすることも、たぶん時々起こるんじゃないかなと思っています。
派閥じゃないけれど、誰々が言っていることと誰々が言っていることでバチバチする時にどう収束させていますか？ 杉原さんどうでしょう。
杉原達也氏（以下、杉原）：はい。意見が割れる場合は、だいたい最初に割れそうなのがわかっているので構えていきます。ある程度、メリデメや判断軸をNotionに型で用意しておいて、発言をそこに当てはめながら話すようにはしています。
なので、感情的になってしまったり「そこは本質じゃないでしょ」というのを言われた時は、見ている人が全員わかるようなかたちで書くのは1つあるかなと思っています。
もう1つあって、その場で意見、意思決定をしないほうがいい場合もあります。例えば、「現場だけではなく、代表を連れて来てその場で承認をもらうかたちにしましょうよ」なのか、「ただ先送りにして1日寝かしたほうがみんな冷静になれるから、明日もう1回話しましょうよ」みたいなかたちで、あえて場を分けることをやろうとしています。
浪川：うんうん、確かに。そうですよね。議論とぜんぜん関係のないところで言い合いが始まっちゃったりすることもあるので、そこは何を決めないといけないんだっけ？ というのはファシリテーターが持っておきたいですもんね。
いったん“目的はなにか”に立ち返ってみる
浪川：井上さんも荒れてしまった時の対応は何かありますか？
井上慎也氏（以下、井上）：どうですかね、難しいなぁ。僕はふだんスクラムの開発をしていて、対立することはあまりないんですよね。
例えば、ユーザーストーリーマッピングと呼ばれる、ユーザーの業務をニューラルとかで可視化していこうみたいなのとか、「なんでそもそもこれは必要なのだっけ？」みたいなのをまとめて、（意見が）割れた時にそれに立ち返る。「あれ？ 結局今ってなんの話をしたんだっけ」「何を目的にやっているんだっけ」というところに立ち返ったら、場が荒れにくいんじゃないかなとは思っていますね。
チームの雰囲気は、誰がメンバーとして参加しているかにもよるとは思います。積み上げていくところでエモい話に持っていくのは鉄板なのかなと思いますが、結局なんのためにこの仕事してるんだっけ？ みたいな（笑）。これは誰が喜ぶんだっけ？ というところに行って、どうしても意見が対立するのであれば、先ほどおっしゃったように持ち帰ります。
その場で対立して解決できないことは、たぶん情報が足りないか、検証していないから答えが出ないところに対して空中戦で議論していると思うので、じゃあ次にこの検証をやりましょうとか、ネクストアクションを決めることが重要だとは思っています。可能であれば、そこで答えを決めきるのを先送りして、それを砕くためのタスクをまず入れるのが鉄板なのじゃないかなぁという気がします。
浪川：うんうん、確かに。
井上：ただ、けっこう抽象度が高いので、難しいですけれど（笑）。
浪川：ありがとうございます。そうですよ。ふだんから変な対立をしない雰囲気を作っておくのは一番大事だなというのと、ネクストアクションを決めてあげるのが確かにファシリテートの役目でもあるので、すごく良いTIPSになったのではないでしょうか。ありがとうございます。
プロダクトマネージャーとプロジェクトマネージャーの役割は違う
浪川：延々と全部話したいところではあるのですが、そろそろお時間がきてしまうので、最後にファシリテートとは関係ないのですが、みなさんにこれを聞いてみようかなと思っています。
「こうだよね」という記事もいろいろたくさん出てはいるのですが、みなさんの中でプロジェクトマネージャーとプロダクトマネージャーの違いはどう捉えているのかなというのが私も気になっています。リリーさんはいかがでしょう。
岡本：いやぁ、難しいですよね（笑）。
浪川：（笑）、難しいですね。
岡本：先ほど井上さんもおっしゃっていましたが、スクラム的な考えで、私がやるプロダクトの開発方法だとPjM（プロジェクトマネージャー）は要らないというところにいつも落ち着くんですよね。
やはりそれは全員が、開発のメンバーがみんなで解決策を考え出しているというところと、各自が責任を持って自分の役割を果たすところにフォーカスしていれば、プロジェクトをマネージする必要はそこまで必要だと感じたことがほとんどありませんでした。
浪川：うんうん、スクラムが自走してるんですかね。
岡本：それが必要だなと感じる時は、やはり個人がまだそこに対してそのマインドを持てていない時です。私はPjMを雇うよりも、マインドを育てていくほうを取ります。
でも複数のプロジェクトが乱立していて、それをまとめてほしいみたいなのはあるので、プログラムマネージャーなのか、プロジェクトマネージャーという名前で解決するのかはわかりませんが、そういう部分で見てくれる人がいるのは助かるなと思う時はありますね。
浪川：ふんふん。ではリリーさんとしては、プロダクトマネージャーが、いわゆるプロジェクトマネジメントみたいなことをやるのは、別の役割だよねという感じですかね？
岡本：そうですね。プロジェクトマネージャーはすごくいろいろなスキルを持っていると思うんですけど、PdMは全部持っているわけではないので。
浪川：うんうん、確かに。
岡本：そこを期待されると、逆にPjMに期待されていることが、私はぜんぜんできませんと毎回言っています。
浪川：あはははは（笑）、まぁそうですよね。そこがけっこうまだ、業界的にも理解が浅い部分なのかなとは確かに思いますね。うんうん、ありがとうございます。
プロダクトマネジメントとプロジェクトマネジメントの違いは“納期”
浪川：では、PjMとPdMの違いについて、杉原さんはいかがでしょう。
杉原：はい。僕はこのSpotifyというかPodcastを聞けばいいんじゃないかなと思ってリンク貼ったんですけど。
浪川：あ、リンクを送っていただいてますね。
杉原：はい。そこに出ていたかもしれないですけど、一番は納期なんじゃないかなと僕は思っています。プロジェクトは終了の条件がある前提なのですが、プロダクトは終了条件はあまりなくて、際限なく成長を求めていくものだと思っています。
プロダクトマネジメントをするためにたくさんのプロジェクトマネジメントをしなきゃいけないのかな？ という捉え方で考えている人間です。
浪川：うんうん、確かに。わかります。
杉原：たぶんいろいろな解釈のうちの1つかもしれません。
浪川：そうですね。確かに、プロジェクトは、ある種、範囲がある程度決まっている中でどう調整するかというマネジメントですもんね。
プロダクトマネージャーとプロジェクトマネージャーは視線の向きが違う
浪川：井上さんはいかがでしょう。
井上：杉原さんのおっしゃるのが、僕も近いかなと思います。わかりやすい違いは、プロダクトマネージャーは視線が基本的にお客さんのほうに向いていたり、市場のほうに向いているのですが、プロジェクトマネージャーは内向きで、チームのメンバーがどうとか、タスクがどうというところを見るほうが多いのかなと思っています。
プロダクトマネージャーは、常にビジネス的な価値を担保しなければいけないところがあるので、社会的にけっこう広く外向けに見ています。
プロジェクトマネージャーは「これが決まりました」「これがゴールですよ」というところを管理していくみたいな、メンバーのケアがメインになってくるので、メンバーと常にいろいろやってみたり。
もちろん2つともやるとは思うのですが、基本スタンスがそう違うのかなという気がしています。プロダクトマネージャーが、ずっとユーザーインタビューに行っているのが、僕は良いプロダクトマネージャーだと思っています（笑）。
浪川：いかにユーザーに寄り添えるかというところが、プロダクトマネージャーの仕事でもありますよね。今この話を聞いていて思い出したんですけど、以前アンケートを取らせてもらった時に、プロダクトマネージャーをされている方は仮説検証やユーザーヒアリングに悩んでいるという答えがすごく多くて、プロジェクトマネージャーの方は、エンジニアとのコミュニケーションに悩んでいる方が多かったので、確かにそこは内向き・外向きみたいな違いはあるかもしれないですね。
位置付けと責任を持つ場所が違う
浪川：では最後に久津さん、このあたりはいかがでしょう。
久津：ちょっとこの質問の問いは厳しいなと思いつつ。
浪川：あははは（笑）、重いですね。
久津：メチャクチャ考えていました。私もちょっと前、リクルートにいた時はプロジェクトマネージャーをやっていて、そこからプロダクトマネージャーに変わっているので、あの時の自分と今の自分で何が違うかなというのを、今ちょっと考えていたんですけど。
やはり会社によってぜんぜん違うというのが前提にあります。ただ、1個共通点かなと思うのは、プロダクトマネジメントはやはりそのプロダクト、あるいは事業に対してどういう方向性でいくのか、次は何を検証しなきゃいけないのか、何をしていくのかみたいな、大きな枠の中にプロジェクトがいくつかあると思っています。
なので、このプロダクトの全体の戦略の中にプロジェクトが何個かあって、プロジェクトマネージャーはここのゴール設定がもうあるはずなので、そのゴールにいかに進むかという役割なのかなと思っています。
私がプロジェクトマネージャーだった時は、例えばリクルートだとリクナビをやっていました。（ジェスチャーをしながら）リクナビのこのプロジェクトの担当リーダーだったんですが、隣でやっているまた違うプロジェクトに関しては、もちろん情報連携はするものの、自分ごとというレベルでは考えていなかったのですね。
ただその当時のプロダクトマネージャー的な役割の方は、そっちとそっちのバランスを見てどっちに投資をすべきなのか、みたいな視点で見られていたなぁと思うので、そういうところの違いかなと思います。
包含と言ったらアレですが、そういう位置付けでそこに責任を持つという違いかなというジェスチャーをしていましたが、すごく抽象的です。
浪川：はい、そのジェスチャーがすごくわかりやすかったですよ（笑）。ありがとうございます。
みなさんが共通しておっしゃっている、やはりプロダクトマネジメントの中に、その範囲としてプロジェクトマネジメントがあるというのが1つの解なのかなぁとは思います。こちらの質問をしていただいた方、この答えでよろしいでしょうか（笑）。
みなさん、いろいろと答えていただきましてありがとうございました。実は、まだ答えられていない質問がたくさんあったり、たぶん私がまだ見えていないだけで、そのあとに投稿してくれている質問がいっぱいあると思います。また明日くらいに、登壇者の方に「こんな質問が来ていました」と共有させていただくので、Twitterとかで答えていただければ幸いです。本日はパネルディスカッション、ありがとうございました。
