こんにちは。スクラムマスターの@sakebookです。 今回は「象・死んだ魚・嘔吐」をチームでやってみたのでその振り返りをします。 「象・死んだ魚・嘔吐」とは 振り返り手法の一つです。Airbnb Story 大胆なアイデアを生み、困難を乗り越え、超人気サービスをつくる方法（原題: The Airbnb Story）の中で紹介されていたようです。 翻訳されてなかなかキャッチーなネーミングになっています。 それぞれ次のようなことを意味します。 象 凄く大きい、見えているけど、みんな見ないふりをしている課題・問題。表層化しているけど大きすぎてみようとしていない。これが何かをみんなで話していく。 死んだ魚 放っておくと腐っていく。そういう問題。放置しておくとまずいことになる問題ってなんだろう？ということを話し合う。 嘔吐 自分の胸の中に隠していて、吐き出せなかったこと。これをこの場で嘔吐する。

やり方 特に難しいところはないです。 1. Cloud Run の「サービス」メニューから「カスタム ドメインを管理」をクリックする ここです。 2. 「マッピングを追加」をクリックして情報を入力していく 注意点がいくつかあります。 2-1. マッピングに対応しているリージョンが限られている それは、マッピングに対応しているリージョンが限られていることです（2022/10/15 時点）。 マッピングを利用したい場合には、予めこれらのリージョンでサービスを作成する必要があります*1。 2-2. ドメインは「確認済み」である必要がある 所有するドメインが自らのものであるという確認を済ませておく必要があります。 上記 2点 をクリアしたならばどんどん情報を入力して、最後に「続行」を押します。 3. 確認待機状態になる 入力が終わるとマッピング一覧画面に遷移し、マッピングの確認待機状態になります。

こんにちは。JX通信社 サーバーサイドエンジニアの内山です。 私が所属するNewsDigestチームでは先日、モバイルアプリ用APIをAWSからGCPにお引越しする、というプロジェクトを行いました。 会社の方針としてGCP利用を推進していることや、GCP特有のマネージドサービスの活用を視野に入れ、移行を決めました。 今回のAPI移行では、大きく以下2パートの作業がありました。 APIのホスティングサービスをGCP上のものにするためのCI/CD設定, 定義作成, アプリケーション修正などの作業 APIドメインのルーティング先をAWS -> GCPに切り替えるインフラ作業 本記事では、後者のルーティングに関して取り上げていきます。 作業概要・前提 有効なSSL証明書を事前に用意するには セルフマネージドSSL証明書の発行・検証作業 トラフィック移行前の確認 安全なトラフィック移行作業をどう行う

こんにちはNewsPicks SREチームの美濃部です。 NewsPicksのSREのミッションの1つに「コストを適正化する」というものがあります。サービスの規模拡大に比例してインフラコストが増えないようにし、売上に対するコストの割合を低く維持していくのがミッションになります。 今回はこのミッションに対するアクションとして開発環境のインフラコストを適正化した話をします。 NewsPicksの開発環境について 開発環境のコストをどうやって適正化したか 稼働時間対応を実現する仕組みについて 実際どれくらい削減できたのか まとめ NewsPicksの開発環境について まず、NewsPicksの開発環境について概要を説明します。 インフラ基盤は本番環境と同様にAWSを利用しており開発チームは現在10以上のチームが存在し、それぞれのチーム専用に用意された開発環境を利用しています。 2年程前までは開発

今回はプッシュ通知のテストについて書きます。 プッシュ通知のペイロードはわかっていてもプッシュ通知の機能がまだない場合ありませんか？ 業務でたまたま発生してプッシュ通知のテストがシミュレーターでできることを知ったので方法をまとめたいと思います。 前提としてApple Push Notification Service payloadという以下のようなフォーマットのJSONファイルが必要になります（拡張子は .apnsのファイル) { "aps":{ "alert":"これはテストです", "sound":"default", "badge":1 } } JSONファイルをシミュレータにドラッグアンドドロップ この方法が１番簡単だと思います。 Simulator Target BundleにプロジェクトのBundle IDを入力します 他にペイロードのデータなどはプロジェクトによって追加して

