suzushin

自己推薦一覧

自己推薦はありません

3年後の目標や野望


世の中の人を幸せにするサービスに携わりたい

SIerに在籍していた頃、巨大でモノリスなシステムのせいでユーザ企業もSEも、みんなが不幸になっている現場をいくつも経験した。上流工程の決定を覆すことは困難で、誤った道でも現場の人間は進むしかない世界だった。ITは人を幸せにするためのものだと思い業界に入ったため、とてもショックだった。 そういった経験から、人を幸せにできるシステムに携わりたい、もっとエンジニアリングを学んで正しい道に導けるようになりたいと思うようになった。事業会社に転職し、マイクロサービスアーキテクチャの推進などに携わったが、依然としてエンジニアが単なるコマのように扱われるような場面にも遭遇する。そのため、もっとエンジニアとしても人としても強くなり、「この人が言うなら」と思われるようになりたい。 そして、技術の力で世界中の人々を幸せにすることができるサービスに携わりたい。

年収評価シート

2023年/2年以内

自社システム開発(シニアソフトウェアエンジニア)

4社目:フードテック企業 ## 概要 - チーム2人目、部署5人目のSWEとして入社 - 当初はECサイトのリアーキテクチャ担当だったが、その後は何でも屋に - 事業のコアドメインが自社開発の食品であるため、他部署のIT活用 (DX) の方が ROI が高く優先度も上だったため ## 担当業務 ### ECサイト - 機能開発、運用保守、開発フロー改善(※ 詳細欄に後述) - 業務委託マネジメント、既存メンバーのサポート - リアーキテクチャ検討、PoC作成、調査 ### エンジニア採用・チームビルディング - 仕組みの整備、実施(※ 詳細欄に後述) - チームビルディングのワークショップを開催、スクラムの導入 ### 社内DXシステム開発 - 研究開発部門などの工程管理、商品管理が Spreadsheet では限界を迎えたため内製化 - PjMしかいなかったため、アーキテクトとして参画。実装のみ業務委託に依頼(フルタイムの人のみ採用) - 基本設計、アーキテクチャ選定、詳細設計レビュー、コードレビューまで担当 ## 詳細 ### 課題 ECサイトの技術的負債 過去数年間に渡り、事業の成長のみを優先した戦略が取られていたため、技術的負債が積み上がっていた。 複数の副業の開発者にチケットを配り、それを社員が管理するという、リソース効率のみを考慮したシステム開発が行われていた。 - その結果、起きていたこと - 継ぎはぎのモノリスなシステムとなっていた - オーナーシップを持ってシステムを見ている人がいなかった(Lint無視、狼アラート恒常化、ビルド最適化がされていない ...etc) ### 施策 通常開発+マネジメント+リアーキテクチャの全てを既存メンバーと2人では無理と判断。 人を増やすことを優先した(バス係数を上げる) - エンジニア採用に注力 - エントランスブックの作成、外部公開、面談トークスクリプトの整備、JDの細分化と見直し、構造化面接の質問集の整備 ...etc - 週に3~5件程度のカジュアル面談実施、複数件の面接実施 - 開発者体験の改善・向上 - 販売チャネルの1つとしての EC ではなく、プロダクト開発の提案を行なった - オーナーシップの醸成や社内委託感の低減、根本的な価値提供を行える開発組織を目指すため - Team Topologies を参考にしたチーム体制の提案や役割の整理 - 「作らない開発」への転換。定期的に発生するキャンペーンや商品追加のたびにエンジニアが手を動かさなくても済むように - トイル撲滅運動。御用聞文化を無くす。他部署から依頼を受けて都度操作していた作業を画面やツールから実施できるように - チーム開発への転換 - エンジニアが増えてきた段階でチーム開発を提案 - スクラムの段階的導入 - チームビルディング - オフラインで偏愛マップやドラッカー風エクササイズで相互理解を深める会 - インセプションデッキ作り、スキルマップ作成 - コミュニケーション施策の実施 - 雑談会、Gather.town 導入、横の1on1実施 - Go + GraphQL で PoC 作成 - 膨大な参照系エンドポイントを減らす方策として実施 - PoC として作成したものの、Nuxt 2と既存の npm module が古いため課題が残り、Next.js 化を優先することとした - Next.js 化 - Nuxt.js 2系の EOL が迫る中、副業エンジニアが1人で移行作業していたプロジェクト - 停滞していたため課題管理や進捗管理など巻き取りハンドリング。 専任メンバーをアサイン - また、レンダリング戦略が誤っていたため検証し、軌道修正、2024/07 無事にリリース ## 成果 - ECサイト開発チームにおいては、理想的な開発環境・開発者体験の認識が取れるようになった - 進行している Next.js 化と合わせて、日々議論できるようになっている - エンジニア採用においては、半年でバックエンド2人、フロントエンド1名、インフラ1名の採用につながっている - 上記成果はもちろん自分の施策だけではないが、エントランスブックやスクリプトは特に好評で、社内外でわかりやすいと評判 - 社内DXシステムは、業務委託メンバーと1つ目のシステムを完成まで漕ぎ着けている

