LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

改修を頼むたびに委託先に現状を聞かないと、見積もりが妥当かどうかも判断できない。社内に仕様を説明できる人がいないまま、委託先の担当者の交代を迎えてしまった——。開発や保守を長く外注してきた会社では、こうした場面が珍しくありません。外注依存の状態から仕様把握をやり直すとは、委託先の手元にしか残っていない仕様の知識を、社内でも説明できる状態に戻していくことを指します。

その担い手としてエンジニア採用を考える会社は多いものの、採った人に何から任せるかが決まっていないと、入社後の数か月が委託先との打ち合わせへの同席だけで過ぎてしまいがちです。本記事では、経済産業省の総括レポートとIPAのハンドブックをもとに、処理と業務の仕様の違い、採った人に最初に任せる作業、委託先との役割の分け方を整理します。

外注依存で仕様が見えなくなる仕組み

経済産業省の「レガシーシステムモダン化委員会総括レポート」は、運用や改良が難しくなったシステムを生む要因の一つに「システムのブラックボックス化」を挙げています。中身として並ぶのは、仕様や設計の文書が整っておらず移行や再構築のときに支障が出ること、運用・保守が属人的になっていること、障害の原因がすぐに特定できないことの3つです。^*1 古い技術でも、仕様が明確で改良を続けられるならレガシーシステムではないとも書いています。問われているのは中身を説明できるかどうかです。

外注との関係について、レポートは、多くのユーザー企業がベンダー企業に依存し、IT人材がベンダー企業の側に偏った結果、ITに対する自律性が下がっていると指摘しています。ユーザー企業はコストを抑えるために委託し、ベンダー企業は受託で安定した仕事を得るという、双方が長く続けてきた関係の結果として描かれています。委託先が仕様を抱え込んだという話ではありません。社内に仕様を受け止める人がいないと、改修のたびに説明を受けても、知識が社内に積み上がらないということです。

IPA（情報処理推進機構）の「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」は、設計書を直さないまま変更が加えられたことや、当初の設計方針に反したコピー＆ペーストなどの変更によって、構造や仕様が「誰にも分からなくなってしまっている」システムがあるとしています。^*3 改修の積み重ねで起きることで、社内開発でも起こりえます。

調査に表れた可視化と内製化

総括レポートの元になった市場動向調査は、約4,000社のユーザー企業とベンダー企業に配り、799社が回答したものです。実施期間は2024年12月17日から2025年2月14日まででした。^*1 レポートは、経営層との情報共有やCxO（CIOやCDOなどの役員）の設置と、可視化や内製化の状況との間に、統計的に意味のある相関が確認できたとしています。

仕様把握に近いのは、ブラックボックス対策と内製化の関係です。対策をしているユーザー企業では80％が内製化しており、対策をしていない企業では52％が内製化していませんでした（n=302）。^*1レポートはここから、仕様の可視化を進めるとシステムの課題やデータ・機能と文書の関係が明らかになり、内製化を行う環境や条件が整うと考えられる、としています。仕様が分かっていることを内製化の土台とみる考え方です。

内製化の範囲を尋ねた設問では、最も多いのは「情シス部門が企画・要件定義を行い、後工程はベンダーと協力、業務部門の要求を把握」の40％で、全ての工程を内製化している企業は21％でした（n=278）。企画と要件定義を社内で持ち、その後の工程は委託先と組む形がいちばん多いということです。全ての工程をベンダーが実施している割合は、モダン化に取り組んでいない企業で30％、取り組んでいる企業で17％でした。^*1 仕様把握を取り戻すことは、委託をやめることと同じではありません。

処理の仕様と業務の仕様

仕様を取り戻すとき、最初に押さえておきたいのがハンドブックの次の指摘です。プログラム解析の技術だけでは「処理」の仕様は復元できても、なぜその処理が必要なのかという「業務」の仕様は復元できない、というものです。^*3 コードを読めば、どの条件でどの計算をしているかは分かります。しかし、その条件がどの取引先との約束から来たのか、どの法令に合わせたものなのかは、コードには書かれていません。

ハンドブックはその理由も説明しています。設計は概要設計から外部設計、内部設計、詳細設計へと進むにつれて目的から手段へ移り、前の工程の目的は次の工程では失われていきます。そのため、詳細設計やプログラムから概要設計の情報をすべて復元することはできず、実際に業務を行っている人、システムを維持管理している人、法制度などから情報を補う必要がある、としています。

