刷新を開発会社に相談する前に、決めておきたい3つのこと

「うちのシステム、そろそろ古いよね」――ある後継社長の月曜日

月曜の朝八時、まだ誰も出社していない事務所で、後継社長の田中さん（仮名・42歳）はパソコンの前でため息をついていた。三年前、父親が急な病気で倒れたあと、準備期間もほとんどないまま社長の椅子に座った。従業員35人の建材卸業。先代である父親は現場一筋の人で、パソコンは苦手だったが「勘と経験」で会社を回してきた。受発注も在庫管理も、20年前に地元の電機屋に頼んで作ってもらったExcelマクロと、紙の帳簿と、ベテラン事務員の頭の中にしかない知識で成り立っていた。

田中さんが社長になって最初に驚いたのは、そのベテラン事務員が半年前に定年退職したことだった。引き継ぎはされたはずだったが、実際にシステムを触ってみると、マクロの内部でどういう計算がされているのか誰も分からない。得意先ごとの掛け率も、在庫の発注タイミングも、「なんとなくこうしている」というブラックボックスのまま運用が続いている。新しく入った若手社員は「なぜExcelでこんな複雑な管理をしているんですか、クラウドのサービスを使えばいいのに」と無邪気に聞いてくる。田中さんは答えられなかった。

そんな中、知り合いの経営者から「システム開発会社に相談してみたら」と勧められ、名刺交換した会社に連絡を取った。初回の打ち合わせの日、田中さんは緊張しながら会議室に座っていた。開発会社の担当者は名刺を渡すと、笑顔でこう切り出した。

「今日はまず、御社の課題を教えていただければと思います。何でも結構ですので、お困りのことをお聞かせください」

田中さんは正直、何を話せばいいのか分からなかった。「システムが古い」「なんとなく不便」「このままだと不安」――そういう漠然とした感情はあるが、それを言語化する言葉を持っていなかった。結局その日の打ち合わせは、田中さんが世間話のように会社の歴史や業界の状況を話し、開発会社の担当者がそれを「なるほど、なるほど」とメモするだけで終わった。後日届いた見積書には、田中さんの想定の3倍近い金額と、聞いたこともない機能がずらりと並んでいた。「なぜこの機能が必要なのか」「なぜこの金額になるのか」を聞いても、担当者の説明は専門用語だらけで、結局よく分からないまま「一度社内で検討します」と持ち帰ることになった。

これは決して珍しい話ではない。中小企業の事業承継の現場では、先代から会社を引き継いだばかりの後継社長が、システムの刷新という重い課題に直面し、右も左も分からないまま開発会社の前に座らされる、という場面が繰り返し起きている。そして多くのケースで、田中さんと同じように「相談したのに、何も決まらなかった」「見積もりが想定と大きく違って驚いた」「結局話が噛み合わないまま時間だけが過ぎた」という結果に終わる。

この記事では、なぜ「決めずに相談する」とほぼ必ず失敗するのか、その構造を解き明かしたうえで、開発会社に相談する前に後継社長が決めておくべき3つのことを、具体的なチェックリストと業種別の実例つきで解説する。専門用語は最小限にとどめ、ITに詳しくない読者でも実践できる形にまとめている。決めた内容を実際の資料に落とし込む段階に進んだら、要件のまとめ方。何から刷新するか固まっていない社長のための資料作りもあわせて参考にしてほしい。

なぜ「決めずに相談する」と失敗するのか――3つの構造的な原因

「システムを刷新したい、でも何から手をつければいいか分からないから、とりあえず開発会社に相談してみよう」――この発想自体は間違っていない。専門家に相談することは正しい第一歩だ。しかし、多くの後継社長が陥る罠は、「相談すれば向こうが全部整理してくれる」という期待にある。実際には、開発会社は魔法のように課題を整理してくれる存在ではなく、「あなたが持ち込んだ情報の質」に依存して提案の質が決まる、という構造がある。ここでは、決めずに相談することがなぜ高確率で失敗につながるのか、3つの構造的な原因を掘り下げていく。

原因1：開発会社は「御用聞き」ではなく「翻訳者」である

多くの後継社長が誤解しているのは、開発会社の役割についてのイメージだ。「困っていることを話せば、向こうが専門知識でうまく解決策を組み立ててくれる」と考えている人が多い。しかし実際の開発会社の仕事は、御用聞きではなく「翻訳」である。つまり、発注側が持っている業務上の要望や課題を、システムとして実現可能な仕様に「翻訳」する仕事だ。

