ID:52067さん

スクラム開発が導入されており、フロントエンド、アプリエンジニアなど含め10人ほどのチーム構成でした。業務内容としては以下の３つのサービスの保守・運用を主軸に、そこから派生したマイクロサービスの開発におけるバックエンド・インフラ領域を主に担当。 1. インフルエンサー向けのスマホアプリ 2. 広告主向けのウェブアプリ 3. 社内スタッフ向けのウェブアプリ ### 担当した業務例 - 社内スタッフ向けのWebサービスをRuby on Rails→NestJS・Prismaにリプレイス - SAMを使ったマイクロサービスの仕様策定・実装（関数にはGolangを使用） - プッシュ通知一斉送信サービス - ワードクラウドの自動生成サービス - AWS各サービスのバージョンマイグレーションを担当 - Amazon Auroraのアップデート（メンテナンスを伴う） - Amazon ElastiCacheのアップデート - コスト削減 - datadogにて不要なメトリクスの取得を停止。年間約60万円ほど削減 - 開発用のDocumentDBをMongoDBイメージのECSコンテナに置き換え。年間約6万円ほど削減 ## 特徴的なエピソード ### 1. 複数の役割を持ったモノレポを役割ごとの専用サービスにリプレイス CTOに仕様やコードレビューの依頼はしておりましたが、仕様策定から実装まで基本的に私一人で進行したプロジェクトです。 「DBマイグレーション」・「cronスケジュールタスク」・「非同期処理用のワーカー」と、3つの役割が一つのRailsプロジェクトにまとまっているリポジトリが存在しました。Railsにはそれぞれ便利なプラグインも用意されているので、これらが一つのリポジトリにまとまっていること自体は大きな問題ではなかったのですが、以下2点については早急に解決すべき問題であると考え、できる部分からリプレイスを進めていきました。 1. Rubyのバージョンが既にサポート終了済みであること 1. 加えて型のないRubyが真価を発揮できる開発フェーズは終わっていた 2. 唯一ECSではなくAWS OpsWorksで管理されていたこと 1. 自動デプロイの仕組みがなく、デプロイ履歴をスクリーンショットで残す必要があった（監査対応） 2. DBマイグレーションやスケジュールタスクなど、役割的に常にサーバーが起動している必要がないのに常に稼働している 技術的負債の返済よりも新しい機能の追加が優先される雰囲気が強いフェーズであったため、以下の順にスプリントタスクの合間を縫ってリプレイスを進めており、3に関しては現在進行中。 1. 非同期処理用のワーカー 1. 最新のRubyバージョンにしたワーカー専用のサービスにリプレイス。既存の複数のRailsサービスから実行されるワーカー群のため、そのままRailsを使用。 2. DBマイグレーション 1. CodeBuild上でDBマイグレーションを実行する専用サービスにリプレイス。併せてこのタイミングでインフラ定義にAWS CDKを導入（それまではCloudFormationを利用していた）。VPC外のCodeBuildからVPC内のDBにアクセスするためにNATGatewayを利用しました。 3. cronスケジュールタスク 1. ECS Scheduled Task を利用した専用サービスにリプレイス。既存のタスクはまずRubyのDockerイメージを利用してECS Scheduled Taskに移行。徐々にGolangに書き換えていく予定。 こういったタスクはビジネスサイドから見ると目に見えて変わることがないためつい後回しにされがちかと思いますが放置するわけにもいかないため、スプリントの隙間にタスクを入れ込めるようになるべく細分化し、最小限のコストになるよう心がけて使用策定を行いました。 ### 2. エンドユーザー間の紹介機能 仕様策定・バックエンド実装 PdM1名・アプリエンジニア1名・私という3名体制のプロジェクトでした。新規のユーザー獲得を推進したいという狙いのもと、ユーザー間の紹介機能を作成しました。私の役割としては仕様策定・バックエンド実装です。 機能としては、被紹介ユーザーがアカウント新規登録を行った上でプロフィールの初期設定を完了させると紹介が成立し紹介特典を送付する、というシンプルなものでしたが、不正な紹介が発生すると直接的に現金を失うリスクがあったため不正な紹介成立をどのように防ぐべきか入念に検討しました。 まずやったことは最大リスクの洗い出しとその対策の検討です。今回のケースの場合、一人のユーザーが異なる電話番号の携帯端末を複数所持している場合は、相互に紹介し合うことで不正に紹介特典を受け取れる可能性がありました。大量に携帯電話を持っている業者からの不正利用などは十分考えられたので、インフルエンサーとして審査通過できるSNSアカウントが存在しないと紹介特典が受け取れないようにするという仕様にすることで対策をしました。 一方で審査通過可能なSNSアカウントを大量に用意するというのはハックするのが困難、かつ既存の認証の仕組みを改変する必要があったため許容可能なリスクと判断しました。 技術的に特筆すべきことはありませんがリリース以降一度もバグを生んでいない、かつ、オペレーション上の大きな問題も発生していないため、リスク管理がうまくできた一例だったかと考えています。一バックエンドエンジニアではありますが、仕様策定・実装・テストケースの作成・ビジネスサイドとのオペレーションや仕様の擦り合わせなど全ての工程を通しで担当できた事例でもあるので、その点が私の特徴でもあるかと考えております。

