自動運転技術と未来への取り組み

はじめに

オートモーティブ事業部の中西 葵です。事業部内の各プロダクト立ち上げのタイミングで様々なプロダクトにかかわらせて頂き、現在は、モビリティインテリジェント部という、オートモーティブ事業部の中でも共通的な役割を持って先端の技術に関わらせて頂いております。

先日、「自動運転技術の技術ロードマップと未来予測」というテーマで外部のイベントで登壇させて頂き、その一部をITエンジニアがオートモーティブ領域で活用している技術として抜粋してこちらの記事で共有させていただく事になりました。

ディー・エヌ・エーでは自動運転関連サービスのみならず周辺技術や有人時代から積み上げることで世の中に価値を還元したいという想いでモビリティサービス基盤を着実に構築し実績を積み上げていっております。

「自動運転業界は興味があるけど遠い世界」と感じているITエンジニアの方々にオートモーティブ事業を少しでも身近に感じて頂けましたら幸いです。

  • 自動運転技術の基礎
  • 自動運転周辺IT技術
  • 技術領域別の取り組み

の大きく3つに分けて解説させて頂きます。

自動運転サービス

自動運転というとどのようなものを想像されますでしょうか?

まず、AI、人工知能などの言葉と並び高度な技術を想像される方も多いでしょう。既に世界中の多くで語られている通り、人間同様にどこでも走れるような自動運転技術というのはまだまだ遠い未来の話ですが、限定的なエリアであれば既にサービスとしても始まっています。

国外の話になりますが、ちょうど先週発表になったのが元GoogleのWaymoが提供を開始したWaymo Oneです。利用できる場所もユーザーも限定的ですが、アプリで24時間いつでも車を呼び出して利用することが出来ます。

【参考】Introducing Waymo One, the fully self-driving service


自動運転技術の基礎

自動運転技術というと大きく「認知」「判断」「制御」に切り分けて話されることが多く、それぞれ以下の通りの内容です。

認知

ライダー、レーダー、カメラ、その他のセンサー類を用いて、車両周辺の障害物や周りの車の状況、車線、信号や歩行者等をリアルタイムで収集する技術です。各種データを用いて自己位置を推定するのもこちらに入ります。

【参考】いまさら聞けないライダー(Lidar)入門

判断

上の認知で認めたデータを元に信号が赤だったり、前方に車両がいた時に停車する。路上駐車を迂回、車線変更の判断などを行います。こちらのNVIDIAの動画が自動運転における認知、判断の処理が視覚的にわかりやすく表現されているので是非御覧ください。

【参考】NVIDIA DRIVE Autonomous Vehicle Platform


制御

判断した内容を元に車に対して実際に指示を出す部分です。自動運転車両のソフトウェアはROS(Robot Operating System)をベースに構築される事が多く、上の認知や判断を行う部分もROSのノードの一つして動作させます。

【参考】ROS (Robot Operating System)

セーフティ

基礎的な技術は上述のとおりですが、安全面では様々な課題を残したままになります。他にもセキュリティ面や、物理的にセンサーが壊れた場合にどうやってそれを補完するのか?など安全に車両を運行する上で必要なことは多数あります。 例えば古いニュースですが、有名なニュースなので記憶に残っている方も多いでしょう。走行中のジープをリモートから乗っ取ることが出来るという衝撃的な話です。

【参考】ドライバーに衝撃:走行中のジープの乗っ取りに成功


自動運転に関わる技術と言っても一言ではまとめられず様々な技術の組み合わせで道路を走行できるようになります。

自動運転の周辺技術

ここまで簡単に自動運転技術について書きましたが、DeNAではご存知の通り自動運転技術の開発は行っておりません。現時点で自動運転技術はパートナー企業様に開発をお任せしており、我々は過去20年に渡って積み上げたITの技術をどのように自動運転社会に活かしていくことが出来るのかを中心にサービスレイヤーの開発を主に行っております。

自動運転に関わるIT技術とはどのようなものでしょうか?DeNAの過去の取り組みを中心にIT技術を使って実現可能なものを見ていきましょう。「自動運転を実現するために必要な技術」であったり、「安全性を高める為に有ると良い技術」、ドライバーレスでのサービスを行う上で「必要となるであろうシステム」、そして、「有人サービスの段階でも必要」とされる技術などがあります。

ナビゲーションシステム

自動運転で車両が走行する為にまず目的地まで道路を案内する必要です。一般的なナビゲーションと同様にどの道を選んで走行するのが最適かを選択し指示します。

地図データ(道路ネットワーク)

ナビゲーションを実現するために道路情報をデータとして必要になります。道路の緯度経度や幅、制限情報などの情報を最新に保つ必要があり、それらの情報とリアルタイムな交通情報を元に現在どの道路を通るのが効率が良いかなどを判断することになります。

マップマッチング

地図データをナビゲーションに使用するためには自己位置を出来る限り正確に把握する必要があります。しかし、GPSのデータは正確ではない為、計算によって一番確率が高い場所を推定する為の技術です。 こちらのUberの動画がわかりやすいので興味が有る方は参考にしてください


高精度地図データ(3Dの空間情報)

先の地図データでは移動する範囲を大局的に見た処理になりますが、一般的に自動運転車両が走行するためには3Dの空間データを元に自己位置をより細かく車両の位置を特定する事でどのように移動するべきかという判断を行うことが出来るようになります。


信号データ

多くの自動運転車両ではカメラの映像を元に信号を判断する仕組みを開発していますが、予め信号から情報を取得することができれば、より安全に車両を運行することが出来るようになります。以下の記事のようにディー・エヌ・エーでは信号機から取得したデータを自動運転車両に送り込むような技術にも取り組んでいます

【参考】日本信号とDeNA、信号情報を自動運転車に送受信する実証実験を実施

映像のストリーミング

将来自動車がドライバーレスで運行することを想定すると、有事の際にはリアルタイムで遠隔から利用者様とコミュニケーションを取る必要が出てきます。そのために私達が検証を行っているのが5Gという高速な次世代通信技術を使った映像のストリーミングです。

【参考】NTTドコモとDeNA、自動運転車の遠隔操作を実証実験へ---5Gを使って

リモート管制システム

映像のストリーミングに限らず、リモートから全車両の位置や状態を把握する仕組みも必要になるため、こちらのような管制システムの開発も行っております。


スケジュール管理

自動運転車両に限らず、車両のスケジュールを効率的にする為のスケジューラーの開発も行っています。例えば荷物を集荷、配達順序をサービス全体として効率化することで、少ない車両台数で同じエリアを運行することが出来るようになります。

車両管理

先日東京進出を果たしたMOV(旧タクベル)では神奈川県及び東京エリアにおいて数千の車両から常に車両の状態が送られています。その車輌情報を元に、ユーザー様向けのアプリからの配車リクエストをリアルタイムで処理するようなシステムが構築されています

技術領域別

過去にオートモーティブ事業部で自動運転関連の業務で取り組んできたのは上記のようなものがありますが、高精度地図、信号データ以外は自動運転に限定した技術ではなく、幅広い領域で使われている一般的なものだと思われる方も多いでしょう。

他にも自動運転に関わらない領域で活用している様々な技術を日々活用しております。事業部全体を見渡してみると、ほとんどのプロダクトで最新の技術を駆使して開発を行っています。「大量のデータ」を「リアルタイム」で処理することを考えるとレガシーな技術ではスケールせず、私達が求めるレベルの品質でサービスを提供できないのが一つの理由です。

オートモーティブ事業領域に限らず、現在コンシューマ向けのサービスを考えるときにはモバイルアプリの開発は欠かせない技術になっています。Android, iOS, Webなどそれぞれの領域でのクライアントアプリの開発が必要になりますし、当然のようにバックエンドも必要になります。

それらを含め、技術を領域毎に分解すると以下のように分けることが出来ます。

サーバーサイド

サーバーサイドといっても幅が広すぎますが、現在オートモーティブ事業部ではAWSやGCPなどのクラウド環境を中心に利用しています。最先端の技術を積極的に取り入れるため「Google Cloud Next '18」や「AWS re:Invent 2018」 といった海外カンファレンスにも積極的に参加し技術の向上をしています。

MOV(旧タクベル)では以下の記事のようにAWSの機能を存分に活用した仕組みで運用されており、その後も進化し続けています。

【参考】タクシー配車アプリ「タクベル」を手掛けるDeNAがAWSを選択した理由

中でも特徴的で面白いのがAWS IoTです。タクシーからリアルタイムで情報を吸い上げるためにはスケールからその後のデータ処理まで考えることが多く、大量のデータを扱うことを考えるとコストもしっかりと考えていく必要があります。新しい技術をどのようにサービスに取り入れていくのかを考えるのは情報も少なく難しいことも多いですが、AWSの方とも密に連携を取りながら設計、開発を行っております。

フロントエンド

最近はスマートフォンの性能も良くなり、アプリのみならずWeb上での高いユーザビリティも求められています。そんな技術を存分に発揮できる環境です。また、様々なデバイスからのアクセスを想定した作りをしていく必要があり、レスポンシブデザインを基本としてWebサイトの開発を行っております。

