Home クラウド SIベンダーが取り組むクラウド・ネイティブ開発 ~JBCC 高浜 祐二氏に聞く

SIベンダーが取り組むクラウド・ネイティブ開発 ~JBCC 高浜 祐二氏に聞く

by kusui
クラウド・ネイティブ・コンピューティングは、SIベンダーの取り組みにも大きな影響を与えている。中堅・中小企業を中心に2万社以上の基幹システムの構築・運用実績をもつJBCCでは、数年前からクラウド・ネイティブ技術にフォーカスし、技術の検証や適用を進めている。同社のSI事業を牽引する高浜祐二氏に話をうかがった。

 

高浜 祐二氏 JBCC株式会社 SI事業部 東日本第ニSI本部 本部長

 

 

従来の方法と
サーバーレスの組み合わせ

IS magazine(以下、IS) JBCCではクラウド・ネイティブなアプリケーション開発にどのように取り組んでいますか。

高浜 まず大きな捉え方として、従来からのシステム構築・運用を置き換えるものではなく、それを広げるものと見ています。そのため従来の開発手法がよりフィットする場合は、そちらを選択します。モノ作りの観点で言えば、より速く、より効率よく、よりよい品質のシステムを開発できる方法をずっと追いかけてきていますが、最近はクラウド・ネイティブ開発という言葉でくくられるテクノロジーにフォーカスしています。

 たとえば従来の方法では、サーバーのセットアップやキャパシティ開発など、手を動かすことがたくさんあります。これに対して「サーバーレス」では、ある程度サービスの制約は受けるものの、サーバーのセットアップやキャパシティ・プランニングは不要で、クラウド側が処理してくれます。しかも自動でスケールし、システムを稼働させた時間だけの課金というメリットもあります。

 従来の方法は、やるべきことが多いぶん、自由にカスタマイズでき、お客様の求める要件にきめ細かく対応可能です。しかし、その負荷は軽くはありません。その一方、サーバーレスはそうした負荷が非常に少なく、業務ロジックを書くことに専念できます。このメリットは、モノ作りの側から言えば、とても大きな魅力です。

 お客様の実際の案件では、サーバーレスなどの新しい方法を、従来からの方法と組み合わせることが増えています。基幹・業務系システムは従来の方法で、モバイルやB2C、デジタル・トランスフォーメーションに関わるシステムはサーバーレスで、という組み合わせです。

IS サーバーレスをユーザーが要望してくるケースもあるのですか。「このシステムはサーバーレスで構築してください」とか。

高浜 スキルフルなお客様からそうした要望が出されることもありますが、ごくまれです。大半は、こういうアプリケーションを作りたい、業務をこう改善したい、という依頼から始まり、それを受けて提案するときに、よりよい手段の1つとしてサーバーレスを用いる構築提案し、採用いただくパターンが一般的です。

 

接客・販売データ管理システムを
サーバーレスで構築

IS つい最近も、サーバーレスを適用した案件があるそうですね。

高浜 時計・宝飾品の輸入および国内販売を行っている株式会社ホッタ様の「接客・販売データ管理システム」の開発にサーバーレスを適用しました。

IS 採用のポイントは何だったのでしょうか。

高浜 ホッタ様では、23ある店舗から本部へ、毎日もしくは毎週、Excelで詳細な販売報告書を提出し、本部ではそれらをまとめて業績データを作成していました。しかし、その負荷が半端ではなく、店舗・本部の担当者の大きな負担になっていたのと、一部の店舗で在庫をリアルタイムに確認できないことや、販売履歴が一元的なデータとして残っていないために、次につながる接客が行えないことが大きな課題となっていました。そこで販売担当者が接客しながら使え、リアルタイムに在庫を確認でき、さらにネットワーク環境のよくないデパート内でも快適に利用できて、繁忙期にも対応可能なシステムを、当社では構想しました。その結果、採用したのがサーバーレスです。短期のサービスインが要請されていたことも、サーバーレス採用の大きな要因でした。

IS どのようなシステムですか。

高浜 システムは当初、図表1の構成で進めました。簡易Webサーバーの機能ももつAmazon S3にWebアプリケーションを置き、接客・販売データ管理システム(業務ロジック)はLambdaに、データはNoSQLデータベースのDynamaDBに配置する構成です。

 

 ところが開発を進めていくなかで、検索条件が大きく増えることになり、その検索部分についてはNoSQLのDynamaDBでは要件を満たせないことが判明し、急遽、リレーショナルDBのAuroraに切り替えました。そして構築中の2017年時点では、AuroraとLambdaを連携させる機能がなかったので、RDSとEC2を用意し、EC2が複数台必要なのでロードバランサーのELBを配置する構成としました。サーバーレスとサーバーありとが併存する、ハイブリッドなシステムに仕立てました(図表2)

 

 

IS ユーザーの課題はどのように解決しているのですか。

高浜 店舗の販売担当者がタブレットでシステムにアクセスし、メニューから「接客販売入力」画面(図表3)へ入って入力を終えると、そのデータはただちに本部へ送信され、かつ接客・販売データベースに蓄積される仕組みとしました。つまり、データの送信がそれまでの週報の代わりとなり、蓄積した接客・販売データはいつでも参照できる仕組みです。販売担当者にとっては、日報もしくは週報のための煩雑な作業がなくなり、接客に時間を割けるようになりました。本部スタッフにとっては、週報のまとめ・整理に煩わされることがなくなり、本来の営業・販売支援やマーケティングに注力できるようになったとのことです。

 

