エンジニア・デザイナー・PM。三者連携を強めるためにできることは?【SELECK LIVE！イベントレポート】

働き方の多様化や専門技術のサイロ化など、不確実性が高まっている中、プロダクトを創り上げていくチームをどのように強化していくべきなのか。

9月27日に開催された「SELECK LIVE！」オンラインイベントでは、UPSIDER、10X、ゆめみの3社からゲストスピーカーを迎え、エンジニア・デザイナー・プロダクトマネージャーの異職種連携を強めるためにできることを伺いました。

本レポートでは3社によるパネルディスカッションの様子をご紹介します。

• keyboard_arrow_down Q1：プロダクトの方向性を決める際、大事にしていることは？
• keyboard_arrow_down Q2：職種を超えたメンバーが連携する上で、よくある課題は？
• keyboard_arrow_down Q3：異職種で相互理解を深めるために、各社が取り組んでいることは？
• keyboard_arrow_down 視聴者Q&A

工藤 元気（SELECKプロデューサー、以下・工藤）：まずみなさんにお聞きしたいのですが、プロダクトの方向性を決定するときに、無数の条件があるなかで、どういうふうに優先順位をつけていますか？

泉 雄介（株式会社UPSIDER、以下・泉）：1個の軸だけで優先順位を判断することはほとんどないですね。いろいろな軸で議論を尽くして、最も合理性の高いものからやることになると思います。その軸というのは、事業戦略との接合だったり、競合環境における自分達の競合優位性だったり、あとは事業そのものの収益性などがありますね。

あと、プロダクトチームが立ち上がった初期の段階なら、チームビルディングを優先する場合も多いです。チームが結成されたばかりのころは結束力が弱く、メンバー間の信頼関係がまだできておらず、プロセスに対する練度、働き方についても共通言語化されていない。プロダクトをつくることより先に、まずはチームのみんなで成功体験をつくっていくことを優先すべきです。

江波 拓郎（株式会社10X、以下・江波）：中期経営方針やプロダクト中期計画といった「より上位の方向性」とのアライン（＝バランスを取る、整合性を取るなど）を大前提として、インパクトや開発コスト、「Why Now?」を総合的に判断します。

10Xでは、「アライメント」という言葉を日常的に使っています。それは、組織として力を入れている方向性と、プロダクトの目指す先が足並みを揃えている状態を指しています。逆に言うと、組織とプロダクトの方向性がズレると、いくら良い機能をつくっても成果に繋がらないこともあり得ます。

そして、課題や要求が集積する中で、やりたいこと、やるべきことは、できることよりもはるかに多く溜まってきます。その中から取捨選択する時に、「Why Now?」をいつも自問するようにしています。本当に今やるべきなのか、本当に今やることに意味があるのかは、ひとつ重要な判断基準ですね。

工藤：この自問する「Why Now?」というのは本当に良い問いだなと思いました。ただ、ここで「Nowではない」と判断されたタスクについては、どのように扱っていますか？

江波：上がってきた課題や要求は全部一箇所に集積して管理してあるので、後回しにしたものもすべてトラッキングできるようにしています。今は半期を軸にそれらを見直していて、新しく上がってきた課題と合わせて優先度付けしています。その過程で不要になるものもありますし、1年越しに重要度が上がってくるものもあります。

田中 翼（株式会社ゆめみ、以下・田中）：今日パネルディスカッションに参加した3社のうち、ゆめみは「クライアントワーク」という大きな特徴があります。そのため、クライアントの事業戦略と支援するプロダクトの戦略の「接続性」「提供価値の明瞭性」「実現可能性」が非常に重要になってきます。

クライアントの戦略を理解したうえで、プロダクトは「誰にどんな価値を届けるべきか」「何のためにその価値を届けるのか」を明確にします。

江波：部門やチーム・職種間で重要視したいものや守りたいものが異なったり、背景知識、プロダクトに対する理解度などの「当たり前」が異なったりするため、「ボールが間に落ちる」ことはよく課題としてあるように思います。

