SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Chatworkのプロダクトマネジメントに学ぼう

UX負債をためない! プロダクトの「小さなカイゼン」を継続するための3つのポイント

Chatworkのプロダクトマネジメントに学ぼう 第4回

小さなカイゼンを推進するための3つの要素

 当たり前ではありますが、小さなカイゼンを適切に進めていくためには、「体制」「プロセス」「ゴール」の3要素を満たすことが重要です。

  • 体制:兼務ではなく、小さなカイゼンを行うことを責務とするチーム
  • プロセス:改善の種を企画にし、意思決定し、開発を推進するプロセス
  • ゴール:小さなカイゼンをすることで、会社として達成したいゴール

 こうして言語化すると、欠けるはずがない要素に思えますが、過去の取り組みを振り返ると、1つ以上の要素が欠けているケースが多く発生していました。

 例えば、「体制」が欠けるケースです。前回の記事で紹介した「Quick PRD」の仕組み作りにおいても、最初は「体制」を見落としてしまいました。誰もが、簡単に起案できるフォーマット「Quick PRD」と、起案するプロセスやルールの整備を行い、起案から開発までのスピードが上がったかのように見えました。しかし実は「体制」が欠けていることに気づいておらず、起案だけがたまっていく状況になってしまいました。逆に、プロセスやゴールが明確でないことで、体制が形骸化してしまった〇〇委員会や××チームなども多く存在します。それらの多くの失敗を経てやっと、これら3つを満たす仕組みを作ることができたのが、「グロースエンジニアリング部」というチームでした。

専任の体制を作る

 「小さなカイゼン」が進められなくなったときに、過去の取り組みの課題と原因の整理をしたところ、すべての課題に共通する原因が「片手間問題」でした。いわゆるGoogle社の20%ルールに倣って、各エンジニアの一部リソースを小さなカイゼンに当てるような取り組みをしていましたが、そもそも人員の限られている環境において、それらは軒並み失敗しました。また、次に大きな課題となっていたのが「評価問題」です。開発本部など大きな枠組みでの組織においては、ロードマップの達成や技術的課題の解決などが目標に設定されるため、小さなカイゼンを積極的に行っても、評価されにくい状況にありました。

 そこで、開発本部から切り離し、独立したプロダクトマネージャー専属の開発チーム「グロースエンジニアリング部」を設置し、所属するメンバーは、小さなカイゼンを通して達成したいKPIを目標に、改善活動に集中することができ、かつそのアクション自体が評価される環境を作りました。

※「グロースエンジニアリング部」の発足当初は開発本部と切り離されていましたが、現在は、プロダクト本部という名称に代わり、グロースエンジニアリング部とプロダクトマネジメント部を内包した本部になっております。

継続的なプロセスの改善

 改善のプロセスについても、まだ課題が残っている状況でした。

 特にユーザーからのフィードバックを、適切な形で整理・分析し、優先度判断を行い、改善につなげるプロセスがほとんど整備できていない状況でした。Chatworkでは、Uservoiceという投票型のオープンフィードバックプラットフォーム(現在は閉鎖し自社フォームを設置)や、Zendesk、Salesforce、フィードバックフォームと、少なくとも4つのチャネルからユーザーの声が届くような状態だったため、情報の集約も分析も非常に難しい状況でした。

 そこで、Airtableというサービスを利用し、各プラットフォームからの要望をAirtableにインポートするような連携を行うことで、各ツールのユーザーフィードバックを一カ所に集約することとしました(現在徐々に自動化に取り組み中)。そして、集約したフィードバックに対して、あらかじめ用意したフィードバックカテゴリのタグ付を行うことで、今まで断片的にしか見えていなかったフィードバックを、定性的にも定量的にも見られるようにしました。

 現在は、「機能改善」と「ロードマップ」というタグから、「機能改善」に当てはまるものの中で、「要望数」「検討難易度」「ユーザーインパクト」の軸で行われたスコアリングを元に、優先順位順にフィードバックを確認することができる状態になりました。

 これにより、より効果的にユーザーフィードバックを活用して、企画の検討が行えるプロセスを作ることができました。

ゴールの優先度決め

 最後に、「小さなカイゼン」を行うにあたって、何をゴールとするかの優先順位を明確にしておくことが重要です。グロースエンジニアリング部の立ち上げ当時は、機能の改善が滞り、UX負債がたまっている状態だったため、改善のデリバリー数を増やすことをゴールとしていました。しかし、年間を通してUX負債の返済を行ったことと、会社の事業ステージが変わり、より事業数値の達成が重要になったことで、現在はビジネスインパクトのある改善を優先するようにしています。

 理想は、UXの改善を通して、ビジネスに寄与することですが、小さなカイゼンの中には直接的には事業数値と結びつかない改善も多くあります。これらの改善の優先順位を決めるときに、同じテーブルに乗せると優先度判断が難しくなるため、Chatworkでは、施策を下記の四象限に当てはめつつ、「すぐやるカイゼン」を最優先とした上で、「ビジネスグロース」と「UX負債の返済」のどちらを優先するかを半期ごとに定めて、それに基づいてKPIの設定と施策の検討や推進を行うようにしています。

まとめ

 今回は、ChatworkにおけるUX負債の考え方や、小さなカイゼンの進め方について紹介させていただきました。小さなカイゼンを行うための専門チームの設置は、試行錯誤しながら、早いサイクルで組織的なチャレンジを行う中で生まれた一つの事例となります。開発組織が30人から50人くらいの規模に成長する過程で、社内外からの要望が増えてくる事業フェーズにおいて特に有効になると思いますので、同じようなフェーズでプロダクトマネジメントに取り組む組織の参考になれば幸いです。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
Chatworkのプロダクトマネジメントに学ぼう連載記事一覧

もっと読む

この記事の著者

石田 隼(Chatwork株式会社)(イシダ ハヤト)

 Chatwork株式会社 プロダクト本部 プロダクトマネジメント部 マネージャー。San Francisco State University 在学中に、VCでのインターンを経て、現地でユーザーテスト事業を開始。日本のゲーム会社やスタートアップのプロダクトローカライゼーションを支援。卒業後、Cha...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/13639 2021/03/12 11:00

おすすめ

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー