特集「マイクロサービス入門」第2回目は、マイクロサービスが注目される背景と、企業がこれからマイクロサービスの導入を検討するに当たって、考えておくべきポイントをオイシックス・ラ・大地で技術顧問を務める寺田佳央氏が解説します。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
2016年に日本人で2人目となるJava Championに就任後、Javaエバンジェリストとして活動する中、2019年6月にオイシックス・ラ・大地の技術顧問に就任した寺田佳央氏が解説する。
2015年ごろからマイクロサービスアーキテクチャ(以後、マイクロサービス)という言葉がIT業界でトレンドになり、2019年の今、マイクロサービスはバズワードになっています。では、マイクロサービスは企業にとって本当に必要なのでしょうか?
結論から言えば、マイクロサービスは企業にとって重要ではありません。企業にとっては、ビジネスを成功させることが最も重要で、そこで扱われるテクノロジーや製品、どのような環境で動作させるかはさほど重要ではないはずだからです。
ここで、筆者があるお客さまから受けた問い合わせの内容を紹介します。
相談者:上司が「今後はマイクロサービスで開発をしていなければならない」と言っているのですが、どこから始めればよいでしょうか。
筆者:なぜ、上司はそのようにおっしゃっているんですか?
相談者:雑誌かイベントで、そういう情報を仕入れてきたみたいです。
筆者:なるほど。ちなみに、提供しているサービスは新機能追加や更新などが頻繁にありますか?
相談者:いえ、そんなにないと思います。
筆者:では、本当にマイクロサービス化が必要でしょうか?
相談者:……。
上記のように目的を明確にしないまま「IT業界のトレンドになっているから」という理由でマイクロサービスでの開発を検討することはとても危険だと筆者は考えています。マイクロサービス化するか否かの判断は、現状のビジネスに大きく左右されるはずだからです。どのようにビジネスを進めていきたいのか、その際どのような手法や概念を用いるとより効率的なのかを考え、改善していった結果が、マイクロサービスだった――これが正しい姿です。
「マイクロサービス入門」第2回目は今のシステム開発に求められる視点、そしてマイクロサービスが注目される背景と、マイクロサービスでの開発を進める前に知っておきたいポイントを紹介します。
海外の友人と会話した際、米国のとある銀行が「Kubernetes」でマイクロサービスを構築し、当たり前のようにサービスを提供しているという話を聞きました。
約1年半前の話でしたが、初めて聞いたときは驚きました。当時、金融機関のソフトウェアに対するイメージは、重厚長大で、構築に年月を要し、マイクロサービス化するのは最も難しい領域だと考えていたからです。しかしなぜ、金融機関がマイクロサービス化に踏み切っていたのでしょうか? それは「ビジネスにおける大きなリスク」があったからでしょう。
従来、金融機関は参入障壁の高い業界とされてきました。しかし昨今、ITを活用した革新的なFinTech企業が次々と登場しています。既存の金融機関におけるソフトウェア開発やリリースのスピードでは、こうしたFinTech企業に追い付けません。対抗するためには、開発や公開までのスピードをこれまで以上に加速させなければいけないというリスクが生まれました。
このようなビジネス上の転機は、今後どのような業種にも訪れます。上記の金融企業のように、今までソフトウェア企業ではなかった企業でさえ、今後はITを活用した新しいサービスを迅速に提供していかなければならないのです(金融企業の例は「Microservices Financial Services」で検索すると事例がたくさん出てくるので、ぜひ調べてみてください)。
さて、少し危機感をあおる内容になりましたが、極度に焦る必要もないと思います。2019年9月、筆者はサンフランシスコで開催されたとある企業のイベントに登壇してきました。「海外の企業はマイクロサービスを用いて一歩先に進んでいる」との思い込みが今まで筆者の中にあったのですが、決してそうではないのを感じました。なぜかというと、筆者のセッション参加者の多くがマイクロサービスについて詳しくなく、他のセッションでも、マイクロサービスの基礎的な内容の紹介が多かったからです。
とはいえ、それで安心するのも良くありません。今後変化が激しくなるビジネスニーズに対して、サービスを提供するまでのリードタイムを短縮させたり、デプロイ回数を増やせられる環境にしたりするなど、いち早く対応できる準備が必要です。できるところから改善を始める必要があるでしょう。
改善するために必要なのは分析です。まずしなければならないのは、自社における現在の開発工程を全て洗い出すことです。工程の洗い出しには「バリューストリームマッピング」(VSM)という手法を用いると良いでしょう。
VSMは、1つのサービスの企画から公開するまでの全行程を具体的に模造紙などに記載する手法のことです。会議の時間や、上長が承認するまでの待ち時間など、作業ではない準備時間なども含めて全て洗い出して、無駄な時間をチェックします。この結果から改善方法を検討します。国内企業でも、今まで8カ月かかっていた工数を1週間まで短縮できたという事例があります(参考PDF:NECソリューションイノベータの事例)。
開発からリリースまでのプロセス改善を考えるならば、まずはここから始めましょう。
Copyright © ITmedia, Inc. All Rights Reserved.