Developers Summit 2016で個人的に興味深かったセッション備忘録

かれこれ5年前から抜歯したほうが良いと歯科で指摘されていた親知らずが、今年に入ってから本格的に疼き出し人生初の抜歯という恐怖に耐え、2週間前に抜歯したら、何だかとってもスッキリしている代表の国本です。

さて、2/18(木)、19(金)の2日間に渡って開催された「Developers Summit 2016(デブサミ2016)」に参加してきました。

実はデブサミに参加するのは、タイミングの問題で今年が初めてなのですが...。
多くのセッションに参加することができた中で、個人的な観点から興味深かったセッションを5つピックアップして簡単に備忘録を書いてみようと思います。
※なお、デブサミ2016の講演者情報や関連資料はこちらにまとめられているようです。

Day 1 (2/18)

実感駆動でものづくり ユーザーストーリーマッピングで想いと体験をつなごう

スクラム開発におけるユーザストーリーマッピングの活用方法と、それらが生み出す価値のお話。

「Controlled Failure」

一定周期で開発を繰り返し、継続的なデリバリーを実現するスクラムにおいては、失敗を起こさないことが重要なのではなく、その失敗をどうコントロールし、次へ生かしていくか？「Controlled Failure」という点をスプリントで振り返ることが非常に重要なポイント。

ユーザーストーリーマッピング

実際にプロダクトを利用するユーザの視点から、プロダクトの利用ストーリーを時系列順で作成し、それらに対して重要度による優先順位付けを行うことで、プロダクトが満たすべき仕様を可視化して、チーム全員で共有するための手法がユーザストーリーマッピング。

ユーザの利用ストーリのフローは一列に並べることで、利用するユーザにとってどこが痛みとなり、どこが喜びのポイントなのか？を判断することができる。

ストーリーはとりあえず、今欲しい物を全部書き出し、それをチーム全員で整理し、横が時系列、縦が重要度で並べ、その上並べられたストーリに対して、リリースの線を引くことで、リリース線より上に存在するストーリーをリリースの対象とする。(つまり縦軸の重要度で仕切る)

会社にとって価値があり(valuable)、ユーザとって使えるプロダクトであり(usable)、実際に作ること・実現が可能(feasible)それらを可視化することがユーザストーリーマッピングの一連の流れとなる。

アジャイルにおける改善効率化の目的

アジャイル開発をすすめる際に、経営サイドと開発チームのプロダクトゴールに関する乖離をヘッジするため、バックログを作り上げる際に、意見をまとめて、フィルターを行い、重要度をつけるプロセスをしっかり行う。ここでユーザストーリーマッピングが一つの例。

アイディア、機能要件、性能、仕様、要求に対してインクリメンタルに開発を進めることでユーザの求める成果を生む出すが、この生み出すまでのアウトプットをできるだけ小さくし、成果を大きくしていかないといけない。

そのために、各種の自動化、小さく機能的なチーム、組織構造の改革を行うことで、チーム中心で大きな成果を生み出せるようにする。

アジャイルにおける改善効率化は決してコスト削減だけが目的ではなく、改善・効率化を進めることで少ないリソースでより多くのプロダクトを生み出せ、結果投資となり最終的に売上をアップさせることができる。

本セッションを聞いて、実際に自分自身でプロダクトに対するストーリーを作成する際に同じような事を意識していましたが、ユーザストーリーマッピングのように体系的に一つの手法として整理されていることで、より活用しやすいと感じたため、早速ユーザーストーリーマッピング購入しました...。

データ分析で始めるサービス改善最初の一歩

IIJさんが自社で開発・運用されているクラウドサービスを対象にデータ分析基盤を導入したお話。

データ分析を導入した経緯

単発の障害検知を目的とした監視がメインとなっていたため、クラウドサービス全体の傾向が捉えられず需要予測が難しい、そして予防的なパフォーマンス改善が行えないという課題があり、解決に向けてログの収集・分析基盤の導入を決意。

