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

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

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

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

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

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

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

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

あー、ありましたね。

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

実際僕も、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には、要望に応えるスピードが求められている

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

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