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

「修正版の仕様書を受け取ったが、どこが変わったのか分からないまま検収印を押した」

「改修を頼もうとしたら、納品されていたExcelの仕様書が今の画面と全然違っていた」

「開発会社から方眼紙状のExcel仕様書が届いたが、これが普通なのか」

システム開発を外部に委託すると、プログラムと一緒に仕様書・設計書が納品されます。日本の受託開発では、この文書がExcelで作られていることが非常に多く、しばしば「Excel方眼紙」と呼ばれる、セルを細かく刻んで原稿用紙のように使うスタイルで書かれています。

Excel方眼紙への批判はインターネット上に数多くありますが、その多くは開発チームの内部文書としての使いにくさを論じたものです。この記事では視点を変えて、受託開発で顧客に納品する仕様書に絞り、何が問題で、どんな形式を選ぶべきかを、検収・仕様変更・保守という契約実務の言葉で整理します。発注する側の方にも、納品する側の開発会社にも役立つ内容を目指します。

1．まず結論

先に要点をまとめます。

• 納品する仕様書の形式は「開発中に書きやすいか」ではなく、「顧客がレビューできるか」「検収に耐えるか」「仕様変更の差分を共有できるか」「数年後の保守で使えるか」で選ぶ
• 結論は「Excelをやめる」ではなく「方眼紙をやめて、適材適所に戻す」。文章はWord、表はExcelの本来の表、図は作図ツール、合意の記録はPDF
• 形式の議論の前に、どの文書を成果物とするか・編集可能な原本を受け取れるかを契約(個別契約の納入物の特定)で決めておく

ドキュメントの性質別の推奨形式を判断表にすると、次のようになります。

以下、なぜこうなるのかを順に説明します。

2．納品物としてのExcel方眼紙仕様書、何が問題なのか

最初に断っておくと、Excelというソフトが悪いわけではありません。表計算・一覧表の道具としてのExcelは優秀で、後述するとおり項目定義書などではExcelが正解です。問題は、文章も図も表も、性質の違うものを全部「方眼紙」に押し込んでいることです。

社内の内部文書であれば、これは「書いた本人たちが困るだけ」の問題です。しかし納品物となると話が変わります。仕様書は顧客が対価を払って受け取る成果物であり、検収の対象であり、その後何年も使われる資産だからです。納品物の視点で見ると、Excel方眼紙には次の問題があります。

2.1 検収でレビューしきれない

Excel方眼紙には、Wordの変更履歴のような実用的な差分表示の仕組みがありません。正確に言えば、Microsoft 365の共同編集環境にはセル変更の履歴(「変更内容の表示」やバージョン履歴)があり、ブック同士を比較するSpreadsheet Compareのようなツールも存在します。しかし追跡できるのはセルの値や数式が中心で、方眼紙文書が多用する図形・テキストボックス内の文字は対象外ですし、メール添付でファイルを往復させる納品の現場では共同編集の履歴はそもそも機能しません。

結局、レビュー指摘を反映した修正版を受け取ったとき、顧客は「どこが変わったのか」を目視で探すことになります。数十シートの文書を毎回全部読み直すのは非現実的なので、実際には「たぶん直っているだろう」で検収印を押すことになります。

これは検収の形骸化です。検収は「納品物が合意した内容どおりかを確認して受け入れる」手続きであり、ここが形骸化すると、後になって問題が見つかったときに「検収を通したではないか」「いや確認できる形で納品されていない」という不毛な議論になります。

2.2 仕様変更の合意記録が残らない

開発の途中で仕様は必ず変わります。そのとき文書がExcel方眼紙だと、変更のやりとりは「ファイルコピーの山」になりがちです。仕様書_v2_最終_修正(2).xlsx のようなファイル名に見覚えのある方は多いはずです。

問題は、どの版が「双方が合意した版」なのかを後から特定できないことです。追加費用や納期をめぐって意見が食い違ったとき、根拠になるのは合意した文書です。その文書がどれか分からなければ、水掛け論になります。

