DesignOps戦略 – DesignOpsチームを成長させるには?
DesignOpsは、多くの組織にとって重要な運営機能となっていますが、一部の企業では、まだ専門のDesignOpsの実装者やチームがなく、ボトルネックや非効率な作業を行っているのが現状です。
2020年にNN Groupが557人のUX実装者を対象に行った調査によると、「組織は推奨されるDesignOpsの取り組みを22%しか行っておらず、DesignOps専用の役割もなく、全体的にDesignOpsの成熟度は低かった 」とのことです。
というわけで、本記事では、DesignOpsの成熟度の4つのステージと、チームを拡張し成長させるために各ステージで設定すべき目標についてお話します。
まだ時代遅れの画像ベースのデザインツールを使っていますか?UXPin のコードベースのデザイン革命に参加して、デザインと開発を同期させる先進の Merge テクノロジーに触れてみてください。無料トライアルにサインアップして、Merge やその他の UXPin 機能をぜひお試しください。
ステージ0:DesignOpsの責任者がいない
機能を超えた小規模チームが一緒に仕事をしている製品では、DesignOpsのモチベーションは低く、NNグループは 「散在型チーム構造 」と呼んでいます。
プロダクトマネージャー、デザインリード、マネージャーは様々な運営活動を担当するため、Opsの仕事はチームメンバー間で「散在」しています。AmazonのシニアUXデザイナーであるオムカール・チャンドガドカール氏は、デザインバリュー会議2022の講演で、UXチームが戦略的ではなく反応的または戦術的に動作することから、この段階を「飛行機を飛ばしながらその飛行機をデザインする」と呼びました。
これはAirbnbの初期にも言えることで、デザイナーとエンジニアで構成されるプロダクトチームが同じオフィスで密接に働き、一日を通して交流し、関わり合っていました。彼らは緊密に連携し運営上の課題を一緒に解決していく、「全員参加型」の成長戦略でした。
しかし、Airbnbの成功と成長により、チームは分離し、サイロが生まれました。これは、急成長するスタートアップ企業や企業団体によく見られる問題です。
「…物事が突然難しくなる転換点に到達しました。チームはもはや全員が同じフロアに収まることはできませんでした…情報へのアクセス、デザイン基準、ワークストリームの衝突、品質問題、すべてが非常に現実的な問題となったのです。」(エイドリアン・クリーブ氏のDesignOps at Airbnbの記事から抜粋)
この段階でAirbnbはデザイン言語システムを開発し、DesignOpsが誕生したのです。
DesignOps ステージ0の主なリソース
ステージ1:一人体制のDesignOpsチーム
DesignOpsの最初の段階は、NN Groupが 「孤高のチーム体制 」と呼んでいるものです。DesignOpsは、その役割にフルタイムで専念する1人体制のチームとなります。SiriusXMのDesignOpsディレクターであるサロメ・モルタザヴィ氏がデザインバリュー会議2022の講演で指摘しているように、「DesignOps部門の70%は1人体制のチームである 」のです。
DesignOpsチームとしてスタートするとき、サロメは、まず耳を傾け、メモを取ることから始めることを勧めています。グループや1対1の環境で、人、スペース、プロセスなどを把握しましょう。
この傾聴のアプローチにより、企業の組織的・体系的な問題をあぶり出すことができます。また、DesignOpsの実装者は、組織の問題を特定し、明確に説明できるため、チームやステークホルダーとの信頼関係を築くことができるのです。
DesignOpsのステージ1の目標は、ボトルネックと問題の特定と、それに応じた修正の優先順位付けであり、サロメは、問題やテーマの特定にデザイン成熟度インデックスを使用しています。このようなDesignOpsの中には、解決しなければならないものもあれば、デザインリーダーに委ねられるものもあります。
DesignOps ステージ1の主なリソース
DesignOpsステージ2:DPM(デザインプログラムマネージャー)の採用
実装者が多少の成功を収め、組織がDesignOpsを拡張することに価値を見出したら、自身のチーム構築が始まります。この段階で、実装者が専門分野の専任チームメンバーの必要性を認識することから、NN Groupではこの段階を「特化型」DesignOpsと定義しています。
DPM(デザインプログラムマネージャー)は、DesignOpsチーム構築の際によく最初に採用されます。このDPMは、日々のワークフローの効率化のためにチームと一緒に仕事をしたり、オンボーディングやツールのキュレーション、ライセンシングなどの特定の分野に重点を置いたりすることがあります。
DesignOpsに影響力があり問題を解決するものですが、ステージ2ではまだ戦略的というより、非常に戦術的です。DesignOpsチームは問題解決や短期的なソリューションの開発には効果を発揮しますが、ロードマップがなかったり、長期的な目標にほとんど時間をかけていなかったりします。
DesignOpsステージ2の主なリソース:
ステージ3:DesignOpsの拡張
成熟したDesignOpsチームは、NN GroupのDesignOpsチーム構造に従って、「分散型」または「高架型」の構造で運営されています。DesignOpsは、このような成熟した構造において、ロードマップ、長期目標、およびプロジェクトの軌道のモニタリングを伴う戦略的な運営に流れていきます。
内部に目を向けるプロセス指向のDesignOps専任のリーダーがいます。Measuring DesignOps Impactでは、Babylonのアソシエイトデザインオペレーションディレクターであるパトリツィア・ベルティーニ氏が、DesignOpsリーダーの役割を5つの箇条書きでまとめています:
- 使命: その方法又はパフォーマンス
- 焦点: エンドツーエンドのデザインプロセスとチーム
- KPI:チームの健全性、支出、パフォーマンスのメトリクス
- 成果物: 運営ロードマップと戦略
- スキル: 変更管理
そして、DPMも同様に5つのポイントを使っています:
- 使命: 運営ロードマップの実行
- 焦点: 実行のためのプロセスの調整
- KPI:プログラムのメトリクス
- 成果物: 設計図、プロジェクト状況
- スキル: プロセスおよびプロジェクト管理
パトリツィア・ベルティーニ氏は、DesignOpsの介入すべき3つの領域を定めています:
- 事業運営:予算やリソース、その他ビジネスに関わるデザイン機能の管理
- ワークフロー及びデザイン運営:エンド・ツー・エンドのデザインプロセスの全体像。デザイナーはどのようにしてコンセプトから最終製品まで到達するのか?
- 人材操作:スキル開発、コミュニケーション、文化など、デザインチームの人的側面の考慮
DesignOpsの測定に関するウェビナーは、UXPinのYouTubeチャンネルでご覧になれます。
成熟したDesignOps環境でのDPMの拡張
DPMは、プロジェクトの戦術的または戦略的な戦略を適用するためにフレームワークを使用しますが、DesignOps Layers of Impactでは、マギー・ディエンジャー氏が以下のように「フレーミングとスケーリング」の方法論を用いて判断しています:
- どこに時間を費やすのがベストなのか
- その時間でどのように確実に最大の効果を発揮するか
マギーのフレームワークは、何かをすることの「適材」を探すのではなく、3つのフレームワークを通して、DPMが最も影響を与えることができる場所を特定するものです:
- デザインチームの規模や組織の状態は?
- どのようなリソースと割り当ての環境で運営されているのか?
- 主なデザインパートナーはどのレベルか?
このようなフレーム要因に対する答えが得られたら、マギーはエンゲージメントの範囲に応じて、一方はズームイン、他方はズームアウトして、影響力を高めることを考えます:
- ズームイン:チームとの日常業務
- ズームアウト:提唱、戦略、プランニング
マギーは、以下の5つの質問に答えることで、自分のフレーム要因と影響の度合いに基づいたサポートDPMの軌道を概説しています:
- どのような活動や環境が、日々自分に仕事のやりがいをもたらしてくれるのか?
- 自身がサポートするチームに対して、今、最もインパクトと影響力を持つ活動は何か?
- 自分のキャリアにとって重要なことに取り組むのに、パートナーをどのように活用すればいいのか?
- 望ましい行動やエンゲージメントに影響を与えるのに、どのようにチームの規模を利用できるか?
- 自分は戦術的な活動か戦略的な活動か、あるいはその両方が得意なのか?
彼女は以下についても考えます:
- 今日はどこにいるか?
- どこにいたいか?
- チームはどこにいたいのか?
DesignOps ステージ 3 の主なリソース
- DesignOps -Uber-:DPM(デザインプログラムマネージャー)が与える影響とは?
- DesignOps vs. Design Leader
- Patrizia Bertini on Medium
- re:Work by Google
- デイブ・マルーフ氏によるAmplify Design
- DesOps.io
- Nielsen Norman Group on DesignOps
UXPin MergeによるDesignOpsの拡張と成熟化
DesignOpsチームは1人であるため、時間とリソースが限られています。成熟するにつれて、ハイレベルな戦略と長期的な目標に焦点を当てたいと思うようになることから、デザインチームの成長や拡張のためのツールの確保は、どのDesignOpsチームにとっても不可欠です。
UXPin Mergeは信頼できる唯一の情報源(Single source of truth)を作成し、時間のかかる手動タスクやアクティビティを排除します。それによってDesignOpsの多くの課題が解消され、実装者やDPMは戦略的イニシアティブや価値作りに集中できる時間が得られます。
コードベースのデザインがどのようにUXワークフローの改善、デザインチームとデベロッパー間の連携の強化、エラーと再作業の削減、DesignOpsの価値提供につながるか、無料トライアルにサインアップしてぜひご体験ください。