爆速で価値あるプロダクトをリリースするためのチームビルディング
Posted on
こんにちは。KARTE Blocks（以下Blocks）でデザインエンジニアをしている@tacamyです。
Blocksは、サイトをノーコードで書き換えたり、ユーザーひとりひとりにコンテンツを出しわけて、既存のウェブサイトをパーソナライズできるサービスです。CMSのように運用するコンテンツをあらかじめ決めておく必要もなく、ページ上の好きな箇所を自由に編集できます。
今回は、少人数のチームで高速な開発とリリースをしていくために、Blocks開発チームがこれまでに取り組んできたチームビルディングや開発の手法について紹介します。
この記事は「KARTE Blocksリリースの裏側」という連載の6日目の記事です。これから数日にわたって記事を更新していくため、更新をチェックしたい方は@KARTE_BlocksのTwitterアカウントをフォローしてください！
「KARTE Blocksリリースの裏側」の記事の一覧です。
- KARTE Blocksを支える技術
- インクリメンタルに新しい技術を取り入れる方法
- セカンドパーティコンテンツをもつサードパーティスクリプトの作り方
- AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術
- ユーザーが自ら理解・学習するためのテックタッチなアプローチ
- 爆速で価値あるプロダクトをリリースするためのチームビルディング ← イマココ
- CSS in JSとしてVanilla-Extractを選んだ話と技術選定の記録の残し方
- 0→1のフェーズで複数のユーザー体験をつなぐUIデザインを考える｜wagon｜note
- リリース後に落ちないように、新規サービスで備えておいたこと
- KARTE Blocksにおけるポジショニングの考え方とその狙い
- 「KARTE Blocksリリースの裏側」の裏側 - 複数人で連載記事を書く方法
Blocksのリリースマイルストーン
Blocksは、2019年10月に更地の状態から開発をスタートし、2ヶ月後の2019年12月に社内向けのα版をリリースしました。7ヶ月後の2020年7月にクローズドβ版、その4ヶ月後の2020年11月にオープンβ版をリリースし、その後10ヶ月かけてフリーミアムモデルへと進化し、2021年9月14日に正式リリースしました。
平均すると、半年に1回のペースでメジャーアップデート[1]していることになります。
公式リリース時には6名で構成されていたBlocks開発チームですが、最初から完成されたチームではありませんでした。プロダクトもまた、最初から完成形が見えているわけではありませんでした。
いまもまだ完成しているわけではありませんが、正式リリースという区切りのタイミングで、いまのBlocksチームがどのようにつくられてきたのかを振り返ってみます。
まずは、タックマンモデルになぞってチームの形成を振り返り、次に、開発手法について紹介します。
タックマンモデルでみるBlocksチーム形成の軌跡
タックマンモデルとは、心理学者のタックマンが唱えたチームビルディングにおける5段階プロセスのことです。
このタックマンモデルになぞらえて、チームの立ち上げから現在までを振り返ります。
形成期
発案者のCPOがホワイトボードで手書きしながら、Blocksの構想をデザイナーに伝えるところからのスタートでした。デザイナーは咀嚼したイメージをFigmaのプロトタイプに落とし、二者間でBlocksのコンセプトを揉んでいきます。
しばらくしてエンジニア1名とデザインエンジニア1名が加わり、Blocksチームが発足しました。メンバー全員で集まってプロトタイプを触りながら、機能やUIを検討していきます。並行して、エンジニアはざっくりとしたイメージで裏のデータベース周りと、ロジックやテストの開発を進めていきます。
セグメントによる配信条件の設定と、バナー（画像とリンク）の書き換えと効果計測ができることを必要最小限の機能としてリリースすることに決まり、エンジニアもさらに1名加わった4名体制で本格的に開発に取り組みはじめました。
開発開始から2ヶ月で、サイトに設置して書き換えや計測をするbuilder.jsと、書き換え設定を行う管理画面が動くようになり、社内向けにα版をリリースしました。
混乱期
ひととおり動くようになった段階で、ビジネスメンバーも1名ジョインしました。ユーザーリサーチで需要や要望を聞き出しつつ、プロダクトの仮説検証を繰り返しながらプロダクトの方向性を模索していきました。この時期にエンジニアが1名ジョインしてエンジニア3名体制となり、開発スピードがさらに加速していきます。
ユーザーリサーチの対象は、KARTEの既存クライアントの中で最大規模のクライアントでした。このクライアントをBlocksの導入事例として紹介したかったため、要望に合わせてHTMLの書き換え、CSSやJavaScriptの配信、スケジュール配信機能などを次々に実装していきました。
本来、我々が価値提供したかったのは、エンドユーザーひとりひとりにパーソナライズされたコンテンツが提供され、その結果、クライアントのサイトのコンバージョンがアップするというストーリーでした。しかし、クライアントが価値を感じるのは、キャンペーンなどに合わせてバナーを自動更新できるCMSのようなツールという価値観のズレがありました。
広く面をとるために、単なるコンテンツ編集ツールの方向に倒すのか、自分たちの提供したい価値を押し通すべきか、チームの中でもプロダクトの進むべき方向性に迷いが生じました。ビジネスメンバーや開発メンバーで何度も話し合い、ときにはCEOやCPOも巻き込み議論を繰り返しましたが、なかなか方向性が定らず、同じ議論を何度も繰り返していました。
その間も、追加機能の開発やUIの改善など、開発の手は止めることなく進めていました。
統一期
チームにプロダクトマネージャーが加わり、Blocksの方向性を繰り返し議論していく中で、ブロックマネージメントシステム（BMS）という概念が生まれました。これは、サイトをブロック単位に分解し、ブロック単位で分析運用を行っていくという、今までのサイト運用になかった新しい考え方でした。また、これまでは”Rewrite”だったサービス名も、この考え方にあわせて”Blocks”へと変わりました。
BMSとノーコードをキーワードとして、Blocksのコンセプトをランディングページで公開したところ、想像以上に反響があり、これはイケるという思いがチームに浸透し、方向性が明確になりました。
ただしこの時点では、ランディングページに書かれている内容は理想形であり、実際のプロダクトの機能はまったく追いついていない状態でした。そこで、ランディングページに合わせてプロダクトを開発していくという、ランディングページ駆動開発がはじまりました。
新しい機能の開発や既存機能の改善をするときには、BMSというコンセプトに沿っているか？という指針にあてはめて判断できるようになったので、以前よりも迷いが生じづらくなりました。
機能期
エンジニアがさらに1名増え、セキュリティ面の強化やリスクヘッジなども行い、プロダクトとしての信頼性を高めていく段階になりました。また、ノーコードでの書き換えやブロック単位での効果検証も行えるようになり、ランディングページの世界観にだんだんと近づいてきました。
クライアント対応をするビジネスメンバーも増え、マーケティングのメンバーも正式リリースに向けてジョインすることで、チームメンバーの比率は、ビジネスチームと開発チームで半々くらいになりました。
ビジネスメンバーと開発メンバーとのコミュニケーションも密に行い、開発メンバーもクライアントフィードバックの場に直接参加するなどユーザーの生の声を聞き、取り入れるべき意見は取り入れ、プロダクトに反映していきました。
また、既存のKARTEのように、セールスがプロダクトを売るSLG（Sales-Led Growth）から、プロダクトでプロダクトを売るPLG（Product-Led Growth）に戦略を切り替えるための開発も進めていきました。KARTEと切り離して単体提供できるようにしたり、サインアップ周りの開発を他のチームと一緒に行ったり、ユーザーが自ら理解・学習するためのテックタッチを強化したりと、正式リリースに向けてプロダクトをブラッシュアップしていき2021年9月14日に晴れて正式リリースできました。
散会期
Blocksはまだ正式リリースしたばかりで、目的の達成には程遠いため、このステージにはまだ至っていません。
さらに、リリース後のタイミングで20代前半のメンバーが数名増え、チームも若返ってリフレッシュされました。ここからまた新生Blocksチームとして進んでいくはずなので、Blocksの散会期はまだまだ先になりそうです。
ここまでのまとめ
タックマンモデルでは、チーム作りにおいて重要なことは、混乱期を避けずにいかに早く通過し、統一していくかであると述べられています。
Blocksチームでは、プロダクトのコンセプトをBMSという言葉で表現し、ランディングページのコンセプトムービーでプロダクトの目指す世界を見える化したことで、ビジョンを明確にしました。また、キックオフやオフサイトも実施し、ビジョンの浸透にも取り組んできました。
ビジョンを明確化することにより、自分のチームのすべきことが明確になり、ひとりひとりの判断に大きなずれは生まれにくくなりました。チームメンバーをお互いを信頼して任せられるようになり、自分のすべきことに集中していても、チーム全体としてプロダクトを進捗させられるようになりつつあります。
小さな機能単位では、個々の理想形に微妙なズレも生じます。そのため、混乱期 → 統一期 → 機能期は、小さな規模で何度か繰り返されます。この微妙なズレをどのように乗り越えてきたのか、Blocksチームで実践してきたチームビルディングについて紹介します。
チームビルディングの実践
チームビルディングとは、個々のパフォーマンスを最大限に発揮できる環境づくりです。ここからは、Blocksチームのマインドセットの形成や、モチベーション向上に影響があったと思われることを、具体的に紹介していきます。
Whyの追求
プロダクトのあるべき姿や本質は、特定の誰かが考えたものを浸透するのではなく、メンバー全員で考え抜いて自分たちで導き出します。ビジョンを浸透させるというよりも、自分たちでビジョンをつくっていくという方が近いかもしれません。
そのため、プロダクトの初期フェーズや新機能を検討する段階では、ミーティングの機会はかなり多くなります。ときには社内外でオフサイトを実施し、一日中プロダクトについて議論することもあります。時間をかけてでもここをしっかりとやっておくことで、実装段階に入ってからの手戻りも少なくなり、結果リリースまでの時間も短くなると考えています。
KPTでの振り返りと改善
KPTとは、ふりかえりによりプロジェクトの改善を加速させるフレームワークです。Keep（続けるべきこと）、Problem（抱えている問題）、Try（次にトライしたいこと）の3つで現状を分析します。
BlocksチームでのKPTの実践方法は、まず各自が付箋にKeepとProblemを書いてホワイトボードに貼り出します。次に、ひとりずつ前に出て軽く説明していき、似ているものをグルーピングしていきます。そして、Problemから、次にどうすべきかをみんなで考えて、Tryを導き出します。
KPTは、2〜3ヶ月の開発サイクルの区切りのキックオフのタイミングで行うことが多く、コロナでリモートワークになってからも、Zoomで繋ぎながらmiroの付箋UIにて代用できました。
雑談を増やす
プレイドでは、職種ごとで席を固めるのではなく、チーム単位で島をつくって集まって作業しています。そうすることで、相談や雑談などのコミュニケーションが自然発生する環境となります。雑談からアイデアが生まれたり、相互理解から信頼関係が生まれたりもするため、雑談はチームビルディングに重要な要素のひとつだと考えています。
ところが、コロナでリモートワークになってからは、雑談が難しくなりました。discordなども最初は入ってみるものの、だんだん集まる人が減ってきて定着しませんでした。定例で雑談タイムを設けてみたこともありますが、雑談のために作業を中断するコストが高く優先度が下がってしまったり、人が多いと発言のタイミングが被ったりしてやりづらくもありました。
その点、非同期のコミュニケーションは負担が少なく、チームのSlackチャンネルには仕事と関係ない写真や話題がたびたび投稿されます。有休中のメンバーが旅行先の写真をリアルタイムで流したり、エンジニアが手作りしたお菓子の写真が投稿されたり、家庭菜園の野菜の成長記録が流れてきたりして、そこからスレッドで会話が広がるといった具合です。
それでもやはりオフラインでのコミュニケーションに代わるものにはならなかったため、コロナの感染者数が落ち着いてきたタイミングで、週に1回ほど出社推奨日を設けたりもしています[2]。
衝突意見も否定しない
たとえビジョンを共有できていても、意見が衝突することはあります。そういった場合でも、反対意見を臆することなく言える環境であることが大切だと考えています。
不満をため込んで、納得しないまま実装を進めることになれば、当然パフォーマンスも下がります。声をあげてくれることで、1on1で個別に話したり、原因を深掘りして解決すべき課題を明確にして対処していくこともできます。
また、自分から声を上げづらいタイプの人もいるため、定期的な1on1も行われています。
チームビルディングのまとめ
チーム内でかっちりとした決め事をしなくても物事を前に進められるのは、一緒に働くチームメンバー同士の信用や信頼で成り立っている部分が大きいと感じます。そのためにも、お互いを理解するためにかけるコストというのは、プロダクトには直接的に関係ないことだとしても、チームづくりには必要なことだと考えます。
爆速でリリースするための開発手法
ここまでは、ビジョンを浸透し、チームの認識を合わせるために実践したことについて紹介しました。しかし、認識を合わせたものが必ずしも正解であるとは限りません。開発したものをリリースして、ユーザーに使ってみてもらわないと実際の問題が分からないこともあります。
そのためBlocksチームでは、リリースして触って試してみるサイクルを、スピード感をもって回すことが重要だと考えています。ここからは、高速な開発とリリースを実践するために、Blocksチームが具体的にどのような方法で開発を進めてきたかを紹介します。
壊すことを前提につくる
プレイドには、「常にゼロベースで考えて進む」という文化があります。少しでも前進するのであれば、プロダクトを躊躇なく壊すことを推奨しており、いま書いているコードが数ヶ月後にはまったく違うものに置き換わっているということも普通にあります。
まだ世にない価値を生み出すためには、仮説検証のサイクルを回して改善を繰り返す必要があります。
実際に、Blocksも最初はバナー更新ツールで画像の書き換えがメインだったのですが、実際にリリースしてみたところHTMLを編集したいという要望が大きく、改善を繰り返していくうちに今ではノーコードエディターとなっています。
このような文化であるため、綿密な計画を立ててきっちり時間をかけてつくったとしても、無駄になってしまう可能性があります。また、よりよい方針が浮かぶことでの仕様変更があった場合に、壊して作り直すことに躊躇してしまうことを避けるためにも、はじめから壊すことを前提としてつくっています。
MVPで出す
細かい粒度でリリースし、反応を見ながら開発を進めていくために、MVPでリリースするようにしています。MVPとは、Minimum Viable Productの略語で、実用最小限の製品という意味です。
とはいえ、最初から小さく考えてしまうとプロダクトの思想まで小さくなってしまうので、まず最初はプロダクトや機能の理想形についてチームでとことん話し合います。それを元にデザイナーが理想をすべて詰め込んだ状態のデザインのプロトタイプを作成して、イメージを共通化します。
そこを理想形として、価値提供を損なわない範囲で機能を削ぎ落としていき、まずは最短でのリリースを最優先とします。削ぎ落とされた機能は、あとから実装するタスクとして詰んでおきます。そのままになることもありますし、機能を強化する必要があると判断すれば、追って実装されることもあります。
たとえば、Blocksの最初の社内リリース時には、管理画面で設定したコンテンツがサイトに即配信されていました。また、CSSセレクタの指定もChromeのDevToolsを使ってもらう前提でミニマムでつくりました。社内検証を進めていく中で、やはり配信前のプレビュー機能とCSSセレクタの選択UIも必要ということになり、Blocks専用のChrome拡張機能をつくってリリースしました。
また、以前ブロックパフォーマンスというブロック計測機能をリリースしたのですが、ユーザーにうまく活用されていなかったり、ブロック管理の複雑化に繋がってしまったため、ブロックパフォーマンスは消滅しました。
素早くリリースすれば、ユーザーの反応を早い段階で得られるため、方向性が間違っていたらすぐに路線変更できます。方向性が正しければ、追加機能を追ってリリースすればよいだけなので、どちらにしても小さく早く出すことが重要だと考えています。
チーム内チームをつくる
プレイドでは、プロダクトの仕様や技術選定などもすべて各チームに任せられるため、チーム内で決断すべきことが多くなります。
Blocksチームの初期は小さなことも全員で話し合って決めていたのですが、決断の場にいる人数が増えるほど議論はまとまらなくなるため、開発メンバーが増えたいま、細かい仕様まですべてを全員で決めようとすると時間がかかってしまいます。そのため現在は、Blocksチームの中にさらに機能単位で小さいチームをつくって、決断はそのチーム内で行うようにしています。
ただ、チーム全体での情報共有も必要なので定期的にミーティングを行っています。現在は、開発チームのミーティングが週2回、ビジネスメンバーも含めたBlocks全体のミーティングが週1回あり、報告や相談はそこで行っています。
メンバーの役割を職種で分断しない
プレイドでは職種による細かな役割の分断はしておらず、チーム内で個人の力を最大限に活用できるように模索しながら開発に取り組んでいます。領域が重なったり足りない部分は、互いに調整しあって開発を行なっています。参考までに、Blocksチーム内では次のような役割で進めています。
エンジニア
プレイドのエンジニアは、バックエンドからフロントエンドまでの全体をやれる人がほとんどです。その中でも、インフラ、バックエンド、フロントエンド、セキュリティなど個々で得意な領域は変わります。
エディター機能や分析機能など、機能単位でその技術に興味を持っているメンバーが開発を担当したり、issue単位では、その領域が得意なメンバーが担当したりして進めています。
デザイナー
プレイドのデザイナーは、UIをデザインするだけでなく、もっと抽象度の高い部分からプロダクトを俯瞰してとらえています。UXリサーチを実施したり、クライアントフィードバックにも積極的に参加したりしながら、ユーザーの思考や行動に仮説を立て、プロダクトのユーザー体験を設計していきます。
そこから、具体のUIをFigmaに落としていき、チーム内で意図を共有し、UIを作り込んでいきます。デザイナーが何をどう考えてプロダクトを設計しているのかについては、次回の記事で触れていきます。
デザインエンジニア
デザイナーともエンジニアとも領域が重なるため、両者とコミュニケーションを密にとりながら、デザイナーの考えるユーザー体験の世界と、エンジニアの考えるパフォーマンスを考慮した機能実装との間で、UIの最終的なアウトプットに対する責務を持っています。
具体的には、UIのブラッシュアップと実装、フロントエンドの機能実装、UIの統一、実装に合わせたUIの調整などをしています。デザイナーが高い視座からプロダクト全体のUXやUIを考えているのに対し、デザインエンジニアはUIのミクロの部分に責任を持ち、プロダクトのクオリティを上げていくというような役割分担をしています。
開発フローを柔軟に変えられる体制
フロントエンドの実装においては、エンジニアとデザインエンジニアとで領域が被るのですが、メンバーのリソース状況やエンジニアの得意領域によって、その都度進めやすいやり方で調整しています。たとえば、APIだけ用意してフロント実装は完全にデザインエンジニアに任せたり、スタイルなしの状態でフロントを実装しておいたり、デザインエンジニアのリソースが埋まっている場合はCSSまで含めてエンジニアが実装したりといった具合です。
UIデザインにおいても、デザイナーとデザインエンジニアとで領域が被るため、実装する上で足りない機能のデザインや状態変化のスタイルなどの細かい部分は、デザインエンジニアが吸収してデザインを調整していきます。デザインが確定してからそれに沿って実装を進めていくのが基本的なスタイルですが、デザイナーのリソースが埋まっている場合は、実装を先行して進めてあとからUIを調整することもあります。細かいデザイン調整を都度デザイナーに相談しているとデザイナーのリソースを消費してしまうため、その部分は任せてもらうことで、デザイナーはマクロの視点でプロダクトの体験を考えることに集中できます。
このように、お互いの領域に踏み込んで柔軟に対応しているので、他の人がボトルネックになって待ち時間が発生するという無駄がありません。
デザイナーも本番デプロイする
フロントエンドのバグやUI実装をすばやく反映するために、デザイナー（デザインエンジニア）もKubernetesで動く本番環境へデプロイしています。
コマンドだけでデプロイできるように整備されているため、ターミナルでコマンドを叩いて自動生成されたプルリクエストをマージするだけで本番へデプロイできるようになっています。もし失敗しても、プルリクエストをリバートすればロールバックできます。
これによって、エンジニアの手が空くタイミングを待ってデプロイをお願いするという待ちの時間がなくなり、すばやくプロダクトに実装を反映できるようになりました。
デザイナーでもデプロイできる仕組みについては「KARTE Blocksを支える技術」を参照してください。
デザインは構想段階で共有
まれに、デザインが完成した状態になるまで、他の人に見せたくないというデザイナーの話を聞きますが、Blocksのデザイナーは手書きの状態であってもどんどん共有してくれます。
構想の段階で共有してもらうことで、もし方向性が違っていたとしても手戻りが少なくすみます。また、大まかなイメージをはやめに共有してもらえるため、エンジニアがそれを元に裏側の開発を先行して進められるというメリットもあります。
適度な相互レビュー
プルリクエストのレビューは、どんな変更でもレビュー必須というルールにはしていません。たとえば、機能実装の場合はエンジニアが相互にレビューしていますが、UIの変更のみでインシデントにはつながらないと分かっている場合は、セルフマージしてデプロイしています。
ただし、プルリクエストにはチームメンションをつけるルールにはなっているため、レビューの強制ではないものの、結構目を通してもらっています。改善すべき箇所があるときはコメントをもらえるため、セルフマージ後にはなりますが、修正対応します。また、不安がある場合には、個別にレビューを依頼をして見てもらっています。
レビューだけではすべてのリスクを取り除くのは難しいため、定常的なモニタリングによって保証している部分もあります。Blocksのリスクヘッジについての詳細は「AWSが落ちてもGCPに逃がすことで落ちないシステムを作る技術」で紹介しています。
社内ドッグフーディングによる品質テストと改善
新しい機能がとりあえず触れる状態になったら、まずは社内向けにリリースし、自分たちで触ってみることでバグが見つかったり、使い勝手のフィードバックが得られます。早い段階で問題を見つけることができれば、リリース前に対処もできますし、プロダクトの仕上がり具合によってはリリース日を調整するなどの対応も早い段階で判断ができます。
ドッグフーディングについては、「ユーザーとしての感覚がKARTEを進化させる。社内外のプロダクトを使い倒すドッグフーディング文化」で詳しく紹介しています。
最後に
Blocksはとてもよいチームではあるのですが、我々の目的は最高のチームをつくることではなく、価値あるプロダクトを提供して、クライアントとその先にいるエンドユーザーの体験をよくしていくことです。
Blocksのプロダクトは、まだその領域には到達できていないため、一緒にプロダクトを成長させていってくれるエンジニア、デザイナー、デザインエンジニアを募集しています。もし興味を持っていただけたら、お気軽にコンタクトしてください。
詳しくは弊社エンジニア採用ページや採用スライドをご覧ください。