ID:23510さん

自己推薦一覧

自己推薦はありません

3年後の目標や野望


5年後に自分が作ったと胸を張っていえる、ユーザー数/売上の大きい最高のプロダクトを作る

エンジニアとして活躍し続ける/価値を出し続けることは現在の延長線で出来てしまう。 5年後振り返った時に、自分が作り上げたと思える最高のプロダクトがあり、大きな報酬を手にしている状態でありたい。

年収評価シート

2015年/1年以内

大規模イベント新規開発 サーバーサイドエンジニア

【プロジェクト概要(目的・人数・体制など)】 大規模イベント新規開発 サーバーサイドエンジニア ◾️サービス ブラウザゲームの名残を残すゲームで、インゲーム/アウトゲームの多くの処理はサーバーにもたせている。 それゆえ更新系のAPIが叩かれる数が非常に多い。 DBの負荷が高くなりがちであるため負荷対策が重要であり、また同一レコードへの更新が同時に走ることから排他制御を厳密に実装する必要がある。 ◾️人員 プロジェクト全体:50人 このイベントの開発体制 プランナー:1人 ネイティブエンジニア:2人 サーバーサイドエンジニア:2人 フロントエンジニア:1人 デザイナー:1人 ◾️イベント概要 チーム対抗で得点を競うイベント ミニゲームが3種類ほどあり、 ・ミニゲームを通してビンゴを開ける ・ドロップしたアイテムを組み合わせて使用する ことによってポイントを獲得。 ◾️開発規模 期間:3ヶ月 テーブル数:約40テーブル サーバーコード量:約2万行(自動生成を除く) 【プロジェクトにおける自身の役割】 サーバーサイドのリードエンジニア 一部バッチの実装を除き、 テーブル設計、実装、単体テスト を全て担当 【当時の背景/抱えていた課題等】 同一のレコードを多数のユーザーが同時に更新する処理が頻繁に行われることにより ・負荷軽減 ・排他制御 が重要であり課題が多く発生した。 負荷軽減のためにユーザーデータはmemcachedを使っていたが、排他制御の処理のタイミングによりmemcachedとDBのデータ不整合が発生するケースが多発した。 また、ほぼ同時にAPIが叩かれた際に後に叩かれた方のAPIの処理において、先に叩かれたAPIの更新結果ではなく更新前の値を参照して処理をしてしまう不具合が発生した。 【課題に対して自身が発揮したバリュー及び成果】 ・多数のユーザーが同時更新するテーブルはmemcachedを使わず直接DBを参照するように変更 memcachedを使うと参照/更新タイミングを厳密に管理する必要が発生するため、実装が複雑になってしまった。 他のエンジニアが今後触る際不具合になりうる可能性も考えて、実装をシンプルにするために直接DBを参照する設計に変更した。 その代わりユーザー自身しか更新しないテーブルはmemcachedを使用して負荷の軽減をはかった。 ・処理冒頭でselect for updateで更新で値を取得することで、タイミングによって参照データが変わる問題を潰した 処理の中で取得したタイミングを考慮しなくて済むよう、冒頭でselect for updateでの取得することにした。 これにより同時に処理が走った場合でも、先に処理された方が更新した値を確実に取得できるため、排他制御によるデータ不整合は起きない。 その分ロック待ちの時間が長くなりユーザー体感が悪くなる可能性があるため、更新処理は出来る限りチューニングして短くなるよう実装した。

2016年/2年以上

GvGゲーム レイテンシ60%改善/エンジニアリーダー、開発ディレクター

