株式会社エル・ティー・エス
取締役　ビジネスコンサルティング第2部長
上野 亮祐 氏

はじめに

「2025年の崖」発表からもう2年半

「2025年の崖」という象徴的なキーワードが登場した経済産業省の『DXレポート』が発表されてから、2021年4月で2年半が経とうとしています。同レポートで謳われた、「日本企業は今後DXを推進しなければ、2025年以降、最大で年間12兆円の経済損失が生じる可能性がある」「その原因の一つは、老朽化や複雑化、ブラックボックス化している既存の基幹システム（レガシーシステム）である」^[1]という警鐘はIT業界やIT部門において広く認知され、基幹システムの再構築というテーマが国内企業の多くにとって非常に深刻な問題であることを示すきっかけになりました。

この2年半、読者の皆さんの企業での基幹システム再構築の取り組みはどのように進んだでしょうか。日経BPの『DXサーベイ2』調査によると、2020年末時点でも約4割の企業が「自社の基幹システムはDX推進の足かせとなっている」、と答えているようです^[2]。

そのような状況の中、多くの企業は今後数年間で基幹システムの再構築を進めようとしています。同レポートでも、調査対象の企業群の58.7%が一部または全面的に基幹システムを再構築する予定であると回答しています(図1)。また、その比率は基幹システムに複雑な業務プロセスが埋め込まれている大企業ほど高く、5000人以上の企業に至っては9割以上が再構築を予定しているという状況です(図2)^[3]。「2025年の崖」というデッドラインを意識しつつも、この2年半で基幹システムの再構築を完了し、新たな企業変革に取り組むことができた企業はほんの一握りだった、ということでしょう。

成功の鍵はユーザ企業のプロジェクトへの関わり方

「激変する外部環境に対応すべく、一刻も早く基幹システム再構築を終え、新たな企業変革に取り組みたい。最新技術さえ使えば簡単にそれができるのではないか―。」経営者の甘い期待とは裏腹に、過去数年間、システム開発の品質・納期・コスト順守状況にはほとんど改善が見られていないのが実態です。以下の図3はシステム導入工期の順守状況を示したグラフですが、500人月以上の規模のプロジェクトでは実に4割以上で遅延を生じており、その傾向は過去数年ほぼ横ばいとなっています^[4]。

これについて、同調査では、回答した企業の約半数がその最大の原因として、「自社要員の要員不足・スキル不足」を挙げています^[5]。基幹システムの再構築をスピーディに実行し、新たな変革に臨むためにはユーザ企業側のケイパビリティの向上が不可欠なのです。

私は、株式会社エル・ティー・エス(以下、当社)というコンサルティング会社に所属し、これまで、数多くの企業様の基幹システムの再構築を支援してきました。特に昨今では、従来のプロジェクト運営を脱し、試行錯誤の中で新たなチャレンジをすることで、大きな成果をあげる事例が現れ始めています。その鍵はやはりユーザ企業側のプロジェクトへの関わり方です。本稿では、実際に当社がご支援したプロジェクト事例を踏まえ、ユーザ企業に属する皆様が今から基幹システム再構築を推進する上で意識すべきポイントを述べていきます。もちろん、複雑な基幹システム再構築のプロジェクトに特効薬はありませんが、本稿が貴社の基幹システム再構築の成功に少しでもお役に立てることを願っています。

①構想策定：重要な議論に集中する

プロジェクトのWhyとWhat

いかなるプロジェクトにおいても最も重要と言って差し支えないのがこの構想策定フェーズです。このフェーズの目的は、「”なぜ”このプロジェクトを行うのか（=Why）」と「”何を”このプロジェクトで行うのか（=What）」を決定し、実際のプロジェクト計画のための指針を示すことにあります。様々なステークホルダーを巻き込みながら推進する基幹システム再構築においては導入完了までに多岐にわたる意思決定や葛藤があります。構想策定フェーズのアウトプットは、そういったプロジェクトの中で何度でも立ち戻ることのできる「骨太の方針」であるべきです。そのため、上記のWhyとWhatを経営、情報システム部門、エンドユーザ部門含めすべてのステークホルダーとしっかりと議論し、合意することが重要となります。昨今ではビジネススピードの加速を背景に、構想策定フェーズの期間も短期化の傾向にあります。私がご相談いただく案件も、多くが半年以内、短い場合は3カ月で構想を作り切りたいという要望も増えています。さらには、技術革新に伴いソリューションの選択肢も多岐にわたるようになり、Whatに関する意思決定も非常に複雑になっています。構想策定フェーズで重要な議論に集中し、高い品質のアウトプットをすることがプロジェクト全体の成否を占うと言っても過言ではありません。

