「使われる」機能を、2週間で届けるまで — AI時代の顧客志向開発

「自分が時間をかけて作った機能、ちゃんと使われていますか？」

エンジニアだったら、たぶん一度は胸の奥に刺さる問いだと思います。仕様書通りに作って、テストも通って、リリースして。でも数か月後にログを見るとあまり利用されていない。そういった経験があるかと思います。

この記事では、冒頭の問いに対して「ちゃんと使われている」と言える機能を開発できた事例を紹介します。AIを活用することで2週間でベータ版提供までこぎつけ、楽楽自動応対の翻訳機能が最終的に「この機能の導入前にはもう戻れない」と顧客に言ってもらえるまでの裏側です。

実際の業務フローをヒアリングすることで機能への解像度を上げた

翻訳機能については以前から要望としていただいており、社内で一度モックを作成したことがありました。ただ、社内で翻訳機能を使ったメール送信を行う機会がなく、正解が見えない状態となっていました。
そこで翻訳機能について、1日に届く問い合わせメールが約300件あり、英語 / 中国語 / 韓国語でも問い合わせがある企業に対してヒアリングを行いました。日本語以外のメールが届いた場合の業務フローを伺うと下記の流れになっていました。

1. 外国語のメールを受信
2. メール本文をコピー
3. 外部翻訳ツールを開く
4. メール本文を翻訳ツールに貼り付け
5. 翻訳結果を確認し、内容を理解
6. 日本語で返信文を作成
7. 返信文を翻訳ツールに貼り付けて外国語に翻訳
8. 翻訳結果をメール返信にコピー＆ペーストして送信

手順として8ステップあり、また別ツールを活用するため、ウィンドウの行き来やコピペが大変だという声を頂きました。

「メール対応のツール自体に翻訳が組み込まれていたら、どれくらい嬉しいですか？」という質問に対して、返ってきたのは「すごく助かる」という回答でした。
ここで機能として提供する価値があることがわかります。

社内の認識合わせを動くものを見ながら行った

今までの機能開発では、事業部側が作成した要求仕様書が存在し、その要求に従って開発側が要件定義を行う流れになっています。このような開発の流れでは、どうしても認識合わせに時間がかかり、要件が固まったとしても実装後に見直しが入ることもありました。
ですが、今はAIがあるため、実際に動くものを即座に作成することが出来ます。テキストによる仕様のすり合わせより実際に動くものを見ながら調整したほうが圧倒的に早く、認識のズレが発生しにくいです。また、即座に作ったものに対しての修正も高速で行えるようになりました。

この機能でも最低限必要な機能として「受信メールの翻訳」と「送信メールの翻訳」をできるスクリプトを作成し、認識合わせに利用しました。
これによって作る機能の方向性が社内で一致します。

ベータ版は"きれいな設計"より"速く出せる"を優先した

社内で方針が決まったとしても、実際に顧客に利用してもらわないと作るものが正解かどうかは分かりません。そこで今回の機能は提供する顧客を絞ったベータ版としてリリースする形を取りました。

ただ、楽楽自動応対は25年の重みがあるプロダクトであり、機能追加にもリリースにも時間がかかる問題がありました。そのため、最速でリリース出来るようにするには本体部分とは分離する別の方法を取る必要があります。

そこで今回はサブシステムとしてリリースしていた機能に相乗りを行う形でベータ版をリリースすることにしました。このサブシステムは最近リリースした機能であるため、AWS上にコンテナとしてデプロイされており、リリース自体もGitHub Actionsで簡単に行えるようになっています。また、フレームワークとしても機能追加が簡単な形になっています。

全く異なる機能が1つのサブシステムに乗るというアーキテクチャとしてあまり良いとは呼べない状態になってしまいますが、ベータ版という前提のもと、メンテナンス性よりも最速でリリースすることを優先しました。これにより、ベータ版の実装から提供までを2週間で行うことが出来ました。この実装でももちろんAIをフル活用しており、コーディング作業の9割はClaude Codeに任せる形になっています。

出す前と出した後、2回顧客に見てもらうことでブラッシュアップした

ベータ版の実装が完了した段階で一度顧客に見てもらう機会を設けました。ベータ版として使っていただく上で逆に機能があることでノイズにならないか、顧客側が使う価値があるのかを確認していただくためです。

実装完了段階では最低限翻訳が出来るようなレイアウトになっていました。

