(2016年04月現在)

ERPを中心とするビジネスパッケージで高い評価を得ているSAP。今、SAPで新たなトレンドが本格的な展開期を迎えている。メモリー上で各種のデータを超高速処理する「SAP HANA」だ。それほどの高速処理が必要なビジネスなのであれば、必然的に大災害発生時への対応(DR=Disaster Recovery)も重要課題になる。高速処理とDRは両立できるのか。この難しい課題に挑み新技術の新たな展開の可能性を示したのがJSOL認定ITプロフェッショナル(ITアーキテクト)の板東貴治である。

JSOL認定ITプロフェッショナル
ITアーキテクト
坂東 貴治

大容量データの高速処理を実現するHANA

「SAP HANA」は、一般的には「単一のメモリー上で高速なトランザクションデータ処理を実現するインメモリー・コンピューティングの技術」などと定義されている。「ストレージに蓄積されている各種のデータを、すべてメモリーに読み込んだうえで、各種処理を超高速で行おうというものです。膨大なデータのリアルタイム分析、短時間での高速処理など、従来のデータベースでは実現が難しかった処理が可能となってきました」

HANAが市場に投入されたのは2010年のことだった。すでに世界で4000社以上が導入しているとも言われる。HANAはすべてのデータをメモリー上で処理するインメモリコーピューティング技術により、ストレージからデータを読み込む従来のデータベースと比べて数千倍から数十万倍の高速処理を実現している。
SAP社のプレゼンテーション資料によれば、2020年末には世界で2120億個の「もの」がネットワークでつながり、同じく20年までに世界のモバイルユーザーは90億人に達する。膨大なデータが連携する、いわゆるIoTがビジネスの前提になり、しかもデータには地理空間データなどの関連情報も付加されている。
これらの膨大なデータを高速分析することで、例えば販売手法を機動的に見直したり、資材の所要量の見込み計算を迅速にしたり、最適な物流ネットワークを組成したりできる。もちろん一般的な経営分析も高速化するし、高速化することで経理ミスを素早く発見できるといった副次的な効果もある。

「すでにSAPの各種ソリューションは多くの企業で活用されていますが、そのシステム更新時だけでなく新規でSAPを導入するお客様においても、『HANAも併せて導入したい』というお客様が増えてきました。2025年にはSAPのデータベースはHANAのみのサポートになると言われていますが、JSOLでは今から積極的にHANAの導入をご提案しています」

SAPの専門家である板東が、HANAの導入を望む顧客のために支援を行うのは特別なことではない。しかし板東がここ数年、あるプロジェクトを通じて取り組み、実績を積み上げてきたのがHANAをベースとするBCP(Business Continue Planning)やDR(Disaster Recovery)といった大規模災害発生時における事業継続のための仕組みづくりだった。
考えてみれば当然のことなのである。超高速データ処理を必要とするような業務が、大規模災害によって継続できなくなれば、その被害・損失は甚大になる。企業の立場からすれば、HANAでの超高速データ処理は寸時も断たれることなく継続できなければならない。
「2011年の東日本大震災を経て、受発注を行っているお客様などは、大災害の発生時だからこそ安定した基盤で受発注処理を高速でさばき、市場にモノを供給したいと考えています。しかし、HANAとDRなどを絡めたシステムのあり方はまだ事例が少なく、今回のプロジェクトではクラウドの活用も含めて新たなサービスの提供に挑みました」

HANAを大規模災害の事業継続にどう使うか

板東がJSOL側のプロジェクト・マネジャーに就任したのは、ある大手食品会社のSAPシステム更改プロジェクトだった。
プロジェクト自体のコンサルティングとアプリケーションの構築は別の会社が担い、JSOLはシステム全体のインフラ部分を担うことになっていた。
ただ、食品会社側から「ERP on HANAの活用とDRも絡めたシステムを構築したい」との要望があり、システム基盤ならびにSAP BASISの専門家である板東らJSOLのベーシスチームにも構築に参加するよう要請がなされた。
「今回のシステム更改プロジェクトでは、SAP ERPだけでなく、ERPを中心とした周辺のシステムも全面的に入れ替える計画であり、SAPを中心としたシステム基盤の構築を担っていた私たちにもお声をかけていただけました」

