日本企業がビジネスにITを利用し始めてから半世紀以上。ITそのものが差別化要因となった時代から、ITはビジネスに必要不可欠なものとなり、現在では新しいテクノロジーを活用して市場に新たな価値を生み出すデジタルトランスフォーメーション（DX）が、企業の重要な経営課題になっている。

こうした時代の変化の中で、これまで「テクノロジーのエキスパート」として、ITパートナーと協力しながら、ビジネスを支えるITシステムの企画、開発、運用に携わってきた、企業のIT部門やIT関連会社に求められる役割にも変化が求められている。既存システムの安定運用や老朽化対策、保守・運用コストの最適化といった従来からの課題に対応するだけでなく、目まぐるしく変わる顧客や社会のニーズに、データとデジタル技術を活用して対応していくDXの実現を推進することも併せて求められつつある。その役割を果たすために、IT部門やIT関連会社には、これまでとは異なるマインドとアクションが必要だ。それと同時に、IT組織を含む企業全体の「変革」も不可避である。

この変革を進めるうえで、IT組織が「やるべきこと」や「持つべき意識」はどのようなものなのか。日本最大のリテーラーである「イオングループ」のIT機能会社、イオンアイビス株式会社の前社長である金子淳史氏に、Ridgelinezの上席執行役員Partnerである岩本昌己、西田武志が話を聞いた。
（インタビュー日：2024年4月11日）

製造業・流通小売業のシステムを見てきた中で感じる「内製化」「標準化」の重要性

岩本　金子さんは、本当に様々な立場から、日本企業のIT組織を見てこられました。日産自動車で製造業のIT部門、流通小売業であるイオングループに移られてからは、まずホールディングスの中でIT部門を統括され、その後、機能会社であるイオンアイビスの社長、DX領域を手掛けるイオンスマートテクノロジー（AST）の副社長も務めておられます。経験を踏まえ、従来型のユーザー系IT関連会社と、DX組織を同時に率いている形になるのですね。

金子　そうですね。ASTはDX企業ですので、新しいテクノロジーを扱えるエンジニアを確保しながら、自分たちでものを作ることをやっています。イオンアイビスは、グループの中核企業であるイオンリテールからITシステムサービス機能とバックオフィスのシェアードサービスセンターを独立させて機能会社としたもので、その意味では現状、一般的なIT関連会社に近いと言えます。基幹系を中心とした既存システムの保守運用やモダナイズ、グループ内のITガバナンスの再構築といった取り組みが主になります。

西田　イオンアイビスでは、ASTのような「内製化」には取り組んでおられるのでしょうか。

金子　例えば、勤怠管理や申請業務のスマートフォン対応のようなプロジェクトでは、PaaSにオープンソースを入れ、自分たちでコーディングして、自分たちで運用をするといったチャレンジを始めています。

岩本　金子さんは前職で米国法人に出向しておられましたが、その当時の米国のIT組織とベンダーとの付き合い方はどのような状況でしたか。

金子　私が米国にいた2000年前後で言えば、ITベンダーとの付き合い方は、いわゆる「丸投げ」スタイルでした。ちょうど、大手のITベンダーが「戦略的アウトソーシング」というコンセプトを推していた時代でもあり、基本的にIT部門からITベンダーに転籍して、そこでオペレーションをしながら、コンサルタントを入れて提案をしてもらうといった形になっていました。

岩本　あの当時、確かにそういった流れがありましたね。

金子　今でこそ、改めて「内製化」と言われていますが、その時代より前は、自分たちで当たり前にプログラムを書いていましたよね。1980年代は、メインフレームにCOBOLでコーディングするというのが主流で、私も自分でプログラムを作っていました。その後、ダウンサイジングからクライアント／サーバーに移行し、Web化が進み始めた1990年代後半から2000年代初頭が、アウトソースが流行った時期です。今まで、自社内でやっていたことを外に出して、自分たちは上流での企画や設計に専念するのだという意識が強くありました。

岩本　自社とパートナーとで役割分担を行った感じでしょうか。

金子　役割分担と言えばそうなのですが、結果として、そこからユーザー企業としてITスキルの空洞化が進んでしまったというのは事実だろうと思います。私は2000年代後半に日本へ戻るのですが、その時にはすでに「丸投げ」スタイルのフルアウトソーシングではなく、セレクティブアウトソースの時代になっていましたので、外部に依存するようになっていたスキルを自社に戻すために、社内での教育なども始めました。プロジェクトマネジメント標準であるPMBOK（Project Management Body of Knowledge）や、管理プロセスのITIL（Information Technology Infrastructure Library）に加えて、技術力についてもある程度身につけていこうという話になりました。ただ、プログラムコードを書くところまでは自社内でやるわけではなく、そこについては引き続きアウトソースする形式でしたね。

