開発会社への仕様変更依頼の書き方｜追加機能・残す業務・未決事項を整理

一文の要望では、開発会社が調べる対象が定まらない

「請求書PDFを出したい」は、追加したい機能の入口です。請求書に何を載せるか、どの操作で作るか、誰が使うかまで決めた仕様ではありません。ここでの仕様とは、システムがどの条件で何をするかを具体的に書いた内容です。

たとえば、担当者が操作して文書を作る案と、ある処理が終わると自動で作る案では、調べる対象が変わります。社内の確認に使う文書と、取引先へ渡す文書でも確認する条件が違います。この例では、どちらもまだ決まっていません。説明のための選択肢を、その会社の確定条件へ書き換えないようにします。

窓口の最初の仕事は、機能の実現方法を決めることではなく、業務担当の希望と分からない部分を、開発担当が質問できる形にすることです。IPA（独立行政法人情報処理推進機構）の解説も、必要な業務の要求を具体化し、関係者と合意へ進める考え方を示しています。この記事の整理欄は、その考え方をこの依頼準備に使う例です。

変更前・追加する仕事・残したい仕事を並べる

まず、基本範囲の記録と追加依頼をそのまま並べます。この例では、基本範囲に請求書PDFの出力は含まれていません。追加したい仕事を、受注数量の登録や納期の共有と混ぜずに示します。

「受注数量の登録と納期共有は残したい」は、発注側の希望です。請求書PDFを追加しても既存の仕事が変わらないという技術的な確認結果ではありません。開発会社へは、残したい仕事も影響を調べる対象として伝えます。

ここでいう「影響の調査」は、追加によって今の仕事や画面、費用、日程がどう変わるかを確かめることです。たとえば、登録済みの数量を請求書へ載せたい場合、数量を訂正したときにどの値を出すか、誰が内容を確認するかも説明が必要になります。これは考え方を示す例で、今回の会社で決まっている条件ではありません。業務担当が使い方の希望を説明し、開発会社が今の仕組みへの影響を調べる、という役割の違いがあります。

残す条件を「今と同じ」で済ませると、数量をどこで登録するか、誰が納期を見るか、どの画面や文書を使うかが伝わりません。実際の会社では、元資料の該当箇所を示し、何を維持したいかを業務担当と確かめます。条件が書かれていない部分は、知らないまま確定させません。

元資料の該当箇所と版を、依頼へ結ぶ

開発会社へ渡す依頼には、基本範囲の記録と追加依頼のメモを添えます。文書の名前だけでなく、どの箇所を根拠にしたか、どの版や日付の資料かを示すと、同じ条件を見て話せます。版とは、改訂した文書を区別するための番号や日付です。

今回の架空資料には、基本範囲の版と、追加依頼を受けた日時が記録されていません。「最新版のはず」と補わず、窓口が確認する項目に残します。別の版に請求書の条件があると分かったら、元の依頼との関係を見直し、どの資料で整理したかを更新します。

メールや打合せで補足を受けた場合も、補足した人と日時、変更された条件を元の依頼に結びます。元の一文を消して整理文だけを残すと、誰の希望をどう解釈したかが追えません。原文と整理案を分けて保存し、整理した内容が希望に合っているかを本人へ確かめます。

未確認の項目に、質問と聞く役を添える

未確認の欄は、窓口が自由に埋める欄ではありません。「何が分からないか」「何を質問するか」「どの役に確認するか」を並べます。担当者の実名と回答期限が決まっていないなら、それも未確認として残します。

横に広い表です。スマートフォンでは横へスクロールし、最後の「確認する役」まで読めます。

表は、質問先となる役の案です。実際の担当者が決まった記録ではありません。小さな会社では一人が複数の役を担っても構いませんが、業務の希望を確かめる作業と、技術的な影響を調べる作業、採否を判断する作業は分けて残します。

必要な資料が見つからないときは、資料名と確認先、次に探す場所を依頼へ添えます。返答がない項目には「未回答」を残し、都合のよい条件で埋めません。質問した日と相手の返答を同じ依頼へ結べば、次に聞くことが分かります。

元の要望を残したまま、開発窓口へ渡す

次は、この資料だけで書ける依頼の例です。元の希望と、窓口が整理した内容を分けます。まだ分からない条件は、質問先とともに渡します。今回は未送信の整理案であり、実際の依頼受付や調査結果ではありません。

元の記録が少ない段階でも、不足する項目を見える形にして相談できます。ただし、回答を待つ間に作業を始めてよいかは、この依頼文だけでは決まりません。調査に必要な条件を確かめる相談と、追加作業の着手を了承する判断を分けます。

変更依頼の整理メモを保存

空欄のメモは、自社の要望と資料を整理するために使えます。記入や保存をしただけでは、依頼を送信したことや、相手の受付、技術的な影響の確認が完了したことにはなりません。

受付後は、回答・採否・実施結果を分けて追う

依頼を送った後は、まず、誰がいつ受け付けたかを元の依頼へ結びます。受け付けたという返事は、変更を実現できるという回答でも、発注側が追加作業を了承した記録でもありません。この架空例は未送信・未調査・未実施で、実際の了承も未確認です。

開発会社の調査回答が届いたら、追加したい仕事だけでなく、残したい仕事への影響と、まだ分からない条件を見ます。発注側の責任者は、業務上の必要性と回答内容を材料に採用・保留・見送りを判断し、その条件と理由を依頼へ結びます。追加費用の見積回答が届いた場合は、追加費用の回答と、作業を始める了承を分ける方法も確認してください。

採用後は、合意した内容を元資料へ反映し、実施した内容と確認結果を残します。IPAの要件定義ガイドも、変更内容、影響の調査、採否、実施結果を分けて追う流れを示しています。この記事の依頼を作っただけで、その後の調査・開発・テストが終わった扱いにはしません。

• 元資料の版が不明：最新版を推測せず、どれを比べるか窓口で確かめます。
• 急ぎだが条件が未定：何をいつまでに誰へ確認するかを相談し、未定の期限を架空の日付で埋めません。
• 業務担当と開発担当の認識が違う：元の希望と整理案、回答の違う箇所へ戻り、担当者と確認します。
• 変更を見送る：理由と残る困りごとを元の依頼へ残し、要望を出した人へ返します。

まとめ：追加する仕事と残したい業務を分けて伝える

開発会社への変更依頼は、元の希望を残し、「追加する仕事」「残したい仕事」「未確認の条件と質問先」を分けて伝えます。残したい条件は希望として書き、変更しても影響がないと決めつけません。

依頼文を整理・送信したこと、相手が受け付けたこと、影響調査の回答、追加作業の了承、実施結果は別々の状態です。この架空例は未送信・未調査・未実施であり、資料の版や希望日などの未確認は質問として残します。

今日の一歩は、追加要望一つを選び、元資料と並べて「追加する仕事」「残したい仕事」「未確認と質問先」を書くことです。その整理案を業務担当に見せ、希望の読み違いを確かめてから、開発窓口へつなぎましょう。