【参考】【図解】レスポンシブデザインとは?定義、特徴、メリットとデメリットを解説

モバイルアプリ

アプリ開発もオートモーティブ領域においては多岐にわたります。一般的なサービス同様にGoogle Play StoreやApp Storeに提供するユーザー様向けのアプリ、自動車とつながる端末として、MOVの乗務員様向けアプリ、後部座席用タブレット向けアプリ、実証実験用にクローズドで提供する場合もあります。また実験用にアプリストアでは提供しないアプリも多数開発を行っています。念のために書いておくとiOSアプリの開発はSwiftでAndroidアプリの開発はKotlinです。

MOVではBLE Loggerというデバイスの開発を行っており、Androidアプリとタクシーメーターの連携をBLE Loggerを経由して行っています。常時接続し続け、遅延やデータの取りこぼしが発生しないような設計など、アプリストアに提供しているような一般的なアプリ開発では経験することが出来ない領域の開発も行います。

データサイエンティスト

オートモーティブ事業部では日々膨大な量のデータが蓄積し、分析されるのを待ち続けています。データ分析を待つ間にも新しい機能開発は進み、やるべきことは増え続けています。リアルタイムに24時間入り続ける交通データを元に難しい課題にチャレンジしたい方にとってはとてもエキサイティングな環境がそこにあります。

AI

DeNAでは「AI×インターネット」をキーワードに事業を広げていますが、オートモーティブ領域においても同様にAIを活用したサービスの開発を行っています。現在、力を入れているのがタクシーの需要予測になります。蓄積したデータとリアルタイムで入ってくるデータを元に需要予測を行った上でリアルタイムでナビゲーションを行うという世界を見渡しても例を見ない取り組みを行っております。こちらは私の所属するモビリティインテリジェント部を中心にAI事業部の皆様と開発を行っています。我こそはという方、興味があるので話を聞いてみたいという方、是非ご連絡お待ちしております。

まとめ

将来やってくる自動運転社会になる時に必要になるであろうサービスを有人の時代から徹底的に作り込み、ドライバーレス時代になったときにはスムーズに移行できるように長期的な視点に立ってものづくりを行っている集団がDeNAオートモーティブ事業部です。未来を作る為には大きな夢をもって難しい課題にチャレンジする必要がありますが、私達が使っている技術は特殊なものではないということを少しご理解いただけたかなと思います。新たなチャレンジを探している方、是非ご一緒に未来を創っていきましょう!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

無線 LAN の通信品質を見える化する話

これは DeNA Advent Calendar 2018 その2 の 7 日目の記事です。

こんにちは、IT 基盤部ネットワークグループの寺増です。

ネットワークグループでは、各サービスを提供している DC ネットワークの他、DeNA グループ全体のオフィスネットワークの管理・運用も行っています。

今回は、中でも日々重要性が増している無線 LAN の特徴と、それを安定的に運用するための通信品質観測の仕組みについて、本社ヒカリエを例に紹介します。

目次

  • はじめに
    • 無線 LAN とは
    • 有線 LAN との違い
    • オフィスの無線 LAN と家庭の無線 LAN
    • オフィスの無線 LAN で発生する様々な事象
  • 無線 LAN の通信観測の仕組み
    • リスト生成
    • データ収集
    • データ集計
    • データ蓄積/可視化
  • まとめ


はじめに

1. 無線 LAN とは

無線 LAN とは、国際標準規格 IEEE802.11 で定義される無線技術を用いたローカルエリアネットワークの総称です。 1999 年策定の 802.11a/b に始まり、11g, 11n, 11ac と続き、来年からは 11ax (Wi-Fi 6) の普及も始まる予定です。


2. 有線 LAN との違い

無線 LAN は、有線 LAN と異なる以下の特徴があります。

  • 通信の伝送媒体が電波である
  • 利用には電波法による一定の制約がある
  • 接続後のスループットが動的に変化する
  • ノイズの影響を非常に強く受ける
  • 上りもしくは双方向の通信が半二重である (2018 年現在)


3. オフィスの無線 LAN と家庭の無線 LAN

オフィスの無線 LAN は、家庭の無線 LAN とは異なる以下のような特徴があります。

  • 約 15 台のアクセスポイント (以下、AP) で一つのカバーエリアを構成している
  • 1 台の AP に対して、40 - 80 台程度のステーション (端末) が同時に接続する
  • 干渉源のデバイス (Bluetooth, デザリング端末等) が多く存在する
  • 高層階では、外来波である各種レーダーの影響を受けやすい


4. オフィスの無線 LAN で発生する様々な事象

前述のような特徴から、オフィスの無線 LAN では次のような事象が発生し「遅延」や「断」に繋がります。

  • 大容量通信による通信帯域の枯渇
  • スティッキークライアントによる帯域の浪費
  • 隠れ端末・晒し端末による余分な通信待ちの発生
  • AP 同士の相互干渉による余分な通信待ちの発生
  • 遮蔽物 (パーティション等) の構成によるカバレッジホールの発生
  • レーダーによる一時的な電波の停波、ひいてはカバレッジホールの発生
  • ノイズによる SN 比の低下、ひいては通信速度の低下
  • 通信周波数の変更による一時的な通信断
  • BSS トランジション発生時の一時的な通信断
  • 無線空間上でのフレーム消失によるパケットロス
  • その他、ステーション側のドライバに起因する様々な問題

ここに挙げた例の中には、ネットワーク機器側の情報だけでは実情の確認が難しいものも多く含まれています。

状況を正確に把握し、適切な措置を行う手段として、DeNA では icmp を用いた無線 LAN の通信品質観測を行っています。


無線 LAN の通信観測の仕組み

DeNA では、社内の ESSID に接続する全てのステーションの接続状態を計測・記録しています。

この仕組みは次のスタックで構成しています。

この仕組みにより、各ステーション・AP・フロア単位の通信品質を網羅的かつヒストリカルに可視化しています。更にこのデータを監視することで、大規模な通信遅延を能動的に検知し、続く改善措置までを一連の運用として行っています。

全体構成は以下のようになっています。

itpf-networkg-wifi-01_20181204.png

各処理について順に説明します。

1. リスト生成

AP に接続しているステーションの情報は、全て上位にある無線 LAN コントローラに記録されています。このフェーズでは、その情報を元にデータ収集の対象リストを Fluentd のコンフィグとして生成します。

無線 LAN のステーションは状態が動的に変化するため、このコンフィグも一定周期で再生成・リロードしています。

ここで生成している Fluentd のコンフィグは、以下のようなテンプレートを元にしています。

<source>
  @type       exec
  command     /bin/ping -i <%= ping_param[:interval] %> <%= client[:ipAddress] %>
  keys        rtt
  tag         foobar.<%= client[:ipAddress] %>
  time_key    time
  time_format %Y-%m-%d %H:%M:%S
</source>

<filter foobar.<%= client[:ipAddress] %>>
  @type       record_modifier
  <record>
    mac          <%= client[:macAddress] %>    // ステーションの MAC アドレス
    vendor       <%= client[:vendor] %>        // MAC アドレスを保有しているベンダー名
    ip           <%= client[:ipAddress] %>     // ステーションの IP アドレス
    ssid         <%= client[:ssid] %>          // 接続している SSID 名
    ap           <%= client[:apName] %>        // 接続している AP 名
    loc          <%= client[:location] %>      // その AP を設置しているフロア名
    rssi         <%= client[:rssi] %>          // ステーションで感知している信号の減衰量 (信号強度)
    snr          <%= client[:snr] %>           // S/N 比 (信号強度と雑音強度に基づく電波品質の指針値)
    proto        <%= client[:protocol] %>      // 接続周波数帯
    user         <%= client[:userName] %>      // 接続時に利用した証明書の CN
  </record>
</filter>


2. データ収集

データ収集には Linux 標準の ping コマンドを利用しています。前項テンプレートの <source> 部分が該当箇所です。この結果を Fluentd の exec Input Plugin でパースし、RTT のみを抽出して結果値に採用しています。

Linux の ping コマンドはタイムアウトを出力しませんが、タイムアウト自体を見る必要がないため意識はしていません。これは、ping のインターバル、応答数とそれぞれの RTT が判ればタイムアウト回数も逆算出来ることが背景にあります。


3. データ集計

ソースデータが常時止めどなく流れるストリーミング系であるため、この集計処理には Norikra を採用しています。このフェーズで、ステーション毎の 1 分間のデータ件数、平均 RTT、最大 RTT を算出して、元データに付与します。

無線 LAN は移動等で RTT が変動するため、平均の算出時には Norikra::UDF::Percentile によるパーセンタイルも行っています。

本社ヒカリエには日々 2000 以上のステーション (スマホ、タブレットを含めると更に倍以上) が存在しています。それらのデータを個別に集計する仕様から、ここには多めの RAM を充当して並列で処理を行うようにしています。

ここで生成される最終的なデータは、以下のようにモデルになっています。