2021年/1年以内

モバイルオーダーサービスのリプレース(テックリード)

3社目: OMO事業会社 ## 概要 - 稼働中のモバイルオーダーサービスのリプレース - 並行して開発された新プラットフォームを利用した Go言語によるリライト - バックエンド2名、フロントエンド2名、アプリ1名のフィーチャーチーム ## 担当業務 - 設計 - ドメイン駆動設計の戦略的設計を企画・主導 - 作りは現行踏襲を基本としながらも、課題となっていた箇所の設計は改善 - Design Doc, ADR の整備、技術選定など - 議論の余地のある設計パターンなどは他チームのアーキテクトやVPoEと相談しつつ方針決め - 実装 - ドメイン駆動設計の戦術的設計に基づき実装 - チームで数少ないGo言語の経験者としてバックエンド開発を主導 ## 詳細 ### 課題 開発組織としてドメイン駆動設計を基本方針として実践して行くことが決まっていたが、経験者がチームにはいなかった。 (自分自身は勉強会や書籍等により知識は持っていたが、その時点で実践経験まではなかった) ### 施策 #### 戦略的設計 - 『ドメイン駆動設計 モデリング/実装ガイド』の輪読会・勉強会をチームで実施 - ドメインエキスパートとしてカスタマーサポートのマネージャー、PdM を招集、ドメインモデリングを実施した(オフラインではホワイトボード、オンラインでは miro で実施) #### 戦術的設計 - 設計パターンをもとに PR を作成、モブレビューによりコンセプトの説明を行い、チーム内で技術レベルの平準化を図った - 立ち上がりのコストを下げるためにモブプロ・ペアプロを実施 - 外部の技術アドバイザーとの定期設計相談会にメンバーを巻き込み、議論を進めた ### 成果 - 1stリリースとして定めたマイルストーンまでに、動作するMVP(プロダクト)をリリースした - Go言語でバックエンドの開発ができるメンバーを3人に増やすことができた(バックエンド2名+アプリエンジニア1名) - 定期設計相談会をもとにDDDの書籍の輪読会がスタートし、継続している - https://showcase-gig.connpass.com/event/241338/

2020年/半年以内

モバイルオーダーサービスの会員管理システム開発(テックリード)

3社目: OMO事業会社 ## 概要 - モバイルオーダーサービスの会員管理システム開発 - 設計から開発初期フェーズは1人で担当し、その後の開発はチームに展開した ## 担当業務 - 要件をもとに技術選定、基本設計(Design Doc作成) - 詳細設計書、APIドキュメント整備 - 開発環境の整備から各種機能の実装、テスト ## 詳細 ### 課題 (1) 当該機能がビジネス要望として高く、素早く要求を満たしてリリースすることが求められた ### 施策 - ユーザ管理および認証に Amazon Cognito を採用 - Feasibility Study を行い、実現可能性および要求を満たせることを確認して選定 - マネージドに寄せることで認証処理やトークン発行、メール送信などの実装コストをカットした - 認証認可については事前学習を行い、要求と設計のすり合わせを行いつつ進めた - 新規の機能開発として起こりがちな QA やスプリントレビューでの手戻りを削減した - オーバーエンジニアリングの防止 ### 成果 トラブルなく、設計開始から約3ヶ月で機能リリースを実現した ### 課題 (2) 開発部門の方針として PHP から Go 言語への転換が求められていたがチームには実績が無かった ### 施策 - プロダクションレベルの Go 言語経験者がチームいなかったため、別チームの経験者とペアプロを実施 - アーキテクチャやミドルウェアの選定などを行い、今後の開発の雛形を策定 - チームメンバーも開発に合流しやすいように参考となる基本機能の実装を行った後、モブプロでチーム内に展開した ### 成果 - ツールなどを除くと、社内で最初の Go 言語によるサービスのリリースを達成した - チームメンバーも Go 言語での開発、コードレビューが行えるようになった

