コンテナ、マイクロサービスは何のために使うのか？――経営層に贈る「DX推進の2要件」：特集：日本型デジタルトランスフォーメーション成功への道（5）（2/3 ページ）

[文:斎藤公二／インタビュー・構成:内野宏信／＠IT]

コンテナとマイクロサービスの本当の価値とは？

──　メディアの責任も大きいと思いますが、「DX」や「デジタル推進室」などビッグワードばかりが注目され、本当に必要なことが置き去りにされている傾向をあらためて感じますね。DX推進の手段として「コンテナ」や「マイクロサービス」が注目を集めていますが、これらの理解に問題があるケースも多いと思います。

安田氏　誤解は依然として多いと思いますね。よくある誤解の1つは、「コンテナは仮想化の置き換えである」というもの。物理サーバを仮想化して同一基盤上に集約することで、ハードウェアの導入・運用コストを削減できる。これと同様に「仮想環境をコンテナ環境に移行するとコスト削減が可能なのでは」と考えてしまう。結果として集約化されることにもなりますが、そもそもコンテナはハードウェアを削減する手段ではありませんし、仮想環境をコンテナに移行してもコストは下がりません。

　マイクロサービスも同様です。周知の通り、マイクロサービスは機能や役割ごとに分けた小さな単位で1つのシステムを構成する考え方です。メリットの1つとして、システム改修の際に影響範囲を限定できるため、テスト工数を削減できることがあります。ただ全体のコストを削減できるわけではないので、コスト削減のためにマイクロサービスを導入するというのは間違いです。

──　そもそも活用目的が違うのですから当然ですね。ここでは細かな定義や機能は置いておくとして、経営者はコンテナやマイクロサービスをどう理解しておけばよいとお考えですか？

安田氏　コンテナについては特長や正しいメリットに対する理解はかなり進んだと感じています。コンテナを使って開発を行うことで、同じアプリケーションをどのような環境でも同じように稼働させることができる。変更も比較的容易になり、新しい機能を短期間でどんどん追加したり、改善したりできるようになる。ポイントは「開発サイクルを高速に、継続的に回すことができる」という点です。つまり前述のように、変化が激しい環境の中で、売上、利益、キャッシュフローといった「アプリケーションの成果」を継続的に改善しやすくなる。

　一方、マイクロサービスについては用語の理解や使い方に、まだまだギャップがあると感じます。例えば、「レガシーシステムにマイクロサービスを適用すれば、ポンッとモダナイズされる」と考えている方も多い。マイクロサービスが実現できれば、機能の追加・改善が容易になるため、アプリケーション、すなわちビジネスの開発・改善サイクルをスピーディーかつ継続的に回せるようになる。コスト削減ではなく、移り変わる市場ニーズに追従することで、着実に収益を増やしていくための手段の一つなんです。

新規開発は全てコンテナに。そこで迷う必要はない

─―　コスト削減を第一義に考えてきた従来のスタンスのまま受け止めるから誤解が生じるのかもしれませんね。特に一般的な企業の情シスは、「コスト削減せよ、システムを止めるな」という守りの姿勢がメインミッションで、「ビジネスをどう変えるか」といった攻めの視点はほぼなかったわけですから。そういう理解の経営層もいまだに多いと思います。

安田氏　そうですね。特に経営層の方は情シスやITに対する理解を改めるべきだと思います。コンテナやマイクロサービスについても、まずは「サービス、すなわちビジネスを推進するためのスキーム、体制、技術領域などのこと」といったざっくりとした理解でいいと思います。「何のためにコンテナやマイクロサービスを導入するのか。それはユーザーが求めている機能を追加／改善して、付加価値を向上させるためだ」という理解を持つことが大切です。

　そうすれば、コンテナやマイクロサービスが持つポータビリティ性や変更容易性、集約性、開発効率性、拡張性といった本来のメリットを自ずと生かせるようになるはずです。ただ「使ってみろ」というのではなく、技術に対する一定の理解と明確な目的意識の下で、デジタル推進室の取り組みをリードし、コミットする必要があるわけです。

──　一方で、「ツールありき」ではいけないというお話があったように、コンテナやマイクロサービスを導入しないという選択肢も、当然あるわけですよね。

安田氏　もちろんです。例えば、安定して動いていて変更要求も少ない、特に課題もないシステムを無理やりマイクロサービス化する必要はありません。コスト削減もできませんしマイクロサービスのメリットも生かせません。一方で、DXを推進するための新しいシステムなら、コンテナやマイクロサービスを導入しない理由はないと考えます。というより、新しいサービスを開発する場合、コンテナ以外は考えられないと言ってもいい。こう表現すると前段の話と矛盾するようですが、あくまで「目的にかなっているから」です。

　特に新規開発において、古い技術をあえて採用する意義はないと考えます。コンテナはセキュリティ面でやや遅れがありましたが、それを補完する仕組みも次々と出てきていますから、あえて仮想マシンを利用する理由はありません。コンテナは仮想マシンでもクラウドでも物理サーバでも動きます。連携するシステム全体をマイクロサービスで構築することも容易です。つまり経営環境変化に対し、ビジネスを止めることなく、最小のコスト、工数、リスクで柔軟に対応できる。これからのアプリケーション開発は、少なくとも新規のものについては、全てコンテナベースになっていくと考えます。

マイクロサービスを正しく使うために、経営と現場は何をすべきか

──　ではコンテナやマイクロサービスにそうした理解を持つ一方で、実際に組織を率いる際にはどのような体制を作るべきでしょうか？

安田氏　単機能のサービスを組み合わせて、1つのシステムを構成するのがマイクロサービスアーキテクチャですから、まず各機能をどのような粒度、種類で切り分けるかという問題があります。その上で、機能（サービス）ごとにチームを構成するのが一般的です。

　こうした機能ごとのチーム構成でポイントとなるのは、各チームに対する権限付与です。責任範囲を明確化し、「ここまではあなたたちが責任を持ち、ここから先はわれわれが責任を持つ」といった理解をチームに浸透させる必要があります。こうした体制づくりは、経営サイドも積極的に協力しなければ作ることができません。

　繰り返しになりますが、一番大切なのは「このシステムで何を実現したいのか」、ビジネスの目的を明確化し、現場との共通認識を持つことです。これによって取り組み方はまったく違ってきます。ゴールが不明瞭な上、何の権限もないようでは、現場層にとって取り組みの推進が難しいだけではなく、精神的にもつらいものがあります。一方で、ゴールに対する共通認識がないまま権限だけを渡されても「何すりゃいいの」となり、やはりつらいものがある。ゴールと達成手段を明確化し、共有する――この2つは経営にも現場層にも求められます。

──　「ゴールと達成手段を明確化し、共有する」ことが不可欠というのは、いまだに誤解が多い「働き方改革」の問題と似ていますね。「残業削減」など、働き方改革を推進するための手段の話に終始し、目的に目が向かわず取り組みが迷走してしまう。

安田氏　共通点はあるかもしれません。例えば、スマートフォンというツールを導入するだけで働き方が変わるわけではなく、スマートフォンを使ってどう働き、どういう成果を狙うのかがポイントですから。アジャイル開発やDevOpsを活用したプロジェクトでも、経営層とのコミュニケーションについては技術的な各論の話より、前述したビジネス観点での評価指標について話すことが重要だと思います。技術的な理解が必要なことが生じたら、その都度、経営層は理解するよう努め、現場層はそれを支援すればいいと思います。