クロスファンクショナルチームでデザイン思考を回す——部門横断プロジェクトの実践ガイド

部門横断チームを立ち上げたのに、結局いつも同じ顔ぶれが話している——よくある光景だ。プロジェクトルームには営業、エンジニア、マーケター、UXデザイナーが揃っている。ところが発言するのはマーケターとエンジニアだけ。営業は「現場では無理です」と繰り返す。デザイナーは黙ってスケッチを描いている。会議が終わると、誰も何も決まっていないことに気づく。

多様な部門が集まること自体は、クロスファンクショナルチームの「必要条件」にすぎない。問題を共に定義し、アイデアを接続し、意思決定を共有する構造が整って初めて、部門横断の恩恵が現れる。デザイン思考はその構造を提供するフレームワークだが、通常のプロセスをそのまま適用しても機能しないことが多い。チームの構成が均質なときに設計されたプロセスを、利害と言語の異なる部門混成チームに当てはめても、摩擦が増えるだけだからだ。

この記事では、クロスファンクショナルチームに特有の課題を整理し、デザイン思考の各フェーズをどう適応させるかを具体的に示す。

なぜクロスファンクショナルチームでデザイン思考が機能しにくいのか

「問題」の定義が部門ごとに違う

営業にとっての問題は「提案が通らない」だ。エンジニアにとっては「仕様が曖昧すぎて実装できない」になる。マーケターは「認知はあるのにコンバージョンが低い」と言う。全員が同じプロジェクトを担当しながら、異なる問題を持ち込んでいる。

デザイン思考の共感フェーズは、ユーザーの問題を探索するフェーズとして設計されている。しかし実際には、チームメンバー自身が抱える問題の定義を統一するステップが先に必要だ。この前工程を飛ばすと、インタビューで集めた情報の解釈が部門ごとにバラバラになる。

専門言語の壁が思考の接続を阻む

エンジニアが「スケーラビリティの問題がある」と言っても、営業にはイメージが湧かない。営業が「顧客のペインポイントを押さえたい」と言っても、エンジニアには設計上の制約との接続が見えない。言語の壁は単なるコミュニケーション問題ではなく、思考の接続を阻む構造的な問題だ。

ワークショップで「自由にアイデアを出してください」と言われても、専門語彙の壁がある状態では、誰かの発言が他の誰かには理解できないまま通り過ぎていく。ブレインストーミングの形式だけが整っていて、実質的な交差が起きない。

責任と評価の構造がコラボレーションを阻む

部門横断チームのメンバーは、プロジェクトの成果よりも自部門の成果指標で評価されることが多い。営業は受注数、マーケターはリード獲得数、エンジニアは機能リリース速度。この評価構造のまま協働を求めると、メンバーは「プロジェクトの成功」よりも「自部門への影響の最小化」を優先し始める。「それは自部門の管轄外」という言葉が増え、難解な問題（Wicked Problems）ほど誰も前に出なくなる。

キックオフで何を決めるか——共通地図の作成

クロスファンクショナルチームのデザイン思考プロジェクトは、キックオフに時間をかけることが最初の投資だ。ここで決めるべきことは3つある。

1. 探索する問いの合意 「何を解決するのか」ではなく「何を探索するのか」として問いを立てる。解決策の方向性を最初に決めると、各部門が「自分たちの解決策」を守り始める。「なぜ顧客は____なのか」「どうすれば____が変わるのか」という探索型の問いにしておくことで、全員がインプット側に立てる。

2. 各自が持つ「見えていること」の棚卸し 営業は顧客との接点から得た生情報を持っている。エンジニアは技術的制約と可能性を知っている。マーケターは市場データを持っている。これらをセッションの最初に出し合い、全員が「他部門が見ている世界」を知ることが、共通地図の起点になる。

3. このプロセスでの役割の定義 部門での役割ではなく、「このプロジェクトでの役割」を決める。ファシリテーター、記録者、ユーザーインタビュアー、プロトタイプ作成者。これらの役割は部門を横断して割り当てる。営業がプロトタイプを作り、エンジニアがユーザーインタビューを担当することで、普段と異なる視点が入る。

