ID:66070さん

# ウェビナー施策に関わる全てのタスクを一元管理できる、ウェビナーPDCAクラウドの開発・運用 # チーム編成 Bizz(13人), エンジニア(6人), デザイナー(1人) # 業務内容 ## サムネイル画像作成機能アップデート ウェビナー告知用のサムネイルを作成する機能に、ユーザーからの要望を反映しました。 具体的には以下の機能を追加しました。 - 文字に色を付ける機能 - 文字のコピー機能 - 文字の寄せ方向を調整する機能 これらの機能追加は、konvaをベースに実装しました。 ## 成果 導入した機能はCanvaに類似していますが、主要な機能ではないため、ユーザーの増加には繋がりませんでした。 ただし、Canvaとの差別化を図るため、文字ベースや画像生成AIを活用したサムネイル生成も提案しました。 ## チャット機能高速化 Bizzチームからの問題提起に対し、チャットページの起動速度やアクションの遅延に取り組みました。 主な改善点は以下の通りです。 - SSRからSPAへの移行 - 無限スクロールの導入 - フロントエンドでのAPI呼び出しの最適化 ### SSRからSPAに 既存のページはSSRであったため、ページの描画が通信待ちにより遅延していました。 SPAへの移行により、ページ描画を優先し、ユーザーが迅速にチャット画面にアクセスできるようにしました。 ### 無限スクロール導入 従来の実装では、全てのチャットルームを一括で取得しており、チャット数が増えると速度が低下していました。 無限スクロールの導入により、リクエスト数を制限し、高速化を実現しました。 APIの改善により、約5分の1の速度向上を達成しました。 ### フロント側のAPIを呼び出しの見直し サービスの未熟さから、APIの呼び出し箇所が不必要に多くなっていました。 この問題に対処するため、取得したデータをStoreに集約し、リクエスト数やデータ量を削減しました。 ## 成果 Lighthouse上では、起動速度が半分以下に短縮されました。 また、重い挙動も軽減され、Bizzチームやユーザーにとって使いやすいチャット機能が提供されました。 現在は、DBクエリの最適化やキャッシュの導入など、さらなる高速化を目指して取り組んでいます。