翻訳という作業には、原文が必要になる。原文があいまいで、行間が多く、文脈依存の情報ばかりだと、翻訳者はどう訳せばいいか分からず、結局「一番安全な、当たり障りのない訳」を選ぶことになる。開発の世界でこれが起きると何が起きるか。開発会社は「御社の業界でよくあるパターン」「一般的な機能」を当てはめたテンプレート的な提案をしてくることになる。それは決して的外れではないが、田中さんの会社の「実は掛け率が得意先ごとに20パターンあって、季節によって変動する」という固有の事情には対応していない。結果として、後から「これでは使えない、思っていたのと違う」という修正合戦が始まり、追加費用と追加期間が発生する。

翻訳の質を上げるには、原文――つまり発注側が持ち込む情報――の質を上げるしかない。これが「決めておく」ことの本質的な意味だ。

原因2：「何を作るか」と「何にお金を払うか」がリンクしていないと、見積もりが際限なく膨らむ

システム開発の見積もりというのは、多くの後継社長が想像する「モノの値段」とは全く違うロジックで組み立てられている。家電量販店で冷蔵庫を買うときは、店頭に並んでいる商品を見て、値札を見て、その場で決められる。しかしシステム開発は「まだ存在しないものを、これから一緒に作る」という取引であり、見積もりの根拠となるのは「どれだけの機能を、どれだけの精度で作るか」という「範囲(スコープ)」である。

この範囲が発注側の頭の中で確定していないと何が起きるか。開発会社としては、「聞いた話全部を実現できる前提」で最大限の見積もりを出すか、あるいは「重要そうな部分だけを抜き出した保守的な見積もり」を出すか、どちらかの判断をせざるを得ない。前者だと想定外に高額な見積もりになり、後者だと「思っていた機能が入っていない」という食い違いが後から発覚する。田中さんのケースで見積もりが「想定の3倍」になったのも、まさにこの構造が原因だ。田中さんが「システムを新しくしたい」というふわっとした要望だけを伝えた結果、開発会社は「取りうる範囲を全部盛り込んだ、リスクの少ない見積もり」を作成してしまったのである。

さらに厄介なのは、見積もりが膨らむ理由が「機能を過剰に盛り込んでいるから」だけではないという点だ。要件があいまいだと、開発会社側は「途中で追加要望が出てくるリスク」を見積もりに含めて金額を上乗せする。これは決して悪意ではなく、リスク管理として当然の振る舞いだ。逆に言えば、発注側が要件を明確にし、追加要望が出るリスクを減らすことができれば、その分見積もりの「安全マージン」も減らすことができる。つまり、事前に決めておくという行為そのものが、コストダウンに直結する。

原因3：意思決定者と現場の情報が「後継社長」というフィルターを通ると劣化する

事業承継特有の問題として、先代が現場に持っていた「暗黙知」が、後継社長にきちんと引き継がれていないケースが非常に多い。先代は長年の経験から「この得意先は掛け率を特別扱いしている」「この工程は実は二重チェックが必要」といった情報を頭の中に持っていたが、それを体系立てて文書化していることは稀だ。後継社長は、その暗黙知を完全には受け継げないまま、システム刷新の意思決定者という立場に立たされる。

このギャップがある状態で開発会社に相談すると、何が起きるか。後継社長は「自分が把握している範囲」でしか要望を話せない。しかし実際のシステムを運用しているのは現場の担当者であり、現場が本当に困っていること、本当に必要としている機能は、後継社長の耳には入ってきていないことが多い。この結果、「社長が話した要望」だけをもとに作られたシステムは、現場で「使いにくい」「これでは前より不便だ」という不満の声を招き、最終的には「せっかく金をかけて刷新したのに、現場が使ってくれない」という最悪の結末に至る。

事業承継から数年以内のタイミングでシステム刷新に踏み切る後継社長は非常に多い。しかし、そのタイミングだからこそ、「自分がまだ完全には把握していない現場の情報」を、開発会社に相談する前にきちんと集めておく必要がある。これを怠ると、開発会社との対話がいくら丁寧であっても、そもそも入力される情報が不完全なので、出てくる提案も不完全になる。

以上の3つの構造的原因――「翻訳の原文としての情報不足」「範囲が確定しないことによる見積もりの膨張」「暗黙知の引き継ぎ不足」――が組み合わさることで、「決めずに相談する」という行動は、ほぼ確実に「時間をかけたのに何も決まらない」「見積もりが想定と大きくズレる」「作ったはいいが現場に合わない」という失敗パターンに帰結する。次章からは、この構造的な失敗を避けるために、開発会社に相談する前に決めておくべき3つのことを、具体的なチェックリストとともに解説していく。

決めておくべきこと1：「何のために刷新するのか」という目的と優先順位