HANAを導入し、かつDR対応も行う。そのためにはいくつもの課題が抽出された。
例えばHANAはメモリー上で超高速処理をする。とすれば莫大な容量のメモリーが必要になり、システムは必然的に高価になる。板東によれば必要なメモリーの容量はストレージの容量に規定され、およそストレージ容量の半分のメモリー容量が必要だ。例えばストレージが2Tバイトならば、必要なメモリー容量は1Tバイト。ハードウエア故障や拠点災害に備えた可用性、SAPシステムとして必要なシステムランドスケープを考えたうえに、RPO(Recovery Point Objective=復旧目標時点)、RTO(Recovery Time Objective=復旧目標時間)などの「目標復旧水準」を満たすためにはHANA環境だけでも莫大なコストがかかる。
例えばDRでも、大災害発生時に業務を成り立たせることを考えた場合、ERPだけがDR対象ではない。ERPを中心とした周辺のシステムのDRも考慮する必要があり、またそれらの復旧手順も確立しておく必要がある。
「いずれにしもコストのかかるもので、システム構築技術や長年のベーシスの知見を駆使して、『確実かつ低コストで実現する手法はないか』などと要望されました」

ITアーキテクト 板東 貴治

先にも書いたような可用性、システムランドスケープ、コスト、復旧水準を満たすために組んだシステム構成は複雑なものとなり、DRとしてシステムを構築するとどのような問題が発生するかは十分に予測がついていなかった。
「そのためにJSOL社内でさまざまなテスト、検証を繰り返し、事前にトラブルの芽を摘む作業を進め、手順を確立しました。実際に、ERP on HANAを中心としたシステム全体のDR切替テストも行いましたが、RTOを満たす形で切り替えることができました。特にHANAに関しては、クラスタ環境とDR環境の二面性を持たせる必要があり、切り替わった時のシステム状態、フェールバックなどの復旧手順については、テストを何度も繰り返しました」

SAPシステム以外に、どの業務をDRとして対象にすべきかについては顧客に検討を依頼。ERP on HANA以外には受発注システムや帳票システム、EAI(システムを連結してデータやプロセスを統合するツール)、これらを統合運用する環境(ジョブ、監視)、さらには食品業界で活用されているEDI(電子データ交換)との接続のための仕組みなども含まれていた。
通常は東京にあるセンターで運用されているSAPシステムは、災害発生に備えて大阪のセンターにバックアップが取られるようになっている。

SAP BASIS、システム基盤に対する深い理解があってのシステム構築

板東のJSOLのベーシスチームに、新技術による新たなシステム構築が期待されたのは、「SAP BASIS」「システム基盤」に対する高度な専門能力を評価してのものだった。システム基盤は、システム構成でいえばOSなどのインフラ部分と、各種の業務処理を担うアプリケーションの中間に位置する仕組みだ。SAPでは、BASISがそれに位置し、BASIS関連だけで独自のビジネスが成立するほど重要な部分だ。

ITアーキテクト 板東 貴治

SAPのERPやBWなどのアプリケーションは、周辺にシステムや業界のEDI、またWebベースでの認証管理などといったさまざまなデータと連携して処理を行っている。簡単に言えば、SAP以外のさまざまなデータやシステムとつながるための仕組みが必要で、それがシステム基盤だ。
「システム基盤がないとSAPはシステムとして成立しない、と言っても過言ではありません。システム基盤をしっかりつくり込めないとSAPシステムは、その優秀な機能を発揮できないのです」

大手食品会社のシステム更改プロジェクトでも、ERP on HANA以外に複数のシステムが新規で導入された。それは顧客自身が使いやすくするためのものだが、それらのシステムとの連携を構築するとなると、品質面の確保もハイレベルなものが要求されてくる。
またSAPとは直接には関係はないが、新システムの稼働において、全国の工場や営業所での帳票類利用にあたり正確にプリントアウトできるようにしてほしいとの要望も出された。システムを使う人の身になってシステムを当たり前に動くようにしていく。システム基盤の仕事は、実に多岐にわたり、かつ力仕事の側面もある。
「今回のプロジェクトでは、JSOLの3人のチームでやり抜きました。BASISは、他のシステムやネットワーク、周辺機器などシステムを構成する多様な技術に対しての理解がなければできない仕事です。SAP BASISだけでなくシステム基盤全体を見ることができるのが、JSOLのベーシスです。それだけにさまざまな課題や要望に応えていきます。言葉を換えればお客さまの要望が最も集中する部分でもあり、さまざまな事態が発生して振り回されることも珍しくありません。ベーシスはタフでなければできない。これが私の経験則です」と板東は笑う。

