suzushin

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つ目のシステムを完成まで漕ぎ着けている

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/

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

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 が採用されるようになった

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を使いこなす必要を感じ、コミッターを擁するロンウイット社のコンサル依頼を提案・主導した