この記事は RevComm Advent Calendar 2023 7日目の記事です。 RevComm Research の加藤 集平です。音声合成を中心に、音声信号処理の研究開発に携わっています。 昨今、生成AIを利用したフェイク動画（偽動画）が世の中を騒がせています。先日も、岸田首相のフェイク動画がSNSで話題となりました。この動画は内容が明らかに偽物であったこと、動画像が稚拙であったこと、合成音声の質がさほど高くなかったことなどから、視聴者が比較的簡単に偽物と見抜けるものでした。しかし、昨今の技術革新のスピードからすると、近い将来、簡単には偽物と見抜けない動画が出回ることは十分に考えられます。 このような状況に対して現在、国際的な法規制が検討されています。一方で、技術的な対抗手段の研究開発も目覚ましい発展を遂げています。本記事では、フェイク動画を構成する要素のうち、 フェイク音声を検出する技術 の現在について調査しました。 フェイク音声はどのようにして作られるのか フェイク音声に求められる条件 条件1: 声色・声の調子が本人に似ていること 条件2: 任意の内容を話すことができること、あるいは本物の音声の一部を改竄できること 音声合成 音声変換（声質変換） 最新の技術でフェイク音声はどの程度検出できるのか 最新の技術ではどのようにしてフェイク音声を見抜いているのか 検出処理の流れ 評価実験 これからのフェイク音声検出 まとめ フェイク音声はどのようにして作られるのか 本題の検出技術の話題に入る前に、そもそもフェイク音声はどのようにして作られるのかについて説明します。なお、筆者自身は悪意を持ってフェイク音声を作ったことがなく、以下はあくまでフェイク音声検出の専門家が現時点で想定している事柄にとどまることにご注意ください。 フェイク音声に求められる条件 悪意を持ってフェイク音声を作ろうとした場合、フェイク音声に求められる条件とは何でしょうか。筆者の知る限り確立された見解はありませんが、筆者は以下のように考えます。 条件1: 声色・声の調子が本人に似ていること フェイク音声の目的が 特定の個人そっくりの声で偽の内容を話させること だとすれば、声色や声の調子が似ていることは必須の条件でしょう。少なくとも、人間の耳で本物の音声かどうかの判別が難しければ、悪意を持った作成者の意図に合致するでしょう。 条件2: 任意の内容を話すことができること、あるいは本物の音声の一部を改竄できること 任意の内容を話させることができれば、悪意を持った作成者に都合のよい、偽の内容を話させることができます。本物の音声の一部を改竄することでも、悪意を持った作成者の目的を達成できるかもしれません。 音声合成 上の2つの条件を満たすものの一つに、音声合成があります。音声合成のうち広く使われているのはテキスト音声合成 (text-to-speech; TTS) で、テキストを入力すると、テキストの内容を読み上げた音声が出力されます。テキスト音声合成は、電話の自動応答・公共交通機関の自動アナウンス・スマートスピーカーなど、すでに日常生活のさまざまな場面で利用されています。 テキスト音声合成はその半世紀以上にわたる歴史の中で、さまざまな手法が提案されてきました。中でもフェイク音声の文脈で重要なのは、深層学習（ディープラーニング）に基づく手法です。深層学習に基づく手法は従来の手法よりもより自然な声を合成することができます。音声合成が人間と同等の自然性を持つこと（＝あたかも人間が話しているように聞こえる）については、2017年に発表された Tacotron 2 という手法により、限られた条件下ではあるもののすでに達成されています。さらに、2023年には、目標話者（声を模倣したい話者）の音声をわずか3秒だけ用意すれば、その話者の声に類似した音声合成が可能となる手法も発表されています ( VALL-E )。さらに、テキスト情報を手がかりに、音声の一部を編集できるような手法も提案されています ( SpeechPainter )。 研究者は決して悪用するために研究をしているわけではありません。しかしながら、最新の手法はその自然性の高さから悪用が懸念されており、たとえばVALL-Eには誰でも試せるような公式のデモシステムや公式実装は存在しません。一方で、 VALL-Eの論文は公開されている ことから、再現実装や劣化版訓練済モデル *1 は存在します。 音声変換（声質変換） もう一つの方法に、音声変換（声質変換, voice conversion）があります。音声変換は多くの場合、ある話者の音声を入力とし、それを別の話者に類似した音声に変換したものを出力とします *2 。音声変換の手法も深層学習の応用でめざましく発展しており、VTuberなどの分野で、すでに広く利用されています。 悪用の懸念としては、SNSなどに投稿された声（特に、有名人の声など）を訓練データとして音声変換モデルを訓練し、その人の声に類似した音声を出力できるようにして悪用することが想定されています。 最新の技術でフェイク音声はどの程度検出できるのか 結論から言うと、深層学習に基づく手法で作成されたフェイク音声のデータセット（後述）に対して人間の音声かフェイク音声かを判別するタスクにおいて、記事執筆時点（2023年12月時点）でおよそ3%〜4%の等価誤り率 (equal error rate; EER) が達成されています（論文: Automatic Speaker Verification Spoofing and Deepfake Detection Using wav2vec 2.0 and Data Augmentation ）。このデータセットは ASVspoof 2021 という自動話者認証・なりすまし攻撃への対抗手段のチャレンジ（競技会）で提供されたものです。ASVspoof 2021の参加チームのうち最も優れた手法の性能はEER = 15%程度でしたから、わずか2年で劇的に性能が向上していることが分かります。 なお、同じデータセットに対して人間がどの程度フェイク音声を見抜けるかのデータは見つけることができませんでした。ただし、同じく深層学習に基づく手法で作成された別のデータセットに対して、全体的な正解率 (overall accuracy) が70%程度（つまり30%程度は間違えた）であるという研究があります。データセットが異なるので直接の比較はできませんが、最新の技術では人間が判別できないようなフェイク音声を見抜ける可能性があります。 最新の技術ではどのようにしてフェイク音声を見抜いているのか ここでは、上述した Automatic Speaker Verification Spoofing and Deepfake Detection Using wav2vec 2.0 and Data Augmentation という論文で提案されている、およそ3%〜4%のEERが達成されている手法を紹介します。 検出処理の流れ 検出処理の流れ システムに入力された音声は、 wav2vec 2.0モデル *3 で変換されたのち、RawNet2ベースのエンコーダーに通され、 の特徴表現となります（Cはチャネル数、Fはスペクトルのビン数、Tは時間方向のフレーム数）。 エンコーダーから出力された埋め込み表現は、 2次元のself-attention (SA) から得られるattention mapを元に 、周波数方向に着目した特徴表現 ( f ) と、時間方向に着目した特徴表現 ( t ) の2つに変換されます。 そして、fとtはgraph attention networkというグラフ構造で表現されるデータを処理できるネットワークで処理され、最終的に人間の音声か (real) フェイク音声か (fake) が出力されます。 なお、本論文ではwav2vec 2.0と2次元のself-attentionを用いていますが、本論文のベースとなっている AASIST というモデルでは、それぞれsinc layerとmax poolingを用いています。さらに、本論文では RawBoost という手法を使って訓練データの拡張 (data augmentation; DA) を行っています。 評価実験 ASVspoof 2021で使用されたデータセットのうち、LA (logical access) データベースがモデルの訓練に用いられました。評価には、LAデータベースの評価セットのほか、DF (deep fake) データベースの一部も用いられました。 ここでは、フェイク音声を想定したDFデータベースによる評価結果を紹介します（EERのカッコ内は異なる3個のrandom seedによる結果の平均で、カッコ外は最もよい結果）。 評価結果 ( source ) まず、sinc-layerに代えてwav2vec 2.0を導入することにより、大幅にEERが改善しています。これは、wav2vec 2.0のような大規模な事前学習モデルを用いることにより、限られたデータセットだけで（特徴量抽出を含めた）モデル全体の訓練を行うよりも汎化性能がよいためだと推察されています。また、2次元のself-attention (SA) およびdata augmentation (DA) もEERの改善に寄与しています。 これからのフェイク音声検出 フェイク音声検出に関連するイベントとして、 ASVspoof という自動話者認証・なりすまし攻撃への対抗手段のチャレンジ（競技会）が2015年より隔年で開催されています。本記事の冒頭で紹介したように、深層学習の発展により人間が見抜けないようなフェイク音声が登場するリスクはますます高まっています。一方で、フェイク音声を検出する技術もASVspoofのコミュニティを中心に劇的な発展を遂げています。 部分的に改竄された音声 (partially spoofed audio) の検出 など、より難しいタスクの研究も進んでいます。また、音楽生成の分野ではありますが、 AIによって生成された音楽に透かしを埋め込む手法 など、生成AI側からの提案もなされています。このような手法は、AIによって生成された音楽や音声の判別をより簡単にするほか、作成者の意図に反した改竄を防ぐことにもつながると考えられます。 まとめ 本記事では、フェイク音声の検出技術の現在について簡単な解説を行いました。RevCommでフェイク音声に関連する機能は今のところ提供していませんが、筆者は音声合成の研究開発をする者としてフェイク音声のリスクに対して無関係ではありません。法規制・技術的対抗手段について、これからも関心を寄せていきたいと思います。 *1 : VALL-Eの論文ではおよそ6万時間の訓練データを使用していますが、いくつかある再現実装ではおよそ600時間の訓練データが使用されているようです。 *2 : より一般には、音声を入力として、何らかの変換を施した音声を出力とします。たとえば、構音障害（発音器官やその動きに問題があり発音がうまくできない障害）の人の音声を、健常者のような音声に変換する研究もあります。 *3 : 大規模な事前学習モデルであるwav2vec 2.0 XLS-R（人間の音声だけで訓練されている）を、フェイク音声を含む訓練データでファインチューニングしたモデルが使用されています。

この記事は RevComm Advent Calendar 2023 6日目の記事です。 はじめに RevCommのバックエンドエンジニアの中島です。 前回は PyCon APAC 2023への参加レポート を寄稿しました。今回もイベント参加のレポートになります。 今回は 2023年11月25日(土) に開催された ISUCON13 に、弊社内でフロントエンドエンジニア1名＋バックエンドエンジニア2名、計3名のチームで参加しました。 isucon.net 私はISUCONには過去数回参加したことがありますが他の2名は参加なしという経験値で、結果としては最終スコア 7,749点、参加チーム数 694組中 314位でした。 なんとも言い難い順位ですが、参加レポートという形で忘備録として未来の参加者に知見を残せればと思います。 キックオフ 中島は8月入社ですが、8月下旬に社内のエンジニアが全員入っているSlackチャンネルで下記を投稿しました。 このようにRevCommではチームや組織を超えたコミュニケーションが活発で、社内Slackを通して日々情報交換や交流がされています。 ISUCONの参加登録が始まる前に何気なく投稿したものだったのですが、 エンジニアとして活躍する美馬さん、大谷さんにリアクションいただきました。 例年参加希望者が参加枠を大幅に上回っており、ISUCONの最も高いハードルは参加登録とも言われます。 メンバーの美馬さんがその恒例の連打バトルに見事に勝ち切ってくれましたので、参加が決定し、私たち3名は正式にチームとして発足することになりました。 早速それぞれの持っている情報を共有したり役割やチーム名を決めたりと、当日までに必要な準備が始まりました。 このとき、私たちが決めた目標は以下の4つになります。 failureしない 計測する 計測を元に一番大きいボトルネックを潰す 本番までに社内ISUCONやりたい このうち、4. の「社内ISUCON」は社内からのみアクセスできる環境構築の準備に手間取ってしまい、本番に向けた練習時間を確保するために計画が頓挫し、開催できませんでした。 しかし、今でも興味があり私の悲願なのでいつかやりたいです。 当日まで まずは「達人が教えるwebパフォーマンスチューニング」を全員各自で読むことにしました。 多くの知見が詰め込まれている有名な本で、基本的なツールの使い方や典型的なチューニング方法や計測の重要性を学びました。 次に公式の情報や勉強会の情報、過去問の改善方法まとめなどの、役に立ちそうな記事についてそれぞれが情報共有する打ち合わせを数回行いました。 このとき、ISUCONの練習環境を社内で利用しているAWSアカウントに準備したりと、ありがたく社内のリソースも利用させていただきました。 日々忙しくチーム揃って手を動かした練習というのは本番一週間前から2時間ずつ3回に分けて行ないました。 練習の内容としては当日を意識した素振りを意識しており、「Git・SSHの設定」「alpやpt-query-digestのインストールや利用」「DBインデックスの活用」「EC2の複数台構成」などを行いました。 利用言語はGolangの予定でしたので、下記のサイトを参考にNew Relic APM Agentを入れて今回のISUCONのゴールドスポンサーでもあるNew Relicの威力も確認できました。 newrelic.com New Relicは非常に便利でこれさえあればアプリケーションのほとんどの計測ができてしまうわけですが、 チーム内では alp や pt-query-digest といったツールと併用することを決めました。 本番当日 ISUCON 13は 10:00-18:00 で競技が行われました。 特に大きな障害などはなくスケジュール通りに進行が行われ、運営の努力を感じました。 参加者が快適に競技に集中できる環境を用意いただけていたと思います。 実際の時間や作業内容は前後していると思いますが、覚えている限りの当日のスケジュールを書いてみます。 9:00 - 9:30 起床・オンラインで集合 10:00 - 11:00 RepositoryやGit・SSHの準備。最初のベンチマーク取得。アプリケーションのドキュメントの確認。 11:00 - 13:00 alpとNewRelicの計測結果から、icon周りの改善を試みる。「304 Not Modified」の実装をした。テーブル構造やインデックスの有無を把握し、データベース周りの理解を進める。 13:00 - 14:00 休憩 14:00 - 14:30 改めてコードを読んだり改善策を探す。どこから修正すべきか議論しながら、できることからやっていくことに。 14:30 - 17:00 DBのスロークエリにインデックスを貼り始める。中間テーブルの削除を検討したり、DNS周りの最適化ができないか考えたり試したり。スコアがじわじわと伸びていく。 17:00 ランキングが隠れる。己との勝負が始まる。 17:00 - 18:00 この時追加でインデックス貼ったりログを切ったりしながら、少しずつスコアを上げていく。再起動後にベンチを回して通過したところでタイムアップとなる。 あとでポータルを確認してみると 16:53 の時点で 5,576 点だったようで、最後の1時間で2,000点以上スコアを更新していることになります。 ISCUON 13 Portal 最後畳みかけるように改善を行いましたが、やりたいことはまだまだあったので、本当に時間が足りなかったです。 振り返り 初回参加のメンバーが多いので、来年再挑戦できれば多くの点で改善できそうだなと感じました。 今回ざっくりと役割分担はあるものの、ほとんどの改善をチーム全員で確認をしながら行いました。 そのため、もっと手分けし並列に進めるようにすると上手に時間を活用できると思いました。 Miroで振り返り 4つの目標のうち以下の3つを達成できたので、大方ヨシ！とします。 Failureしない 計測する 計測を元に一番大きいボトルネックを潰す 本番までに社内ISUCONやりたい これらの目標を達成するために、私たちのチームでは競技終了直前に再起動テストを実施したり、コマンドラインツールだけでなく New Relic を活用した計測に力を入れました。 まとめ 今回は ISUCON 13 に社内でメンバーを組んで参加したというレポートになりました。 ISUCONというコンペに挑戦する場合でも弊社の社員は非常に協力的で、特にネットワークチームには社内環境を準備する際のアドバイスなどもいただけました。 スコアは物足りない部分がありますが、来年はもっと高得点が取れるように自身のスキルを磨きたいです。 最後になりますが、ISUCON 13の作問に携わって下さった方、運営の皆様、スポンサーの皆様ありがとうございました！