ログ収集・分析基盤の導入

まず、ログの可視化として、Flumeでの収集、ElasticSearchでの蓄積、Kibanaで可視化を実施。

この構成において

• ログ容量の大きさ(20GB/1日)
• 各ログのフォーマット差異
• スタックトレースが生で吐かれている
  という点が初期に課題となった。

そこで、分析対象からスタックトレースを除外しApacheだけに絞り込みを行い、加えてFlumeにEsperを組み込むことで、ログの加工を行った所、結果的に10分の1までログ容量を抑えることが可能となった。

このような形で収集したログを、ElasticSearchに投入し、Kibanaで集計するため、テンプレートをセットし可視化を実現。
※ElasticSearchにおけるIndexの定期的な削除が重要

今回、ログ収集・可視化においては、収集の枠組みを後付で作ったため苦労したので、システムを構築する際にログを集める前提でフォーマットや収集が必要なログ情報を選別しておくと楽。

解析について

収集したログに対してHiveを活用した解析と、R機械学習による傾向の変更・検知を導入。

まず、Hiveでの分析を行うために、Flumeで自社クラウドのオブジェクトストレージへ収集ログをPutするSinkを自作。

オブジェクトストレージに格納されたログをHiveで解析することで、様々な利用傾向が見えてきたが、Hiveでの解析処理が属人化してしまい、この段階で機械学習を導入することを決意。

手始めに異常値に関する指標として、速度やバイト数などの閾値ベースで行ってみるがうまくいかず、結果的に機械学習のアルゴリズムを採用。

アルゴリズムを選ぶための試行錯誤はあったものの、Rのライブラリが非常に充実していて、コード一行書くだけでも様々なアルゴリズムを試すことができた。

本セッションを聞いて、Rを活用した機械学習ライブラリの充実っぷりが気になり、とりあえず試してみる分には敷居がそこまで高くなさそうなので、R素晴らしいなっと...。

その他、ログ収集のソフトウェアとして、FluentdではなくあえてFlumeを選定した根拠をお聞きしたかったなぁ...。

JavaScript.trend(spec) 最新言語仕様を軸とした JavaScript の最先端解説

これまでのJavaScriptが歩んできた歴史と時代背景、ES6(ECMA2015)をベースとしたモダンなJavaScriptの書き方、そしてJavaScriptの高速化における取り組みのお話。

特に興味深かったのは、JavaScriptの高速化で、型推論やJITエンジンの改良、そしてasm.jsの登場により、C言語と比較しても2倍程度の速度に迫っているという所でした。

セッション後に更に資料がアップされているとのことでしたので、もう一度読みなおし、今後のJavaScriptの方向性を腹に落としこみ理解する必要があるなと強く感じています。

Yahoo! JAPANの実践から学ぶ、超大規模Webシステムのフロントエンドとインフラ

Yahoo! JAPANにおけるフロントエンドの状況と、超大規模な自社インフラのお話。

Yahoo内でのフロントエンド事情

Yahooはこれまでサーバーサイドサービスが多く、JavaScriptを専門で書けるようなエンジニアが少ないため、シングルページアプリケーション(SPA)やCommonJS/ES6、JSフレームワークはこれまであまり手を付けていなかった。

新規のサービス開発では、CommonJSスタイルやES6などを活用している。

大規模プロダクトのリニューアル

Yahooのような大規模プロダクトをリニューアルする場合、かなりの工数確保が必要となる。
リニューアルをしながらも、日々の機能改修や追加は止まらないので、それらに追従しながらのリニューアル作業という前提で、単純計算で2倍の人間が必要。

リニューアル側の作業が遅いと、機能改修・追加に一向に追いつくことができないという事態に...。

JSフレームワークを統一しようとした話

jQueryとBackboneで開発されているサービスを全てAngularJS 1系統に統一しようとしたが、大規模過ぎて現状では3割くらいしか実現できてない。

