現在、私はNTT東日本の次世代デジタル基盤システムである「Savanna」の開発や高度化に携わっています。もともと、社内では用途ごとに仮想基盤が分散していましたが、これらを効率化すべく1つにまとめていく目的でSavanna構想が誕生しました。リリースから数年で、当初の想定を大きく超えるペースでSavannaへの移行が進み、非常に大規模なシステムへと成長し、現在では東日本エリア10カ所以上の拠点に設備が設置され、NTT東日本の業務システムを搭載する200以上の社内サービスを支える共通プラットフォームとして重要な役割を果たしています。
さらに、社内向けに開発してきたSavannaの機能や仕組みをベースとして、NTT東日本では新たに社外向けのクラウドサービス「地域エッジクラウド タイプV」を2024年にリリースしています。「地域の未来を支えるソーシャルイノベーション企業」として、自治体や企業の課題解決を支援し、安心・安全かつ活力ある地域社会の実現に貢献することをめざし、システムを進化させています（図1）。
一方、システム規模の拡大に伴い、運用にかかる負荷も急増していることから、このコストをどのように抑えていくのかが課題となりました。他社のパブリッククラウドを利用するよりも安価に運用できていた自社クラウドのコスト優位性を維持していくために、ひと工夫が必要になってきたのです。
この課題への取り組みの1つに、Savannaを効率的に監視する仕組みの実現が挙げられます。多数の拠点でさまざまなシステムが稼動していると、A拠点のM装置で故障が起きたとき、具体的に何のサービスに影響が出ているのかを把握し適切に対応する負荷が増加していきます。私たちは故障個所ごとに影響が起きる範囲を可視化する仕組みを内製開発で実現しました。
このように、内製で機能を補いながら運営していくことができているというところにSavannaの強みがあると考えています。

このSavannaによる仮想基盤構想を含め、企業のプライベートクラウド基盤は順調に拡張・高度化していくものととらえていた中で、利用していた仮想化製品においてライセンス体系の見直しなど外部環境の変化が生じ、基盤コストや運営方式への影響が顕在化しました。
そこで当社では、特定の製品やベンダへの依存度を低減し、中長期的に安定した基盤運営を実現していくための選択肢を広げる観点から、マルチハイパーバイザー化に向けた研究開発や技術評価に着手しました。
当社業務への適合性の観点から、既存の基盤で提供している機能や運用ポリシーを大きく変更することなく再構成できる市中製品を探索したところ、Microsoft社製品であるHyper-Vにその可能性があったため、評価対象として選定しました。具体的な理由として、既存で調達しているハードウェア環境をそのまま利用できるカスタマイズ性の高さを持つことに加え、当社が求めている水準でのゲスト間の分離が実現できる権限設計を持っているといった背景が挙げられます。
マルチハイパーバイザー化するにあたって、それぞれのハイパーバイザーがかつて採用していた製品と同等の性能を出せるのかが不確実であったため、私たちは入念な性能評価を実施しました。RHELやWindows Serverなど使用頻度の高いOSでの性能評価として既定の検査コマンドを実行し、同等水準の性能を確認しました。特にストレージに関しては高い性能が求められる要件もあり懸念していましたが、R/W比率、ブロックサイズ、その他弊社環境で想定しているいくつかの条件において、多少の差が見られる組み合わせもありましたが、ハイパーバイザーごとに顕著な差異はなく、ストレージについても問題ないことを確認しました（図2）。
このように、マルチハイパーバイザー化の研究開発はおおむね順調に進んできたといえますが、すべてにおいてスムーズに進んできたわけではなく、苦労した点もさまざまありました。繰り返しにはなりますが、このHyper-Vに関する研究開発・技術評価で最大の肝となるテーマは、既存のサービス仕様に対し変更を加えずにいかにマルチハイパーバイザー環境を実現できるかになります。そのため、本来のHyper-V環境にはない機能を実現したいという要件が、どうしても一部のユーザから出てきてしまうのです。そういった点をどうチューニングしながら実現していくのかを考えていく必要がありました。
1つの例が専用フェイルオーバーホストという機能になります。仮想基盤を構成するハイパーバイザーが物理的に故障した際、仮想マシンが異なるハイパーバイザー上で速やかに再起動される仕組みを利用していますが、この機能を仮想基盤の負荷状況にかかわらず確実に成功させるために必要な仕組みとして、これまで特定の物理サーバをフェイルオーバー専用の領域として動作させる専用フェイルオーバーホストという機能を利用していました。しかし、Hyper-Vにはそのような機能が標準にはなく、専用フェイルオーバーホストと同じような動きをすることができるように、Hyper-Vの持つ機能を組み合わせ、実装上の工夫を行うことで既存環境と同等の機能を提供できるよう設計しました。
さらに、ゲストシステムの使っているソフトウェアによっては、Hyper-V上でサポート外のものもあり、ソフトウェアベンダごとにHyper-V環境のサポートを依頼するケースや、NTT研究所のOSS（Open Source Software）センタの協力を受けながら、対応方法を検討するようなケース、さらに、それでも難しいような製品は別の製品に切り替えるなどの対応を行いました。
このようにして、各種の課題に対応しながらマルチハイパーバイザー化に向けた研究開発を進め、約1年という短期間で、技術評価として一定の成果を取りまとめることができました。