{
  "mac": "11:22:33:44:55:ab",                // ステーションの MAC アドレス
  "vendor": "Unknown",                       // MAC アドレスを保有しているベンダー名
  "ip": "192.168.0.1",                       // ステーションの IP アドレス
  "ssid": "ssidName",                        // 接続している SSID 名
  "ap": "AP01",                              // 接続している AP 名
  "loc": "System Campus > HIKARIE > 20F",    // その AP を設置しているフロア名
  "rssi": -43,                               // ステーションで感知している信号の減衰量 (信号強度)
  "snr": 51,                                 // S/N 比 (信号強度と雑音強度に基づく電波品質の指針値)
  "proto": "5GHz",                           // 接続周波数帯
  "user": "foo@bar.baz"                      // 接続時に利用した証明書の CN
  "count": 4,                                // 1 分間に記録されていたデータの件数
  "max_rtt": 105,                            // 1 分間に記録されていた RTT の最大値
  "min_rtt": 18.4,                           // 1 分間に記録されていた RTT の最小値
  "percentiled_rtt": 89.7,                   // パーセンタイル・カットした RTT の基準
  "avg_rtt": 45.32500000000012               // 1 分間に記録されていた RTT の平均値 (パーセンタイル後)
}


4. データ蓄積/可視化

このフェーズで、Norikra によって生成されたデータを Fluentd によって引き戻し、そこから Elasticsearch にポストしています。Fluentd から Elasticsearch へのデータの引き渡しには、Elasticsearch Output Plugin を利用しています。

これを Kibana から参照することで、各ステーション・AP・フロア単位、それぞれの通信品質を可視化を実現しています。

以下は DeNA で実際に利用している Dashboard のサンプルです。アクセシビリティ向上のため、フロントエンドは別途用意しています。

(a) フロア単位

itpf-networkg-wifi-02_20181204.png

(b) AP 単位

itpf-networkg-wifi-03_20181204.png


まとめ

以上、無線 LAN の通信品質を観測する仕組みについて簡単に紹介させて頂きました。

最後までお読み頂きありがとうございました。

DeNA では、Delight and Impact the World もさることながら、それを成し遂げる過程も非常に大事にしています。この過程の品質に磨きをかけられる手法はどんな奇抜なアイデアでも大歓迎です。

こんなアイデアあるよ! という方、是非我々と一緒に DeNA の運用業務に携わってみませんか。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA QA Night#1開催レポート(第一部)

はじめに

みなさんこんにちは。品質管理部の柏倉です。コマース系、エンタメ系サービスのQAを担当しています。 先日(2018/11/27)、DeNA QA Night#1と称してソフトウェアテスト、品質関連のイベントを開催しましたのでそのレポートをしたいと思います。 記念すべき第一回目となるDeNA QA Night#1では招待講演にデバッグ工学研究所の松尾谷徹氏をお迎えし、ご講演いただきました。それから、第二部としてDeNA品質管理部の紹介と、DeNA品質管理部が取り組んだテストプロセス標準化のお話を紹介しました。今回はその第一部、松尾谷徹氏の講演についてレポートしたいと思います。

DeNA QA Nightを発足した背景

まず初めに、そもそもなぜこのイベントを開催しようと思ったのかについてお話ししたいと思います。DeNAには品質管理部という独立した組織が存在していて、品質向上のために日々業務に取り組んでいます。オンサイトとオフサイトを合わせて、その数なんと750名!毎日750名もの人数が品質向上のために稼働しています!

しかし、これほどのパワーをかけている部門にも関わらず、その地名度は低く、DeNA社内においても「品質管理部??知らないなぁ」という人がいるほどでした。社外における知名度も同様で、DeNAに品質管理組織がある事は知られていませんでした。これはいかんという事で、社内・社外双方で知名度&プレゼンスを上げなければならない!そのための活動の一環として社外向けのQA関連イベントを主催しようという事になり、DeNA QA Nightの開催に至りました。また、イベントを通じて世の中の品質関連技術の向上に貢献したいという思いもあります。世の中の技術力向上と品質管理部のプレゼンス向上を両立すべく、今後も継続して開催していく予定ですのでみなさまのご来場を心よりお待ちしております!

DeNA QA Night_logo.jpg

心配をよそに大盛況!

品質管理部のプレゼンス向上の一環として立ち上げたDeNA QA Nightですが、そもそも品質管理部の知名度が低いのでイベントを開催したところでどれくらいのお客様にご来場いただけるのか、スタッフ一同ものすごく不安を感じながら募集を開始しました。イベントの1ヶ月前から参加希望者の募集を開始したのですが、最初はちょっと弱気で『80名くらい来てもらえたら嬉しいね』くらいの気持ちでした。ところが!公開して数日で募集人数を大きく超える応募をいただき、あっという間に応募枠が埋まってしまいました!皆様本当にありがとうございます!これに気を良くしたスタッフ一同は『あと100名くらい増やしてみようか』とか言い始めます。スタッフ一同調子に乗っちゃってるので誰も止める者はなく、勢いで本当に100名ほど枠を増やしてしまいました!結果的に、募集枠180名に対し、約260名のご応募をいただきました。まさかこんなに応募をいただけるとは思っていなかったので、本当に驚きましたし、嬉しかったです!募集枠に入りきらなかった皆様、今回はお会いできず残念ですが、是非#2でお会いできる事を楽しみにしております!

松尾谷徹氏の講演から感じた事

さてここからは、招待講演にてご講演いただいたデバッグ工学研究所の松尾谷徹氏のお話から個人的に感じた事などを書いてみようと思います。大きな印象としては、我々QA担当者にとって辛辣な問いを投げかけられているように感じました。QA担当者はこれからどうなるのか。絶滅危惧種として難民化するのか、はたまたコントリビューターとして繁栄するのか。

(以降、松尾谷氏の許可を得て講演資料から一部抜粋して画像を掲載しております。)

dena_qa_night_1_1_slide1.png

本題に入る前にQAの本質について私なりの解釈を交えて少し述べてみようと思います。講演の一節にQAの本質は測り、良否の判断ができる事とありました。この部分を私なりに解釈して説明します。従来からQAは良否の判断をするために仕様とソフトウェア動作を比較してきました。ソフトウェアの動作が仕様と異なっていれば否、合致していれば良としていたわけです。これはつまり仕様が無ければテストが出来ないという事を示しています。もし仕様に定められていない動きを見つけた場合は良否の判断が出来ないためです。そのような場合どうするかと言うと、見つけた動きを仕様とするのか、あるいはもっと良い動きに修正するのかを検討し、最終的に仕様化します。つまり、テストの実態は仕様記述だったわけです。

dena_qa_night_1_1_slide2.png

そしてここからが本題になるのですが、これからの時代は仕様記述だけのQA担当者は生き残れないと言う事をおっしゃっていたように思います。ここについても私なりの解釈を交えて少し述べてみます。QA担当者の役割が「仕様に対して良か否か」を判断する事から「社会や文化に対しての良否」を判断する事に変化してきています。また、情報サービスが主役となる時代において、情報そのものの正しさをいかに保証するかも品質における課題となっています。それから、品質に対する考え方も変化してきているように思います。テストで徹底的にバグ出しをして、不具合が出来るだけ含まれない状態でプロダクトを出荷する事に重きを置いていた時代から、OSSを用いてソフトウェア開発を進めるようになって以降は現実的で合理的な品質保証にシフトしてきているように感じます。このような時代において、仕様通りにプロダクトが作られているかを追求するだけではもはや品質は保証出来ません。では、我々QA担当者はどうすれば良いのでしょうか...

dena_qa_night_1_1_slide3.png

松尾谷氏曰く、キーワードは「Contribution」だそうです。google翻訳に聞いてみると「貢献」と教えてくれました。松尾谷氏の経験上、海外の人と一緒に働くとだいたい聞かれるのは「お前のContributionは何?」との事。世界的な流れとしてContribution(貢献)が求められるようになってきている模様です。我々QA担当者もこの流れには逆らえないと思います。難民化しないためには『Contributerである事が大切』と松尾谷氏はおっしゃっていました。講演の後、品質管理部内で解釈をすり合わせてみた結果こうなりました「規範的な批評家QAではなくて、開発やサービスにcontributionできるQAである事」。これはDeNA品質管理部と同じ方向性を示しています。その事に気が付いた時、皆とても嬉しそうにしていました。これからも我々品質管理部はサービス品質向上に向け、あらゆる面でContributionしていこうと再認識出来た講演でした!この場を借りて改めてお礼を述べさせていただきます。松尾谷様、貴重な講演ありがとうございました!

dena_qa_night_1_1_slide4.png

テストプロセス標準化のお話

DeNA QA Night#1の第二部では、DeNA品質管理部より品質管理部の紹介とテストプロセス標準化のお話をさせていただきました。この様子は追ってブログで公開します。お楽しみに!

宣伝

connpassグループへのご参加をお待ちしております!

DeNA QA Nightは主にconnpassでの応募となります。是非グループ登録をお願いします! DeNA QA Nightグループページへ

Twitterフォローお願いします!

DeNA TechCon 2019を開催します!

