プロダクト開発におけるリズムをデザインする
今回は前回記事の続編です。
UI Designerとして日々デザインを重ねながら、以下にも取り組んできました。
今年に入ってからはPdMとしてプロダクト開発における4つのリズム（Daily / Weekly / Monthly / Quarterlyで何をすべきか）のデザインに取り組んだりしているのですが、上手く回り始めたところ、噛み合ってないところ様々で、まだまだ道半ばではあります。
また上記リズムの中で、どのタイミングでどれだけ・どんなデザインを作っていくのかーー。これは今まさに取り組んでいるテーマでもあるので、もう少し考えがまとまったらまたnoteに書けたらと思います。
ここら辺について書ければと思います。
結論からいうと
Dailyで顧客要望に向き合い
WeeklyでOKR進捗と課題を共有しあい
Monthlyで開発計画を見える化し
Quarterlyで次に向かう目的地を定める
上記リズムの中で
最初に具体的な仕様とUIを詰めるコンセプトデザインをし
本格的に実装が始まってからはTechと一緒にディティールデザインをする
ということを書いていきたいと思います。
Dailyのリズム
8:45〜9:00で毎朝チーム朝会があります。チェックインと全体連絡のあと、Shinkaを確認します。
↑Shinka例
Shinkaとは、Slackに投稿されたプロダクトへの改善要望のことです。Shinkaは誰でも投稿することができるのですが、お客さんと日々接するフィールドセールスやカスタマーサクセスからの投稿が多いです。
▼優先度
1.やらないと機能・サービス提供にリスクが生まれる
2.できるだけ早いタイミングで開発したい
3.いつか開発したい
上記のような優先度を添えてもらい、例えば
優先度 : 2.できるだけ早いタイミングで開発したい
店舗数・拠点数も情報掲載して欲しい
理由は〇〇・・・
優先度 : 1.やらないと機能・サービス提供にリスクが生まれる
決算資料がちゃんと表示されていない企業がある
発生したのは△△という企業で・・・
などなど、こういった投稿が日々溜まっていきます。毎朝、どんな要望が来ているか皆で確認。
何度も目にする要望であればそれほど求められている機能/ユースケースなのかなと気づきにもなるし、内容がよく分からないものは投稿者に直接聞いて背景への理解を深めたりします。
緊急度の高いものはその場でNextアクションを決めます。
Weeklyのリズム
毎週1時間、チーム全員で集まる全体MTGがあります。ここでは大きく2部構成で
【前半】OKR進捗状況の共有 [30分]
【後半】皆で議論したい「何か」議題持ち寄りで [30分]
このような形で行っています。
後半30分の「議論したい何か」。今は何だかんだ議題が絶えないのですが、最初のうちは20人近くが集まるミーティングで何を取り上げどう話すと有意義な場になるのか、苦慮していました。
MTGを主催ないしファシリテートする側になって気づいたのですが、職種バラバラ＆大人数が集まるMTG設計は本当に難しい。
最初は、毎日のShinkaの中から「これは」と思うものを自分でピックアップしNextを切るため俎上にのせるよう努めていたのですが、毎週やるには負荷が高すぎるのと会話もインタラクティブになりづらかったので中止...＞＜
↑やめた例
皆もきっと話したいことがあるはずだ...と議題持ち寄り制にしてから、何だかんだ議題が絶えず続いています。
- 来季のターゲット説明・共有 byセールス
- DAUが下がっている件に対する打ち手 by CS
- 開発優先度の相談 by Tech＆Design
こういったことをしばしば話し合っています。全員が集まる場だからこそ、それぞれのスペシャリティを持ち寄ってお互いどう動けば目標により近づけるのか、議論を重ねています。
Monthlyのリズム
バーンダウンチャートは1ヶ月で区切ることを目安に引きます。
↑バーンダウンチャート例
ある機能Aを開発するとして、Aを構成する要素を細かく分解し、ユーザーに価値が届く最小単位であるストーリー(A-1, A-2...)に落とし込む。それらをMiroに付箋として列挙する。ここまでをTech(エンジニア)が行ってくれます。
皆でMiroを見ながら、何をどの順に開発すべきか、ストーリー単位で細かく確認し合います。1ヶ月は短い。ある程度強制的に区切ることで、1機能の中でも特に重要なストーリーは何か考えるきっかけになります。
ちなみに1ヶ月で引いたからといって1ヶ月ずっとリリースが無いわけではなく、ユーザーに価値を提供できるものであれば細かくリリースを重ねます。物によっては漸進的に、数日起きに画面に変化が生まれます（これが楽しみでもあります）。
その逆、1ヶ月を超えるようなバーンダウンも時折あります。ここはケースバイケース。
この時、しばしばBiz(フィールドセールス、インサイドセールス、カスタマーサクセス)やDesign(デザイナー)、Tech(エンジニア)それぞれから見える景色には違いがあったりするので、不明点があれば何度も話し合います。
こちらも回を重ねる毎に徐々に皆の景色が揃っていっている感覚があり、プロダクトにとってどの選択が一番良いか？皆で議論している瞬間は、真剣であると同時に、楽しくもあります。
Quarterlyのリズム
3ヶ月に1度、開発優先度決め合宿（と言っても別に泊まったりはしません、ちょっと長めですが普通のMTGです）というものを行っています。これは次の3ヶ月で何に集中的に取り組むかを話し合うMTGです。
これが一番難しい...PdMとしてある種一番の山場なのですが、こちらについてはまだしばらく頭を悩ませそうなので（ずっと続く気もする...）、今回は簡潔に...^^;
数多ある開発候補の中から、プロダクトを成長させるために次のクオーターで何に集中的に取り組むべきか。自身の考えを提示すると共に、皆で議論します。
自分たちで掲げたVisionに近づくため、Visionドリブンな大きな開発を中心に据え、それ以外を小中規模な改善系にあてるという意思決定をすることもあれば
今まで劣後させてきた小中規模改善にとにかく集中的に取り組むという意思決定をすることもあり、クオーターによって様々です。
試行錯誤の真っ只中にあるリズムでもあるので、もう少し持論が持てるようになったらこちらも続編を書きたいと思います。
＊ ＊ ＊
ここまではデザインの話というより会議体(MTG)設計やチーム運営上の話でした。上記リズムの中、どのタイミングでどれだけ・どんなデザインを作っていくのかーーを少し考えていきたいと思います。
コンセプトデザイン
Quarterlyで決めた方針・列挙した開発候補を元に、仕様とUIを作っていきます。この時点で、
- 企業ページに◯◯情報を追加する
- 検索窓を××の方向で改善し見たい企業ページに到達しやすくする
- FORCASと連携しターゲット企業のニュースが見れるようにする
レベル感は様々ですが、上記のように実現したいことは一定明らかになっているので、これらを満たすデザインを考えていきます。
その際、UI Design BookというUIデザインを作る際の拠り所（Uzabase独自に経験知をまとめた資料、随時アップデートしている）があり、そちらと照らし合わせながら仕様とUIを詰めていきます。
例えばUI Design Bookにはこのようなことが書かれています。
上記がクリアできているかを考えながらつくるデザインを、ここでは一旦コンセプトデザインと呼ぶことにします。コンセプトと呼ぶには細かい所まで考えている...気もしますが、とりあえず。
Techと相談しながらより良い実現方法を探り、Bizと相談しながら目的を達成できているかを確認。そうやって具体的な完成イメージをFigmaにまとめ、プロダクトオーナーへの相談も経て、一段落を迎えます。
できあがったイメージをTechに再共有し、改めて詳細見積もりを出してもらいます。
この詳細見積もりの結果がMiroでのストーリーとなり、ストーリーを元にバーンダウンを組み立てます。Quarterlyの方針から始まりUIデザインに落ち、それがMonthlyの具体的な開発計画に落ちていく。そんな流れです。
ディティールデザイン
デザインは、これで終わりではありません。Techによる実装が始まると、進んでみて初めて分かる問題や、改善した方が良い箇所が出てくることがあります。
随時Techが声がけしてくれるので、オンラインで集まって、どうすべきかを一緒に考えます。
個人的な話ですが・・・最近、この時間が一番楽しい。Techとあーでもないこーでもないと議論する時間。
その瞬間は他のことは考えず、細かい所について皆でプロダクトに向き合う・・・その時間がなんとも言えず幸せだったりします。「ものづくりって楽しいな」と思い出させてくれる瞬間でもあります。
＊ ＊ ＊
ふと思ったのですが...デザイナーは、もしかしたら孤独なのかもしれません。多くの現場でそうだと思いますが、プロジェクトにデザイナー1人だけというのはよくあると思います。
またデザインは多少なりとも開発より先行することになるので、Techは別件の実装真っ只中で、その手を止めてしまう事に後ろめたさを感じながら相談に乗ってもらったり...。
そう考えるとこのディティールデザインフェーズにおいては、何の気兼ねもなく一緒にプロダクトの細かい所を話し合うことができる。
デザインを考える際、自分なりに一生懸命考える、上手く形にならない悔しさやしんどさを味わい乗り越えようとしてこそ力はつくと思うので、そのプロセスは必要だと思いますが...
最後まで1人で抱え込む必要もない。困ったり分からないことがあったら誰かを小さく巻き込む（1時間も取る必要はなく、15〜30分で良いので話を聞いてもらう、それだけで一気に進むこともある）。
この動きをコンセプトデザインの段階からもっと積極的にできると良いかもしれません。抱え込みがちな自分への自戒も込めて。
＊ ＊ ＊
やや脱線しましたが、このようにデザインのフェーズも2つに分けて考える...「コンセプトデザイン」「ディティールデザイン」とし、ディティールデザインにも時間や比重にして2〜3割程度を要する・残すという考えに至ってから、頭の整理が少しついた気がします。
おわりに
現時点で考えていることをつらつらと書きました。
「いつも勇気をくれたのは、プロダクトとチームでした」と創業者の梅田さんが昔言っていたようで、時折その言葉を思い出します。
プロダクト開発はまさにチーム戦。リズムをデザインすると題したこのnoteですが、ひとつのリズムをとっても1人で決めることはほぼ無く、誰かと何かしら相談・議論しながら進めています。
個とチームの力が試されるからこそ、自身の考えと共にチームのあり方・リズムのあり方も常にアップデートしていきたいと思います。