【「自己推薦機能」提供終了のお知らせ】 2024年10月11日(金)に「自己推薦機能」の提供を終了いたします。詳細は**[リリースノート](https://job-draft.jp/release)**をご確認ください。

ID:70369さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


技術のスペシャリストになりたい

技術のスペシャリストになり、チームを助けながらものづくりを楽しみたいです。 プロダクト全体のアーキテクチャを考えたり改善したりしながらチームを引っ張っていける存在になるのが目標です。

年収評価シート

2023年/3ヶ月以内

オンラインコミュニティの運営者を守る機能の実装

# 目的・背景 - オンラインコミュニティ内のエンドユーザーの悪質、不適切な発言によって、運営者が疲弊し、コミュニティクローズになるケースが複数発生していた。 - 上記のようなメッセージを投稿しているユーザーをシステムが強制的に解約したと見えるように、管理者から削除の要請ができるようにしたい。 # プロジェクト概要 オンラインコミュニティ内での不適切なメッセージに対して削除を要請する機能、及び削除されない場合に自動で退会させる機能を追加しコミュニティ運営者を守る。 ## 担当 エンジニアとして1人で以下実装を全て担当 - DB設計 - バックエンドの実装 - APIの実装 - Sidekiqを用いた該当ユーザーの退会予約処理の実装 - フロントエンドの実装 - 削除の要請を行うモーダルの実装 - 管理画面での削除要請履歴の表示 ## プロジェクトのチーム規模 - エンジニア1名 - PM1名 - テスト担当者 4人 (カスタマーサクセス3人 PM1人) ## 仕様 悪質なメッセージに対して、管理者が削除を要請しそれに応じなかった場合24時間後にメッセージ送信者を自動で退会させる ## 工夫した点 ### 機能の実装を慎重に行い、テスト(Rspec)での品質の担保 ユーザーの退会を扱うこともあり慎重に実装する必要があったので、Rspecはかなり手厚く書きました。 該当するメッセージを削除しなければ24時間後にそのユーザーを自動退会させるという機能なので、あらかじめテスト観点を作成しておきそこからテーブルの追加 => Rspecでのテスト項目の追加 => モデル及びコントローラーの実装という順番で進めました。 以下のようなテスト観点を事前に細かく作成していました。 - 削除要請を行ったとき、メッセージ送信者、運営者にメール及びコミュニティ内での通知届くこと - 対象のユーザーが24時間以内にメッセージの削除を行ったとき退会させられないこと - 対象のユーザーが24時間以内にメッセージの削除を行わなかったとき退会させられること - 運営者が削除の要請を24時間以内に取り下げたとき、メッセージを送ったユーザーが退会させられないこと Request Spec、Model Spec、MailerのSpec、Sidekiqで非同期処理を行うWorkerに対するSpecを慎重に書くことを徹底していました。Timecopを用いて24時間後、24時間経つ寸前の状態を作り信頼できるテストを書いていました。 ### 削除要請されたことを履歴として残すことを考慮した設計 削除要請されたことを履歴として管理画面に残せることを考慮した設計を行いました。 メッセージが保存してあるテーブルと削除要請の履歴を残すテーブルの間に中間テーブルを作成することによって、該当する不適切なメッセージが削除された場合でも削除要請された履歴を残すことができます。 中間テーブルが残っていた場合は、削除要請された後、該当する不適切なメッセージが削除されていないという判定を行い、そのユーザーを24時間後に自動で退会するという要件を満たした適切な運用をすることができました。 ### メール配信の丁寧な実装 この機能で10種類メールを追加しました。これらのメールが不具合なく送信されるよう、Mailerのテスト(Rspec)の実装、非同期処理においてjobが積まれることを確認するSpecを丁寧に実装しました。 ### 慎重な動作テストの作成 カスタマーサクセスチームが行う動作テストを上記Rspecの元、PMと話し合いながら慎重に作成しました。 あらゆる操作を想定しスプレッドシートで数百行のテストを作成しました。 無事に全てのテストを通過しリリースすることができました。

2023年/3ヶ月以内

オンラインコミュニティの集客を手伝う機能の実装

# 目的・背景 - コミュニティ毎にPV数や流入経路の変化などのデータの可視化を行い集客に関する効果検証を行えるようにしたい。 - GAは活用ハードルが高く、使いこなせてない人が多いのでコミュニティ内の管理画面で月毎、日毎のコミュニティのPV数を見れるようにしたい。 # プロジェクト概要 各コミュニティの管理画面でトップページ( `/` )、概要ページ(`/about`)のPV数の変化のグラフを日毎、月毎に表示できるようにする。 # 担当 エンジニアとして1人で以下実装を全て担当 - DB設計 - バックエンド - 日毎、月毎のPV数を取得するためのAPI - AWS EventBridgeを用いてBigqueryから取得したPV数をS3にバイナリデータとして保存するバッチ処理 - フロントエンド - PV数をグラフにして表示する処理 # 使用技術 - Ruby on Rails - Vue.js - AWS EventBridge - AWS StepFunctions - Bigquery - AWS S3 # プロジェクトのチーム規模 - エンジニア1名 - PM1名 - テスト担当者 1人(PMが担当) # 実装内容 仕様:各コミュニティの管理画面でトップページ( `/` )、概要ページ(`/about`)のPV数の変化のグラフを日毎、月毎に表示する # 工夫した点 実装において以下のような課題がありました。 - 運営しているコミュニティは約130個あるため、膨大な量のページビュー(開いたページのパスや時刻やURL)がBigqueryに記録されていてそこから特定の期間のPV数をBigqueryからRailsで動いているサービスに読み込むと5〜10秒かかってしまう。 そこで以下のような方法で上記の問題を解決しました。 ## PV数を事前にキャッシュすることによってBigqueryからデータを取得したときの遅延を回避 解決策として、毎日午前0時に前日までのPV数をS3にキャッシュすることで解決しました。 定期実行にはEventBridgeとstepFunctionsを使用しました。 EventBridgeとstepFunctionsでECSコンテナを立ち上げRailsのrakeタスクの中で以下の処理を実行しました。 ① Bigqueryにコミュニティ毎に、日毎、月毎にデータを集計するviewを作成 ② 定期実行を行いRailsコンテナのrakeタスクからBigqueryのAPIを叩いて①のデータを取得 ③ ②のデータをrubyのハッシュの状態でバイナリデータとしてS3にキャッシュする グラフを表示するときは、RailsでS3からデータを取得してRubyのハッシュとしてデータを表示しました。 これによってコミュニティがオープンした日にちから、現在から1日前までの全ての日付のトップページと概要ページのPV数をグラフとして1秒以内に可視化できるようになりました。

プロジェクトカテゴリ
担当工程
経験した職種・役割
あなたが実際に使っていた技術
このプロジェクト詳細は公開されていません

マネージメント能力

アピール項目


アウトプット

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

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

# インフラ・CICD - 要件を満たし、コストパフォーマンスが最も高いインフラアーキテクチャを設計する技術力 - AWS SAA を取得した経験を活かし、非同期処理やバッチ処理を行うマネージドサービス、RDBやNoSQLやS3 などのDBストレージを適切に選定できるようになりたい。コストや要件に合ったアーキテクチャを構築できるようになりたい。 - 自動テスト、自動構文チェック、自動デプロイの仕組みを構築できる技術力 - テストの時間の改善なども積極的に行いたい - デプロイの仕組みもSDKを使うのか、orbsを使うのか、どうやったらより短時間で済むのかを追求したい。 - 本番環境、テスト環境をデプロイする仕組み、開発環境でのコードの変更を一時的に本番環境に反映できる仕組みを構築できる技術力 - 不要なコードを検知できる仕組みを構築できる技術力 - 似たようなファイル、使われていないメソッドなどを削除していき開発効率を上げることに挑戦したい。 # バックエンド - OAuth OICD のアクセストークンを提供する側の実装に挑戦したい(Railsの doorkeeper を使うなど。) - クライアント側よりも、認可サーバー側やリソースサーバー側の実装の方がより、クライアントIDとクライアントシークレットの発行するときにおけるセキュリティへの配慮、アクセストークンの乗っ取り対策、APIのバージョンの上げ方、ドキュメントの整備などエンジニアとして成長できるポイントが多くあると考えているため。 - PAY.JPやstripeを用いた決済機能の開発 - シンプルな決済だけでなく、サブスクリプション決済も実装できる力をつけてあらゆる要件の決済機能の実装を担当できるようになりたい - パフォーマンスチューニングの力をつける - AWSに集積したログやNew RelicやSentryなどの監視プラットフォームを駆使してボトルネックを特定でき、それを解消できるようになりたい - 自分以外の人が初めて読んだときにわかりやすいと感じるコードを書けるようになる - メソッドやクラスの命名、オブジェクト指向を考慮した責務の分割、デザインパターンの使用、コメントアウトの適用などを適切に行えるようになりたい。

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

メンバーの学習意欲、技術への好奇心が高く、チームみんなで助け合いながらものづくりできる環境

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
人材 / アダルト
その他の特徴
新しい技術はとりあえず試す
その他のやりたいこと・やりたくないこと

バックエンドの実装及び、将来的にはインフラの経験を積んで、プロダクト全体の技術構成をブラッシュアップしていけるエンジニアになりたいです。

やりたい事

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

基本プロフィール

年齢
今年で20代後半
好きな Text Editor
vscode
希望勤務地
東京都
希望年収
未入力
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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