ID:31970さん

## プロジェクト概要 カレンダーベースのUIを用いたSNS投稿管理機能のフロントエンド開発をリードし、直感的な操作性を実現しました。 ## 役割・体制 ### 自身のポジションと役割 - チームリーダーとしてフロントエンドの設計を担当し、設計と概念実証コードを作成してメンバーへの技術引き継ぎを実施しました - ブラウザAPI・ライブラリの技術調査と既存機能・APIの活用方法を整理し、メンバーがスムーズに実装着手できるよう、ドキュメントとコードの準備、丁寧な説明を行いました ### チーム規模と構成 エンジニア3名、デザイナー1名、リーダー1名の計5名体制で、スクラム開発を採用しました ## 背景・課題 - SNSの投稿を管理できる機能を刷新するプロジェクトの一つとして、ユーザーが直感的に投稿を管理できるカレンダーベースのUI機能の開発が求められていました - デザイナーが示した機能はメンバーのスキルセットでは実現が難しく、しかし自分自身はマネジメント・採用・コードレビューを主に担当していたため、開発時間の確保が困難でした。 - 「ただ動くだけではなく、アクセシビリティについても考えた実装にする」という要件もありました ## 実際の取り組み ### 開発環境 - スクラム開発を採用し、2週間程度のスプリントで継続的に機能開発を行いました。 - React Aria Component を中心に開発を進めることで、アクセシビリティを担保しつつ保守しやすい開発を目指しました ### 設計・改善内容 - 概念実証用のコードと丁寧なドキュメントを用意し、毎スプリントでメンバーがスムーズに実装に取りかかれるよう説明会やペアプログラミングを行いながら開発を進めました - チーム外でも利用されている日付ライブラリの課題感をチーム間で共有し、課題解消のためのモジュール設計を提案し、実装に結び付けました ### 反省 機能をいざリリースしようというタイミングで、操作性のパフォーマンスがネックになりました。開発時に早期発見できるよう、パフォーマンス面の受け入れ条件も設定すべきでした。 最終的にはリリースに間に合うよう調査・修正を引き受け、パフォーマンス上の懸念もなくしたうえで予定通りリリースを達成しました。 ## 成果・価値 - 約2ヶ月で機能をリリースし、ユーザーから直感的で使いやすいという好意的なフィードバックを得ました - タイムゾーンを考慮した日付データの取り扱いについて、わかりやすく説明するスキルを身につけました - React、Redux、JavaScript のパフォーマンス調査・最適化についての知見を得られました

## プロジェクト概要 RTK Queryコードの自動生成ツールを導入し、フロントエンドのAPI利用工数削減と、APIドキュメント更新フローの改善を実現しました。 ## 役割・体制 ### 自身のポジションと役割 入社後まもない時期で、エンジニア組織のいちメンバーとして開発に参加していました。 ### チーム規模と構成 約15名規模のエンジニア組織で、フロントエンド、バックエンド、インフラ担当者が混在するチームでした ## 背景・課題 - 新規APIを追加する際、バックエンドの実装だけでなくOpenAPIドキュメント作成とフロントエンドのReduxボイラープレートコード作成に工数が発生していました - OpenAPIドキュメントの更新は後回しになりがちであり、ドキュメントと実装の乖離に課題感がありました ## 実際の取り組み ### 設計・改善内容 私は先人の知恵が好きで、特にRob Pike氏（Go言語作者のお一人）の書籍で「プログラムにプログラムを書かせる」考え方が紹介されており、これが心に残っていました。 入社後間もないタイミングで前述の課題感に触れ、「OpenAPIのドキュメントがあるのであれば、ボイラープレートなコードは生成できるはず」「この仕組みが導入できれば、『ドキュメントの更新』というフローを仕組み上必須にできるはず」という仮説を立てて調査しました。 結果として当時はリリース後間もなかった`@rtk-query/codegen-openapi`[パッケージ](https://redux-toolkit.js.org/rtk-query/usage/code-generation#openapi)を見つけました。 プロダクトコードに反映するためのPoCを作成しつつ、[Redux Toolkit](https://redux-toolkit.js.org/)の導入も必要だったためこのドキュメントの調査やドキュメントに記載されていないことについてもソースコードを調査しました。そのうえで社内説明会を開催し、導入の提案を行いました。 導入の際は既存コードの置き換えを目標としないことで、現在の開発スピードを緩めずに新しい開発から効率化していくことを狙いました。 ## 成果・価値 - フロントエンドから新規APIを利用するための開発工数が恒久的に削減され、開発効率が向上しました - OpenAPIドキュメントの整備が促進され、ドキュメントと実装の一貫性が保たれるようになりました - Redux Toolkitも合わせて導入されたことで、Redux関連のボイラープレートコード削減と保守性向上に貢献しました

