2024年からスタートした「SELECK miniLIVE」は、注目企業からゲストスピーカーをお招きし、X（旧Twitter）スペース上で30分間の音声配信を行う新連載企画です。

仕事の合間や移動中、プライベートのリラックスタイムに、気軽に視聴できて学びを得ていただける企画ですので、ぜひ今後のイベント開催も楽しみにしていただければと思います。

さて、記念すべき第1回のゲストスピーカーは、株式会社UPSIDERでVPoEを務める泉 雄介さんです。

泉さんは、2023年9月に開催したオンラインイベントにて、「エンジニア・デザイナー・PMの連携を強めるには？」をテーマにトークセッションをしてくださいました。

その際の視聴者アンケートにて、「メンバー間にコンフリクト（意見の衝突や争い）が発生してしまった時の対処法を教えてください」というご希望をいただいたことから、今回のSELECK miniLIVEにてさらに深掘りしてお話を伺わせていただくこととなりました！

本記事ではその対談内容をお届けしますので、ぜひご覧くださいませ。

▼ゲスト
株式会社UPSIDER / VPoE 泉 雄介さん

▼モデレーター
株式会社ゆめみ / Webメディア「SELECK」プロデューサー 工藤 元気

「100人の壁」を目前に、組織コミュニケーションを再設計するフェーズ

工藤　本日は第1回目の「SELECK miniLIVE」ということで、記念すべきゲストはUPSIDER社でVPoEを務める泉さんです！よろしくお願いします。

泉　よろしくお願いします。

工藤　泉さんとは、2023年9月に「エンジニア・デザイナー・PMの連携を強めるには？」というテーマで開催したSELECK LIVEにてご一緒させていただいて。VPoEを務める中でのお悩みや課題の解決方法を、赤裸々に語っていただきました。

そのイベント後の視聴者アンケートで、「メンバー間にコンフリクトが発生してしまった時の対処法を教えてください」というご希望をいただいたんです。このテーマについて、ぜひ泉さんにお話を伺わせていただければと思い、今回お声がけさせていただきました。

ちなみに前回のイベントでは、UPSIDERさんは全体で70人ほどの組織だと伺いましたが、今はどのくらいの規模になられていますか？

泉　採用活動を非常に活発にやっていて、順次メンバーが増えているので、当時よりもう少し増えていますね。

工藤　やはりどんどん組織が拡大しているフェーズということですね。前回のイベントでは「組織の人数が増えると異職種間の連携が重要になるので、しっかりとコミュニケーション設計をしないといけないよね」という会話がありました。

まさにUPSIDERさんは、いわゆる「100人の壁」を目前に控えているタイミングなのかなと思っていますが、最近の人数増加によって組織内で変化したことはありますか？

泉　ちょうど今、それについて経営陣で話しているところです。UPSIDERは事業のスタート時からリモートワークでやってきたという歴史があって、少ない人数であれば、能動的に働きかけなくても一定の意思疎通ができていたんですけど。

最近はメンバーも増えてきたので、全体でコミュニケーションを取ることへの動機付けを、意識的にやらないとキツいねという話が出ています。そこから「社内の全社会議をもう少し活発にやろう」といった、細かい動きについても話されているフェーズです。

工藤　その全社会議では、経営陣から社員全体に対する「1対n」のようなブロードキャストを行っている感じですか？

泉　基本的にはそうですね。今後は経営陣だけでなく、現場のメンバーからも話してもらうイメージで、もう少しインタラクティブな立て付けにしていきたいと思っていて。

現在も、トップダウンで一方通行の働きかけをするというよりは、現場の第一線で頑張っているメンバーたちからの熱いメッセージや思いを伝える場にもなってきていますね。

工藤　有機的に双方の思いが交差する場という感じがしますね。

ちなみに、昨年9月のイベント時には、泉さんご自身もVPoEでありながらプロトタイプを作られていると伺いましたが、現在はいかがですか。

泉　実は今の方が、当時よりもプログラミングを書いてますね。自分からあまり手を動かさないほうが良いと思いつつ、どうしても人手が足りないところは自分も手を動かして加勢しています。

工藤　そんなお忙しい中で、ご協力いただきありがとうございます！

それでは、VPoEという経営のパスも持ちながら現場にも立つという、泉さんの特徴を生かして、今回の本題の方に入っていければと思います。

コンフリクトを起こさないための予防法と、起きてしまった場合の対処法

工藤　あらためて、今回のテーマは「メンバー間にコンクリクトが起きてしまったときの対処法」ということで、時系列を分けて「コンフリクトを起こさないための予防法」と、「起きてしまった場合の対処法」について伺っていきましょう。

