なぜSIerは「DXの本丸」に切り込もうとしないのか？

　ユーザー企業とSIerとの関係が変化する中で、SIerはどう変わるべきか。長年蓄積されてきたSIビジネスの構造的な「歪（ゆが）み」を解消しなければ、SIerは立ち行かなくなると筆者は考えている。

【その他の画像】

　では、「歪み」を解消するために具体的に何をすべきか。今回は、SIerがITシステムの変革を進めるために必要な技術を取り上げる。デジタルトランスフォーメーション（DX）を実現するためにはITシステムの変革が必要だが、そのためには高い技術が必要だからだ。

●なぜSIerは「DXの本丸」を避けるのか？

　その前に、SIerがITシステムの変革に踏み込まない傾向にあることに触れたい。なぜ、ユーザー企業のDXを支援するSIerが、ITシステムの変革という「DXの本丸」に切り込もうとしないのか。SIer側として長年システム開発に携わってきた筆者の見立ては次の通りだ。

　超巨大で複雑化、ブラックボックス化したITシステムを前に、ぼうぜんとして思考停止状態に入り、避けてきたというところだろう。分かりやすく言えば、「巨大で強力かつ凶暴なゴジラが出現し、対応不能になった自衛隊」のような心持ちだと思う。

　超大型プロジェクトは難易度が極めて高く、失敗すれば大きな赤字を伴うというのはこれまでの連載でも述べてきたとおりだ。同じく、現行機能を保証するプロジェクトも難易度が高く、赤字に陥りやすい。これはIT業界では常識だ。

　筆者の体感では、この2つの要素が合体した場合、そのプロジェクトが赤字に陥る可能性は、どちらか一つの要素しか持たないプロジェクトの数倍に膨れ上がる。そのため、SIerはこれらリスクの高いプロジェクトから逃げ、確実で安定的な案件に流れる傾向がある。案件の数としては、後者の方が多いこともある。いずれにしても、ITシステムを変革する必要性は重々承知していたが、取り組む姿勢を取ってこなかったというのが実態だろう。

●既存のITシステムをいかに「見える化」するか？

　ここから、今回の本題である既存ITシステムの変革に進む。筆者はITシステム変革に必要な技術は次の4つだと考える。

1. 現状のITシステムの抱える問題と課題を「見える化」する技術

2. 既存ITシステムの現行機能を見える化し、設計情報を復元する技術

3. 新たなソフトウェア開発技術（オブジェクト指向型開発）

4. システム変革に向けてのシナリオ策定とシステム移行方式を確立するための技術

　本稿では1のITシステムの「見える化」と、2の現行機能の復元に関する技術を解説する。

●1.　現状のITシステムの抱える問題と課題を「見える化」する技術

　自社が抱えるITシステムの実態を明らかにすること、特にCEOにITシステム変革を自らの責任で進めなくてはならないことを自覚させることが「見える化」の大きな目的の一つだ。

　そもそも多くの企業は、自社のITシステムがどのような構成になっているかを示す「全体システム構成図」を持っていない。ITシステムは、部門ごとに最適化された仕組みから始まり、必要に応じて各部門のシステムを接続している場合が多い。つまり、全体最適は考えられていないのである。当然の帰結として複雑で統率されておらず、バラバラだ。

　全社システム構成図が存在しないことは、全社のDX戦略を立てる以前の問題だろう。全社のDX戦略を立案するためには、デジタル技術を核として、事業や業務を抜本的に変革する必要があり、各部門に対する強力な調整機能が求められる。その「機能」を持っているのは企業ではCEOしかいない。

　しかし、筆者の見るところ、日本企業のCEOの多くはデジタル技術に興味を持たず、自分の仕事とは考えていない。ITシステムに関しては、CIO（最高情報責任者）に丸投げしているケースも多い。日本企業では、CIOは各部門の下請け部門と見なされることがあり、部門間を調整する権限をCEOから与えられていない場合がほとんどだ。

　米国には、CIOはCFO（最高財務責任者）並みの権限と地位を与えられ、CEOと健全な対立関係を構築している企業が多数ある。DXに取り組むためには、CIOの権限も含めて経営体制を変革することが求められる。

