400万人が利用する会社訪問アプリ

回路エンジニアからWebエンジニアへ

【基本情報】 在住: 東京都 最終学歴: 信州大学大学院総合理工学研究科(2016年3月卒) 出身: 群馬県 年齢: 33歳(1991年生)

この先やってみたいこと

未来

【仕事を通じて叶えたいこと】 ・人やモノの能力を100%引き出し、社会から無駄をなくす ・しくみで人の行動をデザインする

ENECHANGE株式会社 の会社情報

ENECHANGE株式会社 1年間

開発現在

- 現在

既存プロダクトの保守、運用、改修 - フレームワーク: Ruby on Rails、Vue.js - インフラ: AWS(Elastic Beanstalk、 ECS)

  • terraformを用いたElasticBeanstalkからECSへの移行

    【概要】 弊社のプロダクトは、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スクリプトを作成し、デモデータ作成を自動化した 結果 ・デモデータの作成コストを削減し、実装に集中することができた

    -
  • 採用 1次面接対応

    エンジニア面接において1次面接を担当した。 1年間で5名担当したが、残念ながら採用には至らなかった。 チームの求める人材とマッチするかを判断するために応募者の深堀りをする経験を得ることができた。

  • 既存アプリの保守運用

    【概要】 弊社のtoBプロダクトは採用企業ごとにリポジトリ管理され、それぞれが独自の機能を持っている。 メインの業務は各プロダクトの保守・運用で、具体的にはバックエンド処理の変更やキャンペーン時の文言改修である。 【チーム構成】 チーム構成は主に以下。 1人で複数のプロダクトを担当している。 ・PM 1名 ・エンジニア1〜2名(自身 + 業務委託エンジニア) ・QA 1名 【担当領域】 担当プロダクトのリーダーとして、以下の工程を担当 ・工数算出 ・設計 ・実装(案件によっては業務委託エンジニアのハンドリング) ・QA指示 【使用技術】 ・Ruby on Rails ・RSpec ・Vue.js ・PostgreSQL ・AWS ・・ElasticBeanstalk ・・ECS ・GitHub 【開発例】 ○ 要望に伴う画面表示や条件分岐の変更 ・該当箇所の絞り込み ・既存処理への影響が無いかを調査 ・要件に沿って変更 ○ 入力フォームの追加 ・Vue.jsで作られたフロントエンドにフォームを追加 ・DBのカラム値を追加 ・Railsで処理(バリデーション含む) 【運用例】 ・採用企業からのプロダクトに関するセキュリティ質問への回答 ・採用企業のメンテナンス作業に伴うインフラ対応 【課題】 ○ 属人化したプロダクトのドキュメントを作成 概要 弊社は5年以上続くプロダクトを複数持ち、それぞれが別リポジトリで管理されている。 新規にアサインされたエンジニアは機能を素早くキャッチアップする必要がある。 過去の事例やエラー対応に関する情報がslack上に散らばっていた。 解決策 ・NotionやGitHub Wiki上にドキュメント化した ・・自分が困った内容に関してドキュメント化を徹底した ・ドキュメント化したことをチーム内に通知した ・作成したドキュメントを元に会話することを意識した 結果 ・作業やエラー対応をURLベースで会話することができ、調査工数を削減した ・エンジニアだけでなくPMもキャッチアップできる環境を作った

園木 佑介さん

のプロフィールをすべて閲覧

過去の投稿を確認する

共通の知り合いを確認する

園木 佑介さんのプロフィールをすべて見る


企業からスカウトをもらいましょう