2015年に出版した
『業務効率UP+収益力UP 中小企業のシステム改革』幻冬舎 (2015/9/18) より
書籍内のコンテンツをタイトルごとに公開いたします。
コンテンツの最後に、コンサルタントのコメントを追加しておりますので、合わせてご覧ください。
P.135～
第4章
「To Beモデル」のシステム構築＆改修で、業務効率・収益力を向上させる
事例１：株式公開を控えてＩＴシステムの刷新を迫られた会社
年商１４０億円、社員数３７０名の建設会社Ｋ社は、株式の新規公開（ＩＰＯ：Initial Public Offering）を行うことになりました。
企業が株式を公開することを、英語でGo Public（おおやけにする）と言うように、上場企業になると、財務諸表をはじめとして、経営の内側をかなりの程度でオープンにしなければなりません。
Ｋ社も、株式公開準備のために、監査法人の指導を受けて、社内体制の整備にとりかかりました。その一環として、会計システムや販売管理システムを新しく構築したのです。ところが、監査法人に言われるがままに導入した新システムに不具合が多発して、業務が滞りがちになりました。社内のシステム部門が総出で問題対策に取り組み、何とか業務が回る程度にはなったのですが、その後も新システムの評判は芳しくありませんでした。
状況を憂えた管理本部長が、システム改革の専門家である私どもの会社に相談を持ちかけてきたのは、その頃のことでした。
そもそも、Ｋ社では、新システム導入の２年前にも、システムを刷新していた過去がありました。それは、ＰＣサーバーを用いて業務をオンラインで統合したオープンシステムで、受注や売上や支払いの情報をリアルタイムで登録して、全国の支店のどこからでも瞬時に参照できるようにしたものでした。
この旧システムは、受注情報や売上情報を同時に登録可能であるなど、使い勝手が良く社内の評判も上々でした。
しかし、使い勝手の良いシステムというものは、おうおうにしてセキュリティが甘いものです。翌年、株式公開準備のために、業務調査に乗り込んできた大手監査法人は、旧システムの内部統制の不十分さを問題にしました。そして、監査法人の子会社のシステムインテグレーターが販売している、別のシステムに入れ替えるように指示をしたのです。
旧システムが、導入からわずか１年でリプレースするように命じられてしまったというだけでも、費用的にはだいぶムダです。
とはいえ、株式公開という新たな目的ができたのですから、仕方がありません。Ｋ社は、監査法人の命に従って、その子会社の新システムを導入することにしました。実際に新システムができあがるまでにはさらに１年がかかりました。
この新システムは、おおまかに言えば、バックエンドの会計システムと、フロントエンドの販売管理システム、そしてそれらを結合させる統合情報システムとに分かれていました。
そして、バックエンドの会計システムのほうは、さすがに監査法人の子会社が作っただけあって、それなりの出来栄えだったのですが、現場の人間が使うフロントエンドのシステムの出来があまりよくありませんでした。
ちょっと試しに使ってみただけでも、遅延やエラーなどのシステム障害が多発して、とても業務に使えるようなものではなかったのです。いくら内部統制が強化されていても、まともに動かないシステムを業務に使うわけにはいきません。
Ｋ社は、株式上場のスケジュールを延期し、とりあえずは旧システムをそのまま使いながら、必死で新システムの手直しをしました。ベンダーがあまりあてにならなかったので、Ｋ社のシステム部門の人間が修正作業を行いました。
さらに１年後、何とか使えるように改修したはずの新システムですが、仕様変更や品質管理の不備によってトラブルが多発し、運用が混乱します。システムダウンやデータ不整合も頻発し、現場の不満も高まっていました。
なにしろ、トラブルを想定して分散システムにしたはずなのに、一カ所がダウンしただけでシステム全体が止まってしまうような状態だったので、分散システムの意味もありません。なぜここまで低品質のものができてしまったのか、誰にも理由がわかりませんでした。
そこで私たちの会社で調べたところ、おおむね次のような事情が原因であることがわかってきました。
開発途中の仕様変更
当初計画されていたシステムは、株式公開を目的とした管理部門向けのシステムという位置付けでした。
そのため、セキュリティ強化を目的に、各営業所には分散サーバーを配置し、それぞれの拠点で入力したデータのみを参照可能とすることを想定していました。
ところが開発途中に組織変更が行われ、それぞれの拠点で、他拠点のデータを見られるようにしなければならなくなりました。
そこで、全社データベースを設置し、ローカルデータベースと同期をとるようにしました。ところが、このデータベースの同期が、技術的に多くの問題点を抱えていたため、障害が多発しました。
開発が始まってからの仕様変更は、スケジュールに遅延をもたらすばかりでなく、完成したシステムの品質にも悪影響を及ぼします。
当初からの仕様に組み込んでおけば、もっと技術的にも容易でスマートなシステムができたはずです。
現場の実態からかけ離れた仕様
当初の仕様では、営業マンは受注高と売上高で業績評価を行い、技術者は社内施工売上と社内施工原価で業績評価を行うことになっていました。
しかし、これは経営陣が勝手に決めた机上の空論でした。
現場では、営業と技術の職務の切り分けが実質的には不可能だと言われていました。そのため、それぞれを部門で分けて管理することは、システムのスタート時点からすでに不可能でした。
現場のヒアリングを十分に行わずに仕様を策定してしまったために、実際には使えないシステムができあがってしまったのです。
システム完成後に修正することになりましたが、それには多大な手間とコストがかかりました。
（３）業務プロセスのルールがなかったために運用が混乱
このシステムは、簡単に言えば、全国の拠点で入力した見積・受注・工事・売上・支払いのデータを、統合情報システムに集めて管理し、管理帳票を作成する一方で、同じデータを会計システムに渡して財務諸表を作るものでした。
管理部門がある本社にメインフレームを設置し、そこで会計システムと全社の工事台帳（原価）、売掛、買掛を一元管理する統合情報システムを構築し、各拠点からのデータを日次で取り込むことになっていました。
ところが、支払いや売上などのデータ修正が発生した場合に、それをどこで行うかのルールが決まっていませんでした。
フロントエンドシステムのＰＣ端末で行うのか、統合情報システムでまとめて行うのか、それとも会計システムで行って財務諸表にだけ反映させるのか、ルールが決まっていなかったため、実際の運用に混乱が発生しました。
結局、月次決算に間に合わせるために、経理が直接、会計システムで仕訳入力を行いましたが、これが、各システム間での数値の不整合を招く結果となり、一層システムの混乱に拍車をかけることになりました。
ITコンサルタントのコメント（2022年10月14日）
この記事は「IPOを目的とした内部統制強化のためのシステム改修」を例として挙げておりますが、統制の強化は法令対応、規程対応など他にも様々な目的で実施されるもので、よくあるシステム開発の理由になると思います。「統制の強化」は、基本的には「利便性」や「変更の可能性」とはトレードオフの関係になります。ですので、何か制限を設ける際はいつでも、その制限を設ける事によりどこかの業務が滞る可能性を考慮しなければなりません。
そこで必要になってくる点は大きく下記２点であると考えます。
1点目は、「業務プロセスの定義」です。
何かの業務をシステムで実施する場合、元々行っていたあらゆる業務の進め方(担当者ごとの独自の進め方など)を全てシステムで実施できるようにすると膨大な開発が必要になります。ですので、基本的には業務プロセスを整理し、統合し、定義することで、必要なパターンのみをシステム化します。ましてや今回の目的は「統制の強化」にありますので、現場に負荷を強いる性質の統制プロセスを業務プロセスのどこにどう配置すれば業務効率の低下を最小限に抑えられるかを検討することが重要なポイントになってきます。
2点目は、「変更の可能性と範囲」です。
1点目にも通じますが、システムというものは「特定のパターン」を想定して作成します。ですので、前提となるパターンに変更が入ってしまうと不具合が生じます。特に、そのパターンへシステムを最適化すればするほど、変更が入った際の影響は大きくなります。あらゆる可能性を見越したシステム設計はもちろん不可能ですが、可能性が高い変更は考慮した設計にする必要があります。
仮に、前提となるパターンに変更が入った際は、要件や設計への影響確認は早ければ早いほど良いです。業務へ致命的な影響を及ぼす部分の把握を最優先で行いましょう。
システム開発では、業務プロセスの定義、変更の可能性と範囲の検討が無くてはなりません。記事にある例のように、足を引っ張るシステムが構築されないことを節に願います。