西田　以前、金子さんがベンダーと対談された記事を読んだのですが、その中で金子さんが「標準化」の重要性を強調しておられたのが印象的でした。仕事の進め方だけでなく、システム部門のプロジェクト管理においても「標準化」することが重要だという意識は、キャリアの中で培われたものですか。

金子　以前からそうした意識はありましたが、真剣にやり始めたのは、前職で空洞化したスキルを自社に取り戻すことに取り組んだときですね。プロセスもそうですし、プロジェクトマネジメントや運用マネジメントなどを内製化して、ノウハウとして蓄積しようと思えば、標準化が不可欠です。業界で一般的なフレームワークを取り入れながら、2、3年かけて組織に導入していきました。

岩本　そうした標準化の取り組みは現在もイオングループで続けていらっしゃるのですか。

金子　今、イオンアイビスでやっているのは、DX企業が使っているような、JIRAやConfluenceといったツールを使ったプロジェクトマネジメントの標準化ですね。そこにPMBOKに準じて作った独自のPMB（Project Management Book）を適用していくということをやっています。

プロジェクトのスタート時には、プロジェクトの範囲や体制、課題や進捗の管理方法を定義します。いわゆる「WBS」（Work、Breakdown、Structure）と呼ばれるものですが、特に大きめのプロジェクトの場合は、それに則って進めていくということをやっています。

西田　その取り組みは、実際にうまく回っていますか。

金子　以前、あるバックオフィス系のシステムをリプレースするという案件があり、当初はホールディンスが主導してベンダーと一緒に作業を進めていたのですが、途中で要件がまとめきれなくなり、イオンアイビスがサポートに入るというケースがありました。

僕らが入って、すぐにやったのは、先ほど述べたようなプロジェクトマネジメントの標準化と、WBSの定義です。ベンダー側のリーダーも巻き込んで、月に1～2回の進捗会議を入れながら、決められたやり方で進めていくことを徹底しました。その結果、何とかスケジュールどおりに完了することができました。

似たようなケースは、ASTが担当するようなDX系の案件でもあります。DX系の案件だと、開発プロセスにアジャイル的な手法を取り入れながら、まずはスピード重視で、プロジェクトの定義などを行わずに作り始めることが一般的です。小規模なものなら、それでうまくいってしまうことも多いのですが、少し規模が大きくなったり、多くの部門やシステムが関わってくるようなものだと、途中で要件が曖昧になったり、担当者間の認識がずれてきたりして、行き詰まってしまうことがあります。その場合も、きちんとPMBを作り、それに則って進めることで、うまくいくケースが多いのです。

そうした経験を通じて標準化の重要性を理解すると、その後はうまく進められるようになりますね。

西田　そういうことをきちんとやっている企業は、特に流通小売業界では本当に少数派だと思います。ユーザー企業側で、そうしたマネジメントを主導しているということが、自分にとっては驚きです。

金子　もしかすると、それは前職で培われたマインドかもしれないですね。「丸投げは駄目だ」ということを散々言われていましたから。

岩本　駄目だとは分かっていながらも、それができていない企業が多いというのが現状だと思います。DXの時代になったことで、ITプロジェクトの複雑性は以前よりも増しています。プロジェクトの実行において従うべき「規範」をユーザー側が持っていないと、ITベンダーの言いなりに高い料金を払わされる状況は助長されると思います。

国内外約300社が集う巨大企業グループにおける「ITガバナンス」の課題

西田　イオングループは流通小売業として、日本でも有数の大規模かつ複雑なビジネスモデルを展開しています。それを支えるシステムもかなり複雑なのではないかと想像するのですが、いかがですか。

金子　流通小売の基幹システムというのは、基本的には「足し算」と「引き算」を大量かつ短時間に行うものであり、その点では、CAD/CAMのようなエンジニアリング領域のシステムまでが含まれる製造業のITと比べればシンプルと言えるかもしれません。

ただ、規模が巨大であるがゆえの難しさはもちろんあります。特にグループ全体での「ITガバナンス」をどう実現していくべきかについては、現在進行形で考え続けています。

西田　金子さんは、グローバル製造業での経験もおありですが、それでもやはり難しいと感じられますか。