プロジェクトではERP on HANAを中心としたDRの仕組みを創りあげた。セキュリティー上、詳細を紹介はできないが、ERP on HANAの導入とDRでの展開という2つの課題に対して、クラウドサービスの比較、周辺システムとの相性、コストなども含めて総合的な提案がなされた。
「HANA自体は、SAPが規格をがっちりと固めていますので直接改変することはできません。むしろ、データベースとしての機能を、どのようなアプリケーションやシステムと絡めると面白いことができるようになるのか。JSOLではHANA利用したさまざまな取り組みが行われています」

顧客からも高い評価を得た。JSOLは毎年CS(顧客満足度)調査を実施しているが、今回の大手食品会社からは、「BASISを中心に、より顧客のためにという姿勢を崩さず、いわば付ききりでプロジェクトを成功に導いてくれた」と評価された。板東は、「困っていらしたら何でも受けてしまう。受けないと気が済まないですね」と笑う。

趣味は数学入試問題と一人マラソン

このインタビュー連載をお読みいただいても分かるとおり、JSOL認定のITプロフェッショナルの面々は、実にユニークな経歴や着想でプロとしての技量を磨いてきた人たちばかりだ。板東の経歴や人柄もまたユニークである。

大阪生まれの大阪育ち。大阪大学理学部数学科を卒業して日本総合研究所(2006年に日本総合研究所より分社)に入社した。数学科では解析を専攻した。師と仰ぐ人がいて、「その先生以外のもとで学ぶ気になれず、必然的に先生の専攻である解析を自らの専攻としました」。
数学者になる夢もあった。ただ、「数学の世界では、未知、未解明の問題のどれか一つでも解明するような論文を出せれば数学者として生きていけます。しかし、先生のもとで学んでいて、自分にはそのようなセンスはないと悟らされました。フェルマーの最終定理が証明された時は、感動したのですけどね」

ITアーキテクト 板東 貴治

日本総合研究所に入社したのは、何もないところからシステムが連携、稼働することに興味を持ったからだ。とは言え、「プログラミングは嫌だ」ということから、入社後すぐにSAP BASIS・システム基盤のチームに配属され、以来、この道一筋だ。
入社から5年後には早くもシステム基盤やSAP BASISのリーダーとして多くのプロジェクトに参画してきた。
「このチームに配属され、新技術も積極的に触らせていただき、新技術が明るみになった時などは、非常にうれしく思います。システム基盤でもJavaの技術が必要になってきますが、たまにコードをかいたりすると楽しいですね。そこは成長したかも」

好きなことは、「数学の大学入試問題を解くことと、ランニング」。
今でもなお数学は大好きで、「悶々と悩みながらもスーッと解答に向かいパッと目の前が広がるときの爽快感がたまらない」。毎年、その年の大学入試の問題集は、ゴールデンウィーク前に出版されるのだという。「ゴールデンウィークに出かける予定がなければ、問題集を買い込んでひたすらに解いています。暗いですかね。私にしてみれば最高のリフレッシュ策なのですが」と笑う。

そしてもう一つ、欠かさないのがランニングだ。毎日走っている訳ではない。その代わり金曜日の夜は、飲み会があって多少酔っ払って帰っても必ず走る。「雨が降っていようが吹雪であろうが、金曜日の夜は必ず走ります。走ると嫌なことも忘れられて、何かに一つの区切りを付けているように思います」

「以前は、仕事中心の日々だったのでいまだに独り者。そろそろヤバいですね」。そんな働きづめの独り者の1年の納めは、「箱根大学駅伝コース1人挑戦」だ。
12月30日の深夜0時に大手町を出発。15時間をかけて100キロ先の芦ノ湖をめざす。到着すると日帰り入浴の施設で温泉につかり仮眠。31日午前0時には芦ノ湖を出発して自宅をめざす。
「自宅には紅白(歌合戦)に間に合うように戻ります。人に抜かれるのが嫌なので、マラソンレースには参加しません。たった一人で、自分のペースでぷらぷらと走る。これが最高の幸せなのです」
腰にバッグを付けて小田原の山を12月30日のお昼頃に黙々と駆け登り、31日未明に駆け下りる男を見かけたら、それは板東かもしれない。


  • 本ページ上に記載または参照される製品、サービスの名称等は、それぞれ所有者の商標または登録商標です。

  • 当コンテンツは掲載した時点の情報であり、閲覧される時点では変更されている可能性があります。また、当社は明示的または暗示的を問わず、本コンテンツにいかなる保証も与えるものではありません。

関連リンク

もっと見る