新機能実装前提条件整理

【商品・サービス】 小規模な制作会社・受託開発会社向けの 案件情報整理SaaS。 顧客とのメールやチャットから、 案件ごとの決定事項、 TODO、 未決事項、 経緯を整理して確認できる。 【現在の対象顧客】 2〜10人程度の制作会社、 受託開発会社、 小規模コンサルティング会社。 複数の顧客案件を並行して進めているチーム。 【追加を検討している機能】 案件ごとの「承認待ち一覧」機能。 顧客から返事・承認を待っている事項だけを 自動で一覧表示する。 【その機能で解決したい課題】 顧客からの承認待ちを見落とし、 案件が止まったままになること。 どの案件で、 何の返事を待っているのか確認するために、 過去のメールやSlackを見直す負担があること。 【その課題が確認された顧客】 顧客A： 5人のWeb制作会社。 顧客B： 3人のデザイン会社。 顧客C： 8人の受託開発会社。 【顧客から実際に聞いた発言】 顧客A： 「クライアントから返事待ちのものだけ一覧で見たい」 顧客B： 「相手待ちがどれか分からなくなることがある」 顧客C： 「承認待ちで止まっている案件を見落とすことがある」 顧客Aからは、 「承認待ち一覧みたいな画面が欲しい」 とも言われている。 【確認できている利用行動】 顧客A： 現在は自分で案件メモに 「顧客確認待ち」と書いている。 ただし更新し忘れることがある。 顧客B： Slackの自分宛リマインダーを使っている。 顧客C： 週1回、 担当者がメールと案件メモを見直して 顧客待ち案件を確認している。 A、B、Cとも、 承認待ち確認のために 現在何らかの手作業をしている。 【現在の代替手段】 案件メモへ手入力 Slackリマインダー TODOへ「顧客確認」と登録 メール検索 担当者による定期確認 【既存機能でできること】 既存のAI整理で、 メールやチャットから 未決事項を抽出できる。 TODOとして登録することもできる。 案件一覧で、 各案件の未決事項を確認できる。 【既存機能ではできないと考えていること】 複数案件を横断して、 「現在、顧客からの返答・承認を待っているものだけ」 をまとめて見る専用画面はない。 ただし、 既存の未決事項の中から 顧客待ちだけを正確に判定できるかは未確認。 【想定している利用場面】 朝に担当案件を確認するとき。 週次の案件確認時。 顧客から返事が来ていない案件を まとめて確認したいとき。 【想定している利用者】 複数案件を持つ担当者。 案件全体を見るディレクター。 【利用に必要だと考えている条件】 AIが、 ・誰からの返事を待っているか ・何について承認を待っているか ・すでに返事が来て解消済みか を判別できる必要があると思う。 ただし、 この判別精度はまだ検証していない。 【既存仕様との関係】 現在の未決事項抽出を使えば、 元になる情報は取れる可能性がある。 承認待ち専用の状態区分は 現在は存在しない。 【既存運用への影響として考えていること】 新しい一覧画面を追加すると、 ユーザーが確認する画面が増える。 未決事項一覧と承認待ち一覧の どちらを見るべきか分かりにくくなる可能性がある。 一方で、 横断的に顧客待ちだけ見られれば 定期確認は楽になると思っている。 【競合・他サービスで確認できていること】 競合Aには、 案件ごとのステータス管理がある。 「顧客確認待ち」というステータスを ユーザーが手動設定できる。 自動で顧客待ちを判定する機能は 確認できていない。 【すでに試した簡易検証】 顧客Aの過去メール10件について、 AIに 「このメールは顧客の返答待ちか」 を手動で判定させた。 【検証結果】 10件中、 明らかに顧客待ちだった6件は すべて顧客待ちと判定した。 残り4件のうち1件を、 顧客待ちと誤判定した。 この10件だけで 十分な精度があるとは判断していない。 顧客A以外ではまだ試していない。 【自分が実装したい理由】 顧客Aから明確な要望がある。 A、B、Cで 「顧客待ちを見落とす」 という似た課題が確認できている。 既存の未決事項抽出を利用できそうなので、 新規機能として作りやすいのではないかと思っている。 【現在不安に思っていること】 顧客Aの要望をそのまま 専用画面として作ってよいのか。 既存の未決事項一覧に フィルターを追加するだけでも 解決できるのではないか。 AIの顧客待ち判定が 実運用で十分か分からない。 専用画面を増やすと、 逆に操作が分かりにくくならないか。 【今回特に確認したいこと】 ・顧客Aの要望をそのまま実装してよいか ・A、B、Cで課題が確認できているなら本格実装へ進んでよいか ・専用画面と既存一覧へのフィルターのどちらがよいか ・AI判定について何を追加確認すべきか ・10件の簡易検証をどこまで根拠にしてよいか ・利用成立条件として何が未確認か ・既存機能との重複をどう扱うべきか ・本格実装前に小さく確認できることは何か

