「その一言」が言えなかった月曜日の朝
月曜日の朝九時、後継社長の机には開発会社から届いた見積書のPDFが開かれていた。件名は「追加開発費用のご案内」。金額は当初の契約書には存在しなかった八十万円。画面をスクロールしながら、後継社長は先週の打ち合わせを思い出していた。現場から「この画面にも承認ボタンを付けてほしい」と言われ、その場で「じゃあお願いします」と開発会社の担当者に伝えた、あの瞬間だ。
先代が現役だった頃は、こうした話は先代と開発会社の社長同士が飲みの席で決めていたと聞いている。契約書もラフで、金額は「まあ今回はこれくらいで」という空気で決まっていたらしい。後継社長にはそんな関係性の蓄積がない。開発会社の担当者とは半年前に代替わりの挨拶で会っただけで、信頼関係もまだ薄い。だからこそ、現場の一言に安易に頷いてしまった自分を責めながら、同時に「これは本当に追加費用が発生する変更だったのか」という疑問も消えない。
総務担当者に聞くと、「先代の頃はこういう揉め事、聞いたことないですよ」と言われてしまった。古参社員からすれば、後継社長がITベンダーとの交渉で右往左往している姿は、経営者としての頼りなさに直結して見える。しかし後継社長の立場からすれば、そもそも「仕様変更」と「当初の契約範囲」の境界線が示されたことすらなく、判断材料がないまま「はい」と答えてしまっただけなのだ。
こういう場面で、後継社長の頭の中にはいくつもの矛盾した思いが同時に渦巻く。一つは、現場の要望にできるだけ早く応えたいという素直な気持ちだ。代替わりしてまだ日が浅い時期、現場から寄せられる小さな要望に真摯に応じることは、経営者として現場との距離を縮める貴重な機会だと感じている。もう一つは、金額の妥当性を判断する材料が自分にはないという不安だ。開発の工程やシステムの内部構造について専門知識を持たない後継社長にとって、「承認ボタン一つ」という言葉の印象と、実際にシステム内部で発生する作業量とのギャップを見抜くことは容易ではない。そして三つ目は、開発会社に対して細かい確認をすることで、まだ浅い信頼関係にひびが入るのではないかという遠慮だ。先代の代から続く取引先に対して、代替わりしたばかりの自分が「金額の根拠を教えてほしい」と切り出すことに、ある種の気後れを感じてしまう経営者は少なくない。
この三つの感情がせめぎ合った結果、多くの後継社長は「とにかく波風を立てずに済ませたい」という選択に流れやすい。目の前の請求書に多少の疑問を感じても、支払ってしまえば表面上は事態が収まる。しかしこの選択を繰り返していくと、仕様変更のたびに予算が膨らみ、いつの間にか年間のシステム関連費用が当初の想定を大きく超えているという事態に陥る。後継社長が本当に向き合うべきは、目の前の一件の請求書の金額そのものではなく、なぜこの状況が繰り返し発生するのかという構造の理解と、その構造に対応するための手順の整備である。こうした構造は、次に保守契約を更新するタイミングでも同じ形で表面化しやすい。保守契約を更新する前に、開発会社から受け取っておくべきものもあわせて確認しておくと、開発会社との関係全体を見直す機会になる。
この記事では、仕様変更を開発会社に伝えるときに追加費用でもめないための具体的な手順を、後継社長という立場に即して整理する。開発会社との関係がまだ浅い後継期だからこそ必要な準備と、現場・古参社員との関係構築を両立させる伝え方についても触れる。単なる交渉テクニックの紹介にとどまらず、なぜこの問題が後継期に特に起こりやすいのかという構造を理解することで、目の前のトラブル対応だけでなく、今後何年にもわたって開発会社と健全な関係を築いていくための土台を作ることを目指す。
なぜ仕様変更が「もめる火種」になりやすいのか
契約時点では「仕様」が完全に固まっていないという構造的事実
システム開発の契約は、要件定義書や仕様書をもとに金額と納期が決まる。ところが多くの中小企業のシステム開発では、契約時点の仕様書は「大枠」でしかなく、細部は開発が進む中で決まっていくことが実務上避けられない。これは開発会社が手抜きをしているわけではなく、ソフトウェア開発という営みそのものの性質による。要件を全て事前に言語化し尽くすことは、専門知識のない発注者側には極めて難しく、開発会社側も発注者の業務のすべてを把握しているわけではないため、実際に画面が動き出してから「ここはこうしたい」という要望が次々に出てくるのは自然な現象だ。
問題は、この「動き出してから出てくる要望」が、契約に含まれる範囲の話なのか、契約の外側にある新規の依頼なのかを、双方が同じ基準で判断できていないことにある。発注者側は「多少のお願い」程度の感覚で口頭で伝え、開発会社側は「契約範囲外の追加作業」として時間を計上している。この認識のズレが積み重なった結果として、月末や納品前になって「追加費用のご案内」という形で突然、金額が提示される。後継社長にとってはこれが「不意打ち」に感じられ、開発会社にとっては「当然の請求」に感じられる。この温度差こそが、仕様変更トラブルの根本構造である。
先代時代の「暗黙の了解」が後継期には機能しない
先代が長年同じ開発会社と付き合ってきた場合、そこには言語化されていない「相場観」が存在していることが多い。「この程度の変更なら無償対応、この規模になったら別途見積もり」というラインを、双方が経験の中で共有していたケースだ。これは正式な契約書には書かれていないが、長年の取引関係の中で形成された運用ルールとして機能してきた。
後継社長が引き継いだ直後は、この暗黙の了解が引き継がれない。開発会社の担当者が代替わりしていればなおさらで、先代時代の担当者が退職・異動していれば、その相場観自体が組織の記憶から失われている可能性もある。後継社長は「先代の頃はこうだったはず」という手がかりすら持てないまま、ゼロから関係を構築しなければならない。この構造を理解せずに「前はこうだったのに」と開発会社に主張しても、相手にとっては「知らない話」でしかなく、話がこじれる原因になる。
現場からの要望が「経由地」を経ずに開発会社へ届く経路の問題
もう一つの構造的な問題は、仕様変更の要望がどこから発生し、誰の判断を経て開発会社に伝わるか、という経路の設計が中小企業では曖昧なことが多い点だ。現場の担当者が使いにくさを感じ、開発会社の担当者と直接LINEやメールでやり取りをして「ここを直してほしい」と伝えてしまう。開発会社の担当者は「発注者側からの依頼」として受け取り、対応を進める。ところがこの依頼が経営判断としての承認を経ていないため、後継社長のもとに費用の請求が来た時点で初めて、変更の存在を知ることになる。
先代の時代は、先代自身が現場に近く、現場の声を即座に自分の判断でさばいていたため、この経路の乱れが表面化しにくかった。後継社長は現場との距離感がまだ定まっておらず、かつ経営判断のプロセスを整備しきれていないため、この「経由地を経ない要望」が特に発生しやすい時期にある。古参社員が長年の慣習で開発会社に直接連絡してしまうことも珍しくなく、これも後継社長の目の届かないところで仕様変更が発生する原因になる。
「口頭でのお願い」が証拠として残らないという実務上の弱点
仕様変更のトラブルの多くは、言った言わないの水掛け論に発展する。会議室での立ち話、電話、チャットの雑談スレッドなど、正式な議事録や発注書を経由しない形で仕様変更の依頼が行われると、後から「そんなことは言っていない」「言ったつもりだった」という対立が起きる。特に後継社長がまだ開発会社との関係構築期にある場合、相手に気を遣って「正式な書面でお願いするのも大げさかな」と考え、口頭でのやり取りに終始してしまうことがある。これが結果的に、追加費用の妥当性を検証する材料を自ら失うことにつながる。
費用感の見積もりロジックが発注者側に見えていない
開発会社が追加費用を算出する際の内部ロジック、つまり「工数×時間単価」という考え方は、多くの後継社長にとって馴染みが薄い。先代の時代は総額での取引が多く、時間単価という発想自体に触れる機会が少なかった経営者も多い。仕様変更の見積もりが「一律いくら」で提示されると、その金額が高いのか安いのか、妥当なのかを判断する軸を持てないまま、感覚的に「高い」と感じてしまう。この不透明感が、開発会社への不信感につながり、関係悪化の引き金になることもある。
さらに、この不透明感には二重の構造がある。一つは金額そのものの不透明感、もう一つは「なぜ今この作業が必要なのか」という必要性の不透明感だ。開発会社の立場からすれば、ある機能を安全に動かすためには、目に見える画面の変更だけでなく、データの整合性を保つための裏側の処理や、既存の機能に悪影響を与えないための確認作業が必要になることが多い。しかし発注者側にはこの裏側の作業が見えないため、「画面をちょっと変えるだけなのに、なぜこんなに時間がかかるのか」という疑問が生まれる。この疑問を解消する手段を持たないまま金額だけを提示されると、後継社長は判断を保留にしたまま合意せざるを得ない状況に置かれてしまう。
「一度動き出したプロジェクトは止められない」という心理的な縛り
もう一つ見落とされがちな要因として、開発が既に進行している状態では、後継社長が心理的に「今さら止められない」と感じてしまうことが挙げられる。仕様変更の依頼をしてしまった時点で、開発会社は既にその作業に着手している場合が多く、途中で「やめてほしい」と言い出すことは、相手の作業を無駄にしてしまうという申し訳なさを伴う。この心理が働くと、多少金額に疑問があっても「もう始まっているのだから仕方ない」という結論に流れやすくなる。開発会社側もこの心理を意図的に利用しているわけではないが、結果として「言い出しにくいタイミング」で請求が行われることが多く、後継社長の交渉力を弱める一因になっている。
以上の六つの構造的要因が組み合わさることで、後継社長は仕様変更のたびに「追加費用でもめる」というパターンに陥りやすくなる。これらの要因は互いに独立しているわけではなく、複合的に絡み合って発生することが多い。たとえば、暗黙の了解が引き継がれていない状態で、現場からの要望が経由地を経ずに直接開発会社へ届き、その内容が口頭のやり取りにとどまったまま作業が進行し、気づいたときには「今さら止められない」状態になっている、という一連の流れが典型的なパターンとして観察される。次章では、実際に起きたケースを見ながら、この構造がどのように具体的なトラブルとして表面化するかを確認する。
ケーススタディ
ケース1:承認ボタン一つが招いた八十万円の請求
食品加工業を営むB社は、社長交代を機に受注管理システムの改修を開発会社に依頼していた。後継社長は現場の生産管理担当者から「出荷指示の画面に、上長承認のボタンを付けてほしい」と相談を受け、会議の場で開発会社の担当者に「それくらいなら簡単ですよね、お願いします」と口頭で伝えた。担当者は「承知しました」と答え、そのまま作業を進めた。
ところが実際の実装では、承認ボタンを一つ追加するだけでは済まなかった。承認権限を持つユーザーの区分を新設し、承認待ち・承認済みのステータス管理をデータベースに追加し、承認されていない出荷指示が誤って処理されないようにする分岐処理を既存の複数の画面に組み込む必要があった。開発会社にとっては当然の作業範囲の拡大だったが、後継社長には「ボタンを一つ付けるだけ」という理解しかなかった。納品前になって提示された見積もりは八十万円。後継社長は「そんな大掛かりな話だとは思わなかった」と困惑し、開発会社側は「口頭で承諾いただいた内容を実装しただけです」と主張し、双方の認識が全く噛み合わなかった。
最終的には金額を半分程度に調整して収める形で落着したが、後継社長は「なぜこの金額になるのか」を理解できないまま支払いに合意することになり、開発会社への不信感だけが残った。この事例が示すのは、依頼した側の言葉のイメージと、実装される機能の実態には常にギャップがあり、口頭での即答が双方にとって危険だという事実である。
ケース2:古参社員が直接依頼してしまった経路の乱れ
金属加工業のC社では、先代の時代から製造管理システムの保守を同じ開発会社に依頼していた。後継社長が就任してからも、工場長を務める古参社員は先代の代から開発会社の担当エンジニアと直接の連絡先を持っており、現場で不便を感じるたびに直接メールで「ここを変えてほしい」と依頼していた。この慣習は先代の時代から続いており、古参社員にとっては当然の業務フローだった。
後継社長がこの実態を知ったのは、四半期末に開発会社から届いた請求書に、自分が把握していない複数の改修項目が計上されていたときだった。工場長に確認すると「前からこうしてましたよ、社長も知ってると思ってました」という返答で、悪意はまったくなかった。しかし経営者として費用管理の観点から見れば、承認プロセスを経ない依頼が積み重なり、想定外の支出が発生していた状態であり、看過できない問題だった。
後継社長はこの一件を機に、古参社員を非難するのではなく、開発会社への依頼は必ず後継社長か指定の窓口担当者を経由するというルールを工場長本人と一緒に作り直した。古参社員のこれまでの動き方を否定せず、「これからは会社としてきちんと管理したいので、一緒にルールを作ってほしい」という姿勢で臨んだことで、古参社員も反発せずに協力的に応じてくれたという。この事例は、経路の乱れそのものよりも、それを正す際の伝え方が現場との関係構築において重要であることを示している。
ケース3:見積もりの内訳を求めたら関係が好転した
印刷業を営むD社の後継社長は、先代の代から取引のある開発会社とまだ距離感を測れずにいた。ある仕様変更の依頼に対して開発会社から提示された見積もりは、金額だけが記された一枚のシンプルな書面だった。後継社長は金額の妥当性を判断できず、しかし関係悪化を恐れて聞き返すこともできず、そのまま合意しかけていた。
そこで後継社長は、思い切って「今後のためにも、どのような作業にどれくらいの時間がかかっているのか、内訳を教えていただけますか」と担当者に尋ねた。開発会社側は快く応じ、画面設計の見直しに何時間、データベースの改修に何時間、テストに何時間、という具体的な工数の内訳を提示してくれた。後継社長はこれを見て、当初想像していたよりも作業範囲が広いことを理解し、逆にどの部分を簡略化すれば費用を抑えられるかを開発会社と一緒に検討することができた。
この経験を経て、後継社長と開発会社の担当者の間には「内訳を共有しながら一緒に判断する」という新しい関係のパターンが生まれた。開発会社の担当者も「先代の頃はこちらから細かく説明する機会がなかったので、今のほうがお互いに納得感がある」と話しているという。この事例は、費用の内訳を尋ねることが対立の火種になるのではなく、むしろ信頼関係を構築するきっかけになり得ることを示している。
ケース4:小さな変更の積み重ねが半年で予算を圧迫した
運送業を営むE社の後継社長は、配車管理システムの改修を年間の保守契約とは別枠で開発会社に依頼していた。就任から半年の間、現場からは「この項目も表示してほしい」「この並び順を変えてほしい」といった小さな要望が月に一度ほどのペースで寄せられ、後継社長はそのたびに「大した金額にはならないだろう」と考えて個別に開発会社へ依頼していた。一件あたりの見積もりは五万円から十五万円程度で、単発で見ればさほど大きな金額には見えなかった。
ところが半年が経過し、経理担当者から「システム関連の費用が年間予算を大きく超えそうです」と指摘され、後継社長は初めて半年間の請求書を並べて確認した。合計すると九件の小規模な仕様変更で百二十万円近い費用が発生しており、当初想定していた年間のシステム予算の大半を、この時点で使い切っていた。個々の依頼は確かに小さく、金額としても妥当な範囲に見えたが、それを月次で管理する仕組みがなかったために、積算した金額の大きさに気づくのが遅れてしまったのだ。
後継社長はこの経験を踏まえ、以後は仕様変更の依頼が発生するたびに、金額と件数を一覧にした簡単な表に記録し、月末に合計額を確認する運用に切り替えた。また、年度の予算を組む際にも「仕様変更用の予備費」という枠をあらかじめ確保しておくことで、突発的な支出に慌てずに対応できる体制を整えた。この事例は、一件ごとの金額が小さくても、管理の仕組みがなければ気づかないうちに予算全体を圧迫してしまうという、積み重ね型のトラブルのパターンを示している。
仕様変更を伝える前後の実務対応ステップ
ここからは、仕様変更を開発会社に伝える際に追加費用でもめないための具体的な手順を、時系列に沿って整理する。それぞれの項目には、なぜその手順が必要なのかという説明を添える。
ステップ1:現場からの要望を受けた時点で即答しない
現場の担当者や古参社員から「この機能を追加してほしい」という要望を受けたとき、その場で「わかりました、お願いします」と即答することは避ける。即答してしまうと、その内容が正式な依頼として開発会社に伝わり、契約範囲の外側にある追加作業として処理されてしまうリスクがある。まずは「検討して開発会社に確認します」という返答に留め、社内で内容を整理する時間を確保する。現場からの信頼を損なわないためには、「すぐに動かないこと」への理解を得ることも大切で、「きちんと確認してから進めたいので少し時間をください」と丁寧に伝えることが有効だ。
このとき重要なのは、即答を避けることと、要望を軽視することを混同しないという点だ。要望を受けた場の空気の中では、後継社長自身も「せっかく相談してくれたのだから、すぐに応じてあげたい」という気持ちになりやすい。しかしその場の空気に任せて即答すれば、後から金額の面で板挟みになった際に、現場に対して「言った通りに進めてもらえなかった」という印象を与えてしまい、結果的にはより大きな不信感を招くことになる。「検討してから正式に回答する」という一手間を、現場に対する誠実な対応として位置づけ、社内でもその考え方を共有しておくと、現場の理解も得やすくなる。こうした要望の受け止め方を社内でどこまで主導し、どこから開発会社側に判断を委ねるかは、刷新を社内主導で進めるか外注に任せきりにするかの決め方とも関わってくるテーマだ。
ステップ2:要望の内容を文書化し、目的と背景を明確にする
現場からの要望を、口頭のニュアンスのまま開発会社に伝えるのではなく、簡単なメモでも構わないので文書に落とし込む。「誰が」「どの画面で」「どういう場面で困っていて」「どうなれば解決するのか」を整理することで、開発会社に伝える際の解釈のズレを減らせる。この段階で目的が明確になれば、実は既存の機能で対応できる、あるいは別のもっと簡単な方法で解決できる、ということが判明することもある。仕様変更という結論に飛びつく前に、課題の本質を見極める工程として重要だ。
文書化の際には、現場の担当者自身に「なぜその機能が欲しいのか」を改めて聞き直すことも有効だ。多くの場合、現場の担当者は解決策の形で要望を伝えてくる。「承認ボタンを付けてほしい」という要望の背景には、「誤った出荷指示が現場に流れてしまうのを防ぎたい」という本来の目的が隠れている。この本来の目的まで遡って整理すると、承認ボタンの追加以外にも、通知の仕組みを変える、確認の手順を追加するなど、複数の解決策の選択肢が見えてくることがある。目的と解決策を分けて記録しておくことは、開発会社との相談の際にも「どの解決策が最も費用対効果が高いか」を一緒に検討する土台になる。
ステップ3:契約書・仕様書を確認し、契約範囲内か外かを仮判定する
要望を整理したら、契約時の仕様書や要件定義書を確認し、その変更が契約範囲に含まれているのか、範囲外の追加依頼になるのかを、自分なりに仮判定してみる。仕様書が手元にない、あるいは内容が古くて実態と合っていない場合は、この時点で開発会社に「現在の契約範囲を確認したい」と問い合わせても構わない。ここで重要なのは、範囲内か範囲外かの最終判断を発注者側だけで決めつけず、あくまで「仮の判断」として持っておくことだ。この仮判定があるだけで、開発会社との会話が「教えてもらう」立場から「一緒に確認する」立場に変わり、対等な交渉がしやすくなる。
後継社長にとって、先代の代の契約書や仕様書を初めて読み込むこと自体が大きな一歩になる。多くの場合、これらの書類は先代の引き出しやファイルサーバーの奥に眠っていて、代替わりのタイミングでも目を通されていないことが多い。この機会に一度通読しておくことで、契約の全体像や保守の範囲、追加費用が発生する条件など、経営を引き継ぐ上で本来知っておくべき情報を自分の知識として取り込むことができる。仮判定の作業は仕様変更対応の一部でありながら、後継社長が会社の契約関係を自分の言葉で説明できるようになるための学習の機会でもある。このとき、契約の形態が準委任契約なのか請負なのかによっても、仕様変更に対する開発会社側の責任の考え方が変わってくる点も併せて確認しておくとよい。
ステップ4:見積もりを依頼する際は必ず書面で、内訳を求める
仕様変更を開発会社に伝える際は、口頭でのやり取りだけで終わらせず、メールやチャットなど記録の残る形で正式に依頼する。そのうえで、金額だけの見積もりではなく、作業内容と工数の内訳を含めた見積書を求める。内訳がないまま合意すると、後から「なぜこの金額なのか」を検証する材料がなく、費用が妥当かどうかの判断ができない。内訳を求めることは開発会社にとって失礼な行為ではなく、むしろ双方の認識を揃えるための標準的な実務であることを理解しておく。
依頼の文面には、ステップ2で整理した目的と背景も併せて記載しておくと、開発会社側も過剰な作業範囲を見積もりに含めてしまうリスクを避けやすくなる。たとえば「承認ボタンを追加してほしい」という表現だけでなく、「誤った出荷指示が現場に流れることを防ぎたいため、承認の仕組みを追加したい」という目的まで伝えることで、開発会社側も目的に対して最も費用対効果の高い実装方法を提案しやすくなる。見積もり依頼のメールには、いつまでに回答が欲しいかという期限も明記しておくと、やり取りが長引いて現場を待たせてしまう事態を防げる。
見積もりの説明を受ける際に専門用語が多く理解できない場合は、遠慮せずにその都度「これはどういう意味ですか」と質問して構わない。開発会社の担当者は、発注者が専門知識を持たないことを前提に説明する経験を積んでいることが多く、丁寧に噛み砕いて説明してくれることがほとんどだ。理解できないまま話を進めてしまうと、後になって「実はよくわかっていなかった」という状態で合意したことになり、双方にとって望ましくない。わからないことをその場で確認する姿勢は、無知を露呈することではなく、正確な合意形成のために必要な行動だと捉えておきたい。可能であれば、社内に多少ITに詳しい担当者がいる場合は同席してもらい、二人体制で説明を受けると、聞き漏らしや理解の齟齬を減らすことができる。
ステップ5:見積もりが出たら、必ず社内で一度持ち帰って検討する
開発会社から見積もりが提示されたら、その場で即決せず、一度社内に持ち帰って検討する時間を設ける。特に金額が大きい場合や、当初の予算感から外れている場合は、なぜその金額になるのかを社内でも整理し、必要であれば古参社員や現場の担当者にも「この機能を実現するにはこれくらいの費用がかかるが、本当に必要か」を確認する。この一手間が、後から「そんな高い金額だとは思わなかった」という後悔を防ぐ。
社内で検討する際は、金額の大小だけでなく「この機能がないことで、現在どれくらいの業務上の支障が出ているか」という観点も合わせて評価すると判断がしやすくなる。たとえば、承認漏れによる出荷ミスが月に一度発生し、その手直しに毎回数時間の作業が発生しているのであれば、一定の費用をかけて仕組みを整えることの合理性は高いと判断できる。逆に、発生頻度が低く、手作業での対応でも十分にカバーできる範囲であれば、優先度を下げて次年度に見送るという判断もあり得る。このように、費用と業務上の効果を並べて検討する習慣をつけておくと、開発会社から見積もりが来るたびに感覚的な良し悪しで判断するのではなく、根拠のある意思決定ができるようになる。
ステップ6:金額に疑問がある場合は、範囲を絞る代替案を提示する
見積もり金額に納得できない場合、いきなり「高い」と主張するのではなく、「この部分は簡略化できないか」「優先度の低い機能を後回しにできないか」という代替案を提示する。開発会社側も、発注者が予算の制約を理由に一方的に値下げを要求するよりも、機能の範囲を一緒に調整する姿勢を見せてくれる方が、協力的に対応しやすい。仕様変更の交渉は金額の交渉ではなく、実現する機能の範囲の交渉であるという意識を持つことが、関係を悪化させずに費用を調整するコツになる。
代替案を考える際は、機能を「必須」「あれば望ましい」「後回しでよい」の三段階に分けて整理すると、開発会社との相談がスムーズになる。すべての要望を一括りにして「高いから減らしてほしい」と伝えるのではなく、「この部分は今回必ず実現したいが、この部分は次のタイミングで良い」と具体的に切り分けて伝えることで、開発会社も見積もりを組み直しやすくなる。段階的にリリースする方法を取ることで、初期費用を抑えながら、実際に使ってみた上で本当に必要な機能を見極めるという進め方も選択肢の一つになる。
ステップ7:合意した内容は必ず発注書・変更契約書として残す
金額と作業範囲について合意ができたら、口頭やメールのやり取りだけで終わらせず、簡単な発注書や変更契約書の形で正式に記録する。これは開発会社を疑っているからではなく、双方の記憶や認識が時間の経過とともにずれていくことを防ぐための、ごく標準的な実務対応である。特に後継社長のように開発会社との関係構築の途中にある場合、書面を残す習慣を早い段階でつけておくことが、将来的なトラブルの予防につながる。
書面に残す項目としては、変更の目的、対象範囲、金額、納期、そして「この変更に含まれない作業は何か」という除外事項まで明記しておくと、後々の解釈のズレを防ぎやすい。除外事項をあえて書いておくのは、発注者側が「せっかく手を入れるのだから、これもついでにお願いできないか」と後から追加を頼みがちだからだ。範囲を明確にしておくことで、追加の依頼が発生した際にも、それが最初の合意に含まれていたのか、新たな依頼なのかを双方が同じ基準で判断できるようになる。なお、この合意内容が納品後にどう扱われるかは検収の基準とも密接に関わる。検収の合格基準そのものを曖昧にしたまま仕様変更だけを重ねていくと、最終的に「何をもって完成とするか」の判断がさらに難しくなるため、納品物は何をもって「完成」とするか、検収の基準を決めるも合わせて確認しておきたい。
ステップ8:仕様変更の履歴を社内で一元管理する
一つ一つの仕様変更が小さくても、積み重なると当初のシステムの姿から大きくかけ離れていくことがある。いつ、どのような変更を、どのような理由で行い、いくらの費用がかかったのかを一覧で管理する簡単な台帳を社内に用意しておく。この台帳があることで、次に似たような要望が出たときに過去の判断を参照でき、また古参社員や後任の担当者に経緯を説明する際にも役立つ。先代の時代の暗黙の了解が引き継がれていない後継期だからこそ、こうした記録を自分の代から作り始めることが重要になる。
台帳の形式は表計算ソフトの簡単な一覧で十分であり、特別なシステムを新たに導入する必要はない。記録する項目としては、依頼日、依頼者、変更内容の概要、目的、見積金額、合意した金額、対応完了日を並べておくと、後から金額の傾向や依頼の頻度を振り返る際に役立つ。半年や一年に一度、この台帳全体を見返す時間を作ることで、どの部署からの要望が多いのか、どの時期に費用が集中しやすいのかといった傾向も見えてくる。この傾向を把握しておくことは、次年度の予算編成や、開発会社との保守契約の見直しの際にも有効な材料になる。
ステップ9:定期的に開発会社と「今後の見込み」を共有する会議を持つ
仕様変更のたびに個別に対応するだけでなく、四半期に一度程度、開発会社と「今後どのような改修の予定があるか」「予算感としてどれくらいを見込んでおくべきか」を話し合う場を設ける。これにより、突発的な追加費用の請求という形での「不意打ち」を減らし、経営計画の中にシステム関連の費用をあらかじめ組み込めるようになる。この場は費用交渉の場というより、事業の方向性を共有し合う場として位置づけることで、開発会社との関係を単なる発注者と受注者ではなく、事業のパートナーとして育てていくことにもつながる。
この定期的な会議には、可能であれば現場の担当者や古参社員にも同席してもらうことを検討したい。経営者と開発会社だけで方向性を決めてしまうと、現場が「自分たちの声が届いていない」と感じてしまうことがある。現場の担当者が直接、日々の困りごとや将来的に欲しい機能のイメージを開発会社に伝えられる場を設けることで、要望が非公式な経路で発生することを未然に防ぐ効果も期待できる。後継社長はこの会議の場を、現場の声を正式なルートに乗せるための仕組みとして活用することができる。
チェックリスト:仕様変更を伝える前に確認すべき項目
現場から要望を受けたときに、以下の項目を確認する習慣をつけておくと、追加費用のトラブルを大きく減らせる。まず、要望の背景と目的を本人に確認したか。次に、その場で即答せず社内検討の時間を確保したか。契約書や仕様書を確認し、契約範囲内か外かを仮判定したか。開発会社への依頼を書面で行ったか。見積もりに作業内容と工数の内訳が含まれているか。見積もりを社内で一度持ち帰って検討したか。金額に疑問がある場合に代替案を検討したか。合意内容を発注書や変更契約書として残したか。仕様変更の履歴を社内の台帳で管理しているか。これらの項目を一つずつ確認することが、感覚的な判断から、根拠に基づいた判断への転換を促す。
このチェックリストは、慣れないうちは一件ごとに時間がかかると感じるかもしれない。しかし運用を重ねるうちに、多くの項目は数分で確認できる定型的な作業に変わっていく。特に契約範囲の仮判定や台帳への記録は、一度フォーマットを作ってしまえば以降は同じ形式を使い続けるだけで済む。最初の数件だけ丁寧に手順を踏むことを意識し、社内の担当者にも同じ手順を共有しておくことで、後継社長が不在のときや多忙なときでも、一定の基準で仕様変更の依頼を処理できる体制が整っていく。この体制づくりこそが、後継期における社内のガバナンス強化の一環として捉えるべき取り組みである。
よくある失敗パターン
失敗パターン1:現場への配慮から即答してしまう
後継社長が最も陥りやすい失敗は、現場や古参社員との関係を大切にしたいという思いから、要望をその場で即答してしまうことだ。代替わり直後は特に、現場から「頼りない」「先代とは違う」と思われることへの不安が強く、少しでも早く現場の期待に応えたいという心理が働く。しかしこの即答が、仕様変更の範囲や費用について検討する機会を自ら放棄することにつながり、後から想定外の請求に驚くという結果を招く。現場への配慮と、経営判断としての慎重さは両立できる。「すぐに対応したい気持ちはあるが、きちんと確認してから進めたい」という姿勢を丁寧に説明すれば、現場もむしろ後継社長への信頼を深めることが多い。即答しないことは冷たい対応ではなく、責任ある経営者としての振る舞いであるという理解を、自分自身の中で持っておくことが重要だ。
失敗パターン2:開発会社を疑っている前提で交渉に臨んでしまう
見積もりの内訳を求めたり、金額に疑問を持ったりすることは正当な実務対応だが、その伝え方次第で開発会社との関係を損なうことがある。特に後継社長が「先代の時代よりも厳しくチェックしなければ」という意識を強く持ちすぎると、疑いの姿勢が言葉や態度に出てしまい、開発会社側が「信頼されていない」と受け取ってしまうことがある。開発会社との関係は本来、対立するものではなく、事業を一緒に前に進めるパートナーである。内訳の確認や代替案の提示は、あくまで双方が納得できる形を探すための対話であり、相手を疑うための取り調べではないという姿勢を、言葉の選び方からも意識する必要がある。「確認させてください」「教えてください」という言い回しを基本にするだけで、対立的な印象を大きく減らすことができる。
失敗パターン3:トラブルの後に対応ルールを整備せず、同じことを繰り返す
一度追加費用のトラブルが起きても、その場をなんとか収めることだけに集中し、再発防止のための仕組みを作らずに終わってしまうケースが非常に多い。目の前の請求書への対応や、開発会社との金額交渉に気を取られ、「なぜこのトラブルが起きたのか」という構造的な原因の分析まで手が回らないことが背景にある。しかし前述のとおり、仕様変更のトラブルには共通した構造的な原因があり、その原因を放置すれば同じパターンのトラブルが必ず繰り返される。一度トラブルが起きたときこそ、依頼の経路を見直し、社内の承認プロセスを整備し、開発会社との書面でのやり取りを習慣化する好機だと捉えることが重要だ。痛みを伴う経験を、仕組みづくりのきっかけに変えられるかどうかが、後継社長としての成長を左右する分岐点になる。
失敗パターン4:小さな変更を軽視し、積算管理を怠る
一件一件の仕様変更の金額が小さいと、後継社長はそれを個別の判断事項としてしか扱わず、月単位や年単位で積算して管理する視点を持たないことがある。前述のケーススタディで紹介した運送業のE社のように、一件五万円から十五万円程度の依頼であっても、これが月一度のペースで半年続けば百万円を超える金額になる。個々の依頼が小さいために「これくらいなら問題ないだろう」と気軽に承認してしまい、気づいた頃には年間予算の大半を使い切っているという事態が起こりやすい。この失敗を避けるためには、金額の大小にかかわらず、すべての仕様変更を一つの台帳やリストに記録し、月末や四半期末に合計額を確認する習慣を持つことが欠かせない。小さな支出の管理を怠ることは、大きな支出の管理を怠ることと同じくらいの経営リスクを持つという認識を持っておきたい。
よくある質問
現場からの要望を一度断ると、関係が悪くなりませんか
要望そのものを断るのではなく、「その場で即答すること」を避けるだけであれば、関係が悪化することは基本的にない。現場が求めているのは多くの場合、要望が実現されることそのものよりも、自分の困りごとに向き合ってもらえたという実感である。「検討します、来週までに開発会社に確認して回答します」と期限を示して丁寧に返答すれば、現場は待つことに納得しやすい。むしろ確認もせずに即答し、後から「やっぱりできません」「費用が高すぎるので見送ります」と覆すほうが、現場の信頼を損ないやすい。
開発会社に内訳を求めると、失礼にあたりませんか
内訳を求めることは、実務として一般的であり失礼にはあたらない。むしろ内訳を提示できない、あるいは提示を渋る開発会社であれば、その姿勢自体を今後の取引の参考にすべきだ。多くの開発会社は、発注者が費用の内容を理解し納得した上で契約を進めることを望んでおり、内訳の説明を求められることを歓迎する。伝え方としては「金額の妥当性を判断したいわけではなく、社内で説明する際に必要なので教えてほしい」という言い方をすると、相手も気持ちよく応じやすい。
先代の時代の契約書が古くて、今の実態と合っていない場合はどうすればよいですか
契約書や仕様書が実態と大きくずれている場合は、まずその事実を開発会社に伝え、現状の運用に合わせて仕様書や契約内容を整理し直すことを提案する。これは後継社長の代でしかできない仕事であり、先代の時代の曖昧な取り決めを、書面として明確な形に整えるチャンスでもある。開発会社にとっても、古い仕様書のまま運用を続けることは双方にとってリスクであり、整理し直す提案は歓迎されることが多い。この機会に、保守契約の範囲や追加費用が発生する基準についても、明文化しておくことを検討したい。
古参社員が開発会社に直接連絡してしまう慣習を、どう改めればよいですか
古参社員のこれまでの動き方を否定せず、「会社としてきちんと管理したいので、一緒にルールを作ってほしい」という姿勢で対話することが有効だ。一方的に「今後は禁止する」と伝えると、長年の慣習を否定されたと感じ、反発や不満を招きやすい。古参社員自身も業務上の必要性から直接連絡していたケースが多いため、その必要性を認めつつ、経由すべき窓口や承認の手順を一緒に設計する形を取ると、協力を得やすい。ルールができた後は、古参社員が新しい手順を守ってくれていることに対して、きちんと感謝や労いの言葉を伝えることも、関係維持のうえで欠かせない。
まとめ
仕様変更をめぐる追加費用のトラブルは、開発会社の請求が不当だから起きるのではなく、契約時点で仕様が完全に固まらないという開発の性質、先代時代の暗黙の了解が引き継がれない後継期特有の事情、現場からの要望が正式な承認を経ずに開発会社へ届いてしまう経路の乱れ、口頭でのやり取りが証拠として残らない実務上の弱さ、そして費用感の見積もりロジックが発注者側に見えていない不透明感という、複数の構造的な要因が積み重なって発生する。
後継社長がこの構造を理解し、現場からの要望をその場で即答せず、内容を文書化し、契約範囲を確認し、書面で見積もりと内訳を求め、社内で検討する時間を確保し、合意内容を正式な書面として残すという一連の手順を実践すれば、追加費用をめぐる衝突の多くは事前に防ぐことができる。同時に、古参社員や現場の担当者との関係については、ルールを一方的に押し付けるのではなく、これまでの慣習を尊重しながら一緒に新しい仕組みを作る姿勢を持つことが、後継社長としての信頼を積み上げていく上で欠かせない。
仕様変更の交渉は、開発会社との対立の場ではなく、事業を一緒に前に進めるための対話の場である。この記事で紹介した手順とチェックリストを、まずは次に現場から要望が出た瞬間から実践してみてほしい。一つ一つの小さな積み重ねが、先代から引き継いだ会社を、自分の代でより強固な基盤に育てていく力になる。
後継社長がこうした手順を整えることは、開発会社との関係だけにとどまらず、社内での立場の確立にもつながる。現場や古参社員は、後継社長が困りごとに丁寧に向き合い、かつ経営として筋の通った判断をしている姿を見ることで、少しずつ信頼を積み重ねていく。先代の時代のやり方をそのまま真似ることはできなくても、先代が長年かけて築いた信頼関係と同じ役割を、自分なりの手順と誠実な対話によって新しく築き直すことは十分に可能だ。仕様変更のたびに繰り返されるやり取りは、一見すると煩雑な事務作業に見えるかもしれないが、実際には後継社長としての経営姿勢そのものを、現場と開発会社の双方に示していく積み重ねなのである。
