LoginSignup
10
10

More than 3 years have passed since last update.

社内エンジニアは見た! 技術的負債とDXの実際【DXレポート,レガシーシステム,デジタルトランスフォーム】

Posted at

多くのエンジニアが逃げられない(であろう)DXについての記事
経産省が発行するDXレポート本文は 50 P 弱で綺麗にまとまっているが、より簡単にまとめたつもり

・抽象化されたDXレポートと実際の現場で感じることの比較ができる
・少しでも元のレポートに興味を持ち、手に取ってくれること
・勤めている、勤めようとしている会社の現状を客観的に評価できるようになる

そんな切っ掛けにしてもらえたらと思う。

特に経営の基幹につながる、いわゆる「基幹システム,ERP」についての問題点が記述されており、少しばかり基幹システムの近くにいた経験から言葉にしてみる。

この記事はフィクションです。そんな会社もあるのかもなぁ。と思いながら読んでください
実際には起こっていないフィクション( ).....ですからね...

はじめに

・事業会社(ユーザー)だから、デジタル人材に投資しない
・ベンダーの協力で開発できればいい
・デジタル技術なんて必要ない
・モノづくりは作れる工場を持っているから強い
・AIを使って何かできないか

なんて言葉を社内で聞いたことありませんか?

しかし現代はデジタル化と無縁でいられない。
今の段階で「どれだけデジタル化に力を入れなければならない」か見えていない状態が如何に危険であるかを考えてみたい。

0.DXレポートとは

DXレポートとは、2018年9月に経済産業省より発行された文書
(記事最下部にリンクと説明あり)

1.DXとは

xはtransの略記

digital transformation
・外部企業の起こす破壊的革新や市場の大規模な変化に対応しつつ
・内部の変革を続け
・IT,先端技術を事業領域に活用して
企業活動を行っていくための活動である

DXへの取り組みとして
- デジタル部門の設置
- AIの活用
- 社内データの活用
- 新しい価値創出のPoC
などの試みを行っている企業も見られるが利益に繋げられている企業はまだ少ない。

その原因は既存システムが十分にデータ活用できる状態でないために、新技術が限定的な使い方しかできないのでは?

2.既存システム誕生と現在の問題

  • 古くから存在する企業では、コンピュータの登場により様々な作業工程で業務効率化すべくシステム導入が行われた
  • 当時のシステム導入は、業務手順の自動化(システム化)の一面が多分に含まれていた
  • そのため平準化された汎用的なシステムよりも、カスタム要素を強く含むシステムや、スクラッチで作り上げるシステムが求められた。

  • 全社的な導入なら管理出来ていたかもしれないが、大きい会社となると部門やチームごとでバラバラのシステム・データベースを設置されてきた

導入したら効率的になるんだから、それはもう好き勝手に。

これがより問題を複雑化させることとなる。

3.過剰品質なシステム

・システムが業務部ごとに立ち上がる
・業務に寄り添ったシステム開発の状態が長く続く

その結果、業務はシステムありきの手順へと変わる

一度決まった手順で動いている業務(ビジネス)側は、システムが変更するとなると、手順やら決まりやらを改変する必要がある。
そのためシステムの変更は業務現場から抵抗を発生させ、徐々に変更しにくい雰囲気になっていく。

・複雑な手順をシステム化する
・限定的な工程にも細かく対応する

最初のシステム立ち上げ時には業務知識があり、作り上げに立ち合い、そのシステムの全景を記憶している社員が複数いた。

しかし、終身雇用・年齢給など成果主義でない企業がほとんどで、
ましてや成果を正しく評価する仕組みのない企業ではその記憶をドキュメント化するインセンティブは少なかった。

以上のことから
・1 - 各工程・部門のシステムに関するドキュメントは残らない
・2 - 連携図は作られていない
・3 - 状況を知る社員が定年を迎えていなくなる
・4 - 古いマイナーな言語で動く仕組みをメンテナンスができなくなる
の順でシステムが手に負えなくなってくる
まさに複雑なブラックボックスと化す

ブラックボックスとなったシステムは、ITに詳しくない各現場が持て余し、
スパゲッティのように絡まりきったシステムの保守運用という「栄誉ある役目」がシステム部へと投げられるのである。

