LASSIC Media らしくメディア

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

改修の見積もりが妥当かを判断したくても、仕様を説明できるのは常駐しているSESの技術者だけ。その人が抜けたら、誰に聞けばよいのかも分からない——。開発や保守をSESの技術者に長く任せてきた会社では、こうした不安を抱えることがあります。SESの外注依存から仕様把握をやり直すとは、社外の技術者の記憶と手元の資料にしか残っていない仕様を、発注側でも確かめられる状態に戻していくことを指します。

やり直すといっても、SESの技術者を外す話ではありません。仕様をいちばんよく知っているのが彼らであれば、その知識を文書と社内の人に移す作業も、彼らの協力なしには進みません。本記事では、IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド 第2版」をもとに、仕様の知識を文書と人に分けて棚卸しの仕方、業務ごとのカバー表のつくり方、SESの技術者に頼む作業と社内が持つべき情報の分け方を整理します。

仕様を頼りきる状態とは

2018年2月に公開されたIPAのユーザガイド^*2は、現行システムを作り直すときに要る「現行業務知識」を、ドキュメントと有識者の2つで捉えています。ドキュメントは、運用・業務の流れと各機能の概要といった現行システムの仕様を確かめられる資料のこと。有識者は、運用や業務の流れの知識と経験を持ち、担当する一定の範囲で要件定義や運用検証のシナリオづくりを自律的に進められる人材と定義されています。^*1

この2つに当てはめると、SESに仕様を頼りきる状態は、ドキュメントが古いか見当たらず、有識者にあたる人が社外の技術者に偏っている状態と言い換えられます。ガイドはもともとシステムの作り直しを前にした手引きですが、仕様の知識を文書と人に分けて確かめる考え方は、作り直しの予定がない会社が自社の仕様を把握し直すときにも使えます。

頼りきりが表に出るのは、ふだんの保守よりも、何かを変えるときです。ガイドは、業務要件を変えずにそのまま移すのだから現行業務知識が足りなくても問題ないと判断して進めると、プロジェクトが問題化すると注意を促しています。^*1 改修の範囲の見極めも、テスト項目づくりも、委託先の見積もりの妥当性の判断も、仕様を知らなければ発注側では進められません。

保守を担う人の知識にも穴がある

ガイドの解説編には、現行の保守を担う会社がテストに必要な業務とシステムの知識を持っている、という前提で進めた作り直しのトラブル事例が載っています。テストに入ってから仕様の漏れが見つかり、追加のテストを組もうとしたものの、項目のもとになる設計書がありませんでした。頼りにしていた保守の会社も、システム全体にわたる業務知識は持っていないと分かり、テストの期間が大幅に延びてリリースも遅れたとされています。^*1

この事例は保守の担い手を責めるものではありません。長く保守を続けるうちに、1人が知っている範囲が担当してきた機能に偏っていくのは自然なことです。ガイドの事例編も、構築から10年以上が経ったシステムでは、改修のときにドキュメントだけが直されず古いまま残ったり、当初の設計に関わった人が異動や退職でいなくなったりしていることが多いと述べています。^*1

SESの技術者についても同じことが言えます。常駐の長い人ほど多くを知っているのは確かですが、「あの人に聞けば全部分かる」という見立てが正しいかどうかは、確かめてみるまで分かりません。仕様把握をやり直す最初の作業は、誰が何を知っているかを確かめることです。

有識者を深さと範囲で見る

ガイドは、現行システムを調べる段階で業務知識の保有状況を確かめるよう求めています。有識者には、スキルの深さ（質の面）と、業務のエリアなどの習熟範囲・カバー範囲（量の面）の2つの側面があるとし、確かめる項目として、業務仕様・基盤・運用保守の担当といった必要な有識者の状況と、運用の検証や合否の判定ができる体制を考えるための保有スキルを挙げています。^*1

