機能を減らす判断に悩む企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、使っていない機能より、使っているが非効率な機能も見直すことを重視して進め方を整理します。
この記事では、基幹システムの再構築で不要な機能を削る判断基準を整理します。機能を減らすべきだとは分かっているが、何を基準に削ればよいか分からないという担当者と、機能削減で費用を適正化したい経営者に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
使っていない機能だけでなく「使っているが非効率な機能」も見直す
不要機能の削減というと、使われていない画面の廃止を想像しがちですが、それだけでは不十分です。毎日使っているが手順が冗長、同じデータを二つの画面で入力している、一つの処理に5画面も遷移する——こうした「使っているが非効率な機能」も、再構築では統合・簡素化の対象です。使用頻度だけでなく、業務効率の視点でも機能を評価することが、投資に見合う改善を生みます。
「残す理由」が説明できない機能は削る候補
削る判断基準は、「この機能がなくなったら誰がどう困るか」を具体的に説明できるかどうかです。説明できなければ、その機能は削る候補です。逆に、担当者が即座に困る場面を語れる機能は、残す必要があります。この問いかけを全機能に対して行うのが、機能棚卸しの本質です。感覚で残す・削るを決めるのではなく、一つずつ理由を言葉にする地道な作業が、適正な範囲設計を生みます。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、「念のため残す」が積み重なって結局全機能を再構築してしまうケースです。「念のため」は、削る判断を避けているだけであり、費用の膨張をそのまま招きます。
また、一律に「使用頻度が月1回以下なら廃止」といった機械的な基準を適用し、月1回だが必須の月次締め処理まで削ってしまう失敗もあります。頻度だけでなく、業務上の重要度も含めた二軸で評価することが必要です。
さらに、機能削減を開発側だけで判断し、現場に確認しないまま進めると、稼働後に「あの機能がない」と発覚して手戻りになります。削る候補は必ず現場と確認し、合意を文書で残してください。
自社で確認できるチェックポイント
機能削減の検討を始める前に、次の点を確認しておくと、判断基準が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
機能削減ならではの棚卸しポイント
基本のチェックリストに加えて、画面・帳票・バッチの一覧、各機能の利用頻度と利用者、「この機能がなくなったら困る理由」の一行説明、同じデータを扱っている重複機能のグルーピング、そして非効率だと感じている操作手順の一覧を確認してください。この棚卸しの結果を「残す・統合・簡素化・廃止」の四段階で分類すると、範囲設計の議論が一気に具体的になります。
機能削減の効果は開発費の圧縮だけではありません。テスト工数の削減、保守の簡素化、新人が覚える画面数の減少という長期的な効果も大きく、稼働後の運用コストにまで波及します。機能が少ないシステムは、壊れにくく、直しやすく、教えやすいのです。
機能削減の進め方では、まず「使われていない機能」を先に除外し、次に「使っているが統合できる機能」をまとめ、最後に「使っているが非効率な機能」を改善対象にする、という三段階で進めると混乱なく整理できます。いきなりすべてを判断しようとすると議論が収束しません。
削減した機能の一覧は、プロジェクト完了後も「再追加候補リスト」として保管しておくと安心です。稼働後にやはり必要だと分かった機能を追加改修する際の参照資料になり、なぜ削ったかの理由も残っているため再検討が効率的に行えます。
延命・部分改善で対応できるケース
機能削減は、全面再構築の前に単独で行うこともできます。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
たとえば、現行システムの中で使われていない画面の非表示化やメニューの整理だけでも、利用者の混乱を減らし、次の再構築時に棚卸しの下地を作れます。費用はほとんどかからず、運用改善としての効果があります。
再構築時に本格的に機能を絞る場合は、棚卸しの結果を「新システムの機能一覧」として定義し、この一覧に載っていない機能は作らないという明確なルールにすることで、開発中の「ついでにこれも」を防ぎます。
機能削減の効果は、一般的に全機能の2〜3割が削減・統合の候補になるケースが多く、開発費にして数百万〜数千万円の圧縮につながります。棚卸しにかかる工数は数人日〜数週間であり、投資対効果は極めて高い作業です。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
機能削減後の構築方針は、残った機能の特性で決まります。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
削減後に残った機能がパッケージの標準機能でカバーできるなら、パッケージ移行への道が開けます。機能削減とパッケージ検討は連動するテーマです。
周辺開発で補うケース
中核は残し、非効率な周辺機能だけを新しく作り直す構成は、機能削減の考え方を自然に適用した進め方です。
スクラッチ再構築が向くケース
スクラッチで全面再構築する場合こそ、機能の絞り込みが最も効きます。範囲が小さいほど開発は速く安くなり、品質も上がります。
マクティズムの見解
マクティズムの見解として、基幹システム再構築で不要機能を削る判断基準では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、使っていない機能より、使っているが非効率な機能も見直すことを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
機能削減の相談では、「減らすことは悪いことではない」というメッセージを、現場にも経営にも繰り返しお伝えすることを大切にしています。機能が多い＝高性能ではなく、必要な機能だけが過不足なくある＝高品質です。この考え方をプロジェクトの共通言語にすることが、削減の合意を得る最も確実な方法です。
相談前に準備しておく情報
機能削減の相談では、画面・帳票・バッチの総数と利用状況の概要、非効率だと感じている操作の具体例が分かると、初回から棚卸しの方針を話せます。現行システムのメニュー画面のスクリーンショットがあると、全体像がすぐ掴めます。
実務では、現行調査で全機能の利用実態を計測し、開発前診断で「残す・統合・簡素化・廃止」の四分類に仕分けたうえで、削減による費用効果を数字でお示しする流れをおすすめしています。
機能を削ることで生まれた余裕を、本当に必要な機能の品質向上や使いやすさの改善に回す。この再配分の発想が、限られた予算で最大の効果を出す鍵です。
身軽なシステムは速く、安定し、変化に強い。機能を絞る勇気が、長く使えるシステムを生みます。必要なものだけを持つ。それがシステム設計における最高の贅沢です。
進め方は、機能一覧の作成、利用実態の調査、四分類への仕分け、現場との合意、の順です。一覧を作り、仕分け、合意する。この三つで機能の適正化は完了します。
なお、機能を削ることに心理的な抵抗がある場合は、「削る」ではなく「優先順位を付ける」と表現を変えるだけで、現場の受け止め方が変わることがあります。今回は対象外だが、次の段階で検討する——この位置づけであれば、現場も前向きに整理に協力してくれます。
機能の数が減ると、テスト工数・教育工数・保守工数もすべて減る。この連鎖的な効果は、開発費の削減以上に長期的な価値を持ちます。
削減の議論では、機能を使っている人の意見を最大限尊重しつつ、全体の投資効果という観点で判断を下す必要があります。個人の便利さと全体の投資効率のバランスを取る。この調整が、推進担当者の腕の見せどころです。
機能を絞ったシステムは、結果として操作が直感的になり、教育コストも下がります。新人が1日で使い始められるシステムは、50画面あるシステムより組織にとって価値があります。
機能削減は決して後ろ向きな作業ではありません。本当に必要なものだけを選び取るという、前向きな設計行為です。その意識を持つだけで、棚卸しの質が変わります。
必要十分な機能だけを備えたシステムは、速く、安定し、愛されます。その姿を目指して、一つずつ判断を積み重ねてください。
削ることは捨てることではなく、磨くことです。本当に必要なものだけが残ったシステムには、無駄のない美しさがあります。
磨き抜かれた機能だけが残ったシステム。それが、長く使い続けられる仕組みの姿です。その姿を一緒に描きましょう。
機能削減の棚卸しは、再構築プロジェクトで最もコスト効果の高い作業です。躊躇する理由はありません。
一つずつ「本当に必要か」と問いかける。地道ですが、この積み重ねがシステムを磨き上げます。私たちもその問いかけに一緒に取り組みます。
必要なものだけを持つ。その判断の積み重ねが、最高のシステムを作ります。
その積み重ねの先に、誰もが迷わず使えるシステムが待っています。
よくある質問
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。画面数の目安と利用状況の概要があれば十分に相談を始められます。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。はい。棚卸しで不要機能を除外するだけで、大きなコスト削減につながります。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。機能削減後に残った機能がパッケージに合うかの確認も、一緒に行います。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。はい。棚卸しだけを先行して依頼いただくことが可能です。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。まず現行の全体像を把握するところからお手伝いします。
