DeNAのサービスが強い、速い、本当の理由：特集：DevOpsで変わる情シスの未来（3）（3/4 ページ）

事例を交えてDevOpsをさまざまな角度から探る本連載。今回は「Mobage」をはじめ各種サービスを提供しているDeNAの強さの秘密を、同社の開発・運用体制に探る。

[内野宏信，＠IT]

ビジネス、開発、運用部門が有機的に連携

　以上のように、DeNAが実践しているDevOpsは非常にシンプルかつ合理的だ。ただ「両部門がお互いの業務知識を理解し、境界線上の問題を解決し合う」と言っても、個人の自発性に任せておくだけでは実践は難しい。

　茂岩氏は「両部門のことが分かるようになってください」と日ごろからスタッフに言っているというが、そうした創業期を知るシニアスタッフの経験知と、社内講習を開く、社内ポータルでナレッジベースを共有する、評価に反映するといった意識的な取り組みが同社のDevOpsを支えていると言えるだろう。情報共有にしてもIRCなどのツールだけに頼らず、開発部門の近くにQAやセキュリティ担当者が席を作ってもらい直接会話できるようにするなど、コミュニケーション上の工夫もしてきたという。

　そうした中でも同社の最大の特徴といえるのが、DevOpsの一般的な定義からは外れるが、IT部門内に閉じない部門間連携を行っている点だ。ビジネス部門が新サービスを企画し、ビジネスモデルを立案する段階から、開発部門、インフラ部門のマネージャ層が会議に加わり、情報共有を行っているのだという。

　「例えばビジネスモデルを立案する際、新サービスで想定されるトラフィック量や、必要なサーバ台数、コストなどについてビジネス部門に相談されますが、要件によってはインフラの準備に時間がかかることもある。それがネックになってリリース時期が遅れることがないよう、特に企業規模が大きくなり始めてからは、ビジネス部門との情報共有をより早い段階からできるよう、意識的に働き掛けてきた経緯があります」

　情報共有の遅れは開発作業にもデメリットをもたらす。例えば、リリース時期も含めた新サービスの全容が決まった後に告知されても、最適なアーキテクチャを考える時間を十分に確保することが難しくなる。

　「特に、想定ユーザー数が100万〜1000万人規模のサービスになると、快適なレスポンスを担保したり、新機能を追加したりと、ニーズに応えながらサービスを運用していく上で、どんなアーキテクチャを採用するかが、その後の収益構造に大きく響くことになります。しかし最初の段階で判断を間違うと、後から修正することが非常に難しくなる。従って、早い段階からビジネス部門、開発部門、運用部門が、それぞれの視点で、ともに計画を考えることが重要なんですね」

　2012年10月にリリースしたコミュニケーションアプリ「comm」や、2013年1月にリリースしたスマートフォン向け音楽アプリ「Groovy」もそうしてリリースしたサービスの一例だという。「comm」の場合は通話の想定トラフィック量の算定が、Groovyの場合は音楽データの貯蔵場所や配信経路の策定が、アクセス集中に耐えられる高レスポンスと投資コストとのバランスを取る上で1つのポイントになったそうだ。

2013年1月にリリースしたスマートフォン向け音楽アプリ「Groovy」のWebサイト。ビジネス部門と連携し、短期間で適切なインフラを考案した

　サービスが企画された段階で、開発部門はどのようなアーキテクチャを採用し、どれほどのユーザーと、どのようなサーバ通信をするかを考え、インフラ部門はそれに基づいて、コストに応じた松竹梅の3段階でインフラ設計を提案する――市場変化に対応できるサービスの展開スピードと品質、収益は、ビジネス部門も含めた有機的な連携が支えているというわけだ。