新機能事前検証設計

【商品・サービス】 小規模な制作会社・受託開発会社向けの 案件情報整理SaaS。 顧客とのメールやチャットから、 案件ごとの決定事項、 TODO、 未決事項、 経緯を整理して確認できる。 【現在の対象顧客】 3〜10人程度の制作会社、 受託開発会社、 デザイン会社。 複数の顧客案件を並行して進めているチーム。 【検証したい新機能】 「今日確認した方がよい案件」を まとめて表示する確認リスト機能。 未決事項、 期限が近いTODO、 顧客からの返答待ちなどから、 確認対象をまとめて表示することを考えている。 【その機能で解決したい課題】 複数案件を持っていると、 今日どの案件を確認すべきか判断するために、 各案件を順番に開く必要があること。 確認漏れによって、 返信や対応が遅れることがあること。 【現在確認できている顧客課題】 顧客A： 「朝、全部の案件を開くのが面倒」 顧客B： 「今日見るべき案件だけ分かると助かる」 顧客C： 「案件が増えると抜けが出る」 A、B、Cとも、 複数案件を確認する負担について発言している。 【現在確認できている利用行動】 顧客A： 毎朝、 案件一覧を上から順番に開いて確認している。 顧客B： 重要な案件をSlackの自分宛メッセージに残している。 顧客C： TODOの期限順に確認し、 必要に応じてメールも見直している。 【現在の代替手段】 案件一覧を順番に確認する。 Slackに自分用メモを残す。 TODO期限順で確認する。 メールを検索する。 【既存機能でできること】 案件一覧を表示できる。 案件ごとの未決事項を確認できる。 TODOと期限を確認できる。 顧客とのやり取りから 未決事項をAIで抽出できる。 【実装前提として確認できていること】 A、B、Cで、 複数案件から確認対象を探す負担がある。 3社とも、 何らかの方法で 「次に確認する案件」を自分で選んでいる。 既存機能には 案件横断で未決事項やTODOをまとめて見る画面はない。 【まだ仮説に留まっていること】 「今日確認した方がよい案件」を システム側でまとめれば、 現在の確認負担を減らせる。 顧客が毎日このリストを見る。 AIが確認対象を自動選定すると便利。 確認リストがあれば、 案件一覧を順番に見る必要が減る。 【反対事例】 顧客Cは、 「TODO期限順で大体足りている」 とも話している。 顧客Aは、 「結局すべての案件をざっと見たい日もある」 と話している。 【特に重要だと考えている未確認事項】 本当に案件横断の確認リストが使われるか。 どんな案件が 「今日確認すべき」と判断されるべきか。 AIによる自動選定が必要か。 手動で重要案件を選ぶだけでも十分か。 確認リストを見ても、 結局すべての案件を開くのではないか。 【想定している利用者】 複数案件を持つ担当者。 複数担当者の案件を見るディレクター。 【想定している利用場面】 朝の業務開始時。 昼や夕方の進捗確認時。 【想定している利用方法】 確認リストを開く。 表示された案件を確認する。 必要な案件だけ詳細画面を開く。 確認済みになったものは リストから外す。 【現在考えている機能の形】 「今日の確認」という画面を作り、 ・案件名 ・確認理由 ・未決事項 ・期限 ・誰待ちか を表示する。 【別の実現方法として考えている案】 既存案件一覧に 「確認が必要」フィルターを追加する。 ユーザー自身が 「今日確認」に追加する。 AIは確認候補だけ提示し、 ユーザーが選択する。 【すでに行った簡易検証】 A、B、Cに、 紙に近い簡単な画面イメージを見せた。 【簡易検証の結果】 A： 「朝これがあれば便利そう」 B： 「見ると思う」 C： 「TODO期限順と何が違うかによる」 実際の案件データを入れて 業務で使ってもらったことはない。 【利用できる既存データ】 案件一覧。 未決事項。 TODOと期限。 元のメール・チャット。 【手動で代替できること】 担当者が 「今日確認すべき案件」を手動で選ぶ。 確認理由も人が入力する。 スプレッドシートで 案件横断の確認リストを作る。 【簡易モックで試せそうなこと】 既存データを使って A、B、Cそれぞれの 「今日の確認リスト」を手動作成する。 専用画面型と、 既存案件一覧のフィルター型を比較する。 【本格実装しないと確認できないと考えていること】 AIが継続的に確認対象を自動選定する場合の 本番運用上の精度。 ただし、 AI候補を手動で作ることで 利用価値自体は先に確認できると考えている。 【検証に使える顧客・利用者】 顧客A、B、C。 各社1名の担当者。 【検証上の制約】 新機能を本格開発する前に検証したい。 既存機能は利用できる。 手動で確認リストを作ることはできる。 【今回の検証後に判断したいこと】 案件横断の確認リストを 本格的な仕様検討へ進める価値があるか。 AI自動選定を前提にする必要があるか。 専用画面を検討する必要があるか。 【今回特に設計したいこと】 ・何を最初に検証すべきか ・「便利そう」という発言をどこまで評価するか ・実際に使われるかをどう確認するか ・手動リストで何を観察すべきか ・Cの「TODO期限順で足りる」をどう扱うか ・Aの「全部見る日もある」をどう扱うか ・AI自動選定をいつ検証するべきか ・専用画面とフィルターをいつ比較するべきか ・本格実装前にどこまで確認できるか