あるべき構想策定フェーズと現実

しかし、このように重要な構想策定フェーズであるにもかかわらず、議論が短期間で煮詰まらない、または想定以上に多くの時間がかかってしまう、といった企業を多く見てきました。その実態が、以下の図4にあるような不適切な　時間の使い方にあると考えています。

本来あるべき構想策定フェーズにおいては、1) whyとwhatの議論に十分な時間を割きつつ、2) 全体として短期間で構想をまとめ切る、ことが求められます。一方で、現実のプロジェクトにおいては多くの場合、現状業務分析や課題抽出に莫大な工数が取られ必要な議論の時間が削られてしまうことが多いのが実態です。

なぜこのようなことが起こるのか、読者の皆様にも心当たりがあるのではないでしょうか。多くの企業において、現場の作業担当者のための手順書やシステム構築時の設計書は存在しても、業務変革やシステム再構築を進めるために必要な俯瞰的な業務・システムの資料は存在しません。また、現行システムを導入してから10年以上が過ぎ、当時のビジネスロジックを理解していた社員が退職・異動し、現行システムの仕様がブラックボックスであるということもよくあります。当社が担当するお客様の大半も多かれ少なかれそのような課題を抱えており、従来のプロジェクトであればその文書化のためだけに数カ月という期間をいただくようなこともありました。しかし、すでに申し上げた通り現状業務分析そのものの付加価値は決して高くありません。繰り返しになりますが、必要なのはWhyとWhatの議論であり、現状業務分析はそのためのインプットにすぎないからです。

現状業務分析と要求整理を並行実施することで生産性を向上

では、そのような状況の中で現状業務分析の期間を短縮し、議論すべき内容に集中するためにできることはなんでしょうか。最近の事例では、プロジェクトの中で自分たちが導入する可能性の高い基幹システムパッケージの標準業務フローや標準機能をベースに、Fit-Gap方式で現状業務・システム分析と要求整理を一気に進める手法が増えてきています（図5）。

これは従来であれば、製品選定後に実施していたFit-Gap分析を製品選定前の構想策定の段階で簡易的に実施してしまう、というものです。こうすることで、現状業務と並行して、将来の業務・システム像を描くというWhatの議論を早期から進めることができます。また、実際の画面イメージを確認しながら議論を進めることで、システム刷新後の業務のイメージをより鮮明に持つことができ、結果的に議論の質の向上にもつながります。さらには、分析の結果、自社の業務がターゲットシステムの標準的な業務フローや機能とマッチしていれば、ベンダー選定のプロセス自体を削減することも可能です。仮に、Fit-Gapの結果マッチ度合いが低ければ、改めて別の製品を選定する方向に舵を切ることもできます。

ERP導入がすでに一般的となり、製品各社も標準的なプロセスや機能を公開している今だからこそ、ゼロから自社の現状業務を整理し、そのうえであるべき像を描くのではなく、ターゲットシステムの標準をベースに現状と将来像の議論を並行することで、より付加価値の高いWhyとWhatの議論に力を注ぐことができると考えています。

②構築：ユーザ企業がプロジェクト推進にオーナーシップを持つ

ユーザ企業がオーナーシップを持つ≠内製化

2つ目のポイントは、体制構築です。従来の日本国内のシステム開発においては、特定のベンダーにシステム導入のすべてを依存してしまう、いわゆる「ベンダー丸投げ」という関係性が続いてきていました。

