ファイル転送、データ連携ならHULFT

クラウド時代の今とこれから クラウドが当たり前になった時代に起こりつつあること

第2回

現在、クラウドを取り巻く状況は一気に進み、少し前まで「これから」の取り組みとして語られることも多かったクラウド化の取り組みは、「今やらなければならないこと」として語られるようになってきたように思います。しかし、そのためにこれから何にどう取り組めばよいのでしょう、あるいはそもそも、クラウド化の流れは今どういう状況なのでしょう。

そこで今回、セゾン情報システムズのCTOであり、またテクノベーションセンター長である小野 和俊に、クラウド時代に向けた変革の取り組みを踏まえて、クラウドの「今」と「これから」について、クラウド化が進む今後「何に取り組むべき」なのか伺います。

PROFILE

小野 和俊

セゾン情報システムズ CTO・テクノベーションセンター長
アプレッソ 代表取締役

  • 肩書と所属はインタビュー時点のものです

「クラウドを使うかどうか」ではなく「クラウドを使うことがまず前提」の時代になっていて、今はさらにその先まで進みつつある、ということを伺いました。

しかし、クラウド化はなかなか容易ではないところもあると思います。既存システムを捨ててクラウドの新システムでやりなおす、というやり方は勇ましいけれども業務としては現実的ではないことも多いので、現実的には既存システムをクラウドに移す必要があるわけですが、こちらもなかなか容易ではないことも多いと思います。

「全部クラウドにする」というのは話としては分かるけれども、不安になってちょっと身構えてしまう、という人も多いのではないでしょうか。

そこで次は、失敗せずに「クラウドへ移行」するにはどうしたらいいかについて、話を伺いたいと思います。

結局、NoSQLではなくRDBMSが使われている

小野
クラウドが騒がれ始めた初期のころ、当時何が言われていたかというと、RDBMS※というのはクラウドのアーキテクチャにあんまり向かないと。

あー、ありましたね。

なので、これからはNoSQL※なんだみたいな話がありました。

RDBMS(relational database management system)
いわゆる世間でDBと言ったときには該当する。「SQL」で様々な操作をして利用する。様々な機能が作りこまれており、業務システムで長年にわたって広く使われている。
NoSQL(Not only SQL)
RDBMS以外のデータベースをおおまかに指す言葉。RDBの利用を前提とした従来の常識にとらわれずに、クラウドやビッグデータ時代に必要となるDBを開発し使おうという風潮が大いに盛り上がった時期がありました。
従来のRDBが苦手なことが解消されていることが多い一方、トランザクションが利用できない、JOINができないなど、機能性に制限があることが多く、SQLも使えないものがほとんどで、従来のRDBMSとは異なる利用ノウハウも必要になりました。

実際僕も、MIJS(Made In Japan Software Consortium)という業界団体の中で、製品技術強化委員会というところにいて、NoSQL時代のエンタープライズシステムのトランザクショナル処理みたいな、色々な実証実験をやっていました。

ところが実際ふたを開けてみたらどうなったかというと、実際のところ、エンタープライズではクラウドでもRDBMSを使っているんですね。もちろんIoTのセンサーから集まってくるデータを全部集めるとかそういうのは別ですが、トランザクショナルなシステムは結局RDBMSだったと。

やっぱりSQLの知見って、みんな長いことやってきているから積み上げがすごいわけです。SQL職人みたいな人々もいっぱいいたりするし、従来からのやり方であれば、失敗しないパターンも見えてきます。

なので、自分たちの今までの成功体験とか、自分たちの今までのスキルが生きるやり方の方が結果的にシステムが安定するということがあって、結局、多くのエンタープライズのシステムが、結局クラウド上でもRDBMSを用いている、もしくはRDBMS的なものを用いている。

会社の人が持っているスキルセットはそんなにすぐ変わらないわけですよね。システムはクラウドに移ったけれども、データベースがNoSQLに変わったわけではないと。

「Lift and Shift」

クラウド化を成功させる移行アプローチに「Lift and Shift」という取り組み方が知られています。
「Lift and Shift」とは、一気にクラウド化すると大変なので、「Lift」でとりあえずレガシーな構成のままでもいいからクラウドに載せましょう。そこから、クラウドらしいシステム構成にする(Shift)のが、うまくゆくコツですよと。

「Lift and Shift」は確かにその通りで、クラウドにするけれどもNoSQLにはしなかった、まずはそれで良かったという話だと思います。

SIerとしても、セゾン情報システムズとしても、また弊社と取引のある様々なお客様にとっても、クラウドだからこうすべきなんですよ、と一気に変えすぎると、変わるところが大きすぎて混乱の割合が大きくなってしまいます。

まず最初にスモールスタートすることが大事で、クラウド化を体験すればわかることも沢山あります。ですから、最初は「Lift」に取り組みます。

あまり現状のシステム構成を変えずに、しかし全く変えるつもりがない、みたいなのもそれはそれでよくないので、例えばストレージのところだけクラウド的に変えてみようとか、変化する割合を、これなら今の自分たちでもいける、これなら今までのシステムと根本的には変わらない、というところに設定するんです。

MITメディアラボ所長の伊藤穣一氏が、今の時代の行動の原則として「Practice over Theory(理論よりも実践を)」ということを言っていますが、そうやってまず最初に「Practice」してみる。やってみて解ることがあるから、まずスモールスタートして、その先はその後でもいい。

