知識マップ: 受託開発の仕様書、Excelのままでいいのか ── 納品物としての形式の選び方

記事「受託開発の仕様書、Excelのままでいいのか ── 納品物としての形式の選び方」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

受託開発で納品される仕様書がExcel方眼紙で書かれていると、差分を示す仕組みがないために検収が形骸化し、更新コストの高さから保守フェーズで実装と乖離していきます。この記事は、文章はWordの変更履歴、本質的に表であるものはExcelの素直な表、合意時点の記録はPDFで凍結、開発側の原本はMarkdown+GitでPandocからWord・PDFを生成するという適材適所の使い分けを整理します。納品物の範囲や編集可能な原本を含めるかは、IPAの情報システム・モデル取引・契約書のように個別契約で納入物を特定してはじめて意味を持ち、仕様変更のやりとりは変更管理台帳と版番号のルールで運用します。継続保守がある場合はWikiでの「生きた仕様書」も選択肢になりますが、契約終了時のデータ持ち出しを決めておく必要があります。

flowchart LR
    accTitle: 受託開発の仕様書納品形式の知識マップ
    accDescr: 受託開発で納品するExcel方眼紙の仕様書が検収の形骸化と実装との乖離を招くこと、Word・Excelの素直な表・PDF凍結・Markdown原本からのPandoc生成という適材適所の代替、IPAモデル契約や変更管理台帳との関係を示す図
    deliverable_spec_document["納品物としての仕様書・設計書"]
    excel_grid_notation["Excel方眼紙"]
    acceptance_degradation["検収の形骸化"]
    spec_document_drift["仕様書と実装の乖離"]
    word_track_changes["Wordの変更履歴(校閲機能)"]
    excel_native_table["Excelの素直な表"]
    pdf_freeze["PDFによる合意版の凍結"]
    editable_original_document["編集可能な原本"]
    markdown_git_source["Markdown+Gitによる原本管理"]
    pandoc["Pandoc"]
    ipa_model_contract["IPA情報システム・モデル取引・契約書"]
    acceptance_inspection["検収"]
    change_management_ledger["変更管理台帳"]
    version_numbering_rule["版番号のルール"]
    wiki_tool_doc["Wiki・オンラインツールでの仕様書運用"]
    doc_access_loss_on_contract_end["契約終了時の文書アクセス喪失"]
    excel_grid_notation -->|"用いるのは非推奨"| deliverable_spec_document
    excel_grid_notation -->|"原因になり得る"| acceptance_degradation
    excel_grid_notation -->|"原因になり得る"| spec_document_drift
    word_track_changes -->|"軽減する"| acceptance_degradation
    word_track_changes -.->|"推奨される対応"| deliverable_spec_document
    excel_native_table -.->|"推奨される対応"| deliverable_spec_document
    pdf_freeze -.->|"推奨される対応"| deliverable_spec_document
    pdf_freeze -.->|"前提とする"| editable_original_document
    deliverable_spec_document -.->|"前提とする"| editable_original_document
    markdown_git_source -.->|"利用する"| pandoc
    markdown_git_source -.->|"推奨される対応"| deliverable_spec_document
    ipa_model_contract -->|"推奨される対応"| deliverable_spec_document
    ipa_model_contract -->|"前提とする"| acceptance_inspection
    change_management_ledger -->|"推奨される対応"| deliverable_spec_document
    version_numbering_rule -->|"推奨される対応"| deliverable_spec_document
    wiki_tool_doc -.->|"推奨される対応"| deliverable_spec_document
    wiki_tool_doc -.->|"原因になり得る"| doc_access_loss_on_contract_end
    wiki_tool_doc -.->|"軽減する"| spec_document_drift

