レポート

インテグレータとしてモノとビジネスのギャップを埋めていく ―「Hadoop/Sparkエンタープライズソリューションセミナー 2016」レポート

この記事を読むのに必要な時間:およそ 4 分

日本でも進むHadoopの大規模利用

ここからは,基調講演の後半で行われたNTTデータのユーザ企業2社 ―三井住友カードと大東建託のHadoop導入事例の概要を紹介します。

メインフレーム上のバッチ処理をHadoopでオフロード ―三井住友カード

最初の事例は三井住友カードにおける基幹業務システムのHadoop適用です。新しい技術トレンドとして注目されるFinTechブームとは対象的に,国内金融機関の多くはCOBOLなどで書かれた古い基幹システムに苦しんでいるところが多く,三井住友カードもまた「EC取引の加速,多様なIoTデバイスの登場などにより,基幹系業務が肥大化,そして膨大な量に膨れ上がったトランザクションボリュームに,30年以上に渡って使用してきたメインフレームの負荷が限界に達しつつあった」⁠NTTデータ 第四金融事業本部 金融グローバルITサービス事業部長 木村千彫氏)という状況にありました。しかし,金融機関の基幹系システムは「すこしでも間違いがあると社会的影響が大きすぎる」⁠木村氏)ことから新技術を導入しにくいというハードルが存在します。

NTTデータ 木村千彫氏

NTTデータ 木村千彫氏

この課題に対応するため,三井住友カードでは基幹業務のバッチ処理の一部をHadoopに切り出す取り組みを段階的に開始しました。2014年度にほぼ1年をかけて事前検証(PoC)を実施,2015年度にHadoop適用可能と判断し,Hadoop基盤構築を開始,2016年7月から並行本番として初回稼働,アプリケーションの整合性を確認した後,10月には本番稼働に至っています。

三井住友カードはなぜHadoopとNTTデータを選んだのか,三井住友カード システム企画部 上席審議役 呉竹義隆氏は基調講演に寄せたビデオメッセージで「ホストの負荷軽減,処理時間の短縮,コスト抑制といった観点から,以前から興味のあったHadoopの導入を決めた。NTTデータはHadoopに関する知見が多いことから声をかけた」と語っています。社内には当然,新技術の適用に対する不安の声も多く,⁠システムインパクトが大きすぎるのでは」⁠30年もCOBOLで動いてたホストがJavaベースに変わって本当に大丈夫なのか」という慎重な意見もあったそうですが,PoCの結果,Hadoopの適用が効果的と判断し導入に踏み切ったとしています。最初ということもありポイント算出サービスのような顧客の利用頻度が高く影響の大きい部分ではなく,顧客影響の少ない部分をNTTデータが開発したツールで切り出したとのこと。⁠今回はファーストステップだったが,非常にうまく動いている。今後も切り出しの対象を高負荷の処理まで拡げ,Hadoopの適用を推進していきたい」⁠呉竹氏)⁠

この事例のポイントについて,PMとして担当したNTTデータ 第四金融事業本部 金融グローバルITサービス事業部 第四統括部 第五開発担当課長 坂巻資浩氏は大きく2つあるとしています。ひとつは「処理の切り出し」で,ファイル間の連携を考慮し,切り出せるジョブを「2000くらいまで絞り込み,さらに900ジョブまでは自動で抽出した」⁠坂巻氏)とのこと。もうひとつは「まずHadoop基盤を作る」ということにフォーカスした点です。将来を見据えた最適なプラットフォームとして今後も継続して運用していくためにも,最初に強固なHadoop基盤を作ることを第一の目標に掲げたと振り返っています。

NTTデータ 坂巻資浩氏

NTTデータ 坂巻資浩氏

三井住友カードの事例は,レガシーを多く抱える金融機関はもちろんのこと,多くのエンタープライズ企業にとっての共通の悩みに対するアプローチとして,参考になる部分が多いのではないでしょうか。Hadoopという業界での稼働実績があまりないプラットフォームを選ぶ,これは同社にとって"いままでしたことがない決断をした"瞬間であり,リスクはあるものの,結果として新しい一歩を踏み出すことにつながっています。⁠モノとビジネスのギャップを埋める」というのはこういうことなのかもしれません。

賃貸事業のリスク分析基盤をHadoopで構築 ―大東建託

2つめの事例は,賃貸住宅管理で業界トップの実績をもつ大東建託のユースケースです。基調講演に登壇した大東建託 情報システム部 システム開発課 板谷隆史氏はまず,⁠建物賃貸事業のリスク」として以下の7つを挙げています。

  1. 空室リスク
  2. 家賃下落リスク
  3. 家賃滞納リスク
  4. 退去時費用負担リスク
  5. 建物老朽化リスク
  6. 火災/地震被害リスク
  7. 借入金変動リスク

