承継後2〜3年目、何から刷新するかを決める全体の進め方

土台の把握が終わった、次の段階です

会社を継いでから2〜3年が経ち、社内にどんなシステムがあり、誰が何を頼りに動いているか、だいたい頭に入ってきた頃だと思います。先代の時代からのExcel台帳、動きが怪しいサーバー、古参社員しか触れない業務フロー。危ないところ、遅れているところが見えてきて、「そろそろ変えたい」という気持ちが芽生えてきたのではないでしょうか。

ここから先は、これまでの「現状を把握する」フェーズとは質が違います。実際に手を動かして、お金を使って、何かを変える段階です。だからこそ、思いつきで一つずつ手をつけるのではなく、全体の進め方を先に決めておくことが大事になります。この記事では、刷新を始める前に押さえておきたい4つのポイントを順番に整理します。

なぜ「土台把握」と「刷新実行」を分けて考える必要があるのか

多くの承継社長は、システムの問題点が見えた瞬間に「今すぐ直したい」という衝動に駆られます。気持ちはよくわかりますが、ここで焦って個別対応を始めると、後になって「あのとき全体を見て優先順位をつけていれば、もっと安く早く済んだのに」という後悔につながりやすいのが実情です。

土台把握のフェーズでやったことは、いわば健康診断です。どこにリスクがあるか、どこが弱っているかを洗い出しただけで、まだ治療は始まっていません。刷新実行のフェーズは、その診断結果をもとに「どの治療から始めるか」「どの医者に頼むか」を決めて、実際に手術に入る段階です。診断と治療を混同して同時並行で進めると、優先順位を誤ったり、費用が想定以上に膨らんだりするリスクが高まります。

この記事は、その「治療計画」を立てるための全体マップです。細部の手順は後続の各記事に譲り、まずは4つのポイントがどうつながっているかを俯瞰できるようにします。

①何から刷新するか、優先順位のつけ方

社内には「変えたいもの」がいくつも見つかっているはずです。しかし、すべてを同時には進められません。予算にも自分の時間にも限りがあるからです。

優先順位をつける最もシンプルな方法は、「影響範囲」と「緊急度」の2軸でマトリクスを作ることです。

たとえば、サポートが切れたサーバーの上で基幹業務が動いているなら、影響範囲も緊急度も高く、最優先です。一方、一部の担当者しか使わない古いツールの使い勝手が悪い程度であれば、後回しにしても大きな問題は起きません。

「一番目立つもの」や「一番古いもの」から手をつけたくなりますが、それが必ずしも一番危ないとは限りません。判断に迷ったら、それが止まったときに会社のどこまでが止まるかを考えてみてください。この考え方の詳細は先代の代からのサーバーが壊れたら何が止まる？単一障害点の洗い出し方で扱っています。

よくある失敗パターン「声が大きい部署から着手する」

優先順位づけで承継社長が陥りやすい失敗が、「一番強く要望してきた部署・人から着手する」というパターンです。声の大きい古参役員や、日常的に不満を口にする部署の要望は耳に入りやすく、つい応えたくなります。しかし、それが会社全体にとって最優先とは限りません。

たとえば、経理担当者から「請求書の作成が面倒」という声が毎日のように上がっているとします。たしかに改善すべき課題ですが、もし同時に受注管理のシステムが老朽化したサーバー上でギリギリ動いていて、いつ止まってもおかしくない状態だとしたら、優先すべきは間違いなく後者です。受注が止まれば売上そのものが止まりますが、請求書作成の手間は「不便」の範囲にとどまるからです。

この判断を誤らないためには、要望してきた本人の温度感ではなく、「それが止まったとき、会社のどこまでが止まるか」という客観的な基準に立ち返ることが重要です。声の大きさと重要度は、必ずしも一致しません。

優先順位マトリクスを実際に埋めてみる

マトリクスは頭の中で考えるだけでなく、紙やExcelに書き出すことをおすすめします。社内で「変えたい」と挙がっているものを思いつく限りリストアップし、それぞれについて次の2つの問いに答えてみてください。

• 影響範囲：これが止まったら、会社のどの業務まで連鎖して止まるか
• 緊急度：あとどれくらい持ちこたえられそうか(サポート切れの時期、担当者の退職予定、契約更新のタイミングなど)

この作業をやってみると、「なんとなく古いから危ない気がする」という感覚だけで判断していたものが、実は影響範囲が狭く後回しでよいとわかったり、逆に「特に問題を感じていなかったもの」が実は最優先だったと気づいたりすることがあります。感覚と実態のズレを可視化することが、このマトリクスの一番の効能です。

②発注する前に、社内で決めておくこと

