ID:68885さん

【プロジェクト概要】 ・AISaaSの機能開発 BtoB向けのSaaSを提供している自社開発企業のフロントエンドエンジニアとして業務してます。月一リリースでプロダクト開発を行ってます。ワークフローは下記に記載の通りです。 【業務内容・ワークフロー】 1. 毎月POおよび開発リーダー中心に機能実装の要件の洗い出しを行う。 2. そこから各要件の工数見積もりを行う。過去稼働実績・ベロシティから、翌月の工数・予想ベロシティを 算出し、その工数の範囲内で月に行う要件を確定させる。 3. 確定後フロントエンド実装、バックエンド実装をそれぞれカードとして切り出しメンバーをアサイン。 4. 各カードのゴールとDeadlineを敷き、ゴールまでのステップを書き出してから実装開始。 5. 基本的にはモブプロを中心とした開発を行い、開発後レビューを受け、問題なければマージ。 6. 2週間後を仮コードFIX日とし、以降は企画チームからのレビュー対応と並行してテスト実装を行う。 7. 3週間後をコードFIX日としタグを切りリリース。 以上の開発業務を毎月行っていく。 細かなIssue対応は隙間時間で適宜Issueカードを取っていき修正PRを出す。 【実装内容】 ■検索機能・検索結果の絞り込み機能実装 ▼課題点： ・分析データ数が多くなり画面が重くなっている状態 ・過去に作った分析データの検索が困難（100件以上の分析データがあった時、それを探す全て黙示しかない状態だった） ・絞り込み機能やそれの条件を保存する機能がなくユーザー体験が悪かった ▼打ち手・使用した技術 ・分析一覧画面上に「検索フィールド」を設け 　作成者/ユーザーID/データ種別で分析データ一覧を絞り込みできるようにする ・各分析データにタグを付与できるようにし、タグでの絞り込みができるようにする ・ページネーション機能を追加し、画面表示の処理スピードを向上させる ・TypeScript、Nuxt.js、Vue.js、GraphQLを使用 ▼成果 ・リリース後の顧客満足度アンケートで機能に関するプラスのフィードバックを複数いただく ・分析結果画面の画面表示時間の短縮 ・絞り込み機能により利便性が高まる声を複数いただく ▼開発時に意識・改善していたこと ・子コンポーネントから画面描画する親コンポーネントまで3つほどコンポーネントを跨ぐ必要がありコードの可読性が下がっていたので、グローバルで状態管理を行いデータの受け渡しがバケツリレーにならないように工夫した。 ・APIでデータをとってくる際、属性ごとでデータ取得を行いそれを関数として用意し、今後再利用しやすいように実装した。 ・ユーザーにとって使いやすい実装かどうかを常に意識し、気になる点があれば小さなことでも積極的に PO、開発リーダーに質問、提案を行う。(ボタンの位置、画面遷移、スピナーの影響範囲、ホバー・クリ ッ ク処理などの細かな点などを含む) ・命名規則を守り変数名だけでどんな関数かを想定がつくように心がけた。(isで始まるメソッドはboolean の想定がつく、能動的なものはon~、動作が具体的なものは適切な動詞を命名するな ど。)命名をどっちにするか意見が割れた時は英単語の語源など用途を調べ、どちらがより適切かの議論をしていた。