実際に見ていただいたところ、業務で使う上で改善していただきたいポイントをいくつもいただくことが出来ました。これも「認識合わせは動くものを見ながら行う」という部分に通ずるところがあります。実際の画面を見ながら業務でどう活用出来るかを見ていただくことで、実際に使っていただけるレベルにブラッシュアップすることができます。

特に画面のレイアウトについては「使われる機能」にするために貴重な意見をいただくことが出来ました。
初期段階では単純に受信したメールの本文とその翻訳結果、返信文とその翻訳結果という4つを表示する形にしていました。ですが、顧客からは「受信メールの原文は読めないから不要」「返信文の翻訳結果を日本語に戻して、ニュアンスが合っているかを確認したい」「実際に入力した返信文と翻訳結果を日本語に戻した内容は左右に並んでいる方が比較しやすい」との声を頂きました。

このような意見は、実際に現場で使っていただく方だからこそ分かる観点になります。このような細かい部分まで顧客の意見を反映することで「使われる機能」になると思います。

いただいた意見はベータ版提供前にすべて反映できました。顧客の手に渡る前にここまで調整出来たことは、後の定着に大きく効いたと感じています。

また、ベータ版をリリースして1週間ほどしてからヒアリングをさせていただいたところ、提供前とはまた異なる意見をいただくことが出来ました。これもベータ版という形で先行リリースすることで顧客の声を聞くことが出来た例になります。

特に使われると思っていたボタンが逆にあることでノイズになり、使い勝手を悪くしているというのは実際に使っていただいたからこそ分かった部分になります。
このフィードバックがあったからこそ、本リリースの際に必要なボタンを洗い出すことが出来ました。

翻訳機能で利用しているAIについてもフィードバックをいただくことができ、モデルの変更やプロンプトの調整に反映しました。実際のメールに使ってもらったからこそ分かる部分であり、ベータ版を経由せずにリリースしていたら「使えない機能」になっているところでした。

ベータ版として最速でリリース出来る仕組みを採用したからこそ、修正も迅速に反映出来る形を取ることが出来ました。いただいたフィードバックを即座に反映して、数日後には修正版をリリースしました。

いただいた内容を反映した結果、ベータ版では最終的にこのような画面レイアウトになりました。

裏側でログを取っておくことで、定量的な観測が出来るようにした

機能をベータ版としてリリースする上で重要と感じたのがログになります。翻訳機能では、どの画面で機能を利用し、何回翻訳を実行したのか、どのボタンを押したのかを計測出来るようにしました。

ベータ版提供後、定期的にログをチェックしていましたが、ログを見ることで機能が実際に業務で使われていることがよく分かりました。また、業務フローの中で一番使われる場面がどこかを把握することができたため、本リリースの際の参考にもなっています。

ベータ版として使っていただく際はヒアリングによる定性的な内容と共にログによる定量的な観測も重要です。

顧客の業務を理解して、初めて使われる機能が出来る

振り返ってみると、今回の翻訳機能開発で起きていたことは「AIを使って速く作れました」というだけの話ではないと感じています。

今回の開発では下記のような流れを取りました。

1. 顧客の業務フローをしっかり聞いて、何が困っているのかを観察する
2. AIを活用して動くものを即座に組み立て、社内・顧客の双方と認識を合わせていく
3. 実際の業務に乗せてみて、ズレや想定外の使われ方を拾う
4. ログでその直感を裏取りする

この流れが噛み合ったからこそ「もうこの機能無しでは業務が回らない！」という意見をいただけたと思います。

AIが効いたのは、主に「形にする」「直す」のフェーズでした。機能要求を読みながら要件定義書を起こす時間や、PoCに数週間かけて社内合意を取りに行く時間が、今は実装と同時並行で進められます。コーディングをAIに任せられる時代では、エンジニアの仕事の重心が「機能を実装する」から「機能を考える」に移ってきている実感があります。

ただ、AIだけで「使われる機能」が作れるわけではありませんでした。実際の業務フローを聞かなければボタンの配置一つ決められないし、ベータ版で現場の声を浴びなければ「ボタンが不要」とは気づけなかった。AIで生まれた時間を、顧客と向き合う時間にきちんと再投資できたことが、今回の機能が定着した一番の理由です。

顧客の業務を理解することと、AIで素早く形にして直し続けること。この2つは別々の話ではなく、お互いを支え合う関係になっていました。AI時代の機能開発のひとつのやり方として、参考にしていただけたら嬉しいです。