　いずれにしても、CEOが真のDXを推進するための「一丁目一番地」は、全体システムの構成図を理解して、その構成要素となる部門ごとのシステムが抱える課題を客観的に把握することだろう。これが第一のステップだ。

　これはある意味、SIerとIT部門がうすうす気付いていた課題を白日の下に晒（さら）すことになる。パンドラの箱を開け、CEO自身がITシステムと向き合うことになるだろう。

　その上で、会社全体として、経営体制の変革も踏まえてITシステム変革をどう進めていくかという計画を策定する必要がある。

　計画策定と同時に、優先順位の高い項目は待ったなしで実行しなければならない。全体計画の策定は極めて重要だが、それと並行して行動に移ることが重要だ。

　既存システムの「見える化」に必要なのが、既存の全体システム構成図の策定だ。「P2M」（プログラム・アンド・プロジェクトマネージメント）と呼ばれる超大型のITシステムの現状を整理する手法が利用されるが、これは極めて難易度が高い。

　第二に、全体システムを構成している機能システム単位に状況を「見える化」し、課題と優先順位を明確化する。

　第三に、第一と第二を合わせ、さらに重要な新たなビジネス変革に関する要素を含めて、ITシステムの変革計画を策定することになる。

　ただ、これは既存SIerがユーザー企業と一体となって進める必要がある。技術的な難易度が高いため、SIerの支援が必須だと筆者は考えている。そういう意味で、SIerがまず必要な技術は、第一と第二の技術だ（注）。ここではこの2つの技術のポイントを述べたい。

「全体システム構成図」はどう作成すべき？

　まず、全体システム構成図の作成から見ていこう。

　ITシステムを考える際、業界共通のITシステムの大きさの概念「サブシステム」を使う。大企業には1000超のサブシステムが存在するため、このレベルで整理すると全体的な状況を把握するのが困難だ。「木を見て森を見ず」になってしまう。そこで、20〜30個程度の部門システムを「機能システム」と定義して整理する。例えるなら、人体を心臓・腎臓・肝臓といった臓器レベルで把握するようなものだ。このレベルであれば、CEOも全体感を持ちながら、具体的な既存ITシステムの課題を把握できるだろう。

　機能システムレベルの何らかのドキュメントは存在するものの、書式や機能システムに関する説明がどの程度詳細に記載されているかが部門ごとにバラバラという企業が多い。さらに、稼働しているサブシステム全てが記載されているかどうかも不明だ。あるサブシステムが他の部門システムのドキュメントに二重に記載されている場合もある。

　各部門にヒアリングしてこうした内容を整理し、その内容をレビューしながら全体システム構成図は精緻化されていく。これには、相当長い経験を積んだSEが中心となったチームが必要だ。情報処理推進機構（IPA）のガイド「DX実践手引書」を基に、具体的な事例でトライアンドエラーを繰り返すことも必要となる。そのためには、適切なユーザー企業を早めに見つけ、実践することがSIerにとって重要になる。

既存のITシステムをいかに「見える化」すべきか？

　次に、既存ITシステムの「見える化」だ。

　これに関しては、「DX実践手引書」で紹介した「PFデジタル化指標」が有用になる。本稿ではポイントを解説する。

　この指標は、機能システムごとに特異性を踏まえた上で、大きく3つの分類となる「DXへの対応力」「ITシステムとしての品質」「老朽化の度合い」で評価する仕組みだ。さらに機能システムごとの重要度などの重み付けを踏まえて、全体システムとして評価する。

　人に例えるならば、「人間ドック」レベルの健康診断になる。胃や心臓に相当する機能システムが問題ないかどうかを評価し、ITシステムの“健康状態”を把握するのが目的だ。

　3つの分類について簡単に解説しよう。

　まず、DXの対応力については、「データの活用」「アジリティーの確保」「スピード」の3つを満たすことがDX対応のためにITシステムが備えるべき事項になる。

　データに関しては前述した。アジリティーに関しては、要件変更への柔軟な対応などの機能面だけでなく、非機能面も要件となる。

　今後、ITシステムには、想定できないデータ集中をはじめとした不確実性を前提とした柔軟な対応力、あるいは発生した障害による影響の極小化が求められるからだ。

　例えば、インフルエンサーの影響で特定商品に対する大量の注文が突然発生した場合、サーバの処理能力を超えてしまう。この時、短時間あるいは動的にサーバのリソースを増強するような仕組みが非機能面におけるアジリティーだ。

