NTT技術ジャーナル記事

   

「NTT技術ジャーナル」編集部が注目した
最新トピックや特集インタビュー記事などをご覧いただけます。

PDFダウンロード

挑戦する研究開発者たち

ユーザの一歩先を行くために、技術の本質的な使い方を迎えに行こう

ソフトウェア開発の効率化、生産性向上が継続的な課題となっている中、NTTコミュニケーションズによるオリジナル開発のオーケストレーションプラットフォームであるQmonusがNTTグループの中に広く浸透し始めています。Qmonusの内製開発者 橋本昭二担当部長に研究開発テーマの概要・経緯と研究開発者としての姿勢について伺いました。

橋本昭二
イノベーションセンター テクノロジー部門
担当部長
NTTコミュニケーションズ

NTT ComオリジナルのオーケストレーションプラットフォームQmonusを開発

現在、手掛けている研究開発から教えていただけますでしょうか。

私はNTTコミュニケーションズ(NTT Com)の研究・開発部門で、高速かつ継続的なソフトウェア開発と柔軟なデリバリを可能にするプラットフォームQmonusの内製開発に取り組んでいます(図1)。
お客さまに提供するサービスやシステムは、その要求条件が多様で、複数のプロジェクトで並行開発するとアーキテクチャが異なる個別システムが量産されることになり、システムの構築・管理・運用が非常に複雑で非効率なものとなります。特にクラウドをベースとして開発を行う、クラウドネイティブな環境が一般化してきている中、さまざまなオープンソースソフトウェア(OSS)や製品、サービスが利用されており、この傾向がますます顕著なものとなってきます。こうした課題を解決すべく私たちが考えるベストプラクティスとしてDevOpsフレームワークを開発し、全社の標準プラットフォームとして使えるように広めていこうというコンセプトでQmonusを開発しています。現在、Qmonusは、クラウドネイティブアプリケーションの開発、およびデリバリ・運用を高度化するためのPaaS(Platform as a Service)としてスマートデータプラットフォームをはじめとし多くのサービス開発を支えています。
Qmonusは、クラウド上でMicroserviceを高速に開発するためのQmonus SDKと、DevOps環境の柔軟な自動構築や、Microserviceのデリバリ・テスト・運用の自動化を実現する、宣言的CI(Continuous Integration)/CD(Continuous Delivery)プラットフォームであるQmonus Value Streamで構成されています(図2)。Qmonusは、サービスごとにサイロ化されて、アーキテクチャ構成の設計、検証、構築、運用に追われて、アプリケーションの開発に注力できないというサービス開発担当者の悩みを一気に解決します。

どのような経緯で内製開発を行っているのでしょうか。

私は、大規模システムの開発に長らく従事していましたが、大手SIerとのぶつかり稽古を通して彼らから多くの知見・ノウハウを得てきました。一方他の社内システムにおいても外注を中心とした開発が乱立し、多額のキャッシュアウトが発生している状況でした。仮想化やクラウド技術、SDNが叫ばれる中、ソフトウェアを内製できないIT企業に未来はないと考え、システムの内製開発の重要性を再認識し、内製化を推進していくには、開発プロセスの効率化による生産性向上と人材育成が急務であると考えました。
そこで、私はSDN向けのコントローラやオーケストレータを開発するための独自のソフトウェアフレームワークを密造し、内製でも十分な生産性や品質で開発できるんだということをサービス開発の部署や幹部にアピールする活動を行い、周囲の理解・信用を得ることに尽力しました。Qmonusは、2014年に開発着手したのですが、表向きは、とあるサービスのコントローラ開発でしたが、設計段階からアプリケーションに特化せず、メタな処理モデルを駆動する実行エンジンと業務ロジックを切り離したアーキテクチャで開発し、後にエンジン部を流用できる構造としました。つまり、このエンジン部がQmonus SDKのコアの原点となります。このパイロットプロジェクトの成功を皮切りに案件を徐々に増やし、周囲の信頼を積み上げて、ようやくクラウドネイティブなプラットフォームQmonusの誕生まで漕ぎ着けました。Qmonusによってサービス開発の速度は飛躍的に向上し、システムの内製率も格段に向上しています。共に開発をし、巣立っていったメンバや事業サイドで導入をフォローしてくれた仲間は、長い年月を経て、グループ各社で活躍し、そこでQmonusの導入推進をしてくれるようにもなってきました。最近までサービス化など考えてもみませんでしたが、周囲の協力や使いたいと言ってくれる声に支えられ、2022年度にNTTグループ向けにサービスを開始する段階まできています。

欲しいモノを自分で育てる楽しさ

自らがつくり出したモノの価値を認められて拡散したという経緯は興味深いですね。

多くの場合、ニーズやシーズから研究開発のテーマを考えるのが一般的だと思いますが、Qmonusは、「私が欲しいモノ」から始まっています。一番欲しいモノをつくるのは楽しいものです。Qmonusにより自分の生産性も上がるし、それを使うことによって周囲の生産性も上がります。またさまざまなフィードバックを得ることでさらに自分も道具も進化することができます。何より欲しいモノを自分でつくり、育てることは楽しいと思いませんか? NTT Comの開発部門には、こうした発想を尊重してくれる環境があります。入社したばかりのとき、システム開発を新入社員だけのチームで内製させてもらったことを覚えています。この環境は今も同じで、新しいビジネスのタネになるような技術開発は何でもやらせてもらえます。ただし、ビジネスですから出口戦略は必須で、価値を見出せなければ継続することはできません。しかし、志や将来性をしっかりと示せば開発着手は認めてもらえます。
その際、自分の志をしっかり伝えるためにきちんと戦略を練る必要があります。私は、先ほどお話ししたQmonus SDKの例のように、まずは実績をつくり使っていただくことで、その価値を実感してもらうことを心掛けています。他にも私は相手の意見をよく聞いて、次の機会には本質的なフィードバックをするように心掛けています。
Qmonusは私の欲しいモノからスタートしたサービスですが、もちろん、開発をする以上、社会貢献や事業貢献につなげていくことが前提です。そのためにも周囲の意見を聞くことは重要で、周囲からのフィードバックを熟考したうえで、それを超えた提案をすることがベストだと思います。まずは技術を追いかけてつくったものを使っていただき、結果のフィードバックから本質的な要求を噛み砕いてプロダクトに反映する、このように「技術の本質的な使い方を迎えに行く」アプローチがユーザの一歩先を読み解くことにつながると考えています。

