スタートアップで作るよデザイン組織 #1 ワークフロー編

(*この記事はスタートアップでデザイン組織を作り上げるために実践している事やTipsを赤裸々に公開していくスタイルの記事です)

🎉目次
 0. 前置き
 1. 概要をさっと湯通し
 2. ストーリーカンバンボードとは
 3. 導入のメリットと方法
 4. さいごに

0. 前置き

こんにちは。 グレイテスト・ヒロキです。
グレイテストショーマンがとっても大好きです。

僕は、先日β版をリリースしたCocoda!というサービスのリードデザイナーとして日々プロダクトやデザインと向き合う日々を送っております。

デザインと向き合う日々を送る中で、やはりプロダクト作りや経営におけるデザインの重要性を強く感じるとともに、

最近は「デザイン経営宣言」が経産省からリリースされたり「CXOnight」(いきたかった、、😂)がめちゃくちゃ盛り上がっていたりと、「デザイン」という概念そのものや、デザインと事業/経営との連結というような文脈が多く話題に上がるようになってきました。デザイン界隈が盛り上がっていくのは素直に嬉しいです、、、!

一方で、しっかりと経営や事業に対してデザインの力を浸透させきれている企業はまだまだ少ないと思っています。

かく言う僕たちも、初めての起業に加えて、ノンデザイナー、ノンエンジニアが集まって、必死に知識をかき集めつつ頑張って創り上げてきたので、まだまだ完璧とは言い難いです。

また、その中でも強く感じていたのは、エンジニアリングやその他ビジネス領域と比較すると、デザイン領域はオープンになりきれておらず、これからデザイン組織を作りたいと志す人達にとっては、情報が手に入れにくかったり、何が良いかが判断しづらかったりと、なかなか困難な道のりだということ。

そんな背景があった上で、まずは自分達からこの状況を変えていこうと考えまして、これから「スタートアップで作り上げるデザイン組織」という題で、僕たちが実際に取り組んでいるデザイン組織づくりの流れを限りなく具体的に、ばばばばっとnoteに書いていきたいと思います!
(ニーズがあれば連載したい🐶)

改めてこのnoteの目的をまとめると以下です。

🎉このnoteの目的
①現在の体制をオープンにして少しでもデザイン界隈の役に立ちたい
②自分たちの体制を改めて言語化/発信することでよりよくしていきたい
③これからデザイン組織を作る人達における勇気の種となりたい

この取り組みを通じて、私達もこれやってみるか、、!🙆とか、こんな人達でもやってんだからうちでもできるはず👍という風に次に続く人たちにとっての拠り所のようになれたらなぁぁと思っております。

では長い前置きはコレくらいにして、本題に入ります。


1. 概要をさっと湯通し

まず初めに、今回のnoteで共有する事項の要旨をまとめておきます。

🎉要旨
1. cocoda!チームで採用している「ストーリーカンバンボード」という
 プロダクト改善フレームに関するお話です。

2. 開発体制が可視化されること / タスクの選択と集中 / スピード感のある
 プロダクト改善が可能という3点が主なメリットです。

3. スタートアップで実際に取り組んでいる事例を元にしたワークフローの
    Tipsが記載されています。

要旨はこんな感じですね!

その上で、プロダクトフェーズや組織状態の前提が揃っていないと理解しづらいと思うので、簡単に僕たちのチームについて以下にまとめます。

🎉サービス/チーム概要
1. Cocodaというwebサービスβ版を5月末にオープンしたばかり
2. クローズドで開放しつつユーザーテストを繰り返し、プロダクトを改善中
3. デザイナー4人、エンジニア2人の計6人で実働 
4. 美大卒あるいはデザイン実務経験者は不在

というような状況でございます。

2.ストーリーカンバンボードとは

さて、今回は僕たちのプロダクト改善プロセスの中でも特に大きな役割を担っている「ストーリーカンバンボード」というものを紹介したいと思います。

「ストーリーカンバンボード」は簡単に言うとプロダクトの改善を行っていく上で使用しているフレームワークです。
具体的には以下の機能を持っています。

🎉機能一覧
・プロダクトの改善点の洗い出し
・一定の期間中に実装までやりきる改善点の選択
・選択した改善点に紐づく担当と進捗の可視化
・ワークフロー全体の可視化 + コミュニケーションの活性化
・プロダクト改善のサイクルタイムを規定