共感フェーズの部門横断対応——誰がユーザーを知っているか

共感フェーズで最もよくある間違いは、「ユーザーリサーチはUXチームがやるもの」という分業だ。部門横断チームにおける多様性の活用という観点からすると、各部門が異なる接点でユーザーと接触しており、それぞれが異なる「真実の断片」を持っている。

Airbnbがサービス初期に成長の停滞を経験したとき、創業者のブライアン・チェスキーとジョー・ゲビアが自らニューヨークに飛んで全ホストを訪問したことはよく知られている。しかしこの行動のポイントは「創業者がリサーチした」ではなく、「ビジネス側・製品側の人間が直接ユーザーと会った」という点にある。得た情報は、エンジニアチームが「機能追加で解決できる」と考えていた問題が、実は「写真の品質」というアナログな要因にあることを示した。これは担当部門を超えた情報収集なしには発見できなかった洞察だ。

部門横断インタビューチームの作り方： インタビューは必ず2名1組、異なる部門から選ぶ。一人が質問し、もう一人が観察と記録を担当する。観察者は「自分の部門のフィルターで何が気になったか」をメモする。インタビュー後に2名が感じたことを突き合わせると、同じユーザー発言が「受注障壁」と「機能要件」の両面から解釈されることに気づく。これが部門間の言語の翻訳起点になる。

問題定義フェーズ——「誰の問題か」を外に向ける

クロスファンクショナルチームが問題定義でつまずく場所は決まっている。ユーザーインサイトを議論しているはずが、いつの間にか「自部門の課題」の話になっていることだ。

IBMがデザイン思考を全社に導入した際（2013年以降の「IBM Design Thinking」イニシアチブ）、最も時間をかけたのが「Hill（ヒル）」と呼ばれる問題定義フォーマットの徹底だった。HillはPOVステートメントの変形で、「誰（Who）が、何（What）を、驚きの方法（Wow）で」という3要素で構成される。このフォーマットを使う理由は明確で、主語を必ずユーザーに固定することで、部門利益の話が入り込む余地を構造的に排除するためだ。

実際のワークショップでは、チームが作ったHillを壁に貼り、全員が「このHillの主語は誰か」「ユーザーの話をしているか、自部門の話をしているか」を互いにレビューするセッションを入れる。他部門の視点から見ると、自部門フィルターのかかった問題定義が一目でわかる。

アイデア発想フェーズ——専門性を「材料」にする

アイデア発想フェーズでクロスファンクショナルチームが強みを発揮できる瞬間は、異なる専門性が「接続される」ときだ。ただし、放置すると専門性は「制約の主張」として現れる。「技術的に無理」「予算が取れない」「現場では回らない」——これらはすべて正当な情報だが、アイデアが出た直後に言うと発散が止まる。

「制約を後工程に移動させる」ルール アイデア発散中は、制約の指摘を付箋に書いて「制約ボード」に貼る。「それは無理」と言う代わりに「それには制約があります」と書いてボードに追加する。発散フェーズが終わった後、制約ボードを見ながらアイデアを評価する。こうすることで、制約情報はアイデアを殺す武器ではなく、評価と改善の材料になる。

また、リモートワークショップ環境でクロスファンクショナルチームを動かす場合は、専門部門ごとの「サイロ発想」を防ぐために、デジタルホワイトボードのグループ分けを部門ではなくランダムまたはクロスで組む必要がある。同じ部門だけがくっついて議論する状態では、部門横断の意味がない。

Spotifyが「スクワッド」と呼ばれるクロスファンクショナルチームを導入した際、アイデア発想において特に効果が出たのは「ギルド」との組み合わせだった。スクワッドは部門横断の小チームで、ギルドは同じ専門性（エンジニア、デザイナー等）を持つ人々が組織横断でつながるコミュニティだ。アイデアをスクワッド内で発散させ、ギルドで専門的な実現可能性を磨く。この二層構造によって、「部門横断の発想」と「専門的な深掘り」の両方が維持された。