まず「コンフリクトを起こさないための予防法」に繋がる話として、前回のイベントでも、組織設計における異職種メンバーの連携強化や、経営とプロダクトがゴールに掲げているものとのアラインメントをしっかり取って動くことが重要だ、といったお話がありました。

泉　そうですね、予防法についてはコンフリクトの種類によっても違うかもしれません。

例えばエンジニア間で言えば、同じ開発チームのAさんとBさんの技術選定や実装方針に関する意見が異なっていて、コンフリクトが生じてしまうとか。あとは、マネージャーとメンバー間で評価に対する捉え方が異なることから生じるケースもあると思います。

そのように種類は色々あるものの、一般的にコンフリクトとは「お互いが思っていたことや、お互いの持っているルール・約束事の前提が合わなかった」という要因が多いのではと感じています。

工藤　その「前提」については、それぞれが無意識で持っているケースもあるので、ネゴシアブルにしておくことが大事だよねともおっしゃっていましたね。

泉　はい、それが大事ですよね。

工藤　その一方で、会社やチームにはある程度のルールや決め事が存在しているので、個々人でネゴシアブルにすることが難しいシーンもあると思いますが、その辺りのくぐり抜け方はあるんでしょうか。

泉　そうですね。今回の「メンバー間にコンクリクトが起きてしまったときの対処法」というテーマを見た時に、「答えは1個しかない気がする」とパッと思ったんです。

起きている事象のコンテキストによって違うかもしれないですが、メンバー間でのコンフリクトに閉じて言うと、「最後に誰が決める？誰が責任を取る？」という話だと思っていて。

UPSIDER社内で言えば、より良い品質のプロダクトを出すというゴールは変わらないし、そこに対してロジカルに考えることがみんなできるとは思うんですが、時には実装方針の違いのようなものが出てくると。ただ、その一部は「第三者による一意見」である可能性もあります。

なので、周囲から異なる意見が出た時には、その意見にも真摯に耳を傾けつつ、最後は責任者が自分の意思で決めないといけないと思います。

結論として、コンフリクトを起こさないための予防法としては、役割や責務をきちんと明確にしておくことに尽きると思います。

例えば、自分がアーキテクチャに関する最終責任を持っていたら、色々な人の意見ももちろん聞いた上で、最良の選択と意思決定は自分ですることになると思うんですね。

特に、アーキテクチャはわりと話題に出やすくて、かつ、みんなも意見しやすい領域だと思っていて。少し前に細谷さんと坂田さんが出されている「構想力が劇的に高まる アーキテクト思考」という著書を読んだのですが、そこに「アーキテクトは1人であるべきだ」って書いてあったんです。

これは、本当にその通りだなと思っています。色々なことを試す中でいくつかのオプションが出てくるので、情報収集のために違う視点を持ってる人たちの意見を聞くことはすごく大事で、それ自体は全然否定する必要はないと思います。

でも、多くの日本人はバシッと意思決定することよりも、みんなで協議してふわっとソフトランディングさせたいという思考を持っているなと感じていて。

それは少なくともアーキテクチャの世界ではやらない方が良いと思います。やっぱり思想がバラバラになって、一貫性に課題が生じてしまうので。

工藤　そこは主体者である人が決めるべきということですね。コンフリクトって非対称なものがぶつかる状態を指しますが、そもそもそこを1つにすれば、コンフリクトにはならないだろうっていう…。

泉　そうですね。あくまでも、意見を言う権利は他の人にもあると思うので、それは全然良くて。「確かにスケーラビリティを考えると、ここにボトルネックがあるから変更すべきだよね」といった新しい視点をもらえたら、ロジカルに考えて取捨選択すべきだなと思っています。

工藤　意思決定する人が色々な意見を収集した上で、その人の裁量の中で決めるという役割設計を、組織として行っておくと良いのではということですね。

泉　そうです。最後、誰が責任取るんだというところは、初めから決めておいた方が良いと思います。

コンフリクトが起きた後も同じだと思っていて、 誰が責任を取るのかが決まっていないということが、原因の8割なんじゃないかと。

工藤　確かにそうかもしれないですね。最終責任を持って意思決定する人が誰か決まっていれば、必然的に情報がそこに集まるわけで。

泉　そうでないとお互いに非効率ですよね。

工藤　組織が大きくなったり決め事が多くなってくると、 その最終責任者自身の裁量もどんどん広げていかないといけないので、聞く技術や情報を集める技術が必要になってくるのかなと思いました。