4.改修・修正しないの?

複雑なブラックボックスとなっていてもビジネスは成り立つため、成り立っているうちは気付かないし問題にならない
経営層はこれを問題なしと判断してしまうし、業務現場はビジネスのための作業が仕事であるのでシステムまで手当できないと言う。

時代と共に業務が変化し、システムも変更の必要が発生する。
そうなると社内に開発できる人材がいない状態なので、古代の言語を知る数少ないベンダー企業を探し増築してもらうのである。

こうして企業のシステムは全貌が曖昧なまま増改築を繰り返し「ウィンチェスターハウス」にも劣らないホラー展開を突き進んでゆく。

image.png

(画像,映画.comより)

5.開発できる人を採用・育成したら?

新しくITの人員として採用した人材が、これから先金にもスキルにも繋がらない技術を学び、絡まったシステムの面倒を見たいという可能性は少ない。
魅力のない仕事を任せた為に、せっかく採用した人材が辞職する事もあるだろう。

絡まったシステムを紐解き、本当に必要な機能に絞って再開発し、現場の業務プロセスを強制的に変更し、システムの理想像を描く。
これは相当に体力が必要となり、長い期間と膨大なコスト・ビジネスが止まるリスクも考えなければならないので、決断できるのは経営層やトップである。

しかし、先ほど挙げた成り立っているうちには問題にならないという点や、経営層のITやシステムへの理解の少なさから問題ないと判断されるのが現状である。
経営者だけでなく現場も現状困っていないために認識されにくく、説明もしにくい。

認識したとしても、経営層は簡単な号令をかけただけでコミットしたと考えている場合もある。
「経営層のコミット」とは「デジタル化を進めるべきだ」というだけではないのである。

6.このままのシステムでビジネスを続けていいの?

既存システムのままでは
・メーカーの保守切れ
・対応するサーバーの生産終了
・セキュリティ更新
・災害時のバックアップサーバ準備の難しさ
などなど、雪だるま式に問題が積み上がり、システムを維持するだけで息切れしてしまうようになる。
実際、日本情報システム・ユーザー協会(JSUA)の調査によれば7割の企業が老朽化したシステムを足枷と考えており、
IT投資費用の8割がシステムの保守運用に充てられ、適切な新領域への投資ができない状態である。

俗に言う「攻めのIT」を行うためにも、足を引っ張り金をむさぼる問題児をなんとかする必要がある。

現実はこんな可愛くない

7.新しくシステムを作り直せばいいんじゃない?

新しく作り直すことで問題は解決するのか?

既存のシステムをよく知る人に、現在の老朽化したシステムの話を聞くとこう言われる。

当時は最先端のシステムだったんだけどね

システムの刷新を決め、新しく作り直したとする。
老朽化したシステムは最新のシステムとなるが、その瞬間からシステムは老朽化を始める。
・ドキュメントが残らず
・増改築が繰り返され
・現場への過剰品質が再び進む
結局、莫大な費用をかけて再び老朽化するシステムを作り直しただけ。

刷新の前に考えることは沢山あり、
・システムはどのように運用すべきか
・事業のどの部分にどんなITを使うべきなのか
・先端技術によるシステム開発
・データ・AI技術等を使った競争力獲得のためのシステム
などが決まっていないならば刷新しても一瞬のメリットしかない。

システムをマイグレーションするだけでなく、ビジョンを定め、常にシステムのメンテナンス・マネジメントを続けていくその「仕組み」を考えなければならない。

たとえ最先端のクラウドストレージを活用した全社統一的なシステムをつくったとしてもこう語るようになるだろう。

当時は最先端のシステムだったんだけどね

昔はすごくても今は大問題

8.刷新するにしてもベンダーに丸投げ

日本はユーザー企業とベンダー企業の間にIT人材の大きな開きがある。

事業を行うユーザー企業はITシステムを一つの道具として考えている場合が多い。
- ビジネスの核になる製品は作るが基本的に道具は作らない
- なぜならば道具を売っているわけではないからである
と。