クラウドではこういうのを使っちゃダメなんです、今までのやり方を捨ててください、そういうのではなくて、今までのやり方をあまり崩さずにクラウドにする。そしてそのためにまず「Lift」する、というのは大事だと思うんです。その後の「Shift」もいきなり全面的に「Shift」でなくて、だんだんクラウドネイティブなアーキテクチャにするのが現実的だと思います。

例えばAWSだと、単にオンプレミスを引っ越しただけだったのを、「Amazon S3」を使ってみようとか、ELB(Elastic Load Balancing)を使った冗長構成にしようとか。データベースの話で言うと、自前のRDMBSを「Amazon RDS」に変えてみるとか、さらにNoSQLの「Amazon Dynamo」に変えてみようとか。

変えながらクラウド化の体験「Practice」を通じてこのあたりも学んでいけると思うんです。例えば、こういう場合は「Amazon Redshift」を使うんだなとか。

「スキルセット」と「マインドセット」

クラウド化に限らないと思うのですが、「変えなさい」と言われているものの、一方で実際に変えるのは難しい。落としどころは無いわけではないけれど、この状況をきちんと説明することも難しいので、納得してもらうことが難しい。ということで板挟みになって困っている人も多いと思います。

デジタルトランスフォーメーションみたいな話をしたときに、スキルトランスフォーメーションはそんなに簡単ではないですよね。明日からNoSQLでシステムを作ってくださいと言われてもなかなか難しい。一方でSQLのスキルと経験を捨ててしまうのも惜しい。

スキルトランスフォーメーションは最小限にしないと、クラウドにするので考え方が全部かわりましたというのは受け入れがたいんですよね。ユーザにとってもSIerにとっても。

どちらかというとマインドセットのトランスフォーメーションの方が必要だと思っています。マインドセットは変える必要があると思っています。

その切り分けはとてもわかりやすいですね。思い出したのですが、中国の荀子の言葉に「着眼大局、着手小局」というものがあります。考えるときには大局を見て考えなさい、でも行動するときには着実な小さな積み重ねで、と。

「マインドセット」は思い切って変えましょう、でも「スキルセット」は慎重かつ着実に変えましょう。とてもわかりやすいですね。

失敗しないように、着実にという意味では、クラウドへの移行の際には、クラウドを使うこと自体がチャレンジなわけじゃないですか。それ自体が見えない部分が大きいし、今までのやり方で当然できると思ったことが意外とできなかったり、リスクがあるわけですよね。

そういうなかで、変なところで躓いてしまうと、ただでさえもチャレンジなのでにっちもさっちもいかなくなってしまうわけですよね。そういうことにはならないように注意しないといけない。例えば、できるだけ低レベルレイヤーというか、インフラに近いところで躓くことがないようにするとか。NoSQLじゃなくて、まずはそのままRDBMSを使うというのもそうですし、一気にシステムを移すのではなく、移行先のクラウドと従来のオンプレミスの連携基盤をまず固めておくこともよいことだと思います。

結局、クラウドに移すことが難しい部分が出てきて、システムの一部をオンプレミス側に残して連携する、みたいなこともあるとおもうので、その場合にも連携がしっかりしていれば、基本的なところで躓いて苦労するようなことは少なくなります。

「Lift」が難しければ身動きがとれないですから、クラウド化に限らず、変えたいと思ったときに最小限のスキルトランスフォーメーションで「Lift」ができるシステムや基盤に整備しておくことが大事だ、ということなのかもしれませんね。

(第3回に続く)

次回は、クラウド時代のシステム開発がテーマです。
ビジネスにかつてなく変化の速度が求められ、ITシステムにも同じく変わる速度が求められる時代になりました。

システム開発はどう変わらなければならないか、新時代の速度感を体感する方法についてなど、引き続き話を伺います。

[参考] 企業システムにおける連携基盤の重要性を解説した資料

市場調査会社により、記事で話題になった「企業システムにおける連携基盤」についてホワイトペーパーが公開されています。
クラウド時代への変化を含む、ビジネス環境の変化や続々登場する革新的なテクノロジに対して柔軟かつ迅速に適応する企業システムに必要なものとして、連携基盤の必要性が解説されています。

■ ビジネスで勝ち抜くためのシステム連携基盤構築指針
~連携基盤ツールによるサステナブル企業システム確立~

昨今の「クラウド」や「ビッグデータ」、「IoT」、「AI」といった革新的なテクノロジーの登場によってビジネス環境も大きな変化が起こっています。これらの外部環境に対して、クラウドやオンプレミスの垣根なく多数のシステムを柔軟につなぎ、経営上の意思決定に貢献する基盤構築の重要性がますます高まっています。「連携システム」を保有されている企業様は多数いらっしゃるかと思いますが、「連携基盤」といえる企業はまだ少ないのが実情です。

クラウド・コンピューティングはすでに多くの国内企業が導入している。今後、IoT、AI、FinTechなどの新しいテクノロジ/製品/サービスを活用する企業が増えることに疑問の余地はない。またこのような時代にあっては、連携基盤が極めて重要な役割を果たすことは論を俟たない。 (本文より)

ホワイトペーパーをダウンロードする

Change Location

Are you visiting HULFT.com (Japanese language) outside Japan ?
When connecting "HULFT" to Japan from overseas, please select "HULFT8".

日本国外からHULFT.com(日本語)にアクセスされようとしています。
海外から日本の「HULFT」と接続する製品をお探しの場合、「HULFT8」をお選びください。