仕様書がないシステムも、
見える化してから引き継ぎます。
設計書が存在しない、あるいは現物と合っていない既存システムを、ソースコードとデータベース定義からAIリバースで読み解きます。止まると困る機能と、改修頻度の高い機能から、使う順番で整理します。整理した仕様と判断の理由はAI-SDDに蓄積し、改修のたびに更新される形で御社に残します。
仕様書がないことで、こんな状態になっていませんか
- 設計書はあるが、何度も改修した結果、現物と合っていない
- 作った会社にしか分からず、見積もりが妥当か判断できない
- 改修のたびに影響範囲の調査から始まり、毎回工数がかかる
- 担当していたエンジニアが退職し、経緯を知る人がいない
- 刷新したいが、現行が何をしているか分からず要件が書けない
- 別のベンダーに相談したいが、渡せる資料がない
仕様書は「作られなかった」のではなく、「更新が止まった」
最初からなかった、という現場はほとんどありません。どこかで更新が止まっただけです。理由は、更新の手間に見合うものが見えなかったから。それに尽きます。
改修は急ぎで来る
障害対応や法改正への対応は、期限が先に決まっています。動くものを優先し、ドキュメントは後回しになります。そして後で戻ってくる時間は確保されません。
分かっている人がいる間は困らない
担当者が覚えている限り、ドキュメントが無くても運用は回ります。問題が表面化するのは、その人が抜けた後です。そのときにはもう、聞ける相手がいません。
誰の仕事か決まっていない
ベンダーの契約範囲は「改修」であって「ドキュメント更新」ではないことが多い。社内にも担当がいない。結果として、誰も更新しない状態が続きます。
使う順番で、必要な仕様から揃えます
「ドキュメントを整備しましょう」と見積もりを取ったら数千万円だった、という話をよく聞きます。全機能を等しく文書化しようとすると、そうなります。範囲を絞れば、投資は小さく、効果は早く出ます。
揃えるのは、棚に並べる文書ではなく、保守・改修・引き継ぎ・刷新の判断に使える情報です。IDSは次の順で整理します。
止まると事業が止まる機能
受注、決済、出荷、請求など。ここだけは、担当者がいなくても復旧できる状態にしておく必要があります。全体の1〜2割程度に収まることがほとんどです。
改修頻度が高い機能
毎回調査から始めている箇所です。ここを整理すると、以後の改修工数が直接下がります。投資が回収しやすい領域です。
長年変更がなく、安定している機能
動いていて誰も触っていない箇所は、優先度を下げて構いません。刷新の判断が必要になった段階で着手すれば間に合います。
ソースコードから現状を読み解きます
ソースコードとデータベース定義（DDL）を、AIとエンジニアの両方で解析します。ソースコードは「実際に動いているもの」なので、記憶や古い資料より確実です。
機能仕様の再構築
どの画面・バッチが、どういう条件で、何をしているか。実装から読み取れる範囲で機能単位に整理します。
処理フローと依存関係
どの処理がどこに影響するか。改修時にいちばん時間がかかる影響範囲の調査を、あらかじめ済ませた状態にします。
データ構造の整理
テーブルの役割と関係。実際には使われていないカラムや、名前と用途がずれている箇所も見えてきます。
分からない領域の明示
ここが重要です。ソースコードから読み取れないもの（業務上の意図、過去の経緯、外部との取り決め）は「分からない」と明記します。分かったふりをした資料は、かえって危険だからです。
AIリバースで、仕様書がないシステムを見える化する
ソースコードとDDLから、機能仕様・処理フロー・データ構造を整理します。通常は初期費用100万円〜のところ、事業会社10社限定で無料でお受けしています（事前ヒアリング・審査あり、NDA必須）。
外注なのに、内製。それが CORE型。
一度整理しても、更新が止まれば仕様書はまた古くなります。IDSは、ベトナムの開発チームを御社の中核チームとして運営し、仕様と判断の理由が人ではなく仕組みとして御社に残る形にします。
-
C
Constant team
固定
業務を理解したメンバーが、専属で続けて担当します。
固定の専属チーム。数名程度から始めて、3か月ごとの更新時に増減できます。
-
O
Open line
直結
御社の担当者と開発メンバーが、窓口を介さずに直接やりとりできます。
Slackの日越自動翻訳環境を当社の負担で構築します。窓口のBrSEは日本語能力試験N2以上です。
-
R
Real-time view
可視
報告を待たなくても、進捗、課題、リスクを把握できます。
AIによるPJ管理。進捗は日次で報告します。
-
仕様書がない課題への答え
E
Embedded knowledge
継承
仕様、判断の理由、運用の知識が、人ではなく仕組みとして御社に残ります。改修のたびに更新されるので、仕様書が再び古くなりません。
既存システムはAIリバースで見える化してから引き継ぎます。仕様と判断の理由をAI-SDDに蓄積します。成果物はお客様に帰属します。
仕様書がない課題への答えは、E（継承）と、その入口になるAIリバースです。AIリバースで今の姿を見える化し、E で見える状態を保ち続けます。
費用の目安
| AIリバース | 初期費用 100万円〜（対象システムの規模と、提供いただける資料の状態によって変動します） |
|---|---|
| 現在の提供条件 | 事業会社10社限定で無料（2026年12月末まで） 事前ヒアリング・審査があります。NDA締結、ソースコード一式・DDLのご提供、匿名での事例公開へのご同意が条件です |
| 開発体制 | Dev（開発エンジニア）月額20万円〜50万円／BrSE（PM兼務）月額50万円〜90万円 日本側のプロジェクト運営支援は別途（固定 月20万円、または実績精算 人月単価150万円） |
| 最小契約期間 | 3か月。数名程度のチームからお始めいただいています |
この課題についてよくいただくご質問
Q仕様書がまったくない状態でも相談できますか？
着手できます。ソースコードとデータベース定義があれば十分です。むしろ、資料が揃っている案件のほうが少ないというのが実情です。
資料が古い・断片的にしかない状態でも構いません。既存の資料は参考として使い、実装との差分も併せて整理します。
Qソースコードを渡すのが不安です。
NDAを締結したうえで実施します。解析はDDL（データベース定義）を優先し、個人情報や機密情報が含まれる本番データは受け取りません。
取り扱いの範囲や保管期間について、事前にご説明します。社内規程との整合が必要な場合は、その確認から始めていただいて構いません。
Q全部作り直すと、いくらぐらいかかりますか？
全機能を等しく文書化する前提だと、規模によっては数千万円規模になります。その進め方は勧めません。
止まると事業が止まる機能と、改修頻度が高い機能。ここから着手すれば、対象は全体の1〜2割に収まります。何にいくらかかるかは、範囲を絞ってからお見積りします。
Q現行のベンダーに知られずに進められますか？
できます。現行ベンダーへの通知は必須ではありません。まず自社で現状を把握したい、という段階からのご相談も多くいただきます。
ただし、ソースコードの著作権や利用条件が既存契約でどう定められているかは、事前にご確認ください。
Q整理したあと、また同じ状態に戻りませんか？
同じ体制を続ければ戻ります。だからIDSは、成果物をAI-SDD／AIDDという仕組みに蓄積して、改修のたびに更新される形にしています。
ドキュメントを人手で更新し続ける前提の設計は、いずれ必ず止まります。更新が開発作業の一部として自然に行われる形にする。再発を防ぐ方法は、これしかありません。