「じゃあその仕組みどうしようか」　楽天が完全仮想化のために取り組んだ3ステップの組織づくり

テレコムの仮想化の標準化まで

小杉正昭氏（以下、小杉）：おはようございます。小杉と申します。本日はこのような場で発表する機会をいただきましてありがとうございます。今回は「完全仮想化の裏側」と題して発表いたします。20分ほどの発表になりますが、どうぞ最後までお付き合いください。

まずは自己紹介します。楽天モバイル株式会社 クラウド基盤技術・運用課でマネージャーをしております、小杉正昭と申します。簡単に職歴を紹介しますと、2010年に前職の会社に新入社員として入社し、その後10年以上ずっとテレコム仮想化のエンジニアとして仕事しています。

入社当時はテレコムの仮想化というのはまだ構想段階で、ベンダー各社がそれぞれ独自の製品を作って提案しており、私もその設計・開発に従事していました。その後、2012年ぐらいに標準団体であるETSI NFVが立ち上がり、世界的に各オペレータやベンダーが数年かけて標準化を行いました。

私もこの標準化に向けて検討とか検証に参加していました。標準化と併せて技術がオープン化し、今ではデファクトと言っていいOpenStackにテレコムならではの要件というものがだんだんと盛り込まれていきました。さらに基板上で動作するテレコムのアプリケーション、ネットワークを構成する機能も仮想化基盤に合わせてより扱いやすいように進化していきました。

そんな中で楽天モバイルが「完全仮想化のネットワークを作る」ということを知り、今まで培ってきたものを活かしてサービスを提供したい、新しいことにチャレンジしたいと気持ちから、2019年2月に楽天モバイルに入社しました。現在は仮想化基盤の構築を主に担当しています。

組織と仕組みづくりの話

今日の話は、さまざまな状況の変化に対応しつつ、スピード感を持って仮想化基盤を全国に展開していくための組織と仕組みづくりのお話になります。新事業の完全仮想化のネットワークのサービスを構築する。この立ち上げにあたってどのような組織、仕組みを作ったか。個人的な目線で順を追って説明いたします。

今日聞いている方々の中で「今までにないプロジェクトに挑戦するんだけどどうしよう」とか、「なんか最近組織がうまくなっていないな」という方がいらっしゃいましたら、参考にしていただくとよいかもしれません。（スライドを示し）これは実際に私のチームの写真です。同じ夢に向かってけっこう困難がありつつも一致団結して毎日楽しく仕事をしています。私のすごく大好きなチームです。

最初にテレコムの仮想化について説明します。今日見ていただいている方々の中には、あまりテレコムの仮想化をご存知ない方もいらっしゃると思いますので、まずは説明します。次にこの完全仮想化をやるにあたっての課題と、課題解決策である組織づくりについてお話をします。最後にまとめとなります。

なぜ仮想化をするのか

ではまずテレコムの仮想化とは。なぜ仮想化をするのか。これには2つ目的があります。1つ目はCAPEXの削減です。従来の仮想化されていないネットワークは、専用装置と独自のOSアプリケーションが動作してネットワークを構築しています。これに対してより安価な汎用サーバ上でオープンな技術を使ってネットワークを構成する。これによって低コストでネットワークを実現する。これが1つ目です。

2つ目はOPEXの削減になります。統一されたサーバとオープンな技術によってオペレーションをシンプル化して、さらに相性のいい自動化を組み合わせてOPEXを削減する。これが2つ目の目的になります。

次に完全仮想化の強みとは何なのか。これは簡単に言うと、モバイルネットワークのすべてを最初から仮想化した。これが完全仮想化の強みと言えます。

一部のネットワークだけを仮想化したり、既存のサービスを止めずに段階的に移行していくとなると、移行の費用がかかってしまうところがあります。それに対して楽天モバイルは最初からすべて仮想化した。これが仮想化のメリットを最大限享受する。完全仮想化の強みと言えると思います。

続きまして私のミッションです。仮想化基盤の構成について説明します。この仮想化基盤には、大きく2種類あります。1つ目は中央のデータセンターです。東西に1つずつ2つのデータセンターが存在します。このデータセンターでは基幹通信網を収容する仮想化基盤を構築しています。もう1つが地域のデータセンターです。日本全国に存在して、無線基地局を収容するための仮想化基盤を構成しています。

入社してしばらく経って、私の尊敬する上司でありテレコム仮想化の先達者であるカーン・アシックさんから「小杉君、地域データセンターの全部の構築よろしく。任せたね」という話をもらいました。それから日本全国の地域に数百またはそれ以上に及ぶ数の仮想化基盤を構築するということが私のミッションになりました。

私自身ずっとエンジニアとして活動していたので、部下を持ったり組織を作るのが初めてで少し不安だったのと、任せてもらってうれしかったというのを今でも鮮明に覚えています。

求められる課題ととりまく環境