こんにちは、小島です。この記事はRevComm Advent Calendar 2023 12/5 分の記事です。 qiita.com 2023年のRevCommに起きた大きな変化のひとつは、英語話者（日本語の読み書きや会話を前提としない）のエンジニア採用を始めたことです。 昨年までは日本語能力の採用要件がありましたが、今年からその要件なしで採用するようになりました。そのため、日本語を母語とする僕もチームメンバーに英語話者が増えていくにつれて適応することになりました。 僕自身は今までまったく英語学習に興味がなく、英語で仕事をすることになるなどとは思ってもみなかったです。そんな人が実際に業務をやってみてどう感じているかについて書こうと思います。 なお、この記事ではRevCommの業務での英語の使われ方や、自分視点での英語を使った業務を進めることへの感想を書きます。英語学習のTipsといった話はこの記事では書きません。 まえおき 2023年12月現在、日本語が公用語の会社に一部英語話者もいるという状態の組織です すべてのエンジニアに英語の読み書き・会話が求められているわけではありません 言語のスキルも含めてチームを編成をするよう努力をしています 僕が所属しているVideoチーム（MiiTel Meetings開発チーム）を前提にした記事となっています 社内の日英話者混合の別チームで異なる体制をとっているチームもあります 筆者の英語スキル 前提として筆者の英語スキルを書いておきます。 正式に受験したことはないのですが、TOEICの問題集を買って模試をやってみたところだいたい600点ちょっとくらいでした。つまり別に良くもないし、悪くもない、普通といったところです。 受けたのは英語学習をちゃんと始める前（今年の5月ごろ）のスコアですが、現時点でもスコアとしてはそんなものではないかなと思います。 自分の自認としては、 読み書きは遅いけどできる、リスニング、スピーキングはあんまりできない コードレビューで一言コメントとかは英語学習をちゃんとする以前からできてた 長文を書くのはだいぶ難しい 会話の経験はほぼないので、議論をするみたいなことは基本できない ただ何言っているのかの大意はわかる。賛成か反対かとか という感じです。イメージとしては、受験勉強をちゃんとやった大卒社会人が持っている感じの英語力は最初から持っていた、と想像してもらえれば。 今年起きた変化 僕の所属するチームで今年起きたことを簡単に書いておきます。 2022年まで 2023年12月現在 ミーティング 日本語のみ 基本英語に。ただ日本語を話してもOK Slack 日本語のみ 特定のチャンネルでの会話は英語に。チーム同士の会話は日本語話者どうしでも英語で行う機会が増えた GitHubのPRタイトル 特に指定なし 英語のみ チーム内のドキュメント 日本語のみ 翻訳して日英対応を適宜実施。新規ドキュメントは英語のみのものもある。 これらがある日を境に一斉に起きたわけではないのですが、徐々に変わっていき現在はこのような形になりました。もちろん日本語の読み書きも自然と行いますが、開発に関することで日本語を書くことはだいぶ減った印象です。 英語で仕事をして思ったこと 純粋に学習に時間がかかる シンプルに英語学習には時間がかかることがわかりました。 AWSのIAMとかで権限設定しているJSONを読み解けるようになるのって、そんなに根詰めて勉強しなくても1, 2ヶ月あれば自ずと意味がわかってくると思います（諸説あります）。しかし、英語は3ヶ月与えられても目に見える成果を出すのは結構難しいです。 自然言語って難しいですね（遠い目） 主体的にならない限り、仕事中にスキルはあがらない 当たり前なんですが、仕事中は仕事を進めるのが重要です。英語の学習になるからと回り道をさせてもらうなんてことはありません。 ということで、意思疎通が難しければ通訳（僕のチームの場合はPjMがバイリンガル）をしてもらったり、あとでSlackで聞き直したりとかで仕事は十分に前に進みます。別に会話の機会とかも増やそうとしなければ増えません。 一方で業務外で勉強した表現を仕事で使うとか、業務外でインプットした表現が実際に同僚の口から出てくる、といったアウトプットの補助/インプットの強化という観点でスキルを上げる機会を作ることはできると思いました。 リモートでの会議がよりむずかしく感じる 日本語でもビデオ会議は対面での会議とは異なるクセがあると想うのですが、英語だとそれがさらに強く出る気がしています。 これは英語（僕にとっての外国語）のせいなのか、ビデオ会議のせいなのか、はたまたその両方同時にあるからなのかは正直わからないです。 なんとなく英語話者の傾向として、一度話し始めるとこちらが止めない限り止まらないことが多いように思います *1 。そこで一度、相手の話を止めて深掘りするとか、自分のわからないところを伝えて詳細を話してもらうとかいうのが必要だと思うのですが、思っているだけでなかなか行動に移すことができません。 仕事の話をしてないからかもしれませんが、飲み会とか対面で会った時のほうが英語を話しやすい感じがします。 テクノロジーのサポート（Google Meetの自動字幕など）はなにもないはずなのに、なにもない方が外国語を喋れるというのは不思議なものですね。 チームに新たな風が吹く 課題ばかり挙げてしまったのでよいところも書くと、チームの中に新たな視点がもたらされるのでそこはとてもエキサイティングです。 例えば、あるエンジニアがフロントエンドのアーキテクチャーに抜本的な指摘をしたりとか、ブランチ戦略の改善を考えないかと提案してもらったりとか。普段なかなか意識しない、議題にあがらないことを議論のテーブルに挙げてくれる人がいて助かっています。 必ずしも英語話者じゃないとできない指摘ではないのですが、持っている知見や過去開発していたバックグラウンドが日本人チームで日本語を使って開発してきた僕とは明白に違うので、意見をあげてくれてその背景を解説してくれるのはとても勉強になります。 具体的にはFeature FlagやDesign Doc、Trunk ベース開発について、教えてもらったりしました。 相手も外国語学習に苦労してる 弊社で採用している英語話者の場合、英語話者といっても母語が英語とは限りません。たとえば、母語はスペイン語やインドの言語という人が第二外国語として英語を学習し英語を話している、という人の方が多いです。 そんなわけで、外国語学習って大変だよねという意見には多くの人が共感してくれます。 弊社のSlackには #club-language-exchange というチャンネルがあり、日本語についての質問や英語についての質問、英語で雑談を振るなど自由に使われています。そういう場に、英語話者の人がさっと現れてニュアンスの違いを説明してくれたり、逆に日本語話者の僕らも日本語の質問に答えたりします。 基本的にほぼ全員がなんらかの外国語を勉強したことがあるので、質問にはみんなとても優しく答えてくれます。 RevCommに入社してくる英語話者の方は来日が前提になっているのもあり、日本に関心が高い人が多いです。そういう方は日本語の学習も熱心だったりするので、一緒に高め合おうという会話をしたりもします。 終わりに この記事ではRevCommの英語話者エンジニアとの仕事について書きました。 もちろん課題や難しいところもありつつも、複数の言語の交流は複数の文化の交流で楽しい側面もたくさんあります。メキシコのお祭りの話を聞いたり、スイスの列車の話を聞いたりしながら業務ができるのは楽しいです。 異文化交流に興味がある人がこの記事を読んで、日本にも面白い環境があるんだなと思っていただければ幸いです。 *1 : ファシリテーターのPMは、何を言ったかを全部覚えられないのでたまにノートとったりしているそうです。

この記事は RevComm Advent Calendar 2023 4日目の記事です。 弊社は Notion を使っています。 Notion は Mermaid が使えて最高なのですが、 flowchart の theme がアルファベットに若干弱い *1 です。というわけで theme をいじって解決します。 これを書くだけです。 %%{init:{'themeCSS':'line-height:1.1rem;'}}%% *1 : この問題はいつか直るでしょう

この記事は RevComm Advent Calendar 2023 1日目の記事です。 RevCommでバックエンド開発をしている小門 照太です。 MiiTelにおける認証基盤を担うマイクロサービス（MiiTel Account）に携わっています。 MiiTelでは外部のIDプロバイダー（IdP）と連携したシングルサインオン（SSO）によるログインに対応しています。 この記事ではMiiTelのお客様がSSOログインを利用する際に必要となる手順とAccountチームの運用について紹介します。 SSO利用までのステップ 現在MiiTelではOpen ID Connect（OIDC）という認証規格によるSSOに対応しています。 システム基盤にはAWSを使っており、認証機能のバックエンドとしてAmazon Cognitoを採用しています。 お客様がSSOを利用開始するまでに以下の手順があります。 IdP上でOAuthアプリケーションの作成（お客様が実施） Cognitoに1. の設定情報を登録 MiiTelで発行した認可リダイレクトURLをお客様に伝達&IdPに登録 OIDCに対応したIdPとして有名なものにはMicrosoft Entra ID（旧 Azure AD）やGoogle Workspaceがあります。 同じAccountチームの同僚が以前OIDC SSOに関する解説の記事を書いていますので、ぜひご覧ください。 Cognito user pool で OpenID Connect を利用した外部 ID Provider によるサインインを実現する - RevComm Tech Blog 上記の手順においてRevCommとしては2. の作業が必要になります。 サービスの構成管理 MiiTel AccountのWebサービスは社内において独立したマイクロサービスであり、AWS上で構築しています。 上述したCogitoをはじめECS/Fargate、ALBなどのインフラリソース一式は基本的にIaCで構成管理しています。IaCにはTerraformを用いています。 インフラの構成変更、つまりAWSサービスの設定変更やリソース追加/変更/削除などはTerraformコードを変更して適用する運用としています。 Terraformコードを修正するPull Requestを作成し、マージされると設定変更が自動適用されるCI/CDの仕組みを整備しています（詳しくは後述します）。 AccountチームにおけるSSOセットアップ MiiTelのお客様に対するSSO利用開始のためにはCognitoの構成変更が必要となるため、上述したTerraformを用いた構成変更による運用をしています。 OIDC IdPの追加 お客様のIdP設定情報（前述の手順2.）はCognitoユーザープールにおける「アイデンティティプロバイダー」として登録します。 参考 - ユーザープールへの OIDC ID プロバイダーの追加 - Amazon Cognito Terraformでは aws_cognito_identity_provider リソースです。 aws_cognito_identity_provider | Resources | hashicorp/aws | Terraform | Terraform Registry resource "aws_cognito_identity_provider" "azure_customer_A" { user_pool_id = "ap-northeast-1_XXXX" provider_name = "for-Customer-A" provider_type = "OIDC" ... provider_details = { client_id = "1234aaaa-bbbb-cccc-dddd-eeeeeeeeeeee" client_secret = "dummy" ... } } 上述したステップ1. でお客様が作成したOAuthアプリケーションのパラメーターを provider_details に設定します。なお client_secret は秘匿情報と見なし、Terraformコードではダミーの値を入れるようにしています。 変更の適用 Terraformコードを変更したらPull Requestを作成します。 CI/CDの自動化として、GitHub Actionsを利用して構成変更のレビューおよび適用できる仕組みを整備しています。 参考 - Automate Terraform with GitHub Actions Pull Requestを作成するとCIのジョブが起動してlint（ terraform fmt ）、dry run（ terraform plan ）などの実行結果がコメントに追記されます。 GitHub Pull Requestのキャプチャ Show Plan で terraform plan の出力結果を確認できます。 ... # module.~~~~~~~~~~~~~~~~~ will be created + resource "aws_cognito_identity_provider" "oidc_google" { + attribute_mapping = { + "email" = "email" + "given_name" = "given_name" + "username" = "sub" } + id = (known after apply) + provider_name = "for-Customer-A" + provider_type = "OIDC" + user_pool_id = "ap-northeast-1_xxxx" ... } ... Plan: 1 to add, 1 to change, 0 to destroy. 変更内容に問題ないことを確認してPull Requestのレビューを受けた後、マージすることでリリース（ terraform apply ）も自動実行されます。 リリースの実行確認後、client_secretをマネジメントコンソールから手動修正、そして前述のステップ3.「MiiTelで発行した認可リダイレクトURLをお客様に伝達&IdPに登録」して頂ければSSOを利用開始することができます。 まとめ MiiTelにおけるSSOをご利用頂くにあたる開発チームとしての運用をご紹介しました。 本記事で紹介した各ステップは、作り込み次第では手順をより少なくできたり完全自動化するような方法もあるかと思います。 しかし本機能の利用シーンは1か月あたり数件程度であり、過度な作り込みはせずまずは属人化を防ぎつつリードタイムの少ない方式を確立することを優先し、現在の運用に至っています。

This article is the English version of Yuta Takase's blog post . Table of contents Table of contents 1. Introduction 2. What is YOLO? 3. YOLOv8 4. YOLOv8 model size 5. Changes with YOLOv5 6. YOLOv8's building and inference execution Inference on images Inference on videos Supplement Supported video formats Text output of detection results Model inputs 7. Overview of the inference results for each model 8. Summary References 1. Introduction Hello, I am Takase, a Research Engineer at the RevComm Research division. In this blog post, I will introduce YOLOv8, the famous object detection framework released by Ultralytics in early January 2023. I will also compare the changes with previous versions and show how to run it. 2. What is YOLO? As many people might know, YOLO is an object detection method proposed in the paper You Only Look Once: Unified, Real-Time Object Detection presented by Joseph Redmon et al. at CVPR2016. The name YOLO stands for You Only Look Once. YOLO improves the slow processing speed of object detection methods by simultaneously detecting and identifying objects. This feature made it a pioneer in real-time object detection with breakneck inference speed. This method is a must-see among the various techniques introduced to date for anyone interested in the topic. This article does not provide a detailed explanation of YOLOv8 – there are already superb explanatory materials on the internet. 3. YOLOv8 YOLOv8 is the latest version of the YOLO model released by Ultralytics, the publisher of YOLOv5. YOLOv8 allows object detection, segmentation, classification tasks, and training on large data sets. It can run on a variety of hardware, including CPUs and GPUs. It also features a new backbone, loss function, anchor-free detection head, and backward compatibility, allowing us to switch between different versions and compare performance. Currently, v3, v5, and v8 configurations are available in the official repository . As of this writing, the YOLOv8 paper is yet to be published. 4. YOLOv8 model size YOLOv8 has five pre-trained model patterns with different model sizes: n, s, m, l, and x. The number of parameters and COCO mAP (accuracy) below show that the accuracy has improved considerably from YOLOv5. In particular, for the larger model sizes l and x, the accuracy improved while the number of parameters was reduced [ reference ]. The table below shows the other models' parameters [ reference ]. 5. Changes with YOLOv5 YOLOv8 has several changes from YOLOv5, but two stand out from the rest at the time of this blog post: Introduction of C2f layer Decoupled head and removal of the objectness branch. In addition, some conv modules have been removed; kernel size has been changed, among other minor improvements. Although not official, a diagram of the YOLOv8 detection model architecture published by RangeKing is a helpful guide. YOLOv8 detection model's architecture by RangeKing [ Reference ] 6. YOLOv8's building and inference execution In this chapter, I will install and play some examples in YOLOv8. This time, I will use a pre-trained model to verify how well it works in a M1 MacBook Pro CPU environment. My environment is as follows: MacBook Pro (13-inch, M1, 2020) 16GB Mac OS Monterey First, you can install YOLOv8 with the command below. pip install ultralytics Now that the installation is complete, let's run it. This time, we will try the inference with a Python script. Inference on images First, let's enter the input. This article will use an image showing a bus and a person . The image size is 810x1080. from ultralytics import YOLO # load pre-trained model. model: YOLO = YOLO(model= "yolov8n.pt" ) # inference # set save=True to store the resulting image with the inferred results. result: list = model.predict( "https://ultralytics.com/images/bus.jpg" , save= True ) YOLOv8n's inference results Inference on videos Let's try inference on videos with YOLOv8x , since we used YOLOv8n for images. The interface is the same, but we pass the path of the video file as an argument. from ultralytics import YOLO # load pre-trained model. model: YOLO = YOLO(model= "yolov8x.pt" ) # set save=True to store the inferred results. result: list = model.predict( "MOT17-14-FRCNN-raw.mp4" , save= True ) This time, we will use the video from the MOT Challenge MOT17 test set . The MOT17 video file is in WebM format, so we converted it to mp4 in advance. The converted video is 30 seconds long, and the frame rate is 30, so inference is performed on 900 images. YOLOv8x's inference results Supplement Supported video formats The image and video file formats supported by YOLOv8 are as follows. Images: "bmp", "dng", "jpeg", "jpg", "mpo", "png", "tif", "tiff", "webp", "pfm" Video: "asf", "avi", "gif", "m4v", "mkv", "mov", "mp4", "mpeg", "mpg", "ts", "wmv" Definitions of supported file formats in the code are here . Text output of detection results When performing inference, saving the detection results as text is often desirable. # Output an image with the detection results drawn and in text model.predict( "https://ultralytics.com/images/bus.jpg" , save= True , save_txt= True ) # Output the detection result and the confidence of each object in the text model.predict( "https://ultralytics.com/images/bus.jpg" , save_txt= True , save_conf= True ) Other arguments can be set to the prediction function. Please refer to the official documentation . Model inputs Although we have specified a single video path to check the operation, you can pass multiple ones as a list. source_list: list = [ "./sample1.jpg" , "./sample2.jpg" ] result: list = model.predict(source_list, save= True ) 7. Overview of the inference results for each model Now that we have built an environment and performed inference let's try it on the YOLOv8 s to l models. In addition to YOLOv5, we will also compare the output results of YOLOv6 and YOLOv7, released within the past year. This time, we want to compare the accuracy of each model rather than the output of each model from a bird's-eye view. I will not go into the details of YOLOv5, YOLOv6, and YOLOv7, but if you are interested in these models, please check them out. YOLOv6 (v3.0) is used as the version for YOLOv6 since it was released almost simultaneously with YOLOv8. YOLOv8's sample images are used as the target images. The following is a summary of the images depicting the detection results of each model, information on the detected objects, and the inference speed. YOLOv8 YOLOv7 YOLOv6 (3.0) YOLOv5 YOLOv8l and x can detect the bicycle in the upper right corner of the image, which was not seen by YOLOv5l and x. The confidence of the detected objects in YOLOv8 shows that it has improved over YOLOv5. All models are fast, although YOLOv7 is slower. 8. Summary This article has provided an overview of YOLOv8, the differences from previous versions, and a brief description of how to use it. My impressions of YOLOv8 are: It is easy to install (run pip install ), easy to use, and has a well-organized interface. It is simple to convert to onnx, torchscript, etc. YOLOv5 was also user-friendly, but v8 has improved further in that regard. Although I have yet to mention model export , it is a valuable tool for exporting models in various formats and executing them efficiently. References https://github.com/ultralytics/ultralytics https://docs.ultralytics.com/ https://github.com/meituan/YOLOv6 https://github.com/WongKinYiu/yolov7 https://github.com/ultralytics/yolov5 https://github.com/ultralytics/ultralytics/issues/189 https://motchallenge.net/data/MOT17/ https://blog.roboflow.com/whats-new-in-yolov8/

