システム化の前に考えるべきこと

システム開発の古い考えでは、システム化は人の作業を効率化し、無駄を無くし、かける人員を減らし、コスト削減をする、と教えられてきた人は多いはずだ。

この発想は、人的資源の補充が潤沢であった時代のもので、今のように人口減少社会の中、採用も難しく、育成に時間をかけてもいられない時代においては、限られた人的資源を効率化し、ビジネスを最大化するという方向に改善をしていくのが、システム化に求められていることだ。

この効率化・人員削減・コスト削減と、効率化・ビジネス最大化は、入り口が同じだけに混同しやすいが、本質的には全く違うことをやらなければならない。

効率化・コスト削減を目指す開発

効率化・人員削減・コスト削減は、要するに無駄をできる限りなくすという発想なので、無駄探しから始めてしまいがちだ。手間がかかっていること、面倒くさいこと、間違えやすいこと。そうしたことを一つ一つ洗い出して、システムで解決を目指すことになる。

このアプローチは、本質的には現状業務を肯定するところから始まりやすいので、現状を根本から変えることにはなりにくい。

しかも現状の根本的見直しを行わずに、慣習的にやってきた業務の枝葉に取り組んでいると、数々の矛盾が生じてしまい、そこが原因となってシステムがうまく動かないということにもなりやすい。

そうなっていくと、辻褄を合わせるために様々な条件をつけて合わせざるを得なくなり、システム仕様はたくさんの文章のかたまりになっていき、非常に難解なものができあがってしまう。

いったん難解なものが完成してしまうと、修正には多大な労力が必要となり、システム改修が大変なために、業務を変更することに消極的になり、結果ビジネスに柔軟性がなくなり、会社の競争力が削がれていく。

効率化・ビジネス最大化を目指す開発

一方、効率化・ビジネス最大化は、アプローチが全然違う。

こちらの目的は、単純な無駄の削減ではなく、ビジネスの最大化だ。

ビジネスの最大化とするならば、何を最大化することがビジネスの最大化なのかを真剣に考えないと行けない。

チャーンレート（離脱率、つまり期間内に顧客が離れていく割合）を下げることか、ライフタイムバリュー（顧客との長い付き合いの中で受け取ることができると想定される売上。チャーンから継続期間を割り出し、平均単価をかけて求める）を最大化することか。もしライフタイムバリューなのだとしたら、何をすることが継続期間の長期化につながるのか、つまりチャーンを下げることになるのか。何をすることが契約の拡大につながるのか。などといったことを考えていかなければならない。

もちろん部門システムの場合であれば、部門のビジネス最大化になるので、例えば離職率を下げることとか、商談期間の短縮とか。対象部門によって異なるが、いずれにしても会社のビジネス最大化に、部門がどのように価値連鎖をしているので決まってくる。

つまり、効率化・コスト削減は、どう作るかが課題になりやすく、効率化・ビジネス最大化は、何を作るかが課題になりやすい。

どう作るかが課題になると、コンピュータの専門家が知恵を出さなくてはならず、主体は情報システム部と開発ベンダーになる。何を作るかが課題になると、主体は経営であり、事業部門になる。

つまり効率化・コスト削減は、表層の改善であり、経営との一体感に乏しく、効率化・ビジネス最大化は、まさしく経営であり、会社の根幹に迫る活動だ。

では、会社の根幹をシステム化するためにはどうしたら良いのか。

どのように進めるべきか

ビジネスの最大化とは、最大化するビジネス価値を明確にすることなので、まずはビジネス価値がどのような状態になっているのかを、的確に捉えることが重要になってくる。

事業状況を捉えるときに、報告だけに頼っているのは古い考えで、報告に頼らなくても数字を的確に捉え、経営から現場までが同じ数字を見て現状把握していることが大切だ。つまり事業が適切にデジタルにリンクされていて、誰のバイアスもかからずに状況を把握する。そういう状況を作る。（余談だけど、これをDXと呼ぶ）

事業が適切にデジタルにリンクされているということは、現場が特別な作業をしなくても、必要最低限のことをやっているだけで、自然と情報は集約され、把握できることが重要。

そう考えていくと、営業であれば、引き合いの記録、見積もり、提案、交渉、検討、作業などの側面で。生産であれば、計画・配置・工程・調達・出荷などのあらゆる側面で、普通に作業していることが集約されていかなければならない。

そして集約されるべきものは、データなのだ。

プログラムを最小化しデータを得る

データを集めるのであれば、データを集めるために最適化していればいい。

なぜここを特別に言っているのかというと、システム開発にコストがかかるのは、データではなくプログラム作成だからだ。

大切なのはデータを適切に集約できるかということなのに、プログラム作成に多大なコストを払う必要は、本当にあるのか。

基幹システムというと、端末に固定的な画面が表示されて、作業を選択して操作しているイメージがあるかもしれない。入力フィールドには、あらゆる誤り訂正機能が入っていて、間違えないように作られている。というイメージ。

こういう仕組みを作り上げることは、実は手間がすごくかかるので、本当は入力を単純化し、複雑な付き合わせや確認は、バックエンドで行う構造にするのが良い。

バックエンドとは、つまりサーバー側のバッチ処理。

これまでの常識では、バッチ処理をできるだけ作らないのが正義とされてきた。バッチ処理に依存すると、システム全体が複雑化し、管理できなくなる。

そのため入力時のシステムでできるだけ頑張り、システム間連携や様々なチェックを入力時に行うことになっていく。

そしてこういうシステムは、極めて開発難易度が高く、技術者のスキルも求められ、開発期間もかかる。つまり開発費用がとても高くなるのだ。

データ処理基盤の革新による構造の単純化

しかし技術の進歩によって、状況は一転した。

バッチ処理の開発が、極めて簡単、高速、単純になったのだ。
BigQueryをはじめとするバッチ型分散処理メカニズムが簡単、格安に利用できるようになり、周辺の仕組みも次々と進歩したおかげで、開発の仕方も、構造も大幅に変化をしたのだ。（当社のMAGELLAN BLOCKSとかも、バッチ処理を効率化する仕組みだったりもする。AIと量子コンピュータだけじゃないんだよ。）

バッチ処理が単純化できるということは、入力時のシステムを単純化できるということで、そうなるとプログラム作成の難しさはなくなり、気が抜けたほど単純なシステムで目的が達成されてしまう。

つまり構造が単純で、コストがかからない。

効率化・コスト削減を目指すと、どうしても入力時のシステムを複雑にしてしまいコストがかかる。効率化・ビジネス最大化を目指すと、大切なものだけを選択して、どうでもいいことを切り捨てることができる。

大切なのはプログラムではなくて、データなのだ。

だからコストがかかるプログラム作成を複雑化するのではなく、適切なデータを適切に集約することに単純化する。

そしてそのデータは、何を最大化することが自社のビジネスなのか。事業部の目的は、どのような価値を最大化（最小化）することなのか。

冗長なプログラムを単純化し、コストと時間を大幅に削減して、ビジネス課題と、ビジネスの価値連鎖考察に手間をかける。

これが現代型のシステム開発。

システムを敬遠する経営に未来は無い

そしてこうした諸々のことは、経営に直結したことなのだ。だから、コンピュータのことはわからないから、誰かに任せる。という経営者は、経営のことはわからないから、誰かに任せる。と言っているのと同じ。

取り組む必要のない無駄探しを延々と続け、経営とシステムのつながりが薄れていく企業は、もう生き残れない。そういう時代だ。