一番手に登壇したのは、2009年にNTTデータに入社し、現在AWS/Azureなどを用いた開発に従事している三原 拓也氏。まずは、今回の登壇者全員が所属している事業部について、次のように語った。

「私たちはモバイルビジネス事業部に所属していて、この部名を略して“モバビジ”と呼び、主に通信キャリアを相手にした実案件を手がけています。そのため、社内では実案件で経験を積んだ技術力の高いエンジニアが多いと言われています。ひと昔前まではAWSの案件がメインでしたが、最近はAzureなどの案件も増えてきて、これらに対応できるようマルチクラウド対応化も進めています。

実案件を手がける一方で、研修を実施したり、資格取得を積極的に推進している他、AWS re:Inventにメンバーを派遣するなど、人を育てるための様々な施策も忘れてはいません。また、大規模案件が多くなってくると生産性が上がらないため、独自のプロビジョニングツールを使用しています。さらに最近は、ContainerとかServerlessのアーキテクチャが増えてきていることから、どのようなデファクトが最適なのかといったことや、Amazon EKSを用いた技術検証など、施策と実案件を同時に回転させることに全組織で取り組んでいます」

現在、クラウド市場はAWSが約50%という圧倒的なシェアを占め、その後にMicrosoft、Google、IBMなどが続き、それぞれのシェアが徐々に伸びてきている状況。将来的には、これら上位のクラウドが市場を寡占していくことが予想される。

「各クラウドを私たちがどのような観点で使い分けているのかというと、まずはAWSですが、これはもうデファクトスタンダードです。どんなシステムを作る時も、AWSから考えることが多いです。

次にAzure。最近増えているのがWindows Serverの2008EoSL対応で、これは非常に需要があります。Azureでは、Windowsのライセンスをそのまま取得できるとか、3年間無料のセキュリティパッチ提供を宣伝していますので、オンプレミスでさほど更新頻度がないシステムを、Azureにそのままマイグレーションするという案件はものすごく増えているのが現状です。あとは、Office365を使いたいというお客様には、かなりニーズがあるでしょう。

GCPに関しては、それほど案件がないというのが正直なところです。それは、AWSやAzureがユーザー企業にトップ営業をかけるため、お客様が指定してくることが多いためだと私たちは考えています。GCPの場合は、エンジニア自体がこの機能が良いから使いたいという形でボトムアップしているケースが多く、大抵、内製されてしまうため、当社のようなSIerにはなかなか降りてこないのかもしれません」

モバイルビジネス事業部では、複数のクラウドを組み合わせる案件が出てきていると話す三原氏。それは、具体的にどんな案件なのだろうか。

「私自身、マルチクラウドには2種類あると考えていて、ひとつ目は1企業が複数のクラウドを使用しているものの、それぞれのシステムは一つのクラウドで構成されているケース。これは、開発者と運用者が違い、SLAも別です。

その一方で、最近増えてきているのが、特定のサービスだけを別のクラウド機能を使用しているというケース。開発者と運用者が同一で、この一つのシステムでSLAが定義されているのが特徴です。こうしたマルチクラウドを使う場合、注意しなくてはならないのがサポートやセキュリティ面です。また、対抗側のクラウドを意識した運用設計も重要になります。コンソールログインも別になり結構煩わしいので、マルチクラウド構成にする時は後者を選ぶべきです」

AWSだけを使いこなす時代から、複数のクラウドを使いこなすことが重要になりつつある今、それができるエンジニアの市場価値は高まってきている。

「クラウドごとに違いはありますが、繋がるところもたくさんあります。ひとつのクラウドを使いこなせれば、別のクラウドを学習することは、それほど難しくはないと思います」

最後に三原氏は、参加者の背中を押すような言葉を投げかけ、自身の発表を終えた。

二番手に登壇したのは、2014年の入社以来、AWSを用いた大規模システム開発に携わっている上村 岳氏。生産性を向上させるため、NTTデータで実施している標準化への取り組みについて説明した。

「お客様がクラウドを利用したいという場合、第一に考えるべきことは、その目的とコスト。それと同様にアジリティの高いシステムを作り、事業スピードを上げていくことを期待しているということを日々感じています。とりあえず仮想サーバーを使えばいいというところから始めてしまうと、後々使いにくいと感じ、結局オンプレミスに戻して事業スピードにも変化が起こらないという結果になりがちです。特に大規模なシステムになると、設定パラメータだけではなく、作業時間が増えたり、構築や運用の工数やコストまで大きくなってしまいます。

こういった状況に陥らないためには、クラウドネイティブな思想を最初から取り入れることが重要。これは、一般的に提供されているクラウドのサービスの仕様を前提に、その特性や利点を最大限に生かす形で構築するといった思想です。私たちは、この思想に“障害を前提としたデザイン” “疎結合なアーキテクチャ” “ソフトウエア開発のライフサイクルの効率化の方法”の3つをプラスして、『Infrastructure as Code × CI/CD』　というキーワードにしています」

