労働力人口減少2030年の崖に備えよ
～第2回 DX化の推進～

最初に第1回でお伝えした「労働力人口2030年の崖」について、簡単に振り返りたいと思います。
最初からお読みいただける方は第1回からお読みください。

日本の人口が減少していることを知らない方はいらっしゃらないかと思いますが、労働力人口（就業者数と求職者数を足した人数）は実はまだ減ってはいません。女性と65歳以上の労働力人口比率が増えることで横ばい、あるいは微増を維持してきました。

しかしながら、今後の予測も含めて人口ピラミッドを見ていただくと、第2次ベビーブーム世代（1971年～1974年生まれ）以降の年齢では、人口が減少し続けていることが見て取れます。第2次ベビーブーム世代がリタイアしてしまえば、最早労働力人口の減少を食い止めることは難しいと考えます。

労働力人口の維持から減少への変化点は、私共は第2次ベビーブーム世代が60代に差し掛かる2030年から始まると考えており、労働力人口減少期の始まりを「2030年の崖」と呼んでいます。

これまで全体の数としては維持されてきた労働力人口が減少に転じるということは、当たり前ですが人手不足となり、リタイアしていく人数に比べて採用できる人数が少ないため、同じ業務のやり方を続けていくことができないことを意味します。
2030年になるまでにいかに効率化を推進し、続けられる業務の仕組みを構築できるかが重要であると考えます。

DX化の進捗状況は企業によって大きく差があります。

2020年前後に基幹システムを入れ替えた際に、殆ど標準機能のままでクラウドのパッケージシステムに入れ替えており、基幹システム周辺のRPA化やAI-OCRの活用なども進んでいる企業もあれば、数十年前のシステムを人間がつなぎ合わせて使い続けており、DX化は課題だが簡単にはできないと悩んでおられる企業もあります。

例えば、ERP導入などはコストの高さに加え、費用対効果を出すのは一般的には難しいため、なかなか変えることができずに来ているという事情はよく分かります。
しかしながら、古いシステムが生産性を悪くしている問題を引き起こしているのであれば、なおさら人に余裕のある今のうちに、この状態から脱しておくことは非常に重要です。

古いシステムが生産性を悪くしているのは、一般的には業務面だけではありません。古いシステムを維持すること自体にコストがかかっていることが多いと思われます。
昔の技術ほど失われるのは早く、いずれ、業務的にもシステム的にも現状を維持しきれない未来が来ることは想像に難くありません。まだ技術者がいる今のうちに手を付ける必要があるのではないでしょうか。

DX化といっても幅広いのですが、今回は全社の取引情報や経営管理情報を扱う仕組みの再構築を想定して、ポイントを3点述べたいと思います。

ポイント1：情報発生元からの徹底的な自動化に拘る
ポイント2：パッケージソフトをそのまま使うことに拘る
ポイント3：意思決定を支えるのに必要なデータに拘る

「徹底的な自動化」というと、理想としては当たり前だと感じられる方も多いことと思います。
自動処理になれば、人間がやるよりも速くて正確で、しかも24時間処理し続けてくれる。2030年を待たずして人手不足や高齢化は一部の企業に広がっていますので、自動化に期待されている方は多いように見受けられます。

ひとつ注意が必要なのは、現在のプロセスをそのまま自動化するのが良いということではないということです。多くの場合、業務は増築に増築を重ねた古い建物のように、過去の経緯を残した複雑な作りになっています。大企業であればさらに組織の壁、担当の壁が存在し、各部署や各人にとっての個別最適な増築を重ねているので、全社で見ると既に使われていない空き部屋が存在したり、迷宮のような複雑な迂回をしたりしている場合もあります。

とあるお客様で、実際に決算で使われているExcelツールの分析をさせていただいたところ、マニュアルに書かれている手順とExcelツールの数式等のロジックの60％が不要なものだった、ということがありました。処理としては必要な部分も単に数式で処理できるものなのに、人間がひとつひとつ数字を拾って足し引きしていくという不思議なプロセスが作られていました。

自動化の推進にあたっては、全社の視点で情報の発生元と、その情報を活用するアウトプットを特定し、その間をできるだけシンプルに繋ぎなおす視点が必要です。
実際にはERPなど市販のパッケージソフトウェアを使うことも多いと思いますが、そういった仕組みの組み合わせでいかにシンプルかつ情報発生元からアウトプットまで、途切れることなく自動で処理できる仕組みができるかを考えていくこととなります。