RevComm Research の加藤集平です。8月下旬に音声処理のトップカンファレンスである INTERSPEECH で発表するため、また引き続いて行われた ISCA Speech Synthesis Workshop (SSW) に参加するためにヨーロッパに出張をしてきました。今回の記事では、INTERSPEECH, SSWおよび私の発表について紹介いたします。 加藤集平（かとう　しゅうへい） シニアリサーチエンジニア。RevCommには2019年にジョインし、音声処理を中心とした研究開発を担当。ADHDと付き合いつつ業務に取り組む2児の父。 個人ウェブサイト X → 過去記事一覧 INTERSPEECH 会議の概要 International Speech Communication Association (ISCA) が主催する国際会議で、音声処理分野を専門に扱う国際会議としては最大級の規模です。2004年にそれまで行われていた2つの国際会議European Conference on Speech Communication and Technology (EUROSPEECH) とInternational Conference on Spoken Language Processing (ICSLP) を正式に統合した国際会議としてINTERSPEECHが開催され、以降毎年開催されています。 開催期間 2023年8月20日〜24日（チュートリアル1日＋発表4日） 開催地 The Convention Centre Dublin、ダブリン（アイルランド） 対象分野 音声処理・音声コミュニケーション全般（音声認識・音声合成・音声変換・音声翻訳・音声符号化・音声対話システム・音声知覚・音声生成など） 発表件数 1,097件（採択率49.7%） 参加人数 およそ2,000人 会場の様子 4日間で1,000件を超える発表を行うため、7つのオーラルセッション（口頭発表）と4つのポスターセッションが並行しての進行でした。 8月22日のプログラム（ INTERSPEECH2023のウェブサイトより引用 ） 会場の大きさは様々でしたが、どの会場も多くの参加者で賑わっていました。 口頭発表会場の例（写真は比較的小さな会場） ポスターセッションの会場 私の発表について 題目（リンク先は論文のアーカイブです） Speech-to-Face Conversion Using Denoising Diffusion Probabilistic Models （ノイズ除去拡散確率モデルを用いた音声から顔への変換） 本研究の主な貢献 Speech-to-face（音声を入力として、それに適した顔画像を出力するタスク）において、初めて拡散モデル（ノイズ除去拡散確率モデル）を導入しました。その結果、よりシンプルかつ柔軟なシステムで、これまでの研究よりも高解像度 (512×512) の顔画像を生成することに成功しました。 ポスター資料 いただいた質問 2時間の発表時間中ほぼ途切れることなく来客があり、以下のような質問をいただきました。 どのような応用先を考えているか？ 将来的に、コールセンター等での応用を考えている。カスタマーサポート（特にクレーム対応）などの顔を出せないような場面で、声に適した顔を生成することでコミュニケーションを円滑にするといったことが考えられる。 顔画像の生成にはどの程度の時間がかかるか？ GPUを使って1枚あたり数分かかる。ノイズ除去のステップ数が多いためであり、ステップ数を削減するための技術を応用することで短縮が可能であると考えている。 データセットはバイアスを内在しているのではないか？内在しているとすれば、何か対処をしているか？ 今回モデルの訓練および評価に使用したデータセット ( AVSpeech および FFHQ Dataset ) は多様な人々や言語を対象として集められたものであるが、それでも見た目や性別等のバイアスは存在する。今回は特に対処していないが、実用化においては重要な問題だと考えている。 ISCA Speech Synthesis Workshop (SSW) 会議の概要 INTERSPEECHのサテライトワークショップ（付随して開催される小さな会議）として、 ISCA Speech Synthesis Special Interest Group (SynSIG) によって開催されているものです。音声合成を専門に取り扱っており、1990年から3年おき、2019年からは隔年で開催されています。 開催期間 2023年8月26日〜28日（INTERSPEECH閉幕の2日後から3日間） 29日に同じ会場でBlizzard Challengeが開催 開催地 グルノーブル・アルプ大学、グルノーブル（フランス） 対象分野 音声合成・音声変換 発表件数 通常発表（査読あり）36件（採択率82.2%） Late Breaking Reports（査読なし）7件 参加人数 110人 会場の様子 発表件数も参加者も小規模であり、すべての発表はシングルトラックで進行されました。 口頭発表会場 ポスターセッションの会場 INTERSPEECHとの違い SSWは音声合成専門のワークショップということで参加人数が小規模でした（110人）。コーヒーブレイクだけでなく昼食も会場内で提供され、休憩時間にもお互い気軽に話しかけられる雰囲気でした。全員が音声合成を専門としているので、話も盛り上がります。 1日目の終わりに開催された懇親会の様子 ポスターセッションも枚数が少ないため（1時間半の枠で12枚）、すべてのポスターを見て回ることができました。INTERSPEECHを含む昨今のトップカンファレンスでは発表件数が非常に多いためにすべての発表を見て回るのは不可能ですが、SSWのように分野を絞って開催されるワークショップは違った雰囲気を楽しむことができました。 Blizzard Challenge SSWとしてのプログラムは8月26日〜28日の開催でしたが、引き続いて29日には同じ会場で音声合成の競技会である Blizzard Challenge の発表が行われました。Blizzard ChallengeはSSWと同じくSynSIGが主催するイベントで、所定の期間内に、与えられたデータセットを利用して音声合成器を作成し、その品質を競う競技会です。音声合成の技術発展を目的として2005年から毎年開催されており（2022年のみ不実施）、今年の課題はBlizzard Challengeでは初めてとなるフランス語の音声合成でした。 冒頭、今年のBlizzard Challengeの概要と結果の発表が主催者からありました。今年の参加者は18チームで、各チームが提出した音声を元に主催者が聴取実験（音声を多数の人間が聞いて評価する）を実施し、その品質が競われました。品質（人間の音声らしいかどうか）は722人の評価者により、1から5の5段階で評価されました。 結果としては、自然音声（人間の音声）とほとんど同等であるという評価を受けたチームから、自然音声とかなり差があると評価されたチームまで、バラツキがありました。 評価結果の説明 主催者による概要と結果の発表に引き続き、各チームから手法の説明が口頭発表の形式で行われました。上位を獲得したチームの発表にはやはり注目が集まりましたが、あえてユニークな手法で挑戦したチームもあり、成功例・失敗例とも大いに参考になるものでした。 会の最後には、次回のBlizzard Challengeの課題の参考とするために、参加者にアンケートが取られました。実は音声合成の分野では、ここ数年の急速な技術革新により、単一話者・単一言語（特に英語などよく研究されている言語）の原稿を読み上げた音声（読み上げ音声）については、十分な訓練データがあれば自然音声（人間の音声）とほとんど同等の品質が達成できる状況になっています。Blizzard Challengeは音声合成の技術発展を目的としたイベントですから、音声合成コミュニティーとして目指すべき次の方向性を探るべくアンケートが取られたわけです。 アンケートの結果としては、「低資源・ゼロショット」（訓練データが少ない、あるいは未知の話者や方言に対応する）、「（原稿を読み上げた音声との対比としての）自発的・会話的音声※」に多くの票が集まったようです。 ※記事執筆時点（2023年11月）では、音声合成モデルの訓練には一般的に「原稿を読み上げた音声（読み上げ音声）」が使われます。これに対して、原稿なしで発話された音声を録音したものを自発的音声 (spontaneous speech)、2人以上の会話を録音したものを会話的音声 (convasational speech) などと呼ぶことがあります。 アンケートの結果 まとめ 8月下旬に音声処理のトップカンファレンスであるINTERSPEECHで発表するため、また引き続いて行われたISCA Speech Synthesis Workshop (SSW) に参加するためにヨーロッパに出張をしてきました。2,000人の参加者で賑わったINTERSPEECH、110人の参加者でお互いの顔の見えたSSW（そしてBlizzard Challenge）、それぞれに違った楽しみがありました。 INTERSPEECHでの発表では多くの方と有意義な議論をすることができました。今回の発表もチーム内で議論してベストなものを発表しましたが、世界中の研究者と議論することで新たな課題や方向性が見つかるものだということを改めて実感する機会となりました。 RevComm Research では、今後も継続的に研究発表を行っていきます。一緒に働きたい方を募集しています。