金子　前職だと、海外の拠点がそれぞれに自分たちでシステムの導入や運用をやりたがるというケースはありましたけれど、その場合、本社で予算を承認しないといった形で、半ば強引にでも統制をすることは可能でした。

イオングループの場合、国内外に約300社の事業体があります。グループの方針として緩やかな連帯を目指していることもあるのですが、結果として各事業体に、システムも自分たちの好きなものを、自分たちの思うように使いたいという意識は強いですね。事業体の規模や個性も様々で、そうした意味では、よりシステム面での統制はとりにくい状況だと言えます。

機能会社として、ユーザーである各事業体にとって、できるだけ使いやすいシステムを提供することは重要な責務です。しかし同時に、この先、グループのシナジーを最大限に高めていくためには、ガバナンスの利いた形でのシステム一本化も不可欠です。特にDXを進めていくうえでは、基盤系が共通化されていないと、シンプルにデータを集めて活用したいといった場合でも、その都度、余計な時間と手間が掛かることになります。

難易度の高い目標ではあるものの、ガバナンスの取り組みは諦めずに続けていかねばなりません。グループに新しく入ってくる事業体のシステムを取り込むことと並行して、既存のところについても、その意義を根気強く説明しながら、段階的に統合を進めていきたいと思っています。

岩本　先ほどの内製化についての話と関連するのですが、内製でスキルやノウハウを蓄積していくべき部分と、アウトソースする部分の切り分けについて、意識しておられることはありますか。

金子　我々の場合、基幹系やレガシーシステムを扱うイオンアイビスと、DX系を行うASTがあるので、それぞれ少しずつ方向性が違います。基幹系やレガシーについては、丸投げではなく、設計は必ず自分たちでやったうえで、実際にプログラムを作る部分は外部の力を借りるというのが現在のスキームです。

一方のDX領域については、自分たちでもある程度作れないと、スピード感を持って進められません。OSS（Open Source Software）やDevOpsのツールを入れて、なるべく自分たちだけで作れる体制を作ろうとしています。ただ、この領域は今、人を集めるのがなかなか難しい状況です。手が足りない場合は、外注することになりますが、その際もこちらでイニシアチブを取って進められるようにしています。

西田　特にDX領域では、どの企業でも人材確保に苦労しているようです。

金子　イオングループに限った話ではありませんが、企業が本当の意味で「DX」を実現していくにあたっては、新しい領域の技術や手法だけでなく、基幹系やレガシーシステムに関連したスキルや理解も必要です。

イオンアイビスでは、2021年から3か年計画で投資を行い、レガシーシステムのモダナイゼーションに取り組んできました。これができていないと、例えばDX領域で「在庫データのリアルタイム化」と、それを活用したアプリケーションを開発したいと思っても、基幹側が対応できません。イオングループの場合、1日あたり150億件以上に及ぶPOSの売上データが発生するのですが、これをクラウドに上げてリアルタイムに利用できるようにするのは、基幹側が古いシステムでは絶対に無理なのです。そういうことが可能な形に、基幹側のモダナイゼーションを進めました。

西田　従来型のシステムと新しい技術領域の両方に理解がないと、DXは実現できないということですね。

金子　一般的に、DX的なシステムはレガシーシステムをリプレースするものだと誤解されているケースもありますが、実際には、両者はまったく別の領域を受け持つものだと捉えています。確かに、新しい技術要素は、どちらにも積極的に取り入れていくべきだと思いますが、ほとんどの企業において、DXで扱う必要があるデータやロジックは、元々レガシーシステムにあったものがベースになるはずです。

経営層のITへの理解と関与を深めるためにIT組織がやるべきこと

西田　我々の問題意識のひとつとして、CEOをはじめとした企業の経営層に、どのようにDXやIT関連の取り組みを理解し、関与を深めてもらうかというものがあります。実際、企業に対して「IT戦略について社長に話を聞きたい」とリクエストを出すと「ITについての話を、なぜ社長に聞くのですか」という反応があることも多いのです。金子さんの経験から、どういったアプローチが、経営層の理解を深めたり、関与を強めたりといったことに効果的だと考えておられますか。

金子　確かに、特にDX領域と基幹系の両方を並行して進めていこうとすると難しい問題ですね。先ほど、イオンアイビスでレガシーシステムのモダナイゼーションを進めた話をしましたが、これを経営陣に認めてもらうための評価軸作りには、私もかなり悩みました。

結論としては、経営陣にはテクノロジー的な側面を説明しても、理解してもらえません。しかし、「これだけの投資に対して、これだけのリターンがあります」という視点であれば、納得してもらうのは難しくありません。