　前回触れたアジャイル型開発に対応するために、ITシステムの分割容易性についても評価項目になる。

　次にITシステムとしての品質である。

　これは、機能面とシステムの仕組みの両面から該当機能システムに求められる基本要件を満たしているかどうかを見極める項目だ。基本的には、本項目が満たされていなければ問題になる。

　最後に、老朽化の度合いである。

　ここでは、利用しているソフトウェアあるいはハードウェアなどのサポート切れ、ソフトウェアの設計情報の欠如（ブラックボックス化）、ソフトウェアの肥大化など、機能システムを維持管理するためにコストや期間、対応の柔軟性に問題が発生していないかどうか、つまり技術的負債化の度合いを示す指標だ。まさに、現状のITシステムが抱えている「パンドラの箱」の中身を明らかにするものだ。

ITシステムを知らずに語られるDX戦略は「絵に描いた餅」

　このように、ITシステムを分割して、機能ごとの問題や課題を具体的に明らかにする。つまり、CEOが理解可能な粒度でITシステムの問題や課題を整理するのがPFデジタル化指標だ。この指標を理解することで、CEOが具体的に進めなくてはならない活動を認識し、リーダーシップを発揮することが可能になる。本質的なITシステム変革はここまできて初めて可能になるのだ。

　現状のITシステムを知らずに語られるDX戦略は、「絵に描いた餅」にすぎない。既存のITシステムは、企業の姿を映す鏡だ。

　当然、ユーザー企業にもITシステムを変革するための推進体制やそれなりのコストが必要になる。何よりもITシステム変革を進めるためのパートナーとの最初の共同作業となる。

　このフェーズを共に進めるパートナーが、最重要のパートナーの第一候補になる。裏返すと、このフェーズは、SIerにとって、ユーザー企業にプロジェクトを十分に実施できるスキルと変革に向けての決意を示す良い機会になる。

　ユーザー企業の将来を見据えて、課題を正確に示しつつ優先順位を付けた具体的な方策とユーザーが実施すべき作業をCEOレベルに分かりやすく示す高い技術が求められるからだ。

　こうした過程を経て、状況を正しく理解したCEOから「一緒に改革を実施していただけますよね」という言葉に決意を示すことが求められる。

（注）詳細については、筆者がIPAでDXの推進責任者を務めていたときに作成責任者として携わった利用ガイド「プラットフォーム・デジタル化指標（PFデジタル化指標）」「DX実践手引書」に詳しい解説が記載されている。また、著書『SI企業の進む道』（日経BP）でも言及している。

●2.　既存ITシステムの現行機能を「見える化」し、設計情報を復元する技術

　ここから、2の既存ITシステムの現行機能を「見える化」し、設計情報を復元する技術に触れる。

　再構築を進めるに当たって最大の問題点となるのが、既存ITシステムの設計情報がブラックボックス化していることだ。この問題を解消するのが復元技術である。既存ITシステムの設計情報復元には、膨大なコストと時間がかかる。

　まずは現行のITシステムで不要なものの削除、廃止が必要になる。SIerのPMとしてシステム開発に携わってきた筆者も、新たな機能を開発する場合、よく似た既存のプログラムを修正して対応することが多かった。短期的には、時間とコストを抑えられるからだ。これを「モディファイ新規」と呼ぶ。

　この場合、新たな機能と関係のない機能は全て削除すべきだが、実際は使わないロジックもそのまま残るケースがほとんどだ。こうしてプログラム規模は大きくなっていく。

　システム老朽化の一因は、こうした不要なプログラムロジックの肥大化にある。時間がたつとその規模が膨らみ、実質的な機能の数倍ものソフトウェア資産を抱えるケースも見られる。

●「ブラックボックス化」している既存システムをどうする？

　いずれにしても、現行のITシステムで分析する範囲を極小化することが必要だ。その上で、次の3つに仕分けする。

1. 廃止する部位

2. 既存の機能は必要だが、実現方式・機能に関しては既存機能を包含して完全に作り直す部位

3. 既存の機能を忠実に再現する部位

リバースエンジニアリングには限界がある

　1は、技術的には対象外となる。

