目的：
日本産業の盛衰に大きく関連する「２０２５年の崖」の対策について
整理をいたします。
ねらい：
日本の衆知を集めて崖対策は実行しなければなりません。
ーーーーーーーーーーーーーーーーーーーーーーーー
１，「２０２５年の崖」とは何か
「２０２５年の崖」とは、２０１８年９月に経済産業省が
「ＤＸレポート」で述べた問題提起です。
これについては、
当ブログ２０１８，１０，１７「 とうとう国も「ＤＸ」の旗振りを始めました！！ 」
http://uenorio.blogspot.com/2018/10/blog-post_4.html
でも取りあげました。
あらためて、要約するとこういうことです。
・老朽化した情報システムは、経営のデジタル化の足を引っ張る。
早急にこの老朽システムの刷新を図らないと、
日本産業の競争力は著しく低下する。
・既存システムは、そもそも事業部門ごとに構築されて
全社横断的なデータ活用ができなかったり、
過剰な要求仕様が組み込まれている、などに加え、
技術の老朽化、有識者の退職、過度なベンダ依存等により
複雑化・ブラックボックス化している。
・経営者がＤＸ（デジタル化経営）を望んでも、
データ活用のために
上記のような既存システムの問題を解決しなければならず、
そのためには業務自体の見直しも求められる中
（＝経営改革そのもの）、
現場サイドの抵抗も大きく、
いかにこれを実行するかが課題となっている。
・この課題を克服できない場合、ＤＸが実現できないのみでなく、
2025年以降、最大12兆円／年（現在の約3倍）の経済損失が
生じる可能性がある。
２．なぜシステムの再構築が行われないのか
そんな問題含みのシステムを
なぜ作り直さずに放置しているのでしょうか。
長年この問題を見てきた私の見解はこうです。
１）再構築には非常に大きな労力・コストがかかる
最近の最大の成功例みずほ銀行の場合は
4,000億円台のコストがかかったといわれています。
どんな企業でも数億円で済むということは考えられません。
２）計画どおりにできないリスクがある
現実に、巷では数多くの失敗例が報告されています。
３）どういう方法で新システムを「再構築」したらよいか分からない
伊勢神宮の式年遷宮のような技術継承をしていませんので、
再構築の経験者は社内にほとんどいません。
昨今はシステム開発方式の技術進歩もあり、
方向性の見極めができない状況という面もあります。
４）再構築の効果を経営に説明できない
非常に大きなコストを正当化する根拠を提示できる手法を
各社は持っていません。
ＤＸレポートでは、「現場の抵抗」もあるように書かれていますが、
ほとんどがそれ以前の問題です。
３．なぜ、あるべきシステム再構築方法が分からないのか
（１）システム再構築方法の選択
システム再構築の方法としては、大きな分類では以下の３通りがあります。
（クリックしていただくと全体が表示されます）
簡単に言うと、リホストはシステムインフラのコストダウンはできますが、
２０２５年の崖対策には全くなりません。
リビルドが、崖対策として本命なのですが「大仕事」でリスク大です。
リライトの特性は、その中間です。
リライトの特性は、その中間です。
この選択は、システム再構築の目的を明確にすれば簡単にできます。
迷うのはこの選択ではないのです。
（２）システム再構築方式の選択
開発してから１０年以上経過しているシステムの場合、
現場では大小さまざまな変更要求がたまっています。
システムを作り直すのなら、この際に、と要求が噴出します。
システム再構築はリビルドに進まざるを得ません。
そうすると、どういう方式で新しいシステムをつくればよいのか、
というシステム・アーキテクチャの選択問題が発生します。
国の外郭団体である情報処理推進機構（ＩＰＡ）が出している
「システム再構築ガイド」では、
前掲のシステム再構築「方法」の選択については詳しく解説しているのですが、
システム再構築「方式」については触れていません。
システム再構築「方式」の主な選択肢は、
以下のとおりであると考えられます（主として上野見解）。
（クリックしていただくと全体が表示されます）
以下のとおりであると考えられます（主として上野見解）。
（クリックしていただくと全体が表示されます）
どの方式が良いのかの検討事例または見解は、
これまで発表されていません。
そのため、システム再構築「方式」の選択の知見が広まっていないのです。
そこで、システム企画研修株式会社では、
上記の究極の手法の部分に関わってきた３社で組んで、
この手法の発表会を開催することとしました。
詳細は未定ですが、２０２０年２月２０日頃の開催を目指して
準備中です。
詳細が決まりましたら、ご案内いたしますので
よろしくお願いいたします。
2 件のコメント:
日米のシステム構築の最大の違いは、情報システムは米国ではユーザーが構築するもの、日本ではベンダーに依頼するもの、でこの両者の違いはエンジニアの派遣型と請負型に表れています。請負型は、固定のコストと納期で発注するので、どうしてもユーザーは豊富な機能を盛り込もうとします。派遣型は、受け入れる方がコスト削減に動き、機能を削ろうとします。
その結果で、今の日本のスパゲティ型の豊富な機能の業務システムが出来上がったのです。日本人の器用で細部にこだわるという特徴も、この日本の複雑な業務機能を作る後押しをしました。一方、これを打破するためにＰＫＧの活用が飛躍的に増加したのですが、ＰＫＧに合わせず大量なカスタマイズをしてしまいました。ＰＫＧ導入の意味が薄れてしまったのです。
今頃になって、複雑だからシンプルにしようなどと言っても、後戻りできません。再度、シンプル化にチャレンジしても、無駄に終わるでしょう。これは、開発ツール、方法論によるものではなく、情報システム構築の仕組み、制度による結果にすぎません。米国はなぜ派遣型でユーザーが主体でシステム構築できるかと言えば、人材の流通が盛んに行われる文化なので、ユーザーはプロジェクト開始にあたって必要な人材を採用できるからです。日本ではとてもこうはいきません。残念ながら、根は相当深いと理解すべきだと思います。『米国流システム構築が日本企業を救う！』という図書が参考になるのではと思います。
匿名さん
ご意見ありがとうございます。
ご指摘のなぜ保守のしにくいシステムになっているかについては、
本稿では触れていませんでした。
私の整理ではこうなります。
１．開発の時から保守性を重要視して作っていない
「まずは動かさなければらない」という状況で、保守のことを考えて作る余裕がありませ んでした。これは米国でも同じだそうです。
現在はＳＯＡ手法を活用したコンポーネント疎結合型が保守性重視の「作り」となってい ます。
２．日本では「外注利用」により企画機能と実装機能が分離している。
ご指摘のとおりのことからこうなっているのですが、
そのため、企画側は実装のことを考慮しないで丸投げしている。
実装側は自分たちに都合のよいように（というよりは最低限の工数で「とりあえずできれ ばよい」主義で）作業をしている。
自分一人でするのならそんな後々ぐあいが悪い方式で処理をしません。
３．分離のせいもあって、誰も本気で保守業務のあり方を研究していない。
経営者も「保守はなければ一番良い」というハードの保守と同じように考えて、
保守に人材も費用も振り向けない。
したがってまともな体制で保守が実行されるわけがない、のです。
他にもたくさんの２次的・３次的原因があります。
なお、ご指摘の「米国流システム構築が日本企業を救う」につきましては、
当ブログでもご紹介しています（２０14.2.23[IT経営者が素晴らしい小説を発表！！」）
コメントを投稿