ID:65867さん

# プロジェクト概要 新規で写真トリミング機能を開発。 ### 担当フェーズ 前任者がフロントを部分的に開発しており、それを引き継いで一人で フロントエンド開発、バックエンド開発及びテスト。 ### チーム体制 1人 ------------ # プロジェクト詳細 ### バックエンド開発 【概要】 以下設計、テストおよびコーディングは全て自分が行った。 - tRPCによるエンドポイント設計とコーディング - Prismaモデル設計とマイグレーション - PrismaでDBに対しどのデータを取得または追加するかを書く - Vitestによるユニットテストの作成 - テスト作成の際、MySQLでテストデータにアクセスし、要件のあてはまるテストユーザーのデータを取得しVitestのユニットテストの条件に含める 【どのような機能の開発・実装か】 トリミング機能のバックエンド側の開発(エンドポイント設計、テスト作成等)を一人で行った。 【課題・問題点】 フロント側からどんなデータを取得するべきかを考え、写真のID、切り抜きをする際に枠が置かれた座標と幅、高さをフロント側から取得する必要があると判断し、そのように実装した。 【打ち手・使用した技術】 - 自分が使用したこの開発の技術 Node.js/Express/tRPC/Prisma/Zod/MySQL/Vitest/Docker ### フロントエンド開発 【概要】 テックリードが途中まで実装していたフロントの基本的なコーディングを引き継ぎ、以降コーディングは全て自分が行った。 【どのような機能の開発・実装か】 切り取りボタンで切り取りの枠を呼び出し、ResizeObserverで監視しながら任意のサイズに縮小するところまではテックリードにより既にできていたため、引き継ぎ後は以下の開発をした。 - ダイアログでユーザーが切り取りを決定した際にtRPCを通じてバックエンドにデータを送る実装。 - 枠の飾りがなかったためその実装。枠の飾りの実装において同じ枠や線が繰り返されているデザインだったため、同じデザインのグループごとに配列化して出現させる。 【課題・問題点】 単純にユーザーが任意の形に整形したものをバックエンドに送るだけだと、送った後にフロント側で表示される、切り取り後の写真のサイズや拡大率が、意図した通りにならなかったため、原因を探った。 ResizeObserverで監視している画像幅に対しimgRefで取得した幅で割った比率を、座標、高さ、幅に掛け算した形でバックエンド側に渡すと問題なく表示されることをつきとめ、実装した。 【打ち手・使用した技術】 - 自分が使用したこの開発の技術 React/Next.js/tRPC/TanStack Query/MUI/Zustand

