創業20年となるDeNAがオンプレミスで運用する全てのシステム基盤を、今クラウドへ移行する理由と、その3カ年計画：特集：日本型デジタルトランスフォーメーション成功への道（4）（2/2 ページ）

[齋藤公二，＠IT]

先にクラウドネイティブにシフトしてから、リフトする

──リフト＆シフトというと、「取りあえずクラウドに移行して、後から中身をクラウドネイティブに作り替える」イメージです。対してDeNAは、最初に作り替えてから持っていく流れで計画を組んでいます。この狙いは何ですか？

　DeNAの場合、「取りあえずクラウドに移行する」となると、コスト負担がとても大きくなると分かっていたためです。クラウドのノウハウもありましたから、いったんオンプレミスでクラウドにあった仕組みに最適化しておいてから一気に移行した方が効率も良く、現在の品質も維持できます。

　この判断は企業によって変わると思います。移行することがコスト減になるケースもあるでしょうし、どう移行するか議論していると何も進まないので取りあえず持っていくアプローチもある。自社に合った方法を選択すればいいのではないでしょうか。

──移行で最も苦労するのは、どの段階とお考えでしょうか？

　年度ごとに苦労するポイントは異なっていて、年度ごとに頑張るメンバーも異なると考えています。2018年度はコスト削減と移行の準備が柱ですから、コストをメインに見ている人は忙しい。特に遊撃的に動く3人には100％の力をアサインしてもらっていて「2019年度にできるだけ楽に移行するためには君たちに今年頑張ってもらう」と。2019年度は顧客向けサービス系の運用管理者が大変になるでしょう。2020年度は、移行し切れないシステムを担当している人が忙しくなるはずです。

──今は、何をどう変えているのですか。マイクロサービス化したり、コンテナに載せたりしているということでしょうか？

　サービスのアーキテクチャを変えているというより、サービスを効率的に運用するための大量のツール群やスクリプト群を、APIで連携させるようなクラウドネイティブなかたちに書き直す作業が多いですね。社内システムについても、例えば資産管理システムでは、APIベースで管理対象のインスタンスやエンティティーを取ってきて、それをヒューマンリーダブルな形に変える。OSやミドルウェアも、これを機にバージョンを更新してしまうなどです。アーキテクチャというより、低位レイヤー部分を変更するための準備がメインです。

──そもそもDeNAでは、マイクロサービス的なアーキテクチャは既にあるということですか？

　そうですね。開発や運用には目端の利くメンバーがいるので、マイクロサービスという言葉がはっきりと定義されだした2012年ごろには社内にそういったアーキテクチャで運用するシステムがありました。

　もともと、モノリシックなシステムはメンテナンス性が悪く、ただデプロイしたいだけなのに影響範囲を考慮してフルでテストを回さないといけないのは非効率という考えがありました。そこでモジュールに分割して、複数のサーバ間通信を経て値を返す仕組みをオンプレミスで作っていたのです。

創業から20年近くたち、当時の革新的な技術が負の遺産に

──2020年度に対応を予定している、移行が難しそうなシステムには、どんなものがありますか？

　一言でいえば「分からないことが多いシステム」ですね。創業して20年近くたちますが、中には、作った人も引き継いだ人もいないシステムがあります。

　例えば、モバゲーの初期のアバターは、特殊なハードウェア、GPUを使った特殊なプログラムで作られていました。OSが古くなったのでOSを更新しようとすると原因不明の黒い線が画像に入る。解決するにはプログラムを一から見直す必要があるが、プログラムを書いたメンバーはもういないため、工数をかけて対応することも難しいという状況です。

　また、フィーチャーフォン向けのサービスも、そうですね。Perlで書かれていて、フレームワークも「MobaSiF」という独自のものを使っています。MobaSiFは2008年にオープンソースソフトウェアとして公開した当時は、革新的なフレームワークでした。しかし現在は、フィーチャーフォン自体の利用者がほとんどいない。フレームワークをなくした方がメンテナンス性は高まるが、それを誰がどう行うか。移行で最も手強そうなのが主力サービスの「Mobage」だったりします。当時の革新的な技術が今、足かせになっているのです。

──技術的な負債は、DeNAに限らず多くの企業が抱えている課題ですね。

　そうだと思います。ガーンと事業が伸びるときは、じっくり運用しやすいようにシステムを作る時間はありません。「規模の拡大にどう追い付こうか」と試行錯誤することで精いっぱいになる。それが長年運用すると、取り扱いが難しいシステムになっていきます。アーキテクチャやフレームワークの問題ではなく、当然の帰結としてそうなってしまうシステムをどう使いやすくするか――それは運用にとっての永遠の課題かもしれません。