情報発生元からの自動化に拘ることを勧めるもう一つの理由は内部統制です。未だに最終的に作られた帳票にハンコを押してJ-SOX用の証跡を作っていらっしゃる企業もありますが、効率化の観点からITACとシステムの処理が正確であることの証明、そしてITGCとシステムが適切に管理されていることから問題はないというこの2点の実質的な整備を進めることも極めて重要です。マニュアルコントロールであればそもそも人間がチェックをし、さらに内部統制のテストにも負荷がかかりますが、システムコントロールにしてしまえば、コントロールの実施は自動で内部統制のテストも最低限で済みます。

できるだけ速くDX化を進めるためには、パッケージソフトウェアをそのまま使うことは極めて重要です。Fit to Standardという言葉でよく言われますので皆様ご存じかとは思いますが、具体的な話になるとどこがポイントなのか理解が分かれていることもあるようですので、ユーザー部門の目線でお伝えしたいと思います。

まず、「そのまま使う」とはどういうことか、ですが、極端に言えば設定のみで使い始めることです。何が設定で、何が開発かわかりづらい場合は、システムベンダーに作ってもらうものが開発だと考えてください。設定の中にはユーザーが自分でできるものと、システムベンダーに設定してもらうものがありますが、デモンストレーションやプロトタイプなどで実際に動いている様子を見られるものは、設定で実現できる範囲です。

開発がどうしても必要になるのはインタフェース（システム間データ連携）で、インタフェースの口を最初から持っているかどうかの違いはありますが、先に述べた徹底的な自動化にもつながる部分ですので、インタフェース開発はむしろ拘って開発すべき部分と考えます。

パッケージソフトウェアをそのまま使おうとすると、当然業務プロセスは影響を受けますが、この時、既存のやり方を残して最低限新システムに合わせようとすると、先ほど述べたような増築を繰り返した家のようになってしまいますので、業務プロセスは一度ゼロリセットして、新システムに合わせた効率的なやり方を考える必要があります。

なお、機能によりますが、会計システムなどの法制度対応が頻繁に起きることが想定できる機能は、パッケージベンダー側のバージョンアップで対応してもらえるものが理想です。インタフェースに影響が出る可能性はゼロではありませんので、全てお任せで済むとは言えませんが、それでも、自社独自で法制度対応を考えるなどに比べて負荷が低いのは間違いありません。労働人口減少の未来を想定した時に、将来にわたるバージョンアップの負荷というのも考慮すべきポイントの一つになると考えます。

もうひとつ拘っていただきたいのはデータです。
社内のどこかには必要な情報はあるんだけど・・・という状態では、使用に耐えません。
かといって何でもできるだけ細かい粒度で集約していつでも使えるようにする、というのも、これだけ膨大にデータが溢れている現在、あまり良い手段であるとは思えません。

全社視点で必要なデータとは何かを定義することが重要です。特に、絶対に保存しないといけないものを落とすことはあまりありませんので、無くても済んでしまうが、良い意思決定をするために必要なデータは何かを良く分析・議論することが重要です。

必要なデータが決まりましたら、次にその粒度と鮮度を定義します。
例えば、売上高という情報が定義されたときに、それを受注番号単位で持つのか、納品／サービス提供単位で持つのか、部門ごとに持つのか、製品区分／サービス区分ごとに持つのか。また、鮮度としてはリアルタイムに必要なのか、毎日前日の分が見られればいいのか、1ヶ月まとめて実績が見られればいいのかを、この情報を誰がいつどんな判断をするために使うのかを想定して定義していきます。

もうひとつ検討が必要なのは予測情報で、売上高実績の用途から実績として必要な粒度と鮮度を定義した上で、それとは別に、売上の予測情報、あるいは利益などまた別の予測情報を作る上で、変数を変えるなどのために分けて持つべき単位というのがあるはずですので、この視点での検討も重要です。

必要なデータとその粒度・鮮度が決まりましたら、それを新システムの中でどのように実現するかを検討していきます。意思決定に必要な情報は、いくら想定しても増えていくことは常ですので、ある程度の拡張性も想定しておくことが望ましいでしょう。

ここまでご精読いただきありがとうございました。
次回本シリーズの第3回目では、2030年の崖を乗り越えるための取り組みの3つ目として、一度効率的に変更した業務を、効率的な状態で維持し続けていく方法についてご紹介します。