2.3 保守フェーズで実装と乖離する

方眼紙文書は更新コストが高いため、納品後の改修で更新されなくなっていきます。レイアウトが崩れるのを恐れて誰も触らない、図形の中の文字は検索にかからないので直し漏れる、といった積み重ねで、数年後には「仕様書はあるが、現状と合っているか誰にも分からない」状態になります。

この状態のツケを払うのは、次の改修のときです。文書が当てにならなければ、現物(動いているシステムとソースコード)の調査からやり直すことになり、その工数は見積もりに上乗せされます。文書が保守されないことは、将来の改修費用に跳ね返るのです。

2.4 顧客の手元で活用できない

印刷を前提に組まれたレイアウトは、画面では読みにくいものです。また、内容が多数のシートと図形に分散しているため全文検索が効きにくく、「あの仕様どこに書いてあったか」を探すのに時間がかかります。顧客側で運用メモを追記したり、社内説明資料に流用したりといった二次利用もしにくく、せっかく対価を払った文書が「保管されているだけ」になりがちです。

3．契約の観点 ── 仕様書は「成果物」である

形式の話に入る前に、一段上の話をします。仕様書・設計書は、契約で納入物と定めることで、プログラムと同じ契約上の成果物になります。逆に言えば、契約で特定されていない文書は、当然に納品されるものとは限りません。IPAの情報システム・モデル取引・契約書でも、個別契約で納入物を特定し、検収の方法と期間を定める構成になっています。モデル契約の全体像は、別記事「受託開発・運用保守の契約はどう結ぶべきか ── IPA『モデル取引・契約書』に学ぶ準委任と請負の使い分け」で解説しています。

つまり、Excel か Word かという形式の議論は、次の土台が決まっていて初めて意味を持ちます。

• どの文書が成果物か: 「ドキュメント一式」ではなく、文書名のレベルで一覧にする
• どんな形式で受け取るか: 編集可能な原本(WordやExcelのファイル)を含むか。PDFのみは保守で困る
• 検収の方法: 何を確認したら受け入れるのか。修正版の差分をどう示すか
• 著作権・二次利用の扱い: 顧客が社内で複製・改変できるか。将来、別の会社に保守を委託するときに文書を渡せるか

ここが契約で決まっていないと、どんなに立派な形式を選んでも「そもそもその文書は納品対象なのか」で揉めます。発注前の整理については「Windowsアプリ 外注・受託開発を依頼する前に整理したいこと」も参考にしてください。

4．納品形式の選択肢 ── 「納品物として成立するか」で比べる

土台が決まったら、形式を選びます。評価軸は冒頭で述べたとおり、顧客の読みやすさ / レビュー・検収のしやすさ / 仕様変更の差分管理 / 保守フェーズでの持続性の4つです。

それぞれ補足します。

4.1 Word ── 文章主体の仕様書の第一候補

概要設計書や業務フローの説明のように「文章で語る」文書は、ワープロで書くのが本来の姿です。Wordには納品文書に必要な道具が最初から揃っています。

• 見出しスタイルと自動目次: 文書の構造が明確になり、目次から目的の箇所へ飛べる
• 変更履歴(校閲機能): 修正版のどこが変わったかが赤字で見える。レビューと検収の実効性が段違いになる
• コメント機能: 顧客からの指摘とその回答が文書上に残る
• 文書の比較: 2つの版の差分を後からでも表示できる

顧客側に特別なツールも学習も要らず、納品形式としてそのまま通るのも実務上大きい利点です。

注意点は、スタイルを使わず「見た目だけ」整った文書を作ると、Word方眼紙とでも呼ぶべき同じ穴に落ちることです。見出しは見出しスタイルで、レイアウトはスペース連打ではなく書式設定で。また「最新版どれ問題」はWordでも起きるので、後述する版管理の運用とセットで使います。

4.2 Excelは「本物の表」に戻して使う

