事業部ごとに個別最適されてサイロ化されたシステム運用
システム連携は必要不可欠
ネットワーク技術の発達により、スタンドアローンで動くシステムは減りつつあります。
個別で動作することにより、高い成果をあげるシステムも少なくありません。
しかし、それは機密性の保持を前提にするなど、特別な条件を持つものに限られており、基本的には連携させたほうが有利になります。
それにもかかわらず、サイロ化されているのは別の事情によるものです。
あらゆる事業部で使える汎用的なシステムが理想的ですが、それを実現するにはいくつかの課題があります。
たとえば、システムの設計が煩雑になることもその一つであり、個別のシステムと比べて要件の定義が何倍も必要になるでしょう。
また、汎用化されたものは専用のものと比べて、設定しなければならないパラメーターが多くなります。
その分だけ実用面で劣る形になってしまうこともネックです。
それらよりも大きな問題として、横断的にシステムを運用することが難しいことが挙げられます。
日本の企業は事業部ごとに独立した関係にあることが多いです。
それどころかライバル関係が存在する事業部も珍しくありません。
自分たちの手の内を明かしたくないと考えるなど、秘密主義を取りがちであり、連携できるような状況ではないということです。
自部門のことしか考えないような傾向も強く、システムも自部門に最適化されていればそれで構わないと思いがちです。
このような風潮が孤立化を進めており、これまではそれでも問題なく運用できていました。
それは他社も似たような運用をしており、差がつきにくいという状況だったからです。
しかし、ネットワーク技術が飛躍的に伸びていき、今や多くの企業が部門間の連携を強化している時代です。
そのため、独立色の強い企業では太刀打ちできなくなってきました。
それぞれの部門が自分たちに最適なシステムを持っていても、総合力では負けてしまうというわけです。
個別の勝負で勝てる部門があっても、企業として負けていては意味がありません。
現場のニーズに耳を傾けることは大事ですが、個々の主張を尊重しすぎていては、最終的にそのような形になるでしょう。
あくまでもシステムを連携させることを前提として、そのうえで個々の要望もできるだけ叶えるようにすることが大事です。
もし個別にシステムを用意するとしても、あらかじめ他のシステムと連携できる仕組みを設けておくことが大事です。
連携により業務効率UP＆生産性UP
たとえば、データのフォーマットを統一しておくだけでも大きな意味があります。
一方のシステムがテキストベースであり、もう一方のシステムがバイナリベースなら、互いにデータをそのまま利用できません。
テキストからバイナリに変えるなど、変化するためのツールや手間が必要になってしまうからです。
それだけで業務の効率がダウンしてしまいますし、日常的に発生するなら生産性の低下も招くでしょう。
したがって、企業で共通の規格を決めておき、各システムはそれに従って設計していくことが重要です。
この例であれば、少なくともシステム間で自動変換できる機能を設ける必要があります。
実際には、完全にフォーマットを統一することが難しいことも少なくありません。
各部門の歴史的な背景も関係しますし、取引先の規格に合わせる必要などもあるからです。
それでも、なるべく汎用的に作ることを心がけることで、業務の効率や生産性の高さは維持されやすくなります。
現場の要望だけを聞いてカスタマイズを進める特化型は、DXの推進を阻害してしまいます。
デジタル技術を駆使してイノベーションを起こすには、そのための土壌を整えていくことが大事です。
孤立化したシステムばかりが存在していれば、それらを連携させることから始めなければなりません。
データを一元化できていない状況だと、部門間を横断するような設計を行うことは実質的に不可能です。
設計のみならず、運用においても大きな問題が生じてしまいます。
システムに障害が生じた場合、代替のものを用意できないので、それ自体が復旧するまで業務は停止するでしょう。
詳細は後述しますが、カスタマイズが複雑であるほど、回復まで時間がかかってしまいます。
それに詳しい人がいなければ、そもそも復旧できないような状況にもなりかねません。
このような問題を未然に防ぐためにも、個別に最適化されたシステムは早期に解消しておくのが得策です。
特化型ばかり存在しているなら、まずは基本となるシステムを決めましょう。
そのフォーマットを社内の標準規格として定め、他のシステムの改修に着手してください。
標準規格に従う形に作り直せば、とりあえず最低限の連携を行えるようになります。
そうすれば、DXを達成するためのステップをかなり削減することも可能です。
そのような変更をすれば、業務の効率化が落ちてしまうと反論する人もいるでしょう。
たしかに一時的にダウンしますが、連携をスムーズに行えるようになると、これまで以上の成果を出せるようになっていきます。
そのためには、改修したシステムをうまく使いこなすノウハウも必要です。
そのようなノウハウを時間とともに身についていくので心配はいりません。
まずはDXのハードルとなっている個別のシステム運用を解消しましょう。
各部門のリーダーにヒアリングして、どのようなシステムを使用しているのか認識することから始めます。
リーダーすら把握しておらず、チームや従業員ごとに別のシステムを使っているケースも珍しくありません。
その場合は、部門内でまずは統一するための話し合いをしてもらう必要があります。
企業の標準規格を伝えておき、それに合わせる形で方向性を決めてもうらことが大事です。
各部門にそのような判断をしてもらい、それらをまとめる形で最終的な指針を打ち出しましょう。
念頭に置いておくのはDXを容易にする環境づくりを優先することです。
仕組み的に連携を実現しても、実務的に利用価値が低ければ成功とはいえません。
DXは企業にとって革新的な進歩をもたらすものだからです。
形だけの連携に終わらないように、運用を開始した後の状況をシミュレーションしておくことが欠かせません。
問題がありそうなら、システムの設計思想を見直すことが必須です。
ベンダー（SIer）依存
依存からの解決方法①
ベンダー企業への依存度が高ければ、それだけDXの実現は難しくなってしまいます。
ただし、コストがかかることを許容するなら、容易に実現できるようになります。
なぜなら、DXに必要な作業をすべてベンダー企業に任せれば良いからです。
しかし、このような方法で実施した場合は、本当の意味で達成できたとはいえません。
なぜなら、これからもベンダー企業の手を借り続けることになり、自社にとって革新的な進歩とは言い難いからです。
DXの作業時にかなりの費用を請求されますし、それ以降の保守やメンテナスの費用も従来以上に高騰します。
何より自社の内情をさらけ出すことになり、いくら守秘義務があるとはいえ、セキュリティ的に不安が残ってしまう状況です。
自社の内情をすでに知っているベンダー企業なら、適切なDXを実現してくれると思うのは普通の心理です。
以前からIT関連をすべて依頼しているなら、DXについても同様に考えるのは自然な流れでしょう。
しかし、そのようなスタイルではこれからの時代を勝ち抜くことは困難です。
たとえば、計算機を使うために、わざわざ他の企業に依頼するようなことはしません。
依頼すると時間やコストの無駄ですし、計算する内容を外部に知られることになります。
さらに、計算するためのノウハウが、いつになっても自社に残らないことも問題です。
DXをベンダー企業に任せることも、基本的にはこれと同じように捉える必要があります。
いつになってもデジタル技術が社内に蓄積されない状況になってしまいます。
知見を持っているのはベンダー企業であり、こちらはクライアントという立場から脱却できないままです。
ビジネスシーンは激動の時代に突入しており、いったん構築したシステムもずっと使い続けられません。
細かな変更を加えることが頻繁に起こると予想されるため、それを自社で行える体制を作っておくことが大切です。
ベンダー企業に構築してもらうと、構造を把握できないので修正は不可能に近くなります。
これを避ける理想的な方法は一から自社で設計することです。
とはいえ、これまで他社にシステム開発を委託していた場合、技術的に困難と感じられる場合もあるでしょう。
IT技術者を育てることが打開策になりますが、それだけの手間をかけられないようなケースもあります。
DXの実現に早期のラインを設定しているなら、気長に育成していたのでは間に合いません。
そこで出てくるのはIT技術者を採用するという発想です。
こちらはコストがかかりやすいですが、短期間でDXに着手しやすくなるというメリットがあります。
自社にとって、どちらのほうがメリットが多いのか検討してください。
依存からの解決方法②
どちらも難しいなら、第3の方法があるので選択肢に入れると良いでしょう。
それはベンダー企業に透明性の高いシステムを構築してもらうことです。
たとえば、自分たちでも分かるプログラミング言語を使ってもらい、アルゴリズムも明快なフローチャートにしてもらいます。
引き渡しの際にソースコードについて解説してもらうことも有効です。
そのような配慮によって、自社の従業員でも変更できるようなシステムに仕上げてもらいます。
ソースコードに丁寧なコメントを付けてもらうなど、ハードルを下げるための工夫を最大限に盛り込んでもらいましょう。
それらを理解するための最低限の知識は必要ですが、その教育程度であれば大した時間は必要ありません。
むしろ、現状の従業員でも理解できるような状態で引き渡してもらうことがベストです。
これを選択するなら、企業内にITスキルを持つ人材がどれだけいるのか把握しなければなりません。
そのレベルについて詳細にチェックする作業も必要です。
彼らを中心としてDXを推進していけば、自社の情報が他社に漏れるリスクは下がりますし、ノウハウを蓄積する準備も整えられます。
自社よりも下請け企業にノウハウが溜まってしまうのはよくある話です。
従業員は指示ばかりして、実務を下請け企業が遂行している場合に多いです。
大企業にも見られる傾向であり、この風潮が恒常化しているとDXの達成は難しくなります。
できるだけ自社で完結できる仕組み作りを始めておきましょう。
依存することのデメリット
ここで気を付ける必要があるのはベンダー企業の誘い文句です。
ベンダー企業にとってDXは大きなビジネスチャンスです。
依頼されると売上が伸びますし、自分たちにしか分からない要素を組み込めば、永続的に収益をあげられるようになります。
保守やメンテナンスの依頼が必須となり、契約が続く間は安定的な収益化を見込めるというわけです。
自社にとっては、将来にわたって固定費が発生し続けることになります。
現状では大きな痛手と感じなくても、将来的に経営を圧迫する一因になりかねません。
支払う余裕がなくなると、アップデートできなくなって、古いシステムを使い続けることになってしまいます。
そのような中途半端なDXでは、競合他社との争いに負ける可能性が高くなるでしょう。
必ずしもすべてを自社で実現する必要はありませんが、他社に主導権を握られることは避けなければなりません。
これまでそうであったら、DXこそが主導権を奪いかえるチャンスになります。
あくまでも自社が推進の中心となって、ベンダー企業には協力を仰ぐ程度に留めることが基本です。
言い換えると、ベンダー企業に依存している状態だと、まだDXを実施できる段階に達していません。
DXの準備段階と捉えて、社内のITレベルを高めることに注力しましょう。
具体的な方法は育成と採用の2種類ですが、両者を並行して進めることも悪くありません。
遅かれ早かれ、従業員のITレベルを上げる作業は必要になります。
DXが進むに従って、利用するデジタル技術は広がっていくからです。
デジタルはITだけを指す言葉ではありませんが、中心的な存在であるのは間違いありません。
これからのIT社会において、その知識やスキルが不十分な人材は戦力的にも期待できないでしょう。
違う見方をすると、アナログ的な手法を好む従業員のIT化もDXの一部ということです。
ベンダー企業が不可欠という課題のクリアを目指しましょう。
既存システムの老朽化、複雑化、ブラックボックス化
既存システムが招く危険性
実装した当時は最新のシステムでも、数年もすれば陳腐化してしまいます。
IT技術の進歩は目覚ましく、既存のシステムよりも良いものが次々と登場するのが実情です。
使い慣れているからといって、既存のシステムを使い続けていると、最新のものを使用している競合他社に後れを取ってしまいます。
老朽化が加速度的に進んでいることを自覚し、劣勢になる前に手を打つことが理想的です。
とはいえ、それを妨げる要因があることも覚えておきましょう。
主に2つあるので双方に対して対策を練っておく必要があります。
1つ目はシステムが複雑化していることであり、改修やアップデートが困難になっています。
現状で通用するもの、使用変更を加えすぎた結果、原型が残らないほど変わっていることも珍しくありません。
何年もわたってそうしていると、もはや誰も手をつけられないほど複雑になりやすいです。
しかも、一人で変更を加え続けていた場合、その従業員がいなくなるとまったく対処できないでしょう。
これこそが多くの企業で問題になっている属人化であり、DXにとって高いハードルにもなっています。
DXのメリットとして属人化の解消が挙げられますが、あまりに顕著すぎると実施自体が困難になることもあるのです。
2つ目の問題はシステムがブラックボックス化していることです。
1つ目の問題とも関係しますが、システムの内部の情報が共有されていない状況になっています。
使えるけれども変更はできず、まるでパッケージ版のソフトを用いてるような感覚です。
このままだと情勢の変化に合わせて最適化できませんし、OSの更新などで使えなくなるリスクもあります。
早くDXを進めたくても、ブラックボックス化されていると、どのように改善すれば良いのか見当を付けられません。
ソースコードを読み解くことから始める必要があり、着手できるまでに数カ月を要することもあるでしょう。
ブラックボックス化されているシステムがあるなら、できるだけ早い段階で解消に向けた取り組みをスタートするのが正解です。
これらの問題を楽観視する人が多いことも大きな問題となっています。
既存のシステムへの信頼度が高い場合に起こりやすく、変更や置き換え自体が不要という結論に至りやすいです。
当面の間はそれで乗り切れたとしても、これから先も通用するという保証はありません。
たいていの場合は時代に追従できなくなり、大規模な改革を迫られることになるでしょう。
そうなると、予想もできないほどの金額が必要になるかもしれません。
かなりの時間がかかってしまい、その間は売上が急激にダウンすることも懸念されます。
つまり、傷口が広がってからでは、ダメージの総量が膨れ上がるということです。
自社へのダメージを最低限に抑えたいなら、上記の問題をできるだけ早く片付けておきましょう。
念入りな対策をしっかりと心がける
老朽化に関しては、どのような点が現状にそぐわないのか抽出することが重要です。
わずかであれば、置き換えなくても対処できる見込みがあります。
複雑化に関しては、変更した人にソースコードの整理を指示することで解消が可能です。
それと同時に、仕様書やマニュアルの更新も行ってもらいましょう。
ブラックボックス化の対策も基本的には同じです。
少なくとも現在の担当者が中身を変更できる状態にしなくてはなりません。
したがって、ソースコードを解読する時間を与えるなどの配慮が求められます。
もう一つの注意点として、前述のように古いシステムがあると、他のシステムと連携しにくいことが挙げられます。
しかし、複雑化やブラックボックス化を解消できていると、大きな問題になることを避けられるでしょう。
たとえば、データのフォーマットを統一するような作業も短時間で実施できます。
影響を限定的な範囲に留められるため、最終的なチェックにかかる時間もそれほど多くありません。
言い換えると、それらが残っているとDXのクオリティが下がってしまいます。
複雑化された状態でも連携自体は不可能ではないでしょう。
しかし、機能的な制約が大きくなるので、従業員たちはスタンドアローンな機能だけを用いるかもしれません。
ブラックボックスの部分は避けて、自分が分かる範囲の変更に留めようとする傾向も見られます。
このような問題を引き起こしかねない既存のシステムは、多かれ少なかれどのような企業にも存在します。
それらを一気になくすことは困難ですが、少しずつでも置き換えていく計画を立ててください。
ただし、連携の課題もあるため、最初に全体の構図を描くことを忘れてはいけません。
個々に置き抱えた結果、それに互換性がなければ意味がないからです。
あらかじめデータの標準規格などを定めたうえで、それにマッチするシステムに変えていく必要があります。
また、この段階で老朽化しにくいように工夫しておくことも欠かせません。
理想的な工夫は自動でアップデートする機能を搭載させておくことです。
パッケージ版のクラウドソフトなどではスタンダードな機能ですが、個別に設計されたものには基本的に備わっていません。
ただし、それは現時点のことであり、今後は搭載されることが当たり前になっていくでしょう。
そのため、DXに向けて設計をするなら、やはりアップデート機能を盛り込んでおくのが得策です。
特に税制など国が頻繁に改定するコンテンツを含むものは、アップデート機能の有無が使い勝手に大きく影響します。
それらを中心として、アップデートの負担を軽くすることもDXの目的に掲げましょう。
同様の理由によりブラックボックス対策として、インタフェース上で内部を変更できる仕組みも設けておきたいところです。
プログラミング言語を使わなくても、ソースを変更できる機能を持つシステムが増えています。
予期せぬ不具合が生じやすいので、バックアップ機能を備えておくことも条件の一つです。
ブラックボックスを皆無にすることが理想ですが、現実的にはハードルがかなり高いです。
高度なシステムであるほど難解になるため、属人化も進みやすい状態になってしまいます。
そのため、上記のような機能を持たせるなど、別の視点からの対策が求められるのです。
