Tweet
Tweet

Slide 1

Slide 1 text

SREからゼロイチプロダクト開発へ ー越境する打席の立ち方と期待への応え方ー 2025-04-23 Product Engineering Night #8 LayerX @itkq

Slide 2

Slide 2 text

whoami *: 当時はDevOps Intro id: itkq / handle: いたこ LayerX バクラク事業部 Platform Engineering部 SRE* Tech Lead Cookpad → Ubie → LayerX (2023/02~) 主にインフラ基盤やCI/CD基盤を担当 © LayerX Inc. 2

Slide 3

Slide 3 text

Intro © LayerX Inc. 3

Slide 4

Slide 4 text

Intro © LayerX Inc. 4

Slide 5

Slide 5 text

バクラクのSRE Intro プロダクト開発部 各プロダクトごとに自律した少数人数の開発 チーム Platform Engineering部 SRE サービス運用の支援 インフラ基盤の運用や改善 © LayerX Inc. 5

Slide 6

Slide 6 text

私とプロダクト開発 © LayerX Inc. Intro 顧客に提供するプロダクトの機能開発経験はほぼ無い チャンスがあればがっつりプロダクト開発してみたいと思っていた 開発チームで実際に開発することでSREやPlatformを俯瞰 プロダクト機能の切り口で直接的な事業貢献 特にバクラクの場合、「プロダクト開発の強さ」が外向けにもアピールされており、体 感してみたかった 開発速度が速い #とは 6

Slide 7

Slide 7 text

本日の内容 © LayerX Inc. Intro バクラク勤怠チームに開発者として参加し、Slack連携中心の機能を担当したこと Slackアプリや通知のアーキテクチャをゼロから考えて実装 大きく2つのテーマ 打席に立つ 期待に応える 7

Slide 8

Slide 8 text

打席に立つ

Slide 9

Slide 9 text

背景：勤怠をうまくやりたい © LayerX Inc. 打席に立つ ―バクラク勤怠開発に参加するまでの経緯 "ぼくのかんがえたさいきょうの社内用の勤怠Slackアプリ" (slack-kintai) を勝手に作り 始める 以前: PCログによる自動打刻 今: Webで手動の打刻 → むずかしい 最終的には正式化 周りの人にテストしてもらった後、全体に向けて公開 労務チームと連携し、オンボーディングに組み込まれる 9

Slide 10

Slide 10 text

打席に立つ ―バクラク勤怠開発に参加するまでの経緯 © LayerX Inc. 10

Slide 11

Slide 11 text

なぜSlackアプリを選んだか © LayerX Inc. 打席に立つ ―バクラク勤怠開発に参加するまでの経緯 Slackは常に立ち上がっている 一方、ブラウザで勤怠サービスを開くのすら億劫 App Home（ホーム画面）の活用 誰でも直感的に操作できる フレックス時間差や勤怠アラートを同時に見ることができる 技術的関心 社内の勤怠習慣との親和性 例: 日報をSlackに投稿する 11

Slide 12

Slide 12 text

バクラク勤怠とSlack連携 © LayerX Inc. 打席に立つ ―バクラク勤怠開発に参加するまでの経緯 Slack連携は当初からつくる想定だったが、優先度が相対的に低かった 何をつくるかすら決まっていない状態 そこでslack-kintaiをベースに潜在顧客にデモしたところ好感触 しかし開発リソースに余裕はない そして話が来た…！ 12

Slide 13

Slide 13 text

© LayerX Inc. 打席に立つ ―バクラク勤怠開発に参加するまでの経緯 13

Slide 14

Slide 14 text

期限付きの異動 打席に立つ ―バクラク勤怠開発に参加するまでの経緯 SRE関連の会議を徐々に減らす ボールを強い気持ちで手放す 例: SOC1 Type2 Report 仕事を減らす活動が功を奏した Slack botによるデプロイフローの型化 Terraformリリースフローの改善 © LayerX Inc. 14

Slide 15

Slide 15 text

まとめ1：打席をつかむためのTips © LayerX Inc. 打席に立つ ―バクラク勤怠開発に参加するまでの経緯 常に新しい (おもしろい) 仕事を探す 技術以外にもSlack public channelを追ったり、経営会議の議事録を丁寧に読む トイルを減らす。自動化したり、不要なことを思い切ってやめる 種を撒いておく "20%口出しルール" ―LayerX羅針盤 "手を動かした人だけが世界を変える" ―Yasuhiro Onishi 15

Slide 16

Slide 16 text

期待に応える

Slide 17

Slide 17 text

