「これくらい、ついでにお願いできますか」で始まる小さな悩み
月曜の朝、先代から会社を引き継いで三年目になる後継社長は、営業から上がってきた一通のメールを見て手が止まった。「見積書のフォーマットを、案件ごとに割引率を自動計算できるようにしてほしい。あと、担当者ごとの進捗が一覧で見られるようにできたら助かります」。要望自体はシンプルだ。だが、これを誰に、どう頼めばいいのかが分からない。
先代の時代は、パソコンに詳しい古参社員が独自にExcelマクロを組んで、なんとなく現場を回してきた。その古参社員も定年間近で、後継社長は今の業務システムがどういう仕組みで動いているのか、正直よく分かっていない。開発会社に連絡すべきなのか、それともいつも来てくれるITベンダーの担当者に電話一本でいいのか。見積もりを頼んだら、また前のように「一式300万円、要件定義から半年」という大掛かりな話にされてしまうのではないか。そんな不安が先に立って、結局「担当者ごとの進捗一覧」の話は後回しになり、営業は今日もExcelを手作業でコピーして進捗表を作っている。
これは決して珍しい光景ではない。事業承継を経た会社では、システムに対する「頼み方」の作法が世代交代のタイミングで途切れてしまう。そもそも小さな不具合や改修を自分で直すか、開発会社に投げるかという判断自体に迷う場合は、承継1年目、システムの不具合は自分で直すか開発会社に投げるかも参考にしてほしい。先代が長年の付き合いで築いた開発会社との関係、口頭で済ませていた発注の慣習、値段交渉の勘所——これらは引き継ぎ資料に書かれていないことが多く、後継社長は手探りで再構築するしかない。
さらに厄介なのは、この「頼み方が分からない」という悩みを、後継社長がなかなか周囲に相談できないという点だ。取引先との交渉や資金繰り、人事の問題であれば、商工会や税理士、経営者仲間に相談する場が既にある。しかし「Excelの進捗表を自動化したい」といった小さなIT改修の相談先は、意外と見当たらない。経営コンサルタントに聞く規模の話でもないし、システムに詳しい知人がいなければ、誰にも聞けないまま先延ばしにされる。そうして小さな非効率が現場に溜まり続け、気づけば従業員が毎日30分かけて手作業で行っている集計作業が、実は数万円の改修で自動化できたはずだった、ということが積み重なっていく。
本稿では、こうした「小さな追加開発」を安く早く、かつ後々こじれないように依頼するための実務的な考え方と手順を、具体的なケースとチェックリストを交えて解説する。技術的な専門知識は一切不要で、必要なのは発注者としての「作法」を知ることだけだ。この作法は一度身につければ、開発会社が変わっても、依頼する内容が変わっても、繰り返し使える普遍的な型になる。
なぜ「小さな追加開発」ほど頼み方が難しいのか
大きなシステム開発、たとえば基幹システムの入れ替えや新規サービスの立ち上げであれば、後継社長も「これは重大な意思決定だ」と身構えて、複数の会社から見積もりを取り、契約書を読み込み、社内の合意形成に時間をかけるだろう。ところが「見積書のフォーマットを直したい」「あの機能にボタンを一つ増やしたい」といった小さな改修は、逆に頼み方が難しい。その理由は構造的に整理すると、大きく五つに分けられる。
理由その一 見積もりの「最低ライン」が発注側に見えない
開発会社にとって、どんなに小さな改修依頼でも、ゼロコストで対応できるわけではない。要望を正確に理解するための打ち合わせ、既存システムのコードを読み直す時間、修正後の動作確認、リリース作業——これらは案件の規模にかかわらず一定の固定コストとして発生する。仮に実際の改修作業が1時間で終わる内容だったとしても、打ち合わせや確認作業を含めれば実質的な稼働は5時間、10時間になることも珍しくない。
後継社長からすれば「ボタンを一つ増やすだけなのに、なぜこんなに時間もお金もかかるのか」という疑問が湧く。しかし開発会社の立場から見ると、その「ボタン一つ」の裏には、既存の画面デザインとの整合性確認、他の機能への影響調査、テスト、リリース後の不具合対応まで含まれている。この見積もりの「最低ライン」の存在を発注側が理解していないと、価格交渉が噛み合わず、「高い」「いや、これくらいはかかる」という水掛け論になりがちだ。
理由その二 先代時代の「暗黙の相場観」が引き継がれていない
先代社長は、長年同じ開発会社やITベンダーと付き合いを重ねる中で、「このくらいの改修ならだいたいこの金額」という相場観を体感的に持っていた。値段交渉の際も、過去の実績を踏まえて「前回のあの改修が5万円だったから、今回はこのくらいだろう」という基準を持てていた。
後継社長にはこの相場観がない。先代からの引き継ぎ資料に「システム改修の相場」まで書かれていることはまずないし、口頭での引き継ぎでも業務の流れは説明されても、発注実務の勘所までは伝わらないことが多い。相場観がないまま見積もりを受け取ると、それが高いのか安いのか、妥当なのか判断できず、結果として「言われた通りに払う」か「なんとなく渋る」かの二択になってしまう。これは開発会社との関係においても不健全で、対等な交渉ができない発注者は、良いパートナーシップを築きにくい。
理由その三 要望の伝え方が「業務言語」のままで「開発言語」に翻訳されていない
現場の従業員や後継社長自身が持っている要望は、多くの場合「業務の言葉」で表現される。「担当者ごとの進捗が一覧で見られるようにしてほしい」という要望は、業務としては明確でも、開発の視点では曖昧さが多く残っている。進捗とは何を指すのか。受注から納品までのステータスなのか、それとも作業工程の完了率なのか。一覧はどの画面に表示するのか、既存のどの画面の延長として作るのか、それとも新規画面なのか。誰が見る想定で、更新頻度はどれくらいか。
この「業務言語」と「開発言語」のギャップが埋まらないまま見積もり依頼を出すと、開発会社側は多めに見積もらざるを得なくなる。なぜなら、要件が曖昧なままだと、後から「思っていたのと違う」と言われるリスクを開発会社側が負うことになり、そのリスク分を見積もりに含めるからだ。逆に、要望を具体的に、開発会社が動きやすい形に翻訳して伝えられれば、見積もりの精度は上がり、結果として金額も下がりやすくなる。
理由その四 発注ルートが定まっておらず、都度「探す」コストがかかっている
先代の時代からの付き合いで開発会社やITベンダーが複数存在している場合、後継社長は「この改修はどの会社に頼むべきか」を都度判断しなければならない。この窓口の整理は、運用フェーズの体制。承継後の社内と開発会社の役割分担で扱った役割分担とも密接に関わる。基幹システムを作った会社、ホームページを作った会社、業務用のツールを作った会社がそれぞれ別で、しかも古参社員しか各社の担当者を知らない、というケースは事業承継後の会社によく見られる。
発注ルートが定まっていないと、小さな改修一つのために「誰に聞けばいいか」を探すところから始まり、これだけで数日のロスが生まれる。さらに、複数の開発会社に相談すること自体が心理的なハードルになり、結局「今回は諦めて手作業で対応する」という選択に流れやすい。これが積み重なると、システムは更新されないまま古びていき、現場の非効率な手作業だけが増えていくという悪循環に陥る。
このような状態は、実際にシステムを図で整理してみると発覚しやすい。どの業務がどのシステムで動いていて、それぞれの窓口が誰なのかを、後継社長自身が一枚の紙に書き出してみると、思いのほか複雑な依存関係になっていることに驚くことが多い。この整理作業自体は開発会社に依頼するものではなく、後継社長が自分の頭を整理するために行うものだが、これをやっておくだけで、次に何か改修したいときに「まずどこに聞けばいいか」で悩む時間がなくなる。
理由その五 「古参社員」というインターフェースの喪失
先代の時代、システムに関する要望は多くの場合、パソコンに詳しい古参社員が窓口となり、現場の声を「開発会社にわかる言葉」に翻訳し、開発会社からの説明を「現場にわかる言葉」に翻訳し直すという、いわば通訳の役割を担ってきた。この古参社員が退職・引退すると、後継社長は現場と開発会社の間に立つ通訳を自分で担わなければならなくなる。
しかし後継社長自身がITに詳しいわけではない場合、この通訳作業自体が大きな負担になる。現場からの要望を正確に理解し、それを開発会社に伝わる形に整理し、見積もりの妥当性を判断し、開発会社からの提案を現場にわかりやすく説明する——これらすべてを一人でこなすのは容易ではない。結果として、システムに関する意思決定そのものが停滞し、小さな改修依頼が滞留していく。
この「通訳機能の喪失」は、単に業務上の不便さにとどまらず、古参社員と現場従業員、そして後継社長との間の関係性にも微妙な影響を与える。古参社員が存命中は、現場の従業員は「あの人に言えばシステムのことは何とかしてくれる」という安心感を持っていた。その安心感が失われると、従業員は「言っても無駄だろう」という諦めの感情を抱きやすくなり、本来であれば改善提案として上がってくるはずの声が、そもそも上がってこなくなる。後継社長が意識してこの機能を再構築しないと、現場の改善意欲そのものが目減りしてしまうリスクがある点も見過ごせない。
以上の五つの構造的な要因が絡み合うことで、「小さな追加開発」は実際の作業量以上に、発注する側にとって心理的・実務的なハードルの高い行為になってしまう。
さらに、これら五つの要因は互いに独立しているのではなく、悪循環として連動している点にも注意が必要だ。相場観がない（理由その二）ために見積もりの妥当性を判断できず、判断できないから要望を具体的に翻訳する努力（理由その三）を後回しにし、翻訳が甘いまま依頼を出すから見積もりが高くなり(理由その一)、高い見積もりに驚いて依頼そのものを躊躇するようになり、躊躇が続くうちに発注ルート（理由その四）を維持する機会も減り、結果として古参社員が担っていた通訳機能（理由その五）の代替を作る余裕もなくなっていく。この悪循環に一度入ると、システムへの追加投資そのものが「怖いもの」「面倒なもの」として避けられるようになり、現場の非効率がそのまま固定化されてしまう。
逆に言えば、この悪循環のどこか一箇所に楔を打ち込めば、循環全体を良い方向に反転させることができる。本稿が提案する手順は、特に「理由その三(要望の翻訳)」と「理由その二(相場観の欠如)」の二箇所に働きかけることで、悪循環を好循環に転換することを狙っている。要望を具体的に翻訳できれば見積もりの精度が上がり、見積もりの内訳を毎回確認する習慣がつけば相場観が育ち、相場観が育てば次の依頼への心理的ハードルが下がる。この好循環を回し始めることが、本稿全体を通じての狙いである。
次の章では、実際にどのような場面でこの問題が表面化するのか、具体的なケースを見ていく。
ケーススタディで見る「頼み方」の落とし穴
ケース一 見積もりの前提が伝わらず、想定外の高額提示に驚いた印刷会社の事例
創業45年の印刷会社を継いだ二代目社長は、受注管理システムに「得意先ごとの過去の発注履歴をワンクリックで見られるようにしてほしい」という改修を依頼した。先代の時代からシステムを構築している開発会社に電話で相談し、「履歴を見られるようにしてほしい」とだけ伝えたところ、後日届いた見積もりは80万円。想定していた金額の何倍もの提示に、社長は「ぼったくられているのではないか」と疑念を抱いた。
しかし実際に開発会社の担当者と打ち合わせを重ねると、事情が見えてきた。既存の受注管理システムには「得意先」というデータの持ち方自体が明確に定義されておらず、同じ会社でも部署違いで別の得意先として登録されているケースが多数あった。つまり「得意先ごとの履歴」を正しく表示するには、まず既存データの名寄せ作業が必要で、これがシステム改修そのものよりも大きな作業量になっていた。80万円という見積もりは、画面に一つボタンを追加する話ではなく、実質的にはデータベースの構造を見直すデータクレンジング作業だったのだ。
このケースが示すのは、後継社長が「見た目の要望」しか伝えていなかったために、開発会社側も「本当は何を頼まれているのか」を正確に把握できず、結果として見積もりの内訳が伝わらないまま高額な数字だけが提示されてしまったという構造だ。もし最初の相談時に「まず、この要望を実現するために既存データがどういう状態か教えてほしい。データがきれいでないなら、優先度を下げて別の安い方法を考えたい」と一言添えていれば、開発会社側も「まずは調査だけ先に受けて、その結果次第で本改修の要否を判断しましょう」という段階的な提案ができたはずだ。実際、後日改めて相談した結果、この会社は本格的な名寄せは見送り、代わりに「得意先名で検索できる」という簡易版の改修を15万円で実施することになった。要望を分解して段階的に頼む、という発想があれば、最初から穏当な進め方ができていたケースである。
ケース二 「ついでにお願い」を繰り返した結果、見積もりが把握できなくなった介護施設運営会社の事例
地域で複数の介護施設を運営する会社を父親から引き継いだ後継社長は、利用者管理システムの改修を、月に一度程度のペースで開発会社に依頼していた。「この項目を追加してほしい」「この画面の並び順を変えてほしい」「このボタンの位置をこちらに動かしてほしい」——いずれも単発では数万円程度の小さな依頼だったが、これを口頭やメールでその都度依頼し、見積もりも簡易的なやり取りで済ませていた。
半年後、経理担当者から「この開発会社への支払いが、四半期で120万円を超えている。何にそんなにお金がかかっているのか説明してほしい」と指摘され、後継社長は初めて自分がどれだけの改修を依頼していたのか整理できていないことに気づいた。個々の依頼は数万円だったが、積み重ねると相当な金額になっていた上に、どの改修がどういう業務上の効果を生んだのか、後から振り返る記録が一切残っていなかったのだ。
さらに問題だったのは、月一回のペースで小刻みに依頼を出していたことで、開発会社側も毎回「打ち合わせ」「見積もり作成」「改修」「確認」という一連の作業を都度フルセットで行う必要があり、本来まとめて依頼すれば一度で済んだはずの固定コストを、毎月支払っていたことになる。開発会社の担当者も「本当は3か月に一度、要望をまとめてから相談してもらえた方が、貴社にとっても安く済むのですが」と内心思っていたが、後継社長からは特に相談されなかったため、言い出せなかったという。
このケースの教訓は、小さな改修を「ついで」に依頼し続けることが、実は一件一件で見ると得に見えても、トータルで見ると非効率かつコスト高になるという点だ。改修要望は溜めておいて、ある程度の期間ごとにまとめて相談する仕組みを作ることで、開発会社側の固定コストの発生回数を減らし、結果として単価を下げることができる。またこれによって、経営者自身も改修の履歴と効果を定期的に振り返る機会を持てるようになる。
ケース三 開発会社を変えた際に「言い値」で押し切られそうになった建築設備会社の事例
先代が個人的な付き合いで頼んでいた小規模な個人事業主のエンジニアが高齢を理由に廃業し、後継社長は新たに法人の開発会社にシステムの引き継ぎと追加開発を依頼することになった。新しい開発会社は既存システムのソースコードを一から読み解く必要があり、「まず現状把握のための調査費用として50万円、その後の改修は別途見積もり」という提示を受けた。
後継社長はこの提示に強い不安を感じた。先代の時代は無料か数万円程度の対応だったものが、いきなり50万円という調査費用を求められたことに、「新しい会社に乗り換えたら余計にお金がかかるのではないか」という懸念が生じたのだ。しかし複数の開発会社に同じ相談を持ちかけて相見積もりを取ったところ、実は「まず現状把握のための調査費用」を明示的に提示してきたこの会社の方が、後々のトラブルを避けられる誠実な進め方をしていることが分かった。他の会社は調査費用を明示せず、いきなり改修費用の見積もりだけを出してきたが、実際に着手すると「思っていたコードと違う複雑さがあった」という理由で追加費用を請求されるリスクを抱えていた。
このケースが示すのは、後継社長がシステムの「土地勘」を持たないまま開発会社を選ぼうとすると、価格の高低だけで判断してしまい、本来注目すべき「進め方の誠実さ」を見落としてしまう危険があるということだ。属人化していた個人事業主のエンジニアから、体制のある法人の開発会社に切り替えるタイミングは、事業承継後の会社によく訪れる転機であり、この移行期にどのような発注の作法を確立するかが、その後何年もの改修コストと関係性の質を左右する。
ケース四 要望を「機能」でなく「目的」で伝えたことで、開発費が三分の一になった運送会社の事例
長距離輸送を主軸にする運送会社を叔父から引き継いだ後継社長は、配車管理システムに「ドライバーごとの稼働時間をグラフで表示する機能を追加してほしい」という要望を、社内の配車担当者から受け取った。当初は言われた通りに「稼働時間のグラフ表示機能を追加してください」と開発会社に依頼しようとしていたが、本稿にあるような「目的から伝える」という考え方を知り、依頼の仕方を変えてみた。
改めて配車担当者に話を聞くと、本当の目的は「労働基準法上の上限に近づいているドライバーを早めに把握して、シフトを調整したい」ということだった。グラフ表示という手段は、配車担当者が思いついた一つの解決策に過ぎず、目的そのものはもっと単純だった。この目的を開発会社に伝えたところ、担当者から「グラフを新規に作るとなるとデータの集計処理から構築が必要で30万円ほどかかりますが、目的が上限に近いドライバーの把握であれば、既存の稼働記録データに対して、上限の8割を超えたら一覧の該当行の背景色を変える、という簡易な仕組みで対応できます。これなら10万円程度で済みます」という代替案が提示された。
後継社長はこの代替案を採用し、当初想定していた30万円の三分の一程度の予算で、しかも配車担当者が本当に必要としていた機能を実現することができた。このケースが教えてくれるのは、現場から上がってくる要望は、既に「解決策」の形になっていることが多く、その解決策は必ずしも最も効率的な手段ではないという点だ。後継社長が「なぜその機能が欲しいのか」という目的まで一段掘り下げて開発会社に伝えることで、開発会社側の技術的な知見を活かした、より安価で的確な代替案を引き出せる可能性が生まれる。目的を尋ねる、目的を伝える、というシンプルな一手間が、開発費用を大きく左右することをこのケースは示している。
実務対応 小さな追加開発を安く早く進めるための手順
ここからは、実際に後継社長が「小さな追加開発」を依頼する際に踏むべき手順を、具体的なチェックリスト形式で解説する。
ステップ一 要望を「業務言語」から「開発言語」に自分で一段階翻訳する
現場から要望が上がってきたら、そのまま開発会社に転送するのではなく、まず自分自身で以下の観点から要望を整理する。
- 現状はどうなっているか。 今、その作業はどうやって行われているのか（例、Excelで手入力している、紙の帳票を見ながら転記している等）を具体的に書き出す。開発会社は現状を知らないと改善案を考えられないため、この整理が最も重要になる。
- 理想はどうなってほしいか。 「見られるようにしてほしい」ではなく、「誰が、いつ、どの画面で、何を見たいのか」を具体的にする。担当者名、頻度、目的（管理のため、報告のため等）まで書けると理想的だ。
- どのくらい困っているか、優先度はどれくらいか。 「今すぐ困っている」のか「あったら便利」なのかを明確にする。これによって開発会社側も緊急度に応じた提案ができる。
- 既存のどの画面・機能に関係するか。 現在使っているシステムの画面名やメニュー名を、スクリーンショットを取って添えると、開発会社側の理解が格段に速くなる。
この翻訳作業を後継社長自身、あるいは社内のシステム担当者が行うことで、開発会社との打ち合わせ時間が大幅に短縮され、結果として見積もりに含まれる打ち合わせコストを下げることができる。
実務上のコツとして、この四つの観点を毎回同じ書式のメモやチャットのテンプレートにしておくと、要望を受け取るたびにゼロから文章を考える手間が省ける。たとえば「現状:」「理想:」「困り度:」「関連画面:」という四つの見出しだけを用意した簡易フォームを社内で共有し、要望を上げてきた従業員自身にまず記入してもらう運用にすれば、後継社長が通訳する負担そのものを現場に分散できる。最初は従業員も書き方に慣れないため、後継社長が一緒に埋めてあげる必要があるが、数回繰り返すうちに現場側も「開発会社にわかる言葉」で要望を出す感覚を掴んでいく。これは、失われた古参社員の通訳機能を、個人の暗黙知に頼らず、仕組みとして再構築する取り組みでもある。
ステップ二 要望を「即対応が必要」「まとめて依頼」「様子見」の三段階に分類する
すべての要望をすぐに開発会社に投げるのではなく、社内でいったん受け止めて分類する仕組みを作る。
- 即対応が必要なもの。 システムのエラーで業務が止まっている、データが消える危険がある等、緊急性が高いものはすぐに相談する。
- まとめて依頼するもの。 ケーススタディ二で見たように、単発の小さな要望は溜めておき、月次や四半期ごとにまとめて開発会社に相談する。これによって打ち合わせや見積もり作成の固定コストの発生回数を減らせる。複数の改修を並行させるべきか順番に進めるべきかという判断は、刷新を1つずつ進めるか、複数を同時並行で進めるかの決め方も参考になる。
- 様子見にするもの。 「あったら便利」レベルの要望は、いったん保留し、本当に必要かどうかを一定期間見極める。時間が経って不要になる要望も少なくない。
この分類を担う社内の窓口を一人決めておくと、要望が場当たり的に開発会社へ流れることを防げる。理想的には、後継社長自身か、経営に近い立場の社員が月次でこの分類作業を行い、リスト化しておくとよい。
リスト化する際は、表形式で「要望内容」「依頼元(誰から出た要望か)」「分類(即対応・まとめて・様子見)」「想定される効果」「起票日」の五項目を記録するだけで十分だ。凝ったツールを導入する必要はなく、共有のExcelやスプレッドシート一枚で管理できる。このリストがあることで、四半期ごとの棚卸し面談（後述するステップ七)の際に「今溜まっている要望はこれです」とすぐに開発会社に共有でき、打ち合わせの効率が大きく上がる。またリストが可視化されることで、後継社長自身も「今どれだけの改修要望が溜まっているか」を経営の目線で把握できるようになり、資金繰りの計画にIT改修費用を組み込みやすくなるという副次的な効果もある。
ステップ三 見積もり依頼時に「予算感」と「目的」を先に伝える
見積もりを依頼する際、単に「これをやってほしい」と伝えるだけでなく、以下の情報を先に開示する。
- おおよその予算感。 「5万円程度で収まる範囲で対応可能か」「10万円を超えるなら別の方法も検討したい」といった予算の目安を伝えることで、開発会社側も予算に収まる範囲での代替案を提示しやすくなる。予算を隠すと、開発会社は「本来やるべき理想形」で見積もりを出してくることが多く、結果的に高くなりがちだ。
- その改修が実現したい業務上の目的。 「進捗一覧を作りたい」という手段ではなく、「営業会議で担当者ごとの受注状況を毎週確認したい」という目的を伝えることで、開発会社側から「その目的ならもっと安い方法がある」という代替提案を受けられる可能性が高まる。
- いつまでに欲しいか。 期限を明確にすることで、開発会社側のスケジュール調整がしやすくなり、無理な特急対応による追加費用の発生を避けられる。
ケーススタディ四の運送会社の事例が示すように、目的を先に伝えることは単なる礼儀ではなく、開発会社の専門性を引き出すための実務的な工夫でもある。開発会社は日々さまざまな業種のシステムに触れており、「この目的ならこういう簡易な方法もありますよ」という代替案の引き出しを豊富に持っている。しかし発注者側が「この機能を作ってください」という手段の指定だけを伝えてしまうと、開発会社側もその指定された手段の範囲でしか提案できなくなる。目的というゴールだけを共有し、手段の選択は専門家である開発会社に委ねる、という発注スタイルに切り替えることで、コストダウンの余地が生まれやすくなる。
ステップ四 見積もりを受け取ったら「内訳」を必ず確認する
見積もりの総額だけを見て高い安いを判断するのではなく、内訳を確認する習慣をつける。確認すべき項目は次の通りだ。
- 打ち合わせ・要件確認にかかる時間はどれくらいか。
- 実際の開発作業（プログラムの修正）にかかる時間はどれくらいか。
- テスト・動作確認にかかる時間はどれくらいか。
- 既存システムへの影響調査は必要か、その分の時間はどれくらいか。
- リリース後のサポート期間や不具合対応は見積もりに含まれているか。
内訳を尋ねることは、開発会社に対する不信の表明ではなく、むしろ発注者としての基本的なリテラシーを示す行為であり、多くの開発会社はこの質問を歓迎する。内訳の説明を渋る、あるいは曖昧にする開発会社であれば、それ自体が一つの判断材料になる。改修が完了した後の検収の要点や、万一の不具合対応の頼み方については、後継社長が知っておきたい検収の要点と不具合対応の頼み方でまとめている。
さらに一歩進んで、見積もりの内訳を確認する際には「この項目は削れば安くなりますか」という質問も有効だ。たとえば「既存システムへの影響調査」の工程について、「今回の改修は独立性の高い画面なので、影響調査は簡易版でよいのでは」と提案してみると、開発会社側も状況に応じて工程を調整し、見積もりを圧縮できる場合がある。ただし、テストの工程や記録を残す作業を安易に削ることは避けたい。これらを削ると短期的にはコストが下がるが、後の失敗パターンで述べるように、長期的なリスクを増大させることになりかねない。削ってよい工程と削るべきでない工程を見極める視点も、内訳確認の重要な狙いの一つだ。
ステップ五 「今回は見送る」という選択肢を常に持つ
小さな改修の相談をしたからといって、必ず発注しなければならないわけではない。見積もりの内容が予算感と合わない場合、あるいは目的に対して手段が大掛かりすぎる場合は、率直に「今回は見送りたい」と伝えてよい。良い開発会社は、この意思表示を受けても関係を悪化させることはなく、むしろ次回の相談のために「では、もっと簡易な方法を考えてみましょう」という提案を用意してくれることが多い。
逆に、見送りを伝えた際に強引に契約を迫ってくる、あるいは態度が変わるような開発会社であれば、長期的な付き合いには適さない可能性が高い。この見送りの選択肢を持つことは、価格交渉における最大の武器でもある。
見送りを決める際の判断基準として、投資回収の視点を持つことも有効だ。たとえば10万円の改修によって、現場の従業員が毎日15分の手作業から解放されるとすれば、時給換算でどれくらいの期間で投資が回収できるかを簡単に計算してみる。従業員の時給が1500円程度であれば、1日15分の作業削減は月あたり約5000円強の人件費相当の効果があり、10万円の改修であれば1年半程度で回収できる計算になる。逆に、月に一度しか使わない機能のために30万円をかけるのであれば、回収に何年もかかる可能性があり、見送りや簡易対応への切り替えを検討すべきサインになる。すべての改修をこの計算式に当てはめる必要はないが、金額が大きい依頼については、この視点を持つだけで判断の精度が上がる。
ステップ六 改修の記録を必ず残す
依頼した改修の内容、金額、実施日、効果（業務がどう改善したか）を、簡単な表でよいので記録に残す。これによって、次に似たような改修を依頼する際の相場観が育ち、開発会社との交渉力が高まる。また、複数の開発会社と付き合っている場合は、どの会社にどういう傾向の依頼をしてきたか、対応の速さや金額感がどうだったかを比較できるようになる。
この記録は、後継社長個人の頭の中にとどめるのではなく、次の後継者や社内のシステム担当者に引き継げる形で文書化しておくことが望ましい。事業承継の際に自分自身が経験した「相場観の引き継ぎ不在」という問題を、次の世代には残さないという意識が大切だ。
ステップ七 定期的な「棚卸し面談」を開発会社と設定する
四半期に一度程度、開発会社の担当者と「棚卸し面談」の場を設け、これまでの改修依頼を振り返り、今後の要望をまとめて相談する機会を作る。この場では以下を話し合うとよい。
- これまでの改修で効果があったもの、なかったもの。
- 現時点で保留している要望のリストと、その優先順位。
- システム全体として、今後半年から一年でどういう方向に改善していきたいか。
- 開発会社側から見て、現在のシステムに潜在的なリスクや老朽化している部分はないか。
この棚卸し面談を定例化することで、「ついで」の小さな依頼が場当たり的に発生する頻度を減らし、開発会社側も計画的にリソースを配分できるようになる。結果として、双方にとって効率的でコストを抑えた関係が築ける。
棚卸し面談は、単なるコスト管理の場にとどめず、後継社長自身が開発会社との信頼関係を深める機会として位置づけることも大切だ。先代の時代から続く関係性を、単に「業務委託の契約先」として扱うのではなく、経営の相談相手の一人として捉え直すことで、開発会社側も「この会社をもっと良くしたい」という気持ちで提案をしてくれるようになる。実際、定例の棚卸し面談を続けている会社では、開発会社側から「そろそろこの部分のシステムが古くなってきているので、次の中期計画で見直しを検討してはどうですか」といった、発注者側からは気づきにくい提案が自発的に出てくることも多い。これは、日頃から対話の頻度と質を保っている会社だからこそ得られる関係性の果実であり、小さな追加開発の頼み方を整えることの延長線上にある、より大きな経営上の価値だと言える。
よくある失敗パターン
失敗パターン一 口頭・チャットの一言だけで発注してしまう
「あれ、ちょっとお願いできますか」という一言のメッセージだけで改修を依頼し、詳細な要件も金額の確認もせずに作業が進んでしまうケースは非常に多い。特に、先代の時代からの気心の知れた開発会社であるほど、この「お願いしますで済ませる」文化が根強く残っている。しかしこれは、後になって「思っていた内容と違う」「想定より高額だった」というトラブルの火種になる。口頭やチャットでの依頼であっても、最低限「何を」「なぜ」「いつまでに」「予算感はどれくらいか」の四点は文字にして残すべきだ。これを徹底するだけで、後々の水掛け論を大幅に減らすことができる。気心が知れているからこそ、逆に確認を丁寧にすることが、長期的な信頼関係の維持につながる。
この失敗パターンが特に危険なのは、被害が発覚するタイミングが遅れることだ。口頭で依頼した改修が想定と違う形で仕上がってきても、多くの後継社長は「まあ、これでもいいか」と妥協して受け入れてしまう。そうした妥協が積み重なると、システム全体が少しずつ使いにくい方向にねじれていき、数年後に「なぜこんな仕様になっているのか誰も分からない」という状態に陥る。文字に残す一手間は、目先の依頼のためだけでなく、数年後のシステムの健全性を守るための投資でもあると捉えるべきだ。
失敗パターン二 相見積もりを取らずに一社に決め打ちしてしまう
先代の時代からの付き合いがある開発会社に対して、義理や気まずさを感じて他社に相談することをためらい、結果として一社の言い値をそのまま受け入れてしまうケースがある。もちろん長年の関係性には価値があり、頻繁に相見積もりを取ることが常に正解とは限らない。しかし、金額が大きい改修や、初めて依頼する種類の作業については、少なくとも一度は他社の見積もりも取ってみることで、自社の相場観を育てることができる。相見積もりを取ることは既存の開発会社への裏切りではなく、発注者としての当然の権利であり、多くの開発会社もそれを理解している。むしろ相見積もりの結果を正直に共有し、「他社はこういう提案だったが、今後も長く付き合いたいので相談したい」と伝えることで、より良い条件を引き出せることも多い。
失敗パターン三 「安さ」だけを基準に開発会社を選び、後で高くつく
追加開発の依頼先を選ぶ際、単純に見積もり金額の安さだけで判断してしまうと、後になって思わぬコストを払うことになりがちだ。極端に安い見積もりを出す会社の中には、既存システムの構造を十分に理解せずに場当たり的な改修を行い、後で別の不具合を引き起こすケースや、ドキュメントを残さずに改修を進めるため、次に改修が必要になったときにまた別の会社が高い調査費用を要求することになるケースがある。安さの裏にある「何が省略されているか」を見極める視点が必要だ。具体的には、見積もりの中にテストの工程が含まれているか、改修内容の記録（ドキュメント）を残す作業が含まれているかを確認するとよい。これらが省略された見積もりは、短期的には安く見えても、長期的なシステムの健全性を損ない、結果的に高い代償を払うことになりやすい。
このパターンに陥りやすい後継社長の心理として、「先代の代から高い費用を払い続けてきた」という反発心から、次の発注では極端に安さを求めてしまう、という傾向も見られる。先代の時代の費用が本当に高すぎたのかどうかを検証せずに、単に「安ければ良い」という反動に振れてしまうと、今度は品質面でのリスクを抱えることになる。安さを求めるにしても、本稿で紹介した内訳確認や相見積もりといった手順を踏んだ上で、根拠のある安さを選ぶことが重要であり、根拠のない安さに飛びつくこととは明確に区別して考える必要がある。
よくある質問
質問一 先代の代からの開発会社に、料金交渉をすると関係が悪化しませんか。
料金交渉自体が関係を悪化させることは、誠実な進め方をしていれば基本的にない。重要なのは「一方的に安くしてほしい」と要求するのではなく、内訳を尋ね、予算感を先に共有し、代替案を一緒に考える姿勢で交渉することだ。多くの開発会社は、発注者が自社の状況やコスト構造を理解しようとする姿勢を見せれば、むしろ協力的になる。逆に、内訳の説明を求められて不機嫌になる、あるいは説明を拒む会社であれば、関係の見直しを検討すべき時期に来ているとも言える。
質問二 開発会社が一社しかなく、他に相談先が見当たらない場合はどうすればよいですか。
地方の中小企業では、システムを丸ごと理解している会社が一社しかなく、実質的に他の選択肢がないという状況は珍しくない。この場合、いきなり他社に切り替えることは現実的ではないが、小さな改修の一部（たとえば単純なデータ集計やレポート作成など）を、クラウド型の業務ツールやノーコードのサービスで代替できないか検討する余地はある。既存システムに手を入れずに、外側で補完する方法を探ることで、既存の開発会社への依存度を下げつつ、将来的な選択肢の幅を広げることができる。またIT関連の相談ができる商工会や地域の支援機関に、他の開発会社の情報を尋ねてみるのも一つの方法だ。
一社依存の状態そのものを問題視しすぎる必要もない。長年の付き合いによって、システムの背景や会社の事情まで理解してくれている開発会社の存在は、それ自体が大きな資産だからだ。むしろ意識すべきは、いつかその会社との関係が続けられなくなる事態(担当者の異動や退職、会社の廃業など)に備えて、システムの仕様や過去の改修履歴を、その会社だけが知っている状態から脱するようにドキュメント化しておくことだ。これは開発会社に依頼して作ってもらうこともできるし、後継社長側で改修の記録を取り続けることでも代替できる。一社依存のリスクは、依存先を増やすことだけでなく、依存先が持つ情報を自社側にも残しておくことでも軽減できる。
質問三 現場の従業員から次々に改修要望が来て、対応しきれません。どう整理すればよいですか。
まず、要望を受け付ける窓口を一本化することが重要だ。誰でも思いついたときに開発会社に直接連絡できる状態だと、依頼が場当たり的になり、コストも管理できなくなる。窓口となる担当者（多くの場合は後継社長自身か、経営に近い立場の社員）を決め、要望はいったんそこに集約し、前述の「即対応」「まとめて依頼」「様子見」の三段階に分類する運用を徹底するとよい。窓口を一本化するだけで、開発会社に流れる依頼の数が自然と絞られ、質の高い要望だけが通るようになる。
質問四 見積もりの内訳を聞いても、開発会社がうまく説明してくれません。どうすればよいですか。
内訳の説明が苦手な開発会社もあれば、意図的に曖昧にしている場合もある。まずは「打ち合わせにどれくらいの時間がかかりましたか」「実際にプログラムを直す作業は何時間くらいですか」など、具体的な質問を一つずつ投げかけてみるとよい。抽象的に「内訳を教えてください」と聞くよりも、具体的な工程名を挙げて質問した方が、答えやすくなる開発会社の担当者も多い。それでも説明が得られない、あるいは説明があまりに不自然な場合は、他社に一度相見積もりを取り、比較材料を持つことをおすすめする。なお、現場からの要望を分類・記録する仕組みについては、最初から専用のツールを導入する必要はない。既に使っているExcelやスプレッドシート、社内のチャットツールの一つのチャンネルを「要望専用」として運用するだけで十分に機能する。重要なのはツールの高度さではなく、窓口が一本化されていることと、分類・記録が継続的に行われることだ。運用が定着し、要望の件数が増えてきた段階で、必要であれば専用の管理ツールの導入を検討すればよい。
まとめ 小さな依頼の積み重ねが、会社とシステムの未来を作る
事業承継後の後継社長にとって、追加開発の依頼は決して些末な業務ではない。先代から受け継いだシステムとの付き合い方、開発会社との関係性、社内の要望を整理する仕組み——これらすべてが、日々の「小さな改修依頼」という具体的な行為の中に集約されている。
本稿で見てきたように、小さな追加開発を安く早く進めるためには、要望を業務言語から開発言語に翻訳する力、要望を分類し溜めてまとめて依頼する仕組み、予算感と目的を先に共有する交渉術、見積もりの内訳を確認するリテラシー、そして時には「見送る」という選択肢を持つ胆力が求められる。これらは特別な技術知識ではなく、発注者としての基本的な作法であり、意識して実践すれば誰でも身につけられるものだ。
先代の時代に暗黙のうちに機能していた発注の作法は、事業承継のタイミングで一度失われる。しかしそれは裏を返せば、後継社長が自分自身の代で、より透明で合理的な発注の仕組みを新しく作り直せる機会でもある。古参社員の退職や開発会社の世代交代といった変化のタイミングは、負担であると同時に、それまでの「なんとなく」の慣習を一度見直し、記録と対話に基づいた新しい関係性を築き直す好機でもある。
小さな改修の一つひとつを丁寧に、そして戦略的に依頼していく積み重ねが、いずれ会社全体のシステムを健全な状態に保ち、現場の従業員が働きやすい環境を作り、そして次の世代へまた良い形で引き継いでいけるシステムと関係性を育てていく。
本稿で紹介した七つのステップは、どれも今日から実践できるものばかりだ。すべてを一度に完璧に導入する必要はない。まずは、次に現場から要望が上がってきたときに「現状・理想・困り度・関連画面」の四点をメモに書き出してみる。それだけでも、これまでの発注の仕方とは違う一歩を踏み出したことになる。そこから徐々に、要望を溜めてまとめて依頼する仕組みや、開発会社との定例の棚卸し面談へと運用を広げていけばよい。
事業承継は、先代が築いた資産だけでなく、先代が築けなかった課題も同時に引き継ぐ機会である。システムに対する発注の作法が整っていなかったのであれば、それを整えるのは、次の世代へこの会社を渡す後継社長自身の仕事だ。まずは今、手元に溜まっている小さな要望を一つ、書き出してみることから始めてみてほしい。
