# PRISM — エグゼクティブサマリー > **PRISM（プリズム）** > プロジェクトという白色光を、進捗・リソース・知識・リスクのスペクトルに分光する。 > > **タグライン：「動いているプロジェクトの"いま"が、ひとりでに見える。」** --- ## 0. 本ドキュメント群について 株式会社リベラウェア 和田様へのヒアリング内容をもとに構想した、プロジェクト可視化・自動化サービス「PRISM」の企画案。 | ファイル | 内容 | |---|---| | `01_executive_summary.md` | 本書。課題・解決策・事業性の全体像 | | `02_product_overview.md` | 機能一覧と各機能の詳細仕様、画面設計 | | `03_business_model.md` | 料金体系、収益構造、ユニットエコノミクス | | `04_go_to_market.md` | 導入シナリオ、GTM、次アクション | | `05_market_research.md` | 市場規模、競合分析、Why Now | | `06_technical_architecture.md` | 技術構成、推定エンジン設計、PoC設計 | | `07_hearing_design.md` | 次回ヒアリング設計書（そのまま持ち込める質問票） | ### 記法 - `【確認済】` … ヒアリングで直接言及があった内容 - `【仮説】` … こちらで補完した推定。次回ヒアリングでの検証が必要 - `【要確認】` … 企画の分岐点となるため、優先的に確認したい論点 --- ## 1. 3分で読む版 ### 何を作るのか **既存の業務システムから進捗を「自動で拾い上げ」、3つの視点（開発者・PM・経営層）に自動翻訳して見せるプロジェクト可視化プラットフォーム。** さらに、集まった実作業ログからプロセスを自動的に再構成し、「繰り返されている定型作業」を検出して自動化候補として提案する。 ### なぜ既存ツールでは駄目なのか Jira、Backlog、Notion、Asana、Redmine — すべて優れたツールである。 しかしこれらは共通して **「人間が正しくステータスを更新し続ける」ことを前提**に設計されている。 少人数チームが多数のプロジェクトを並行して回す環境では、この前提が真っ先に崩れる。 ``` 導入直後 1ヶ月後 3ヶ月後 6ヶ月後 ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ 全員が │ → │ 忙しい人 │ → │ 更新が │ → │ 誰も │ │ 律儀に │ │ から更新 │ │ 週1に │ │ 見ない │ │ 入力 │ │ が遅れる │ │ なる │ │ 墓場 │ └────────┘ └────────┘ └────────┘ └────────┘ ↑ ↓ └────────── ツールを乗り換える ───────────────┘ ``` **ツールが悪いのではなく、「入力を人間に依存する」というアーキテクチャが少人数・多プロジェクト環境と構造的に相性が悪い。** ### 核となる発想 — Zero-Input（入力させない）進捗管理 エンジニアもPMも、実は**すでに大量の進捗シグナルを日々発信している**。 | 発信している場所 | そこにある進捗情報 | |---|---| | GitHub / GitLab | コミット、PR、レビュー、マージ、Issue | | Slack / Teams | 「〇〇終わりました」「××で詰まってます」 | | Google Calendar | 打合せ、レビュー会、現場作業の予定と実績 | | Google Drive / Notion | 仕様書、議事録、報告書の更新 | | 見積・請求・受発注 | 案件のフェーズ、金額、納期 | | 現場報告・点検レポート | 実作業の完了実績 | これらは**すでに存在している**。ただ、バラバラで、人間が読める形になっていないだけだ。 ``` 【従来】 人間が入力する → ツールが表示する ↑ ここで破綻 【PRISM】 既存システムが吐くログ → AIが解釈・推定 → 人間は訂正するだけ ↑ 負荷が1/10 ``` 人間がやることは「入力」ではなく「**AIの推定が違っていたときの訂正**」だけになる。 そして訂正はそのまま学習データになる（訂正するほど精度が上がる）。 ### 3階層への自動翻訳 同じ実態を、見る人の役割に応じて自動的に翻訳して見せる。これが2つ目の柱。 | 階層 | 見えるもの | 必要な粒度 | |---|---|---| | 経営層 | 全27案件のうち赤信号3件。うち2件は同じ人のリソース超過が原因。来月の売上見込みは確度87% | 意思決定に必要な粒度。数字と信号と選択肢 | | PM | 案件Aは設計フェーズで3.2日遅延。原因は仕様確定待ち。田中さんが今週3案件を掛け持ち、稼働132% | 段取りに必要な粒度。ボトルネックと打ち手 | | 開発者 | 今日やるべきは3つ。うち1つは他の人の待ちを生んでいるので優先。報告は不要、勝手に上がる | 手を動かすのに必要な粒度。今日の一手だけ | **重要な設計思想：下の階層に「上への報告のための作業」を一切発生させない。** 経営層が見るダッシュボードは、開発者が何も追加作業をしなくても埋まる。 これが実現できないなら、このプロダクトは既存ツールと同じ末路をたどる。 ### 3つ目の柱 — プロセスの分解と自動化提案 【確認済】ヒアリングで「業務プロセスを可視化しながら自動化に向けてプロセスを分解していく」という言及があった。ここが中長期的な差別化の中核になる。 PRISMには実作業ログが蓄積されていく。ここから**プロセスマイニング**の手法で、「実際に行われている業務フロー」を再構成する。 ``` 【誰も書いていない、しかし実在するプロセス】 受注 ──→ キックオフ ──→ 現場調査 ──→ 見積修正 ──→ 実施 │ │ (平均2.1日) │ (平均5.4日) │ (平均9.8日) ★ │ │ │ │ │ └─ 25%のケースで └─ 40%のケースで │ ここで停滞 見積修正が2回発生 ★ │ └─ 「受注→キックオフ」が特定の1名に依存（属人化スコア 0.91）★ ★ = PRISMが自動検出した改善ポイント ``` 検出した定型パターンに対して、PRISMは自動化を提案する。 - 「この報告書作成、毎回同じ形式で月8回発生しています。自動生成しますか？」 - 「見積修正の40%は"現場条件の相違"が原因。事前チェックリストを作りますか？」 - 「この承認、過去120件すべて承認されています。閾値以下は自動承認にしますか？」 **可視化 → 分解 → 自動化 という段階を、ツールが伴走する。** --- ## 2. 解決する課題（ヒアリングからの抽出） | # | 課題 | ヒアリング上の根拠 | PRISMの解 | |---|---|---|---| | 1 | 業務の属人化 | 【確認済】「少人数でずっと回していると、業務が属人化してしまいがち」 | 暗黙知の自動抽出、バス係数の可視化、ナレッジカード自動生成 | | 2 | 進捗が見えない | 【確認済】「今どういう進捗状況にあるのかが可視化されると」 | Zero-Input進捗推定 | | 3 | 3階層それぞれの視点 | 【確認済】「開発者」「プロジェクト管理者」「経営層」を明示的に列挙 | 3階層自動翻訳ビュー | | 4 | プロジェクト多重化 | 【確認済】「会社の中で動いているプロジェクトが多い状態」 | ポートフォリオ横断ダッシュボード、リソース競合検出 | | 5 | 次の一手の判断遅れ | 【確認済】「次の手を打ちやすい」 | 予兆検知アラート、シナリオシミュレーション | | 6 | 自動化の入口が分からない | 【確認済】「自動化に向けてプロセスを分解していく」 | プロセスマイニング、自動化候補スコアリング | | 7 | リソース配分の最適化 | 【確認済】「リソース管理」への言及 | 稼働率ヒートマップ、負荷平準化提案 | --- ## 3. 提供価値（ステークホルダー別） ### 開発者・現場担当者にとって - **報告のための作業がゼロになる。** 週報も日報も進捗入力も、原則不要。 - **「今日やること」が3つに絞られて提示される。** 優先順位の判断を委ねられる。 - **自分の作業が誰の待ちを解いているかが見える。** 仕事の意味が可視化される。 - **知識が自動でカード化される。** 「あの時どうやったっけ」が検索できる。 ### プロジェクトマネージャーにとって - **進捗確認のための会議・チャットが激減する。** 聞かなくても分かる。 - **遅延が「起きてから」ではなく「起きる前」に分かる。** 予兆検知。 - **リソースの取り合いが数値で見える。** 「田中さんが3案件で稼働132%」 - **複数案件を同じ画面で管理できる。** 案件ごとにツールを開き直さない。 ### 経営層にとって - **全社の案件ポートフォリオが1画面で見える。** 何件が順調で、何件が危ないか。 - **危険な案件の「原因」まで下りられる。** 信号の色だけでなく理由が分かる。 - **意思決定のシミュレーションができる。** 「この人を投入したらどうなるか」 - **属人化リスクが数値で見える。** 「この人が抜けたら止まる案件が5件」 --- ## 4. 差別化の本質は3点 1. **「入力させない」** — 唯一、人間の入力に依存しないアーキテクチャ 2. **「3階層への自動翻訳」** — 同じデータを役割別に自動で言い換える 3. **「可視化で終わらない」** — 分解して自動化まで伴走する 特に3点目が重要である。多くの可視化ツールは「見える化」で止まり、「見えたけど何も変わらない」という状態を生む。PRISMは可視化を**自動化への前工程**として位置づける。 詳細な競合比較は `05_market_research.md` を参照。 --- ## 5. 最大のリスクと対策（要約） ### リスク1：AIの進捗推定精度が実用に耐えない **これが最大かつ唯一の致命的リスク。** 推定が外れ続けるなら価値がゼロになる。 - Phase 0 で実データによる精度検証を最優先で行う - 推定には必ず**確信度**を付与し、低いものは「要確認」として人間に投げる - 訂正が学習データになる設計 - 初期は「推定」ではなく「シグナルの集約表示」から始め、段階的に推定へ移行 ### リスク2：連携できないデータがある - LINE/Slackボットへの一言報告（「A現場終わりました」）を受け口にする - Excel/スプレッドシートの定期取り込み - **「全部が繋がらなくても、繋がった分だけ価値が出る」**設計にする ### リスク3：監視ツールだと受け取られる - **個人の生産性を評価する指標を、意図的に実装しない** - 見せるのは「作業量」ではなく「詰まり」と「待ち」 - 開発者ビューの第一義的価値は「上への報告が消えること」に置く - 導入時に「何を見て、何を見ないか」を明文化して全員に開示する ### リスク4：既存ツールとの共存 - **PRISMは置き換えを求めない。** 既存ツールの上に乗る「レイヤー」として設計する - Jiraを使い続けたまま、PRISMがそこからデータを読む - これは弱みではなく強み。導入判断のハードルが劇的に下がる リスク登録簿としての詳細は `06_technical_architecture.md` の §7 を参照。 --- ## 6. 次のアクション | # | アクション | 目的 | 時期 | |---|---|---|---| | 1 | 和田様への詳細ヒアリング（2回目） | 【要確認】項目の解消 | 2週間以内 | | 2 | 実プロジェクト2〜3件の業務プロセス実地観察 | As-Isの正確な把握 | 1ヶ月以内 | | 3 | 既存ツールのデータ提供依頼（匿名化可） | 推定精度の技術検証 | 1ヶ月以内 | | 4 | 進捗推定エンジンのPoC | 最大リスクの検証 | 2ヶ月以内 | | 5 | 3階層ビューのプロトタイプ提示 | 価値仮説の検証 | 2ヶ月以内 | 質問票は `07_hearing_design.md` にそのまま持ち込める形で用意した。 --- ## 付録：一言でいうと > **既存ツールは「人間に入力させて、見せる」。** > **PRISMは「勝手に集めて、役割別に翻訳して、自動化まで持っていく」。** > > 可視化はゴールではなく、自動化への入口である。