LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

技術ドキュメントの未整備が生む3つのリスク

技術ドキュメント整備の外注とは、設計書・API仕様書（アプリケーション・プログラミング・インターフェースの仕様を記述した文書）・運用手順書・テスト仕様書など、システムに関わる技術的な文書の作成・更新・体系化を外部パートナーに委託する取り組みを指します。

社内に担当できるエンジニアがいない、業務が逼迫して整備に着手できない、あるいは客観的な第三者視点でドキュメントを整理したい、といった場面で活用されます。

担当者退職でシステム仕様が消える属人化リスク

システムの設計意図や運用ルールが特定の担当者の記憶にしか存在しない状態を属人化と呼びます。この状態では、担当者が退職・異動・長期不在になった時点で、システム保守の継続が難しくなります。

IPA（独立行政法人情報処理推進機構）が2019年に公開した「情報処理システム高信頼化教訓集 ITサービス編」^*1では、ソフトウェア起因の障害54件の教訓が収録されており、その多くがドキュメント不備・手順の属人化に起因するガバナンス・マネジメント上の問題を含んでいます。技術文書の不整備は障害対応の遅延や再発防止の困難につながります。

設計書がない状態でシステムを保守・改修しようとすると、コードを読んで仕様を逆推測する工程が発生します。この「リバースエンジニアリング」は通常の開発作業と比べて時間・費用の両面でコストが高くなります。

引き継ぎ失敗が生む運用停止・障害のコスト

運用手順書が整備されていない場合、保守担当者の交代時に手順が正しく伝わらず、手順の誤実施によるシステム停止が発生するリスクがあります。特に夜間・休日の緊急対応では、手順書の有無が対応速度に直結します。

IPAがシステム開発の契約・取引を標準化するために公開した「情報システム・モデル取引・契約書（第二版）」^*2では、設計書・仕様書・運用手順書が開発委託の成果物として定義されており、これらの文書をシステムと切り離せない資産として扱う考え方が示されています。

ドキュメントが整備されていない状態でベンダー切り替えや内製化を試みると、既存ベンダーへの強い依存（ベンダーロックイン）が続き、交渉力の低下につながります。

DX推進でドキュメント不備がボトルネックになる背景

既存システムのドキュメントが整備されていないと、DX推進の文脈でシステムを刷新・連携しようとした際に「現状把握」の工程が発生し、プロジェクト全体が遅延します。

IPA「DX白書2023」^*3は、「進み始めた『デジタル』、進まない『トランスフォーメーション』」という観点でDX推進の課題を整理しています。技術基盤の文書化が不十分なままでは、新たなデジタルサービスの開発や既存業務のデジタル化において、システム間連携の設計が難しくなります。

また、IPAが推進する「国際規格SLCP（ISO/IEC/IEEE 15288:2023・12207:2017）」^*4では、多様なステークホルダーが「共通の土台を持たずに議論すると合意に時間がかかり、しばしば作り直しや契約トラブルが発生する」と指摘しています。ドキュメントを整備することは、DXプロジェクトにおける関係者間の共通言語を作ることでもあります。

外注できる技術ドキュメントの種類と発注範囲の設計

設計書・API仕様書・運用手順書 — 作成代行の対象5種

技術ドキュメント整備の外注対象として、主に以下の5種類が挙げられます。

発注範囲を決める際の原則は「成果物の形式を先に決めること」です。「ドキュメントを整備してほしい」という曖昧な発注では、委託先の解釈によって成果物の品質・粒度がばらつきます。

現地調査（ヒアリング）が必要なドキュメントと事前提供で足りるもの

技術ドキュメントの外注では、委託先が得られる情報の種類によって進め方が変わります。大きく2つのパターンに分類できます。

一方は「既存ソースコード・設定ファイル・ログ等から起こすパターン」です。コードやサービス定義ファイルを提供することで、委託先がそれを解析してドキュメントを生成します。ヒアリングの機会を最小化できる反面、意図・背景の情報は文書に反映されにくくなります。

もう一方は「現地ヒアリングが必要なパターン」です。運用手順書・障害対応手順書など、担当者の暗黙知を文書化するドキュメントは、ヒアリングなしでは作成できません。この場合、ヒアリング対象者の確保と参加可能なスケジュール調整が外注成功の前提条件になります。

著作権・機密情報の取り扱いと契約上の留意点

技術ドキュメントの外注では、契約段階で以下の3点を明確にすることが重要です。