歯科医院・歯科技工所向け、歯の詰め物の受発注管理システムの受託開発案件でした。 私は7名体制であったエンジニアチームの開発リーダーとして設計・開発業務を担当。6名中の3名は業界未経験入社の新人エンジニア、1名は本プロジェクトのディレクターと兼務しており、ディレクターとしての初担当案件でした。加えて開発期間は約4ヶ月間とのことで、とにかく納期までにクライアントの求める要件を満たすことを目標に取り組み、手戻りが発生しない仕組み作りに今までで一番頭を使ったプロジェクトでした。 私にとっても開発リーダーとしての初案件でしたので、まずは社内の他案件の成功事例を調査しました。安定した開発スピードを出せているプロジェクトには以下の2点の特徴があると考えました。 1. 質問をしなくても仕様把握可能なレベルのドキュメントが整備されている 2. バックエンドとフロントエンドのデータを受け渡すためのViewModel、シンプルかつ共通化が容易なRepositoryパターン 上記のようなものが当たり前の開発組織も多いかとは思いますが、これらが揃っておらず不明点が出るたびにコミュニケーションが発生するようなプロジェクトも散見されていました。個々人の純粋な実装スピードを上げるよりも、無駄なコミュニケーションを最小化することで結果として開発スピードを上げられた経験となりました。 2.に関して具体的には、以下のような構成で実装しました - フロント側では表示をするためのデータの加工が必要のないようにデータの加工をバックエンドで担当 - 全てのViewModelが最後は同じメソッドを通るようにし、返り値は同じフォーマットの配列に統一 - Repository層には1メソッド1クエリとなるようメソッドを作成、取得するリレーション先の情報は引数で渡すようにすることで処理の共通化に勤めた また本プロジェクトではBluetoothプリンタに接続した上での印刷機能も要件に含まれており、ハードウェアとソフトウェアどちら起因の問題なのか切り分けが困難であるという経験にもなりました。

官庁からの二次受け、中小企業と事業者をつなぐマッチングサービスの新規開発案件。 私はインフラ担当としてアサインされ、開発・ステージング・本番環境の初期構築からリリースまでのメンテナンスを担当しました。業務としてインフラを担当するのは初めての経験でしたので、インフラ構成を策定したものは別の者ですが、AWS各種サービス・Terraformを使ったインフラ構築、GitHubActionsを使ったCI/CDの実装を一名で行いました。 アサインされた時にはデプロイにはGitHub Actionsを利用することが決まっていたものの、社内では通常CircleCIを利用することがほとんどで、見本となるようなソースコードが社内に存在しませんでした。着手をなるべく早くすること、トライアンドエラーの結果を全てメモとして残していき効率的な消去法を愚直に繰り返すことで期限内にデプロイフローを含めた3環境（開発・ステージング・本番環境）を構築することができました。 またECSへのCD実行時にAWS SystemsManagerを使って環境変数を設定する手法を導入することでよりセキュアなCD構築をしたり、RDS(Aurora MySQL)への接続をSSL化させたりと、社内ではほとんど知見のなかった要件も上記のようなスタンスで取り組んでまいりました。

大手脱毛クリニックからの受注で来客時の料金シュミレータ新規開発案件でした。 ウォーターフォール型、3名体制のサーバーサイド開発メンバーとして参画。 管理画面はPHP/Laravel、エンドユーザー側の画面はnuxt.jsを使ったSPAのモノリポ構成。 DB設計、API設計、管理画面のサーバー・フロント両面の実装、API実装を担当しました。 管理画面のデザイン費は見積もりに含まないプロジェクトであったため、AdminLTEを導入し実装コストを抑えました。基本的には同期処理での実装がほとんどでしたが、一部料金設定フォームなどで非同期での表示切り替えを伴う箇所があったためVue.jsのcomponentとして切り出し非同期での表示切り替え処理を実装しました。 またエンドユーザー側の画面はSPAであっため、フロントエンドエンジニアとコンセンサスを取りながらAPIの使用を作成していきました。社内ではAPI仕様書を作成するフォーマットが決まっていなかった（API仕様書が存在しないプロジェクトもあった）が、少人数のプロジェクトということもありSwaggerUIを利用し必要十分と思われる仕様書を作成した。 その他、LaravelのRequest内で条件分岐を伴う複雑なバリデーションやBootstrapでのスタイル作成など、Webサービス開発にまつわる基礎的な経験を積無ことができたプロジェクトです。