では課題です。QCDの観点から求められるものというのをまず考えてみました。QCDはQuality/品質、Cost/コスト、Delivery/納期の3つから構成され、生産管理を行う上での1つの指標となります。この3つがそれぞれトレードオフに関係していて、課題とも表裏一体です。

楽天モバイルのプロジェクトで求められるものはQuality/品質。これはいわゆるキャリアグレードです。携帯電話のサービスは24時間365日止まらないことが求められるので、そのネットワークを構成する仮想化基盤も高い品質が求められます。

次にコストです。これが完全仮想化の肝です。先ほどご説明したとおりCAPEXやOPEXの削減というところがターゲットになっていますので、もちろん構築においても大幅なコスト削減が求められます。

最後にDelivery/納期なんですけど、「スピード!!スピード!!スピード!!」。これは楽天の成功のコンセプトとして挙げられているものの1つで、他社が1年かかることを1ヶ月でやり遂げるというスピード感が求められます。

こうしたQCDのすべてに求められる水準が高いという状況に加えて、会社としても成長段階。人を増やしたり組織を作ってプロセスを作って、さらに仮想化基盤を構築していく。こういった取り巻く環境の中で課題を分析してみると、大きく2つに分けられました。

1つ目は一般的な組織の課題でも挙げられることですが、技術と作業が属人化してしまっているというのが、まず挙げられました。やることがとても多くて多様なのでなかなかスケールしない。もう1つは人材不足ですね。スケールしたいんだけど人を雇おうとしてもテレコムの仮想化のエンジニアというのはそんなにいないので、これもけっこう難しい。なので、作業を平準化してスケールできる組織にしたいなと思いました。

もう1つは楽天モバイル独自の課題で、これは変化への対応ですね。世界初のシステムになりますので、その仕様変更とか問題解決に初めて出てくるものが多いです。それに対してスピード感を持って対応していかなければいけない。そのため、変化に迅速かつ柔軟に対応できるような組織にしたいなと思いました。

まず反省会で現状把握する

ここからは組織づくりでやったことを3つのステップに分けて順を追って説明していきます。ステップ1は反省会、現状把握です。この反省会をやったときに、もういくつかの構築を進めていたのですが、だんだんとチームメンバーの負荷が上がってきたりとか、何かあったときの対応のスピード感が落ちてきているというのを感じていました。一旦ちょっと立ち止まってみんなで現状を分析してみようということで、役割の見直しをしました。

話しているうちにわかってきたのは、1人の人が複数の役割を果たさなければならず、それによって負荷が上がったり、仕事が途中で止まっていたことです。例えば何かの判断をしなければいけない人がいます。だけれどもトラブルシュートをしなくてはいけなくて、それが終わるまで手が離せません。そうするとその判断を待っている人が次の仕事ができません。こういったことが起きていました。

みんなで話し合った結果、「4つの役割に分けたらどうでしょうか」ということになり、（スライド）こちらの表になります。1番、2番、4番はこのように役割分担をすることで今のみんなで補える。要件を定義、判断する人。要件を実現する人。トラブルシュートする人。ですが、圧倒的に足りなかったのが、構築する人でした。これを何とかプロセス化によって必要なスキルレベルを下げてスケールできないか。そんな話をしました。

もう1つ反省会で話したこと。組織づくりとセットで重要なプロセスについて見直しをしました。忙しかったりして積み上げたものを1回最適化しましょう、時間を短縮しましょう。もう1つは先ほどの構築する人のハードルを下げるために自動化して、誰でもできるオペレーション、誰でもOK/NGを判断できる結果にする。簡略化することによって構築する人のハードルを下げる。こんなことをしましょうという話をしました。

構築する人へのトレーニング

ではステップ2です。組織の立ち上げ。組織の立ち上げで主にやったのは、その構築する人へのトレーニングです。主に4つのトレーニングをしました。1つはプロセスを書き出してみましょう。テレコムの仮想化をまったく知らない人もいるので、まずはみんなで話せるように同じ言葉で覚えましょうというところです。

2つ目は古いプロセスで実際に構築してみよう。ハンズオンのトレーニングをしました。これは自動化したものをやってもらってもいいんですけど、今後プロジェクトに参加したときに、自分が何を構築しているのか理解してもらうということと、「自動化ってこんなにすごいんだな」というのを体感してもらうことが目的です。今後に向けた布石の1つとしてこういったことを行いました。

3つ目が自動化の設計に参加してみよう。自動化というのは基本的にプロセスを並べてみて、どうしたら続けて人が触らずにできるかというところがありますが、実際にこの自動化したツールを使うユーザは構築する人なので、ユーザの観点で「こうしたらもっと使いやすい」。そういった要件を今後盛り込んでもらえる。そういうことを期待してこのトレーニングをしました。