優先順位が決まったら、すぐに開発会社に相談したくなるところですが、その前に社内で固めておくべきことがあります。ここを飛ばすと、相談の場で「で、何をお困りですか」と聞かれて答えに詰まったり、後から「言った・言わない」のトラブルになったりします。

最低限決めておきたいのは次の3点です。

• 何に困っていて、何を実現したいのか(現状の課題と、理想の状態)
• かけられる予算の上限(補助金の活用も含めて)
• いつまでに、何が動いていてほしいか(納期の目安)

これらが固まっていないまま相談すると、開発会社側も的確な提案ができません。逆に、ここが整理されているだけで、相見積もりの精度も、提案書の質も大きく変わります。詳しい進め方は刷新を開発会社に相談する前に、決めておきたい3つのことにまとめています。

「困りごと」を整理するときにやりがちな失敗

社内で課題を整理しようとすると、多くの場合「システムが古い」「使いにくい」といった抽象的な言葉で止まってしまいます。これでは開発会社に相談しても、どこをどう直すべきか噛み合った提案は返ってきません。

有効なのは、課題を「誰が」「いつ」「何をしようとして」「何に困っているか」という具体的な行動の単位まで分解することです。たとえば「受注管理システムが使いにくい」ではなく、「営業担当が外出先から受注状況を確認しようとすると、社内のパソコンからしかアクセスできず、電話で事務員に確認を依頼している」というレベルまで具体化します。ここまで書けて初めて、開発会社は「では外部からアクセスできるようにクラウド化しましょう」といった的確な提案ができます。

課題の言語化に自信がない場合は、社内の各担当者に「今の業務で一番時間を取られている作業は何か」「一番『これさえなければ』と思っている手間は何か」を聞いて回るところから始めるとよいでしょう。現場の生の声を集めることが、抽象的な不満を具体的な要件に変える近道です。

予算感をどう作るか

予算の上限を決める段階で、多くの承継社長が「相場がわからないので決めようがない」と足踏みします。しかし、相場を先に調べてから予算を決めようとすると、いつまでも動き出せません。

現実的な進め方は、まず「これくらいまでなら投資してもよい」という自社の体力に基づく上限を仮に置き、その金額感を相談の場で開発会社に伝えてしまうことです。開発会社側も予算感が共有されていれば、その範囲でできる現実的な提案をしてくれます。逆に予算を隠したまま相談すると、身の丈に合わない高額な提案が出てきたり、逆に安すぎて機能不足の提案になったりと、噛み合わない結果になりがちです。

補助金の活用を検討している場合は、申請から交付までのスケジュールも予算計画に組み込む必要があります。補助金頼みで計画を組むと、不採択になったときに全体が止まってしまうため、補助金は「使えたら投資額を積み増せる」くらいの位置づけで考えておくと安全です。

③外注先の選び方の要点

社内の準備が整ったら、いよいよ外注先を探す段階です。ここで焦って1社だけに決めてしまうと、後から「もっと合う会社があったかもしれない」と後悔することになりがちです。

外注先選びで見るべきポイントは、大きく3つに集約されます。

1. 提案書の中身(要件を理解した上での提案か、テンプレートの使い回しか)
2. 契約形態(請負契約か準委任契約か、何が納品物になるのか)
3. 危険なサインの有無(見積もりが極端に安い、質問への回答が曖昧など)

特に先代の時代から付き合いのある会社をそのまま使うか、新しい会社に切り替えるか迷う社長は多いです。どちらが正解ということはなく、今回の刷新内容に合っているかどうかで判断するのが基本です。見極め方は危険な開発会社のサイン10選、承継社長が見極めるポイントを参考にしてください。

先代の代からの開発会社を使い続けるべきか、新しく探すべきか

この判断で迷う承継社長は非常に多いです。先代の代からの開発会社には「システムの経緯を知っている」「関係性ができている」という安心感がある一方、「先代への遠慮から強く言えない」「新しい技術への対応力が未知数」という不安もつきまといます。

判断の目安は、今回の刷新の性質によって変わります。既存システムの延命や部分改修が中心であれば、そのシステムを知り尽くした先代の代からの開発会社に分があります。逆に、基幹システムをゼロから作り直す、クラウドに全面移行するといった刷新であれば、経緯を知っていることのメリットは小さくなり、最新技術への対応力や体制の厚みで比較検討する価値が大きくなります。

いずれの場合も、1社だけに絞らず相見積もりを取ることをおすすめします。先代の代からの開発会社であっても、他社と比較されることで提案の質が上がることは珍しくありません。相見積もりを取るとき、条件をそろえるための伝え方も参考に、公平な条件で複数社を比較してみてください。

提案書のどこを見れば「テンプレートの使い回し」を見抜けるか