• 著作権の帰属：委託で作成したドキュメントの著作権は、契約で明示しない場合に受託側に帰属する可能性があります。「成果物の著作権は発注者に帰属する」旨の条項を契約書に記載してください。
• 機密情報の管理：設計書・ソースコード・インフラ構成は、流出した場合のリスクが高い情報です。NDA（秘密保持契約）の締結とともに、作業環境・アクセス手段・情報の廃棄方法を仕様として定めてください。
• 成果物の受け入れ基準：どの状態のドキュメントを「完成」とみなすか、事前に合意しておく必要があります。IPA「情報システム・モデル取引・契約書」^*2では、成果物の受け入れ検査と確認プロセスが契約上の重要事項として位置づけられています。

技術ドキュメント整備を外注する5ステップ

STEP1 現状棚卸し — 何がなく何が陳腐化しているかを洗い出す

外注を始める前に、まず「現状どのドキュメントが存在するか」を棚卸しします。存在するドキュメントは、内容が現在のシステム状態と乖離していないか（陳腐化）も確認します。

棚卸しの対象は「存在するドキュメント」だけでなく「存在しないが必要なドキュメント」も含めます。この工程を省くと、外注先に「何を作ればよいか」を明確に伝えられず、仕様確認に時間がかかります。

STEP2 スコープ定義 — 対象システムと成果物の種類を決める

棚卸し結果をもとに、今回の外注で「どのシステムの」「どの種類のドキュメントを」「どの粒度・形式で」作成・更新するかを決めます。スコープが広いほど費用・期間が増加するため、優先順位をつけて段階的に発注することも選択肢です。

スコープ定義の成果物として「ドキュメント整備計画書」を1枚でまとめると、委託先との認識合わせが容易になります。対象システム名・ドキュメント種別・目標とする完成水準・提供可能な情報の一覧を記載してください。

STEP3 RFP作成 — 委託先選定に必要な発注仕様書を書く

RFP（Request for Proposal・提案依頼書）は、委託先から比較可能な提案を受けるために必要な文書です。技術ドキュメントの外注では、以下の要素をRFPに含めることが求められます。

• 発注背景（なぜ今整備が必要か）
• 対象システムの概要（技術スタック・規模・稼働年数）
• 作成・更新対象のドキュメント種別と件数
• 提供可能な情報の種類（ソースコード提供可否・担当者ヒアリング可否等）
• 成果物の形式・ツール（Confluence・Notion・Word等）
• スケジュール・予算感

STEP4 委託先評価 — 技術理解力・セキュリティ体制・品質確認の3軸

技術ドキュメントの外注では、委託先を選ぶ際に「文章力」だけでなく「技術理解力」を確認することが重要です。設計書やAPI仕様書を正確に記述するには、対象システムの技術スタック（使用言語・フレームワーク・ミドルウェア）を理解できるエンジニアが関与している必要があります。

評価の3軸として「技術理解力」「セキュリティ体制（NDA・アクセス制御・情報廃棄の実績）」「品質確認プロセス（レビュー体制・修正対応）」を設定し、提案内でこれらへの言及を求めることが実務上有効です。

STEP5 受け入れ検証 — ドキュメント完成後の確認・承認フロー

完成したドキュメントを受け取った際、内容の正確性を確認するのは発注側の責務です。特に設計書・運用手順書については、実際のシステム・手順と照らし合わせた検証が欠かせません。

受け入れ検証の結果として修正指摘が発生することを想定し、修正対応の回数・範囲をあらかじめ契約に盛り込んでおくことで、追加費用の発生を防ぎやすくなります。

外注費用の目安と内製コストとの比較

作成代行の費用構成（市場参考値・一次資料ではない）

技術ドキュメントの外注費用は、対象のドキュメント種別・ページ数・ヒアリング工数・修正対応の規模によって変動します。以下は市場参考値であり、一次調査を出典とした公表データではありません。あくまで発注規模感の参考としてください。

• 既存コードからの設計書起こし：対象システムの規模・複雑度により大きく異なります。小規模システム（機能10〜20程度）であれば数十万円規模から依頼可能な事例があります。
• 運用手順書の新規作成：ヒアリング工数が費用に占める割合が高くなります。手順の複雑度と対象手順数によって見積もりが変わります。
• API仕様書の整備：OpenAPI形式での標準化を含む場合、専門のエンジニアリソースが必要となります。

複数の委託候補先から見積もりを取ることで、実際の価格感を把握できます。費用だけでなく「技術理解力のある担当者がアサインされているか」「セキュリティ要件への対応実績があるか」を評価基準に加えることが重要です。

内製との工数比較 — 専任担当者の確保が難しい理由