DeNA TechCon 2019 を2019年2月6日(水)に開催します!みなさま、ぜひご登録下さい!! techcon2019_logo.png

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

DeNA Engineers' Blogをリニューアルしている話

@mazgiです。
これはDeNA Advent Calendar 2018の3日目の記事です。

せっかく社のBlogを書くことになったので社のBlogリニューアルについてご紹介します。 今日2018/12/03現在みえているこのBlogのリニューアルを「Engineers' Blog編集委員会(仮)」という有志の横断的な組織で進めていてだいぶ形になってきました。
(Advent Calendarには間に合いませんでした)

きっとこんな見た目になります!
we-just-building-new-dena-engineers-blog.screenshot.png

技術Blogやオウンドメディアの長期運用あるあるな話としてどなたかのご参考になればという気持ちで書かせていただきます。

なぜリニューアルするのか?

リニューアルする理由をざっと書き出すと次の3点です。

  • もっと活性化してほしい
  • 機能追加やシステム更新がつらくなってきた
  • オンプレミスでのセルフホスティングをやめたい

順にご説明します。

もっと活性化してほしい

今のこのBlogはMovable Type製なのですが、全社員にアカウントが払い出されているわけではなく、初めて記事を書くときにBlog専用アカウントを申請する運用になっています。
また書いてから公開されるまでのフローは整備されてはいるのですが当事者以外からはなかなか知ることができず、その結果新たに「Blogを書いてみようかな」と思ったときに「どうやって書くんだろう?」「どういう内容ならOKなんだろう?」「誰にレビューお願いすればいいんだろう?」といった疑問が心理的障壁になっていることがわかりました。

これを解消するため前述の「Engineers' Blog編集委員会」で「もっと気負わず思いついた時に誰でも記事を書けるようにしたい!」と話し合いました。

機能追加やシステム更新がつらくなってきた

DeNAは元々腕利きのPerl Mongerな方々が集まっていた会社でもありこのBlogのシステムは2010年頃にMovable Typeで構築されたようです。
ところでDeNAは来年2019年で20周年だそうです。IT企業として20年、すごいですね!老舗ですね!
この機会に技術Blogもシステム刷新してもいいのではないでしょうか?

前述の活性化を行うにしてもイマドキな方が色んな方に書いていただけそうですし、長く運用できそうです。
Blog編集委員会では「新し目で運用負荷低い仕組みを目指しましょう」と話し合いました。

オンプレミスでのセルフホスティングをやめたい

20世紀からWebサービスを作っておられる多くの会社がそうだと思いますが、DeNAもオンプレミスとパブリッククラウドを併用している会社です。
しかしこの度パブリッククラウドに完全移行することが決まりました :tada:
ところで2010年頃に構築されたBlogのサーバーは? ...オンプレミスです。移行しましょう!

編集委員会でも「パブリッククラウド上でサービスするのは当然としてインスタンス立てたくないね」と話し合いました。

ちなみに全社インフラのクラウド移行については弊社オウンドメディア@ITでも記事にしていただいていますのでご参照ください。
また、2019年2月のTechConでも紹介される予定ですのでこちらもぜひご参加ください。

どうやってリニューアルを進めているか?

先ほど上がった理由をブレイクダウンし、それぞれの課題を解決する方法を考えていきます。

どうやってもっと活性化しやすくするか?

まず、Blogシステムの概観をどうすれば活性化しやすいくなりそうか話し合いました。

世の中には色々な素晴らしいBlogサービスやCMSが存在することも改めて確認し、同時にエンジニアリングやデザインのリソースが少し取れそうだったので自前実装という道も生まれました。
これらの状況を加味した上で自由度とセキュリティ担保や今後の運用とを秤にかけ「薄く自前実装しよう」という方針が決まりました。

それが今の私たちにとって、システム面でも文化や雰囲気の面でも、もっともバランスの良い形に思えたのです。

まず"書きやすいシステム"にする

技術Blogの主なWriterとなるエンジニアが"書きやすいシステム"について考えた結果以下を決めました。

  • 普段使っているGitHub(Enterprise)に集約しよう
    • 記事内容はもちろん、記事執筆のフローもGitHub的にしよう
    • Pull Request -> Review && Merge -> CI/CD で記事が公開されるようにしよう
  • Markdownで書けるようにしよう
    • フォーマットの好みは色々あれどMarkdownは大抵の人が書いたことあるはず
  • 社内向けBlogを併設してもっと気軽に記事を書けるようにしよう

GitHubへの集約ですが、この画像のようなリポジトリのmasterにMarkdownで書かれた原稿がMergeされると公開されるようにしました。
(Private Repositoryですが全社員がメンバーとして設定されています)
we-just-building-new-dena-engineers-blog.0090.png

レビューは何かを開発するときと同じようにPull Request上で行えますが、Push毎にこのように記事をプレビューできる専用のURLが発行されます。
we-just-building-new-dena-engineers-blog.0050.png

このプレビュー用URLは社内から誰でも閲覧できるので例えば法務や広報といった、GitHubアカウントを持っていない方にもレビューに参加していただけます。

最後の「社内向けBlog」については、「『社名とともに世界に公開される』と考えると気後れしてしまうかもしれないけど、社内限定公開なら何書いても恥ずかしくないよね!」という気持ちで作ることにしました。

  • 「内容軽すぎない?」=>「1 tip(s)だけでも大丈夫です、社内限定公開なんで」
  • 「これ社外秘かも...」=>「社内の人が知ってて大丈夫なら書いて大丈夫です、社内限定公開なんで」
  • 「社内のあれこれ知らないと伝わらない」=>「読む人みんな知ってるので書いてください、社内限定公開なんで」

という感じで記事を書くハードル下げられるといいな!と思ってます。
社内向けBlogも公開Blogもリポジトリが異なるだけで仕組みや原稿フォーマットは一緒なので、社内限定記事を公開記事に変換する時はリポジトリ間でファイルをコピーするだけです。
社外秘な社内限定記事は後日社外秘じゃなくなるように編集して公開すればいいですし、社内知識が前提となっている社内限定記事は先に社内知識を説明する記事を公開すればいいですよね!

"書きやすい雰囲気"にする

DeNAで掲げている「DeNA Quality」の1つに「透明性」があります。
言葉通り「正直でオープンなコミュニケーション」を是とするいたって真っ当な姿勢なのですが、今回の一連のBlogリニューアルの動きとしてもこの「透明性」を強く意識しています。

リソースのほとんどはGitHubに集約され、全社員がアクセスできます。
we-just-building-new-dena-engineers-blog.0030.png

タスク一覧や進捗はGitHub Projects(カンバン)上で公開されており、自由にカードやIssueを作ることができます。
we-just-building-new-dena-engineers-blog.0040.png

SlackでのやりとりもPublic Channel上で行われ、
we-just-building-new-dena-engineers-blog.0080.png そのままでは流れ去ってしまうSlackコメントは必要に応じてGitHubのIssueコメントとして蓄積されます。
we-just-building-new-dena-engineers-blog.0081.png そしてGitHubでのコメントや色々なアクティビティはSlackのPublic Channelに通知されます。
we-just-building-new-dena-engineers-blog.0082.png

DeNAでは開発業務に従事していない方などGitHubアカウントを持っていない方もいるのですが、Slackアカウントは全員が持っているので、誰でもこれらの情報にアクセスしコメントすることができます。

こうやって記事やレビュー内容だけに留まらず経緯までオープンかつ正直に残しておくことで、今だけではなく将来にわたって「あ、こんなカジュアルでいいんだ」と感じてもらえたらいいな!と思っています。

どうやって機能追加やシステム更新を行いやすくするか?

まずどんなシステムにしてどんなサービスを使ったところで、そのままではいずれ機能追加が行えなくなり更新がつらくなると考えています。
それはきっと避けられないのでしょう。

なのでせめて2018年に考えられる継続的にアップデート可能な"オープンな普通の仕組み"を作ろうと努めました。
具体的には以下のツールやサービスを組み合わせてBlogを構成しました。

HugoとTerraformはOSSですし、その他のXaaSはどれも有名で調べればすぐに情報が得られます。
また2030年くらいまでにはBlogのリニューアルが避けられなくなるかもしれませんが、むしろもっと短いイテレーションで頻繁にシステム構成自体を再考し更新し続けられたらうれしいですね!

パブリッククラウド上でどのような構成にするか?

今からオンプレミスのサーバーを新規構築しないのは当たり前として、Blog編集委員全員に「インスタンス立てたくない!」という強い気持ちがあり、サーバーを立てない前提で話が進みました。
これだけ色々なマネージドサービスが提供されている2018年にBlogのためにサーバーを運用するリソースはもったいないですね。
そのリソースはDeNAのサービスを使ってくださっている皆さまのためにもっと違う形で使いたいものです。

構成は前述の通りなのですが、それぞれ以下のような点を考慮しました。

Markdown

平易なテキストフォーマットなので他のシステムへの載せ替えも容易。

Hugo

