DesignOpsのフィールドガイド

DesignOpsは、設計者がワークフローやライブラリの管理などの管理業務ではなく、問題解決に集中できるようにする考え方です。 DesignOpsの考え方は、創造的な卓越性を促進するデザイン中心の役割に情報を提供します。 DesignOpsのスタッフは、プロセスとツールセットを調整し、設計チームの文化を発展させ、設計が組織戦略の不可欠な部分であることを確認します。

「DesignOps」という用語は、速度、効率、自動化を優先するソフトウェア開発とシステム管理への共同アプローチであるDevOpsの離陸です。 DevOpsと同様に、DesignOpsは効率を重視しています。 その主な焦点は、デザイナーが自由にクラフトに集中できるようにすることです。これにより、デザインが組織に大きな影響を与えることができます。

残念ながら、多くの設計者は、設計システムの保守や他の部門への設計ワークフローの伝達などの管理業務に引き込まれています。 DesignOpsスタッフの役割は多面的です。

• 設計チームのプロセスとツールセットを調整することにより、設計者が高レベルで生産できるようにします
• 設計チームの目標と方法の認識を高めることにより、部門間の関係を促進します
• 生産性や設計チームのダイナミクスを犠牲にすることなく、設計を拡張できるようにします

DesignOpsの考え方は正確には何ですか？ 組織はどのようにしてDesignOpsの旅を始めることができますか？ そして、一度確立されると、DesignOpsチームはどのようにしてより高いレベルの成熟度に到達できますか？

DesignOpsは考え方です

理想的な世界では：

• 設計チームは孤立して存在しません
• 平凡なタスクは設計者に負担をかけません
• エンジニアリング（および他の部門）は、コラボレーションに熱心になります

しかし実際には、大規模な組織は、可動部分、官僚主義の狂気、およびさまざまな議題に満ちた複雑なエンティティです。

DesignOpsは、構造と柔軟性で複雑さに直面します。 これは、標準化された公式でも、厳格なルールとツールのセットでもありません。 それは考え方です。 確かに、DesignOpsのスタッフは実践とプロセスを確立しますが、それは「どうすれば…」などの組織固有の質問に対処した後でのみです。

• 時間の経過とともに設計チームを成長させ、進化させますか？
• 高度なスキルを持つデザインの才能を引き付け、維持しますか？
• 効率と品質のバランスをとる設計プロセスとシステムを作成しますか？
• 定期的に設計出力を測定して改善しますか？
• 設計部門と他の部門の間に永続的な協力関係を構築しますか？
• デザインが会社の戦略の重要な側面であることを確認しますか？

大規模な組織では、そのような質問は特に差し迫っています。 組織を維持し、目標を達成するために、多くの企業は厳格な内部ガバナンスに依存しています。 意図は秩序ですが、多くの場合、結果は停滞、または反イノベーション、デジタル時代の必殺技です。

DesignOpsソロスタッフのための8つのヒント

デザインに対する熱意はかつてないほど高まっていますが、多くのリーダーは、社内でデザインを全体的に実装する方法を知りません。 また、設計チームを巧みに拡張する方法も理解していません。 デザインは予算を獲得しますが、デザイナーが複数の方向に引っ張られたり、意思決定から除外されたりするため、その潜在能力を最大限に発揮することはできません。

この段階で、2つのことのいずれかが発生します。 誰かがDesignOpsとそれに対応する職務を擁護することを決定するか、誰かがデザインファシリテーターの必要性を認識して採用します。 いずれにせよ、DesignOpsチームオブワンが誕生します。

これは重要な分岐点です。 広大な組織の1人の人物が、設計を成功させるための人材、プロセス、ツールセットを調整し、イニシアチブに影響を与えるにはどうすればよいでしょうか。

1.何よりも関係を築き、育む

ソロスタッフは、組織内の人々、問題、目標を知らなければ繁栄することはできません。 関係がなければ、信頼はありません。

2.会話と会議を文書化し、要点に優先順位を付ける

タイトルに「Ops」が含まれているロールにはリクエストが殺到しますが、その多くはデザインとは関係ありません。 すべてを文書化し、アフィニティマッピングを検討して、繰り返し発生するニーズやアイデアを特定します。

3.関連性のためにDesignOpsバックログとランクエントリを確立します

ソロスタッフはそんなに多くのことしかできません。 いくつかのアイデア（良いアイデアでさえ）は後日待つ必要がありますが、完全に消えてはなりません。

4.会社の目標と戦略に合わせる

調整の領域が明確でない場合があり、設計をより適切に含めるために調整が必要な目標と戦略がある場合があります。 しかし、可能な限り、設計（したがってDesignOps）は、会社の目的とプロセスと一致するように努める必要があります。

5.組織内で変更を実装するための戦略について学ぶ

組織内に変化をもたらす実証済みのモデルがあります。 それぞれに長所、短所、哲学的見解があります。 たとえば、Lewinの変更モデルでは、組織の変化は次の3つの段階で発生すると想定しています。

• 凍結解除：今後の変更に備えて会社を準備します。
• 変化：会社が新しい態度や行動を受け入れるのを助けます。
• フリーズ：会社を統治する更新された原則とプロセスを形式化して文書化します。

6.あらゆる場面でデザインの価値を伝える

人々がデザインの価値を高く評価していると思い込まないでください。 ビジネス目標に結び付けられた明確な価値提案を欠いた説明、プレゼンテーション、および会話は、無駄な機会です。