しかし、新たなデジタル技術が登場する現代で、すべてのデジタル技術を単なる道具と考えていると、
ITの活用ノウハウが蓄積しない情報システムとは名ばかりの集団が出来上がり、
いつの間にか手遅れになってゆく。
(いつまで道具を使わせてもらう待ちの姿勢なのか?)

自社で主導した開発経験も無いため、ウォーターフォール型の開発をいつまでも続け、時間がかかることこの上ない。
プロジェクト・マネジメントできる人材も少ないまま。
ひょっとしたらマネジメントとはコスト削減と納期に向けてケツを叩くことなのかもしれない。
開発者の育成の計画も立たない。

一方、ベンダー企業はIT人材を確保し、ユーザー企業の欲しがる道具を作る。
IT人材の集まるベンダー企業にITを志す若者が集まるのも自然な流れである。
ユーザー企業の絡まったシステムも、ベンダー企業からしたら大きい工数を確保できる案件であり、
世の中にもはや供給できるエンジニアがいない言語では、必然的に単価も高くすることが可能となる。

ただし、ベンダー企業にとっても若者に魅力的でない技術に関わらせていては若者に離職される危険もある。
さらに、絡まったシステムの増築を受けてしまったがために、
予想以上に絡まっており調査に大幅な時間がかかり、契約していた金額と労働時間におさまらなくなる。
(時に訴訟につながる)

つまり赤字 である

さらに、技術者のいない&システムのわからないユーザー企業は要件定義からベンダーに依頼することもある。

想定していた時間までに完成出来なかったことによりユーザー企業から賠償金を負わされることもある。
その一因として、ユーザー企業が現状のシステムの複雑化を認識していないために、契約に盛り込めなかったという原因もあるので、クラシックなユーザー企業とのかかわりは慎重になってしまう。

広い目で見るとベンダー側の旨味は少ないのである

(もはやユーザー側の社内SEとは御用聞きか伝書鳩なのかもしれない)

旨味の少ない仕事なら、もうユーザー企業の介護は嫌だ

9.デジタル・ディスラプション と 2025年の崖

壁ではない。である。
つまり落ちれば〇ぬ

絡まったシステムに目を向けず、方針を定めることもなく手を付けない場合、徐々に首が締まっていくことは想像に難くない。
いずれベンダー企業にとっても旨味となる案件で無くなり見捨てられ、誰も介護してくれなくなり、本来行いたい企業活動が出来なくなる。

さらにIT企業の起こすデジタル・ディスラプションである

「我々はIT企業でなく事業会社だから~」とふんぞり返ってデジタル技術の軽視とも取れる主張を行うIT部門の人はまさか居ないと思う。
(居ないでほしい...)

そのIT企業が旧態の事業会社を駆逐し始めている

  • タクシー会社は車を所有し配車できるのが競争力であった。
  • 宿泊施設は宿を提供するための不動産を所有するという競争力があった。
  • リサイクルショップは不要な物を買取り、必要な人に安く売るプラットフォームであった。

しかし、これらはIT企業によるたった一つのアプリケーションで塗りつぶされ駆逐され始めている。

事業会社は、ふんぞり返るための体の柔らかさを身に着ける前に、競争領域に対する適切なデジタル技術の理解と投資に注力すべきである。
同時に、競争領域でない部分に対しては平準化され、コストを抑えたシステムを採用できるかを考え続ける。

システムのあるべき姿のビジョンと、競争領域でのデジタル活用を考えれば「AIを使って何かできないか」なんて言葉は出てくる事はないだろう。
・競争領域を維持するためにコレを尖らせなければならない
・他社との差別化をしなければならない
実現したいwhatを見つけてこその先端IT技術の活用であり、データやAIの出番となる。

「事業会社だから専門技術を身に着ける必要はなくベンダーと~」なんて言っている暇があれば最新と先端の技術から使うべき技術を見極めて社員に勉強させるべき。

これからはあらゆる企業がデジタル企業になっていくのだから。

たった1社のIT活用で今までの産業は世界ごと変わる

(情報処理推進機構の調べから、2025年に人材の引退・サポートの終了・リスク対応などにより最大12兆円の経済損失が起きるとの予想から崖とつけられた)