Hyper-Vを利用した環境は画面UI（User Interface）や権限管理、仮想インフラ管理性や操作性において、改善余地が残る部分があると感じています。ここに関して、今後は図3に示すとおり、Azure Arcの管理機能を活用しながら、UIや管理機能の機能拡張をめざしていく方針としました。
Azure ArcはHyper-Vと同様、Microsoft社のサポートが受けられるとともに、シンプルで安定した廉価なIaaSというSavannaの強みを活かしつつ、Azureの高度な機能も活用することができる当社のコンセプトに合うサービスであることから、現時点ではこのサービスを利用していくことが機能拡張の研究開発に有効な選択肢の1つであると考えています。最近では、Hyper-V基盤が抱えている管理性の課題をAzureベースの機能で克服できる可能性を確認できつつあり、このサービスを活用してユーザからみたマルチハイパーバイザーの使用感をそろえていく研究開発を今後さらに加速していきます。

当社は社会インフラを支える通信事業者として、長年にわたり大規模かつ高信頼な設備を運用してきました。その中で培ってきた知見や運用ノウハウを踏まえ、社内の重要システムを支える基盤についても、過度に外部環境へ依存することなく、自らがコントロール可能な環境で安定性と継続性を確保していくことが重要であると考えます。
特に業務の根幹を支えるシステムについては、長期にわたり安定的に稼働できる設計・運用が求められることから、信頼性・可用性を確保しつつ将来にわたって持続可能なコスト構造となるよう、基盤の整備や運用の高度化を進めていく必要があります。
一方で、仮想化基盤を取り巻く外部環境は変化しており、従来デファクトスタンダードとされてきた特定製品への依存は、調達や運用の観点でリスクと再認識されるようになりました。こうした状況を踏まえ、当社では特定の製品やベンダへの依存度を適切にコントロールし、複数の選択肢を持てるレジリエントな基盤アーキテクチャを実現するための研究開発・技術評価を継続的に進めています。
大規模なシステムには、さまざまな製品が搭載され、多様なベンダが存在しています。そのため、M＆Aなど外的な影響を受ける可能性を前提に、突発的な変化にも対応できる柔軟性を備えることが重要です。私たちが心掛けるべきことは、新しい技術をしなやかにカスタマイズして上手にフィットさせ、必要に応じてスムーズに取り込めるよう、日頃からレジリエントな筋力を鍛え続けていくことではないでしょうか。

今後は、「マルチベンダ化」が1つの大きなテーマになっていくと思います。仮想化基盤を取り巻く外部環境の変化を受け、仮想化レイヤにおけるハイパーバイザーはマルチ化が進みつつあり、今後、ここでの技術的な工夫が重要な課題になっていくと考えられます。マルチベンダ化により、さまざまな会社の製品を同時に使っていくとなると、画面や手順も異なり、稼働負荷が倍になるといった課題は昔からよく聞かれる話ですが、一朝一夕には解決へ至らない困難な問題の1つです。
ただ、昨今、AI（人工知能）や自動化といった技術は急スピードに進歩してきているため、私たちとしてはこの製品ごとの差分をかなり吸収しやすくなってきたなと感じ始めています。AIや自動化の技術を活用し、トータルで整合を図りながら導入を検討し、現実的な運用を実践していくことが、今後非常に重要なテーマになっていくと思います。
私たちのシステムでは、ちょうど大規模刷新のタイミングが到来していることから、ここでAI技術を積極的に活用することを検討しています。基盤システムの中で採取されるさまざまなログから故障個所を特定・分析し、自動での動作テストを行うといった、1歩進んだ世界観にチャレンジすることでマルチベンダ化によって、増えていってしまう製品差分や問題解決のナレッジをAIに極力オフロードしていけると理想的ですね。
今後、AzureのSREエージェント等、AI関連技術の適用性を引き続き技術評価し、段階的に導入を見据えて設計・検証を進めていきます。オペレータの復旧作業を支援するレコメンドの提示や、障害発生時の周知・1次対応に関する運用手順の自動化（支援）など、AIを活用した運用高度化の取り組みを進め、運用負荷の低減と復旧の迅速化に向けて次世代デジタル基盤を磨き上げていきます。

