仕様書がない・ブラックボックス化したシステムを刷新する方法
「古いシステムを刷新したいが、仕様書が残っていない」「中身を理解している担当者がもういない」
こうした“ブラックボックス化”に直面し、システムの刷新を躊躇している企業も多いのではないでしょうか。その背景には、どこを変えると何に影響するかが読めず、うかつに手を付けられないといった事情があると考えられます。
しかし、ブラックボックス化したシステムであっても、やり方次第で既存システムの仕様を解き明かし、ブラックボックスを解消することは可能です。本記事では、仕様書がなくブラックボックス化したシステムを安全に刷新する方法を、現行仕様の可視化から始める具体的な手順とともに解説します。
→ブラックボックス化したシステムをAIで可視化し、刷新の上流工程を進める方法は、資料でまとめてご確認いただけます。
- 目次
- お役立ち資料
- 「LaKeel Blu」製品資料
システムのブラックボックス化とは？なぜ起きるのか
システムのブラックボックス化とは、システムの内部構造や仕様、設計意図が誰にも把握できなくなり、「動いてはいるが、中で何が起きているのか説明できない」状態を指します。基幹システムやその周辺システムのように、長く使われ続けるシステムほど、この状態に陥りやすくなります。
主な原因は次のとおりです。
- 設計書（仕様書）が更新されていない・存在しない：改修のたびにドキュメントの整備が後回しにされ、実態との乖離が広がる。
- 担当者の退職・世代交代：現行仕様を知る人がいなくなり、なぜそのような設計にしたのかという背景が引き継がれない。
- 度重なる改修：場当たり的な修正が積み重なり、当初の設計から逸脱していく。
- 属人的な開発・保守：特定の担当者しか触れない領域ができ、どこを修正すれば安全かの判断が、その人の経験に依存するようになる。
つまりブラックボックス化とは、システムの仕様がコードの中にしかなく、設計意図は人の記憶にしか残っていない状態だといえます。どちらも、組織として共有できる形、すなわち形式知になっていないということです。
仕様書がない・ブラックボックス化したシステムの何が問題か
ブラックボックス化を放置すると、次のような問題が積み重なっていきます。
- 改修・機能追加に時間とコストがかかる：影響範囲が把握できず、修正に着手するたびにコードを読み解くところから始めなければならない。
- トラブル対応が遅れる：障害時に原因箇所を特定できず、復旧が長引く。
- 刷新・移行に踏み切れない：現行の仕組みが分からないため、何をどのように変更すべきか判断できない。
- 新サービスの追加・制度改正への対応が遅れる：影響範囲の調査に時間がかかり、事業のスピードに追いつけなくなる。
レガシーシステムは、使い続けるほどブラックボックス化が進み、こうした問題を招きます。そして厄介なのは、その状態を解消するための刷新にも、中身の理解が欠かせないという点です。
ブラックボックスのまま刷新してはいけない理由
長年使われたシステムには、当時の業務都合で組み込まれた例外処理や、今では誰も理由を説明できない分岐が無数に潜んでいます。たとえば、特定の取引先だけに適用される特別な計算ロジックや、月末・年度末にしか動かない処理などは、ドキュメントにも担当者の記憶にも残りにくく、刷新時に見落とされがちです。これらを取りこぼしたまま新システムへ移行すると、稼働後に「この処理が消えて業務が止まった」というトラブルが噴出します。システム刷新が失敗する典型的な原因は、まさにこの「システムの理解不足」にあります。
そのため、既存システムを解き明かしてから新システムへの刷新に着手することが賢明と言えます。この順序を守ることが、失敗を避けるポイントです。では、どう解き明かせばよいのか、次章で具体的な手順を見ていきます。
ブラックボックス化したシステムを刷新する進め方
仕様書がなくブラックボックス化したシステムの刷新では、まず「現行の可視化」に取りかかることをおすすめします。
ステップ1：既存システムを解析して現行仕様を可視化する
最初に、既存システムのソースコードやデータ、稼働状況を解析し、構造・依存関係・処理の流れを可視化します。仕様書がなくても、コードという“事実”は残っているため、そこから現行仕様を読み解くことができます。どの機能がどのデータを扱い、どこから呼ばれているかが見えるだけで、「変更してよい部分」と「変更すると危ない部分」の区別がつくようになります。こうしたコード解析の技術的な手段としては、リバースエンジニアリング（ソースコード解析による設計書の自動生成）というアプローチがあります。（詳しくは別のコラム「AIによるソースコード解析・設計書の自動生成」「リバースエンジニアリングとは？ツールとAIによる現行解析」で解説しています。）
ステップ2：設計書・仕様一覧を整備する
可視化した内容を、設計書や仕様一覧として整備します。これにより、関係者が共通の前提に立てるようになり、「コードと人に埋もれていた暗黙知」が、組織で共有できる資産に変わります。ここで整備したドキュメントは、刷新プロジェクトの土台になるだけでなく、刷新後の保守でも使い続けられます。
ステップ3：残す・変える・捨てるを判断する
現行（As-Is）が明らかになったら、それぞれの機能や処理について「残す・変える・捨てる」を判断します。「なぜこの処理があるのか」を踏まえ、本当に必要なものだけを新システム（To-Be）へ引き継ぎます。現行の非効率をそのまま持ち込めば、刷新は“改善”ではなく“ただの作り替え”に終わります。長年の改修で形骸化した処理や、使われていない機能を、この段階で見極めて切り離すことが重要です。
ステップ4：段階的に刷新する
最初から全面刷新を狙うとリスクが大きく高まります。可視化によって把握した依存関係をもとに、影響の小さい領域や費用対効果の高い領域から段階的に進めるのが安全です。小規模な範囲で刷新し、効果と影響を確認したうえで、問題がなければ次の領域へ進みます。この繰り返しが、大規模な刷新における失敗リスクを抑えることにつながります。
AIで既存システムのコードを解析する
人手に頼ると負担が大きいのが、コードを読み解くステップ1と、その結果を文書にまとめ直すステップ2です。何万行にも及ぶコードをすべて読み、さらに設計書や仕様一覧の形に整えるには、膨大な工数がかかります。ここで有効になるのがAIの活用です。
AIを用いてソースコードを解析すれば、構造・依存関係・処理の流れを体系的に整理し、実装の意図を読み解く手がかりまで得られます。設計書の最新化や新規生成、システムの要約ドキュメント作成まで、一連の作業を進めることができます。ただし、ある分岐が“なぜ”存在するかという業務上の理由は、コードからは分かりません。ここは現行の業務担当者への確認と組み合わせて見極める必要があります。「この機能はどこから呼ばれ、どのデータを更新するか」「この分岐はどのようなケースを想定したものか」といった問いにも、コードを根拠とした回答が得られるようになり、ブラックボックスの中身が徐々に見えてきます。
その一例が、ラキールの製品「LaKeel Blu」です。LaKeel Bluでは、現行解析エージェント（AIエージェント）が、既存システムのソースコードや設計書を解析し、構造や依存関係を整理することで、現行仕様を根拠とともに提示できる状態をつくります。設計書がなければ新たに生成し、設計書があっても古ければ実態に合わせて最新化します。また、レガシーシステムの要約ドキュメントを生成して新規参入者の理解を助け、ソースコードを根拠として、仕様に関する疑問に回答します。こうすることで、刷新の前提となる調査を効率的に進めることができます。可視化した結果は、LaKeel Bluのプロジェクトリードエージェントが受け継ぎます。「何を・なぜ刷新するか」という上流の検討をLaKeel Bluが高い精度で支えることで、ブラックボックスの解明から刷新の要件定義・基本設計までを一貫して支援できます。
刷新後にブラックボックスを再発させないために
苦労して刷新しても、再び同じようにブラックボックス化しては意味がありません。刷新をゴールにせず、そこから先の運用で仕様を見失わないためには、次の3点を押さえておく必要があります。
- 設計書を“生き続ける資産”にする：改修のたびにドキュメントを更新する運用をルール化し、実態との乖離を防ぐ。
- なぜそのような設計にしたのかを残す：判断基準や設計意図を、個人の記憶ではなく共有できる形で記録する。
- ベンダー丸投げを避ける：外部に任せきりにすると再び中身が見えなくなるため、自社で仕様を把握・蓄積できる体制をつくる。
刷新の過程でAIによる現行解析を取り入れ仕組み化しておけば、以降も継続的に仕様を可視化・更新しやすくなり、ブラックボックス化の再発を抑えられます。
よくある質問
Q仕様書がなくてもシステムは刷新できますか？
Aできます。仕様書や設計書がなくても、ソースコードを解析すれば仕様を読み解けます。AIによる現行解析でシステムの中身を可視化し、設計書を整備してから刷新に着手するのが安全な進め方です。
Qシステムのブラックボックス化はなぜ問題なのですか？
A影響範囲が把握できず、改修・トラブル対応・刷新のすべてが滞るためです。事業のスピードを落とす要因にもなり、放置するほどリスクとコストが膨らみます。
Qブラックボックスのまま作り直すのはダメですか？
A危険です。現行に潜む例外処理や必要な分岐を取りこぼしたまま移行すると、稼働後に業務が止まるトラブルが起きやすくなります。まず現行を可視化し、残す・変える・捨てるを判断してから進めるべきです。
Q現行解析はAIでどこまでできますか？
Aソースコードの構造・依存関係の整理、設計書の最新化・新規生成、仕様に関する質問への回答などが可能です。人手では非現実的な規模のコードの読み解きも効率化できます。ただし精度は100%ではないため、その結果はドラフトとして扱い、最終的な確認・判断は人が行う協働的なアプローチが前提となります。
Qシステム刷新でよくある失敗は何ですか？
A現行の可視化が不十分なまま進み、必要な処理を取りこぼすことです。可視化を人手だけで行うと膨大な工数がかかり、人が行う作業である以上、読み落としが生じることもあります。その取りこぼしが、稼働後に「この処理が消えて業務が止まった」というトラブルにつながります。
Q刷新したのに、また仕様が分からなくなるのを防ぐには？
A改修のたびにドキュメントを更新する運用をルール化し、仕様を個人の記憶ではなく共有できる形で残すことです。ベンダーへの丸投げを避け、自社で仕様を把握・蓄積できる体制を保つことも再発防止に有効です。
まとめ：ブラックボックス化したシステムの刷新は“作り替える前に解き明かす”ことから始まる
本記事で見てきたとおり、現行の理解が追いつかないままのシステム刷新は、必要な処理を取りこぼし、稼働後のトラブルを招きかねません。刷新で問われるのは、どのように作り替えるかではなく、その前に中で何が起きているかを理解しているかどうかです。
まずは、刷新したいシステムの「仕様書がどれだけ残っているか」「仕様を説明できる人がいるか」を点検してください。もしブラックボックス化していることに心当たりがあるなら、刷新に取りかかる前に、現行を可視化し、ドキュメントとして整備する手立てを用意することが、最初の一歩になります。
手を付けられないシステムを、動かせる状態にする
とはいえ、何十年も改修を重ねたシステムの現行解析を、人手だけで担うには限界があります。この「現行を解き明かす」工程にAIを使うのが、現実的な打ち手です。本記事で触れた「LaKeel Blu」は、現行解析エージェントが既存システムのソース・設計書を解析して仕様を可視化し、設計書を新規生成・最新化したうえで、刷新の上流まで一貫して支援します。ブラックボックスを解き明かしてから刷新へ進む順序を、仕組みとして実現するアプローチです。
「仕様書がなく、既存システムに手を付けられない」「現行の仕様を分かる人がもういない」——そんなブラックボックスを抱えている、情報システム部門・DX推進担当・保守運用・経営層の皆さまに向け、AIの現行解析で既存システムを可視化し、刷新の上流の検討を高い精度で支える「LaKeel Blu」の仕組みと活用シーンを、資料で詳しくご紹介しています。お困りの際や、少しでもご興味をお持ちいただけましたら、ぜひお気軽に資料をダウンロードしてください。個別のご相談やお問い合わせも喜んで承ります。
このコラムを書いたライター
本サイトでは、企業のDX推進に役立つ様々な情報をお届けしています。