Apache 2ライセンスのOSSでライセンス上の検討事項が少ない。
Golang製でバイナリファイル1つで動く。バイナリさえ保持しておけば先々「本体は入手できてもライブラリが入手できない」といった事態を避けられる。

GitHub Enterprise / CircleCI Enterprise

DeNA内で標準的に利用されており世間的にもデファクトスタンダードと言える。

Terraform

MPL 2ライセンスのOSS。
Hugo同様Golang製でバイナリファイルといくつかのモジュールだけあれば動く。
IaCのとても著名なツールと言え情報も多い。

AWSの各リソース

AWS自体はいうまでもなく世界有数のクラウドサービスプロバイダで情報が大変多い。
もちろんDeNA内でも広く使われている。

Blog閲覧時のアクセス経路は、公開/社内向けそれぞれ以下の通り。

公開Blog: Browser -> CloudFront -> S3
社内向けBlog: Browser -> CloudFront -> WAF -> S3

更新時はCircleCI上でHugoにより生成されたHTML, CSS, JavaScriptなどをS3にアップロードしている。

さいごに

いちばん最初に載せさせていただいたかっこいいBlogテーマはデザイン担当の方が作ってくださいました!
(かっこいいので再掲)
we-just-building-new-dena-engineers-blog.screenshot.png

