# PRISM — サービス機能詳細 --- ## 0. 機能マップ ``` ┌─ 収集レイヤー ────────────────────────────────────────────┐ │ F-01 コネクタ群（GitHub/Slack/Calendar/Drive/見積・請求/現場報告）│ │ F-02 一言報告ボット（APIで取れない情報の受け口） │ └──────────────────────────────────────────────────────────┘ ↓ ┌─ 推定レイヤー ────────────────────────────────────────────┐ │ F-03 進捗推定エンジン（確信度付き） │ │ F-04 訂正学習ループ │ │ F-05 予兆検知 │ └──────────────────────────────────────────────────────────┘ ↓ ┌─ 翻訳レイヤー ────────────────────────────────────────────┐ │ F-06 開発者ビュー F-07 PMビュー F-08 経営層ビュー │ │ F-09 ポートフォリオ横断ダッシュボード │ └──────────────────────────────────────────────────────────┘ ↓ ┌─ 分析レイヤー ────────────────────────────────────────────┐ │ F-10 稼働率ヒートマップ／リソース競合検出 │ │ F-11 属人化分析（バス係数） │ │ F-12 ナレッジカード自動生成 │ │ F-13 プロセスマイニング │ └──────────────────────────────────────────────────────────┘ ↓ ┌─ 自動化レイヤー ──────────────────────────────────────────┐ │ F-14 自動化候補スコアリング／提案 │ │ F-15 自動化エージェント実行基盤 │ └──────────────────────────────────────────────────────────┘ ``` Phase 1 で F-01/03/06/07/08、Phase 2 で F-05/10/11/12、Phase 3 で F-13/14、Phase 4 で F-15 を実装する。 --- ## 1. 収集レイヤー ### F-01 コネクタ群 | ソース | 取得するもの | 進捗シグナルとしての意味 | 優先度 | |---|---|---|---| | GitHub / GitLab | commit, PR, review, merge, issue, label 遷移 | 実装フェーズの進行度。最も信頼できる一次シグナル | ★★★ | | Slack / Teams | チャンネル発言、スレッド、リアクション | 「詰まり」「待ち」の検出。定性シグナルの主役 | ★★★ | | Google Calendar | 会議、レビュー会、現場作業の予定と実績 | フェーズ境界の検出（キックオフ・検収など） | ★★☆ | | Google Drive / Notion | ファイル更新、コメント、閲覧 | 設計・仕様フェーズの進行度 | ★★☆ | | 見積・請求・受発注 | 案件フェーズ、金額、納期 | 案件の外形（正本としての期日と金額） | ★★☆ | | 現場報告・点検レポート | 実作業の完了実績 | 現場作業フェーズの唯一の実績シグナル | ★★☆ | 設計方針: - **読み取り専用**で始める。書き込み権限は要求しない（導入時の心理的障壁を最小化）。 - コネクタは **1つずつ有効化できる**。全部繋がなくても価値が出る（リスク2への対策）。 - 各コネクタは最終同期時刻を必ず表示する。「いつのデータか」が分からない可視化は信用されない。 - 【要確認】リベラウェア様が実際に使っているツールの内訳。ここでコネクタの実装順が決まる。 ### F-02 一言報告ボット APIで取れない情報の受け口。Slack / LINE に常駐し、自然文の一言を構造化する。 ``` 入力: 「A現場、点検終わりました。ダクト内の腐食2箇所あり写真あとで送ります」 ↓ 出力: 案件=A現場点検 / フェーズ=現場作業 → 完了 / 所見=腐食2箇所（要フォロー） / 添付待ち=写真 / 確信度=0.93 ``` - 定型フォームを出さない。**自由文のまま投げられる**ことが要件。 - 「あとで送ります」のような未完了の約束を検出して、フォローアップ対象として保持する。 --- ## 2. 推定レイヤー ### F-03 進捗推定エンジン（本プロダクトの心臓部） シグナル群から案件のフェーズと進行度を推定し、**確信度**を必ず添える。 | 出力項目 | 例 | 備考 | |---|---|---| | 現在フェーズ | 設計 | 案件テンプレートで定義された標準フェーズ | | フェーズ内進行度 | 62 % | 過去の類似案件との比較から推定 | | 遅延 | 3.2 日 | 計画（見積・カレンダー）との差分 | | 遅延原因の推定 | 仕様確定待ち（先方回答 5 日経過） | Slack・メールの文脈から抽出 | | 確信度 | 0.87 | 0.70 未満は「要確認」に回す | **確信度の設計が信頼を作る。** 「たぶん進んでます」と言い切るツールは1回外すと二度と信用されない。 「これは0.61なので確認してください」と言うツールは、外しても信頼を失わない。 ### F-04 訂正学習ループ 人間の操作は「入力」ではなく「訂正」のみ。 ``` PRISM: 「案件Aは実装フェーズ 62% と推定しています（確信度 0.71）」 人間: 「いや、まだ設計が終わってない」 ← ワンタップ ↓ ・その案件の推定を即座に上書き ・「この種の案件では GitHub のコミットが設計完了より先に立つ」というパターンを学習 ・同種案件の推定ルールに反映 ``` - 訂正は**1タップ＋任意の一言**まで。理由の入力を必須にしない。 - 訂正履歴は精度指標として蓄積し、ダッシュボードに「推定精度 91.4 %」として開示する。 ### F-05 予兆検知 「遅延が起きてから」ではなく「起きる前」に知らせる。検知する予兆の型: | 予兆パターン | 検知条件（例） | 通知先 | |---|---|---| | 沈黙 | 案件に紐づくシグナルが N 日間ゼロ | PM | | 待ちの発生 | 「確認待ち」「回答待ち」の文脈が閾値日数を超過 | PM | | リソース衝突 | 同一人物が同週に閾値超の稼働 | PM・経営層 | | 手戻りの反復 | 同一フェーズへの逆行が2回以上 | PM | | 属人化の進行 | 特定作業のバス係数が 1 に近づく | 経営層 | --- ## 3. 翻訳レイヤー ### F-06 開発者ビュー **設計原則：この画面に「入力」を発生させない。** - 画面上部：**今日やること 3 件**だけ。それ以上出さない。 - 各カードに「他の n 人の待ちを解く」バッジ。優先順位の理由を明示する。 - 画面下部：**「報告は不要。勝手に上がっています。」** と、直近で自動的に拾われたシグナルのログ（コミット3件・Slack発言1件・レビュー1件）。 → 「監視されている」ではなく「代わりにやってくれている」と感じさせるための、最も重要なUI。 - 自分の作業量・生産性スコアは**表示しない**（そもそも算出しない）。 ### F-07 PMビュー - 担当案件のフェーズ帯（受注→設計→実装→検証→納品）と、遅延のアンバー表示。 - 遅延の**原因**を必ず1行で言い切る。「3.2日遅延」だけでは行動が決まらない。 - 稼働率ヒートマップ（メンバー × 週）。100 % 超のセルのみ発光。 - 「待ちを解く一手」の提案カード。例：「田中さんの当週稼働が 132 %。案件Cの検証を来週へ寄せると 96 % に収まります」 ### F-08 経営層ビュー - 全社サマリ：稼働案件数 / 順調 / 注意 / 赤信号。 - 売上見込みと**確度**（例：1.82 億円・確度 87 %）。 - 赤信号案件のリスト。**原因でグルーピング**する（「うち2件は同一人物のリソース超過」）。 → 経営判断は「案件ごと」ではなく「原因ごと」に打つ方が効率が良い。 - 属人化リスク：「この人が抜けたら止まる案件が 5 件」。 - シナリオシミュレーション：「この人を投入したらどうなるか」。 ### F-09 ポートフォリオ横断ダッシュボード 案件ごとにツールを開き直さないための一覧。ソート軸は「危険度」「納期」「金額」「停滞日数」。 --- ## 4. 分析レイヤー ### F-10 稼働率ヒートマップ／リソース競合検出 - 人 × 週のグリッド。100 % 超のセルのみアンバー〜コーラルで発光。 - 競合検出：同一人物が同週に複数案件のクリティカルパス上にいる状態を検出。 - 平準化提案：どの作業を何週ずらせば全員 100 % 以下に収まるかを提示。 ### F-11 属人化分析（バス係数） - 作業単位で「その作業を実行した実績があるのは何人か」を数える。 - バス係数 1（＝1人しかできない）の作業を列挙し、案件への影響度で並べる。 - **属人化スコア**（0〜1）を作業・人・案件の3粒度で算出。 - ここが【確認済】課題「業務の属人化」への直接の解。 ### F-12 ナレッジカード自動生成 - Slack・議事録・PRレビューから「判断」と「その理由」のペアを抽出してカード化。 - 例：「点検時にダクト内腐食を見つけたら、写真2枚＋位置図をセットで残す（2026-03 A現場の手戻りが理由）」 - 検索の入口は自然文。「あの時どうやったっけ」で引ける。 ### F-13 プロセスマイニング 蓄積された実作業ログから、**誰も書いていないが実在するプロセス**を再構成する。 出力するもの: 1. **実プロセスマップ** — ノード（フェーズ）とエッジ（遷移）。エッジの太さ＝通過件数、色＝滞留時間。 2. **滞留のホットスポット** — 平均滞留日数が長い遷移（例：見積修正→実施 9.8 日）。 3. **手戻りループ** — 自己ループとその発生率（例：見積修正が 40 % で2回発生）。 4. **属人化ポイント** — 特定の1名に依存する遷移（例：受注→キックオフ、属人化スコア 0.91）。 5. **バリアント分析** — 「標準ルート」から外れたケースの類型化。 --- ## 5. 自動化レイヤー ### F-14 自動化候補スコアリング／提案 検出した定型パターンを、以下の軸でスコアリングして提案順を決める。 | 軸 | 意味 | |---|---| | 頻度 | 月あたり何回発生しているか | | 定型度 | 手順・入出力のばらつきの小ささ | | 削減時間見込み | 1回あたり所要時間 × 頻度 | | 失敗コスト | 自動化を誤ったときの影響（承認系は高い） | | 実装容易性 | 既存コネクタの権限だけで実行できるか | 提案UIは常に**「試す」「あとで」の2択**。断る操作を軽くする。 提案の例: - 「この報告書作成、毎回同じ形式で月 8 回発生しています。自動生成しますか？（削減見込み 4.2 時間/月・確信度 0.88）」 - 「見積修正の 40 % は"現場条件の相違"が原因。事前チェックリストを作りますか？」 - 「この承認、過去 120 件すべて承認されています。閾値以下は自動承認にしますか？」 ### F-15 自動化エージェント実行基盤 提案した自動化を実際に実行する層。Phase 4 の中核であり、Automation Add-on の課金対象。 - 実行は必ず**ドライラン → 承認 → 本番**の3段。 - 全実行にログと巻き戻し手段を持たせる。 - 失敗時は自動停止し、人間に戻す（暴走を構造的に防ぐ）。 --- ## 6. 画面設計とデザイン原則 ### 3つの原則 1. **入力欄を作らない。** テキストボックス・送信ボタンをUIから排除する。プロダクトの主張と矛盾する。 2. **推定であることを隠さない。** 確信度を常に併記する。断定しないことが信頼を作る。 3. **監視の記号を使わない。** 目・カメラ・虫眼鏡・顔のモチーフを禁止する。見せるのは人ではなく「詰まり」と「待ち」。 ### ビジュアルアイデンティティ `design_guidelines.md` を正本とする。要約: - コンセプト：1本の白色光がプリズムを抜けて4本の色帯（進捗・リソース・知識・リスク）に分かれる。 - 光は常に「集まる → 分かれる」方向。逆は使わない。 - カラー：`#070B18`（ベース）／`#22D3EE`（進捗）／`#A78BFA`（知識）／`#34D399`（順調）／`#FBBF24`（注意）／`#FB7185`（危険）。 - 数値は等幅フォント＋単位必須（`132 %` `0.87` `3.2 日`）。 ### モックアップ 本デモの `mock/app_mock.html` に、6画面（経営層 / PM / 開発者 / プロセスマイニング / 自動化提案 / 設定・連携）の実装イメージを用意した。