job-history.md

職務要約

高専卒業後の2018年4月に<A社>に入社し、動画配信サービスのWebサイトおよびモバイルアプリ(iOS/Android)の保守・改善プロジェクトに従事
入社から2年程度は試験要員として試験観点、試験項目の作成および試験実施を担当
その後はフロントSEとして、新規案件や改修案件の要件定義、仕様調整、ベンダーマネジメントも担当

2022年7月に<B社>に転職し、受託開発の要件定義および開発に従事
入社から半年程度はOJTとして自社サービスのリプレイス案件を担当
その後はAWSを活用したサーバーレスWebサービス開発案件のコアメンバーとして要件定義、開発、テスト、リリース、保守を担当

職務経歴

◯2018年4月～2022年6月

勤務先名

A社

職務内容

大手配信事業者向け動画配信システムの保守・改善プロジェクトを担当
自社データセンターに設置した動画配信サーバーを利用して顧客が動画配信サービスを運営されており、
そのサービスのWebサイト/モバイルアプリに関する要件定義、仕様調整、試験、リリース、保守、問い合わせ対応等を実施

担当業務

• 要件定義
  顧客への要件ヒアリングや仕様調整の打ち合わせに参加し、顧客と直接コミュニケーションを実施
  また、フロントデザインを一新する際にはPrott等を利用してワイヤーフレームを作成

• 仕様調整
  顧客からヒアリングした要件を、仕様書としてまとめベンダーに発注
  その際に実現が難しい要件があった場合は顧客と都度調整

• 契約
  ベンダーへの発注契約の処理を担当
  見積依頼、契約書の内容調整、社内稟議等を実施

• 試験設計・試験
  仕様書を基に試験観点、試験項目を作成
  また、作成した試験項目に沿ってベンダーが開発したWeb/Appに対して試験を実施 定常的なWebの試験に関してはRanorexで自動化を実施

• 不具合管理
  試験で発見した不具合を管理し、都度ベンダーに修正依頼を実施

• 進捗報告
  フロントエンド担当として、進捗会議にて顧客に試験状況等の報告を実施

• リリース
  改修内容を本番環境へリリースする際のスケジュール調整や、リリース後の本番環境での試験等を実施

• 保守/問い合わせ対応
  運用時の不具合申告や問い合わせ対応を実施

環境/技術

• Linux
• MySQL
• PostgreSQL
• Ruby on Rails
• React.js
• AWS

◯2022年7月～2023年1月頃

勤務先名

B社

職務内容

学習塾向けの基幹システムを自社サービスとして提供しており、OSや開発言語が古くなったことなどを受けてリプレイス案件が発足、
上記案件に途中から参加し、メンバーとして下記業務を実施

担当業務

• 既存DBからのデータマイグレーション
  現行DBのデータをdumpし、Docker上にマイグレーション用DBを立ち上げ、Mybatis Migrationを使ってマイグレーションを実施
  リプレイスにあわせてDBのデータ構造も刷新したため、新旧データの紐づきを意識してマイグレーションSQLを作成

• 自社製フレームワークの習得
  現行の開発言語はRuby on Railsだったが、面倒を見れるメンバーがチームから減ってきたこともあり自社製フレームワーク(Java, Vue2ベース)に書き換えた
  自社製のため不明点があっても検索等で解決しきれるわけではなく、ドキュメントも十分に整備されている状態ではなかったため
  設計者に質問したり自分でソースコードを読むなどして習得に努めた

• 画面や各機能の実装
  現行のソースコードやstg環境での動作確認などを行いつつ、現行にある画面や機能を実装

• 開発支援
  案件に参加した段階ではあまり開発環境が整っていなかったため、CI環境の整備(Commit時に自動テストを実行)、開発用テンプレートを生成するGradleタスク作成、ドキュメント整備などを実施

環境/技術

• Java
• Vue2
• JUnit
• Tomcat
• Gradle, Groovy
• PostgreSQL
• Docker

◯2023年1月～現在

勤務先名

B社

職務内容

大手物流向け資材レンタルシステムを運用されており、そのシステムから取得できる各種データをAWS QuickSightを用いて可視化し、顧客に提供したいという要望があり
上記レポートを顧客に提供するためのWeb画面およびバッチ処理等を開発する案件を担当

• ログイン機能や権限による表示制御機能などを提供する画面
• お客様側で保有されているアカウント管理システムとQuickSightユーザーを連携するバッチ処理
  等

上記案件のメイン開発メンバーとして、要件定義、アーキテクチャ検討、技術検証、実装、テスト、リリース、保守を実施
(PM1人、開発1人(私)、インフラ/ネットワーク1人)
現在は保守継続中

担当業務

