ID:45293さん

自社のプロダクト開発・運用 派遣等の求人や面接の管理システム ## プロダクト概要 派遣業界向けの採用管理SaaSシステム。 領域は応募から採用までのフローを一括で管理を行える。 特徴としては過去に応募したり在職していた求職者の掘り起こしを行う部分であり、休眠状態の求職者へアプローチを重点的に行うことができる 【チーム全体】 - PdM : 4人 - エンジニア : 12人 - フロントエンド : 6人 - バックエンド : 6人 - UIデザイナー : 1人 - QAエンジニア : 6人 これらを3つのチームに分けそれぞれわけ、私が所属していたチームは7人規模となりました - PdM : 1名 - フロントエンド : 2名(私含む) - バックエンド : 2名 - QAエンジニア : 2名 --- ## 業務内容 **概要** - 人材派遣管理の新規機能実装 - 技術負債となっている箇所のリプレイス - ユーザー満足度が低い画面や機能をリプレイス **担当業務**： フロントエンド領域, 仕様書ドキュメント作成、Issueチケット切り、PdMやUIデザイナーとの協議、チームレトロ、チーム内での機能探索会の実施 **使用技術**: Vue.js, React.js, Next.js, Node.js, アジャイル/スクラム, GitHub --- ### Vue.jsからReactへのリプレイス作業 Vue2で構築されていた機能をReact(Next.js)へ置き換える社内のリプレイスプロダクト。 **【課題】** Vue2のEOLになったため、Vue3への更新が必要となったのと、これからのプロダクトをより洗練していくため、これを気にコミュニティが活発であり、TypeScriptの恩恵が受けれるReact(Next.js)へリプレイスを行う。 **【実装・目的】** プロダクト理解をより深めるために、リプレイスIssue(画面)を一部担当を致しました。 Vue2側で実装されている画面や機能をコードリーディングを行い、それをどうReact側へ落とし込むかを実務として経験することにより、プロダクト理解を含めコードリーディング能力と設計力と実装力を向上させる事を目標と致しました。 **【成果・成長点】** Vue側では1つの行数が多いコンポーネントだったのを、Reactでは機能毎に切り分けをし更にAPI層や関数群や型定義などをディレクトリに整理をし、後で他エンジニアから見てもリーディングしやすい事を意識し実装を行いました。 コードレビューではチームの暦が長いフロントエンジニアやテックリードの方から多くの指摘を頂き、何度も実装し直すなどで自己の立ち位置と不足している部分、実装を通して学んだ事が多いタスクとなりました。 #### 新機能画面の新規実装 **【課題】** 1ヶ月毎の開発期間毎に次期開発計画として新規機能開発を行う。 新規機能開発を選出するベース。 - プロダクトをより洗練していく中で必要な機能 - ユーザーの満足度が低い及びユーザーから改善の要望があった機能 その中で私が携わった箇所の2つの機能の課題があった。 - 求職者への求人配信や復職の働きかけなどの結果の統計がExcelで非常に見にくく、件数が多いと負荷が高く閲覧に支障を来していた - 配信や復職の働きかけなどを行わない除外対象とする画面で、設定ミスが発生しうるUIであったので改修が急務であった - 新たな機能としては除外対象としてメールアドレスのドメインを指定する場面が出てきたので対応する **【実装】** 当初はメンターの方とペアプロしながら作業を行ったが、チームでの新規実装1Storyをすべて携わる事となり、PdMとデザイナーとの仕様定義から実装、週に1度のスプリントレビューでの開発内情報共有なども行った。 実装していく中で開発をスムーズに行う上で以下の事を工夫して行った。 - 実装に入る前にUIデザイナーが作成してくださったFigmaを元に、どのような実装をするかDesignDocを作成 - DesignDocをテックリードやチームのフロントエンドエンジニアにレビューをして頂き、設計を固める **【成果】** 実装上での成果としては、初期はメンターエンジニアとの伴走から疑問点をペアプロで解決していただいた時が多かったが、最終的には新規実装のエピックなどは、私個人1人で新規実装を行えるようになった。 開発を行った結果、ユーザー様からは以前より使いやすく見やすくなったとの声を頂きました。 ・エクセルで見ていた統計をブラウザ上で見ることができ、フィルターなどが非常に使いやすかった ・統計画面の実装をお聞きしており、非常に期待し待っていたとのユーザー様の声をいただいた #### バックエンドエンジニアと共同でREST APIの仕様定義 半年ほどより、チームのバックエンドエンジニアの方とともに新規実装するAPIの定義やどのようなデータの構造が必要なのかを、打ち合わせしながら共同でAPIの実装を行った。 私はフロントエンド側の知識を元に、フロントエンドではどのような形で使われるかをバックエンドエンジニアの方へ伝え、どのような形での実装がよいかの情報提供をし、ときにはバックエンドエンジニアの方の疑問をフロント側の実装内容を元に解決に導いた。 ##### 手引のドキュメント作成 実装を行う上で、開発チーム独自に組んだロジックや関数などをメモや使用方法の手引をドキュメントにしておくことで、どこで詰まったかやどのように使えばよいかを社内での共有資産としてドキュメント化を行った。 ##### 仕様書への仕様変更箇所の反映及びADRへの反映 PdMやUIデザイナーとの仕様決定ミーティングを通して決定した内容を、自ら仕様書へ反映を行い、ADRなどへ変更ポイントを記載しチームチャットで周知を行った。 PdMが行う作業であったが、携わらせていただくことで仕様書の流儀やドキュメントの変更ポイントの書き方、チームへの周知などを経験することで、仕様決定時の流れを学ぶことができた。 #### チーム内での実装箇所の探索会を実施 ユーザーからの使い心地や不具合点などを事前に洗い出すために、実装した画面や機能に対してチームメンバーで一度触り機能を確かめるイベントを一定の進捗毎に開催を行った。 開発メンバーだけではなく、QAエンジニアの方にも入っていただくことにより、QA目線での不具合や機能的にわかりにくいポイントの洗い出しなども行うことで、より品質の高い状態での実装を終える事がチームとして出来るようになった。 また、開発チーム全体としては週に1度スプリントレビューで実装箇所のお披露目があるため、その前までに所属チーム内で探索会を行う事でより品質が高い状態でスプリントレビューでCSや営業の方にお披露目が可能となった。 --- ### 成長への取り組み ##### DesignDocを元にしたIssue切り出し、実装、PR作成 より実装コードの設計力を向上させ、また実装方針をドキュメント化していくためにDesignDocをメンターエンジニアの方と共に作成を行った。当初はペアプロで行っていたが、一通りDesignDocの作成と実装を行った後には、1人で作成をしその後メンターエンジニアやテックリードエンジニアの方にレビューをしてもらってからの、実作業へ移るような開発工程へとシフトした。これにより、事前に実装上でAPIとの疎通をどのコンポーネントに任せるかや、コンポーネントの親子関係を決定しておくことで、実装する上での品質向上や実装速度の向上を実現した。 #### 最新のトレンドに詳しくなるためのウィークリーニュース活動 次のエンジニアとして進むべき道を「最新の技術に詳しく、設計やアーキテクチャでリードできるエンジニア」と定めました。 どのような事を行えば最新のトレンドに詳しいエンジニアになれるかを考えた時に、いち早く最新の情報を入手しそれを試す事であると考えました。そこでまずはじめに社内のフロントエンドエンジニア向けに一週間前の週に発表されたり出来事が起こったニュースをまとめ、概要と感想を添えて社内に発信するウィークリーニュースをこの5月から始めました。 社内のエンジニアよりもいち早く情報を入手し社内発信を行う事で、社内のテックリードエンジニアでもまだ気づいていないライブラリの更新などをお伝えすることができ、プロダクトの環境更新などの一助になったこともあります。 トレンドでより深堀りを行ってみたいものに関してはテックブログを作成し、サンプルコードなどを元にどのような技術なのかを社内外共に情報発信しました。 その結果、社内としてはテスト環境改善のためPlaywrightの導入検討を行っている中で、私主導の勉強会などを行う予定となっておりました。