目的があいまいだと、全ての判断がブレる

システム刷新の相談で最初に開発会社から聞かれるのは、たいてい「今回、システムを刷新される目的は何でしょうか」という質問だ。この質問に、明確に答えられる後継社長は実は多くない。「古くなったから」「なんとなく不便だから」「同業他社が新しくしたと聞いたから」といった漂うような答えになりがちだ。

しかし、この目的こそが、システム刷新に関わる全ての判断の基準になる。予算をどこにかけるか、機能の優先順位をどう並べるか、スケジュールをどう組むか――これらは全て「何のために刷新するのか」という目的に対してどれだけ寄与するかで判断されるべきものだ。目的があいまいだと、開発会社との打ち合わせのたびに判断がブレて、「あの機能もいる」「この機能もいる」と要望が膨らみ続け、収拾がつかなくなる。

田中さんの建材卸業の例で言えば、目的は複数考えられる。「ベテラン事務員が退職した後も、誰でも受発注業務ができるようにしたい」という属人化解消が目的なのか、「得意先からの受注をリアルタイムで見える化して、欠品を減らしたい」という業務効率化が目的なのか、「若手社員が使いやすいシステムにして、採用力を上げたい」という組織づくりが目的なのか。これらは似ているようで、実は優先すべき機能が全く異なる。属人化解消が目的なら、まずはマクロの中身をドキュメント化し、誰でも理解できる形に整理することが最優先になる。業務効率化が目的なら、在庫データと受注データをリアルタイムで連携させる仕組みが最優先になる。採用力向上が目的なら、スマホからでも使えるモダンなUIが最優先になる。

目的を決めるための実践ステップ

目的を決めるといっても、いきなり「我が社のシステム刷新の目的は」と机に向かって考えても、抽象的な言葉しか出てこないことが多い。以下のステップで、具体的な目的に落とし込んでいくことをお勧めする。

まず第一に、「今、何に困っているか」を全部書き出す。これは開発会社に相談する前に、社長ひとりで、あるいは主要な社員数名を交えて、ブレインストーミング的に行う作業だ。「入力に時間がかかる」「ミスが多い」「担当者しか分からない」「他部署と情報共有できない」「外出先から確認できない」――思いつく限り、些細なことでも書き出す。この段階では優先順位をつけずに、とにかく数を出すことが重要だ。

第二に、書き出した困りごとを「お金に換算できる問題」と「お金に換算しにくい問題」に分類する。「入力ミスで月に3件クレームが発生し、対応に1件あたり2時間かかっている」というのはお金に換算しやすい問題だ。「システムが古くて、若手社員のモチベーションが下がっている気がする」というのはお金に換算しにくい問題だ。両方とも重要だが、開発会社に相談する際には、お金に換算できる問題を軸にして話すと、投資対効果の議論がしやすくなる。

第三に、分類した問題の中から「今回の刷新で必ず解決したいもの」を3つまでに絞る。ここが最も難しく、また最も重要なステップだ。困りごとを全部解決しようとすると、予算もスケジュールも膨れ上がり、結局何も決まらないまま議論が長引く。「今回は、この3つが解決できればひとまず成功とする」という基準を、社長自身が決めておく必要がある。

第四に、絞り込んだ3つの目的について、それぞれ「誰が困っていて、誰が嬉しくなるのか」を明確にする。社長が嬉しいだけの刷新は現場に定着しない。現場の担当者、得意先、経理担当者など、関係する人たちにとってのメリットを言語化しておくと、後の要件定義がスムーズになる。

目的設定チェックリスト

以下のチェックリストは、開発会社に相談する前に、社長自身で確認しておきたい項目だ。

• 今回のシステム刷新で解決したい課題を、5つ以上書き出せているか
• その課題を「お金に換算できるもの」と「できないもの」に分けられているか
• 課題の中から、優先度の高い3つ以内に絞り込めているか
• 絞り込んだ課題について、それぞれ「なぜ今なのか」を説明できるか
• 目的が「システムを新しくすること」自体になっていないか(手段が目的化していないか)
• 現場の担当者に、今回の刷新で解決したいことをヒアリングしたか
• 得意先や取引先から見て、今回の刷新はどう見えるかを考えたか
• 3年後、このシステムがどう使われていてほしいかを、具体的にイメージできるか
• 刷新しない場合に、どんなリスクが待っているかを言語化できているか
• 目的を、社内の主要メンバーに一度説明してみて、反応を確認したか

目的があいまいなまま進んだ場合に起きること