7.過度の責任を負わないようにする

コミット中、配信超過。 すべての要求と新しいイニシアチブに「はい」と言い過ぎないでください。また、長年にわたる企業の対立に飛び込む前に、リスクを比較検討してください。

8.忍耐強く前向きであり続け、段階的な変化を予測する

DesignOpsのソロスタッフは、企業文化を一夜にして変えることを期待すべきではありません。 小さな勝利を祝い、避けられない挫折にとらわれないでください。 組織の慣性をリダイレクトすることは困難です。 それは不可能ではありませんが、時間がかかります。

DesignOpsマイルマーカー

組織内でDesignOpsを成長させる単一の方法はありません。 DesignOpsの開発は、直線的なプロセスではなく、反復的なプロセスと考えるのが最善です。 デザイナーや組織のニーズは固定されていません。 それらは動的です。

とは言うものの、DesignOpsが存在しないことと、十分に油を注いだDesignOpsチームとの間の道には、いくつかの重要なマイルマーカーがあります。

ステージ1：システムで時間を節約する

企業内でDesignOpsがサポートされるようになると、必ずしも新しい役割を確立する必要はありません。 DesignOpsビジョンを策定して、その実装をガイドすることが有益な場合があります。

この移行段階では、多くの企業が設計の体系化を開始します。 多くの場合、これは、視覚的なガイドラインとコンポーネントライブラリを作成するために、専任の設計チームメンバーと提携している設計リーダーのように見えます。 体系化することで、設計者に再利用可能な資産と繰り返し可能なロジックを提供して、繰り返し発生する設計の問題を解決することにより、時間を節約できます。

ステージ2：コラボレーションフォースを編成する

システム化は不可欠ですが、それはDesignOpsの1つの側面にすぎません。 堅牢な設計システムでさえサイロ化することができます。 コラボレーションして、設計以外の利害関係者からのサポートを得る時が来ました。

「タイガーチーム」と呼ばれることもあるDesignOpsタスクフォースは、設計、エンジニアリング、マーケティングなどの部門のリーダーで構成される部門横断的なグループです。 メンバーは半定期的に会合を開き、学際的なコミュニケーションのラインを開き、共有されたデザイン関連の目標に向けて取り組みます。

タスクフォースは、さまざまな専門的背景を持つ人々の問題解決能力を組み合わせているため、便利です。

ステージ3：DesignOps外交官を探す

DesignOpsが繁栄するためには、企業は最終的に、デザインに力を与え、DesignOpsの考え方を促進することを唯一の目的とする人を雇う必要があります。 この担当者は、設計チームと協力して課題を理解し、生産性を向上させるプロセスとリソースを紹介します。

その役割を担う者は誰でも、設計部門と他の部門との間の継続的な結束を確保するために外交を示さなければなりません。

ステージ4：業務と文化を強化するためにスタッフを雇う

専任のDesignOps採用者が設立されたため、増大するDesignOpsワークロードをサポートするために追加のスタッフが必要です。 ここでは、アプローチが異なります。 一部の企業は、設計スタッフ、予算、およびリソースのニーズを調整するために運用マネージャーを雇っています。

他の企業は、優秀な人材を引き付けて保持するデザインチーム文化を育むために誰かを任命するかもしれません。 この担当者は、設計スタッフに目的とモチベーションの感覚を与える習慣（オンボーディング、パフォーマンスレビュー、昇進パス）を監督します。

ステージ5：部門間のワークフローを管理する

DesignOpsの成熟の「最終」段階はありません。 DesignOpsの考え方では、設計チームのニーズと会社の目標が確実に満たされるように、継続的な警戒が必要です。 ただし、設計部門と他の部門、特にエンジニアリング部門との間のワークフローを管理する人を雇うことが有益な場合があります。 意図は、共通の目標に向かって進むときに、設計と他の機能の間の結束を維持することです。

DesignOpsは問題解決に活力を与えます

多くの企業はデザインを高く評価し、多額の投資を行っていますが、リーダーシップを発揮する非デザイナーは、デザインを拡張する方法や、より広範なイニシアチブに組み込む方法を知らない場合があります。 DesignOpsまたは同様の促進的な役割がないと、大規模な組織の設計チームは、注意散漫に圧倒され、他の部門から切り離されるリスクがあります。 プロセスはダブテールになり、ツールセットは扱いにくくなり、結果として生じる混乱は製品の不整合を引き起こし、内部の争いやユーザーの問題点を生み出します。

DesignOpsの考え方は、プロセス、ツールセット、およびそれらを使用する人々の間の調和の必要性を認識しています。 企業はアプローチが異なり、実装について独断的である必要はありません。 多様な構造は、DesignOpsの核となる信念を取り入れている限り、成功する可能性があります。設計者は、自分が最も得意とすること、つまり問題を解決するために時間を必要とします。

ご意見をお聞かせください。 以下にあなたの考え、コメント、フィードバックを残してください。

•••

Toptal Designブログでさらに読む：

• 構造の力–システムモデルを設計するためのガイド
• 進化するUX–CXOを使用した実験的な製品設計
• 過去はまだ存在している–時代を超越したデザインの概要
• アクセシブルデザインとインクルーシブデザイン（インフォグラフィック付き）
• リモートデザインスプリントを実施する方法