# 【プロジェクトの概要を記載】 主にIPO準備を目指す企業が社内の業務を統制していることを記録、整理するために作成する内部統制文書を効率よく作成するためのSaaSプロダクトになります。 現在リリース1年が経ち、メイン機能を中心に中小企業から大企業向けのサービス提供に向けて開発をしています。 ・従来：Excelを使用して「業務フローチャート」「業務記述書」「リスクコントロールマトリクス」の通称3点セットを作成していた ・smoove利用時：重複した記載の自動連携、証憑ファイルの添付や管理などをできるようにして、従来の作成時間が大幅にカットされるようにするイメージです。 # 【業務内容の深堀】 ## 使用技術： ・フロントエンド：Typescript, React, Next.js, react-hook-form, yup(フロントバリデライブラリ), tailwind CSS, testing library など ・バックエンド：Rails, RSpec, factorybot, caxlsx, roo, など # 開発フロー スクラム開発を採用。通常は2週間に1回のリリース。PjMから受け取った機能別のフィーチャーチケットを細かく設計、タスク分割、見積もり決めをする ▼流れ スプリント最終日：次スプリントの計画作り 1~5日目：開発期間 6日目：開発完了日、stagingにリリース物反映 7日目：QA実施 8,9日目：QAで出たバグ改修→staging反映 10日目：リリース、次スプリントの計画作り # フロントエンド領域の開発業務 ## ①：コンポーネント設計 モーダル、テキストフィールド、サイドバー、カード、トーストなどの各パーツをコンポーネントとして用意 props値の決定、useState, useContextを使った状態管理、useFormを使ったフォーム実装などを実装する ・工夫すること・考えること ### ◯基本的にはUIとロジックを分けてコンポーネントは作りたい 例えばそのコンポーネントのみで使っているAPIリクエストをしているメソッドがあればファイル内でカスタムフックとして用意しておく。そのフックを別箇所でも使いたい場合にexport をつけることですぐに横展開できるメリットがある。コンポーネント内部でメソッドを定義していて、そのメソッド内でコンポーネントで定義している useStateなどを参照していたらロジックのみ後から切り出すのが難しくなる。なので最初からロジックを分ける前提で作りたい。 ### ◯reutrn内にはなるべくロジックを含めない map処理などをしているとついついその処理ないでconst定義をしたくなるがDOM構築する箇所にロジックの記述があると可読性が損なわれると考えるため可能であればreturn の外で変数は準備しておきたい ## ②：インターフェース設計 主にバックエンドに投げるリクエストを決める。ここはバックエンド実装も一緒にやる時に考えることが多い →フロント的に渡しやすい形は何か。 →バックエンド的に扱いやすい受け取り方は何か を考えてその整合性が合うように作っていくイメージ。 ・工夫すること・考えること ### ◯基本はテーブル構造と合わせる その方がparamsで受け取ったバックエンドがそのままDB保存しやすいので。ただ少しの加工でフロントでの取り回しがしやすいものになるならそれは許容してバックエンド側で調整する ### ◯propsはSOLID原則に則って設計する コンポーネントの入り口となるpropsはすぐに窓口が広がりがちになるので、結構慎重に決めることが多い。どこまでをそのコンポーネントの責務とするかをちゃんと考えないと汎用性のないでかコンポーネントができるだけなのでSOLIDを基本にインターフェースを考える ## ③：レイアウト調整 デザイナーの意図を組むこと・不安であれば積極的に会話をすること・似たようなコンポーネントができないように共通化を意識すること -------------------------------- ## バックエンド領域の開発業務 ## ①：MVCを基本に設計・実装する モデルにはそのモデル特有のロジックを定義する コントローラーには可能な限りロジックを含めない。あくまでフロントから受けとったparamsをDB保存していいかの関門のイメージ。 どういてもロジックを含める必要があったときは、モデル側で管理できないかや、サービス層に切り出すかなどを検討 ビューは実質Nextが担ってるので割愛。 ## ②：テーブル設計について 基本はnull: false, 1対多, 多対多がわかる名前にする migrationファイルは下記の優先度で実装する 1. migrate, rollbackが1回ずつ必ず実行できる 2. 既存データが死なないこと 3. 過去に戻ってもデータの整合性がとれること ## ③：モデルについて validatesをちゃんとつける →存在チェック、ユニーク制約、「特定のモデルがあるときは〇〇になる」のようなカスタムバリデもモデルに定義 has_many, belongs_toによる関連付けを行う dependent: :restrict_with_error, dependent: :destroyで紐づくモデルの対応もする 外で使わないメソッドはprivateメソッドで管理 ## ④：コントローラーについて エラーメッセージはフロントで管理するのでエラーコードだけ返すようにする permit処理の実施 -------------------------------- # その他 ## undo/redo の実装 図形の削除→undoボタン押下→図形の復活 というようなundo（Command + Z の機能）を自作した /task という1つのエンドポイントで管理して、そこに操作アクションを定義してそのアクションの逆操作も一緒に定義して, taskQueue, undoStack, redoStackを操作ごとに詰んだり消したりしてundo/redoが行えるように実装した ## 共同編集の実装 Action Cable というRailsの機能を使って、バックエンドからWebsocket経由でフロントに他の人の操作が反映されるようにした。