目的を決めずに相談を進めると、典型的には次のようなことが起きる。開発会社との打ち合わせが進むにつれて、あれもこれもと機能要望が積み重なっていき、最初に想定していた予算の2倍、3倍という見積もりになる。あるいは逆に、開発会社が「よくあるパッケージ」を提案し、それを導入したものの、実際の業務の細かい部分に対応できず、結局現場が独自のExcel運用を続けてしまい、システムと現場の実態が二重管理になる。

事業承継後のシステム刷新において、目的を最初に固めておくことは、単なる準備作業ではなく、プロジェクト全体の成功確率を大きく左右する、最も重要な意思決定だと言える。

決めておくべきこと2:「予算の上限」と「その根拠」

「いくらまでなら出せるか」を言わないと、いくらでも高くなる

システム開発の見積もりで最もよくある失敗が、「予算を先に伝えると高く見積もられるのではないか」と考えて、予算を隠したまま相談を進めることだ。これは一見合理的な発想に思えるが、実際には逆効果になることが多い。予算という制約条件がないと、開発会社は「実現可能な最大限の機能」を前提に提案を作ってしまうため、結果として予算を明かした場合よりも大きな見積もりが出てくることが多い。

もちろん、予算を伝えれば必ず安くなるという単純な話ではない。しかし、予算という上限を共有することで、開発会社は「その予算の中で、どの機能を優先すべきか」という現実的な提案を組み立てることができる。予算を隠したまま「一番良い提案をしてください」と依頼するのは、レストランで「予算は言いませんので、一番美味しいコースを出してください」と頼むのに近い。結果として出てくるのは、シェフのおまかせフルコースであり、値段を見て驚くことになる。

予算の上限を決めるための考え方

予算をどう決めればいいのか、多くの後継社長が悩むポイントだ。ここでは、実務的に使える3つのアプローチを紹介する。

第一のアプローチは、「投資回収の視点」から逆算する方法だ。今回のシステム刷新によって、年間でどれだけのコスト削減や売上増加が見込めるかを試算し、その何年分を投資として許容できるかを考える。たとえば、属人化していた受発注業務が自動化されることで、月20時間の残業が削減できるとすれば、時給換算でおおよその金額が出る。それを年間に換算し、投資回収の目安を3年程度に置くと、おおまかな予算の上限が見えてくる。この方法は数字に落とし込みやすく、経営者として説明責任を果たす際にも有効だ。

第二のアプローチは、「会社の規模に対する妥当な投資割合」から考える方法だ。中小企業のシステム投資は、一般的に年間売上の1%から3%程度が目安とされることが多いが、これは業種やシステムの重要度によって大きく変わるため、あくまで参考値として捉えるべきだ。自社の売上規模と、今回のシステムが経営にとってどれだけ重要かを踏まえて、大まかな枠を決めておく。

第三のアプローチは、「複数の会社から概算見積もりを先に取る」という方法だ。本格的な要件定義に入る前の段階で、2社から3社程度に「このくらいの規模の刷新をするとして、ざっくりどの程度の費用感になりそうか」を聞いてみる。この段階では厳密な見積もりは出てこないが、相場感をつかむことができる。相場感がないまま予算を決めると、極端に低すぎる予算を設定してしまい、結局どの開発会社からも「その予算では対応できません」と断られる、という事態にもなりかねない。

予算に関して決めておくべき3つの数字

予算について相談前に決めておきたいのは、単に「総額いくらまで」という一つの数字だけではない。以下の3つの数字を、可能な範囲で用意しておくことをお勧めする。

一つ目は「初期投資として出せる上限額」だ。システムを新しく作る、あるいは大きく作り変える際の一括の費用として、どこまで出せるかという数字である。

二つ目は「月々の運用コストとして許容できる金額」だ。多くのシステムは、作って終わりではなく、クラウドの利用料や保守費用が毎月発生する。この継続コストを見誤ると、初期投資は予算内に収まったのに、運用開始後に「毎月の費用が思っていたより高い」と後悔することになる。

三つ目は「追加開発・改修のために確保しておきたい予備費」だ。システムは作った瞬間から陳腐化が始まり、運用しながら改善していくものだ。最初の開発費用だけを予算として確保し、その後の改善費用を全く考えていないと、「作ったら終わり」という発想になり、結果的に数年後には再び「古くなった、また刷新しないと」という同じ問題に直面する。

予算設定チェックリスト

