【エンジニア勉強会レポート】OAuth 2.0/トランザクション分離レベル/OpenAI API
こんにちは！
homieの長澤まさみです。
さて、今回は
・プロダクトチームの勉強会はどんな感じで開催されているのか？
・どんな発表をしているのか？
このような内容を発信していこうと思います。
発表内容やクイズもありますので、是非もの好きの皆様は読んでみて下さいね！
参加メンバー
今回の参加メンバーは以下の通り。
チーム単位の勉強会がはじまった背景
プロダクトチーム全体での勉強会は月1で開催しているのですが、それとは別に「チームの勉強会したい！」と、とあるエンジニアねばおくんの一声でこの度はじまることになりました。
なぜエンジニア全体ではなくチーム単位で開催したいの？とねばおくんに聞いてみました。
日々開発業務で貯めた知見を気軽に共有しあえる場がほしいねん
全体の勉強会では事前準備をしっかりしないといけないイメージが拭えず、もうちょいライトにしたいねん
そして発表に慣れる意味合いも含めチームでやりたいねん
ということで、決まり事は以下のみ。
テーマ：技術関連ならなんでもよし
タイムスケジュール：発表（20分ずつ）あまりで質疑応答
こうして、第一回チーム単位の勉強会がスタート。
それぞれの発表タイム
トランザクション分離レベルについて（発表者：ねばお）
複数トランザクションが同時に行われた場合に、他のトランザクションに影響を与えてしまうとデータの一貫性や永続性などに問題が生じてしまいます。
そのような問題への対応レベルを定義したものが「トランザクション分離レベル」であり、それぞれの分離レベルによってメリット・デメリットが存在します。
今回の発表では、分離レベルの種類、それぞれのメリデメ、結局どれを使うのがベストなのか？等をNotionにまとめて発表してくれました。
（※今回大人の事情により発表内容のキャプチャをギャル顔負けな程加工しております。実際にはNotionにすごくわかりやすくまとめてくれています。）
この発表についてカタキンより質問が。
カタキン＞
「分離レベルがREPEATBLE READのとき、トランザクション開始時に読み取ったレコードを一時的にスナップショットに保存し、トランザクション内ではスナップショットのレコードを参照することで、他のトランザクションによってレコードが書き換えられないことを担保している」とありますが、スナップショットをとることによるパフォーマンスへの影響はありますか？
ねばお＞
一般的にスナップショットをとるときは、取った時点ではデータコピーをしてない（まだ同じメモリを参照してる状態）。変更が実際に反映されたら初めて新しくデータとしてディスクに書き込む（コピーオンライトという）。つまり、変更が反映されればパフォーマンスが落ちる可能性も多少あるが、最初からパフォーマンスが落ちることはない。
のようです。
私は２人が何を言ってるのかまではわかりませんでしたが、2～3ヶ月前に弊社のシステムHOTLEAD上で起こったお困りごとについて、ここを勉強していたねばおくんの知識のおかげでスムーズに解決したことは知っています。
勉強してくれてありがとう。
OAuth2.0について（発表者：カタキン）
まずOAuth 2.0を簡単にいうと
OAuth 2.0 とは、サービスのユーザーが、サービス上にホストされている自分のデータへのアクセスを、自分のクレデンシャルズ (ID & パスワード) を渡すことなく、第三者のアプリケーションに許可するためのフレームワークのこと。
名前だけ聞くと、「OAuth 2.0？おーすにいてんぜろ・・？アキラ100％？」となりますが、私達が普段使っている身近なものですね。
OAuth 2.0に則らない場合は、意図せず自分の個人情報が流出してしまう可能性があるということです。
素晴らしいですね、OAuth。ありがとう、OAuth。
そして認証と認可についても説明してくれました。
認可というのは、内部的に認証を包括している。（認可できる=認証も最低限できている）
正しく認可されている場合（例：正しく権限を与えられている場合）には、ある程度の正しい認証システムが備わっているとも考えられ、認可というのは内部的に認証も包括していると言えるそうです。
言うなれば、「フランス料理人だけども料理人でもある」みたいな感じらしいです。
・・・え？
前述で充分理解していたのに、この例えのおかげで逆にわからなくなりました。^_^
ちなみに弊社のシステムHOTLEAD⇄弊社請求書発行システムへの連携や、
HOTLEAD⇄クライアント様が使用しているCRMへの連携にも利用されており、このOAuthがあるおかげで、安全に連携でき業務の効率化が実現できているわけですね。
趣味はAPI連携というくらいAPI連携大好きマンな私は、とても納得＆馴染みやすい内容でありました。
※フランス料理人の話以外は除く。
OpenAI API（発表者：あっきー）
OpenAI APIを使用して弊社内の「とある業務」を自動化できないか？を調査。
研究した結果、これをする場合1,000万/月程かかるので現実的ではなかったのですが、OpenAI API、夢が広がりますね。
役に⽴つかもしれないtips3選（発表者：いけみん）
お、これは馴染みのやすそうなタイトルだと思ったのもつかの間、ここからエンジニアじゃない方は白目ゾーンへ突入します。
エンジニアのみなさんは考えてみてね♡♡
答えは・・・・
続きまして。
答えは・・・・
Why？
さて、まだまだいきます。
答えは・・・・
Why？
さて、のってきましたか？まだまだです。
答えは・・・
まだいきますよ？
答えは・・・
続きまして、
（ここから私はもう言葉がでないので無言で貼っていきますね）
エンジニアのみなさん、解けましたか？？
バグ調査や、事故りそうになることを防げるようです。みなさま使ってみて下さい。
いけみんの発表に対して、参加者から「低レベルな話だ～」と感想が。
なんと、急に悪口？喧嘩が始まるのでは？と、ゴングを用意しようとしたのですが、これはOSI参照モデルの物理層に近い（低）レイヤーを対象にしたコーディングだという意味合いで日常的に使われるそうで、決して悪口じゃないそうです。ほっ。ゴングを定位置に戻しました。
そしてここでもカタキンがわかりやすく説明してくれようと、
「例えば、フランス料理人が土壌の話から～」と例え話をしようとしてきたので、全力で耳を塞ぎました。
感想、あとがき
ということで、エンジニアと正反対の位置に生息している私がエンジニア勉強会に参加してみたレポでした。
普段エンジニアはリモートワークをしており、Slackでのコミュニケーションが主です。
システムに何らかの障害が起きた際に投稿するSlackチャンネルがあるのですが、障害報告に対してスレッド内であれよあれよと対応、解決していく様子は、まさにみんなを救う正義のヒーロー。
この華麗な連携プレーができているのは、前提にみんなの様々な技術への興味感心と深く学び続ける姿勢があり、その上で実際に個人学習をしているおかげだなあと改めて実感しました。
（今回の発表資料にも5～8時間かけて研究、作成したそう。）
改めて尊敬、感謝、良いチームだなあと胸熱になりました。
みんないつもありがとうございます。
私もメンバーの可能性を最大限に発揮できる環境をつくっていきますね。
homieってどんな会社なの？と思ったそこのあなた・・・
homieは個人の成長が事業成長に繋がると考えています。
そのためインプットの時間を大切にしており、勉強会の他にも毎週インプットデーとなるものがあり、各々インプットに充てる時間を設けています。（またこちらも記事にします）
成長意欲の強いメンバーの要望で福利厚生も日々UPDATEしており、技術書の購入や社外セミナーの受講に加え、SaaS（Miro, AWS, GCP, ChatGPT等）の個人利用も可能です✨
成長の機会に溢れているので、ギークなメンバーとギークなお話をしたい方、事業内容や働き方などにご興味がある方はお気軽にお話ししましょう♪
普段ほみろぐサイドの執筆をしている私。
「エンジニアブログ」として投稿するのはどうか？題名詐欺ではないか？と考えたのですが、何事もやって後悔しようと母に言われたので投稿してみます。ですので、クレームは母へお願いします。
じゃあな！