• 要件定義
  メイン開発メンバーとして案件の初期からお客様打ち合わせに参加し、要件定義を実施
  本案件ではお客様側でやりたいことがある程度固まっていたので、要件を聞き出すような形で要件定義を進めた

• アーキテクチャ検討、技術検証
  「サーバーレスでやりたい」というお客様の要望をベースに、AWSのどのサービスを使ってシステムを構築するかを検討
  Developer Associate資格を取得していたため(現在は失効)ある程度AWSサービスの知識はあったが、使ったことがないサービスも調査・技術検証した上でメリット/デメリット等を勘案しお客様に提案

• 実装
  お客様の希望で画面側はAngularを採用したが、経験がなかったため1からキャッチアップした
  また、認証/認可のためAuth0のトークンを受け取る処理を実装する必要があったが、
  認証/認可の実装やJWTトークンの取り扱いについても未経験だったため、こちらもキャッチアップして実装を進めた

• テスト
  PythonおよびAngularの自動テストを作成し、ビルド時に自動テストを実行するようにCI環境を整備
  手動テストについても、自社の規定で実装者以外がテストを実施する必要があるため、誰でもテストしやすいようにテスト仕様書を工夫して作成

• リリース
  本番環境の公開作業を実施
  現行の他システムからのデータ移行もあり、開発したバッチを使用して数万人規模のユーザーの登録を実施し、問題なく移行を完了

• 保守
  リリース後にも不具合修正や機能追加、調査依頼などの保守対応を実施
  自らが書いたコードの保守をすることで、設計が甘かった部分などを運用面から認識するなどの経験を得た

環境/技術

• AWS
  • S3
  • Lambda
  • API Gateway
  • CloudFront
  • CloudWatch Logs, Scheduler
  • CodeCommit, CodeBuild
  • QuickSight
  • Glue
  • Athrena
• Python
• Angular
• Jest, Pytest
• Auth0

◯2024年4月～現在

勤務先名

B社

職務内容

病院を退院する患者と在宅医療事業者をマッチングさせるサービスを開発するプロジェクトを担当
上記案件のメイン開発メンバーとして、要件定義、アーキテクチャ検討、技術検証、実装を実施
(PM1人、開発1人(私)、インフラ/ネットワーク1人)
現在は実装中

担当業務

• 要件定義
  メイン開発メンバーとして案件の初期からお客様打ち合わせに参加し、要件定義を実施
  本案件は、お客様側でやりたいことはあるにはあるがどのように実現するかは未検討だったため、お客様と一緒に実現方法について考えるような形で提案を実施

• アーキテクチャ検討、技術検証
  本案件も基本はサーバーレスの想定だったため、2023年1月～の案件を参考にしつつ本案件の要求を満たせるような構成を検討し提案
  使用言語については特に制約はなかったため、未経験ではあったがNuxt3のSSRを採用
  認証についてはAWS Cognitoを採用し、こちらもキャッチアップした

  また、今後関連サービスを次々と作っていく想定のためコードベースとなるものを作ってほしいという要望があり、
  汎用的に使えるコードベースについて検討をしたり、コードベースの意図や思想なども含めたドキュメントを残したりしている

• 設計/実装
  Nuxt3のSSRで画面およびAPIを実装
  PostgreSQLのRLSによる権限制御やアカウント毎の権限の設計、
  AWS Cognitoによる認証/認可の実装、メールによる二要素認証のためカスタム認証の実装なども実施

環境/技術

• AWS
  • S3
  • Lambda
  • CloudFront
  • CloudWatch Logs
  • CodeCommit, CodeBuild
  • RDS
  • Cognito
• Python
• Nuxt3, Vue3
• PostgreSQL
• Docker

自己PR

自走力、キャッチアップ力

B社に入るまではプライベートで少し触っていたPython以外の言語の経験がありませんでしたが、
入社してすぐにOJTとして自社製フレームワーク(Java, Vue2ベース)を使った開発をする必要がある環境に置かれました。
言語の基本的な部分は検索などで学習し、フレームワークに関する内容についてはドキュメントが整っていない中で
フレームワークの設計者に積極的に質問したり、できるだけソースコードを自分で読み理解することで習得を進めました。

その結果、1ヶ月程度でフレームワークを使用した開発をキャッチアップすることができ、基本的な画面であれば1人で実装できるようになりました。
これを成功体験として内面化し、以降のプロジェクトでも未経験の技術に対して恐れることなく積極的に学習し、提案に組み込んでいくことができました。
例えば2024年4月～の案件では未経験ながらNuxt3を採用しましたが、こちらは社内でも経験のある人がいなかったため公式ドキュメントを読むなどして1人でキャッチアップしました。

アーキテクト的な役割の経験