【検証したい新機能】 複数案件を横断して、「今日確認した方がよい案件」をまとめて表示する確認リスト機能。 想定している表示内容は以下。 - 案件名 - 確認理由 - 未決事項 - 期限 - 誰待ちか 候補となる実現方法は以下。 - 専用の「今日の確認」画面 - 既存案件一覧の「確認が必要」フィルター - ユーザー自身による「今日確認」への追加 - 単純な条件による候補提示 - AIによる候補提示または自動選定 最初からAIや専用画面を前提とせず、まず「案件横断の確認リスト」という体験自体に利用価値があるかを検証する。 --- 【解決したい顧客課題】 - 複数案件を持っていると、今日確認すべき案件を判断するために各案件を順番に開く必要がある。 - 案件数が増えると、確認漏れや抜けが発生する。 - 確認漏れによって、顧客への返信や必要な対応が遅れることがある。 - 確認対象を覚えるために、Slackの自分宛メッセージ、TODO期限順、メール検索など複数の手段を使っている。 - 案件横断で未決事項やTODOをまとめて確認できないため、確認対象の選定を利用者自身が行っている。 --- 【現在確認できていること】 ### 課題と既存行動 - A、B、Cの3社すべてで、複数案件から次に確認する案件を選ぶ負担がある。 - Aは毎朝、案件一覧を上から順番に開いて確認している。 - Bは重要案件をSlackの自分宛メッセージに残している。 - CはTODOを期限順に確認し、必要に応じてメールを見直している。 - 3社とも、何らかの方法で「次に確認する案件」を自分で選んでいる。 - 現在、案件横断で未決事項やTODOをまとめて見る画面はない。 ### 利用可能なデータと機能 - 案件一覧 - 案件ごとの未決事項 - TODOと期限 - 元のメール・チャット - AIによって抽出された未決事項 ### 事前反応 - A：「朝これがあれば便利そう」 - B：「見ると思う」 - C：「TODO期限順と何が違うかによる」 これらは受容性や期待を示す材料ではあるが、実利用、継続利用、既存行動の変化を示す証拠ではない。 ### 検証可能性 - 人が「今日確認すべき案件」と確認理由を選び、手動リストを作成できる。 - A、B、Cの実案件データを使った検証ができる。 - スプレッドシートや簡易モックで、AIや専用画面を実装せずに試せる。 - 専用画面型と既存案件一覧のフィルター型は、簡易モックで比較できる。 --- 【重要な未確認事項】 ### 確認リスト自体の利用価値 - 実案件・実業務の中で、確認リストが実際に参照されるか。 - 説明や催促がなくても、通常の確認場面で利用されるか。 - 一度だけでなく、異なる通常業務の機会でも繰り返し利用されるか。 - 確認作業の起点になるのか、途中の補助として使われるのか。 - リストを見ても、結局すべての案件を開くのか。 ### 既存行動への影響 - 案件一覧を上から順番に開く行動が減るか。 - 重要な案件を先に確認できるか。 - Slackメモ、TODO期限順、メール検索の利用方法が変わるか。 - 確認漏れや対応遅れを防ぐ兆候があるか。 - 全件確認の代替なのか、優先順位付けの補助なのか。 ### 候補の選定基準 - 何をもって「今日確認すべき」と判断するのか。 - 未決事項、TODO期限、返答待ち、誰待ちかで十分か。 - メール・チャット上の経緯が必要か。 - 既存データには含まれない判断材料があるか。 - 「今日確認すべき」と「今日対応すべき」をどう区別しているか。 - 不要候補や候補漏れがどの程度発生するか。 ### 反対事例との関係 - Cにとって、TODO期限順では拾えない追加価値があるか。 - Aが全件確認する日でも、優先順位付けには使われるか。 - 利用者や利用場面によって、新機能が不要な場合があるか。 ### 自動化と画面形式 - ユーザーの手動追加だけで十分か。 - 単純な条件による候補提示で十分か。 - AIによる候補提示が必要か。 - AIによる自動確定まで必要か。 - 専用画面が必要か、既存一覧のフィルターで十分か。 - 確認済み、持ち越し、再確認をどのように扱うと自然か。 --- 【先に確認する仮説】 最初に確認する仮説は以下。 1. 実案件から作った案件横断の確認リストは、通常の確認業務で実際に参照される。 2. リストを参照することで、必要な案件を先に確認できる。 3. リストによって、案件を順番に開く、Slackにメモする、メールを検索するなど、既存行動の一部が変化する。 4. 全件確認が残る場合でも、確認順の決定や見落とし防止に価値がある。 5. 候補の追加・削除・持ち越しを観察することで、「今日確認すべき案件」の主要な判断基準を把握できる。 6. Cについて、TODO期限順では拾えない有用な確認対象が存在する可能性がある。 7. 手動リストで価値が成立するかを確認してから、自動化の必要性を判断できる。 AIの必要性、専用画面の必要性、完全自動化の妥当性は、最初の仮説には含めない。 --- 【検証方法】 ### 1. 現在の確認行動の把握 新しいリストを提供せず、A、B、Cが通常どのように確認対象を選んでいるかを観察する。 記録する内容は以下。 - 最初に開いたもの - 確認対象を決めるまでに参照した情報 - 開いた案件と順番 - 全案件を開いたか - Slackメモ、TODO期限順、メール検索の利用 - 全件確認を行った理由 - 既存データにはない判断材料 ### 2. 手動確認リストの限定試用 既存データをもとに、人がその日の確認候補と理由を作り、スプレッドシートなどで提供する。 AIによる選定、専用画面、自動更新などは人手で代替する。通常業務の中で使ってもらい、発言よりも実際の参照と行動変化を観察する。 ### 3. CのTODO期限順との比較 同じ時点の実案件について、以下を比較する。 - TODO期限順で得られる案件 - 未決事項や返答待ちを含む手動確認リスト - C本人が実際に確認すべきと判断した案件 期限順では拾えなかった有用案件があるか、結果がほぼ同じかを確認する。 ### 4. 候補作成方法の段階的比較 確認リスト自体に価値が見られた場合に限り、以下を比較する。 - ユーザーによる手動追加 - TODO期限や未決事項などの単純ルール - 人がメール・チャットの経緯まで読んだ候補 - システムやAIによる候補提示 - AIによる自動確定 人による文脈判断は、AI候補提示の疑似体験として利用する。ただし、実際のAI精度を確認したことにはしない。 ### 5. 専用画面とフィルターの比較 確認リストが利用され、必要な情報が把握できた後に、同じ候補・同じ情報を使って比較する。 - 専用の「今日の確認」画面 - 既存案件一覧の「確認が必要」フィルター 見た目の好みではなく、確認開始、案件選択、全件一覧との往復、確認済み処理などの行動差を見る。 --- 【試す利用者】 - 顧客Aの担当者 - 顧客Bの担当者 - 顧客Cの担当者 それぞれ、複数案件を並行して確認している利用者として試す。 この検証結果だけで、対象顧客全体、複数担当者の案件を見るディレクター、他の役割の利用者にも同様に必要だとは判断しない。 --- 【試す利用場面】 主な場面は以下。 - 朝の業務開始時 - 普段から行っている案件確認時 - 昼や夕方にも通常の進捗確認をしている場合は、その場面 - 案件数が多い日 - 期限や対応が集中している日 - Aが全件を確認したい日 - CがTODO期限順で確認する場面 検証のためだけに設定した場面ではなく、可能な範囲で通常業務に近い場面を使う。 --- 【提供するもの】 ### 最初に提供するもの 実案件データから人が作成した、簡易な「今日の確認リスト」。 掲載候補は以下。 - 案件名 - 確認理由 - 関連する未決事項またはTODO - 期限 - 誰待ちか - 確認済みを記録する欄 - 必要に応じて既存の案件詳細へのリンク 形式はスプレッドシートなどとし、本番画面に近い完成度にはしない。 ### 人手で代替するもの - 確認候補の選定 - メール・チャットの経緯の確認 - 確認理由の記載 - 候補の追加・除外 - 確認済みと持ち越しの管理 - AI候補提示に相当する文脈判断 ### 最初は提供・実装しないもの - AIによる自動選定 - AIによる自動確定 - 専用の本番画面 - 本番の一覧フィルター - 自動追加・自動除外 - リアルタイム更新 - 通知 - 状態の永続保存 - 翌日への自動持ち越し --- 【観察する発言】 ### 期待に関する発言 - 何が「便利そう」なのか。 - どの場面で使う想定なのか。 - 現在のどの作業が減ると考えているのか。 これらは期待の把握に使うが、利用価値の確認済み証拠とはしない。 ### 実際に使った後の発言 - どの候補が役立ったか、その理由。 - 不要だった候補と、その理由。 - 抜けていた候補。 - 判断に不足していた情報。 - リストがなければ見落としていた可能性があるか。 - 使わなかった場合、その理由。 - 元の確認方法に戻った理由。 - 次に使うとすれば、どの場面か。 ### 選定基準に関する発言 - 期限、未決事項、返答待ち、誰待ちかのうち何を重視したか。 - 「今日確認すべき」と「今日対応すべき」の違い。 - 表示された確認理由に納得できたか。 - 既存データ以外に必要な判断材料。 - 候補を追加、削除、後回しにした理由。 ### Aに対する確認 - すべての案件を見たい日はどのような日か。 - その日でも、確認リストを優先順位付けに使えたか。 - リストを使った後に全件確認した理由。 ### Cに対する確認 - 「TODO期限順で大体足りる」の「大体」に含まれないケース。 - 期限順にない候補が本当に確認に値したか。 - 確認リストが判断負担を増やしていないか。 ### 自動化に関する発言 - 自分で追加するだけでも足りるか。 - 候補提示と自動確定のどちらを望むか。 - 誤った候補や候補漏れをどのように捉えるか。 - 候補を採用・却下するために必要な説明。 発言だけで、自動化や本格実装の必要性を確定しない。 --- 【観察する利用行動】 - 通常業務で実際にリストを参照したか。 - 催促がなくても参照したか。 - 確認作業の最初に見たか、途中で見たか。 - 異なる通常業務の機会でも再度利用したか。 - どの案件をどの順番で開いたか。 - 掲載案件のうち、実際に詳細を開いた案件。 - 掲載されていても開かなかった案件。 - リスト外で開いた案件。 - 一覧情報だけで判断を終えられた案件。 - リストをきっかけに返信、確認依頼、TODO対応などを始めたか。 - 結局すべての案件を開いたか。 - 案件一覧を上から順番に開く行動が変わったか。 - Slackメモ、TODO期限順、メール検索を併用したか。 - 確認済み、持ち越し、追加、削除、並べ替えを行ったか。 - 元の方法へ戻った時点と理由。 - 途中でリストの利用をやめた箇所と理由。 - リストがなければ見落としていた可能性のある案件があったか。 一度開いたことだけで継続利用とは判断しない。また、全件確認が残ったことだけで無価値とは判断せず、確認順や対応行動が変わったかを見る。 --- 【反対事例として確認すること】 ### Cの「TODO期限順で大体足りる」 - 確認リストとTODO期限順の結果がほぼ同じか。 - 期限順にない有用案件が存在するか。 - 期限以外の情報が実際の確認や対応につながるか。 - 追加情報が判断負担を増やしていないか。 - Cには新機能ではなく、既存TODO表示の改善で足りないか。 Cで追加価値が見つからなくても、機能案全体を直ちに破棄しない。TODO期限順で足りる利用者には対象不一致である可能性を整理する。 ### Aの「すべての案件をざっと見たい日もある」 - 全件確認する日の条件。 - リストを先に使って重要案件を確認したか。 - 確認順が変わったか。 - 安心のために全件確認したのか。 - 通常日も常に全件確認へ戻るのか。 全件確認が残っても、優先順位付けとして使われた場合は部分的な価値がある。 ### その他の反対事例 - BがSlackメモだけを使い続ける。 - 不要候補が多く、リストへの信頼が下がる。 - 候補漏れを恐れて、毎回全件確認に戻る。 - 確認理由が不足し、毎回メール検索が必要になる。 - リストの更新や修正が既存手段より負担になる。 - 通常業務では存在を忘れられる。 - 特定の場面や特定の利用者にしか使われない。 これらは失敗と一括判断せず、対象利用者、利用場面、候補品質、表示情報、導線のどこに原因があるかを分ける。 --- 【検証の順番】 ### 1. 現在の確認行動を把握する A、B、Cの通常の確認方法を観察し、比較の基準を作る。 ### 2. 手動の確認リストを実案件・実業務で試す リストが実際に参照され、確認行動の起点または補助になるかを見る。 ### 3. 既存手段との差と反対事例を確認する - A：全件確認との使い分け - B：Slackメモとの役割分担 - C：TODO期限順との差 確認リストが全件確認の代替なのか、優先順位付けや見落とし防止の補助なのかを整理する。 ### 4. 選定基準と必要情報を抽出する 候補の追加・削除・持ち越し、不要候補、候補漏れから、必要な判断基準と表示情報を整理する。 ### 5. 自動化の必要性を段階的に比較する 以下の順で検討する。 1. ユーザーによる手動追加 2. 単純ルールによる候補 3. システムやAIによる候補提示 4. AIによる自動確定 リスト自体に価値がない場合、AI検証へ進まない。単純ルールや手動追加で足りる場合も、完全自動化を前提にしない。 ### 6. 専用画面と一覧フィルターを比較する 確認リストが利用され、必要情報が分かった後に、同じ候補・同じ情報で形式のみを比較する。 ### 7. 本番に近いAI精度や長期運用は後に残す 日々変化する情報への追従、候補の自動追加・除外、長期的な信頼性などは、前段の価値が確認された後の検証対象とする。 --- 【この検証で判断できること】 - 案件横断の確認リストを、本格的な仕様検討へ進める材料があるか。 - 実案件・通常業務の中で、確認リストが使われる兆候があるか。 - 確認リストが確認作業の起点になるか、補助として使われるか。 - 必要な案件を先に確認する行動につながるか。 - 全件確認の代替なのか、優先順位付けなのか。 - 案件一覧、Slackメモ、TODO期限順、メール検索との補完・置換関係。 - CにとってTODO期限順を超える追加価値があるか。 - Aが全件確認する日でも部分的な価値があるか。 - 「今日確認すべき案件」を判断する主要な基準。 - 必要な確認理由と表示情報。 - ユーザーによる手動追加で足りる可能性。 - 単純ルールで候補を再現できる可能性。 - AI候補提示を次に検討する理由があるか。 - 自動確定ではなく候補提示が適する可能性。 - 専用画面を検討する必要があるか、一覧フィルターで足りる可能性があるか。 - 機能が有効になりやすい利用者や利用場面の条件。 これらは実装可否の最終決定ではなく、次の仕様検討や追加検証へ進む材料として扱う。 --- 【この検証では判断できないこと】 - AIが本番環境で継続的に正しく候補を選定できるか。 - 日々追加されるメール、チャット、TODOに安定して追従できるか。 - 返答待ちの解消、期限変更、状況変化を自動で正しく反映できるか。 - 手動リストと同じ品質をAIが再現できるか。 - AIで候補を作れることから、自動確定してよいか。 - 長期的に確認漏れ、返信遅れ、対応遅れが減るか。 - 本番機能として長期的に自発利用されるか。 - A、B、C以外の対象顧客全体にも必要か。 - 担当者とディレクターで同じ仕様が有効か。 - 専用画面やフィルターの最終的な詳細仕様。 - 実装可否の最終決定。 - 開発工数、予算、リリース日、価格。 --- 【検証後に整理する判断材料】 ### 確認リスト自体について - 通常業務で実際に参照されたか。 - 異なる通常業務の機会でも再利用されたか。 - 確認順、開く案件、対応行動が変わったか。 - 一覧だけで判断できた案件があったか。 - リストがなければ見落としていた可能性のある案件があったか。 ### 既存手段との関係 - 全件確認を置き換えたか、優先順位付けに使われたか。 - Slackメモ、TODO期限順、メール検索が残った理由。 - 既存手段との併用に価値があるか。 - 元の方法に戻った原因が、候補品質、情報不足、習慣、利用場面のどれか。 ### 候補品質と選定基準 - 採用された候補と却下された候補。 - 候補漏れと、その判断材料。 - 不要候補が信頼低下につながったか。 - 期限、未決事項、返答待ち、誰待ち、経緯のうち有効だった情報。 - 本人固有の優先順位がどの程度あるか。 ### 対象利用者・利用場面 - A、B、Cのうち誰に価値があったか。 - 案件数やその日の状況との関係。 - 朝、昼、夕方のどの場面で使われたか。 - TODO期限順で足りる利用者には不要か。 - 全件確認したい日にも補助価値があるか。 ### 自動化と画面形式 - 手動追加だけで運用できるか。 - 単純ルールで有用候補を再現できるか。 - 文脈判断が必要な具体例があるか。 - AI候補提示へ進む根拠があるか。 - 自動確定ではなく、利用者による採否判断が必要か。 - 専用画面とフィルターのどちらが通常導線に合うか。 肯定的な発言、一度の利用、モックへの評価、手動リストの利用を、それぞれ継続利用、本番実装、完全自動化の根拠へ飛躍させずに整理する。 --- 【総合計画】 最初に確認するのは、AIの精度や専用画面の好みではなく、**案件横断の確認リストが実案件・通常業務で使われ、現在の確認行動に意味のある変化を起こすか**である。 まずA、B、Cの現在の確認行動を把握し、その後、既存データから人が作成した簡易な確認リストを通常業務で提供する。発言上の好意ではなく、実際に参照したか、必要案件を先に確認したか、返信や確認依頼などの行動が起きたか、既存手段との使い分けが変わったかを観察する。 Aについては、全件確認が残ったことだけで否定せず、重要案件を先に見るための優先順位付けに使われたかを確認する。Cについては、TODO期限順では拾えない有用案件があるかを比較し、差がなければCには既存TODO表示で足りる可能性を整理する。Bについては、Slackメモと手動追加型の確認リストが同じ役割を持つかを確認する。 確認リスト自体に利用価値が見られた後、候補の追加・削除・持ち越しから選定基準を整理する。その上で、手動追加、単純ルール、候補提示、自動確定の順に必要な自動化範囲を検討する。手動運用が役立ったことだけで、AIや完全自動化が必要とは判断しない。 専用画面と既存一覧フィルターの比較は、リストが使われ、必要情報が分かった後に行う。同じ候補と情報を使い、見た目の好みではなく、確認開始のしやすさ、画面移動、全件確認との併用、確認済みの扱いなどの行動差を見る。 この事前検証で整理するのは、確認リストの利用価値、適する利用者・場面、既存手段との関係、主要な選定基準、必要情報、自動化と画面形式を次に検討する根拠である。AIの本番精度、長期定着、対象顧客全体への一般化、実装可否の最終決定、詳細仕様の確定までは進めない。