すでに『DXレポート』をはじめ多くの識者が述べている通り、ベンダー丸投げ型のシステム開発では、ユーザ企業とITベンダーの間では交渉関係や利害相反が発生してしまうことも多く、そのコミュニケーションコストは膨大です。また、劇的な外部環境の変化に対して、プロジェクトを進めながら要件の優先度や課題対応をスピーディに行っていくためにも、システム導入を進めるユーザ企業自らが主導するプロジェクト体制を組成することは必須であると考えます。

私たちがこのような説明をお客様に差し上げると決まって、「内製化を進める必要がある、ということは頭では分かっているが、突然エンジニア社員を採用してプロジェクトを組成するということは不可能」というような反応をいただきます。ここで強調したいのは、内製化もユーザ企業が主導的にプロジェクトを進める上での一つの手段にすぎない、ということです。大切なことはユーザ企業が「主導的に」体制を構築することであり、「オーナーシップを持って」プロジェクトを推進する、ということです。

ITベンダーとの関係性を再構築する

当社のあるお客様では、従来は自社のIT子会社に一括請負の形で業務委託していたシステム開発を、領域ごとの専門性(例えば、ソリューションコンサルタント、インフラ技術者、データサイエンティスト、PMO、等)を持った人材を準委任の形で集め、自らがPMとなって自社の責任でプロジェクト導入を進められています(図6)。もちろん、IT子会社の人材は自社システムに関する経験も豊富であり、貴重なパートナーとして参画していますが、同時に、小規模でも技術力がある企業や、優秀な個人事業主も含め、プロジェクトには非常に多様な人材が配置されています。それにより、予算抑制や柔軟なプロジェクト運営はもちろん、新たな外部の知見を入れて難易度の高いチャレンジにも自社のリスクで取り組むことができています。また、これまではプライムベンダーの下で仕事をしていた小規模企業や個人事業主にとっては、ユーザ企業と直接繋がり、パフォーマンスを発揮できる非常に魅力的な機会であり、参画するメンバーの意欲向上にも寄与しているようです。

このように、先進的な企業では、ベンダーとの関係がここ数年で様変わりしてきています。過去の日本企業のITベンダーへの期待は「IT機能の一部、または全部の仕事を任せる」というものでした。しかし、今では「自社に必要な外部の技術やノウハウを取り込むための連携先」という風に意識が変化していることを肌で感じます。上述のお客様もその点は強く意識されており、例えばパッケージ導入であればパッケージベンダーの営業担当者だけでなく、製品開発のSEも含めてプロジェクトに巻き込み、製品が元々持っているポテンシャルを最大限発揮しながらプロジェクトを進めています。自社が主導的にオーナーシップを持って情報を集め、ITベンダーとの関係性を幅広く構築することさえできれば、内製化にこだわる必要はない、ということがお分かりいただけるのではないでしょうか。

③保守運用：小さく始めて育てる

システム導入の一環としての攻めの保守運用

最後のポイントは、基幹システム導入は小さく始めて育てる、という視点です。従来の基幹システム導入プロジェクトにおいては構想策定から導入まで1年半～2年程度、場合によってはそれ以上の期間がかかるというのが一般的でした。しかし、現在の劇的なビジネス環境の変化においては、2年前に想定した要件が全く使い物にならない、ということはよくあることです。昨今の当社への相談の中でも、1年以内にシステム再構築を目指したい、というお客様からの問い合わせも増えてきています。

そういった背景も踏まえて増加傾向にあるプロジェクトのあり方が、「小さく始めて、育てる基幹システム」という考え方です。初期の導入はウォーターフォール型ではあっても、スピード重視で終え、その後、数年かけて徐々に必要な機能を追加していく、という方式です。これは、従来のように、「ユーザからの問い合わせや法定要件の変更を予算の範囲で改善する」という受け身の保守運用ではなく、「基幹システム導入の一環として、システムを実際に使用しながらアジャイルでユーザと共にあるべき姿を構築していく」という攻めの保守運用の姿、と言ってもよいかもしれません。

育てる基幹システムのポイントは人の成長