OJTの段階から、開発支援としてCIの整備や開発用テンプレート生成のためのGradleタスクを作成するなど、開発環境の整備を行いました。
また、B社での案件では「どういった技術を使い、どのAWSサービスをどう構成して要件を満たすか」について検討・提案を行う経験を積みました。
さらに、B社の2024年4月～の案件では「他サービス開発時に利用できるコードベース」を用意するため、どのような技術を採用するか、また別の技術等を採用することになっても差し替えがしやすい設計を心がけて検討を進めました。
これらにより、単にコーディングするだけでなく「他の人が開発・保守しやすいようにする」という意識・視点を養うことができました。

また、自分が作ったシステムに対して脆弱性テストや負荷テストなどを行われることにより、非機能要件に対する意識も強まりました。

自動テストの経験

A社では主に受け入れテストの観点でWeb/Appのテストを行っており、定常的なテストに関してはRanorexという有料ツールを用いて自動化を行いました。
また、Seleniumでのe2eテストも可能です。

B社では主に単体テストの観点でJUnit、Jest、Pytestなどを使って自動テストを作成・実施しました。
A社のころは開発コードに触れなかったので実現できなかったですが、B社ではテストピラミッドを参考に関数レベル・モジュールレベルの自動テストを多めに作ることができました。

リファクタリングやTDDについて興味があり、学んだ内容を日々の開発に活かしています。
(TDDそのものは実践できていませんが、TDDにおけるテストの意義などは把握しています)

顧客対応

A社ではフロントSEとしてお客様との定例打ち合わせなどに参加し、B社でも開発メンバーとして要件定義や仕様の調整などを行っておりました。
雑談やアイスブレイクはあまり得意ではありませんが、誠実に対応することを心がけており、
分からないことも煙に巻いたりせず素直に伝え、お客様と一緒に考えていくことで信頼・評価を頂くことができました。

静的型付け言語

PRになるか分かりませんが、静的型付け言語が好きです。
業務で主に使用している言語はTypeScriptですが、Elmを少し勉強したことがあるほか、最近ではGleamに興味を持っています。
動的型付け言語であるPythonでコードを書く際も基本的にはクラスは使わず、関数を定義したり型定義を書いたりしています。
静的型付け言語が好きな理由は以下です。

• 型情報が即ちドキュメントとなり、可読性が向上するため
• ビルド/コンパイルする段階で大体の不備を検知してくれて、仕様バグの発見に注力できるため
  → その結果、テストコードもドメインロジックに集中させることができるというメリットが好ましい
• 「状態を持たない」という特徴がソースコードの複雑性を下げることに一役買っているように思うため
  → 自然と自動テストしやすいコードになる

総じて、ソースコードを開発者が修正しやすい状態に保つ手助けをしてくれるパラダイムだと思っています。

希望するキャリアビジョン

大まかなキャリアプランとしては、管理職ではなくスペシャリストを目指していきたいと考えております。

その上で、第一にユーザー目線での開発をしたいと考えております。
現職も受託開発なので直接のお客様目線に立つことはある程度可能ですが、
私の場合は担当している2案件がどちらも「お客様のユーザー」(いわゆるBtoBtoCのC)にサービスを提供する案件となっています。
そのためお客様のユーザーとの直接の接点が乏しく、お客様からヒアリングも間接的であったり、お客様自身もそこまで詳しくないことがあり
サービスの本来のユーザー目線に立ちきれず、歯がゆい思いをすることもありました。
そのため、本当にターゲットとしているユーザー目線での開発ができる環境に身を置きたいと考えています。
機会があればDDDによる開発もしてみたいと思っています。

そもそもユーザー目線で開発をしたい理由としては、その方がユーザーが喜んでくれて嬉しいという点は勿論ですが、
ユーザーにとって使いやすいサービスであればサービスの利用が伸び、それに伴い自分が作ったシステムへのフィードバックの量も多くなったり、大量のセッションを捌く必要が出てくるなど特有の経験を得ることができ、それによってエンジニアとして大きく成長できると考えているためです。

また、可能であればチーム単位で開発できる環境にいたいと思っています。
現在担当している2案件はどちらも開発メンバーが私1人だけなので、裁量はあるのですが「本当にこれで良いのか」と不安になったときに相談しやすい相手がいないという課題があります。
言語やシステム開発の基本的な部分であれば社内の誰でも相談できるのですが、プロジェクト固有の話題やドメイン知識が絡む相談については他の人に相談しようとするとまず案件の説明からしなければならず、気軽に相談できないと感じています。
そのため、「1つのプロジェクトに一緒に取り組むチーム」を体験してみたいと思っています。
チームで1つのプロジェクトに取り組んでいるということは、1つのドメインに対して深く考えているメンバーが複数人存在しているということなので、話し合いや議論をすることでお互いに新しい知見を得たり、よりドメイン知識を深めるといったプラスの効果が得られるのでは、と期待しています。

以上