プロジェクト課題と解決アプローチ: SpecDojo
本書は、シビックテックの三つの主要課題と、SpecDojo が採用する解決アプローチを定める。
1. 課題一覧
| 課題ID | 課題 | 利用者への影響 | 優先度 |
|---|---|---|---|
| P-01 | 当事者が感じる社会課題と、技術者・AI が扱える要求・仕様の間に断絶がある | 現場の価値と異なるソリューションが作られ、利用されない | High |
| P-02 | 資金と専門人材が限られ、ソリューションの構築・改善・提供に必要な費用を負担できない | 必要性があっても実現できず、試作後に停止する | High |
| P-03 | 活動が少数の参加者の善意、余暇、経験、記憶に依存する | 負荷集中や離脱により、知識とソリューションが継承されない | High |
2. 原因（仮説でも可）
| 課題ID | 原因区分 | 内容 | 根拠 / 確認方法 |
|---|---|---|---|
| P-01 | 仮説 | 課題、対象者、期待する変化を要求・仕様へ変換する共通の型がない | 当事者と技術者の説明・成果物の一致を試行で確認する |
| P-02 | 仮説 | 既存知見・OSS・AI の再利用が不十分で、費用と作業を毎回抱えている | 追加支出、作業時間、再利用物を試行前後で記録する |
| P-03 | 仮説 | 判断、作業、負荷が共有されず、役割の分担・交代条件が定まっていない | 担当別作業時間と引き継ぎ結果を確認する |
これらは仮説であり、代表試行と公開後の実利用で検証する。
3. 解決策候補
| 案ID | 案 | 関係 | 概要 | 期待できる効果 | 対応課題 |
|---|---|---|---|---|---|
| A-01 | 社会課題と技術を共同で言語化する | 補完 | 当事者の言葉を起点に、対象者、期待価値、制約、要求、仕様、検証を関連付ける | 現場の Why を保った実行可能なソリューションになる | P-01 |
| A-02 | オープンな資産と AI を再利用する | 補完 | OSS、既存成果物、テンプレート、AI 支援を組み合わせ、追加支出と重複作業を減らす | 限られた資金と人員でも試行・改善できる | P-02 |
| A-03 | 負荷と知識を共同化する | 補完 | 必要な成果物だけを選び、判断、未決事項、作業時間、次の作業を共有して分担・交代する | 善意を消耗せず、参加者が変わっても継続できる | P-03 |
AI Agent は A-01〜A-03 の言語化、再利用、実行、検証を支援するが、当事者価値と主要判断は人間が承認する。具体的な運営戦略と支援ツールは 代替案比較 で選定する。
4. 採用アプローチと理由
A-01〜A-03 を一体で採用する。A-01 だけでは実現費用を下げられず、A-02 だけでは現場と異なる解を安価に作り、A-03 だけでは実現するソリューションを定められないためである。
初期公開では、次の一連の流れを一つの代表試行で検証する。
- A-01 で社会課題を実行可能な仕様へつなげる。
- A-02 で事前に定めた現金支出・作業時間の上限内に試行成果を作る。
- A-03 で負荷を確認し、別の参加者が改善を継続する。
判断では、当事者価値との一致、総費用、参加負荷、継続可能性の順に重視する。安価であっても当事者価値を満たさない案や、無償労働へ負荷を転嫁する案は採用しない。
5. トレードオフ/リスク
| 区分 | 内容 | 対応 | 所有者 |
|---|---|---|---|
| トレードオフ | 初期公開では全文書種別や本番ソリューションを完成させない | 三つの価値仮説を検証する最小成果物と試行成果を優先する | PO |
| トレードオフ | 低コスト化のため既存 OSS と無償手段を優先する | セキュリティ、持続性、利用条件を採択前に確認する | ARC |
| リスク | 当事者の言葉を技術側が都合よく解釈する | 当事者が期待価値と試行結果の対応を確認する | BA |
| リスク | 現金支出だけを減らし、人の負荷を無償労働へ転嫁する | 作業時間、役割、継続負担を分けて記録する | PM |
| リスク | AI 出力や OSS の品質・権利・保守性を確認せず利用する | 人間のレビュー、検証証跡、ライセンス確認を完了条件にする | QE |
| リスク | 記録作業が増え、参加の負担になる | 必須項目を絞り、試行で使われない項目を削る | BA |
| リスク | 公開資料に個人情報や非公開情報が混入する | 公開前レビューで一般化または除外する | QE |
リスクは プロジェクト登録簿 で追跡する。
6. 次の検討事項（ToDo）
| ToDo | 完了条件 | 責任ロール |
|---|---|---|
| 代表課題、当事者、技術協力者を決める | 課題と期待価値を確認できる人、試行成果、協力条件が決まる | PO, BA |
| 費用・負荷の上限を決める | 現金支出、参加者別作業時間、対象期間、除外費用が定義される | PO, PM |
| 初期公開の最小成果物を決める | SC-01〜SC-03 に必要な成果物と作成支援資料が特定される | PO, ARC |
| 公開範囲とライセンスを決める | 再利用できる情報、権利、改善提案の入口が確定する | PO, BA |
7. 見直しと変更管理
当事者評価、費用・作業記録、継続状況のいずれかが仮説に反する場合、課題、アプローチ、最小成果物を見直す。主要変更は PO が承認し、理由を プロジェクト登録簿 または決定記録に残す。