アーキテクト的な働き 期待に応える ―成果を出すまでの道のり Slack連携のコアは Bolt for JavaScript + jsx- slack で着地 他プロダクトでGoによる実装のつらみがあった ViewやBlockの組み立てが複雑になる将来は予測できた Webアプリと同様にGraphQLを利用 Slackアプリも「フロントエンド」 © LayerX Inc. 17

Slide 18

Slide 18 text

期待に応える ―成果を出すまでの道のり © LayerX Inc. 18

Slide 19

Slide 19 text

Embedded SRE的な働き © LayerX Inc. 期待に応える ―成果を出すまでの道のり 例: パフォーマンス観点でのRedisキャッシュ導入 Enablingチームとも連携して、汎用的な設計を行い、スムーズにインフラの展開まで行えた ドメイン知識があることで議論がスムーズ 初期の運用 監視設計やリリース・障害対応を全面的に引き受ける 19

Slide 20

Slide 20 text

ここまでは「今まで通りの」期待…

Slide 21

Slide 21 text

機能開発で壁にぶち当たる © LayerX Inc. 期待に応える ―成果を出すまでの道のり 他のメンバーと比較して思うように進捗を出せない 焦る 勤怠のドメインキャッチアップに苦しんでいるわけではなかった プロダクトのコードはそこそこ読むことになったが、全体感はすでに把握していた 最初の設計 〜 一歩目の実装 の生みの苦しさ 21

Slide 22

Slide 22 text

転機 © LayerX Inc. 期待に応える ―成果を出すまでの道のり mosaとの初めての1on1で「動くもので示して」とフィードバックを受ける 誰でも最初から100点は取れない 目標: 1日1デモ そもそも仕様が決まっていない事情も絡んでいた 手戻りは悪ではないが、繰り返せば時間を消費する バクラクのプロダクト開発エンジニアは 仕様を磨き込むのも自分の仕事 高速にフィードバックループを回すことが最重要 週3日物理出社で同期的な議論を増やした 22

Slide 23

Slide 23 text

Slack承認依頼申請通知の例 期待に応える ―成果を出すまでの道のり 承認待ちの申請をSlackで通知する機能 都度通知だと煩いのでは？ 休日に通知する？ etc. 現実的なユースケースをカバーできるシンプル な設定に © LayerX Inc. 23

Slide 24

Slide 24 text

Slack上で直接承認できない？ 期待に応える ―成果を出すまでの道のり バクラク申請ではSlack通知から承認できるが… しかし勤怠申請は性質が異なりシステム上複雑すぎると考 えていた 特に承認者が複数いる場合のメッセージ更新 Slackの制約 承認に特化したUI・UXを発明 まとめて連続承認 一方、却下はできない 絵文字による申請区別の工夫 © LayerX Inc. 24

Slide 25

Slide 25 text

まとめ2: 期待に応えるためのTips © LayerX Inc. 期待に応える ―成果を出すまでの道のり 信頼を得る 自分が持っている強みを活かす アンラーンして殻を破る Feedback is a gift 限界を勝手に決めない "提供価値にこだわる" ―LayerX羅針盤 25

Slide 26

Slide 26 text

持ち帰ったこと © LayerX Inc. 振り返り プロダクト開発者の人格を宿す 仕様のブラッシュアップから問い合わせ対応まで、本当にやることが多い 例: そのセルフサービス化は果たして全体最適か？ "Platform as a Product" プロダクト開発のエッセンスでPlatformはよりよいものにできる 私達には "羅針盤" があり "プロダクト開発のプロ" という顧客がいる、これ以上ない環境 26

Slide 27

Slide 27 text

副産物 振り返り Slack連携のローカル開発を効率化するべく、 ngrok代替となる汎用ツールを開発 https://github.com/itkq/hook-relay フィルタにより複数人が同時に開発可能 自分のIDが含まれるイベントだけ取れればよい © LayerX Inc. 27

Slide 28

Slide 28 text

越境のススメ © LayerX Inc. 振り返り "計画的偶発性理論" 個人のキャリアは偶発的に決定されることが多く、その偶然を「計画的に設計」する考え方 自分が憧れるエンジニアは境界を引かないがち "Beyond boundaries" ―Cookpad Engineering Manifesto (2022) 28

Slide 29

Slide 29 text

まとめ © LayerX Inc. SREがバクラク勤怠チームに開発者として参加した話 打席に立つ 期待に応える 持ち帰った学び 越境は大変だが、それ以上の見返りがあると思う 周りのサポートも必要。LayerXでは羅針盤もあり、チャレンジしやすい環境 29