# 新規開発[予定] ## 概要 SNSサービスの買収及び、それにともなうサービス変更による混乱により、多数のユーザーが分散型SNSて移動を行った。 しかし、分散型SNSの欠点として、情報の共有が起こりにくいとの事象が存在するため、SNSの情報をまとめるサービスを立ち上げる事とした。 ## 開発環境構築 チームでの開発であるため、Dockerを使用する。 当方は開発マシンがWindowsであるため、WSL2 + Ubuntu22.04を用意しその上でDocker環境を構築。 ## 担当フェーズ 要件定義・技術選定・詳細設計・実装・テスト フロントエンドエンジニアとして参画。 主にフロントエンド周りとして、技術選定や画面毎の要件定義などを担いながら、実装やユニットテスト/統合テストの実装も行う。 ### 技術選定 プロダクトの性質上、画面の変更が頻繁に行われないため画面の表示を素早く行えるSSRやSSGを扱えるNext.jsを採用。 また、バックエンドはPythonとし主にAPIを担い、それをフロント部分でREST APIなどで呼び出す構造とするため、 FetchのキャッシュをNext.js App Routerで行えるのも理由の一つである。 ## [予定] フロントエンド ユーザー登録画面・まとめ記事一覧・編集画面等を作成予定 ### 要件定義 Next.js App Routerを使いフロントの画面を構築する。 REST APIのエンドポイントとやり取りすることで、ログインや必要なデータのやり取りを行う(予定) 現在要件定義中。 ## [予定] バックエンド MySQLとのやり取りを担い、それらをフロントへAPIの形式で担う。 ### 要件定義 言語は発注者の要望でPython。 REST APIとしてMySQLのDBの値をやり取りするために、FastAPIを導入。 各APIのエンドポイントについては現在要件定義中。