## プロジェクト概要 Gitのブランチ運用体制を改善し、新機能開発の効率化とコンフリクト解消コストの削減を実現しました。 ## 役割・体制 ### 自身のポジションと役割 入社後まもない時期で、いちメンバーとして開発に参加する立場でした ### チーム規模と構成 約15名のエンジニアチームでした ## 背景・課題 - 新機能開発がフィーチャーブランチ上で数カ月単位で行われ、またmasterブランチはスカッシュマージ運用であったため、両者間の乖離が進んでいました - ブランチ間の差異を解消するためのコンフリクト対応に定期的に大きな時間とコストがかかっており、一部のメンバーが新機能開発に集中できない状況が続いていました - メインブランチを定期的にリリースするフローでしたが、リリース前のテスト期間が存在し、この間はバグ修正以外でメインブランチを更新できませんでした ## 実際の取り組み ### 改善の提案 現状のブランチ運用の課題感について整理しつつ、新しいブランチ運用フローについてコミットグラフによる図解とともに提案しました。 また説明会を開き、具体的にどのような運用フローになるかをチーム全体に説明しました。 他、元の運用で得ていたメリットを継続的に享受できるよう、代替操作についても示し、移行がスムーズに行われるよう意識しました。 ### その他アピールポイント 一連の取り組みについて会社ブログに執筆しています。この記事は2万PVを超え、会社ブログの流入トップを誇る記事となっています。 [https://www.wantedly.com/companies/socialdog/post_articles/461640](https://www.wantedly.com/companies/socialdog/post_articles/461640) ## 成果・価値 - 新しいブランチ運用によってコンフリクト解消にかかる工数が削減されました - 「リリース前にメインブランチの開発をストップする」というフローがなくなり、開発がスムーズになりました - コミット履歴の粒度が増え、修正の背景を追いやすくなりました - スカッシュマージから移行した事例として記事を公開することができ、会社の広報にも寄与しました

## プロジェクト概要 Event Sourcing + CQRSアーキテクチャを導入し、監査要件に対応した機能の設計をリードしました。 ## 役割・体制 ### 自身のポジションと役割 - チームリーダーの立場から、新機能実装に向けたドメイン駆動設計およびEvent SourcingとCQRSをベースとしたアーキテクチャ設計を担当しました - 新しいアーキテクチャ導入の提案と技術調査を行い、開発チームの設計方針策定に貢献しました - コーディングエージェントの活用推進も行っていたため、AIと当該アーキテクチャとの相性についても検討しました ### チーム規模と構成 エンジニア3名とリーダー1名の計4名チームです ## 背景・課題 （未リリースのため、機能の詳細な情報は伏せさせていただきます） 新機能では監査要件やデータの更新履歴保持が必要で、既存のコードベースのアーキテクチャではこれらを実現するために課題感がありました。 ## 実際の取り組み - 要件に適合する技術としてイベントソーシングベースのアーキテクチャの採用を提案し、技術調査を通じてその妥当性を検証しました - コーディングエージェントを使った開発が今後主流になると考え、それを前提とした検討を行いました - 開発チーム向けにドメイン駆動設計、イベントソーシング、CQRSに関する勉強会を開催しました ## 成果・価値 - 未リリースのため、ビジネス価値が実際にあるかは正直まだわからない段階です - 他チームから「ドメイン駆動設計を導入したかった」という声は寄せられ、コードベースの今後の改善の契機になったかもしれません - チーム外向けの勉強会は限定的ながらも、「ビジネス価値を高めるための設計」について啓蒙する機会となりました