このうち,大東建託が自社のリスク「賃貸経営受託システム」としてカバーしているのが1~5までのリスクです。これらは大きく「家賃収支管理」「修繕収支管理」に分けられ,精緻な分析が必要にもかかわらず,既存のリスク分析基盤は

  • あらかじめ定義した軸による定型的な集計結果しか見ることができない
  • 営業所単位など絞り込まれた情報による粗い分析しかできてない
  • 分析に至るまでの手順や方法が個人スキルに依存している
  • データの抽出や加工に時間を要し,タイムリーに対応できていない

という課題を抱えていました。そしてこれらを解決するために選んだのが「ミドルウェアにHadoop,BIにSAS Visual Analytics」という構成です。板谷氏はその理由として「今後さまざなデータを蓄積し,掛け合わせて分析していくためにも,柔軟な拡張性を備えたHadoopが最適だと考えた。オープンソースであることもコストメリットが高い。またSASは個人スキルに依存することなく,誰もが直感的に分析でき,データ量やユーザ数の増加に対する拡張性を高く評価した」と語っています。

大東建託 板谷隆史氏

大東建託 板谷隆史氏

またNTTデータを選んだ理由として「Hadoopのリーディングカンパニーとして多くの知見が蓄積されており,NTTデータが執筆した産学連携ソフトウェア工学実践事業報告書に大きな感銘を受けた」⁠板谷氏)ことを挙げています。大東建託はシステム構築に際しては必ず3社見積もりを取るという習慣があるそうですが,今回の場合「NTTデータが最安値というわけではなかった」と板谷氏は振り返ってます。それでも同社を選んだのは,やはりHaoop構築で数多くの実績を残していることが大きかったようです。⁠NTTデータにはヒアリング専門の担当者がいたことにすごく驚いた。開発にずっとかかわってくれると思ったのに,突然いなくなってさびしくなった」⁠板谷氏)と,プロジェクトチームとしても良好な関係が築けたことを語っています。

新しいリスク分析システムにより,多様な分析ができる環境が構築され,たとえば「部屋単位の情報を積み上げた建物単位のデータにもとづいた,精緻な分析が可能になった」⁠間取り,地域,築年数などさまざまな切り口を組み合わせてかしかできるようになった」⁠個人スキルに依存しない分析が可能になった」という効果が得られているとのこと。大東建託には「正直,ビッグデータと呼べるほどの大量なデータはいまはない」と板谷氏は言います。しかし,データ分析が同社の今後のビジネスを支えるのは間違いなく,その基盤となるプラットフォームにHadoopを選んだことで,多様で柔軟なBI環境を構築することが可能になりました。今後はさらにHadoopでの実績を積み上げ,⁠いままでにないような,新しい切り口による発見や未来予測につなげていきたい。また,これまでの粗い分析しかできなかった基盤では根付かなかった"アナリティクスの文化"を定着させていきたい」と板谷氏。新しい分析基盤だけでなく,新しい企業文化もまたHadoopによってもたらされたと言えるのかもしれません。


イベント終了後,下垣氏にお話をうかがったところ,⁠Hadoopへの興味をもつレイヤが変わってきている」とコメントをいただきました。一般的なHadoopのイベントの参加者は開発者が多く,内容も技術的なトピックに偏りがちなのですが,今回はビジネスユーザの参加が非常に目立ったとのこと。これまでよりも幅広い層にHadoopが知られるようになっているのはたしかなようです。3トラックで用意された午後のセッションにも多くの来場者が詰めかけ,あらためて,データアナリティクスの基盤としてHadoop/Sparkが注目されていることを実感しました。

300人以上の来場者のそれぞれのレベルにあわせてHadoopやオープンソースのセッションを用意するのは,1社だけではかなり負荷が高いように思えますが,それを回せるだけの人材がNTTデータに揃っているともいえそうです。今後も三井住友カードや大東建託のような良いHadoop事例を積み上げ,オープンな新しい技術によるインフラの拡張がビジネスに結果をもたらすシーンを,同社が数多く作り上げていくことが期待されます。

著者プロフィール

五味明子(ごみあきこ)

IT系の出版社で編集者としてキャリアを積んだ後,2011年からフリーランスライターに。フィールドワークはオープンソースやクラウドコンピューティング,データアナリティクスなどエンタープライズITが中心。海外カンファレンス取材多め。Blog 「G3 Enterprise」やTwitter(@g3akk),Facebookで日々IT情報を発信中。

北海道札幌市出身/東京都立大学経済学部卒。