# プロジェクト概要 ガントチャートの大規模リニューアル 。 # 担当フェーズ デザインへの提案、詳細設計、フロントエンド開発、バックエンド開発及びテスト。 # チーム体制 3人 - 自分(バックエンド,フロントエンド) - フランス人エンジニア(フロントエンド) - テックリード(レビュアー、2ケ月目よりページのパフォーマンス改善のため、フロントエンド、バックエンドを担当) # 業務内容 デザイナーからデザインが示され、チームで検討しながら担当部分に関して自身で詳細設計、開発。当初業務委託の方から示されたデザインが簡易的だったため、自身で提案しながらユーザビリティをさらに追求したデザインを提案しPMやテックリードと協議の上実装した。 ## バックエンド開発 【概要】 既存のガントチャートページを大規模にリニューアルすることになり、新しいエンドポイントの設計と開発、また、既存のREST APIのエンドポイントをtRPCのエンドポイントに変更する必要があったため、そのほとんどの作業を自分が同時に行った。 【どのような機能の開発・実装か】 エンドポイントの設計について初期はテックリードから若干の方向性指示があったものの、 以下を一人で行った。 - tRPC/Node.js/Expressによるエンドポイントの設計と実装、Prismaのモデル設計とマイグレーション - Vitestを使ったバックエンドのテストの実装。テストサーバーから条件に合うテストユーザーをMySQLを使って割り出してテストの内容に含める。 【課題・問題点】 全く新しくこのプロジェクトのためにtRPCでエンドポイントを作成する作業以外に、REST APIで作成していた既存のエンドポイントをtRPCで作り直す必要があったが、フロント側で使うときに使いやすいJSONを返す必要があった。またそのエンドポイントは汎用性のあるエンドポイントで、他のプロジェクトでも使っていたため、アプリケーション全体のことを考えてJSONを作る必要があった。 【打ち手・使用した技術】 まずは自分で必要なJSONの要素の洗い出しをし、フロント側で使いやすいJSONを設計し作成、その後メンバーとも議論を重ねながら、また自分でフロント側で実際に使ってみて様子も見ながら追加の要素を入れた。フロント側で使うガントチャートのそれぞれのプロジェクト開始日と終了日が条件期間に収まるように、あらかじめバックエンド側で計算して返すようにした。 <この開発で自分が使った技術> Node.js/Express/REST API/tRRC/zod/Prisma/MySQL/Vitest/TypeScript ## フロントエンド開発 【概要】 フロント側は既に別のエンジニアが開発しており、バックエンド側開発完了時点からの参画となった。ガントチャートと表が合体した形式のデザインになっており、自分は、ガントバーの作成や、表の列部分に対してメニュー機能実装、また、デザインの提案などを行っていった。 【どのような機能の開発・実装か】 親タスク子タスク孫タスクのようなネストされたタスク群にたいし、それぞれガントバーを実装する。また、表形式の部分に対しては簡単なメニュー機能を実装した。また、主にガントチャート部に対しデザインの提案をした。 【課題・問題点】 初期のガントチャートのデザインではユーザビリティ上足りないと感じる部分があったため、それに対する提案をしていった。 - ガントバーを見分けるための色の優先度がユーザビリティを考えると逆転している。 - 名称が不足していたのでガントバーの見分けがつかない。 - ガントバーの袖を伸ばしたときにハンドルがないのでユーザーにとっては引き伸ばせるのかがわかりにくい。 - 引き伸ばした先の着地点の日付がどこなのか不安を覚える。 【打ち手・使用した技術】 - ガントバーの色の優先度をつける。どちらがユーザーにとってより重要な情報なのかによって優先度をつけ、色の強弱をつける。 - ガントバーの名称をつけてどのタスクに属したガントバーかを一目でわかるようにした。 - ガントバーの袖を伸ばしたときのハンドルをつけて、引き伸ばした先の着地点の日付がわかるように日付を追加した。 <この開発で自分が使った技術> TypeScript/React/Next.js/tRPC/TanStack Query/Zustand

# プロジェクト概要 写真アルバムページのUIおよびバックエンド部分のリニューアル。 # 担当フェーズ デザインへの提案、詳細設計、フロントエンド開発、バックエンド開発、一部ミーティング主催。 # チーム体制 4人 - 日本人(バックエンド・フロントエンド) - 自分(バックエンド・フロントエンド、ミーティング調整) - アメリカ人(バックエンド・フロントエンド、リーダー) - フランス人(バックエンド・フロントエンド、サブリーダー) # フロントエンド開発 【概要】 デザイナーからの大まかな指示があり、担当部分に関して自身で詳細設計、開発。 【どのような機能の開発・実装か】 自分の開発範囲は、選択した写真をアルバムにするための設定画面の機能実装と、アルバム化したあとにその写真グループ詳細を一覧形式で表示するための画面の実装を担当した。 【課題・問題点】 機能実装自体は不足部分や問題があればデザイナーやチームと相談して追加実装したり問題を修正してうまく実装していたが、ビジネス側より大口リード顧客に契約してもらいたいため納期を1ケ月早めたいという話があり、開発スケジュールを前倒しにする必要が出てきた。しかし、リーダーたちはあまり急いでおらず、非常にのんびりした空気になってしまっていた。加えて、日本語があまり堪能なメンバーがリーダーだったため、自分がビジネス側とのブリッジ的な役割を果たす必要もあった。 【打ち手・使用した技術】 まだチーム全体が開発を始めたばかりだったため、開発スケジュールを修正することも簡単だと判断し、チームをフォローするため自発的にミーティングを開催し開発スケジュールを修正したり、メンバーの休みを取る日程などを差し引いて、予定の稼働日数からフロント、バックエンド、テスト、リリースなどの期間について割り出していった。基本的に新しいスケジュールで動くことになったが、途中でビジネス側から新しい機能を追加実装の依頼があったり、コアとなる機能で思うように開発できないなどが出てきたため、ビジネス側と話し合い、結局新しい納期より2週間ほどスケジュールを伸ばすことにした。 <この開発で自分が使用した技術> React/Next.js/TypeScript/Recoil # バックエンド開発 【概要】 Node.js/Express/REST API/Prisma/ZodによるAPIエンドポイントの開発。 【どのような機能の開発・実装か】 アルバムフォーマットのAPIの開発においてREST APIに基づく実装をした。アルバムフォーマットAPI用にZodで型安全にデータ構造を定義し、データ検証するファイルの実装と、ExpressやPrismaなどを使ったRouterを実装していった。 【課題・問題点】 初めてのバックエンドの実装をした。初期は他のエンジニアから大体の流れを聞いたが、ほぼ自走することができた。 【打ち手・使用した技術】 Node.js/Express/REST API/Prisma/Zod

