なぜ、多くの基幹システムは
「作り直し」になるのか
最初に、システムが作り直しに追い込まれていく典型的な道筋を整理しておきます。御社の現状と照らし合わせてみてください。
多くの場合、出発点は「曖昧なまま容認された要件定義」です。業務の細部やイレギュラーな処理を詰めきらないまま開発が進み、稼働後に「実はこういうケースがあった」が次々と噴き出します。その都度、場当たり的に機能を継ぎ足していくと、システムの内部はつぎはぎだらけになり、ある機能を直すと別の機能が壊れる、という状態に陥ります。
こうなると、追加開発のたびに調査と検証のコストが膨らみ、保守費用も右肩上がりになります。やがて「これ以上手を入れるより、いっそ作り直した方が早い」という結論に至る。これが、作り直しという名の“二度目の大きな出費”が発生するメカニズムです。
作り直しは、システムが古くなったから起きるのではありません。最初の土台が、拡張に耐えられない作りだったから起きるのです。
事例の概要 ― 内装業者様の10数年
ここで紹介するのは、ある内装業者様のコア業務システムです。
2014年のリリース時、システムは45機能でスタートしました。その中核に据えられていたのは、顧客・案件管理（CRM）です。内装業にとって、どの案件をどう受注し、どう進め、どう完了まで管理するかは、まさに事業の心臓部に相当します。そしてこの「案件の回し方」は、会社ごとに流儀が全く異なります。だからこそ、既製のパッケージに自社の業務を合わせるのではなく、自社の業務に合わせてシステムを一から作る価値がありました。
そこから10数年。システムは450機能以上へと成長しました。注目すべきは、その成長の過程で作り直し（再開発）が一度も発生していないことです。機能を足しても足しても、既存の土台はそのまま使い続けられました。次の章では、その「育ち方」の中身を具体的に見ていきます。
何が増えたのか ―
「案件」を中心に、放射状に育ったシステム
45機能から450機能へ。この拡張は、機能がバラバラに積み上がっていったわけではありません。顧客・案件管理（CRM）という一本の太い軸を中心に、その案件にぶら下がる業務が放射状に広がっていった——これがこのシステムの育ち方を最もよく表しています。
案件を軸に、前後・周辺の業務へ放射状に拡張（450+機能 / 現在）
まず、案件管理を軸に、その前後の業務へと展開していきました。案件に紐づく社内プロセス、原価の管理、そして売上管理へと、業務の流れに沿って機能が伸びていきます。
次に、内装業ならではの業務が深掘りされていきました。協力会社への工事の発注、注文書と請求の管理、工事ごとの原価管理。さらに、工事が終わって引き渡した後のメンテナンス部門の案件管理や、取引のベースとなる得意先・仕入先のマスタ管理へと広がっていきます。これらは、内装業の現場に固有の業務であり、汎用のパッケージでは到底カバーしきれない領域です。
加えて、システムは外へも接続していきました。他システムや外部サービスとの連携が増え、業務の幅が広がっていきます。そして、法改正や業務ルールの変更といった、避けられない環境の変化にも対応を重ねてきました。
これだけ多方向に機能が増えれば、普通なら土台のあちこちに無理が生じます。にもかかわらず作り直しが起きなかった。その理由を、ここから2つの角度で解説します。
作り直しが起きなかった理由①
手戻りを生まない要件定義
最大の理由は、最初の要件定義にあります。私たちが「手戻りを生まない要件定義」として実際に徹底している工夫は、抽象的な心構えではなく、具体的な手順です。
-
METHOD 01業務の例外・イレギュラーケースを、最初に徹底的に洗い出す。
作り直しを生む最大の原因は、稼働後に発覚する「想定外の業務パターン」です。だからこそ、要件定義の段階で、通常の流れだけでなく、例外的なケースやイレギュラーな処理を先に洗い出しきります。後から「実はこんなケースが」が出てこないようにしておくことが、手戻りの最大の予防策になります。
-
METHOD 02決めきれない部分を、曖昧なまま進めない。
要件定義では、どうしても判断に迷う論点が出てきます。そこを「とりあえず後で」と先送りにすると、その曖昧さが必ず後工程で作り直しとして跳ね返ってきます。決めきれない部分こそ、その場で詰めきる。この姿勢が、土台の精度を支えています。
-
METHOD 03将来の拡張を見越して、データ構造とマスタを設計する。
目の前の45機能だけを見て設計するのではなく、その先にどんな業務が足されうるかを見越して、データ構造とマスタを設計します。これが、前章で見た「案件を中心とした放射状の拡張」に10数年以上耐えられる直接の理由です。お客様の各データの意味をしっかりと定義するドメイン管理やテーブルの持ち方を、将来を見据えて設計していたからこそ、後から発注管理も原価管理もメンテナンス管理も、既存を壊さずに足すことができました。
-
METHOD 04実際に使う画面・帳票・メールと、完全に一致するプロトタイプを作る。
要件定義の認識のズレは、言葉のやり取りだけでは消えません。そこで、ユーザーが実際に使うことになる画面・帳票・メールと完全に一致するプロトタイプを作り、実物で認識を合わせます。「思っていたものと違う」という、稼働後に最も多い手戻りを、実物で事前に潰しておくわけです。
なお、私たちはお客様にとって不要な設計書は作りません。これは手抜きではなく、読まれない書類に工数をかけるより、実物のプロトタイプで認識を合わせる方が確実で速いという判断です。手戻りを防ぐことと、ムダな成果物を作らないことは、両立します。
作り直しが起きなかった理由②
拡張に耐える設計
要件定義で固めた土台を、設計でそのまま実装に落とし込みます。ここで効いてくるのが、先ほど挙げた「将来の拡張を見越したデータ構造・マスタ設計」です。
システムの拡張に弱いか強いかは、見た目の機能ではなく、その裏にあるデータの持ち方で決まります。案件・顧客・取引先・工事・原価といった情報の構造を、最初から整合性をもって設計しておけば、新しい機能はその構造の上にそのまま乗ります。逆に、目先の機能ごとにデータをバラバラに持ってしまうと、機能を足すたびに既存との辻褄合わせが必要になり、やがて破綻します。
このシステムが450機能まで耐えられたのは、最初の45機能の時点で、すでに将来の450機能を受け止められる土台が敷かれていたからです。
整合性の取れた設計を、設計どおりに開発し、テストで裏づける。この堅実な積み重ねが、10数年以上にわたる「壊れない拡張」を可能にしました。
パッケージ・SaaSでは、
こうはいかない理由
ここまで読んで、「パッケージやSaaSではだめなのか」と思われた方もいるでしょう。答えは、業務によります。
勤怠管理、給与、会計のように、どの会社でもやることがほぼ共通している業務は、パッケージが向いています。わざわざ自社で作る必要はありません。
一方で、今回の事例に出てきた工事原価管理や、工事後のメンテナンス部門の案件管理は、内装業という事業に固有の業務であり、会社ごとにやり方が違います。こうしたコア業務をパッケージに当てはめようとすると、「できないことを諦める」か「無理なカスタマイズで複雑にする」かのどちらかになり、結局は自社の強みが削られていきます。
共通業務はパッケージで、コア業務はフルスクラッチで。
この使い分けこそが、システム投資をムダにしないための基本です。コア業務は、御社の形に合わせて一から作るからこそ、10年、20年かけて育て続けられます。
まとめ ―
作り直しは「運」ではなく「設計」で防げる
10数年で機能が10倍になっても作り直しが一度も起きなかった。これは、運が良かったからではありません。最初の要件定義で業務の例外まで洗い出し、曖昧さを残さず、将来の拡張を見越してデータ構造を設計し、実物のプロトタイプで認識を合わせた——その結果です。つまり、再現性のある方法論です。
裏を返せば、今あなたの会社のコア業務システムが「もう作り直すしかない」状態にあるとしたら、その原因もまた、最初の土台にあった可能性が高いということです。そして次に作るときは、作り直しのない、育ち続けるシステムを選ぶことができます。
御社のコア業務システムに不満があるなら、まずは現状の課題をお聞かせください。フルスクラッチが適しているかどうかも含めて、率直にお伝えします。