仕様変更の履歴の残し方｜決まったことと変わったこと
クライアントからの追加要望は、制作の現場では珍しくない。ただし依頼を受けたことと、費用や納期を含めて合意したことは同じで…
text: HYPE編集部
エンジニアの記事一覧へクライアントからの追加要望は、制作の現場では珍しくない。ただし依頼を受けたことと、費用や納期を含めて合意したことは同じではない。初期仕様、変更提案、決裁、実装の履歴を分けて残すことで、制作者も発注者も後から判断根拠を確認できる。変更管理は対立を避け、仕事を進めるための共通資料となる。
最初の合意を基準版として保存する
要件定義書、画面構成、納品範囲、検収条件を日付付きで固定する。修正された最新版だけを残すと、どの時点で何が増えたか追えない。契約書の記載と実装メモの階層を分け、変更前の前提へ戻れるようにする。
最初に合意した画面構成や機能要件が残っていなければ、途中で何が増えたか説明できない。議事録と見積書だけでなく、承認された要件の版を基準として固定する。口頭の追加指示を基準版へ静かに混ぜ込まない。
版の管理と履歴の残し方の基本は、GitHub Docsの入門資料でも確認できます。
要望と決定を同じ扱いにしない
打ち合わせ中に出たアイデアは、そのまま実装義務にはならない。依頼日、提案者、希望する変更、確認待ちの論点を仮登録し、承認者の判断が下るまでステータスを「提案」としておく。
「やってほしい」は決裁ではない。要望を受領した日、検討した担当、承認者、決定結果を分けると未確定事項を制作工程に紛れ込ませずに済む。保留の理由も記録し、次回会議で再検討する。
仕様変更の影響見積もりを支援してもらうなら、要件整理から承認までの作業範囲を明確にする。 公開や納品の環境を整えるなら、レンタルサーバー エックスサーバーのようなレンタルサーバーも候補になります。
変更が及ぶ場所を具体化する
問い合わせ項目の追加は画面だけでなく、通知メール、保存データ、管理画面、プライバシー文書へ波及する場合がある。要望を見た時点で影響する成果物と確認工程を洗い出し、表面上の修正量だけで見積もらない。
変更の説明を一画面だけで終えず、共通部品やメール通知、管理画面への波及を確認する。文言変更に見えても導線や検証手順が変わる場合がある。影響箇所の一覧が追加費用の根拠になる。
追加工数と納期の調整を記録する
変更で増える制作時間と、削れる作業があればその差分を示す。見積金額と納期への影響を提案し、相手の承認を得てから作業に反映する。金額を決める前に着手すると後で説明しにくくなる。
工数の追加には作業時間だけでなく、既に完成した部分の再検証も含まれる。納期を守る場合には何を後回しにするかを併記する。金額だけ先に伝えて合意したことにせず、範囲と日程をセットで承認してもらう。
履歴管理ツールは承認コメントと元の要望を検索できるかが選定の要点だ。 帳簿づくりまで見据えるなら、マネーフォワード クラウド確定申告のようなクラウド確定申告も役立ちます。
作業の見える化には、Trelloのようなボード型の管理ツールも使われます。
意思決定者を特定する
窓口担当者が賛成していても、予算を持つ部門が合意していないことがある。承認権限、承認日時、決定内容、連絡手段を残す。会議の口頭合意は要点を文書にして確認する。
担当窓口からの連絡と最終決裁者の承認を取り違えない。組織内で合意が必要な変更なら、誰の回答をもって着手してよいか確認する。曖昧な状態のまま進めると納品時に認識違いが発覚する。
バージョンとチケットをつなぐ
変更ごとに識別子を付け、関連するデザイン、実装、テストとひもづける。名前を上書きするだけでは作業の経緯が見えないため、差分と適用先を記録する。実装完了と依頼主承認は別の状態として扱う。
作業チケットの番号と仕様の版をつなげれば、どの修正が何のために入ったか追跡できる。古いファイル名に「最終」を増やすより、一つの履歴に承認内容と差分を残すほうが後任にも伝わる。
変更交渉を苦手とする制作者には、見積もりの説明練習を含む学習プログラムも選択肢になる。 体系立てて学びたい場合は、Webスキルを学ぶオンラインスクール デイトラのようなオンラインスクールも選択肢になります。
変更要望をチケットで管理する考え方は、GitHub DocsのIssues解説にまとまっています。
やらないと決めた項目も残す
見送り理由が残っていないと、別の担当者から同じ指示が繰り返される。予算、優先度、技術制約など判断の根拠を明記する。ただし制約が変わった場合に再検討できるよう、永久に不可能と断定する書き方は避ける。
見送りにした機能を「忘れたもの」と扱われないため、対象外にした理由と再検討条件を記す。追加開発で実現できるか、現行仕様で代替できるかを分けると、後の商談で適切な提案に変わる。
履歴が営業上の交渉材料になる
追加料金の請求だけでなく、初期見積もり時点では予測できなかった条件を次回のヒアリング項目に反映できる。依頼主も予算変更の説明ができ、双方の責任境界が整理される。
履歴が整っていると、制作者の判断ではなく顧客の依頼内容に沿って費用説明ができる。追加請求を正当化するためだけの文書ではない。発注者も社内説明や次の予算編成に活用できる。
判断に使う比較表
| 確認する場面 | 実際に見ておく材料 |
|---|---|
| 最初の合意を基準版として保存する | 要件定義書、画面構成、納品範囲、検収条件を日付付きで固定する |
| 変更が及ぶ場所を具体化する | 問い合わせ項目の追加は画面だけでなく、通知メール、保存データ、管理画面、プライバシー文書へ波及する場合がある |
| 意思決定者を特定する | 窓口担当者が賛成していても、予算を持つ部門が合意していないことがある |
| やらないと決めた項目も残す | 見送り理由が残っていないと、別の担当者から同じ指示が繰り返される |
案件での使い方
制作途中で「お問い合わせ画面をもう一つ増やしたい」と要望が出たとする。追加画面自体の作業量に目を向けがちだが、遷移、通知、スマートフォン表示、管理者の確認画面まで影響を広げて考えたい。見積もりではデザイン作業と実装、試験を分けて示すと、どこが増えたのか説明できる。
顧客が要望を伝えた日時と、実際に着手してよいと決めた日時は別に管理する。途中で保留された項目は、実装待ちなのか承認待ちなのかを判別できる名称にする。期限が迫ったときも、保留中の依頼を勝手に完成扱いにせず、次の版へ回すという合意を取り直す。
履歴が営業に役立つのは、追加請求の証拠になるからだけではない。変更が頻繁に起こる領域を把握すれば、次の案件では初回ヒアリングの質問を増やせる。見積書に想定していない作業と追加依頼の扱いを書いておけば、同じ認識違いを繰り返しにくくなる。
変更要求が複数の窓口から届くなら、同じ機能への矛盾する指示を見つけられるようにする。最新版を一つに集約し、合意済みの内容には承認者と時刻を添える。情報を整理する工程そのものも制作管理の仕事である。
変更の履歴は対立のための証拠ではなく、判断の順番を見えるようにする道具である。承認前に動かない習慣が、納期と請求の双方を守る。
運用時に確認したいこと
会議後に変更点を共有する際、単に最新版のファイルを送るだけでは差分が伝わらない。前回承認版から変わった機能、変更した理由、費用と検収への影響を一緒に書く。承認する側は全文の読み直しではなく、意思決定に必要な箇所を確認できるようになる。
最後の確認
仕様履歴の保存場所を案件ごとにばらばらにすると、承認された資料を探す時間が増える。基準版、決定事項、進行中の要望、見送った要望を区別し、関係者が同じ情報を参照する仕組みを作りたい。新しい担当者が途中から参加したときに、現在の仕様に至った理由をたどれるかが運用の試金石になる。
承認済みの仕様と未確定の希望が混在すると、作業者はどちらを優先すべきか迷う。履歴の一覧には、決定日と決定者を記載するだけでなく、関連する成果物の版を記しておきたい。見積もりの金額に影響しない変更でも、既に行った検証が無効になるなら納期調整が必要になる。費用の増減がないことを理由に手続きから外さない。
出典
CTA
仕事の取り方や単価の決め方で迷ったら、HYPEへご相談ください。→ お問い合わせはこちら
※本記事にはプロモーションを含みます。
合わせて読みたい
つくる人の仕事のヒントを、週1で
新しい記事と、学び・案件のヒントをメールでお届けします。
RECOMMEND
注目のコンテンツ