うむ。文字だけだと伝わりづらい、、。
よりイメージが付きやすいように、実際に使用しているグーグルスプレッドシート(※以下GSS)を掲載用に修正したものを以下に貼っておきます。

 基本的にフレームワークをGSSに落とし込んだものを、皆で突き合わせつつ議論したり、更新していっています。

さらに、分かり易いように図解したものを以下に掲載します。

概要は上図の通りとなっており、基本的にチームとしてのデザイン-開発体制はほぼ全てこのプロセスに則っています。

※カンバンボードを用いたチーム体制のイメージを先に付けたい方は、とても簡易で分かりやすい記事があったので見てみるといいかもしれません。(若干違うところもあるので、詳細は当noteを読んでいただけると嬉しいです!)


次に、それぞれのステップに区切って位置付けや、具体的なアクションを記載していきます。


①プロダクトの改善点洗い出し

このステップでは、プロダクトをよりユーザーフィットさせていくという前提のもとに、プロダクトの改善点(ここではバックログと呼んでいます)を発散/蓄積していきます。

このステップの後に、蓄積したバックログの中から実際に改善していくものを選択していくことになります。

Cocodaチームでは、以下に記載する主に2つのアプローチによって「バックログ」を発散/蓄積できるようにしています。

🎉バックログの出し方
1. ユーザーの要望にFitしていないポイントを抽出
2. サービス上でユーザーが躓いてしまうポイントを抽出

1では、リリースしたプロダクトを用いたユーザーインタビュー等を実施した上で、ユーザーの要望にフィットしていない部分を洗い出していきます。

2では、ユーザーがサービス上で行うアクションを全て洗い出した上で、ユーザーが離脱しているポイントを抽出していきます。どれだけユーザーの要望に沿った機能を実装できても、IAやUIが不適切であることでユーザーが離脱することも有り得るので、それらを防ぐ意味で実施します。

2を行う際に実際に使用しているシートを掲載用に修正したものを以下に貼り付けておきます。

上記のGSS上で行っている事を分かりやすいように図解すると以下になります。

まずはじめに(1)ユーザーがログインする - (2)ホーム画面を開く - (3) 初めのコンテンツを選択する - (4) コンテンツの説明を読む ぐらいの粒度で、ユーザーが経験する全アクションのフローを定義し、

それらのフローに対してグーグルアナリティクスや、ユーザーインタビューを用いて、ユーザーが躓きうるポイントをその現象と要因に分けて洗い出します。

次に、ユーザーの離脱率やKPIへの影響を考慮しつつ優先順位付けをします。

最後は、ユーザーが躓きうる要因を解消するための改善点を発散してバックログへと移行させます。ちなみに、改善方針を策定する際にはフックモデルを用いて、アクションに対してアクションを誘発するトリガーあるいはその後の報酬(リワード)が薄いのではないかという観点から考えることが多いです。

フックモデルに関しては、大嶋たいとさんが以前投稿していたLINEのリデザインを考えてみたnoteで触れられていて、とてもわかり易かったので、そちらを掲載しておきますね!(大嶋さんいつも見てますファンです!💫)


チームとして、「どれだけインパクトの大きいバックログ(解くべき問題)を見つけられるかどうかが、プロダクトの天井を決める」と考えているので、このステップはスピードは意識しつつ、とても力を入れて、メンバー全員が責任を持って進めています。

②スプリントで扱う改善点の選択

ここでは発散したバックログの内、実際にチームとして仕掛かるものを選択していきます。PMがこのステップを担当する場合が多いですが、cocodaチームでは全メンバーが参加するMtgで扱います。

選択した後の流れとしては、基本的に1週間を一つのサイクル(このサイクルをスプリントと呼んでます)として、改善のための施策(UI変更等)出しから、ユーザーテスト、実装(デプロイ)までをやりきることになっています。

仕掛かるバックログを選択する際のポイントを以下にまとめておきます。

🎉仕掛かるバックログを選択する時のポイント
1. 一回のサイクルで扱うバックログは5個程度にすること
2. ユーザーの深い課題に紐づくバックログを優先度高く選択すること
3. KPIとの結びつきを言語化しておくこと

