2017/12/21

1か月かかる環境構築を1日に短縮。DeNAのリーン開発基盤は、なぜ圧倒的な開発効率化を実現できたのか?

どんな時代も、“開発効率化”はエンジニアにとって関心の高いテーマのひとつ。可能な限り少ない工数で多くの機能を開発するため、過去にはさまざまなフレームワークやツールが生み出されてきました。サービスインキュベーション事業部システム部の村田紘司と平野朋也も、部署が抱えていた課題を解決するため、開発効率化に“フルスイング”したエンジニア達です。

 

彼らは、DeNAの開発文化の常識から脱却したり、アプリ開発において共通して用いられる処理を「Daizu」というフレームワーク群に集約したり、ライブストリーミングサービスの共通基盤を構築したりと、部署の圧倒的な生産性向上に寄与しました。今回は、そんな彼らの取り組みにスポットライトを当てます!

 

PerlからRubyへ。オンプレからAWS

――お2人は、部署の開発効率化のためにさまざまな取り組みをしてきたそうですが、「DeNAの開発文化の常識から脱却」とは具体的にどんなことを実施したんですか?

 

村田:大きく分けると2つあって、「①開発言語はPerlが主流だったのをRuby(Ruby on Rails)に変えた」「②インフラはオンプレが主流だったのをAWSに変えた」です。

 

 

私たちの部署は、「エンジニア1~2人くらいの小規模なプロジェクトチームが、個々にサービスを立ち上げて短いスパンで開発し、リリースする」というスタイルを取っています。

 

コマース&インキュベーション事業本部サービスインキュベーション事業部システム部 村田紘司(むらた こうじ)
2014年に新卒でDeNAに入社。エンジニアとして新規事業開発の部署に配属され、一時的にプロデューサーも兼任しながら、少人数チームでこれまで7つの新規事業の立上げ・運用に携わる。現在はリーンスタートアップを支えるエンジニアとして、クライアントからサーバサイドまで1人で開発の全工程を手がける。中でもiOSの実装をしているときが一番幸せ。

 

このスタイルの場合、Perlはあまり適していません。テンプレート化がしづらいですし、サービスを立ち上げるまでに時間がかかるからです。むしろ、Ruby on Railsの方が圧倒的に初期の立ち上げはスピーディーにできます。「ならば、部署の業務に適した言語(やフレームワーク)を使用すべきだ」と思い、Ruby on Rails化を推進したんです。

 

平野:さらに言うと、インフラはオンプレが主流だったのをAWSに変更したのも、ほぼそれと同じ理由です。DeNAのインフラ部隊は本当に優秀で、依頼すると数日で高スペックなサーバー環境を構築してくれるんですけど、“数日”かかってしまうのが私たちにとってはネックだったんです。

 

コマース&インキュベーション事業本部サービスインキュベーション事業部システム部 平野朋也(ひらの ともや)
2016年に新卒でDeNAに入社。エンジニアとして新規事業開発の部署に配属、エンジニア一人のプロジェクトを経て、現在はライブ配信サービスのエンジニアとしてクライアントを低レイヤーからフロントまで幅広く実装する。プライベートでもアプリを作る事が趣味。

 

開発からリリース、運用までのサイクルが非常に短いスパンで回っているので、極端に言えば「ボタンを押せばすぐサーバーが用意できる」くらいのスピード感を求めていました。

 

――つまり、部署の開発スタイルにアジャストさせる形で文化を刷新していったのですね。

 

 

部署の抱える課題を解決すべく生まれた「Daizu

――フレームワーク群「Daizu」の開発に着手したのはどうしてですか?

 

村田:サービスインキュベーション事業部システム部が抱えていた、ある“課題”を解決するためです。先ほども話したように、私たちの部署では小規模なプロジェクトチームが、個々にサービスを立ち上げて短いスパンで開発し、リリースします。

 

そのスタイルであるが故に「開発ノウハウがプロジェクトチームごとに閉じてしまい、部署全体に共有されない」「他のプロジェクトで使われたソースコードをそのままコピペして流用するケースがあるため、部署内でソースコードの重複が多い」といった課題を抱えていました。

 

その状況を改善したいと考え、よく使われる機能を一元管理して誰もが使いやすくするために「Daizu」というフレームワーク群を作ったんです。以下が、よく使われている代表的な機能です。

 

【iOSアプリ系】 ・Realm実装の簡略化

 ・クライアントログの送信

 ・アプリ内課金

 ・OAuth

 ・プッシュ通知の設定

 ・アラートの表示

 ・Date型の文字列へのフォーマット

 ・お問い合わせメール画面起動

 

【サーバサイド系】

 ・以下のような機能を含めたテンプレートによるアプリケーションの立ち上げ

  ― JWTによる認証

  ― 管理画面の基本的な実装

  ― 管理画面へのLDAPによるログイン

  ― エラー処理

  ― AWS SNSによるプッシュ通知実装

 

【環境構築系】

 ・AWSの環境を作るterraformのテンプレート作成

 ・環境設定をするためのitamaeのテンプレート作成

 

村田:「便利だね」と周りのメンバーが積極的に導入してくれて、今では部署のエンジニアの9割以上が使用しています。

 

――部署のメンバーが「Daizu」を使い始めてから、開発効率は上がりましたか?

 