IS 開発で印象に残ったことはありますか。

高浜 お客様のほうで店頭で利用する際のレスポンスを非常に重視されていたのでシングル・ページ・アプリケーション(SPA)を採用しましたが、それが非常によかったと思っています。

 SPAは、ブラウザによるページの遷移を行わず、単一ページでコンテンツを切り替える技法です。ホッタ様のプロジェクトでは、最初にWebアプリケーションと業務ロジックをつなぐインターフェース仕様を決め、その次に、仕様に基づく“おうむ返しのAPI”をバックエンド側で作成しました。

“おうむ返しのAPI”とは、Web画面で入力があると、それに反応するだけのハードコーディングのプログラムです。このプロトタイプを作ったおかげで、フロント側とバックエンド側とで相互に仕様を確認し合え、お客様にも具体的なイメージを基に早い段階でUIの出来やシステムの機能を確認していただけました。最終的にプログラムの手戻りがなく、品質を保ってプロジェクトを推進できたと評価しています。プロジェクトでは、インターフェース仕様を確定させたあとに、フロント側とバックエンド側とにそれぞれ分かれ、並行してUIの作り込みとロジックの開発を進めました。

 

基幹システム連携、
マイクロサービス、コンテナ

IS 既存の基幹システムとの連携で、サーバーレスを使うことはありますか。

高浜 案件としてはこれからですが、基幹上の在庫管理システムをチャットボットから利用するような連携は、今後増えてくると見ています。当社では、基幹・業務システムのモダナイゼーションでは高速開発ツールのGeneXusを推進していますが、GeneXusにもAPI連携の機能が取り込まれ、環境が整ってきています。具体的には、Swagger(RESTful APIの仕様を共通化するオープンソース)で作成した定義をGeneXusに取り込むと、API連携するためのプログラムを生成するというものです。

IS SI案件で、開発するシステムをマイクロサービス化する動きはありますか。

高浜 マイクロサービスの開発は、最初はとても大変で、モノリシックなシステムの1.5?2倍はかかりますが、疎結合で作っておけば、あとで部分的な改修がしやすいので、長い目で見れば大きなメリットです。今後は業務システムでの採用も増えていくと考えていますし、JBグループの俺のクラウド(*)で提供している販売支援業務パッケージ(NX販売支援)などでの採用も検討していきたいです。

 それとNX販売支援の開発に関しては、2年前からDevOpsに取り組んでいます。頻繁かつ継続的なシステム改善や機能追加を行うためですが、すでに図表4のような構成で実践しています。これにマイクロサービス化を適用していけば、さらに細かい粒度で、サービスの改善や機能追加が行えます。

 

IS コンテナについては、どのように見ていますか。

高浜 コンテナは、マイクロサービス・アーキテクチャの採用に密接に関係してくると感じていますが、現在はクラウドベンダーが使うケースが多いとの認識で、お客様のSI案件で本格的に検討することは多くありません。ただし今後は、マルチクラウドの観点で重要になると見ています。つまり、クラウドサービスの利用を1社に絞ったときの危険をいかに回避するかという、リスクヘッジの観点です。コンテナでシステムを構築しておけば、あるクラウドでサービスが突如停止となっても、別のクラウドへの移行がスムーズに行えます。

 コンテナも、Kubernetesが登場し、管理機能や可用性を担保する仕組みが整ってきました。これからは、コンテナで業務システムを構築する例が増えてくると思います。

 

クラウド・ネイティブ時代のエンジニアの要件

IS クラウド・ネイティブ・コンピューティング時代のエンジニアの要件は何でしょうか。

高浜 即戦力になるのはAPIを使いこなせる人で、次はAPIを作れる人、そして世の中のクラウドサービスを幅広く熟知し活用できる人だと思います。

 APIについては、一般化されたAPIは使えばいいだけですが、API自体が作れないと、お客様に合ったシステムを柔軟に構築・改修していくことはできません。APIは今後ますます重要になる技術だろうと思います。

 それと、私の部署では、アプリケーション・エンジニアもインフラのスキルを身に付けるべきだと、機会あるごとに話しています。それは、システムがトラブったときにインフラがわからないとシューティングできないのと、インフラ担当者と会話できないからです。Dockerくらいは勉強しておいてくださいね、と伝えています。

IS 今年5?6月に開催されたJB Group IT Forum 2018の講演で、「JBグループはIT業界のクックパッド」と言っておられました。「豊富なレシピを揃えています」とも。

高浜 レシピは、一般的には「クラウド・デザイン・パターン」と言われますが、そのクラウド・デザイン・パターンをたくさんもっていることが、SIベンダーとしての強みであり、他社との競争のポイントにもなると考えています。日々変わる外部のサービスをキャッチアップしながら、それも取り込み、いかにソリューションのレシピを揃えていくか。JBグループ各社がそれぞれの強みを活かし、取り組みを進めています。

・・・・・・・・

(*)JBグループとパートナー企業が互いの技術を活かしてクラウド基盤の構築からソリューション、運用まで、必要なものを最適な形で提供し合うエコシステム・クラウドサービス。

・・・・・・・・

[IS magazine No.20(2018年7月)掲載]

related posts