# YJ ## Links 櫻山和浩 kazusaku@yahoo-corp.jp alfred https://blog.hello-world.jp.net/posts/book-4136 300, 500, 650, 860, 1250 Cassandra 近侍近傍探索 ### 話したいこと - **実装**はどのような機能を追加/修正するのか - **テスト**は何を保証したいのか(逆に何は保証しないのか) - を切り分けて実施することで高速な意思決定ができる --- ### 自己紹介 - いつもの --- ### コンテンツキーワードターゲティングの紹介 - 設定されたお客様が配信したい(したくない)キーワードが含まれる(ない)記事を提供する - ディスプレイ広告(運用型)で利用 - 全体のトラフィックの0.5%が流れる - 概要図貼る --- ### キーワードターゲティングに用いられる技術 - 記事に含まれる重要な名詞を抜き出して別のコンポーネントに渡すこと - tf-idfで実装されてる - 文書ごとの特徴量(単語の重要度)を定量的な数値で表したもの - (ある単語が文書にどれくらい含まれてるか) x (複数の文書の中でどれくらい含まれてるか) - 詳しくはググって --- ### 現状の課題 - 意味のあるロジックを入れることに意義があるか定量的に示されていないこと - もしかしたらロジックを入れずにランダムなキーワード提示を行った方が性能がよくなるかもしれない - 当たり前だと思うことを定量的に評価することは大事 --- ### ランダムロジックの追加と検証 - 目的 - 意味のあるロジックを入れることに意義があると示すこと - そのために必要なこと - 意味のないロジックと意味のあるロジックに対するライブテスト(A/Bテスト)の実施 - 実施した結果の解析と考察 - 対照群の設計 - なるべく意味のないロジックにすること - ランダム性を持たせる - 生成するキーワード数も動的な値にする --- ### ランダムロジックの実装と3種類のテスト - テストと実装の追加 - ユニットテスト - ロジックの入力と出力が正しいことを保証する - dev, stgでそれぞれオフラインテスト - 追加したロジックでキーワードリストとキーワードごとの特徴量を更新できていることを保証 - ライブテスト - 1%ずつのA/Bテスト - 9/7~で実施 - 得られた結果は誤差とも考えられるため延長して実施 --- ### ライブテストの結果 - 表中の用語 - Conversions - Revenue ### ライブテストの考察 - 現状で得られた結果がノイズでないと仮定 - ランダムロジックはtf-idfロジックよりもCPA⤴︎、Conversion数⤵︎ - 精度の低いキーワードリストを提供していると考えられる - ランダムロジックはtf-idf - ランダムロジックは与えているキーワード数が多い --- ### 改善案の提示 - 上からn%ではなく固定値にすることで行いたい検証ができそう --- ### 個人的な学び --- - 他にやったタスク一覧 - cs-keyword-extractorに潜んでいたバグの発見 - テスト実施中に変な挙動を見つけたので修正 - cs-readerのv1.8.1のリリース - Graceful Shutdownの実装 - メモリリークが起きていないことを保証するテストの追加 - optimizer-serverの不要ダイヤル項目削除 - 実装とテストの修正PR - Cookbookでの設定値の修正PR --- - おわりに - **実装**はどのような機能を追加/修正するのか - **テスト**は何を保証したいのか(逆に何は保証しないのか) - を切り分けて実施することで高速な意思決定ができる --- ## 09/10 本日の目標:全員に対して感謝のメッセージを送る ### TODO - 18:15に必ず業務終了すること - 人事に確認 ### メモ - 可読性 - JSON - ドキュメントを書くことのメリット - 詳細設計はやりながら考える - interfaceから中身の実装をしてくれる - 朝会は長買ったかもしれない - 同期コミュニケーションと非同期コミュニケーション - 最初は同期コミュニケーション、残りは非同期コミュニケーション ## スライド内容 ### 話したいこと - **実装**はどのような機能を追加/修正するのか - **テスト**は何を保証したいのか(逆に何は保証しないのか) - を切り分けて実施することで高速な意思決定ができる --- ### 自己紹介 - いつもの --- ### コンテンツキーワードターゲティングの紹介 - 設定されたお客様が配信したい(したくない)キーワードが含まれる(ない)記事を提供する - ディスプレイ広告(運用型)で利用 - 全体のトラフィックの0.5%が流れる - 概要図貼る --- ### キーワードターゲティングに用いられる技術 - 記事に含まれる重要な名詞を抜き出して別のコンポーネントに渡すこと - tf-idfで実装されてる - 文書ごとの特徴量(単語の重要度)を定量的な数値で表したもの - (ある単語が文書にどれくらい含まれてるか) x (複数の文書の中でどれくらい含まれてるか) - 詳しくはググって --- ### 現状の課題 - 意味のあるロジックを入れることに意義があるか定量的に示されていないこと - もしかしたらロジックを入れずにランダムなキーワード提示を行った方が性能がよくなるかもしれない - 当たり前だと思うことを定量的に評価することは大事 --- ### ランダムロジックの追加と検証 - 目的 - 意味のあるロジックを入れることに意義があると示すこと - そのために必要なこと - 意味のないロジックと意味のあるロジックに対するライブテスト(A/Bテスト)の実施 - 実施した結果の解析と考察 - 対照群の設計 - なるべく意味のないロジックにすること - ランダム性を持たせる - 生成するキーワード数も動的な値にする --- ### ランダムロジックの実装と3種類のテスト - テストと実装の追加 - ユニットテスト - ロジックの入力と出力が正しいことを保証する - dev, stgでそれぞれオフラインテスト - 追加したロジックでキーワードリストとキーワードごとの特徴量を更新できていることを保証 - ライブテスト - 1%ずつのA/Bテスト - 9/7~で実施 - 得られた結果は誤差とも考えられるため延長して実施 --- ### ライブテストの結果 - 表中の用語 - Conversions - Revenue ### ライブテストの考察 - 現状で得られた結果がノイズでないと仮定 - ランダムロジックはtf-idfロジックよりもCPA⤴︎、Conversion数⤵︎ - 精度の低いキーワードリストを提供していると考えられる - ランダムロジックはtf-idf - ランダムロジックは与えているキーワード数が多い --- ### 改善案の提示 - 上からn%ではなく固定値にすることで行いたい検証ができそう --- ### 個人的な学び --- - 他にやったタスク一覧 - cs-keyword-extractorに潜んでいたバグの発見 - テスト実施中に変な挙動を見つけたので修正 - cs-readerのv1.8.1のリリース - Graceful Shutdownの実装 - メモリリークが起きていないことを保証するテストの追加 - optimizer-serverの不要ダイヤル項目削除 - 実装とテストの修正PR - Cookbookでの設定値の修正PR --- - おわりに - **実装**はどのような機能を追加/修正するのか - **テスト**は何を保証したいのか(逆に何は保証しないのか) - を切り分けて実施することで高速な意思決定ができる フィードバック ・ライブテストの1%の議論がなかった ・色々とやっていたことが成長の糧になったと思っている ・広告配信の一連の仕事の進め方が少しは経験できたのではないかと考えた ・2週間と考えるとすると A/Bテスト ・技術的な部分もやってみた ## 09/09 本日の目標:no_rtgのPR作成までやる ### 森下さん 1on1 - 11年目 - 前は広告検索系 - 違うことがしたかった - メディアがいけそうだった - 他の部署に行きたかったら - 部署が違ってもやることがかなり違う - 転職は候補には上がった - 高速化に特化した技術ばかりやっていて、他の部署との関わりもなかった - メディアに行ったらニュース記事のレコメンドなどいろいろなことができる - 退職金と給料面の不安もある →メディアだと社内のフロントだけではなく、バックエンドの大まかな流れもある →半分くらい、給料面の不満があってやめた →やってることにもう少しお金もらえてればなと思う人が多い 新しい技術とかOSS、プラットフォームとか →社内プラットフォームの知識は増える →会社は外部公開されているOSS →大規模なサーバを並べてできるノウハウがある →３年くらいやっていれば、そこが差分になる 経験としては門脇さんと同じ → 自動化が進んでない →自動化できる部分をやってない 通知を自動化してないのが微妙 → 長い割にドキュメントが充実してない →運用作業のドキュメントが 人間ができている人が多い →感情的に何かを言う人が少ない →褒める方向性ができてる人が多い →Good Keep Try →社内の満足度調査がでが →自己肯定感が低かった →ダメなところがあったら改善する →そのサイクルが早い 検索エンジン →低レイヤ部分をやってると →今後は分散が大事になってくる →近侍近傍探索（これがトレンドになってきそう） →普通の単語検索 →検索対象の形態素解析 →検索を早くする →精度を高くする 9/10 安部さん →櫻山さん チームとしてC++を脱却したい →個人情報、秘密計算 →広告系はresponseが早くできるかが結構重要なステータス →広告をやっていると、転職すると広告系にばかり行く オフィスが綺麗で、先輩と同僚が仲良い →ワイワイしてても問題ない →ストレスを感じずに仕事ができる →人間関係 →ガチャ(上司) →横だけではなく縦の関係 →上司ガチャに外れる →チーム自体が他力本願すぎた →上司に相談してダメだったので、人事に相談したら変えてもらった →配属ガチャはあるけど、 リモートになってから感じること →困った時に、先輩から助けられる環境があった →今は相手の顔が見えない →自分がのびのびと働ける 自分がやりたいことを上司が全部やらせてくれる →外のmtgに参加させてもらえる →チームのタスク自体は、トップダウンではなくボトムアップ(チーム内で提案していくもの)→配属は誰が決めてるんですかね→2年後 →アンナプルナ(技術的負債を減らしていこうというプロジェクト) →OSSに刷新していく→PHPはSpringに変える→ちょっとマシになると思う 給料に不満があった →転職活動→Y2/Y3に650/年→修士だと500弱からスタートだったはず→500ちょいまでは上がる →Y1/Y2は普通にやってれば上がる →チームの主要な役割を担っている部分が厳しい * 業務遂行上、必要な知識・スキルを習得し、後輩指導も行いながら業務を効率的に遂行できている * 周囲と円滑なコミュニケーションを行い、チーム・プロジェクトにおいて主要な役割を担っている →部長にも目がかけられるような、→650万以下なら(2年くらいは500くらいのはず)→Y1の1とか→チームの中で優先順位が決められる→お願いをする時に ・配属ガチャはある →OJTは3週間1ローテx4周→ローテの中間でどういうスキルがあるか、やりたいことがあるか変わった→2週間ローテ&ランダム(フロント)→厳しいですね バックとフロントはある程度は聞かれているはず、 →どのサービスに関わるかはあまり関係ない オフラインとオンラインでは違いがある →オフラインだと、全てのデータがgiven→オフラインだと、学習データとしては選択されたデータしかない 　→引いた結果に対して最適化ができれば良い結果だけが落ちてくる →オンラインだと、毎回どれを選ぶか考えるときに、ひかないものも考える 　→引かなかった結果も含めて、最適化を行う必要がある　→得られるデータに関係ない選択部分の要素が含まれてしまう→縦軸は確率密度関数 →横じくは報酬→累積分布関数(積分値) →ε-greedyという問題→2019年 Targetとするキーワードの数が多くなっていた 初めに個数を取得して →候補の広告数が増えるので、課金額が増える→広告の下金額は任意に定まる→セカンドプライスオプション　→1位の人の金額が2位の人の金額+1円くらいにしてくれる仕組み→100円で入札した人はなるべく無駄な加算額をなしに加えてみたい→人間のチューニングポイントがそこになる広告主の設定→この設定が入ってたら、その設定が入っている人に対して→キーワードが多いと、キーワードの密度が高くなる→RPR(最終的な落札額)ベースではなく、fprice base(1位の FP-RPRは下がっている →Selectionは下がっている→tf-idf RPRは下がっている→tf-idfは引けてる広告が少ない→ 下金額は上がっているLa→キーワード数が多いLb→Lbのキーワード数が少ないから、→あたるものを増やせばセカンドプライス→(広告主のパフォーマンスを良くするためではなく、広告主からお金を貪りとるだけ →目的関数が売上の最大化→広告主のことも考える必要がある→両方を評価するのなら、conversions(クリックしてからランディングページで動いた指標)CPA(Cost Per Action)は低い方がいい広告主はその先で行動してもらうことが目的 →Suumoなら内見をしてもらうこと RPRは短期的な指標→短期的な利益 →これに見合わないConversionsだと、入札額を下げられることがある CPA=Revenue/ConversionsImpression=表示click=クリックConversion=その後の操作クリックされたからいいというわけではない→ClickからConversionの質は高くない Tf-idfの方がいいと言える→CPAが下がっていて、Conversionも上がっているのでいいと言えるLaとLbで出ている広告が違う場合もある→単価の高さ低さ 入札学にCVRを掛けて検索する→Conversions 注意したいのはimps コンテンツターゲティングは0.5% →1日のライブテストだと判断できない→考察としてはあり →ノイズの可能性もあるので、引き続き観察する必要がある ランダムロジック →ロジックを導入することに意味があるかを示したかった →tf- →KPIの選定は目的に合っているか 評価基準が広告主のためなのか →正当なオークションが行えているのか？ →オークションが悪くなった →セカンドプライスがファーストプライスにつながる 考察 →「差がノイズでないと仮定した場合の」考察 ## 09/08 9/8 本日の目標:発表内容をざっくり決めておく 発表資料は前日までに作っておくと良い発表は10分 ・考えておく やること ・optimizer 見るところ →RPR Hiveの方からhpr ## 09/07 9/7 本日の目標:朝会で簡潔に説明する(昨日は少し長かった) 01から20のレーンのうち、どれを使うかは確認して欲しい リリース用の ・朝会で事前に話す内容を決めておこう →やったこと cs-keyword-extractor 設計書の作成と実装はdoneで、Stagingにデプロイ中です。 今日やること cs-keyword-extractorの ・ライブテストに向けた準備 ・ Cs-readerの PRはSquash&mergeしてもよろしいでしょうか？ Requester本日release作業をする予定です。 Release作業の仕方がわからないので、extractorの作業が終わったら後ほど下村さんに確認します。 Modelの観点だと、オフライン試験 CPCが変化していないことの確認 佐々木さん 入社前：オファーが来るやつで1次スルーのやつで応募した 日本を便利にすると思って入社した 入社後：思ったより大きな会社だった、売り上げ、相手にする会社も大きい会社だった →年功序列とかがない →仕事の内容で評価された方が良い OJTで複数の部署を渡ってきた →それぞれの部署の人で共通していたことって何ですか？ 6月に決まるまでは、どういう経緯が →広告の部署で共通していたこと、どこも親切な人が多い →Slackで聞くとメンションしてなくても答えをくれる人がいる →業務に真面目 →チームのメンバーが変わったとか、年齢層が幅広くいたチームがあった →質問はしやすい、雑談するレベルではなかった 業務以外の話やすさがあったほうが良い →スクラムに必要な時間が長かった →どこが大事かわからない 他のところは忙しそうな部署もある →人の移り変わりが少なくない →転職して2人いなくなった →他のところから 色々なタスクが降ってきた→良いところ 門脇さん 目に見える形で見えるのが好き KPIを意識する →既存のものに追加することはよくやってきた CS-Keyword-Extractorというような、新しく作れたのがよかった→不便だと思った時に作りたいといえばすぐにできる Jiraにチケットを作る 少し落ち着いて数秒待とう Jiraに 6年目 →入社時点のギャップはなかった 最初と違ったこともない →今見ている部分は全体でそういう人が多そう辞めた理由はなんなんだろう →全然違うところに行きたい →広く触りたい やめている→転職するのが普通なのかな →キリが良い、大体どんな感じなのかわかってきた→より違う人と働きながら転職する そういう大きな →検索から広告に来たとき →必要なドメイン知識が変わる →技術的な知識だけではなく、ドメイン知識の習得が必要 →転職してもあまり変わらない 検索から広告に移動 →1on1で話すときに、別のやりたいことがないかお願いしたらこうなった→選択する→給料面では問題ないの？ →基本新しく挑戦したいという理由でやめる人が多い 経験がなければ→大企業だからこそ、ちゃんとしたテストの意味が大事 →考えを持たせてもらったことが大きい→3年目くらいで大きく上がった→1/2年だとあまり具体的には言わない方が良い →Y2->Y3にいければ結構上がった→きちんと評価されない時、人が評価するので仕方ない お忙しい中 →広告配信について俯瞰したい →運用型広告、予約型広告→事故を通して、その魅力を話せていければ良さそう UPS(無停電)→商用電源PDUがショート→ラックが電源断で落ちる →余剰分のリソースを並行で走らせながら復旧 →バランスを考えて構築していくことが大事→CPC(Cost Per Clieck)→ユーザデータが利益に寄与している →事前に防げるのが良さそう 事故ケーススタディ →KVS(CacheのExpを増やす)→負のスパイラルに入ったことが問題(Expを増やすのは、0に近いヒット率をあげるようにしたかったため)→ロールバックでは解決できない問題をどうにかしたい→スリリングな状況を体験し、巨大システムをもつ広告はおすすめ →ここのエンジニアの主体的な動きが事故による悪影響を最低限に抑えている →現在は事故を事前に防ぐべく、キャパ管理なども力を入れている 事故を通したケーススタディ→Optimizerの→自動入札の機能追加→広告配信系 →年30億→SPブラパネ→Yahooに存在する→エンジニア発 or SM(Service Manager)で作ったものが多い 少し話しすぎた？かな？ → ## 09/06 9/6 本日の目標:朝会での発表を簡潔にする 昨日やったこと ・ライブテストの実施→ライブテスト用のIssueとDraft PRの作成 →嶋田さん、Workflow Platformでの補足コメントありがとうございました！ ・no_rtgの進行 →Optimizerから実施した Viewerで確認できた→今日の14時のnotifyで確認できそう→ Optimizerのログを見る必要がある →Optimizerまでログが来ていることを確認する ## 09/03 9/3 本日の目標:人と話すことを意識する リリース作業を並行して森下さんが →今日のランダムロジックを ランダムロジックの件をマージしたら森下さんに連絡してもらう →別に 改めること ・「〜的には」という言い方はよくない ・朝会で事前に話す内容を決めておこう →やったこと、今日やること →改めようか 　→1.7.1を先に出してもらう 　→1.7.2を私がPRを作ってリリースする (別々のリリースをする) ライブテスト系 ・ターゲットとするKPIの設定方法 ・対象枠 ・実施期間とマイルストーン ・リスク Application.yamlの設定を変更した際のログを見れない→./gradlew bootRunの時は問題なく実行できている Realtime bidding →他社の広告のオークション RPR(Revenue per Request( Dialに新しくメモを追加する Local以外の名前にしてみる メンターの共有→ドキュメント作成→必要最低限の部分を作成できたのはよかった→設定ファイルの ## 09/02 9/2 本日の目標:手を動かす 来週火曜の昼にLT会 →10min ~11:30 下村さんに方針を確認する(Issueを立てる) →go installが使えない →1発でインストールできない →シングルバイナリはGitHubのreleaseを使ってはならないルールがあるので使えない（実行環境に応じて色々作る必要がある） →一度ビルドしておいたものを気軽に使いたい ~14:00 docker imageの作成とhubへのアップロード ~15:00 docker Publisher? →blockedBy Requires: commit jobが起きた時に動かす的な(GitHub ActionsのOn的な) Docker imageができてbuildできたら 学んだこと GOPRIVATE 再発防止策を提示できることが大事 no_rtg_hogehogeのタスクについて →Nortgdynamicusefeaturesのうち、4つ渡しているが前の2つしか使っていないので、後ろ2つは削除してもいいよね、という話 Miroのやつ何ですか？ Good Keep Try ギャップに感じたことはありますか？ →自分の周りが言ってた人物像と全員新卒集められた時の雰囲気 　→思ってたばかりの人物像 どういう特徴がある人？ →上昇志向の人が少ないと思いきや、そうでもない？ もっとトップダウン（裁量を持って作業できる） Scienceは開発系は運用が → 実装のタスクはやるだけ → Etcdが落ちたの定義したState(Key-Value Store) sskのデータせんたが機能不全に →どうやって戻すか 　→一度落としてから 　　→ダウンタイムなしでなんとかしたい 　　→2データセンタのキャパを用意するとお金が足りない 　　→マルチリージョン 　　　→BCP対応が 　　→エンドユーざのレイテンシはあまり意識しなくても良い →通信速度(0.2秒以内) 　→チームの管理のしやすさ 　→マイクロサービス(Protobuf) 　→改修スピードが →grpc 　→(protobuf) 　→optimizer serverのcentOS7で動いていて、 背景と目的 KPI 確認事項に追記する ・悪化する前提で進める ・あまりにも悪化したら早めに止める K8sの件 sshの件 ロードバランサ zcpはkubernetesを管理しているだけ オートスケーリング →最大を予想して ## 09/01 9/1 本日の目標: ・終了時刻を意識して行動する 小目標 ・簡潔に説明するように意識する ・作業内容 →簡単な案件をやる optimizerの開発 修正すべきところ ・GitHubのPRには実行結果を記載すること 学んだこと ・Networkのエラーで落ちている時はrestartしてみると良い ・ 昼に部会がある Kaniさんへの質問コーナー Keywords: C++/Java, DIY ・入ってギャップに感じたことは何ですか？ ・おすすめの本を1冊教えてください ・YJで魅力に感じることと残念なところを1つずつ教えて下さい →広告周りは初めて？ →リモートを率先して進めていた KANIさんは複数 →EM・TechLead 　→テクノロジ統括本部がやってる　→EMを目指している 　→やりたいといえば、案件に応じて振られる →信頼？とは 　→失敗しないというのが大事 　→失敗した時にリカバリできる 　　→ダメだったことを修正できていると良い →他の人は実践できていると思いますか？ やりたいと言ったことはできる →成果主義的なところがある →頑張っている人(信頼されている人には仕事を振られる) cs-readerがdevのcs-readerにリクエストする ・試験方法 →きちんと動いていること →contents-analyzed-dbでランダムロジックできちんと格納されることを確認 →3つの環境全てで確認 Dev/stagge/prod dev: merge前に確認可能 →dev環境のcassandraにローカルからデータを投げる →read->write->read curl -XPOST -H "Content-Type: application/json" -d '{"contentsId": "hoge", "action": "update"}' http://localhost:8080/notify PRに書く Stage: merge後に確認可能 Prod: release後に確認可能 でcs-readerにデータを流せる わからなかったら下村さんに投げて 試験の流れが PRのログ <details> <summary></summary> ``` ``` </details> ドキュメントに残すようにしてね Requester →cs-readerにかかる負荷と、analyzed-contents-dbにかかる負荷を確認できる releasesに固めておくと良さそう 嶋田さん →物理的な障害が起きた時の話 →電源に傾倒（自家発電、外の電源も壊れた） 　→障害のレベルに応じて、前者的に起きている 　→物理的に、リソースが足りていない →統括本部長等に報告する 　→復活させるコンポーネントとしての取り組み 　→優先順位をつけて 自分のチームでの復活の手順を考えて、指揮をとる →プラットフォームとのやり取り 　→自分でやりたいと思っても、コードを描けなくなる 　→チームのパフォーマンスを最大化させる →自分のまとまった時間を確保しづらい 　→ちょこっとしたスクリプト 　→チームの規模によって様々 　→数人なら →なりたての頃はやりたい部分だけだとダメ 　→やりたい部分だけだとダメ 　→個人としての最大化 →他の人の成長機会を奪う 　→島田さんは最初から 　→YJは、しっかり考えて発言している（マイルドな人は多い） 　→利己的ではない 　→間違っていると間違っていると認められる人が多い08/31 やること ・Linterの設定 ・環境構築 →鍵ファイルが必要なので、それをやる ・ランダムロジックの実装 →n%決め打ちで取得する →tf-idfと同じくらいの数で ・チケットの発行 気になっていること ・ビルドタグはどこで設定されてるんだろうか ・cs-keyword-extractorのunit-test 気づいたGood Move ・終わった後に何か質問はありますか？と聞く ・Botでデイリースクラムメッセージを流し、議題がある人はスレッドに足す →良さそう ・結合のために、何をテストするかを言語化すると良い →後方互換性を担保するために、とか ・ランチ会 直すべきこと ・hereメンションは基本的に使わない ・概要に目的を書く ・Model1に実装する 気づいたことメモ ・IntelliJでApplyするのを忘れない・LintはCmd+Option+Shift+L ・SerializeFieldのところでAlt+Enterを押してAdd hope fieldを選択するとUIDが挿入される ・secrets.envはk8s用の設定に利用する ・loggerのformatは{}でやる → log.debug(“hoge: {}”, hoge); メンバー ・morishitaさん(Shannonとかやってた) ・shimomuraさん(Goが好き？) ・sasakiさん(OJT新卒) A/Bテスト→Liveテスト ・自明だと思っていたことがそうでもないこともある →EMとスクラムマスターは別？ 　→スクラム気味（スクラム） 　→KPTのチームの前頭 　→miroの部分 →Goodは最近チームの話しあいで幸福度の測定をする 　→承認のスコアが下がってるかもしれない（もっと良い） →6年目　→ギャップに思ったことはあります？ 　→予想してたのと違ったこと 　→勤務時間外の作業　　→有給が取りやすい 　→時間外の労働は絶対にダメ 　→労働環境が良い 　→立場的にフランクに話せる 　→大企業なのに仕事がしやすい 　→とはいえ、大企業は意思決定に時間がかかる 　→インターネット企業として 　→有給は初年度12日 　→1年ごとに20日（夏休みがない） YJは買収によって大きくなっている →Asiaにどうやって広げていくのかな？ →Yahooという名前だと名前が広がらない →今後世界に力を入れていく →サービス統合 →この規模になると、他社のコストがかかる →DCを増やしていく 　→自前で作ると良さそうかな　→Private Cloudでやっていき→大きいのは2つ 　→規模が小さいとそうなる 　→KubenetesクラスタをKubernetesクラスタで管理する　→外部公開するかもしれない Yahooの福利厚生で検証用という本を1万円分 →面白い ## 08/31 08/31 やること ・Linterの設定 ・環境構築 →鍵ファイルが必要なので、それをやる ・ランダムロジックの実装 →n%決め打ちで取得する →tf-idfと同じくらいの数で ・チケットの発行 気になっていること ・ビルドタグはどこで設定されてるんだろうか ・cs-keyword-extractorのunit-test 気づいたGood Move ・終わった後に何か質問はありますか？と聞く ・Botでデイリースクラムメッセージを流し、議題がある人はスレッドに足す →良さそう ・結合のために、何をテストするかを言語化すると良い →後方互換性を担保するために、とか ・ランチ会 直すべきこと ・hereメンションは基本的に使わない ・概要に目的を書く ・Model1に実装する 気づいたことメモ ・IntelliJでApplyするのを忘れない・LintはCmd+Option+Shift+L ・SerializeFieldのところでAlt+Enterを押してAdd hope fieldを選択するとUIDが挿入される ・secrets.envはk8s用の設定に利用する ・loggerのformatは{}でやる → log.debug(“hoge: {}”, hoge); メンバー ・morishitaさん(Shannonとかやってた) ・shimomuraさん(Goが好き？) ・sasakiさん(OJT新卒) A/Bテスト→Liveテスト ・自明だと思っていたことがそうでもないこともある ## 08/30 8/30 広告とは何 https://ads-help.yahoo.co.jp/yahooads/ydn/articledetail?lan=ja&aid=27041&o=default User(ユーザ）：ニュースが見たい Demand（広告主）：商品を請求したい Supply（メディア）：広告を表示したい で構成されているので、バランスを取ることが大事 検索広告 →検索した時に表示されるテキスト広告 ディスプレイ広告 →Y!Japanのトップページに表示する広告 →画像や動画付きで表示できる広告 →知らないユーザと行動に起こしていないユーザに効果的 →画像や動画で魅力を伝えられる →クリックされたら料金が発生 →広告に年代や性別を設定 →設定したキーワードを検索したユーザに表示 →予約型と運用型がある YDA: 広告配信の仕組み →https://ads-help.yahoo.co.jp/yahooads/ydn/articledetail?lan=ja&aid=27041&o=default Vision オンライン・オフラインの全てのメディア上で ユーザ・広告主・メディアにとって適切で価値のある広告の世界にUPDATEすることが目的｜ Mission 広告プロダクトを通じてユーザと広告主 広告が激アツらしい 大切にしたいこと 一言で言うと、チームワーク ・情報を共有しよう ・意見はOPENな場で言おう ・不確実性と多様性を認めような 検索 今後やろうとしているのは、オフラインのところも取っていこうという話 現状の課題って何なんですか？ 現状の広告配信全体の課題って何なんですか？ →YDAは大きなシステムで構成されている 関連するコンポーネントがたくさんある →最適な広告を配信するために、複数のコンポーネントが存在している 幅広い技術を学べるのが、システム開発面の →データモデリング —- システムよりの話 ディスプレイ型広告に関する話 Yahooの広告サービス→検索広告 →ディスプレイ広告 　予約型広告 　→ブランド認知 　運用型広告 　→目的を設定してもらう 　「サイト誘導」が目的なら、クリック数を最大化する配信をする 　→広告内容に興味がありそうな潜在層に配信 　→パートナーサイトにも表示可能 　→クリック、動画再生に応じた課金 地域・性別・年齢ターゲティング サイトリターゲティング コンテンツターゲティング →最近出たやつ — 広告配信のステークホルダ 広告主 →商品・サービスを知ってもらいたい →買ってもらいたい メディア →広告を配信する場所、サービス →できるだけ利益を多く得たい ユーザ → — 広告システム ・業務系 →広告主等が扱う →配信実績等を扱う ・配信システム →実際に入稿されたシステムを配信する ・メディア →ユーザの目に当たる部分 ・集計システム →配信実績 — 広告配信の全体像 ・ユーザコンテンツ情報 ・広告検索 ・品質評価 1. ユーザがメディアに接触→PCやスマホから閲覧（アクセス）した時 2. メディアが広告配信サーバへのリクエスト→ブラウザは広告タグが埋め込まれた部分に応じてリクエストが飛ぶ→アプリは広告SDKがリクエストを飛ばす26万req/sec 3. 配信サーバがユーザコンテンツ情報を取得→ユーザ情報の分析(リクエスト情報：配信面の情報（どういう広告枠？）、Cookie情報、IPアドレス等）→ユーザ素性（検索キーワード、性別・年齢推定、興味推定、広告主サイトへの訪問履歴、広告への接触履歴）→コンテンツIDを投げると、コンテンツ情報（コンテンツに含まれるキーワード等）？ 4. 配信可能な広告を検索→リクエスト情報(広告主の設定した条件に一致する広告を複数取得する）→配信計画(広告に設定された目的に従って配信を最適化する)　→予算情報と最大化したいスコアを鑑みて、広告のランキング参加確率や入札学を決定する　→コンバージョンが目的の場合、コンバージョン率がスコアになる　→予算を一気に消化しないように、広告の予算消化ベースを調整している 5. 広告の品質評価（ランク付けする）→広告の品質評価　→品質評価（運用型）　　→もっとも品質スコアの高い広告を配信→品質スコア＝入札単価x予測クリック率 6. 配信 7. 配信結果のフィードバックを配信ログに積む→ サイエンス観点 →オークションロジックの改善 →アドフラウドなどの不正検知 システム観点 →内政検索エンジンの開発・改善 →OSSを利用したデータ連携の高速化 →PDCA高速化のための仕組みづくり A/Bテスト →２つのversionを比較してどちらが優れているか比較する →ロジック改善時の効果測定の目的で利用 →トラフィックをパケットと呼ばれる単位に分割して実施 A/BテストのKPI可視化→ Y!の広告サービス→検索広告→ディスプレイ広告→ユーザとコンテンツでターゲティング 広告配信→ 運用型＝入札額xクリック率を算出 トラフィックを０.２s以下で処理する必要がある 検索と評価に時間がかかっている 半分以上の時間は検索と品質評価にかかっている →検索の質をどれくらい高くやろうとするか →質と速さはトレードオフ →ターゲティングが一致している部分を返す →コンバージョン率を予測するとか →理想としては、検索結果が1000件くらい会ったときにその結果を予測するところがボトルネックとなっている→最初のフェーズでは荒めに、大体あっていそうな結果を検索するようにする→選び方 →評価の部分が結構遅め →トレードオフをどれだけ維持できるか — 予約型配信のシステム概要→予約型の概要→システムの外観→システム概要・運用型は、柔軟な運用ができるが、表示量や運用方法によって幅がある →予約型は、お客様に知っていただくことに重点を置いている →予約された量を確実に表示することを目的としている配信量と価格が確定する より印象に残る広告を配信できる シミュレーションと配信計画から構成される→購入時に金額と配信量が決定しているので、確実な広告配信が約束される→VP型/枠購入型/時間帯ジャック購入型 予約型 →認知度増加が目的？ デイリーで、検索ようインデックスを更新する →シミュレーションをする際に最新の予約ずみの在庫を確認して、デイリーのインデックスと最新の予約情報を取得して、結果を提示する 配信計画→計画した配信量をちょうどよく満たせるように、配信をコントロールすること 予約型配信計画→Hadoopリアルタイム補正をかけた上で、広告検索DBに投げてあげることでPD制御を行うCmd+Kが便利 その日にやることを1分程度で簡潔に行う・タスクの共有事項 ・朝会、夕会以外はカメラOFFでおk・チームメンバーから1on1の連絡が飛んでくる・承認して・日報1. 実施事項2. 感じたこと、気になる点、困っている点などを共有する日報は18時半までにSlackで共有しておくと良い→わからんかったらnewcomeに投げると良い→ Jiraのセッティングchmod(ちょもど)←言い方がkawaii 　 Contents service→YJ面のキーワード情報 Keyword extractorとは →コンテンツターゲティングとは 　→これをサービスとして提供するために必要なコンポーネント →コンテンツキーワードターゲティングとは 　→ユーザにターゲットするものと、広告が表示される面（コンテンツ）にターゲットするもの ユーザにターゲティングするのが ジャンルに対して提供するターゲティングがコンテンツキーワードターゲティング →コンテンツの中のキーワードにターゲティングするサービス ２種類ある 除外ターゲティング →ブランド既存に関わるキーワードが含まれるコンテンツに出力しない 配信ターゲティング→キーワードが該当したらそのキーワードに対応するやつ →台風の記事に台風系のキーワードを含めている広告を表示する 記事専用のIDがパスパラメータに含まれて、Optimizerに渡されるコンテンツIDを入力すると、キーワードやキーワードIDを返すもの→これが今回作るcs-keyword-extractorもこれの1つ Shannon：記事を入稿してくるやつ→ コンテンツをユーザが閲覧するごとに、毎回実行される→cs-keyword-extractor→記事が入稿されるたびに通知→feature-generatorとkeyword-extractorが動いているfeature-generatorが生のテキストから単語を抽出する→tf-idfでスコアリングして上位単語をキーワードとして抽出→単語集合の中で出現回数が高い単語を出力する(tf-idf)→閾値以上のものを 配信ターゲティングは住宅・投資・ギャンブル系 除外ターゲティングは NextAction→キーワード抽出精度の改善→キーワード抽出精度の定量的な評価tf-idfよりはランダムロジックよりも評価精度が良いことを提示できるA/Bテストの基盤はあるので、ランダムロジック→名刺の一覧からランダムにいくつか選んで Command +クリックでx-refが見れる