最後は独自の手順を作ってみようということで、手順を作る人に作ってもらってもいいんですけど、実際に構築する人たちに理解しやすい言葉、それをちゃんと改善・メンテナンスをしてもらう。こういったことを期待して構築する人たちに独自の手順を作ってくださいとお願いしました。

あえて旧プロセスから始めて今後の技術を底上げする、継続的な改善を期待するということで、こんなトレーニングをしました。

独自の構築管理システムを導入

ステップ3の変化に対応できる組織へというところで、最後に残る課題になるんですけど、役割の見直しとプロセス改善トレーニングによって、なんとかスケールしやすい組織は確立しました。ただ一方で変化への対応を継続していかなければいけないという課題が残ります。

変化とは何かというのをもうちょっと振り返ってみますと2つありまして、1つは仕様の変更です。新しいソフトウェアの変更、機能を追加する、仮想化基盤の設定を変更する、いろいろなことがあります。私の経験上、通常テレコムの仕様の変更というのは数ヶ月ぐらいで行われるのですが、楽天モバイルでは数週間とか早いときは数日。こんなスピード感で変更が求められます。

もう1つは問題の発生ですね。各種バグが起きたりとかハードウェアの故障が発生したときに交換しなきゃいけない。フローと手順の見直し、こういった修正を継続的かつ迅速に適用する仕組みというのが必要になってきます。

「じゃあその仕組みをどうしようか」と、これもチームで話をして、我々の組織とプロセスにあった独自の構築管理システムを導入してしまおうということになり、みんなで設計して導入しました。

1つ目の変化で仕様変更が起きたときに1番の要件を定義、判断する人、この人が改善要求を出します。その要件を実現する人が手順書・ツールに落とし込む。改善されたものの最新版を常に構築する人が使う。これで1つのループができたわけですね。

もう1つの変化で問題が発生した場合。これは構築する人にまず問題管理のチケットを上げてもらいます。そうするとトラブルシュートする人がまた手順書とツールに反映して、それをまた構築する人が使う。仕様変更と問題という、この2つの変化に対して改善のループを形成しました。

作業ではなく、目的達成をするためのお願いをする

最後に、仕組みを作ったんですけど、これらをどうマネジメントするかということについて、私が日々気を付けていたことを少し話させてください。まずは、作業をお願いするのではなく、目的を達成するためのお願いをする。背景と目的というのを理解してもらうために、チーム全員で常に話し合う、理解してもらえるまでとことん説明する。これを徹底しました。

例えばチームのみなさんにいつも言っているのは、「一番の目的は日本全国へ仮想化基盤を展開する。これをできるだけ早く完成することです。達成するための効率化を常に考えてください」。要件を実現する人たちには「プロセスの最適化をするということが肝で、だんだん繰り返して溜まってくると崩れてしまうので、最適な状況を保てるようにキープしてください」ということをお願いしました。

構築する人には「効率化の観点だと一番重要なのはみなさんが楽になることです」と。「何か面倒くさいなと感じたらいつでも教えてください」とお願いをしました。最後のトラブルシュートする人へは「早く解決することが最重要になります。必ずしも常に恒久対処が必要なわけではないです。また、起きてからではなくて起きる前に問題を防ぐということも考えてみてください」とお願いをしました。

これらは何を意図しているかと言いますと、役割ごとに構築の中でアンテナをもって敏感に反応してもらう、変化に反応してもらって対応してもらう。これをできるようになってほしくて、こういうお願いの仕方をしました。この背景と目的の共有を進めているとチームでプロアクティブな改善ができるようになりました。

例えば要件を実現する人が要件を出す前に「そう来るなと思って先に作っておきました」。事前に話しておいた背景を汲んでくれていて、もう作っちゃいました。他には構築する人がだんだんと技術を覚えてくれて、「こうしたらもっと楽です」という要求を出してくれたりとか、「あの問題は実は自分で解決しちゃいました。更新しておきますね」。こんなふうに全体がプロアクティブに改善してくれるようになりました。

それぞれのQCDの求められる水準というのは非常に高い中で、新規の世界初のシステムということで課題も多い中、背景と目的を共有して続けてきた結果、感謝し合い、励まし合い、助け合う、そんな組織が自然とできあがりました。こういったみなさんと一緒に成長していける組織を作れたというのが私の一番うれしかったことであり、みなさんに感謝しているところです。

常に背景と目的を共有して、チーム全体で成長していく

最後にまとめです。結局やったことは、足りないものは何か見つける。その足りないものを補う方法を考える。そしてこういうことが起こらないように改善していく仕組み・組織にするといったところです。それにプラスして常に背景と目的を共有して、チーム全体で成長していくというところです。

今後については、これまでにチームで作ってきたものとか仕組みを自動化して、自動化の最終目標の1つと言っていいゼロタッチオペレーション。何もしなくても構築が進むというような世界を今後は目指していきたいと考えています。

本日の発表は以上となります。ご清聴ありがとうございました。