【商品・サービス】 小規模な制作会社・受託開発会社向けの 案件情報整理SaaS。 顧客とのメールやチャットから、 案件ごとの決定事項、 TODO、 未決事項、 経緯を整理して確認できる。 【現在の対象顧客】 3〜15人程度の制作会社、 受託開発会社、 デザイン会社、 小規模コンサルティング会社。 複数案件を並行して進めているチーム。 【検証したい新機能】 「今日確認した方がよい案件」を 案件横断でまとめて表示する確認リスト機能。 未決事項、 期限が近いTODO、 顧客からの返答待ち、 長期間更新されていない案件などから 確認候補を出す。 【その機能で解決したい課題】 複数案件を持っている担当者が、 毎回すべての案件を開かなくても、 先に確認すべき案件を把握できるようにすること。 確認漏れや対応遅れを減らすこと。 【現在確認できている顧客課題】 顧客A： 「朝、全部の案件を開くのが負担」 顧客B： 「急ぎの案件を見落としたくない」 顧客C： 「TODO期限だけだと、 顧客待ちや止まっている案件を拾えないことがある」 顧客D： 「週次確認の前に、 見るべき案件だけ先に分かると楽」 A、B、C、Dとも、 複数案件から確認対象を選ぶ負担を挙げている。 【現在確認できている利用行動】 顧客A： これまでは毎朝すべての案件を開いていた。 手動で作った確認リストを使い始めてからは、 まず確認リストを見て、 必要な案件から先に確認している。 全件確認をする日もあるが、 毎日最初から全件を見ることは減った。 顧客B： 以前はSlackの自分宛メモで重要案件を管理していた。 現在は手動確認リストを最初に見て、 そこにない案件だけ必要に応じてSlackメモで補っている。 顧客C： 以前はTODO期限順を中心に確認していた。 手動確認リストで、 期限のない未決事項や顧客待ち案件が表示されたとき、 TODO期限順では気づかなかった案件を確認したことがある。 ただし、 期限付きTODOだけを見る日は 従来のTODO期限順でも十分だと話している。 顧客D： 週次会議前に、 担当案件を一件ずつ確認していた。 現在は手動確認リストを最初に使い、 表示された案件から確認している。 必要に応じて一覧にない案件も追加確認している。 【現在の代替手段】 案件一覧を順番に見る。 TODO期限順で見る。 Slackに自分用メモを残す。 メール・Slack検索。 週次で担当案件をすべて確認する。 【既存機能でできること】 案件一覧を表示できる。 案件ごとの未決事項を確認できる。 TODOと期限を確認できる。 顧客とのメール・チャットから 未決事項をAIで抽出できる。 顧客待ち事項も一部抽出できる。 【実装前提として確認できていること】 A、B、C、Dで 確認対象を探す負担がある。 4社とも、 手動で作成した案件横断の確認リストを 実業務で使用した。 A、B、Dでは 確認リストが最初の確認先として使われた。 Cでは、 TODO期限順だけでは拾えなかった案件が 確認リストによって見つかった事例がある。 確認リストを見ても、 すべての案件をまったく見なくなるわけではないが、 優先順位付けや最初の確認先として使われている。 【まだ仮説に留まっていること】 AIが確認対象を自動選定すべき。 AIが自動で確定してよい。 「今日確認すべき案件」の条件を 全顧客で共通化できる。 専用画面の方が 既存案件一覧のフィルターより使いやすい。 確認済みになった案件を 自動でリストから外せる。 長期間使っても 確認リストが継続利用される。 【反対事例】 顧客Cは、 期限付きTODOだけ確認したい日は 既存のTODO期限順で十分だと話している。 顧客Aは、 重要なリリース前などは 確認リストがあっても全案件を見る。 顧客Dでは、 確認リストに入っていない案件を 週次会議前に追加確認することがある。 そのため、 確認リストが全件確認を完全に置き換えるとは考えていない。 【特に重要だと考えている未確認事項】 どこまで自動選定する必要があるか。 単純ルールだけでも十分か。 AI候補提示まででよいか。 AIが自動確定してよいか。 どの条件を使って 確認候補を出すべきか。 利用者自身が 候補を追加・削除できる必要があるか。 確認済み・持ち越し・翌日再表示を どう扱うべきか。 専用画面か既存一覧フィルターか。 担当者とディレクターで 必要な表示が違うか。 【想定している利用者】 複数案件を担当する担当者。 複数担当者の案件を見るディレクター。 【想定している利用場面】 朝の業務開始時。 週次会議前。 案件数が多い日の確認。 【想定している利用方法】 確認リストを見る。 確認理由を確認する。 必要な案件を開く。 必要に応じて候補を追加・削除する。 確認済みになった案件を処理する。 【現在考えている機能の形】 候補A： 専用の「今日の確認」画面。 候補B： 既存案件一覧に 「確認が必要」フィルターを追加。 候補C： 案件一覧上に 確認候補だけ目立たせる。 【別の実現方法として考えている案】 ユーザー自身が 「今日確認」に追加する。 TODO期限などの単純ルールで候補を出す。 AIが候補を出し、 ユーザーが確認して採用する。 AIが自動で確認対象として確定する。 【すでに行った簡易検証】 1. A、B、C、Dに対して、 既存データを使い、 人が「今日確認すべき案件」を選んだ。 2. 案件名と確認理由を含む 手動確認リストを提供した。 3. 実際の通常業務で使ってもらった。 4. 利用後に、 確認した案件、 追加した案件、 削除した案件、 元の確認方法へ戻った場面を確認した。 【簡易検証の結果】 A： 確認リストを最初に見た。 表示された案件から確認した。 全件確認する日もあった。 「全部見る必要がない日は楽」と話した。 B： 確認リストを最初に見た。 重要案件の一部は 自分で追加した。 Slackメモの利用は残ったが、 以前より補助的に使った。 C： TODO期限順では拾えなかった 顧客待ち案件を確認した事例があった。 一方、 TODO期限だけで十分な日は 確認リストを使わなかった。 D： 週次会議前に 確認リストから確認を始めた。 リスト外の案件も一部追加確認した。 「最初に見る案件が分かるのは助かる」と話した。 【利用できる既存データ】 案件一覧。 未決事項。 TODOと期限。 顧客待ち事項。 元のメール・チャット。 案件の最終更新情報。 【手動で代替できること】 人が確認候補を作る。 利用者が候補を追加・削除する。 確認済み・持ち越しを スプレッドシートで管理する。 複数の候補ルールを 人が再現して比較する。 【簡易モックで試せそうなこと】 同じ候補データを使い、 ・専用画面 ・一覧フィルター ・案件一覧上の強調表示 を比較する。 AI候補の代わりに、 人が複数条件から候補を作って AI候補提示の体験を再現する。 【本格実装しないと確認できないと考えていること】 大量の案件や日々変化する情報を対象にした AI自動選定の継続的な精度。 自動で確認済み判定・翌日再表示を行う場合の 本番運用上の安定性。 【検証に使える顧客・利用者】 顧客A、B、C、D。 各社の担当者。 顧客Dではディレクターも確認可能。 【検証上の制約】 本格的な自動化はまだ実装しない。 既存データは利用できる。 候補作成や状態更新は手動で代替できる。 簡易モックは作成できる。 【今回の検証後に判断したいこと】 次の仕様検討で どの自動化方式を中心に検討するか。 AIを使う必要がある部分はどこか。 完全自動化ではなく 候補提示型で十分か。 表示形式をどの方向で検討するか。 担当者とディレクターで 異なる入口が必要か。 【今回特に設計したいこと】 ・すでに確認済みの利用価値をどこまで再検証する必要があるか ・次に何を優先して検証するべきか ・単純ルールとAI候補提示をどう比較するか ・AI自動確定をいつ検証するべきか ・利用者による追加・削除をどう評価するか ・Cのように一部場面では既存TODOで十分なケースをどう扱うか ・A、Dのように全件確認も残るケースをどう評価するか ・専用画面、フィルター、強調表示をいつ比較するか ・確認済み、持ち越し、翌日再表示をどの段階で検証するか ・本格実装前にどこまで仕様判断材料を揃えられるか

