普段の製品・ソリューション紹介だけでは聞き出せない情報を「実際のところはどうなんだろう？」という素人視点で、専門家に聞いてみるシリーズです。
題して「実際どうでしょう」。。。どうぞ、ご覧ください。
今回は、お二人の方に同時にインタビューさせていただきました。名コンビで実況中継と解説という雰囲気になり、とても沢山の話題を提供して頂きました。
＜聞いてみて良かった(*´ω｀*) メリひろ担当がエキスパートにインタビュー＞
堀越 啓二 様
・入社以来、研究部門に所属し製品担当になったのは去年の秋
・趣味は5歳から続けているテニス、毎週テニスの試合を楽しんでいる
都築 英夫 様
・身長183cm 、体重秘密。以前より片目の視力が極端に弱かったが、最近、両目とも人工レンズに交換し好調。３Dテレビが見られるようになって嬉しい。
・料理は趣味というより日常。冷蔵庫にある余り物の即興料理が得意。
※ 2013年12月時点でのプロフィールです。
—今日はよろしくお願いします。お二人は同期なのですね。（インタビューアー）
堀 越：そうです。ただ、一緒に仕事をするようになったのは昨年の秋からです。私が研究所からブランド／製品の担当になったのがきっかけです。
都 築：開発研究所ですが、今は研究員もお客様先に行き、接点を持つようにシフトしています。
堀 越：基礎研究の人達は研究に集中していますよね。
都 築：そうですね、とりわけ、特許をとるために研究している人達は別ですよね。日本IBMは実は、特許だけでビジネスになっている企業なのです。
堀 越：あれ、詳しいですね。
都 築：以前、特許ソリューションを担当しておりましてね、えーっと、そのソリューションというのは・・・
堀 越：今日はHadoopがテーマですよね。
—そ、そうなのです、そのソリューションも興味あるのですが、まずは現在も注目されているHadoopについてお聞かせ願いますでしょうか。
都 築：了解しました。基本的な事項は堀越さんにお任せするとして、私は脱線担当ということで（笑）
堀 越：では適時私が振りますのでよろしくお願いします。（笑）
今さら聞けない？Hadoopの誕生の背景
堀 越：Hadoopは大量のデータを複数に分散して処理できるオープンソースのソフトウェアです。
採用企業は年々増えており、ビッグデータ活用には必要不可欠な存在になっています。
データ量の増加にともなうサーバーの増加をする場合は、プロセス同士の通信の監視や障害時の対応など、共有データ部分の管理が煩雑になります。いわゆるスケールアウトの課題です。
エンジニアにとって、分散処理は効果があるけれど、対応が面倒な存在だったのですが、Googleが先頭にたって開発したのがHadoopというフレームワークです。
そして、ペタバイトベンダーのYahoo!やFacebookなどがそのテクノロジーに注目して採用し、共同で開発して生まれたのが、ApacheプロジェクトのHadoopという訳です。
—元々はGoogleの開発だったのですか、知らなかったです。
都 築：そうです。背景を知ると面白いですよ。そしてHadoopといえば、MapReduce（マップリデュース）とHDFS（エイチ・ディ・エフ・エス）ですねMapとReduceという用語はLISPなどの関数プログラミングから来ていてですね、関数型言語なのですが・・・
堀 越：都築さん、その話になると一般の読者はついていけないかも・・
— 堀越さん、ツッコミありがとうございます。実はすでにメモを取る手がフリーズしておりました。
都 築：あ、失礼しました。暴走したら止めて下さい。それでは何故Googleが開発したかという話にしますね。豆知識です。（笑）
Googleの命は検索エンジンですよね。大量のデータ、当時で数億ページだったWebをクローリングして、ひとつひとつの単語にインデックスを付けるわけです。
ユーザが検索した単語にURLを繋げるというマッピングの作業なのですが、爆発的に増え続けているインターネットのページに対してGoogleは新しいページを数日でインデックスする事ができるのです。これらの基盤をHadoopは支えています。
えー、それでは本筋に戻しましょう。堀越さん、お願いします。（笑）
弱点を克服していくベンダー
堀 越：はい。解説ありがとうございました。それではHadoopの基本的なテクノロジーについて続けます。
Hadoop前は複数のマシンをプロセス監視（通信、障害検知）するためには逐一考慮して、プログラムする必要があったため、分散処理は大変だったのです。
Hadoop後は、プログラマーはそれらを気にすることなく分散処理を実装できるのですごく助かります。
都 築：実は、IBMはもっと昔に並列処理としてSP2というマシンがありましたし、DB2にもパラレルエディションというのがあって、分散並列処理で高速化したという点ではHadoopと同じでした。
—世の中に出すのが早すぎたのですね。
都 築：そうですね、ネット普及前だったので、それほど大きなデータではなかったという事でしょうか。
堀 越：確かにIBM独自の路線もあったのですが、オープン性をみて、Hadoopを採用したのです。
—先行開発だとすると通常は自社開発にこだわってしまいそうですが、切り捨てる決断も凄いですね。
堀 越：次に、Hadoopの構成を説明しましょう。
冒頭に出たMapReduceは処理の分散管理で、HDFSはストレージの管理、複数のマシンをひとつのマシンとして管理できる基本機能です。
とにかく、エンジニアは継ぎ足す度に、設定をかえていたので大変でした。この２つの機能で並列処理の利便性が格段に向上したのです。
都 築：この分散ファイルシステムの弱点はシングルポイントフェイラー（システムの冗長化が行なわれていない単一障害ポイント）ですが、全体を管理している人（Mainノード）をIBMは2重化して問題を解決しています。
—プロマネを二人配置するみたいにですね？
都 築：そうです、その人が急にいなくなっても大丈夫なように、つまり企業で使えるようにというのを意識しているのです。
堀 越：HDFSの良い点はデータ処理時間の短縮化ですね。そして、データ管理が強みもポイントです。
—Hadoop=大量データ=大企業向けというイメージですが。それだけじゃないということでしょうか。
堀 越：そうです、処理時間の短縮という点は色々な企業に適応できます。
夜間バッチでデータの加工、集計処理をしていたのが、昼間、その日に処理が完了したデータを見られるようになるというのは、企業収益の改善と直結します。
データの管理についてですが、RDBでの管理は、データが増えて、DBの表を大きくしていくとスケールアウトの課題にあたるのですが、HadoopはHBase(エイチベース)という分散データベースの仕組みを使っているので、表の追加・修正をする必要がないのです。
— それはいい事だらけではないですか？
堀 越：しかし、万能ではないのです。データのKeyと値で表現する、シングルデータ管理は得意ですが、リレーショナルな複雑なデータ管理は得意ではないのです。ですよね、都築さん。
欲しいデータそこにあるのに、取り出せない「暗黒大陸」
都 築：そうですね。やはり、トランザクションではなく、バッチ処理に向いていると言えます。
例えば、支店の売上げデータを締めて、集約して各支店の店長にレポートを出すという業務があったとします。データの量が増えていくけど、朝が来る時間はかわらない。
長くなるバッチ処理に担当者はドキドキしているのです。1日で終わらないケースもありますので、そうなると分析をしている担当は、データ待ちの時間がネックになります。
こういったシーンはよくあります。
ある銀行の分析担当の人は、欲しいデータはそこにあるのに、取り出せないので、「暗黒大陸」と呼んでいました。システム運用の方は対応したくてもバッチ処理や他の業務優先で対応できなかったのです。
—暗黒大陸ですか。（笑）すぐにデータを見たいフロントと様々なタスクをもっているバックエンドの対立というかジレンマは確かにありがちな課題ですね。
都 築：大量のデータを高速で処理できるというのはすごくメリットがあるのは、みんな知っていましたが、昔はサマリーデータ、つまり、1ヶ月分のデータをまとめて・・という業務が多かったのです。
堀 越：現在のように１週間でビジネスが変わってしまう時代では、それでは間に合わないですよね。
都 築：実は日本では昔からビジネスにおけるデータ把握はタイムリーに出来ていたので「あ、奥さん今日はそろそろおでんじゃないですか？いい大根あるよ」という商売ができていました。
しかし、マーケットの拡大や全国展開の大企業になると、データ集約が間に合わないので、粒度が荒くなっていきました。セグメント化してバルク（まとめて）でやらざるを得なかったのです。
ちょうど【顧客から「個」客へ】というのがIBMのスマーターマーケティングのスローガンになっていますね。
—そのテーマでもお話を伺いたいのですが、時間に限りがあるので、ぐっと我慢して、次のトピックスへお願いします。
技術者からみたら怖くて採用できなかった？
堀 越：では次にHadoopのオープンソースに対してベンダーが取り組んだことを話しますね。
HDFSでストレージ管理というのは新しく生まれた技術だったこともあり、本来ストレージとしてあるべき機能、例えばアーカイブ、スナップショットなどをサポートされていませんでした。
HDFS内のネームノードの高可用性がネックだったので、企業のインフラ管理者から見たら、対障害性という点で問題がありました。
都 築：もう、悪夢だよね。障害対応を考えると夜も眠れません。
堀 越：そう、技術者からみたら怖くて採用できないのです。（笑）
その対策を各ベンダーが出していきました。
HDFSの単一障害点の課題解決をはかったストレージベンダーなどです。
都 築：HadoopはSNSを駆使している企業にユーザが多いのですが、そのユーザはコンプライアンスをあまり気にされない場合があります。あ、言い方悪いですね。新しいサービスを立ち上げるスピード優先という意味です。
そもそもHadoopにはロックダウンする仕組みがなかった。
サービスの継続提供と共にセキュリティの強化というコンプラの順守を各ベンダーも考慮したのです。
堀 越：あとは、Hadoopは物理サーバー上のクラスターで処理しているのですが、Hadoop用の物理インフラを別途管理する必要があります。
サーバーの仮想化、統合化が進んでいるのに独立して物理サーバーを用意するのは面倒です。Hadoop用、BI用、ローカルストレージなど個別にサーバーを立てていくのは非効率なのです。
そこで、現在はApacheのクラスターをサーバー仮想上の上で動かすプロジェクトを進めています。
各ベンダーはインフラの観点でビッグデータの活用にどのようなアプローチをするのかがKeyになっていますからね。
都 築：Googleの仕組みって実は一般企業には足りないところが色々あるのです。あ、語弊がありますかね。
ただ、これは悪いことではなくて、Googleは自らのサービスで必要なところに特化しただけなのです。
この潔さが良いところなのです。ところがジェネラルパーパスとして一般企業でも安心して使えるようにするとGoogleが捨てたところをフォローするなどの配慮が必要です。
しかも、スピードを犠牲にしないで改善してきたMapReduce機能について、IBMはものすごく改良して、早さを生かしたファイルシステムにしています。
オープンソースは新しい技術をどんどん出すというところにフォーカスされていてそれが推進力になっているのですが、IBMは企業のお客様が必要なところも大事にしています。
ビジネスで言えば、管理の大変さ、コンポーネントが増えれば、管理のポイントが増えるので運用コストが増えていく一方だったのです。あるお客様はサーバーを増やすという運用の困難さが採用の懸念点になるわけです。
堀 越：そこでアプライアンスというのがひとつの答えなのですね。
都 築：そうです、そうです。冷蔵庫を提供する感じです。配置して、電源を入れて、温度調整のつまみをガチャガチャっと回して、ハイ使えますという感じです。
堀 越：今の冷蔵庫はつまみではないでしょうけどね。（笑）
都 築：そうですね。（笑）
その他にも開発支援ツールを出したりと、Hadoop関連では、周辺製品がどんどん出てきて、名前も”Pig”だったりして、動物園みたいになっています。
堀 越：しかも放し飼いね。
—Hadoopのロゴは黄色い象ですよね。それにしても放し飼いですか（笑）
都 築：そうです、もうね、象の周りに沢山の動物が放し飼いで・・・そこでZooKeeperを出して、全体を管理できるようにしています。
—その飼育員ですが、それは洒落ではなくて、プログラム名ですか？
都 築：はい。ZookeeperはApache Hadoopのサブプロジェクトです。設定情報の集中管理のサービスを提供するソフトウェアですね。
そのようなツールが必要なくらい、実は、普通にHadoopを入れようとすると大変なのです。
相性とかバージョンが合わないといったのはオープンソースでは良くある課題です。先端を追いかける人はそれでもいいのかもしれないが、一般企業ではそれでは不安です。
今は新しいシステムを導入するときはスタンドアローンということはなくて、必ず他のシステム経由のデータ連携がありますからデータアダプタを使ったりと様々な設定が必要なのです。
— それら煩雑な設定をまとめてくれるKeeperがいるということですね。
堀 越：そして、その分、値段も上がっていくこともある・・・（笑）
表に出てこない採用コストを削減するために
都 築：そこですね、沢山の周辺ツールやオプションがあるのはユーザの利便性向上にとって好ましいですし、必要なオプションを選択していけばいいという考えがあります。
しかし、パーツにわけたりするとお客様の 、予算、稟議プロセスも大変複雑になるのです。 この事務プロセスはコストなのです。
IBMが取り扱う製品だと何万パーツになる訳ですが、これでは事務プロセスが増えるだけです。
パーツを分けるのは個人ではメリットかもしれないが、企業だとコストになることが多いです。
—その観点はあまり聞いたことないです。確かに日本企業の予算獲得や稟議プロセスを考えるとお客様の担当者は次フェーズも含めて、まとめて予算申請しておきたいという要求はよくありますよね。
都 築：そうです。初期コストというのは分かりやすいですし、目立ちますが、運用コスト、障害時の対応コストに加えて、導入する際の検討、採用コストも考慮すべきです。
—決してベンダー都合ではなく、お客様が選択、採用しやすい仕組みを設けるのもベンダーの役割ですね。
都 築：はい、あとベンダーの役割としては、こういった新しい技術を知ってもらうための活動に力を入れるというのも大事です。
近年は一方的なメッセージや囲い込みではなく、オープンコミュニティにお客様も参加してもらい、認知してもらっています。
オープンコミュニティはお客様とベンダーの窓口として大事です。あ、またHadoopから離れちゃいましたね。
いつ採用すればいいのか？
堀 越：それではスタジオに戻します。（笑）
なぜ、Hadoopなのか、いつ使うのか？という話をします。
都 築：「今でしょ！」 でいいですか？ 年間大賞としても旬ですから、今のうちに使っておきましょう。
（一同 笑い）
堀 越：そうですね、今ですね。
何故ならば、過去において、企業は社内データの活用でよかったのですが、グローバルな競争に勝ち、ビジネスチャンス拡大にはマシンデータやSNSなどの外部データを積極的に取り込んでいくという綿密な情報戦略が必要です。その中ではHadoopは必然な存在です。
オープンソース＋付加価値の製品が出てきているので、企業戦略として採用しやすくなっています。
こういったツールを活用してビッグデータへのベストとプラクティスを作るのが（MERITひろば運営会社の）NI+Cさんやシステムインテグレータ様 の力の見せ所なのです！
—あ、ありがとうございます。「最後のひとこと」のようですね。
都 築：締め括りに入らなければならないところをまた脱線します。（笑）
データ活用という意味では、データ・ソースというキーワードが大事です。
10月7日に開催されたIBM Think Forum Japan 2013で、ロメッティ（IBMのジニー・ロメッティCEO）がパナソニックの津賀一宏社長とパネルディスカッションをしていた時の話です。
パナソニックのカスタマーサポートでは一日に１万件の電話がくるらしいです。
これを分析すれば新しい製品のヒントがあるだろうと思って分析したら新しいアイデアは出てこなかったそうです。
そこで気がついたのは新製品開発には内部だけではなく、外部の人の声、つまり現在お客様では無い人の声を聞くのも大事だということです。
そこでSNSデータの有効活用に発展していくのです。
—なるほど。実際にやってみないと分からないことも多いですよね。脱線ついでですが、ビッグデータという意味ではマシンデータ、とりわけセンサーデータの活用について興味があります。 以前、データサイエンティストの中林さんにインタビューした時に、センサーデータの活用はこれから発展してく領域だと伺いました。
堀 越：国内大手重機メーカーは重機が地球の裏側で故障しても、アラートがあがって迅速にメンテパーツを送ることができるなどは有名な事例ですね。違うパーツを差すとエラーも出るすぐれものです。
都 築：確かに、アフターパーツの補完、管理はメーカーにとってコストなのです。
堀 越：さらに、故障前にアラートあげるという仕組みも進んでいます。
—SPSSも品質保全管理のソリューションとして出ていますね。あ、更に脱線しますね。
都 築：はい、MDA（Machine Data Analytics）は興味深いソリューションですよ。統計の世界ではオーバーフィッティングの問題があります。
データマイニングの世界では点をつなぐ重回帰の考えですが・・・（以下、ページの都合上省略。ご了承下さい。）
よし、SPSSの話は次の機会にしましょう（笑）
とにかく、現在、製造業においてアフターマーケットがアツいです。ここは日本企業が強いです。
—それでは、そろそろまとめをお願いします。
堀 越：Hadoopが必須技術なのは先ほど申し上げたとおりですが、それ以外にも技術の進歩は速いです。
使う側のユーザも進歩しなければ使いこなせないのですが、使う側が強い意思、意図をもっていなければならないと思います。我々はそれを支援するのです。
都 築：例えば我々（IBM）が、万年筆を製造する立場だとするとインク補填もいらないくらい、ずっとスラスラ書ける最高の万年筆を作ります。
周辺として専用の紙もあってインクもにじみません・・・という製品を売っていますが、「では直木賞はどうやってとるのですか？」とお客様に聞かれても我々は答えを持っていません。
そこはお客様の経営判断なのです。
—お二人ともありがとうございます。堀越さんにはきっちりと基礎を教えていただき、そこから都築さんが動物園から万年筆まで色々な例えをしてくださり、とてもためになって楽しいインタビューでした。
