こんにちは、今年は家電が何かと壊れる freee会計のアプリケーションエンジニア 
id:him0 です。
この記事は freee Developers Advent Calendar 2022 の19日目の記事です。
今年自分のチームは特定のドメインの DB を分離しパフォーマンスのカイゼンを図るプロジェクトに取り組んでいました。下調べを行いドメインの境界を定義し分離できるぞーとプロジェクトは走り始めましたが、やはり単純には行かないのがアプリケーション開発、ちゃんと問題に突き当たります。特定の検索条件を利用する際に分離される予定の 2 つの DB を横断して JOIN を行っていることが発覚しました。
この問題に対して我々チームは当初パフォーマンス犠牲に元ある機能を再現することを考え始めたのですが「この検索軸消しちゃっていいんじゃない？」というメンバーの提案をきっかけに方向を転換して「ユーザーさんと合意を取りつつ検索軸を削除する」というリファクタリングとしては最良の選択を取ることができました。
この記事では自分がまた同じ場面に出くわしたときやこの記事を読んだ方が躓いたときに効果的なコミュニケーションを取れるように、今回の事例を一段抽象化し「エンジニア目線でクローズしたい機能」が出てきたとき「エンジニア主導でできるコミュニケーション」を言語化してみたいと思います。
相手に伝わる抽象度で説明できる様にする
freee で機能をクローズをするには、カスタマーサクセス（以下 CS）やカスタマーサポート（以下 Support.）そして、ユーザーさんに納得してもらい、プロダクトマネージャー（以下 PdM）が最終的な意思決定を行う必要があります。簡単に言い換えれば、非エンジニアに説明して理解してもらった上で、Go サインを貰う必要があると言えます。この様な場面で、エンジニアがよくやってしまう失敗として DB のテーブル名やプログラム上のモデル名といったエンジニア同士の会話で使う言葉を非エンジニアの前で使ってしまう失敗です。明確にやりたいことを伝えるためには UI 上で使われている言葉や目で見て観測できる挙動がどう変わるのかを説明できるように準備しておく必要があります。最初にエンジニアチームで説明の認識を合わせておくと、続くコミュニケーションのなかでの説得力が増して、スピード感をもって意思決定ができます。
また機能をクローズするという部分だけでなく、エンジニア的に機能をクローズするとどんなメリットがあるのかも、一般的に伝わる言葉で説明できるようにしましょう。DB のパフォーマンスと言ってもなかなか伝わりづらいので、UI に基づきこの操作を行う際の動作時間など具体的な表現を考えましょう。
利用状況を調べて、クローズの意思決定の一歩目を踏み出す
我々エンジニアは幸福なことにデータを自在に扱いユーザーさんの行動を調査することができます。該当データの作成状況や、API のアクセスログを解析し、機能の利用状況を調べましょう。また既存のデータでいまいちユーザーさんの利用状況がつかめないというパターンもあります。この場合は一旦新規でロガーを仕込んでユーザーさんの操作を記録する期間を置いてから、改めて調査を行うなど、判断材料を手堅く集めるムーブをしましょう。データが揃ってきたらいよいよ機能をクローズしたいという意向を PdM に伝え、一緒にデータを眺めつつ機能のクローズに向けて動き始めましょう。
データ調査の際にヘビーユーザーを見つけておくと、そのユーザーさんをペルソナに設定することもでき今後のやり取りの際に役立ちます。
複数の「落とし所」を用意する
この記事では機能をクローズするための話をしていますが、代替手段を用意しようという判断も実際の現場では発生します。その場合は複数の「落とし所」を用意して非エンジニアとのコミュニケーションに望みましょう。
代替案を考える際によく自分が指標にするのは エンジニアリングコスト と ユーザの受け入れ負荷 です。例えば、機能を削除し代替手段を用意しない場合エンジニアリングコストは低くなりますが、ユーザの受け入れ負荷は高くなります。逆に、機能の代替となる実装を作成した場合、エンジニアリングコストは大きくなり、ユーザの受け入れ負荷は低くなります。この2つの指標はグラデーションがあり、ユーザーさんの体験は少し変わるけど同じ機能を用意するという場合は、エンジニアリングコストが中くらい、ユーザーさんの受け入れ負荷も中となったりします。
freee社内だとどこまでユーザーさんをケアするのか 松竹梅 の3案を用意して相談に望む場合が多いです。この案はたたき台でコミュニケーションを行うメンバーが増え、詳細度が上がってきたタイミングで調整していきます。
ユーザーさんと直接話しているメンバーと話してみる
いきなりユーザーさんへのインタビューに行く前に、まずは社内の CS、support. のメンバーに機能のクローズを考えている旨を共有し意見をもらいましょう。機能のクローズに際してどこまでユーザーさんのケアをすれば、納得してもらえるのか認識合わせをおこない、社内ではこの「落とし所」にしたいという認識合わせをしましょう。
（エンジニアからできるとか言っておきながらこのあたりの調整 PdM にお願いしていたので、画像で依頼しているのは PdM の方）
ユーザーインタビューをして「落とし所」の妥当性を確かめる
CS のメンバーにインタビューできるユーザーさんを探してもらい、普段の利用状況のヒアリングという形でインタビューを設定しましょう。実際のインタビューの流れに関しては、自分が書くよりも良い記事がある気がするので割愛します。ユーザーインタビューの目的は機能のクローズとその代替手段に対する反応を確認し、最終的な意思決定のヒントを得ることです。いずれかの「落とし所」を押し付ける形にならないようにあくまでも意見を引き出すことを主体に考えつつインタビューに望みましょう。
ユーザーさんのインタビューの結果が出たら、エンジニア、PdM、CS で再度話し合い、最終的な意思決定を行いましょう。
スケジュールと代替手段、もしものときの窓口を社内周知
機能のクローズに際して、一番最初に具体的なフィードバックが返ってくるのは CS や support. チームなので、機能のクローズのスケジュールとその代替手段を周知して、実際の反応があった際にスマートに対応できる体制を整えましょう。また、代替手段でカバーできない事象が出てきたときにエンジニアや PdM にすぐ相談できるように窓口となる人を周知しておきましょう。
（ここもアナウンス PdM にお願いしていたので、画像でアナウンスしているのは PdM の方）
ユーザーさんに伝える
機能クローズの社内周知が完了したら次は、ユーザーさんに機能クローズの意向を通知しましょう。機能が削除されるという情報だけでは、不安になってしまうので、どうしてクローズするのか、代替手段はどうしたらいいのかを詳しく案内しましょう。実際に機能を使っているお客さんに届いてほしい情報なので、プロダクト内のクローズしようとしている機能の近くに案内を出せるとベストかなと思います。お知らせは閲覧状況をトラッキングして、全然見られていないのであれば、文言を調整したり、出す場所を調整したり、ユーザーさんに伝えるための調整を入れましょう。
実際に行った機能クローズの周知の案内を例に画像を貼っておきます。
お知らせのスライドは、PdM に依頼して作ってもらい、エンジニア、CS でレビューして公開しました。
機能をクローズして更に観察する
いざというときのために機能のクローズは切り戻し手段を用意しつつ行いましょう。機能がスケジュールどおりにクローズされたら、アクセスログや代替手段の利用状況をみてユーザさんの反応を確認しましょう。予想していなかったユーザフィードバックや、動きがが現れたら、すぐにステイクホルダーを集め、切り戻しを含めて判断しましょう。
extra. いっぱい感謝しましょう
無事機能のクローズが完了して、ユーザに受け入れられていることが確認できたら、協力に対し感謝を伝えましょう。機能をクローズするのは新しい機能を出すよりも、たくさんの人の確認と手間がかかるとても大変な作業です。やりきってしまうと以外に感謝するタイミングってのがしてしまいがちなのですが、忘れないようにしましょう。
うまくいったことをちゃんと伝えると今後同じ様な課題が起こったときに、そういえばあのときうまく行ったな、どんなことしてたっけと思い出すきっかけになったりします。良かったことのフィードバックって忘れがちなのですが、ちゃんと言語化して伝えましょう。
この記事を書いて
思ったことを雑多に書いた文章になってしまったので読みづらい部分もあるかと思いますが、自分のなかで物事の因果関係を整理するいい機会になり、また、今後ともユーザーさんのためになることであれば、機能開発も機能クローズも全力で取り組んでいきたいと改めて気が引き締まりました。成長し続ける freee会計 をよろしくおねがいします。
次回予告
やめて！12月があっという間に過ぎ去っていったらあっという間に jaxx さんのアドベントカレンダーの番がきちゃう！ お願い、がんばって jaxx さん！あんたが今ここで筆を折ったら、アドベントカレンダーをみんなで走り切るっていう約束はどうなっちゃうの？ 記事公開までの時間はまだ残ってる。ここで書き切れれば、絶対いい記事が出せるんだから！ 次回「jaxx さん記事を時間通りに公開する」。デュエルスタンバイ！