泉　そうだと思います。過去の失敗体験として、会社が最終責任者を任命したとしても、周りの人が実はそれを認識してなかったというケースがあります。なので、責任者は誰かを決めるだけじゃなくて、どのようにプロセスの中に入れるかも明確になっていないと、うまく機能しないなと思います。

工藤　なるほど。例えば、技術選定や技術転換の際のコンフリクトをそれで解消したとして。その後に入社して経緯を見ていない人たちは、「何でこうなっているんだっけ？」と腹落ちしないまま進む可能性があるのかなと思います。

そのようにコンフリクトの元になる潜在的なモヤモヤって、おそらく多くの組織内に渦巻いているのかなと思っていて。それを解消・予防するという観点だといかがでしょうか。例えばドキュメントに残すといった意識はされていますか？

泉　全ての意思決定の経緯を細かく追えるようにするべきかと考えると、それも非効率な感じがするんです。工藤さんがおっしゃる通り、すでに解決した課題をまたはじめから議論をするのはめちゃくちゃ無駄なことなので、ドキュメントに残すことはもちろん大切だと思います。

とはいえ、ドキュメントが用意してあるからみんながそれに目を通すかと言ったら、そんなことはないという気がしていて。

結論、現状に対して「なんでこうなったの」と追求する時間はもったいないので、過去に費やす時間はせいぜい2割にして、残りの8割は将来どうしていくかを明確にする方に時間を使った方が良いんじゃないかなと思っています。

工藤　今日も名言をいただきましたね！「過去は2割にとどめて、8割は将来を明確にすることに使う」という泉さんのお考えについて、今まさにコンフリクトを経験している方々にも意識していただきたいです。

それによって「あ、私たちは今未来に目を向けないといけないよね」と双方で価値観を共有できるのは、すごく大事だと思いましたね。

泉　そうですね。日本人って反省会とか振り返りが好きな人が多い気がしませんか？過去の議題に時間を使ってミーティングが終わっちゃうようなケースが結構多いなと思っていて。

工藤　確かに、それはあるかもしれないですね。

泉　もちろん振り返りが大事な場面もあると思います。でも、例えばインシデントの対応なんかが顕著な例で、基本的には過去のことより未来に目を向けるしかないじゃないですか。

工藤　そうですよね。今後の対応や次の予防策を考えるべき時なのに、いわゆる障害報告書や形式的なものに囚われてしまったり。

泉　そうそう、「囚われすぎちゃう」っていう。そういう傾向があるなと感じます。

工藤　メタ的な話ですが、それぞれの個人の心の中で、過去のしがらみと「これからこうあるべきなのでは」という仮説がぶつかって、コンクリクトが起きてしまっているケースもあるんじゃないかなと感じました。それが日本人カルチャーかどうかは一旦置いておいて。

泉　そうですね、それはもう常にある課題ですよね。

開発における「単一責任の原則」の考え方を、組織づくりにも活かす

工藤　少し話題を変えまして、先ほど例として「同じチームのエンジニアAとBの実装方針が違う」というケースと、「マネージャーとメンバー間の評価の捉え方が違う」というケースを出していただきました。

このように上司と部下の関係性がある時は、基本的にはマネージャーがグランドルールを理解していて、会社が定めたルールに沿って動くと思います。その場合、おそらく責任の所在のパワーバランスもマネージャー側に傾くのかなと思っていて。

コンフリクトが生じた際にマネージャー（上司）が強者になってしまいがちな組織構造の中で、マネージャーからメンバーに対する配慮や、気をつけたいなと思うことはありますか？

泉　開発組織のマネージャーは優しい方がすごく多いので、むしろ僕は逆のケースの方が起こりやすいのではと感じています。

本来は、マネージャーが持っている権利を使うことも大事じゃないですか。でも、例えばマネージャーのポジションにいるのに物事を決めるのをためらってしまったり、なあなあな感じで収めちゃったりとか。

なので、マネージャーからメンバーに対して配慮するというよりは、逆にマネージャーの権利を使いきっていないことに対してフィードバックすることが、本人のためにもなるし、会社のためにもなると考えていて。もちろん人によりけりですが、そういう方もいるなと思っています。

あと、アーキテクチャを考える上で重要な「シングル・レスポンシビリティ・プリンシパル（単一責任の原則）」が、開発だけでなく組織にも当てはまると思っていて。

「コンポーネントが保持する責務は1つであるべきだ」という考え方を組織に当てはめると、マネージャーは1人で全ての責務を負ったらすぐにパンパンになるので、メンバーに助けてもらう立場だと思うんですよね。その際に、メンバーに対して責務や役割とゴールを明確にしておくことは、その後にコンフリクトを起こさない予防法にもなると思います。