【追加を検討している機能】 - 複数案件を横断して、顧客からの返答・承認を待っている事項だけを確認できる機能。 - 現時点では、主に次の実現方法が候補となっている。 - 独立した「承認待ち一覧」画面を追加する。 - 既存の未決事項一覧に「顧客待ち」フィルターを追加する。 - 保存済みフィルター、簡易な横断リスト、案件一覧上の表示などで補う。 - 既存の未決事項抽出結果を元に、AIが以下を判定する構想がある。 - 誰からの返事を待っているか - 何について返答・承認を待っているか - 現在も返答待ちか - 返答済み・解消済みか - 「承認待ち」に限定するか、質問への回答、資料送付などを含む「顧客からの返答待ち」全般を対象とするかは決まっていない。 【解決したい顧客課題】 - 顧客からの返答・承認待ちを見落とし、案件が止まったままになること。 - どの案件で、誰から、何について返事を待っているのか分からなくなること。 - 状況を確認するために、過去のメール、Slack、案件メモなどを見直す負担があること。 - 顧客から返答が来た後も、手動記録が更新されず、古い顧客待ち情報が残ること。 - 複数案件を横断して、現在の顧客待ちだけをまとめて確認できないこと。 - 本質的な課題は「専用画面がないこと」ではなく、顧客待ち事項を漏れにくく、少ない手間で把握・更新できないことである。 【課題について確認できていること】 - 顧客A、B、Cの3社で、類似した課題が確認されている。 - 顧客A：「クライアントから返事待ちのものだけ一覧で見たい」 - 顧客B：「相手待ちがどれか分からなくなることがある」 - 顧客C：「承認待ちで止まっている案件を見落とすことがある」 - 3社とも、顧客待ちの確認を何らかの手作業で補っている。 - 顧客Aでは、案件メモに「顧客確認待ち」と記録しているが、更新忘れが発生している。 - 顧客Bでは、Slackの自分宛リマインダーを使用している。 - 顧客Cでは、担当者が週1回、メールと案件メモを見直している。 - 顧客Aからは「承認待ち一覧みたいな画面が欲しい」という具体的な要望も確認されている。 - 一方、顧客B、Cで確認されているのは課題であり、専用画面への要望までは確認されていない。 - 見落としの頻度、確認作業にかかる時間、案件遅延への影響などは定量化されていない。 - 3社での確認結果を、対象顧客全体へ一般化できる根拠はまだない。 【現在の代替手段】 - 案件メモに「顧客確認待ち」などを手入力する。 - Slackの自分宛リマインダーを使用する。 - TODOに「顧客確認」などを登録する。 - メールを検索して返答の有無を確認する。 - メール、Slack、案件メモを定期的に見直す。 - 既存の案件一覧から案件ごとの未決事項を確認する。 - 担当者が記憶や定期確認によって状態を維持する。 - これらの手段は一定の対応にはなっているが、更新忘れ、情報の分散、見落とし、確認負担が残っている。 - ただし、新機能を提供すれば既存手段から切り替わることや、既存手段が不要になることは確認されていない。 【既存機能で対応できること】 - AIがメールやチャットから未決事項を抽出できる。 - 抽出した事項をTODOとして登録できる。 - 案件一覧で、案件ごとの未決事項を確認できる。 - そのため、顧客待ち情報の元となる候補は既存機能から取得できる可能性がある。 - 一方、現在は以下に対応していない、または対応可否が確認されていない。 - 複数案件を横断した顧客待ちだけの表示 - 顧客待ち専用の状態区分 - 未決事項の中から顧客待ちだけを安定して分類すること - 誰から何について返事を待っているかの事項単位での特定 - 返答後の解消状態の継続的な追跡 - 既存の未決事項、TODO、顧客待ちは対象情報が一部重複する。 【新機能で変えようとしていること】 - 案件ごとに確認している未決事項を、複数案件横断で確認できるようにする。 - すべての未決事項ではなく、顧客からの返答・承認待ちに対象を絞る。 - メモ入力、メール検索、Slackリマインダーなどに分散している確認作業を、一つの導線に集約する可能性を検討している。 - 顧客待ちの登録を、完全な手入力からAIによる分類・候補提示へ変える可能性がある。 - 返答後の状態更新を、手動更新だけでなくAI支援または自動判定で補う可能性がある。 - ただし、次のいずれが適切かは未確定である。 - 完全自動で一覧へ掲載する - AIが候補を出し、人が確定する - 人が顧客待ちを設定し、AIが補助する - 専用画面が必要なのか、既存一覧の拡張で十分なのかも未確定である。 【想定利用場面】 - 担当者が朝に担当案件を確認するとき。 - ディレクターが週次で複数案件を確認するとき。 - 顧客から返事が来ていない案件をまとめて点検するとき。 - 顧客への催促やフォローが必要か判断するとき。 - 案件が顧客待ちで停止していないか確認するとき。 - 顧客から返事が来た事項が、解消済みとして反映されているか確認するとき。 - 顧客Cが週1回確認していることは確認済みだが、新機能がその場面で使われることまでは確認されていない。 - 朝の確認は想定であり、顧客の実際の利用行動としては確認されていない。 - 一覧を能動的に見に行く方法と、通知・ダイジェストで知らせる方法のどちらが適切かも未確認である。 【利用成立条件】 - 対象となるメールやチャットを取得できること。 - やり取りを正しい案件へ関連付けられること。 - 顧客待ち事項を、会話全体ではなく事項単位で識別できること。 - 少なくとも以下を判定または登録できること。 - 顧客待ちか、自社側の対応待ちか - 誰から返事を待っているか - 何について待っているか - いつから待っているか - 返答が来たか - 返答によって解消したか - 部分回答、条件付き承認、差し戻し、再質問などをどう扱うか定義できること。 - 顧客待ち状態をデータとして保持し、更新できること。 - AIの誤判定や見逃しを利用者が確認・修正できること、または修正不要な精度があること。 - 顧客待ちではなくなった事項が、適切な時点で一覧から外れること。 - 電話、会議、対面、連携外ツールで返答された場合の反映方法が成立すること。 - 担当者とディレクターそれぞれの閲覧範囲や権限を扱えること。 - 顧客情報やメッセージをAI処理するために必要な権限・許可が得られること。 - 既存の未決事項、TODO、案件メモとの関係が理解でき、二重管理が過度に発生しないこと。 - AIの確認・修正を含めても、現在の確認作業より負担が増えすぎないこと。 - 利用者が朝、週次または必要時に実際に確認する導線が成立すること。 【既存商品・運用への影響】 - 専用画面を追加した場合、利用者が確認する場所が増える。 - 未決事項一覧と承認待ち一覧のどちらを見るべきか分かりにくくなる可能性がある。 - 既存一覧へのフィルターであれば確認先は増えにくいが、絞り込み操作やフィルターの存在を認識する必要がある。 - 未決事項、TODO、顧客待ちに同じ事項が重複して表示される可能性がある。 - 現在のメモ、Slackリマインダー、メール検索を減らせる可能性がある一方、併用による二重管理も起こり得る。 - AIを使う場合、利用者の作業が「自分で登録する」から「AIの候補を確認・修正する」へ変わる可能性がある。 - 誤表示が多い場合は除外作業が増える。 - 見逃しがある場合は、従来のメール確認をやめられない。 - 解消判定が不十分な場合、古い事項が一覧に残り、手動整理が必要になる。 - 誰が状態を修正・解消するか決めない場合、更新責任が曖昧になる。 - 横断表示が成立すれば、担当者は自分の担当案件、ディレクターは複数案件全体を見るという使い分けが可能になるが、実際にその運用が適合するかは未確認である。 【確認できている前提条件】 - A、B、Cの3社で、顧客待ちの把握に関する課題が存在する。 - 3社とも、顧客待ち確認のために手作業を行っている。 - 顧客Aでは、手動記録の更新忘れが起きている。 - 顧客Bでは、Slackリマインダーによる補完が行われている。 - 顧客Cでは、週1回のメール・案件メモ確認が行われている。 - 顧客Aは、返事待ちだけを一覧で見たいと述べ、一覧のような画面を要望している。 - 現在の既存機能には、複数案件横断で顧客待ちだけを見る専用画面がない。 - 顧客待ち専用の状態区分も現在は存在しない。 - 顧客待ちは既存の未決事項と情報が一部重複する。 - 顧客Aの過去メール10件を使った簡易検証では、明らかな顧客待ち6件はすべて顧客待ちと判定された。 - 顧客待ちではない残り4件のうち、1件が顧客待ちと誤判定された。 - この検証から確認できるのは、限定されたメールではAI判定が可能だった例と誤判定例があることまでである。 - 専用画面を追加した場合、確認画面が一つ増える。 【仮説に留まる前提条件】 - 横断一覧を提供すれば、顧客待ちの見落としや案件停止を減らせる。 - A、B、Cが実際に一覧を継続利用する。 - Aの専用画面要望が、フィルターでは満たせない。 - B、Cも専用画面を必要としている。 - 朝や週次の確認先として一覧が定着する。 - 能動的に一覧を見るだけで十分であり、通知やダイジェストは不要である。 - AIによる自動判定が、手動設定や候補提示より適している。 - 既存の未決事項抽出を利用すれば、顧客待ちを安定して分類できる。 - 誰待ちか、何について待っているかを安定して抽出できる。 - 顧客から返事が来たことと、その返事で事項が解消したことを区別できる。 - 顧客A以外、Slack、長いスレッド、複数論点でも同程度に判定できる。 - 誤判定を利用者が修正できれば実運用上問題にならない。 - AI確認・修正を含めても、現在より総作業量が減る。 - 新機能によって既存のメモ、TODO、Slackリマインダー、メール検索を置き換えられる。 - 専用画面を増やしても、利用者が既存機能との使い分けに迷わない。 - 3社で確認された課題が、対象顧客全体にも当てはまる。 - 既存機能を再利用できることが、本格実装へ進む根拠になる。 【反対事例】 - 10件の簡易検証では、顧客待ちではない1件を顧客待ちと誤判定している。完全自動判定が正確であるとはいえない。 - 顧客Aでは手動の「顧客確認待ち」記録を更新し忘れているため、手動更新を中心とする設計では同じ問題が残る可能性がある。 - 顧客B、CはすでにSlackリマインダーや週次確認を行っているため、新機能追加後も既存手段を継続する可能性がある。 - 既存機能ですでに未決事項を確認できるため、独立画面は情報や管理先を重複させる可能性がある。 - 専用画面は確認先を明確にする一方で、確認場所を増やす。 - メール・チャット以外で返答された場合、AIが把握できず、解消済み事項が一覧に残る可能性がある。 - 見逃しを抑えるため判定対象を広げると誤表示が増え、誤表示を抑えると見逃しが増える可能性がある。 - 顧客から返信があっても、部分回答や差し戻しであれば未解消のことがあり、「返信あり」と「解消済み」は一致しない。 - 顧客A以外のデータやSlackではまだ検証しておらず、Aの10件を他の顧客・媒体へ一般化できない。 【実装前に追加確認したいこと】 1. **課題の重大性** - 各社で顧客待ちがどの程度発生しているか。 - 見落としがどの程度起き、案件にどのような影響があったか。 - 現在の確認にどの程度の手作業が発生しているか。 2. **対象範囲** - 「承認待ち」に限定するか、「返答待ち」「資料待ち」なども含めるか。 - 顧客以外の外部関係者待ちを含めるか。 - 何らかの返信で解消とするか、要求を満たした場合だけ解消とするか。 - 部分回答、条件付き承認、差し戻し、再質問をどう扱うか。 3. **利用者と運用** - 主利用者が担当者か、ディレクターか、両方か。 - 実際に使う場面が朝、週次、随時のどれか。 - 一覧を見に行く運用で十分か、通知やダイジェストが必要か。 - 誤判定の修正や解消操作を誰が行うか。 4. **表示方法** - 顧客Aが求める「一覧」が独立画面を意味するのか、既存一覧の絞り込みでもよいのか。 - B、Cも横断一覧を使いたいか。 - 専用画面、フィルター、保存済みフィルター、簡易表示のどれが業務導線に合うか。 - 未決事項、TODO、顧客待ちの使い分けを利用者が理解できるか。 5. **AI判定** - A以外の顧客データでも判定できるか。 - メール以外のSlack等でも判定できるか。 - 長いスレッド、複数論点、転送メールを扱えるか。 - 誰待ち、待っている内容、発生日を事項単位で抽出できるか。 - 返答後の解消、部分解消、差し戻し、再オープンを追跡できるか。 - 見逃しと誤表示のどちらが利用者にとって重大か。 - AI結果を確認・修正する作業が許容されるか。 6. **データ・連携** - メールやチャットを正しい案件へ安定して紐付けられるか。 - 必要なやり取りが連携対象内に存在するか。 - 電話、会議、対面、連携外ツールの情報をどう反映するか。 - 必要な連携権限やAI処理への許可を得られるか。 7. **実際の利用価値** - Aが試作品を継続的に確認するか。 - B、Cも同じ導線を利用するか。 - 現在の手作業が減るか、確認・修正作業との二重管理になるか。 - 既存のメモやリマインダーを減らせるか。 - 元のメールやSlackを毎回確認せずに判断できるか。 【小さく検証できる可能性があること】 - 既存の未決事項に手動で「顧客待ち」タグを付け、横断表示自体に価値があるか確認する。 - 専用画面を作らず、既存一覧の仮フィルターや保存済みフィルターで利用してもらう。 - スプレッドシート等の手動一覧をA、B、Cに提供し、実際の案件確認で参照されるかを見る。 - AIが候補を出し、人が確認したものだけ一覧へ載せる運用を試す。 - 過去データだけでなく、現在進行中の案件で発生から解消までを追跡する。 - A以外のB、Cのデータ、Slack、長いスレッド、複数論点を含むやり取りへ検証対象を広げる。 - 「誰待ち」「内容」「発生日」「経過日数」「元の会話」「状態」を手動整理し、実際に必要な情報を確認する。 - 同じ情報を用いて、以下の簡易モックを比較する。 - 専用一覧 - 既存一覧のフィルター - 保存済みフィルター - 案件一覧上の簡易表示 - 誤判定例を利用者に提示し、削除・修正できれば許容できるか確認する。 - 「返答あり・未解消」「部分解消」「解消済み」「差し戻し」「再度顧客待ち」の状態を提示し、理解できるか確認する。 - 電話や会議で解消した事項だけ手動更新し、その運用が成立するか試す。 - 検証中に以下を観察・記録する。 - 一覧を実際に確認したか - 元のメール・Slackへ戻ったか - 誤表示、見逃し、解消漏れがあったか - 修正が何度必要だったか - 既存のメモやリマインダーを併用したか - 現在の確認作業を減らせたか 【現時点では判断できないこと】 - 顧客Aの要望どおり、専用画面を実装すべきか。 - A、B、Cの3社で課題が確認されたことをもって、本格実装へ進んでよいか。 - 専用画面と既存一覧へのフィルターのどちらが適切か。 - 一覧より通知やダイジェストが適しているか。 - AIの完全自動判定、AI候補提示、手動設定のどれが適切か。 - 10件の簡易検証結果が、実運用上十分な精度を示すか。 - 顧客Aの結果をB、Cや他の対象顧客へ一般化できるか。 - 誤表示と見逃しについて、どの程度が許容されるか。 - 返答済み・解消済みを安定して自動判定できるか。 - 新機能が見落としや案件停止を実際に減らすか。 - 利用者が継続的に確認するか。 - 既存のメモ、TODO、Slackリマインダー、メール検索を置き換えられるか。 - AI結果の確認・修正を含めても、総作業負担が減るか。 - 専用画面の追加が、確認先の明確化になるか、確認先の分散になるか。 - 対象顧客全体に同じ必要性があるか。 - 本格実装の合否を決める基準。入力には成功基準が定義されていないため、現時点では確定できない。 - 開発工数、費用、売上効果、利用率、市場規模、優先順位、実装期間については、与えられた情報から判断できない。 【総合整理】 - 「顧客待ちの把握に手作業と見落としがある」という課題は、A、B、Cの3社で確認されている。 - 顧客Aからは一覧画面への具体的な要望もあるが、B、Cで確認されているのは課題までであり、同じ解決方法への要望ではない。 - 既存機能は未決事項の抽出と案件単位での確認には対応しているため、新機能は完全に別の情報を追加するものではない。既存の未決事項に顧客待ちの分類と横断確認を加える関係になり得る。 - したがって、専用画面を新設する前に、既存一覧のフィルター、手動タグ、AI候補提示などで「横断確認自体が使われるか」を切り分ける余地がある。 - 10件の簡易検証は、AI判定の可能性を示す初期的な材料にはなる。一方、他社・他媒体への適用、事項単位の追跡、返答後の解消判定、継続運用の根拠にはならない。 - 特に未確認なのは、管理対象の定義、実際の利用者と利用場面、専用画面の必要性、AI判定の許容水準、解消状態の追跡、既存運用を減らせるかである。 - 現段階では「課題があること」と「判定できる可能性があること」は確認されているが、「承認待ち専用画面を本格実装すべきこと」は確認されていない。 - 本格的な設計・開発へ進む前に、手動一覧、既存一覧の仮フィルター、AI候補の人手確認、複数顧客・複数媒体でのデータ検証を通じて、利用価値と利用成立条件を分けて確認する必要がある。 - 以上は実装しないという結論でも、実装すべきという結論でもない。現時点では、解決策と成立条件に未確認事項が残っており、実装の最終判断はできない。

