SIビジネスには長年蓄積されてきた構造的な歪みが存在している。システム開発にまつわるトラブルもこの歪みに端を発するものが多い。SIerとしてシステム開発に携わってきた筆者が、「歪みを解消するためにSIerがすべきこと」を考察する。
この記事は会員限定です。会員登録すると全てご覧いただけます。
ユーザー企業にとって、SIerはITシステムの導入から運用、故障時の対応や更新などに欠かせない存在です。
ただし、その関係性はと言うと、対等なパートナーと言うよりも、ユーザー企業はSIerに対して丸投げしがちで、SIerも「お客さまであるユーザー企業の要望は断りづらい」ために、ユーザー企業のITシステム全体の最適化よりも、その場その場のニーズへの対応を重視しがちな「御用聞き体質」が指摘されてきました。
しかし今、DX案件の増加やIT人材の慢性的な不足、ユーザー企業の内製化志向などのさまざまな環境変化によって、ユーザー企業とSIerとの関係は変わらざるを得なくなりつつあります。
この連載を通じて、SIビジネスを取り巻く構造的な問題を掘り下げ、ユーザー企業とSIerが目指すべき関係の在り方を探っていきます。
ユーザー企業とSIerとの関係が変化する中で、SIerはどう変わるべきか。長年蓄積されてきたSIビジネスの構造的な「歪(ゆが)み」を解消しなければ、SIerは立ち行かなくなると筆者は考えている。
では、「歪み」を解消するために具体的に何をすべきか。今回は、SIerがITシステムの変革を進めるために必要な技術を取り上げる。デジタルトランスフォーメーション(DX)を実現するためにはITシステムの変革が必要だが、そのためには高い技術が必要だからだ。
その前に、SIerがITシステムの変革に踏み込まない傾向にあることに触れたい。なぜ、ユーザー企業のDXを支援するSIerが、ITシステムの変革という「DXの本丸」に切り込もうとしないのか。SIer側として長年システム開発に携わってきた筆者の見立ては次の通りだ。
超巨大で複雑化、ブラックボックス化したITシステムを前に、ぼうぜんとして思考停止状態に入り、避けてきたというところだろう。分かりやすく言えば、「巨大で強力かつ凶暴なゴジラが出現し、対応不能になった自衛隊」のような心持ちだと思う。
超大型プロジェクトは難易度が極めて高く、失敗すれば大きな赤字を伴うというのはこれまでの連載でも述べてきたとおりだ。同じく、現行機能を保証するプロジェクトも難易度が高く、赤字に陥りやすい。これはIT業界では常識だ。
筆者の体感では、この2つの要素が合体した場合、そのプロジェクトが赤字に陥る可能性は、どちらか一つの要素しか持たないプロジェクトの数倍に膨れ上がる。そのため、SIerはこれらリスクの高いプロジェクトから逃げ、確実で安定的な案件に流れる傾向がある。案件の数としては、後者の方が多いこともある。いずれにしても、ITシステムを変革する必要性は重々承知していたが、取り組む姿勢を取ってこなかったというのが実態だろう。
ここから、今回の本題である既存ITシステムの変革に進む。筆者はITシステム変革に必要な技術は次の4つだと考える。
本稿では1のITシステムの「見える化」と、2の現行機能の復元に関する技術を解説する。
自社が抱える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システムの「見える化」だ。
これに関しては、「DX実践手引書」で紹介した「PFデジタル化指標」が有用になる。本稿ではポイントを解説する。
この指標は、機能システムごとに特異性を踏まえた上で、大きく3つの分類となる「DXへの対応力」「ITシステムとしての品質」「老朽化の度合い」で評価する仕組みだ。さらに機能システムごとの重要度などの重み付けを踏まえて、全体システムとして評価する。
人に例えるならば、「人間ドック」レベルの健康診断になる。胃や心臓に相当する機能システムが問題ないかどうかを評価し、ITシステムの“健康状態”を把握するのが目的だ。
3つの分類について簡単に解説しよう。
まず、DXの対応力については、「データの活用」「アジリティーの確保」「スピード」の3つを満たすことがDX対応のためにITシステムが備えるべき事項になる。
データに関しては前述した。アジリティーに関しては、要件変更への柔軟な対応などの機能面だけでなく、非機能面も要件となる。
今後、ITシステムには、想定できないデータ集中をはじめとした不確実性を前提とした柔軟な対応力、あるいは発生した障害による影響の極小化が求められるからだ。
例えば、インフルエンサーの影響で特定商品に対する大量の注文が突然発生した場合、サーバの処理能力を超えてしまう。この時、短時間あるいは動的にサーバのリソースを増強するような仕組みが非機能面におけるアジリティーだ。
前回触れたアジャイル型開発に対応するために、ITシステムの分割容易性についても評価項目になる。
次にITシステムとしての品質である。
これは、機能面とシステムの仕組みの両面から該当機能システムに求められる基本要件を満たしているかどうかを見極める項目だ。基本的には、本項目が満たされていなければ問題になる。
最後に、老朽化の度合いである。
ここでは、利用しているソフトウェアあるいはハードウェアなどのサポート切れ、ソフトウェアの設計情報の欠如(ブラックボックス化)、ソフトウェアの肥大化など、機能システムを維持管理するためにコストや期間、対応の柔軟性に問題が発生していないかどうか、つまり技術的負債化の度合いを示す指標だ。まさに、現状のITシステムが抱えている「パンドラの箱」の中身を明らかにするものだ。
このように、ITシステムを分割して、機能ごとの問題や課題を具体的に明らかにする。つまり、CEOが理解可能な粒度でITシステムの問題や課題を整理するのがPFデジタル化指標だ。この指標を理解することで、CEOが具体的に進めなくてはならない活動を認識し、リーダーシップを発揮することが可能になる。本質的なITシステム変革はここまできて初めて可能になるのだ。
現状のITシステムを知らずに語られるDX戦略は、「絵に描いた餅」にすぎない。既存のITシステムは、企業の姿を映す鏡だ。
当然、ユーザー企業にもITシステムを変革するための推進体制やそれなりのコストが必要になる。何よりもITシステム変革を進めるためのパートナーとの最初の共同作業となる。
このフェーズを共に進めるパートナーが、最重要のパートナーの第一候補になる。裏返すと、このフェーズは、SIerにとって、ユーザー企業にプロジェクトを十分に実施できるスキルと変革に向けての決意を示す良い機会になる。
ユーザー企業の将来を見据えて、課題を正確に示しつつ優先順位を付けた具体的な方策とユーザーが実施すべき作業をCEOレベルに分かりやすく示す高い技術が求められるからだ。
こうした過程を経て、状況を正しく理解したCEOから「一緒に改革を実施していただけますよね」という言葉に決意を示すことが求められる。
(注)詳細については、筆者がIPAでDXの推進責任者を務めていたときに作成責任者として携わった利用ガイド「プラットフォーム・デジタル化指標(PFデジタル化指標)」「DX実践手引書」に詳しい解説が記載されている。また、著書『SI企業の進む道』(日経BP)でも言及している。
Copyright © ITmedia, Inc. All Rights Reserved.