10.責任者・経営者の役割

米国では全米取締役協会のガイドラインにITシステムやサイバーセキュリティに関する項目が記述されており、
自社のITの状況を理解しビジョンを示せなければCEO(最高経営責任者)としての役割が果たせていないと評価される。

CIO(最高情報責任者)はベンダー企業の評価と、その協力によって価値を作り出すことが役割であり評価対象となる。

日本でのCIOは
・有名な名前のベンダー
・付き合いが長く社内システムを良く知る
・縦割り会社なので部門間で調節役を買ってくれる
そんな便利屋的要素に依存して頼み続ける傾向がある。

徐々にベンダーに任せきりになり、開発したシステムは「ベンダーの責任」となる
(本来CIOのベンダ見極めや、協力会社の技術力評価による失敗である)

経営者は企業の情報資産を見える化し、理解を深め、既存システムのアセスメントを行う必要がある。
不要な機能は破棄し、システムの規模を見直し、複雑度を軽減する。
当然この規模の意思決定はトップによる強いリーダーシップが必要である。

11.事業部門のコミット

システム開発とは、「納期以内に完成したか」ではなく「システムによってビジネス効果が上がったか」で判断すべきである。

事業部門は便利&必要なシステムを作ることでビジネス価値を産むことがだけが仕事になってしまっている。
評価対象に取り入れられていない以上、システム開発に関わることは「余計な仕事が増えた」と感じるのが現状である。
開発に参加していないため、複雑化しないよう必要以上の機能開発を抑えているシステム部門には「なんで開発してくれないのか」と不満だけが挙がってしまう。

システム部と事業部はお互いの現状理解と、全社的なシステム構築方針にのっとって
共に開発していくのが理想の姿である。

12.刷新にむけた取り組みと、持つべき人材

複雑化を防ぎ、刷新を考えるためにも
・システムのマイクロサービス化
・短いサイクルでのアジャイルな開発とリリース
が注目されている。

また、競争領域でないシステム部分は、共通の機能を求める複数の会社でシステム開発を行うなど、オープンな活動を通してコストの低減を図る。

刷新に際してユーザー側の人材として
・CDO(最高デジタル技術責任者)によるシステム刷新と経営変革
・業務知識とIT知識が組み合わせられる人材
・ビジネスの要求を明確にできる人材
・設計、開発できる人材
・AI,データサイエンティスト(この一分だけとりあえず付けといた感ある)

ベンダー側の人材として
・受託開発の依存から脱却した成長戦略を描ける人材
・新技術と手法を要件に適応できる人材
・ユーザーの要求をまとめあげる人材
・業務内容とデジタル技術を理解する人材

ベンダー企業とのwin-winな関係についても、契約方法の見直しや、刷新されたシステムはベンダー企業が他企業に販売できる仕組みなど、協力関係の新しい形を探す必要がある。
ベンダー企業もマイクロサービスやアジャイル開発について十分にキャッチアップできる人材をそろえる必要がある。

企業は学びなおしや、スキル明確化(IPA資格等)により人材育成を行い、先端技術は産学連携によりデータ提供と技術享受の関係を築いていく。

13.プランニング

経営層は
・DX推進の成熟度
・現状の情報資産の理解
・ビジョンの策定
が必要となるが、
取締役会でどの程度議論されているかのチェック項目として「実効性評価項目」が発行されている

2020年からプランニングを行い、2021年から2025年にかけて既存システムの刷新を進め、データ活用の実行に繋げていくのが理想である。

え? まだ刷新に動き出してない?

\huge{大丈夫!だって、
}
\huge{2021まで、あと2か月あるのだから...
}

2020/10/02 執筆

参考資料

DXレポートとは、2018年9月に経済産業省より発行された文書
同年12月に「DX推進ガイドライン」

2019年7月
「DX推進指標とそのガイダンス」
「DX推進における取締役会の実効性評価項目」が発行され、具体的なチェック項目が公開された

どのレポートも十分に整理され読みやすく、現状を俯瞰的に説明している。

DXレポート本文
DX推進ガイドライン
DX推進指標とそのガイダンス
DX推進における取締役会の実効性評価項目

10
10
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
10