# プロジェクト概要 - CypressによるE2Eテストのエラー修正 - その他UIのバグ修正 # 担当フェーズ フロントエンド側実装とテストリーダー # チーム体制 5人 - ベトナムオフショアチーム - アメリカ人 - コンゴ人 - 自分(テストリーダー) # E2Eテストのバグの修正 【概要】 CypressによるE2Eテストがエラーを300ほど出していたため、そのエラーを限りなく0にすること。自分はこのプロジェクトでテストのリーダーとなっていた。 【どのような機能の開発・実装か】 E2Eテストのエラーの内容を洗い出し、現状のUIに合うようにテストを書き換える。必要があればプロダクションコードを微修正する。 【課題・問題点】 当初300ほどだったエラーを1ケ月半で20にまで減らすことに成功したが、同時期に行っていたフロントエンドの開発のおかげで再び300に戻ってしまった。そもそもエラーの解消に意味があるのかや、メンバーのモチベーションやリソース、時間的な問題なども気がかりだった。 【打ち手・使用した技術】 この結果を踏まえ、当時のCTOに対し、E2EテストはUIが活発に開発されている段階では意味がなく、他の開発プロジェクトをするためのリソースや時間など考慮すると、大変もったいないためプロジェクトを中止するべきと進言した。メンバーも同意しており、CTOはこの進言を受け入れてE2Eテスト自体をなくすこととなった。 <この開発に自分が使用した技術> React/Next.js/Cypress/MUI/Storybook

# プロジェクト概要 写真表示部分と写真にメモを書き込む機能のUIおよびバックエンド部分のリニューアル。 # 担当フェーズ デザインへの提案、詳細設計、フロントエンド開発、バックエンド開発。 # 担当人数 3人 - コンゴ人 - 自分(前半リーダー、フロントエンド、バックエンドの開発) - テックリード(後半よりリーダーとして参加) # 業務内容 デザイナーからデザインが示され、チームで検討しながら担当部分に関して自身で詳細設計、開発。 # 功績・取り組み 初期は自身がリーダー的存在としてタスクを切っていた。 自身で一からMUIを使ったカスタムのUIライブラリコンポーネントを作成した。 後半は、大量の写真を一度に表示するパフォーマンス改善のためや、アプリケーション全体のコードを既存のpresenter containerパターンからシンプルな設計に変更し、可読性を高めたいというテックリードの意向により、モデルとなるプロジェクトにするため、テックリードがリーダーを担った。

# プロジェクト概要 モバイルのライブラリの更新・SSO・リリースの通知。 - モバイルリリース更新通知機能実装。 - 状態管理ライブラリの置換え(RecoilからZustand)。 - AWS Cognito / AWS Amplify クライアント認証(SSO)。 # 担当フェーズ 設計、開発 # 業務内容 - デザイナーまたはリーダーからの大まかな指示があり、自身で詳細設計、開発 またはシニアエンジニアが設計方針を指示し実装 # 功績・取り組み ## プロジェクトの背景 RecoilからZustandへ置換えをすることになった背景としては、一部のエンジニアから、Recoilはしばらくメンテナンスが行われていなく、また長く正式リリースもされていない、実験的なライブラリであるためプロダクトに組み込まないでほしいというアナウンスが公式に記載されているのにプロダクトに組み込んでいて良いのかという声があがったことから、RecoilからZustandへ乗り換えとなった。 Zustandはnpmでのダウンロード数でRecoilよりも圧倒的に多く信頼できる上、軽量シンプルに書けることも良かった。 ## 成果 ほぼ自身のみの開発でリリースすることができた。 バックエンドのエンドポイントの実装も一人で行うことができた。 特にRecoilからZustandへの置換えは誰の手も借りることなく開発を終えることができた。 Zustandでの実装は初めてで概念を理解することに苦労したが、ZenやQiitaや海外の記事などを用いて情報を収集して実装した。