技術を迎えに行くとはユニークな表現ですね。その活動において課題やテーマを探すときに心掛けていること、意識して実行されていることはありますか。

目前の課題に対応しつつ、自分たちだけでは解決できないような大きな問題を見据えて動くという状態ですから、取り組む課題やテーマをじっくりと考える余裕がないのが実情です。ただ、抱えている案件が非常に多いうえ、ユーザも多く、その分フィードバックもありますからテーマの材料には事欠きません。だからといって、すぐにテーマとして飛びつくのではなく、全体を俯瞰する力も必要です。社会において私たちがどのポジションにあるかを知らないと、社会や事業への貢献からほど遠いテーマとなります。
このため、私は同じ志を持った仲間とのブレーンストーミングを大事にしています。例えば、DevOpsに別の視点や軸で臨んでいる組織の仲間とディスカッションしたり、お互いの近況、悩みを共有しています。それだけでもたくさんの課題テーマやアイデアが出てきますし、技術だけではなく、ビジネスの戦略や組織的な課題等も共有できて大変刺激を受けてることができます。他にも、技術論文やホワイトペーパー、OSSの動向にも目を配り、私たちが取り組まなければいけないニーズやシーズ、トレンドも集めます。
余裕がない中でも情報収集や思考の時間をつくらなければならないので、私は午前中をコーディングやデバッグ等の直接の開発の時間にあて、午後はコミュニケーションや思考の時間にあてています。頭がフレッシュな午前中は集中してコーディングを行い、老眼で疲れてきたら、情報収集やコミュニケーションを通じてさまざまな意見を聞くとリラックスできて「次あれやろ」と課題やビジョンが浮かんでくるからです。

10から100にするのは、0から1にするよりも大変

研究開発者の仕事の醍醐味を教えていただけますでしょうか。

研究開発者の仕事は0から1を起こす仕事だと思っており、3年ほど前はそれが醍醐味だと思っていました。0から1にするのは大変で、その1を10にするのは楽しい、けれどもその次のステップ、10から100、1000にするフェーズは、それが0から1とは比べ物にならないほど大変であることに直面しています。ソフトウェアはコピーすればスケールしますが、案件プロジェクトが膨大になってくるとソフトウェアでカバーできない部分でどうしても人が必要になります。導入支援や設計コンサル業務、運用支援といった部分で限界があるのです。
したがって、「しかけ」をつくる必要があります。これは人を含めたシステム化のイメージで周囲のパートナーとうまく連携しなければ実現できませんし、連携するにはWin-Winの関係を築かなければ協力を得ることはできません。単純に技術と向き合っていればよかった0から1の世界とは違い、100から1000をめざす今は全く違う景色が見えています。関係パートナーをコーディネートするのは骨が折れますが、その大変さより100から1000に向かって進んでいる実感が増す喜びのほうがはるかに大きいと感じています。
ところで、研究開発の醍醐味はある意味自己満足だと思っています。ただ、その根幹には研究開発者の「社会に貢献したい」という信念があり、その信念に基づく結果に対する自己満足なのです。例えば、私はユーザからいただく感謝の言葉に喜びを感じます。これは自分がいいと思ったものが実際に世の中で使われているという事実を「誰かの役に立った」と、とらえているからだと思います。研究開発者としてこうした喜びを得るためには、最後まで成し遂げる志や、自分を信じるだけではなく、周囲や仲間をしっかり信じることが大事だと思います。なぜなら、研究開発者として0から1にする、つまりモノはつくれるかもしれないけれど、仲間がいなければ100にすることはできないからです。そこには必ず、仲間、そして「しかけ」が必要になります。

後輩に一言メッセージをお願いします。

私は日頃、上下関係を意識せず後輩の皆さんと仲間感覚で接して仕事をしていますので、その感覚でお話しさせていただきます。
若いエンジニアは「この技術をやりたくてNTT Comに入りました」「外部で発表したいです」「論文書きたいです」という方も結構多く、この姿勢や行動は研究開発者にとって当たり前でとても大切なことだと思います。
ただ、皆さんには、今やっている研究開発が事業にどのようにつながっていくのか、事業における自分のポジションを常に把握して業務に取り組んでほしいと思っています。そして、その成果をタイムリーにアウトプットしていくように努めてほしいと思います。これによって、事業貢献と研究開発が両立し、ブレのない研究開発を継続できますし、アウトプットするために必要な信頼関係を早いうちから築くことができ、それが将来の役に立つのです。
理想形を追い求めず、動く技術をなるべく早く事業に届けることを意識して取り組むとよいのではないでしょうか。
世の中の動きもとても速くて、似たようなことをしている人が世界にいることを知ると、それが気になって目標や目的を見失うこともあります。そのためにも、コンパクトにアウトプットできるルートは常につくっておくのがよいと思います。
私は生涯現役プログラマーを可能な限り続けたいと思っています。「橋本さん、ボケました」と若い人から突き上げられるまではキーボードは離さないつもりです。