• 初期投資として出せる上限額を、数字として決めているか
• その上限額の根拠(投資回収年数や売上比率など)を説明できるか
• 月々の運用コスト(サーバー費用、保守費用など)の許容額を考えているか
• 開発後の追加改修のための予備費を確保する考えがあるか
• 銀行融資や補助金・助成金の活用を検討したか、あるいは自己資金で完結させる前提か
• 見積もりが想定を超えた場合に、機能を削るか、予算を増やすか、期間を延ばすか、優先順位を決めているか
• 複数社から概算の相場感を聞き、自社の予算感が現実的かを確認したか
• 予算を決算・経営会議など、社内の意思決定プロセスにどう通すかを想定しているか
• 先代の時代の投資判断(過去にいくらかけてどう失敗・成功したか)を確認したか
• 「安ければ安いほど良い」という発想になっていないか(極端に安い見積もりのリスクを理解しているか)

予算を曖昧にしたまま進んだ場合のリスク

予算を明確にしないまま相談を進めると、要件定義が進んだ段階で初めて金額が提示され、その金額が想定より大幅に高いことに気づき、そこから機能を削る作業に入る。しかしこの段階まで来ると、すでに要件定義のために費やした時間や、開発会社側の作業時間が「無駄」になってしまっており、双方にとって精神的な負担が大きい。最初から上限を共有していれば、その上限に収まる形で要件を組み立てる、という前向きな進め方ができたはずだ。予算の共有は、決して「手の内を見せて損をする」行為ではなく、むしろ双方にとって効率的な進め方を実現するための土台である。承継1年目でどこまで予算をかけるべきかの判断軸は承継1年目に予算をかけるべきこと・かけなくていいことでも整理している。

決めておくべきこと3:「誰が意思決定者で、誰が使うのか」という体制

システムは「作る人」と「使う人」と「決める人」が違うと失敗する

事業承継後のシステム刷新でもうひとつ、非常によく見落とされるのが「体制」の問題だ。ここでいう体制とは、「誰が最終的な意思決定者なのか」「実際にシステムを使うのは誰なのか」「開発会社とのやり取りの窓口は誰が担うのか」という、人と役割の整理のことだ。

田中さんのケースを振り返ると、初回の打ち合わせに出席したのは田中さん一人だった。しかし、実際に受発注業務を担っているのは事務担当の社員であり、在庫を管理しているのは倉庫の担当者だ。田中さんが一人で開発会社と話を進め、決めてしまうと、後になって「現場の実情と合っていない」という不満が噴出するリスクが高い。逆に、現場の声を全部拾おうとして、多くの社員が打ち合わせに参加すると、意見が分散して収束しなくなる、という別の問題も起きる。

この体制の問題を事前に整理しておかないと、開発会社との打ち合わせの場で「これは社長の判断ですか、それとも現場の意見も聞く必要がありますか」という確認が毎回発生し、意思決定のスピードが著しく落ちる。事業承継後の企業では特に、先代の時代からの「実質的な決定権を持つベテラン社員」が別に存在するケースも多く、社長が決めたつもりでも、後からベテラン社員の反対で覆る、という事態も起こりうる。

体制を決めるための3つの役割

体制整理では、最低限、以下の3つの役割を明確にしておく必要がある。

一つ目は「最終意思決定者」だ。予算の承認、要件の最終確定、スケジュールの調整など、最終的に「これでいく」と決める人物を一人に定める。複数人の合議制にすると、意見が対立した際に誰も決められず、プロジェクトが停滞する。後継社長自身がこの役割を担うのが基本だが、先代がまだ会長として実権を持っている場合は、先代の承認をどのタイミングでどう得るかも事前に決めておく必要がある。

二つ目は「実務側の窓口(プロジェクトオーナー)」だ。日々の細かい仕様確認や、現場からの要望のとりまとめを行う人物である。社長が全ての細かいやり取りに対応するのは非効率であり、現場をよく知る中間管理職や、ITに比較的強い社員を窓口に据えることが望ましい。この窓口役が、現場の声を吸い上げて整理し、開発会社に伝える「翻訳者」の役目を果たす。

三つ目は「実際の利用者(エンドユーザー)」だ。受発注担当、経理担当、倉庫担当など、実際にシステムを操作する人たちである。要件定義の段階で、この利用者たちの声をどのタイミングでヒアリングするか、そして完成後の操作研修をどう行うかを、事前に見通しておく必要がある。利用者を蚊帳の外に置いたまま開発を進めると、完成後に「使いにくい」「これでは前のやり方の方が良かった」という反発が起き、せっかく作ったシステムが定着しないまま終わる。

事業承継特有の落とし穴:先代・会長との関係

事業承継後の企業でシステム刷新を進める際、特有の難しさとして「先代・会長の意向」との調整がある。先代がまだ会社に関わっている場合、システム投資という大きな決断に対して、先代が口を出してくることは十分に想定される。「今のやり方で長年うまくやってきたのに、なぜ変える必要があるのか」という反発が出るケースも少なくない。

