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