実際、開発の現場においても、その確認にものすごく時間を使っていると思うので。プロダクトのユーザーが欲しいものは何で、最終的に誰の何を解決するのかをしっかりと双方で認識した上で開発しないと、後で手戻りが発生したり、無駄な時間を過ごすことになったりしちゃうじゃないですか。

だから、初期の段階で、後々課題になり得る種を潰しておいてから実装に入った方が、無駄が少なくて済むと思うんですよね。

工藤　私自身の体験としても、最初の段階で期待を明確に伝えていかなかったがゆえに、期待に対してギャップがあるのかどうかの判断が揺らぎ、フィードバックがしにくくなるのだと感じました。

先ほどのオブジェクト指向での「単一責任の原則」を組織にも反映するというのは、コンウェイの法則的な発想ですごく印象的でした。

泉　そこのストラクチャーがしっかりしていないと、後々人間的な問題が起きやすいというのは、多分あると思いますね。

工藤　ここまでお話しいただいたことをまとめると、まずはメンバーへの期待やジョブディスクリプションをしっかりと項目ごとにインプットしてあげた上で、それをお互いにフィードバックし合える関係性を作ることが重要。

そして、さらに上のマネージメントラインでは、メンバーの意見を柔軟に聞きながらも、最終的には意思決定者が決めるのだということを明確にしておくというイメージですね。

泉　そうですね。それを大々的に言うというよりは、少なくともマネージャーの頭の中ではきちんと構造化されているべきだと思うし、場合によってはそれをメンバーに対して明確に伝えることで、メンバーが迷わなくて済むということもあると思います。

工藤　泉さんのお話からは、メンバーへの優しさや、以前お話しいただいた相手の問題を自分のことのように捉える「マイルドな自責」というスタンスが伝わってきますね。

総論として、かっちりした土台作りと、「寄り添う余白」みたいな人間らしいゆとりの両立が大事なのかなと感じました。

クリエイティブな作業や、共同作業にはオフラインを活用

工藤　今もUPSIDERさんはリモートワーク中心だと思いますが、意見の対立やモヤモヤが起きる背景にも、オンラインがゆえのコミュニケーション不足はあるのかなと思っていて。

人数が増えてきたことで新たに見えてきた課題があったら、最後にシェアしていただきたいなと思っております。

泉　もちろん物理的に集まることがあまり無いため、全社との接続を感じる機会が少ないと感じるなどの課題はあると思います。

一方で日々の業務に目を向けると、開発のユニットは大体5〜6人単位でやり取りしているので、組織全体の人数が増えても、コミュニケーション自体はそんなに変わっていないかなと思っています。

ここ3、4年で、オフラインとオンラインの意識的な使い分けが染みついてきていると思いますが、やっぱりクリエイティブな作業だったり、共同や集合知を指すコレクティブな作業については、オフラインが適しているなとは思いますね。

例えば、先日コーポレートIT（情シス）のメンバー数人と議論したんですが、その時は完全にディスカバリーのプロセスで、探索的に話さないといけない内容だったので、オンラインだとすごく限界があるなと感じました。こういう時はオフラインに切り替えて、パッと集まって議論した方が効率的ですよね。

工藤　組織の規模が大きくなっても個々のチーム単位の人数はあまり変わらないから、オフラインとオンラインの役目と価値を見定めて選択していけば、新たなコミュニケーションの問題は発生しないということですね。

…さて、第1回のSELECK mimiLIVEをお送りしてきましたが、あっという間にお時間となりました。30分という短い時間の中で、めちゃくちゃ学びが詰まっていましたね。

今回のゲストは、UPSIDER社VPoEの泉さんでした。本当にありがとうございました！

泉　ありがとうございます！

おわりに

いかがでしたでしょうか。今回は「メンバー間にコンフリクトが起きてしまったときの対処法」をテーマに、VPoEを担う泉さんのお考えについて詳しくお話しいただきました。皆さまの組織づくりのヒントになれば幸いです。

今後も、現場で役立つナレッジをお伝えするイベント「SELECK miniLIVE」を、定期的に実施していきますので、ぜひご視聴くださいませ。（了）

▼今回のイベント音声録音と、過去にUPSIDER社に取材した記事も、ぜひ一緒にお楽しみください

• 当日のイベント音声はこちら
• 累計200億超の資金調達も達成！急成長中の「UPSIDER」プロダクト誕生＆開発の裏側