ASTの社長がよく言っているのは「入れた後でどうするか」までを考えるということで、これは私もそのとおりだと思います。昔のIT部門的なスタンスだと「このシステムをいくらで、スケジュールどおりに入れました」というところで話を終えてしまうのですが、今は「入れたことで、業務側にこれだけの効果が出ました」というところまでを言っていかないと駄目だと思います。そうした実績を積み上げることでしか、経営層の理解は得られないのではないでしょうか。

岩本　経営層も理解できる評価軸を、組織で共有していく必要があるということですね。その際の「実績」を説明する責任は、現場側とIT部門側のどちらにあるのでしょうか。

金子　両方でしょうね。イオングループの場合はASTが良い例ですが、何らかのプロジェクトを進める場合は、必ずIT担当と業務部門の担当者がセットの「推進チーム」として動く体制にしています。推進チームは事業会社と話し、彼らが何を求めているのかを理解したうえで、開発側に伝えます。その際、これをやれば「これだけ生産性が上がる」「これだけコストが下げられる」という成果を共有して開発に入り、出来上がったら必ず、当初に共有した成果が達成されているかを評価するようにしています。

岩本　基幹系の再構築やモダナイゼーションについてはどうでしょう。先ほど、基盤を整えておかなければ、DX領域でのデータ活用もうまく進められないというお話がありましたが、特にインフラ選定などにおいては、その時点で業務側に提供できる付加価値まで見えていないケースも多いのではないかと思います。

金子　「投資に対して、どれだけのリターンがあるかを示す」という点では同じだと思います。特にレガシーシステムの場合、「クラウドに移行することで、運用や更新のコストがこれだけ安くなる」というのは、より示しやすいのではないでしょうか。

イオンアイビスは機能会社なので、事業会社のシステムを契約ベースで見ることになります。そのとき「基幹系のモダナイゼーションにお金が掛かるので、利用料を上げます」という話は、基本的に通りません。事業会社としては「利用料が変わらないか、あるいは安くなってトラブルも起きないのなら、新しいシステムにしてもいい」というスタンスです。逆に、これまでになかった新しいものを入れるのであれば、その投資に見合うリターンを示せればいい。「既存システムにかかるコストを下げて、それを新しいところに投入する」というロジックが定石だろうと思います。

IT組織は事業会社や事業部門に伴走する「コンサルタント」であれ

岩本　システムの作り方が、イオングループで進めておられるような新しい体制へ移行していくとき、これまでの事業会社、IT会社、ITベンダーとの関係性には、どういった変化が生まれると考えておられますか。

金子　専門性ごとの役割は残っていくと思いますが、それぞれのフェーズを完全に区切るようなラインは、徐々になくなっていくのではないでしょうか。システムづくりの役割分担で言えば、戦略・企画、要件整理、システム設計、プログラム、運用といったものがあり、それぞれに専門性が必要です。ただ、これまで各フェーズの役割が明確に分かれていたのに対し、今後は全体のライフサイクルを考慮した戦略が必要になりますから、そこをチームとして一体でやっていく形になっていくのではないかと思います。

その中で、今後のIT部門、IT会社がどうなっていくべきかという話ですが、まずは「ビジネスのイノベーションを自ら提案する」組織にならなければいけません。そのためには、組織にある「データ」をフルに活用できる環境を整備しておくことが不可欠です。場合によっては、チーム内にデータサイエンティスト的なスキルを持つ人を抱えてもいいのかもしれません。

そうした機能を備えたうえで、事業会社や事業部門のビジネスに「いかに貢献できるか」「どれだけ生産性が上げられるか」といった視点で提案をしていく。そうしたところに新しい役割があるのではないでしょうか。

テクノロジーとしてのDXの使い方は、事業会社や現場にはわかりません。よくユーザー企業と「伴走する」という言い方をしますが、事業やデータへの理解も持ちながら、テクノロジーのエキスパートとして「新しい技術をこう使えば、こんなにいいことがある」という提案ができる、いわばコンサルタント的な役割を果たしていくことが求められるのだと思いますし、我々もそれを目指しています。

西田　それができるようになると、会社の中でのIT部門の評価も、より高まりますね。

金子　モダナイゼーションについては、イオングループで賞をもらったのですが、具体的な取り組みとしては、それまでオンプレで動いていたPOSレジのシステムをクラウドに移行し、スマートフォンや従業員の接客端末からPOSデータを送れるようにしたことが評価されました。システムをオンプレからクラウドに変えたことよりも、従業員の働き方に良い変化を起こせたことが、経営陣にとっては重要だったわけです。

