24万ものユーザーを抱える (*1) 日程調整サービス「Spir」。この1年間、rootはSpirの新機能開発や、UIリニューアル、開発チーム全体の体制づくりを支援してきました。
rootが関わり出した時、Spirにはフルコミットのデザイナーはおらず、業務委託のデザイナーが複数で役割を分担して関わっているような状態でした。
そこから、開発チーム全体のコミュニケーションフローを改善し、チームが協業しやすい体制づくりを行います。結果、リリース数も増加し、新たにプロダクトマネージャーやプロダクトデザイナーが入社しました。
事業フェーズが進む中で、開発チームの体制が整えられていない時の対応として参考になればと思い、背景についてまとめていきます。
日程調整ツール「Spir」は、2020年に提供開始され、今では24万ユーザーを超える方にご利用いただいています。
親しみやすいUI/UXを特徴としており、創業者の大山さんを中心にユーザーリサーチもかなり積極的に行っています。開発チームには歴が長いメンバーが多く、体制的にも拡大してきています。
ただ、当時Spirの開発チームでは「アジャイルな開発プロセスが取れていない」という悩みがありました。
rootが関わり出したのは、SpirのCTOの方からの相談がきっかけです。
話を聞くと、日々ユーザーリサーチや開発の議論は盛んに起こっているものの、2〜3ヶ月経っても何もリリースできていないようなことが起こってしまっているようでした。
CTOの方は経験豊富で、以前の組織でもアジャイルな開発体制をつくってきた知見があるため、同じようにアジャイルな開発プロセスを取り入れようとしてもなぜかうまく回らないと悩んでいました。
同時期に、これまでSpirにいた業務委託のデザイナーが契約満了となったり他の業務委託のデザイナーと体制を作っていく機運も高まったこともありrootを頼ってくれました。
rootから私がデザイナーとして関わりはじめ、開発チームの状況を観察してみると、建設的な会話が起こっている他社の開発組織と比べて、コミュニケーションに問題がありそうなことがわかりました。
代表の大山さんのドメイン理解が非常に高く、プロダクト設計に対して頼りになる存在であること。また、フルリモートの組織なことも影響して、開発チーム主体でのコミュニケーション量が少なくなっているように感じていました。
開発チーム内での会話は、目先の業務に関するものが多くなり、思っていることを気軽に言えたり、自然と振り返ったりすることが起こっていませんでした。
まずはrootが関わっていた新機能開発チームを対象として、コミュニケーションプロセスを改善していくことに取り組み始めます。
主に、3つの改善を行いました。
デザインのマスターデータを整備
アジャイルのフローを取り入れる
行動ではなく、感情ベースでの振り返り
Spirでは、これまで業務委託のデザイナーが複数で役割を分担して関わっているような状態だったため、デザインのマスターデータを用意することができていませんでした。
すでに実装されている画面でも、デザインデータがないものもあり、コンポーネントも揃っていないので、エンジニア側で直接実装してしまうことも時たま起こっていました。
このような状況が続けば、毎回デザインデータがあるのか確認する工数も発生しますし、プロトタイピングも行いづらく共通認識も生まれません。そもそも適切なコミュニケーションを取れるような状態にしていく必要がありました。
そこで、デザインのマスターデータを整備するところから始めていきます。すでにリリースされているすべての画面のスクショを撮ってきて、対応するコンポーネントを用意できているか精査しました。
全部一気にデザインデータを揃えるのは負担なので、タスクが起こったらそれに該当するページのデザインデータを徐々につくっていくような運用で進めています。
マスターデータができたことで、プロトタイピングを行いやすくなり、デザイナーがUIをつくる途中からエンジニア側に実装観点でのレビューを受けることもできるようになりました。
さらに、ちょうどUIを刷新しようというタイミングだったので、それに合わせてコンポーネントも刷新していくことも並行して進めていきました。
さらに、議論だけでプロジェクトが前に進まない状態から、1週間ごとに前進している状態にしていくことを目指してアジャイルな開発フローを導入していきました。
とはいえ、外から入ってきた人がいきなり開発フローを変えようと言っても信頼されないので、関係値を築きながら進める必要があると考え、全員と1on1することから始めました。
その後、自分がまずはフローをえいやで引いてみます。ここでは、丁寧に位置付けを共有することにこだわりました。
まず「このフローは暫定のもの。絶対不具合が起こるので、回しながら変えていこう」ということを明示します。
さらに、プランニング、Standup、測定、という一つ一つの機会の意図や位置付けも丁寧に説明していきました。
フローを形だけ取り入れても、結局メンバーが前のめりになってくれないと行動は変わりません。「ふーん」とだけ思われないよう、丁寧にコミュニケーションを試みています。
プロセスの中でも、振り返りの設計には特にこだわりました。
最初の半年は、行動に対する振り返りが中心でした。
一般的なKPTのフォーマットでは、Problemの箇所で建設的な議論が起こりづらいかなと思っていたので、事実ベースで行動を振り返ることができる「Start/Stop/Continue」というフレームワークを使います。
プロダクト開発の生産性を上げるために「〇〇をやろう。そのためにやめることはXXで続けることは△△」という流れで、週次で振り返りを行っていきました。
加えて、「Thanksカード」という感謝を伝え合うコーナーも用意していました。そこでは前向きに意見を言う行動が多く見られ、行動だけでなく、感情的な振り返りも有効そうであることを確かめていきます。
さらにその後、フルリモート組織であるSpirにとって、よりベストな振り返り手法があるのではないかと模索していきます。
後半の半年では、行動や業務ではなく、些細なことも含め言い合えるよう、感情の振り返りをする場と変えてみました。
「独り言だと思って、誰かを責めるのではなく話し合っていきましょう」というメッセージとともに、「喜怒哀楽」や「大事にしたいこと」を言語化していきます。
このような1年間の振り返りの改善を経て、徐々にチームとしても忌憚なく意見が言い合えるようになっていきました。
結果として、チームで面と向かって会話することが起こるようになりました。
イテレーションを回すことで前に進む感覚が生まれ、長くいたメンバーも心が開いてチームとしてもやりやすくなったと言ってくれています。
さらに、その効果として機能のリリース数も増えました。UIリニューアルも終わり、それに伴う開発もうまく進められるようになっています。
そして、開発組織の環境を整えられたことが影響してか、プロダクトマネージャーやプロダクトデザイナーの入社も起こり、Spirの組織は次のフェーズに進みつつあります。
私は、組織のトラブルのほとんどは「コミュニケーション」が原因だと考えています。
以前のSpirのように、強力なメンバーが揃っていて事業としても伸びているのに、うまく開発プロセスを整えられない場合は、何らか共通の価値観や考えを持つことができていないということが多く
そこで無理にプロセスだけを浸透させようとしても、かえって逆効果で、メンバーの不満にもつながってしまいます。
今回は、「Spirの開発とはこういうものだよね」という、いわばバリューをつくるところから始めたことで、うまく組織に所属するそれぞれのメンバーの行動が変わっていきました。
rootとして、このような組織づくりの課題を抱えるチームに伴走していくことを今後も続けていくので、ぜひご相談いただければと思います。