システムに業務を合わせるべき(3)-全社会的最適化

2018年9月15日土曜日

システム開発

t f B! P L

パッケージソフトやプラットフォームの存在意義は、全社最適などという矮小なものではなく、全社会的にITリソースを共有し、社会全体をシステム中心に最適化することにある。

IT人材の有効活用(ソフトウェアの共有)

日本企業の業務システム開発ではよく「車輪の再発明」とよばれる非効率な開発をたくさん行っている。
人事システム・顧客管理システム・労務管理システム・在庫管理システム・生産管理システム....仕様が少し違うだけの似たようなシステムを各会社でそれぞれバラバラに開発している。
パッケージを導入すれば良い話なのだが、「ウチのやり方はよそとは違う!」という論理で開発する。
仮に1000社の会社が開発したとして、1つの開発に10人のIT人材が必要だとしよう。「よそとは違うウチのやり方」とやらを残すために1万人のIT人材を浪費することになる。
このような人材資源の無駄な浪費をさんざんやっておきながら「IT人材が足りない!」と叫んでいるのである。
全社がノンカスタムでパッケージを導入すれば1万人のIT人材を他の仕事にアサインできる。
人手不足も少しはマシになるだろう。

開発を依頼する方も悪いが、引き受ける方も悪い。

POSパッケージを開発している会社で働いたことがあるが、その会社では30社ほどの顧客企業のカスタマイズに対応し、社内の6割ぐらいのITエンジニアをカスタマイズにあてていた。
この人的リソースをパッケージ本体の開発に投入すれば優れたパッケージが開発できるだろうに。

15年もデフレが続いたせいか、企業は人的資源を無駄遣いすることに慣れてしまって、有効活用する方法を忘れてしまったようだ。

パッケージの機能に不足があればベンダーに要請して不足している機能を汎用的な機能として実装してもらえば良い。
パッケージは成長しユーザー全てが便益を受ける。
人的資源の無駄遣いも無い。
要請が断られたら「よそとは違うウチのやり方」とやらに価値が無いということだ、パッケージに合わせれば良い。
ITエンジニア向けの技術書のなかに代表的な業務システムの設計手法を解説した分野がある。
生産管理システム・会計システム・販売管理・在庫管理・給与管理....と様々な業務システムの作り方について解説しているのだが、それほどノウハウが体系化できているのならばなぜそのノウハウでパッケージを開発して売らないのだろうか。謎だ。

パッケージには業務知識の蓄積がある。
パッケージを使うということは業務知識をみんなで共有するということだ、それも世界中で。
日本企業は業務知識を全部自分で作っているが欧米と中国企業はパッケージごと業務知識を買ってきてビルトインしてると聞く。
そんな相手と価格競争できるだろうか。

流通経路の単純化(中抜き)

これはパッケージよりプラットフォームに該当する。
もっとも最近のパッケージはSaaSアプリケーションでサブスクリプション契約で提供するものが多くパッケージとプラットフォームの境界線は無くなっている。
プラットフォームの性質の一つに「流通経路の単純化(中抜き)」がある。Amazon.com などを見てわかるように、ECは流通経路を単純化してしまう。

従来の書籍の流通は、作家→出版社→取次→書店→読書 と最低4段階有ったが Amazon.com は間の取次と書店を中抜きし、作家→出版社→読者 にしてしまった。
さらに電子書籍では作家→読者 も実現している。今のところ出版社には編集・校閲・営業・宣伝などの付加価値があるので簡単には無くならないが、これらのサービスを作家に直接提供するサービスが現れたら出版社は無くなるかもしれない。
これらの中抜きにより全国の小規模書店は消滅した。
取次も縮小は避けられないだろう。