*1 こんにちは、サーバーサイドエンジニアの @kimihiro_n です。 今回はSentryというエラー集約管理システムをGo言語で扱う場合の知見を共有したいと思います。 Sentry とは Sentryはエラーの集約管理を行うためのシステムで、作成したアプリケーション内で発生したエラーを一括で収集して見やすく管理することができます。 sentry.io 類似のエラーをグルーピングして発生頻度を確認したり、エラーの発生状況をSlackのようなチャットツールに通知してくれたりします。 予期しないエラーが発生したとき、生のログを見なくてもSlackやWebのUIで確認出来るのはとても便利です。 バックエンドからフロントエンドまで幅広い言語に対応しているためシステムのエラーを一括で集約が可能です。 JX通信社ではエラー管理ツールとしてSentryを広く利用しており100を超えるシステムが登録

こんにちは！JX通信社シニアMLエンジニアのファンヨンテです。私は普段から、顧客にとって価値の高い(言い変えれば、顧客を幸せにできる)AIを開発することをモットーに仕事に励んでます。そのためには、AI開発の速度を高め、様々なAIやその見せ方を顧客に試していただくことで、顧客の幸福度を上げる方向性を見出していく必要があります。 効率性を高め、AIの開発速度を上げるために、JX通信社では様々な工夫を行っており、これまでもブログで紹介してきました。 tech.jxpress.net tech.jxpress.net tech.jxpress.net 今回はその取り組みの中でも、あるClassのデータを集中的に追加する時の背景やTipsと注意点についてまとめます 目次 目次 背景 データ作成の手順 簡単なフィルター Classにふさわしいデータを判別するシステムを作成する 対象Classにふさわし

FASTALERT開発チームバックエンドエンジニアの鈴木（泰）です。 本記事は、AWS Lambdaの構成管理のためにTerraformを導入してみたというお話です。 TL;DR FASTALERTチームの開発文化とTerraformの導入に至った背景 AWS Lambda関数をTerraformでどう管理しているか もくじ TL;DR もくじ 本対応の背景 FASTALERTとチーム文化 workerレポジトリ apexのメンテナンス停止 Lambdaの構成管理ツールとしてTerraformを採用した理由 AWS Lambdaの構成管理のためにTerraformを導入（詳細） ディレクトリ構造 ファイルの中身 Lambdaのデプロイ方法 所感 あとがき 本対応の背景 具体的なAWS Lambda x Terraformの話に入る前に、FASTALERTチーム、workerレポジトリ、今回

背景 問題点 Vertex AIの公式ドキュメントに記載されている形式 Hydraの形式 解決方法 Hydra形式へ変換し、本来の学習コードを実行するスクリプトの作成 HydraのコードでVertex AIのハイパーパラメータ調整ができた まとめ 補足：チームでR&Dに取り組む工夫 我々とともに挑戦する仲間を求めています 初めまして、JX通信社のMLチームでインターンをしている田中です。これまで物体検知や深層距離学習を使った画像分類、自然言語の分類や生成などのAI作成、MLOpsなどをやっています。今回、MLエンジニアのヨンテさんのもとで文書生成AIのハイパーパラメータ調整の並列化に挑戦しました。 Hydraで書かれたコードをVertex AIでハイパーパラメータ調整するためのサンプルコードはgithubにて公開しています！ ぜひ、一度試してみてください！😊 github.com 背景

皆様こんにちは！JX通信社で機械学習エンジニアを担っているファンヨンテです。 弊社提供のビックデータ リスク情報サービスFASTALERTでは、Deep Learningを使ってSNSの投稿をリアルタイムに解析し、火事や事故などのリスク情報の検知を行っています。 SNSの投稿には、文字だけでなく、画像、動画などの情報も含まれているため、SNS解析にはよくマルチモーダルなAIモデルが用いられます。今回は「SNS の投稿からのリスク情報の判定」というタスクをテーマに、マルチモーダルなAIモデルの判定根拠の可視化や、精度を上げるための工夫などをご紹介します。 FASTALERT（ファストアラート）について 「FASTALERT」は、SNSをはじめとする各種ビッグデータから、AIがリスク情報を検知・配信するビックデータ リスク情報サービスです。報道に必要不可欠なツールとしてNHKと全ての民放キー局