【検証したい新機能】 小規模な制作会社・受託開発会社などを対象に、案件横断で「今日確認した方がよい案件」を理由付きで表示する確認リスト機能。 候補の根拠として、以下を想定する。 - 未決事項 - 期限が近いTODO - 顧客からの返答待ち - 長期間更新されていない案件 - メール・チャットや案件経緯から判断できる要確認事項 実現形式の候補は以下。 - 専用の「今日の確認」画面 - 既存案件一覧の「確認が必要」フィルター - 案件一覧上での候補強調表示 自動化方式は、単純ルール、AIによる候補提示、AIによる自動確定を分けて検証する。 --- 【解決したい顧客課題】 複数案件を担当する利用者が、毎回すべての案件を開かなくても、先に確認すべき案件とその理由を把握できるようにする。 具体的には、以下の負担やリスクを減らすことを狙う。 - 朝にすべての案件を開いて確認する負担 - 急ぎの案件や重要案件の見落とし - TODO期限順だけでは拾えない顧客待ち・期限のない未決事項・停滞案件の見落とし - 週次会議前に一件ずつ確認対象を探す負担 - 案件一覧、Slackメモ、メール・Slack検索などを横断して確認対象を決める負担 ただし、全件確認や既存手段を完全に置き換えることは前提にしない。最初の確認先や優先順位付けとしての役割を中心に検証する。 --- 【現在確認できていること】 - A〜Dの4社で、複数案件から確認対象を選ぶ負担が確認されている。 - 4社とも、人が作った案件横断の確認リストを実業務で使用した。 - A、B、Dでは、確認リストが最初の確認先として使われた。 - Aでは、毎日最初から全案件を見る行動が減った。 - Bでは、Slackメモが主な確認手段から補助的な手段になった。ただし、重要案件の一部は本人が追加した。 - Cでは、TODO期限順では拾えなかった顧客待ち案件が、確認リストによって実際の確認につながった。 - Dでは、週次会議前に確認リストから確認を始めた。 - 確認リストには、確認対象の絞り込み、確認順の決定、TODO期限順では拾いにくい案件の発見という価値がある。 - 一方で、確認リストは全件確認、TODO期限順、Slackメモを完全には置き換えていない。 - 既存データを使い、人が候補を作成することで、本格実装前でも単純ルール候補やAI候補提示相当の体験を再現できる。 - したがって、「案件横断の確認リストに基本的な利用価値があるか」を同じ形で最初から再検証する必要性は低い。 ただし、一度使われたことから継続利用や対象顧客全体への一般化までは判断できない。 --- 【重要な未確認事項】 1. **候補選定方式** - 単純ルールだけで十分か。 - 文脈を考慮した候補提示に追加価値があるか。 - AIが必要なのは抽出、順位付け、確認理由生成のどこか。 2. **候補条件** - TODO期限、未決事項、顧客待ち、最終更新日のどれが有効か。 - 条件をどう組み合わせるべきか。 - 朝、週次会議前、リリース前などで条件を分ける必要があるか。 3. **候補提示と自動確定** - 利用者が確認・修正する候補提示型で十分か。 - AIやシステムが「今日の確認対象」として自動確定してよいか。 - 自動確定によって過信や見落としが起きないか。 4. **利用者による修正** - 候補の追加・削除がどの程度必要か。 - 修正が例外的か、繰り返し発生するか。 - 個別事情、当日の目的、候補生成の誤りを区別できるか。 5. **利用場面による使い分け** - CのようなTODO期限順で十分な日をどう扱うか。 - Aのリリース前やDの週次会議前のような全件確認とどう併用するか。 6. **状態管理** - 確認済みの定義。 - 「案件を開いた」と「確認が完了した」の違い。 - 持ち越しや翌日再表示に必要な状態と操作。 - 自動判定が必要か、明示操作で十分か。 7. **表示形式** - 専用画面、一覧フィルター、強調表示のどれが業務導線に適するか。 8. **利用者の役割差** - 担当者とディレクターで候補内容、表示単位、入口を分ける必要があるか。 9. **継続利用** - 複数日・複数場面でも自発的に最初の確認先として選ばれるか。 - 候補や持ち越しが蓄積して負担にならないか。 --- 【先に確認する仮説】 1. TODO期限、未決事項、顧客待ち、最終更新日を組み合わせた単純ルールで、有用な候補の多くを抽出できる。 2. メール・チャットの文脈を考慮した候補は、単純ルールでは拾えない案件を追加できる。 3. 文脈考慮候補の追加価値がある場合でも、AIによる自動確定ではなく、理由付き候補を利用者が修正する方式で十分な可能性がある。 4. 利用者による追加・削除は必要だが、修正理由にはルール化できるものと、その日固有の事情がある。 5. 確認リストは、TODO期限順や全件確認の代替ではなく、最初の確認先や確認順の決定手段として成立する。 6. 利用場面によって、確認リスト、TODO期限順、全件確認を使い分ける必要がある。 7. 候補内容と必要な状態を整理した後なら、同一候補を使ったモック比較で表示形式の方向性を判断できる。 これらは検証対象であり、現時点で確認済みとは扱わない。 --- 【検証方法】 ### 1. 既存データ分析 既存の案件一覧、未決事項、TODOと期限、顧客待ち事項、最終更新情報を使い、以下の候補を再現する。 - TODO期限中心 - 未決事項中心 - 顧客待ち中心 - 長期間更新なし中心 - 複数条件の組み合わせ - 条件に優先順位を付けた候補 方式ごとに、候補の重複、各方式だけが拾った案件、実際に確認された案件、候補漏れを整理する。 ### 2. 手動運用 人が以下のリストを作り、通常業務で利用してもらう。 - 単純ルール候補 - 複数ルール候補 - 元のメール・チャットまで見た文脈考慮候補 文脈考慮候補は「AI候補提示相当」の体験として扱う。実際のAI精度検証とは扱わない。 追加、削除、確認済み、持ち越しなどは、スプレッドシート等で手動代替する。 ### 3. 候補提示型と確定型の擬似比較 同じ候補を以下の2通りで提示する。 - 「確認候補です。必要なものを選んでください」 - 「今日の確認対象です。必要なら修正してください」 候補品質を変えず、表示上の扱いによる行動差を確認する。 ### 4. 簡易モック比較 同一の候補データを使って以下を比較する。 - 専用の「今日の確認」画面 - 既存案件一覧のフィルター - 案件一覧上の強調表示 見た目の好みではなく、案件の確認、既存TODOへの切り替え、全件一覧への移動などの作業を行ってもらう。 ### 5. 限定試用 複数回の朝確認や週次会議前で手動運用し、初回利用と繰り返し利用を分けて観察する。既存手段の利用は禁止せず、どの場面で併用・切り替えたかを記録する。 --- 【試す利用者】 - 顧客A、B、C、Dの担当者 - 顧客Dのディレクター 担当者の結果をそのままディレクターへ一般化しない。ディレクターの検証は、役割差の仮説を得るためのものとして扱う。 --- 【試す利用場面】 - 朝の業務開始時 - 案件数が多い日の確認 - 期限付きTODOだけを確認したい日 - 週次会議前 - 重要なリリース前など全件確認が必要な場面 - 確認後も対応が完了せず、翌日へ持ち越す場面 利用場面ごとに、その日の確認目的と選ばれた手段を対応させる。 --- 【提供するもの】 - 案件名と確認理由を含む手動確認リスト - 単純ルール別の候補リスト - 文脈考慮候補リスト - 候補の追加・削除欄 - 修正理由の記録欄 - 未確認、確認済み、今日中は残す、翌日へ持ち越すなどの状態欄 - 候補提示型と確定型の簡易表示 - 専用画面、一覧フィルター、強調表示の低忠実度モック - 案件詳細や元情報を参照するための導線 TODO期限順、案件一覧、Slackメモ、メール・Slack検索、全件確認は利用可能なままとする。 --- 【観察する発言】 - どの負担が減った、または増えたか。 - なぜ最初にその確認手段を選んだか。 - 「TODO期限順で十分」と判断した条件。 - 「全件確認が必要」と判断した条件。 - 候補理由だけで優先順位を判断できたか。 - 不足していた情報は何か。 - 候補漏れと過剰候補のどちらをより問題視するか。 - 削除した候補が、誤候補なのか、正しいが今日は対象外なのか。 - 追加した案件を既存条件で拾えなかった理由。 - 候補の採用操作や修正を負担に感じたか。 - 確定表示を網羅性の保証として受け取らなかったか。 - 確認済み、持ち越し、翌日再表示をどう捉えたか。 - 専用画面、フィルター、強調表示で、具体的に何がやりやすいか。 - 担当者とディレクターで必要な情報がどう異なるか。 「使いたい」「便利そう」だけで利用価値や継続利用を判断せず、実際の行動と対応させる。 --- 【観察する利用行動】 - 最初に開いたリストや画面。 - 候補を確認した順番。 - 実際に開いた案件と、開かなかった候補。 - 文脈考慮候補でのみ拾えた案件が、確認・対応につながったか。 - 候補理由を読んだか、案件名だけで判断したか。 - 追加・削除した案件とその理由。 - リスト外から確認した案件。 - 確認リストの後に全件確認したか、必要案件だけで終了したか。 - 全件確認時に、確認順が変わったか。 - TODO期限順、Slackメモ、検索などへ切り替えた時点と理由。 - 案件を開いた後、確認済み、TODO更新、返信などのどこまで行ったか。 - 確認済み、今日中は残す、持ち越しを使い分けたか。 - 翌日再表示された案件を再確認したか。 - 状態更新や追加・削除を途中から行わなくなったか。 - 複数日・複数場面でも自発的に入口として選んだか。 - 担当者とディレクターで確認対象や追加案件が異なったか。 --- 【反対事例として確認すること】 - Cのように、期限付きTODOだけを見る日は既存のTODO期限順で十分な場合。 - Aのように、重要なリリース前には全件確認が必要な場合。 - Dのように、週次会議前にリスト外の案件も確認する場合。 - Bのように、Slackメモが補助手段として残る場合。 - 利用者による重要案件の追加が必要な場合。 - 確認リストを開いても、候補数、理由不足、操作負担によって途中離脱する場合。 - 候補漏れへの不安から全件確認へ戻る場合。 - 文脈考慮候補が増えすぎて、絞り込みにならない場合。 - 状態更新や持ち越し管理が負担になり、使われなくなる場合。 - 専用画面と案件一覧の往復が増え、既存一覧だけに戻る場合。 反対事例は機能案の即時否定とは扱わない。適用場面の限定、既存手段との役割分担、候補条件やUIの問題を分けて解釈する。 --- 【検証の順番】 1. **利用場面と既存手段との使い分けを整理する** - 基本価値を再検証しすぎず、いつ使われ、いつ使われないかを確認する。 2. **単純ルール候補と文脈考慮候補を比較する** - 表示形式を固定し、候補生成方式だけを比較する。 3. **候補の追加・削除と修正理由を確認する** - 候補提示型で補完可能か、自動確定が危険かを判断する材料にする。 4. **担当者とディレクターの違いを確認する** - 別画面を前提にせず、候補内容や表示単位の差を見る。 5. **同一候補で表示形式を比較する** - 専用画面、フィルター、強調表示を比較する。 6. **確認済み・持ち越し・翌日再表示を手動で試す** - 必要な最小状態と操作を整理する。 7. **候補提示型と自動確定型を擬似比較する** - 文脈考慮の追加価値や修正実態を確認してから行う。 8. **必要性が残った場合にのみ、本番AIや自動状態更新を検討する** - 単純ルールで十分ならAI検証を拡大しない。 --- 【この検証で判断できること】 - 単純ルールで候補化できる範囲。 - 文脈考慮によってのみ拾える案件の種類と追加価値。 - AIを検討する場合、抽出、順位付け、理由生成のどこが対象になり得るか。 - 候補提示型を中心に検討できるか。 - 利用者による追加・削除を初期仕様候補に含める必要があるか。 - 修正理由を共通ルール、個人設定、当日だけの補完のどれとして扱うべきか。 - TODO期限順、確認リスト、全件確認の適切な使い分け。 - 確認リストを「置き換え」ではなく「入口・補完」と位置付けるべきか。 - 確認済み、持ち越し、翌日再表示に必要な最小状態。 - 専用画面、フィルター、強調表示の方向性。 - 担当者とディレクターで、異なる表示や入口を検討する根拠があるか。 - 本格実装前に、どの自動化方式を次の仕様検討の中心にするか。 これらは次の仕様検討に必要な判断材料であり、実装可否や詳細仕様の最終決定ではない。 --- 【この検証では判断できないこと】 - 実際のAIが日々変化する大量の案件から安定して候補を生成できるか。 - AIの見逃し、過剰候補、抽出誤りの継続的な発生状況。 - AI候補が長期間にわたって信頼されるか。 - AIによる自動確定を本番で継続的に受け入れられるか。 - 確認済みの自動判定や自動除外の運用安定性。 - 日付変更、新着情報、担当者変更を含む持ち越し・再表示の完全自動運用。 - 大量案件での生成速度や最新情報とのずれ。 - 長期的な定着や、確認漏れ・対応遅れが実際に減少するか。 - 4社の結果を対象顧客全体へ一般化できるか。 - 顧客D以外のディレクターにも同じ役割差があるか。 - 実装可否、詳細仕様、開発工数、本番リリース日、価格。 また、手動運用で使われたことを完全自動化の根拠にはしない。 --- 【検証後に整理する判断材料】 - 各候補方式で実際に開かれた案件。 - 確認や対応につながった案件。 - 単純ルールだけで拾えた案件。 - 文脈考慮でのみ拾えた案件。 - 不要候補、候補漏れ、追加・削除の内容と理由。 - 修正理由の再現性。 - 利用場面ごとに選ばれた確認手段。 - 確認リストから全件確認へ移った理由。 - 確認リストが全件確認の順序を変えたか。 - 候補提示と確定表示での行動差。 - 必要だった状態と、使われなかった状態。 - 表示形式ごとの具体的な作業上の違い。 - 担当者とディレクターの候補・表示ニーズの差。 - 複数回利用時の状態更新負担、候補蓄積、既存手段への回帰。 - 本格実装前に絞り込めた範囲と、実装後にしか確認できない不確実性。 これらを基に、次の仕様検討で以下のどれを中心に扱うかを整理する。 - 単純ルール中心 - 単純ルール＋利用者補完 - AIによる理由付き候補提示 - AI候補提示＋利用者による確定 - 将来的な自動確定の追加検証 --- 【総合計画】 本検証では、すでに一定の支持がある「案件横断で優先案件を示す価値」を最初から証明し直すのではなく、**候補の作り方、利用者による修正、利用場面ごとの使い分け、必要な状態、適切な表示形式**を順に切り分ける。 最初に、既存データと人手を使って単純ルール候補と文脈考慮候補を比較する。文脈考慮候補はAI候補提示相当の体験として扱い、AI精度の証明には使わない。同時に、追加・削除や既存手段への切り替えを観察し、候補提示型で業務を支えられるかを確認する。 次に、候補内容を固定したうえで、専用画面、フィルター、強調表示を比較する。その後、確認済み、持ち越し、翌日再表示を手動運用し、必要な最小状態を整理する。 AI自動確定は、文脈考慮候補に単純ルールを上回る価値があり、候補漏れや利用者修正の実態が整理され、「候補」より「確認対象」として扱う方が業務に合う可能性が確認された後に扱う。それまでは完全自動化を前提にしない。 CのTODO期限順、Aの全件確認、Dの追加確認、BのSlackメモ利用は失敗とは扱わず、確認リストの適用範囲と既存手段との役割分担を示す反対事例として評価する。 検証後は実装可否や詳細仕様を確定せず、次の仕様検討で中心にする自動化方式、AIが必要な部分、候補提示型で十分な範囲、表示形式の方向性、役割別対応の必要性を判断するための材料を整理する。