見出し画像
Photo by ya_ya_musume

ICTシステム構築プロジェクトがうまくいかない根本原因は何か？

UMEZO

今や殆どの会社でコンピュータとインターネットを利用した業務支援システムが導入されています。業績向上に寄与していると思いますが、一方で正しく使いこなせておらず、また膨大なコストを掛けて常に修正し続けている例も非常に多く見受けられます。それどころか、業務のニーズに対応することを諦めているところもあります。
うまくいかない根本原因はなんであるか、ここで探ってみたいと思います。


業務の観点

まず、ICT（Information and Communication Technology)を使っているシステムとしては、基幹業務が挙げられます。基幹業務とは、その会社には無くてはならない機能の事を言います。例えば下記のようなものです。

  • 見積 / 売上 / 会計 / 顧客管理
    どの会社でも必要になる基本のものですね。しかし、独自文化を生みやすい部分でもあります。

  • 設計 / 製造計画 / 製造管理 / 在庫管理 / 調達 / 品質管理 / 物流管理
    製造業で必要になるものです。中小企業以上では手作業での管理は不可能ではないでしょうか。

  • 決済 / 審査・承認 / 代理店管理 / ポイント管理 / 不正取引検知
    金融業で必要になるものです。正確性や稼働条件も厳しいのが特徴です。

  • 充填計画 / 配送計画 / 在庫管理 / 調達 / トレンド調査
    自動販売機やプロパンガスなど、生活に必要な事業で必要なものです。

各業種・業態によって特殊なシステムが存在しています。機能が業務観点を跨ぐように作られてしまっていると、システムは複雑化しがちで、ちょっとした改修でも多くの費用が必要になったりします。
殆どの場合は各システムはお互いに連携する必要があり、日時バッチでのファイル連携やDBでの連携等がされていると思います。情報の鮮度が落ちるばかりではなく、後段にある処理ほど間違いに対する修正等が逼迫しがちで、結局は現場の人力対応になる傾向があります。

役割の観点

このようなシステムを、役割の観点で区分けしてみましょう。

  • 人力では手間のかかる作業を行う
    顧客管理・注文・販売・集計・運用監視等

  • 記録に残す
    審査・承認・作業履歴・出入金履歴・設計等

  • トレンドを見る
    季節変動・品質変動等

  • 記録に残す
    審査・承認・作業履歴・出入金履歴・設計等

  • 未来を予測する・計画を立てる
    業務最適化・配送計画等

どんな業種・業態においても、ICTで行われているシステムの特徴は、この5つに収斂されるのではないでしょうか。つまり、特徴にあわせてシステムが存在するわけで、異なる特徴を持つ内容を一つのアプリとして作ってしまうと、改変が大変になってしまいます。

文化の観点

さらに、別の観点で見てみましょう。

  • どこの会社でも同じ処理
    税金計算・売上計算・退勤記録・人事考課

  • その会社特有の処理
    キャンペーン・生産計画・在庫管理・設計・品質・配送）の組み合わせ

この「その会社特有の処理」にあるものは何でしょうか？その企業の文化であり、その企業が他社と差別化できる収益の源泉に相当するものです。所謂パッケージ製品(CRM/ERP等)は、どこの会社でも同じ処理として利用し、その会社特有の処理については、パッケージをカスタマイズするのではなく、外部にアプリケーションとして保持すべきなのです。

一昔前のパッケージ製品やメインフレームでのアプリケーションは、外部とのやり取りが難しく中に作り込む必要がありましたが、令和の時代のアプリケーションの殆どは、外部とのやり取りを行うためのインターフェースが用意されています。

複雑さの助長がリスクを生む

では、「自社特有」の分野について、どのようなものを作ればより効率が上がるのでしょうか。
基幹システムで扱われるアプリケーションのほぼ全ては、

  • 　データ

  • 　ロジック

  • 　手順（業務プロセス）

  • 　画面

で構成されています。つまり、それぞれの役割に応じたモジュールを作り、それを繋げあわせることが必要です。

この簡単で当たり前のことが、現場では出来ていないのが現実です。なぜか？開発言語が高級なため、何でも出来てしまいます。アーキテクチャを策定せずに作り始めてしまうと、役割分担の無い一枚岩のアプリが出来てしまいます。
この状態でアプリケーションに追加変更を加えていくと、ロジックやデータの適切な削除や進化醸成が出来ず複雑化され（スパゲッティ状態）、変更を加えるための影響分析に時間がかかり、変更に対して品質の低下（リスク）を生み、結果的にコスト増に繋がります。また、コストが掛かることで業務施策を諦める等の負の循環に陥ります。

パッケージ製品で安く完結すると信じ込み、やってみたら出来なくて、細かい作り込みを延々と行うプロジェクトのなんと多いことか... リスクとコストを膨らませているだけです。しかも、ICT業界は人材不足の為、プロフェッショナルとは言い難い人材が実装をしているケースもよくあり、さらなる品質の低下を招いている一因にもなっています。

驚愕の事実に、日頃モダナイゼーションやDXを声高々に叫んでいる大企業も、このパッケージ製品のカスタマイズによる出口なきトンネルから抜け出していないのです… ああ、嘆かわしい…

これが、冒頭に述べた「うまくいかない」プロジェクトの最たる要因だと思います。

アーキテクチャに立ち返る

アプリケーションアーキテクチャを正しく制定し、役割分担を明確にしたアプリケーションを構築することで、リスクを下げ、品質を向上させ、コストを下げる事ができます。これが重要。
プロフェッショナルな仕事をする人間こそが、機能的なことはもちろんのこと、最終的に美しさまでも兼ね備えたアプリケーションを提供します。

一段深堀りすると、アプリケーションアーキテクチャとして正しく設計しても、最大の効果を引き出すにはデータとロジック部分をどう設計・実装するかが鍵となります。
ロジックの書き方には手続き型と宣言型の２種類がありますが、情報工学を学んできた殆どの方が手続き型のロジックを書いています。これは現在のコンピュータの動作に準じた方式であり、プログラミングの基礎であるので致し方ないところではあります。
一方、「重量が500g以上の場合、配送料として100円を追加する」等と、業務は宣言型で書かれているのが普通です。ここにギャップが有り、プログラマーが宣言型のロジックを手続き型に直しているのが現実なのです。認識の齟齬やバグの発生が多く発生する原因であり、少しの修正にも多大な時間を必要としてしまいます。

従って、ロジックを宣言型で書くことで、業務側もそのロジックを理解することができます。これはその後のロジックの改修、つまり文化の醸成に大きく良い影響を与えています。これには、ロジックを宣言型で書ける「ルールエンジン」がまさしく当てはまり、品質の向上と改変の容易さ、コストの削減には直結します。

まとめ

システム構築プロジェクトがうまくいかない原因は、

  • 不適切なアーキテクチャ

  • 企業文化を大切にしていない

  • パッケージ製品を無理矢理カスタマイズ
    というところが見えてきます。

これを解決するには、

  • 適切なアプリケーションアーキテクチャを取る

  • 企業文化を保持・管理し続けられる構造にする

  • 適切な開発手法の検討や業務部門とICT部門とよく会話することで、リスクとコストを最小にする
    ということになりますね。

こちらも御覧ください！

いいなと思ったら応援しよう！