ID:66850さん

【職務内容】 <経験業務> ・大手保険会社のBtoC/SNSサービス　インフラ移行（Hexabase→MySQL）に伴うAPI改修、機能改修 技術環境： Typescript(Node.js /Express)/Jest/GitHub/Docker ・大手薬局のBtoC/処方箋電子化申請サービスに伴うバックエンド、インフラ機能改修 技術環境: Typescript(AWS CDK) チーム:10名(フロント2名、バックエンド6名、インフラ1名、PM1名) 役割:バックエンドエンジニアとして割り振られたAPIを一人で担当 【実績】 ＜問題＞未経験のため進捗を出せるかどうか自信もなかったし期待もされていなかった。 ＜対策＞ ・疑問点は切り分けた上で、知識不足によるものは自ら調査し、解決が難しいものは他者に質問することで、タスクの進捗を一定に維持した。回答者への負荷を考慮し、緊急性の低い質問はまとめて行うなどの配慮をした。 ・タスクの影響範囲を常に意識し、自身の完了したタスクが他メンバーに影響する場合は率先して共有することで業務を円滑に進めた。 ・メンバーのこれまでの進捗や負荷を考慮してタスクを割り振り、個人の進捗状況を可視化・共有することで稼働の過不足を防いだ。 ・認識の齟齬や解釈の不一致には、状況に応じてテキストベースのコミュニケーションとビデオ会議を使い分け、丁寧に対応した。 ＜結果＞・最終的な成果については問題がなく、同等タスクのメンバーと比較して進捗や精度面で最もバランスが取れていて純粋な職務遂行能力では９０％以上の評価を直属上長（PM）やリーダーからいただいた。 【詳細な機能】 改修担当機能:170個あるうちの40個のAPIをhexabaseからexpressにリプレースするための改修を一人で実施した(その他のメンバーも担当割り振りして一人で実施)。ユニットテストコードも全て実装した。 デバッグ担当: 対象地域を3つ選択する機能のソート機能のデバッグ 1つの地域につき、都道府県、市町村、地域の3つを選択できるが不要な都道府県、およびそれに対応する市町村が含まれていたことで処理に4秒以上かかるようになっていた。2,300行にも及ぶアーキテクチャに難のあるしコードを精査して選択結果に基づいて次の項目の選択候補が変わるようなロジックをGETのコントローラーに追加してユニットテストを行った。

[役割]チーム3名(pm,フロント、バックエンド・インフラ)のうちバックエンドインフラエンジニアリーダー(1名なので)として参画 【職務概要】 ・疑問点に優先順位をつけて、調べたり考えればわかるような問題かつ、今後も出てきそうな知見の場合は、理解できるまで分析、検討、考察、確認する。 ・作業開始前にはある程度考えて取っ掛かりがみえてから作業に着手する 唯一のバックエンドエンジニアとしてバックエンドに参画した。上記2点を踏まえて作業を行い、2週間以上先行してストーリーポイントを消費することができた。 余裕を持ってタスクを完了できたため、バックエンドのクリーンアーキテクチャやインフラのファクトリー的な構成への理解、非同期処理をラムダ関数の最大負荷を考慮して設計したりするなど技術的な知見を実装に活かすことができた。 また、APIの設計やテスト設計、インフラレイヤーに携わることで、全体像を俯瞰して考える習慣ができたため次のwoven by toyotaの社内システム構築プロジェクトで要件定義や設計工程の担当を期待されている。 【職務詳細】 実装した機能:メッセージ機能 新規作成したAPI:MC/LIFFメッセージ送信・取得(webSocket通知,サービスメッセージ通知),MC予約メッセージ送信,MC予約メッセージ送信キャンセル,未読メッセージ送信フラグ,備考取得・更新・作成,予約メッセージ送信バッチ,LIFF服薬フォロー登録など 改修したAPI: 処方箋ステータス更新,処方箋作成 新規作成したDB Table: メッセージステータス、メッセージ、備考など 【課題・問題点】エンジニアになり2つめの案件であったが新規でAPI、インフラを作成する経験は初めてであった。またメンバー一人で実質リーダー的な振る舞いを求められていたら、クリーンアーキテクチャで実装されており、アーキテクチャの理解が必要であった。 個別のAPIでは、負荷を考慮して1対1にデータを対応させない設計が難解であった(メッセージ:メッセージステータス=多対1) 【打ち手】 ディレクトリ構成をみて全体像を掴み、細部の細かな点はざっくり何をしているかだけ把握しつつ全体の流れを理解するようにした。 【結果】 二週間先行してストーリーポイントを消費して実装を完了した。