課題①：仕様がファイルやプロンプトに分散し、構造化されていない
①課題
仕様駆動開発では、AIに仕様を渡してコード生成や設計支援を行います。
しかし、仕様がExcel、Markdown、設計書、チャット、個人メモ、プロンプト履歴に分散していると、AIに渡す情報の粒度や表現がばらつきます。
たとえば、次のような問題が起きます。
-
画面項目とデータ項目の関係が曖昧になる
-
入力値、出力値、更新対象が整理されていない
-
処理条件や分岐条件が文章の中に埋もれる
-
同じ項目が別の表現で書かれる
-
AIが不足している前提を推論で補う
-
生成されたコードが意図とズレる
AIにとって必要なのは、長い説明ではなく、構造化された仕様情報です。
①XERVによる課題解決
XERV Modelystは、業務・画面・データ・処理・項目・条件などの仕様を、RDB上に構造化して保存します。
仕様を単なる文章やファイルとして扱うのではなく、開発に必要な要素ごとに整理し、関係性を持ったデータとして管理します。
これにより、次のような状態を実現できます。
-
仕様を要素単位で定義できる
-
業務・画面・データ・処理の関係を管理できる
-
入力・出力・更新対象を明確にできる
-
処理条件や制約を整理できる
-
AIに渡す前提情報を標準化できる
-
実装時の解釈違いを減らせる
XERVは、AIに渡す仕様を“文章”ではなく、“構造化された開発データ”として整えます。
課題②：仕様が蓄積されず、再利用できない
②課題
AI開発では、毎回プロンプトに仕様を書いて説明するケースが多くあります。
しかし、このやり方では、過去に整理した仕様が再利用されにくくなります。
よくある問題は次の通りです。
-
以前AIに渡した仕様がどこにあるか分からない
-
類似機能の仕様を探せない
-
開発者ごとにプロンプトの粒度が変わる
-
同じ仕様を何度も説明し直す
-
過去の判断や前提が残りにくい
-
AIへの入力品質が毎回ばらつく
仕様が蓄積されていないと、AIを使うたびに人が仕様を集め、整理し、説明し直す必要があります。
②XERVによる課題解決
XERV Modelystは、定義した仕様をRDBに蓄積し、次の開発でも再利用できる状態にします。
一度定義した業務、画面、データ、処理、項目、条件などを継続的に蓄積し、必要なときに参照・更新・再利用できます。
これにより、次のような状態を実現できます。
-
定義済み仕様を蓄積できる
-
類似仕様を参照しやすくなる
-
AIに渡す仕様の粒度をそろえられる
-
開発者ごとの指示品質のばらつきを減らせる
-
仕様を次の開発資産として再利用できる
-
必要な仕様からAI連携用Markdownを自動生成できる
XERVは、仕様をその場限りのプロンプトではなく、再利用できる開発資産として蓄積します。
課題③：仕様変更によって整合性が崩れる
③課題
仕様駆動開発では、仕様が開発の起点になります。
そのため、仕様変更が起きたときに整合性を保てなければ、開発全体が不安定になります。
特に、MarkdownファイルやExcelで仕様を管理している場合、変更のたびに人が関連箇所を探して修正する必要があります。
よくある問題は次の通りです。
-
画面仕様は変更したが、データ仕様が古いまま
-
処理条件を変えたが、チェック仕様に反映されていない
-
同じ項目が複数ファイルで違う意味になっている
-
古い仕様と新しい仕様が混在している
-
関連仕様への反映漏れが起きる
-
どの仕様が最新なのか分からなくなる
仕様が変わること自体は問題ではありません。
問題は、仕様変更が関連仕様に正しく反映されず、整合性が崩れることです。
③XERVによる課題解決
XERV Modelystは、仕様をRDBに構造化して保存するため、仕様同士の関係を管理できます。
業務、画面、データ、処理、項目、条件などを関係づけて管理することで、仕様変更時にも関連する仕様を確認しやすくなります。
これにより、次のような状態を実現できます。
-
変更対象と関連仕様を確認しやすい
-
業務・画面・データ・処理の不整合を減らせる
-
関連仕様への反映漏れを減らせる
-
古い仕様と新しい仕様の混在を防ぎやすい
-
変更後の正しい仕様からMarkdownを自動生成できる
-
AIに渡す仕様の正確性を保ちやすい
XERVは、変わり続ける仕様を破綻させずに管理し、AIに渡す前提情報の整合性を保ちます。
課題④：不整合な仕様をAIが“それっぽく”実装してしまう課題
④課題
.png)
AI開発で怖いのは、AIが間違えることだけではありません。
もっと怖いのは、間違った仕様をもとに、AIが正しそうな成果物を作ってしまうことです。
たとえば、仕様に次のような矛盾があるとします。
-
画面仕様では「商品コードは必須」
-
データ仕様では「商品コードは任意」
-
処理仕様では「商品コードなしは登録不可」
-
別の仕様では「商品コードなしでも仮登録可能」
この状態でAIに渡すと、AIは必ずしも矛盾を指摘して止まりません。
むしろ、文脈から推論して、一部では必須チェックを入れ、一部では任意として扱い、別の箇所では仮登録可能として実装してしまう可能性があります。
論理破綻した仕様変更を重ねると、AIはその都度、不足や矛盾を推論で補います。
その結果、画面、データ、処理、チェック、テストの前提が少しずつズレ、全体として整合しないシステムになっていきます。
④XERVによる課題解決
XERV Modelystは、AIに渡す前に、仕様を構造化・蓄積・整合管理します。
その場で思いついた仕様をAIに渡すのではなく、RDBに保存された整合性のある仕様情報をもとに、XERVがAI連携用Markdownを自動生成します。
これにより、次のような状態を実現できます。
-
AIに渡す仕様の前提を整理できる
-
不整合な仕様をそのまま渡すリスクを下げられる
-
AIが推論で補う領域を減らせる
-
業務・画面・データ・処理の前提をそろえやすい
-
生成されるコードの品質を安定させやすい
-
レビューや修正の負荷を減らせる
XERVは、AIに“考えさせる”前に、AIが迷わない仕様を用意します。
課題⑤：業務フローと開発仕様の整合性が取れない
⑤課題
仕様駆動開発では、画面・データ・処理の仕様をAIに渡して開発を進めます。
しかし、その仕様が業務フローと合っていなければ、AIが生成するコードも実際の利用シーンに合わないものになります。
よくある問題は次の通りです。
-
画面仕様はあるが、どの業務ステップで使う画面なのか分からない
-
処理仕様はあるが、前後の流れとのつながりが曖昧
-
データの登録・更新タイミングが利用シーンと一致していない
-
例外処理、承認、差戻しなどのパターンが仕様に反映されていない
-
業務フロー変更に対して、画面・処理・データ仕様の変更が追従していない
-
AIに渡す仕様が、実際の利用シーンを含んでいない
この状態では、AIが画面や処理を作れても、実際に使いにくいものになる可能性があります。
⑤XERVによる課題解決
XERV Modelystは、開発仕様だけでなく、業務フローもデジタル化して管理できます。
業務フロー、画面、データ、処理をつなげて管理することで、開発仕様がどの業務の流れに対応しているのかを確認しやすくなります。
これにより、次のような状態を実現できます。
業務フローと画面仕様の関係を確認できる
業務ステップと処理仕様のつながりを整理できる
データ登録・更新タイミングを利用シーンと合わせやすい
例外パターンや分岐条件を仕様に反映しやすい
業務変更時に関連する画面・処理・データ仕様を確認しやすい
AIに渡す仕様に、利用シーンの前提を含めやすい
XERVは、開発仕様だけでなく業務フローもデジタル化し、実際の利用シーンと整合した仕様をAIに渡せる状態にします。
課題⑥：業務ユーザーと開発者の仕様認識がズレる課題
⑥課題
仕様駆動開発では、AIに渡す仕様が開発の前提になります。
しかし、その仕様が業務ユーザーと開発者の間で正しく共有されていなければ、AIに渡す前提そのものがズレてしまいます。
よくある問題は次の通りです。
-
業務ユーザーが仕様書を読んでも内容を理解しづらい
-
開発者の理解と業務ユーザーの期待がズレる
-
仕様レビューが技術者中心になり、利用者視点の確認が不足する
-
業務上の例外や判断条件が仕様に反映されない
-
口頭で合意した内容が仕様に残らない
-
レビュー後の修正内容が業務ユーザーに伝わりにくい
この状態でAIに仕様を渡すと、AIは開発者が解釈した仕様をもとに実装します。
その結果、後から「そういう意味ではなかった」「その流れでは使えない」「その条件は例外がある」といった手戻りが発生します。
⑥XERVによる課題解決
XERV Modelystは、非開発者でも仕様を理解しやすい形で、業務・画面・データ・処理の関係を可視化できます。
業務ユーザーと開発者が同じ仕様情報を見ながら認識合わせできるため、AIに渡す前の仕様確認がしやすくなります。
これにより、次のような状態を実現できます。
-
業務ユーザーと開発者が同じ仕様を見て確認できる
-
非開発者でも仕様の関係を理解しやすい
-
業務フローと画面・処理・データのつながりを共有できる
-
例外条件や判断条件を仕様に反映しやすい
-
仕様レビューを業務ユーザーも含めて行いやすい
-
合意した仕様をAIに渡す前提として残せる
XERVは、開発者だけでなく、業務ユーザーも含めて仕様を共有できる仕組みを提供します。
課題⑦：メンバー間で仕様を共有・レビューしづらい
⑦課題
仕様駆動開発では、AIに渡す仕様が開発の前提になります。
しかし、その仕様をチーム内で共有・レビューできていなければ、開発者ごとに異なる前提でAIを使うことになります。
特に、Markdownファイル、Excel、個人メモ、チャットログ、プロンプト履歴で仕様を管理していると、次のような問題が起きます。
-
どれが最新仕様なのか分からない
-
メンバーごとに見ている仕様が違う
-
仕様変更の意図が伝わらない
-
レビュー対象の範囲が分かりづらい
-
どの画面・データ・処理に影響する変更なのか確認しづらい
-
指摘事項がチャットやコメントに散らばる
-
レビュー後の修正が関連仕様に反映されたか追いにくい
-
AIに渡した仕様がレビュー済みか判断しづらい
この状態では、AIを使って開発スピードを上げても、後から「前提が違った」「その仕様はまだ確定していない」「レビュー指摘が反映されていない」といった手戻りが起きます。
⑦XERVによる課題解決
XERV Modelystは、仕様をRDB上に構造化して保存し、チーム全員が同じ仕様情報を参照できる状態を作ります。
業務ユーザー、開発者、レビュー者が同じ仕様を見ながら、関係性や変更内容を確認できます。
これにより、次のような状態を実現できます。
-
メンバー間で同じ仕様情報を共有できる
-
仕様の最新版を確認しやすい
-
業務・画面・データ・処理の関係を見ながらレビューできる
-
変更対象と影響箇所を確認しながらレビューできる
-
レビュー後の修正反映を確認しやすい
-
AIに渡す前の仕様確認をチームで行いやすい
-
レビュー済みの仕様からAI連携用Markdownを自動生成できる
XERVは、仕様を個人のファイルやプロンプトに閉じ込めず、チーム全員で共有・確認できる開発基盤にします。
課題⑧：Markdownファイル管理では仕様の正確性に限界がある
⑧課題
仕様駆動開発では、Markdownで仕様を書き、AIに渡す方法が増えています。
MarkdownはAIに読み込ませやすく手軽に始められる点では有効です。
しかし、仕様をMarkdownファイルとして保存するだけでは、仕様管理に限界があります。
よくある問題は次の通りです。
-
ファイル単位でしか仕様を管理しにくい
-
仕様同士の関係を正確に扱いにくい
-
同じ項目が複数ファイルに重複しやすい
-
変更時に関連ファイルの修正漏れが起きやすい
-
仕様の整合性確認が人の目に依存する
-
AIに渡すMarkdownの品質が安定しない
Markdownは、AIに仕様を渡す形式としては便利です。
しかし、仕様そのものを正確に管理する仕組みとしては不十分です。
⑧XERVによる課題解決
XERV Modelystは、仕様をMarkdownファイルとして保存するのではなく、RDBに構造化して保存します。
RDB上で仕様を正確に管理し、AIに渡すときには、XERVが必要な仕様からMarkdownを自動生成します。
つまり、XERVは、
Markdownで仕様を管理するツールではなく、
RDBで正確に管理した仕様から、AI向けMarkdownを自動生成するツール
です。
これにより、次のような状態を実現できます。
-
仕様を構造化データとして正確に保存できる
-
仕様同士の関係をRDB上で管理できる
-
重複や意味のズレを抑えやすい
-
変更時に関連仕様を確認しやすい
-
整合性の取れた仕様をAIに渡しやすい
-
Markdown出力の品質を安定させられる
XERVでは、Markdownは保存形式ではありません。
RDBで管理された正確な仕様を、AIに渡すために自動生成される出力形式です。