そして、この間にJS界隈ではReactが出現し、AngularJS 2系統が出てきてしまい、このような状況下でいまさらAngulaJS 1系統で統一はないでしょう...。

そして、結論としてはフレームワークを統一しない！という事に。

技術選定の方向について

• 言語仕様は近しい未来の話なのでPolyfillを活用し未来を先取りして実装することでプロダクトの寿命を引き延ばす
• 新しく出現してきた概念に関してはチェックしておく
• フレームワークは本質的な機能は近しいため、今後の言語仕様に沿っているかが選定のポイント

技術を取り入れる時期は、対象とするプロダクトの規模によりけりだが、大規模の場合は直ぐに採用ではなく、話題後、半年から1年程度経過してその段階でも筋が良さそうであれば、取り込むような形が良いと考えている。

大規模開発に適した方法

• 仕組みの共通化(ESLintやMocha、タスクランナーや、プルリクのフォーマットなどを統一化)
• モジュールの共通化(各プロジェクトのディレクトリ構成を揃えるとかだけでも効果はある)
• 属人化の回避(担当をシャッフル、別プロダクトをレビューしたり、別プロダクトのテストを担当するなど)

OpenStackと大規模環境でのコンテナ利用

YahooはOpenStackによって物理レイヤを利用者に意識させないようにしている。

• APIのフォーマットが変わらないことが重要
• 異なる環境でも同じAPIで動作することが重要
• インフラのAPIはアプリに近づくことが前提

データセンタ抽象化の一例としてOCP(Open Compute Project)を採用していて、初期にOpenStack基盤で導入し検証後、後に大規模なHadoop基盤へ展開した。

アプリケーションレイヤでのライフサイクル

Dockerコンテナの利用において、大規模なインフラ環境ではコンテナ層でネットワークのレイヤーを増やすことはトラブルを増加させる要因となり得る。

Docker層とIaaSでネットワークを構成するのは辛いため、実環境においてはCalicoなどの純粋なIPネットワークを重視している。

また、コンテナを手でデプロイするのは現実的に辛いので、デプロイ自動化するとしても、その前段側でもろもろ自動化を考えるポイントがあり、揃えるものは結構多いと考えている。

現状、YahooではVMが8万くらい稼働していて、これらを全てオーケストレーションで自動化してる。

Day 2 (2/19)

日本発IoTプラットフォームビジネスへの挑戦 ～ SORACOM 立ち上げ格闘記 ～

IoTにおける様々な課題に対して、オープンでフェアなプラットフォーム「SORACOM」を立ち上げ現在に至るまでのお話。

SORACOMのサービスは発表時からかなり興味をもっていましたが、今回デブサミ2016で「SORACOM API Sandbox」が発表され、より気軽に簡単にSORACOMのAPIを触れる環境が開放されたので、これは是非近日中に触って見なければと思っています。

サービス以外にも特に興味深かったのは、SORACOMのチーム開発と運営体制のお話で、全員がリーダーとして取り組み、年齢や入社時期で壁を作らないように全員があだ名で呼び合い、メンバー全員が率直な意見・提案が言えるような関係性を築いているという点。

チーム内で徹底したオープンでフェアな関係性が築かれているからこそ、オープンでフェアなIoTプラットフォームというSORACOMが生まれているのかと感じました。

全体的な所感

セッション以外で、サイボウズさんが運営されていたジャングルカフェのWi-Fi品質がピカイチで、セッションの合間に仕事も進めることができ、とてもありがたかったです。(なんとドリンクもオールフリー)

個人的には有料でも良いので、今回のジャングルカフェのような高品質のWi-Fiスポット＆カフェを幾つか会場内に準備してもらえると嬉しいです。

デブサミ参加は今年初でしたが、取り上げたセッション以外にも非常に面白そうな内容のお話が多く、満足の二日間でした、来年も是非参加したいと思っていますので、よろしくお願いしますm(__)m

kuni