ID:66503さん

# 概要 ToC向け大規模アプリのバックエンド改修外注 # 担当 社内IT担当としてプロジェクトマネジメントとベンダーコントロールを担当しました。 # 取り組み プロジェクトマネージャーとして、ウォーターフォールモデルにおける以下の工程を担当しました。 ・要件定義 ・ベンダーへの要件説明 ・開発予算の確保（社内プレゼン） ・試験（受入試験、性能試験）計画の作成 ・リリース前準備（試験結果まとめ、リリース体制の確保、ベンダー調整、リリース承認のための社内プレゼン） ・リリース当日の夜間作業 ・検収 # 工夫した点 ・プロジェクトを進める上で迷ったときは、相談したいことを自分言葉で整理して先輩社員にアドバイスを仰ぐようにしました。 ・社内プレゼン（開発予算の確保やリリース準備）において、どんな観点で資料を作ってプレゼンしているのか複数の先輩社員に相談して伝え方を学びました。 ・試験計画を立てるときには、仕様書や定義書の中身をしっかりと把握した上で業務要件を満たす内容になっているかどうか気をつけました。

# 概要 ToC向けサービスのアプリログ、アクセスログを管理しているプラットフォームと運用保守におけるコスト最適化を行いました。 プラットフォームについては Elstic Cloud（以降：旧環境）からAzure Data Explorer（以降：新環境）内に構築したDBに移管作業を行いました。 運用保守では移行前の旧環境では運用保守契約を締結してベンダーに依頼していたが、移管後は内製で私がメインの担当として運用を行っております。 ※プロジェクト開始時点で移管先のプラットフォームはすでに決まっており、技術選定やPoCは含まれておりません。 # プロジェクトの流れ 1： 旧環境と新環境を並行稼働させ、初動確認として以下の観点でテスト項目表の一覧の作成と実施 - 格納されてくるデータの現新比較 - 格納されてくるデータのボリュームが一致すること 2：社内システムリリース承認会へ上程して説明 上長に旧環境の停止及び新環境への移行について承認をいただくための資料として以下の点をパワポにまとめて説明 - システム構成に関するAs-is/To-beの説明 - 初動確認結果の結論と初動確認プロセス - 旧環境の停止作業におけるリスクとその対策 - 旧環境のスケジュール、体制が準備できていること 3：旧環境の停止作業 - 停止作業手順書の作成、社内レビューの実施 - 停止作業 - 旧環境でのベンダーとの保守契約回りのクローズ連絡 # 担当範囲 - 全体スケジュールのマネジメント兼メイン実作業者 - 現新比較テスト項目の作成と実施 - 社内リリース判定会での説明 - ベンダーへの保守契約終了連絡 - 新環境でのログの管理、アラート機能の追加

# 概要 販促DMシステムの開発・運用 # 担当 新卒で入社し、開発運用業務を行っているデータエンジニアのチームに配属。 具体的には * スマホアプリの販促DMシステムの開発運用 →Azureによるデータ分析基盤のETLパイプライン(Azure Data Factory)やSalesforceなどを利用 * スマホのアプリで使用しているAPIのテストデータ作成 →SQL Server Management Studioを使用してテストデータの作成 * エンドユーザからの問い合わせ内容についてデータパイプラインやデータベースでのバグ・エラーの調査 →ETLパイプライン(Azure Data Factory)やSQL Server Management Studio、Azure Databricks を利用 などを担当しました。 # 課題 入社したタイミングが大規模改修直後で、バグが相次いでいました。メイン開発者であった先輩社員からしばらくの間引き継ぐことになりました。具体的な課題としては、 * 運用ドキュメントやテーブル定義書、ER図などがほぼ整備されていない * 本番環境のみしか整備されていない * 本番環境へデプロイ後に本番環境が想定通りに動くことで、初めて問題ないか判断するしかない状況 など、枚挙に遑がない状況でした。 # 取り組み * データ分析基盤にあるテーブルの役割やデータの定義を１つずつ紐解き、Azure Data Factoryにてパイプラインを構築するためを考え方を先輩社員に相談して勉強しました。 * テスト用アカウントへのテスト配信をするために、既存のパイプラインを利用してアクティビティやクエリの改修作業をしました。 * 配信DMの内容の構造をリニューアルするために、既存のパイプラインにおけるクエリの改修作業をしました。 # 工夫した点 * 業務の隙間時間にAzure全般の技術を勉強して良いか上司に相談し、目の前のタスクだけに囚われずに、公式ドキュメントを1から読んでクラウド技術の理解度向上に努めました。 * ステージング環境がないことにより、本番環境で障害を起こさないように業務に取り組むのはとても苦労しました。 引き継いだシステムの理解度を上げるべく、***「過去に作られたデータ分析基盤やパイプラインにおけるビジネス上の知見」***や***「全くコメントがないソースコードを読み解いて、複数人でコメント化してわかったこと」***など、知見を１つのプラットフォームで共有し合う体制を作り、チーム全体で１から新しい文化を作ることを努めました。

## プロジェクト概要 PDFビューワーアプリの新機能をAndroidおよびiOSで開発し、ユーザー要望に応える機能リリースを実現しました。 ## 役割・体制 ### 自身のポジションと役割 - アプリ開発エンジニアとして、上司から任された機能のAndroid版（Java）とiOS版（Objective-C）それぞれのコーディングとテストを担当しました。 - ユーザーからの要望を基に、仕様決定から実装、テストまで3ヶ月サイクルで複数機能の開発を継続的に実施しました。 - コード品質向上のため、コードレビューでの指摘事項をExcelで管理し、改善点を体系的に蓄積し再発防止に努めました。 ### チーム規模と構成 - 上司含むエンジニア3名の少人数チームで、各メンバーが独立して異なる機能を担当し分担して開発を進めました。 ## 背景・課題 - ユーザーからの具体的な機能要望に対応するため、既存のPDFビューワーアプリに新たなボタン機能などを追加し、アプリ内完結型の改善を目指しました。 - 転職直後でチームでのコーディング経験が不足していたため、コードレビュー指摘の繰り返しを防ぐことが課題となりました。 - 複数機能の同時並行開発において、品質を保ちつつスケジュール通りにリリースするための効率的な作業管理が求められました。 ## 実際の取り組み ### 開発環境 - AndroidアプリはJava、iOSアプリはObjective-Cを用いて開発し、両プラットフォームでの機能実装と動作検証を並行して行いました。 - アジャイル開発手法に基づき、3ヶ月の開発サイクルで仕様決定、実装、テストを繰り返し実施しました。 - Gitでのコードの管理とレビューを円滑に進めました。 ### 設計・改善内容 - 上司の設計仕様を忠実に実装しつつ、ユーザビリティを考慮したボタン機能を中心に新機能を開発しました。 - Excelでコードレビューの指摘事項（日時、内容、理由、レビュー者）を記録し、指摘の再発を防ぐ仕組みを自発的に構築しました。 - レビューの内容を体系的に蓄積することで、品質向上と効率的なコード修正を実現しました。 ### その他アピールポイント - ユーザー要望に応える機能のリリースにより、営業メンバーが新機能を活用した提案が可能となり、ビジネス価値の向上に貢献しました。 ## 成果・価値 - ユーザーからの機能要望を反映した新機能をリリースし、顧客満足度の向上に寄与しました。 - コードレビュー指摘事項のExcel管理による機能の品質改善が実現しました。 - 営業メンバーが新機能をアピールポイントとして活用できるようになり、営業活動の幅が広がりました。