【商品・サービス】 小規模な制作会社・受託開発会社向けの 案件情報整理SaaS。 顧客とのメールやチャットから、 案件ごとの決定事項、 TODO、 未決事項、 経緯を整理して確認できる。 【現在の対象顧客】 3〜15人程度の制作会社、 受託開発会社、 小規模コンサルティング会社。 複数案件を同時に進め、 顧客とのやり取りをメールやSlackで行っているチーム。 【追加を検討している機能】 複数案件を横断して、 「顧客からの返答待ち・承認待ち」の事項だけを確認できる機能。 既存の未決事項に 「顧客待ち」という状態を付け、 横断一覧またはフィルターで確認できる形を想定している。 【その機能で解決したい課題】 顧客の返答待ちを見落として、 案件が止まったままになること。 担当案件が増えると、 どの案件で何の返事を待っているのか分からなくなり、 メールやSlackを見直す負担が増えること。 【その課題が確認された顧客】 顧客A： 5人のWeb制作会社。 顧客B： 7人の受託開発会社。 顧客C： 4人のデザイン会社。 顧客D： 12人のWeb制作会社。 【顧客から実際に聞いた発言】 顧客A： 「返事待ちのものを案件をまたいで見たい」 顧客B： 「未決事項の中でも、こっち待ちか相手待ちかを分けたい」 顧客C： 「クライアント待ちだけまとめて確認できると助かる」 顧客D： 「週次で顧客確認待ちを全部拾っているので、 一覧で見られるなら使いたい」 A、C、Dは、 専用画面である必要まではないが、 案件横断で顧客待ちだけ確認したいと明言している。 【確認できている利用行動】 顧客A： 毎朝、 案件メモとメールを確認して 顧客待ち事項を手動で確認している。 顧客B： TODOに 「相手待ち」 と手入力して管理している。 顧客C： Slackのリマインダーを使って 返答待ちを管理している。 顧客D： 週次会議の前に、 担当者が全案件のメールと案件メモを確認し、 顧客待ち事項を一覧化している。 4社とも、 顧客待ち確認のための手作業を継続している。 【現在の代替手段】 案件メモへの手入力 TODOへの「相手待ち」登録 Slackリマインダー メール・Slack検索 週次での手動一覧作成 【既存機能でできること】 AIがメールやチャットから 未決事項を抽出できる。 未決事項をTODOとして保存できる。 案件ごとの未決事項を一覧で確認できる。 未決事項には元のメール・チャットへの参照情報がある。 【既存機能ではできないと考えていること】 未決事項について、 ・誰の返答待ちか ・顧客待ちか自社待ちか ・現在も未解消か を区別していない。 また、 複数案件を横断して 顧客待ちだけを見る方法がない。 既存の案件単位の未決事項確認だけでは、 顧客Dの週次横断確認を置き換えられていない。 【想定している利用場面】 顧客A： 毎朝の案件確認。 顧客D： 週次会議前の全案件確認。 顧客B、C： 返答待ち状況を確認するとき。 これらは想定だけではなく、 現在実際に行っている確認行動から確認できている。 【想定している利用者】 複数案件を担当する担当者。 複数担当者の案件を見るディレクター。 顧客Dでは、 ディレクターが実際に週次で横断確認している。 【利用に必要だと考えている条件】 少なくとも、 ・顧客待ちか自社待ちか ・何について返答を待っているか ・現在も未解消か ・元の会話を確認できるか が分かる必要があると考えている。 A、B、Dにも確認したところ、 ・誰待ちか ・内容 ・元の会話 ・現在の状態 が分かれば、 現在の確認作業に使えると回答している。 【既存仕様との関係】 既存の未決事項を元データとして使える。 新しい情報として必要なのは、 主に ・待っている相手 ・顧客待ち／自社待ち ・状態 の分類と考えている。 既存の未決事項自体を 別管理にする必要はないと考えている。 【既存運用への影響として考えていること】 専用画面を追加する場合は、 確認先が増える。 一方、 既存未決事項一覧のフィルターとして提供する場合は、 現在の確認画面を増やさずに済む可能性がある。 顧客A、Bには簡易モックで両方を見せたところ、 どちらも機能自体は使いたいと回答した。 Aはフィルター型を好み、 Bは専用一覧型を好んだ。 そのため、 表示形式についてはまだ確定していない。 【競合・他サービスで確認できていること】 競合Aでは、 「顧客確認待ち」ステータスを手動設定できる。 競合Bでは、 TODOの担当者を外部相手には設定できないため、 顧客待ちはタグで管理している利用例がある。 競合に同じ自動分類機能が必要かどうかは 今回の判断材料としては確認できていない。 【すでに試した簡易検証】 1. A、B、C、Dの過去のメール・Slackから、 顧客待ち候補をAIで抽出した。 合計40件を確認した。 2. 抽出した結果を スプレッドシート上で顧客待ち一覧として整理し、 A、B、C、Dに見てもらった。 3. A、Dでは、 実際の1週間の案件確認でも 同じ形式の手動一覧を試した。 【検証結果】 40件のうち、 実際に顧客待ちだった24件について、 AIは22件を顧客待ち候補として抽出した。 顧客待ちではなかった16件のうち、 3件を顧客待ち候補として出した。 この結果だけで 本番運用に十分な精度とは判断していない。 ただし、 A、B、C、D全社で 「顧客待ちだけを横断して見られること自体は役に立つ」 という評価があった。 A、Dでは1週間の手動運用を実施した。 Aは、 毎朝のメール確認の一部を 一覧確認に置き換えた。 Dは、 週次会議前の全案件メール確認を完全にはやめなかったが、 一覧を最初の確認先として利用した。 Dでは、 一覧から元メールに戻って内容を確認する使い方が多かった。 【自分が実装したい理由】 4社で共通課題が確認できている。 4社とも現在手作業で対応している。 横断一覧自体の利用価値は、 簡易モックと手動運用で確認できている。 既存未決事項を元にできるため、 現在のサービス構造とも関係が深い。 そのため、 本格的な仕様検討へ進んでもよい段階ではないかと考えている。 【現在不安に思っていること】 AI判定の扱いを 完全自動にするべきか分からない。 フィルター型と専用一覧型の どちらがよいか決まっていない。 A、Dでは使われたが、 長期間継続して使われるかはまだ未確認。 顧客待ちから解消済みへの更新が、 実運用でどこまで自動化できるかは未確認。 【今回特に確認したいこと】 ・実装前提として確認できていることは何か ・まだ仮説に留まることは何か ・4社で共通課題が確認できていることをどこまで根拠にしてよいか ・手動一覧が実際に使われたことをどこまで評価してよいか ・AI判定精度は本格仕様検討へ進む前提として十分か ・完全自動化を前提にしなくてもよいか ・フィルター型と専用一覧型を今決める必要があるか ・現時点で「まだ課題確認からやり直すべき」なのか ・本格的な仕様検討へ進む前に追加確認すべきことは何か

