なぜ、承継後の刷新は「焦らない方がいい」のか
はじめに、正直なことをお伝えします。ITを生業にしている私自身、自社の社内システムをきちんと作ったのは、実はつい最近のことでした。それまではExcel中心の運用で、会社の規模的にも、それで何とか回っていたからです。承継してすぐの私がしたのは、システムの刷新ではありませんでした。リーマンショック後の立て直しを最優先に、お客様の獲得と経営基盤の安定に集中し、気づけば十数年が経っていた——というのが実際のところです。
大きな変革は既存社員との軋轢を生むと考えて、最初に手をつけたのは総務や購買といった、紙での運用が多く残っていた領域でした。まずは「データ化する」という、ごく初歩的なところから。そこから採用や就業規則、待遇面の改革を少しずつ進め、経営基盤が安定してきて、やっと余力ができたところで、社内システムの開発に踏み出しました。
承継直後は業務を見直す好機です。ただ、好機であることと、いま急いで大きく作ることは、別の話。承継直後の大きな投資が失敗すれば、「新しい社長は大丈夫なのか」という社内の不安に直結しかねません。
システムを生業にしている人間ですら、順番を守りました。だから私は、「承継したら、まず基幹システムを刷新すべきだ」とは言いません。焦らず、本当に必要な分だけを、確実に。それが、いちばんの近道だと考えています。
どこから、どれくらいの規模で始めるか
では、後継の経営者は、何から始めればいいのか。私の答えは明確です。紙やExcelでの間違いを無くせる領域から、小さく始めること。総務・購買のような、手作業のミスがそのまま損失や手戻りにつながりやすい業務は、システム化の効果が分かりやすく、現場も納得しやすい。逆に、要件を固めないまま、現場の要望を丸呑みして一気に作ろうとすると、リスクも投資も一気に膨らみます。
ひとつ補足させてください。「小さく始める」と言っても、その小ささは会社によってまったく違います。10ほどの機能から始めるのが適切な会社もあれば、業務の芯を支えるために、最初から50を超える機能が必要な会社もあります。大事なのは数の大小ではなく、「本当に必要か」を一つひとつ見極めること。必要なら、最初から相応の規模で作ります。逆に、要望として挙がっても、根本原因に立ち返れば不要だと分かるものは、思い切って作りません。
パッケージソフトとの向き合い方も、同じ考え方です。既製のパッケージで足りるなら、それがいちばん堅実です。けれど、業務の芯（コア業務）に、パッケージがどうしても届かない——そこを我慢して、業務のほうを仕組みに合わせて歪めてしまうと、かえって現場が疲弊します。
そういうときは、フルスクラッチで作り直すのが正解になることもあります。その場合でも、原則は変わりません。根本原因から必要な範囲を見極め、要件を固めてから、段階的に育てていく。だから、たとえ相応の規模の刷新であっても、賭けにはならないのです。
そして、始める時期に「承継の前か後か」はさほど関係ありません。承継の前後を問わず、本当に必要になったタイミングが、その会社にとっての適期です。承継したから急ぐ、のではなく、必要になったから始める。この順番を守れるかどうかが、最初の分かれ道になります。
承継後の刷新で、つまずくパターン
小さく始めるとして、それでも承継後ならではの落とし穴はあります。代表的なものは、次の3つです。
- 先代の時代の業務が属人化・ブラックボックス化している
- 現場（既存社員）の様子見・不信を招いてしまう
- 現場の要望を丸呑みして「作りすぎ」てしまう
ひとつ目は、先代の時代の業務が属人化・ブラックボックス化していること。長年回ってきた業務ほど「なぜそうしているのか」が言語化されておらず、担当者の頭の中にしかない。これを整理しないまま仕組みに置き換えると、動かなくなります。
ふたつ目は、現場（既存社員）の様子見・不信です。新体制の変革には、期待と同時に警戒も向けられます。現場の実務に本当に効くものでなければ、システムは「使われないもの」になってしまいます。私が総務・購買から、しかもデータ化という地味な一歩から始めたのも、この現場の空気を無視しなかったからでした。
そして最大の落とし穴が、要望を丸ごと積み上げてしまうこと——言い換えれば、「作りすぎ」です。承継直後は決めることが多く、現場から挙がる「あれも欲しい、これも欲しい」をそのまま要件にしてしまいがちです。しかし、ここで立ち止まれるかどうかが、後の成否を大きく分けます。
成否を分けるのは、結局「要件定義」
私はこれまで多くの開発を見てきましたが、プロジェクトの成否を最も左右するのは、華やかな技術でも開発スピードでもなく、最初の要件定義でした。そして、率直に申し上げると、私がたどり着いた結論はこうです。
最もバグの少ないシステムは、必要最小限の機能でできている。だから、作らずに済むなら、その機能は作らない。
お客様からは、よく「こんな機能が欲しい」とご要望をいただきます。そのとき私が最初にお聞きするのは、機能の中身ではありません。「何に困っているから、その機能が欲しいのですか」ということです。そして、その困りごとが、そもそもどうして発生しているのか。根本原因を、お客様と一緒に特定していきます。
根本原因が分かると、実は、本当に必要な機能は最初のご要望とはまったく違うものだった、ということが少なくありません。要望どおりに作らなかったからこそ、正解にたどり着けた、というケースです。こうした一つひとつの積み重ねは、とても地味です。けれど、この地味な作業こそが、要件定義であわや失敗を防ぐ、いちばんの特効薬だと考えています。
費用を膨らませる一番の原因は、開発そのものよりも「手戻り＝作り直し」です。曖昧なまま、あるいは要望を丸呑みしたまま進めると、後半で必ずしわ寄せが来ます。逆に、最初に「本当に要るものだけ」を見極めて、整合性の取れた設計に落とし込めていれば、後からの作り直しは起きません。
経営を継いだ立場が、要件定義に入るということ
ここが、私自身が一番お伝えしたいところです。要件定義でつまずく典型は、「経営が実現したいこと」と「現場の実務」と「システムの仕様」の三者が、うまく翻訳されないことにあります。経営の言葉のまま開発に渡すと現場とずれ、現場の要望をそのまま積むと経営の狙いから外れる。この翻訳のズレが、要件の甘さの正体です。
経営の狙いを現場の要件に翻訳し、現場の実務を経営の言葉に戻す。その両方を、一人の頭の中で橋渡しできる。
私は、経営を継いだ立場として会社の意図が分かり、同時に、要件定義・設計そのものを自分の手で行えます。だからこそ、「その機能は本当に必要か」を、経営の視点で早い段階に問い直せる。これは「私だから成功する」という話ではなく、なぜ成功の確度が上がるのか、という理由です。
その結果は、実績にも表れています
ある内装業者様のシステムは、2014年に45機能でリリースして以降、十数年で450機能以上へ拡張し、その間の作り直し（再開発）はゼロ。ある食品会社様のシステムは、運用5年で要件定義の不備ゼロ・設計書の不備ゼロを実現しています。
（2014年）
（十数年）
これらの実績の要件定義や設計には、いずれも私自身が携わりました。私は要件定義や設計の仕事が本職で、社長業の合間に時間ができれば、社員と一緒にその作業に取り組んでいます。名人芸の話をしているのではなく、この関わり方そのものが、上のような結果につながっている——そうお伝えしたいのです。
とはいえ、属人では終わらせない
こう書くと、「その社長がいないと成り立たないのでは」と思われるかもしれません。そこは、はっきりお伝えしておきます。私が大切にしているのは、名人芸ではなく、再現できる進め方です。
曖昧な要件定義をしない、必要最小限を見極める、整合性の取れた堅実な設計に落とす、設計どおりに開発してテストで裏づける——この一連の流れを、私個人の勘ではなく、チームで再現できる方法論として積み上げてきました。だからこそ、リリースして終わりではなく、その後も作り直しなく育て続けられます。一人に依存する会社ではなく、確かな進め方を持つ会社であること。承継後の長い付き合いを考えれば、ここはむしろ安心していただきたい点です。
誠実なやり取りが、長く残るシステムをつくる
最後に、私が最も大事にしていることをお伝えします。私たちは、システムを売ることを目的にはしていません。お客様と一緒に考えて、不要だと思えば「これは要りません」と正直にお伝えする。逆に、本当に必要だと思う機能は、こちらから提案する。そういう会社と会社、突き詰めれば人と人との誠実なやり取りこそが、中長期的なパートナーシップの土台だと考えています。
必要のないものまで作れば、その分だけ費用がかさみ、バグの温床も増える。だから「作らない」という提案ができることは、私たちにとって、正直さの証でもあるのです。
二代目の一歩を、確かな成果に
事業承継のタイミングの見直しは、正しく順番を守り、要件を見極めれば、「失敗が怖い賭け」ではなく、「焦らず踏み出せる、確かな一歩」に変えられます。確かな芯から、本当に必要な分だけを、確実に。その積み重ねが、10年先、20年先まで長く残るシステムになります。
私自身も事業を受け継いだ立場です。代替わりの重みも、失敗できないというプレッシャーも分かる伴走者として、まずは現状の課題からご一緒します。打合せがリモートで可能なら、名古屋・横浜・東京以外でも大歓迎です。
アイピーシー株式会社