2019年/2年以内

モバイルオーダーサービスおよびそのプラットフォームの開発

3社目: OMO事業会社 ## 概要 - 飲食店でスマートフォンから注文できるモバイルオーダーサービス、およびそのプラットフォームの開発 - 2019年4月にバックエンドエンジニアとして参画 - 2020年1月からプロダクト開発チームの Tech Lead として、プラットフォームチームとの横断的な課題解決やエンジニア採用にも参加 ## 担当業務(入社後〜ローンチまで:2019/04 〜 2019/07) - 入社時は設計が完了し、実装・単体テストフェーズ - 要件・仕様のキャッチアップ後、機能開発および自動テストを担当 ## 担当業務(ローンチ後:2019/07 〜 ) - プロダクト開発チームにて、バックエンドを主軸になんでも屋 - フロントエンドはそれまで未経験ながら、Vue.js, React をキャッチアップして改修タスクは担当 - 人員拡大フェーズであったため、オンボーディング資料の整備やモブ / ペアプロの開催、採用面接の参加など ## 詳細 ### 課題 (1) 継続開発のための技術的負債解消 - Fat Controller かつトランザクションスクリプトによる実装が多かった - 可変関数などによる黒魔術的な実装が存在していた - 設計手法や原則、アーキテクチャに明るい開発者が少なかった ### 施策 - 可変関数などによる黒魔術的な処理をはじめとした可読性の悪いコードをリファクタリング - 単体自動テストを追加し、カバレッジを計測、掲示した(PHP Unit, S3) - 開発ガイドラインの策定、成果物の定義などを行った - 良いコード・目指すべきコードの認識を合わせるために社内勉強会を開催 ### 成果 - テストカバレッジは C1 で 70% を目指そう、といった共通の指標で会話ができるようになった - 新規開発機能などは Layered Architecture などをベースに実現されるようになった - PRでの議論も開発者の好みなどではなく設計原則などを元にしたものに変化した - 社内勉強会は輪読会として1年以上継続している ( https://note.com/scg_tech/n/n0d1ddf57b529 ) ### 課題 (2) 開発組織としてスケールする仕組み化ができていなかった - ドキュメントが整備されておらず、エンジニアが増えても戦力化に時間がかかる - 過去の設計経緯や意思決定理由がわからず、調査や改修の初期コストが高い ### 施策 - オンボーディング資料として全体俯瞰図や仕様書・UMLを整備して、現状を把握できるようにした - Design Docや調査報告書の雛形を作成して作業フローの統一を図った - 意思決定を ADR で残すべく、プレゼンを行った( https://szk416.hatenablog.com/entry/20210516/1621150003 ) ### 成果 - それまでの新メンバーは習熟度を考慮して任意のタイミングで実作業に参加していたが、資料やフローの整備後は 1sprint(2week) のオンボーディングを経て、2sprint目から実作業に参加する流れが定着。作業分担や計画が立てやすくなった - ドキュメントの雛形があることで、チケットの Acceptance Criteria や Definition of Done が自動的に定まることが多くなり、ベロシティが安定した - 自分の所属するプロダクトチームだけでなく、プラットフォームチームでも ADR が採用されるようになった

2017年/2年以内

口コミサイト マイクロサービス化プロジェクト