Blogリニューアルの初期は仮テーマということにして私が作ったテーマで実装してたんですけど、見比べていただけるとどれくらいかっこよくしていただいたかわかると思います(

そして残タスクはデータ移行。。
どんなシステム刷新も最後に残るのはデータ移行ですね。
完全な自動マイグレーションは難しそうなので今色々とディスカッションしてます。
we-just-building-new-dena-engineers-blog.0010.png

DeNA「Engineers' Blog編集委員会(仮)」ではこのように技術Blogのリニューアルを検討中です :muscle:
Slackでコミュニケーション取ったり、
we-just-building-new-dena-engineers-blog.0020.png 意見はフィードバックいただいたり、
we-just-building-new-dena-engineers-blog.0070.png we-just-building-new-dena-engineers-blog.0060.png オフラインで集まったり、 we-just-building-new-dena-engineers-blog.0100.jpeg

進めていますので次は「リニューアルしました!」とご報告できることを楽しみにしています。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

ライブ配信を支える技術と知識

こんにちは、IT 基盤部の高橋です。
DeNA が提供するエンタメ系やヘルスケア系のサービスのインフラを見ています。
大規模ライブ配信を支える技術については DeNA TechCon で弊社漢が紹介しています (2017, 2018) が、今回は大規模ライブ配信を支える技術をさらに支えるライブ配信の基礎知識について紹介します。

通信プロトコルの種類

映像を届けるためのプロトコルには数多くの種類がありますが、弊社では主に以下の二つを利用しています。

  • RTMP (Real Time Messaging Protocol)
    • その名の通りリアルタイムにメッセージをやり取りするために開発されたプロトコル
    • Flash Player での利用を想定されている、映像や音声を通信させることができる
    • 持続接続のプロトコルで、状態を持つ
    • 映像は JPEG/H.263/VP6/AVC(H.264) のコーデック、音声は Linear PCM/ADPCM/MP3/AAC/speex のコーデックに対応
  • HLS (HTTP Live Streaming)
    • HTTP を通してストリーミング配信をできるようにしたもの
    • 配信される映像を記録したプレイリスト (m3u8) とメディアセグメント (ts) を使って、映像を届ける
    • マスタプレイリストにメディアプレイリスト含めることで複数のビットレートを扱うことが出来たり、DRM 対応などもできる
    • HTTP なので Apache や Nginx からでもライブ配信することが出来る (= CDN と親和性が高い)

映像コンテナの種類

映像コンテナ (マルチメディアコンテナ) には以下のようなものがあります。 これらは動画や音声を格納することができます。

  • MPEG-2 TS (mpegts/mpeg2ts)
    • 地上波デジタルや Blu-ray/DVD などで使われるコンテナ
    • 188 バイトの固定長パケットに映像や音声、プログラム情報を記録する形式となっている (TS パケット)
    • PID が同一のデータを集めることで音声や映像を復元することができる
  • MP4 (quicktime mov)
    • QuickTime の mov が元となって作られたコンテナ
    • 複数トラックを記録させることやメタデータの記録も可能となっているため多重化できるコーデックなら記録できる
    • Movie Fragment という 3GPP 規格もあり分割された映像として記録もできる
  • flv (rtmp)
    • FlashVideo で利用できるコンテナ
    • 映像・音声以外にもファイルやスクリプトも埋め込める
    • rtmp の形式とほぼ同じであるためストリーミングで使える
    • 格納できる映像コーデックが VP6/H.264/On2、音声コーデックが MP3/AAC/Speex など

コーデックの種類

映像や音声の圧縮形式で、分かりやすい例だと zip 圧縮か rar 圧縮かの違いです。 tar.gz をコンテナとコーデックとして表現すると、映像や音声を tar コンテナでまとめて gz コーデックで圧縮していると表現できます。

  • H.264 (AVC = Advanced Video Coding)
    • 動画圧縮形式、フレーム間予測やエントロピー符号化方式など高い圧縮率をもつ
    • プロファイルによって利用目的に応じて適切な値を定義できるようになっている
    • 4K までの映像を扱うことができる
  • H.265 (HEVC = High Efficiency Video Coding)
    • H.264 の後継、H.264 におけるブロックノイズの低減や同ビットレートでも 40 %近い圧縮率を出せる
    • 8K 映像やスーパースローのような高 fps も扱うことができる
  • VP6/VP8/VP9
    • On2 のビデオコーデックの一つ、VP6 は H.264 よりも高い圧縮率とデコードが早い
    • ライセンス問題で H.264 よりも普及しそうでしていない

Mux/Demux について

コンテナにデータを入れることを Mux
コンテナからデータを取り出すことを Demux
と呼びます。
Mux は Multiplexing のことで多重化とも呼んでいます。

Screen Shot 2018-11-19 at 15.14.14.png

フレームとフレームレートについて

30 fps の映像とは、1 秒につき 30 枚の画像に分割している映像のことです。
分割された画像はフレームと呼ばれます。
フレーム数が多いほどより滑らかに映像は表現されるが、フレーム数が増えるためデータサイズが増えます。
そこで動画では分割したフレームを I フレーム・P フレーム・B フレームに分類し映像の差分だけを記録するようにしています。 I フレーム・P フレーム・B フレームの集まりのことを GOP (Group Of Picture) と呼びます。

  • I フレーム
    • 元となるピクチャのこと
    • ほぼ全ての情報が格納された映像フレームで、データサイズが一番大きい
    • キーフレームとも言う
  • P フレーム
    • フレーム間の差分ピクチャのこと
    • 差分映像フレームで、データサイズは小さめ
  • B フレーム
    • 補正フレーム
    • ベクトル差分の補正を行うフレーム、次のフレームまでの補正差分を持つ、データサイズは最も小さい

画素数について

1920x1080 や 1280x720 などの 幅x高 を示す単位です。
FullHD だと 1920x1080 の画素数で HD だと 1280x720 の画素数となります。
いずれも16:9が基準となっています。
また、表現にもいくつかあるため、

  • 1080p と表記がある場合は 1920x1080 のプログレッシブ画像である
  • 1080i と表記がある場合は 1920x1080 のインタレース画像である
  • 1080p60 または 1080p/60 と表記がある場合は 1080p の 60 fps 映像である

ビットレートについて

画質の良さに比例する単位で、3Mbps や 500Kbps のように bps (bits per second) で表現します。
転送量に密接に関わってくる数値となります。
配信側も視聴側もこの帯域が利用できるようになっている必要があります。

プロファイルについて

映像コーデックによっては映像の種類に応じてプロファイルと、エンコード強度 (符号化) レベルなどを定義されています。
それぞれビットレートや処理負荷に影響します。
下記はH.264のプロファイルの一例です。

  • baseline
    • I + P フレームのみ
  • main
    • I + P + B フレーム
  • high
    • main + 高ビットレート

映像を届けるための仕組み

用語の定義

  • Origin
    • Origin サーバ、映像を受け付けるサーバのこと
    • Publisher から映像を受取り、このサーバで受け付けた映像は配信するための形式に変換され、Edge サーバから取り出され Viewer に届けられる
    • 必要に応じて Publisher から受け取ったストリームを変換することもある (transcode)
  • Edge
    • Edge サーバ、映像を配信するサーバのこと
    • 映像は Origin サーバから取り出して配信を行う
    • 多数の Viewer が接続する、そのため同じストリームの接続は束ねられ複数の Viewer が居ても Origin への接続数を減らす役割を持っている (offload)
    • Viewer の利用するプロトコルに応じて Edge は映像の届け方を変えている
  • Publisher
    • 映像の配信元、配信者のこと
    • カメラやマイクから受け取った映像・音声データは Publisher 側でエンコードし、映像データとして Origin に送信している
  • Viewer
    • 映像を見る端末、視聴者のこと
    • 視聴者には利用環境に応じて、視聴形態が違う

ストリームについて

RTMP を例にすると、RTMP 内では Video パケットと Audio パケットがパケットとして流れています。
それぞれのパケットには時間が記録されているので、Video パケットと Audio パケットの時間を同期しながら再生させることで音ズレせずに映像が流れます。

Screen Shot 2018-11-24 at 0.05.32.png

Publisher から Origin に届くまで

配信者はエンコーダを使いながら、ビデオカメラやマイクから拾った映像・音声を適切に変換しながら Origin にストリームを流しています。
エンコーダには FMLE や OBS などがよく利用されます。

Screen Shot 2018-11-24 at 0.08.58.png

Origin から Edge に届くまで

Origin ではある程度の映像パケットを受信したら、Edge サーバで利用可能な形式のパケットに変換します。
例えば 2 秒チャンクを生成し、Edge へは 2 秒チャンクを配信します。
この 2 秒チャンクを生成するためには、H.264 などの映像では I フレーム (キーフレーム) が記録されていないと映像を構成することが出来ないためある程度のバッファが必要になります。
つまりフレームレートとキーフレーム挿入間隔によって I フレームでの分割を行いつつ Edge にデータを転送しています。(= 遅延時間)

Screen Shot 2018-11-24 at 0.09.57.png

Edge から Viewer に届くまで

Edge では Origin から受け取った映像データを繋ぎに来ている Viewer 全てに同じデータを配信する作業を行います。
ただし、Viewer によっては視聴タイミングが違ったりするため、一時的なキャッシュを行う (= chunk size) ことがあります。
また、Viewer 側でもある程度のバッファを積むことがあります。それはネットワークの帯域が一定でない場合に数秒間バッファ積む事で映像の乱れを防いでいるものです。(NetStream#BufferTime など)
RTMP などのリアルタイムストリームについてはそのまま届けることができますが、遅延が発生する場合はこの部分である可能性が高いです。

Screen Shot 2018-11-24 at 0.10.49.png

以上、ライブ配信を行う上で必要な各基礎知識についての概要を説明してきました。
DeNA では SHOWROOM や pococha などの様々なライブ配信サービスを、ここで触れた基礎知識以外にも様々な工夫やノウハウを駆使して提供しています。
ぜひ DeNA で我々と一緒に学びながら研究しませんか。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

ソフトウェアエンジニアリングシンポジウム併設ワークショップで発表してきました

はじめに

はじめまして、品質管理部の河野です。
所属は品質管理となっておりますが、普段はいわゆるQAマネジャやQAエンジニアという立場で主にヘルスケア関連のサービスのQA業務全般に従事しております。また、その他には部門横断の改善活動や新規サービスのQAの立ち上げにも注力しております。
特にQAの立ち上げは、初期段階で基礎固めをすることが非常に重要だと考えています。それで、昨年末からあるサービスのQAの立ち上げの案件がありましたので、色々と勉強をしながら仕組みづくりをしてきました。

9月に掲題のワークショップでQAの立ち上げ事例を発表してきましたので、少し時間が経ってしまいましたが、簡単に当日の様子や発表内容をレポートしたいと思います。

なぜ発表するのか?

さて話は変わりますが、私は年に一度くらいの頻度で社外発表するように意識しているのですが、皆さんはいかがでしょうか。
私は以下のような理由で定期的に社外発表するようにしています。

  • 業務(の成果)の棚卸しをする
  • 上記の業務(の成果)に対して世の中一般の立ち位置を明らかにする
  • 原稿(論文)を書くことで文章を作成する力を維持する
  • 普段のルーティンな生活に刺激を与える
    などなど

当日の発表

シンポジウムの会場が大学ということもあり、30人程度で一杯になるような小さな教室で参加者は10名強という小規模なワークショップで発表しました。学術系のシンポジウムの併設ワークショップということで、大学の先生や学生が参加者の半数くらいの割合を占めていました。
発表時間は大まかに管理されていたものの、比較的自由度が大きく発表後にフリーディスカッションを行うような形式でした。その中で、色々なフィードバックが得られたことが今回の収穫でした。

発表内容

さて、「はじめに」で簡単にお伝えしたようにQAの立ち上げの事例の発表になるのですが、アジャイル開発という文脈でQAの困りごとを整理して、その解決アプローチを検討すると言った発表になります。
詳細は、こちらのポジションペーパと以下の発表資料に譲りたいと思います。

アジャイルソフトウェア開発における テスティングの課題およびその解決アプローチ from Tetsuya Kouno

おわりに

すでにこちらでもレポートが出ておりますが、今後もDeNAの品質管理部では認知度を高めるためにも社外発表を進めていく予定です。 また、DeNA QA Night というイベントも企画しております。

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

builderscon2018に参加してきました

こんにちは! コマース&インキュベーション + ブロックチェーンR&D部門のエンジニア、緒方です。

9/6,9/7,9/8で、3日間(前夜祭も入れると4日間)に渡り、「builderscon2018」が開催されました。 DeNAのエンジニアも私含め、3名登壇しております。 少し発表から時間が空きましたが、オフィシャルからフォトやムービーが公開され始めたこのタイミングで 登壇者からのコメントなどを交えつつ参加レポートを書きたいと思います!

buildersconとは

「知らなかった、を聞く」をテーマとした国際テックカンファレンスです。 毎年1000人以上のエンジニアが集まり、5トラックでのトークが行われる大規模なイベントです。 技術を愛する全てのギーク達のお祭り銘打ち、トークに関して、技術的な制約などはないと公式でアナウンスされているため、 様々なエンジニアリング観点で、幅広い題材をテーマにトークが繰り広げられるのが特徴です。 DeNAはじめ、数多くの企業が協賛しており、関心の高さが伺えるイベントになっています。

18_09_07_a_002.jpg

登壇したエンジニアより

当日登壇したエンジニアから、発表内容やCfPを出した背景などについてコメントをいただきました。

1. ブロックチェーン(DApp)で作る世界を変える分散型ゲームの世界

あらためまして、 コマース&インキュベーション + ブロックチェーンR&D部門のエンジニア、緒方文俊(@oggata)です。

今回は、DeNAでもR&Dとして研究を進めているブロックチェーンを題材に発表を行いました。 CfPを出した経緯は、社内でもブロックチェーン技術のサービスを考える時に、 仮想通貨のような投資観点としてのみ、認識されている事が多く、 技術として、もっと面白いアプローチがあることを知って欲しいという部分を内外にアピールしたいと思ったことがきっかけでした。

カンファレンスでは、 自身の趣味で作成しているブロックチェーン惑星探索ゲーム「PlanetTravelers」を題材にしつつ、 ゲームという分野において、どのような活用ができるのかという観点で話をしました。 (PlanetTravelersは惑星を旅し、発見した惑星をブロックチェーンに書き込みを行うゲームです。)

ブロックチェーンという技術自体初めてという方も多かったため、 基礎的なところから始めて、簡単なハンズオンのような形で、手元のスマートフォンでゲーム内の土地を所有体験してもらったり、実際にスマートコントラクトを書くところまで、 1時間という時間でしたが、幅広く説明をさせていただきました。

18_09_07_d_091.jpg

2.事前知識なしで理解する、静的検査のいろは

SWET (Software Engineer in Test) グループ所属の Kuniwak (@orga_chem) です。

今回の CfP で伝えたかったことは、(1) 静的検査の仕組みがどうなっているか、(2) 静的検査が意外と簡単だということ、の2点です。なお、この発表内の知識は、私が OSS として公開している静的解析ツールの開発経験を通して得た学びがもとになっています。

この発表で触れるさまざまな基礎技術は、静的検査はもちろん、メタプログラミングやトランスパイラ、独自プログラミング言語の開発にも役立つ重要なものです。これらを技術の引き出しとして覚えておけば、今後の開発体験を豊かにしてくれることでしょう。 18_09_07_e_102.jpg

3.遠いようで身近なサウンドエンジニアリング

オープンプラットフォーム事業部所属でソフトウェアエンジニアとして働いている@karupaneruraです。

今回は「遠いようで身近なサウンドエンジニアリング」という題のCfPを採択して頂き、それについて話をしました。普段はソフトウェアのエンジニアリングをしています。 サウンドエンジニアリングというと聞き慣れない方もいらっしゃると思いますが、ここでは音楽のレコーディング、ミキシング、マスタリングなどの技能を指しています。 僕は趣味で自分のバンドの自主制作CDのレコーディングなどをやるのですが、素人なりにその課題や面白さを知ってもらいたいと思い、このCfPを応募しました。 また、せっかく「知らなかった、を聞く」という素敵なテーマを持ったカンファレンスですから、ソフトウェアエンジニアリングに限らずもっと幅広い話題が集まるきっかけになれば良いなという思いもありました。

内容としてはデモンストレーションも交えて音の性質とそれにまつわる問題、それをどのようなものをつかって解決していくか。といったことを話しました。詳しくはスライドか動画をご覧頂ければと思います。 これを通じてサウンドエンジニアリングについて知って頂き、あわよくばやってみたい!とか、エフェクトや音源がどのように実装されているのか気になる、自分で実装してみたい!と思ってくれる方がいてくれたら嬉しいなと思います。

18_09_08_ b_032.jpg

おわりに

登壇後に、ブロックチェーン関連の勉強会に参加したのですが、 自分の登壇を聞いて、興味を持って参加しました、と言ってくださった方が数名いらっしゃっていたり、 TokyoBitcoinHackathonで優勝した方が、 自分の発表をきっかけに勉強を始めたとtwitterでメッセージをくださったりと、とても嬉しいことがありました。 運営のみなさまにはこの場を借りてお礼を申し上げたいと思います。 また来年も参加したいと思います!

buildersconの公式HPはこちら

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

ECCV 2018で発表してきました

はじめに

皆さんこんにちは。DeNA AIシステム部の李天琦(leetenki)です。DeNAのAIシステム部では、物体検出、姿勢推定、アニメ生成等、様々なComputer Vision技術の研究開発に取り組んでいます。また、AIシステム部では世界の最新技術トレンドをキャッチアップするために、年一回国際会議に自由に参加する機会が設けられています。今回は、ドイツ ミュンヘンで開かれたComputer Visionに関する世界トップの国際会議の一つである「ECCV 2018」について、AIシステム部のメンバー5名で参加してきましたので、その内容について紹介したいと思います。また、今回は聴講としてだけでなく、DeNAからもWorkshop論文が1件採録され、濱田晃一(下図右)と私(下図左)の2人で発表してきましたので、その様子についても紹介したいと思います。

Image from iOS (4).jpg

ECCVとは

ECCVの正式名称は「European Conference on Computer Vision」で、CVPR、ICCVと並ぶComputer Vision分野における世界三大国際会議の一つです。ちなみにComputer Visionというのはロボット(コンピュータ)の視覚を指し、広義は画像認識、映像認識の技術分野全般を意味しています。そのComputer Visionの分野において世界三大国際会議の一つがこのECCVです。そして近年ではDeep Learningを始めとするAI技術の飛躍的な進歩により、あらゆるComputer Vision分野でDeep Learningを使う事が当たり前になってきているので、ECCVでもDeep Learningの手法を応用した論文が大半の割合を占めるようになりました。

スクリーンショット 2018-09-23 18.08.47.png

今年の開催期間は9/8〜9/14の7日間です。最初の2日と最終日は特定のテーマに絞ったTutorial & Workshopで、あいだの4日間がMain Conferenceです。また、Main Conferenceの4日間では、Expoと呼ばれるスポンサー企業の展示会も並行して行われ、世界をリードするIT企業の最新の研究成果や製品などが展示されました。

開催場所

今年の開催場所はドイツのミュンヘンで、GASTEIG Cultural Centerという、劇場・図書館・大学が一体となった大型文化施設を貸し切って会議が開かれました。

1171537694457_.pic_hd.jpg

[会場のGASTEIG Cultural Center]

近年AI技術への注目の高まりを受けて、ECCV参加者は年々増加し、今年は参加者も採録論文数も過去最高となりました。統計によれば、今年の投稿論文数は2439本で、採録論文数は776本でした。そして今回のECCV参加人数は3200人以上と、ECCV 2016の時と比べて倍以上にものぼっています。

スクリーンショット 2018-09-28 23.06.42.png

[参加者の統計]

スクリーンショット 2018-09-28 23.06.52.png

[投稿論文数の統計]

セッションの様子

ECCVに採録された論文のうち、評価の高かったものはOralと呼ばれる口頭発表形式のセッションで発表されます。その場でデモを行うものもあります。それ以外はPosterと呼ばれるセッションで発表され、著者と直接ディスカッションを行うことができます。

スクリーンショット 2018-09-28 23.09.56.png

[Oralセッションの様子]

ネットワーキングイベント

Main conference期間中、初日の夜に「welcome reception」と、3日目の夜に「congress dinner 」という2つの公式ネットワーキングイベントが開催されました。今回は時間の都合でcongress dinnerには参加できませんでしたが、初日のwelcome reception partyでは立食パーティ形式で世界各国の研究者達と親睦を深める事ができました。

1151537694262_.pic_hd.jpg

[Welcome receptionに参加してるDeNAメンバー]

また、会議公式のイベントとは別に、多くのスポンサー企業が会場近くのカフェやクラブを貸し切って、独自のネットワーキングイベントを開催していました。今回濱田と私が発表したFashion, Art and Design Workshopでも独自に懇親会を開催していたため、そちらにも参加し、世界各国のFashion, Art関連の研究者と仲良くなる事ができました。

受賞論文

今回ECCVで発表された論文の中で、受賞されたものをいくつか紹介します。

  • Implicit 3D Orientation Learning for 6D Object Detection from RGB Images まず、今年のECCV Best Paperに選ばれたのが、こちらのImplicit 3D Orientation Learning for 6D Object Detection from RGB Images (Martin Sundermeyer et al.) です。

スクリーンショット 2018-09-23 22.24.12 (1).png

[Martin Sundermeyerらの提案手法の全体の流れ]

この論文を一言で要約すると、6D物体検出(3次元空間座標だけでなく3方向の向き姿勢情報も含んだ検出問題)を高速に行う事ができ、かつ6Dのラベル付き教師データがなくても学習可能という画期的な手法です。ただし、6Dラベル付き教師データの代わりに、検出対象となる物体の3D CADデータが必要となる点に注意が必要です。 もう少し具体的に全体の処理の流れを説明すると、まず入力となるRGB画像に対してSSDを用いて対象物体のBounding Boxを推定し、その後、推定されたBounding Box領域から物体の姿勢情報を推定するという処理を行います。実は後半のBounding Box領域から物体の姿勢情報を推定する部分がこの論文の一番の重要なポイントで、ここで独自のAugmented AE(AutoEncoder)というものを提案しています。

スクリーンショット 2018-09-28 23.23.24.png

[Augmented AEの構造]

このAugmented AEというのは、背景や遮蔽を含んだ物体画像を入力した時に、背景や遮蔽を取り除いて対象物体だけが映る画像を出力するように訓練されたCNNです。このネットワークを訓練するには、背景を含む物体画像とそうでない画像のペアの教師データが必要ですが、そこでCADデータを使い、ランダムに集められた背景画像と合成した人工的なデータセットで学習を行います。また、あらかじめ対象物体のあらゆる姿勢の画像をCADデータから生成し、Augmented AEで潜在表現を計算しておいて、データベースに蓄積しておきます。これによって、テスト時に検出されたBounding Box領域をAugmented AEのEncoderに入力して、得られた潜在表現とデータベースにある潜在表現の照合検索を行う事で、高速に姿勢情報を推定する事ができます。

  • Group Normalization 次はHonorable Mentionを受賞した2本の論文のうちの1つであるGroup Normalization (Yuxin Wu et al.) を紹介します。

スクリーンショット 2018-09-28 23.23.34.png

[Group Normalizationを含む各種正規化手法比較]

こちらの論文はかの有名なKaiming He氏も共著に入っており、とてもシンプルでかつ有用なDeep Learningにおける正規化手法です。通常、Deep Learningの学習にはバッチ正規化 (Batch Normalization) という手法がよく使われますが、その性能はバッチサイズの大きさに依存し、バッチサイズが小さくなるにつれて不安定になるという問題があります。そこでこの論文では、バッチ単位ではなく、入力チャンネルをいくつかのグループに分け、各グループ単位で正規化するというアイデアを提案しています。これにより、バッチサイズが小さい場合でも有効な正規化を実現しています。

  • GANimation:Aanatomically-aware Facial Animation from a Single Image 最後に紹介する論文が、2本のHonorable Mention受賞Paperのうちのもう1本であるGANimation:Aanatomically-aware Facial Animation from a Single Image (Albert Pumarola et al.) です。

スクリーンショット 2018-09-28 23.23.42.png

[Albert Pumarolaらの提案手法全体像]

こちらの論文では、最近AI分野で注目を集めている敵対的生成モデルのGAN (Generative Adversarial Network) を使った顔表情生成の手法を提案しています。キーとなるアイディアは、顔画像を生成する際に、入力画像に加えて「Action Units (AU)」と呼ばれる条件変数も一緒にGeneratorに入れることです。このAUというのはもともと心理学の分野におけるFacial Action Coding Systemで用いられる概念で、人間の顔のそれぞれの表情筋に対応する30種類のAUの組み合わせで7000以上の表情を表現できるとのことです。このAUを条件変数として一緒に使うことでよりリアルかつ自在な顔表情を生成できるようになります。既存手法のStarGANでは離散的な表情変化しかさせられなかったのに対し、連続的に表情を変化させられるところがポイントです。また、表情に関係しない部分を保持したまま表情のみを変えるためにAttentionを利用するという工夫もなされています。

スクリーンショット 2018-09-28 23.24.00.png

[Attention maskを含むGenerator図]

DeNAのPoster発表

今回、会議最終日のFirst Workshop on Computer Vision for Fashion, Art and Design Workshopにて、DeNAからも1件の採録論文ががあり、First Authorの濱田と私の2人で発表を行いました。

スクリーンショット 2018-09-29 0.21.03.png

[Fashion, Art and Design WorkshopでのPoster発表の様子]

スクリーンショット 2018-09-24 0.18.59.png

[PSGANのPoster]

こちらが今回発表してきた『HD高解像度の全身アニメ生成』の論文 (Full-body high-resolution Anime Generation with Progressive Structure-conditional Generative Adversarial Networks) です。この論文では、各解像度で構造条件付けられたGeneratorとDiscriminator を進歩的に成長させるGANs (PSGAN) により、従来難しかった、構造一貫性を持った高解像度での生成を実現しています。また、DeNAではこれまでにMobageサービスで蓄積してきた10万点以上のアバターの3Dモデルデータを保有しており、それを活用してPose情報付きの独自のアバターデータセットも構築しています。

avatar.gif

[PSGANの生成結果]

より詳細な内容はこちらのプロジェクトページで解説していますので、興味ある方はぜひこちらをご覧ください。

全体の感想

今回のECCV2018で、私としてもDeNAとしても、初めての大きな国際会議での論文発表を行いました。私は聴講として毎年CVPRにも参加していますが、一番大きな違いはネットワーキングのしやすさだと感じました。学会で新しく知り合った研究者と雑談する時、必ずと言っていいほど「今回のカンファレンスでどんな論文を発表するんだい?」のような質問を聞かれます。聴講での参加ですとそこで話題が途切れてしまいますが、発表者として参加するとそこから論文の話が広がり、より広く交流を深める事ができました。DeNAでは毎年国際学会に参加する機会が設けられていますので、次回行く時もできれば論文発表者として参加し、更に言えば本会議でのOral発表も目標に目指したいと思います。

参考文献

  • Martin Sundermeyer, Zoltan-Csaba Marton, Maximilian Durner, Manuel Brucker, Rudolph Triebel. Implicit 3D Orientation Learning for 6D Object Detection from RGB Images.
  • Yuxin Wu, Kaiming He. Group Normalization. arXiv:1803.08494 [cs.CV]
  • Albert Pumarola, Antonio Agudo, Aleix M. Martinez, Alberto Sanfeliu, Francesc Moreno-Noguer. GANimation: Anatomically-aware Facial Animation from a Single Image. arXiv:1807.09251 [cs.CV]
ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

GDG DevFest Tokyo 2018 に参加してきました!!

技術企画の tachikei です。9/1 GDG DevFest Tokyo 2018 にスポンサーとして参加しましたので、その報告をします。

エンジニアによる登壇

Goらしいコードを業務でも書くために

devfesttokyo2018_1 © GDG DevFest Tokyo 2018

Go らしさを説明しつつ、学び方のアイデアを発表したスライドです。これから Go をはじめられるエンジニアの方に参考になる内容だと思います。

パネルディスカッション: AAC実践導入について

devfesttokyo2018_2 © GDG DevFest Tokyo 2018

Android Architecture Component について、各社でどのように活用しているのかのパネルディスカッションです。サービスにより差はありますがDeNA では現時点では Data Binding、Lifecycles、ViewModel、LiveData、Room などが利用されています。 ProcessLifecycleOwner を利用したプロセス単位での foreground/background 判定の活用例や、Room の良い点や課題に感じる点等についてのお話をしました。

※ https://tokyo2018.gdgjapan.org/android

スポンサーブース

devfesttokyo2018_3.jpg

スポンサーブースでは、タクシー配車アプリ「タクベル」の実機デモとネットワーク構成図の展示をおこないました。

タクシーの配車依頼から、タクシー乗務員向け端末での配車対応、タクシーメーターなどの車載器とのシステム連携といった一連の流れにそって、実物を触りながらサービスを体験することができます。

ネットワーク構成図では、主にバックエンドで利用している技術要素を説明しました。タクシーの位置情報などの収集・管理にはAWSを、配車の受付から配車するタクシーの決定などアプリケーション部分はGCPというように、用途に応じて最適な技術を組み合わせて利用しています。参加者からも各クラウド製品の使い分けなど具体的な質問が多く、現場エンジニアが詳細に説明させて頂きました。

おわりに

DeNA は様々な事業に取り組んでいて、様々な技術的課題が発生します。それらへの取り組みやそこで得た知見を、少しでもお伝えできればと考えています。

ブースまで足を運んでいただいた皆様、滞りなくイベント運営をされたスタッフの皆様、発表およびブース設営に関わった皆様、ありがとうございました。今後も積極的にコミュニティ活動を応援したいと思います。引き続きよろしくおねがいします!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る

ソフトウェア品質シンポジウム2018 に登壇しました

はじめに

こんにちは。システム本部品質管理部QC第二グループの小林元樹です。
普段の業務では、ゲーム以外のモバイルアプリケーションやWebサービスのQAを担当しております。

先日9月12(水)~14日(金)で開催された ソフトウェア品質シンポジウム2018 に一般発表枠で登壇してきましたー。
ということで、今回は現地のレポートではなく発表した内容についてご紹介したいと思います。

その前に、そもそも「ソフトウェア品質シンポジウムって何?」という方もいらっしゃると思いますので、まずはそちらをかんたんにご説明させていただきます!

ソフトウェア品質シンポジウムとは

かんたんに説明すると、ソフトウェアの品質を良くしたい人達が講義や発表を通じて情報共有し、より良い活動に役立てるための場です!
しっかりしたイベントで年々参加者も増え(今回は3日間で延べ2,000名超え)、ソフトウェア品質に関する国内最大級のイベントのようです。
そして、何を隠そう小林は今回初参加でして、正直参加する前は下記のようなイメージを持っていました。

  • 品質保証・品質管理を生業としている方達が参加する会なのだろう
  • なので、きっとテスト技法や手法に関する講義や発表をする場なのだろう
  • すごい専門的なことばかり話されて理解できなさそう
  • ある程度知識がある人向け?敷居高そう

しかし、参加したあとはイメージが変わりました。

  • 参加者はテストに精通した人ばかりではなく、さまざまな業種の方が参加している
  • 実例を基にしたソフトウェア開発やテストの現状、そして今後の傾向などの新しい情報や基本を知れる
  • 取り上げる課題はテストに関することだけではなく開発工程での取り組みなどさまざま、その中から興味があるものを聴講できる
  • 各自の経験を基にした分析結果や取り組みの紹介・提案形式なので理解しやすい

みたいな感じで、参加する前は違ったイメージを持ってたんだなーと思いました。
そして実際に聴講することで色々参考になることもあったのですが、今回そのあたりは割愛します。

ソフトウェア開発に関わる方には有益な情報を得られるイベントだと思いますので、ご興味がある方は次回参加してみるとよいかと思いますー。

本題の発表してきた内容のご紹介

思ったよりソフトウェア品質シンポジウムの宣伝をしてしまいました。。
さて、そろそろ本題に移ります!
今回「テスティングロールに基づく人材マネジメントの取り組み」というタイトルで発表してきました。

テスティングロールに基づく人財マネジメントの取り組み from genkikobayashi

詳細を説明しだすと登壇した内容を文章にするだけになってしまうので、概要だけお伝えします。
====================
弊社では、大小さまざまな種類のサービスが急激な拡大や変化を繰り返しており、またその運用フェーズでは恒常的なエンハンスが発生し、それに対しての品質保証(QA)業務が発生している。そのようなサービスの急激な拡大・変化に伴って、QA業務を担う我々の部門の人員も急速に増加している。
そして、それら人員の多くは、テストベンダから派遣されたメンバで構成されており、またプロパーのメンバはそのようなQAメンバのマネジメント業務が一定の割合を占めている。そのようなテストベンダからの急速な人員増加に伴い、技術・マネジメント領域を問わず様々な問題が発生するようになった。
本取り組みではマネジメント領域に焦点を当て、QA業務とQAメンバのスキルがマッチしない問題やQAメンバのモチベーションに関する問題を取り上げ、その解決のためにまずQAメンバのスキルレベルをテスティングロールとして定義した。この定義において、テスト業務を遂行する上で必要な業務要素をテスト技術・マネジメント技術の両面から洗い出し、4つの技術領域の枠組みを定め、その枠組で業務要素を整理した。次に、テスティングロールに基づきQAメンバのアサイン・QAメンバのモチベーションという観点で活用法を検討し、実際に2年以上の運用を行った。
本発表では、以上の取り組みに加えて、2年以上の運用を経たテスティングロールの有効性を評価するために実施したアンケートの結果についても報告する。
====================
概要で興味を持っていただけたら、スライドを参照いただけると幸いですー。

最後に

今回初参加のシンポジウムで、さらに人生初の登壇だったのですが、実際にやってみると思ったより緊張しないものですね~。 (練習に付き合ってくれた方のおかげだと思います)
機会があれば、また登壇してもいいかなーとか思ったり、思わなかったり。。

ということで、この記事を通じてDeNAの品質管理部のことを少しでも知っていただけたら嬉しいです!

ツイート
シェア
あとで読む
ブックマーク
送る
メールで送る