This blog post is the work of Hongkai Li, edited by Tolmachev Arseny. The authors belong to Works Applications and are working for RevComm. TL;DR Background Evaluation Metrics Experiments Datasets and Systems Results Correlation Among the Metrics Micro Analysis: Relevance-Based Metrics Micro Analysis: Factual Consistency-Based Metrics Evaluating Factual Consistency of Reference Summaries Performance Differences by Dataset ChatGPT’s Behavior FactSumm’s Behavior Dialogue vs. Narrative . TL;DR We tried different summarization metrics with four datasets and summarization models. Our findings are: Relevance metrics give different results from factual consistency metrics. Some metrics, especially factual consistency metrics, perform differently between dialogue summarization and conversational summarization. It is essential to choose different metrics according to the purpose of the evaluation, especially from the industrial perspective. Many metrics are not easy to adapt to other languages, especially those that require fine-tuning models. Background During the development of summarization systems, we need to measure the performance of the system and compare it to different systems. We use various performance metrics for this. Probably, the most important direction to compare is the quality of summarization itself. In this blog article, we give a very brief overview of several summarization evaluation metrics and our experiments on evaluating those metrics with a focus on summarizing dialogues. We investigated various existing summarization evaluation metrics, focusing on relevance and factual consistency, across several systems and datasets by comparing the scores and correlations between each other. Here, we would like to share our results and findings. Document summarization is the process of reducing the size of a document while keeping the main concepts. ROUGE and BLEU are widely used as evaluation metrics for the summarization task. ROUGE and BLEU do not capture paraphrased expressions (same meaning but different words). Several scores have been proposed in recent years to address this issue. Most proposed scores are word-based methods such as BERTScore . However, other methods have been proposed for the past three years. For example, there are evaluation methods using information extraction and question-answering . Evaluation Metrics There are a lot of aspects for evaluating a summary, such as coherence, consistency, fluency, and relevance, as suggested in this article and this article . Most works focus on relevance or/and (factual) consistency. Relevance measures how well the summary captures the key points of the source document. It focuses on whether all and only the important aspects are contained in the summary. The key points are usually included in reference summaries. So, relevance scores are usually calculated with system summary and reference summary pairs. Factual consistency is defined as the factual alignment between the summary and the summarized source. A factually consistent summary contains only statements that are entailed by the source document. So, factual consistency scores are usually calculated with system summary and source text pairs. The example below describes the two very well. The summary in the first row fails in relevance, and the second has a factual error. Figure 1. Examples of relevance and factual consistency errors ( source ) Figure 2. Difference between relevance and factual consistency metrics ( source ) For years most papers have been using ROUGE to measure summaries. Recently, especially since 2019, researchers have focused on factual consistency of summarization. LLMs such as ChatGPT further contributed to this trend because there are often hallucinations in their outputs. So, we focused on both aspects and chose the existing evaluation metrics listed below. A very brief description of those metrics is provided in Figure 2. Table 1. Relevance metrics Metric Japanese? TL;DR ROUGEcode Perfect Exact n-gram overlap (ROUGE-n) or longest common sequence (ROUGE-L) between 2 texts (e.g. summary and reference) BERTScorecode Yes, needs BERT model Calculate similarities between 2 sentences and get recall and precision scores using contextual embeddings from a pre-trained BERT model. MoverScorecode Yes, needs BERT model Extension of BERTScore that uses hard alignments between sentences. With Word Mover Distance (WMD) developed from Earth Mover Distance (EMD), MoverScore finds the minimum effort to transform a text to the other to get soft alignments. BARTScorecode Maybe, needs fine-tuning Weighted log probability of one text given another text Table 2. Factual consistency metrics Metric Japanese? TL;DR OpenIE *code Maybe. needs a Japanese entity relationship extractor Extracts triples from both the summary and source document and evaluate whether the triples of the summary are included in those of the source document FactCCcode Maybe. Needs data or data generation scripts. FactCC: A classifier to judge whether a summary is factually consistent with the source document.FactCCX: I think the X means explanation, meaning this model is able to explain why the summary is wrong. DAEcode Maybe, needs Japanese dependency parsing and model training. Dependency Arc Entailment. DAE views dependency arcs as semantic units and each arc is judged independently based on whether the relation it implies is entailed by the source sentence. QAGS *code Maybe, needs Japanese QA and QG models. QAGS is based on the intuition that if we ask questions about a summary and its source, we will receive similar answers if the summary is factually consistent with the source. CoCocode Maybe, needs BART CoCo selects key tokens in summary and masks the tokens in the source document. The masked source document is then fed to the scoring model. If the scoring model is still able to generate the masked token with a high possibility, it means that the token is more likely to come from the scoring model instead of the source document. Therefore a penalty should be added. SummaCcode Maybe, needs training/fine-tuning Sentence level alignment. FactGraphcode Maybe, needs Japanese AMR FactGraph uses abstract meaning representation to form the graph of a sentence and then uses the model above to give the final score. * For OpenIE and QAGS, we use the implementation from a toolkit called FactSumm . Experiments Datasets and Systems We conducted experiments on the following datasets and systems. The aim of the experiments is to Investigate the advantages and disadvantages of each metric Compare the results between relevance and factual consistency-focused metrics We used the following datasets for the experiments. Samsum dataset contains instant messenger-like conversations with summaries. Conversations were created and written down by linguists fluent in English. CNN / DailyMail Dataset (CNNDM) is an English-language dataset containing just over 300k unique news articles written by journalists at CNN and the Daily Mail. XSUM consists of online articles from the British Broadcasting Corporation (BBC) and single-sentence summaries. Specifically, each article is prefaced with an introductory sentence (aka summary), which is professionally written, typically by the article's author. DialogSum consists of three public dialogue corpora, as well as an English speaking practice website. These datasets contain face-to-face spoken dialogues that cover a wide range of daily-life topics, including schooling, work, medication, shopping, leisure, and travel. Table 3. Dataset summary   DialogSum Samsum CNNDM XSUM Num. of documents in the train dataset 12,460 14,732 287,113 204,045 Num. of documents in the test dataset 1,500 819 11,490 11,334 Num. of tokens in a source document 210 157 868 487 Num. of tokens in a summary 35 26 66 26 Compression Rate 17.80% 21.40% 9.20% 9.50% Table 4. Scope of experiment; ”o” means the target Dataset＼System ChatGPT GPT3 Flan-T5 T5 Samsum ○ ○ ○ ○ CNNDM ○ - ○ ○ XSUM ○ - ○ ○ DialogSum ○ - ○ ○ For Flan-T5 and T5, we either used existing fine-tuned models or fine-tuned flan-t5-large or t5-large with the datasets by ourselves. The models used for the Samsum dataset are: philschmid/flan-t5-base-samsum jaynlp/ t5-large-samsum Results Correlation Among the Metrics Figure 3. Heatmap of Pearson correlation among the metrics Figure 3 shows the Pearson correlation among the metrics. Metrics from rouge1 to bart_hypo_ref are categorized as relevance metrics, and metrics from dae to factcc are factual consistency metrics. We can clearly see that relevance metrics correlate with each other while having a low correlation with factual consistency metrics, except the bart_hypo_ref score. Factual consistency metrics only correlate with factual consistency metrics as well. For relevance metrics, some metrics have precision, recall, and F1 scores. We can find recall scores ( bert-r-r , bart_hypo_ref , etc.) have a relatively low correlation with precision scores ( bert-r-p , bart_ref_hypo , etc.). In most cases, the ROUGE scores seem enough to reflect the performance at the system level. The low correlation between retrieval and factual metrics can be explained because they focus on different aspects. Sometimes, a summary may get a high relevance score because it is extremely similar to the reference summary with only a 1-word difference. However, this word is very important and changes the whole meaning of the summary. Factual consistency metrics are able to capture this kind of error. Additionally, some summarizers may output more information that is not included in the reference summary, but according to the source text, the information is true and consistent. This will also contribute to the low correlation. See the example below. Source Dialogue Rudi: Hetta, did you see the last trump video Henrietta: nope Henrietta: what did he do now? Rudi: <file_video> Henrietta: OMG Henrietta: what a jerk Rudi: it gets worse Rudi: <file_other> Rudi: the whole interview is here Henrietta: can't believe he said that about a congress woman Rudi: yeah Henrietta: do you wonder where the limit is? Rudi: wdym Henrietta: if he will say something that will actually get him kicked out of the white house Rudi: not really Henrietta: fuck Rudi: yeah Reference Summary Trump is acting like a contemptible fool and it is getting worse. Rudi has sent Henrietta the link to his interview. System Summary Rudi and Henrietta discuss a video of Trump insulting a congresswoman, and wonder if he will say something that will get him kicked out of the White House. ROUGE LSUM 0.1632653061 FactCC 1 CoCo 0.441158 Here, the system summary includes more facts (e.g. White House) than the reference one, so it gets a better FactCC score than the reference one. Micro Analysis: Relevance-Based Metrics As mentioned above, the bart_hypo_ref score correlates with neither other relevance metrics nor factual consistency metrics. It is defined as recall, which is the probability of generating the reference summary from the system summary, according to the BARTScore paper. So, we can find it relatively correlates with   bert-r-r , bert-d-r , and bart_cnn_hypo_ref . By investigating and comparing the scores of each sample of different systems, we found that for example, the range of the bart_hypo_ref scores of Flan-T5 with Samsum was (-13, -0.7), while that of ChatGPT was (-8.6, -0.8). As a result, the average score of ChatGPT was higher than Flan-T5, even though Flan-T5 outperformed ChatGPT in other metrics. BARTScore seems very risky because it does not have a specific range. Micro Analysis: Factual Consistency-Based Metrics When investigating the scores from DAE, we found that more than 90% of the samples scored more than 0.90 (90%). Take the sample from Samsum below, for example: The T5 output had only one thing wrong: the neighbors are only Ricky’s new neighbors but not Frederick and Ricky’s. Since dae is based on dependency arcs, it is relatively easy to understand that most arcs match the source text, so the score was extremely high. On the other hand, factcc is a binary classifier. If the sentence contains any wrong information, the whole sentence will be false. And since the T5 output only had one sentence, the final score was 0. The factsumm-qa  is based on facts (QA pairs) extracted from the source text and the system summary and can recognize that some parts of the sentence are true while some are false. This remains a problem whether we should allow partially correct summaries or reject summaries containing any false information ( factcc  vs. factsumm-qa ). Evaluating Factual Consistency of Reference Summaries Factual consistency-based metrics calculate scores with the source document and system summary pairs, while relevance-based metrics use system and reference summary pairs. We are pretty curious about whether reference summaries can get high scores in factual consistency-based metrics, so we fed some of the evaluators with source documents and reference summary pairs of Samsum corpus. Here are the results. Metrics Ref ChatGPT GPT-3 Flan-T5 T5 FactSumm-src-fact 0.0122 0.0147 0.0119 0.0142 0.0159 FactSumm-src-qa 0.2786 0.2731 0.2644 0.2963 0.3186 FactSumm-src-triple 0.0348 0.0514 0.0428 0.0739 0.1096 FactCC 22.1 21.25 27.11 21.37 18.93 DAE 95.16 93.78 91.82 93.4 94.71 CoCo 24.64 27.7 24.82 30.61 34.55 Red  = Worst, Blue  = Best Interestingly, reference summaries even got the worst scores in some of the metrics. It may be because the evaluators failed to extract facts from the source document or summary. From this perspective, DAE may be the best or most convincing evaluation metric. Performance Differences by Dataset We used four datasets with different properties for our experiments and observed that systems performed differently among the datasets. ChatGPT’s Behavior From our observation, ChatGPT tends to output more information than needed to make perfect answers. Regarding summarization, it tends to output longer summaries than other systems. This results in 2 main consequences: ChatGPT got relatively higher recall scores, such as the hypo-ref direction of BARTScore, which is defined as ‘recall’ in BARTScore’s paper, and recall scores of BERTScore. And conversely, the precision scores, such as the ref-hypo direction of BARTScore are extremely low. ChatGPT got higher factual consistency scores in certain metrics with some of the datasets. Since ChatGPT tends to output more information, and considering ChatGPT’s ability to extract information from the input, the extra information is also consistent with the source text, making factual consistency scores relatively high. This is especially obvious for the XSUM dataset because each reference for each document is only one sentence. Flan-t5 and t5 models have been fine-tuned with XSUM’s training data, so the two models only produce one-line summaries as well. On the other hand, summaries from ChatGPT always include several sentences, so ChatGPT got relatively high scores in recall and extremely high scores in factual consistency, while other relevance scores were very low. FactSumm’s Behavior We have also observed that some evaluation metrics performed differently among the datasets. Take FactSumm, for example. We got extremely low scores with all systems among all datasets except CNNDM. We consider it was because FactSumm extracts information from source texts and summaries to compare the pairs. Since both source texts and summaries of CNNDM are relatively long and formal, FactSumm can extract more facts from both. When we investigated the results of FactSumm for other datasets, we found that many summaries were scored 0 because FactSumm failed to extract any entity from the data. We consider this as a big disadvantage of FactSumm (or OpenIE, to be precise). Dialogue vs. Narrative From our observation, information extraction-based metrics such as OpenIE or DAE failed to extract important information because the person name of the speaker is in the front of their lines. Abstractive summarizers can summarize the lines with the correct speaker name, but extractive methods sometimes fail to recognize that, resulting in low scores. Below is a simple example of this phenomenon by FactSumm (OpenIE, QAGS): Input Input Source Text Jack killed John. Jack: I killed John. (*3) Input Summary Text Jack killed John. factsumm-fact (*1) Facts None Fact Score 0 factsumm-qa Answers based on SOURCE [Q] Who killed John? [Pred] Jack [Q] Who did Jack kill? [Pred] John [Q] Who killed John? [Pred] <unanswerable> [Q] Who did Jack kill? [Pred] John Answers based on SUMMARY [Q] Who killed John? [Pred] Jack [Q] Who did Jack kill? [Pred] John QAGS Score 1 0.5 factsumm-triple SOURCE Triples ('Jack', 'killed', 'John') None SUMMARY Triples ('Jack', 'killed', 'John') None (*2) Triple Score 1 0 *1. For factsumm-fact, since both samples got the same results, the details are omitted. *2. FactSumm only outputs common triples of source and summary. *3. When we changed the input source text to ‘Jack said that he killed John.’, the results were the same as ‘Jack: I killed John.’ This is considered to be able to be avoided by fine-tuning with dialogue data.

Introduction Hi! My name is Jose, a software engineer working for RevComm. In this blog post, I'll discuss four takeaways from my first PyCon APAC and the most interesting talks I attended. What is PyCon APAC? PyCon APAC is a non-profit annual Python conference organized in countries of the Asia-Pacific Region. The 2023 edition in Tokyo consisted of four days: one tutorial, two conferences, and one development sprint. Lessons 1. Plan ahead Every PyCon exhibits the most varied collection of talks, from obscure tricks of the language to the technical marvels of frameworks. This year, there were more than fifty presentations in English and Japanese across five tracks. To get the best out of them, prepare an agenda. Read each talk's description; sometimes, the title is enough, and choose where you are going. Creating a calendar for the event in iCal or gCal is especially useful for coordinating with friends. Just so you know, the schedule above took me around forty-five minutes. 2. Take time for the sponsor booths My first major mistake was forgetting about the sponsor booths. I skipped the last two tracks of Day 2 to go around, and It was worth it! Check them out. They are a fantastic reference for the country's Python market – what different companies are doing, their stack, and who is hiring. You might be as surprised as I was to find unexpected sponsors. The stamp rally was a great motivator, too. 3. Talk to people Any major conference is an opportunity to engage with the community. Talk to people. I met so many charming characters and learned a considerable amount. If you don't have time on the conference days, the official and unofficial parties are ideal for networking. 4. Join the developer sprint As the famous proverb says: After two days of conference and drinking parties, the developer sprint sounds like a stretch. It’s not. You will be surprised how productive you are in a couple of hours. For instance, my team merged a PR to the cPython's official repo! macOS CI for CPython now supports `free-threaded` mode CI as the conditional CI. It was done during the PyCon APAC sprint. https://t.co/rrcRxtkw7K #pyconapac pic.twitter.com/7pULkgP9By — Donghee Na (@dongheena92) October 29, 2023 Coding along with people you've just met is as open-source as it gets. Talks I attended eight talks, seven in English and one in Japanese. For brevity, I'd like to discuss the ones who impressed me the most. Write Python for Speed by Yung-Yu Chen https://2023-apac.pycon.jp/timetable?id=WNN9WG www.youtube.com This talk goes deep into optimizations for speeding up your Python programs. Although the field of application was outside my current job, Chen's passion and wit made me follow it until the end. I loved some of his quotes: "Python is the second-best language for everything." "To go fast, you do dangerous things." Couldn't agree more. Beaming up to the flow! by Thu Ya Kyaw https://2023-apac.pycon.jp/timetable?id=KKELHA www.youtube.com An enlightening talk about data streaming, the basics of Apache Beam, and the feature engineering process at Google. The expositor was also present at the Google Cloud booth, so I got to ask many questions. Debugging and Troubleshooting Python Applications by Neeraj Pandey https://2023-apac.pycon.jp/timetable?id=C7HGZS www.youtube.com This talk deepens into logging, profiling, and debugging in monolithic and distributed systems. I was blown away by OpenTelemetry. What does your application need to run on production? by Shota Kokado https://2023-apac.pycon.jp/timetable?id=FHTQDR www.youtube.com After years of working in Software Engineering, this talk was a good refresher on all the basics any production-ready application should have. The talk is in Japanese, but you can extract the vital information from the slides. So for next year… Indonesia will host next year's PyCon APAC. We also have the annual PyCon JP. And many more! Check pycon asia's website for more information. Special thanks Huge thanks to RevComm for supporting me throughout the event, to my colleagues whom I went with, to the more than fifty members of the APAC organizing committee, and, of course, to all the new people I met. Each of them made the conference for me. You can follow me at twitter ( @juanjo12x ). See you next year! References PyCon APAC 2023 official website : https://2023-apac.pycon.jp/timetable Check the official PyCon JP’s YouTube channel for all the conference talks : https://www.youtube.com/@PyConJP/featured

