ID:81741さん

## プロジェクト概要 - AIを活用し、目標設定から日々の行動管理までを支援するWebアプリの開発 ## プロジェクトにおける自身の役割 フロントエンドを主軸（全体の約7割）として、UI設計・実装およびパフォーマンス改善を担当しました。 あわせて、検索・権限周りなど一部バックエンド（約3割）の実装にも関わり、フロントエンドとバックエンドの責務分担を意識した設計改善にも取り組みました。 また、実装だけでなく、開発がスケールする中で顕在化した課題に対して、PRレビュー体制や設計のあり方について改善提案と実行を行いました。 ## 当時の背景・抱えていた課題等 開発のスケールに伴い、PRレビューの属人化や技術的な面としてフロントエンドへの責務集中といった構造的な課題が顕在化していました。 ## 課題に対して自身が発揮したバリュー及び成果 ### PRレビュー体制の再設計 当時、PRレビューは特定のメンバーに集中しており、レビュー待ちが発生するだけでなく、依頼する側も心理的な負担を感じやすい状況でした。私はこの状態を、個人の問題ではなく、属人化したレビュー体制そのものがボトルネックになっていると捉えました。 そこで、PRレビュー体制の再設計を行いました。単純な均等ラウンドロビンでは、大規模変更や難易度の高い実装においてレビュー品質が低下する懸念があったため、PRの難易度に応じてアサインを分ける方針を採用しました。具体的には、難易度の高いPRは経験豊富な2名が担当し、それ以外のPRについてはチーム内でラウンドロビンを行う形としました。 私自身が他者のコードレビューを通じて成長してきた経験から、レビューを特定のメンバーに閉じず、チーム全体の学習機会として機能させたいという意図もありました。 また、Slack通知を自動化してレビュー依頼を可視化し、依頼・対応双方の心理的負担を軽減しました。 その結果、レビューの偏りが解消され、レビュー完了までの流れがスムーズになりました。加えて、メンバー間のコード理解が進み、チーム全体の底上げにつながりました。 ### フロントエンドに集中していた責務の再設計 当初、検索や編集権限の判定といった業務上の判断ロジックをフロントエンド側で担っており、データ量の増加に伴ってロジックの肥大化やパフォーマンス低下が発生していました。 私はこれを実装上の問題ではなく、「本来バックエンドが担うべき判断をフロントエンドが抱えすぎていること」による設計上の課題だと捉えました。このまま機能追加を続けると、変更に弱い構造になると判断しました。 そこで、検索や編集権限といった判断ロジックをバックエンドに集約し、フロントエンドは取得結果の描画に責務を集中させる構成へ変更しました。 その結果、フロントエンドのロジックが簡素化され、挙動の把握やデバッグが容易になりました。機能追加時の影響範囲も限定され、拡張性を意識した構造へと改善することができました。
 ### その他、実装面での主な取り組み フロントエンドを主軸に、以下のような実装・改善にも取り組みました。 - SWRフックの定義や利用方法が散在していたため、データ取得用のカスタムフックを共通化し、責務と利用箇所を明確化 - SWRキーが増えすぎてキャッシュ制御が追いづらくなっていたため、キーを一元管理し、意図しない再取得や更新漏れを防止 - 大量データ取得時にフロント側の処理負荷が高くなっていたため、バックエンドでの絞り込みと無限スクロールを組み合わせ、表示パフォーマンスを改善 - 認証初期化前にAPIが呼ばれるケースでUXが悪化していたため、ローディング・リトライ挙動を整理し、不要な再試行や表示崩れを防止

## プロジェクト概要 AIを活用し、目標設定から日々の行動管理までを支援するモバイル向けネイティブアプリの開発 ## プロジェクトにおける自身の役割 React Native（Expo）を用いたモバイルアプリのフロントエンド開発を主軸として担当しました。 画面設計やUI実装に加え、プッシュ通知機能の設計・実装、モバイルアプリ特有の利用シーンを考慮したUI構成の検討などを行いました。 また、少人数チームでの開発であったため、実装だけでなくコードレビューや実装方針のすり合わせにも関わり、品質を保ちながら開発を進めました。 さらに、ExpoおよびEASを用いたビルド設定やストア公開準備にも関わり、 Google PlayおよびApple App Storeへのリリースまで担当しました。 ## 当時の背景・抱えていた課題等 既存のWeb版ではプッシュ通知が行えず、ユーザーがアプリを能動的に開かなければ更新やタスクの変化に気づきにくいという課題がありました。 また、本サービスは個人ユーザーだけでなく組織での利用も想定しており、日々のタスクや行動管理をスマートフォンから利用するケースが増えることが見込まれていました。 そのため、ユーザーが適切なタイミングで通知を受け取り、モバイル環境でもスムーズに操作できるようにする目的で、ネイティブアプリの開発が行われました。 一方で、Web版のUIはマウス操作と広い画面を前提として設計されていたため、同じ機能をそのまま移植するとモバイル環境では操作性が低下する可能性がありました。 そのため、単純なレスポンシブ対応ではなく、モバイル利用を前提とした体験設計へ再構築することが課題となっていました。 ## 課題に対して自身が発揮したバリュー及び成果 ### モバイル利用を前提とした体験設計の再構築 ネイティブアプリ開発において、Web版の機能をそのまま移植するのではなく、デバイスごとの操作特性に合わせて体験を再設計することを重視しました。 Web版はマウスと広い画面を前提としたUIであり、一覧性や複数情報の同時把握を重視した設計でしたが、モバイル環境では画面サイズやタッチ操作を前提とした設計が求められるため、同じ機能でも役割を見直す必要がありました。 例えばAIチャット機能では、Web版では作業画面を見ながら並行して利用する補助UIとして配置されていましたが、モバイル版では画面サイズの制約を考慮し、チャットを独立した専用画面として設計しました。これにより、ユーザーが1つのタスクに集中して会話できる体験へと変更しました。 また、タスク詳細画面では、Web版では子タスク、コメント、関連情報、アクティビティを1画面で横断的に確認できる構成でしたが、モバイル版では縦スクロールを前提とした構成に変更し、コメント入力や子タスク操作がキーボード表示によって崩れないように設計しました。 検索機能についても設計を変更しました。Web版ではキーボード中心のSpotlight型検索として素早く呼び出せるUIでしたが、モバイル版では検索を全画面モーダルとして切り出し、入力から結果確認までを1つの流れで完結できるUIとしました。限られた画面サイズでは検索行為そのものに集中できる構成の方が操作性が高いと判断したためです。 このように、レスポンシブ対応として単純に画面を縮小するのではなく、マウス前提のUIとタッチ前提のUIを分けて設計することで、モバイル環境でも直感的に操作できる体験を実現しました。 ## その他、実装面での主な取り組み モバイルアプリの開発において、以下のような実装や開発環境の整備にも取り組みました。 - Expo / EASを利用したモバイルアプリのビルド環境の構築 - Expo Notifications を利用したプッシュ通知機能の実装 - iOS（APNs）および Android（FCM）を利用した通知配信構成 - CI環境での自動テストの実装による品質向上 - Expo EASを利用したビルドおよびGoogle Play / Apple App Storeへのリリース対応