平野 直弥

【目的、背景】 　某放送局社員が収録した映像や音声などのコンテンツを管理したり放映リストに登録できる業務システムの実装 【タスク内容】 ・画面のUIコーディング ・機能実装 ・単体テスト ・経験浅い人へのアドバイス ・リファクタリング ・状態管理ツールのリプレイス ・api routeでのログ出力実装 ・ファイルアップロード機能 ・ただ仕様通りに開発するのでなく、ほんとうに必要な仕様か、もっとこうした方が良いなどユーザー目線で提案 【規模感、チーム構成、担当した役割 　リーダー：1名 　セクションリーダー：3名 　開発メンバー：10名 【使用技術や開発環境等】 　フロントエンド：TypeScript、Next.js、MaterialUI, バックエンド：C♯ DB：MySQL、SQL Server ツール：DevOps、Git、Teams 【取り組んだ課題1】
 　多くの機能を提供していた画面のため1つのコンポーネントのコード量が1500行以上になり、開発の運用性や可読性に欠けていた。このままだとバグも発生しやすくなり保守性に欠けると考えたことから以下を行なった。 　・画面の構成要素ごとに別コンポーネントに切り出し、共通化・部品化及び外出しを行なった
　　 　・状態管理の共通化できそうなロジックはカスタムフックで切り抜き再利用性を高めた
　　　　 　・同じプロップスの型が様々なコンポーネントでその都度定義されていたので、TypeScriptの「type of」などを使って型定義の再利用を行なった。 
 　結果、1500行以上のコンポーネントの行数を300行未満~500行までに削減でき、ソースコードの運用性や可読性を向上させて開発コスト削減に貢献した。 私はこのように業務の中で自ら問題点を見つけ解決に導けます。 【取り組んだ課題2】
 　画面設計書の記載が抽象的なためプランニングの際に仕様を詰めきれておらず、チケットの見積もりが甘くなり予定工数通りにチケット消化が進まない状態が続いた。 　対策として、画面設計書の記載を以下のような具体的な情報を記載することで、プランニング時にタスクを細分化しやすくより正確な見積もり時間を算出できるようにチームに提案して実行した。 　・「分けるべき」または「共通化/部品化すべき」コンポーネントのロジックやプロップスなどのコンポーネント構造 　・状態管理はuseStateを使うのか、Reduxでグローバルに管理するのかなどの状態管理方法 　・エラー時の挙動、使用するエラーコードやエラーメッセージなどのエラーハンドリング情報 
　　結果、1スプリント内にチーム内のチケット消化が10チケット中5チケット程度しか消化できなかったのが、10チケット中8チケット以上を消化できるまでになった。 　　私はこのように失敗経験を糧にして試行錯誤していくことで、成功体験に結びつけることができます。 【取り組んだ課題3】
 　どのAPIにどの状態管理ツールを使用するか私と他メンバーで相違があったことから、一度フロントエンドの全メンバーと認識合わせする必要性を感じ以下を実行した。 　・フロントエンドメンバー全員をMTGに招待して認識合わせの機会を設けた
　　 　・MTGにて、私が認識しているuseState, Redux, RTK Queryの状態管理ツールの使用用途を整理したフォーマットを共有して、それぞれ状態管理ツールの使用用途の認識合わせを行った。
　　 　・MTGにて、先ほどまとまった状態管理ツールの認識を元に、どのAPIにどの状態管理ツールを使用するかの検討と認識合わせを行った。 　結果、状態管理ツールの使用用途と各APIの状態管理ツール採用理由の認識を合わせることができた。 私はこのように他者を巻き込んで積極的に気付いた問題を解決に向かえる行動力があります。

チャットの様々なグループからの頻繁な情報更新についていけないという問題を抱えておりましたので、情報をキャッチアップすべく工夫を心がけました。 ①　後から調べると時間がかかりそう、もしくは変更が多いタスクはExcelにまとめてデスクトップに保存し、素早く修正・追加・確認ができるようにしました。 ②　Excelにまとめる時間がない場合は、付箋にメモしたり、チャットを未読に戻して隙間時間でまとめました。 ③　“あるタスクに詳しい人”を把握しておき、どうしてもわからない事はその人にチャットで直に聞いて、短時間で不明点を聞き出せるようにしました。 御社でも業務及び新技術をいち早くキャッチアップすることで貢献していければと存じます。