SOMPOの実例に学ぶ、大企業がアジャイル／スクラム、マイクロサービス、コンテナを導入する際の最適解：エンタープライズの特性を踏まえたスクラムのアレンジは正義（2/2 ページ）

[柴田克己，＠IT]

「マイクロサービス」か「モノリス」かは現実を踏まえて判断

　続いてのワードは「マイクロサービス」アーキテクチャだ。「単一の大きな機能」を持った旧来の「モノリス型」アーキテクチャと対義的に使われ、「複数の独立した機能を組み合わせることで、1つの処理を実現するアーキテクチャ」とされる。

「モノリス」と「マイクロサービス」（西野氏の講演資料から引用）

　「マイクロサービス」と「モノリス」についても、それぞれにメリットとデメリットがある。「モノリス」は、機能が「一枚岩」となっているが故に、一部の変更が全体に影響を与えてしまうため、修正に手間がかかると同時に、拡張性や可用性の面で課題を抱えがちとされる。その点、「マイクロサービス」では、全体を構成する個々の機能が独立しているため、保守性、拡張性、可用性、再利用性といった面でのメリットは大きいとされている。

　一方で、「マイクロサービス」は、アーキテクチャの構造上、通信が多く発生するため、処理のパフォーマンス面では「モノリス」と比較して不利であり、トランザクション保証も難しい。加えて、開発や運用のノウハウを組織として共有したり、ユーザー体験の一貫性を維持しつつシステムを発展させていったりしたい場合には「モノリス」の方がシンプルに行えるといった状況もある。

　両者の比較に向いた一例として挙げられたのが、以下の事例だ。Sprintチームでは、あるWebアプリを開発する際に、「ユーザーが入力した郵便番号から住所を取得する」機能を、マイクロサービス化（このケースでは内部公開API化）するか、モノリス化（このケースでは共通ライブラリ化）するかについて議論を行ったという。

　マイクロサービス化した場合のメリットとしては「同じ機能が必要な他案件での流用が可能」というものがある。一方、モノリス化した場合には、後に個別変更が発生した場合でも「変更の影響が他の案件に及ばない」という点がメリットだ。Sprintチームでは、それぞれの「案件横断管理が必要」（マイクロサービス）、「全体の入れ替えが起こった場合のコスト考慮や枝分かれの管理が必要」（モノリス）といったデメリットについても同時に考慮した上で「内部公開API化はしない」という結論を出したという。ただし、他案件で同じ機能が必要になった場合には、流用による個別APIの作成を認め、将来的には共通化も視野に入れるという条件だ。

住所取得APIマイクロサービス化？（西野氏の講演資料から引用）

　「マイクロサービスとモノリス、それぞれのメリットとデメリットを把握した上で『体制上、利点を生かせるか』『案件全体での需要があるのか』といった、現実を踏まえた総合判断をすることがポイント。検討に当たっては、切り分けの境界設定ミスに注意し、場合によっては、初めはモノリスで作り、後に必要が出てきた段階でマイクロサービス化することを視野に入れるのも良い方法だと思う」（西野氏）

開発とデプロイの敏しょう性を一気に高める「コンテナ」技術

　DockerやKubernetesの登場によって、一気に注目されている「コンテナ」関連の技術。エンタープライズの領域で、ここ20年ほどの間に普及と進化が続く「サーバ仮想化」の領域よりも、さらに上位のレイヤーでアプリケーションの動作環境をコンパクトにパッケージ化することで、開発やデプロイのアジリティを高めることができる技術群だ。西野氏はコンテナ技術のメリットとして「軽さ」「可搬性の高さ」「環境のフリーズドライによる状態再現の容易さ」の3つを挙げた。また、さらにKubernetesなどのコンテナオーケストレーションエンジンを用いることで、アクセス状況に合わせたコンテナのオートスケーリングのような自動管理も行えるようになるという。

　デジタル戦略部では、コンテナのテクノロジーを「本番環境の一部」と「開発用ローカル環境」の双方で採用している。本番環境への導入が「一部」とされている理由としては、現状のアクセス状況においては「オートスケーリング」への要求がそれほど高くないことを挙げている。その一方で、ある案件で開発された資材（成果物）を、他の案件で再利用する場合などには、コンテナによる「フリーズドライ」のメリットが十分に生かされるという。「開発用ローカル環境」では、特にAWS Lambdaを使った「FaaS」（Function as a Service）開発における環境の同一化に、同じくフリーズドライを活用しているそうだ。

　「軽さや可搬性、スケーラビリティ、フリーズドライといったコンテナ技術のメリットについて、必要性や、その利点を生かせるかどうかの『要否』検討と同時に、社内にそれを実現できるスキルセットがあるかの『可否』を検討すべきだ。これらの条件の下で『適用範囲』を検討して、活用していくことを勧めたい」（西野氏）

デジタル戦略部でのコンテナの適用範囲（西野氏の講演資料から引用）

「正しい理解と使い方」によって新技術はエンタープライズでも価値を生む

　西野氏は、これら「バズワード」となっている技術の適用を検討する際のポイントとしてあらためて次のように述べた。

　「新しい技術と従来の技術のどちらにも、メリットとデメリットがあり、さらにそれらは複数の要素に分かれている。まずは、要素ごとに正確にメリットとデメリットを把握する。全ての利点に適合しなくても、その手法の利点と課題を整理した上で、プロジェクトにおいて総合的に利点が勝つようなら適用すべきだ。もし、従来手法の方がそのプロジェクトに合うようであれば、そのままにしておくべきだ」（西野氏）

　また、特に「アジャイル」や「スクラム」の適用に当たっては「教科書通りの適用にとらわれないこともポイント」とした。

　「スクラムへのアレンジには賛否があるが、私としては、エンタープライズの特性を踏まえたアレンジは正義だと考えている。ただし、アレンジの可否を検討する場合にも『アレンジした場合でも、従来手法よりメリットが大きいか』を検討することは必要」（西野氏）

　西野氏は最後に「バズワードへの向き合い方」として「バズワードがバズワードになっている理由を考える」ことを勧めた。そのワードが、どこでバズっており、バズることで「誰」が得をするのかを常に考えながら向き合うことで、「バズる理由」が理解できるようになる。理由を知ることで「バズワードに振り回されず、そのメリットを活用できるようになる」という。

　西野氏は「バズワードとなっているような手法や技術は、その特性を知った上で正しく扱えば、エンタープライズの開発にも価値のある効果をもたらす。まずは実践してみることで、自分たちにとってのベストプラクティスを生み出していきましょう」と述べて、講演を締めくくった。