園木 佑介

【概要】 弊社のプロダクトは、AWSサービスであるElasticBeanstalk（EB）環境上にデプロイされている。 しかし、EBはホストOSのEOLによるプラットフォームブランチの廃止や、Rubyのマイナーバージョンアップによる環境の作り直し、サービス自体のブラックボックス化など、課題が多いサービスである。 そこで、アプリのデプロイ先をECSに移行することでこれらの課題を解決した。 【チーム構成】 ・実装: 自分 ・アドバイザー: 先輩エンジニア 【どのように進めたか？】 弊社はAWSリソースをterraformで管理している。 今回のECS化にあたり、EBを構築しているterraformコードをECS用に変更した。 アドバイザーである先輩エンジニアにマイルストーンを用意して頂き、それを実現するための実装を自分がおこなった。 【課題】 ○ 初のterraform作業 terraformを用いた開発自体がはじめてであったため、まずはterraformに慣れる必要があった。 同時期に「EventBridgeSchedulerを用いてEC2を夜間停止する」「セキュリティグループを変更してIP許可リストを更新する」というチケットが発生したため、これを対応することでterraformの書き方を理解した。 また、弊社は機能の一部をモジュール化しており、そのドキュメントを読み込むことで機能を理解した。 ○ AWS知識の習得 terraformはAWSリソースをJSON形式で管理する。 既存のコードを読んで内容を理解するには、AWSの知識が必要になる。 本案件が走り出す直前にSAA C-03を取得していたため、必要なサービスの選定をすることができた。

【概要】 既存の電力申し込みサイトへの追加開発をおこなった。 開発内容は以下である。 ・サブドメインの追加 ・申し込みページの追加、出し分け ・パラメータ付与による処理の出し分け ・入力フォームの追加 ・既存Jobの出し分け ・CRMページの追加、出し分け 【チーム構成】 ・PM 1名 ・エンジニア 2名（自分、業務委託） ・QA 1名 【担当】 ・要件定義 ・工数算出 ・実装 ・・チケット管理 ・・インフラチームへの指示 ・QA指示 【課題と解決策】 ○ プロダクトに対する知識が不足しており、要件を理解することが困難であった 解決策 ・社内のプロダクトに関して知識がある人を部分的に巻き込んで開発を進めた ・調査内容と実装方針を全てGitHubのissue上でまとめることで、実装後にプロダクト知識のドキュメント化をしやすくした 結果 ・プロダクトの理解が進み、仕様の決定と実装をおこなうことができた ・GitHub Wiki上にドキュメントを作成し、プロダクトの属人化を解消した ○ 要件が決まりきっていないタイミングで実装を開始する必要があった 解決策 ・プロジェクトとしてはウォーターフォールであったが、機能（コンポーネント）ごとに細かくチケットを作成し進めた 結果 ・コンポーネントでチケットを切ることで、2人体制でも互いに影響なく実装を進めることができた ・PRレビューのコストを小さくし、開発を素早く進めることができた ・小さい単位で検証環境に反映し、QA, UATの効率を高めることができた ○既存のプロダクトであるため、既存機能に影響がない実装をする必要があった 解決策 ・既存処理を変更する際は丁寧に調査した ・RSpecで自動テストを書くことで、実装した処理が既存機能に影響がないことを確認した ・QAに対し、既存機能に影響がないことのテストをするように指示した 結果 ・既存機能に影響のない実装を完了することができた ○ 複数モデルをまたぐデモデータ作成の処理が煩雑であった 解決策 ・Rubyスクリプトを作成し、デモデータ作成を自動化した 結果 ・デモデータの作成コストを削減し、実装に集中することができた