　2は現行機能の分析が必要になる。一般的には、概要設計の工程で現行機能の保証活動が必要になる。概要設計のキー情報の一つである業務フローに関しては、業務フローにおける各作業に関する現行システム・新システムの機能やデータの対応関係を一覧にした「対応表」を整理し、抜け漏れがないかどうかを確認する。

　また、画面や帳票、他システムのインタフェースデータやDB（データベース）に関しても、現行システム・新システムの対応表を整理し、抜け漏れがないかどうかを確認しなければならない。こうした準備作業を実施することで、既存ITシステムの機能は基本的に抜け漏れなく把握できる。

　システムの再構築を伴うITプロジェクトでこうした作業を実施しなければ、大きな機能の漏れが発生する可能性があり、大きなリスクになりかねない。特に、既存のITシステムを担当していない企業がシステムの再構築を手掛ける場合は、絶対に必要だと筆者は考える。

　特に重要なのは、概要設計のキー情報の情報復元技術だ。これに関して筆者は、IPAのDX実践手引書に詳しく理論を述べた。これは、私が野村総合研究所（NRI）で10年間かけて開発した手法を同社の許可のもと公開したものだ。

　同手法のポイントは、既存のITシステム（マイクロサービスなどで開発されていないシステム）は、基本的に4つのサブシステムの形態（O/L型、B/T型、Web型、GW(ゲートウェイ)型）があり、そのサブシステム形態ごとに概要設計のキー情報が異なる。

　具体的には、O/L型は業務フロー、B/T型はDFD（データフローダイグラム）、Web型は画面遷移図、GW（ゲートウェイ）型は状態遷移図だ。

　これらの情報をプログラム解析や業務マニュアルなどの資料や、現場で保守・開発を担当している技術者、業務で利用しているユーザー部門を対象としたヒアリングなどを通じて得た情報から復元する必要がある。

　プログラムをいくら解析しても、「何をしているか」は理解できても、「何のためにやっているか」という情報は存在しないからだ。概要設計レベルの情報の中には、工程が進むごとに消えていく情報が多く存在する。そのために、どのような情報を復元すべきかを明確化した上で、前述したプログラム解析などを実施して、失われた情報を丁寧に収集することが重要だ。

　リバースエンジニアリングには限界があり、プログラムに存在しない情報は復元しようがないからだ。ただ、現在、業務が実行されている以上、さまざまな手段を用いることで概要設計のキー情報を集めることは基本的には可能だ。

現行機能を保証するために何をすべきか？

　3の「既存の機能を忠実に再現する」は、2に加えて必要になる作業だ。大まかな考え方としては、工程単位で段階的に現行機能を保証することが肝要になる。簡単に言えば、外部設計では項目レベルでの現行システム・新システムの比較が必要になる。必要になる全てのデータ項目が新システムに存在することを保証する必要がある。

　内部設計レベルで作成されるプログラムとその機能が確定される。その時点で、新旧のプログラム単位での対応表を策定し、詳細設計レベルでコード単位に機能が網羅的に新プログラム機能に漏れなく反映されていることを確認する。このように、段階的に旧プログラムレベルの機能を保証する。

　段階的に進めるもう一つの理由は、プログラムレベルで機能を保証するためには、プログラムレベルまで新システムが詳細化されて比較可能になることと同時に、そのレベルで解析する体制が確立している必要があるからだ。プログラムを開発する体制が整わなければ、コードレベルで解析する体制も整備できない。

　このように、これまでの開発に加えてさらに工数とコストが発生する。総合テスト工程では、現行のシステムと新システムに同様の環境で同一のテストケースでテストし、現行機能が正しく反映されているかどうか、新旧のデータベースを比較して証明することが必要であり、そのために必要なテスト環境は大掛かりなものになる。

　総合テスト工程の新データベースが旧データベースとマッチングすることに基づいて、現行機能を保証するプロジェクトもある。しかし、ここまで述べてきた、機能の反映漏れを工程レベルで最小化する作業を実施しなければ、総合テストの期間中に対応できる範囲に絞り込めない。品質保証可能な範囲を工程ごとに定め一歩一歩段階的に品質を確保することで初めて想定のスケジュールで品質を保証できる。これは、ITプロジェクトマネージメントの要諦である。

　次回は、今後主流になるソフトウェア開発方式について解説する予定だ。