画面項目定義書、コード一覧、権限マトリクスのような文書は、本質的に表です。これをWordで書くのは逆に不便で、Excelが正解です。ただし方眼紙ではなく、データとして扱える素直な表として使います。

• 1行が1レコード、1列が1属性。1シートには1つの表だけを置く
• セル結合でレイアウトを作らない。見出しは先頭行に1行
• 印刷の見栄えのためにデータ構造を壊さない(印刷用の体裁は別の手段で)

こう作っておくと、保守のときに文書を機械的に扱えます。項目定義と実際のデータベース定義を突き合わせる、一覧をそのまま試験項目のベースにする、といった再利用が効くようになり、「文書が実装と乖離していないかの確認」自体が楽になります。

4.3 PDF ── 「合意した版」を凍結する形式

PDFは手軽に編集できないことが欠点にも利点にもなります。仕様書の原本としては失格ですが、検収を通った版・仕様変更で合意した版のスナップショットとしては適しています。うっかり書き換わることがないため、「この時点でこう合意した」という記録として機能します。

ただし厳密には、PDFも作り直すことはできます。記録としての力はPDFという形式そのものではなく、双方が同じファイルを保管していることから生まれるので、メールで送付して送信記録ごと残す、双方の環境で保管するといった運用とセットにしてください。紛争時の証拠性まで求めるなら、電子署名やタイムスタンプの付与も選択肢です。

もう1つの原則はシンプルです。PDFは常に、編集可能な原本とセットで。PDFのみの納品は、顧客の将来の選択肢(自社での活用、他社への保守委託)を狭めます。

4.4 Markdown + Git を原本に、Word / PDF を生成して納品する

開発会社側の管理としては、仕様書をMarkdownで書き、ソースコードと同じGitリポジトリでバージョン管理する方法が近年広がっています。行単位の差分が取れ、コードレビューと同じ仕組みで文書レビューができ、変更の経緯が履歴として残ります(開発実務の記録としては十分ですが、監査や紛争対応の証拠まで求めるなら、履歴の書き換えを禁止した運用などが別途必要です)。

このとき顧客にGitを求める必要はありません。原本はMarkdownで管理し、納品物はPandocなどの変換ツールでWordやPDFを生成する構成にすれば、顧客は今までどおりWord/PDFを受け取るだけです。開発側の管理効率と、顧客側の読みやすさを両立できます。

注意点は「原本はどちらか」を契約上明確にすることです。生成したWordファイルに顧客が直接手を入れると原本と分岐してしまうので、修正依頼はコメントでもらい原本側に反映する、といった運用の取り決めが要ります。

4.5 Wiki・オンラインツール ── 継続保守がある場合の「生きた仕様書」

保守契約が続いていて改修が頻繁にあるシステムでは、NotionやConfluenceのようなオンラインツールで仕様書を常時更新していく形も有力です。検索性が高く、変更履歴が自動で残り、「納品して終わり」ではなく「生きた文書」を維持しやすい形式です。

ただし納品物として見ると、契約が終わったときに何が残るかを最初に決めておく必要があります。エクスポート形式(WordやPDFに書き出せるか)、スペースの所有権と料金負担、閲覧アカウントの扱い。ここを曖昧にすると、特定ツールへのロックインが起き、契約終了と同時に文書へのアクセスを失うリスクがあります。

5．仕様変更のやりとりをどう回すか

形式を整えても、運用が無ければ「最新版どれ問題」は再発します。納品して終わりではなく、開発中も保守フェーズでも仕様は変わり続けるからです。おすすめの基本形は次のとおりです。

1. 変更管理台帳を1つ用意する: 変更番号・日付・内容・影響(費用/納期)・合意者を1行で記録する一覧表。これ自体はExcelの素直な表で十分です。IPAモデル契約の変更管理手続(前述の記事参照)と対応させます
2. 文書の修正は差分が見える形で往復する: Wordなら変更履歴をオンにして修正版を送り、顧客は赤字を中心に確認する。変更履歴の付け漏れが不安なら、受け取った側がWordの「比較」機能で前回合意版と突き合わせれば漏れも検出できます。合意したら履歴を反映して版を確定します
3. 版番号のルールを決める: 検収版をv1.0とし、変更合意のたびにv1.1、v1.2と上げる。「最終」「修正」「(2)」をファイル名に使わない
4. 合意した版はPDFで凍結し、双方が保管する: どの版で合意したかを、後から誰でも特定できるようにします