RevCommの中島です。 2023年10月26日（木）から29日（日）に開催された PyCon APAC 2023 に参加しました。 弊社からは陶山 嶺、小門 照太、松土 慎太郎（兼 コアスタッフ）の3名が登壇しました。 今回はConferenceの振り返りとして登壇者らのコメントとトークの感想をお送りします。 登壇振り返り Pythonはどのようにデータベースと繋がるのか 概要: Webアプリケーション開発で何気なく使っているO/Rマッパーやデータベースアダプタのライブラリはとても便利です。 数々のライブラリが、我々がプログラムとネットワークはどのように繋がっているのかを考える必要なくデータベースと繋がることを助けてくれています。 このトークでは、ソケット通信でつながる方法を深掘りしていく他、複数のライブラリでの実現方法、PEP249で決められているルール、非同期処理をどのように実現しているか、最新のO/Rマッパーやデータベースアダプタのライブラリ事情などを紹介していきます。 登壇者: Shintaro Matsudo（ shintaromatsudo ） 発表資料: Pythonはどのようにデータベースと繋がるのか www.youtube.com 登壇者の感想 Shintaro Matsudo 日々Webアプリケーションを開発している中で疑問に思っていることからテーマを決めました。資料を作る中で多くのことを学ぶことができました。 聞いてくれた方々もなにかを得てくれていたら嬉しいです。 また、今年はPyCon APACだったので日本以外からの参加者とも多く交流することができました。 来年のPyCon APACにも発表を英語でできるようになってプロポーザルを提出しようと思っています。今年出会えた方々とまた来年会えることを楽しみにしています。 Pythonで一歩踏み出すバイナリの世界 概要:コンピュータの世界はゼロとイチで成り立っています。 この文章もPythonのロゴ画像もみなさんが書いているプログラムもすべてゼロとイチで表現されています。 ということはみなさん知っているでしょう。 しかし、そのことを意識したことがなかったり、「バイナリ」や「バイト列」という言葉に苦手意識を感じる方も多いのではないでしょうか。 本セッションでは、Pythonの対話モードやprint()、structモジュールなどを使ってバイナリの世界を覗いてみます。 バイナリに慣れるとより深くコンピュータを知ることができ、目の前の世界が一気に広がります。 本セッションを通じて、その最初の一歩を踏み出しましょう。 登壇者: Rei Suyama ( rhoboro ) 発表資料: Pythonで一歩踏み出すバイナリの世界 www.youtube.com 登壇者の感想 Rei Suyama 今年はPyCon APAC 2023レビュアーの評価観点を参考に、初心者だった頃の自分を振り返りながら発表テーマを決め、プロポーザルを提出しました。 発表資料や内容に関しても、最初の一歩ということでセッションを聴講してくれる方々を置いていってしまわないよう丁寧な説明を心がけ構成を練りました。 その甲斐もあってかXのポストや懇親会で感想を聞いた印象では、想像以上に参加者の方々に楽しんでもらえていて嬉しかったです。 時間の関係で非表示にしてスキップしたスライドも多くありましたので、ぜひ発表資料を見ていただければと思います。 あなたのアプリケーションを本番システムで動かすために 概要: Webアプリケーションの開発と運用において必要な知識は多岐に渡ります。 フレームワークの使い方を覚えることはもちろん重要ですが、開発したアプリケーションは本番システムにリリースして実際に稼働することになります。 そして、リリースしたシステムは継続的に運用していく必要があります。 このセッションでは、本番システムでの運用を見据えたアプリケーション開発に必要な知識や勘所を紹介します。 登壇者: Shota Kokado（ skokado ） 発表資料: あなたのアプリケーションを本番システムで動かすために www.youtube.com 登壇者の感想 Shota Kokado 普段からWebサービスの開発、運用する中で「一つのことだけやっていれば良い」ということは無く、様々な知識やバックグランドが武器になることを実感しています。 今回のトークがエンジニア入門者の方々にとって役に立てば光栄です。 当日の質疑応答に対する補足を個人の参加レポートに記載していますので、そちらもぜひご覧ください。 PyCon APAC 2023に参加＆登壇してきました @skokado | Qiita 登壇者の感想は以上です！ 他にも、中島が視聴して興味深かった登壇をいくつか紹介させていただければと思います。 Dev Containers時代のPython開発環境のあり方 登壇者: Yoshiki Shibukawa https://2023-apac.pycon.jp/timetable?id=M8QP3X 一般的に言語やパッケージのバージョンが異なるプロジェクトを開発していると環境分離が大切になります。 pipenv、poetry、hatchなど、これまでPythonのパッケージ管理ツールは標準であるvenvでの仮想化をベースにして開発されてきましたが、それらのツール群や選択肢が却ってPythonの環境構築の難易度を上げています。 登壇者のShibukawaさんは「環境構築の手間が楽」「必要以上に柔軟性を与えるのをよしとしない」「深く考えない状態でも難しくなく使える」という観点から、VSCode上のDev Containersに注目し、その場で環境構築を実践しながら紹介されていました。 普段 Docker で開発環境を用意することが多い私ですが、Shibukawaさんの実践を見ながら手元のPCでもDev Containersを試してみますと、すぐに環境が起動し動かすことができたので、今後カスタマイズなどを学んで活用していこうと思いました。 ModuleNotFoundErrorの傾向と対策: 仕組みから学ぶImport https://2023-apac.pycon.jp/timetable?id=9TKP3P 登壇者: Toshifumi Tsutsumi Pythonを使っていると誰でも経験したことのあるModuleNotFoundErrorについて、基本的な要素から噛み砕きながら深掘りしていて、非常に分かりやすい発表内容でした。 本登壇を聴講した方はModuleNotFoundErrorが何も怖くない状態になったことと思います。 PythonのImportの役割と仕組みを分解し、以下の技術などについて段階的に解説されてます。 ModulesSpec PathFinder sys.path 何気なくImportを記述するとエラーが解決するので、意識したことのない言語仕様、特にImport周りを理解することができ、よりPythonに詳しくなれました。 まとめ このようなイベントに参加するのは初めてだったため不安な部分もありましたが、会場やイベントは終始ウェルカムな雰囲気で参加者同士の交流も盛んでした。 そんな雰囲気に後押しされ、私も積極的にポスターセッションやスポンサーのブースをたくさん回り、たくさんの方に話を聞かせていただき、たっぷりと楽しむことができました。 公式グッズのTシャツとバッグとタオル また、非常の多くの方が集った本イベントはスタッフやスポンサー様に支えられて開催されています。 イベントを支えてくださった登壇者、スタッフの皆さん、スポンサー様や関係者の方々、本当にありがとうございました！ 来年は登壇者として参加できれば良いな、と強く感じました。 左から小門、松土、中島、陶山、大谷、ホセ 最後に RevCommは電話営業や顧客応対を可視化する音声解析AI搭載型のクラウドIP電話「MiiTel（ミーテル）」を開発しています。 プロダクトの開発においてWebアプリケーション、機械学習/深層学習などの領域でPythonが広く使用されています。 「コミュニケーションを再発明し人が人を想う社会を創る」というミッションを達成するべく、一緒にプロダクトを開発して頂けるエンジニアを募集しています！ hrmos.co

Photo by Luke Chesser on Unsplash Introduction (This article is a translation of the Japanese article titled "MiiTel AccountのSLO: 測定と継続的な最適化の方法") I'm Kei Usami from RevComm. We develop and provide an AI-powered phone system "MiiTel" and an AI-powered online meeting analysis tool "MiiTel Meetings." I work in the MiiTel authentication platform (MiiTel Account) team, serving as a Project Manager and Software Engineer. Previous Articles: Cognito user pool で OpenID Connect を利用した外部 ID Provider によるサインインを実現する - RevComm Tech Blog Webアプリケーションの国際化対応をバックエンドからフロントエンドに移行した話 - RevComm Tech Blog In this article, I'd like to introduce the measures we are taking to ensure the stable operation of the MiiTel Account service, while also discussing its relationship with SLO (Service Level Objectives). SLO - What is it? In a nutshell, SLO can be described as "objectives on service reliability." Generally, companies providing web services or systems strive to minimize disruptions in order to offer users a better experience. However, since systems are not infallible, occasional outages or system issues are inevitable. This is where SLO comes into play. SLO represents the quality objectives set by service providers (such as companies offering web services like MiiTel). It is based on the quality levels users can expect when using the service. Actual SLOs are expressed as specific numerical values. For example, “guaranteeing 99.9% uptime” or “maintaining a response time of 2 seconds or less for 99.9% of all requests”. These metrics serve as indicators to assess how comfortably customers can use the service. Related terms - SLI and SLA SLI (Service Level Indicator) and SLA (Service Level Agreement) are closely related to SLO, and are also important concepts. SLI (Service Level Indicator) : SLI is a specific and quantitative metric used to measure the performance and quality of a service. It includes metrics such as average response time and error rates. SLA (Service Level Agreement) : SLA is a contract or agreement between the service provider and the customer. It typically specifies what quality metrics the service provider should meet and includes compensation arrangements in case the goals are not achieved. SLO (Service Level Objective) : SLO is a quality target set based on SLIs. It defines the performance and quality of a service in specific numerical terms. While often used as an internal target, some services publicly disclose their SLOs. In summary, SLI quantifies the state of a service, SLA defines the agreement between the service provider and the customer, and SLO sets the quality goals the service should achieve. These metrics are key to enhancing the reliability between service providers and customers. The difference between SLO and SLI is clearly illustrated on the Google Cloud website as follows: SLO and SLI - Google Cloud Now, let's explore how MiiTel Account sets SLOs and what specific measures are being taken to achieve them. Role of MiiTel Account First, let me explain the role of MiiTel Account within MiiTel. MiiTelの技術スタックとアーキテクチャ変遷を紹介します（2023年5月版） - RevComm Tech Blog MiiTel architecture MiiTel Account corresponds to what was introduced as the "Authentication Infrastructure Application" in this article. MiiTel Account handles the authentication functions for the entire MiiTel platform. If an issue were to occur with MiiTel Account, it would result in the inability to access any of the services that make up MiiTel. Since MiiTel is used for calls and inbound interactions, even a few seconds of service downtime can have a significant impact on users. Therefore, it is a service that must operate robustly and stably above all else. However, on the other hand, there is a dilemma between maintaining service stability and swiftly adding authentication-related features to meet business needs. SLO provides a framework to effectively manage this. By setting higher SLOs than regular services, you can ensure stability while allowing for some aggressive feature development as long as the SLOs are met. By formalizing goals through SLO and visualizing the current state of service performance and quality, you can somewhat alleviate the tension between stable operation and feature additions. SLO in MiiTel Account So, what SLOs are set for MiiTel Account in practice? MiiTel utilizes Datadog as a monitoring tool and currently has the following target values set: The percentage of 5XX errors in the total request count should be within 0.2%. The average response time should be under 3 seconds. *Both of the above criteria should be met for 99.9% or more within the last 90 days. These are quite strict numbers. However, as of October 2023, the error percentage exceeds 99.999%, and the response time is 100%, surpassing the targets. With a considerable error budget, there is room for proactive feature development while maintaining the stability of the system. SLO API errors - past 90 days SLO slow response - past 90 days Datadog is a valuable tool, particularly when combined with APM (Application Performance Monitoring) , as it makes setting and monitoring SLOs straightforward. It automatically calculates monitoring metrics and allows you to configure alerts according to your preferences, making it highly convenient. Efforts Toward Achieving SLOs To maintain SLOs, various initiatives and operational strategies are necessary. Here, I'll introduce some of the efforts within MiiTel Account. Setting Various Metrics and Monitoring Alerts One of the most effective and easy-to-implement measures is setting up metrics and monitoring alerts. While various tools can accomplish this, as mentioned earlier, RevComm utilizes Datadog as its monitoring tool. You can set thresholds to trigger alerts in cases where there are anomalies in request counts or when infrastructure metrics, such as those from AWS, are more critical than usual. These alerts can be configured to notify you via platforms like Slack. docs.datadoghq.com Datadog memory usage alert Datadog request count alert Moreover, Datadog allows for creating simple scenarios to run end-to-end tests periodically, which can be used for health checks to ensure the login functionality is working correctly. When setting up alerts, it's advisable to differentiate notification channels between production and non-production environments. This way, you can easily discern whether immediate attention is required, preventing development environment alerts from getting lost in the mix. Regular Metric Checks in Meetings The MiiTel Account team conducts bi-weekly meetings where they discuss task progress, share insights, and address concerns. To foster constant awareness of SLOs and various metrics, the team begins each meeting by checking the SLO dashboard in Datadog. SLO dashboard - Datadog With Datadog APM set up, you can access dashboards that display time-series data for metrics like request counts, error rates, and latency. This is highly effective in understanding the current state of the service. In some cases, analyzing the trends of request counts and response times for each API endpoint and using this data to consider effective measures for improvement may be necessary. Sometimes, abnormalities are detected during these regular meetings. Anomaly requests An example of this was noticed by Shota Kokado (@skokado, previous article: Amazon Inspectorによるプラットフォーム診断とコンテナイメージ改善の取り組み - RevComm Tech Blog ), who has appeared in this blog on several occasions. At that time, request count alerts as mentioned earlier had not been set up. However, during a routine dashboard check in a meeting, an abnormal tenfold increase in requests was observed. Due to web server auto-scaling and other measures, there was no significant impact on the service, and the issue was resolved through the use of security features like WAF. If it hadn't been discovered promptly, there could have been potential service disruption due to resource constraints in the infrastructure. Automation of Integration Tests and E2E Tests After Release While enhancing monitoring and alerting is essential, most incidents tend to occur shortly after a release. There might also be bugs that are only noticeable when working with the actual environment and database, as unit tests can't detect them. To mitigate these risks, MiiTel Account has automated API integration tests and E2E tests to run after a release. These tests are configured for each environment (we have three major environments), allowing them to check for any unexpected bugs before a production release. Integration Tests: Comprehensive testing of nearly all API endpoints for normal operation. E2E Tests: UI tests for critical functionality using Autify. Upon completion of these tests, notifications are sent to Slack as follows: E2E testing result The automation framework for tasks like these has been developed by Raman Yachi (@r-ym). He has recently summarized the details in a blog post, which you can refer to for more in-depth information. E2E Testing system for MiiTel Account - RevComm Tech Blog (English) MiiTel AccountチームのE2Eテスト自動化 - RevComm Tech Blog (日本語) Thanks to this system, which significantly reduces the need for manual testing, releases can now be carried out with greater safety and reduced psychological burden. These tests have significantly enhanced the service's security, allowing the team to transition from weekly night releases to releasing during the day whenever necessary. Deployment frequency is an important metric, especially emphasized in the Four Key Metrics of DevOps Research and Assessment (DORA), so this initiative holds significance not only in terms of SLOs but also in improving development productivity. Looking Ahead Thanks to these measures, we've been fortunate to achieve SLOs and maintain a higher level of metrics. While operating a web system, it's inevitable that there will be occasional disruptions and temporary drops in service performance. However, with the strategies mentioned earlier, you can control this risk and maintain high productivity while continuing to develop new features. Looking ahead, the goal is to not only maintain SLOs but also enrich the metrics for more detailed service health checks and enhance development productivity. www.revcomm.co.jp