Infrastructure as Code（以下IaC）とは、コード→リポジトリ→ビルド→テスト→デプロイしていくソフトウエア開発のプロセスを、インフラストラクチャの構築に適応していくことを指す。

「IaCのメリットは３つあり、ひとつ目は手動作業をコード化・自動化することで、オペレーション工数や工期、コストを削減できること。二つ目はインフラ構成をコード化することでバージョン管理ができ、第三者によるレビューも可能になるといった意味で品質向上に繋がること。三つ目は、一度記述したコードを別の場所で再利用できることです。

ただ、デメリットもあります。IaCへの理解がないまま採用してしまうと、逆にゼロからコード化・自動化すること自体に工数や時間がかかるだけではなく、そのツールを使うための学習コストも増大します。また、自動化と手動作業が混在する場合作業方法が多くなり、品質悪化に繋がる場合も。IaCのメリットを享受するためには、実現方式の標準化が必要です」

その理由は、前任者と同じ手順でサーバーを構築したのに、違うパラメータのものになった。コードを書くだけで簡単にできるからと、どんどん基盤を構築していくと管理しきれなくなってしまい問題が発生するなど、様々なトラブルが生じるためだ。

「IaCによる成果物の信頼度を上げていくためには、CI/CDのパイプラインをしっかり回していくことが大事です。そのパイプラインに求められることのひとつ目は、標準化。二つ目は、全体の自動化です。そこで、私たちはこれを実現するために、独自のAWS統合開発ソリューションアセンブリ（CiSA）を開発しました」

CiSAとは、プロビジョニングとデプロイ、オペレーションの３つのサービスを連携させて、設定テンプレートからインフラストラクチャの構築はもとより、その上に載せるOSやミドルウエア、アプリケーションの設定から運用まで標準化するソリューションチェーンだ。

「CiSAのひとつ目は設計情報から必要なクラウドリソースの調達、ブートストラップするだけではなく、クラウドリソースの固定化、環境差分情報を吸収する機能を持つプロビジョニングのレイヤーサービス、CiSA Provi。二つ目が仮想ホストに対してOS層以上の設定やミドルウエア、アプリケーションのデプロイを実現する機能を持つCiSA Deploy。三つ目が、実際に構築した環境を運用していくための機能を果たすCiSA Viewです。

CI/CDの連動においては、リリースレポジトリ以降のインスタンスのプロビジョニング、ソフトウエアのコンフィグレーション、アプリケーションのデプロイメントまでをCiSAで実現しています」

上村氏は最後にまとめの言葉を述べ、次の登壇者に引き継いだ。

三番手は、2012年よりNTTデータにて主にAWSを用いたシステム開発に従事している齋木 孝宣氏。近年ではSRE Teamを主導し、システムの非機能改善にも注力している。6種類のAWS認定資格も保有する齋木氏が、実案件における技術選定のポイントについて持論を展開した。

「R&Dと実案件の違いは、2点あります。ひとつは顧客がいること。二つ目は保守や運用が必ずあることです。また、システムのライフサイクルを考えると、開発より運用のほうがずっと長くなります。その際、技術選定で考えなくてはいけないことは、単に流行だけで判断しないということです。

例えば、ブログなどで『今の時代は、この技術！』といったコメントを目にすることが多いと思いますが、それは、技術者のただの自己満足に過ぎないことも。理想だけではなく、しっかり現実を見て物事を判断することが大切です。そのためにも、お客様が本当に望んだものとはまったく違うシステムを設計してしまってはいないか、自問自答する必要があります」

この考えを踏まえて齋木氏が技術選定の際に心がけていることは、サービスやチームにマッチするかどうかだという。

「今のサービスに、その技術が生かせるのか、既存の課題を解決するのか、顧客業務の向上に繋がるのか。さらに運用まで意識して、チームメンバーが使いこなせるのか、後で負担にならないかといったことまで考えます。自分がプロジェクトから抜けたとたんに、回らなくなるようでは困りますから」

齋木氏が2年ほど前に関わったAWSをマルチリージョンで展開している大規模グローバルシステムでは、Containerのオペレーションツールに何を使うのか検討。その時、KubernetesとAmazon ECSの名が挙がり、最終的に選んだのは、Amazon ECSだった。なぜなら、Kubernetesよりも学習効果が高く、データベースのマネージドサービスも優れていて、困った時にも使えると判断したからだ。

受注開発における生存戦略では、人柱になる必要はなく、永遠の2番手集団を目指すことが大切だと話す齋木氏。ただし、周回遅れにはならず、きちんとキャッチアップしながらといった条件付きで。

「多くのSI現場は“人月”の世界で動いているので、受託案件には必ず工数見積もりがあります。想定外にコストがかかったり、実工数が上振れしてしまうと赤字プロジェクトに転落してしまいます。また、使ったことのない技術を精緻に見積もることはできません。

そこで、これからの技術者のスキルとして必要になるのが、すぐに取り組むべきか、スルーしたほうがいいのかといった目利き力です。もうひとつが、PoC力。実際に手を動かして検証してみることが大事です。

世の中のクラウドネイティブランドスケープだけを見ても、さらに複雑になっていて、新しいツールもどんどん出てきています。CI/CDだけ見ても、30種類以上のラインナップがあります。