ここにエンジニアを採用する意味があります。コードの解析は委託先にもできます。一方で、業務の目的を社内の担当者から聞き出し、コードの処理と結びつけて書き残す作業は、社内にいて業務部門と日常的に話せる人のほうが進めやすい仕事です。採った人に任せる仕事の中心は、この業務の仕様をつなぐ役になります。

採った人に最初に任せる作業

ハンドブックは、仕様を戻す前に、まず社内のシステム全体を把握する手順を示しています。準備の段階では、業界のビジネス構造と自社の業務の概要を理解し、複数のシステムを押さえている人や業務を広く理解している人を「有識者」として確認します。有識者は10名を限度に業務全体をカバーできる程度に特定し、まずIT部門から、必要に応じて業務部門にも確かめる、としています。^*3 有識者の一覧づくりは、入社後の最初の仕事にちょうどよい大きさです。

2つ目は、稼働しているサブシステム（業務ごとに分かれた小さなシステム）を資料から洗い出して一覧にし、つながりを構成図にまとめる作業です。ハンドブックは、資料は重複があってもよいので不足しないよう多く集めること、一覧ができたら1年分のシステム運用ログなどの客観的な証拠で漏れや重複を確かめることを挙げています。^*3

3つ目は、一覧の中から1つのシステムを選び、業務の仕様を書き起こす作業です。書き起こす形はシステムの形態で変わります（次の節）。採った人が委託先の担当者に資料の所在を尋ねて一覧の空欄を埋めていく流れにすると、委託先との関係を保ったまま、社内の手元に情報がたまっていきます。

戻す範囲の絞り方

全体の一覧ができたら、どのシステムの仕様から戻すかを決めます。ハンドブックは、仕様復元には地道な情報収集と確認・整理の作業が要るため、対象を十分に絞り込むことが重要だとしています。形態ごとに中心に置く設計情報は次の表のとおりです。

ハンドブックは、この粒度で業務要件が明確になれば、新しい業務要件を加えて新システムを設計するのに十分な情報になると考えられるとしています。分析の目的はそのまま作り直すことではなく、機能を明らかにすることです。概要設計の分析は過度に詳しく行わず、プログラム解析も必要な範囲にとどめるのが合理的だとしています。最初から全部のコードを読もうとして手が止まるのを避けるうえでも役立つ考え方です。

戻しきれない部分が残ることも、あらかじめ想定しておきます。有識者がいない場合や、実行モジュールだけで元のソースコードが無い場合には、仕様が完全には復元できないリスクがあり、不完全な部分を補うためにテストの時間も要る、とハンドブックは書いています。その部分が本当に必要なのかを判断し、廃棄もあわせて検討するという扱いです。

委託先と分ける役割

仕様把握を社内に戻すといっても、委託先との仕事を切ることが目的ではありません。総括レポートは企業が取るべき対策として、ベンダー企業がユーザー企業の内製化を支援・伴走する立ち位置に変わっていく必要があるとしています。ハンドブックも、組織を支えて助言する立場のITコンサルタントやIT企業が理解しておくべき資料だと位置づけています。

決め手は、一覧と業務の仕様の文書を社内の誰が持ち、更新するかです。解析を委託先に頼んでも、結果を受け取って直す人が社内にいれば知識は積み上がります。社員に移す仕事と委託を続ける仕事の分け方はエンジニア採用による外注依存の脱却計画で、仕様書そのものの直し方はレガシーの仕様書を引き継げる形へ直す手順で扱っています。

求人で伝えたい作業と経験

総括レポートは、ユーザー企業の内製強化のために、情報システム部門などに魅力的なジョブやキャリアパスを設けて広く情報公開し、市場価値の高い人材をジョブに見合った処遇で獲得していくことが重要だとしています。仕様把握を任せる求人であれば、何を任せるのかを具体的に書くことが出発点になります。

たとえば「基幹システムの有識者の一覧づくりと、サブシステムの一覧・構成図の作成」「委託先と組んで進める業務フローの書き起こし」のように、入社後の最初の作業を書きます。求める経験としては、既存システムの設計書を読んで改修した経験や、業務部門から要件を聞き取って文書にした経験が合います。