ガイドのケーススタディには、調査結果の書き方の例も示されています。業務知識の範囲は現行の保守要員（協力会社）を含めれば網羅できているものの、深さは初期開発から時間が経っていて十分とは言えず、複数人で分担してカバーしている、という記述です。^*1 社外の技術者を含めたうえで、範囲と深さを分けて書く形は、SESの技術者が多い会社でもそのまま使えます。

深さと範囲を分けるのは、それぞれで打つ手が違うからです。範囲に空白があるなら、その業務を知る人を社内外から探さなければなりません。範囲は埋まっていても深さが足りないなら、文書を起こしながら複数の人で突き合わせて、知識を確かめていくことになります。SESの技術者についても、契約上の担当範囲ではなく、実際に答えられる範囲と深さで見ておきます。

業務ごとのカバー表

ガイドは、有識者が足りない範囲には、運用部門や現行システムの開発時のメンバーなどからカバーする人を割り当てるとし、A業務・B業務・C業務を複数の有識者が重なり合って受け持つイメージ図を載せています。^*1 これを表にすると、縦に業務、横に人を並べ、交わるところに答えられる深さを書き込む形になります。SESの技術者、社内のシステム担当、利用部門の担当者を同じ表に並べるのがこつです。

表を埋めるときの注意として、ガイドは2つを挙げています。1つは、割り当てる有識者が期待する範囲とレベルの知識を本当に持っているか確かめること。もう1つは、1人の担当範囲が大きくなりすぎないようにすることです。範囲が適切な規模を超えると作業が過多になって有効に機能しなくなり、その人がボトルネックになるおそれがあるとしています。

確かめ方は、本人の申告だけに頼らず、実際の問い合わせに答えられたかで見るのが確実です。直近の改修や障害の対応で、どの機能を誰が説明できたかを振り返るだけでも、表の空白と重なりが見えてきます。1人のSESの技術者に多くの業務が集まっている列は、その人の負荷が高いことの表れでもあり、文書化を急ぎたい箇所です。

SESの技術者に頼む作業

ガイドは、ドキュメントの不足への対応を、文書の詳しさの段階で分けています。処理設計書のレベルはソースコードから作り直し、基本設計書から要件定義のレベルは有識者や利用部門への聞き取りで作り直す、という整理です。^*1 日々ソースコードを読んでいるSESの技術者にいちばん頼みやすいのは、前者の処理の仕様を文書に起こす作業です。

ガイドの事例編は、ソースコードやシステムの設定の分析だけでは把握しにくい情報も挙げています。どれが最新で正しいソースコードか、処理量や処理のサイクルと起動時刻、基盤の仕組みによって結果的に実現されている排他制御、業務が変わって今は使われていない機能、といった情報です。^*1 どれも日々の保守で触れている人ほど知っている見込みが高く、SESの技術者に書き出してもらう対象に向いています。

文書づくりをふだんの保守作業に上乗せすると、どちらかが後回しになりがちです。何を書き起こしてもらうか、どの程度の時間を充てるかを、委託先と相談して決めておくのが筋でしょう。資料の作成をどこまで頼めるかは契約によって異なるため、契約書の内容と委託先に確かめてください。

社内が持つべき情報

一方で、なぜその処理が必要なのかという業務の仕様は、社内が持つべき情報です。ガイドが基本設計書から要件定義のレベルを利用部門への聞き取りで作り直すとしているとおり、業務の目的やルールを知る人は発注側にいます。SESの技術者が起こした処理の仕様を受け取り、業務の言葉で説明し直せる人が社内にいるかどうかが、仕様を把握し直せたかの分かれ目になります。

カバー表そのものと、分からない箇所の決め方も社内で持ちます。ガイドは、整えきれなかった不足部分について、要件定義のときに現行の仕様が分からない場合や、新旧の比較テストで結果が合わず正解が分からない場合の判断を、意思決定のプロセスで行うよう企画の段階で決めておくことを求めています。^*1 分からない箇所を誰が決めるかは、SESの技術者に委ねられない判断です。