村田:著しく上がった実感があります。手前味噌ですが、「Laffy」というライブ配信フリマアプリを僕が1人で開発(※)した際に、「Daizu」を使ったことによって企画から開発、リリースまでの期間が3~4か月で済んだんです。それは間違いなく、「Daizu」の恩恵だと思っています。

 

※…リリース直前の時期にもう1名エンジニアが参画。

 

 

ライブストリーミング基盤も共通化。工数が1か月⇒1日へ短縮 

――その他にも、ライブストリーミングサービスを開発するための共通基盤も作り上げたと聞きました。

 

村田:そうなんです。このライブストリーミング基盤は、DeNAのインフラを担当しているIT基盤部のメンバーと一緒に作り上げていきました。

 

――その基盤ができる前の時代、エンジニアが「ライブストリーミングサービスを開発したい」と思った場合には、どういう手順を踏む必要があったのですか?

 

村田:「SHOWROOM」や「Mirrativ」など他のライブストリーミング系アプリのソースコードを読んで「どんな処理が実装されているのか」を理解し、さらに「インフラがどういった構成になっているのか」の知識も身につける必要がありました。

 

つまり、「サービス開発をしたいだけなのに、インフラも理解しなければいけない」状態になっていたんです。非常に効率が悪かったので、誰もが簡単にライブストリーミングサービスを開発できるようにするため共通基盤を構築しました。

 

 

その結果、ライブストリーミングの仕組みを「①管理ツールでサービスを生成・token取得」「②Gemで基盤からURLを取得する」「③URLをクライアントのフレームワークに渡す」という3ステップで実装できるようになり、相当に楽になったんです。

 

――この共通基盤を使用したことで、サービス開発の期間はどれくらい短縮できましたか?

 

平野:私がライブ配信アプリ「Pococha」を開発した際には、かつて1か月くらいかかっていた配信基盤の構築が1日で済みました。いや、正確には1日もかからなかったですね。

 

――1か月かかっていた作業が1日以下になった、というのは相当な効率化ですね。

 

平野:さらに、SHOWROOMやMirrativにはなかった機能もこの基盤には追加実装されており、独自進化しているんです。

 

――具体的には、どういった機能ですか?

 

平野:例えば、顔に美肌・美白のフィルターをかけたり骨格を補正したりして綺麗に見せる機能や、通信環境に応じて適切な画質に変更するといった機能があります。今後も、各アプリで共通して使いそうな機能があれば、積極的に取りこんでいく予定です。

 

 

「簡単に使える」からこそ、みんなが使ってくれる

――それらの経験を踏まえ、フレームワークや共通基盤を開発する際に、「こういうことに気をつけるといい」というポイントはありますか?

 

平野:そのフレームワークが「導入しやすい仕様になっているか」は非常に重要だと感じています。仮にフレームワークを開発しても、他のエンジニアから見て使いづらいものになっていれば、なかなか導入してはもらえません。

 

それこそ、「コードを1行追加するだけで使える」とか「ワンラインのコマンドを打てばすぐに実行できる」くらいに簡単にすることは非常に重要です。

 

例えば、「Daizu」には環境構築系の機能として「AWSの環境を作るterraformのテンプレート作成」があるんですが、これもシンプルなコマンドを打つだけですぐに使えるようになっています。もしこれが、複雑なコマンドを打つような仕様になっていたら誰も使ってくれなかったと思います。

 

――「この機能を共通化もしくは自動化したら便利になる」というアイデアは、どういったときに湧くことが多いですか?

 

▲「Daizu」を用いて開発されたサービス群。

 

平野:普段の業務の中で、特定の作業が3回くり返されたら、基本的には「自動化・共通化しよう」と考えています。そのくらいの回数出現したということは反復性のある作業であり、今後も継続的にくり返されるものなので。

 

あとは、その作業に「何人の人が関わるか」も重要な選定基準です。何かを自動化・共通化しても自分1人しか恩恵を受けられないのであれば、ほとんどメリットはありません。でも、多くのメンバーの作業が楽になるのであれば、自動化・共通化する意味は非常に大きいと思います。

 

 

「あのアプリもこのアプリも、自分の血が流れている」

――最後に聞きたいのですが、お2人が開発効率化の取り組みに“フルスイング”できたのは、どうしてだと思いますか?

 

村田:私はよく、「どうすれば、いいエンジニアになれるか」「どうすれば、いいエンジニアとして評価されるか」ということを考えています。それを実現するには、ただサービスを開発するだけではなく「部署やチームにプラスの影響をもたらせる人になること」がとても重要だと思うんですね。

 

そんなエンジニアを目指して、毎日の仕事に励んでいます。開発効率化の取り組みも、そうなるための行動の1つなんです。つまり、自分自身が成長したくてやっていることが、結果的に周囲のメンバーの役に立っている、というだけなんですよ。

 

平野:私はサービスを作ることが好きなんですけど、ライブラリやフレームワークも広義での“サービス”だと考えています。そして、そのサービスが、自分たちの開発しているアプリのDNAに少しずつ組み込まれていく、というのがすごく嬉しいですね。「あのアプリもこのアプリも、自分の血が流れている」みたいな(笑)。

 

つまり、「自分の開発したものが誰かの役に立っていること」がエンジニアとしてエキサイティングなんだと思います。それは、相手が社外のお客さまであっても、社内のメンバーであっても、変わらないんですよ。