道具は何であれ、この4点が回っていれば「どこが変わったか分からない」「どれが合意版か分からない」という2大トラブルはほぼ防げます。逆に言えば、ツールの選定より運用ルールの合意の方が本体です。

6．発注側が契約前に確認しておきたいこと

発注する側の方向けに、見積もり・契約の段階で確認すべきことをチェックリストにまとめます。

• 成果物一覧に仕様書・設計書が文書名のレベルで入っているか(「ドキュメント一式」になっていないか)
• 編集可能な原本(Word/Excelファイル等)で受け取れるか。PDFのみになっていないか
• 修正版を受け取るとき、どこが変わったか分かる形(変更履歴・変更箇所一覧)で提示されるか
• 保守契約の範囲に改修時の文書更新が含まれるか。含まれないなら乖離していく前提で構わないか
• 文書の著作権・二次利用の扱い。将来、別の会社に保守を委託するときに文書を渡せるか
• 仕様変更の手続き(変更管理台帳・合意の残し方)が決まっているか

受託側の視点でも、この一覧はそのまま見積もりの整理に使えます。どの文書をどの詳細度で書くかは工数であり、金額です。成果物の範囲を曖昧にしたまま受注すると、納品間際に「このドキュメントも当然含まれると思っていた」というすれ違いが起きます。文書の一覧と形式を最初に合意しておくことは、双方を守ります。

7．FAQ

Q1. 発注元からExcel方眼紙のテンプレートを指定されました。従うしかないですか？

納品形式の指定に従うこと自体は受託側の務めですが、指定の目的を確認する価値はあります。社内の文書標準や監査対応が目的なら、同じ内容をWordの様式で満たせないか提案の余地がありますし、テンプレートが昔からの慣習で残っているだけというケースも少なくありません。指定を変えられない場合でも、修正版に「変更箇所一覧」を添える、合意した版をPDFで凍結するなど、運用の工夫で差分が見えない問題の多くは緩和できます。

Q2. 仕様書がPDFだけで納品されました。問題ないですか？

その時点では読めるので問題に見えませんが、保守・改修の段階で困ります。PDFの編集は専用ツールで不可能ではないものの、WordやExcelの原本のように構造を保ったまま更新し続けるのは現実的でなく、仕様変更のたびに実装との乖離が進みます。将来別の会社に保守を頼む場合にも、編集可能な原本がないと引き継ぎにくくなります。契約時に「編集可能な形式を含めて納品する」ことを成果物の条件として明記するのが確実です。すでにPDFのみで受け取っている場合は、原本の提供を開発会社に相談してみてください。

Q3. 仕様書はどこまで詳細に書いてもらうべきですか？

「詳しいほど良い」わけではありません。詳細な文書ほど更新コストが高く、実装と乖離しやすくなるためです。目安は、検収の基準として使える程度に振る舞いが特定されていること、そして保守・改修のときに参照される情報(画面項目、データ構造、外部連携、業務ルール)が残っていることです。コードを読めば分かる実装の逐一の説明は、文書よりコードとコメントに残す方が乖離しません。詳細度は工数と金額に直結するので、契約前にすり合わせておくべき項目です。

Q4. 納品後の仕様書の更新は誰の責任ですか？

契約によります。保守契約の範囲に「改修時の設計文書の更新」が含まれていれば受託側の作業ですし、含まれていなければ、改修のたびに文書更新を個別に発注するか、乖離していく前提で扱うことになります。トラブルになりやすいのは、決めないまま「当然更新されているはず」と双方が思い込んでいるケースです。保守契約を結ぶときに、どの文書を保守対象にするかを文書名のレベルで明記しておくことをおすすめします。

