安定志向のNRIが変化の激しいKubernetesを推進する理由：巨大SIerのコンテナ・Kubernetes活用事例（1）（2/2 ページ）

[小林隆浩，野村総合研究所]

NRIにおける組織・開発文化の課題　Kubernetesの適用が目標とするもの

　さて、説明してきたように、NRIが得意とするプロジェクトの形態はモード1であり、大規模な開発プロジェクトであっても標準化を通じて効率的に推進し、顧客ビジネスを支える安定したシステム運用につなげてきた。その中でNRIの組織は、長い時間をかけて得意とする大規模向けの開発・運用プロセスに最適化されてきたといえるだろう。

　組織の最適化とはつまり、機能の分化である。システム開発・運用において必要な機能を、以下のように分けている。

1. Dev：アプリケーション開発
2. Infra：基盤・開発支援
3. Ops：運用・統制

　それぞれが専門技術をプロジェクトに提供することで、多数の顧客から寄せられるさまざまなリクエストに応えることが可能となっている。例えば、Infraには「ハードウェア・ソフトウェアの発注を行い自社データセンター（DC）に組み上げるチーム」や「アプリケーションの開発を効率化するフレームワークを提供するチーム」が含まれ、内部で専門領域に応じて細分化されている。

　こうした組織構成はNRIの固有のものではないが、そこには大きな課題が存在する。それが「組織間の壁」である。

組織間の壁

　Infraの担当者はアプリケーションの設計を理解せず、同様にDevの担当者はフレームワーク以下の仕組みに踏み込まないなど、本来必要なコミュニケーションが壁によって阻まれた好ましくない状況が発生し、課題となっていた。

　そうした壁を打ち壊し、NRIが得意とするモード1だけではなく、デジタルトランスフォーメーション（DX）の担い手としてモード2のプロジェクトへ積極的に取り組むために、社内でもさまざまな変革が行われている。その一つがKubernetesに代表されるクラウドネイティブ技術の適用である。クラウドネイティブ技術の活用で、アプリケーション開発者はよりパワフルになり、運用は効率化され、結果として壁を取り除かれた組織全体が活力を取り戻す。そうしたゴールを目指し、各プロジェクトの模索が続いている。

　今後の連載各回のテーマを、バイモーダルにおけるプロジェクトの分類、そしてプロジェクト推進体制の違いで生じる組織間の壁の有無で整理すると下表のようになる。

　ここからは第2回以降で紹介するプロジェクトのアウトラインを少しだけ紹介していこう。

顧客の新規ビジネスを創り出すプロジェクト

　NRIが多くの基幹システムを長年支えてきた結果、顧客の重要なビジネスパートナーとして認知され、新規ビジネスの立ち上げでも相談いただくことがある。最近はユーザー側の技術理解も非常に高く、コンテナ技術やKubernetesのメリットを顧客とNRIの双方が理解した上でプロジェクトをスタートできる例も増えてきている。

　このプロジェクトは、モード2として、新規システム構築で開発スピードと変化許容性を重視してコンテナ技術を採用し、少数精鋭の開発チームでサービスリリースまでを走り切ったケースだ。こうした小規模プロジェクトでは厳密なプロジェクト管理の必要性が薄く、NRI内のさまざまなプロジェクトと比較して先端技術の導入が容易というメリットがある。

　このプロジェクトではパブリッククラウドからコンテナ技術、プラットフォーム、アプリケーション開発と業務知識までを兼ね備えたエキスパートチームを組成して、前述のDevとInfraの壁を乗り越えた。しかし、業界固有の規制要件により、Opsとの間には壁が存在していた。これらをプロジェクトのアジリティを損なわずに、どのように回避したかについても焦点を当てる予定である。

社内サービスの開発におけるKubernetes適用

　NRIはチームのコミュニケーションを促進するサービスとして「aslead」を展開しており、サブプロジェクトとして、開発チームに必要な継続的インテグレーションのパイプラインを提供する「aslead DevOps」がある。

　aslead DevOpsは、以前から抱えていたさまざまな課題の解消に向けて、各コンポーネントを適切に分割してコンテナ化し、マネージドKubernetesサービスにデプロイして管理する構成にした。これにより「Pod」「Node」レベルのオートスケールも実現し、開発ピーク時に発生する密度の高いパイプラインのリクエストにも柔軟に対応が可能となっている。

　こちらもモード2のプロジェクトであるが、自社向けのサービスとしてDev／Infra／Opsを全て統合した組織で管理し、Kubernetesがもたらすメリットの最大化を実現している。　

　また、若いエンジニアたちが組織の壁に縛られずに活動し、「CKA（Certified Kubernetes Administrator）」「CKAD（Certified Kubernetes Application Developer）」などの資格取得を通じて知識を強化するとともに、外部コミュニティーからベストプラクティスを持ち帰り、新規技術のプロジェクト適用を積極的に推進した。

　この事例はコンテナ技術、Kubernetes技術の獲得と社内共有を目的とした側面もある。実績をもとに他プロジェクトへ展開が可能となったのはもちろん、ステートフルなワークロードへのKubernetesの適用可否やマルチクラスタ対応など“その先”のノウハウ獲得に向けて、asleadは前進している。

大規模な基幹プロジェクトにおけるKubernetes適用

　NRIが得意とする大規模プロジェクトでKubernetesを適用した事例だ。こちらは典型的なモード1であり、対応する組織構成も従来通りで壁が随所に見られる状況だった。それに加えて、前述のInfra組織の中でも役割が分かれ、Kubernetesに関連するチームとして基盤チームと開発支援チームが生まれた。

　基盤チームは、Kubernetesクラスタ管理者＝仮想サーバの上にKubernetesのクラスタを構築・運用するという役割を担い、Kubernetesのノードやネットワーク、そしてNamespaceの設計・構築・テストを行った。もう一方の開発支援チームでは、KubernetesのNamespace内管理者という役割を担い、Kubernetesリソースをどのように使うか標準化し、必要であれば定義ファイル（YAML）のひな型を作り、Devチームに展開した。そして、コンテナをビルドするパイプラインの構築・管理も開発管理チームが担当した。

　では、アプリケーション開発チームではどのように開発を行ったのだろうか。そして、それはKubernetesの導入により何か変化があったのか。

　今回の対象プロジェクトでは生産性を重視し、アプリケーションの設計・開発は大きな変化なく行えることを方針とした。つまり、DevとInfra間の壁をそのまま残し、同時にKubernetesなどの技術理解の必要性も壁の内に閉じ込めた。こうしたアプローチはNRIで過去に蓄積されてきたアプリケーション設計やフレームワークを最大限に生かすためだったが、当然課題も存在した。それらの詳細は連載第4回で記す予定だ。

まとめ

　NRIはモード1のような安定性が求められる大規模プロジェクトにおいて、これまで多くの成功をおさめ、顧客の信頼を勝ち得てきた。しかし現在、異なる形でのプロジェクトへの参与を望まれている。それはDXの潮流における革新の担い手として、モード2のプロジェクトに寄り添い、スピード感を持って歩むことだ。

　その実現にはNRIが長年培ってきた組織と開発文化の変革も不可欠だ。コンテナ技術やKubernetesを変革の一助として捉え、組織間の壁を乗り越えようとする動きは今回紹介する3つの事例に限らず、今後も多くのプロジェクトに拡がっていくだろう。

　NRIにおけるコンテナ技術やKubernetesの活用事例が、自らの組織・文化に同様の課題を抱える読者にとって、変革を始める一助になれば望外の喜びである。

筆者紹介

小林隆浩

野村総合研究所でデータベースを中心としたインフラ設計を担当。