# 保守運用 ## 概要 ユーザーからあがってきた不具合調査や、ユーザーからの要望が実現可能かなどの調査を行う。 ## 手順 - ユーザーから操作ログを頂き、不具合が起きた場所のログから操作を再現する - 操作を再現し、不具合を再現できたらコードの調査を行う - コードに問題があれば、どのような不具合か、コードのどの部分に問題かの報告書を作成し提出 - 不具合のFIXを行うかはPLが判断する - 修正依頼がきたら、修正作業を行う 基本的にはこの手順で調査を行う。 1日2件を担当し、週に10件ほど消化していくのが通常業務であり、 特別依頼が合った場合には、複数人で1件を多角的に調査することもあった。 # 医療検査の点数が最新のものかを通知する画面を作成(1画面) ユーザーからの要望により、医療検査などの最新の医療点数かを通知する画面を作成した。 ## 概要 検査の医療点数は検査期間毎に改定される事がある、しかし改定量が多かったりすると、 検査を依頼する医師側が、気づかず以前のまま依頼を出してしまうことが多かったため、 それを防ぐために新規画面として機能を追加した。 ## 課題点 - 選択された検査の情報などは、アプリの基本機能として処理している - 参照しようとするには、設計の奥深くの変更が必要 - 通知するべき情報などは、既存のテーブル上には存在しない - 通知の画面は新規設計とする ## 課題点の解決方法 - 選択された検査の情報などは、アプリの基本機能として処理している 医師が選択した医療検査の情報は、アプリの設計の基礎的な場所で行われており、その情報を参照しようとしたら、その部分の設計変更が必要となった。 取った手法としては、既存処理の変更は最低限、情報を新しい変数へ代入するようにし、それ以外はなるべく変更を行わないようにした。 また、必要な情報を既存の処理から取り出す際に、すでに使われていない処理やリファクタリングされていない部分などブラックボックス化している場所に触れなければならず、そこの解読を行うのに非常に時間がかかった。 - 通知するべき情報などは、既存のテーブル上には存在しない 通知する情報などの精査には、改めて新設した年度マスターテーブルや最新の検査情報テーブルからデータを取り出すこととした。 また、判定はクライアントサイドのアプリで処理を行い、通知画面をポップアップするようにした。 課題としては、 また、既存処理のリファクタリングは工数的に不可能であったため、既存の処理へ影響を及ぼさないように新しい変数や戻り値などを設定していく工数が非常に手間がかかった。 - 通知の画面は新規設計とする 画面の新規設計自体は予め画面設計を行い、話合っていたため問題が発生することはなかった。 # ソフト高速化対応 顧客より、ソフトの起動や動作が遅いとの不満があがった。 ソフトの処理が遅い箇所を調べ、改善方法を提案するチームに配属され、実際に調査/改善方法の検討を行うこととなった。 ## 調査 ソフトの処理が遅いとの事であったが、どのような操作を行った時に処理が重いかを調べる所となった。 ユーザーの操作ログを精査した結果、ソフトを起動時に約5分ほど起動に時間がかかっている事が解った。 更に調べていくと、クラサバとのSQLの通信を行っている部分で処理が詰まっている事が判明。 次に、他のユーザーでも同じような現象を調べた所、データベースに非常にデータが多いユーザーで同じような遅延が起きていることがわかった。 その時のデータベースは1ユーザー平均で20GBほどであった。 ## 解決方法の提案 調査結果を伴って、まずは以下のような提案をPLへ相談を行った。 - 起動時のSQL部分で遅延が起こっているため、SQLのリファクタリング - サーバー側の不要なデータを整理することが可能か - 起動処理でも遅延しやすい処理が多かったため、起動する部分の処理もリファクタリング可能か **サーバー側の不要なデータを整理することが可能か**と**起動する部分の処理もリファクタリング可能か**は、コードを大幅に書き換えるため、デバッグやそもそものリファクタリングに莫大な工数がかかるため、今回は見送りとなった。 そのため、SQLのリファクタリングを行うことで、高速化が行えないかの調査で作業を続行することとなった。 ## SQLのリファクタリング 高速化方法としては、以下の事を試すこととした。 - SQLの全面的な再構築 - 処理が遅くなっている部分のクエリの一部分を改修する - インデックスを構築しSQLには手を出さない **SQLの全面的な再構築** 該当のSQLが、サブクエリやジョインなどを一つのクエリの中で多く行い、30行以上の複数行に渡ってSQLとなっていた。 それをまとめれる部分はまとめ、無理やりジョインしていたりサブクエリにしていた部分を分解し、小分けにし高速化が行えるかを試した。 **処理が遅くなっている部分のクエリの一部分を改修する** サブクエリやジョインなどで、条件クエリを追加したり、より範囲を絞るなどして、参照箇所を減らすようにし、高速化が行えるかを試した。 **インデックスを構築しSQLには手を出さない** 既存のSQLにインデックスが適用されるように、インデックスを構築し直した。 試した結果、**SQLの全面的な再構築**を行うほうが一番起動時間の高速化が行えた。 これらの事を試し、高速化した結果の起動時間等を比較した資料を作成し、PLへプレゼンを行った。 ## 調査の結果 結果として、SQLのリファクタリングも同じくリファクタリングした時のデバッグ工数や不具合発生などを考えた時に、行うのはリスクが高いという判断をPLが下したため、インデックスの構築を行う事となった。 実作業はサーバー担当者が行ったところ、該当ユーザーの起動処理が高速化を行えた事を、後日PLより簡単な報告を受けた。