補足として、1回のサイクルで扱うバックログを5個程度に抑えるのは、タスクに対して選択と集中を行い、着実に改善をしきること、スピード感を維持すること、不測の事態に対しての対応を行いやすくするということが意図としてあります。


③改善点それぞれの担当と進捗の可視化

ここでは、次のサイクルで扱うことになったバックログを実際に改善していくことになります。

基本的には1つのバックログに対して、デザイナーとエンジニアがタッグで取り組めるような担当振りを意識しています。これによって、1週間という短い期間の中でも、改善の方向性からデザイン、実装までの流れが一切ぶれずスピード感を持って改善が進められるようになります。

その上で具体的な改善のフローは以下のようになっています。

🎉改善のフロー
(1)  IDEA -要望の明確化 + 改善の方向性定義
(2) DESIGN -要件化 + プロトタイピング
(3) TEST - ユーザーテスト+ デザインへの反映
(4) IMPLEMET - 実装(デプロイ)

項目だけでは分かりづらいので図式化したものが以下になります。

基本的な情報は全て上図に入れ込んだつもりですが、最近Cocodaチームでテンションがとても上がったポイントがあったので、記載しておくと、Figmaを用いたプロトタイプの同時編集がとてもおすすめです。

多くの場合、ラフスケッチやプロトタイプ作成はデザイナーが担当して、作ってきたものに対して共有して議論したりと、コストがかかることが多いと感じているのですが、

Figmaを使えば全員で同じアートボードを同時に操作しながらデザインが作れるので、コミュニケーションコストが限りなく減り、かつ素早くプロトタイプが作成できます。Figmaに関する記事も貼っておくので是非見てみてください。


基本的には上記のフローで改善を行いつつ、適宜Slack上に進捗を報告、GSSへの反映、週一回の進捗確認Mtgで共有を行っていきます。デプロイが完了したバックログに関しては次のステップへと工程が移行します。

④検証方法と検証結果の蓄積

ここでは、デプロイまで完了したバックログの効果検証を行っていくにあたって、それぞれの検証方法とその結果を蓄積していきます。主な検証方法をマトリクスでまとめると以下になります。

それぞれの機会に関して詳細を記載しているとこれまた長くなってしまうので、あえて鉄板な機会ではなさそうなTwitterや、もくもく会について簡単に記載しておきます。

(1)Twitter
 CEOのココディー氏(@co_co_d3 )は生粋のツイッタラーなのですが、Twitter上でユーザーと交わされるコミュニケーションがプロダクト改善にも大いに役立っていたりします。

例えば、実際にユーザーの方からプロダクトの使用感や、フィードバックを送っていただいたり、

次の例のように、スプリントで改善した機能をTwitter上で周知し、そこに対してのフィードバックを頂いたりというような形です。

twitter民の皆様にはcocodaチーム一同本当に感謝しております。これからもよろしくお願いいたします。💁

(2)もくもく会
Cocoda!では、以下のようにCocodaを使用してくださっているユーザーの皆様や、デザインに興味がある方々が集うSlackコミュティを運営しているのですが、

コミュニティに参加している人たちが、集まってデザインを勉強したり、知識を共有し合ったり、交流を深めるための機会として「もくもく会」なるものが開催されています。

基本的には、デザインに興味がある人同士の交流や、一緒にデザインをする場として開かれるのですが、Cocoda!の新機能が搭載された時には実際にその場で使っていただいて、使用感を聞かせてもらったりします。

フラットな環境の中でリアルな声を聴かせていただけると、プロダクトのコアな改善点や、伸ばすべき点が見えてくるので、本当にありがたいです。

上記はほんの一例ですが、記載したような機会の中で改善したバックログの効果検証を行い、もし、まだ改善が不完全であった場合には再度バックログとして蓄積するようにしています。


⑤チームでの扱い方

ここでは補足という形で、上記のワークフローをマネジメントするという観点で行っている事や、意識している点を簡単に記載しておきます。具体的なアクションとしては以下です。

🎉マネジメント側のアクション
(1)全メンバーを上流(Biz ~ UX ~)議論へ巻き込むこと
(2)週一回進捗確認+ 次の仕掛かりタスクを意思決定するMtgを設置すること
(3)Slack上での活発なコミュニケーションを促すこと