岩本　先ほどのお話にもありましたが「システムを変えたことで、現場の業務がどれだけ良く変わったか」を示せたことが経営にも理解されたのですね。これからのIT部門は、あらゆるプロジェクトについて、そこまでのことをやっていくべきだと思うのですが、従来型のIT組織で長くキャリアを積んできた人にとっては、ハードルが高く感じられることもあると思います。そうしたことができる人材は、どう育てていますか。

金子　そこは悩ましいのですが、結局「やらなければ始まらない」に帰結するのだと思います。
新しいシステムを入れたり、古いシステムを入れ替えたりしたときに、障害が起これば現場から怒られますし、信頼も失います。でも、そうした状況に耐えながらシステムを改善していき、障害がなくなれば「便利になった」と現場も評価してくれます。そうした実績を積み重ねながら、信頼を得ていくしかないのではないでしょうか。

岩本　我々も、クライアントのIT部門の方に「事業部門にスモールスタートを提案しよう。そうするとスモールウィンがいっぱい出てくるので、それを実績にして次に進もう」と話すのですが、そうすると「我々はIT部門なので、そこまでは……」と躊躇されることもあります。

金子　変化を起こしていくためには「小さく始めて、成功体験を作っていく」シナリオが基本になるのは間違いないと思います。だからこそ「アジャイルでやるべきだ」という意見も出てくるのですよね。ただ、スピード重視で進めていくと、小さな虫食いのような「抜け」が出がちになりますので、そこは気を付けなくてはいけません。ある程度の規模がある組織の場合、まず全体の青写真を描いておいてから、順番にやっていくようにしないと、問題が増えるように思います。

岩本　論理的なシナリオとしての「To-Be」像を描いておいて、それに従って進めていくことの重要性は、我々も感じています。そうした考え方を業務現場の方に訴求していくことも同じくらい重要だと思うのですが、そのために何をすべきかについて、どうお考えでしょうか。

金子　難しい質問ですが、「自分からやる」ことでしょうか。

岩本　自分の背中を見せて、感じてもらうということですか。

金子　言い方を変えれば「一緒になって悩む」ことと言えるかもしれません。上司としては、ある程度、確固とした方向性を示す必要があります。それがないと、部下はついてきません。だからといって、方向性だけ出して「後はよろしく」では問題が出てきます。

あくまでも私の場合ですが、複数のプロジェクトが動いているとき、特にある程度、規模が大きなもの、主要なものの進捗会議には必ず出るようにしています。そこで問題がないかを聞くと、結構、みんな困っているのですよね。「こんな問題が起こっているけれど、解決のためにどういう動き方をすべきかわからない」というケースがよくあるわけです。そこで「今こうしていて、こういう問題が出たのなら、次はこうしてみてはどうだろうか」という方向性を上司がうまく示すことができ、それが問題解決につながれば、現場もこの仕事に面白みを感じられるのではないかと思っています。

「基本的なことをきちんとやる」環境と組織文化が変革の基盤となる

西田　今回は、国内有数の製造業と流通小売業のIT部門、IT関連会社のトップとして業界を見てこられた金子さんの視点から「これからのIT部門、IT会社はこう変わっていくべき」という知見を伺えたと思います。

金子　「レガシーシステムは、DXに向けて、整理とモダナイゼーションを進める」「クラウドを活用する際には、単純なIaaSだけでなくPaaSを活用して運用効率化を図る」といったあたりは基本になるでしょう。そのためには投資が必要になるので、投資した分のビジネス的なリターンを必ず出すというところまでを、ビジネス部門や経営陣と意識共有しながらやっていく必要があるということだと思います。

新しい技術を利用してシステムを作るためのスキルやノウハウは、できるだけ自社に蓄積していった方がいい。人手が足りずにアウトソースする際も、丸投げではなく、自分たちでマネジメントしながら、スキルトランスファーを念頭に置いて使っていく。

このあたり、自分としては、あまり特別なことだとは思っていないのです。「基本的なことを、きちんとやれる仕組みを作る」ことが重要だということです。プロジェクトマネジメントだけでなく、アジャイル開発にも、世の中には基本となる手法があります。そうしたものにきちんと則ってプロジェクトを進めていける体制を、事業会社とIT会社、事業部門とIT部門が共同で作っていくことが求められているのではないでしょうか。

岩本　「基本」を実行していくための仕組みと、それにチームとして取り組める組織文化が変革の基盤になるという点で、大変示唆に富むお話を伺えました。ありがとうございました。