Photo by Luke Chesser on Unsplash はじめに RevCommの宇佐美です。 RevCommでは、音声解析AI電話「MiiTel（ミーテル）」やAI搭載オンライン会議解析ツール「MiiTel Meetings」を開発・提供しています。 私はMiiTelの認証基盤 (MiiTel Account) 開発チームで、Project Manager兼Sortware Engineerとして活動しています。 過去記事: Cognito user pool で OpenID Connect を利用した外部 ID Provider によるサインインを実現する - RevComm Tech Blog Webアプリケーションの国際化対応をバックエンドからフロントエンドに移行した話 - RevComm Tech Blog 今回は、MiiTel Accountというサービスを安定的に運営するためにどのような取り組みをしているのか、SLO (Service Level Objective) と絡めて紹介したいと思います。 SLOとは何か SLOは直訳すると"サービス信頼性目標"です。 一般的に、Webサービスやシステムを提供している会社は、ユーザーによりよい体験を提供するため障害を最小限に抑えるよう努力しています。 ただシステムである以上、サービスは常に100%の信頼性を持って稼働できるというわけではなく、どうしても時々障害やシステム不具合が発生します。そこで登場するのがSLOです。 SLOは、サービス提供者（例えばMiiTelのようなWebサービスを提供する会社）が設定するサービスの品質目標です。これは、ユーザーがサービスを利用する際に期待する品質レベルをもとに表現されます。 実際のSLOは、正確な数字で表現されます。例えば、99.9%の正常稼働時間を保証するとか、全リクエストのうちの99.9%のレスポンスタイムを2秒以内に維持する、のような形です。これらは顧客がサービスをどれだけ快適に利用できるかを評価するための指標です。 関連用語 - SLIとSLA SLOに関連して、SLI (Service Level Indicator) とSLA (Service Level Agreement) もよく似ていますが重要な概念です。 SLI (Service Level Indicator) : サービスの性能や品質を測定する具体的かつ定量的な指標です。例えば、平均応答時間やエラー率などが含まれます。 SLA (Service Level Agreement) : サービス提供者と顧客との間で合意される契約ないし取り決めです。通常、サービスの提供者が顧客に対してどの品質指標をどのくらい満たすべきかが明記され、目標が満たされなかった場合の補償を含みます。 SLO (Service Level Objective) : SLOはSLIに基づいて設定される品質目標であり、サービスの性能や品質を具体的な目標数値で設定します。内部的な目標として使われることが多いですが、サービスによっては公表されています。 まとめると、SLIはサービスの定量的な状態を示し、SLAはサービス提供者と顧客の合意事項を定義し、SLOはサービスが達成すべき品質目標を設定する役割を果たします。これらの指標が、サービス提供者と顧客の信頼性を高める鍵となっています。 Google CloudのWebサイトでは、下記のようにSLOとSLIの差がわかりやすく図で示されています。 SLO と SLI の関係を示すグラフ - Google Cloud SLO を定義する  |  アーキテクチャ フレームワーク  |  Google Cloud ここからはMiiTel AccountがどのようにSLOを設定していて、その達成に向けて具体的にどんな取り組みをしているかをご紹介します。 MiiTel Accountの位置づけ まず、MiiTelにおけるMiiTel Accountの位置づけについて説明します。 MiiTelの技術スタックとアーキテクチャ変遷を紹介します（2023年5月版） - RevComm Tech Blog MiiTel architecture MiiTel Accountは、こちらの記事で紹介があった「認証基盤アプリケーション」というものにあたります。 MiiTel AccountはMiiTel全体の認証機能を担っているため、もし障害が発生するとMiiTelを構成するどのサービスにもアクセスできません。MiiTelは通話や受電に使われるため、数秒のサービス停止であってもユーザーに大きな影響を及ぼしてしまいます。 そのため、何よりも堅牢かつ安定的に稼働することが求められるサービスだといえます。ただ一方で、認証関連の機能追加もビジネス的なニーズによって迅速に行なっていく必要があり、ここでサービスの安定稼働とのジレンマが生じます。 これをうまくコントロールするために使える枠組みがSLOです。 通常のサービスよりも高いSLOを設定することで安定稼働を担保しつつ、SLOが達成できていて余裕があるうちは、ある程度攻めの機能追加開発も可能になります。 SLOという形で目標を明確化するとともに、サービスの性能や品質についての現状を可視化しながら運用することによって、安定稼働と機能追加の緊張関係をある程度緩和することができます。 MiiTel AccountにおけるSLO ではMiiTel Accountでは、実際にどのようなSLOを設定しているのでしょうか。 MiiTelではモニタリングツールとしてDatadogを活用しており、ここで今は以下のような目標値を設定しています。 総リクエスト数における5XXエラーの割合が0.2%以内 レスポンスタイムの平均値が3秒以内 *いずれも直近90日以内の99.9％以上で上記を満たすこと かなりシビアな数字ではありますが、2023年10月現在の実績値としてはエラーの割合のほうが99.999％、レスポンスタイムの方は100％と目標を達成しています。エラーバジェットにもかなりゆとりがあるため、ある程度積極的な機能開発ができる状態を保てています。 SLO API errors - past 90 days SLO slow response - past 90 days Datadogは、 APM (Application Performance Monitoring) を入れておけばSLOの設定も容易で、こういったモニタリング数値なども自動で計算してくれて、アラートの設定も思いのままなので非常に便利です。 SLO 達成に向けた取り組み SLOを保つためには、様々な取り組みや運用上の工夫が必要です。ここからは、MiiTel Accountでの取り組みの一部を紹介します。 各種メトリクス・モニタリングアラートの設定 まず簡単にできてかつ効果が高いものとして、メトリクスやモニタリングアラートの設定があります。これは色々なツールで実現できますが、上記のとおりRevCommではDatadogを監視ツールとして使っています。 リクエスト数に異常値があった場合や、AWSなどのインフラのメトリクスが通常より逼迫している場合などに、閾値を設定してSlackなどにアラートを送るように設定することができます。 docs.datadoghq.com Datadog memory usage alert Datadog request count alert またDatadogでは、簡易的なシナリオを作ってE2Eテストを定期実行することができるため、これを活用してログイン機能が正常に動いているかどうかをヘルスチェック的に運用しています。 アラートを設定する場合は、本番環境とそれ以外の環境の通知チャンネルを分けておくと、至急対応が必要なものかどうかわかりやすく、開発環境のアラートで埋もれてしまうことも避けられるのでおすすめです。 定例ミーティングでのメトリクスチェック MiiTel Accountチームでは週に2回の定例ミーティングを行っており、タスクの進捗状況や相談・共有事項などについて会話します。 普段からSLOや各種メトリクスについて意識するため、ミーティングの冒頭で毎回DatadogのSLOダッシュボードをチェックしています。 SLO dashboard - Datadog Datadog APMを設定しているとダッシュボードが確認でき、リクエスト数やエラーレート、レイテンシーなどの値が時系列で一覧できるため、サービスの現状を把握するために非常に有効です。 場合によってはAPIエンドポイントごとのリクエスト数の推移や、レスポンスタイムなどを分析して、改善が必要な場合にこのデータを元に効果的な施策を検討することもあります。また、ときにはこの定例ミーティングでのチェックから異常が見つかることもあります。 Anomaly requests これは、過去に何度かこのブログでも登場している Shota Kokado (@skokado) (過去記事: Amazon Inspectorによるプラットフォーム診断とコンテナイメージ改善の取り組み - RevComm Tech Blog ) が気づいてくれた事例です。 このときはまだ前述のリクエスト数アラートを設定していなかったのですが、定例ミーティングでのダッシュボードチェックで通常時の10倍ほどの異常なリクエスト増が確認されました。 Webサーバーのオートスケーリングなどのおかげでサービスへの顕著な影響はなく、結果的にはWAFなどのブロックによって対応できました。もしすぐに発見されていなければ、どこかでインフラのリソースが逼迫してサービスに影響が出ていた可能性があります。 リリース後のインテグレーションテストと E2E テストの自動化 監視やモニタリングを充実させることも重要ですが、一方で障害の多くはリリース直後に起きることが多いです。また、実環境やデータベースを使わないとユニットテストでは気づけないようなバグなどが混じっていることもあります。 MiiTel Accountではこういったリスクを低減するため、リリース後のAPIインテグレーションテストとE2Eテストを自動実行するようにしています。これは各環境 (大きく分けて3つの環境があります) ごとに設定しており、本番リリース前に予期しないバグなどが起きていないかどうか確認することができます。 インテグレーションテスト: ほぼ全APIエンドポイントへの正常系テスト E2Eテスト: Autifyを使ったクリティカルな機能のUIテスト テストが完了すると、それぞれ以下のようにSlackに通知が来ます。 E2E testing result このあたりの自動実行の仕組みは Raman Yachi (@r-ym) が構築したもので、最近ブログにまとめてくれているので、詳細はこちらをご覧ください。 E2E Testing system for MiiTel Account - RevComm Tech Blog (English) MiiTel AccountチームのE2Eテスト自動化 - RevComm Tech Blog (日本語) この仕組みによって手作業で動作確認する手間がかなり省けたため、より安全かつ心理的な負担も少ない中でリリースが行えるようになりました。 これらのテストで安全性がかなり担保されるようになったため、元々週次夜間に行っていたリリース作業を現在は日中随時に行うよう切り替えています。 デプロイ頻度はDevOps Research and Assessment (DORA) のFour keys metricsでも特に重要視されている指標なので、SLOだけではなく開発生産性という意味でも大きな意味がある施策だったと考えています。 今後に向けて 以上のような施策によって、幸運にも今のところはSLOを達成したうえでさらに高い水準の指標をキープできています。 Webシステムを運営していく以上は障害やサービスのパフォーマンスが一時的に落ちることは避けられない面もありますが、これまで述べてきたような施策によってこのリスクをコントロールしつつ、高い生産性を保って新機能開発を続けていくこともできるはずです。 今後はSLOを保ったまま、さらに指標を充実させてより詳細なサービスのヘルスチェックができるようになったり、開発生産性を向上させていくことを目指しています。 RevCommでは機能開発だけではなく、こういった運用面の知見を深めたり新しい取り組みを行う機会が豊富にあります。興味がある方は、下記から採用情報をチェックしてみてください。 www.revcomm.co.jp

