業務における"システム"って何だろう

管理部門だけでなく、全ての部門でそうだと思うけど、
「システム化したい、DXを推進したい、CMでこんなシステムを紹介してた、、、」。
コロナを中心とする世の中の流れや、自社の課題等、いろんな文脈の中で上記のような話があがる。
確かに、結果的にシステム化して効率化することは非常に大事だと思うし、自分もそれを生業としている。なので重要性は理解している。
しかし、今まで「システムを入れたから解決しました！」と言っている会社や担当をあまり見たことがなく、むしろ「システム入れたけど使えていません」、「老朽化して、エクセルなどでやってます」など、まつわる課題を聞くほうが多いのは何故だろうか。

もちろん原因は多岐にわたると思っているが、主たるものは下記のようなものが多いんじゃないだろか（意味合い的に被る部分あり）
１．システムを使いこなせていない
２．要件定義が間違っている、足りていない
３．担当が理解していない
４．システムが使いにくく、エクセルなどのほうが便利と感じている

１．システムを使いこなせていない

システムをひとくくりにしても、いろんな種類があるが、
１．パッケージ商品（すでに作られているもの）
２．スクラッチ開発（自社のために作ったもの）
３．１と２の中間
の3つに分けるとして、基本的に導入されるのは１のパッケージが多いのではないだろうか。
パッケージの特徴は、低コストで使えて、そのシステムの担当領域は網羅的にカバーされていること。仕様は決まっているので、基本的には自社の業務をシステムに合わせていく必要がある。
自分も、楽楽精算（精算）、IEYASU（勤怠管理）、X-Point（ワークフロー）を導入してきたが、基本的には自社の業務のやり方をシステムに合わせるように現場とは調整。これはこれですごい大事。一般的にアウトプットが決まっているものは、その通りに仕組化してしまったほうが効率がいい。

しかし、自社の営業や製造などに関わる仕組みはそうはいかない。
これがないと困る、うちの部署はこのルールじゃないと無理、この客先にはこれを特別に提出している、この場合だけはこういうカタチにしたい。。。
パッケージの限界。
スクラッチならいけるの？というと、これも厄介なところで、自社の（言い方悪くすると）ワガママな仕様には、当初の要件定義では解決できず、スクラッチのシステムに追加コストをかけて仕様を変えてもらう。ちょっとならいいが、これはほとんど積もり積もって、担当者もシステムの全体像がわからない、システム会社も紐解かないとわからないブラックボックス。
変えるにも変えられないカオスな状態。

こんな状況、みたことありませんか？

２．要件定義が間違っている、足りていない

これもあるある。
要件定義という、解決したいと考えている課題や、導入したいシステムについての要求をまとめたものが、間違っていたり足りていないことが多い気がしている。
これも原因は多岐にわたるし、一発で要件定義ができることなんてほぼないと思うが、個人的に思う主原因は、システムを使う部署と作る部署が違うこと。例えば、自分の組織なら、システムを使う人は人事総務や現場、システムを作るのがシステム部。システム部は一般的にはシステムのことは詳しいけど、具体的な業務の流れや課題を知らないことが多い。だから、現場にヒアリングをして要件を固めていく。現場もやっていることや課題を伝えるが、網羅されていることは多くないのと、ここをこうしたい！などの解決策を提示できないことが多い。それは今までの業務の流れを、ある種「こんなもん」と思っているから、変える必要性を感じていなかったり、想像できていないことが多いと思っている。
で、システム部は言われたものを基本的には作るので、足りていないことがでてくる。変える必要性を感じていない担当の話をきいてシステム化すると、そもそも前提が違うので間違ったものになる。
自分で書いてて、これも両方とも大なり小なりみてきたな、と思う事例。

３．担当が理解していない

システムはあるけど、機能を使いこなせていない事例も多い。
特にパッケージのシステムの場合、いろんな機能がついていたり、クラウドのものだと機能改善されていくことが一般的だけど、そこを網羅的に知らないがゆえに、使いこなせていない事例もよく見かける。
例えば、いつもはこの一覧をPDFで出力して転記して集計しているけど、実は別のページからcsvを取り出せてそれを集計したらすぐに終わるというものや、固まったある機能を使いたいけど導入者も退職してしまったし、誰に聞いても曖昧な返答だからやむなくエクセルで当該情報を別管理してます、のようなもの。
これは宿命とも思っているけど、システムの全体像を知っている人がいないと頻発する問題と思っている。

４．システムが使いにくく、エクセルなどのほうが便利と感じている

結局、自分でいじれるエクセルや、時にはAccessのようなもののほうが、担当者の好きに使えるので便利だし、自分好みにできるっていうのは、どの企業でも100％といっていいくらいある話。
過去3社経験してきたけど、野良エクセルや、野良ファイルは腐るほどあって、創作者がいればまだいいけど、退職や異動で引き継いだ人が「このエクセルのこのボタンを押せばいいって言われています」や、このエクセルだと足りなくなったのでもう1個作りました、など野良が増えていく理由がたくさんあるし、担当者の気持ちもわかる。
結局、全員がシステムという型にはめて業務できるわけもなく、またアウトプットも日々変わっていく中で自分用にカスタマイズできるツールは大変便利なのである。

５．解決策ってあるんだろうか

上記のような課題の解決策ってあるんだろうか？
全てを解決できる現実的な改善策は、今の自分では思いつかない。
ただ、自分で業務をみて作ってきた経験からすると
業務をわかる人がシステムを組むのが最適
と割と真剣に思っている。組織的な話をすれば、システム部を独立した組織にするのではなく、現場にくっつけて現場のための選任システムとして役割を与えたほうがいいのだと思う。
※システムの中でもインフラ関連は別。
デメリットは、システム部が増えていくので人件費の増加につながるし、そもそもそこまで採用できるのかも謎。
もう一つは、これも当たり前だが、実務者のITリテラシー・スキルを上げるのも方法としては正しい気がしている。
ほぼすべての業務にITは切っても切り離せないはずで、担当者がこれを知らずして業務をしていくことは、進化を阻害してしまうと思う。
少なくとも責任者は技術革新には目をくばり、何かあれば部下に指示したり、自分で手を動かしてもいいのだと思う。

自分の場合は、基本的なシステムの知識や要件定義などの論理的な課題整理と解決までのロードマップをつくりかたちにするのはずっとやっているので、（今までの3社での結果が価値あるものという前提で）上記のような問題は起こににくく、属人的ではあるが運用含めてフォローできていると思う。もちろん属人化してしまうので、常に後任に考え方の同期はしているが、ここがこの仕組みの最大の欠陥で、今度は「人」に紐づいてしまう。

あー、簡単にシステム化、ＤＸっていうけど、どの会社も色んな悩みに頭を抱えているんだろうな、と思いながら、自分も少しでもこの問題に解決策を提示し、働く人の負荷を軽減しながら、作業効率を高め、結果的にそれが競争力になっていくといいな、と思い今日も仕事をします。

長々とありがとうございました。