ディスカバリーと開発のギャップ
オポチュニティキャンバス
確かめられる事実
解決策
価値についての仮説
2
課題
この解決策が扱う課題を、見込みユーザーや顧客は今どう抱えているか。
合意した仕様がディスカバリー側に留まり、実装側から読まれない
テストを見てもどのルールを満たしているのか分からない
ルールが自動化済みかどうかが、どこにも記録されていない
3
顧客とユーザー
この解決策が扱う課題を抱えているのは、どんなユーザー・顧客か。
実装リポジトリの開発者
実装リポジトリで動くAIエージェント
自動化の進み具合を見たいファシリテーター
4
現在の解決手段
ユーザーは今、その課題にどう対処しているか。
仕様を都度Slackで訊く
チケットに仕様を転記し、そこから先は同期しない
コードコメントにルール番号だけ書くが、番号は他のマッピングにも存在する
5
事業上の課題
ユーザーと顧客のその課題は、自分たちの事業にどう響いているか。
仕様と実装の乖離が、時間とともに静かに広がる
何が未実装かを人手で数え直している
1
解決策のアイデア
具体的なプロダクト・機能・改善のアイデアを挙げる。
仕様の一点をlivt URIで名指しし、テスト・Issue・コミットから引けるようにする
実装リポジトリのエージェントがMCP経由で仕様を読む
10
予算
この課題を解いてその成果を得るために、どれだけの費用やチームの時間を充てるか。
OSSとして個人の余暇で開発、外部コストは持たない
6
ユーザーは価値を得るために何をするか
この解決策が届いたとき、対象のユーザーは何をするか。
テストコメントのlivt URIから、ルールと具体例へ戻る
ルール単位でIssueを起票し、実装リポジトリで自動化する
未自動化のルールを横断で見渡して、次に埋めるギャップを選ぶ
7
指標
価値を得るまでの一連の行動のうち、実際にそうしたと示せるものとして何を測れるか。
livt URIを引用しているテスト・Issueの数
Tasksページの未自動化ルール件数の推移
8
採用の道筋
顧客とユーザーは、この解決策をどう知り、使い方を覚え、使い続けるようになるか。
実装リポジトリ向けのMCPプラグインとして配る
起票スキルが、backpointerを最初から本文に埋める
9
事業へのインパクト
この解決策がうまくいったとき、どの事業指標が動くか。
自動化済みルールの比率
仕様の取り違えに由来する手戻り件数
ユビキタス言語