Web制作の仕様設計で開発が停滞する理由と制作会社との認識齟齬を防ぐドキュメント設計の判断基準とは
福岡ECサイト株式会社
代表 鳥井 敏史
福岡ECサイト株式会社 代表 鳥井 敏史
ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。
専門分野
ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計ECサイト改善の主な実績
この記事の監修
福岡ECサイト株式会社 代表 鳥井 敏史
Web制作の仕様書が形骸化する理由と制作会社との溝が埋まらないとき
Web制作の仕様書があるのに開発が進まない。
担当者と制作会社の認識がズレている。修正が増え続けて納期が延びる。このような状況は多くの企業で起きています。
Web制作の仕様書とは、制作会社と依頼企業が「何を作るのか」「どう動くのか」「どんな体験か」を共有するために設計する、サイト全体の機能・構造・体験フローを言語化した設計書です。
仕様書がある企業でも仕様書がない企業でも、開発が進まない理由は同じです。
それは「技術仕様」「ビジネス仕様」「体験仕様」の3つが分断されているからです。
このテーマは以下の3つに分解できます。
- なぜ仕様書があっても開発が進まないのか
- 仕様書が実務で使われない本質的な理由は何か
- 制作会社との認識を共有する仕様設計の判断基準は何か
仕様書があるのに開発が進まない現場の現実
仕様書を作ったのに開発が進まない理由は明確です。
これは企業内で無言のストレスになっています。
制作会社の開発チームがShopify管理画面やカスタム開発の要件定義書を見ても「これ、実装できるの？」と疑問を持つ。
企業側も「なぜこんなに時間がかかるのか」と不満を持つ。その結果、修正指示が増えて、修正対応で納期が延びていく。
この悪循環が起きています。
では、何が原因なのか。多くの場合、仕様書に書かれていることは「機能的な要件」だけです。「このボタンをクリックしたら〇〇という画面に遷移する」「このフォームに3つの入力項目がある」という機能の羅列に過ぎません。しかし実装を進める際に必要なのは、それだけではないのです。
制作会社の視点で見ると、こう見えています。「ユーザーがボタンをクリックした後、システム側では何が起きるのか」「データベースにはどの値が保存されるのか」「決済システムとの連携ではどのタイミングでAPIを呼ぶのか」「エラーが発生したときの分岐はどうするのか」。これらは、仕様書に書かれていないことが多いのです。
つまり、仕様書は「見た目と機能」は書いているけれど、「内部の動き」と「異常系の処理」が抜けているのです。
だから、開発が進まないのではなく「実装の途中で判断が止まる」という状況が発生するのです。
Web制作の仕様設計における3つの分断構造
仕様書が機能しない理由は、3つの異なる仕様が混在しているからです。
福岡ECサイト株式会社が支援する企業の制作現場では、この分断を「仕様の三層構造」として整理しています。
- 技術仕様：システムが何をするか（APIの呼び出し・データベースの設計・エラー処理）
- ビジネス仕様：企業が何を実現するか（売上目標・CVR・顧客データの活用）
- 体験仕様：ユーザーが何を感じるか（導線・ページ遷移・ストレス要因）
これら3つは独立していません。しかし、多くの仕様書では「体験仕様」だけが詳しく書かれ、「技術仕様」と「ビジネス仕様」が抜けているのです。
例えば、フォーム入力画面の仕様を考えてみます。体験仕様では「ユーザーが3つの項目を入力して確認ボタンをクリック」と書かれています。ところが、制作会社の開発チームには以下の質問が生じます。
- 「郵便番号を入力した時点で、自動的に住所を補完する機能は必要ですか」（技術仕様・実装コスト）
- 「ここで入力されたメールアドレスは、その後のメール配信に使われますか、それとも確認用ですか」（ビジネス仕様・データ設計）
- 「入力エラーが出たとき、どの項目が間違っているのかを、ユーザーに一覧で見せますか、それとも1項目ずつ指摘しますか」（体験仕様・UX）
これらの質問に答えられない場合、開発チームは「判断できないから一度停止」という状態になるのです。その結果、制作会社から「確認いただきたい点があります」というメールが届き、返答待ちになります。これが積もり積もると、開発が進まないという現象になるのです。
制作会社との認識がズレる本質的な理由
なぜ認識がズレるのか。ここは意外と見落とされがちですが、「仕様書を読む視点」が企業と制作会社で違うからです。
企業側の視点では「最終的にこんなサイトになってほしい」というゴール像を持っています。ワイヤーフレームやデザインカンプを見ながら「こういう体験ですね」と認識します。
一方、制作会社の開発チームの視点では「このサイトを実装するには、何行のコードが必要か」「データベースはどう設計するのか」「本番環境でのテストはどこまでやるのか」という実装の粒度で考えています。
同じ仕様書を見ていても、読み方が違うのです。企業側は「全体の流れ」を見ており、制作会社は「個別の実装判断」を見ているのです。だから、齟齬が生まれるのです。
さらに厄介なのは、この齟齬が「開発の中盤以降」に発覚するということです。なぜなら、開発の初期段階では「大枠はあっている」からです。ところが、詳細な実装に入ると「この処理、どうしよう」という細かい判断が必要になり、そこで初めて仕様書に書かれていないことに気づくのです。
その結果、修正依頼が増えます。企業側からすると「え、こんなことまで修正が必要なの」という感覚になり、制作会社からすると「これは仕様書に書かれていなかったから、この判断は妥当です」という認識になります。両者の温度感がズレたまま、プロジェクトが進むのです。
制作会社が実装で止まる5つの判断ポイント
では、具体的には何が足りないのか。制作会社が開発で「判断が止まる」ポイントを整理しました。
- データの正常系と異常系の処理が未定義 フォーム送信時に「データが正常に送信された」というシナリオは書かれていますが、「ネットワークエラーが発生した」「タイムアウトした」「重複データが届いた」という異常系の処理は書かれていないことが多いです。また「エラーが発生したとき、ユーザーには何を表示するのか」という仕様も書かれていません。制作会社は「ユーザーに『エラーが発生しました』と表示しておきます」と実装しますが、企業側は「もっと丁寧なメッセージを出してほしい」と修正を求めるのです。
- 外部システムとの連携タイミングが曖昧 決済システム・在庫管理システム・CRMなど、複数のシステムと連携する場合、「どのタイミングでどのシステムにデータを送るのか」が明確に書かれていないことが多いです。例えば「ユーザーが購入ボタンをクリックした直後に決済を実行するのか」「確認画面で『決定』ボタンをクリックしたときに実行するのか」「支払い完了メールが届いた時点で在庫を減らすのか」といった順序が曖昧だと、実装の方法が複数になり、確認待ちになるのです。
- 権限管理とセキュリティの実装範囲が不明確 管理画面を設計する際に「管理者は全ての機能を使える」「店舗スタッフはこの機能だけ」という要件が書かれていても「不正なアクセスを防ぐために、どのレベルまでセキュリティチェックを入れるのか」「ユーザーがブラウザの戻るボタンを押したときの挙動をどう制御するのか」といった実装の細部は書かれていません。制作会社は「安全のため」という判断で多くのチェック機能を入れることがありますが、企業側は「チェックが多すぎて使いづらい」という評価になるのです。
- パフォーマンスとスケーラビリティの定義がない 仕様書には「このページを1秒以内に表示する」という要件は書かれていても「ユーザーが1万人同時アクセスしたときにも1秒以内に表示するのか」「データが100万件になったときのサーチ機能の速度をどうするのか」といった実装の複雑さを左右する要件が書かれていないことが多いです。制作会社は「現在のデータ量では問題ありません」と実装しますが、数ヶ月後に「ページが遅くなった」という報告が来て、その時点で高額な改修が必要になるのです。
- 本番環境とテスト環境の仕様が分かれていない 開発環境では正常に動いていても、本番環境では異なる挙動をすることがあります。例えば「メール送信のタイミング」「画像ファイルの保存先」「ログの記録方法」といった環境依存の処理が仕様書に書かれていないと、本番環境でのテスト時点で問題が発見され、修正が必要になるのです。これが納期直前に起きると、大きなリスクになります。
これら5つのポイントで「判断が必要だが、仕様書に書かれていない」という状況が起きるのです。
仕様書の形骸化と修正ループの悪循環
仕様書に不足がある→開発が止まる→確認メールが増える→修正が増える→納期が延びる。このループは、一度始まると抜け出すのが難しくなります。
なぜなら、修正が積もるにつれて「仕様書を更新するのが間に合わない」という状況が起きるからです。企業側は「開発を進めて」と制作会社に急かし、制作会社は「仕様書が確定していないのに進められない」と返す。その結果、企業側は「仕様書なしで進めてください、修正で対応します」と言い始めるのです。
ここまで来ると、仕様書は存在しても「参照されない書類」になります。開発チームはSlackのやり取りやメールのやり取りを仕様として実装を進めることになり、本来あるべき仕様書は単なる形骸化した文書になるのです。
この状態で開発が進むと何が起きるか。一貫性がなくなります。開発期間が長くなると、開発メンバーが入れ替わることがあります。新しいメンバーはSlackのログやメールのやり取りを遡るしかなく、その結果「古い実装と新しい実装で異なる作り」になることがあります。テスト段階で不具合が発見されても「なぜこう実装されているのか」が分からず、修正に時間がかかるのです。
制作会社との認識を共有する仕様設計の3つの原則
では、仕様書がちゃんと機能するようにするにはどうするのか。必要なのは「仕様書の書き方を変える」ことではなく、「何を仕様書に入れるか」の設計を変えることです。
福岡ECサイト株式会社が支援する企業では、仕様設計に3つの原則を導入しています。
原則1：技術仕様を体験仕様と一緒に書く
体験仕様だけを先に作り、後から技術仕様を追加するのではなく、最初から両者を一緒に設計するということです。
例えば、商品検索機能の仕様を考えます。体験仕様では「検索ボックスにキーワードを入力して検索ボタンをクリック→検索結果一覧が表示される」と書きます。同時に、技術仕様では「この検索は全文検索エンジンを使うのか、データベースのLIKE句で実装するのか」「検索結果は自動更新するのか、手動で更新するのか」といった実装方法を並行して決めるのです。
そうすることで、体験と技術のズレが生まれません。また「この体験を実現するには、このくらいの実装コストが必要」という判断もできるようになります。
原則2：エラーシナリオと異常系を最初に定義する
多くの仕様書は「正常系」だけを詳しく書きます。ところが、本来重要なのは「ユーザーが何か間違えたときにどうなるか」「システムがエラーを出したときに何を表示するか」という異常系なのです。
異常系を仕様書に盛り込むときの工夫は「シナリオ形式で書く」ということです。例えば、決済フローの仕様であれば「ユーザーが金額を間違えて入力した場合」「クレジットカードの有効期限が切れていた場合」「3Dセキュアの認証に失敗した場合」など、想定される異常なシナリオを列挙し、それぞれの処理を書くのです。
このようにしておくと、制作会社の開発チームは「ここまでカバーすれば良いんだ」という判断基準が明確になり、実装の漏れが減ります。
原則3：確認フローを最初に決める
どんなに詳しい仕様書を作っても、開発の途中で不明な点は出てきます。重要なのは「その時点で誰が、何日以内に判断するのか」を決めておくことです。
例えば「開発チームから確認メールが届いた場合、24時間以内に返答する」「判断できない場合は、月1回の打ち合わせで一括確認する」といったルールを決めておくのです。そうすることで「確認待ち」が長引くのを防げます。
さらに重要なのは「確認した内容を仕様書に記録する」ということです。その後の開発や本番運用で同じ質問が出てこないようにするためです。
仕様設計の判断基準：何から始めるべきか
では、実際に仕様設計を改善する場合、どういう基準で判断すべきか。以下の診断ポイントを確認してみてください。
- 修正依頼が月50件以上である場合：仕様書の不足が明らかです。体験仕様と技術仕様の分断を解決することを優先してください。次の制作プロジェクトで、仕様書の設計段階から改善するべきです。
- 開発が予定よりも30日以上遅延している場合：確認メールのやり取りが増えている可能性があります。現在の仕様書で「不明な点」をリストアップして、制作会社と一度整理する打ち合わせを開催してください。
- テスト段階での不具合が20件以上ある場合：異常系の仕様が不足しています。本番運用で同じような問題が繰り返される可能性があります。テスト段階で発見された不具合を「これは実装の誤りか、仕様の不足か」で分類し、仕様書に記録してください。
- 本番環境で予期しない問題が発生している場合：環境依存の仕様が不足しています。本番環境で起きている問題を「どの仕様に抜けがあったのか」で分析し、次の制作プロジェクトで反映してください。
制作会社との認識共有を実現する仕様書のテンプレート要素
では、実際に仕様書を作り直す場合、何を入れるべきか。
福岡ECサイト株式会社が支援する企業との制作案件では、以下の8つの要素を仕様書に入れています。
- 機能一覧と優先順位：何を実装するのか、その中で何が最優先か。
- ユースケース図：ユーザーが何をするのか、その流れを図で示す。
- データフロー図：データがどう流れるのか、どのシステムを経由するのか。
- シーケンス図：正常系と異常系の処理の順序を時系列で示す。
- 画面遷移図：ページがどう遷移するのか、ボタンのクリックでどこに移動するのか。
- エラー定義表：起こりうるエラーの一覧と、各エラー時の表示内容・処理方法。
- 外部API連携仕様：外部システムとの連携タイミング・パラメータ・成功時の処理・失敗時の処理。
- 非機能要件：パフォーマンス目標・セキュリティ基準・テスト項目・本番環境での対応。
これらの8つを全て含めることで、制作会社が「判断が止まる」ポイントはほぼなくなります。
よくある失敗パターン：仕様書を作ったのに機能しないとき
仕様書を改善しても失敗することはあります。よくあるパターンをご紹介します。
失敗パターン1：仕様書の詳しさと実装の現実がズレている
仕様書に書かれていることが、実装する技術で実現不可能なことがあります。例えば、Shopifyのカスタム開発では「この処理は標準機能で対応できない」ということが開発の中盤で発覚することがあります。その場合、仕様を「実装可能な形に変更する」か、「別の技術で実装する」かの判断が必要になるのです。
こうなるのを防ぐため、仕様書を作る段階で「使う技術の制約を確認する」ということが重要です。Shopifyであれば「Liquid言語で対応できる範囲」を最初に確認し、その範囲内で仕様を設計するのです。
失敗パターン2：仕様書が作られたけれど、制作会社との打ち合わせで内容が変わっている
企業側が仕様書を作ったものの、制作会社との初回打ち合わせで「実装が難しい」「期間が足りない」という理由で仕様が削られることがあります。その場合、削られた仕様書を更新しないまま開発が進むことがあり、後になって「あれ、この機能は？」という確認が出てくるのです。
これを防ぐため、打ち合わせで仕様が変更された場合は「その場で仕様書を更新する」というルールを決めておくべきです。
仕様書が実務で使われるようにする3段階のアプローチ
では、実際に仕様設計を改善する場合、どういう流れで進めるべきか。
福岡ECサイト株式会社が企業と制作会社の間で支援する際は、以下の3段階で進めます。
段階1：現在の仕様書の課題をリストアップする（1〜2週間）
今、進行中のプロジェクトがあれば、そのプロジェクトで「どんな確認メールが来ているか」「修正は何が理由か」をリストアップします。そこから「仕様書に不足している要素」を逆算します。
例えば、決済機能の確認メールが多ければ「支払い完了後の処理」「エラー時の処理」が仕様書に足りていないということが分かります。
段階2：次のプロジェクト以降で適用する仕様テンプレートを設計する（2〜3週間）
課題が分かったら、仕様書に「何を」「どの粒度で」「どの形式で」入れるかを決めます。このとき、制作会社にもヒアリングしておくと、より実務的なテンプレートが作れます。
段階3：テンプレートを使った仕様書で1つのプロジェクトを試してみる（3ヶ月）
次のプロジェクトでこのテンプレートを使い、「修正の減り具合」「開発期間の短縮」を測定します。改善できた部分と改善できていない部分を整理し、テンプレートを調整します。
このように段階的に進めることで、企業の文化に合った仕様設計が実現します。
制作会社の視点で考える仕様書の質
企業側が仕様書を評価するときのポイントは「これ、分かりやすいな」という主観的な感覚ですが、制作会社の開発チームが仕様書を評価するときのポイントは異なります。
制作会社は以下の観点で仕様書を読んでいます。
- 「この仕様書から、何をコーディングすべきか明確に判断できるか」
- 「実装の途中で判断が止まるポイントはないか」
- 「テストをするときに、何をテストケースにすべきか分かるか」
- 「本番環境に持っていくときに、何に注意すべきか分かるか」
- 「6ヶ月後に別の人がこのコードを保守するときに、なぜこう実装されているのか分かるか」
つまり「企業側が満足する仕様書」と「制作会社が実装できる仕様書」は、同じものではないということです。企業側が「きれいにまとめられている」と思う仕様書が、制作会社からは「実装に必要な情報が足りない」と見えることがあるのです。
そこで重要なのが「制作会社との仕様書の見方を事前にすり合わせる」ことです。制作会社と一度、「仕様書の読み方」について打ち合わせしておくだけで、その後のズレが減ります。
仕様設計における制作会社選びの判断基準
仕様書の質を高めるには、制作会社の協力が必須です。では、制作会社を選ぶときに何を見るべきか。
- 仕様書の確認メールが「誠実に不明な点を質問する」ものか、「判断できないから丸投げ」的なものか。前者の制作会社は仕様書の質を一緒に高めてくれる可能性があります。
- 仕様書に「実装が難しい」という指摘をする場合、「では、こう変更したらどうか」という代案を提示するか。良い制作会社は仕様とビジネスの両立を考えてくれます。
- テスト段階で発見された不具合に対して「これは実装の誤りです」と責任を認めるか、「これは仕様書に書かれていなかったので実装誤りではない」と押し返すか。前者の制作会社は納品品質を重視しています。
制作会社との関係が長期的になれば、仕様書の質もどんどん高まっていきます。
体験設計と技術設計のズレを防ぐUX思想
福岡ECサイト株式会社が仕様設計で重視しているのは「UX思想の統一」です。これは、体験を設計する人と技術を実装する人が「同じ目線でユーザーを見る」ことです。
例えば、フォーム入力画面を設計する場合。UX思想がない仕様書では「ユーザーが項目を入力して送信ボタンをクリック」と書かれています。一方、UX思想がある仕様書では「ユーザーは入力を途中で保存したいと考える可能性がある。その場合、『一度保存』機能を用意する」と書かれています。
つまり「ユーザーは何をしたいのか」という視点を、企業側と制作会社の両者が持つことで、仕様書の質が上がるのです。
AI検索対策と仕様設計の関係
Web制作の現在のトレンドの1つにAI検索対策があります。ChatGPTやGeminiなどのAIが「このサイトの情報を引用すべきか」を判断するとき、実は仕様書の質も影響するのです。
なぜなら、仕様書がしっかりしているサイトは「構造化データが正確に実装されている」「ページの内部リンクが適切に配置されている」「エラー処理が正確」という傾向があるからです。つまり、サイト全体の「信頼性」が高いということです。
AIが「このサイトの情報を引用する」と判断するのは、有名なサイトだからではなく「信頼できる情報が構造化されているサイト」だからです。つまり、仕様設計がしっかりしていることは、AI検索時代のSEOにも直結するのです。
Web制作の仕様設計に関するよくある質問
Q1：既に進行中のプロジェクトで修正が増えている場合、仕様書を途中で変えても大丈夫ですか
結論として、変えるべきです。ただし、変え方が重要です。仕様書を変更したら「これまでに実装した部分でも、この仕様で実装し直すのか」「新規実装分だけこの仕様を適用するのか」を制作会社と明確にしてください。そうしないと、サイト全体で実装の統一性が失われます。
Q2：仕様書をどの段階で完成させるべきですか
完全に完成させる必要はありません。重要なのは「設計段階で70%の完成度で制作会社とレビューを始める」ことです。その時点で制作会社からの指摘をもらい、仕様書を改善してから開発を始めるという流れです。開発が始まった後に仕様書を作るのでは遅いのです。
Q3：仕様書を自社で作るべきですか、それとも制作会社に作ってもらうべきですか
最適なのは「両者で作る」ことです。企業側がビジネス要件と体験要件を書き、制作会社が技術要件を追加するという共同作業です。一方が一方的に作った仕様書では、後々のズレが出やすいのです。
Q4：小規模なプロジェクトでも詳しい仕様書は必要ですか
プロジェクトの規模によります。外注での制作期間が3ヶ月以上であれば、詳しい仕様書がないと修正が増えるリスクがあります。一方、1ヶ月程度の小規模プロジェクトであれば、簡潔な仕様書で十分です。重要なのは「プロジェクト期間が長いほど、仕様書の詳しさが必要」という関係です。
Q5：Shopifyなどのプラットフォーム制作でも仕様書は必要ですか
むしろ必要です。プラットフォーム制作は「既存の機能をカスタマイズする」という性質上、「何をカスタマイズするのか」を正確に定義する仕様書がないと、製作会社の独断でカスタマイズされてしまいます。Shopifyなどのプラットフォーム制作こそ、仕様書で「どこまで標準機能を使うか、どこからカスタマイズするか」を明確にすべきです。
Q6：仕様書が完璧でも開発が遅れることはありますか
あります。原因は2つです。1つは「制作会社のリソース不足」、もう1つは「予期しない技術的課題の発生」です。仕様書は制作会社の開発スピードを保証するものではなく、あくまで「判断が止まる」のを防ぐものです。開発期間の短縮を期待するなら、仕様書の質とともに「制作会社の技術力」も見るべきです。
判断基準まとめ：自社のプロジェクトはどのレベルか
以下の基準で、自社のプロジェクトが「仕様設計の改善が必要か」を判断してください。
- 修正依頼が月30件未満かつ開発遅延が15日以内→現在の仕様書で問題ありません。次のプロジェクトで「異常系の処理」を追加するだけで十分です。
- 修正依頼が月30〜50件かつ開発遅延が15〜30日→仕様書に「技術仕様」の要素が不足しています。次のプロジェクトから「データフロー図」と「エラー定義表」を追加してください。
- 修正依頼が月50件以上かつ開発遅延が30日以上→仕様書の構造的な改善が必要です。企業側と制作会社の仕様観をリセットし、共有テンプレートで新しい仕様書を作り直すべきです。
- テスト段階での不具合が15件以上→本番運用での問題が予測されます。テスト段階で「なぜこの不具合が出たのか」を仕様書で分析し、記録してください。次のプロジェクトでそれを反映させます。
つまり、Web制作の仕様設計とは何か
つまりWeb制作の仕様設計とは、企業側が「何をしたいのか」と制作会社が「どう実装するのか」の間にある「見えない溝を埋めるプロセス」です。仕様書は単なるドキュメントではなく、両者が同じゴールで動くための「共有言語」なのです。
まとめ
Web制作が進まない理由は、仕様書の不足ではなく「何の仕様が足りないのか」が見えていないからです。体験仕様・技術仕様・ビジネス仕様の3つをバランスよく設計し、企業側と制作会社の認識を事前にすり合わせることで、修正は減り、開発速度は上がります。
判断基準として、修正依頼が月30件を超えている場合は仕様設計の改善が優先度高です。その場合、次のプロジェクトから仕様テンプレートを導入し、制作会社との確認フローをルール化してください。本番環境での問題を防ぎ、納期遵守につながります。
まずは、現在のプロジェクトで「修正依頼の理由」をリストアップして、「どの種類の仕様情報が足りないか」を制作会社と一緒に分析してみてください。そこから次のプロジェクトでの改善が始まります。
Webサイトリニューアルを検討している企業へ
Web制作の中でも「既存サイトのリニューアル」は、仕様設計がより重要になります。既存の動作を引き継ぎながら、新しい機能を追加する場合、仕様書がないと実装の混乱が必ず起きるからです。
福岡ECサイト株式会社は、Shopify移行やMakeShopへの移行を支援する際、既存サイトの仕様書を整理することから始めています。その上で、新しいプラットフォームでの仕様書を設計することで、リニューアル期間の短縮と品質の確保を両立させています。
リニューアルを検討している企業は、単なるデザイン改善ではなく「仕様書から見直す」という視点を持つことで、本当の課題が見えてきます。
お客様の声
食品メーカー・IT部長
Shopifyへの移行を検討していましたが、既存サイトの仕様が複雑すぎて、引き継げるのか判断できていませんでした。福岡ECサイト株式会社に相談したら、既存の動作を仕様書として整理してくれて、「ここはShopifyの標準機能で対応できる」「ここはカスタマイズが必要」という判断ができました。結果、スムーズにリニューアルでき、修正も想定より少なくて済みました。仕様書の重要性を実感しました。
—