RevComm Research Dept. Development Groupの高橋典生です。先日開催された、NIKKEI Tech Talkの 【日経×コドモン×RevComm】サービスの安定性、信頼性を高めるDevOps/SREの取り組み に登壇しましたので、紹介させていただきます。 NIKKEI Tech Talkとは NIKKEI Tech Talkとは、日本経済新聞社 CDIO室が開催する技術勉強会です。毎回テーマを変えて様々なトピックで開催されています。私が登壇したのは以下の回でした。 nikkei.connpass.com これ以後も、 nikkei.connpass.com nikkei.connpass.com と興味深いラインナップで続いてますので、興味があればぜひご参加ください。 発表内容の概要 Feature Flagを私のチームで導入した経験を踏まえて、どのように検討、導入、運用したかという点についての説明が発表の大まかな内容です。 私の所属するRevComm Research Dept. Development Groupというチームは、研究開発の部門の中にあります。 「機械学習の研究成果を製品に組み込み、ユーザーに価値を届ける」 というのがチームのミッションの一つになっています。RevCommは音声解析分野の機械学習の研究を社内で続けており 1 、そういった研究成果を MiiTelの製品群に組み込み、ユーザーに新たな価値を提供し続けられるように努めています。したがって、私のチームが開発するサービスの多くは機械学習を使ったサービスになります。 こういった背景の中、機械学習サービス固有の機能・非機能面の不確実性への対応をとりつつ、他のチームの開発に依存せず開発が継続できるようにするためにFeature Flag を導入しました。このあたりのモチベーションは、 こちらのスライド 付近にまとめています。また、そもそもFeature Flagと言ってもその役割や性質に応じて質的に異なるものと認識した方が良いということを検討フェーズで学びました。この点は 「Feature Flagって4種類あんねん」 というキーワードとともにMartin Fowlerの引用を元に こちらのスライド 以降にまとめています。最後のハイライトは導入後の運用面です。Feature Flag導入後、使わなくなったFeature Flagを消すための工夫に関して こちらのスライド にまとめました。 スライドの最後にも書きましたが、今後はA/Bテストや全社的な切り替えをPdMが行えるような仕組みに発展させていく可能性があるので、ここで検討した内容を踏まえ、よりユーザーに価値を安定的に届けていける形を目指そうと思います。 登壇資料はこちらにアップロードされていますので、ご興味のある方はご覧ください。 speakerdeck.com チームに仕組みを入れてDevOpsを加速させる RevComm Researchでは、SREというロールはなく 、EM(Engineering Manager) を除くIC(Individual Contributor) 個々人が主体となって、SRE的な視点を持ってDevOpsの改善を図っています。 最近では、Platform Engineeringというキーワードもよく目にするようになりました。もちろん、大規模な組織の場合Platform Engineer(or SRE) 専任、のようなパターンはありますが、そのようなパターンであっても(社外の) ユーザーの使うアプリケーションを作っている開発者がSRE的な視点を意識する ことがより良い DevOpsの改善に重要 だと私は考えています。 とはいえ、「ちゃんとDevOpsやっていこう」という精神論だけでは、再現性もないですし、チームとしてうまく行動することができません。そうならないためには、 チームに仕組みを入れる 必要があります。私のチームでは、 「小さな改善活動」 というルールがあり、それがDevOpsを推進する仕組みの一例になっています。チームとしてのコミットメントは最優先なものの、チームの合意が必要になるような大きな変更でなければ、自由にこういった運用の改善、バグの修正、CI/CDの改善などを行うことができます。Feature Flagの対応もこの「小さな改善活動」の中から生まれたものでした。 登壇のメリット RevCommではDevRelを支えてくださっている方もいらっしゃいますし、個人的にもこういった登壇の機会はメリットが大きいのでどんどん挑戦しようと考えています。 こういった場での発表を行うことで、知っていることを共有して、知らないことを共有してもらうことができます。ソフトウェアの進化の歴史がまさしくそうであったように、これはソフトウェアエンジニア全体の利益になると思います。 あまり意識されない登壇者のみのメリットもあります。発表内容に詳しくなるのはもちろんですが、私はここで、別の点も強調したいと思います。まずは、社内に閉じた専門知識を世の中における一般的な水準で位置付ける良い機会になります。これによって、視野が広くなり、社内の問題解決にも新たな視点で対応できる可能性が増えます。また、発表することで、良い点・悪い点を指摘してもらうことができます。これにより自分一人では思いつかなかった観点での考えを知ることができ、より深く技術を見つめることができます。 こういった場は大好きなので、今後も発表したり参加者として楽しんだりできればうれしいなと思っています。 以下は発表後の最後の締めの様子です(みんな楽しそう) 発表後の Zoom の様子 最後に 最後にNIKKEI Tech Talkの参加者のみなさま、運営者・登壇者のみなさま、社内でDevRel対応をしてくださった方、レビューしてくださった方に感謝の意を示して締めさせていただきます。 我々は “コミュニケーションを再発明し、人が人を想う社会を創る” というミッションを掲げて日々励んでいます。そのためにはたくさんの優秀な仲間が必要です。今回のこういった活動を見て、RevCommに興味を持ってくださった方は 採用ページ もぜひご確認いただけると幸いです。 「Forbes AI 50 2023」に選出 アジアで唯一、最も有望なAI活用企業として表彰されました ( https://prtimes.jp/main/html/rd/p/000000158.000037840.html ) ↩

2023年10月27日(金)〜28日(土)に開催される PyCon APAC 2023 に RevComm のエンジニアの陶山 嶺と小門 照太と松土 慎太郎が登壇します。 イベント概要 https://2023-apac.pycon.jp/ 公式サイトより引用 https://2023-apac.pycon.jp/ PyCon APACは、プログラミング言語「Python」を中心としたボランティアによる非営利の年次カンファレンスです。このカンファレンスの目的は、Pythonプログラミング言語とその周辺技術を探求し、議論・実践できる場を提供することです。運営チームは、アジア太平洋地域における国または地域が主体となり、現在では、シンガポール、マレーシア、インドネシア、フィリピン、タイ、韓国、香港、ベトナム、日本、台湾、インド、バングラデシュが毎年交代して開催され、2023年は日本のメンバーが主体となり運営します。そして、日本での開催は2013年以来の10年ぶりとなります。 日程: 2023年10月27日(金)～28日(土) 会場 TOC有明コンベンションホール 参加申し込みはこちら 主催: 一般社団法人 PyCon JP Association 登壇情報 Pythonはどのようにデータベースと繋がるのか Webアプリケーション開発で何気なく使っているO/Rマッパーやデータベースアダプタのライブラリはとても便利です。 数々のライブラリが、我々がプログラムとネットワークはどのように繋がっているのかを考える必要なくデータベースと繋がることを助けてくれています。 このトークでは、ソケット通信でつながる方法を深掘りしていく他、複数のライブラリでの実現方法、PEP249で決められているルール、非同期処理をどのように実現しているか、最新のO/Rマッパーやデータベースアダプタのライブラリ事情などを紹介していきます。 日時: 2023年10月27日(金) 13:40～13:55 登壇者: Shintaro Matsudo リンク: https://2023-apac.pycon.jp/timetable?id=8XZDC7 Pythonで一歩踏み出すバイナリの世界 コンピュータの世界はゼロとイチで成り立っています。 この文章もPythonのロゴ画像もみなさんが書いているプログラムもすべてゼロとイチで表現されています。 ということはみなさん知っているでしょう。 しかし、そのことを意識したことがなかったり、「バイナリ」や「バイト列」という言葉に苦手意識を感じる方も多いのではないでしょうか。 本セッションでは、Pythonの対話モードやprint()、structモジュールなどを使ってバイナリの世界を覗いてみます。 バイナリに慣れるとより深くコンピュータを知ることができ、目の前の世界が一気に広がります。 本セッションを通じて、その最初の一歩を踏み出しましょう。 日時: 2022年10月28日(土) 11:30～12:00 登壇者: Rei Suyama リンク: https://2023-apac.pycon.jp/timetable?id=QEHREX あなたのアプリケーションを本番システムで動かすために Webアプリケーションの開発と運用において必要な知識は多岐に渡ります。 フレームワークの使い方を覚えることはもちろん重要ですが、開発したアプリケーションは本番システムにリリースして実際に稼働することになります。 そして、リリースしたシステムは継続的に運用していく必要があります。 このセッションでは、本番システムでの運用を見据えたアプリケーション開発に必要な知識や勘所を紹介します。 日時: 2022年10月28日(土) 14:10～14:40 登壇者: Shota Kokado リンク: https://2023-apac.pycon.jp/timetable?id=FHTQDR 最後に RevComm は電話営業や顧客応対を可視化する音声解析AI搭載型のクラウドIP電話「MiiTel（ミーテル）」を開発しています。 プロダクトの開発において Web アプリケーション、機械学習/深層学習などの領域で Python が広く使用されています。 「コミュニケーションを再発明し人が人を想う社会を創る」というミッションを達成するべく、一緒にプロダクトを開発して頂けるエンジニアを募集しています！ hrmos.co

Works Applicationsに所属しており、業務委託としてRevCommで働いている勝田です。8月末に開催されたNLP若手の会 (YANS)に参加し、発表を行いました。今回のブログ記事ではその報告をします。 著者 YANSの概要について 名称：NLP若手の会 (YANS) 第18回シンポジウム (2023) 開催日：2023年8月29日(火) - 31日(木) 29日はハッカソンのみ、シンポジウムは30日と31日の2日間で開催 会場：浅草橋ヒューリックホール リンク： https://yans.anlp.jp/entry/yans2023 2020年からオンラインでの開催が続いたため今回は4年ぶりの現地開催であり、対面での交流や議論はオンラインの時とは違った盛り上がりでした。参加者は300人、発表数は140件と去年よりも多く、特に発表数は去年の倍近い件数となっており、チケットの獲得時点から今年は雰囲気が違うと感じました。ChatGPTやLLM関連の発表が多く、サービスに近い業務にNLPを応用するハードルが下がってきたのではと思いました。 発表について タイトル： [S1-P09] オンライン会議の議事録自動作成に向けた前処理手法の検討 概要： ChatGPTや事前学習済みLLMを使うことで高品質な要約文を容易に生成できますが、テキスト長が大きくなれば、推論に時間がかかり計算コストが大きくなります。ここでは、オンライン会議の会話の文字起こしテキストを要約し、議事録を出力するシステムを作ることを目標にコストと精度の観点から前処理+要約のシステムを評価しました。特に会話の文字起こしテキストには、フィラーや定型的なやり取りなど、議事録に不要な表現が多く出現します。そのため、要約の前処理として不要な文を取り除くことで、計算コストを下げることが期待できます。そこで、実際のオンライン会議の会話の文字起こしテキストに、ルールベースや機械学習ベースの前処理を適用し、前処理の有効性について調査を行いました。 ポスター資料： ポスター資料 頂いた質問 オラクルの評価も行って、ある程度の上限値を見ると参考になるのではないか YANSまでに準備は間に合わなかったが、圧縮率に対するROUGEスコアが最大となる組み合わせを抽出した結果を見てみたいとは考えている。 名詞の抽出方法はどうしたか 形態素解析にはspaCy（ ja_core_news_sm ）を使った。 系列ラベリング的な手法は取らないのか システムに導入する上でコストや処理時間を考慮してできるだけシンプルな手法にしたいので文単位での2値分類で解くことにした。 アライメントを取るうえでコンテキストを考慮した方が精度が良いのではないか 上記と同様な理由で今回は試せていない ルールベースの前処理をしたうえで機械学習で解いた方がよいのではないか ルールベースと機械学習の手法を組み合わせることはできるが、機械学習が現状のデータセットに対してどの程度対処できるかを見たかった。 2値分類の精度はどれくらい出ているか 教師ありで学習させた場合は76%程度の精度となった。 まとめ 8月末に開催されたNLP若手の会 (YANS)の参加報告を行いました。私の発表に聴講や議論をしてくださった方に感謝申し上げます。オフラインでの交流ということもあり、ポスターを挟んでの直接の議論は得るものも多かったように感じます。 今後の研究方針としてどう精度を上げるかという問題もありますが、コストを無視することはできずコストパフォーマンスの良い手法を模索する必要があります。 例えば、FrugalGPT[1]では簡単なタスクは小さくコストが安いモデルに解かせ、難しいタスクになるほどコストをかけて大きいモデルに切り替えるといった戦略を取ることで精度を下げずに98%のコスト削減を行っています。 今回はChatGPTを使って要約を行うことを想定しており、そこではChatGPTが一番コストになるためその役割をどれだけ減らせるかという観点で”コスト≒圧縮率”として計算を簡略化しています。しかし、実際は前処理にもコストは発生しますし、それはどの手法を使うかによっても変わってきます。最終的にはシステム全体でのコストを見積りつつ、コストと精度の観点から最適な組み合わせを見つけたいと考えています。 謝辞 本研究にあたり、NTTPCコミュニケーションズが提供するInnovation LabのAI共創パートナープログラムにおいてサーバ環境を無償でご準備いただきました（補足：RevCommはこのプログラムのパートナーとして採択されています）。NTTPCコミュニケーションズに感謝を申し上げます。 引用 [1] Lingjiao Chen, Matei Zaharia, James Zou, “FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance”, paper

RevCommのフロントエンドエンジニア兼イベントモデレーターの小山です！ RevCommは7/5(水)に「世界に認められたAIスタートアップが、Djangoを使って感じる良さとは？ 」というイベントを開催しました。今回はそのイベントで公開したスライドや動画を公開しながら、イベント中に時間の都合で答えられなかった質問にも答えていきます。 今回のイベントは私が企画からモデレーターまで務めさせていただきました。登壇した小門さんと近藤さんは、RevCommの中でも技術についてのプレゼンやディスカッションが得意な2人です。期待以上に良いプレゼンをしてくれて、参加者の方々にも深い質問をいただくことができた会になりました。 フレームワークの使い方はドキュメントでも学ぶことができますが、状況に応じた選定や判断は使い手次第。今回はその点にも触れていますので、ぜひともご閲覧いただけるとありがたいです！ speakerdeck.com speakerdeck.com youtu.be Q and Aへの回答 イベントではたくさんの質問をいただくことができました。時間の関係上、全てに答えることができなかったので、この場で共有をさせていただきます。 — Q: Djangoのバージョンアップ計画とかどうされていますか？ 直近だとDjango4.2でMySQL5.7とPostgreSQL11のサポートが切れるので、そのあたりでどのように適用されたか、またはどのように適用しようとしてるなどあれば教えてください。 A: 社内ではマイクロサービス単位にアプリケーションが分かれていて、プロジェクトとして独立しています。 スケジュールや方式など含めた計画はプロジェクト毎に策定しています。 Django 3.2 LTS は 2024年4月にはメインストリームから外れるため、なるべくそれまでに更新することを社内の共通認識としています。 またDBは PostgreSQL バージョン12以上を使用してるため、その影響はありませんでした。 DBやRedisなど、周辺のサービスもこまめにバージョンアップすることも重要だと思います。 Q: 40個もアプリが分かれてると大変そうですが、どういう基準でアプリを分割してるのでしょうか。 A: 機能の責務や依存関係を考慮します。 例えばユーザー認証の機能とログイン後に利用する機能とでDjangoアプリケーションは分割します。 責務ごとにアプリケーションを分割することで改修範囲を小さくできたり、コードベース全体の見通しを高く保つことができます。 Q: 一部でDjango4.2を利用されているとのことですが、アップデートしてよかったところや、注意が必要だったところはありますか？ A: 前述の通り、Django 3.2 LTS はいずれメインストリームから外れて開発も停止するため、最新の LTS に追従することはほぼ必須と考えて対応しています。 また、細かい機能改善も多数あり便利になっていっています。 アップデート時の注意点として、初めにリリースノートから大きな変更や影響が無いか確認しました。 Django 4.2 release notes 他の質問にもある、MySQL5.7/PostgreSQL 11 のサポート切れについても書かれています。 既に社内でアップデート済みの対応については別のブログ記事でも説明しています。 tech.revcomm.co.jp Q: 2019年の途中からDjangoに切り替えたということですが、移行時にはどのように実施したのでしょうか？全部書き換えるとすると実装もテストすごく大変そうだなと思い気になりました。 A: 当時Djangoへの移行を担当した方にヒアリングしたところ、下記のような返答をいただきました。 Node.jsからDjangoへ切り替えた当時は機能・コードともに少なかったので、テストも実装もあまり時間かからず移行できました。振り返ると、早い段階で移行する判断ができたので良かったと思います。 また、当時は品質よりスピードが求められていたこともあり、ユニットテストはまだなく、手作業によるシステムテストだけ実施し、品質を担保していました。このためテストケースはそのまま流用できたため、移行のネックになることはありませんでした（現在はユニットテスト、システムテスト、QAプロセスまで整備しています）。 Q: Djangoはディレクトリ構成を統一しやすいというお話があったかと思いますが、それはstartappコマンドで作られるDjangoアプリケーションの構成はほぼそのままで使われることが多いから似たような構成になりやすい、という意味でしょうか？ A: 必ずしもそのまま使う必要は無いと思います。 例えば、django-admin startapp コマンドで作成されるファイルに models.py や views.py などがあります。 我々のプロジェクトでは models/xxx.py, views/xxx.py など、ディレクトリ配下にモジュールを分割して配置しています。 ファイルか ( models.py ) ディレクトリか ( models/ ) という違いはありますが、命名と役割をDjangoのプロジェクト雛形に準拠しています。 Q: RevCommの開発もTDDで行われているのでしょうか A: TDDかどうかは個人に任されております。ただ機能追加したい際や既存の処理を変更した際には合わせてユニットテストを書くという共通認識はあります。 Q: フロントがTS、バックエンドがDjangoという構成なら、最近だとDjangoのかわりにFastAPIを使う選択肢もあるかと思いますが、仮に新規で開発することになった際に、どちらを採用したいと思っていますか？ または全く別の選択肢を考えているなら、それについて教えていただけると幸いです。 A: 個人的には TypeScript のライブラリも選択肢に挙げたいところですが、技術者の確保を考えると Python のライブラリになるかと思います。 また、新規サービスの種類にもよりますが FastAPI も選択肢に上がると思います。実際に直近立ち上がったプロジェクトではマイクロサービスとして切り出す API を FastAPI で作ってます。また、3年ほど前に BFF に FastAPI を採用した際には、「asyncio対応、型ヒントへの対応、OpenAPIドキュメントの自動生成、Django ほど多機能ではなくていい」などが決め手になったようです。 Q: 多数のDjangoAppを含むコードベースを運用する上で、DjangoApp同士の依存関係に関して規約や工夫されていることはありますか？ A: 規約は特に入れていないです。 複数の App で明らかに何度も利用するものは common ディレクトリに処理を寄せていたり、App間に依存が発生する場合(全文検索のAppと検索対象のAppなど)はSSOTを心がけて依存が複雑にならないようにしています。 全体的に特定の技術に固執しすぎずに、実現したいことに合わせて柔軟に技術選定を行っているという回答でした。また個人の自由もある程度認めながらも、チーム全体のことを考えるという感じですね。 終わりに RevCommが急成長する中で、開発者は日々課題に向き合っています。その過程で得た知見やそのときの判断は社内だけでなく、きっと社外の誰かの参考にもなるはずです。これからもイベントを開催してより良い会にしていきたいと考えています。ぜひとも楽しみにしてください！

はじめに こんにちは！私はRevCommのCorporate Engineeringグループで主にSalesforce Administrator & Developerとして活動している長谷部です。今回はRevCommが提供するクラウドIP電話サービス「MiiTel」をお客様がご利用を開始するために必要なシステムの内の1つ、「MiiTel Signup」の効率化についてお話したいと思います。 「MiiTel Signup」とは、MiiTelを提供するにあたって必要な法人確認、本人確認システムのことを指します。これは、RevCommが電話転送サービス事業者として遵守すべき犯罪収益移転防止法の要件を満たすために必要なシステムです。 旧システムの課題 今までの「MiiTel Signup」では、業務効率の観点でいくつかの課題がありました。 散らばったシステム : 旧「MiiTel Signup」は顧客情報を管理しているSalesforceとは切り離されたシステムとして構築されていました。これにより、各システム間でデータを連携するために一部手作業での紐づけ業務が発生しており、時間と労力が増大していました。顧客データの一元管理が困難であり、その結果として顧客対応の速度と品質に影響を与えていました。 進捗確認の困難さ : データ連携をする必要があるため、常にリアルタイムで進捗ステータスをアップデートすることができず、法人確認、本人確認の進捗ステータスの確認が煩雑で、作業の効率が低下していました。確認作業は、各システムを切り替えながら行う必要があり、そのたびに時間とエネルギーを消費することとなりました。 上記の課題により、確認作業の工数がそもそも多い上、進捗状況や必要なネクストアクションの特定に手間がかかることで、社内の作業負荷が増幅していました。その結果、重要な業務に集中するための時間が奪われ、全体の作業効率に悪影響を及ぼしていました。 旧システムの概要イメージ 新システムの開発 そこでこれらの課題を解消するために、新しい「MiiTel Signup」システムをSalesforce上に構築しました。 まず始めに、新システムの全体的な構成を理解するために以下のシステム構成図をご覧ください。顧客側入力から確認作業まで全てSalesforce上で完結させるため、以前と比較してシンプルな構成となっています。 新システムの概要イメージ この新システムは、以下のキーポイントを中心に構築されています。 進捗確認の効率化 ：顧客が情報を入力する画面はSalesforceのExperience Cloudにより構築され、入力された情報はSalesforce上の顧客データと紐付けられます。これにより、法人確認、本人確認の進捗ステータスを一元管理することが可能になり、データの連携に必要な時間と労力が大幅に削減されたため、煩雑だった作業が大幅に効率化されました。 eKYCサービスの見直し : 新しい「MiiTel Signup」では、本人確認に必要な身元確認書類をWebカメラを用いて提出できるようになりました。これにより、顧客が情報を入力する一連の流れで身元確認書類を提出できるようになりました。また、身元確認書類の提出時に顔貌の撮影を行うこともできるようになりました。これにより、身元確認書類と顔貌の比較ができるようになり、間違いなく本人が提出していることを担保することができるようになったため、今まで必要だった郵送による個人宅への住所確認の実施も不要になりました。 操作性の向上 ：Salesforceの取引先レコードページ上に、法人確認、本人確認の進捗状況やネクストアクションが確認できる管理画面をLWC(Lightning Web Component)で実装しました。この画面では、顧客の現在の法人・本人確認の進捗ステータスやネクストアクションを確認することができ、確認作業における工数を大幅に削減することに貢献できました。 以下のイメージは、この新しい管理画面の一部抜粋です このようにして、新しい「MiiTel Signup」は、顧客との契約に必要な法人確認、本人確認を効率的に行うためのツールとなりました。次のセクションでは、これらの改修がもたらした具体的な効果について説明します。 改善後の効果 新たな「MiiTel Signup」をSalesforce上に構築したことにより、私達は様々な面で大きな効果を得ることができました。 情報管理の効率化 ：旧システムでは情報が分散していましたが、新システムでは全ての顧客情報と確認ステータスがSalesforce上で一元管理されるようになりました。これにより、全て顧客のデータに紐づいてeKYCのデータが紐づくため、情報の探し出しにかかる時間と手間が大幅に減り、全体の業務効率が向上しました。 レポート機能の活用 ：Salesforce上で情報が一元管理されるようになったことにより、Salesforceのレポート機能を活用することができるようになったため、作業が必要な取引先のみを瞬時に一覧化することができるようになり、必要な作業の優先順位付けやスケジュール管理が容易になりました。また、Salesforceのレポート機能は非常に柔軟かつ簡単に抽出内容や抽出条件を変更したりできるので、Adminチーム側で必要な情報を抽出するためのレポートを必要に応じて柔軟に作ることができるようになりました。 確認作業の効率化 ：取引先レコードページ上に管理画面を構築したことにより、社内での確認工数が大幅に削減されました。この画面では、顧客の法人確認や本人確認の進捗状況をリアルタイムで把握し、必要なネクストアクションを明確にすることができます。これにより、確認作業の精度が向上しただけでなく、無駄な手間を削減し、手作業によるミスを防止することも可能となりました。 これらの改善により、社内の業務効率化が図られ、全体としてMiiTelのサービス提供能力の向上に貢献できました。Adminチームのメンバーからも「以前に比べて使いやすくなり、確認作業の工数も大幅に削減できました」という声をいただきました。 まとめ 本記事では、MiiTelを提供するための法人確認・本人確認プロセスを効率化するためのシステム「MiiTel Signup」の再開発についてお話しました。これは我々が犯罪収益移転防止法を遵守するための重要な取り組みです。 旧システムでは顧客情報の一元管理が難しく、法人確認・本人確認の進捗状況の確認が煩雑な状況にありました。そのため、確実な法令遵守を実施するために多くの工数がかかっておりました。しかし、新システムにより、これらの課題が大幅に解消され、工数削減や法人確認・本人確認のリードタイム短縮など、様々な業務効率化が実現しました。 今後も私達は、更なるサービス改善を目指して、必要な改善を逐次行っていきます。今回の取り組みが、業務効率化やCRMの活用に興味のある方々の一助となれば幸いです。

※この記事はバックエンドエンジニアRaman Yachiによる記事『 E2E Testing system for Miitel Account 』を翻訳したものです。 はじめに こんにちは、バックエンドエンジニアの谷地ラマンです。 RevCommではマイクロサービスアーキテクチャを採用しており、私はその中で認証/認可の機能を提供するAccountチームに所属しています。 ユーザーのログイン認証を処理する重要な部分であり、ここに障害が発生するとユーザーがサービスにログインできなくなる可能性があるため、可能な限り防ぎたいです。 そのための対策としては、第一に全ての機能に対応する単体テストを実装することです。 私のチームではテストフレームワークであるpytestを使用し、Pull Requestにおいて単体テストが実行されるためコミットごとの機能を保証し、あるいはバグを検出することができます。 単体テストに加えて、実際のユーザーシナリオとしての振る舞いを確認するためのシステムテストを実装しています。これは実環境のAPIエンドポイントに対してPostmanによるテスト (E2Eテスト) を実行し、レスポンスを検証しています。 この記事では私たちのE2Eテスト自動化について紹介します。 課題 テストを自動化する前は、各メンバーがローカルマシン上でE2Eテストを手動実行してデプロイ後のサービスが期待通りの動作をすることを確認していました。 しかし、例えばあるメンバーの環境では成功していたものが別のメンバーは失敗したりと、テストの動作を統一できていないことが課題でした。 結果として、テストの信頼性が低くなってしまいました。 また、開発/ステージング/本番など、環境ごとにPostmanの変数を使い分けることも面倒でした。 そこで、リリース後の不具合を検知するためにより良い方法がないかどうか検討しました。 これまでのことから、私たちの要件は次の通りです。 常に最新のアプリケーション（URL構造やインターフェース）をテストできること 非ローカル環境で実行することで、テスト結果をチーム内で共有できること 最小限の設定内容のみを必要とするシンプルな仕組み 解決策 まず最初に、Postmanによるテストの実行をAWS CodeBuildに移行しました。CodeBuildはAWS CodeDeployによるリリースの後に起動されます。 これによりテストは常に最新のアプリケーションを対象とし、かつ個人のローカル環境に依存しないプラットフォームで実行できます。 The e2e testing pipeline 詳しく説明します。 ソースコードの修正を取り込むと、GitHub Actionsを介してCodeDeployによるデプロイプロセスが起動します。CodeDeployの正常終了をトリガーにして、CodeBuildによるE2Eテストが起動します。 CodeBuildの処理の中で、リリース直後のアプリケーションに対してAPIリクエストを実行します。 この中でPostmanのCLIツールであるNewmanを使っています。 https://learning.postman.com/docs/collections/using-newman-cli/command-line-integration-with-newman/ これによって、PostmanのテストケースをCodeBuildで実行することができます。 テストの実行結果はCodeBuildのレポートとしてアップロードされます。 CodeBuildの処理が終了すると、そのレポートを通知するLambda関数を起動します。Lambda関数はレポートをパースしてテストの結果をSlackチャンネルに送信します。 テスト結果の通知例を示します。テストの成功件数と全体件数、そしてタイムスタンプが分かります。 特定のテストケースが失敗した場合は、該当のテストケース名を添えて通知します。 ここまでで説明してきた仕組みに関するAWSのインフラ環境やテストケースのレシピはGitHubリポジトリで管理しています。 AWS環境の構成管理、変更はTerraformで管理しています。 またCodeBuildはソースプロバイダーの指定によってこのリポジトリからテストレシピを取得できるため、常に最新のテストケースでPostmanによるE2Eテストを実行できます。 これにより、ここまでで述べてきた自動テスト全体の仕組みを1つのリポジトリを管理することで完結させています。 これらのパイプラインによってCI/CDとしてバックエンドをテストできます。 テストが必要になるたびに開発者の生産性を低下させることなく、信頼性の高いテストを実行できます。テストの結果をすぐに確認できて、元となった修正も簡単に追跡できます。 まとめ 最後に、これは私にとってTerraformとCI/CDへの初めての挑戦でしたが、このタスクを任されたことは幸いでした。 自分で問題に取り組む裁量が与えられていたし、分からないことはいつでも同僚からアドバイスしてもらえました。 同じように問題解決に主体的に取り組める人なら、RevCommはあなたにとって最適な環境だと思います！ (翻訳・編集: 小門照太 RevComm Technology Dept, Backend Group)

Intro Hello, my name is Raman Yachi. I am an engineer here at RevComm working on the Accounts team. Our product suite at RevComm follows a microservices architecture and I would like to talk about how we automate testing our Account backend, which is a pivotal part of the backend as it deals predominantly with user authentication. Failures here could lead to users being unable to log into our services, which is something we want to avoid as much as possible. Our first line of defense against that is ensuring all our features have corresponding unit-tests. For the backend we use Pytest as our testing framework and each commit merged to a PR triggers the whole battery of tests so that we can guarantee functionality on a commit-by-commit basis and know exactly where breaking changes were introduced. Unit-tests do not convey the whole story so in addition we run system tests to ensure performance in real-world scenarios. This is done by running Postman tests (E2E Test) against our live server’s API endpoints and validating their responses. Issue Prior to having automated the tests our team used to run manual API tests from local machines using Postman to ensure that the newly deployed service was working as intended. The issue with that was the test suites, while version controlled, were not ensured to be uniform. So someone’s test could fail and another’s could succeed and the only way to tell is by lining up the backend and test versions. This made the testing process unreliable as it becomes hard to tell which machine’s result is correct at first glance. Furthermore co-ordinating variables between the production, staging and development environments could become a hassle for people not used to the Postman product. So we sought for an alternative that served as a single source of truth regarding whether the changes shipped broke any endpoint. From these key requirements we know that we need: A testing framework that tests the backend with correct (most recent) API structure (endpoint URL, body format etc.), and executes on non-local infrastructure so that results are available across the team. A simple enough interface that requires minimal configuration on the user end What we did To accomplish this our first step was simply migrating the Postman test runs to a CodeBuild instance, which ensures that the platform is up-to-date and independent to our machines. Once the tests were set up we still needed a method to trigger them, along with a notification system. This was accomplished using the architecture below. To the left of the CodeBuild testing is our Trigger portion of the pipeline and to the right the Notification mechanism. The e2e testing pipeline Every time we release to our environment a respective deployment is triggered in CodeDeploy via Github Actions. At the successful conclusion of this deployment we can assume that the new release is now available and we initiate our integration tests. We do this in the next step by triggering a CodeBuild build. CodeBuild then tests our new backend instance by testing the API of the backend by mimicking user API calls (engaging with the user-facing endpoints). The tool we use for that is Newman, Postman’s CLI counterpart. https://learning.postman.com/docs/collections/using-newman-cli/command-line-integration-with-newman/ This allows us to craft/debug test-cases in Postman and then have our CodeBuild instance run those tests. These test-case results are uploaded to CodeBuild’s report. The conclusion of this CodeBuild run will then trigger a Lambda function that receives the CodeBuild Report. The Lambda will then parse the report and send a message to a dedicated Slack channel that informs everyone of the test’s conclusion and results . An example result from the E2E tests is shown below, where we get the pass/total count, and timestamp: Should tests fail the team is notified by their name being included in the report: With this we have gained the ability to confidently know whether our service is functional after every merge. And with the Slack integrations any failure can be converged upon much quicker. Thus fixes can be issued faster too. The AWS infrastructure, along with the testing recipes are managed by us in a single repository. The test recipes are handled with Postman, while infra changes are affected via Terraform. This repo also serves as the instruction set for our CodeBuild testing instances. What this means is that our Postman test recipes are version controlled in the same repo, to ensure the tests are always up to date whenever a E2E test run is initiated. Thus the whole testing pipeline is managed in a self-contained manner and allows us to hermetically test our backend. Conclusion With the new pipeline we can test our backend in a CI/CD manner which ensures developer productivity does not take a hit every time testing is required and the tests conducted are reliable, the results readily available and also easily traced back to their respective changes. Parting thoughts for this is that I really enjoyed this task as this was my first foray into Terraform and CI/CD and being tasked with the problem despite that was a blessing in disguise. I was given free reign to tackle the problem on my own, and whenever my lack of experience became apparent my colleague’s were able to provide advice and direction – and if you are someone who similarly enjoys working autonomously on interesting problems I believe RevComm would be a great place for you to contribute and grow!

2023年4月28日(金)に、【RevCommのエンジニアの開発組織とは】というオンラインイベントを開催しました。この記事ではイベントの内容に触れながら、時間の関係でイベントで触れることのできなかった情報を紹介します。 イベントは3つのテーマに分けて、プロダクトや働き方、カルチャーを紹介しました。 RevCommという会社と開発しているプロダクトについて 開発組織について 現場のリーダーの考えについて イベントの動画も公開しています。 www.youtube.com 急成長しているスタートアップの1つの開発組織のあり方として参考になると思います。ぜひご覧ください！ RevCommの開発組織の中心にいる4人の登壇者 今回の登壇者は、RevCommの開発組織の中心にいる4人。執行役員/CTOの平村と、執行役員/Senior Engineering Managerの瀬里、Engineering Managerの川添と、Backend Engineerの大谷です。 役職としてはマネジメントやリーダーのポジションですが、全員がコードも書きます。 RevCommではおおよそ8 〜 9割ほどのリーダーやマネージャーが、マネジメントをしながらも開発をしています。 技術を深く理解し、チームワークを駆使し、コミュニケーションの再発明に向けてプロダクトの改善や、新規プロダクトのリリースに向けて日々向き合っている4人です。 それでは、イベントの内容に踏み込んでいきましょう。 RevCommの会社組織と主要プロダクト まずはCTOの平村からRevCommがどういう企業なのか、そしてどんなプロダクトを作っているのかの説明です。会社概要・ミッション・プロダクトの説明やMiiTelのデモをしました。 平村は、高い技術力を持ちながらもビジネスの企画が得意で、両方についてわかりやすく伝えることができるCTO。ミッションである「コミュニケーションを再発明し、人が人を想う社会を創る」と「なぜその中で音声にフォーカスするのか」という話のあたりから熱が入ります。 「(テキストコミュニケーションと比較して)音声のコミュニケーションはまだ全然データ化もされておらず、検索・分析や、AIが人の代わりに何かをするような試みにまだ繋がっていません。これはビジネスチャンスなんじゃないかと。こういったサービスやプロダクトを作ろうと集まったメンバーが作った会社です」 次にRevCommの主力サービスである、MiiTelの紹介です。 「電話営業のブラックボックス化問題という課題を解決したい」という目的と、1つ1つの機能についての説明をしています。 動画内では デモ も行っています。MiiTelを使ったことのない方も多いと思うので、ぜひ動画のデモもご覧ください。 RevCommのエンジニア部門について 次に、執行役員/Senior Engineering Managerの瀬里からRevCommのエンジニア組織についての説明です。 マトリックス組織という体制をとっていること、アジャイル開発を行っていること、使用している言語やツール、社員間でのコミュニケーションも大切にしていることについて話しました。 「弊社のマトリックス組織とは、個人がテクノロジーチーム(フロントエンドやバックエンドといった職能ごとのチーム)に所属し、それぞれのチームから人が集まってプロジェクト(MiiTel Analyticsや新規プロジェクト)を作り上げるという組織体制です。特徴的な制度として、時間さえあれば自身の配属されたチームとは異なる興味の分野のタスクも、担当していいという制度(15%ルール)があります」 例えば、筆者の知っている範囲でも、フロントエンドエンジニアがモバイルアプリ開発のためFlutterを扱ったり、バックエンドのタスクを担当したりということがあります。 また、瀬里は社員同士のコミュニケーションについても語ります。 「フルリモート、フルフレックスだからこそコミュニケーションは活発です。対面でも、年に4回ほどチームのミーティングなどで会う機会があります。普段の業務ではSlackだけで解決しない問題はすぐにビデオ会議をしたりします。また、社員によっては、休みのときに旅行先にいる社員と会って飲み会をしているということもあります」 その他、何か困ったことがあるときに助けを求めるためSlackにhelpmeチャンネルがあるということなどが話題に上がりました。 プロジェクトとエンジニアの紹介 今までは会社全体やエンジニア組織全体についての説明が中心でした。次に各プロジェクトのメンバーをまとめる2名の紹介です。 規模が小さくスピードが求められるプロダクト群を扱うEngineering Manager まずはEngineering Managerの川添から。川添はCorporate Engineeringというチームのリーダーをしていて、主にセールスやカスタマーサクセスなど社内のメンバーが業務で使うシステムを開発しています。 「スピードが求められるので、プレッシャーを感じることはあります。一方で融通も利くので、バランスをとりながら進めています」とのこと。 「社内のメンバーが使うシステムを扱っているからこそ、自分たちの作ったものの上で、ビジネスを動かしていくことができる」という所にやりがいを感じているそうです。 その他、川添は社内の開発者が自分の専門外の技術を学ぶ機会を作っていることにも触れています。 自分のチームだけではなく、社内のエンジニアの技術向上の機会を作っていただけるのが素晴らしいですね！(実は筆者もお世話になっています。) チームの連携をとりながら全体も俯瞰するBackend Engineer 次はBackend Engineerの大谷です。入社して半年ほどですが、多方面で活躍しています。 プロジェクトマネージャーの補佐もしており、担当しているのは、通話の分析結果を表示するMiiTel Analyticsというプロダクト。MiiTel AnalyticsはMiiTelの中心とも言える存在です。 「MiiTel Analyticsは他のチームと連携する必要がある部分も多く、各チームのタスクの調整を行うこともある」そうです。 また、「プロジェクトマネージャーと連携して、Analyticsチームの役割がこのままで良いのかということや、プロジェクト管理のやり方も見直しを図りながら進めています」とのこと。 大谷はMiiTel Analytics以外にも、組織全体のプロジェクト管理のあり方について改善を図るチームにも、自分で手を上げて参加しています。 入社歴に関わらず、意欲のある方が自分の力を発揮できるところはRevCommの良いところです。 おわりに 上記のような内容が座談会では話されました。 この他にも、モデレーターの小畑がよく聞かれる質問への答えも登壇者から引き出しています。また、応募者の方向けにフォロー体制やキャリアパスなどにも触れています。 少しでも興味が湧いたらぜひ 動画 をご視聴ください！ また、RevCommは7月5日（水）の正午にDjangoをテーマにした技術勉強会を開催します。 世界に認められたAIスタートアップが、Djangoを使って感じる良さとは？ オンラインでの開催です。是非ともイベントへのご参加をお願いします！