--- # 個人開発プロダクト ## 概要 とあるゲームを中心に、Youtubeで配信している配信者の方々をピックアップし一覧表示を行い、更に配信者毎の過去アーカイブ動画なども一覧で表示するWebサービス [公開サイト](https://ffxiv-vtuber-archive-clone.vercel.app/) ## 背景 昨今、ネットワークに接続しプレイをするゲームが流行っており、 更に動画配信サイトでその様子を配信しながらゲームを遊ぶスタイルが確立されている。 配信者の様子をみた視聴者が共に遊ぶためにゲームソフトを購入し、 参加する視聴者が増えることで配信が盛り上がり、配信者のコミュニティが大きくなる事で、 更に視聴者が増えたり、ゲームソフトのコミュニティ自体が大きくなるサイクルが起こっている。 しかし、大きくなっていくと共に、課題も発生している状況となっている。 実際にも配信者と遊び関わっていく中で、視聴者側の視点/配信者側の視点からの両方で課題があると考えた。 ### 視聴者側 視聴者が配信を行っている配信者を見つけるには以下の障害があると分析している。 #### 配信者を探し出す事が難しい - ゲームソフトのタイトル名で検索をしても、配信者ではなく近い内容の投稿動画が表示 - 配信者を探す事は可能であるが、いくつかのオプションを変更する必要があり、操作の手順が多い - 必ずしも現在配信中の配信者や、関係のある配信を行っている人が結果で表示されるわけではない - 視聴者がそのゲームソフトの配信で関心のある内容で探し出せない - 視聴者が複数個の過去アーカイブを見るまで把握することができない #### SNSで見つける事が難しい - 配信者はSNSにもアカウントを持っているが、SNSも検索機能は満足度が高い物ではない - 動画配信サイトよりも関係のない結果が返ってくる事が多く、探し出せない - SNSでも情報量は記載している情報が多くなく、視聴者の関心で探しだせない 上記の現状より、視聴者はたまたまおすすめに上がってきた配信者を見に行ったり、 たまたまSNSでタイムラインに他のユーザーから宣伝されたのを見て、訪れたなど偶然に頼る要素がかなり強い。 ### 人を集めることができない 配信者側も、配信を通じ自身の配信コミュニティを拡大していく中で以下の障害があると分析している。 #### 視聴者を集めにくい - 配信サイトのアルゴリズムが、評価の高い配信を上位に表示する 高評価や同時視聴者数、配信コミュニティ登録者数が多いコミュニティを検索結果上位に表示する傾向がある。 そのため、登録者数や視聴者数が少ないコミュニティは結果に表示されづらく、視聴者の流入が少ない。 - 概要欄などに配信傾向をハッシュタグなどで付けていても、期待してるほどの効果がない 上記のアルゴリズムの他、複数の条件検索で検索を行っても、タグ検索を行えるわけではないため、 傾向とマッチする視聴者を流入させれるほどの効果はない。 また、視聴者側もハッシュタグ検索などを使うわけではないため、タグ検索はあまり意味をなしていない。 このような結果、大手であると同時視聴者数は多く、配信者が任意の遊びをしようと人を募集した場合に、 1分も待たずに人が集まるが、逆に同時接続が30名ほどであると1時間や2時間など長時間に及ぶことがある。 それにより、配信者の画面が変わらず見栄えが悪くなるなどで、配信者も視聴者も満足度が下がる結果となっている。 ### どういうサービスにするのか 対象ゲームで配信を行っている配信者の一覧及び検索機能を作る --- ## 開発 ### 担当フェーズ 要件定義・設計・新規開発・結合テスト・リリース・保守運用 ### 開発環境 #### 言語・フレームワーク】 TypeScript Next.js Prisma #### OS Windows10 #### DB Supabase Google Spreadsheet #### 管理 Github Projects Github Issue --- ## 要件定義や詳細設計の方法 ## プロダクト管理/タスク管理の課題 ### 背景 個人開発を行っていく中で、最初はシンプルなタスクややりたい事をその場で考え順番に着手し開発を行っていた。 プロダクトのVer1リリース前後から、今後の機能実装案や改善案、不具合修正などで多くのタスクが重なってきていた。 ### 課題 - 様々なタスクや機能案が発生し、個人で管理しきれない - 機能要望や改善案に対してのドキュメントを整備出来ていない - どうするのか、どうやってするのかなど、実装方法などの資料がなく、見返すと思い出せなくなる - 何をしたいかをメモ化していないので、1つのタスクが終わると次にやることの思い出しからになる ### 改善方法 - Github Issueへ、機能案や改善案などを積んでいく - 個々のIssueに、背景や課題点などをドキュメントとして残していく - 画面の実装になると、簡易な実装案のワイヤーフレームなども残しておく - 2週間スプリントで、それらの積まれたタスクで優先度の高いものを選択肢、Trelloのタスクへ積んでいく - スクラムマスターとして、開発実行が出来る粒度までチケットを分解していく ### 実績 - 何をしたいか、どうするかなどがドキュメント化されたことにより、プロダクトの全体が把握可能となった - Issueとして残す事で、課題や議題が可視化され、優先度を決めやすくなった - デザイナーへの発注やメンターへの相談などでも、ドキュメント化されているので、課題点を相談しやすくなった - PRの粒度がチケット単位まで分解されたことで、コードレビューがしやすくなった ### チーム開発 ・商用デザイナーの方にコミットをして頂き、プロダクト全体して相談及び会議を行い、プロダクトの方向性や実装案などを打ち合わせをし、それらを実装案を決定。　 ・打ち合わせをした内容を、スクラムの手法を元にGithub Issueへ落とし込み、詳細設計や要件定義を経て、Trelloにてチケットを発行し、実装作業へ落とし込む。 ・イラストレーターのデザイナーの方へ、ローディングUIなどを、イメージ図と共に仕様書を作成し、発注を行った。 ・イラストレーターとの打ち合わせ時には、画面上ではどう見えるか、ユーザーはどう捉えるのが目的に即しているかなども踏まえて、会議を行った。 ### 実績・取り組み #### こだわったポイント ・TOPページの配信者を選ぶ事で、すぐに配信者のアーカイブを見ることができる ・アーカイブでは取り扱うジャンルだけをピックアップするため、続けて過去の配信を追いやすい ・条件で検索をすることにより、好みの配信者を検索出来る(将来的に拡充予定) ・Next.js/TypeScriptでAppRouterを使い最新のモダン環境で開発を行った ・SSRを主体で使う事で、ユーザーの不満になりやすいロード待ちを減らすように設計を行った ・アーカイブ一覧では、Youtubeと挙動が出来るだけ同じになるように無限スクロールで実装を行った ・配信者一覧は入力がやりやすいスプレッドシートで入力管理をし、それを元にSupabaseへ反映を行う ・バックエンド側の実装で開発負担を上げたくなかったため、Next.jsのバック側とPrismaを使いバックの代替を行った ・URLのクエリパラメータを元に、PrismaのWhere文を動的に作成 ・クエリパラメータを元に値の取得が行われるため、ユーザーがURLのブックマークを行い擬似的なお気に入りを可能とした ・レスポンシブデザインにすることで、スマホとPCでも同じ体験となり操作の違いによりユーザー離れを防ぐ ・配信者の登録数が増えても、ページ自体はNext.jsのAppRouterにより動的に対応する ・配信者の登録数が増えても、移動ボタンは自動的に生成されることで、手動でボタンを増やさなくてもよい ・実装したい機能や作業中のタスクが混雑するようになりどこまで作業を進めればよいか管理しきれなくなったので、スクラムの手法を取り入れる。 ・機能の追加や実装案や改善案などはIssueで管理し、Trelloで優先度を管理するなど、作業の進捗の透明化を行った #### 苦労した点 ・AppRouterの情報が少なく、公式ドキュメントを見ながら実際にどのような挙動になるのかを確認しながら開発を行った ・無限スクロールでは、最初は全て自ら設計したため、試行錯誤による作り直しなどの手直しが何回も発生した ・開発サーバー環境では動作するが、Vercelの本番環境ではエラーになる箇所の特定と原因究明 ・管理者画面作成時に、Supabaseのログイン認証処理で、Cookieへの反映が行えずログイン処理が失敗になっていた点 ・スプレッドシートとSupabaseの登録情報を照合するロジックで、動的にKeyが増えた場合でも対応出来るようにオブジェクトから配列を作り出したロジック ・PRを作成しコードレビューを行って頂いたいたが、自らの考えをかけておらず、質問等などの確認で時間を浪費した所 ・スクラムの取り入れる時に、1週間スプリントで試しに行ってみた所、振り返るタスクが頻繁になり、タスク管理の負荷が上がりすぎた点 ・AppRouterにMSWが対応していないため、Fetch等のテストでは手動でMockを作成しなければいけない点