2社目: Web事業会社 ## 概要 - 口コミ・ランキングサイトの マイクロサービス化 - 10年を迎えレガシーかつモノリスであるため、開発スピードの低下や依存性の排除が急務となっていた ## 担当業務(2017/09 〜 2018/02) - 現行システムの状況をキャッチアップしてすぐにプロトプロジェクトにジョイン - 単なるリライトではまたすぐに技術的負債となりうるため、変更容易性を考慮した実装を行った - 複雑な仕様や出し分け条件、蓄積されたアドホックな処理などを企画や営業と連携して整理 ## 担当業務(2018/03 〜) - 前職でのマネジメント経験を買われ、チームのマネジメントを兼務 - QCD管理 - 他部署折衝 - マイクロサービス社内広報 ...etc ## 詳細1. マネジメント ### 課題 - 当初マイクロサービスチームは若手のエンジニアのみで構成されており、管理者不在と言われている状態にあった - タスクに対しての概算見積すら行われていない(大まかなマイルストーンがあるのみ) - 設定したリリース予定日から数ヶ月単位で作業が遅延する - 毎朝出社後、各々が気分でやりたい作業を行う ### 施策 - リリース計画が曖昧で営業施策にも影響が出ていたため、プロジェクトマネジメントの一般的なプラクティスを実施 - タスク一覧に対してストーリーポイント制で概算見積を実施 - バーンダウンチャートで進捗状況を可視化・メンバーにも納期意識を持たせる - 毎日の朝会、週末のbacklog grooming、週次定例、リリース後の振り返り会を実施 - 月次定例で毎月、作業概要・進捗状況・今後の予定を報告 ### 成果 - マネジメント実施後の3回のリリースにおいて、すべて1週間以上のズレなくリリースを完了した - 営業部や企画部からも施策の計画を立てやすくなったと評価された - 開発部に閉じていたマイクロサービスチームの活動が全社に認識されるようになった ## 詳細2. 検索機能の改善 ### 課題 - 検索エンジンとして Solrを利用しているが、デフォルト設定で使っているだけの状態だった - レガシーな primary-replica な構成で、稀に障害が発生する(書き込みがSPOFである) - 情報の差分更新に時間が掛かり、管理画面の操作からエンドユーザ画面の反映まで最大30分のラグがある - Facet Queryを多用しているため、Slow Queryが多発している ### 施策 - Solrのクラスタリングの仕組みであるSolrCloudを検証環境で試作・提案(コストの兼ね合いから導入予定・時期未定) - 開発・検証・ステージングのSolrをBlue/Greenにすることで、Solr系施策の開発を並行できるようにした - 情報更新のSQL見直しを行い、1回あたりの実行時間を10分の1に削減(処理効率化・index見直し) - Solrのキャッシュ設定を見直し、キャッシュヒット率を3割向上させた(コンサルタント曰く比較的高い数値) - 検索機能の抜本的な改善のためにSolrを使いこなす必要を感じ、コミッターを擁するロンウイット社のコンサル依頼を提案・主導した

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

マネージメント能力

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

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

アピール項目


アウトプット

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

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

- 分散トレーシング、分散トランザクションなどの分散システムに関する技術 - より高いレベルの Go言語の知識、技術力、エコシステムの理解 - コーチングなどのソフトスキル

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

- チーム開発を行っており、適切な権限を持って自律的に動くことができる - 無礼な人、横柄な態度を取る人がいない - 体調に応じて労働時間をコントロールしたり、リモートワークができる

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
水とプログラミングどっちが大事?
自信を持って人より秀でていると言える点
調整力 / 問題解決力 / 責任感
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
SI / 広告 / ゲーム / アダルト
その他の特徴
レガシーな環境を改善できる / 新しい技術はとりあえず試す
その他のやりたいこと・やりたくないこと

世の中を良くする、人を幸せにするサービスに携わりたいです。
また過去に巨大なモノリスシステムに関わり苦労した経験から、そういったシステムの運用保守よりは、マイクロサービス化であったり、モジュラモノリスとして適切な分割を行っていく試みに関心があります。
作っている人も、使う人も、お互いに幸せになるシステムやサービスに人生の多くの時間を費やしたいと考えています。

やりたい事

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

基本プロフィール

年齢
今年で30代後半
好きな Text Editor
IntelliJ IDEA
希望勤務地
東京都 / 神奈川県 / リモート勤務
集まる必要性がない場合は基本リモートが許可される環境が必要
希望年収
未入力
転職ドラフトに参加して
企業から指名を受け取ろう!
会員登録をして転職ドラフトに参加すると、参加企業から年収付きの指名を受け取ることができるようになります。
会員登録する
ご意見箱

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

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

  • {{error}}
SIGN UPSIGN IN


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