技術ドキュメントの整備を内製で行う場合、実務と兼務するエンジニアが担当することが多く、業務優先度の競合によってドキュメント作業が後回しになりやすくなります。

また、既存システムの設計書を「現状のコードと一致した状態に更新し続けること」は、変更のたびに更新作業が必要となるため、継続的なリソース確保が求められます。特定のエンジニアに任せる形式だと、その担当者の退職・異動で再び属人化が発生するリスクがあります。

外注を選択するメリットは、社内リソースへの依存を切り離してドキュメント整備を着実に進められる点と、客観的な第三者視点で「現状システムの状態を正確に記述する」作業が期待できる点にあります。

失敗しない委託先の選び方 — 技術力・守秘義務・継続性の3点

技術系ドキュメント作成に求められる専門知識

技術ドキュメントの外注先として「ライティング専業の会社」と「ITシステム開発・保守の実績を持つ会社」では、対応範囲が異なります。設計書・API仕様書・インフラ構成書のように、内容の正確性が直接システム運用に影響するドキュメントでは、技術的な検証能力を持つエンジニアの関与が必要です。

委託先を評価する際は、過去の技術ドキュメント作成事例を開示してもらい、どの技術スタック（例：Java/.NET/AWS/Azure等）への対応実績があるかを確認することが実務上有効です。

この作業を内製で行うには、対象システムの技術スタックへの習熟・ドキュメント作成の経験・ヒアリングスキル・文書レビューの体制が揃う必要があります。これらを同時に内製で備えることが難しい状況での外注活用が、技術ドキュメント整備の委託の実態です。

情報漏えいリスクへの対策（NDA・アクセス制限・作業環境）

設計書・ソースコード・インフラ構成書は、競合他社や攻撃者に渡った場合のリスクが高い情報です。外注先に共有する際は以下の対策を事前に確認してください。

• NDA（秘密保持契約）の締結：プロジェクト開始前に機密情報の定義・使用範囲・廃棄方法を定めたNDAを締結します。
• アクセス権限の最小化：必要な情報のみを提供し、本番環境への直接アクセスを避けます。読み取り専用の参照環境や、必要なファイルのみのエクスポート提供が有効です。
• 作業環境の確認：委託先が個人端末で作業していないか、クラウドストレージへの無断アップロードが禁止されているかを確認します。セキュリティ要件を発注仕様書に明記することで、委託先の対応を義務化できます。

元請（プライムベンダー）に依頼するメリット

技術ドキュメント整備の委託先として、システム開発・運用保守の元請（プライムベンダー）に依頼することで、単なるドキュメント作成代行を超えた価値が得られます。

元請（プライムベンダー）は、システムの全体設計から運用までを一貫して把握しているため、ドキュメントに「なぜその設計になったか」「どのような制約のもとで運用しているか」という背景情報を反映しやすくなります。断片的な成果物ではなく、実際の運用に使えるドキュメントを納品する観点から、技術的な一貫性を担保できます。

また、ドキュメント整備後の保守・更新をシステム保守と一体で依頼できる点も継続性の観点から有効です。

まとめ — 技術ドキュメント整備外注の3つの判断軸

本稿では、技術ドキュメント整備を外注する際の判断軸・発注範囲・進め方・委託先の選び方を整理しました。要点を3つにまとめます。

第一に、属人化リスクの深刻度で外注の優先度を決めること。担当者の退職・異動でシステム仕様が消えるリスクや、引き継ぎ失敗による運用停止リスクが高い状況では、外注によるドキュメント整備の早期着手が有効です。

第二に、スコープ定義と受け入れ基準を事前に合意すること。何を作るか・どの粒度か・誰が承認するかを契約前に明確にすることで、完成後の品質トラブルを防ぎます。著作権の帰属と機密情報の管理条件も契約に明記してください。

第三に、委託先の「技術理解力」を評価軸に加えること。設計書・API仕様書・インフラ構成書は、技術的な正確性が求められます。文章力だけでなく、対象システムの技術スタックへの対応実績と、セキュリティ体制の確認が委託先選定の重要な軸になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（独立行政法人情報処理推進機構）「情報処理システム高信頼化教訓集 ITサービス編」（2019年）
2. *2　出典：IPA（独立行政法人情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2020年）
3. *3　出典：IPA（独立行政法人情報処理推進機構）「DX白書2023」（2023年）
4. *4　出典：IPA（独立行政法人情報処理推進機構）「国際規格SLCP（ISO/IEC/IEEE 15288・12207）」

Tweet