散発的な開発はやめる。システムは全体構想が大事

個別のシステム開発

現場部門のリクエストに応えるため、散発的な個別のシステム開発がよく行われます。もちろん社内システムは、経営者や現場を助けるために存在していますから、個別開発自体を否定するものではありません。

たとえば、消費税のインボイス制度導入による販売管理(または債権管理)システムの改修。法律改正に伴うものは必須です。早めに準備しておかなければなりません。また、経営者から指示された、経営戦略上重要な業務にかかるシステム開発やデータ分析。これも早急に対応すべきものと言えます。

しかし、無条件に散発的な個別開発を繰り返すと、社内システムや情報システム部はとんでもない状態に陥ります。

散発的な個別開発の弊害

いったいどんな状態に陥るのか? ITのプロではない経営者や現場部門の方にも実感してもらえるように、具体的に書きたいと思います。

開発の重複

個別開発でその業務専用の機能・メニュー・マスタ・データを開発すれば、社内システムのあちこちに、似たような機能・メニュー・マスタ・データを持つことになります。

たとえば、上長に申請して承認をしてもらう「承認機能」。さまざまな業務プロセスで発生します。個別システム内で単独開発すべき承認機能もあると思いますが、全体感を持って開発していれば、共通化して統合できることも少なくありません。

また、商品コードで整理される「商品マスタ」もそうです。営業部が見積段階で使う「商品マスタ」、受注段階で使う「商品マスタ」、購買部が発注段階で使う「商品マスタ」と、過去に異なる3つの商品マスタを持っていた会社もありました。

業務の増加

マスタ・データの重複は開発だけでなく、マスタ保守・データ整備等の運用のムダも生み出します。たとえば、マスタに変更があった場合、共通化していれば修正は1カ所で済みますが、複数の類似マスタがあれば、その数だけ直さなければなりません。

データの場合は、もっと厄介です。たとえば、営業部が販売管理システムに入力した「売上金額」と、経理部が債権管理システムに入力した「請求金額」が異なる場合、どちらが正しいのか? 理由は、経理部が直前の金額改定を反映してないだけかもしれませんし、営業部の単純な入力ミスかもしれません。

いずれにせよ、複数の類似データがあると、相互チェックや確認作業が必要です。仮に販売管理システムと債権管理システムがデータ連携していれば、「売上金額」と「請求金額」が異なることはありません。

業務の非効率化

システムを新しく作る場合は、一から機能・メニューを作り、その構成・配列を考えることができます。しかし、現行システムを改修する場合は、既存の機能・メニューと新しい機能・メニューが並存します。

つまり、「A→B→C」という業務プロセスが、「A→B´(ビーダッシュ)→C」になったりします。機能・メニューがあちこちに散逸し、不自然な業務フローになったり、迂回的なプロセスで余計な手間が発生するわけです。

改修に改修を重ね、業務プロセスが迷路のようになってたり、似たような機能がありすぎてメニュー名を見てもどんな機能かわからないシステムも珍しくありません。

経営管理の増加

個別システムの数だけデータは散逸しているので、データの集計・分析は大変です。そのため、経営管理資料を作るために、たいがい各個別システムからデータをそれぞれ転記する形で、別途Excelが発生します。

1個のExcelファイルで済めばまだ良いほうで、A部門で作成したExcelを、B部門のExcelに一部転記して、さらにそのExcelの一部を経営管理部が自部署のExcelに転記することも、少なくありません。いわゆる「Excelのバケツリレー」です。

このような場合、BIツールを活用すればよさそうですが、それもそう簡単な話ではありません。散発的に開発された個別システムは、経営管理で使うことまでは意図していません。生データのままでは使えず、人によるデータの選別・内容修正、データ連結の際は粒度・更新タイミングの調整など、手作業が必要なこともしばしばです。

レスポンスの低下

システムは、最初に開発された時の業務を前提に、データベースを設計、必要なスペックを決めています。ですから、その後の改修によって、データ項目が追加されたり、データ量が増えたり、データを引き出す・参照する頻度が増えたりすれば、レスポンス(処理速度)は落ちます。※スクラッチ開発の場合

保守費用の増大

システムは作って終わりではなく、リリース後、安定して長期間稼働させることが重要です。個別システムの数が多いと、情報システム部はその数だけ異なる環境を保守します。

異なる設置場所(クラウド・データセンター・自社サーバー)、異なるハードウェアの構成・設定、異なる周辺機器の種類・設定、異なるOS・ミドルウェア・アプリケーション等の組み合わせ(各ソフトのバージョンの相違含む)などなど。個別システムの増加は保守費用と作業負荷を確実に増やします。

一方で、使わなくなったシステムや機能・メニューがあれば、その分、保守費用を減額したいところですが、それも一概にはいきません。過去データを見るために旧システムを置いておくと保守は継続します。使わなくなった機能・メニュー分だけでの減額等、ベンダーは受け付けてくれません。

つまり、旧システムを廃棄しない限り、新旧両方の保守費用が重複してかかることになります。

システム全体の構想を考える

特定の部署の特定の業務を処理するために個別システムを作る、という考え方は、一見フットワークが早くて良さそうに見えます。しかし、全社全体で見ると、むしろ弊害のほうが気になります。散発的な個別システムの開発は、緊急性や重要性を考慮して限定的に扱うべきです。

では、どうすればよいのか? 社内のシステム全体をどうしていくか、ある程度方針を持つことです。これを「システム構想」「システムのグランドデザイン」等と言ったりします。

システム構想があれば、各システムの役割や守備範囲が明確にになり、マスタ・データをどのように共有し、機能・メニューをどうしていくかを整理できます。

ですから、簡易的なものでもよいから、まず先にシステム全体の構想を考えること。これが結果的に、開発や業務の重複を抑え、開発コスト・保守費用の低減につながり、本当の意味で経営や現場に良いシステムをもたらします。