# プロジェクト概要 モバイルにおけるメンション機能のうち未読既読に関する追加実装およびその他の実装。 # 担当フェーズ デザインへの提案、詳細設計、フロントエンド開発。 # 業務内容 自分からデザインを提案し、担当部分に関して自身で詳細設計、開発。 # 功績・取り組み 小さな機能だが、自分で良いと思ったデザインを取り入れて設計と開発まで行うことができた。 例えば、Xで使われているメンション機能では、新着があるとスクロールボタンが出現し、かつ新着メッセージがフォーカスされるようになっているが、このような機能は他のアプリでも使われており、ユーザーのメンタルモデルになっていると 感じるので、ヤコブの法則によりそのような機能をこのメンション機能にも追加した方がユーザーにメリットがあると感じたため、相談の上実装するに至った。

# プロジェクト概要 - ユーザー管理機能のUIリニューアル - IPアドレス管理機能のUI作成 # 担当フェーズ フロントエンド側実装。 # 人数 3人 - 自分(フロント開発) - アメリカ人(フロント・バックエンド開発) - コンゴ人(フロント開発) # 業務内容 - 検索機能、フィルター機能、タブ機能およびそれらを連携させた機能を開発 # 功績・取り組み - アメリカ出身エンジニアとともに英語でコミュニケーションをとりながら実装できた。 - 自分一人でロジックを考えて実装することができた。

# プロジェクト内容 海外向けBtoB、BtoCのマッチングプラットフォームのプロジェクト # プロジェクト詳細 ウェビナーやオンラインでの商談、ニュースサイト、取引会社の商品が閲覧できるカタログサイトなどを含んだ総合的なプラットフォーム # 担当フェーズ アイデア出しは既にできていたので、そこから実際に機能やデザインなどどうするかを要件定義しRFPに落とし込みました。また、開発会社選定も主体的に関わっており、技術要件だけでなく、このプラットフォームの特殊事情を絡めて判断していきました。 バックエンドやインフラではITコンサルタントの意見も聞いての判断をしておりました。 # 課題 経営側で落とし込みたい要望と、部署内で検討されていた要望、またそれらの実現可能性についてを各社と協議し、XD上のプロトデザインに落とし込み、受託開発企業に見積もりをとって開発させる。 - 中国でのECサイトの展開(経営側の要望)については、実現できるかをAWSやアリババクラウドなどと協議したが、社内、部署としてもリスクもあり実現には反対の立場だったため経営側への説得資料を作成した。社内の派閥間での競合などもあり結果実現しなかった。 - オリジナルのミーティングツールの作成 業界内で商談を活発に進めるためのツールの作成のためにビデオツールを開発している国内外の企業(Whereby/Google/Zoom/V-cube)について調査し、ミーティングやウェビナーでどの程度の人数が入れるのかなど見積もりをとった。 - 受託開発企業の選定 5社に声をかけ、3回ほどミーティングを設定し、技術言語やセキュリティ知識などから、最終的に1社に絞ることになった。 いずれもITコンサルタントの方にも意見を伺いながら進めていった。 # 技術要件 Webエンジニアのいない会社でしたが、プラットフォームを開発後にエンジニアを雇って内製化する可能性があったため、エンジニアを雇いやすい言語にこだわりました。人気のない言語ですと、メンテナンスが難しくなることを見越して、人気のある言語で開発したことのある開発会社様を採用要件にしておりましたが、多言語対応ができるかどうか、実際に海外向けプラットフォームを開発したことがあるかなども基準にしておりました。