ガイドは、ドキュメントは作るだけで終わらせず、その後に要員が内容を理解してプロジェクトを進められる状態になるよう計画することも求めています。文書を受け取ったら、社内の担当者がそれを読んで小さな改修の影響範囲を説明してみる、といった形で、理解できているかを確かめておきます。

足りない情報の補い方

文書も人も見当たらない部分は、別の経路から補います。ガイドの事例編は、補う方法として、いまの担当者への聞き取り、別の文書からの情報入手、テスト環境での操作トレーニング、ソースコードや稼働ログの分析からの推測、ソースコードからの設計ドキュメントの再生などを挙げています。エンドユーザ向けの操作マニュアルは、開発の文書に比べて新しい内容に直されていることが多い、という指摘もあります。^*1

聞き取りについては、開発当時の関係者が残っていなくても、いまの担当者が保守の中でつかんでいる情報に、全体像を理解する手がかりが残っている場合があるとしています。SESの技術者への聞き取りは、システムの概要と主な画面の操作から始め、ソースコードの分析結果と組み合わせて空白を埋めていく進め方が取りやすいでしょう。

画面の操作は、机上で聞くよりも、テスト環境で実際に操作してみるほうが短い時間で要点がつかめることもある、と事例編は述べています。社内の担当者がSESの技術者の隣で操作を教わる時間を設ければ、聞き取りと文書の確かめを同時に進められます。

つまずきやすい点

よくあるのは、文書をそろえること自体が目的になってしまうことです。一度書き起こしても、改修のたびに直されなければ、文書はまた古くなります。改修を終えたと見なす条件に関係する文書の更新を含め、その更新を社内の誰が確かめるかまで決めておきます。

もう1つは、把握し直した知識が、また一部の人に戻ってしまうことです。ガイドは、プロジェクトが終わった後に、得た知識やノウハウが再び失われていくリスクを軽くする対策を考えることも重要だとしています。^*1 SESの技術者の交代はいずれ起こるものとして、カバー表で1人しか書かれていない業務を減らしていく運用にしておきます。委託先の担当者が替わるときの段取りはSES契約終了の後任への引き継ぎで、外注依存が続く理由と解き方はSESの外注依存とベンダーロックインの防ぎ方で扱っています。

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

SESの外注依存から仕様把握をやり直すうえで、確かめておきたい点は3つに整理できます。第一に、仕様の知識をドキュメントと有識者に分け、SESの技術者も含めて誰がどの業務をどの深さで説明できるかを表にすること。第二に、処理の仕様や運用の情報はSESの技術者に書き出してもらい、業務の仕様は利用部門への聞き取りで社内が起こすこと。第三に、分からない箇所の決め方と、文書を読んで説明できる担当者を社内に置き続けることです。この3点を押さえておけば、「担当の技術者が替わった途端に、誰も仕様を説明できない」事態を避けやすくなります。仕様を受け止める社内の人が足りないときは、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「システム再構築を成功に導くユーザガイド 第2版」（PDF）（https://www.ipa.go.jp/archive/publish/qv6pgp000000117x-att/000057294.pdf）。出典：独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター（2018年）。1.2のトラブル事例（現行の保守を担う会社の業務知識）、2.2(2)業務知識の保有状況、ケーススタディ（ステップ1）の「II. 業務知識」、3.5 現行業務知識不足への対応（観点D）の目的・表3.4・タスクの内容・図3.10とポイント、4.7 計画策定編「現行業務知識不足への対応（観点D）」の事例の取り組み背景と(1)①②③④⑥・(2)①〜④⑥を参照（確認日2026年10月5日）（2026年10月確認）
2. *2　参考：IPA「SEC BOOKS：システム再構築を成功に導くユーザガイド 第2版」（公開ページ）（https://www.ipa.go.jp/archive/publish/secbooks20180223.html）。発行日（2018年2月23日）と、2018年2月26日に第2版が公開されたことの確認として（確認日2026年10月5日）（2026年10月確認）

Tweet