サーバサイド開発やインフラ周りをいじっているたっち(TatchNicolas)です。今回はJX通信社における障害対応フローの改善について書きます。 はじめに TL;DR; slack-goとZapierを組み合わせて、障害対応時の提携作業を自動化するツールを作った 「自動化しよう」という意見がでやすい場自体を仕組みとして整備したことが改善のきっかけになった 今回の話の背景 少し前に、ビープラウドさんとのイベントにて、JX通信社NewsDigestチームのCI/CDおよび障害対応についてお話しさせていただきました。*1 そのなかで、「障害対応時に専用のSlackチャンネルを都度作成していること」「Notionテンプレを使って情報の整理をしていること」*2を紹介しました。イベント後も何か障害やヒヤリハットが起こると少しずつフローが改善されていき、またNewsDigest以外のプロダクトチームで

あけましておめでとうございます。 サーバーサイドエンジニアの @kimihiro_n です。 今日はAWSに載っているシステムの避難訓練を実施したことについて書いてみようと思います。 弊社が提供している FASTALERT というサービスでは、全国の災害や事件などを検知して報道機関や自治体、インフラを支える企業などにリスク情報として提供しています。 リスク情報を提供するという性質上、情報検知の素早さや網羅性に加えて「システムの可用性」も重要なサービスの要素となっています。 FASTALERT の多くのシステムは AWS の東京リージョンで動いており、複数データセンターを活用した冗長化(マルチAZ)がされています。 しかし、例えば大規模地震のような広域かつ被害の大きい災害の場合、東京リージョン全体にわたって問題が発生する可能性があります。 首都直下型の大きな地震は今後30年以内に70％の確率

10月からコンサルタントに出戻りしたエンジニアです. 入社前に想定していた以上に毎日が楽しいです*1. それはさておき, つい先日に前職の同僚であるエンジニアリングマネージャーの@jazzsasoriさんとサシ飲みしたのですが, 「エンジニアリングマネージャーとかテックリードとかになると, 議事録（的なメモ）」を取る力無いと辛いよね, 案外言及されてないけど という話題になりました, 酔っ払ってあんまり覚えてないけど🍻*2 で, どれぐらいの方がこの話題に興味あるのかな?と気になり, 昨夜、久々に前職エンジニアリングマネージャー氏と飲んでて、何かの拍子に「エンジニアがビジネスな力をつける訓練の一つとして議事録書くのがいいんだよね」的な話をしたのですが 「エンジニアのための議事録書き入門」とかいうブログ記事って需要あると思いますか皆さん🤔— Shinichi Nakagawa / 中川

こんにちは！JX通信社でMLエンジニアのファンヨンテです。私は自分だけでなくMLチームの成果を最大化するために日々全力を尽くしています！ JX通信社のMLチームでは人的リソースを最大限活用するため "力を使うべき所にのみ注力しよう！" をスローガンに徹底的に効率化しています。 今回はちゅらでーた様と弊社の共同勉強会で私が発表した内容をより掘り下げてお伝えできればと思います。 本内容については ちゅらデータさんとの共同勉強会にて発表しております！ speakerdeck.com 動画を見たい方はこちら を御覧ください〜 R&Dタスクの属人化について 図１ アプリ開発におけるチーム開発(左)とR&Dチームで発生しがちな属人化した、タスクの進め方 弊社はNewsDigestを始めとしたアプリを開発しており、アプリ開発の場ではチームの皆が一丸となり、アプリ開発という一つの目標に向かって協力し合いな