※エンジニアリーダー、開発ディレクターは別セクションに譲り、ここでは技術的挑戦で一番大きかったものを紹介 これ以外にも大型開発を多数実施。 【プロジェクト概要(目的・人数・体制など)】 最大25 vs 25の計50人で戦うとGvGがメインのカードゲーム。 ヘビーユーザー同士(参加人数、行動回数が多いチーム同士)の対決では、レイテンシがかなり高くプレイ体感が悪いことが発覚し、調査及びレイテンシ改善を行った。 その結果、最大約60%のレイテンシ削減に至った。 【プロジェクトにおける自身の役割】 原因の調査、分析 チューニングのための実装 評価 【解決までの流れ】 ■調査 ○New Relicでボトルネックの調査 本番のAPIサーバーに仕込んでいるNew Relicをもとに、レイテンシが高い時の各処理の所要時間を計測。 レイテンシが高い時の所要時間99%はロック待ちだった。 ロック待ち時間が肥大化したことによって、行動数の多いGvGではレスポンス速度が悪化していたことが推測された。 ○待ち時間行列モデル(M/M/1)による検証 上記ロック待ちの仕組みの置いて、ロック中の処理時間と平均レイテンシの関係は待ち時間行列のM/M/1モデルを適用して検証した。 待ち時間行列のM/M/1モデルとは、1つしかない窓口にお客がランダムに到着した場合の、 ・お客の到着する頻度 ・窓口での処理時間 を元に、平均の待ち時間を算出するモデル。 M/M/1モデルをGvGのロック待ちの仕組みに適用すると 単位時間当たりに到着するgvgのリクエスト数:λ 単位時間当たりにサーバーが処理するリクエスト数:μ として、平均のレイテンシ(W)は W = 1/ (μ - λ) で計算できる。 これをグラフ化し数値検証したところ、 ロック中の処理時間を20%改善すればレイテンシは最大70%改善することが分かった。 そのため ・ロック中に行う処理を減らす ・ロック中の処理を高速化する を行うことにした。 ■取り組んだチューニング ○ロック中に行う処理を減らす 必ずしもロックが必要ない処理(排他制御をしなかったとしてもデータの整合性が崩れない)のみで構成されるAPIを洗い出し、ロック処理を削減した。 インゲームにおけるリクエスト数の25%を占めるAPIのロック処理を削除することができた。 ○ロック待ちの間に、ロックが不要な計算を始める ロックを取得した後に各種データを取得・計算をすると、どうしてもロック中の処理は長くなる。 ロックを取得した前後で計算結果に差がない処理を抽出し、ロック取得前に処理を行うようリファクタした。 ○アベイラビリティゾーンの統一(インフラ) もともとAPIサーバー、Redis、MySQL全てアベイラティビティゾーンを半分つずつに分けて2つのアベイラビリティゾーンに配置していた。 APIサーバーごとのレイテンシを確認すると、存在するアベイラビリティゾーンによってレイテンシにばらつきが確認された。 それぞれのアベイラビリティゾーンに存在するAPIサーバーにNew Relicを入れて検証したところ、逆ゾーンに存在するRedis、MySQLへアクセスする際レイテンシが高いことが分かった。 これを受けて、API、Redis、MySQLのアベイラティビティゾーンを全て片側に寄せた。 各MySQLのレプリカを全て逆のアベイラティビティゾーンにおくことで、データの信頼性は担保した。 この対応でGvGのletencyが改善しただけではなく、ゲーム全体のレイテンシが平均10%程度改善したり、一部バッチの処理時間が1/3になったりなど、ゲーム全体として大幅な改善が見られた。 ○テーブルのindexの見直し、不要レコードの削除 不要に貼られたindexが多かったため、精査の上削除した。 更新処理におけるindexの更新時間を少しでも短くするために行った。 ○Auroraの導入、統合(インフラ) 過去の負荷対策によって、4台に水平分割していたGvGのDBを1台のAuroraに集約した。 書き込み処理が多かったためAuroraと相性が良く、同じ費用で更に処理性能の高いものに変更できた。 同じクエリのレイテンシを比較しても、Aurora導入前より改善されていた。 ○遅い処理の探し出し、チューニング 上記のような抜本的な改修と合わせて地道なリファクタリングも行った。 長年の運用開発が積み重なった結果、効率の悪い検索ロジックやや不要なDB参照をしている箇所がいくつか見受けられたため、 計測→リファクタリング→計測を繰り返し、を改善を行った。

2019年/1年以内

リリース直前の負荷試験〜運用中ゲームにおけるエンジニアリーダー

