Chatworkでの開発プロジェクトの種類
Chatworkのプロダクト開発は、大きく2つのタイプに分類されます。開発期間が1カ月以上かかり、プロダクトマネージャーと複数のエンジニアやデザイナーがプロジェクトチームを形成して実施される「ロードマッププロジェクト」と、プロジェクト化されることなくスプリントの中で1～3週間ほどの開発期間で完了する「小さなカイゼン」です。
「ロードマッププロジェクト」は、期初に定められたプロダクトロードマップに乗っているプロジェクトであり、非常に特別で、何よりも優先されるものとなっています。もし開発内容に変更があったり、期間が大幅に延期になったりすることがあれば、役員承認が必要となります。
一方で、プロダクトロードマップに乗っていない「小さなカイゼン」は、ユーザー要望や社内からのフィードバックの中で、ロードマップには乗らないものの、ユーザー体験やアクティブ化率・有料化率の改善につながる施策を、プロダクトマネージャーがリソース状況を鑑みながら実施するものとなります。
ところが、ユーザー数が増加し、セールスチームによる新たな販売網が構築され始めると、より多くの機能要望が届くようになり、ロードマップとして取り組むべきプロジェクトの数や規模が大きくなっていった結果、小さなカイゼンにあたる要望を受けても、全く着手できない状況に陥ってしまいました。
そこで、ロードマッププロジェクトを推進しながら、小さなカイゼンを継続的に行うための仕組み作りにトライしてきました。
プロダクト価値につなげるUX負債の返済
そもそも、なぜ小さなカイゼンを行う必要があるのでしょうか？
Chatworkでは、継続的な小さなカイゼンを通して「UX負債」（UX Debt）を返済していくことが、プロダクト価値を安定させるのに非常に重要だと考えています。
リリースを優先した結果、将来的なサービスの安定提供が難しくなる技術負債が生まれるように、デザインやユーザー体験においても負債が生まれ、それがUX負債となります。UX負債は主に、今提供しているプロダクトの機能性や品質と、ユーザーが理想とする機能性や品質との間に生じたギャップだと考えられており、徐々にそのギャップが広がっていきます。
UX負債が生まれる要因は、大きく以下の3つがあると考えています。
- 初期の機能スコープによるもの
- ユーザーの緩やかなニーズ変化によるもの
- サービスへの期待値変化によるもの
最初から理想的な形でリリースできることはほとんどありません。新しい機能を開発する際は、リソースや予算、他のプロジェクトとのスケジュール調整など、さまざまな外部要因を踏まえて初期スコープを定義し、その時点で最大限の機能性や品質で提供します。そのため、リリース時点で一定の負債を許容している状態です。そして、その後も会社を取り巻く環境の変化に伴って、ユーザーのニーズや期待値が変化することで、ユーザーが理想とする品質と、提供している品質とのギャップが拡大していきます。
例えば、Chatworkにはグループチャットの全員に通知を送る「To ALL」という機能がありますが、初期は「グループチャット内のすべての人に通知を送りたい」という要望が非常に多くあり、その要望に応える形で開発しました。しかし、To ALLの利用頻度が増えると、今度は「そこまで重要ではないメッセージまで全員に通知を送られると困る」という新たな課題が生まれました。
こうして発生したUX負債は、少しずつ蓄積することから、一時的なデータからは課題が発見しづらかったり、直接的に事業数値にひも付かなかったりする改善も多く、優先順位を上げにくい傾向にあります。
しかし、ユーザーの期待値とのギャップが大きくなりすぎると、解約や、他サービスへの乗り換えにつながる可能性があります。そのため、Chatworkでは機能表に◯を付けるような開発だけでなく、小さなカイゼンを継続的に行うことが重要と考え、そのための仕組み作りにトライしてきました。
