2021年12月2日、株式会社AnityA主催のイベント「人と組織の成長につながるデータ活用とは ANAの事例で読み解く、『人』『組織』『データ基盤』の整え方」が開催された。
本イベントの前半では、株式会社データ総研（以下、データ総研） エグゼクティブシニアコンサルタント 小川康二氏と、全日本空輸株式会社（以下、ANA） イノベーション推進部 部長 野村泰一氏が登壇し、データ活用を推進するための具体的な取り組みについてそれぞれプレゼンテーション形式で紹介を行った。
この内容は、別途「そのデータ活用は『人と組織の成長』につながっているか──ANA野村氏が部門横断で取り組む『顧客ファーストなデータ活用組織』の作り方」記事で紹介しているので、ぜひ参照されたい。
イベントの後半では、小川氏と野村氏のプレゼンテーションの内容を受けて、AnityA 代表取締役 中野仁氏を交えた3人によるパネルディスカッションが行われた。本稿ではこれらの内容をダイジェストでお届けする。
DXとデータ活用を始めるには、まず何から手を付ければいいのか？
中野氏： 私はさまざまな企業のDXの取り組みをコンサルタントとして支援しているのですが、その際によく聞くのが「何から手を付けていいのか分からない」という声です。
小川氏： 私もお客さまから同じような声をよくお聞きします。でも、そこで私たちが大上段に構えて「仕組みを作りましょう！」「組織を作りましょう！」と威勢よく提言したところで、現実的にはお客さまは予算や人員などの面で多くの制約を抱えていますから、実際にできることには限りがあります。
従って、何よりも「お客さまの立場に立って、現実的にできることを一緒に探っていく姿勢」が重要なのだと思います。最近では「アウトプットとして何を出したいのか？」という議論からまずは出発して、小さくてもいいからしっかり結果を出す方向に持っていくことを心掛けています。
中野氏： 野村さんは、一度ANAを退職してPeach Aviationの立ち上げに参画して、後に再びANAに戻られています。ANAに戻ってDXを進める際に、まずは何から手を付けようと考えましたか？
野村氏： 先ほどのプレゼンテーションでも紹介したように、まずはマインドセットの変革に着手したのですが、それと同時に、当時はあちこちのプロジェクトが炎上していたので、メンバーがDXに取り組めるだけの時間的な余力を作れるよう、炎上プロジェクトの消火活動に奔走しました。
実際にやったのはデバッグやプロジェクト計画の見直しといった、極めて泥くさい作業で、DXとは程遠い世界だったのですが、これをやらないまま「新しいことをやろう！」といくら声を上げても、結局はメンバーに掛かる負荷が高まって苦しめてしまうだけなのです。
中野氏： そうやって環境を整えた後に、ようやくデータ活用の取り組みを始めたということですね。ちなみに小川さんの先ほどのプレゼンでは、データ活用支援組織の構成員として「データサイエンティスト」「データアーキテクト」「データスチュワード」など、実にさまざまなロールを挙げていました。
小川氏： これらをお客さまに話すと、決まって「こんなに多くの人材を用意できるわけがない！」と言われるのですが、本当に重要なのはこうした機能を通じて「組織内のデータをきれいにすること」です。
データは「素のままの状態」ではユーザーに使ってもらえませんから、まずは使いやすい形に整える必要があります。そのために先ほど挙げたようなさまざまな役割や組織が必要になってくるのですが、残念ながら多くの企業のIT部門は、「データの中身をきれいにしてユーザーに使ってもらいやすくするための努力」を怠っているように見えます。
野村氏： 確かにANAでも、かつては仕組み作りに注力するあまり、データを軽視していたという反省があります。IT部門はどうしてもアプリケーション開発やインフラ運用に力点を置きがちですが、これだけクラウドやSaaSアプリケーションが普及してきた今、自社でアプリケーションやインフラを構築・運用する意義は薄らいできています。
むしろ、今も昔も変わらず重要なのはデータです。データの質と鮮度、そして加工の方法を考えることこそが最も大事な取り組みなのではないかと、私たちも考えを改めつつあります。
小川氏： 具体的な取り組みとしてはMDM（マスタデータマネジメント）が代表格ですが、これもあらかじめ「どの業務のどの範囲のデータを対象にするのか」をはっきりさせておかないと、「MDMシステムの導入自体が目的化」してしまって、収拾がつかなくなってしまいます。やはり、目的と対象をあらかじめ明確化しておくことが大事だと思います。
大事なのは、短期的な取り組みと中長期的な取り組みのバランス
中野氏： まずは「目指すべき目標や、将来あるべき姿」をきちんと描いた上で、そこから逆算する形で段階的に施策を講じていくことが大事だということですね。ただし一方で、いざデータ活用の具体的な仕組みを作ろうとしても、「将来どんなデータが役立つかどうか分からない」という問題に突き当たります。
その点、ANAさんでは、メインフレームの基幹システムとその他の周辺システムとの間でデータをやりとりできる「データハブ」のレイヤーを設けることで、この問題の解決を図っています。
このレイヤーが持つ重要性については、私も常々いろいろなところで力説しているのですが、経営から見ると、やはりこの部分に対する投資は成果が見えにくく、なかなか理解を得るのが難しい側面もあります。
野村氏： そうですね。従って私たちは、この部分に対する投資の稟議をあげる際には、「データハブとしての意義」を直接説くのではなく、「こういうビジネス課題を解決するためにやりたいと考えています」という形で説明します。そうやって、ある特定のシステムを作ると言いつつ、実際に裏でやっているのは全体図の中の1つのピースをはめている──ということなんですね。
小川氏： 先ほどのプレゼンテーションで、ANAさんの具体的な取り組みについて説明していただきましたが、基幹システムに手を加えることなくデータをうまく抜き出して、それらをマイクロサービスで使いやすい単位に区切ってユーザーやアプリケーションに提供する──というアーキテクチャ設計が絶妙だと感じました。
ほかの企業でも、基幹システムの刷新自体をやみくもに目指すより、その中にあるデータの使い方にまずは注力した方がいいケースは多いように感じます。仕組みの整備にこだわっていたずらに時間を消費するより、アウトプットから逆算してなるべく早く成果を刈り取ることがDXでは重要ですからね。
野村氏： そういう意味では、私たちも「短期的に小さな成功体験を生み出せる取り組み」と、「時間がかかるデータ基盤整備の取り組み」の両方を並行して進めました。まずは、小さな成功体験を積み重ねていって、そこで新たに生まれたデータを後に完成したデータ基盤に投入することで、短期的な活動と中長期的な活動の成果をマージできるようにしたのです。
小川氏： 基幹システムのデータマネジメントのような重厚長大な取り組みになると、やはりそれなりにじっくり時間をかける必要がありますからね。データ活用を成功させるためには、短期的なビジネス成果を追求する取り組みと、中長期的な視野に立ってじっくり取り組むべき施策の両立をうまくマネジメントしていくことが重要になってきますね。
中野氏： 旧来のSoR（System of Record）のシステム分野と、DXを担うSoE（System of Engagement）のシステム分野とでは、そもそもミッションもカルチャーも大きく異なりますから、安易に混ぜるのではなく、ある程度分けて考えるのが定石だと言われていますね。
小川氏： SoRとSoEとでは、システムに求められるサービスレベルや性能がまったく異なります。またSoEのシステムを通じて取得した顧客接点のデータを、SoRの基幹システムに反映させて業務で生かせるようなユースケースもあまりありませんから、やはり、ひとまずは両者を切り分けて考えた方が分かりやすいと思います。
野村氏： そうですね。私もこの両者の仕組みを完全に1つにするのはかなり難しいと思います。ただ、両者をデータでつなぐことで、新たな価値が生まれることは多々ありますから、SoRとSoEは切り分けつつも、両者の距離はデータを介してだんだん近付きつつあると感じています。
中野氏： システム開発プロジェクトにおける発注側と受注側の関係性にも言えることですが、お互いが同じ方向を向いて、かつ目に見える成果を積み重ねて共有していけば、自然と一体感が生まれてくるんですよね。そういう意味では、先ほど野村さんがおっしゃったような、ちゃんと短期的な成果を出しつつも、同時に裏でデータ基盤の整備も着々と進めていく──というやり方が最も現実的なのかもしれません。
「将来のMDM実現を見据えたコード統一」をスムーズに進めるには？
中野氏： 本イベントをオンライン視聴してくださっている方から、「サイロ化状態の既存業務システムとデータベースが多数あり、情報の重複などもあるのですが、データ基盤を作る際の筋のいい手の付け方があればアドバイスをいただければ幸いです」という質問をいただいています。
小川氏： 基幹システムごとくっつけようとすると大変なので、ANAさんがやられたように、既存システムからデータを引っこ抜いてきて、いったんデータレイクやDWH（データウェアハウス）に突っ込んでしまうのがいいと思います。ただし、コード体系がばらばらのデータをいくら集めても横串の分析ができませんから、標準コードに変換した上で突っ込むことが大事です。
中野氏： コードの標準化はMDMにもつながる取り組みになりますよね。
小川氏： その通りです。ただし社内で「MDMをやります！」と言うと、「コードを変える気か！」と社内のさまざまな部門の反発を招く可能性もあります。従ってここは、IT部門から「われわれがデータを集めた先で何とかしますから、一切心配いりません」とメッセージを出した上で、将来のMDM構築に備えたコード標準化を裏で着々と進めていけるようなプロセスをうまく設計するのが得策だと思います。
中野氏： 次の質問は、会場にお越しいただいている方から受け付けたいと思います。
質問者： 私は現在2000人規模の会社にいるのですが、75年ほどの歴史があるので、規模はさほど大きくないわりに、システムがサイロ化してしまっている状態です。
こうした中で、全社的なデータ活用の仕組みを新たに構築するとなると、さまざまな面倒が起こると予想されることから、本社の仕組みに手を入れる前に、まずは海外子会社から手を付けるのも手かなとも考えています。
野村さんはANAだけでなくPeach Aviationにもいらっしゃいましたが、小さいところから手っ取り早く手を付けるのがいいのか、それとも大きなところをコツコツやっていった方がいいのか、どちらの方がお勧めでしょうか？
野村氏： Peach Aviationはゼロからの立ち上げだったため、うるさいことを言う人がいなくて、違う意味でとてもやりやすかったですね。でも御社のように歴史のある会社は、恐らく「大きいか、小さいか」という観点よりも、「過去から引き継いできたデータ資産に価値があるのかどうか」、そしてそれらを生かしていくのであれば「どのようにデザインして価値を引き出していくのか」という点に着目した方がいいような気がします。
中野氏： 現在持っているデータの価値次第、ということですね。この場合も仕組みが先に立つのではなくて、あくまでも「生み出す価値は何か？」という点がポイントになると思います。
小川氏： 単純に本社の仕組みと海外の仕組みを比較すれば、やはり海外の方が機能がシンプルなので、手を付けやすいというのは確かだと思います。ただし、海外で先行して導入した仕組みが、そのまま国内でも通用するとは限りません。
個人的には、海外で先に導入したシステムをその後国内でも採用する例というのは、ほとんど見たことがありません。それに国内の大規模システムと海外の小規模システムがまったく別のものになると、コードの不一致にまつわるさまざまな問題に悩まされることになります。
従って私たちの王道の提案としては、まずは「全社的にどのようなデータを管理して活用するか」という全体像やアーキテクチャをきちんと描いて、それに基づいて「最低限流通させるべきデータ」をはっきりさせます。
どうしてもパッケージやツール、ベンダーの選定に目が向きがちですが、システムを「データの器」ととらえた場合、まずは「どんなデータを流通させたいのか」を明確化することが何より重要です。
全てを外注に頼っている中小企業が、DXやデータ活用を実現するには？
中野氏： 「内製化を進める場合、自社内で開発作業まで行えるようにした方がいいのでしょうか？」という質問も視聴者の方からいただいています。
野村氏： 外部に開発を依頼するとなると、きちんと意思決定プロセスを経たり、ドキュメントをしっかり整備する必要があるので、どうしてもスピード感に欠けます。社内で開発ができれば、業務部門の方々とビジネス課題について直接対話しながらものを作れますから、スピーディーかつスムーズに意思疎通が図れます。
それに最近ではローコード／ノーコードツールやRPAなどが普及していますから、そうしたツールを使えばたとえ高度な開発スキルがなくてもプログラムを開発できる時代になっています。実際にANAでも、そういうツールを使って開発を行う専門部隊を設けています。
ただし当然のことながら、自分たちですべてのことができるとは限りませんから、「どこまでのレベルなら内製開発でまかなえるのか？」という点はあらかじめきちんと見極めておく必要があると思います。
また、業務部門に過度な期待を持たせると「何でも内製開発してくれるんでしょ？」と無理なお願いをされることも出て来るでしょうが、そんなときは無理して引き受けたり、あるいはむげに断るのではなく、「そこまでは無理だけど、ここまでのレベルなら内製でもできると思います」と、現実的な提案ができるようにするべきでしょう。
小川氏： 逆に外注に頼りすぎてしまうと、「業務ノウハウを全部外に出してしまって自社には何も残らない」──という状態に陥りかねません。そういう意味では、やはり内製開発ができることに越したことはないと思います。
もちろん、パッケージやツールでできることまで一生懸命作る必要はありませんから、どの部分を内製してどこを外注するかの線引きをきちんと見極めることが大切です。具体的には、「顧客接点の部分をスピード感を持って開発する部分は内製でスピーディーに対応」しつつ、「細かな部分をブラッシュアップして完成度を高める部分に関しては外注する」──といったような切り分け方がいいのではないでしょうか。
中野氏： 次の質問も会場から受け付けたいと思います。
質問者： 私が勤めているのは500人規模の中小企業で、IT部門にエンジニアが1人もいないため、システム関連の作業はほぼすべて外注しています。このような組織において、DXやデータ活用を推進していくには、どのような方法をとるべきなのでしょうか？
野村氏： 私たちも「内製力を高める」ことを標榜していながら、実は外部のパートナー企業の方々の協力を仰ぐことは多々あります。ただし、開発作業を丸ごと外注してその成果物だけを受け取るというやり方ではなくて、私たちのプロジェクトの中に入ってもらって一緒に開発するという方法をとっています。
単にものを作る仕組みを整えるだけではなくて、外部の方々も私たちの仲間として一緒に入っていただいて、同じゴールをともに目指すマインドや志の部分も含めて一緒にプロジェクトに取り組んでいきたいと考えています。
小川氏： 志を共にしていれば、「所属が社内か社外か」というのは、あまり関係ありませんよね。重要なのは、自分たちの業務をどれだけ知っているかという点ですから、外部の方でも自社の社員と同じぐらい手間暇かけて育成すれば、内製力を高めるための戦力になってくれると思います。あるいはANAさんのように、社内の他部門から人材を公募するのもいいかもしれません。
中野氏： 私も外部のパートナーさんに仕事を発注する場合は、基本的には受託ではなくて、準委任契約で自社のプロジェクトの一員として働いていただく形を基本にしています。さらに言えば「どの会社に発注するか」ではなく、「誰に仕事をお願いするか」という観点を重視しています。
受託契約が悪いというわけではないのですが、この契約方式が、発注者の当事者意識を欠落させたり、「企画からの丸投げ」につながったりすることも少なくないのが実情です。その結果、発注者に欠かせない「なぜ、この課題を解決するのか？」という命題から逆算してプロジェクトを設計する能力が退化してしまうのではないかと思うのです。
例えば、お金さえ払えば、「誰もが当事者意識を失った成れの果ての筋が悪い仕事」もやってもらえたりするわけですが、そういう仕事を拾う層の人材の質は下がる一方です。にもかかわらず、人手不足によって人件費は上がっているので、企業は下手をすると、質が低い人材に高いお金を払うことになりかねません。
一方で、質が高い仕事をする人にはプロジェクトが集中するので、彼らは好きな仕事を選べます。彼らが重視するのは、「その仕事にやりがいがあるか」「その仕事によって自分が成長できるかどうか」であり、「報酬水準が適切かどうか」です。
人手不足が深刻化する中では、「優秀な社外のプロフェッショナル」に仕事をお願いすることも増えるはずです。そういう人に協力してもらうためには、発注側が常に「優秀な人に興味を持ってもらえるような面白い仕事」をオファーできるようにしておかなければなりません。
今後、ジョブ型の働き方が普及していくにつれ、こうした考え方はますます重要になってくるような気がします。
人と組織の成長につながるデータ活用とは ANAの事例で読み解く、「人」「組織」「データ基盤」の整え方
執筆
吉村哲樹
早稲田大学政治経済学部卒業後、メーカー系システムインテグレーターにてソフトウェア開発に従事。その後、外資系ソフトウェアベンダーでコンサルタント、IT系Webメディアで編集者を務めた後、現在はフリーライターとして活動中。
イベント企画・編集
後藤祥子
ITmediaエンタープライズの担当編集長を経て独立。現在はエンタープライズITの変革者に伴走するメディア「Darsana」の編集長として、変革者へのインタビュー、イベント企画、コミュニティ運営を手掛けている。ITとビジネスをつなぐ役割を担っているCIO、IT部門長へのインタビュー多数。モットーは、「変化の時代に正しい選択をするのに役立つ情報を発信すること」