見出し画像

事業貢献できるデザイン組織を目指して - コムデ唯一のDPM 1年目のトライ

こんにちは!ファインディ コミュニケーションデザインチームのトム(@_tomd4)です🐕

「事業貢献に関して気づいたこと」をテーマにした ファインディデザインチーム Advent Calendar 2024 の23日目の記事です🎄

今回はタイトルの通り、コミュニケーションデザインチーム唯一のDesignOps担当・DPM(仮)として、入社1年目でやったトライをご紹介します!
具体的なトライの内容だけ知りたい人は、目次の「今年やったトライ」からご覧ください ✌︎



「DesignOps」との出会い

私が「DesignOps」というキーワードと出会ったのは約1年前の話です。
ファインディに入社前、オファー面談を受けた2023年8月某日。マネージャーの向さんにいただいたオファーメッセージには「入社後は、デザインだけでなくDesignOpsも期待します」というような一文が書かれていました。
いただいたオファーを即承諾しつつ、当時は「DesignOps……?はて…?」という状態。

DesignOpsとは、端的に言うとデザインにまつわるオペレーション改善のことで、調べると下記のように解説されています。

DesignOpsとは、Design Operationsの略称で組織内でデザイン業務を行うにあたり各種機能を整備し、デザイン業務やデザイナーを最大化する役割を担う機能または機能を持ったチーム

引用:DesignOpsの役割とは - Goodpatch Blog

そして、DPMとはDesignOpsを推進する人のこと💡

DesignOpsを推進するのがDPM(デザインプログラムマネージャー)です。デザイナーが「エンドユーザー」のためにデザインスキルを駆使するのに対し、DPMは「デザイナーとデザインチーム」のためにデザインスキルを駆使します。

引用:デザイン組織を強くする「DesignOps」と「DPM」とは DPMがその役割と6つの取り組みを紹介

前職でもOps改善ぽいものは自主的にやっていたので「なるほど楽しそう、やってやろうじゃないの〜🔥」と肩をぶん回しながら入社しました。

当時のオペレーションの伸びしろ

ファインディは2016年に設立した「挑戦するエンジニアのプラットフォーム」として4つのサービスを展開しているマルチプロダクトのスタートアップです。
組織が急拡大しており、正社員数はここ1年で2〜2.5倍(約300名)、デザインチームもほぼ2倍になっています🎉

そんなファインディのDesignOpsはこんな感じでした。

🫨 デザイン依頼時の情報量や素材の揃い具合がバラバラ
組織が急成長したこともあり、色んなバックボーンを持つメンバーから依頼をいただくように!嬉しい反面、このデザインはいつまでに?誰に向けて?何を達成したいんだっけ?…などがわからず手戻りがあったり、慣れない進行ですり合わせに時間がかかりデザインに着手できず…なんてことも🌇

😭 一度経験したしくじりが別の事業部でも再現してしまう
組織が急成長したため、施策の幅もどんどん増えていきます。今までにないデザインをつくる上でのしくじりや落とし穴がシェアできておらず「それ◯◯事業部のXXでも同じこと起きてた、、、」という事象がたびたび起きました。かなC…。

😵‍💫 DesignOps改善どこから進めたらいいかわからん
元々ドキュメント化や仕組み化は進んでいたほうですが、組織拡大につれOps改善の需要がどんどん高まっていきました。優先度をつけて進めようにも、みんなの声を聞くとどれも「優先度:高」にしてしまいたくなる…どれから進めよう…と迷っているうちに改善のスピードが落ちてしまうことも。

今年やったトライ

トライ1つめ:誰が依頼しても最低限の情報が揃う!依頼フォームの改善

ファインディにおけるデザイン依頼は、スプレッドシートの「依頼フォーム」から起票→Trelloでタスク化→Slackで担当デザイナーに通知…というフローになっています(仕組みがすごい)

先述のデザイン依頼時の情報量や素材の揃い具合がバラバラ…を解決するために、依頼フォームの項目を「どの事業部の誰が依頼しても致命的な情報の抜け漏れがない状態」に改善しました💪

依頼フォームは大カテゴリ(LP/バナー/イベントバナー/記事サムネイル/印刷物…)でタブを分け、大カテゴリごとに項目を最適化しています。

どの大カテゴリでも共通して入れている項目は下記の通り。

* 納品希望日
* カードカテゴリ(選択式)
* 納品形式(選択式)
* 何を作るか
* なぜやるか、施策をやるに至った背景
* 誰に向けて作るか、ターゲットと影響範囲
* 施策のKPI
* リリース日
* 緊急度(選択式)
* 依頼の承認者
* 新規 or 流用 or テンプレ(選択式)
流用する・テンプレ化されたデータのURL
参考デザイン
参考デザインの良い点、踏襲したい点

今期のデザインチームで特に重視しているのは「施策のKPI」。
事業にインパクトの大きい施策はクオリティ重視で力を注ぎ、お試し施策はスピードを重視したりと、注力度合いを使い分けています。

デフォルトの項目に加えて、印刷物は印刷物ならではの項目もあります。

* 使用する場所・イベント名
* 入稿日(yyyy-mm-dd)
* 入稿テンプレートの格納先 or URL
* 入稿する印刷所の商品ページURL
* 印刷サイズ(選択式)
ページ数(選択式)

実際の依頼フォームはこんな感じ👇スプシ!!

デザイン依頼時に情報が揃うようになったことで、デザイン着手までのスピードが上がったり、施策の目的を知れることでより良い見せ方の提案ができるようになりました!