GameFiメディアです。まだ公にリリースをしていません。 ゲームの情報と、ゲームのニュース情報、ゲームのTransaction、ゲーム内トークンの価格を確認することができます。 # チーム編成 Bizz(1人), エンジニア(2人), デザイナー(2人) # 概要 2023年3月から、先輩から直接声をかけてもらい、GameFiメディアの立ち上げに参加しました。 主に先輩、そして内定者のインターンのデザイナーと協力して開発を進めています。 インフラと監督役でCTOに入ってもらっています。 # 技術選定 ## 使用技術 ### フロント - Nuxt3.2 ### API - Nest - Go ### DB - Mysql ### インフラ - AWS - ECS - Amazon RDS - AWS Aurora - AWS batch - Lambda - Amazon Managed Blockchain ### その他 - Python - GO ## 技術選定理由 - Nuxt3.2 新規事業であり採用の観点からモダンな技術を採用しました。 VueとReactで迷いましたが、技術スタック的にVueを採用しました。 また、新規事業でありスピードが重視されコードが雑になることが予想されたので、TSを採用しました。 - Nest web3系のフレームワークでJavaScriptが豊富だったため、Node.js系を採用しました。 その中で、開発工数を最小限に抑えるためにNest.jsを選択しました。 しかし、後にNest.jsを廃止しました。 理由としてnode固有のイベントループのブロックが不定期に発生し、安定稼働しなかったためです。 マルチスレッドにする方法や、レスポンスの容量を減らしてみましたが、改善されませんでした。 - Go(Gin+Gorm+CA) Goを採用した理由として、早急にNestjsから移行をしたかったため、自分が一番得意であるGoを採用しました。 また、当事業部にはGoエンジニアが多いので増員しやすいと思ったからです。 フレームワークとしてGinとechoで悩み、最終的に知り合いの学生数人にどっちのプロダクトに参加をしたいか聞き新卒の採用の観点からGinにしました。 ORMは最も人気のあるGromにしました。 テストを必ず書きたく、精度の良いテストにしたかったのでCAを採用しmockを使用したテストを書いています。 - AWS アプリケーションは全てイメージにしてECSに乗せてあります。 また、AWS batchにてトークンの価格とトランザクション情報を取得しています。 トークンの価格は、[CoinGecko APIにて取得](https://qiita.com/MoriKeigoYUZU/items/2db58fbea689dc84a80c)しています。 トランザクション情報はAmazon Managed Blockchainにてノードを立てて取得しています。 最初は[Etherscanにて取得](https://github.com/MoriKeigoYUZU/etherscan-rec)しようと思ったのですが、従量課金制で予算を出せば自分でノードを立てたほうが安くなるのでノードを立てています。 # グラフ機能 ## 概要 トークンやトランザクション情報を一覧で表示するために、グラフ機能を導入しました。 以下はグラフ機能の要件です。 - トークン価格情報の表示（複数の場合は選択可能） - トランザクション情報の表示 - 期間選択（7日、1ヶ月、1年、自由選択） - グラフクリック時に縦線を表示し、クリックした日を強調する - グラフクリック時には該当する日付のニューストピックに自動遷移する - ニューストピックを選択した場合、該当するグラフを表示する（表示範囲外の日付がクリックされた場合は、クリックされた日を中心に表示範囲を調整する） ## 取り組み・苦労した点 ### グラフクリック時の処理 - グラフのフレームワークとしてchartJSを使用しました。特定の日を強調する機能がなかったため、独自のプラグインを作成し、クリックした日付に色付けする機能を実装しました。 - ニューストピックに自動遷移させるために、クリックした日付に関連するニューストピックを表示する方法を開発しました。クリックされた日付に対応する情報がない場合は、その旨をユーザーに明示的に伝える仕組みを導入しました。 こちらは非常に苦労しました。 まず、グラフのフレームワークにchartJSを使用しており、特定の日を強調するライブラリがなかったので、自作のプライグランを作成し特定の日がクリックされたら色付けをする機能を実装しました。 以下一部抜粋 ```javascript const pinnedGraphDatePlugin = { id: 'pinnedGraphDatePlugin', afterDatasetsDraw: (chart: any, args: any, options: any) => { const ctx = chart.ctx; if (props.isTopicData == false) { return } const svgImage = new Image(); svgImage.src = thumbtackSvg; chart.data.labels.forEach((label: string, index: number) => { if (options.days.includes(label)) { ctx.save(); ctx.beginPath(); ctx.moveTo(x, textBoxY + textBoxHeight); ctx.lineTo(x, chart.chartArea.bottom); ctx.lineWidth = 2; ctx.strokeStyle = 'rgba(238, 66, 142, 0.45)'; ctx.stroke(); } }); }, }; ``` ### ニューストピックを選択した場合の処理 - ニューストピックを選択した際には、APIにクリックした日付と現在の表示範囲を送信します。APIはこれらの情報を元にデータを取得します。ただし、取得したデータが現在の表示範囲よりも未来の日付を含む場合や、過去のデータが表示範囲外に及ぶ場合には、適切な調整を行いレスポンスを返します。 また、ニューストピックを選択したら該当するグラフを選択し表示させるでは、 ニューストピックをクリックしたときに、APIにクリックした日付と、現在の表示範囲に送っています。 そこで、APIは日付と表示範囲から情報を取得するのですが、範囲が現在よりも未来になってしまったり、過去のデータの取得以前に及んでしまう場合は、ずれるように調整をしてレスポンスを返しています。 # ニューストピック取得 ## 概要 ニューストピックを半自動的に取得しています。 なぜ半自動化しているかというと、チームメンバーが少ないため手間をかけないように考えた結果決定しました。 ## 取り組み ニューストピックはかなり特殊な方法で取得しています。 GameFiは多くがDiscordにて情報を発信しています。 そのため、Discordをスクレイピングして自動化する方法にしようとしました。 しかし、Discordはスクレイピングが禁止されているので、別のアプローチを取る必要がありました。 そこで、Discord butを作成しbutを通して取得できるのはないかと思い採用しました。 仕組みとして、Gameのニュース・トピックが必ず公式のアナウンスチャンネルにて発信されます。 Discordサーバーに直接butを入れることは権限的にできないので、自分のチャンネルに転送させ、自分のチャンネルに常駐しているbutにて取得します。 取得したニュース情報は、OpenAIにて要約します。 その後、Slackにて要約した文と和訳した文を投稿しています。 投稿後、Bizz側が確認をし、OKであればスタンプにてアクションを、NGであればスレッドに新しいメッセージを書き込むことで編集ができるようにしました。 なぜSlackにて確認ができるようにしたかというと、管理者画面もあるのですが、ゲームタイトルの増加とともに大量のニュースが来ることが予想されたので、より気軽に使うことができるSlackにしました。 # ログイン機能 ## 概要 独自のお気に入りゲームリストや、自分の保有しているトークンの価格をリアルタイムでみたり、収支を確認する機能を追加するためにログイン機能を作成します。 認証にはMetaMask認証を使用します。 リリースに向けて制作中です。

