ID:29768さん

2025年11月回 指名


まだ何もありません

あなたを気にしている企業

キャリアビジョン


DX(Developer Experience)を追求していけば良い製品をスピーディーに届けられるはずだ

エンジニアが良い製品を良い品質でスピーディーに作り続けたり、自己研鑽を続けるときに必要なのはDX(開発者体験)や楽しさだと思います。 地道なリファクタやパイプラインの整備やより良いアーキテクチャの導入などを取り入れていき、より製品そのものに注力できるようにすることをモットーにしています。 直近だとサーバレスというキーワードで技術習得をするのが良いアプローチだと信じて日々エンジニアリングをしています。

プロジェクト経験

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

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

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

2022年/2年以上

クレジットカードイシュアの機能開発運用

# プロジェクト概要 自社クレジットカードのイシュアリングを担うシステムの機能開発と運用。カード発行、決済、債権回収機能及び明細管理機能、ユーザー向け、社内管理者向け画面を、複数のスクラムチームでScrum of scrums体制で開発を行っています。 複数チーム全体のスクラムマスター及び、1チームのPdLを担当しています。 # プロジェクトにおける自身の役割 機能開発保守全般を行うと同時に複数チーム全体のスクラムマスターと1チームのPdLを担当しています。 基本は案件ごとに要件定義〜Delivery全てを1チームモブワークで行っていますが、案件によっては私自身がメイン担当者として、あるいは他のメイン担当者のサポートとして、レビュー全般を担っています。 # 当時の背景/抱えていた課題等 現在はScrum of scrumsの形をとっていますが、当初は大人数でスクラムを行っており、スクラムの形骸化やコミュニケーションコストの増加、また1チームで複数案件を取り扱うことによる認知負荷が大きな問題となっていました。 スクラムチームを複数に分割し、かつチームごとに担当するドメインを定義することでコミュニケーションと認知負荷のコストを下げました。 また、スクラムの原理原則の啓蒙を行い、アジリティのあるスクラム運用をすることができるようになりました。 スクラムチームが分割することによるチーム横断のディスコミュニケーションや実装箇所の競合等を防ぐための取り組みも行い、各自が並行して開発ができるようになりました。 # 課題に対して自身が発揮したバリュー及び成果 スクラムマスターとしてチーム分割を主導しました。 並列開発するためのCI/CDフローやルール整備を行いました。 それらの改善と機能開発のアウトプットを出し続けました。

2024年/3ヶ月以内

SRE Enablingチームへの留学によるインフラ・運用改善プロジェクト

所属する開発チームへFBする目的で、SRE Enablingチームへ3ヶ月間留学し、プロダクトチームのSRE力向上とシステムの信頼性向上に貢献しました。 元々前職での"何でも屋"での経験があり、基本的なインフラ業務のバックグラウンドがありつつも、色々な課題に直面した濃密な時間を過ごすことができました。 「プロダクトチームのSRE力を高める」というEnablingの役割を通じて、単なる技術提供ではなく「プロダクトチームの裁量領域を増やす」ことで事業貢献するというSREの本質を学びました。環境構築、SLO策定、可観測性向上、共通基盤整備を通じて、サービス信頼性を維持する仕組みの提供ができるようになりました。また、アジャイル手法の移行支援などチーム運営にも貢献し、開発経験をSRE # 主な実績 ## SLO策定とモニタリング基盤の構築 - 担当プロダクトのSLO/SLI策定を主導し、可用性・レイテンシ指標をDatadogに実装 - SLO管理用Terraformモジュールを改善し、アラートメッセージに運用シートURLを自動挿入する機能を実装 - Error Budget枯渇時のトラブルシューティング手順を自動化し、運用負荷を軽減 - 複数サービス(マイクロサービス構成含む)のパフォーマンス分析を実施し、SLO目標値を策定 ## 可観測性の向上 - CDNからDatadogへのログ転送基盤を構築し、可用性・レイテンシ監視を実現 - 高負荷サービスの可観測性を大幅に向上 - CDN連携からDatadog統合まで一気通貫で実装 ## 環境構築とEnabling活動 - 複数プロダクトの新規/追加環境構築を実施(staging/本番環境、EKS移行など) - タイトなスケジュールに対応するため本番→staging構築と逆順での実施を提案・実行 - 社内のIaC標準構成を習得し、実装 - プロダクトチーム単独で環境構築できるよう出口戦略を意識したEnablingを実施 ## 共通基盤の整備 - 負荷試験の共通方針を策定し、各プロダクトチームが迷わず実施できる仕組みを構築 - CI/CDパイプライン改善(kubectl認証問題の解決、kustomize動的インストール) - Fluentd設定拡張によるログ収集基盤のS3出力機能実装 ## 日常運用とインシデント対応 - 社内問い合わせチャンネルやアラート通知への日次対応を通じてプロダクトチームとの関係構築 - セキュリティインシデントの初動対応を実施 - 障害通知チャンネルの可視化推進によるインシデント認知改善

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

マネージメント能力

スクラムマスターとして複数チームのスクラム運用の整備
当初15人のエンジニアメンバーで1チームでスクラムを運用していましたが、チーム内コミュニケーションの複雑さや一部古参メンバーへの作業負荷の偏り、サービスの機能スケールに伴う認知負荷がネックとなり、技術や運用負債の取りこぼしや、ビッグバンリリースなど多くの問題が顕在化しました。 上記の問題を解決し、デリバリーや品質の問題に対しチームが健全に取り組める環境を作る必要がありました。
コミュニケーションや認知負荷に関する問題は1チーム内のコミュニケーションパスや関心の種類が多いものと考え、チームとチームが担当するドメインを分割するアプローチを取りました。 当初はLeSSを導入しスプリント内でのアプローチを取りましたが、そもそもサービスで取り扱うドメインが多岐にわたっていた為、スプリントレビューやレトロスペクティブでの認知負荷が下がらず、各メンバーや各チームにとって価値のあるものにならないことがわかりました。 そこで、Scrum of scrumsに切り替えて、情報集約のタイミングをボードメンバーだけに絞って会話することで解決することができました。 また、各チーム内でモブプロ、モブワークを行うことでチーム内の負荷や技術知識を平滑化することで、作業負荷の偏りを減らすことに成功しました。 Scrum of scrumsを取り入れたことでコミュニケーションパスや認知負荷や各チーム内のドメスティックな改善をすることができましたが、今度は各チームを跨いだメンバー間のコミュニケーションや技術知識の伝達が希薄になりました。 また、各チーム間の技術力の偏りも顕在化しています。 上記のような問題を解決するために、横断的に働きかけをするチーム内TLやEMを設置しようと考えています。

アピール項目


アウトプット

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

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

未入力です

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

未入力です

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
問題解決力 / 責任感 / 巻き込み力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
年収が第一
やりたくない分野
SI / ゲーム / アダルト
その他の特徴
使用言語にはこだわらない / レガシーな環境を改善できる / 新しい技術はとりあえず試す / 勉強会でLTをよくする / 多職種のバックグラウンドがある / stackoverflowで回答した
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で40代前半
好きなテキストエディタ
GoLand
希望勤務地
東京都
希望年収
1200万円
ご意見箱

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

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

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