概念間の関係(全18件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

Excel方眼紙を納品物としての仕様書・設計書に用いることは推奨されません。文章・図・表すべてを方眼紙に押し込むExcel方眼紙は、顧客に納品する成果物としての仕様書には推奨されない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Excel方眼紙は検収の形骸化の原因になることがあります。Excel方眼紙には実用的な差分表示の仕組みがないため、修正版のどこが変わったか目視で探すことになり検収の形骸化を招くことがある / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Excel方眼紙は仕様書と実装の乖離の原因になることがあります。Excel方眼紙は更新コストが高いため、納品後の改修で更新されなくなり実装との乖離が進む原因になることがある / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Wordの変更履歴(校閲機能)は検収の形骸化を軽減します。Wordの変更履歴は修正版の差分を赤字で可視化し、検収の形骸化を軽減する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Wordの変更履歴(校閲機能)は納品物としての仕様書・設計書に対する本記事の推奨です。文章で説明する文書には、見出しスタイル・変更履歴・コメント・文書比較を備えたWordが推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Excelの素直な表は納品物としての仕様書・設計書に対する本記事の推奨です。画面項目定義・コード一覧・権限マトリクスのような本質的に表である文書には、Excelを素直な表として使うことが推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
PDFによる合意版の凍結は納品物としての仕様書・設計書に対する本記事の推奨です。検収を通った版や仕様変更の合意版の記録には、うっかり書き換わらないPDFでの凍結が推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
PDFによる合意版の凍結は編集可能な原本を前提とします。PDFは編集可能な原本の代わりにはならないため、PDFでの凍結は編集可能な原本が別に納品されていることが原則とされる。PDF単独での凍結自体は技術的には可能だが、それでは将来の自社活用や保守委託の選択肢が狭まる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
納品物としての仕様書・設計書は編集可能な原本を前提とします。納品物としての仕様書は、将来の自社活用や他社への保守委託のために編集可能な原本を含んで受け取れることが望ましいとされる。契約上PDFのみで納品されることも実際にはあるが、その場合は保守段階で困る / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Markdown+Gitによる原本管理はPandocを利用します。本記事が示す構成では、Markdown+Gitで管理する原本は、Pandocによって顧客向けのWordやPDFへ変換されて納品される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Markdown+Gitによる原本管理は納品物としての仕様書・設計書に対する本記事の推奨です。開発会社側の管理効率を重視する場合、Markdown+Gitを原本としWord/PDFを生成する構成が推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
IPA情報システム・モデル取引・契約書は納品物としての仕様書・設計書に対する本記事の推奨です。IPAのモデル取引・契約書は、どの文書を成果物とするかを個別契約で特定する構成を持ち、納品仕様書の扱いの土台として推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
IPA情報システム・モデル取引・契約書は検収を前提とします。IPAのモデル取引・契約書は、個別契約で納入物を特定するとともに検収の方法と期間を定める構成になっている / 確度: 確立した関係 / 確認日: 2026-08-01 出典
変更管理台帳は納品物としての仕様書・設計書に対する本記事の推奨です。仕様変更のやりとりを回すため、変更番号・日付・内容・影響・合意者を記録する変更管理台帳の運用が推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
版番号のルールは納品物としての仕様書・設計書に対する本記事の推奨です。「最終」「修正」をファイル名に使わず、検収版をv1.0として変更合意のたびに版番号を上げるルールが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
Wiki・オンラインツールでの仕様書運用は納品物としての仕様書・設計書に対する本記事の推奨です。保守契約が続き改修が頻繁にあるシステムでは、常時更新できるWiki・オンラインツールでの仕様書運用が選択肢として推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Wiki・オンラインツールでの仕様書運用は契約終了時の文書アクセス喪失の原因になることがあります。エクスポート形式・スペースの所有権・アカウントの扱いを最初に決めていないと、Wiki・オンラインツールは契約終了と同時に文書へのアクセスを失わせることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Wiki・オンラインツールでの仕様書運用は仕様書と実装の乖離を軽減します。検索性が高く変更履歴が自動で残るWiki・オンラインツールは、保守フェーズでの継続的な更新によって実装との乖離を軽減しうる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

納品物としての仕様書・設計書: 受託開発で顧客に対価と引き換えに納品され、検収の対象となり数年間使われ続ける、契約上の成果物としての仕様書・設計書。
Excel方眼紙: セルを細かく刻んで原稿用紙のように使う、日本の受託開発で仕様書・設計書によく使われるExcelの書き方。
Wordの変更履歴(校閲機能): 修正版のどこが変わったかを赤字で示し、コメントや文書比較とあわせてレビュー・検収の実効性を高めるWordの機能。
Excelの素直な表: 1行が1レコード・1列が1属性で、セル結合を使わず1シートに1つの表だけを置く、方眼紙ではないExcelの本来の使い方。
PDFによる合意版の凍結: 検収を通った版や仕様変更で合意した版を、うっかり書き換わらないPDFとして双方が保管する記録の取り方。
Markdown+Gitによる原本管理: 仕様書をMarkdownで書き、ソースコードと同じGitリポジトリで行単位の差分・レビュー・履歴を管理する、開発会社側の原本管理方法。
IPA情報システム・モデル取引・契約書: 個別契約で納入物を特定し、検収の方法と期間、変更管理手続を定める構成を持つ、IPAが公開する契約のひな形。
変更管理台帳: 変更番号・日付・内容・影響(費用/納期)・合意者を1行で記録する一覧表。仕様変更のやりとりを回すための基本形の1つ。
版番号のルール: 検収版をv1.0とし変更合意のたびにv1.1、v1.2と番号を上げていく、ファイル名の「最終」「修正」表記を避けるための版管理ルール。
Wiki・オンラインツールでの仕様書運用: NotionやConfluenceのようなオンラインツールで仕様書を常時更新していく、継続保守がある場合の運用形態。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。