予算と実績を管理し、今後どのように予算を使うか管理できる、予実管理SaaSです。 内定者インターン期間から参加し、新卒1年目の2月まで担当しました。 主にAPIを担当しましたが、学生時代にVueのアプリを複数個作ったことがある経験からAPIに比重をおいたフルスタックとして取り組みました。 # チーム編成 Bizチーム（4人）、エンジニア（8人）、デザイナー（3人） エンジニアはテックリードがいるわけではなく、全員がレビューする文化でした。 # 初めての業務 ## 概要 このインターンシップを通じて、私はエンジニアとして大きく成長しました。 以前の技術力は、フロントエンドではVueで簡単なアプリケーションを作成でき、APIでは他のインターンシップで学んだGoを用いてMVCのAPIを作成できる程度でした。 プロのエンジニアからのレビューやテストの経験がなかったため、自己評価は低く、初めの数日は自己嫌悪に陥っていました。 ## 取り組み 絶望している間もコードは進まないと考え、チームメンバーに基本から質問攻めにすることにしました。 また、特定の固有仕様に縛られることを避けるため、定期的に他社のエンジニアからアドバイスを受けるようにしました。 この習慣は今でも続けています。 本プロダクトでは、クリーンアーキテクチャが採用されていました。 私はDIや依存関係の考え方に不慣れでしたが、繰り返し壁にぶつかりながらペアプログラミングや研究を重ね、成長することができました。 # 学生インターンメンター担当 ## 概要 2021年のサマーインターンでは、2人の学生を指導しました。 私はAPIを主に担当しました。 ## 取り組み、工夫点 管理者向けアプリを開発しました。 フロントエンドは新規作成し、APIは既存のプロジェクトから組み込みました。 学生のスキルレベルから、大枠の要件定義とテーブル設計を行いました。 彼らが自力でAPIエンジニアとして成長することを目指し、厳しい文章は避け、難しい概念は口頭で説明するようにしました。 さらに、事業会社での楽しさを知ってもらうために、後半はBizzのメンバーと直接話す機会も設けました。 ## 成果 1ヶ月半で主要な機能を完成させることができました。 また、後日彼らがメガベンチャーのバックエンドエンジニアとして採用されたことを聞いて、非常に嬉しく思いました。 # MVCからクリーンアーキテクチャへの移行 ## 概要・課題 プロジェクトは当初MVCで開発されており、保守性が低かったため、クリーンアーキテクチャへの移行が必要でした。 ## どのような機能の開発・実装か MVCからクリーンアーキテクチャに載せ替えるだけなので、単純に載せ替えをしても良かったのですが、コード自体もスパゲッティになっていたのでSOLID原則を特に意識して書きました。 ## 成果 日々の移行作業により、大部分のコードをクリーンアーキテクチャに移行することができました。 また、移行が完了していない部分については、優先度や難易度に基づき、正社員や学生インターンに割り当てました。 このプロセスで、私は新しいメンバーに教えることや、事業部外のエンジニアとの勉強会を主催するまで成長できました。 チーム全体として、保守性が向上し、テストや可読性の改善が実現しました。 # APIドキュメント作成 ## 概要・課題 当時、詳細なAPIドキュメントが存在しなかったため、Swaggoを使用した自動生成機能を開発しました。 ## Swagoo採用理由 主にエンジニアはAPIのPostmanでリクエストを送っており、Swaggoにて発行される形式がそのままPostmanにインポートできるため採用しました。 ## 躓いた点 当サービスでは、セッション管理にauth0を使用していたため、BearerTokenの設定が必要でした。 しかし、Swaggoを使用してもBearerTokenに値を設定することができませんでした。 そのため、API Tokenを生成し、BearerTokenとして使用できるようにしました。 https://github.com/swaggo/swag/issues/709 # ピン留め機能作成 ## 概要 PLの見通しと、計画にピン留めをし、他の機能でもピン留めされたPLの見通しや計画にピンを表示実装をしました。 ## 取り組み・躓いた点 通常、単純にピン留め機能を実装するだけであれば、新しいカラムを追加するか、新しいテーブルを作成すれば十分でした。 しかし、組織や部門間の緊密な関係があるため、複数のテーブルを考慮しました。 また、ビジネスロジックをクエリ内に含めることを避けたいという方針もあり、ロジックの量が増加することが予想されました。 そのため、テスト駆動開発のアプローチを取り、テストを通過させるためにロジックを細分化しました。