時間が限られている中で、実案件でどうするかといった質問への回答は、今のところありません。でも、様子見しているだけでは前に進めないので、新しい技術やツールの採用判断基準は、多くの案件に適応可能であることが第一。また、特定のプラットフォームでしか動かないツールには、極力依存しないようにしています」

「これからは5GやEdge Computingの時代が到来すると言われていて、しかも、すぐ側まで近づいています。今後は遅延との戦いが激化し、マルチプラットフォームを活用する案件が増加していくでしょう。そのために、どのようなところにアンテナ感度を高めておくべきかと言うと、CDNをウォッチしておくこと。そして、HTTP/3に関する知見も高めておく必要があります。あとは、ContainerとかServerlessとかも。

ちなみに私が好んで構築しているのは、このスライドようなネットワーク。注目していただきたいのは、右下の北米リージョンとかオレゴンリージョンを使用したPoC環境です。東京リージョンに来ていない新サービスや新機能をいち早く検証可能で、料金も安いなどのメリットがあります」

齋木氏は、地に足が付いた開発をするための学びの場がNTTデータには豊富にあり、これらを利用して、各自がそれぞれ知見やスキルを高めていることも、最後に紹介した。

勉強会のトリを務めたのは、2014年にNTTデータに入社し、AWSによるデータ分析アプリ開発や、AzureでもDMP基盤開発に携わってきた真野 洋平氏。自身が参画した実案件に基づき、NTTデータのモバイルビジネス事業部におけるマルチクラウドの取り組みなどについて語った。

「事業部内でマルチクラウド対応を少しずつ進めていますが、そのポイントのひとつはクラウドサービスの深堀りです。具体的には機能・非機能の観点でサービスを検証してノウハウを蓄積することで、サービスの選択肢幅を広げています。もうひとつは、横断的なクラウドエンジニアの配置。1案件の中では技術やノウハウが閉じがちになってしまうため、複数のプロジェクトを横断的に見て、情報共有やアドバイスができるエンジニアをアサインする取り組みを行っています。

実際、クラウドサービスの深堀りに関しては、例えば、いろいろな種類のストレージやサービスの中でどれが最適なのかといった検証を実施。横断的クラウドエンジニアの配置においては、マルチクラウドの知識や技術を持つエンジニアを育成するため、受託案件の中でAWSやAzureの認証資格を取得できたり、外部研修を受講できる体制になっています。また、全社的にも一人ひとりにセミナーなどに参加できるセルフ・イノベーションタイムが与えられているほか、クラウドベンダー各社と連携して、社内外でクラウドサービスの勉強会なども頻繁に開催しています」

あくまでもこれは、自身が手がけてきた案件を通して感じた個人的な見解としながらも、AWS/Azureの強みと弱みについて真野氏は次のように述べた。

「自身がAzureを扱っている感触としては、AWSに比較すると、まだまだ成熟していない印象です。カタログスペック的には、サービスの種類はAWSと同じものが揃っているように見えますが、細かなところでは機能がAWSに追い付いていません。特にPaaS/SaaSの多用を考えている場合は、Azure提案前に詳細に調査すべきです。

一方で、Office365ユーザーとAzure連携が必須な案件であれば、Azureに一考の余地はあります。既存のADアカウントをAzureサービスに連携して認証利用できる点（AAD連携）は、Azureならではの強みです。ただ、AAD連携に対応していないサービスもあるため、これも事前に確認すべきです」

2019年9月にAzure Private Linkがプレビュー公開され、PaaSに対するプライベート接続が可能になった。これに関して、真野氏はどのように感じているのだろうか。

「DBでは、Azure SQL Databaseがパブリックアクセスをベースとしているため、どうしてもパブリックIPが付与され、アクセス元のIPが制御できないという課題がありました。アクセス制限を設けるために、VNet（プライベートネットワーク）上にローンチ可能なSQL MI（マネージドインスタンス）を利用したのですが、こちらもデータロードが遅いとか、最大容量が少ないなどの課題が発生。そこで、Azure Databricksというサービスを取り入れることを検討中です」

真野氏が携わっているこのシステムにおいては、SQL MIがDMPサービスのボトルネックになっていた。Microsoft社およびお客様と議論し、スライドにあるようにSQL MIに頼らないアーキテクチャに変えていくことを検討している。

「現在、AWSとAzureの案件はあるのですが、それ以外の受注はほぼ皆無です。今後はGCPやOracle Cloudといったその他のクラウド案件を増やしていきたいと考えています。また、通常の案件内では、どうしてもシステムに関連したサービス検証に片寄ってしまうため、新サービスも検証できるよう、人と時間を確保していく計画です。これらの取り組みをするために必要な人財は短期間で増やせないため、勉強会や認定資格取得、アサイン案件の転換などを通して、横断的に案件を見ることができるマルチクラウドエンジニアを育てていきたいと考えています」

マルチクラウド拡大へ向けた取り組みについて真野氏がこのように語り、勉強会は幕を閉じた。