About us データのじかんとは？
About us データのじかんとは？
野村氏 こうしたカルチャーやマインドセットの変革を推し進める一方で、システム面の改革も少しずつ進めていきました。先ほど申し上げた通り、当時のANAの社内システムは業務ごとに個別に構築したシステムが林立する「サイロ化」の状態で、システム間のデータの連携や流通がスムーズに行われていませんでした。
そこで、業務ごとにアプリケーションを一から開発する手法をあらためて、システムの機能ごとにマイクロサービスを作って、それらを組み合わせることで業務システムを構築する新たなアーキテクチャを採用することにしました。
こうした仕組みの下では、同じプラットフォームの上に各業務アプリケーションが載る形になるため、プラットフォームを管理するIT部門の立場からすると、各業務アプリケーションが管理するデータを入手しやすくなるというメリットがあります。これによって、IT部門主導で組織や業務の垣根を超えた全社最適のデータ活用を推進しやすくなります。
松本氏 そうしたメリットを生かしたシステム開発の例として、これまでどのようなものがあったのでしょうか？
野村氏 例えば、お客さまが飛行機の出発予定時刻の45分前までに保安検査場を通過してくれたら、出発ゲート付近の売店で500分円の買い物ができるクーポンを発行する——という仕組みを構築したことがあります。
これはマーケティング部門にとっては、お客さまに新たなユーザー体験を提供することでロイヤリティ向上を図れるというメリットがあります。しかしそれだけでなく、空港のオペレーション部門にとっても、より多くのお客さまが45分前までに保安検査場を通過してくれたら、その分予定通りに飛行機が出発できる確率が高まります。そしてもちろん、売店にとっても売り上げ向上の効果が期待できます。
このように、単一のプラットフォーム上にマーケティングと空港オペレーション、そして売店の仕組みを一緒に載せて、互いにデータを共有することによって、「これまでにない新たな価値」をお客さまに提供するとともに、社内の複数の部門が同時にメリットを得られるようになったのです。
松本氏 従来のように各部門のシステムが独立していては、こうしたビジネスモデルはなかなか生まれなかったでしょうね。
野村氏 そうですね。こうして組織の壁を超えたプロセス連携とデータ連携が新たな価値を生むことが証明できたので、次はこの成果を全社規模に拡大すべく、社内でワークショップを定期的に開くようにしました。
ワークショップでは、社内のさまざまな部門の代表者に集まってもらい、現在業務でどのような課題を抱えているかをヒアリングし、IT部門が持っているソリューションでそれらをどう解決できるかその場で検討します。また、社内SNSを通じて課題を募る活動も行っており、現在社内のあらゆる部門の1700人ぐらいの従業員がこのSNSに参加して、互いに自由に情報交換をしながらイノベーションのネタを模索しています。
さらには、IT部門の組織にも手を加えました。これまでは、お客さま向けシステムを担当する「サービスイノベーションチーム」と、社内の業務システムを担当する「業務イノベーションチーム」の2チームに分かれていましたが、これに加えて業務カットではなくテクノロジーカットでソリューションを企画・開発するテクノロジードリブンのチームを新設しました。
2019年春には、それまでホスト部隊の配下にいたデータ担当チームをこちらに引き入れて、長年の悲願だった「データドリブンのチーム」を新たに作りました。これでようやく、テクノロジーとデータを武器に自分たちから能動的にシステム戦略の提案ができる体制が整いました。
松本氏 単に業務部門からの依頼に従ってシステムを作るだけでなく、その先のお客さまに提供する価値や、社内のさまざまな部門のメリットも加味した上で、システムやサービスを設計することを心掛けているのですね。今までのお話をうかがっていると、野村さんがこれまでIT部門だけでなく営業や空港の現場など、さまざまな立場で働いてきた経験がそうした考えに結び付いているという印象を受けました。
野村氏 確かにそうした視点は、以前から大事にしていたのかもしれません。今思えば、ANAに入社して営業部門からIT部門に異動したばかりのころもそうでした。当時、自動チェックイン機を空港に大々的に導入したのですが、単に人手の作業を機械に置き換えただけの仕組みだったので、思ったほど使ってもらえなかったんです。
使う人にとっての利便性があまり考慮されていなかったので、私は使われなくて当然だと思っていましたが、当時の会社側の考え方は「これを使えば搭乗手続きが楽になるはずなのに、なぜ皆使わないのだろう」というものでした。これは完全にプロダクトアウト型の発想なんですよね。
その後、チェックイン手続きを不要にする「スキップサービス」という仕組みを私がデザインした際には、何より「お客さまにどんな価値を提供できるか」を重視しました。もともと飛行機の利用者は、時間を節約するために飛行機に乗るわけです。従ってチェックイン手続きを省くことで10〜15分でも搭乗手続き時間が短縮できれば、確実にお客さまにメリットを感じていただけると考えました。
松本氏 その分だけ、空港に到着する時間を遅らせることができますからね。
野村氏 しかもこの仕組みは、お客さまにとってのメリットだけでなく、自社にとってもさまざまなメリットが期待できました。スキップサービスのシステムを導入すれば、「お客さまが何時何分に保安検査場を通過したか」というデータが取れるようになるので、空港オペレーションの担当者はリアルタイムにお客さまの動向が把握できるようになります。またスキップサービスの利用者が増えれば、その分だけチェックイン手続きを空港で行うお客さんが減るので、自動チェックイン機の台数も減らせてその分のコストを節約できるようにもなります。
松本氏 お客さまとオペレーション部門、設備部門がいわば「三方良し」の状態になるわけですね。
野村氏 その通りです。このように、ある仕組みをデザインするときには、必ず「ステークホルダーはどこにいて、どんな課題を抱えているのか？」ということを意識するようにしています。
その課題を見つけるために、関連すると思われる部署にこちらから出向いて、業務内容や課題をヒアリングすることも多々あります。単にシステム開発の依頼元の要望に応えるだけでは、その依頼元が抱える課題は解決できるかもしれませんが、それ以外のステークホルダーには何の価値も提供できません。
その点、近年では対面のヒアリングだけでなく、テクノロジーやデータを使ってステークホルダーの存在や彼らが抱える課題を可視化できるようになりましたから、よりステークホルダーを意識したデザインがしやすくなっていると感じています。
松本氏 私は普段、データサイエンティストとしてさまざまな企業のデータ活用プロジェクトのお手伝いをしているのですが、テクノロジーやデータの波に飲まれ、溺れてしまっている企業が少なくないと感じています。
よく見られるのが、企業のトップが「はやりのデジタル技術を使って何かやれ！」「うちにもデータがたくさんあるはずだから、それを使って売上げを上げろ！」と号令を出すものの、はっきりした指針や見通しがないまま見切り発車して、結局は何の成果も出せない——というケースです。
こうした失敗事例を数多く見てきたわけですが、野村さんが戻ったあとのANAさんでも、そうした失敗例があったと思うのです。それでも着々と成果を上げてきた秘訣はどこにあるのでしょうか？
野村氏 ご指摘の通り、私たちもすべてに成功してきたわけではなく、さまざまな試行錯誤を重ねながら学びを得てきました。
例えばある時、羽田空港の担当部門から「空港内の車いすやベビーカーを探すために年間1460時間も費やしており、この作業を何とか効率化したい」という相談を受けました。そこで早速、車いすやベビーカーにビーコンを取り付けて、位置をリアルタイムに取得してアプリに表示させるという仕組みを開発して、試験運用までこぎ着けました。
その結果、現場から「8割が満足、2割が不満足」というフィードバックをもらいました。この結果を受けて、今後の方針を検討するための中間会議を開いて、関連部門の代表者に集まってもらいました。しかしそこで、思わぬ反応が返ってきたのです。
松本氏 どんな反応があったのですか？
野村氏 つい昨日まで「この仕組みはいいですね、ぜひやりましょう！」と、とても前向きだったある部門が、その会議の場で急に「2割の方が不満足なので、この仕組みはやめるべきです」と発言を翻したのです。あとから分かったのですが、どうやら部門の中の会議で「稼働状況が可視化されてしまうと、自分たちの裁量でベビーカーや車いすの購入がしにくくなるのではないか」という声がでてきたようなのです。
そこでビーコンのデータを集計・分析して、車いすとベビーカーの時系列の稼働状況をヒートマップ上に表示させて、全体の稼働率を割り出しました。その上で、「この稼働率だと現状では台数が足りませんから、おたくの部門で積極的に追加購入するべきだと思います」とこちらから逆提案したのです。そうしたところ、部門は一転してこちらに協力してくれるようになりました。
松本氏 データを基に、ステークホルダーをうまく説得したわけですね。
野村氏 さらに、この仕組みの運用を続けるうちに、単に車いすやベビーカーの位置を可視化するだけでは、もともとの課題である「探す時間を減らしたい」という目的がなかなか達成できないことが分かりました。
より具体的にいえば、「空港が混雑しているときに探す手間を減らせないと、結局は仕事の効率化に結び付かない」ことがデータから明らかになりました。そこで、「単に位置を可視化する仕組み」を提供するだけでなく、「空港が混雑していない時間帯を見計らって車いすとベビーカーを探しに行って、あらかじめ混雑する時間帯に備える」ようなオペレーションを提案しました。その結果、最終的には1460時間かかっていたのを700時間まで短縮することができました。
松本氏 とても興味深い事例ですね。データを活用する仕組みを作り上げた結果、「データを基に実態が可視化されては困る」と考えるステークホルダーが出てきた。でも、さらにデータを使ってその人を説得して、さらにシステムの効果的な運用方法までデータを基に最適化する。各ステークホルダーの利害をデータを基に可視化して、さらに調整していったわけですね。
松本氏 データ活用がうまくいかない別のパターンとして、「今、手元にあるExcelシートの範囲内でしか分析をしようとしない」「自分たちの閉じた世界でしかデータを使えていない」というケースも多いように感じます。一度、思い切って視野を広げて、「こんなデータも使ってみたらどうだろう？」という発想ができないと、なかなか新しい価値は生まれてこないような気がします。
野村氏 ANAでもかつてはフライトデータはフライト担当部門、整備データも整備部門でしか使われていませんでした。でも最近では、部門を超えてデータを活用することで、思わぬ効果が生まれるケースが出てきました。
例えば、ある時、整備部門から「エンジンのとある部品が定期的に壊れるので、その原因を調べたい」という相談を受けました。その部品は1つのエンジンにつき8個使われていますから、1つぐらい壊れても飛行には何の支障もありませんが、不具合が見付かったら即交換するルールになっているんです。交換作業には時間がかかるため、場合によっては遅延や欠航につながる可能性もありますし、1個数百万円もするのでコストもばかになりませんでした。
松本氏 整備部門では、既に整備データを使った分析を行っていたんですね？
野村氏 はい。でもそれだけでは理由が分からず、結局、私たちのところに相談が持ち込まれたわけです。そこで整備部門が持っている整備データに、私たちが持っていたフライトデータを突き合わせて相関分析を行ったところ、エンジンの空気の流量と故障との間に相関があることが判明しました。
松本氏 すぐに原因が判明したのですね。
野村氏 そのことを整備部門に伝えたところ、返ってきた反応は「そこは、うちでもとっくに把握している」というつれないものでした。そこでほかのデータとも何らかの相関がないものかと、さらに分析を進めていきました。一般的に部品の耐久度は飛行時間と相関があると言われており、私もそう睨んでいましたが、整備の実務のことなど何も知らないデータ分析担当者が出してきた答えは、「飛行機が飛ぶ路線と相関がある」というものでした。
これは従来の整備の常識を覆すような結果だったので、私自身も当初は半信半疑だったのですが、いろいろ調べてみると、PM2.5（微小粒子状物質）の飛散量が多い航路を飛んでいる機体はフィルターが目詰まりしやすく、空気の流入量が減ってしまうために、結果的に部品が早く故障する傾向があるらしいことが分かってきました。
松本氏 この結果を初めて聞いたときの整備部門の反応はいかがでしたか？
野村氏 何せ、これまでの整備の常識を完全に覆してしまったので怒られるかと思ったのですが、完全に驚いてましたね（笑）。でも最終的には納得してくれて、彼らとしての判断でフィルター交換の新たなオペレーションを導入してくれました。
このケースでも、もし整備部門のデータの範囲内だけで分析しようと思ったら、きっと真の原因には辿り着けなかったと思います。初めから「課題の裏返しとしてのソリューション」が定義されていて、それをただシステム化するだけでは自分たちがデザインする余地がないんですね。
そうではなく、課題だけがあって、それを解決するための方法を現場スタッフと一緒に試行錯誤しながら考えるのは、やっぱり楽しいですね。さらに、その過程で「こんなデータを使ってみたらどうだろう？」「じゃあそのデータを持っているこの部門に相談してみよう」と社内のネットワークがどんどん広がっていくプロセスも、とても面白いと思います。
松本氏 データを軸にソリューションをデザインするだけでなく、同時に組織や業務の壁を超えた人的ネットワークも広がっていくわけですね。
ルール厳守やQCDの追求だけにとらわれない「例外の文化」を作るデータを使ってデザインする人を「孤立させない」ために
メルマガ登録をしていただくと、記事やイベントなどの最新情報をお届けいたします。
30秒で理解！インフォグラフィックや動画で解説！フォローして『1日1記事』インプットしよう！