この点についても、開発会社に相談する前に、後継社長自身が「先代にどう説明し、どう了承を得るか」の道筋をある程度考えておくことが望ましい。先代の懸念は多くの場合、「使い慣れたものが失われる不安」「投資が無駄になるかもしれない不安」に起因している。この不安に対して、目的(何のためにやるか)と予算(いくらまでか)がすでに整理されていれば、説明はぐっとしやすくなる。逆に、目的も予算もあいまいなまま先代に相談すると、「よく分からないが、金がかかりそうだから反対」という結論になりやすい。

体制整理チェックリスト

• 最終的な意思決定者が誰か、社内で明確になっているか
• 開発会社とのやり取りの窓口(プロジェクトオーナー)を誰にするか決めているか
• 実際にシステムを使う現場の担当者を洗い出せているか
• 現場担当者へのヒアリングをどのタイミングで行うか、計画があるか
• 先代・会長がまだ経営に関与している場合、どう説明し了承を得るかを考えているか
• 開発会社との定例ミーティングに、誰が出席するかを決めているか
• 現場からの要望と、経営としての優先順位が対立した場合、誰が最終判断するかのルールがあるか
• システム完成後の操作研修・引き継ぎを誰が担当するかを想定しているか
• 退職したベテラン社員が持っていた業務知識を、誰がどう補うかを考えているか
• 開発期間中、通常業務と並行してどれだけの時間を体制構築に割けるかを見積もっているか

体制が整理されていないまま相談を進めると、開発会社は「窓口が誰なのか分からず、確認事項がその都度別の人に聞かれて回答が食い違う」という混乱に陥る。これは開発の遅延だけでなく、要件のブレにも直結する。事業承継直後の後継社長にとって、体制整理は地味に見えるが、実は最も労力を割くべき準備作業のひとつである。

業種別に見る「決めておくべきこと」の具体例

これまで解説した3つの決めておくべきこと(目的、予算、体制)は、業種によって重視すべきポイントが微妙に異なる。ここでは代表的な3つの業種を例に、具体的にどう考えればよいかを紹介する。

建設・工事業の場合

建設・工事業を先代から引き継いだ後継社長の場合、システム刷新の目的として多く挙がるのは「工事の進捗管理と原価管理の見える化」だ。先代の時代は、現場監督が手帳やホワイトボードで進捗を管理し、原価は月末に事務員が紙の請求書を集めて手計算で集計する、というアナログな運用が根付いていることが多い。この業種特有の注意点は、現場作業員の多くがパソコン操作に不慣れであり、スマートフォンからの簡単な入力で完結する仕組みでなければ現場に定着しないという点だ。目的設定の際には「誰が入力するのか」を強く意識する必要があり、体制整理においては現場監督クラスの意見を早期に取り込むことが不可欠になる。予算面では、原価管理の精度向上によって見積もり精度が上がり、無駄な工事コストが削減される効果を数値化しやすいため、投資回収の視点から予算上限を算出しやすい業種だと言える。また、建設業では取引先(元請け・下請け)との請求書や見積書のやり取りが多く発生するため、既存の取引先が使っているフォーマットとの整合性も、決めておくべき事項の一つに加える必要がある。

製造業(部品加工・小規模工場)の場合

製造業の後継社長がシステム刷新を検討する場合、目的としてよく挙がるのは「受注から生産、出荷までの一連の流れの可視化」と「熟練職人の技術・工程知識の形式化」だ。先代の工場では、加工の順序や段取りの勘所が、特定のベテラン職人の頭の中にしかないことが多く、事業承継後にその職人が高齢で引退すると、技術の空洞化が一気に進むリスクがある。この業種における予算設定では、単純なシステム開発費だけでなく、既存の生産管理機器やセンサーとの連携が必要になるケースが多く、想定外の周辺コストが発生しやすい点に注意が必要だ。体制面では、工場長や現場のリーダー格の職人を早期に巻き込み、「システムに置き換えられる」という不安を払拭しながら進める必要がある。製造業特有の落とし穴として、システムを導入すれば全てが自動化されるという過度な期待を経営側が持ってしまい、実際には「データを入力する手間」がむしろ増えるケースもあるため、目的設定の段階で「どこまでを自動化し、どこは人の判断に残すか」を明確にしておくことが重要になる。

小売・卸売業の場合