(1)に関しては主にCEOのココディー氏(@co_co_d3 )やPMの加藤(@slum_danker )が役割として大きく担ってくれているのですが、メンバー全員がデザイナー/エンジニア関係なくビジネスサイドやユーザー体験のような上流から、実装方針まで議論できるような組織づくりを意識しています。

これによって、タスクを振った後に方針を見失って出戻しになるような自体が限りなく少なくなったり、そもそも全員が同じ水準でプロダクトに関して議論ができるようになっていきます。

(2)に関しては、実際に使用しているアジェンダを掲載しておきます。基本的には全メンバーが目標と進捗を同じ水準で理解し、次回のサイクルで扱うことに関して疑問が一切ない状態を目指すことを意識しています。

(3)に関してはこれまた長くなってしまうので、次回以降に詳細を記載したいのですが、ポイントとしては「分報」などの仕組みを取り入れつつ、オンライン上で詳細かつリアルタイムで進捗を共有し合い、即座に課題解決が行われるようにすることがあげられます。

多くの場合、毎日の朝会などで進捗が共有されるようですが、スタートアップのような毎日劇的に状況が変化する環境では、日毎の進捗共有ですらコミュニケーションのタイミングとして遅かったりリモートが多いと実施が難しいなどの背景があり、Slack活用をおすすめしています。

「分報」に関しても詳細が分かりやすくまとまっている記事があるので、掲載しておきますね!(これは坪田朋さんにSlack弟子入りした時に教えてもらいました。記事はLeo君が書いてくれてます。お二方に圧倒的感謝です😂)


3. 導入の効果とポイント

ここではまとめとして上記のワークフローを導入することによって得られる効果や、導入してみた上でのポイントを記載したいと思います。

まずはじめに導入することによる効果をまとめると以下になります。

🎉導入の効果
(1) 改善の体制、進捗が可視化されること
(2) タスクの選択と集中が促され、結果的に素早く改善が進められること
(3) スピード感を持った改善が可能となること

主な効果は上記の3つに集約されると思います。もちろんその他にも沢山導入の効果はあるのですが、今回は特に大きな3つを取り上げました。

Cocodaチームでも、導入する前はワークフローが決めきれていなかったため、若干場当たり的に改善をしまくっていくというような状況だったのですが、カンバンボードを取り入れてからは、大きくチームの動きが変わったように思います。

また、チーム全体がデザインに大きく関わるワークフローを採用したことによって、チーム全体のデザインへのリテラシーが高まったり、ユーザーの体験をよりよくするという共通目的を強く意識して議論や実働ができるようになったと感じています。

ワークフローを見直してみることは、直近の課題解決能力が向上するということだけでなく、長期的な組織づくりにも大きく影響を与えるものなのだと強く学んだ次第でありました。


4.さいごに

🎉ありがとうございます。
書き始めたら思った以上に長くなってしまったのですが、ここまで読んで頂き本当にありがとうございます!
もう少し分かりやすく書けたらと反省する部分も多いのですが、デザイン界隈をもっともっと盛り上げたいという思いが、有り余りに余りまくっておりましたのでnoteを作成しました。
今後も何かしらの形で貢献したいと考えているので、そのときは是非よろしくおねがいします!

🐶是非、お話したいです。
もしこのnoteで興味を持ってくださった方がいれば是非お話したいです!
デザインの事や、スタートアップのこと、ノンデザイナーからデザインになる道のりなどなど、いろいろ話したいし、繋がりを作っていきたいのでDMやリプ等々お待ちしております💁

ちなみに7/1よりcocodaチームこぞって、上京して目黒と渋谷を行き来する人になります!

👶Cocodaをよろしくおねがいします。

「デザインを学ぶ、デザインと遊ぶ、デザイナーになる」コンセプトのデザインコミュニティサービスCocoda!はこちらになります。今はClosedβ版として運用しておりサーバーやバグ対応などの観点から事前登録や利用申込された方から少しずつ解放させていただく形となっています><

では、また。

この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

46

#デザイン 記事まとめ

デザイン系の記事を収集してまとめるマガジン。ハッシュタグ #デザイン のついた記事などをチェックしています。広告プロモーションがメインのものは、基本的にはNGの方向で運用します。
5つのマガジンに含まれています
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。