ID:52067さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


自分の生活から「めんどくさい」と思うことを無くす

「めんどくさい」と感じるものは辞めるもしくは自動化して、前向きな活動にのみ時間を使っていきたい。

年収評価シート

2022年/2年以内

インフルエンサー・広告主マッチングサービス開発

スクラム開発が導入されており、フロントエンド、アプリエンジニアなど含め10人ほどのチーム構成でした。業務内容としては以下の3つのサービスの保守・運用を主軸に、そこから派生したマイクロサービスの開発におけるバックエンド・インフラ領域を主に担当。 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アカウントを大量に用意するというのはハックするのが困難、かつ既存の認証の仕組みを改変する必要があったため許容可能なリスクと判断しました。 技術的に特筆すべきことはありませんがリリース以降一度もバグを生んでいない、かつ、オペレーション上の大きな問題も発生していないため、リスク管理がうまくできた一例だったかと考えています。一バックエンドエンジニアではありますが、仕様策定・実装・テストケースの作成・ビジネスサイドとのオペレーションや仕様の擦り合わせなど全ての工程を通しで担当できた事例でもあるので、その点が私の特徴でもあるかと考えております。

2021年/1年以内

歯科医院向け受発注管理システム

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

2020年/半年以内

官庁案件・マッチングシステム開発

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

2020年/半年以内

脱毛クリニック料金シュミレータ

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

マネージメント能力

このマネージメント能力は公開されていません

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
未入力です
Zenn アカウント
未入力です
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
未入力です

今後、身につけなければいけないと思っている技術は何ですか?

- 高負荷なアクセスをさばくためのバックエンド開発・運用経験 - 英語の読解・会話

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

未入力です

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
調整力 / 問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
ゲーム
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと

スーツ着用で勤務したくない

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で30代中盤
好きな Text Editor
Visual Studio Code
希望勤務地
東京都 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
800万円
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
SIGN UPSIGN IN


転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?