田中さんの建材卸業のようなケースを含む小売・卸売業では、目的としてよく挙がるのは「在庫管理の精度向上」と「得意先ごとの取引条件(掛け率・支払い条件)の一元管理」だ。この業種の特徴は、得意先ごとに個別の取引条件が積み重なっており、その条件がシステム化されずに「担当者の記憶」や「個別のExcelシート」に散らばっていることが多い点だ。予算設定においては、在庫の欠品や過剰在庫によって発生している損失額を試算しやすいため、投資回収の説明がしやすい業種と言える。体制面では、受発注担当と経理担当の両方の視点を取り込む必要があり、特に得意先との取引条件は経理・営業の双方が絡むため、どちらの部署の意見を優先するかを事前に整理しておくべきだ。また、卸売業では得意先側のシステム(EDIや専用の発注システムなど)との連携が必要になるケースもあり、この点は開発会社に相談する前に、主要な得意先に「今後システムを変更する予定があるが、連携の仕様に変更が生じる可能性があるか」を一言確認しておくと、後々のトラブルを避けられる。

よくある失敗パターン3選

ここまで紹介したチェックリストを踏まえても、実際の現場では似たような失敗が繰り返されている。ここでは特に頻度の高い3つの失敗パターンを紹介する。自社が同じ轍を踏んでいないか、確認してみてほしい。

失敗パターン1:「とりあえず」で相談を始めてしまう

「とりあえず一度話を聞いてもらおう」という軽い気持ちで開発会社に連絡し、目的も予算も体制も整理せずに打ち合わせに臨むパターンだ。この場合、開発会社側は限られた情報から提案を組み立てるしかなく、結果として「よくあるパッケージの紹介」か「聞いた話を全部盛り込んだ大掛かりな提案」のどちらかに偏りやすい。後継社長側は「思っていたものと違う」と感じるが、そもそも自分が何を思っていたのかも明確ではないため、フィードバックが的確にできず、二度目の打ち合わせも同じ堂々巡りになる。このパターンの根本原因は、「相談すれば何かが決まる」という誤った期待にある。相談は、決めた内容を検証し、実現可能性を確認するための場であり、決める作業そのものを代行してくれる場ではない。

失敗パターン2:社長一人で全部決めて、現場が置いてけぼりになる

事業承継直後の後継社長は、自分の経営者としての判断力を示したいという思いから、システム刷新についても自分一人で全てを決めてしまいがちだ。現場へのヒアリングを省略し、開発会社との打ち合わせも自分だけで進め、要件を確定させてしまう。しかし完成したシステムを実際に使うのは現場の社員であり、彼らの日々の業務フローや、細かい例外処理の知識が反映されていないシステムは、稼働してから「使いにくい」「前のやり方に戻したい」という声が噴出する。最悪の場合、現場が独自にシステムを使わずに元のExcelやノートに戻ってしまい、投じた費用がほぼ無駄になる。このパターンを避けるには、決めておくべきこと3の「体制」で解説した通り、意思決定者と実際の利用者を分けて考え、要件定義の初期段階から現場の声を吸い上げる仕組みを作ることが不可欠だ。

失敗パターン3:見積もりが出た後に、慌てて機能を削ってスコープが崩壊する

予算の上限を決めずに要件定義を進めた結果、想定を大幅に超える見積もりが提示され、その場で慌てて機能を削る、というパターンだ。この場合、削る機能の判断基準がその場しのぎになりやすく、本来最も重要だった機能まで削られてしまうことがある。また、要件定義がある程度進んだ段階での変更は、開発会社側の作業のやり直しを伴うことが多く、追加のコストや期間の遅延を招く。さらに厄介なのは、機能を削った結果、当初の「目的」が達成できないシステムになってしまうケースだ。予算に収めるために機能を削ったのに、その結果、そもそも刷新したかった課題(属人化の解消や業務効率化)が解決されない、という本末転倒な結果に陥る。このパターンを避けるためには、決めておくべきこと1(目的)と2(予算)を先に固め、「予算内でどうしても実現すべき最優先事項」と「予算に余裕があれば実現したい項目」を事前に分けておくことが有効だ。

まとめ:相談は「答えを聞く場」ではなく「決めたことを検証する場」

先代から会社を引き継いだ後継社長にとって、システム刷新という決断は、経験もノウハウもない中で下さなければならない、非常に不安の大きい判断のひとつだ。だからこそ「専門家に相談すれば何とかなる」という期待を持ちやすいが、この記事で見てきたように、開発会社は魔法のように課題を整理してくれる存在ではなく、発注側が持ち込む情報の質に応じて提案の質が決まる「翻訳者」である。