上流を担える人が少ないことも前提にしておきます。総括レポートは、ビジネスアーキテクトやITアーキテクト、データサイエンティストといった上流人材が特に不足しているとしています。1人で全部を担える人を待つより、仕様を読む経験を持つ人を採り、設計の判断は委託先や社内の上位者と組んで進める形のほうが現実的です。

つまずきやすい点

一つめは、一覧や文書を作ったところで止まることです。総括レポートには、構成管理が不十分で既存システムの仕様を理解するのに非常に苦慮したという声や、システム間の連携を平時から把握するには組織的な取り組みがないと難しいという声が載っています。^*1 改修のたびに一覧と文書を直す手順を、委託先との作業の流れに組み込んでおきます。

二つめは、採った人に一人で抱え込ませることです。業務の目的を聞き出すには業務部門の協力が要り、ハンドブックも事業・業務・ITシステムの3つの立場の人が三位一体となることを求めています。^*3 業務部門の責任者から、聞き取りに時間を割くよう声をかけてもらうと進みやすくなります。

三つめは、今の機能をそのまま作り直す前提で仕様を集めることです。総括レポートは、現行機能保証や現行踏襲への強い要望が、モダン化の足かせになっているとしています。残す機能と手放す機能を選べる状態にすることも、仕様把握の目的です。

まとめ：仕様把握で確かめておきたい3つの点

外注依存の状態からエンジニア採用で仕様把握を取り戻すうえで、確かめておきたい点は3つに整理できます。第一に、コードから戻せるのは処理の仕様までで、業務の仕様は業務を知る人から補う必要があること。第二に、採った人には有識者の一覧づくり、サブシステムの一覧と構成図、範囲を絞った業務の書き起こしから任せること。第三に、解析は委託先と組みながら、一覧と文書を社内で持ち、改修のたびに直していくことです。この3点を踏まえておけば、「採ったのに、仕様は相変わらず委託先に聞くしかない」事態を避けやすくなります。任せる作業に合う人の探し方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：経済産業省「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」（PDF）（https://www.ipa.go.jp/disc/committee/begoj90000002xuk-att/legacy-system-modernization-committee-20250528-report.pdf）。出典：経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室（2025年5月28日）。p.7（レガシーシステムの定義）、p.9（ソフトウェア産業の構造と低位安定）、p.11（モダン化を取り巻く現状の問題）、p.15（市場動向調査の対象と実施時期）、p.18・p.22（可視化・内製化に関する傾向）、p.26（モダン化の障壁と自由記述）、p.28（IT人材の需給ギャップ）、p.31・p.35（企業が取るべき対策）を参照（確認日2026年10月2日）（2026年10月確認）
2. *2　参考：経済産業省「レガシーシステム脱却に向けた「レガシーシステムモダン化委員会総括レポート」を取りまとめました」（https://www.meti.go.jp/press/2025/05/20250528003/20250528003.html）。出典：経済産業省の報道発表（2025年5月28日）。総括レポートの公表日と、委員会の事務局が経済産業省・デジタル庁・IPAであることを参照（確認日2026年10月2日）（2026年10月確認）
3. *3　参考：IPA「DX実践手引書 ITシステム構築編 レガシーシステム刷新ハンドブック」（PDF）（https://www.ipa.go.jp/digital/dx/hjuojm000000eem6-att/000089583.pdf）。出典：独立行政法人情報処理推進機構。令和3年11月16日に「プラットフォーム変革手引書」第1版から名称変更・加筆改訂。1.1（背景）、1.2（想定読者）、2.5のSTEP⓪・STEP①（有識者の特定、サブシステム一覧と客観的な証左での確認）、3.1〜3.4（仕様復元とその必要性、段階的情報遡及、概要設計の遡及の考え方）を参照（確認日2026年10月2日）（2026年10月確認）
4. *4　参考：IPA「DX実践手引書 ITシステム構築編」（公開ページ）（https://www.ipa.go.jp/digital/dx/dx-tebikisyo.html）。ハンドブックが「DX実践手引書 ITシステム構築編」の別冊として公開されていることの確認として（確認日2026年10月2日）（2026年10月確認）

Tweet