当日の様子を一枚だけ。手前味噌ですが、弊社の事例について、紹介をさせていただきました。アイスバーグwww.wework.com机を並べた前に立つわけではなく、みなさん自由なスタイルで聴いていただき初めて経験する、良い意味でのラフなスタイルでの登壇でした。途中まで、イベント参加者ではない一般の利用者の方もいらっしゃいました当日のお品書き(アジェンダ)どうでもいいんですが、アジェンダという言葉が使い慣れなくて「お題」とか「お品書き」っていう日本語を使いたくなります。最初はアクセス制御の話からここはAWSのサービスを紹介しているだけなのでそのまま載せる&説明は省きます。次に、stripe様のサービスを使った不正ガードについて事例を交えて設定できる項目は実際にはもっと多く、細かな設定ができます。次に、取引データから、チェックのためのリストを作成する仕組みについて紹介しました。期間を指定して、メタデータを取得して表示します。ファイルを特定のフォルダにアップロード(これはどこでも大丈夫です)まとめ不正対策に終わりはないと思いますが、有効な対策は必ずその時その時で存在します。有効対策は諦めないことだと思っています。いって対策をしないのは本当に勿体無いので終わりのない戦いだとしても、皆さんで立ち向かいましょう。最後におきまりのやつ。ゲストににワクワクを届けるため、最高のプロダクトを作っていこう!というマインドをもったメンバーがたくさん働いてます。話を聞いてみたい!という方ははお気軽にご連絡ください。最初は、会社の雰囲気知りたいーと言った気軽な感じでも大丈夫です。イベントレポートこんにちは。アソビュー!プロダクト開発チームでプロダクトマネジャーを担当している矢野です。社内共有も含めてテックブログにイベントレポートを書きたいと思います。この記事は主に、マーケティングやカスタマーサクセスを業務にしている人向けの内容です。多くのセッションに参加しましたが、個人的に学びの多かったセッションに絞ってレポートを書いています。Preston氏Amplitudeとは?ネクストユニコーン。エンジニア30人体制で、アプリ内のデータ、行動分析のしやすさを追求したプロダクト。ターゲットはどう定義してるのか?バーガーキングのロイヤルカスタマーはいない。マックでもレストランでも行く人がターゲット。オンラインで注文できることで、デジタルユーザー化していくことを目指してる。以前のアプリにはクーポン配布しかなかったが、新アプリからオンライン注文、決済ができるようになった。オンライン注文、決済が新アプリでできることを認知してもらうためにプロモーションをおこなった。▼プロモーションの内容は?マクドナルドの店舗の半径600フィート内にはいると、ワッパーのクーポンがダウンロードできるという内容。最大化のためのグロース運用ノーススター・メトリックスを向上させているユーザー行動の特徴を分析するノーススター・メトリックスを向上させるマジックナンバーを求めるカスタマージャーニーから施策実行箇所を求めるいかに施策を早く回せるか?が重要。バーガーキングでは学習回数を増やすことを意識して運用したそうです。アプリ内行動でセグメント化すると、良いインサイトが取れるとのこと。アプリ内の行動で成果のでている機能を特定する。良いプロモーションは?クラスターごとにプロモーションを分けて行っている。パーソナリゼーションを活用し様々なタッチポイントをつくること。予約時点が一番欲しい状態、1週間後だといらないと感じちゃう。tokyoリアル店舗のあり方がかわってきた。売り場ではなく、体験の場、サービスの価値提供の場。tokyoでは全組織をデジタルネイティブにしていっている。弊社では、体型変動の保証を月額390円で何度でも対応するサブスクを開始した。カスタマーエンゲージメントを取り組んだ結果、新規会員も自然に増える。今年もカスタマーエンゲージメント高める施策に振り切る。UXとして大事なことはお客様の時間を奪わないことまとめ新規獲得からリテンションに施策の優先度がシフトしてるリテンションを上げるためにはエンゲージメント施策が大事エンゲージメントを高める手段として、パーソナリゼーションを活用したターゲティングが必要ターゲットのセグメントはデモグラ属性では不十分。アプリ内の行動をもとにセグメント化すると効果が高いユーザーから時間を奪わない。ゲストにワクワクを届けるため、最高のプロダクトを作っていこう!というマインドをもったメンバーがたくさん働いてます。話を聞いてみたい!という方ははお気軽にご連絡ください。イベントレポート2020-01-14canvasを使って動体感知。canvas犬アレルギーだけど犬が大好きな相原(@raihara3)です。実家で定期的に起こる、ワンコのとある事件の犯人を捕まえるべくcanvasを活用して簡単につくった監視ツールの紹介です。名前の通り、トイレの話です。汚い表現は極力控えていますが、苦手な方はご注意ください。実家には現在3匹のワンコがいます。犬あるある「他の子の排泄物を口にしてしまう子」がうちにもいるんです...母性本能で良い事なんですが、みんな成犬なのでやめて欲しい...犯人はもう分かっています。(なぜ分かったかは省略)でも、いつも人間の目を盗んで犯行を行う為証拠もなく、注意できずにいます。差分がある場合は、被疑者が近づいては危ないので(4)(5)のような流れになります。排泄物あり)仕組み※この先折り紙を丸めたものが排泄物として登場します。15000)モーション検出Diffy.jsというライブラリを使用しました。フレームを少しずらしたWebカメラのスナップショットを取得し、ハイコントラストの差分があれば"モーション検出"される仕組みです。トイレに末っ子がやってきました。15に映像を分割し、matrixに白〜黒のカラーコードが配列で渡されます。差分がなければ白が入ります。モーション検出の条件に設定している割合は、カメラからの距離や映り込む被写体の大きさによって前後すると思うので要調整です。動きがなくなった5秒後に最初の状態と変わりないか確認します。}}dataプロパティで取得したRGBAから+-30を許容値としました。これは白のトイレシートと排泄物の明暗差からざっくり決めました。差分が検出されると人間に向けた通知音を流します。trueの状態でモーション検出すると、音と共にcanvasから写真のダウンロードリンクを生成します。音といっても、あまりビックリさせても良くないので知らない犬の鳴き声にしてみました。canvas.toDataURL("image/jpeg");document.getElementById('evidence-box').appendChild(aTag);この音に気を引かれてやめてくれるか、人間が駆けつけて止めるか、です。被疑者の長女がやってきました。音のする方を気にしてくれてます。止めることができなくても、リンクから画像をダウンロードすればしっかり証拠が手に入ります。排泄物がある状態ではモーションを検出している間、5秒おきに写真を撮り続けます。その為ただトイレをしにきただけだった、という場合もちゃんと確認できます。毎回人間の目を盗んで犯行を行うなんて賢いけど、しっかり撮ってるからね...これから取り締まっていこうと思います。13:06canvasを使って動体感知。Qiitaの25日目、最後の記事になります。メリー・クリスマスCPOの江部です。アドベントカレンダーもいよいよ最終回となりました。僭越ながらトリを務めさせていただきます。自己紹介ですが、総じて事業・プロダクト両面において道のないところに道をつくったり、空いてるスペースに走り込んだりする役割を担ってきました。目の前の扉は蹴り破るスタイルを得意としています。今回のお題ですが、ゼロからの組織立ち上げを経てある程度の組織規模となった現状に至る中で感じたことを吟じてみたいと思います。相当な乱文かつ少し抽象度の高い話になりますが興味のある方はご一読ください。生産性の高い開発組織とは生産性の高い組織であるために必要なことはなにかを考えたときに、数年前くらいからマーケット、組織、アーキテクチャの3つが統合できている状態じゃないかなーと考えるようになりました。わかりにくいかもしれませんが簡易的な図で表すと下記のようなイメージです。顧客に対して提供するサービスの境界が明確であり、それをどの組織がオーナーシップをもって作り上げるのか定義されている状態です。誰の何の課題を解決すべきか明確チームがシステム(コード)に対してオーナーシップを持てている影響範囲が特定できるスピーディーに変化できるのではないかと考えています。逆に、この状態が歪んでいると、様々な組織課題が現れます。個人的な感覚ですが、これまで私達が直面した組織課題はほとんどこの歪みが原因で発生しているように思います。「フロント」、「バックエンド」など技術レイヤで区切られた組織の場合に起こりやすいかとおもいます。組織はマーケットの境界で区切られているが、システムはモノリシックなケースなど。あるシステムに対して異なる目的をもった複数チームがそれぞれ修正を加えることになり、システムとしての品質を維持するのが困難になる。システムのコードに関する所有権・オーナーシップ・責任が曖昧になる。気づいたらデジタル九龍城がそこに生まれる。影響範囲がわからない。触った結果障害が起こる。統合の順序ではなにをガイドラインにしてマーケット、組織、アーキテクチャを統合していくのがよいのでしょうか。答えはそのビジネスやフェーズによって違うのかもしれませんが、すくなくともいまのアソビューで言えばマーケットに従った組織によってアーキテクチャを変化させるのが良いのではと考えています。)があり、さらにゲストはチャネル別、パートナーは商品別、代理店は業種別に分けられます。これらは異なるKPIやビジネスライフサイクルでアプローチされるわけですが、それぞれに対して明確な責任をもったチームが組まれ、そのチームにおいて事業目標達成の手段としてアーキテクチャを最適化していくことにより、マーケット、組織、アーキテクチャが統合されていくというシナリオが理想かと思います。スタートアップのサービス開始当初はエンジニア人数も時間も制約があるなかでモノリシックなアーキテクチャで構築されがちです。それ自体はもちろんそのタイミングでは正解なのですが、事業成長し組織が複雑化するにつれアーキテクチャやコードが最後に変化に取り残されていきます。そのアーキテクチャを最適化しようとする時、マイクロサービスの導入を検討するわけですが、往々にしていかに最適な要素に分解するか、という視点で議論しようとする向きがあります。誰かが横軸の技術視点で分解、整理することにより技術最適化を図ろうとしてしまいがちですが、そうではなくそれぞれのマーケットに従ったチームが自らのビジネスドメインに基づいて凝集させていくほうが、長期的に整理が付きやすく、実際にそれに向けてプロジェクトが動きだすことが多いです。ここでいう凝集とは、ビジネスドメインを整理し、それを実現するシステムに必要なサブシステムや関連システムのデータ、機能などを取り込んでいくことにより最適なアーキテクチャをビルドアップしていこうというアプローチです。一方の分解とは、様々なデータや機能が含まれるモノリスを、ある基準に従って境界線を引きながらマイクロサービスに切り分けることによってアーキテクチャを最適化しようという思考パターンです。技術視点での分解は、機能的な重複がきれいに整理され一見効率のよいアーキテクチャのように見えますが、往々にして上述のような組織とマーケットとの乖離を起こします。ビジネスドメインに基づいて凝集させていく考え方であれば、ある程度のデータや機能の重複は随所に起こるものの、それぞれがマーケットや組織と連動した形となり、結果ビジネスやオペレーションを含めた全体視点でみると効率的となります。目的としたプロジェクトとして打ち出すことができ、エンジニア以外のチームやメンバーと目線を合わせて進めやすくなります。Record)的なシステムでも、社内の運用部門をシステムやチームにとっての顧客ととらえれば同様の考え方が適用できます。)あくまでマーケット起点での組織、アーキテクチャであるべきであって、既存の組織の形や技術的な効率だけを理由にしたアーキテクチャの設計、とくに異なるマーケットにまたがった低レイヤーの統合は、恒常的にアーキテクトチームなどが保守できる体制でなければなるべく避けたほうが懸命です。さいごにかなり纏まりのない文章になってしまいました。これは多分に理想論なので、人がたりないスタートアップだとどうやってもそんなきれいにはいかないよーとかあると思います。我々も試行錯誤の連続のなかで振り子のように行ったり来たりしながら最適解を探し続けている状態です。いろいろな組織課題に悩まれているマネジメントレイヤーの方々に、少しでも思考の整理や今後の方向性を考える上でなにがしかのヒントにつながればと思い書いてみました。Qiitaの23日目の記事になります。アソビュー!のサーバーサイドエンジニアの山野です。弊社ではSpockを使用したユニットテストを行なっています。今回はその実装方法について備忘録も兼ね、書きたいと思います。以下のような特徴や機能があります。・テストケース内がブロックで明確に分かれており、テストケース内にテーブル形式でテストデータを定義できるため、テストの内容や仕様が分かりやすい。・テスト結果確認(アサーション)が簡潔に記述できる。・Mockの仕組みが標準で用意されている。http://spockframework.org/基本のテストコード実装例テストクラス内のメソッドとブロックは以下のような形で実装します。・テストクラスはSpockのSpecificationクラスの継承が必要です。・テストケース内のsetupはgivenと宣言してもよく、expectブロックを使えばテスト対象の実行と結果確認一緒に行えます。・またテーブル記述を使ったテストを行う場合は、whereブロックが必要です。}}[実装の具体例]商品の単価と個数を渡すとその合計金額を返却するメソッドのテストケースです。通常プログラムのように比較演算子で確認することができます。テスト対象実行とテスト結果確認を一緒に行う。・ユニットテストにおいて、一つのテスト対象メソッドに複数パターンのパラメータを指定して繰り返しテストを行うたいことはよくあることと思います。最低12パターンのテストケースが必要となります。設定値や期待結果にミスが生まれやすくなると思います。渡し繰り返しテストを実行できる機能があります。このデータテーブルを使用する場合はwhereブロックが必要となります。'item-F'}テーブルの一行目(テーブルヘッダ)は各項目の変数名にあたり、setupブロックやwhen/thenブロックで使用することができます。テストを実行すると二行目以降のテストデータが順次この変数にセットされ、テーブル行数分のテストを実行してくれます。この実装例では、ageとgenderの値がsetupブロックのRecommendItemクラスのパラメータとしてセットされ、thenブロックでwhereブロックのexpected(期待値)の値とテストの結果を比較しています。このデータテーブルを使用したテスト(パラメタライズドテスト)を行う際はテストケースに@Unrollをつけるのを忘れないようにしてください。何回目のテストで失敗したかは表示をしてくれません。下記のように各回別のテストの合否が確認できるようになります。Mockを使ったテストコード実装DB接続などが伴うユニットテストでDBのデータに依存しないようMockを使うケースがあると思いますが、Spockでは標準でMockの機能が用意されています。以下は商品IDを指定してDBから商品情報を取得する処理で、DBから商品情報を取得するDaoクラスをMock化した実装例です。{テストデータ}の記述で指定したデータを返却するよう振る舞いを定義している点です。商品名:商品1のデータが返却されるよう定義しています。"商品1")以上、簡単ですがSpockの実装方法について書かせていただきました。内容がご参考になれば幸いです。22日目の記事になります。はじめまして!新卒2年目の山内と申します。特徴的な髪型から、社内ではキノコとしばしば呼ばれています。現在は、社内基幹システムの運用保守とバックエンド開発をしているのですが、1年目のときにアソビュー!のグロースを目的としたA/Bテストを行っていたので、その時のことを書いていこうと思います。A/BテストとはA/Bテストとは、オリジナルページに変化を加え、オリジナルパターンとテストパターンを同条件で比べて効果をはかるテスト手法になります。Optimizeを利用していました。Optimizeでの手法を紹介していこうと思います。テスト準備さて、いざテスト実装と言いたいところですが、施策を考えなければ実装ができません。施策を考えるときに重要になるのが、施策の目的・課題・仮説を明確にすることです。▼ページを特定まず、テストを行うページを特定します。▼課題の抽出・仮説出し次に仮説を考え、そのページにはどのような課題があるかを洗い出します。私の場合、色々な場面で実際にアソビュー!を使って仮説を出していきました。外にいるときはこのボタンは目立たないかもしれない。あったり、お出かけ先で、明日の朝体験したいとなったらどのような情報があったら良いだろうか。等々あらゆる場面や時間、状況を想定しました。実際に知人にアソビューを使ってもらい、ページの課題のインタビューを行いました。▼施策出し最後に、課題を解決する施策を出します。このように施策を考え出すまでの目的・課題・仮説を明確にすることでテスト後の考察が的確にできるようになります。いざテスト実装いざ、テストを実装していきます。今回は、アソビューのチケット枚数選択画面の「購入する」というボタンに対して実際に行ったテスト例を紹介します。こちらの「購入する」というボタンの文言を変更していきます。チケット枚数選択の文言が、「購入する」だといきなり購入がはしるのでは、という不安感があるため、文言を変更することで遷移率が向上するのではないか。いう仮説のもと、他に適切な文言がないかを検証するため、下記の文言でテストを行いました。購入に進む上記で購入に進む次へ枚数を確定するこちらの4つの文言をOptimizeに反映させ、テストを作成します。OptimizeではGUIで簡単にボタンの大きさや色、文言を変更することができます。Optimize上でCSSを上書きする方法がおすすめです。Optimize上で実際にCSSを書いてみるとこのような感じで文言の変更ができます。"購入にすすむ";}※クラス名は仮です。「購入に進む」に変更できました。このようにCSSを上書きすることで、文言の変更を行うことができます。テスト開始テストパターンの作成が完了したら、目標の設定や、テスト対象ページの設定、対象デバイス(PC/SP/タブレット)等の選択を行い開始ボタンを押すと実際に開始されます。ページにもよりますが、2週間ほどテストを行うと十分なOptimizeが十分な結果が取れたと認識し、レポートが作成されます。今回の結果がこちらになります。Optimizeによると、「購入にすすむ」が目標に対して、最適である可能性が高いことがわかりました。重要なのは効果検証です。今回の結果から、「購入に進む」というすぐに購入するわけではないという文言を示したことにより、ゲストの不安が払拭され、次ページへの遷移率が向上したと考察する事ができます。このように結果を元に、なんでうまくいったのだろう、なんでうまくいかなかったのだろうと考察すると思います。その際に活きるのが、テスト前に明確にした施策を行った目的・課題・仮説です。うまくいった際は、この仮説のようなゲストが多かった、なので同じ仮説を元に考えると次はこの施策をやってみよう、であったり、うまくいかなかった際にも、この仮説のようなゲストは少なかった、なので次の施策はこうすれば良いのではないかと考えることができます。施策の目的・課題・仮説を明確にすることで格段に素早くPDCAを回すことができます。効果まとめ1つのテストが終了し、結果を集約することも重要です。私達は、A/Bテストの成功事例を青シート、失敗事例を赤シートというようにまとめました。今回の結果をまとめたシートがこちらです。失敗した際も同じように考察し、シートにまとめます。変更点は何なのか、目標や仮説は何なのか、結果はどうなったのか、どう考察できるのか、をすべての施策に対してまとめました。このようにシートにまとめることで、ひと目で過去の具体的なA/Bテストの振り返りや、社内でA/Bテストの知見を広めることができます。A/Bテストのタスク管理チケットや実際の結果、青/赤シートがわかるようにスプレッドシートに集約し、管理していました。このように一括して管理することで、テスト後のソースコード改修や、変化率、テストの消化状況をモニタリングすることができます。まとめ実際に僕は紹介した手法で、2ヶ月間で15個ほどのA/Bテストを実行しました。うまくいったもの、いかなかったものとそれぞれありましたが、どちらのパターンもシートにまとめ考察することで、アソビュー!を利用するゲストがより使いやすくなるにはどう改修すればいいのか、という知見を貯めることができたと思います。アソビューにてバックエンドエンジニアの服部と申します。VIETNAMのCTOに任命され、組織のスケールアップをメインミッションとして日々奮闘してます。最近はベトナムにくると「帰ってきた...」というホーム感がでるようになってきました、不思議です。無秩序なバイクのイメージが強いホーチミンですが、テト明けは人も少なく装飾が綺麗です。はじめにオフショア開発を初めてみたはいいが、どこかうまくいってない。開発は進んでるしリリースもできてるんだけど、人の入れ替わりは多いしどこか日本と現地で噛み合っていないような。アソビューでは2018年にベトナムにオフショア開発拠点を自社で立ち上げおります。ベトナム開発拠点の立ち上げから1年。新規開発系のプロジェクトはうまく回っていたが、エンハンスメント案件系の対応チームがこの問題に直面しており、スケールしづらくなってました。それを少しだけ改善した話。日本のメンバーから下記のような声がよくあがるようになってきました。自分も同じように言っていた1人です。依頼通りのものが出てこない各タスクの進捗がわからないコード品質が悪いプロダクトバックログに積まれたタスクが山ほどあるのにタスクがないと言われるPO/決裁権のある人が知らないないものが開発されている数ヶ月で人がすぐ辞めていくetc...(これってベトナム組織の問題なの...?というものが多数混ざってますが一旦。)離職率も上がっているように見え、ベトナム開発組織でなにが起きているのかみんないまいちちゃんと把握できてない状態でした。いうことで、ベトナムに参りました。何が起きていたかベトナムに来て最初やっていたことは、とにかく毎日観察/調査です。日本組織にも大いに課題がありそうということが見えてきました。作業の振り返りをしていないチーム間のメンバー移動がフレキシブルに行われているレポートラインが多すぎて誰も管理できてない状況になかなか渋い状況ですね。日本で管理できていると思っていましたが、見えないところでいろんな作業が発生していました。ベトナム組織からも下記の不満が出てきていました。案件依頼にルールがないタスクをやってもリリース直前で止められるタスク完了直前で仕様変更がある事業貢献度がわからない開発の進め方にルールがないこれではベトナム組織も疲弊するのは当然です。これ、ほとんどスクラム開発で解決できそう課題としては、日本組織は開発依頼体制が、ベトナム組織は開発受け入れ体制が整備されていないこと。スクラムガイドラインに則った開発ができるように整備すれば、両方とも解決できそう。日本組織では2年ほど前よりスクラム開発を導入し、知見も溜まってきております。採用/教育含めスクラムマスターをベトナムで急遽起用するのは現状難しそうだと判断し、CTO兼スクラムマスターとしてスクラム開発を数チームに導入し、改善を図ってみることにしました。スクラム導入の下準備とはいえ、「スクラム開発やろうぜ!」といって始められるわけではないので下準備(スプリント0の実施)をしていきます。巻き込まないといけな人が多いので、実際にスプリントを回し始めるより大変です。ベトナム開発チーム内での準備ベトナム開発組織のメンバーは全員スクラム開発をやったことがないとのこと。ベトナム語訳があったので、1週間以内に読んでくることを依頼。下記を並行で実施しました。毎朝、同じ時間に朝会の実施(のちにデイリースクラムに移行)スクラムガイドの読み合わせスクラムイベントの簡単なシミュレーションタスク管理ツールのルール化POとの調整チームの整理および当時のプロダクトバックログや今後のタスクに関してはPOと整理しました。基本的にPOがタスクを作成するPOがOKを出した場合のみ、そのタスクに関してのみ代理でスクラムマスターがタスクを作成することができる(これはスクラムガイドに反してますが今回OKとしてます)メンバー/サポートからの依頼の吸い上げはPOが参加するミーティングでやるやらを判断するメッシュになってたのが嘘のよう。レポートラインが明確化されましたそしてスクラムへ...初めてのスクラムイベントスクラムイベントの初回実施時は、どのチームでも質問責めにあいます。1つ1つの行動や発言に対してなんでやるのか今のはどう言う意味かこうした方が効率がいいと思ういろんな意見が出てきますが、ちゃんと意味を説明し、また初回なので教科書通りにやっていくことを伝えます。いえみんなポジティブで、「スクラム開発やってみたい!だから教えて欲しい!」という姿勢なので、やりにくさや進めづらさはなかったです。導入してどうなったか...課題としてあげた部分に関してはほぼ解消。以前は個人プレーが割と多いと感じてましたが、イベントをこなすにつれてチームでゴールを達成するにはどうすればいいか。いう良い空気も出てきました。ここ、さらっと書いてしまっていますがスクラム導入までの整理や調整が本当に大変で、導入後は日々みんなで改善を繰り返していくだけです。レトロスペクティブ後のようす。最初は恥ずかしがってましたが最近は楽しそう!とはいえ、課題はまだまだ以前よりよくなった!とはいえ開発チームが自走し、かつ組織がスケールしていくには課題がまだまだあります。日本の遊びをもっと世界に広めたい!、オフショア開発や海外経験してみたい。いうことに興味がある方はぜひ一緒に働いてみませんか?というわけで、アソビューでは一緒に働ける、世界をワクワクさせたい仲間を募集してます。イベントレポートcanvasを使って動体感知。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。