他部署からの救い、全社の想いをのせたプロダクトへ
2018年当時、Goodpatchが開発・運用する国産初のプロトタイピングツール「Prott」はグローバル対応と技術的負債を解消するため、フルリニューアルを計画していました。しかし、リリースされることなくリニューアルプロジェクトは終了を迎えます。その後、PO／CTOの離脱や大量離職、売上が上がらない重圧などの壁にぶつかります。苦しい状況でも諦めず、組織エンゲージメントスコアを48から80まで改善。新規事業として立ち上げたオンラインホワイトボードツール「Strap」は、大企業からベンチャーまで多様な企業が導入するまで成長し、2021年9月に1周年を迎えました。
この連載では、開発現場で起こる、あるあるの失敗談を対談形式でお話ししながら、新規プロダクト開発における陥りやすい罠とその善後策をお届けします。現在のStrapプロダクトマネージャー大竹智史が聞き手となり、当時の様子や想いについて、エンジニアリングマネージャーの西山雄也が語ります。
第1回ではメンバーの大量離職など過酷な状況に陥った過程と、その失敗からコラボレーションの重要性に気づくまでを、第2回では信頼が失われた中で開発を進める苦悩や、失敗経験を踏まえチームで取り組んだことをお届けしました。
第3回の今回は、Strap開発の中で変化したチームメンバーの役割や開発の進め方、またStrapを大きく前進させたGoodpatch社内での部署をまたいだ協力についてお届けします。
チームの橋渡しを担うUXエンジニアの存在
大竹：Prottのリニューアルプロジェクト（以下、Prott v2）からの学びを経てスタートしたStrap。しかし、チームにはビジネスサイドがいなかったそうですね。そんな中、この新規事業をどのようにして立ち上げたのですか。
西山：Goodpatchの文化がStrapの短期間での成長に起因していると感じています。
Goodpatchには、早期にプロトタイプを作成しテストする“プロトタイピング文化”があります。Strapチームもこの文化を積極的に取り入れ、エンジニア、デザイナーを中心に“まずは手を動かす”ことでStrapの開発を進めました。
プロトタイピングの中でも僕らは、採用予定の技術を実装し試作する「テクニカルプロトタイピング」という手法を採りました。目に見え、操作できるプロトタイプがあると、実際に使用するシーンがイメージしやすくなります。作成したプロトタイプは、他部署のクライアントワークチームに操作してもらい、ユーザーインタビューを行いながらフィードバックを得ました。そして、得たフィードバックを素早くプロダクトに反映し続けたことが、Strapの成長の加速につながったのだと思います。
大竹：要件定義に数年かけたPrott v2とは、開発の進め方が明確に異なりましたね。今回のプロトタイプドリブンな開発は、チームにどんな影響を与えましたか。
西山：2つの良い影響があったと感じています。
1つ目は、価値検証の段階で“プロダクトが前進している手応え”をチームとして感じられたことです。前回のPrott v2開発では、フィードバックを半年後にしか得られず機能をリリースできない状態が続いたことで、メンバーのモチベーションの降下、離脱につながりました。しかしStrap開発では、小さく早くプロトタイプしフィードバックを得たことで、価値検証のサイクルも早く回りプロダクトの前進を感じながら開発することができました。
また価値検証のサイクルが早く回ることで「どう進むべきか」など大きな方向性の議論や軌道修正もしやすくなりました。ものづくりをする人間にとって、フィードバックは非常に大きな価値となることを、改めて感じましたね。
2つ目は、エンジニアの多様な実装機会によりチームの実装の再現性が高まったことです。第2回でもお話ししましたが、Strapの開発時はシステムの縦割りではなく、ユーザーストーリー単位で担当を分けるという体制を取っていました。そのため、バックエンドエンジニアがUIを実装したり、逆にフロントエンドエンジニアがバックエンドのコードを書いたりすることもありました。この体制とプロトタイプドリブンな開発により、“誰でも実装可能”と言えるほどチームでの再現性が高まりました。
大竹：新規事業をエンジニア、デザイナー起点で進めていくにあたって、チーム内の役割はどのように設計していたのですか。
西山：当時のチーム構成は、エンジニア6人、デザイナー1人、 カスタマーサクセス2人の計9人でした。その中でエンジニア、デザイナーには、価値検証段階から参画し互いにディスカッションを行いながら開発を進めるという役割を担ってもらいました。
前回（Prott v2）と比較しStrapチームの大きな特徴となったのが、エンジニアとデザイナーの橋渡しを担う「UXエンジニア」の存在です[※1]。UXエンジニアは、デザインとエンジニアリング両方の言語を話し、翻訳しながらチームの価値観をつなげていく、とても重要な役割を担っていました。
[※1] 参考：「PO/CTO離脱をエンジニアとデザイナーの共創組織で乗り越える / イベントレポート」（Goodpatch Blog）
大竹：UXエンジニアと一般的なエンジニアの違いを詳しく教えてください。
西山：機能ベースでなく、機能がもたらす価値や役割をベースにプロダクトを構想する点が大きな違いです。UXエンジニアは、実装しつつ価値の定義から検証までの一連のサイクルを回していく役割を担います。そのため、実装可能性の観点も含めて「なぜStrapにこの機能が必要で、どのような価値を提供するのか」というWHYとWHATの解像度を上げていく必要があるのです。
特にStrapは具体的な課題を解決するプロダクトではなく、もっと俯瞰した“プロセス・組織を改善をするプロダクト”として構想しています。細かい機能ではなく「どういった価値があるのか」などグランドデザインを明確にすることを大切にしていました。
そのためStrapチームには、UXエンジニアという、エンジニアリングスキルやシステム思考とともに、要件定義や戦略など上流の価値をベースにプロダクトを構想できる存在が必要不可欠だったのです。