【追加を検討している機能】 - 既存の未決事項に、以下の分類・状態を追加する機能 - 顧客待ち／自社待ち - 待っている相手 - 未解消／解消済みなどの現在状態 - 複数案件を横断して、顧客からの返答待ち・承認待ちだけを確認する機能 - 表示方法の候補 - 既存の未決事項一覧にフィルターを追加する - 顧客待ち事項の専用一覧を設ける - AIによって顧客待ち候補を抽出する機能 - 自動確定するか、候補提示に留めるかは未決定 - 一覧から元のメール・チャットを確認できる導線 - 顧客からの返信などを基に、状態更新を支援する可能性 - 解消済みまで自動判定するかは未確認 現時点では、既存の未決事項とは別のデータとして管理する必要性は確認されていない。 --- 【解決したい顧客課題】 - 複数案件の中で、「どの案件で、何について、誰の返答を待っているか」を把握し続ける負担が大きい。 - 顧客待ち事項が、メール、Slack、案件メモ、TODOなどに分散している。 - 顧客待ちか自社待ちか、現在も未解消かを判断するために、元の会話を読み直す必要がある。 - 担当案件が増えるほど、案件横断での確認負担が増える。 - 顧客待ち事項を見落とし、案件が止まったままになる可能性がある。 - ディレクターが複数担当者・複数案件を確認する場合、手動集約の負担が大きい。 中心的な課題は、一覧がないこと自体ではなく、**顧客側の対応を待っている事項を、漏れなく少ない負担で把握・追跡できないこと**である。 --- 【課題について確認できていること】 - A、B、C、Dの4社すべてが、顧客待ち確認のための手作業を継続している。 - A、C、Dは、案件横断で顧客待ちだけを確認したいと明言している。 - Bは、未決事項を自社待ちと相手待ちに分けたいと明言している。 - 4社すべてが、スプレッドシートで作成した顧客待ち一覧を「役に立つ」と評価している。 - A、Dでは、一覧が実際の業務で1週間利用された。 - Aは毎朝のメール確認の一部を一覧確認に置き換えた。 - Dは週次会議前の最初の確認先として利用した。 - Dでは、一覧から元メールに戻って確認する行動が多かった。 - A、B、Dは、以下が分かれば現在の確認作業に使えると回答している。 - 誰待ちか - 待っている内容 - 現在の状態 - 元の会話 - 既存の案件単位の未決事項一覧だけでは、Dの週次横断確認を置き換えられていない。 一方、以下は確認されていない。 - 見落としや案件停止の発生頻度・影響 - 4社以外での課題発生率 - 課題が他の改善事項より優先されるか - 一覧によって見落としや案件停止が実際に減るか 4社の結果は、**少なくともこの4社に共通課題が存在する根拠**にはなるが、対象顧客全体への一般化まではできない。 --- 【現在の代替手段】 - 案件メモへの手入力 - TODOへの「相手待ち」の登録 - Slackリマインダー - メール・Slack検索 - 案件ごとのメール、チャット、メモの読み直し - 週次での手動一覧作成 - スプレッドシートによる顧客待ち一覧 - 元の会話に戻って、現在も未解消かを人が判断する運用 これらにより業務自体は成立しているが、情報の分散、手入力、更新漏れ、横断確認の負担が残っている。 --- 【既存機能で対応できること】 - AIがメールやチャットから未決事項を抽出できる。 - 未決事項をTODOとして保存できる。 - 案件ごとの未決事項を一覧で確認できる。 - 未決事項から元のメール・チャットを参照できる。 - 既存の未決事項を、新機能の元データとして利用できる可能性がある。 既存機能だけでは、以下を直接扱えない。 - 顧客待ちか自社待ちか - 誰の返答を待っているか - 現在も未解消か - 複数案件を横断した顧客待ち確認 ただし、既存機能で不足していることだけを理由に、新機能が必要だとは判断できない。手動タグ、既存一覧の拡張、候補提示などでも課題を軽減できる可能性がある。 --- 【新機能で変えようとしていること】 - 案件単位の未決事項確認から、複数案件を横断した顧客待ち確認を可能にする。 - 人が会話を読み直して行っている「誰待ちか」の判断を、AI候補や分類情報で支援する。 - TODOへの「相手待ち」入力や手動一覧作成を、既存未決事項の状態管理に統合する可能性を持たせる。 - メールやSlackを最初から全件確認するのではなく、確認対象を一覧で絞り込めるようにする。 - 元の会話を確認する行動は残しつつ、そこへ到達するまでの探索負担を減らす。 価値が比較的強く確認されているのは、**顧客待ち事項を案件横断で確認し、必要に応じて元会話へ戻れること**である。専用画面、完全自動分類、自動解消は、まだ必須とは確認されていない。 --- 【想定利用場面】 - 顧客Aのような、毎朝の案件確認 - 顧客Dのような、週次会議前の全案件確認 - 担当者が自分の複数案件について返答待ちを確認するとき - ディレクターが複数担当者・複数案件を横断して確認するとき - 顧客への催促やフォロー前に、待っている内容と元会話を確認するとき - この利用は想定であり、実利用までは確認されていない - 案件が止まっている際に、誰の対応待ちかを確認するとき AとDについては既存の定期確認行動に一覧が組み込まれたが、BとCの実業務での利用頻度は確認されていない。 --- 【利用成立条件】 少なくとも、以下を確認できる必要があると考えられる。 - 顧客待ちか自社待ちか - 誰の返答を待っているか - 何について待っているか - 現在も未解消か - 元のメール・チャット - 対象の案件 運用上は、以下も成立条件になる可能性がある。 - 会話と案件が適切にひも付いていること - 利用者が対象案件と元会話を閲覧できること - 誤判定を修正できること - 見落とされた事項を追加できること - 解消済みへの更新が行われ、古い事項が残り続けないこと - AIが確定する場合も、人が確認・修正できること - 分類・更新作業が、現在の確認作業より過度な負担にならないこと 担当者別表示、期限、待機日数、最終連絡日などが必要かは未確認である。 --- 【既存商品・運用への影響】 - 既存の未決事項に分類・状態を追加する場合、現在のデータと元会話参照を再利用できる可能性がある。 - フィルター型なら、既存画面の延長として提供できる可能性がある。 - 専用一覧型なら、横断確認の入口は明確になる一方、確認先が増える。 - TODOへの「相手待ち」入力やSlackリマインダーと重複する可能性がある。 - AI候補の確認、誤判定の修正、解消済みへの更新など、新しい操作が発生する可能性がある。 - 一覧が古くなると、一覧自体への信頼が下がる可能性がある。 - ディレクター向け横断表示では、既存の閲覧権限との整合が必要になる可能性がある。 - Dの実利用から、元会話への導線は既存運用との接続点として重要である。 - 一覧は元会話の確認を全面的に置き換えるのではなく、確認対象を絞る入口になる可能性がある。 --- 【確認できている前提条件】 - 4社には、顧客待ちを確認・管理するための手作業が存在する。 - 4社から、顧客待ちを案件横断で確認することの価値が評価されている。 - A、Dでは一覧が実業務で利用された。 - Aでは既存作業の一部を置き換えた。 - Dでは最初の確認先になった。 - 元の会話へ戻れることが実利用上必要になる場合がある。 - 既存機能では、顧客待ち／自社待ち、待っている相手、現在状態を区別できない。 - 既存の未決事項を元データとして利用できる可能性がある。 - AI候補抽出には、見落としと誤判定の両方がある。 - 実際の顧客待ち24件中22件を候補として抽出した。 - 顧客待ちではない16件中3件を候補として出した。 - 完全自動化は、確認された顧客価値の必須条件ではない。 - A、Bでは表示形式にかかわらず機能自体への利用意向があった。 - フィルター型と専用一覧型の好みは分かれている。 --- 【仮説に留まる前提条件】 - 一覧によって顧客待ちの見落としが減る。 - 案件の停止期間が短くなる。 - 確認時間やメール・Slack検索時間が継続的に減る。 - A、Dでの1週間の利用が長期的に定着する。 - B、Cも実業務で継続利用する。 - 4社の課題が対象顧客全体に共通する。 - AI候補の確認・修正負担が、現在の手作業より小さい。 - 顧客からの返信を検出すれば、解消済みへ自動更新できる。 - 顧客待ち／自社待ちの二分類だけで実務上十分である。 - TODO、Slackリマインダー、手動一覧を置き換えられる。 - 通知がなくても、利用者が自発的に一覧を確認し続ける。 - フィルター型か専用一覧型の一方だけで、担当者とディレクター双方の用途を満たせる。 - 新しい分類・更新操作を追加しても、既存運用が複雑にならない。 - 一覧が長期間、正しい状態に保たれる。 --- 【反対事例】 - Dでは、一覧を使っても全案件のメール確認を完全にはやめていない。 - AIは実際の顧客待ち24件中2件を見落としている。 - AIは顧客待ちではない16件中3件を候補として出している。 - AとBで表示形式の好みが分かれている。 - B、Cでは、実業務での継続利用を試していない。 - A、Dの実利用は1週間に限られている。 - 4社とも既存の代替手段で業務を継続できている。 - 一覧が便利だという評価は得られているが、長期利用や既存手段からの切り替えまでは確認されていない。 これらは機能価値を否定するものではないが、完全な置き換え、完全自動化、長期定着を前提にできない根拠になる。 --- 【実装前に追加確認したいこと】 1. **継続利用** - A、Dが引き続き利用するか。 - B、Cが実業務でも利用するか。 2. **実際の効果** - 確認時間や検索負担がどう変わるか。 - 見落としや案件停止に変化があるか。 - 既存のTODO、リマインダー、手動一覧のどれが残るか。 3. **AI判定の扱い** - 自動確定、候補提示、手動分類のどれが受け入れられるか。 - 誤判定と見落としのどちらが業務上より問題か。 - 確認・修正作業がどの程度発生するか。 4. **状態更新** - 顧客待ちの開始・修正・解消を誰が管理するか。 - 返信は来たが未解決の場合をどう扱うか。 - メールやSlack以外で解決した場合をどう反映するか。 - 古い事項が残らない運用が成立するか。 5. **必要な情報** - 誰待ち、内容、状態、元会話だけで十分か。 - 担当者、期限、待機日数、最終連絡日などが必要か。 - 顧客待ち／自社待ち以外の分類が必要か。 6. **表示形式** - フィルター型と専用一覧型を、利用場面ごとにどう使い分けるか。 - 担当者とディレクターで適した入口が異なるか。 - 現時点で一方に決める必要はない。 7. **既存機能・権限との整合** - 未決事項、TODO、顧客待ちの意味を混同しないか。 - 横断表示と元会話参照が既存権限内で成立するか。 8. **対象顧客への一般化** - 4社以外の同規模・同業種でも同じ課題と行動があるか。 - 案件数や利用チャネルによって必要性がどう変わるか。 --- 【小さく検証できる可能性があること】 - A、Dへの手動一覧提供を継続し、確認行動が続くかを見る。 - B、Cにも実業務で手動一覧を使ってもらう。 - AI候補を人が承認・修正する運用を試す。 - 誤判定の解除、見落としの追加、解消済みへの変更を手動で行い、負担や迷いを観察する。 - 既存の未決事項に、手動で顧客待ち分類を追加して横断集約する。 - フィルター型と専用一覧型のモックを、毎朝確認・週次確認などの具体的場面で比較する。 - 一覧項目を変え、実際に参照・更新される情報を確認する。 - 40件のうち、見落とした2件と誤判定した3件の原因を分析する。 - 過去データから、顧客返信と実際の解消が一致する割合や例外パターンを調べる。 - 一覧と既存のTODO、Slackリマインダー、手動一覧を並行利用し、どの管理手段が残るかを見る。 - 誰がいつ状態を更新するのが自然か、手動運用で確認する。 - 既存の権限情報を確認し、ディレクター向け横断表示が成立するかを調べる。 これらは、完全自動化や本格実装を前提にせず実施できる。 --- 【現時点では判断できないこと】 - 本格実装すべきかどうか。 - 実装投資に見合う事業効果があるか。 - 対象顧客全体でどの程度必要とされるか。 - 長期的に継続利用されるか。 - 見落としや案件停止をどの程度減らせるか。 - 現在のAI精度が本番運用に十分か。 - AI判定を完全自動化してよいか。 - 解消済みへの更新をどこまで自動化できるか。 - フィルター型と専用一覧型のどちらが適切か。 - 通知やリマインドが必要か。 - 状態更新の負担が、削減できる手作業を上回らないか。 - 4社の結果を市場全体へ一般化できるか。 - 契約継続、導入判断、アップセルなどに影響するか。 --- 【総合整理】 課題確認から全面的にやり直す必要がある状態ではない。4社で共通する手作業と要望が確認され、A、Dでは短期間ながら一覧が実際の確認業務に組み込まれている。そのため、**顧客待ちを案件横断で確認する価値について、本格的な仕様検討と追加検証へ進む根拠はある**。 ただし、確認できているのは一覧の基本価値と短期利用までである。長期定着、見落とし削減、状態更新の成立性、対象顧客全体への一般化は未確認である。 AIの40件での結果は、候補抽出を検討する材料にはなるが、完全自動確定を前提にするには不足している。現時点では、候補提示と人による確認・修正を含む形も有力な検証対象であり、完全自動化を前提にする必要はない。 また、フィルター型と専用一覧型を今決める必要もない。確認されている要求は「案件横断で顧客待ちを確認できること」であり、表示形式は利用場面と継続利用を比較しながら検討できる。 したがって現段階は、**実装を決定する段階ではなく、既存未決事項を基礎に、候補提示・手動修正・状態更新・元会話参照を含む最小限の運用を小さく検証しながら、本格仕様検討を進める段階**と整理できる。