このような導入をすることの最大のメリットは、ユーザ側のリテラシが向上し、本当に必要な機能を必要な時に構築することができることにあります。基幹システムという複雑なシステムの全体像を理解する一方、ベンダーに作成してもらう設計書の妥当性を細かく判断する、というような業務は経験がない方にとっては非常に困難で、やはり習熟するには相応の経験が必要です。従来型のビッグバンでの大規模導入ではそういった熟練がないままプロジェクトが終了し、体制も解散してしまいます。保守運用フェーズを回しながら、実際のエンドユーザの利用状況に触れつつ、日々ベンダーとやり取りをする中でそういった力は自然に身に付きますし、それにより、優先順位を定めながらより品質もコストも適切な追加開発を進めていくことができます。

当社のあるお客様では、基幹システムの導入を9カ月で終了し、その後数年をかけて改善を続けています。元々は要件定義書のレビューにも苦戦されていた情報システム部門のご担当者様でしたが、このような改善の期間を経て、パッケージの仕様やベンダーの見積妥当性の判断にもかなり習熟し、エンドユーザと共に議論して優先順位をつけていく姿は非常にたくましく、まさにあるべきシステムを創り続けるリーダーです。この事例では、正直に申し上げると、導入時は狙ってこのような導入をしたわけではなく、期間と予算の制約でそうせざるを得なかった、というのが実態ではあります。しかし、改めて振り返ると、ユーザ側のリテラシがない状態で機能追加の議論をするのと比べて、運用フェーズも含めてじっくりと腰を据えて必要な機能を見極めていくという姿勢が費用対効果の高いシステム導入に繋がっていると実感しています。

おわりに

プロジェクトの成功とは

ここまで、様々なお客様の悩みを伺い、一緒にプロジェクトを進めてきた経験から感じる、この時代にあった基幹システム再構築の成功則をお話してきました。いかがだったでしょうか。何か皆様のお役に立つことができれば幸いです。

最後になりますが、改めて基幹システム再構築の成功とはなにかということを少し考えてみましょう。2000年代当初、大規模ITプロジェクトの勃興初期は品質・コスト・納期通りにプロジェクトを完遂することがプロジェクトの成功と言われていました。その後、単にシステムを作るだけでなく、それが経営に資する貢献があったか否かをしっかり判断すべきと言われるようになり、ROIといった概念が注目されてきました。

しかし、プロジェクトの成功を測る尺度はそれだけでしょうか。私はプロジェクトの成功とは、プロジェクトを通じて企業が変革実行能力を手に入れることができたか否かであると考えています。変革実行能力とは、昨今の事業環境において必須となる、「変化を受け入れ、自己を変革しながら社会の変化を生み出す力」です。これからの事業経営においては、基幹システムの再構築すらも実はその能力を手に入れる手段にすぎない、というのが私の考えです。

そして、この変革実行能力の最大の肝は、それを推進する「人」という要素にあると考えています。基幹システム再構築プロジェクトを通じて社員が成長し、これから何度も繰り返される変化に対して意欲を持って取り組める状態を作ることが、素晴らしいシステムを導入することと同じか、それ以上に重要です。

御社の基幹システム再構築プロジェクトは、社員にとって魅力的な仕事になっているでしょうか。若手のリーダーが、手を挙げてやってみたいと思うようなチャレンジングな仕事でしょうか。ベンダー丸投げで調整業務をするだけ、というレガシーシステム再構築になっていませんか。これまでお話した3つのポイントを活かしつつ、ユーザ企業の社員が主役となってシステム再構築プロジェクトを進めることで、ひとつでも多くの企業で変革実行能力の火が灯ることを強く願っています。

^[1] 『DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～』（2018）経済産業省
^[2] 『DXサーベイ2　Withコロナ時代の実態と課題分析　2-28-1. 既存の基幹系システムの足かせ度、昨年よりも深刻？』(2020) 日経BP
^[3] 『DXサーベイ2　Withコロナ時代の実態と課題分析 2-28-3. 従業員数が増えるほど「2025年の崖」問題は深刻に』(2020) 日経BP
^[4] 『企業IT動向調査報告書2020 9.2 システム開発における工期・予算・品質』(2019) 日本情報システム・ユーザー協会
^[5] 『企業IT動向調査報告書2020 9.3 プロジェクト悪化傾向の主な要因』(2019) 日本情報システム・ユーザー協会