10Xでは、各職種の責任をしっかり言語化してクリアにする文化が浸透しているのですが、それでも絶妙にどちらの責任とも取れそうだがどちらもボールを持たず、お見合い状態になってしまうことが起きてしまいます。課題が放置され、もしくは両方で取り合いになる場面もよくありますね。

泉：ボールが間に落ちる現象は起きやすいですね。江波さんの話を「うんうん」と思いながら聞いていました（笑）。

そうしたことが起きた時は、「相手の言っていることを言語上で理解したものの、実は同じ気持ちにはなれていない」ことが多いように思います。

案外普段では、相手に言葉の真意を再確認することを躊躇したりすることが多いんですよ。遠慮して聞けなかったりして。そういった曖昧さを背負ったまま開発などを進めてしまうと、「この人、なんでこんな些細な部分を突っ込んでくるんだろう」など、情報の不対称性故の誤解が生まれます。

だからコミュニケーションを取るときに、「なぜそうしたいのか」「実現したいビューはどんなものか」など、背景を詳しく説明することが求められます。背景を知れば「その立場だったら、確かに俺もこれを重要視するよな」と理解できるようになりますね。

工藤：田中さんはいかがでしょうか？クライアント支援事業だと、社内のみならずお客様とのやりとりもあり、より各方面との連携が複雑になりそうですが……

田中：そうですね。社内の場合、同じチームの開発メンバーとデザインメンバーは同じプロジェクトに取り組むので、気持ちがひとつになりやすいんです。

一方で、そのプロジェクトのフロントに立つPMとクライアントの間では、目標は一致していたとしても、気持ちのズレが生じやすいと思います。例えば、PM側はやる気満々で、一方クライアント側は社内政治的な要因で「一旦、ここまでやれば十分だ」と思っていたら、双方の間に熱量の差が生まれてしまう。その熱量の差が生まれることにより、言語や認識のズレが発生することはあると思いますね。

江波：熱量の違いでいうと、最近痛感したのは、文字で理解したことと、実際に現場に入ってみて、その業務を体験してみた時に「確かにここに課題があるんだね」とわかった時の腹落ち具合は全然違うことです。

我々は日常的にサービスを提供しているパートナー様からいろんなフィードバックやリクエストをいただいています。それらを文字でいただいて読むだけでも、イシューやそれが要求された背景がわかるんです。ただ、それを単に文字として受け取ったメンバーと、一緒に現場に入って体験したメンバーとは、同じ情報に触れているけど、理解度が全く違うことがあります。

泉：最近はリモートワークになって、Slackでコミュニケーション取ることが圧倒的に増えてきました。でも文字だけでやり取りしても、「やはり（1文字）2バイト以上の情報は伝わらない」と感じることが多々あります。なので、行き詰まったら「5分だけ話そうぜ」とリアルに会話したりする時間を大事にしていますね。

工藤：リモートワークもそうですが、近年グローバル人材の方々も多く活躍されていますね。そうなると、どうしても非対称性が生まれやすい環境にはなるかと思いますが、そのあたりどういうふうに対策されていますか？

泉： Cognitive Overload（＝認知的過負荷）にならないように、一人ひとりが考えられる情報や見る領域を狭くするようにしています。コミュニケーションを円滑にするために、会話の際に考えることを少なくして、目の前のテーマに集中できるようにすることが重要です。これを実現することが組織デザイン上の重要なテーマだと思います。

工藤：10Xさんはマトリクス型の組織を実践されているとのことですが、職責や機能、事業方針を縦横に浸透しやすいように、組織デザインにおいてはなにか工夫されていますか？

江波：10Xは組織構造を考える上で、「組織は事業に準ずる」という考え方を大事にしています。マトリクス型の組織を採用したのも、これが事業を営むにあたって、現時点で最適なフォーメーションだと判断したからです。我々が今フォーカスしたいチーム情報の連携や開発プロセス改善などのテーマに注力しやすいフォームになっています。

田中：組織は事業に準ずるというのは、すごく面白い考え方ですね。「良いプロダクトをつくったから、良い組織になる」わけではないし、「良い組織があるからといって良いプロダクト、良いサービスが生まれるわけでもない」ということですね。

