alma の Product Research チームの @yokinist です！普段はプロダクト戦略とリリースの乖離を検証しながらロードマップをつくる役割を担っています。さて、今回は alma の新規プロダクトである Cocoda Board が今までに比べ格段にリリースまで「スピーディかつ、手戻りなく進める」ことができたので、その背景にフォーカスをあてていきます。大きな鍵は「職種や領域の垣根を越えた共通言語をそれぞれ作ること」でした。振り返りながら、具体的にどのようなことを意識し取り組んでいたか赤裸々に紹介していきます🙌
Product Research チーム など alma の組織体制についてはこちらが詳しい：
自分は Cocoda Board の開発時には、PO と開発チームの橋渡し役として全力で開発に向き合えるような環境を整える役割、そしてフロントエンドの実装に関わっていました。
ちなみに：Cocoda Board とは alma が提供しているユーザーの行動・課題・施策アイデアを分かりやすく整理し、チーム全員の納得感を生みながら確信度の高い設計を行えるプロダクト体験管理ツールです。詳しくはこちらのプレスリリースから👇
https://prtimes.jp/main/html/rd/p/000000012.000037235.html
実装とUIデザイン間の認識のズレをなくすために
当たり前のようにも思えますが、デザインをガッツリと完成してから実装を始めるとなると、とても時間がかかってしまいます...。限られたリソースと限られたスケジュールでリリースするために、Cocoda Board の開発時にはデザインのUI作り込みと実装は同時並行で進めていました！どのようにして、同時並行のワークフローを実現していたのか紹介していきたいと思います。
同時並行ワークフローでは「スピードが出る」「手戻りが少ない」という大きく2つのメリットがありました！それまではデザインを作った後に実装上で論点となりうるものが出てきて、すり合わせてデザインを作り直すといったことが度々起きてしまっていました🥲
使ったツールは Figma、そして Tailwind CSS / UIです！
UI を磨き込む前に、まず簡易な情報設計図を Figma で整理しました。UI デザインもリードする @greatest_hiroki がプロトタイプをもとに情報構成レベルで図式化してくれました。一目で全体像を理解でき、リアルタイムで更新できるのはとても便利でした💡
一気に解像度があがり、それをもとに実装上の論点や潰しておくべきポイントを見極めコミュニケーションをとりながら認識を揃えていくことができました！横にそこで話したことなどメモを残しています。
また、特に走り出した新規プロダクトの開発では検証をしないといけない機能も複数あり、どこまでが確度高く開発を進めていいものかが分かりづらく混同してしまいます。そこで、「未検証でまだ確定していない部分」を半透明にすることで明示的に表現していました(※ 実際に新規開発時に使っていた6月時点のものなので情報は最新ではありません)。
Tailwind CSS はフロントエンドのスタイリングで採用した技術でした。初速を出したかったので、Tailwind UI という公式のテンプレートを購入しデザインデータも合わせて活用しました。早めの段階で導入の意思決定をしたため、とにかく作って壊して作り直すことが求められるプロトタイピングでも役に立ちました！
UIデザインをする上でも0からつくるのではなく、Tailwind UI にテンプレートとして使えそうなコンポーネントがあればファイルを拾ってきて拡張やカスタマイズする方針を取っていました。Tailwind CSS が良いのは、柔軟に組み合わせることができるので自由度が高いことと、値や命名の制約を設けることで余計なことに迷わないことでした✅
β版として運用し続ける開発スタイルガイドで迷わないように
実装の仕方は無限のようにあります！人によって書き方や実装の仕方が大きく異なると、特定の箇所を特定の人しか運用できないようになってしまいます...😭
そこで、「こんな時は、どのような書き方を推奨するのか」「それはなぜなのか」といったものを迷う度にメモに残し、スタイルガイドとしていました。迷ったことがあれば、すぐ Slack などで相談をして、チームとして認識を揃えることで、レビューする観点も明確になりとても役に立ちました！（ちなみに、GitHub レポジトリの README.md に最初は書いていたんですが、リアルタイムに書き込め・参照できる Notion に軍配が上がり移行しました）
トグルの中に内容がはいっていて、クリックすると開きます
スキーマ駆動開発でバックエンドとフロントエンドを円滑に繋ぐ
バックエンド・フロントエンドの連携についての方針は「作業の依存は極力なくしつつ、共通箇所はあえて依存させてしまうこと」でした。領域を分け隔てなく開発することも多いのですが、土台からしっかり作っていくことが求められたり、作業の依存が多かったりとで得意な領域に集中するような分担で進めていました💻
結論からいうと、「スキーマ駆動開発」を今回初の試みで取り入れてみて「めちゃ良かった」という話です。スキーマ駆動開発とは、スキーマ(データの構造)をはじめに定義し、API開発者(バックエンドの開発者)と利用者(フロントエンドの開発者)が定義されたスキーマを中心に開発を進めていくことです。
導入した効果として、大きく3つのメリットがありました。それは、バックエンドの実装を待たずしてフロントエンドの実装ができるようになったこと。型の信頼性と安全性が向上したこと、型定義の二度手間が省けたことでした！
(せっかくなのでちょっと技術寄りな話もこちらに：スキーマの定義は先ほどの Figma でつくった情報設計図をもとにして Stoplight Studio という GUI エディタで OpenAPI を実装前にバーンと全部記述してしまいました。バックエンドではスキーマファイルと実装の乖離がないか committee でテストを行っていました。フロントエンドでは、prism を用いてスキーマファイルからモックサーバーを動かしつつ、aspida を用いて生成した型付きの HTTP クライアントで全てのリクエストを記述していました。OpenAPI 周辺の OSS コミュニティには感謝の気持ちでいっぱいです....🙇♂️)
まとめタイム！
さて、長々と書いてしまいましたが、まとめにはいっていきます📝
今回の新規開発では、デザインから実装までスピーディーかつ手戻りなりを少なく抑えることが、職種や領域の垣根を越えた共通言語をそれぞれ作ることにより実現することができました。頭が揃っている状態でチームで仕事をしていると、華麗なパス回しをしながらゴールに向かっているみたいな感覚でお互いに気持ちよく働けます。
...とは言っても、既に運用上の課題もいくつか出てきているのも事実です。ベストプラクティスだと盲信せず、これからも組織や事業のフェーズに合わせて柔軟にコミュニケーションの取り方や共通言語の作り方など見直していきたいと思います💪
少しでも、コミュニケーションの取り方や連携の仕方について参考になると嬉しいです！
全体像を整理するとこのような形になります：
ロードマップの話やプロダクトの Why 部分をメンバーとどのように認識を揃えたかなど、書き足りないこともたくさんありますが、日が暮れてしまうので今日はここらへんで失礼します！他にもたくさんのデザインケースをこれからも発信していくのでチームのページ是非、チェックしてみてください！ありがとうございました🙏
