執筆の契機
DXプロジェクトにおける仮説検証のリアルを伝えたく、この記事を書きました。
背景
私は、生成AIを活用して社内DXを推進するチームに所属するエンジニアです。
私たちのチームは、「AIツールの普及」と「AIリテラシー向上施策」を通じて、1年後にプレスリリースできる象徴的な事例をつくることを目標としています。
第一段階として、業務効率化を推進しています。
その中で浮かび上がったのが、「日常的なメール返信業務」の非効率性です。
これを解決すべく、生成AIを活用して 「メール自動返信くん」 の開発をスタートしました。
「メール自動返信くん」は、受信したメールに対する一次返信を自動生成することで、業務効率を高めることを目的としたツールです。
AIツールは内製だけでなく、Difyを積極的に活用しています。それらの取り組みは下記をご参照ください。
仮説検証フィットジャーニーに関して
DXプロジェクトの推進では、早期に仮説検証を行い、効率的に価値を確認することが求められます。
そこで、私たちはFit Journeyフレームワークを採用し、プロジェクトを段階的に進めました。
Fit Journeyは以下のフェーズで構成され、それぞれの段階で仮説と検証を繰り返しながら進行します。
-
CPF (Customer Problem Fit)
顧客の課題を明確に特定する段階 -
PSF (Problem Solution Fit)
課題に対する解決策を構築・検証する段階 -
SPF (Solution Product Fit)
解決策が現実に機能するかを実証する段階 -
PMF (Product Market Fit)
プロダクトが実際に市場やユーザーに受け入れられていることを確認する段階
このフレームワークを活用することで、フェーズごとに最小限のリソースで成果を見極め、必要に応じて次の段階へと進めます。
また、仮説が外れた場合でも柔軟にフェーズを戻り、再検証を行えるため、リスクを抑えながら確実な前進が可能になります。
スタートアップのように不確実性の高い環境で、仮説検証を効率的かつ効果的に行うために有用です。
東京大学 FoundX 馬田隆明さんの資料が大変参考になりました。
忙しい人のためのまとめ
私たちは、「メール自動返信くん」の開発において、以下の流れでFit Journeyを進めました。
-
CPF:
- 社内のアシスタント(AS)やプロジェクトマネージャー(PM)に対してヒアリングを行い、メール返信業務の非効率性を課題として特定しました。
- 特に「移動中や業務逼迫時に即時返信ができない」点と「論点や要件の抜け漏れ」が大きな課題でした。
-
PSF:
- 課題に対する解決策として、2つの方向性でデモアプリを作成しました。
- AIアシスタント方式: 返信案を提案し、その場で修正指示を送る。
- 自動下書き生成方式: 受信メールをトリガーに下書きを生成し、手間を削減する。
- ユーザー体験を検証した結果、シンプルで効率的な「自動下書き生成方式」を採用しました。
- 課題に対する解決策として、2つの方向性でデモアプリを作成しました。
-
SPF:
- 社内での実証テストを行い、「簡易的な返信」には一定の効果が見られたものの、
複雑な論点解消や申し送りには対応しきれないという課題が明らかになりました。
- 社内での実証テストを行い、「簡易的な返信」には一定の効果が見られたものの、
Fit Journeyで見えた「期待と現実」
仮説検証を丁寧に進め、力を注いで作り上げた「メール自動返信くん」でしたが、最終的にプロダクトとしての普及には至りませんでした。
- 期待: 普遍的な業務「メール返信」を効率化できるツールとして社内に普及する
- 現実: 「簡易的な返信」に留まり、コンサルタント業務に必要な「複雑な論点解消」には力不足だった
Fit Journeyの詳細へ
「メール自動返信くん」の開発は、私たちにとってDXプロジェクトのリアルを突きつける結果となりました。
丁寧に仮説検証を重ね、ユーザーの課題を一つずつ解き明かしていくプロセスを経ても、プロダクトとして完璧な形に仕上げることは容易ではありません。
それでも、この過程で得られた気づきや学びは非常に大きなものでした。
ここからは、Fit Journeyの各フェーズにおいて、私たちがどのように課題を特定し、解決策を検証し、そして実証へと進んだのか――その詳細を振り返っていきます。
CPF (Customer Problem Fit): 顧客の問題に対する理解と共感が得られた部分
課題ヒアリング
「メール自動返信くん」と「メール返信くんver2」の開発に向けて、社内のターゲットユーザーを対象に課題のヒアリングを行いました。
質問は半構造化インタビューの形式を意識しました。オープンクエスチョンとクローズクエスチョンを織り交ぜるインタビュー形式です。
質問テンプレート↓
- (日/週/月次に)メール返信にかけている時間は?
- 今現在、お客様へのメール返信をどうやって行っているか?(CCつけるつけない.受信から返信までの流れ.レビュー/チェックの有無)
- メール返信業務で感じている課題は?
- メール返信の課題を解決するために試したことがあれば教えてください
- これまで試したソリューションで気に入らないポイントは?
- (実現可能性を抜きにして、)ドラえもんなどがいて、なんでもできるとしたらメール返信に対してどんなことをして欲しいですか?
- 他になんでも!
この過程で、以下のような課題仮説と実際の声が明確になりました。
課題候補の整理
A. メール返信を忘れてしまう課題
- 受信したこと自体が漏れてしまう
- 返信するのを忘れてしまう
B. メール文面を作成する工数の課題
- 観点や要件の抜け漏れをチェックするのが大変
- 要件を埋める作業が手間
- 失礼のない文面(ビジネスマナー)の確認が面倒
ヒアリング結果
-
業務状況の実態
- 複数案件を抱えるアシスタント(以下、AS) は、移動中にメール返信の時間を確保できないことがある。
- プロジェクトマネージャー(以下、PM) レイヤーでは、何を返信すべきか整理する工数や、レビュー待ちに時間がかかるケースが多い。
-
課題の具体化
以下の課題が共通して見られました。- 返信する内容の「論点」や「含めるべき項目」が漏れる
- レビュー待ち時間(特に先輩PMからの指摘)が長い
- フォーマットやインデントの修正が発生し、工数を圧迫する
- ChatGPT等の既存ソリューションは、都度フォーマットが変わることで手間が増える
課題候補の検証結果
ヒアリングから、メール返信業務における2つの主要な課題が特定されました。
1. メール返信の即時性と効率化
- 移動中や業務逼迫時にメール返信が遅れることで、顧客からの印象が低下する。
- 返信作業にかかるコピペやツール起動などの手間を省きたい。
2. メール内容の品質向上とレビュー時間削減
- 論点の漏れや不適切な伝え方が発生し、レビュー待ちが1日以上かかるケースがある。
- フォーマット修正や要件漏れチェックに時間が取られ、本来の業務が圧迫される。
ターゲットと問題整理
ヒアリングを通じて、以下のユーザー層と具体的な問題が見えてきました。
ターゲット1: アシスタント(AS)
-
問題:
- 忙しい状況で返信時間が取れない。
- 即時返信による顧客印象の向上が求められる。
-
課題:
- 移動中など、PCを使えない環境での返信が手間。
- コピペやツール起動含め、1通10分かかる工数の削減。
ターゲット2: プロジェクトマネージャー(PM)
-
問題:
- 返信すべき「含める内容」が整理できていない
- レビュー工数が発生し、待ち時間が長い
-
課題:
- 要件の抜け漏れや伝え方の品質担保が必要
- フォーマットやインデント修正に時間を取られる
課題解決への方向性
ヒアリング結果をもとに、以下のソリューション仮説を立てました。
-
メール自動返信機能
- 受信メールをトリガーに一次返信を自動生成し、手間を削減する。
-
メール返信くんver2
- 含めるべき論点を入力することで、メール内容を自動構築する。
- フォーマットやビジネスマナーを考慮した品質の高い文面を提供する。
まとめ: CPF達成のポイント
ヒアリングを通じて、社内ユーザー(アシスタントやプロジェクトマネージャー)の課題が明確化されました。
- アシスタント層の即時返信ニーズ
- プロジェクトマネージャー層の品質担保と工数削減の必要性
これにより、「メール自動返信くん」の方向性として、効率化と品質向上の2軸を仮説として構築しました。
PSF (Problem Solution Fit): 問題に対する解決策が適切であった部分
課題の再確認
CPFで特定した課題から、解決策は大きく以下の2軸に整理されました。
-
メール返信の即時性と効率化
- 忙しい状況で手間なく返信を行いたい。
- 移動中や業務逼迫時に1通10分かかる作業を短縮したい。
-
メール内容の品質向上とレビュー時間削減
- 要件の抜け漏れやフォーマットの修正が発生する。
- レビュー待ち時間の削減が求められている。
意思決定までの過程
1. ソリューションの絞り込み
CPFを踏まえて、以下の2つの方向性に基づいたデモアプリを作成しました。
1. AIアシスタント方式
-
概要:
メール受信をトリガーに、AIアシスタントが返信案を生成。 -
特徴:
- AIが返信案を提示し、その場で修正指示を送れる。
- 返信内容の確認依頼がAIから届くため、柔軟に修正が可能。
2. 自動下書き生成方式
-
概要:
受信メールをトリガーに、一次返信の下書きを自動生成。 -
特徴:
- コピペ作業なしで下書きが作成され、即時返信が可能。
- Google Chatに組み込むことで、検索性が向上する。
2. デモアプリの体験とヒアリング
デモアプリを社内のターゲット(アシスタント(AS)およびプロジェクトマネージャー(PM))に試用してもらい、以下のフィードバックが得られました。
AIアシスタント方式のフィードバック
- メール受信後にAIが提案を出す点は好評だったが、修正指示の手間が残る。
- 3人以上の関係者が含まれる場合、ステークホルダーの識別が難しいケースがあった
- カジュアルなやり取りが求められる場合でも、返信が固くなりがちで、修正が必要になることが多かった。
自動下書き生成方式のフィードバック
- 「すぐに下書きを確認できる」「コピペ不要」という点で好評。
- Google Chatに組み込むことで、受信通知から即座に返信作業が可能。
- UI/UX検証でも、下書き生成フローのシンプルさが高く評価された。
Mockを用いたUI/UX検証
検証内容
- 目的: デモアプリの体験の流れが適切か、改善点をヒアリングする。
- 対象: アシスタント(AS)およびPM層
体験の流れ
- メール受信
- Google Chat通知
- フォーム入力(含めたい内容・送信者名)
- 一次返信生成
- 下書きとして出力
上記の体験は、実際にユーザーにデモアプリを触ってもらい検証しました。(下記はヒアリングMTGの様子)
ヒアリング結果
- フォーム入力項目は適切で、過不足は見られなかった。
- 生成された返信文を下書きで修正できる方が良いという声が多く、修正UIの柔軟性が評価された。
- 一覧性のトレードオフ(修正UIが狭くなる vs 下書きで誤操作リスク)については、下書き修正の選択肢が好まれた。
結論: 「メール自動返信機能」を採用
デモアプリの検証結果とヒアリングを踏まえ、以下の理由から自動下書き生成方式を採用しました。
-
即時性と効率性
受信メールをトリガーに下書きを自動生成することで、ASメンバーの手間と時間を大幅に削減できる。 -
シンプルなUI/UX
下書きをそのまま確認・修正するフローは直感的であり、業務への組み込みが容易である。 -
Google Chatとの連携
通知から返信作成までの一連の流れをシームレスに実現し、検索性や操作性も向上する。
まとめ: PSF達成のポイント
問題解決の方向性として、「メール自動返信機能」が最も適切であると判断しました。
- メール返信業務の効率化と即時性の確保
- レビュー工数の削減と品質向上
次のフェーズ(SPF)では、この機能が実際に社内でどの程度の効果を発揮するか、プロトタイプの運用検証を行います。
実装
アーキテクチャ
Google ChatからCloud FunctionへHTTPリクエストを送信しイベント処理をする構成にしました。
Gmailの受信を定期的に監視するためにCloud Schedulerを用いて、新規受信メールがあった場合Google Chatへ配信します。
Gmailの認証情報の管理や、送信先のGoogle Chatなどのデータ管理はFirestoreで行いました。
シーケンス図
リリース!
ついにプロダクトが完成して、大々的にリリースしました!!
期待に胸を膨らませ、ユーザーに公開しました!
ダッシュボードも作って、息巻いてました。
SPF (Solution Product Fit): 解決策が実現できているかの検証結果
結果
「メール自動返信くん」は簡易的な返信において一定の効果が見られたものの、以下のフィードバックと結果が得られました。
-
アンケート結果
- 「現状結構自分で書き直してしまっています><」という声が多い。
- 利用状況は簡易的な返信に限定されており、難しい返信業務には使われていない。
具体的なフィードバック
- 利用業務の2~3割: 「ありがとうございます」などの簡易返信。
- 利用されない業務の7~8割: 複雑な論点の返信、日程調整、資料添付など。
-
ヒアリング結果
- 現状、簡単なライト系の返信には対応できているが、「論点解消」や「日程調整・資料やり取り」 には対応できていない。
- 「自分で返信文を打ったほうが早い」という意見が多く、返信文の作成自体にハードルを感じている。
考察
「メール自動返信くん」は以下の点で課題が浮き彫りになりました。
-
前提として、普及対象がコンサルタント
コンサルタント業務では、顧客へのメール返信はアポイントメントの前後で大きく状況が変化する。- プロジェクトの履歴や文脈がメールに反映されないため、AIの出力では論点が解消できない。
-
対応範囲が簡易的な返信に限定されている
- ライト系(例:「了解しました」「ありがとうございます」)の対応に留まっており、
複雑な論点や具体的なやり取りには機能が不足している。
- ライト系(例:「了解しました」「ありがとうございます」)の対応に留まっており、
結論
「メール自動返信くん」は簡易的な返信に強みを持つ一方で、ターゲット層であるコンサルタントの要望に応えられなかったことが明らかになりました。
-
想定されるニーズ:
アポイントメント前後に発生する「複雑な論点解消」や「申し送り」に対応できるツールが必要である。 -
現状の限界:
AI出力は簡単な内容には対応できるが、文脈やプロジェクトの背景が必要なメールでは十分な精度を担保できない。
展望(検証終了)
「メール自動返信くん」の精度向上と機能拡張に向け、以下の方向性を検討します。
-
アポイントメントの文字起こしデータを含めた精度向上
- 会議の音声データや議事録をコンテキスト情報として組み込むことで、メール内容の精度を担保する。
-
より広い職種への展開
- 営業など、顧客とのコミュニケーション頻度が高い職種であれば、簡易返信機能がさらに有効に活用される可能性がある。
-
UI/UXの改善
-
下書き生成フローの改善:
- 受信メールから返信文の下書きURLを生成し、枠組みの中に複数の返信候補(例: 候補①、候補②)を提示する。
-
ハードルを下げる体験設計:
- 自動で送信者名を取得する、空欄対応を許容するなど、入力負荷を軽減する。
-
下書き生成フローの改善:
まとめ: SPF達成に向けた次のステップ
現時点での「メール自動返信くん」は、簡易的な返信ツールとしての有用性は確認できましたが、
コンサルタント業務における複雑な論点解消や高度な申し送り業務には対応しきれていません。
今後の展望として、アポイントメント文字起こしデータの組み込みやUI改善を進めることで、精度向上と業務範囲の拡大を目指します。
また、営業職など他職種への適用可能性を検証し、ツールの価値最大化を図ります。
振り返りと教訓
振り返り
「メール自動返信くん」の開発は、Fit Journeyフレームワークに基づき、真っ当に仮説検証を行いました。
- CPF (Customer Problem Fit): 顧客の課題を明確に特定し、メール返信業務の「即時性」と「品質向上」に対するニーズを把握。
- PSF (Problem Solution Fit): デモアプリを作成し、UI/UX検証やフィードバックを通じて「自動返信機能」の方向性を確認。
- SPF (Solution Product Fit): 実際の運用で「簡易的な返信」には対応できた一方、複雑な論点や高度なやり取りには不十分であることが明らかになりました。
結果として、「かなりの力作」を作り上げたものの、期待した成果を十分に得るには至りませんでした。
仮説検証を通じて課題を可視化したことは成果ですが、それだけに悔しさも残ります。
教訓: Fit Journeyを通じて得た学び
-
仮説検証の重要性
Fit Journeyの各フェーズを着実に進めることで、ユーザーの真の課題を明らかにすることができました。- 最終的に得られた課題は「複雑な論点解消」や「申し送り業務」への対応という新たな気づきでした。
-
成功しなかった原因の可視化
- 初期の想定: 簡易返信ツールとしての価値提供。
-
実際のニーズ: コンサルタント業務における高度なやり取りへの対応。
開発ツールがターゲットの業務フローや文脈に追いついていなかったことが明確になりました。
-
「仮説の外れ」も次のステップへの布石
失敗ではなく、次の改善策へ繋がる貴重なデータと学びを得ることができました。
今後の改善策: 絶対に成仏させる
今回の結果を踏まえ、私たちは「メール自動返信くん」の再検証と改善に向けて以下のアクションを検討しています。
-
高度な文脈理解の強化
- アポイントメントの文字起こしデータやプロジェクト履歴をコンテキストに組み込み、複雑な論点や申し送りに対応する精度向上を目指します。
-
ターゲット層の拡張
- コンサルタント以外にも、営業職など顧客対応が多い職種に適用範囲を広げることで、新たな価値を検証します。
-
ユーザー体験の再設計
- 返信文生成の体験をさらに簡単かつシームレスにするため、下書き生成フローのUI/UX改善を行います。
まとめ
「メール自動返信くん」は一度壁にぶつかったものの、仮説検証を通じて真の課題と向き合うことができました。
今回の学びを糧に、もう一度検証と改善を重ね、「絶対にこのツールを成仏させる」ことを目指します。
次こそ、ユーザーの期待を超えるDXツールとして生まれ変わらせるために、チーム一丸となって挑戦を続けます。