泉：いつも心がけているのは、相手の持っている課題を他責にしないこと。自分の問題でもあると捉えて、一緒に解決しようという強い当事者意識を大事にしています。これがUPSIDERの社内にカルチャーとして存在しているのはすごく良いところだなと思っています。

田中：「自分ごとに置き換える」っていうのは、 モノをつくる、事業を進める上では本当に重要だと思います。クライアントワークは、どうしても他責的になりがちです。クライアントを支援している、受注しているという関係性を超えて、相手のサービス、プロダクトをグロースさせたい、より良くしたいという思いを持ちつつ、自分ごととして受け止めるのは、支援する時でもすごく大事なポイントかな。その際、どうやってクライアント側も巻き込んでワンチームをつくっていくべきか、いつも悩むところですね。

江波：それを実現するためには、大きな課題や困難を取り組むメンバー全員で共通理解することが求められますね。そのために一緒に現場に入ったり、一緒にユーザー分析したりしています。

田中：それに、背景のコンテキストを共有することも大事ですよね。課題だけ提示されても、自分ごとに置き換えるための共感がしにくいところがある。裏に隠れている情報も重要ですね。

江波：自分が入社してすぐの時に、ビジネスサイドのメンバーと一緒に『アジャイルな見積もりと計画づくり』という本の輪読会をやったことがあります。

当時、プロダクトをつくる側にとって、アジャイルの考え方はもはや当たり前でした。一方で、ビジネスサイドはパートナー側からのリクエストを最大限に実現するために、しっかり計画を練ってから実行することが正だったのです。双方の考え方が揃っていない中で、ビジネスサイドと開発サイドが会話しても、永遠に噛み合いませんでした。

輪読会を通して、原点に立ち戻って、お互いの大事にしている思想とその背景を理解することができました。田中さんが話したように、しっかりコンテキストを揃えに行くことは、同じ方向性に向かう上で必要不可欠なことですね。

工藤：田中さんが事前回答で、相互理解を深めるために重要なのは「コミュニケーション」、「レクリエーション」、「評価」の3点だと書いてくれていますが、この「レクリエーション」とは具体的に何を指していますか。

田中：泥臭いことを言うと、「飲みに行くって大事だよな」ということです（笑）。

泉：確かに、飲みニケーションが下手でも、実際にあったほうが効率良いことってありますね。

Webミーティングというのは、かなり高い「税金」を払っているんですよ。というのも、常に7割ぐらいでしか、情報が伝わってない気がします。同じ空間で、同じ問題をホワイトボーディングしたりとかする時間。30分、1時間かけてオフィスに行っても、ペイすると思います。その1回でコンテキストが揃えば同じ目線で仕事ができるから。

工藤：そのコンテキストを理解するのにかかっている時間が、いわゆる「オンラインコミュニケーション税」ということですね。

江波：あと、正式な会議体じゃない場での真面目な話に価値があるともよく思います。我々は結構商談で現場に行くことが多いんですけど、 現場からの帰り道はみんな気持ちが高まっているから、そこでの「感想戦」がものすごく価値が高くて、自分にとっての宝ですね。

工藤：視聴者からお三方にお答えいただきたい質問が集まっていますので、ここからはこれらの質問をもとに、よりミクロな視点からそれぞれのお考えを紐解いていきたいと思います。

1.　プロジェクトのサイクルの中で、具体的にどのフェーズから職種間の連携強化を考えていくべきですか。

田中：これはクライアントの事業フェーズや組織規模にもよるかなと思います。事業規模っていうのは、その組織の中の人数もそうですけど、事業としてどのフェーズにいるのか。投資フェーズだった場合に、シリーズAなのかシリーズBなのかというところでも結構変わってくるかなと思っています。

その上でプロジェクトに入ったときの連携の仕方としては、最初のキックオフで、全体感をつかむために連携強化は必要だと思っています。基本的には、初期のプロジェクトの開始直後に関わるメンバーの連携強化っていうのが、すごく重要になってくるかなと思っていて。

さらに、プロジェクトを進める中で、例えばCSの方と連携を取らなければいけないとか、物を売る事業会社だった場合にはセールスの方と関わらなければいけない。さらに、売るためにはどのようにPRしていけばいいのか、マーケティングメンバーと関わらなければいけないこともあります。プロジェクトを進めるにつれて、連携を強化する相手を次々と巻き込む形になりますね。

