ID:67082さん

＃プロジェクト概要 新しく監査の対応が必要になった部門の監査対応とそれに付随する承認フローなどの整備 ＃チーム情報 エンジニア 1名 監査対応部門 2名 # 取り組んだ課題と解決したこと 新しく監査の対象となるため、監査法人はどういった事業でどういったシステムがどう連携して動いているかを理解する必要がありました。 ## 解決策 まずは、すべてのシステムの連携を図にまとめドキュメントとして新しくまとめ直しました。 また、分かりづらい業務や売上利益に関わる部分にどう人の手がか関わっているかも1つの資料でわかるようにしました。 ## 成果 これまでのどの部署よりも丁寧にまとまっていると評価いただけました。 また、この機会に個人情報を見ることができる人の制限を行えるように、チームメンバーの業務の洗い出しと使用できるツールの制限をかけることでより安全にシステムを利用できるようになりました。

＃プロジェクト概要 データ可視化までの時間を短縮できる、データ分析基盤の構築 ＃チーム情報 エンジニア1名 # 取り組んだ課題と解決したこと ## 課題1 私が所属している事業部は、カートを含めた多数のSaaSを利用しており、データが分散しているという課題がありました。また、各媒体からCSVをダウンロードし、それぞれが異なる定義でデータを加工していたため、統一されたデータ定義が存在していないという課題もありました。 ## 解決策 これらの課題を解消するため、データ基盤を新たに構築しました。初期段階ではAWS BatchとEmbulkを利用してデータ基盤を構築していましたが、運用エンジニアが不在であり、データ変換の多さから理解しづらい状態でした。そこで私は、外部のETL基盤であるtroccoを導入することで、新規接続元の追加と運用保守にかかる工数を削減しました。 ## 成果 これにより、新規接続元の追加と運用保守にかかる工数が削減され、データ基盤の運用が効率的になりました。 削減した工数は月間130hを削減しました。 # 課題2 データの変換ロジックや定義がメンバー間で一致していなかったことです。これにより、各人が見ている数字の定義が異なっており、会話がうまく噛み合わない事態が発生していました。 ## 解決策 私はデータ基盤を構築する過程で、各メンバーが持っている定義が事業的に適切かどうかを検討し、統一した定義を確立しました。その後、BIツールを用いてデータの可視化を行い、いつでも同じ定義に基づいたデータを見られる環境を整備しました。 ## 成果 これにより、データの分析にかかる工数と数字の確認にかかる工数を大幅に削減することができました。 毎朝分析担当者が行っていた２０分程度の業務を５分に短縮することができました。

＃プロジェクト概要 受託案件で受けたつわりを支援するアプリケーション開発 ＃チーム情報 エンジニア１名 デザイナー１名 ビジネス１名 # 取り組んだ課題と解決したこと ## 課題 エンジニア１人でバックエンドからアプリケーション作成までを３ヶ月で行う必要があり、なるべく効率化した開発が求められていました ## 解決策 バックエンドには、SaaSのHasuraを採用しバックエンドの開発工数を削減しました。 この結果、DB設計とデータ取得形式、権限の設定のみでバックエンドを開発することができました。 アプリ側は今後Androidの開発を予定ししている点と要件が複雑ではなかったため、Flutterを採用しました。 初学者でしたが ## 成果 ３ヶ月という短い期間でしたがアプリを完成することができました。 また、2023/07/現在でもリリース後の不具合が０となっております。

＃プロジェクト概要 自社開発プロダクトのライター管理ツールのバックエンド側のリアーキテクティング ＃チーム情報 エンジニア 6名 デザイナー１名 ビジネス 5名 # 取り組んだ課題と解決したこと ## 課題1 立ち上げ初期のプロダクトのため、突貫工事で作成した部分が多く存在していました。 特にバックエンド側がレイアードアーキテクチャを採用していましたが、設計者が不在となりチーム全体として正しい設計がわからない状態に陥っていました。 ## 解決策 私は途中から参画したため、まず設計者が何を意図してクラス設計を行っているかを整理しました。 現状の実装と設計者が意図していた設計のズレいている箇所を洗い出し、資料化とチームメンバーへモブプログラミングなど行うことで布教をしました。 ## 成果 結果として、設計に迷うことがなくなり、全体として統一した意思のもと開発を進めることができるようになりました。 ## 課題2 レイアードアーキテクチャが概念だけ取り入れた状態になっており、API作成をする場合に作成するファイル数が増加していました。 その結果、１機能の実装にかかる時間が１ヶ月とリリース後の不具合も200件を超える状態となっていました。 ## 解決策 分析を行っていくと、Read処理とPost処理両方で作成にかかる工数が同じであることがわかりました。ReadはDBの中身を指定された条件を用いて出すことが多くビジネスロジックがあまり関わらないにも関わらず増加ていました。 立ち上げ初期のため、描画項目増加に係る工数も増加していました。 そのため、CQRSの概念を取り入れ、データ作成はビジネスロジックとして処理を行い。読み込みの処理は、クエリとして処理するように変更を行いました。 ## 成果 開発工数も1ヶ月かかる実装を2週間で終わるようになりました。