# ①リリース直前で負荷試験 リリース直前で負荷試験の進行に問題があることが発覚し、状況を改善すべく役員に呼ばれ参画。 今までのプロジェクトの負荷試験経験をもとに、 - リリースまでに担保すべき負荷試験のパターン(スパイク試験、長時間試験etc)の整理 - サービスが担保すべき負荷試験の数値の策定 - 負荷試験実施スケジュールの策定 - 有識者を呼んでの進捗/試験結果の精査 を推進し、リリースまでに負荷試験を間に合わせた。 # リリース後の不具合/障害対応 サービス運用経験のあるメンバーが少なかったため、障害対応や不具合の調査の取りまとめ及び実行の推進を行なった。 # リリース後の大型機能開発のリード 開発期間2ヶ月、バックエンド3人体制の大型新機能追加においてテックリードを担当。 技術的設計要素: - 多人数系による厳密な排他制御(メイン実装担当) - テーブル数:20 リリースが間に合わない状況から、不具合の出にくい設計と工数が膨らむ要件のプランナーとの調整を行い、無事リリースに間に合わせ、不具合がほぼ起きなかった。 # エンジニアリングマネージャー就任 それまでのエンジニアリングマネージャーが異動になったため、エンジニアリングマネージャーに就任。 それまで弱かったプランナー/事業責任者との連携を強め、よりエンジニアチームが事業にコミット出来る状態にしていった。

2020年/半年以内

新規ゲームにおけるカスタマーサポート向けログ基盤開発/ リリース後機能開発、本番対応etc

※リリース後に行っている業務は上2プロジェクトと似ているのでここでは割愛。 下記はリリース前に行なった一番大きな対応の紹介 リリース後にカスタマーサポートのお問い合わせ調査で - ユーザー行動ログの調査 - ユーザー状態確認 が必須となる。 それまでリリースされたタイトルではバックエンドエンジニアが調査を担当することも多かったが、リリース後のユーザー規模的にバックエンドエンジニアでは対応不可能であることが見越されていた。 非エンジニアでの調査が出来る環境と継続な調査環境改善を実現すべく、 - 調査ツールに必要な内容の要件定義 - バックエンドの実装とログ基盤を鑑みたカスタマーサポート用ログの設計/実装 - redashを用いた調査環境の整備 - 調査用クエリの実装 - CSエンジニア(クエリ調査)の採用と育成 を一貫して行なった。 結果リリース後カスタマーサポートチームだけでお問い合わせ調査をほぼ裁くことができ、その後追加が必要になったクエリはCSエンジニアで完結出来るようになった。 バックエンドエンジニアは開発に集中できる環境になり、チーム全体の生産性向上につながった。

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

マネージメント能力