ファシリテーターの役割——翻訳者として立つ

クロスファンクショナルチームのデザイン思考を成立させる鍵の一つが、ファシリテーターの質だ。ファシリテーター育成の観点から言えば、部門横断セッションのファシリテーターには通常のスキルに加えて「翻訳力」が必要になる。

翻訳力とは、ある部門の専門用語を他部門の文脈に置き換えて理解を橋渡しする能力だ。エンジニアが「APIのレイテンシ問題がある」と言ったとき、ファシリテーターが「それはユーザーが待たされるということですか、どのタイミングで」と問い直すことで、営業とマーケターも会話に入れる状態を作る。逆に営業が「クロージングで詰め切れない」と言ったとき、「それは情報が足りないから？それとも信頼感が足りないから？」と問い直すことで、UXデザイナーがタッチポイントの課題として捉えられるようになる。

ワークショップでのコンフリクト管理も、クロスファンクショナルセッションでは頻繁に起きる。部門間の利益対立がそのまま発言対立になることがある。このとき有効なのは「立場ではなく観察に帰る」介入だ。「今、2つの立場が出ています。どちらもユーザーから見ると正しい可能性があります。どちらの立場が正しいかではなく、ユーザーに何が起きているかを確認しましょう」と場をリセットする。

組織への定着——一度きりで終わらせない

クロスファンクショナルチームによるデザイン思考プロジェクトが一度成功しても、次のプロジェクトで同じことが再現できなければ、組織的な能力にはならない。組織へのデザイン思考定着という観点から、継続のために整えるべき構造を3つ挙げる。

1. 共通語彙の整備 プロジェクトを通じて発見した「部門間の翻訳パターン」を記録する。営業の「顧客が動かない理由」がUX的には「認知コストの高さ」として定義できる、といったマッピングだ。これを組織の共通辞書として蓄積することで、次のチームが同じ摩擦から始めずに済む。

2. 「越境レビュー」の仕組み化 月1回、各部門のプロジェクト状況を他部門に5分で共有するセッションを設ける。共有の目的は承認ではなく「他部門から見えること」のフィードバックだ。これを継続すると、部門間の「相手が何をやっているかわからない」という断絶が徐々に解消される。

3. リーダーシップ層の関与形式の設計 リーダーシップのデザイン思考への関与は、プロセスへの介入ではなく「問いの設定」と「障壁の除去」が適切な形だ。マネジメントがプロセス途中でソリューションを指定し始めると、クロスファンクショナルチームの自律性が失われる。リーダーの役割は「このプロジェクトで何を学びたいか」を定義し、学習の障壁（予算、権限の壁など）を取り除くことに絞る。

クロスファンクショナルチームは、構造なしに動かすと均質なチームより機能しないことがある。異なる部門から来た人々が同じ部屋にいることが、そのままコラボレーションを意味しない。しかし構造を整えたとき、均質なチームでは決して出てこない洞察が生まれる。一人では見えない角度から問題が照らされ、制約だと思っていたものが別部門にとっては当然のリソースだったことに気づく。

多様性は目的ではなく、手段だ。そしてデザイン思考は、その多様性を機能させるための構造を提供する。

---

参考文献

1. IDEO. (2015). The Field Guide to Human-Centered Design. IDEO.org. https://www.designkit.org/resources/1

2. IBM Design. (2018). IBM Design Thinking Field Guide. IBM Corporation. https://www.ibm.com/design/thinking/

3. Gothelf, J., & Seiden, J. (2021). Lean UX: Designing Great Products with Agile Teams (3rd ed.). O’Reilly Media.

4. Graham, P. (2013). “Do Things That Don’t Scale.” paulgraham.com. https://www.paulgraham.com/ds.html (Airbnb初期の顧客接触戦略に関する論考を含む)

5. Kniberg, H., & Ivarsson, A. (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds. Crisp AB. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf