ID:45293さん

--- # 個人開発プロダクト ## 概要 とあるゲームを中心に、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を作成しなければいけない点

# 新規開発[予定] ## 概要 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より簡単な報告を受けた。

## プロジェクト目的 Web系の言語習得を目的とした個人開発プロダクト。 課題としては、その時プレイしていたソーシャルゲームのゲーム内通貨を現金へ換算すると幾らになるかが、ゲーム内で調べる手段がなかったので、サイトとしてサービスを作る事とした。 規模感としては言語初挑戦なところもあり、題材として現金換算の処理をなど規模としてちょうど良かったため作成の決断を行った。 ## 公開 [Github](https://github.com/OKAUEND/grablprice.github.io) [公開サイト](https://grableprice.azurewebsites.net/) ## 使用技術/開発環境 ・HTML / CSS / JavaScript ・VSCode / Github ## 課題 Web開発初挑戦であったため、HTMLのマークアップの構成や、CSSのスタイリングなどで苦労をした。 特に、CSSは中央配置や半透明などで、CSSをあまり理解していなかった部分が多く、プロパティの扱いで数日を費やすこととなった。 ロジック部分では、ゲーム内通貨とゲーム内で使えるチケットなどを合算し現金へ処理する必要があった。 ユーザーの入力されているのを動的に受け取り、それを無入力かどうか、数字以外の文字列が入力されているかどうかのバリデーション処理を行うなどの課題が多くあった。 バリデーション処理では、共通部分の処理も多かったため関数として切り出すなどのDRYも意識しつつ全体のロジック製作を行った。 ## 成果 公開を行った後に、同じゲームをしている方々へ使用をしていただき、今いくらのゲーム内資産があるかが分かりやすくなったと高評価を頂いた。 最初のプロダクトであったので、私のスキルとしてWeb周りの知識が身につき、特にCSSとJavaScriptの基本なども学ぶ事ができたなどの成果があった。