まず誰を巻き込むかの意思決定を部門内で連携して、そのうえで他部門を巻き込んでさらに連携強化して一枚岩にしていくことが重要なんです。

工藤：となると、プロジェクトが始まってからではなく、その前にもう連携を開始しないといけない、という回答にはなるんですかね。泉さん、江波さんいかがでしょうか？

泉：連携は「これは多分、1人でできない」と思った瞬間からやるべきではないですかね。気を付けていることとしては、役割を明確化して曖昧にしないこと。

UPSIDERはいま開発の足場を強化するところで、アプリケーション側とインフラ側が密に連携することが求められるようになってきました。その連携にあたって、改めて各組織の担当者の責任分野を明確にしたんです。

これはプログラミングにも共通する話で、最初から責務の設計をしっかりしないと、データ収集用のコンポーネントがいつのまにかデータの処理を始めてしまったような感じで、かなり混乱してしまうんですよね。

江波：理想をいうと、各組織がAPIのように、必要な機能を期待通りに埋めてもらう形がもっとも理想的ではあります。ただ、現実的にはそううまくいかないので、誰がどこまで担当し、どう連携するかに関しては、人と人で粘り強く情報連携することが必要になると思います。

 

2.　デザイナーが提案したデザインに対して、開発者からのフィードバックや修正の要求がある場合、それを受け入れて反映することが難しいことがあります。こうした時のコミュニケーションで意識していることはありますか？

工藤：こちらはおそらくデザイナーの方からのご質問ですね。まずはデザイナーである田中さんに伺いつつ、逆にそのフィードバックをエンジニア的にはどのように気をつけているのかという話をお二方からいただきたいです。

田中：確かに難しい場合もありますね。スクラムで開発していると、まずストーリーポイントの見積もりをしてから対応可能かどうかをお答えするようにしていますね。

デザイナーとのコミュニケーションがうまくいかないという相談だと思いますが、可能性のひとつとして、デザイン側のストーリーポイントの見積もりが甘いかもしれません。または、時間内にデザインは起こせたんだけど、実現可能性が低いものを出してしまったというパターンも考えられます。

もしくは、他の開発メンバーに聞いた時に「できるよ」って言われたけど、チケットを渡した担当者が改めて見積もって「できない」と判断し、双方の食い違いが発生することもあるかなと思っています。

このような食い違いが発生しないように、「何のためにこれやっているのか」を、いつも考えるようにしていて。もし事業やプロダクトのロードマップ上のスコープに重なっているのであれば、少々無理な修正依頼でも、受け入れるようにしています。

僕の場合は、まず自分のストーリーポイントの見積もりを踏まえてできる限り調整し、難しかった場合は「どこまでなら技術的にデザインに合わせることができるのか」をお互いに歩み寄って検討するようにしています。

泉：組織的に「常にnegotiableである」ことは大事だと思っています。

プロダクトのことをめちゃくちゃ知っているのはエンジニアだったりします。そのため、デザインについて検討するシチュエーションでも、「これ、そもそも顧客の課題を解いてないのでは？」など、最初の要件定義まで遡って検討する場合があります。良いプロダクトをつくるために、そこを突き詰める「余白」をはじめから用意する必要は組織としてあると思いますね。

江波：お二方のお話を聞いていると、ものづくりを進めるに当たって「そもそも今回解決したい課題はなんなのか」など、出発点を明確にしておくことが非常に大事だと感じました。

出発点を明確にした上で、さらにフィードバックが上がるということは、必ずなにかしらその出発点に対してコミットできてない動きがあるからだと思います。そこの認識のすり合わせをお互いにできていれば、ハレーションが相対的に起きにくいはずですね。

泉：あと、プロダクトの事業責任を持ち、最終判断をするのが大事だと思うので、決定権が誰にあるのかを明確にすることも重要ですよね。

 

3.　自社で各職種の連携がうまくいった、良い成果が出せたと実感した実例があれば教えていただきたいです。

