デブスト2019講演メモまとめ
実家でみかんをいっぱい食べました。
どうも。あんです。
昨年11月末に、U30限定・若手エンジニア向けカンファレンスイベント、「Developers Boost2019」に参加してきました。
遅れ馳せながら、その講演内容のメモを何とか見せられる形にねりねりしましたので、こちらに公開いたします。なお、用語説明や記事リンク等は、こちらで後から勝手につけたものになります。
感想はこちらの記事にてまとめています。
前置き
Developers Boost2019
日時：2019年11月30日(土) 13:00-19:30
場所：サンシャインシティ会議室
- Developers Boost デブストとは
翔泳社が主催する「Developers Summit」からスピンオフした、U30限定・若手エンジニア向けの技術カンファレンス。2019年のテーマは「これが私の戦い方」。
A-1 自分の可能性を広げよう！ エンジニアとしてのキャリア
Microsoft Cloud Developer Advocates 千代田まどか
# 千代田まどかさん
通称「ちょまど」 エンジニア兼漫画家
新卒入社SIer(三か月で辞める)→iOS/Androidアプリのスタートアップ→日本マイクロソフト→米国マイクロソフト(現在)
Microsoft Cloud Developer Advocatesとは、Microsoftと開発者との橋渡し役。開発者の皆が楽しく開発できるようコミュニケーションをとり支援する。
英語ができると海外のデベロッパーの方と交流できて、技術セッション等ができる。(楽しい！)
ここで伝えたいこと
- 好きで打ち込めることを見つけてほしい（ODD、オタ駆動開発）
- あなたの人生です 自分の人生に責任を持てるのは自分だけ
- Follow My Heart. 自身の心に従ってほしい
- 「オタク」とは ここでは
推しに対して並々ならぬ愛をもっており、それに対し時間や労力、お金などを投資している人 をいう。
# 経歴
幼少時：入院生活、お絵かき大好きな子供だった。
中学時：ハリポタにはまり、中学時点で高校英語段階まで勉強した。
高校時：自由な校風の女子高。ここで一生懸命になれる「趣味」「好きなこと」にであう。布教、もとい、腐教活動に勤しむように。好きなものを伝え広める。
大学受験シーズン：情報学科に行きたかったが、落ちる。
他の大学、英文学科に入学。
大学時：
大学入学祝いにパソコン、ペンタブを買ってもらう。
サイト作成の道具を入手したことで、「自分のサイトを作って情報発信をしよう！」とプログラミングに少し触れる。
この頃は、腐女子が世を忍んでいた時代だったので、情報発信というと、逆SEO対策・検索避けを施した個人サイトが主流。
ホームページを自動生成してくれるようなサービスもあったが、今のようにはパーソナライズされていない広告が大量に付随するものだった。閲覧者はガラケーを利用してのサイト閲覧が多いので、広告の邪魔さはコンテンツ提供上致命的。
広告のないところがいい、というので自分で作る方向に。
HTMLとCSSでウェブサイト作る
→マウスポインタをキャラクターが付いてきてくれるものにしたくてJavaScriptも勉強
→サーバー構築の勉強、掲示板が欲しくてPHPも勉強……。と、勉強漬けの生活に！
最初のうちは、入門書がまず分からない。出てくる単語の意味が分からない、調べるほどにわからないことが出てくる。スタックオーバーフロー状態。
Twitterでやさしい猛者（）に、プログラミングの勉強についてきいてみると、HaskellやOS自作入門などを勧められる。やってみるが、さっぱりわからない。
動くものを作れるのは楽しい、でも分からない。
親切にアドバイスしてくれるのに何一つ分からないことに、劣等感と罪悪感でつぶれそうに。
→基礎から学ぶため、基本情報技術試験の勉強を始める。体系だった知識を習得するために、毎日8時間くらい勉強。
→Twitterの猛者たちの言っていること・要求事項のレベル感も分かるように。
→C++のmetaプログラミングにはまって記事を書いたりしていた。
https://chomado.com/programming/c-plus-plus/template-meta-programming/
お絵かきやプログラミングをしつつ、サーバー運用費を稼ぐため塾講師のバイトもしていた。
# 分岐点の話
就職して新卒でSIerに。研修中はオフラインでプログラミングの話ができて楽しかったが、実務に入ると延々と単調な作業が続き、技術的なことに触れられないことが苦痛だった。他の人なら辛抱できることが自分にはできない。
→実務二週間で退職願を提出
→一週間後にスタートアップの会社に転職
Xamarinについての記事を書き始める。
この頃、IDE(統合開発環境)なVirtualStudioとC＃言語に出会う。
Xamarin：モバイル向けのクロスプラットフォーム開発環境&ライブラリ。C#を用いてiOSとAndroidのアプリケーションを開発可能。
→漫画家としても活動しており、プログラミング言語擬人化漫画をリクルートで連載していた。
リクルートキャリアの忘年会で、普段はアプリ開発をしつつ、自身のプログラミング知識を生かしてプログラミングを題材とした漫画を描いているという話をしたところ、忘年会に参加していたMicrosoft社の社員さんに声を掛けられる。それがご縁で日本Microsoft社に入ることに。
→登壇の機会が増える。
最初は人前に出られなかったが、登壇を重ねていくうちに経験&技術向上、Developers Summit2017では総合アワード受賞。(嬉しい！)
→二年後、日本Microsoft社から米国Microsoft社の所属になる。
# 広がる世界について
こんなスティーブ・ジョブズの言葉がある。
「Connecting The Dots」（点と点を繋げ）
先を見通して点を繋ぐことはできず、振り返って繋ぐことしかできない。だからこそ、将来何かしらの形で点と点が繋がると信じることですよ、というようなことを語っている。
今この時にできるのは、将来繋ぐことができると信じて、点を打ち込むことだけ。
後になって振り返ると、自分は推しに対して全力だった。お絵かき、英語 、腐教活動、塾講師バイトetc.何かに打ち込んだその経験が点になり、今の仕事に繋がっている。
経験則として、最低でも三つ点があるとよい。
一点だと点だが、二点なら線、三点なら面になる。
自分の場合は、エンジニア、腐女子、漫画家。
ここで伝えたいこと(再掲)
- 好きで打ち込めることを見つけてほしい（ODD、オタ駆動開発）
- あなたの人生です 自分の人生に責任を持てるのは自分だけ
- Follow My Heart. 自身の心に従ってほしい
「今は変化の時期。プログラミングができると、可能性は無限大」
A-2 複数のGCPサービス活用と基幹システム連携事例
パーソナルキャリア 草薙 駿
# パーソナルキャリア 草薙 駿さん
パーソナルキャリアは、転職・アルバイト関連の人材サービスを手掛ける会社。
スライド構成：
１ソリューションについて
２使用技術について
３開発時の裏話
４デモ
# 事例の概要まとめ
・転職サービス「duda」において、ブラックボックス化されていたカウンセリング(と称されている、転職希望者からのヒアリング)工程をを可視化
→ノウハウ蓄積、ヒアリングデータの分析
→カウンセラー育成時間の短縮、マッチングの向上
・GCPのサービス活用で負担軽減、効率化
# dudaの「カウンセリング」ソリューション
「duda」は転職サービス。
このサービスにおいて、「カウンセリング」と称される、社に求職者を招き転職希望者の情報・要望等をヒアリングする工程がある。カウンセリングにより集められた情報が、よりよい転職活動のために用いられるというもの。
従来は、アドバイザーと求職者の二人のみの部屋で行われていた。
→AIスピーカーを設置し、二人の声を分けて録音できるようにすることを提案。
録音データをもとに、より手厚いサポートを試みる。
許可を得た相手から収音した音声をweb上で聞けるようにし、キャリアアドバイザーの教育にも役立てる。
基幹システムには、希望条件、転職理由等を簡単に入力できるシステムを備えている。
収音したデータは、収音の許可を頂いた求職者に還元するべく、収音した音声をテキスト化した後、単語の割合等でより合う条件を割り出し、求人・企業側のデータと突合させることで、マッチング精度の向上に役立てている。
AIスピーカーには、発言者を上手く切り分けて表示する仕組みが備わっている。
収音したデータは、Google Cloud Platform(以降GCP)のサービスを経て、発話単位で区切られた音声として(webに？)上がっていく
→ Speech to Text APIをたたく
→テキスト化された発言がDBに登録される
(登録されたデータはwebで確認できる。)
→バッジサーバからテキスト分類を行う
これは、発話の内容から自動で分類される。
# 開発時の裏話
プログラマーの三大美徳 「怠惰」「短気」「傲慢」
(Perlの開発者、Larry Wall氏が唱える)
ここでは「怠惰」を取り上げたい。
少しこの定義とは離れるが、怠惰、「楽をしたい」として「私の戦い方」を紹介する。
今回は、GCPを活用してシステムを構成した。
要件の変更は突然に起こるものであり、今回のシステムにおいても、それは発生している。
例えば、
「API側にデータを置くのはNG。あと、すぐにwebでみられるようにして」と突然言われる。
→Google Cloud Functionsを活用することに
サーバーレスアプリ
収音した音声をスピーカー内にためず、Google Cloud Storageに収納
→Google Cloud StorageからAPIに投げる
→結果をDBに格納
これにより、セキュリティ要件を満たしたうえで、リアルタイム処理の実現をした。
また、後になって
「いいかんじに機械学習できるようにして。運用保守もよろしく」と告げられる。
→Google Cloud AutoMLを使用
専門知識に詳しくなくても機械学習ができる。データさえあればノンプラミングで利用可能
→エンジニアでなくても保守ができる（運用保守をビジネス側にやってもらう）
既存のサービスを使用することで、「楽をして」要件を満たすことができた。
# Google Cloud AutoMLのデモ
(会場では、実際にクラウドトゥメールのデモンストレーションが行われた。)
機械学習を自前でやる場合、名詞だけ取り出す等データの前処理をして、パラメータ調整して、テストして……と、とかく処理が大変。
しかし、Google Cloud AutoMLは文章そのままで利用できる。助詞等が付随したものでも、基本的に処理可能。テキストをアップロードするだけで機械学習ができる。
アップロードするとどういうデータを学習させている、というのがすべて出てくる。
テストや検証に必要なものもグーグル側が用意してくれているので、そのまま使用すれば「やりたいこと」が実現できる。
# 事例の概要まとめ(再掲)
・ブラックボックス化されていたカウンセリング工程をを可視化
→ノウハウ蓄積、ヒアリングデータの分析
→カウンセラー育成時間の短縮、マッチングの向上
・GCPのサービス活用で負担軽減、効率化
A-3 入社半年でPOになったエンジニアが、プロダクトと組織と技術的負債に立ち向かう話
リクルートマーケティングパートナーズ 保坂 駿
#保坂 駿さん
ニックネーム「ほっしゃん」
リクルートマーケティングパートナーズ所属
(ゼクシィ等を手掛ける会社)
ここでは、
・チームと取り組んできた2つの事業について、四つの立場での経験を代表して喋る
(その1： いきなりPOを任せられた時の、プロダクト、チーム、そして事業との対峙の話)
# 経緯
保育事業にエンジニアとして配属
→プロジェクトが炎上、立て直す上でスクラムチームの解散を提案した
→前任のPOから声掛けがあり、POになる
その時の状態
・PO(プロダクトオーナー),SM(スクラムマスター),テックリードが抜けた状態
・全員が新任、経験ゼロ
・開発フローがない
#やったこと
- 文化と開発フローを作る→スクラムに立ち戻る
やったことをやめてみると、何故やっていたのか？ を見直せる。
- 解決試行錯誤
活動開始！ 次にやることが分からない、という状態が多発
→ミニウォーターフォール的な開発を行うように
不確実性の高いものを調べるにも四苦八苦
中規模以上は対応できているが、小さいものは小割がきかない。複数人が同じ作業を重複して行っていることも。
※ ウォーターフォール：開発型の一つ。段階的に開発を行う。工程が一方通行、下流から上流へは基本戻らない。
→スクラムをチームで1から勉強して、逐次改善していく形に切り替え
# 学んだこと
・課題に行き詰まった時は、ブレーキングチェンジが必要なこともある
・チームは常に変わるので、正しい開発フローよりも変更できるフローにすることが大切
・役割に応じた決定義務を持つこと、チームの中で合意をとっていくことは、「動かす力」になる
※ブレーキングチェンジ：既存の機能の削除など後方互換性のない変更
プロダクトの課題として、
・社内権力が弱い
・顧客競合によるマーケット環境の激化
ということがあった。
- やったこと
・ドメイン知識の吸収、チームへのシェア
・信頼を得ないとやっていけない、というのでコミュニケーション
・デザイナー主導のプロトタイピングに、他の人を巻き込む
・知識を得る機会として、保育士体験を行ったこともあった
・チームの疑問にしっかり向き合う(大事！)
・プロダクトビジョン、考え方、判断軸の共有
お客さんは、子供、親、保育士。ターゲットの属性が違うので、要件の競合が起きることもあった。
→判断軸の共有を行う。
「子供にとっていいもの」を判断基準に。これによって意思決定時の中間コストを下げられる。上に上にと回していって、決定を出してもらわなくても、その場でその人達が判断できる。
→クレド(指針)をプロダクトチーム外へ共有するように
人の数だけやらないといけないことがある。自分の定義はなに？ を決めることが大事。
各々でそれが定まっていれば、定義・役割に合った行動が自発的に行なわれる。誰かが働きかけなくとも動いてくれるようになる。
(その2： 技術的な負債を改善する話、組織を越境しつなぐ話)
#リニューアルと負債改善プロジェクト
- アプリの背景
「デザインが古くなっているので、新しくしてほしい。ついでにコード負債もなんとかしてほしい」
・巨木コードベース
・開発フローはウォーターフロー
アプリ自体は効果を生み出しているので、負債改善をリスク少なくやってほしい、というもの。
開発組織がそもそもグループ会社側で分断されている。目的・文化のギャップがある状態。
→現在、開発組織の最適化に取り組んでいる
- やったこと、やっていること
・パイロット開発を行うための社内組織の立ち上げ
変えたはいいが生産性は上がるのか？ ということがあるので、全体で施行する前に、内部でお試し開発を実施
→その結果として、新たに適応しようとしている開発方法が問題ないことが判明。タイムボックスチケット型の開発に
→以降、社内組織でメリットが見出せれば、グループ会社にその方法を輸出、というようなことをしている
タイムボックス：前もって作業に掛ける時間を決めておく
チケット駆動開発：作業をタスクに分割し、チケットに割り当てて管理を行う開発スタイル。
・組織の交通整備
→全フローを知っている人を作る
→接続パスが何処にあるかを明らかにする
(ひとつの業務を組織間などで受け渡していくこともままあるため、全体像とどこに接続があるかを確認)
→ディレクターデザイナー組織とのつなぎ
→オフショア組織とのつなぎ
オフショア組織：この場では、人件費の安価な海外企業・海外子会社、のニュアンス
⇒ プロダクト開発組織に変えていく
ビジョンを伝え、一緒に働きかけることが大事
# まとめ (これが私の戦い方)
・詰まったら、視点・立ち位置を変える
・越境して道を作る、その道から情報や文化を流入する
・達成したいことや目的をはっきり伝えて、協力者を作っていく
・越境するのに権力や威厳は要らないのでやっていい
B-4 人間関係における信頼性とブロックチェーンを用いたビジネス適応の可能性
パーソルキャリア 川里 怜
# 自己紹介
川里 怜さん
エンジニアのグループに所属している。科学素材メーカに入社して、人事として働いた後、
コンサル会社で
趣味は釣り。
！ 実は先ほどの自己紹介に、嘘がある。
科学素材メーカに入社して、人事として働いた→嘘
趣味は釣り→嘘
？ 嘘の情報を聞いて、皆さんは困ったか。
例えば採用のシーンで、皆さんが採用担当者だとして、経歴が嘘だと困る。
証明が必要なシーンで嘘をつかれると困ることになる。
証明が必要なシーン
ex.)採用、クレカ申し込み、レストラン紹介
この「証明」は、信用と信頼で成り立っている。
信頼：相手の不確定な情報を信じることで、不利益を被る可能性がある。
信用：相手の証明をもって信じる。
たとえば採用担当者からしたら、真実かどうかわからないが、真として扱う。
採用されたい側は「信じてほしい」ので証明書などをもって信じてもらう。
# 信用、信頼にはそれぞれ「課題」がある。
- 信頼
相手の情報は嘘かもしれない、不利益を被るかも
→だから信頼リスクを減らす、被る不利益を小さくする。
→たとえば、事前にインターンをする（すぐ辞める人だったりしないか？ その人についての情報を増やす）
- 信用
相手に信頼してもらいたいけど、相手にとっては嘘かも信じてもらえないかも
→だから信用のコストを増やす・相手に提示する情報の質や量を増やす。
→たとえば、資格、経歴など、情報を細かく提示する。
# ここで提案したいこと
信用コストを増やす面で、ブロックチェーンを用いられないか？
ブロックチェーンは、仲介事業者なし、個人間で取引できるようにする。
DLT：各々のユーザがデータを管理する。
ブロックチェーンは、このDTLをまとめる、ひとつなぎにする技術。
ブロックチェーンのメリットは、一度書き込むとハッシュ値がとられているので改竄できないということ。
コンソーシアムチェーン、プライベートチェーンならば、管理者がいる。管理者がいると、新しいユーザが参加できるかどうかを判断できる。
コンソーシアムチェーン：複数の管理主体で管理されるブロックチェーン。
プライベートチェーン：ひとつの組織内で管理されるブロックチェーン。
信用情報の質を、ブロックチェーンを用いて高めることができるのではないか？
信用の質。
例えば、第三者――大学や在籍企業などに自身の信用情報を書いてもらう。
→改竄されないので、信頼する側として信頼できる。
ブロックチェーンは信用・信頼の発生するシーンに活用できる技術である。是非活用していただければと思う。
C-5 入社二年目からスクラムマスターとしてチーム改善に取り組んだ話
ヤフー株式会社 西山慧
スライドアーカイブ：
# はじめに
スクラムマスターとして今まで七チーム経験している。
ここでは、失敗から学んだことをお話しする。スクラム改善のフレームワークとして運用していただければ幸いである。
チームメンバー2人でスクラムスタートとなった。
スクラムマスターを務めるにも、スプリントレトロスペクティブ？ スプリントレビュー？ 分からない言葉、知らないことだらけ。
スプリント：仕事の時間単位、スクラムの一期間、一周期単位をスプリントと呼ぶ。一スプリントの長さは、チーム、ケースによる。
スプリントレトロスペクティブ：スプリントの振り返り。
スプリントレビュー：スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うもの。
インクリメント：完成の定義を満たしており、リリースしようと思えばリリースできるプロダクトのこと。
バックログ：実施すべきとされながら、未処理、未着手のまま放置されている作業や業務、案件などのこと。今後着手すべき作業などを期限や優先度などとともに列挙にしたもの。
https://www.ryuzee.com/contents/blog/7137
- 話のトピック
１．終わらないユーザーストーリー
２．プラクティスが導入できない
３．白熱して追い付けない議論
# １．終わらないユーザーストーリー
長く続いたユーザーストーリー作業。３スプリント(1か月半)でようやく終わる。
前任SM「スクラムは、チームの今を可視化してくれる」の言葉を思い出し、スプリント内のチームの動きを可視化してみることに
→スプリントをタイムラインで振り返る。付箋で起こったことをメモし、ホワイトボードに貼り付ける。
→結果、全員でユーザーストーリーに取り組んでいることが分かった。(分担できていない)
⇒チームのルールとして、分からない場合はすぐに全員集まって作業することが決まった。
- スクラムの三本柱
透明性：チームの今を見えるようにする
件さ：課題に対して解決すべきか考える
適応：課題を解決するためのアクションをする
この3柱がスクラムのはじまり。デイリースクラム（一日単位のスクラムチーム）に三本柱を回す。
# ２．プラクティスが導入できない
3チーム10人で大規模スクラム開始。
ある人に、「バーンダウンチャートって必要なの？」と言われる。（バーンダウンチャートは、タスクの減量を見えるようにする）
→うまく説明できないまま、廃止になってしまった。
目的を伝えることができなかったのが問題だった。
→しっかりと目的を伝えてアクションを提案する。
そうすることで、チームが納得してアクションに取り組むように。
プラクティスを導入する際には、チームがどうなるかの目標がないと動きにくいのでは？ と考えた。
→自分たちが目指すチームの目標を決めるようにした。
チームビルディング！ チームで、目指したいチーム像を議論、目標を定めるように。
→自分がいなくても、「こういう風にしようぜ」の話が出てくるように。改善のためにポジティブに動けるようになった。
→チーム目標のために、プラクティスを導入するという場面も出てきた。
同じ目標に向かいチームで改善に取り組む姿勢を生み出すことが大事。改善を目指す上で、目標を決めてみるのも一つの手段である。
プラクティス：開発において、問題発生のリスクを低減する具体的かつ経験則的な活動をプラクティスと呼ぶ。開発を進める手段、開発を進める方法。
# ３．白熱して追い付けない議論
ある二人がずっと議論している。一人が取り残されてしまうような状態が続いていた。
さて、たとえば。
チーム目標：じっくり技術力を伸ばし、確実に成果を出す
解決したい課題：議論に追いつけないメンバーがいる・メンバー間の知識差が生まれている
？ 上記の目標と課題があったとして、現状をどう解決しますか
→解決策は十人十色で様々
→選ぶポイントは「チームが目標に近づけるか」「楽しく仕事ができるか」
理解できなかったらボールを掲げる、という方法をとった。
→そのうち「仮想ボール」とボールがなくてもボールを持つ手の形にして挙げたり、分からなかったら分からないと手を挙げたりして、話を止めて訊くようになった。
- どんどん失敗しましょう
失敗したとしても一週間、二週間程度。
何がダメでどういう点が良かったのかを振り返る。
アクションがなじんでいくとそれがチームの文化になる。
# まとめ
・スクラムは今を見えるようにするだけ
三本柱を意識して改善
・チームの目標を決めてより良い振り返りを使用
・どんどん失敗しよう
アクションはチームの文化になる
B-6 CloudNativeな監視とは 今日から始める監視
さくらインターネット株式会社 仲亀拓馬
スライドアーカイブ：
# 仲亀拓馬さん
Twitter名義は「かめねこ」
ペンギンアイコンのひと。
インフラエンジニア、エバンジェリストとして活動している。
# クラウドネイティブな監視とは？
- クラウドネイティブとは
CNCFが文書「CNCF Cloud Native Definition v1.0」で定義している。
これによれば、「回復性」、「管理力」、および「可観測性」を持つ「疎結合」なシステムを、クラウドネイティブが実現したシステムとする。
これらを堅牢な自動化と組み合わせることで、最小限の労力で期待通りの変更を加えられることになる。
CNCF：Cloud Native Computing Foundationの略。クラウドネイティブなアプリケーションのための、オープンソースソフトウェアの開発を進めている団体。
# マイクロサービスとクラウドネイティブ
ここでは、マイクロサービスにフォーカスを当てる。
クラウドネイティブを利用するのに、マイクロサービスが来たな、と感じている。
マイクロサービス：複数の小さなサービスを組み合わせてシステムの機能を実現する。
ウェブ三層モデルは、昔からあるアーキテクチャである。
何か問題が発生した場合、従来webは以下の順で問題の原因を調査することになる。
ロードバランサ→ウェブ上→アプリケーション側→DB
これがマイクロサービスのオペレーションとなると、小さなサービス毎に追いかけなければならない。追いかけるのが大変な労力である。たくさんのサーバがあり、それぞれアーキテクチャが異なったりする。全てのコンポーネントに入って、なんてやっていられない。
→「可観測性」 Observability
様々なシステムやアプリケーションを観測すること
今までは「障害に対するアラート」が出ていた。ここで出てくるアラートは、想定された障害によるものであり、想定された障害に対するアプローチとなる。
しかし、分散システムではどんな障害が発生するのか予測することは不可能。障害が起こってもなぜ起こったのかデバッグできない。
→後からデバッグできるように、すべてのコンポーネントを観測していきましょう。
- ObservabilityでのTesting
サービスの成長性をみるためのテストがある。
（リリースの後もテストしていきましょうね）
サービス品質を高めるためのTesting。ビジネス観点で品質を満たしているか？ たとえば、重なるアップデートによる品質劣化を検出する。
# Observabilityを実現するツールに求められる要素
代表的な三要素は
「Metrics」「Logging」「Tracing」
- Metrics
これを用いることで、統計的に集計を行える。トレンドの予測を立てられる。アラートの閾値として使える。
問題としては、単一のメトリクスを見ただけでは何が起きたのか分からない、事実しか確認できない。どういうイベントだったの、が分かるわけではないということ。
メトリクスを実装するのに、プロメテウスというプロダクトがある。
- Logging
イベントを見るための概念。比較的実装が簡単だが、横断的に見るのに向かない。
プロダクトとしては、Grafana Lokiがある。
- Tracing
リクエスト単位で見ることができる。
ツールとしてJaegerがある。
(Telemetryの話も挙がっていたはずだが、子細なメモができていない？)
Telemetry関連記事
https://blog.lenovojp.com/entry/2018/01/14/023245
- Telemetryの課題
・全体をデバッグするためのソリューションがない
そのため、構築・運用のコストが高い
・時間を軸に見るしかない
- Observabilityの先
Observabilityの先には、Analyticsがあると考えている。収集した事実を活用することが望まれる。
Analytics：分析論。データの中に意味のあるパターンを見出す。目的に基づき、データ内のパターンや相関を抽出する。
# 監視の力を伸ばすには？
・社内の監視の強い人を真似してみる
・Meet upで監視に強い人とコミュニケーションをとってみる
・いろんな本を読んでみる
「０からの監視は難しくないよ」
A-7 新卒一年目でサーバーサイド開発あるあるを踏み抜いてきた話
エムスリー 大和 康平さん
スライドアーカイブ：
（私の基礎知識が足りず、話していることが分からない。必死にとったメモも、何が書いてあるのか分からない状態。）
事例が3件紹介され、各事例での対応と、経験を通しての教訓が語られた。
# 事例1教訓
起動の仕組みに手が入るようなツールを使う際は、Breakポイントを設けて処理を追ってみると詳細が分かる。
ライブラリ追加時には、追加による影響に注意する。
# 事例2教訓
動作が変わらない部分の単体テストを先に埋めて、非正規化の動作を保証しながら問題に対応する。最初は大変かもしれないが、後に負債にならない。
不在になるときは、情報引継ぎはしっかり行う。
# 事例3教訓
ドキュメントをしっかり読み、動作確認を行う。
C-9 モバイルゲームの運用に欠かせないデータ分析基盤の作り方
サイバーエージェント 伊藤 皓程
# 伊藤 皓程さん
株式会社サイバーエージェント所属。株式会社アプリボットでバックエンドエンジニアを務めた、アプリ寄りのバックエンドエンジニア。ボイガル(♪)、ボイフレ（仮）等に携わっていた。
- データ分析基盤について
ここでは、「データをまとめる、加工する、分析する」基盤をデータ分析基盤と呼ぶ。集約したデータを分析しやすい形に加工して分析する。ここを基盤化することで、データを見たり、加工したりが容易になる。データの民主化が進む。
- 旧データ分析基盤
ログ・データなどを、他社サービスを利用しEC2上にアップ。Fly Data、Amazon Redshiftなどを利用して、データを分析・可視化していた。
2018年ころから、Fly Dataの障害が発生しだした。Amazon Redshiftのデータの容量も占めてきて高額に。データ容量が増えるほど集計に時間がかかるようになってきた。内部で使われている集計用のツールをメンテナンスできるエンジニアがいない状態にもあった。
Fly Data：ビッグデータの管理・分析に用いられる。Amazon Redshiftとのデータ同期を容易にするサービス。
Amazon Redshift：データウェアハウスサービス。データウェアハウスは、大量のデータを蓄積し、時系列などで分析を行うことでビジネスの状態などを把握し、経営を改善したりシステムの効率化用のデータを取得したりする。
# 新データ分析基盤
- データの集約
AWSのData Lakeを利用することにした。
行動ログ、データ諸々を一か所に置いておける。分析したいときに、したいことに合った分析ができる。
SQLエンジンの移行が容易。サーバーレスなので、従来データ分析基盤より運用コストも減る。
従来では、データを集約する・送信するのが大変だった。サーバーがたくさんあるとログが細切れになったり、帯域を気にしたり監視したりしなければならない。データの集約によって、これを解消した。
- データの加工
Glue Job、Amazon ECSを利用。
ジョブごとに独立したコンテナで実行できるので、ジョブ同士が干渉しない。デプロイが容易。
（？ 話についていけず、メモが追い付いていない）
- データの可視化
Re dashとTableauを利用している。
クエリを書いてデータを抽出すれば、自動でダッシュボードを作ってくれる。よく検索するクエリを登録しておくと、非エンジニアもつかえるものに 。
# 新データ分析基盤に移行した結果
新データ分析基盤に移行した結果、75％ほどインフラ負担・コストが軽減した。
クエリ見直しも含め、全体として90％削減。障害も起きず、データの送信遅延もほぼ無しに。
プルリクで集計を送る動きを作れるようになったため、インフラ勢は自分の仕事に集中できるようになり、非エンジニアの担当者は自分でダッシュボードを作成するようになった。
当初の目的だった、データの民主化が達成されつつある。
https://blog.applibot.co.jp/2019/05/31/data-analysis-for-social-game/
B-10 買い物体験を進化させるトライアルなスマートストア
ティー・アール・イー 田原 卓弥
# 前置き
- 田原卓弥さん
データ処理と画像分析を専門としている。
- トライアルとは
日本型スーパーセンター。郊外に出店している。ワンストップショッピングをコンセプトにしている。
デジタルサイネージのついたスマートレジカートを導入している。これを用いることで、店舗内で買いたい商品がすぐに分かるようになっている。カートに入れたものの類似商品提案なども行う。
ここでは、リアルのデジタル化について。リアル店舗をデジタル化することによってどう変わる？ ということを話す。
# リアル店舗のスマートストア化
- スーパーでの買い物
良さ：実物を見て買える。多くの商品が一度に視界に入る。買ったものがすぐ手に入る。
不満：欠品・扱っていない品ぞろえ。レジ待ち。
- ネット
良さ：実店舗に比べ品が豊富。レジ待ち時間がない。
不満：実物が見られない。すぐに手に入らない。
良し悪しを吸収するような店舗を実現できないか、ということがスマートストア化の上では課題になっている。例えば、「amazon go」では、レジ待ちをなくすことに成功している。
# トライアルのAIカメラ活用
今回はAIカメラにスポットをあてて紹介する。
- 欠品検知
トライアルでは、AIカメラで欠品検知している。棚と商品で格子状に分析し、欠品を検知する。
現在は生鮮食品コーナーで使われている。生鮮食品は山積みができないので、欠品が出やすい。人が目で見て欠品を補充していたのを、AIカメラで検知することで、欠品が出やすい・売上機会を逃す状況を解消した。
AIカメラで売り場上の状態を数値化スコア化し、あるしきい値を下回るとアラートが飛ぶ仕組み。
- AIカメラを使ったマーケティング・購買前の行動分析
バナナの売り上げ・陳列は存在が大きい。スーパーの入り口付近に陳列される。
お店に行ったときに買いたいものがあるということは、魅力的な店舗である条件の一つ。（バナナの陳列台は一種の目安になる）
ショッパーマーケティング、買い物客行動の深い理解に基づくマーケティング活動を行う。買い物客の体験を重視する。POSデータ、売り上げデータからでは購入前の買い物客の行動はわからない。
購買前の行動を分析するため、AIカメラを使用する。触られる頻度をヒートマップで確認してみると……、ビールは濃い色が特定のものについている、お菓子は薄い色が様々なものについている。ビールは「これを買う」と決めて買っており、お菓子はいろいろ手に取ってみて買うことを決めていることが分かる。商品によって、買い方が異なることが可視化される。
入店して、購入するまでの行動が確認できるので、商品の前を通る人数／立ち止まった人数／商品を手に取る人数／手に取った商品を購入する人数で、パネル分析を行ってみることに。
商品接触と購入は、骨格情報で判定する。通路と棚にカメラを設置し、ある商品に対するアプローチ・買われ方を確認することで、どのフェーズで、どこで商品がドロップしているか、というのを知る。商品に対する適切なマーケティング方法に繋げる。
AIカメラを使うことで、今までより手軽にできるになった。人間では大変すぎる・コストがかかりすぎることが簡易にできる。
クロス・マーチャンダイジングについても実験した。
「飲み物のついでにお菓子」と「お菓子のついでに飲料」、どちらのついで買いが有効なのか試してみることに。
→お菓子の中に飲料を置いた場合の立ち止まり効果の方が高いことが分かった。
→しかし、接触や購入に至る確率はそう変わらないことも分かった。
AIカメラで適切なマーケティングの施策ができる。
# 余談 AIカメラの店舗設置
カメラは独自生産しているもの。カメラの設置のため、現場の電源ケーブルは大量に引かれることになった。
カメラの設置にエンジニアの判断が必要になるので、現場で直接指揮をとった。マネージャーとしての知見が、工事という世界に適応できたことが大きかった。
以上。
この記事が気に入ったらサポートをしてみませんか？