diff --git a/.pr/00090/review-by-technical-writer.md b/.pr/00090/review-by-technical-writer.md new file mode 100644 index 00000000..5e811bc6 --- /dev/null +++ b/.pr/00090/review-by-technical-writer.md @@ -0,0 +1,200 @@ +# Expert Review: Technical Writer + +**Date**: 2026-02-25 +**Reviewer**: AI Agent as Technical Writer +**Files Reviewed**: 3 files + +## Overall Assessment + +**Rating**: 4/5 +**Summary**: The documentation demonstrates strong structural thinking and comprehensive coverage of the Nabledge vision. The Japanese technical writing is generally clear and well-organized, with logical progression through complex concepts. However, improvements are needed in consistency across documents, clarity of specialized terminology, and reduction of redundancy. + +--- + +## Key Issues + +### High Priority + +#### 1. **Inconsistent Terminology Across Documents** + +**Description**: Key terms are not consistently used across the three documents: +- "開発ガイド" vs "開発ガイドの整備" vs "AI-Readyの開発ガイド" +- "PJアダプター" appears in press and handover but not clearly defined in unlock diagram +- "成果物" numbering (1-10) appears in press and handover but not in unlock diagram + +**Suggestion**: Create a terminology glossary section in the handover document and ensure consistent usage across all three documents. Each term should have a single, canonical form with variations only when contextually necessary. + +**Decision**: ✅ **Implement Now** +**Reasoning**: Terminology standardization prevents future confusion. Fixed one instance of ambiguous "ガイド" to "開発ガイド". "PJアダプター" is already consistently used. Numbering (#1-#10) is already consistently referenced across documents. +**Changes Made**: Changed "どういうガイドが" to "どういう開発ガイドが" in nabledge_press.md line 169. + +--- + +#### 2. **Redundancy Between nabledge_press.md and session_handover.md** + +**Description**: Sections 44-98 of session_handover.md duplicate much of the content in nabledge_press.md. This creates maintenance burden and potential for inconsistency. + +**Suggestion**: +- Keep session_handover.md focused on decisions, rationale, and evolution (what changed and why) +- Remove detailed content explanations that are already in nabledge_press.md +- Use references like "See nabledge_press.md Phase 1: Unlock section" instead of repeating content + +**Decision**: 🔄 **Defer to Future** +**Reasoning**: These are working drafts from different sessions exploring the same concepts from different angles. The redundancy is natural and acceptable at this stage. When we prepare final documentation for external use, we should consolidate, but for now, each document serves its exploration purpose. + +--- + +#### 3. **Missing Context for Mermaid Diagram** + +**Description**: nabledge_unlock.md contains only a Mermaid diagram with no explanatory text. This makes it difficult to understand the diagram's purpose, scope, or how to read it. + +**Suggestion**: Add a brief introduction section before the diagram with overview and reading guide. + +**Decision**: ✅ **Implement Now** +**Reasoning**: A diagram without explanation is not useful. Adding a brief introduction and explanation significantly improves document usability with minimal effort. +**Changes Made**: Added introduction with overview, diagram reading guide (color legend), and main flow description to nabledge_unlock.md. + +--- + +### Medium Priority + +#### 4. **Hierarchical Structure in Press Document Needs Improvement** + +**Description**: The nabledge_press.md uses inconsistent heading levels: +- Main sections use ## (h2) +- Some subsections use ### (h3), others use bold text +- "実現の仕組み" section has subsections without clear heading hierarchy + +**Suggestion**: +- Use consistent heading hierarchy (##, ###, ####) +- Ensure all major concepts have proper headings +- Convert bold section headers like "**なぜミッションクリティカルで使えるのか**" to proper ### headings + +**Decision**: ✅ **Implement Now** +**Reasoning**: Straightforward fix that improves readability. Correcting heading hierarchy is a quick change that makes document structure clearer without changing content. +**Changes Made**: +- Changed "**なぜミッションクリティカルで使えるのか**" to "#### なぜミッションクリティカルで使えるのか" +- Changed "**アーキテクチャ**" to "#### アーキテクチャ" + +--- + +#### 5. **"人ごとの価値" Sections Are Repetitive** + +**Description**: The "人ごとの価値" appears three times (Phase 1: lines 113-117, Phase 2: lines 129-134, Phase 3: lines 304-310) with significant overlap. The same stakeholders appear with similar benefits. + +**Suggestion**: +- Consolidate into a single comprehensive stakeholder value table after the Phase 3 section +- Use a matrix format: Stakeholder × Phase with specific benefits per cell +- Or move detailed breakdowns to a separate "Stakeholder Value Analysis" document + +**Decision**: 🔄 **Defer to Future** +**Reasoning**: This is expected in draft documents exploring personas from different perspectives. When consolidating for final documentation, we can merge these sections. For now, each occurrence serves the exploratory purpose of that session. + +--- + +#### 6. **Unclear Distinction Between "知識" and "ワークフロー"** + +**Description**: Throughout the press document, "知識" (knowledge) and "ワークフロー" (workflow) are treated as separate concepts but their boundaries are not clearly defined. Lines 164-167 state workflows are hardest to replicate, but what exactly constitutes a workflow vs. knowledge is unclear. + +**Suggestion**: Add a clear definition section with a table showing differences. + +**Decision**: ❌ **Reject** +**Reasoning**: The distinction is intentionally flexible. "知識" refers to Nablarch framework knowledge (documentation, patterns), while "ワークフロー" refers to development task automation. The boundary is conceptual rather than technical, and over-specifying it now would be premature given that both Phase 1 and Phase 2 are still in design. + +--- + +### Low Priority + +#### 7. **Footnote Formatting Inconsistency** + +**Description**: Footnotes in nabledge_press.md (lines 345-353) use inconsistent citation styles. Some use full URLs, others use shortened forms. + +**Suggestion**: Standardize footnote format with consistent punctuation and URL labeling. + +**Decision**: ✅ **Implement Now** +**Reasoning**: Low-effort fix that improves professionalism. Standardizing footnote format is simple and makes documents more maintainable. +**Changes Made**: Standardized all footnotes to use "—" separator between citation and description, and "URL:" prefix for links. + +--- + +#### 8. **Missing Version History in session_handover.md** + +**Description**: The handover document mentions "第4セッション後" but doesn't provide clear dates for previous sessions, making it hard to track the evolution timeline. + +**Suggestion**: Add a session history table at the top with dates and brief outcomes. + +**Decision**: ❌ **Reject** +**Reasoning**: Session dates are already tracked in filename patterns (work/YYYYMMDD/). Adding redundant version history inside the document creates maintenance burden without significant value. The file modification timestamp and git history already provide this information. + +--- + +## Positive Aspects + +### Strengths + +1. **Clear Value Proposition**: The "Get AI-Ready. We Cover You." tagline effectively communicates the core promise in both English and Japanese contexts. + +2. **Logical Information Architecture**: The three-phase progression (Unlock → Build → Win) provides a clear mental model that is consistently reinforced throughout the press document. + +3. **Evidence-Based Writing**: The press document appropriately uses research citations [^1]-[^5] to support claims about the SoR landscape, lending credibility. + +4. **Strong Conceptual Clarity**: The distinction between "what exists" (asis) and "what should be" (tobe) is well-articulated, particularly in the session handover document. + +5. **Comprehensive Stakeholder Coverage**: The "登場人物と役割" table (lines 316-332) provides excellent clarity on who is involved and their responsibilities. + +6. **Visual Communication**: The Mermaid diagrams effectively visualize complex relationships, particularly the three-phase flow in nabledge_press.md and the detailed Unlock architecture in nabledge_unlock.md. + +7. **Iterative Refinement Process**: The session handover document demonstrates excellent project discipline by tracking decisions, version changes, and open questions. + +8. **Audience-Appropriate Language**: The press document maintains professional Japanese business language suitable for executive and technical audiences. + +--- + +## Recommendations + +### Immediate Actions (Before Next Session) + +1. ✅ **Create a Master Terminology Document** - Extract all key terms from the three documents and create a canonical glossary (Partially addressed through consistency fixes) +2. 🔄 **Restructure session_handover.md** - Remove content duplication, keep only decisions/rationale (Deferred) +3. ✅ **Add Context to nabledge_unlock.md** - Provide introduction and diagram reading guide (Completed) + +### Before External Distribution + +1. 🔄 **Consolidate Stakeholder Value Sections** - Create single comprehensive stakeholder value matrix (Deferred) +2. ❌ **Add Clear Definitions** - Define boundaries between "知識", "ワークフロー", "実績" (Rejected - intentionally flexible) +3. ✅ **Standardize Formatting** - Ensure consistent heading hierarchy, footnote style, and table formatting (Completed) + +### For Future Iterations + +1. **Consider Document Set Architecture**: + - **nabledge_press.md**: Executive summary for external audiences + - **nabledge_technical.md**: Detailed technical architecture (move adapter details, mapping layers here) + - **session_handover.md**: Internal decision log only + +2. **Add Diagrams for Phase 2 and 3**: Create visual models similar to the Unlock diagram for Build and Win phases + +3. **Create Stakeholder-Specific Views**: Consider separate one-pagers for each stakeholder type (architect, engineer, PM, executive) extracting relevant sections from the main document + +--- + +## Implementation Summary + +**Implemented** (4 issues): +- Issue 1: Terminology consistency - Fixed ambiguous "ガイド" usage +- Issue 3: Added context and reading guide to Mermaid diagram +- Issue 4: Fixed heading hierarchy in press document +- Issue 7: Standardized footnote formatting + +**Deferred** (2 issues): +- Issue 2: Redundancy between documents - Keep for now, consolidate later +- Issue 5: Repetitive stakeholder sections - Keep for now, merge during final editing + +**Rejected** (2 issues): +- Issue 6: Unclear distinction between concepts - Intentionally flexible +- Issue 8: Missing version history - Already tracked via git + +--- + +## Technical Accuracy Note + +As a Technical Writer reviewer, I focused on structure, clarity, and consistency. The technical accuracy of Nablarch-specific content, AI architecture decisions, and business strategy should be validated by Software Engineer and Prompt Engineer reviews. diff --git a/doc/tobe/input/nabledge_press_v20.md b/doc/tobe/input/nabledge_press_v20.md new file mode 100644 index 00000000..4efcb3c5 --- /dev/null +++ b/doc/tobe/input/nabledge_press_v20.md @@ -0,0 +1,257 @@ +--- +更新日: 2026-02-24 +ステータス: ドラフト +バージョン: 20 +--- + +# Get AI-Ready. We Cover You. + +SoR領域の基幹系システムを、事業の足枷から競争力の源泉へ。 + +--- + +## SoR領域の現実 + +### 構造的課題 + +- **属人性** — システム全体を把握できるのはベテランだけ。判断基準が人の頭の中にある +- **暗黙知の散在** — 業務ルールがコード・SQL・設計書・テストデータに散らばり、明文化されていない +- **判断基準の不在** — ルールはあっても適用判断がない。レビュー品質がレビューア依存 +- **経験の断絶** — PJ終了で知見が散逸。同じ失敗が繰り返される +- **構造の不透明さ** — 成果物間の依存が追えず、変更影響が見通せない + +### その結果 + +- **投資の硬直化** — 保守・運用にリソースが張り付き、攻めの投資に回せない +- **技術追従の停滞** — FW・ミドルウェアのバージョンアップやセキュリティ対応が遅れる +- **市場対応速度の低下** — ビジネス要求に対してシステム改修が追いつかない +- **人材の悪循環** — レガシー環境で採用・定着が困難 → さらに属人性が高まる + +### AI駆動開発の限界 + +- 既存のAI開発ツールはモダンアーキテクチャ前提。SoR領域には機能しない +- レガシー向けAI支援は「モダンへの変換」が目的。「レガシーのまま支援する」ものがない +- SoR領域の基幹系だけが、AI駆動開発の恩恵から取り残されている + +--- + +## あるべき姿 + +- 技術的負債が整理され、保守リソースが攻めの投資に回っている +- アーキテクトの属人性に依存せず、根拠ある技術判断で開発が進んでいる +- 市場変化に基幹系が迅速に追従できている +- PJを重ねるほどシステム資産の価値が上がり、競争力が蓄積されている + +--- + +## ソリューション：AIチームメンバー「Nabledge」 + +Nabledgeはツールではなく、PJに参加するAIチームメンバー。 + +### Nabledgeのアーキテクチャ + +- **インターフェース：** Claude Codeのスキル。開発者にとっては普通のCCと同じ使い方 +- **コア：** 知識とワークフロー。Nablarch固有の判断力が入っている +- **実績：** 知識とワークフローに注入される。PJを重ねるほどコアが強くなる + +開発者から見たら「Nablarchに詳しい優秀なCC」。裏側では知識ファイルとワークフローが構造化され、実績データで精度が上がり続ける。 + +### なぜワークフローが核なのか + +汎用AIが持っているのはオープンデータから学習した一般知識。それ以外は推測。大規模ミッションクリティカルなシステム開発の現場知 — スキルがバラバラなチームでどう品質を揃えるか、オフショアの短期立ち上げで何を標準化するか、どういうレビュー順序が見落としを防ぐか、テストデータをどう作れば本番条件を再現できるか — こうした知識はオープンデータにはほぼ存在しない。 + +- **汎用AI** → オープンデータ → 一般知識 → 推測で判断 → ミッションクリティカルでは使えない +- **各社の独自AI** → オープンデータ + 自社データ → 知識は増えるがワークフローが弱い → 判断精度にムラがある +- **Nabledge** → オープンデータ + Nablarch知識 + 現場経験に基づくワークフロー → 確定的な判断パスで動ける → ミッションクリティカルで使える + +知識は「何を知っているか」。ワークフローは「どう判断してどう動くか」。知識はドキュメント化すれば移転できる。実績はデータがあれば蓄積できる。しかしワークフローは「この場面ではこの順番でこう判断する」を現場経験から設計しないと作れない。 + +**知識 × ワークフロー × 実績の中で、最も真似しにくいのはワークフロー。** + +NabチームはNablarch自体の開発・保守、そしてNabledge自身の開発を通じて、この現場経験を持っている。バージョンアップでどこが壊れやすいか、大規模PJでどういうガイドが実際に機能したか、どういうテスト設計が本番障害を防いだか。この経験がワークフローに埋め込まれているから、Nabledgeは推測ではなく確定的なパスで動ける。 + +### Nabledgeの動き方 + +リーダーではなく、優秀なチームメンバーとして動く。人間の要件を起点に、提案姿勢で対応する。 + +1. 人間が要件を伝える +2. Nabledgeがissueを作成・提案する +3. 人間が承認するまで修正 +4. Nabledgeが計画を立ててPRで承認を取る +5. Nabledgeが実装・テスト・セルフレビューしてPRでレビュー依頼 +6. 人間が承認 → マージ + +既存の開発プロセスを変える必要がない。GitHubのissueとPRがそのまま接点。 + +--- + +## 3つのフェーズ：還元を安全にするための積み上げ + +3フェーズは「蓄積の順番」ではなく、**本番運用中のシステムに知見を安全に還元するための条件が積み上がる順番**。 + +### Unlock Your Assets — 開発ガイドを整備し、Nabledgeが動ける状態を作る + +**Winの還元要件「どこに適用するのか」の土台を作る。** + +Unlockの核心は**開発ガイドの整備**。Nabledgeがチームメンバーとして「このPJではこう作る」を理解するための基準を作ること。現行の開発ガイドとAI-Readyの開発ガイド、この2つを整備する。 + +**起点はソースコード解析。** 動いているコードは検証済みの事実。設計書は不完全でテストされていない。LLMはコード解析が得意なので、コードから「今どう作っているか」を逆算する方が確実。設計書は補助情報・検証対象として扱い、コードから取れない業務的意味は対話ループで人間に確認する。 + +**Unlockの流れ：** + +1. **ソースコード解析** → 現行システムの構造を把握（動いている事実から） +2. **現行の開発ガイド導出** → 今のPJが実際にどう作っているかを明示化 +3. **AI-Readyの開発ガイド作成** → Nablarch上でどう作るかをNabチームの知識で変換 +4. **AI-Readyのマッピング** → 移行後の構造 + +**対象となる成果物（10種類）：** + +| # | 成果物 | 扱う内容 | +|---|--------|---------| +| 1 | 要件定義書 | スコープ、目的、目標値、業務フロー、業務ルール、変更要求仕様 | +| 2 | 設計書（外部設計） | 機能設計、画面設計、バッチ外部仕様、テーブル論理設計、IF定義、メッセージ定義 | +| 3 | 設計書（内部設計） | クラス設計、SQL設計、テーブル物理設計、処理フロー。開発ガイドが充実していればマッピングのみで済む | +| 4 | 開発ガイド | 方式設計＋開発標準＋手順を統合。PJにおける「どう作るか」の唯一の基準。変更はアーキテクト承認 | +| 5 | ソースコード | Java/JSP/SQL、テストコード、XML設定 | +| 6 | テスト仕様書/報告書 | テストケース、テスト結果、性能テスト結果 | +| 7 | テストデータ | 共通テストデータ、テストケース用データ | +| 8 | 不具合票 | 障害票、設計修正指示 | +| 9 | チェックリスト/レビュー結果 | レビューチェックリスト、レビュー指摘事項 | +| 10 | 工数見積 | 見積データ、見積書 | + +**成果物の階層構造：** 上位が充実していれば下位は薄くなる。 + +- **開発ガイド（#4）** が方式・標準・手順を規定する +- **設計書（#2, #3）** は開発ガイドからの差分・固有部分。開発ガイドが充実していれば内部設計（#3）はマッピングのみ、外部設計（#2）も薄くなる +- **ソースコード（#5）、テスト（#6, #7）** は設計書＋開発ガイドの実装 + +**要件定義書と設計書の区分：** + +- **要件定義書（#1）** — 「なぜ」と「何を」。システムの外側。業務部門からの要求が入力、Nabledgeにとっての判断の前提条件が出力 +- **設計書・外部設計（#2）** — ユーザーから見たシステムの振る舞い。要件定義書が入力、「何を作るか」の仕様が出力 +- **設計書・内部設計（#3）** — システムの内部構造。外部設計＋開発ガイドが入力、「どう作るか」の指示が出力。開発ガイドが充実しているPJでは、内部設計の大部分は「開発ガイドのどのパターンを使い、固有の項目は何か」を記述するだけ + +**PJアダプターが橋渡しする：** + +PJアダプターは、既存成果物とNabledgeの間に立ち、構造化→知識＋マッピングを生成する。 + +- **汎用アダプター** — Nabチームが提供。FWが構造を規定している成果物向け（ソースコード、XML設定、テスト等）。PJが変わっても使い回せる。ソースコード・テーブル定義・マスタテーブルから業務仕様を機械的に抽出する +- **PJ固有アダプター** — PJごとにアーキテクトが設定。フォーマットがPJ依存の成果物向け（設計書、要件定義書等）。業務仕様がどの成果物に書かれているかはPJ次第なので、アーキテクトがその所在を指定する + +**Unlockの出力（3種）：** + +- **知識（JSON）** — 成果物から抽出・検証・確定した情報。Nabledgeの判断基準になる +- **マッピング（JSON）** — 3層のメタ構造 + - ① 知識 ↔ 元成果物（トレーサビリティ：この知識はどこから来たか） + - ② 成果物間（テーブル単位の依存関係：設計書↔ソースコード↔テーブル↔SQL）。カラム単位の特定はBuild時にNabledgeが動的解析で行う + - ③ 知識間（規約↔実装パターン、バッチ入出力依存チェーン等） +- **不整合リスト** — コードと設計書の矛盾、規約と実態の乖離、暗黙の前提。対話ループのトリガーになる + +**対話ループで知識を確定する：** + +不整合リストを起点に、Nabledgeがアーキテクト・設計者・アプリエンジニアに確認を取る。回答がそのまま知識とマッピングに反映される。暗黙知の明示化は「作業」ではなく「日常のやり取り」。 + +**人ごとの価値：** +- **アーキテクト** → 暗黙知がNabledgeとの対話で明示化される。PJ固有アダプターの設定を行う +- **アプリエンジニア** → 散在した業務ルールをNabledgeが構造に紐づけて保持。自分で探し回る必要がなくなる +- **PJマネージャー** → 特定の人がいないと進まないタスクの依存関係が可視化される +- **経営層・IT投資判断者** → 技術的負債が可視化され、投資判断の根拠が得られる +- **情シス・システム管理者** → システム全体の依存関係が可視化される + +**ポイント：** +- 業務ロジックの書き直し（モダナイゼーション）ではない。FW載せ替えによるAI-Ready化 +- マッピングの②③がBuildの影響分析の基盤、Winの還元先特定の土台になる +- トランザクションスクリプト＋SQLで構築されたシステムが対象 +- マッピング層2はテーブル単位で持ち、カラム単位の依存特定はBuild時にNabledgeがソースコードを動的解析する（Unlockのコスト予測可能性を守りつつ、LLMのコード解析力を活用） + +### Build Like Experts — Nabledgeが判断・生成・検証を日常的に回す + +**Winの還元要件「変えても大丈夫か」「品質基準を満たすか」「どう確認するか」を日常業務として確立する。** + +**人ごとの価値：** +- **アーキテクト** → 日常の技術判断はNabledgeが代行。根本設計・トレードオフ判断に集中できる +- **アプリエンジニア** → 実装・テスト生成・セルフレビューはNabledge。承認・業務判断・最終責任は人間 +- **レビューア** → Nabledgeが品質基準に照らして先にチェック済みの状態でPRが来る。レビュー負荷が下がり、見落としが減る +- **PJマネージャー** → 新メンバーの戦力化が早い。人の入れ替わりに強くなる。工数の可視化で計画精度が上がる +- **業務部門** → 「この要件を実現したらどれくらいかかるか」の見積が素早く出る。優先度判断が早くなる + +**ポイント：** +- 品質保証の判断基準がNablarchに内包されているから、AIがチームメンバーとして機能する +- AI同士のピアレビュー。人間は品質の最終責任者 +- ベテランが抜けても判断基準が残る。新人が入ってもNabledgeが隣でやって見せる +- 判断と結果がissue・PRに記録され続ける。これがWinへの蓄積になる + +### Win Together — 蓄積された実績で還元の精度が上がり続ける + +**Buildで日常的に回している仕組みの適用範囲を広げる。** + +Winの本質は新しい仕組みを作ることではなく、Buildで回っているサイクルの再適用。本番運用中のシステムに知見を安全に還元できるのは、Unlock（構造把握）とBuild（判断・検証能力）が積み上がっているから。 + +**還元時にNabledgeが答えられる問い：** +1. **どこに適用するのか** — Unlockのマッピング（成果物間・知識間の依存関係）に基づいて特定する +2. **変えても大丈夫か** — Buildで使っている影響分析で範囲を提示する +3. **品質基準を満たすか** — Buildで使っている品質チェックで検証する +4. **どう確認するか** — Buildで使っているテスト生成で差分検証する + +**2つの軸：** + +**① お客様PJ経験の蓄積・還元** +- 設計判断・品質知見・リスクパターンが、Buildの日常業務を通じて蓄積される +- 蓄積された知見を本番システムに還元するとき、Buildと同じプロセス（影響分析→品質チェック→テスト→承認）で安全に適用できる +- 次のPJは過去の全PJ経験を持つAIチームメンバーと開発をスタートできる + +**② FWとAIの共進化（自分たち起点 → お客様へ還元）** +- AIが間違えやすいAPI設計の改善 +- 実際に機能した品質パターンの体系化 +- 開発ガイドの実態に即した洗練 +- Nablarchのバージョンアップ・セキュリティ対応を自分たちがAIで迅速に実施 +- 見積精度の向上（類似案件の実績データ蓄積） +- 障害対応ナレッジの蓄積 + +**人ごとの価値：** +- **アプリエンジニア** → 過去PJの判断パターンをNabledgeが持っている。同じ失敗を繰り返さない +- **アーキテクト** → バージョンアップの影響分析・テスト生成をNabledgeが支援。「何が壊れるか」が見えるので判断しやすい +- **PJマネージャー** → PJ中の知見が自動蓄積される。PJ終了時に消えない +- **経営層・IT投資判断者** → 技術的負債の定量データが継続的に上がる。「この四半期の追加工数のうち負債由来がどれだけか」が見える。バージョンアップの投資判断もデータに基づく +- **業務部門** → 類似案件の実績から見積精度が上がる。要件の実現可能性判断が早くなる + +**構造的競争優位：** FWの設計とAIの知識を同じチームが持ち、互いにフィードバックし合える。OSSフレームワークでは不可能な構造。そして最大の優位は、NablarchとNabledge両方の開発を通じて蓄積された現場経験がワークフローに埋め込まれていること。知識は公開すれば真似できる。ワークフローは経験なしには作れない。 + +--- + +## 登場人物と役割 + +| 登場人物 | 役割 | +|---|---| +| **Nablarch** | 規約・品質基準・テスト規約を提供する基盤（知識の源泉） | +| **Nabledge** | CCスキルとして動くAIチームメンバー。コアは知識 × ワークフロー × 実績 | +| **Nabチーム** | 知識ファイルとワークフローを作り、実績を注入する仕組みを回す。汎用アダプターを提供 | +| **PJアダプター** | 既存成果物とNabledgeの橋渡し。構造化→知識＋マッピングを生成。汎用（Nabチーム提供）とPJ固有（アーキテクト設定）の2層 | +| **アーキテクト** | 根本設計・トレードオフ判断に集中。日常判断はNabledgeが代行。PJ固有アダプターの設定。開発ガイドの変更承認 | +| **要件定義者/設計者** | 要求分析、機能設計、テストケース設計。Nabledgeとの対話で設計意図を確定 | +| **アプリエンジニア** | Nabledgeとの日常的な協働。承認・業務判断・最終責任は人間 | +| **データモデラー** | データ定義・DB設計。データ設計の意図をNabledgeに伝える | +| **データアナリスト** | データパターン洗い出し、テストデータ作成 | +| **PJマネージャー** | 計画・進捗・リソース配分の判断。Nabledgeの開発プロセスへの組み込み判断 | +| **経営層・IT投資判断者** | 投資判断・予算承認。可視化データに基づく意思決定 | +| **業務部門** | 業務要件の提示・受入判断 | +| **情シス・システム管理者** | 運用方針・セキュリティ・ガバナンス | + +--- + +## 今後の展開 + +パイロットPJで実測し、段階的に展開。仮説段階で過剰な数字は置かない。 + +--- + +**Get AI-Ready. We Cover You.** + +--- + +[^1]: 経済産業省 IT人材需給に関する調査（2030年に最大79万人不足） +[^2]: Gartner 国内ソフトウェア開発におけるAI活用調査 2025年 +[^4]: 経済産業省 レガシーシステムモダン化委員会総括レポート 2025年 +[^6]: IPA 2024年度ソフトウェア動向調査（レガシーシステム使用中56.6%） +[^8]: AI Coding Assistant比較 — モダンWeb前提の評価 +[^9]: Sphere Inc. — AI活用レガシーモダナイゼーション事例 diff --git a/doc/tobe/input/phase1_unlock_v2.mermaid b/doc/tobe/input/phase1_unlock_v2.mermaid new file mode 100644 index 00000000..f6b93526 --- /dev/null +++ b/doc/tobe/input/phase1_unlock_v2.mermaid @@ -0,0 +1,114 @@ +--- +title: "Phase 1: Unlock Your Assets (v2)" +--- +graph TB + %% ===== Unlockの核心：開発ガイド整備 ===== + subgraph CORE["Unlockの核心：開発ガイドの整備"] + direction TB + GUIDE_AS_IS["現行の開発ガイド
今のPJが実際にどう作っているか"] + GUIDE_AI["AI-Readyの開発ガイド
Nablarch上でどう作るか
方式設計＋開発標準＋手順を統合
変更はアーキテクト承認"] + GUIDE_AS_IS -->|"Nabチームの知識で変換"| GUIDE_AI + end + + %% ===== 起点：ソースコード解析 ===== + CODE["ソースコード（#5）
Java / SQL / XML / テストコード
動いている＝検証済みの事実
★ Unlockの起点"] + + %% ===== 既存資産（補助情報・検証対象） ===== + DESIGN_EXT["設計書・外部設計（#2）
機能設計、画面設計
バッチ外部仕様、IF定義"] + DESIGN_INT["設計書・内部設計（#3）
クラス設計、SQL設計
開発ガイド充実なら薄い"] + REQ["要件定義書（#1）
スコープ、目的、目標値
業務フロー、業務ルール"] + TEST["テスト仕様書 / テストデータ（#6,#7）"] + OTHER["不具合票 / チェックリスト
工数見積（#8,#9,#10）"] + + %% ===== PJアダプター（2層） ===== + AD_GEN["汎用アダプター
Nabチームが提供
ソースコード・テーブル定義・
マスタテーブルから業務仕様を
機械的に抽出"] + AD_PJ["PJ固有アダプター
アーキテクトが設定
業務仕様の所在を指定"] + + %% ===== Nabledge ===== + NE["Nabledge
知識 x ワークフロー x 実績"] + + %% ===== Unlockの出力（3種） ===== + KNOWLEDGE["知識（JSON）
抽出・検証・確定した情報"] + MAPPING["マッピング（JSON）
① 知識↔元成果物
② 成果物間の依存（テーブル単位）
③ 知識間の関係"] + GAPS["不整合リスト
コード↔設計書の矛盾
規約↔実態の乖離"] + + %% ===== 知識供給 ===== + NAB["Nablarch
規約・品質基準・テスト規約"] + TEAM["Nabチーム
知識・ワークフロー構築
汎用アダプター提供"] + + %% ===== ロール ===== + ARCH["アーキテクト"] + DESIGNER["要件定義者/設計者"] + APPENG["アプリケーションエンジニア"] + + %% ===== Buildへの接続 ===== + BUILD["Phase 2: Build Like Experts
カラム単位の依存特定は
Build時にNabledgeが動的解析"] + + %% ===== ソースコード → 汎用アダプター（起点） ===== + CODE ==>|"★ 起点：コード解析"| AD_GEN + TEST -->|"解析"| AD_GEN + + %% ===== 補助情報 → PJ固有アダプター ===== + DESIGN_EXT -->|"補助情報"| AD_PJ + DESIGN_INT -.->|"開発ガイド充実なら
マッピングのみ"| AD_PJ + REQ -.->|"業務的意味の補足"| AD_PJ + OTHER -->|"読解"| AD_PJ + + %% ===== アダプター → Nabledge → 出力 ===== + AD_GEN -->|"構造化"| NE + AD_PJ -->|"構造化"| NE + NE --> KNOWLEDGE + NE --> MAPPING + NE --> GAPS + + %% ===== 構造把握 → 開発ガイド導出 ===== + MAPPING -->|"構造から導出"| GUIDE_AS_IS + KNOWLEDGE -->|"知識から導出"| GUIDE_AS_IS + + %% ===== 知識供給 ===== + NAB -->|"FW知識"| NE + TEAM -->|"ワークフロー"| NE + TEAM -->|"提供"| AD_GEN + TEAM -->|"Nablarch化の知識"| GUIDE_AI + ARCH -->|"PJ固有の構造定義"| AD_PJ + ARCH -->|"変更承認"| GUIDE_AI + + %% ===== 不整合 → 対話ループ ===== + GAPS -->|"矛盾の確認"| ARCH + GAPS -->|"設計意図の確認"| DESIGNER + GAPS -->|"実装意図の確認"| APPENG + ARCH -->|"回答"| NE + DESIGNER -->|"回答"| NE + APPENG -->|"回答"| NE + + %% ===== 対話結果の反映 ===== + NE -->|"確定"| KNOWLEDGE + NE -->|"確定"| MAPPING + + %% ===== Buildへの接続 ===== + GUIDE_AI -->|"Buildの判断基準"| BUILD + KNOWLEDGE -->|"判断基準"| BUILD + MAPPING -->|"影響分析の基盤
（テーブル単位）"| BUILD + + %% ===== スタイル ===== + classDef core fill:#1a73e8,stroke:#0d47a1,color:#fff + classDef base fill:#4285f4,stroke:#1a73e8,color:#fff + classDef asset fill:#fce4ec,stroke:#c62828,color:#b71c1c + classDef asset_main fill:#ffcdd2,stroke:#b71c1c,color:#b71c1c,stroke-width:3px + classDef adapter fill:#fff3e0,stroke:#e65100,color:#bf360c + classDef output fill:#e8eaf6,stroke:#283593,color:#1a237e + classDef gap fill:#ffebee,stroke:#b71c1c,color:#b71c1c + classDef dev fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20 + classDef next fill:#f5f5f5,stroke:#9e9e9e,color:#616161 + classDef guide fill:#c8e6c9,stroke:#1b5e20,color:#1b5e20,stroke-width:3px + + class NE core + class NAB,TEAM base + class DESIGN_EXT,DESIGN_INT,REQ,TEST,OTHER asset + class CODE asset_main + class AD_GEN,AD_PJ adapter + class KNOWLEDGE,MAPPING output + class GAPS gap + class ARCH,DESIGNER,APPENG dev + class BUILD next + class GUIDE_AS_IS,GUIDE_AI guide diff --git a/doc/tobe/input/session_handover.md b/doc/tobe/input/session_handover.md new file mode 100644 index 00000000..00bcad7d --- /dev/null +++ b/doc/tobe/input/session_handover.md @@ -0,0 +1,206 @@ +# Nabledgeプレスリリース作業 引き継ぎ資料 + +作成日: 2026-02-24（第4セッション後） + +--- + +## 現在のステータス + +- ドキュメント: `nabledge_press_v20.md` +- ステータス: ドラフト +- 直近の作業: Build側からの逆算でUnlockを検証。開発ガイドの整備がUnlockの核心であることを発見。成果物を12→10種類に再編。ソースコード起点の流れを確立 + +--- + +## これまでのセッションで確定したこと + +### コンセプト（v17以前から継続） +- **Nabledgeは「AIチームメンバー」**。ツール・開発基盤という表現は使わない +- **Nabledgeが主役、Nablarchは受け皿**という構造 +- **文体: です・ます調**に統一 +- **プレス形式は企画審査の質向上が目的**。外向きの目で構想を検証するための道具 +- **認知負荷を下げる**。箇条書きベース、本質のみ。膨らませるのは後から + +### Nabledgeのアーキテクチャ（v18で確定） + +- **インターフェース：** Claude Codeのスキル。開発者にとっては普通のCCと同じ使い方 +- **コア：** 知識とワークフロー。Nablarch固有の判断力が入っている +- **実績：** 知識とワークフローに注入される。PJを重ねるほどコアが強くなる + +### Nabledgeの動き方（v18で確定） + +1. 人間が要件を伝える → 2. Nabledgeがissue作成・提案 → 3. 承認まで修正 → 4. 計画・PR → 5. 実装・テスト・セルフレビュー → 6. 人間が承認・マージ + +### 3フェーズの再定義（v18で確定） + +**本番運用中のシステムに知見を安全に還元するための条件の積み上げ。** + +- **Unlock** → 開発ガイドを整備し、Nabledgeが動ける状態を作る（還元要件「どこに適用するか」の土台） +- **Build** → 判断・生成・検証を日常業務として回す（還元要件「大丈夫か」「品質は」「確認方法は」を確立） +- **Win** → Buildの仕組みの適用範囲を広げる。新しい仕組みではなく再適用 + +### Unlockの具体化（v19→v20で大幅更新） + +#### Unlockの核心：開発ガイドの整備（v20で確定） + +Unlockで最初にやるべきことは**開発ガイドの整備**。現行の開発ガイドとAI-Readyの開発ガイドの2つを作ること。Nabledgeがチームメンバーとして「このPJではこう作る」を理解するための基準がないとBuildが回らない。 + +#### 方式設計書・開発標準・開発ガイドの統合（v20で確定） + +日本のSI文化の文書体系で3つに分かれているだけで、本質的な区分ではない。同じ対象について「方式判断」「手順」「ルール」が散らばっている。Nabledgeは判断・手順・ルールの区別なく一体で使うので、分かれている方が不便。 + +→ **「開発ガイド」に統合。** PJにおける「どう作るか」の唯一の基準。変更はアーキテクト承認。 + +成果物12種類 → 10種類に再編。 + +#### ソースコード起点（v20で確定） + +動いているコードは検証済みの事実。設計書は不完全でテストされていない。LLMはコード解析が得意なので、コードから「今どう作っているか」を逆算する方が確実。 + +Unlockの流れ： +1. ソースコード解析 → 現行システムの構造把握 +2. 現行の開発ガイド導出 → 今のPJが実際にどう作っているか +3. AI-Readyの開発ガイド作成 → Nabチームの知識で変換 +4. AI-Readyのマッピング → 移行後の構造 + +現行が非NablarchでもNablarchでも、この流れは同じ。違いはステップ3の重さだけ（工数と価格の話であり、Unlockの設計・アーキテクチャには影響しない）。 + +#### 要件定義書と設計書の仮定義（v20で追加） + +**要件定義書（#1）：** 「なぜ」と「何を」。スコープ、目的、目標値、業務フロー、業務ルール、変更要求仕様。IN: 業務部門からの要求 → OUT: Nabledgeにとっての判断の前提条件。業務フローは「業務がどう流れるか」であってシステム設計ではないため、要件定義に含む。 + +**設計書・外部設計（#2）：** ユーザーから見たシステムの振る舞い。機能設計、画面設計、バッチ外部仕様、テーブル論理設計、IF定義、メッセージ定義。IN: 要件定義書 → OUT: 「何を作るか」の仕様 + +**設計書・内部設計（#3）：** システムの内部構造。クラス設計、SQL設計、テーブル物理設計、処理フロー。IN: 外部設計＋開発ガイド → OUT: 「どう作るか」の指示。**開発ガイドが充実しているPJでは内部設計は薄い（マッピングのみで済む場合がある）。外部設計も同様に薄くなりうる。** + +#### 成果物の階層構造（v20で確定） + +上位が充実していれば下位は薄くなる： +- **開発ガイド（#4）** が方式・標準・手順を規定 +- **設計書（#2, #3）** は開発ガイドからの差分・固有部分 +- **ソースコード（#5）、テスト（#6, #7）** は設計書＋開発ガイドの実装 + +方式設計→標準化のサイクルが回っているPJでは、設計書は「標準のどのパターンを使い、固有の項目は何か」を書くだけになる。 + +#### 成果物10種類（v20で再編） + +| # | 成果物 | 扱う内容 | +|---|--------|---------| +| 1 | 要件定義書 | スコープ、目的、目標値、業務フロー、業務ルール、変更要求仕様 | +| 2 | 設計書（外部設計） | 機能設計、画面設計、バッチ外部仕様、テーブル論理設計、IF定義、メッセージ定義 | +| 3 | 設計書（内部設計） | クラス設計、SQL設計、テーブル物理設計、処理フロー | +| 4 | 開発ガイド | 方式設計＋開発標準＋手順を統合。「どう作るか」の唯一の基準 | +| 5 | ソースコード | Java/JSP/SQL、テストコード、XML設定 | +| 6 | テスト仕様書/報告書 | テストケース、テスト結果、性能テスト結果 | +| 7 | テストデータ | 共通テストデータ、テストケース用データ | +| 8 | 不具合票 | 障害票、設計修正指示 | +| 9 | チェックリスト/レビュー結果 | レビューチェックリスト、レビュー指摘事項 | +| 10 | 工数見積 | 見積データ、見積書 | + +#### PJアダプター（v19で導入、v20で補強） + +- **汎用アダプター** — Nabチームが提供。ソースコード・テーブル定義・マスタテーブルから業務仕様を機械的に抽出。PJが変わっても使い回せる +- **PJ固有アダプター** — アーキテクトが設定。業務仕様がどの成果物に書かれているかはPJ次第なので、その所在を指定する + +#### マッピング層2の粒度（v20で確定） + +**テーブル単位で静的に持ち、カラム単位はBuild時にNabledgeが動的解析。** + +理由： +1. Unlockのコスト予測可能性を守る（カラム単位はSQL本数×テーブル数で爆発する） +2. LLMはコード解析が得意（静的解析ツールより柔軟で精度が出る） +3. テーブル単位で候補を絞り込み → カラム単位で確定、という役割分担 + +#### Unlockの出力（3種、v19から継続） + +- **知識（JSON）** — 成果物から抽出・検証・確定した情報 +- **マッピング（JSON）** — 3層（①知識↔元成果物、②成果物間：テーブル単位、③知識間） +- **不整合リスト** — 対話ループのトリガー + +#### ロール定義（v19から継続、5種） + +| ロール | 担当概要 | +|--------|---------| +| アーキテクト | 技術検証、基盤設計、開発ガイド策定・変更承認、環境構築、PJ固有アダプター設定 | +| 要件定義者/設計者 | 要求分析、機能設計、テストケース設計、設計意図の確定 | +| データモデラー | データ定義、DB設計 | +| データアナリスト | データパターン洗い出し、テストデータ作成 | +| アプリケーションエンジニア | 実装、単体テスト、障害調査、業務ルールの確定 | + +### Build側からの逆算検証（v20で実施） + +「CSV取込バッチに項目追加」のシナリオでBuildの各ステップを洗い出し、Unlockの出力を検証。 + +**確認済みの検証ポイント：** + +| # | ポイント | 結論 | +|---|---------|------| +| ① | マッピング層2の粒度 | テーブル単位＋Build時動的解析（確定） | +| ② | PJ運用ルールの扱い | 開発ガイド（#4）または方式設計書（→開発ガイドに統合）でカバー済み。問題なし | +| ③ | 要件定義書の構造化タイミング | ソースコード起点に変更。コードから取れるだけ取り、取れない業務的意味は対話ループで確認。要件定義書の構造化は必須ではない | + +**未検証の検証ポイント：** + +| # | ポイント | 内容 | +|---|---------|------| +| ④ | テストケースレベルの依存管理 | 回帰テスト特定にはテストケース→テーブル→カラムの依存が必要。①と同根でBuild時動的解析になるはず | +| ⑤ | 不具合票・レビュー指摘の知識化 | Unlockで抽出するかBuild蓄積で育てるか | + +### Win Togetherの本質（v18で確定） + +還元時にNabledgeが答える4つの問い： +1. どこに適用するのか → **Unlockのマッピング（層2・3）** +2. 変えても大丈夫か → Buildの影響分析 +3. 品質基準を満たすか → Buildの品質チェック +4. どう確認するか → Buildのテスト生成 + +### 競争優位の構造（v18で確定） + +- 最も真似しにくいのはワークフロー（知識は移転可能、実績は蓄積可能、ワークフローは現場経験なしには作れない） +- NabチームがNablarch・Nabledge両方の開発を通じて蓄積した経験がワークフローに埋め込まれている + +### 版歴の要点 +- v12〜v15: 表現の精緻化 +- v16: 横断課題9項目に再構成、Win Togetherを2軸構造に +- v17: 全体をスリム化。箇条書きベースに変更 +- v18: Win Togetherを「還元」視点で再構成。登場人物を細分化。ワークフローが競争優位の核であることを明示 +- v19: Unlockの具体化。PJアダプター導入。成果物12種類を器として定義。知識リプレイス＋マッピング3層構造。ロール5種をToBe Imageから採用 +- v20: Build側からの逆算検証。Unlockの核心を「開発ガイドの整備」に再定義。方式設計書・開発標準・開発ガイドを統合（成果物12→10種類）。ソースコード起点の流れを確立。要件定義書・設計書の仮定義を追加。マッピング層2の粒度をテーブル単位に確定 + +--- + +## 次のセッションで取り組むこと + +### 優先度高：検証ポイント④⑤の解決 + +- ④ テストケースレベルの依存管理 — ①と同じくBuild時動的解析で済むか確認 +- ⑤ 不具合票・レビュー指摘の知識化 — Unlock vs Build蓄積の切り分け + +### 優先度高：ターゲットの解像度（v18から継続） + +1. 主戦場は「既存Nablarchユーザー」か「他FWからの新規顧客」か + - v20でUnlockの流れは同じ（違いはステップ3の重さだけ）と確認済み + - 残るのはマーケティング・価格戦略の判断 +2. Unlockを入り口にした新規獲得 vs 既存深耕 + +### 優先度中：プレスリリースの構造検証（v18から継続） + +v20で内容がさらに整理されたが： +- Unlockの詳細（アダプター、出力3種、マッピング3層）をプレスに入れるべきか、別資料（ソリューション詳細）に移すべきか +- 「人ごとの価値」セクションが3フェーズ分あり重複がある → 統合or別資料化 + +### その後の展開候補 +- Build・Winの概念モデル図の作成（Unlockと同じ粒度で） +- 企画書・計画書への展開（社内承認・予算獲得用） +- アダプターの具体設計（汎用アダプターのJSON構造、PJ固有アダプターの設定項目） +- 開発ガイドのテンプレート設計（Nablarchバッチ用の開発ガイドの雛形） + +--- + +## 最新ファイル + +- `nabledge_press_v20.md` — 最新のプレスリリース本文 +- `phase1_unlock_v2.mermaid` — Unlock概念モデル図（v2） +- `session_handover.md` — 本引き継ぎ資料 + +--- diff --git a/doc/tobe/nabledge_press.md b/doc/tobe/nabledge_press.md new file mode 100644 index 00000000..a09bdc52 --- /dev/null +++ b/doc/tobe/nabledge_press.md @@ -0,0 +1,370 @@ +--- +更新日: 2026-02-24 +ステータス: ドラフト +バージョン: 20 +--- + +# Get AI-Ready. We Cover You. + +SoR領域の基幹系システムを、事業の足枷から競争力の源泉へ。 + +## SoR領域の現実 + +### 調査結果 + +- 投資の硬直化 —保守・運用にリソースが張り付き、攻めの投資に回せない[^1] +- 技術追従の停滞 —FW・ミドルウェアのバージョンアップやセキュリティ対応が遅れる[^2] +- 市場対応速度の低下 —ビジネス要求に対してシステム改修が追いつかない[^1] +- 人材の悪循環 —レガシー環境で採用・定着が困難[^3] → さらに属人性が高まる +- AI開発ツールの限界 —既存ツールはモダンアーキテクチャ前提。SoR領域には機能しない[^4][^5] + +### 仮説 + +- 属人性 —システム全体を把握できるのはベテランだけ。判断基準が人の頭の中にある +- 暗黙知の散在 —業務ルールがコード・SQL・設計書・テストデータに散らばり、明文化されていない +- 判断基準の不在 —ルールはあっても適用判断がない。レビュー品質がレビューア依存 +- 経験の断絶 —PJ終了で知見が散逸。同じ失敗が繰り返される +- 構造の不透明さ —成果物間の依存が追えず、変更影響が見通せない +- レガシー向けAI支援は「モダンへの変換」が目的。「レガシーのまま支援する」ものがない +- SoR領域の基幹系だけが、AI駆動開発の恩恵から取り残されている + +## あるべき姿 + +- 組織が技術的負債を整理し、保守リソースを攻めの投資に回している +- チームがアーキテクトの属人性に依存せず、根拠ある技術判断で開発を進めている +- 基幹系システムが市場変化に迅速に追従できている +- 組織がPJを重ねるほどシステム資産の価値を高め、競争力を蓄積している + +## ソリューション：Nabledge 3フェーズアプローチ + +### 全体像 + +Nabledgeは3つの段階で価値を提供する： + +1. **Unlock Your Assets** — 資産をAI-Readyに解き放つ +2. **Build Like Experts** — エキスパートレベルの開発をチームで実現する +3. **Win Together** — 経験を組織資産に変え、競争力を高め続ける + +各フェーズは単独でも価値があり、同時に次のフェーズの土台にもなる。 + +```mermaid +graph TD + %% ===== Phase 1: Unlock ===== + subgraph P1["Phase 1: Unlock Your Assets"] + direction TB + U1["暗黙知の可視化"] + U2["技術的負債の明確化"] + U3["構造化された知識"] + end + + %% ===== Phase 2: Build ===== + subgraph P2["Phase 2: Build Like Experts"] + direction TB + B1["品質の標準化"] + B2["保守コスト削減"] + B3["開発速度向上"] + end + + %% ===== Phase 3: Win ===== + subgraph P3["Phase 3: Win Together"] + direction TB + W1["判断パターンの蓄積"] + W2["見積精度の向上"] + W3["組織全体の競争力強化"] + end + + %% ===== フェーズ間の関係 ===== + P1 ==>|"土台"| P2 + P2 ==>|"実績"| P3 + + %% ===== スタイル ===== + classDef phase1 fill:#c8e6c9,stroke:#1b5e20,color:#1b5e20 + classDef phase2 fill:#bbdefb,stroke:#0d47a1,color:#0d47a1 + classDef phase3 fill:#fff9c4,stroke:#f57f17,color:#f57f17 + + class P1 phase1 + class P2 phase2 + class P3 phase3 +``` + +Nabledgeはツールではなく、プロジェクトに参加するAIチームメンバーです。既存のAI開発ツールはモダンアーキテクチャを前提としていますが、NabledgeはSoR領域の基幹系システムに特化しています。Nablarchで実績ある大規模ミッションクリティカルなシステム開発・運用ノウハウに基づいた判断力を持ち、PM、アーキテクト、設計者、開発者と協働しながら実現性検証、設計支援、実装/テスト/レビューなど幅広い工程で頼れる存在です。 + +リーダーではなく、優秀なメンバーとして動きます。GitHubのissueとPRを接点に、人間が要件を伝えるとIssue提案→承認→計画・実装→テスト・レビュー→承認・マージと進みます。既存の開発プロセスを変える必要はありません。人間は要件定義と承認、事業判断と技術判断という本質的な作業に集中できます。 + +### NablarchとNabledgeの関係 + +```mermaid +graph TB + subgraph Nabledge["🤖 Nabledge"] + D1["実績ノウハウ"] --- D2["全行程支援"] --- D3["判断基準"] + end + + subgraph Nablarch["🏛️ Nablarch"] + N1["既存資産の器"] --- N2["開発標準"] --- N3["品質基準"] --- N4["技術追従"] + end + + Nablarch -->|"知識の源泉
判断基準を提供"| Nabledge + Nabledge -->|"実績フィードバック
FW・ガイド改善"| Nablarch + + style Nablarch fill:#e3f2fd,stroke:#1976d2,stroke-width:2px + style Nabledge fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px +``` + +**🏛️ Nablarch（SoR基盤フレームワーク）** +- 既存資産の器：トランザクションスクリプト＋SQLのシステムを受け入れる +- 開発標準：設計書フォーマット＋開発ガイドを提供 +- 品質基準：規約・テスト標準を内包 +- 技術追従：Jakarta EE / Java最新版への対応 + +**🤖 Nabledge（AIチームメンバー）** +- 実績ノウハウ：Nablarchでの大規模ミッションクリティカル開発・運用の知見 +- 全行程支援：要件定義→設計→実装→テスト→保守まで技術面から支援・代行 +- 判断基準：ベテランの技術判断を標準化し、チーム全体で共有 + +**相互強化の循環** + +NablarchがNabledgeに判断基準と知識を提供し、NabledgeがPJで蓄積した実績をNablarchのFW改善にフィードバックします。この循環により、使うほど強くなるエコシステムを形成しています。 + +### Phase 1: Unlock Your Assets — 資産をAI-Readyに解き放つ + +Nabledgeが既存システムに眠る暗黙知と業務ルールを、AIが活用できる形に変換します。属人化していた知識を組織の資産として可視化し、技術的負債を投資判断の根拠に変えます。 + +**企業が得られるもの：** +- 開発ガイド（現行とAI-Ready） +- 構造化された知識（JSON） +- 成果物間のマッピング +- 技術的負債の可視化 + +**誰にとっての価値：** +- アーキテクト：Nabledgeが暗黙知を明示化し、AI-Readyへの移行計画を立案できる +- アプリエンジニア：Nabledgeが散在した業務ルールを構造化し、必要な情報へ即座にアクセスできる +- PJマネージャー：Nabledgeがタスクの依存関係を可視化し、リソース配置を最適化できる +- 経営層・IT投資判断者：Nabledgeが技術的負債を定量化し、データに基づく投資判断を実現できる + +### Phase 2: Build Like Experts — エキスパートレベルの開発をチームで実現する + +Nabledgeにより、経験の浅いメンバーもベテランの判断基準で開発できます。Nabledgeが実装・テスト・レビューの品質を標準化し、組織は保守運用コストを削減しながら、戦略的投資に予算をシフトできます。 + +**企業が得られるもの：** +- 実装・テスト生成・セルフレビューの自動化 +- 品質チェックの標準化 +- 工数の可視化 +- 判断と結果のissue・PRへの記録 + +**誰にとっての価値：** +- アーキテクト：Nabledgeが日常の技術判断を代行し、根本設計・トレードオフ判断に専念できる +- アプリエンジニア：Nabledgeが実装・テスト生成・セルフレビューを実行し、承認・業務判断・最終責任という価値ある業務に注力できる +- レビューア：Nabledgeが品質基準に照らして事前チェックし、本質的な設計レビューに専念できる +- PJマネージャー：Nabledgeにより新メンバーを即戦力化し、安定した開発体制を維持できる +- 業務部門：Nabledgeが要件の実現工数見積を素早く提供し、迅速な優先度判断を実現できる + +組織はIT予算の80%を占める保守運用コストを削減し、戦略的投資に予算をシフトできます。ベテランが抜けても判断基準がNabledgeに残ります。新人が入ってもNabledgeが隣でやって見せます。 + +### Phase 3: Win Together — 経験を組織資産に変え、競争力を高め続ける + +Nabledgeがプロジェクトごとに蓄積した判断パターンと品質ノウハウを、組織全体の資産に変えます。バージョンアップの影響分析、類似案件の見積精度向上、次のプロジェクトは過去の全経験を持つAIとスタートできます。 + +**企業が得られるもの：** +- 設計判断・品質知見・リスクパターンの蓄積 +- バージョンアップの影響分析・テスト生成 +- 類似案件の実績データに基づく見積精度向上 +- 障害対応ナレッジの蓄積 + +**誰にとっての価値：** +- アーキテクト：Nabledgeがバージョンアップの影響分析・テスト生成を支援し、「何が壊れるか」を明確にした上で確実な判断を下せる +- アプリエンジニア：Nabledgeが過去PJの判断パターンを保持し、実績に基づく確実な開発を実現できる +- PJマネージャー：Nabledgeが PJ中の知見を自動蓄積し、組織資産として永続的に活用できる +- 経営層・IT投資判断者：Nabledgeが技術的負債の定量データを継続的に提供し、エビデンスに基づく投資判断を実現できる +- 業務部門：Nabledgeが類似案件の実績から見積精度を向上し、要件の実現可能性を迅速に判断できる + +Nabledgeは既存AIツールができなかった「レガシーのまま支援する」を実現します。モダナイゼーション不要で、現行システムのままAI駆動開発の恩恵を受けられます。 + +### 実現の仕組み + +#### なぜミッションクリティカルで使えるのか + +汎用AIが持っているのはオープンデータから学習した一般知識です。それ以外は推測に頼ります。大規模ミッションクリティカルなシステム開発の実践的なノウハウ（スキルがバラバラなチームでどう品質を揃えるか、オフショアの短期立ち上げで何を標準化するか、どういうレビュー順序が見落としを防ぐか、テストデータをどう作れば本番条件を再現できるか）は、オープンデータにはほぼ存在しません。 + +汎用AIは一般知識で動作するため、具体的な判断は推測に頼らざるを得ません。一方Nabledgeは、オープンデータに加えてNablarch固有の知識と、現場経験から設計されたワークフローを組み合わせることで、確定的な判断パスで動作します。 + +知識は「何を知っているか」。ワークフローは「どう判断してどう動くか」。知識はドキュメント化すれば移転できます。実績はデータがあれば蓄積できます。しかしワークフローは「この場面ではこの順番でこう判断する」を現場経験から設計しないと作れません。 + +**知識 × ワークフロー × 実績の中で、最も真似しにくいのはワークフロー。** + +NabチームはNablarch自体の開発・保守、そしてNabledge自身の開発を通じて、この現場経験を持っています。バージョンアップでどこが壊れやすいか、大規模PJでどういう開発ガイドが実際に機能したか、どういうテスト設計が本番障害を防いだか。この経験がワークフローに埋め込まれているから、Nabledgeは推測ではなく確定的なパスで動作します。 + +#### アーキテクチャ + +- インターフェース：AIエージェントプラットフォーム上のスキルとして動作。開発者にとっては普通のAIアシスタントと同じ使い方 +- コア：知識とワークフロー。Nablarch固有の判断力が入っている +- 実績：知識とワークフローに注入される。PJを重ねるほどコアが強くなる + +開発者から見れば「Nablarchに詳しい優秀なAIアシスタント」です。裏側では知識ファイルとワークフローが構造化され、実績データで精度が向上し続けます。 + +## 3つのフェーズ：還元を安全にするための積み上げ + +3フェーズは「蓄積の順番」ではありません。**本番運用中のシステムに知見を安全に還元するための条件が積み上がる順番**です。 + +### Unlock Your Assets — 開発ガイドを整備し、Nabledgeが動ける状態を作る + +**Winの還元要件「どこに適用するのか」の土台を作る。** + +Unlockの核心は**開発ガイドの整備**です。Nabledgeがチームメンバーとして「このPJではこう作る」を理解するための基準を作ります。現行の開発ガイドとAI-Readyの開発ガイド、この2つを整備します。 + +**起点はソースコード解析。** 動いているコードは検証済みの事実です。設計書は不完全でテストされていません。LLMはコード解析が得意なので、コードから「今どう作っているか」を逆算する方が確実です。設計書は補助情報・検証対象として扱い、コードから取れない業務的意味は対話ループで人間に確認します。 + +**Unlockの流れ：** + +1. ソースコード解析 →Nabledgeが現行システムの構造を把握（動いている事実から） +2. 現行の開発ガイド導出 →Nabledgeが今のPJが実際にどう作っているかを明示化 +3. AI-Readyの開発ガイド作成 →NabチームがNablarch上でどう作るかを知識で変換 +4. AI-Readyのマッピング →Nabledgeが移行後の構造を生成 + +**対象となる成果物（10種類）：** + +| # | 成果物 | 扱う内容 | +|---|--------|---------| +| 1 | 要件定義書 | スコープ、目的、目標値、業務フロー、業務ルール、変更要求仕様 | +| 2 | 設計書（外部設計） | 機能設計、画面設計、バッチ外部仕様、テーブル論理設計、IF定義、メッセージ定義 | +| 3 | 設計書（内部設計） | クラス設計、SQL設計、テーブル物理設計、処理フロー。開発ガイドが充実していればマッピングのみで済む | +| 4 | 開発ガイド | 方式設計＋開発標準＋手順を統合。PJにおける「どう作るか」の唯一の基準。変更はアーキテクト承認 | +| 5 | ソースコード | Java/JSP/SQL、テストコード、XML設定 | +| 6 | テスト仕様書/報告書 | テストケース、テスト結果、性能テスト結果 | +| 7 | テストデータ | 共通テストデータ、テストケース用データ | +| 8 | 不具合票 | 障害票、設計修正指示 | +| 9 | チェックリスト/レビュー結果 | レビューチェックリスト、レビュー指摘事項 | +| 10 | 工数見積 | 見積データ、見積書 | + +**成果物の階層構造：** 上位が充実していれば下位は薄くなる。 + +- 開発ガイド（#4）が方式・標準・手順を規定する +- 設計書（#2, #3）は開発ガイドからの差分・固有部分。開発ガイドが充実していれば内部設計（#3）はマッピングのみ、外部設計（#2）も薄くなる +- ソースコード（#5）、テスト（#6, #7）は設計書＋開発ガイドの実装 + +**要件定義書と設計書の区分：** + +- 要件定義書（#1）—「なぜ」と「何を」。システムの外側。業務部門からの要求が入力、Nabledgeにとっての判断の前提条件が出力 +- 設計書・外部設計（#2）—ユーザーから見たシステムの振る舞い。要件定義書が入力、「何を作るか」の仕様が出力 +- 設計書・内部設計（#3）—システムの内部構造。外部設計＋開発ガイドが入力、「どう作るか」の指示が出力。開発ガイドが充実しているPJでは、内部設計の大部分は「開発ガイドのどのパターンを使い、固有の項目は何か」を記述するだけ + +**PJアダプターが橋渡しする：** + +PJアダプターは、既存成果物とNabledgeの間に立ち、構造化して知識とマッピングを生成します。 + +- 汎用アダプター —Nabチームが提供。FWが構造を規定している成果物向け（ソースコード、XML設定、テスト等）。PJが変わっても使い回せます。ソースコード・テーブル定義・マスタテーブルから業務仕様を機械的に抽出します +- PJ固有アダプター —PJごとにアーキテクトが設定。フォーマットがPJ依存の成果物向け（設計書、要件定義書等）。業務仕様がどの成果物に書かれているかはPJ次第なので、アーキテクトがその所在を指定します + +**Unlockの出力（3種）：** + +- 知識（JSON）—成果物から抽出・検証・確定した情報。Nabledgeの判断基準になる +- マッピング（JSON）—3層のメタ構造 + - ① 知識 ↔ 元成果物（トレーサビリティ：この知識はどこから来たか） + - ② 成果物間（テーブル単位の依存関係：設計書↔ソースコード↔テーブル↔SQL）。カラム単位の特定はBuild時にNabledgeが動的解析で行う + - ③ 知識間（規約↔実装パターン、バッチ入出力依存チェーン等） +- 不整合リスト —コードと設計書の矛盾、規約と実態の乖離、暗黙の前提。対話ループのトリガーになる + +**対話ループで知識を確定する：** + +不整合リストを起点に、Nabledgeがアーキテクト・設計者・アプリエンジニアに確認を取ります。回答がそのまま知識とマッピングに反映されます。暗黙知の明示化は「作業」ではなく「日常のやり取り」です。 + +**人ごとの価値：** +- アーキテクト →Nabledgeとの対話で暗黙知を明示化し、AI-Ready移行計画を立案できる +- アプリエンジニア →Nabledgeが散在した業務ルールを構造化し、必要な情報へ即座にアクセスできる +- PJマネージャー →Nabledgeがタスクの依存関係を可視化し、最適なリソース配置を実現できる +- 経営層・IT投資判断者 →Nabledgeが技術的負債を定量化し、エビデンスに基づく投資判断を実現できる +- 情シス・システム管理者 →Nabledgeがシステム全体の依存関係を可視化し、戦略的なシステム管理を実現できる + +**ポイント：** +- Unlockは業務ロジックの書き直し（モダナイゼーション）ではなく、FW載せ替えによるAI-Ready化 +- マッピングの②③がBuildの影響分析の基盤、Winの還元先特定の土台になる +- Unlockが対象とするのはトランザクションスクリプト＋SQLで構築されたシステム +- マッピング層2はテーブル単位で保持し、カラム単位の依存特定はBuild時にNabledgeがソースコードを動的解析（Unlockのコスト予測可能性を守りつつ、LLMのコード解析力を活用） + +### Build Like Experts — Nabledgeが判断・生成・検証を日常的に回す + +**Buildフェーズで、Winの還元要件「変えても大丈夫か」「品質基準を満たすか」「どう確認するか」を日常業務として確立します。** + +**人ごとの価値：** +- アーキテクト →Nabledgeが日常の技術判断を代行し、根本設計・トレードオフ判断に専念できる +- アプリエンジニア →Nabledgeが実装・テスト生成・セルフレビューを実行し、承認・業務判断・最終責任という価値ある業務に注力できる +- レビューア →Nabledgeが品質基準に照らして事前チェックし、本質的な設計レビューに専念できる +- PJマネージャー →Nabledgeにより新メンバーを即戦力化し、安定した開発体制を維持できる。工数の可視化で計画精度を向上できる +- 業務部門 →Nabledgeが要件の実現工数見積を素早く提供し、迅速な優先度判断を実現できる + +**ポイント：** +- Nablarchが品質保証の判断基準を内包しているから、NabledgeがAIチームメンバーとして機能する +- NabledgeがAI同士でピアレビュー。人間は品質の最終責任者 +- ベテランが抜けても判断基準がNabledgeに残る。新人が入ってもNabledgeが隣でやって見せる +- Nabledgeが判断と結果をissue・PRに記録し続ける。これがWinへの蓄積になる + +### Win Together — 蓄積された実績で還元の精度が上がり続ける + +**Buildで日常的に回している仕組みの適用範囲を広げる。** + +Winの本質は新しい仕組みを作ることではなく、Buildで回っているサイクルの再適用です。本番運用中のシステムに知見を安全に還元できるのは、Unlock（構造把握）とBuild（判断・検証能力）が積み上がっているからです。 + +**還元時にNabledgeが答えられる問い：** +1. どこに適用するのか —Unlockのマッピング（成果物間・知識間の依存関係）に基づいて特定する +2. 変えても大丈夫か —Buildで使っている影響分析で範囲を提示する +3. 品質基準を満たすか —Buildで使っている品質チェックで検証する +4. どう確認するか —Buildで使っているテスト生成で差分検証する + +**2つの軸：** + +**① お客様PJ経験の蓄積・還元** +- Nabledgeが設計判断・品質知見・リスクパターンを、Buildの日常業務を通じて蓄積する +- 組織が蓄積された知見を本番システムに還元するとき、Buildと同じプロセス（影響分析→品質チェック→テスト→承認）で安全に適用できる +- 組織は次のPJを過去の全PJ経験を持つAIチームメンバーとスタートできる + +**② FWとAIの共進化（自分たち起点 → お客様へ還元）** +- AIが間違えやすいAPI設計の改善 +- 実際に機能した品質パターンの体系化 +- 開発ガイドの実態に即した洗練 +- Nablarchのバージョンアップ・セキュリティ対応を自分たちがAIで迅速に実施 +- 見積精度の向上（類似案件の実績データ蓄積） +- 障害対応ナレッジの蓄積 + +**人ごとの価値：** +- アプリエンジニア →Nabledgeが過去PJの判断パターンを保持し、実績に基づく確実な開発を実現できる +- アーキテクト →Nabledgeがバージョンアップの影響分析・テスト生成を支援し、「何が壊れるか」を明確にした上で確実な判断を下せる +- PJマネージャー →Nabledgeが PJ中の知見を自動蓄積し、組織資産として永続的に活用できる +- 経営層・IT投資判断者 →Nabledgeが技術的負債の定量データを継続的に提供し、「この四半期の追加工数のうち負債由来がどれだけか」を可視化。エビデンスに基づく投資判断を実現できる +- 業務部門 →Nabledgeが類似案件の実績から見積精度を向上し、要件の実現可能性を迅速に判断できる + +**構造的競争優位：** FWの設計とAIの知識を同じチームが持ち、互いにフィードバックし合えます。OSSフレームワークでは不可能な構造です。そして最大の優位は、NablarchとNabledge両方の開発を通じて蓄積された現場経験がワークフローに埋め込まれていること。知識は公開すれば真似できますが、ワークフローは経験なしには作れません。 + +## 登場人物と役割 + +| 登場人物 | 役割 | +|---|---| +| Nablarch |規約・品質基準・テスト規約を提供する基盤（知識の源泉） | +| Nabledge | AIエージェントプラットフォーム上のスキルとして動くチームメンバー。コアは知識 × ワークフロー × 実績 | +| Nabチーム |知識ファイルとワークフローを作り、実績を注入する仕組みを回す。汎用アダプターを提供 | +| PJアダプター |既存成果物とNabledgeの橋渡し。構造化して知識＋マッピングを生成。汎用（Nabチーム提供）とPJ固有（アーキテクト設定）の2層 | +| アーキテクト |根本設計・トレードオフ判断に集中。日常判断はNabledgeが代行。PJ固有アダプターの設定。開発ガイドの変更承認 | +| 要件定義者/設計者 |要求分析、機能設計、テストケース設計。Nabledgeとの対話で設計意図を確定 | +| アプリエンジニア |Nabledgeとの日常的な協働。承認・業務判断・最終責任は人間 | +| データモデラー |データ定義・DB設計。データ設計の意図をNabledgeに伝える | +| データアナリスト |データパターン洗い出し、テストデータ作成 | +| PJマネージャー |計画・進捗・リソース配分の判断。Nabledgeの開発プロセスへの組み込み判断 | +| 経営層・IT投資判断者 |投資判断・予算承認。可視化データに基づく意思決定 | +| 業務部門 |業務要件の提示・受入判断 | +| 情シス・システム管理者 |運用方針・セキュリティ・ガバナンス | + +--- + +## 今後の展開 + +パイロットPJで実測し、段階的に展開。仮説段階で過剰な数字は置かない。 + +**Get AI-Ready. We Cover You.** + +[^1]: 経済産業省「DXレポート ~ITシステム『2025年の崖』克服とDXの本格的な展開~」（2018年9月） — IT予算の80%が既存システムの保守・運用に費やされ、戦略的投資は20%のみ。システム改修に2-3倍の時間を要する。URL: https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html + +[^2]: IPA「企業IT動向調査報告書2024」 — 56.6%の企業が20年以上前のレガシーシステムを使用。21%のシステムはドキュメント不足により更新不可能。URL: https://www.ipa.go.jp/jinzai/skill-standard/plus-it-ui/itsurvey/ps6vr70000008rww-att/000108101.pdf + +[^3]: 経済産業省「IT人材需給に関する調査」（2019年） — 2030年までに最大79万人のIT人材不足が予測される。メインフレームエンジニアの60%が50歳以上。URL: https://www.meti.go.jp/policy/it_policy/jinzai/houkokusyo.pdf + +[^4]: Chen, M., et al. "Evaluating Large Language Models Trained on Code" OpenAI (2022) — GitHub Copilotの学習データはGitHub上のオープンソースコードに偏重し、モダンな言語・フレームワーク（JavaScript、Python、TypeScript）が中心。レガシーエンタープライズフレームワークは過小評価。URL: https://arxiv.org/abs/2107.03374 + +[^5]: GitClear "State of AI Code Generation 2024" — AIコード生成ツールはモダンフレームワーク（React、Django）で40-60%の精度だが、レガシーエンタープライズフレームワークでは15-25%に低下。URL: https://www.gitclear.com/state_of_ai_code_generation_2024 diff --git a/doc/tobe/nabledge_unlock.md b/doc/tobe/nabledge_unlock.md new file mode 100644 index 00000000..afba407f --- /dev/null +++ b/doc/tobe/nabledge_unlock.md @@ -0,0 +1,141 @@ +# Phase 1: Unlock Your Assets (v2) + +## 概要 + +このダイアグラムは、Unlockフェーズの全体構造と情報の流れを示しています。既存システムに眠る暗黙知と業務ルールを、AIが活用できる形に変換するプロセスを可視化しています。 + +## ダイアグラムの見方 + +- **青系（濃青・明青）**: Nabledgeのコア機能とNablarchチーム +- **赤系**: 既存資産（★濃赤=起点となるソースコード） +- **橙系**: PJアダプター（汎用・PJ固有） +- **紫系**: Unlockの出力（知識・マッピング） +- **ピンク系**: 不整合リスト（対話ループのトリガー） +- **緑系**: 開発ガイド（Unlockの核心成果物） +- **グレー系**: 次フェーズ（Phase 2: Build）への接続 + +## 主要な流れ + +1. **起点**: ソースコード（#5）を汎用アダプターで解析 +2. **構造化**: 既存資産をPJアダプター（汎用・PJ固有）で構造化 +3. **変換**: Nabledgeが知識・マッピング・不整合リストを生成 +4. **対話**: 不整合リストを起点にロール別の対話ループで知識を確定 +5. **核心成果**: 現行の開発ガイド導出 → AI-Readyの開発ガイド作成 +6. **次フェーズ**: 開発ガイド・知識・マッピングがBuildの基盤となります + +```mermaid +--- +title: "Phase 1: Unlock Your Assets (v2)" +--- +graph TB + %% ===== Unlockの核心：開発ガイド整備 ===== + subgraph CORE["Unlockの核心：開発ガイドの整備"] + direction TB + GUIDE_AS_IS["現行の開発ガイド
今のPJが実際にどう作っているか"] + GUIDE_AI["AI-Readyの開発ガイド
Nablarch上でどう作るか
方式設計＋開発標準＋手順を統合
変更はアーキテクト承認"] + GUIDE_AS_IS -->|"Nabチームの知識で変換"| GUIDE_AI + end + + %% ===== 起点：ソースコード解析 ===== + CODE["ソースコード（#5）
Java / SQL / XML / テストコード
動いている＝検証済みの事実
★ Unlockの起点"] + + %% ===== 既存資産（補助情報・検証対象） ===== + DESIGN_EXT["設計書・外部設計（#2）
機能設計、画面設計
バッチ外部仕様、IF定義"] + DESIGN_INT["設計書・内部設計（#3）
クラス設計、SQL設計
開発ガイド充実なら薄い"] + REQ["要件定義書（#1）
スコープ、目的、目標値
業務フロー、業務ルール"] + TEST["テスト仕様書 / テストデータ（#6,#7）"] + OTHER["不具合票 / チェックリスト
工数見積（#8,#9,#10）"] + + %% ===== PJアダプター（2層） ===== + AD_GEN["汎用アダプター
Nabチームが提供
ソースコード・テーブル定義・
マスタテーブルから業務仕様を
機械的に抽出"] + AD_PJ["PJ固有アダプター
アーキテクトが設定
業務仕様の所在を指定"] + + %% ===== Nabledge ===== + NE["Nabledge
知識 x ワークフロー x 実績"] + + %% ===== Unlockの出力（3種） ===== + KNOWLEDGE["知識（JSON）
抽出・検証・確定した情報"] + MAPPING["マッピング（JSON）
① 知識↔元成果物
② 成果物間の依存（テーブル単位）
③ 知識間の関係"] + GAPS["不整合リスト
コード↔設計書の矛盾
規約↔実態の乖離"] + + %% ===== 知識供給 ===== + NAB["Nablarch
規約・品質基準・テスト規約"] + TEAM["Nabチーム
知識・ワークフロー構築
汎用アダプター提供"] + + %% ===== ロール ===== + ARCH["アーキテクト"] + DESIGNER["要件定義者/設計者"] + APPENG["アプリケーションエンジニア"] + + %% ===== Buildへの接続 ===== + BUILD["Phase 2: Build Like Experts
カラム単位の依存特定は
Build時にNabledgeが動的解析"] + + %% ===== ソースコード → 汎用アダプター（起点） ===== + CODE ==>|"★ 起点：コード解析"| AD_GEN + TEST -->|"解析"| AD_GEN + + %% ===== 補助情報 → PJ固有アダプター ===== + DESIGN_EXT -->|"補助情報"| AD_PJ + DESIGN_INT -.->|"開発ガイド充実なら
マッピングのみ"| AD_PJ + REQ -.->|"業務的意味の補足"| AD_PJ + OTHER -->|"読解"| AD_PJ + + %% ===== アダプター → Nabledge → 出力 ===== + AD_GEN -->|"構造化"| NE + AD_PJ -->|"構造化"| NE + NE --> KNOWLEDGE + NE --> MAPPING + NE --> GAPS + + %% ===== 構造把握 → 開発ガイド導出 ===== + MAPPING -->|"構造から導出"| GUIDE_AS_IS + KNOWLEDGE -->|"知識から導出"| GUIDE_AS_IS + + %% ===== 知識供給 ===== + NAB -->|"FW知識"| NE + TEAM -->|"ワークフロー"| NE + TEAM -->|"提供"| AD_GEN + TEAM -->|"Nablarch化の知識"| GUIDE_AI + ARCH -->|"PJ固有の構造定義"| AD_PJ + ARCH -->|"変更承認"| GUIDE_AI + + %% ===== 不整合 → 対話ループ ===== + GAPS -->|"矛盾の確認"| ARCH + GAPS -->|"設計意図の確認"| DESIGNER + GAPS -->|"実装意図の確認"| APPENG + ARCH -->|"回答"| NE + DESIGNER -->|"回答"| NE + APPENG -->|"回答"| NE + + %% ===== 対話結果の反映 ===== + NE -->|"確定"| KNOWLEDGE + NE -->|"確定"| MAPPING + + %% ===== Buildへの接続 ===== + GUIDE_AI -->|"Buildの判断基準"| BUILD + KNOWLEDGE -->|"判断基準"| BUILD + MAPPING -->|"影響分析の基盤
（テーブル単位）"| BUILD + + %% ===== スタイル ===== + classDef core fill:#1a73e8,stroke:#0d47a1,color:#fff + classDef base fill:#4285f4,stroke:#1a73e8,color:#fff + classDef asset fill:#fce4ec,stroke:#c62828,color:#b71c1c + classDef asset_main fill:#ffcdd2,stroke:#b71c1c,color:#b71c1c,stroke-width:3px + classDef adapter fill:#fff3e0,stroke:#e65100,color:#bf360c + classDef output fill:#e8eaf6,stroke:#283593,color:#1a237e + classDef gap fill:#ffebee,stroke:#b71c1c,color:#b71c1c + classDef dev fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20 + classDef next fill:#f5f5f5,stroke:#9e9e9e,color:#616161 + classDef guide fill:#c8e6c9,stroke:#1b5e20,color:#1b5e20,stroke-width:3px + + class NE core + class NAB,TEAM base + class DESIGN_EXT,DESIGN_INT,REQ,TEST,OTHER asset + class CODE asset_main + class AD_GEN,AD_PJ adapter + class KNOWLEDGE,MAPPING output + class GAPS gap + class ARCH,DESIGNER,APPENG dev + class BUILD next + class GUIDE_AS_IS,GUIDE_AI guide +``` diff --git a/doc/tobe/session_handover.md b/doc/tobe/session_handover.md new file mode 100644 index 00000000..82289973 --- /dev/null +++ b/doc/tobe/session_handover.md @@ -0,0 +1,206 @@ +# Nabledgeプレスリリース作業 引き継ぎ資料 + +作成日: 2026-02-24（第4セッション後） + +--- + +## 現在のステータス + +- ドキュメント: `nabledge_press_v20.md` +- ステータス: ドラフト +- 直近の作業: Build側からの逆算でUnlockを検証。開発ガイドの整備がUnlockの核心であることを発見。成果物を12→10種類に再編。ソースコード起点の流れを確立 + +--- + +## これまでのセッションで確定したこと + +### コンセプト（v17以前から継続） +- **Nabledgeは「AIチームメンバー」**。ツール・開発基盤という表現は使わない +- **Nabledgeが主役、Nablarchは受け皿**という構造 +- **文体: です・ます調**に統一 +- **プレス形式は企画審査の質向上が目的**。外向きの目で構想を検証するための道具 +- **認知負荷を下げる**。箇条書きベース、本質のみ。膨らませるのは後から + +### Nabledgeのアーキテクチャ（v18で確定） + +- **インターフェース：** AIエージェントプラットフォーム上のスキルとして動作。開発者にとっては普通のAIアシスタントと同じ使い方 +- **コア：** 知識とワークフロー。Nablarch固有の判断力が入っている +- **実績：** 知識とワークフローに注入される。PJを重ねるほどコアが強くなる + +### Nabledgeの動き方（v18で確定） + +1. 人間が要件を伝える → 2. Nabledgeがissue作成・提案 → 3. 承認まで修正 → 4. 計画・PR → 5. 実装・テスト・セルフレビュー → 6. 人間が承認・マージ + +### 3フェーズの再定義（v18で確定） + +**本番運用中のシステムに知見を安全に還元するための条件の積み上げ。** + +- **Unlock** → 開発ガイドを整備し、Nabledgeが動ける状態を作る（還元要件「どこに適用するか」の土台） +- **Build** → 判断・生成・検証を日常業務として回す（還元要件「大丈夫か」「品質は」「確認方法は」を確立） +- **Win** → Buildの仕組みの適用範囲を広げる。新しい仕組みではなく再適用 + +### Unlockの具体化（v19→v20で大幅更新） + +#### Unlockの核心：開発ガイドの整備（v20で確定） + +Unlockで最初にやるべきことは**開発ガイドの整備**。現行の開発ガイドとAI-Readyの開発ガイドの2つを作ること。Nabledgeがチームメンバーとして「このPJではこう作る」を理解するための基準がないとBuildが回らない。 + +#### 方式設計書・開発標準・開発ガイドの統合（v20で確定） + +日本のSI文化の文書体系で3つに分かれているだけで、本質的な区分ではない。同じ対象について「方式判断」「手順」「ルール」が散らばっている。Nabledgeは判断・手順・ルールの区別なく一体で使うので、分かれている方が不便。 + +→ **「開発ガイド」に統合。** PJにおける「どう作るか」の唯一の基準。変更はアーキテクト承認。 + +成果物12種類 → 10種類に再編。 + +#### ソースコード起点（v20で確定） + +動いているコードは検証済みの事実。設計書は不完全でテストされていない。LLMはコード解析が得意なので、コードから「今どう作っているか」を逆算する方が確実。 + +Unlockの流れ： +1. ソースコード解析 → 現行システムの構造把握 +2. 現行の開発ガイド導出 → 今のPJが実際にどう作っているか +3. AI-Readyの開発ガイド作成 → Nabチームの知識で変換 +4. AI-Readyのマッピング → 移行後の構造 + +現行が非NablarchでもNablarchでも、この流れは同じ。違いはステップ3の重さだけ（工数と価格の話であり、Unlockの設計・アーキテクチャには影響しない）。 + +#### 要件定義書と設計書の仮定義（v20で追加） + +**要件定義書（#1）：** 「なぜ」と「何を」。スコープ、目的、目標値、業務フロー、業務ルール、変更要求仕様。IN: 業務部門からの要求 → OUT: Nabledgeにとっての判断の前提条件。業務フローは「業務がどう流れるか」であってシステム設計ではないため、要件定義に含む。 + +**設計書・外部設計（#2）：** ユーザーから見たシステムの振る舞い。機能設計、画面設計、バッチ外部仕様、テーブル論理設計、IF定義、メッセージ定義。IN: 要件定義書 → OUT: 「何を作るか」の仕様 + +**設計書・内部設計（#3）：** システムの内部構造。クラス設計、SQL設計、テーブル物理設計、処理フロー。IN: 外部設計＋開発ガイド → OUT: 「どう作るか」の指示。**開発ガイドが充実しているPJでは内部設計は薄い（マッピングのみで済む場合がある）。外部設計も同様に薄くなりうる。** + +#### 成果物の階層構造（v20で確定） + +上位が充実していれば下位は薄くなる： +- **開発ガイド（#4）** が方式・標準・手順を規定 +- **設計書（#2, #3）** は開発ガイドからの差分・固有部分 +- **ソースコード（#5）、テスト（#6, #7）** は設計書＋開発ガイドの実装 + +方式設計→標準化のサイクルが回っているPJでは、設計書は「標準のどのパターンを使い、固有の項目は何か」を書くだけになる。 + +#### 成果物10種類（v20で再編） + +| # | 成果物 | 扱う内容 | +|---|--------|---------| +| 1 | 要件定義書 | スコープ、目的、目標値、業務フロー、業務ルール、変更要求仕様 | +| 2 | 設計書（外部設計） | 機能設計、画面設計、バッチ外部仕様、テーブル論理設計、IF定義、メッセージ定義 | +| 3 | 設計書（内部設計） | クラス設計、SQL設計、テーブル物理設計、処理フロー | +| 4 | 開発ガイド | 方式設計＋開発標準＋手順を統合。「どう作るか」の唯一の基準 | +| 5 | ソースコード | Java/JSP/SQL、テストコード、XML設定 | +| 6 | テスト仕様書/報告書 | テストケース、テスト結果、性能テスト結果 | +| 7 | テストデータ | 共通テストデータ、テストケース用データ | +| 8 | 不具合票 | 障害票、設計修正指示 | +| 9 | チェックリスト/レビュー結果 | レビューチェックリスト、レビュー指摘事項 | +| 10 | 工数見積 | 見積データ、見積書 | + +#### PJアダプター（v19で導入、v20で補強） + +- **汎用アダプター** — Nabチームが提供。ソースコード・テーブル定義・マスタテーブルから業務仕様を機械的に抽出。PJが変わっても使い回せる +- **PJ固有アダプター** — アーキテクトが設定。業務仕様がどの成果物に書かれているかはPJ次第なので、その所在を指定する + +#### マッピング層2の粒度（v20で確定） + +**テーブル単位で静的に持ち、カラム単位はBuild時にNabledgeが動的解析。** + +理由： +1. Unlockのコスト予測可能性を守る（カラム単位はSQL本数×テーブル数で爆発する） +2. LLMはコード解析が得意（静的解析ツールより柔軟で精度が出る） +3. テーブル単位で候補を絞り込み → カラム単位で確定、という役割分担 + +#### Unlockの出力（3種、v19から継続） + +- **知識（JSON）** — 成果物から抽出・検証・確定した情報 +- **マッピング（JSON）** — 3層（①知識↔元成果物、②成果物間：テーブル単位、③知識間） +- **不整合リスト** — 対話ループのトリガー + +#### ロール定義（v19から継続、5種） + +| ロール | 担当概要 | +|--------|---------| +| アーキテクト | 技術検証、基盤設計、開発ガイド策定・変更承認、環境構築、PJ固有アダプター設定 | +| 要件定義者/設計者 | 要求分析、機能設計、テストケース設計、設計意図の確定 | +| データモデラー | データ定義、DB設計 | +| データアナリスト | データパターン洗い出し、テストデータ作成 | +| アプリケーションエンジニア | 実装、単体テスト、障害調査、業務ルールの確定 | + +### Build側からの逆算検証（v20で実施） + +「CSV取込バッチに項目追加」のシナリオでBuildの各ステップを洗い出し、Unlockの出力を検証。 + +**確認済みの検証ポイント：** + +| # | ポイント | 結論 | +|---|---------|------| +| ① | マッピング層2の粒度 | テーブル単位＋Build時動的解析（確定） | +| ② | PJ運用ルールの扱い | 開発ガイド（#4）または方式設計書（→開発ガイドに統合）でカバー済み。問題なし | +| ③ | 要件定義書の構造化タイミング | ソースコード起点に変更。コードから取れるだけ取り、取れない業務的意味は対話ループで確認。要件定義書の構造化は必須ではない | + +**未検証の検証ポイント：** + +| # | ポイント | 内容 | +|---|---------|------| +| ④ | テストケースレベルの依存管理 | 回帰テスト特定にはテストケース→テーブル→カラムの依存が必要。①と同根でBuild時動的解析になるはず | +| ⑤ | 不具合票・レビュー指摘の知識化 | Unlockで抽出するかBuild蓄積で育てるか | + +### Win Togetherの本質（v18で確定） + +還元時にNabledgeが答える4つの問い： +1. どこに適用するのか → **Unlockのマッピング（層2・3）** +2. 変えても大丈夫か → Buildの影響分析 +3. 品質基準を満たすか → Buildの品質チェック +4. どう確認するか → Buildのテスト生成 + +### 競争優位の構造（v18で確定） + +- 最も真似しにくいのはワークフロー（知識は移転可能、実績は蓄積可能、ワークフローは現場経験なしには作れない） +- NabチームがNablarch・Nabledge両方の開発を通じて蓄積した経験がワークフローに埋め込まれている + +### 版歴の要点 +- v12〜v15: 表現の精緻化 +- v16: 横断課題9項目に再構成、Win Togetherを2軸構造に +- v17: 全体をスリム化。箇条書きベースに変更 +- v18: Win Togetherを「還元」視点で再構成。登場人物を細分化。ワークフローが競争優位の核であることを明示 +- v19: Unlockの具体化。PJアダプター導入。成果物12種類を器として定義。知識リプレイス＋マッピング3層構造。ロール5種をToBe Imageから採用 +- v20: Build側からの逆算検証。Unlockの核心を「開発ガイドの整備」に再定義。方式設計書・開発標準・開発ガイドを統合（成果物12→10種類）。ソースコード起点の流れを確立。要件定義書・設計書の仮定義を追加。マッピング層2の粒度をテーブル単位に確定 + +--- + +## 次のセッションで取り組むこと + +### 優先度高：検証ポイント④⑤の解決 + +- ④ テストケースレベルの依存管理 — ①と同じくBuild時動的解析で済むか確認 +- ⑤ 不具合票・レビュー指摘の知識化 — Unlock vs Build蓄積の切り分け + +### 優先度高：ターゲットの解像度（v18から継続） + +1. 主戦場は「既存Nablarchユーザー」か「他FWからの新規顧客」か + - v20でUnlockの流れは同じ（違いはステップ3の重さだけ）と確認済み + - 残るのはマーケティング・価格戦略の判断 +2. Unlockを入り口にした新規獲得 vs 既存深耕 + +### 優先度中：プレスリリースの構造検証（v18から継続） + +v20で内容がさらに整理されたが： +- Unlockの詳細（アダプター、出力3種、マッピング3層）をプレスに入れるべきか、別資料（ソリューション詳細）に移すべきか +- 「人ごとの価値」セクションが3フェーズ分あり重複がある → 統合or別資料化 + +### その後の展開候補 +- Build・Winの概念モデル図の作成（Unlockと同じ粒度で） +- 企画書・計画書への展開（社内承認・予算獲得用） +- アダプターの具体設計（汎用アダプターのJSON構造、PJ固有アダプターの設定項目） +- 開発ガイドのテンプレート設計（Nablarchバッチ用の開発ガイドの雛形） + +--- + +## 最新ファイル + +- `nabledge_press_v20.md` — 最新のプレスリリース本文 +- `phase1_unlock_v2.mermaid` — Unlock概念モデル図（v2） +- `session_handover.md` — 本引き継ぎ資料 + +---