事業部からは「デザインを作るのにこんなに情報がいるんですね、知りませんでした…!」というお声をいただくこともあります。
丁寧にフォームを書いてくれる事業部のメンバーがいてこそ成り立っているものなので、本当に事業部メンバーに感謝です🙏😭ARIGATO…


トライ2つめ:二度と同じ轍は踏まんぞ…事業部とコムデの知見の溜まり場 「あゆみ👣」

一度経験したしくじりが別の事業部でも再現してしまう…を解決するために生まれたのが「あゆみ👣」
(命名はマネージャーのぱやさん)

事業部とコムデがよりうまく連携していくための事例と対応策を知見として残していくためのシートです。事例ごとに、起きた事例/次どうするかの対応を合わせて記載しています!

具体例を3つ出してみます👇

▼事例
資料をちょっと修正するだけのはずが、構成から変えることに…工数が思ったよりかかってしまった…

▼対応
・依頼者&デザインチームで関係者にベストな形をヒアリングしてから一緒に進めていく

▼事例
初めてやる媒体の広告の知見がお互いに少なく、初校が上がった段階で方向性を再検討することになってしまった

▼対応
初媒体のときは、いつもよりコミュニケーションを行うようにする(事業部、デザチどちらも)
→事業部、デザインチームともに経験者をアドバイザーとして1名確保

▼事例
普段とは違う事業部から、予測していなかったデカめの施策のデザイン依頼をいただいて、パツりそう!

▼対応
事業部と月1でMTG実施、事前に依頼予告をもらっておく

などなど…。
デザインチームは事業部担当制ですが、上記のような事例を定例等でシェアすることで自分の担当外の事業部や施策の知見を溜めて次に活かすことができます。

このシートを定期的に振り返ると、しくじりを繰り返してない=デザインチームが常に前進していることも把握できます💪


トライ3つめ:改善によるリターンを定量で示す、DesignOpsリスト

DesignOps改善どこから進めたらいいかわからん…を解決するために生まれたのが「理想郷 - ユートピア」シート🍑
(命名はマネージャーのぱやさん)

実際のDesignOpsリスト「理想郷 - ユートピア」

このシートに伸びしろ(改善したいDesignOps)と、DesignOpsを改善することによるリターンをまとめています。

リターンを出す計算式はざっくり以下の通り。項目を埋めることで1ヶ月あたりに削減できる人件費を出せるようにしました ✌︎

(事業部)月に何人が/月に何回/1回あたり何分
= 事業部の工数/月

(デザチ)月に何人が/月に何回/1回あたり何分
= デザチの工数/月

合計工数/月 * 分給(nnn円)
= リターン金額/月

ちなみに実際の計算シートがこちら🙈(さっきのシートの右の方にある項目です)

リストには私を含むデザインチームの声や、事業部からいただいたOpsに関する声が集まっています。
すべて改善したいところですが、タイトルにある通りコムデのDPM的ポジションは私ひとり。
捌ききれないときは「リターンが大きい × 改善の工数が少ない」ものから改善するようにしています💪

また、DesignOps改善はチームにとって必要な取り組みですが、目に見える成果物がないので評価されづらい(しづらい)という一面もあります。
定量でリターンを示すことでやるべきOpsを明確にできるだけでなく、上長も評価しやすいとのこと!


おまけ:カレンダーでのタスク管理&GASを使った予実の比較

これはまだ個人で試運転中なのですが、、「今日やろうと思ったのにまたできなかった…」を減らすためのトライをご紹介!

私は今日やるタスクを全てGoogleカレンダーに入れているタイプでして、1日のタスクがカレンダー通りに終わったかをGASを使って比較してみています。

最終のアウトプットをお見せするとこんな感じ👇
青い列の「工数差分」が予実の比較(タスクの見積もり時間との差異)です。

▼実行フロー
1. 始業直後、Googleカレンダーにタスクを入れる
2. タスクを入れ終わったらGASを実行
〜日中、タスクをこなしつつ所要時間を見直しながら予定を調整〜
3. 終業直前、GASを実行
4. 朝(予)と夜(実)にどの程度差があったか確認

上の表を見ると、タスクの見積もりを誤りまくっていることがわかりますね…🫠

とはいえこのトライをしたことで、どの程度見積もりミスがあるか、どんな種類のタスクで見積もりミスが多いか、どの程度差し込みタスクがあったかが掴めてきました!

ちなみにGoogleカレンダーでのタスク管理はこんな感じでしています👇
忘れっぽい人におすすめ😘

ガパオライスはちゃんと食べました

ちなみにこれはChatGPTに連投しながら書いてもらったGASなので意図しない挙動が多いのと、カレンダーにタスクを入れるタイプじゃないと運用できないなのでこのまま個人で使うだけかもしれないです🥱

DesignOpsを改善しようとして「チームに何かしらのアクションや記入をしてもらう」というフローを挟むことがありますが、こういうトライをするとアクションの大変さや運用の大変さを体感できていい学びになりますねえ…。

おわりに

長くなってしまいましたが、トライのご紹介は以上です!
コムデでやっているDesignOpsや事業貢献のための取り組みをもっと知りたい人は、コムデのマネージャー ぱやさんのnoteもぜひ👇

コムデのDesignOpsの事例はあまり表に出ることが少ない気がしているので、皆さんのトライもあればぜひ教えてください!

それではまた次回〜👋🎅

Xのお友達も募集中です🕊️トム @_tomd4



いいなと思ったら応援しよう!