はじめまして。JX通信社でデータアナリストをしている @nrtaking です。 弊社では、7/23〜8/8に行われた東京オリンピック、8/25〜9/5に行われた東京パラリンピックにあわせて関連した日本語ツイートを全量収集し、Twitter Japanなど各社に提供していました。 内容に関する簡単な分析についてはプレスリリースでお伝えしているので、そちらもあわせてご覧ください。 prtimes.jp 実はこのツイート収集システムは、2週間ほどでほぼゼロから立ち上げたものでした。 今回は五輪関連のツイート収集を支えた技術について紹介します。 叶えたかった要件 五輪に関するツイートを、NTTデータの提供するAPIからストリームで受け取り続ける ツイート量などの統計情報やRTが多いツイート情報をダッシュボードの形で見ることができる 上記を（ほぼ）リアルタイムで実現できる 実はこの取り組みにあたり

近況報告も兼ねてたまには日記として書きます. 今日で42歳になりました. コロナ渦の中でも, 健康に元気に仕事もプライベートも生きていけているのは友人・職場の同僚・両親に家族そしてこのブログを含めて応援してくださっている方々のおかげです. いつもいつもありがとうございます🙇🏻 なお干し芋（欲しい物的なリスト的なやつ）はこちらです. このエントリーは, 昨年と同様に 41歳のイチ年間はどういう年だったか（近況報告も兼ねて） 42歳はどうしたいか みたいな話をゆるく書きたいと思います. 41歳のPay-Off Pitch（ふりかえり） 41歳のイチ年間の精算（供養）*1です. お仕事と外部活動 昨年のエントリーにて, ガツッとバリューを出して魅力的な40代男性であるよう, 「明日の自分は今日の自分を超えるやで」的なウザい意識の高さでやっていこうと思います. という言葉を残しましたが, 「魅

最近の野球界隈の出来事が斜め上すぎて驚いてるマンです.*1 本業の仕事および, 本業じゃない個人開発や趣味プログラミングにおいて, データの量が多くて 単位やフォーマットが不揃いで それでも仕事（もしくは趣味の分析）をこなすため, いい感じの使いやすいデータセットにしないと（使命感） という機会は非常に多いです. いや, 機会が多いというより多かれ少なかれ毎日戦っている気がします. 今回は, ちょっとした分析とお遊びのため, メジャーリーグの公式データサイト「Baseball Savant」のデータを使ったBigQueryデータベースを作りたくなったので, クローラーでBaseball Savantのデータを取ってCSVにして CSVからデータを集計したり整えたりしていい感じの単位にして BigQueryから使えるようにしてみたよ！ というタスクをGoogle Cloud Platform

背景 はじめまして、JX通信社でインターンをしている原田です。 近年深層学習ではモデルが肥大化する傾向にあります。2020年にopen aiが示したScaling Laws（[2001.08361] Scaling Laws for Neural Language Models） の衝撃は記憶に新しく、MLP-Mixerが示したように、モデルを大きくすればAttention構造やCNNでさえも不必要という説もあります。（[2105.01601] MLP-Mixer: An all-MLP Architecture for Vision） しかし大きな深層学習モデルを利用しようとすると、しばしば以下のような問題に悩まされます。 推論速度が問題でプロダクトに実装不可能 GPU/TPUはコスト上厳しい プロダクトの性質上バッチ処理が不可能（効率的にGPU/TPUが利用できない） 例えばJX通信社

株式会社JX通信社（本社：東京都千代田区、代表取締役：米重克洋 以下「当社」）は、8月8日に閉幕した東京五輪の大会期間中、日本語による五輪関連ツイート(Twitter投稿) を全量収集及び分析を行いました。その分析結果について、お知らせいたします。 ■ 調査結果概要 東京五輪に関連するツイートは大会期間中で少なくとも4000万件に達していた。 特に野球・ソフトボールや柔道、サッカーに注目が集まったが、新競技であるスケートボードも伝統的な競技に比肩する注目度があった 五輪中止を求めるハッシュタグの使用割合が23日の開会式を経て急激に減少するなど、開会式を経て五輪に対する空気が一変したことが裏付けられた ■ 詳細な結果 ツイートは累計4千万件超え 分析では、一部競技が先行して始まった7月21日から閉会式が行われた8月8日のツイートを対象としました。東京五輪に関連するツイートの数は4000万件を