工藤：さきほど江波さんが異職種の連携を深めるために、現場観察にいったり、輪読会を実施したりする例を上げてくださいましたが、そこの事例をもっと詳しくおしえていただけますでしょうか？

江波：「実際に現場にいく」ことを例にすると、2パターンあります。ひとつは職種横断で現場に行って、実際にいちスタッフとして仕事をさせてもらう、いわゆる「現場体験」ですね。実際に自分たちがつくっているプロダクトを使って業務を行うことで、いろんな課題が発見できるわけです。

そこでポイントとなるのは、やはり職種を問わずチーム全員で行うことですね。PMの私だけが現場にいって持ち帰って言葉で伝えるのではなく、一緒に体験をして同じ絵を見ている状況をつくって考えるというのは、非常に有効かなと思います。

もうひとつが、つくったプロダクトが使われている現場にいって、その使用シーンを見学させていただく「現場観察」です。これはまた、実際に体験するのと違う発見があったりします。

具体的には「こういうところで躓くんだ」とか、「そのような使い方をされるのか」などの課題発見につながります。職種横断で一緒に見ることで「 そういえばあの時、こんな課題があったよね」と引き出しをもつこともできますね。

泉：自分も前職は物流業界のサービスをつくっていたんですが、その時に40か所ぐらいの物流の現場をデザイナーやエンジニア、PMで見に行って、みんなで現場の解像度を上げることをやっていました。

江波さんがおっしゃっていたように、みんなの共通言語になりうるのは、顧客のことなので、そこに立ち返る体験は必要不可欠だと思いますね。

田中：僕の場合、前職が事業会社だったので、そこでの経験を事例として挙げると、 プロダクトオーナーと、エンジニア、デザイナーが一緒にユーザーインタビューとユーザビリティテストを実施していました。

同じものを同じ時間、同じ空間で見ているので、意識が揃います。そうすると、その後で爆速にイシューを立てるようになったり、開発メンバーから逆に「もっとこうした方がいいんじゃない」などアイデアが出てきたりすることもよくあります。

ゆめみでも、事業会社のプロダクトづくりを支援していた時に、普段は現場に行かないCSのメンバーが同行したことがあります。そうすることでプロダクト側は普段と異なる視点でイシューを立てられるようになったし、CSのメンバーもプロダクトで課題をどう解決したらよいのかの視点を持てるようになりました。非常に大きな成果だと思います。

 

4.　特にスタートアップの初期フェーズでは、連携強化まで意識が向かないことが多いと思います。組織の拡大に伴って連携強化が必要になったら、まず何から取り組むべきでしょうか?

工藤：今日のお三方のお話を聞いていると、「連携強化は早い段階から必要だ」というふうに感じますが、いかがでしょうか。

江波：キャリアの初期に、創業初期の社員数1桁のタイミングで参画したこともありましたが、正直連携強化を意識していなかったんですね。それは、リソースの関係上連携強化に意識が向かないっていうよりも、まだまだ関わる人数が限られているので、向ける必要がないというほうが正しいかもしれません。

ただ、少しずつ事業のフェーズが変わり、組織が拡大していくにつれて、暗黙の了解でできていたことは、少しずつできなくなっていく。それが明るみに出るタイミングで初めて、連携強化を意識する必要が出てくると捉えていました。

工藤：いわゆる「30人の壁」を意識した時に、江波さんのいうタイミングがくると思うんですけど、まず何から始めたらいいでしょうね。

田中：第一歩はドキュメンテーションでの言語化、コミュニケーションの設計だと思います。このプロジェクトについて話す時はこのチャンネルで、など、基礎的なことですが初期の仕組みをつくるところがポイントになるのかな。

泉： 30人の壁って、名前と役職を覚えられる最大人数のような気がします。30は一見大した数字にはみえないけど、ハンドシェイクの数を求める数式で計算してみると、コミュニケーションパスは450ぐらいになるんですよ。

30人までは、だいたいみんなニックネームで話し合うぐらいの感じでやっているところから、段々「HRの山崎さんね」とか、役職の話が出てきて。最後に「人事部にお願いしよう」と、組織単位になっていきます。呼び名の変化からも、組織フェーズの移り変わりが見えますね。