決めずに相談することが失敗につながる構造的な理由は、翻訳の原文となる情報が不十分であること、範囲が確定しないことで見積もりが際限なく膨らむこと、そして先代からの暗黙知の引き継ぎ不足によって後継社長が把握している情報自体が不完全であること、の3つに整理できる。この構造を理解した上で、相談前に「何のために刷新するのか」という目的、「いくらまで出せるのか」という予算、「誰が決めて誰が使うのか」という体制の3つを固めておくことで、開発会社との対話は初めて実りのあるものになる。

建設業、製造業、小売・卸売業といった業種による違いはあっても、この3つの軸で事前に整理しておくという基本姿勢は共通している。そして、よくある失敗パターンとして挙げた「とりあえず相談する」「社長一人で決める」「見積もり後に慌てて削る」は、いずれも事前準備の不足から生まれる、避けられる失敗だ。この3つを固めたあとに開発会社へ提出する資料の作り方は要件定義、開発会社に伝わる資料の作り方で、契約形態の基礎知識は請負契約と準委任契約、何がどう違うのかで、それぞれ詳しく解説している。

最後に強調したいのは、相談という行為の位置づけについての考え方だ。相談は、答えを一から聞く場ではなく、自分たちで決めたことを専門家の目で検証し、実現可能性やより良い方法を一緒に考えてもらう場である。この位置づけを正しく理解し、事前に決めておくべきことをきちんと固めてから開発会社の前に座ることができれば、田中さんが経験したような「話が噛み合わないまま時間だけが過ぎる」という失敗を避け、事業承継後の会社にとって本当に必要なシステム刷新を、納得感を持って進めていくことができるはずだ。

よくある質問(FAQ)

Q1. 目的・予算・体制を決めるのに、どれくらいの期間をかければいいですか

会社の規模や課題の複雑さによって異なるが、目安としては2週間から1ヶ月程度を想定しておくとよい。社長一人で考えるのではなく、現場の主要メンバーへのヒアリングや、先代への説明・了承取りといった対外的なやり取りも含まれるため、思っているより時間がかかることが多い。焦って1日で決めてしまうと、現場の声を十分に反映できず、後になって前提が崩れるリスクが高まる。一方で、あまりに長く時間をかけすぎると、決めた内容自体が状況の変化によって古くなってしまうこともあるため、1ヶ月程度を目安に、区切りをつけて開発会社への相談に進むことをお勧めする。

Q2. 予算の上限を先に伝えると、開発会社に「その金額まで使い切ろう」とされませんか

そのような懸念を持つ後継社長は多いが、信頼できる開発会社であれば、予算の上限を伝えることで、その範囲内で優先度の高い機能から提案する、という誠実な進め方をしてくれるはずだ。むしろ、予算を伝えた際の対応の仕方は、その開発会社が信頼できるかどうかを見極める一つの材料になる。予算を伝えた途端に、予算ぎりぎりまでの機能を無理に勧めてくるような会社であれば、慎重に検討した方がよい。逆に、「その予算であれば、まずこの機能を優先し、残りは第二段階で検討しましょう」といった段階的な提案をしてくれる会社は、長期的なパートナーとして信頼できる可能性が高い。

Q3. 現場の社員がITに詳しくなく、要望をうまく言葉にできません。どうすればいいですか

現場の社員に「システムに何を求めるか」を直接聞いても、うまく言葉にならないことは非常によくある。この場合は、「何を求めるか」を聞くのではなく、「今、業務のどの場面で困っているか、時間がかかっているか」を具体的に聞くとよい。「毎朝、在庫を確認するために何をしているか」「受注が入ったとき、最初に何をするか」といった、実際の作業の流れを一つずつ聞いていくことで、システムに求める要件が自然と見えてくる。この作業は、開発会社に相談する前に、社長やプロジェクトオーナーが現場を実際に観察しながら行うと、より精度の高い情報が集まる。

Q4. 先代がシステム刷新に反対している場合、どう進めればいいですか

先代の反対の背景には、多くの場合「使い慣れたものが失われる不安」や「投資が無駄になるかもしれない不安」がある。この不安に対しては、感情的な説得よりも、この記事で紹介した目的・予算・体制の整理をきちんと行い、具体的な数字と計画をもって説明することが効果的だ。特に、投資回収の見通しや、現状のまま放置した場合のリスク(属人化の悪化、退職リスクなど)を具体的に示すことで、先代の懸念に対して正面から答えることができる。また、いきなり大掛かりな刷新を提案するのではなく、小さな範囲から試験的に始めて、効果を実感してもらいながら段階的に進める、という進め方も、先代の理解を得やすい方法のひとつだ。

相談前に決めておくべきことの一つが、フルスクラッチとパッケージのどちらを軸にするかだ。フルスクラッチとパッケージ、承継後の刷新はどちらを選ぶ？で比較している。