要約: DesignOpsチームの構造は、チーム固有の課題とニーズから導き出す必要があります。これらのタイプのチーム構造は、DesignOpsチームをサポートし、可能にすることができるさまざまなアプローチを示しています。
DesignOpsは、一貫した高品質のデザインを実現するために多くの要素が存在するため、大きな可能性を秘めています。組織がDesignOpsの実践で重視するのは、その組織のニーズと目標であり、DesignOpsチームや役割に関しても、その実践の構造を反映したものであるべきです。
この記事では、DesignOpsチームの一般的な5種類の構造について概説します。企業にとって適切な構造は、全体的な組織構造、目標、および正式なDesignOpsプログラムの必要性のレベルによって異なるため、最高クラスの構造は存在しません。これらの構造は、さまざまなコンテキストに適した潜在的なモデルであり、DesignOpsの成熟度モデルにおける必須または漸進的なステップと見なすべきものではありません。組織によっては、規模が拡大するにつれてこれらの構造を通じて自然な進行が見られるかもしれませんが、チームは適切なサポートとリソースを提供する構造以外を目指す必要はありません。
この記事で概説するDesignOps構造の一般的な5つのタイプは次のとおりです。
- 散在型：DesignOpsの取り組みは、他の役割（例えば、デザインマネージャー）が日々の職務の一部として担っている。組織内では、「DesignOps」は用語として使われておらず、正式な概念としても知られていないようです。
- 孤立型：このDesignOpsの専任担当者は、デザインチームの最大のペインポイントを特定し、プログラムを開発します（多くの場合、最初は消極的な方法で）。
- 特化型：DesignOpsは、DesignOpsの特定の側面をフルタイムで管理または監督する数人に分割されています。
- 散在型：DesignOpsの役割が組織内の各チームに分散・専任され、チーム間の調整と連携に重点を置いています。
- 高揚型：DesignOpsの規模を拡大して独立した組織とし、設計組織全体に影響と利益をもたらす集中的なリソースとプログラムを提供します。
タイプ1：散在型
DesignOpsが分散している場合、DesignOps関連の活動をしている人はたくさんいますが、公式な実践や肩書きがありません。多くの組織では、誰も「DesignOps」という言葉を聞いたこともなければ、それが何を表しているのかを理解していないかもしれません。確かに「DesignOps」という言葉はすべての組織で日常的に使われている言葉ではありませんし、ほとんどの組織には正式なDesignOpsの役割（つまり、DesignOpsにフルタイムで従事する人）がありません。(実際、私たちの調査によると、DesignOpsのリードやマネージャーを持つチームはわずか13%でした)。
しかし、正式なDesignOpsの実践と役割がない組織でも、設計チームとそのプロセスに関連する運用上の課題を特定し、解決しようとしている人たちがいます。おそらく、そのようなラベルを貼らなくても、シニアレベルのデザイナー、リード、およびマネージャーが、正式に認められた他の職務と並行してDesignOpsタイプの仕事をしているのでしょう。
このような分散的な構造が蔓延しているのは、組織全体のDesignOpsの成熟度が低いためと思われます。557人のUXプロフェッショナルを対象に、組織におけるDesignOpsの成熟度について調査したところ、「チーム全体でDesignOpsを広く理解している」「企業文化の中でDesignOpsの価値が確立されている」と回答した人はわずか10％でした。
散在型構造における実践
正式なDesignOpsが存在しないということは、全体的なUXの成熟度の低さを示している可能性があります。確かに、UXの価値を認めず、UXの実践全体をサポートしていない企業は、正式なDesignOpsの実践をサポートしたり、DesignOpsの専門家を雇用したりすることもないでしょう。そのような場合、デザインリードやマネージャーは、業務上の課題を解決してデザイン作業を可能にするための時間とリソースを確保するために奔走することになり、これらの努力に対する評価もないまま、さらなる負担を背負うことになります。
また、DesignOpsが理解され評価されている組織では、散漫なDesignOpsの構造になっている可能性もあります。DesignOpsのジャーニー、あるいはUXの旅全体の初期にあるチームには、たとえそのような役割が広く望まれていたとしても、DesignOps専門の役割を担うリソースがまだない可能性があります。このような状況では、チームは、既存のデザインの役割の職務内容や責任の中に、Ops関連の責任を含めること、そしてできれば正式に認識することを決定することができます。たとえば、デザインマネージャーには、チームのメソッドプロトコルを作成するための権限とリソースが与えられるかもしれません。あるいは、代表的なデザイナーからなる委員会が、デザインシステムの構築、デザインプロセスの文書化、UXミーティングの体系化など、DesignOpsに関する特定の課題を引き受けるかもしれません。
散在型構造の課題とメリット
統一されたDesignOps構造を持たない個々のチームには、ツールや手法を自律的に選択できるという利点がありますが、分散した構造における最大の問題は、一貫性の欠如であることが多いのです。個々のチームが連携していない場合、プロセス、手法、およびツールスタックに大きなばらつきが生じ、コラボレーション、洞察やテンプレートの共有、または重複作業の回避が困難になることがあります。
タイプ2：孤立型
孤立型構造では、一人の人間がDesignOpsにフルタイムで献身することを公式に認められ、裁量を与えられています。この担当者は、DesignOpsリード、DesignOpsマネージャー、DesignOpsヘッドなどの自由な肩書きを持ち、未知の領域に道を切り開き、DesignOpsのフロンティアにチームを導く、DesignOpsの槍の先端となる役割を担っていることが多くあります。
このDesignOpsチームは通常、必要なダメージコントロール、運用負債のバックログを理解すること、最も明白なペインポイントに1つずつ取り組むことに重点を置いています。この役割は、複数の設計者や設計チームにまたがって働き、運用上の最大の課題を特定し、すべてのチームに利益をもたらす一貫性と標準を開発することです。
デザインチームのリエゾンとしてチーム全体の課題に耳を傾け、それらを統合する役割と、デザイナーとして、それらのペインポイントを緩和し、デザイナーをよりよく働かせるためのアプローチやプロセスを構築する役割の2つに分かれることがよくあります。
孤立型構造における実践
孤立型構造は、時系列的に散在の構造に続くことが多くあります。なぜなら、散らばった組織の中で、誰かが個々のデザイナーやチーム間の矛盾や非効率性を認識し、もはやそれを我慢できなくなり、問題解決のために叫び声を上げるからです。
歴史的に小さなチーム（10人未満のデザイナー）が急速に2倍、3倍の規模に拡大した場合、既存のデザイナーは、成長するチーム全体でプロセスやコラボレーションを維持することが難しくなっていることを認識することがあります。このような場合、既存のデザイナーは、成長するチーム全体でプロセスやコラボレーションを維持することが困難になっていることを認識します。このデザイナーは、ペインポイントを直接感じ、これらの運用上の問題を引き受けるようリーダーシップに訴え、初めて正式なDesignOps担当が誕生しました。
あるいは、複数のチームが比較的高いレベルのUX成熟度を持ち、全体的に連携がとれている場合、リーダーシップは正式なDesignOpsの必要性を積極的に認識し、経験豊富なDesignOpsの専門家を迎え入れ、組織内でDesignOpsを「立ち上げる」ことができるかもしれません。
孤立型構造がもたらす課題とメリット
孤立型構造では、DesignOpsは公式に認められています。設計プロセスを最適化し、少なくとも1人がこの仕事をフルタイムで担当できるようにすることについて、少なくともある程度の正式な承認と賛同が得られているのです。しかし、この担当者は、解決すべき運用上の課題の多さと、そのために必要な多くの活動（障害の特定、ロードマップ作成活動、取り組みの追跡、フィードバックの収集、取り組みの進化など）にすぐに圧倒されてしまうことがあります。この負担は、既存の設計者がフルタイムで専念することを認められる前に、いくつかのDesignOpsイニシアチブの成功を証明しなければならない場合、さらに深刻になります。
さらに、この駆け出しの役割は、不安定な立場にあります。彼らは、利害関係者と、変化を受け入れない可能性のある個々のデザイナーの両方に対して、DesignOpsをたゆまず提唱するという知られざる責任を果たすため、抵抗勢力に直面する可能性があるのです。なぜなら、サイロの中でプロセスを設計し、押し付けようとする孤独な構造のDesignOpsプロフェッショナルは、サポートしようとする設計者のシステムから拒絶されるからです。
タイプ3：特化型
Specialized DesignOps構造では、複数の（ただし限定された）DesignOps専用の役割があり、それぞれが特定のプログラムまたはDesignOpsの専門領域に焦点を当てています。孤独な構造のように、あらゆる種類のDesignOpsの課題の特定と解決に専念する単一のDesignOpsジェネラリストを持つのではなく、DesignOpsの専門家は専門化されており、それぞれがDesignOpsランドスケープの何らかの側面に対応する特定の独自のフォーカスエリアを持つことを意味します。
この構造における個々のDesignOps専門家は、各自の専門分野とスキルセットに沿った運用上の課題とソリューションに注力しますが、互いに緊密に連携し、デザイナーをサポートするために導入された運用プログラムが補完的かつ協調的になるように協力し合います。
この構造におけるDesignOpsの役割は、専門的なニーズがある分野が明らかになった後に作られ、多くの場合、孤立型構造における個人の過剰な負担を軽減し、各人が最も意欲的で最も知識のある分野に集中することができるようにします。
特化型構造における実践
DesignOpsが浸透し、時間をかけて測定可能な成功を証明するにつれ、単一の役割では手に負えなくなることがあります。たとえ一人の超人がDesignOpsの複数の分野を長期的に専門的に管理できたとしても、取り組むべきDesignOpsの潜在的な分野すべてに興味があるわけでも、得意なわけでもないでしょう。
1人のDesignOpsチームが最初のDesignOpsの取り組みの成功をベンチマークして測定することに成功した場合、DesignOpsの役割を追加することへの賛同が得られることがよくあります。この場合、DesignOpsチームは、最も効果的であることが証明されている特定のプログラムやDesignOpsの専門的な側面に焦点を当てることができる専任の役割を追加することによって拡張されます（最初はもう1人か2人程度）。
たとえば、小規模で新興の専門組織では、3人のDesignOpsプロフェッショナルを置くことができます。1人は採用やオンボーディングなどのPeopleOpsイニシアチブに焦点を当て、1人はデザインワークフローの最適化に焦点を当て、1人はツールのキュレーション、ライセンス、ツールのオンボーディングに焦点を当てることができます。
特化型構造の課題と利点
特化型構造では、個々のDesignOps専門家が特定のワークストリームに集中することができ、デザイン組織の長期的な成功に不可欠と特定された分野に専念することができます。しかし、これらの役割の間に強力な連携がなければ、DesignOpsは断片的になってしまいます。
さらに、この成長するDesignOpsチームは、その役割を周囲に理解してもらう責任を怠ってはなりません。他の役割と比較して、DesignOpsが提供する差別化された価値について明確に説明する必要があります。また、組織内の他のオペレーションの役割（PeopleOps、MarketingOps、DevOps、BusinessOpsなど）とのパートナーシップを構築し、全員がその取り組み、目標、およびコミュニケーションに同期していることを確認するために時間と労力を割く必要があります。
タイプ4：分散型
分散型構造では、DesignOpsの専門家が組織内の個々の設計チームに献身的なサポートを提供します。これらのDesignOpsの役割は、サポートする個々のチームの一部であり、ワークフロー管理、設計目標の設定、プロジェクトの軌道の監視、ロードマップ作成などの領域を通じてチームを支援することができます。
理想的には、これらのDesignOpsの役割が連携して、これらすべてのチーム間で全体的な戦略とコミュニケーションが同期していることを確認することができます。分散したチーム構造と同様に、分散したチームメンバーが互いに共有しコラボレーションするための専用の時間を提供するタッチポイント（例：ミーティング）を確立する必要があります。
分散型構造における実践
この構造は、高度なスケーリングが行われている設計チームや、チームが広範囲に分散している場合によく見られます。デザインチームの規模が大きくなると、1人（または限られた人数）のDesignOpsの役割だけでは、変化するニーズや課題に対応することが困難になります。デザイン組織の健全性をよりよく監視し、最適化するために、DesignOpsはより多くの「現場での足」を必要とする場合があります。この場合、専任のデザインプロデューサーやデザインプログラムマネージャーが、日々のデザインプロセスの推進と障害の除去を支援します。
一般的にDesignOpsの専任者はよりジェネラリスト的な役割を担いますが、必ずしもそうとは限りません。たとえば、急成長しているチームでは、採用やオンボーディングに特化したDesignOps専任のロールを採用することがあります。
分散型構造の課題と利点
このアプローチは、どのチームもDesignOpsのサポートを受けるか受けないかを選択できるため、チームのニーズがまちまちであったり、DesignOpsに対する受け入れレベルが異なる組織でも、柔軟に対応することができます。したがって、準備が整っていないチームや、そのような役割の必要性をまだ認識していないチームに、DesignOpsを「強制」することはありません。
さらに、DesignOpsの専任サポートがあれば、個々のチームのニーズやフィードバックがより理解され、考慮される可能性が高くなります。分散したチームは、DesignOpsの役割が整合性を生み出すための健全な構造を備えていれば、知識を共有し、一貫したプロセスを持つことができる可能性が高くなります。
しかし、専任のDesignOps担当者がどこに焦点を当てるべきかを判断するのは難しい場合があります。個々のチームプロジェクトのサポートに力を入れるべきか、それともグローバルなUXプログラムとプロセスの最適化に力を入れるべきか。この時点で、全体的な戦略とアプローチを推進し、この広範なチームを調整する強力なDesignOpsのリーダーシップが必要です。
タイプ5：高揚型
高揚型構造では、DesignOpsはそれ自体が組織であり、設計組織全体をサポートするハイレベルなツールやプログラムの作成に重点を置いています。
ここでは、DesignOpsと設計は別のチームですが、互いに連携しサポートする構造と目標を持っています。この構造は、チーム間のアライメントが最適化され安定したときに発生し、一部のDesignOpsの役割が解放され、より戦略的な役割を果たすようになります。このアプローチにおけるDesignOpsの役割は、グローバルなイニシアティブに焦点を当て、設計チームとそのプロセスを積極的に支援する設計全体のリソースを作成する傾向があり、日々の設計活動やプロジェクトのタイムラインからはより離れています。
この構造では、DesignOpsは、組織内の他の部門のリーダーシップの役割と並行して、強力なリーダーシップの層を必要とします。DesignOpsは戦略的な会話の一部であり、クラス最高のデザインを提供し、健全なチームと文化を維持するための重要なコンポーネントと見なされています。
高揚型構造における実践
一部の高位DesignOpsチームは、共有システム（デザインシステムやリサーチリポジトリなど）の作成と維持の負担を、個々のデザイナーの仕事量から取り除いています。そのようなDesignOpsチームでは、デザイナーと開発者がフルタイムでこれらの共有システムに取り組むこともあります。
集中型のDesignOpsチームは、分散型モデルを採用することもできます。この場合、DesignOpsの役割の1つのグループは各チームにまたがって働き、直接専任となり、1つのグループは集中型で文化構築、新入社員の経験、キャリア経路などのグローバルな取り組みに専念します。
高揚型構造の課題とメリット
専任のチームメンバーがフルタイムで集中的にツールやプログラムに取り組むことで、これらの取り組みが真に有用で利用しやすいものとなるよう十分な注意が払われ、デザイナーは二重責任にとらわれずデザイン業務に専念できるようになります。しかし、DesignOpsチームは、デザインチームのフィードバックを収集し、それに基づいて行動することに勤勉でなければなりません。さもなければ、無関係または役に立たないプロセスやツールがトップダウンで押し付けられていると感じているチームから軽蔑される危険性があります。
このアプローチでは、イニシアティブに優先順位を付け、時間をかけてDesignOpsを拡張する計画を立てるための強力なリーダーシップが必要です。DesignOpsの目標の進捗を評価し、ビジネスニーズの変化に応じてDesignOpsの注力分野を進化させ、DesignOpsのリーダーシップと影響力を組織内の他の部門と同等に高めるなどのプログラムの作成を考えている役割もあるはずです。
まとめ
組織で使用されているDesignOps構造を認識することは、強みを特定し、既存の成功したプログラムや取り組みを基にし、潜在的な危険性を認識するのに役立ちます。さらに、需要や規模が拡大し続ける中で、DesignOps構造の進化を緩やかに計画することも可能になります。
これらの構造を参照する場合、以下の点に注意してください。
- このリストはすべてを網羅しているわけではありません。これは一般的なDesignOps構造のセットですが、含まれていない他のモデルでもデザインチームをうまくサポートできる可能性があります。さらに、2つ以上のモデルのハイブリッドが存在することは合理的であり、一般的でもあります。
- これらの構造は成熟度モデルではありません。これらのDesignOps構造は、必ずしもDesignOpsの成熟度に対応するものではありません。チームによっては、1人のDesignOps専任の役割（つまり、孤立型構造）が適切なサポートレベルである場合もあります。ですから、高度の構造を持たないからといって、DesignOpsの実践が成熟していないとは限りません。あなたの構造は、現在および近い将来の状態における組織のニーズに基づいているはずです。
- ベストインクラスの構造というものはありません。ここには正解も不正解もありません。異なる組織は、そのコンテキストとニーズに応じて、異なる構造を使用することになります。