- エンジニアリングマネージャー① - メンバー:5人 - 期間2年(新卒2年目-) - 開発ディレクター -メンバー:10人 - 期間1年(新卒3年目-) - エンジニアリングマネージャー② - メンバー:5人 - 期間1年(新卒5年目-) - QA責任者 - メンバー社内4人、外部20人 - 期間半年(新卒6年目)
# エンジニアリングマネージャー①、② ## 役割 - エンジニアリングチームのマネジメント - コード/サービスの品質担保(テックリード) 自身もコードを書きながらのプレイングマネージャーとしての # 開発ディレクター ## 役割 - 各リリースタイミングごとの開発物の決定(事業責任者とのすり合わせ) - ガントチャートを利用した進行管理、遅れた場合の調整と意思決定 - リリース作業の統括(クライアント、サーバー、QA) エンジニアリングマネージャー①と兼任 # QA責任者 ## 役割 - エンジニア/QA間での認識合わせ/情報共有フローの構築 - QA計画の立案 - QA計画の実施
# エンジニアリングマネージャー① ## 直面の課題: ①エンジニアリングマネージャーとしての信頼確立 ②サービスの品質担保 ## 考えと対策: ### ①エンジニアリングマネージャーとしての信頼確立 #### 課題: 自分より全員10歳以上年上のエンジニアのチームでエンジニアリングマネージャーに就任。 経験の浅い若手がリーダーになったと見えていたようで、あまり信頼されている状態ではなかった。 自分がチームとして正しい意思決定を行い、遂行出来る状態を目指した。 #### 対策: ##### ・メンバーと普段から徹底的に話す マネジメント以前に、人間同士としてある程度信頼関係がある状態が必要と考えた。 ランチにたくさん行く、毎日雑談を話しかける、相手がやっているスマートフォンゲームを自分もやって話しかけに行くなど、地道に話す接点を増やし続けた。 ##### ・根拠のある意思決定の提示、間違っていなければ絶対にぶらさない 意思決定をメンバーに伝える場合は、その意思決定がなぜ妥当なのかを必ず説明するようにした。 なりでやってこなかったこと(レガシーな実装の仕方やテストを書かないなど)は、雰囲気に押されそうな曲面でも必ず断り、決めたことをやってもらうようにした。 ### ②サービスの品質担保 #### 直面の課題: ・コードの品質が低く、レビューで良くなる環境になっていない ・単体テストがほとんどない(ゆえに肥大化したメソッドが乱立している) ・本番環境で不具合/障害が頻発する コードの品質担保とサービスの品質改善を目指した。 #### 対策: ##### ・徹底的にコードレビュー デザインパターンやリーダブルコードで基本とされている内容を徹底的にコードレビューで書いた。 必要あれば席まで行って説明しにいった。 ##### ・単体テストの推進 仕組みだけは存在していたので、リファクタ時にメソッドの切り分け、テストを書くことを推進した。 「こういう風にやるのが良い」を伝えるためにも、参考になるようなプルリクを出すようにした。 ##### ・インフラ構成/実装設計の見直し 事業責任者やインフラチームを巻き込んで障害に強い設計に変えるための手順立て、工数の確保を行った。 機能開発だけで工数が一杯になていたところから、保守性の向上のための工数を取れるようにした。 # 開発ディレクター ## 直面の課題 開発ディレクターが突然不在になった後の、開発チームの再構築 ## 考えと対策 開発ディレクターはビジネス職のメンバーが担っていたが、急遽移動になり不在になった。 残ったメンバーから開発ディレクターを出す必要があり、バックエンドチームのエンジニアリングマネージャーと兼任する形で立つことになった。 兼任である以上以前のようなマイクロマネジメントを開発ディレクターとして担保することは困難。 - 自分が一番コミットするのは最上流の意思決定と全体の進行/品質担保 - 各セクションの業務は各セクションのリーダーにより移譲する 方針で進めることとした。 その分全体の進行と品質担保には強くコミットするようにした。 結果エンジニアが開発ディレクターをやっている利点も作用し、以前よりプロダクト改善開発のリリース物量が2倍以上に増え、機能開発に止まらない開発チームになっていった。 # QA責任者 ## 直面した課題 - プランナー/エンジニアとQAが連携できていない - 情報共有すらままならず、お互いに不信感がある状態 - 開発ワークフローが構築/定着されていない - QA状況がチームから見て見えてこない 状況を改善するべく、QAの責任者として入ることになった。 ## 対策 ### 徹底的に情報を集約 / 開示 - 開発物の共有 - QA必要項目/観点のすり合わせ - その後開発からQAスケジュールの確認 を行うmtgを全開発機能に対してやり直し、QA/他セクションが認識あっている状態を作った。 ### QA状況の開示 他セクションから見て欲しい情報を洗い出し、デイリーで開示できるスプレッドシートを構築。 毎朝の共有ができる状態にした ### 開発環境のフロー整理 QAを行うにあたり - 開発物の開発状況 - クライアントのビルド - サーバーの環境 - 各種データ/アセット状況 がちぐはぐなまま進行していた。 QAを開始できる状態定義を行い、全て満たしている場合QA着手を行うフローを整理した。

アピール項目


アウトプット

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

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

# Golang ビジネス要件を満たした開発を行うだけであれば今まで使ってきた技術で十分だが、近年の新卒の指向性として、比較的新しい言語、特にGolangでやりたいという話が非常に多い。 優秀な新卒を獲得してくエンジニア組織を作るためにも、組織が技術セットを更新していくのが大事だと思う。 そのためにはまず自分が積極的に学習して使いこなせている状態が望ましい。 # AWSを活用したインフラの構築スキル バックエンドがほぼクラウドになって久しく、コードベースでインフラが記述できるようになってきた。 バックエンドエンジニアとしての技術・専門性を伸ばすことを考えた時に、インフラエンジニアが担ってきた領域も自身で出来るようにしていく必要がある。 個人開発で積極的に使うようにしているが、より普段の業務でも使っていく必要があると感じている。

エンジニアとして影響を受けた本を教えてください

未入力です

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

現場での意思決定が主体的に行われ、スピード感を持って組織が前に進んでいる環境

キャラクター

直近で一番やりたいこと
現場にいたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
問題解決力 / 責任感 / 経営判断力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
風通しの良さや意思決定ライン
やりたくない分野
未入力です
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 勉強会でLTをよくする / 趣味は仕事
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

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

要望、不具合報告、使いづらい点や感想など、なんでもお気軽にご連絡ください。

ID:23510さん
今年で20代後半
Visual Studio Code
参加ステータス
不参加
参加回数
2回
累計平均提示年収
751 万円
SIGN UPSIGN IN


このサービスを友人に薦めたいですか?