まとめ

受託開発で納品する仕様書について、この記事の要点をまとめます。

• 納品する仕様書の形式は、検収・仕様変更・保守の観点で選ぶ。「開発中に書きやすいか」だけで選ばない
• Excel方眼紙の本質的な問題は、差分が見えないことによる検収の形骸化、合意記録の喪失、更新コストの高さによる実装との乖離
• 結論は「Excel全廃」ではなく適材適所への回帰。文章はWord(スタイル+変更履歴)、表はExcelの素直な表、合意の記録はPDF凍結
• 開発側の原本をMarkdown+Gitで管理し、納品物としてWord/PDFを生成する構成は、双方の利点を両立できる
• 形式より先に、成果物の一覧・編集可能な原本の納品・著作権の扱いを契約で決める。ツールより運用ルールの合意が本体

なお、Excelをプログラムから読み書きする話(帳票出力)は「Excel帳票出力の作り方 - COM/Open XML/テンプレート」で、契約の組み立てはIPAモデル取引・契約書の解説記事で扱っています。あわせてどうぞ。

受託開発・保守の委託をご検討の方へ

合同会社小村ソフトでは、Windows業務アプリの受託開発をお受けする際、この記事で紹介した考え方で成果物ドキュメントの範囲・形式・更新の運用を最初に発注側と合意するようにしています。また、既存ソフトの改修では「仕様書はあるが現状と合っているか分からない」状態からの調査もお受けしています。仕様書の整備や納品形式の見直しを含めて、お気軽にご相談ください。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

発注元からExcel方眼紙のテンプレートを指定されました。従うしかないですか？

納品形式の指定に従うこと自体は受託側の務めですが、指定の目的を確認する価値はあります。社内の文書標準や監査対応が目的なら、同じ内容をWordの様式で満たせないか提案の余地がありますし、テンプレートが昔からの慣習で残っているだけというケースも少なくありません。指定を変えられない場合でも、修正版に「変更箇所一覧」を添える、合意した版をPDFで凍結するなど、運用の工夫で差分が見えない問題の多くは緩和できます。

仕様書がPDFだけで納品されました。問題ないですか？

その時点では読めるので問題に見えませんが、保守・改修の段階で困ります。PDFの編集は専用ツールで不可能ではないものの、WordやExcelの原本のように構造を保ったまま更新し続けるのは現実的でなく、仕様変更のたびに実装との乖離が進みます。また将来別の会社に保守を頼む場合にも、編集可能な原本がないと文書を引き継ぎにくくなります。契約時に「編集可能な形式(WordやExcelの原本)を含めて納品する」ことを成果物の条件として明記するのが確実です。すでにPDFのみで受け取っている場合は、原本の提供を開発会社に相談してみてください。

仕様書はどこまで詳細に書いてもらうべきですか？

「詳しいほど良い」わけではありません。詳細な文書ほど更新コストが高く、保守フェーズで実装と乖離しやすくなるためです。目安は、検収の基準として使える程度に振る舞いが特定されていること、そして保守・改修のときに参照される情報(画面項目、データ構造、外部連携、業務ルール)が残っていることです。逆に、コードを読めば分かる実装の逐一の説明は、文書よりコードとコメントに残す方が乖離しません。どの文書をどの詳細度で作るかは工数、つまり見積もり金額に直結するので、契約前にすり合わせておくべき項目です。

納品後の仕様書の更新は誰の責任ですか？

契約によります。保守契約の範囲に「改修時の設計文書の更新」が含まれていれば受託側の作業ですし、含まれていなければ、改修のたびに文書更新を個別に発注するか、乖離していく前提で扱うことになります。トラブルになりやすいのは、この点を決めないまま「当然更新されているはず」と双方が思い込んでいるケースです。保守契約を結ぶときに、どの文書を保守対象にするかを文書名のレベルで明記しておくことをおすすめします。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。