理想のプロダクトを作るために利用者が開発チームの一員になった話

はじめに

初めまして、QA（品質保証）エンジニアの矢引です。今回は、私たちが開発している販売管理システムのオペレーターを開発チームに迎え入れた話をします。

Clara とは

Clara とは、オンラインストアと販売管理システムを開発するプロジェクトです。オンラインストアというのは弊社のクラウドサービスであるKintoneやその他関連サービスを、顧客（Kintoneのユーザー）が購入するためのシステムです。もう一方の販売管理システムとは、クラウドサービスの売り手として受注・見積・請求などを行う弊社のオペレーターが受注管理などを行うためのシステムです。いずれも米国市場向けに開発されています。

Claraの2つのシステム：オンラインストアと販売管理システム

私はClaraで品質保証に携わっており、販売管理のドメイン知識の難しさを常々感じています。販売管理システムは受注管理などの業務と密接に結びついているため、より良いシステムを開発するためにはその業務に関する専門的な知識を獲得する必要があります。

しかし、販売されているサービスの種類や商流などが多岐にわたっている上、開発者にとっては耳慣れない専門用語が多いため、ドメイン知識の獲得は容易ではありません。また、弊社の海外ビジネスは黎明期で海外向けの販売管理のフローは日々変化しています。このため一度ドメイン知識を獲得するだけでは十分ではなく、常に知識をアップデートし続けなければならない難しさもあります。

しかし、自社のサービスを販売して売上を上げることは企業活動の根幹でもあります。前述のような難しさを感じながらも、販売管理システムの重要性とその品質保証を行うやりがいを日々感じながら開発を行っています。

体験入部

弊社には「大人の体験入部」という制度があります。これは弊社のキャリア形成・研修制度の一つで、興味のある部署の仕事を一時的に体験することができる制度です。今回、普段から販売管理システムを利用する販売管理部門のメンバー2名が体験入部を希望し、 Clara開発チームのQAエンジニアを体験しました。

目的は、販売管理システムの オペレーターと開発者の知見を交換し互いの理解を深め、より良い販売管理システムを作ることです。同じ会社とはいえ、オペレーターと開発者で、システムについての理解や知識が異なることも多いと思います。

実際にやったこと

2人はQAエンジニアとして販売管理システムの品質保証業務を行いました。例えば、オペレーターとしてのドメイン知識を生かして以下のようなことを行いました。

バックログリファインメントに参加
- 販売管理システムの新機能や機能改善に関するバックログに対してオペレーター視点でフィードバックする
開発チームのモブプログラミングに参加
- モブプログラミングに参加して実装中の機能の画面を開発者に見せてもらい、オペレーター視点で迅速にフィードバックする
実運用に近いデータでのテストの実施
- 実際に顧客に発行したライセンスのデータを参考にして、より実運用に近いテストデータを使って販売管理システムのテストを行う
開発チームのドメイン知識向上のサポート
- 受注管理の基礎知識や、受注フローの具体的な作業内容を共有する勉強会を開催

上記の業務を行う上で必要な知識（例えば、品質保証に関する一般的な知識やプロダクトの仕様など）に関しては、開発チームが2人に対してレクチャーしました。

勉強会のイメージ。ビデオ会議で、受注管理の基礎知識をオペレーターが開発チームのメンバーに対して講義している — 勉強会のイメージ

得られたもの

より気軽に意見交換することができるようになった

まず、開発者とオペレーターの間にあった心理的な壁のようなものが少なくなったと感じています。開発者とオペレーターが同じチームとして活動することで距離が近くなったため、以前より気軽に意見交換することができるようになりました。開発者が実装中に抱いた疑問点をすぐにオペレーターに質問して解決したり、オペレーターが抱いた要望や不満を開発チームに共有したりしやすくなりました。

開発者自身が問題を深掘りして考えられるようになった

また、開発者が持つドメイン知識が増えたため、オペレーターが要望した機能をそのまま実装するのではなく、より良い解決策が無いかを開発者自身が考えられるようになりました。例えば販売管理システムへのデータインポート機能を実装した際、オペレーターの実際の作業内容に合わせて保存前に値を修正できる機能を開発チームが提案することができました。

また、そもそも解決したい問題が曖昧な場合はオペレーターと一緒に「本当に解決したい問題は何か？」を深掘りし、安易に機能追加をせずにオペレーターの業務フローの改善を提案するなど、根本的な解決策を探る取り組みを行えるようになりました。

学び

自分たちのプロダクトを過大評価している自分に気づけた

個人的な学びとなりますが、 「システムを使いたくて使っているユーザーはいない」ということに気づけたことは大きいです。

恥ずかしいことに、自分たちが開発しているプロダクトを過大評価してしまい「自分たちのプロダクトが使われるのは当たり前」、ひいては「自分たちのプロダクトは重要なのだから、多少不便があってもユーザーは受け入れてくれるだろう」と心のどこかで思っている自分がいたことに気づきました。しかし、オペレーターの実際の業務を知ると、用途に合わせて数多くのシステムを利用しており、 Claraの販売管理システムは単にその中の一つのシステムにすぎないことが分かりました。

当たり前ですがユーザーは自分の課題を解決するためにシステムを利用しています。販売管理システムの場合、ユーザーとはオペレーターを意味しますが、そのオペレーターにとっての課題とは「どうすれば販売管理の業務を効率化できるか？」「どうすれば自社のサービスをより多くの人に快適に利用してもらえるか？」といったものです。開発者としてその課題解決に少しでも貢献できるようなシステムを開発したいとあらためて思いました。

HRTの原則の大事さを再認識した

最後に、この体験入部を通じて、あらためてHRTの原則が大事だと感じました。 HRTとは、書籍『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』で紹介されている「Humility（謙虚）」、「Respect（尊敬）」、「Trust（信頼）」を示す言葉です。弊社の開発本部は文化としてHRTの原則をとても大事にしており、私はその一員として、それをとても誇りに思っています。

今回、ドメイン知識があるとはいえ開発の知識がほとんどないメンバーを開発チームの一員として温かく迎え入れることができたのは、チームメンバー全員がHRTの原則を実践しようとする気持ちがあったからだと思っています。今後もより良いプロダクト開発を行うため、HRTの原則を大事にしていこうと思いました。