個人的には、自ら触って試すことをとても重視しています。実際に構築し、設定し、動かしてみて、初めて見えてくる問題点も多いと実感しており、その積み重ねがエンジニアとして引き出しの数を増やしてくれていると感じています。マニュアルを読んだだけで多くを分かった気になりがちですが、例えば、冷蔵庫のマニュアルだけ見ていても、冷蔵庫の使い勝手はなかなか分からず、実際に家電量販店へ行き、冷蔵庫を触って、扉の開き方がどうであるとか、ドレッシングはここに入るものなのかといった実物を触って初めて気付くことがあると思います。
システム開発も同じで、自分の目で見て触って組み上げていかないと、その善し悪しが全く分からないと自分は考えています。そういった意味では、たとえ業務には直接関係なくても、最近話題になっているOSSやサービスなど自分が気になっている対象は直接触り、動かしてみることを意識的に取り組んでいます。明確に役立つシーンはさほどなくても、プラモデルを遊び心でつくってみる程度の感覚で触ってみて、いろいろ苦労しながらも実際に動かせたら楽しいですし、偶然、将来の業務へもつながったらラッキー程度の軽い感覚で自分が興味あるものをさまざま触り、技術の幅を広げていくことはエンジニアとして重要な営みであると思います。

私のチームには4人のメンバーがいます。人によって技術レベルに差がある場合は、なるべくそれぞれの人が食べられる最大サイズの大きさにタスクを切り出して渡し、実際に手を動かしてもらうことをチームの方針としています。特に若手のメンバーには前述のとおり、実機を積極的に触り動かしてもらっています。私が所属している先端テクノロジー部 クラウドサーバ技術部門には、私と同じように、自分の手で実機を触ることが好きなメンバーが集まっていますので、その調子でどんどん進めていこうと背中を押しています。
また週に1回、部門メンバーが集まり、「私はこんなことをやってみたので、その内容を聞いてください」といった個人発表の時間を設けており、「自分が触ってみたらこんな感じで、こういったことに役立った」と全メンバーへ情報を共有しています。そういった営みの中では、実際に物をつくっていく感覚や、ほかの人にその良さを伝えていく練習も兼ねているため、これを継続し少しずつ積み重ねながら、各人のスキルを伸ばしていければと思っています。
プライベートクラウドは、将来にわたっても必須の技術領域といえ、このノウハウを脈々と受け継いでいかなくてはなりません。未来の世の変化に対して柔軟に対応していけるメンバーを組織的にどう育てていくのか、その道筋をいかに引いていくかが、私の次のミッションになっていくのではないかと思っています。
事業会社で研究開発をしていると、さまざまな事業上の制約や非エンジニアリング的な調整が膨大に発生してしまいます。若手の将来について考えたときに、その調整業務を経験していくこと自体良いことではあるので、そのような状況下においても、いかに必要となる技術要素を確実に効率良く獲得し、成長していける環境をつくっていけるかが重要です。外部との調整業務と、コア技術育成のための中核技術の深掘り業務とを整理し、技術者が育っていける持続可能な組織体制や育成計画を策定していくことが、中長期的に大変重要なテーマであると思います。放っておくと調整業務が多くなりがちであるため、そこをいかにうまくコントロールしてあげるかが、今後の仕組みの持続性において肝になっていきます。
NTTグループの人事制度は変わり、スペシャリストコース（SG）という枠組みが新設されました。またNTT東日本ではITの即戦力としてデジタル枠採用で入社した優秀な若手もおり、私のチームや周囲のチームでも活躍しています。ちなみに私は他社でシステム運用やサービス設計に10数年間携わった後、2023年に転職してきたエンジニアです。こういった専門スキルを持った人材も、徐々にではありますが活躍できる環境が当社においても整いつつあります。高いスキルを持った若手たちが安心して技術のコア部を一層攻めてもらえるよう人事環境や組織環境を整備していきたいと考えています。

事業会社の研究開発という目線にはなりますが、コアとなる基礎技術や製品への理解は大前提にあり、それらの勉強はもちろん必須です。しかし、それだけではある水準以上を越えることができません。技術にバックボーンのある専門家として、技術知識が十分ある人に対してはもちろんのこと、仮にほとんどない人たちに対しても十分理解してもらえるようなコミュニケーション力をつけていきましょう。これは大変重要なスキルなのです。
技術側ではない他の組織との交渉や、調整の綱引きを行っていく中で、最終的に技術的に正しいといえる範囲内に着地できるようトータルコーディネートしていく力は、技術開発者としてとても大切なことだと思っています。これは経営層に対しての説明においても同様です。自分自身でもこれについては日々至らない部分であると痛感するところではありますが、それらを含めて開発者の技術力であると固く思っています。
そうしたスキルは筋肉のようなもので、日々トレーニングしていかないと絶対強くなっていきませんし、逆にたゆまず筋トレを続けていけば着実に強くなるものであると信じていますので、「実機を触って楽しかったです。勉強になりました」では終わらずに、「それが、どういったときに、どういう背景で、どのように役立つのか」をしっかり読み解き、理解したうえで、さまざまなバックボーンを持った人たちにも分かるように伝えてほしいです。例えば、チームメンバーや上司に自分がトライしてきたことを日頃からプレゼンテーションし、具体的にアウトプットしていくことが、この筋肉をつけていくための第一歩であり、とても重要な要素であると考えます。このような営みは地味でコツコツとした作業にはなりますが、大きなプロジェクトにおいて力を発揮する源泉になりますから、積み重ねていただきたいと思っています。