パッケージの発想では業務知識を組み込んだ機能を売るという発想しか無いが、プラットフォームではこれに人間を巻き込むことによりサービス化し流通経路と取引の仕方、働き方を変えてしまうことが可能になる。
たとえば現在の会計ソフトはパッケージをクラウドに載せただけだが、これに人間の税理士や会計士を取り込み財務をクラウドソーシング的に提供すれば企業と税理士や会計士の取引が変わる。
まず営業は必要なくなる。
企業と税理士の間に間に挟まる仲介業者もいらなくなる。
税理士事務所や会計事務所といったスペシャリストをまとめて雇用している会社もいらなくなり、スペシャリストと企業が直接契約する。
最低賃金や下請法など取引秩序の維持に関してはプラットフォームが責任を持つべきだろう。
プラットフォームによる流通経路の単純化(中抜き)により、これまで自ら付加価値を生み出すわけでもなく仲介手数料をピンハネしているだけの中間流通業者が全ていらなくなり、全社会的最適化が行える。

業務プロセスの標準化と業務知識の共有

業務パッケージやプラットフォームのデファクトスタンダードが2、3種類定まることにより、業界全体で業務プロセスをデファクトスタンダードに合わせようとするバイアスがかかる。
同じような業務を各社バラバラの手順で遂行することには多くの無駄がある。
財務や販売代理・システム開発など外注の多い業務で顧客企業が「ウチのやり方は、ヨソとは違う」を貫けば、外注業者ではは異なる業務手順に合わせるコストが発生する。
当然そのコストは費用に上乗せするのだが、全社会的にはこのコストは何の付加価値も生み出さない無駄なコストである。
日本産業界全体でこの無駄を払い続けるのならば競争は発生しないが、海外企業はそんなのんきではない。どんどんパッケージを導入して業務の標準化とコストダウンを進めて競争を挑んでくる。
「業務プロセスの標準化を行わない」という現在の日本企業の選択は、「全ての業務で余分なコストを負担し続ける」ことを意味する。
逆にデファクトスタンダードが定まれば、外注業者も全ての取引先で同じ業務手順で仕事ができるので効率化しやすい。
人材育成も一つの基準で行える。
結果として全ての取引先の業務を単一のラインに載せることができるので生産性が上がりコストダウンし易くなる。

業務パッケージやプラットフォームのデファクトスタンダードを「業務知識の共有」という側面から見てみよう。
「ウチのやり方は、ヨソとは違う」を貫く企業のなかには、業務手順が古いまま進歩していないケースがまま見られる。
このやり方では、業務の進化を自社の努力だけで進めているので進歩の速度にどうしても限界がある。会社によっては本業の進歩で精一杯で周辺業務の進歩に全く投資できない会社もあるだろう。

パッケージというものは多数の顧客を抱え、顧客と相談しながら常に最新の業務プロセスを機能に反映しているものでありそれができていないパッケージは競争で淘汰される。 顧客企業はパッケージを導入するだけでその業界の最新の業務プロセスの恩恵を受け続けることになる。
これが「業務知識の共有」である。

顧客企業も何らかの分野の業務の専門家であり、本業では最先端の業務知識を有しているはずだ。
これを人間中心指向で運営していたらそれ以上の発展はない。
しかし、システム中心指向で業務知識をシステム化してパッケージにして売れば、日本中・世界中に業務知識を売ることができる。

「これからは全ての企業がIT企業になる」と言われているが、これはそういうことである。
誰かが業務知識をシステム化してプラットフォームを作りデファクトスタンダードの地位を握れば人間中心指向のサービスは書店のように淘汰される。

他のサービスは2つ3つぐらいしか残らない。
PCはWnidowsとMacしかない。
スマホはiOSとAndroidしかない。
ECはAmazonと楽天しかない。
プロセッサはインテルとARMしかない。
デファクトスタンダードの世界では上位3つぐらいしか消費者に覚えてもらえないのだ。
もし「ウチのやり方」が世界一ならばシステム化してデファクトスタンダードにして世界を制覇すべきだ。
もしそうでないならパッケージを買うべきだ。

業務の種類はニッチを極めれば意外に沢山あるのと思う。
デファクトスタンダードも世界全体を必ずしも目指す必要は無く、限られた地域のスタンダードでも良いはずだ。
セイコーマートなど北海道の地理的特性に特化した小売業でデファクトスタンダードの地位を取っている。

業務をシステム化することを極めると、結果として全社会的に業務が最適化されることになる。

なぜシステムに業務を合わせるのか。
これが私が考える真の意味だ。

<おわり>



このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