──これまでは、古くなったアーキテクチャやフレームワークの更新にはどう取り組んできたのですか？

　メンテナンス頻度が高いものは新しい仕組みを作って載せ替えてきました。既存の機能が必要なら参照先だけ代えて使えるようにするなどです。ただ、メンテナンス頻度が低いものは取り残されがちです。1つのシステムでも、一部はマイクロサービスとして切り出されて外部のモジュールとして動いているのに、一部はモノリシックな内部に取り残されて、それがまたカオス感を増すことにつながっているのです。

　もちろん、その場その場で最適なものを選んできたという自負はあります。しかし、それと同時に、全体として最適化を狙っていかないと、自分たちの首を締めていくことになります。

クラウド移行で運用管理者の役割はどう変わるのか

──クラウドへ全面移行すると、運用管理者の役割はどう変わるのでしょうか？

　DeNAにおいては、「運用管理者」「インフラエンジニア」という言葉の表す範囲が、一般的に使われるものとは異なっていると感じることが多くあります。DeNAでは「フルスタックエンジニア」というか、「できることを全てやる」という役割意識なので、それはクラウドに移行しても大きく変わらないと思います。

　コミットすべきことは、システムの安定稼働、高いセキュリティ、低コストです。ただ、マネージドサービスなどクラウドの便利なサービスを使えば、ハードウェア／機器の故障や修理対応といった作業が必要なくなるので、その分、新しい運用方法を提供することに取り組んでいきたい。

──なくなる仕事が出る一方、新しい仕事も出てくるということでしょうか？

　そうですね。単純にサーバが必要になったらキッティングして渡すというだけなら、その役割はクラウドに置き換えられるのではないでしょうか。ただ、インフラの仕事はそれだけではなくて、インフラから派生してミドルウェアを見ようとか、アプリケーションのプログラムの中まで見ようとか、それらの専門家にまでなろうかというところまで広がっていきます。そういう働き方ができるエンジニアの方が、市場価値が高くなる。エンジニア個人としてもハッピーになれると思っています。

──クラウドに移行すると、オンプレミスで培ってきたノウハウが失われることもあるのではないでしょうか？

　計画段階で、そうした懸念は出ていました。そこで、失われるノウハウは具体的に何があるか列挙して、それが事業会社であるDeNAにとって許容できるのかできないのかを色分けして考えました。

　オンプレミスのサーバの余剰をどう見積もるか、修理パーツをどうやって購入するか、効率的なラッキング方法は何か、効率的なラッキングの仕組みどう構築すべきかなどは、DeNAにとって失われることが許容できないノウハウかというと必ずしもそうではない。最悪失われても許容できるのではないか――と一つ一つ納得感を出せるようにして色分けしてきました。

──今後は、そのようにして企業として運用管理の役割を見直す必要が出てくるのでしょうね。

　ただ、注意したいのは、狭義の「インフラエンジニア」が必要ないからといって、企業側がそのポジションや部門をなくしてしまうことは避けるべきということです。自分たちの会社のシステムを分かっていて、動かせる人がいなくなるので必ずしっぺ返しを受けます。

──開発や事業のニーズばかり見ていると部分最適になるという話にも通じます。

　そうですね。会社としても、インフラエンジニアには「こういうキャリアの広げ方があるのでは」と提示して、目線を広げてできることを増やすことが求められます。双方向でインフラエンジニアの定義を変更したり、カバーする範囲を拡大したりしないと、お互いが不幸になる。逆に言えば、それができれば、会社とエンジニア双方がハッピーになる。そういう時代になったということだと思います。

特集：日本型デジタルトランスフォーメーション成功への道 〜“他人事”ではないDXの現実解〜

テクノロジーの力を使って新たな価値を創造するデジタルトランスフォーメーション（DX）が各業種で進展している。だが中には単なる業務改善をDXと呼ぶ風潮もあるなど、一般的な日本企業は海外に比べると大幅に後れを取っているのが現実だ。では企業がDXを推進し、差別化の源泉としていくためには、変革に向けて何をそろえ、どのようなステップを踏んでいけばよいのだろうか。本特集ではDXへのロードマップを今あらためて明確化。“他人事”に終始してきたDX実現の方法を、現実的な観点から伝授する。

特集：日本型デジタルトランスフォーメーション成功への道 〜“他人事”ではないDXの現実解〜