提案書を受け取ったとき、非IT出身の社長がその中身を評価するのは簡単ではありません。専門用語が並んでいると、それだけで「しっかりした提案だ」と錯覚しがちですが、見るべきポイントは意外とシンプルです。

一番わかりやすいサインは、自社の課題や社内の固有名詞(部署名、業務フローの通称など)が提案書の中にどれだけ具体的に登場しているかです。相談時に伝えた自社の状況を踏まえた提案であれば、当然その内容が反映されているはずです。逆に、どの会社にも当てはまりそうな一般論と機能一覧だけが並んでいる提案書は、テンプレートをそのまま流用している可能性が高いといえます。

もう一つの見極めポイントは、課題に対する「なぜその解決策なのか」という説明の有無です。単に「クラウド化します」「AIを導入します」と書いてあるだけでなく、「御社の場合はこういう課題があるので、この方法が適している」という論理がセットになっているかを確認してください。

④現場を巻き込むことの重要性

最後に、意外と見落とされがちなのがこのポイントです。刷新の中身と発注先が決まっても、現場の協力が得られなければ計画は止まります。

特に「今のままでいい」という古参社員の反応は、多くの承継社長が最初にぶつかる壁です。これは悪意ではなく、これまでのやり方に慣れているだけのことがほとんどです。頭ごなしに変化を押し付けるのではなく、なぜ変える必要があるのか、現場にとって何が楽になるのかを丁寧に説明することが、結果的に一番の近道になります。

現場を巻き込まずに刷新を進めると、システムができあがっても誰も使わない、という最悪の結果を招きかねません。向き合い方の具体的なヒントは古参社員の「今のままでいい」が招く停滞と、向き合い方の最低ラインで紹介しています。

「現場が使わないシステム」はなぜ生まれるのか

刷新プロジェクトが技術的には成功したのに、蓋を開けたら現場が使ってくれない、という事態は珍しくありません。この原因の多くは、システムの中身そのものではなく、導入までのプロセスにあります。

典型的なのは、経営層と開発会社だけで要件を決めてしまい、実際にそのシステムを毎日使う現場の担当者が蚊帳の外に置かれるケースです。現場からすれば、ある日突然「来月からこのシステムに変わります」と告げられるだけで、自分たちの意見が反映された実感がありません。使い勝手に多少の不満があっても、それを言い出す機会がなかったため、不満を抱えたまま渋々使う、あるいは裏で従来のExcelやFAXを使い続ける、という状況が生まれます。

これを防ぐには、要件を固める段階から、実際にシステムを使う現場の担当者を最低1人は巻き込むことが有効です。完璧な合意形成までは不要ですが、「意見を聞かれた」という実感があるだけで、現場の受け止め方は大きく変わります。

説明会や試用期間を設けるタイミング

現場の巻き込みは、システムが完成してから一度だけ説明会を開くのでは遅すぎます。理想的には、次の3つのタイミングでそれぞれ現場と接点を持つことです。

1. 要件を固める前：現場の困りごとをヒアリングし、何を解決したいシステムなのかを共有する
2. 開発の中盤：試作段階のものを見せて、イメージと違う部分がないか確認する
3. リリース前後：実際の操作方法を説明し、しばらくは並行運用や質問窓口を用意する

特に③のリリース前後は、古参社員ほど「前のやり方の方が早い」と感じやすいタイミングです。ここで突き放してしまうと、せっかく巻き込んできた効果が水の泡になります。最初の1〜2週間は多少非効率でも、新しいシステムに慣れるまでの移行期間だと割り切って、質問しやすい体制を維持することが定着の鍵になります。準備の進め方は古参社員を説得する、システム刷新の説明会の準備と進め方でも詳しく扱っています。

次のステップへ

ここまでの4つのポイント、①優先順位のつけ方、②発注前の社内準備、③外注先の選び方、④現場の巻き込み方は、それぞれ単独の作業ではなく、一つの流れとしてつながっています。優先順位が決まらなければ社内の準備は進まず、社内の準備が甘ければ良い外注先には出会えず、外注先が決まっても現場が動かなければ絵に描いた餅で終わります。

逆にいえば、この4つを順番通りに押さえていけば、大きな遠回りをせずに刷新を前に進められるということでもあります。焦って外注先を先に決めてしまったり、現場への説明を後回しにしたりすると、どこかの段階で必ずつまずきます。この記事を全体マップとして手元に置きながら、一つずつ確実にクリアしていくことをおすすめします。

この4つを一通り押さえたら、いよいよ実際に発注し、開発会社とやり取りしながらプロジェクトを進めていく段階に入ります。契約後の付き合い方や、検収の進め方、トラブルが起きたときの対処法については、次の段階で詳しく扱っていきます。焦らず、一つずつ順番に進めていきましょう。