伴走から自律へ：形式知へと導くSREイネーブリングによるプロダクトチームの信頼性オーナーシップ向上 / SRE NEXT 2025

伴走から自律へ：   形式知へと導く SREイネーブリングによる   プロダクトチームの信頼性オーナーシップ向上     @SRE NEXT
2025, 2025/07/12   株式会社ビズリーチ（ Visionalグループ）   プロダクト本部 /プラットフォーム統括部 /ビズリーチプラットフォーム部 /SREグループ    佐々木康徳  1

自己紹介  経歴  • 2019年〜 SIer  ◦ 主に顧客システムの更改案件を担当     ◦
リーダー/サブリーダーとして経験を積む       • 2024年〜株式会社ビズリーチ  ◦ SREとしてビズリーチプラットフォームの     信頼性向上に貢献     趣味  • eSports（競技プレイヤー #スマブラ）  • アウトドア（キャンプ . ボルダリングなど）  佐々木康徳  2

即戦力人材と企業をつなぐ転職サイト「ビズリーチ」  引用：ビジョナル株式会社「 2025年7月期第3四半期決算説明資料」   C (ビズリーチ会員様) とB (直接採用企業様 /
ヘッドハンター様)へ転職プラットフォームを提供  3

顧客基盤の拡大に支えられた堅調な成長  引用：ビジョナル株式会社「 2025年7月期第3四半期決算説明資料」   4

私たちが働く未来  引用：ビジョナル株式会社「 2025年7月期第3四半期決算説明資料」   5

今日分かること  なぜイネーブリングが必要か  イネーブリングが必要だった背景はなにか   イネーブリングを進めることによって生まれる変化はなにか   どのようにプロダクトチームのオーナーシップを向上させたか   ビズリーチSREによるプラクティスや具体的アプローチを伴うイネーブリングによって  
どのようにプロダクトチームがオーナーシップを向上したか   6

アジェンダ  1. SREについて  1.1. ビズリーチのSREとは    1.2. 私たちが目指すSREの将来像    2.
イネーブリングを進めた背景   2.1. SREが行っていた作業    2.2. なぜイネーブリングが必要か    2.3. ビズリーチSREはどうイネーブリングしていくか    3. SECIモデルで進めるイネーブリング   3.1. SECIモデルとは    3.2. ケーススタディ：WAF運用を「できる」ようになるため    3.3. イネーブリングがもたらす価値    4. 最後に  4.1. 明日からできること  7

SREについて  8

ビズリーチのSREとは  • 日々の取り組み  SREについて  オンコール対応  他チームへの  イネーブリング  システム&組織改善  （Issue対応）  学びへの投資 
（勉強会など）  9

ビズリーチのSREとは  • 日々の取り組み  SREについて  オンコール対応  他チームへの  イネーブリング  システム&組織改善  （Issue対応）  学びへの投資 
（勉強会など）  システム管理や運用における課題を解決し、   突発的な問題に速やかに対応する仕組みを設けて、サービスの信頼性を向上させる。   10

私たちが目指すSREの将来像  直近目指している姿   SREについて  Product A Product C Product B
BizReach SRE Team A Team B Team A Team B Team A Enabling 11

私たちが目指すSREの将来像  直近⽬指している姿 SREについて  ビズリーチSREが掲げる理想的な姿   Product A  Product C  Product
B  BizReach SRE  Team A  Team B  Team A  Team B  Team A  +SRE能力  +SRE能力  +SRE能力  12 Product A Product C Product B BizReach SRE Team A Team B Team A Team B Team A Enabling

私たちが目指すSREの将来像  直近目指している姿   SREについて  Product A Product C Product B
BizReach SRE Team A Team B Team A Team B Team A Enabling Embedded Embedded Embedded ビズリーチSREが掲げる理想的な姿   Product A Product C Product B BizReach SRE Team A Team B Team A Team B Team A +SRE能⼒ +SRE能⼒ +SRE能⼒ 13 プロダクトチームが信頼性の向上を   自律して行えるようにしたい     SREが伴走して、取り組みを浸透させたい   SRE プロダクトチームは   信頼性を向上する取り組みを   主体的に行える   SREは  「開発者の『やりたいこと』への集中」   を後押しできる 

イネーブリングを進めた背景  14

• 現代の開発状況  ◦ システムの複雑化が加速する一方、ビジネスは「開発速度」と「信頼性」の両立を強く要求している  ◦ これらの大きなプレッシャーの板挟みが、開発現場における大きな課題となっている    • 課題  なぜイネーブリングが必要か 
イネーブリングを進めた背景  15 開発者の認知負荷の増大  サービス信頼性の  低下リスク  開発サイクルの遅延と  コミュニケーションロス 

イネーブリングを進めた背景  16 開発者の認知負荷の増⼤サービス信頼性の  低下リスク  開発サイクルの遅延とコミュニケーションロス

イネーブリングを進めた背景  17 開発者の認知負荷の増⼤サービス信頼性の低下リスクサービス信頼性の  向上活動のオーナーシップを  プロダクトチームに  持ってもらうべき  開発サイクルの遅延とコミュニケーションロス

ビズリーチSREはどうイネーブリングしていくか  イネーブリングを進めた背景  18 サービス信頼性の向上活動のオーナーシップをプロダクトチームに持ってもらうべき   インフラに関する知識が特定の担当者に集中し、   「その人がいないと対応できない」という属人化を招く   認知負荷が高い状態で、不慣れなインフラ作業を行った結果、
  意図しない設定ミスや障害を引き起こすリスクが高まる   サービス信頼性の  低下リスク 

SREが行っていた作業  イネーブリングを進めた背景  エンドユーザー  セキュリティソフトウェア   (WAF)  Bizreach サービス  Internet  19

• 定期的な運用        • 突発的な運用  イネーブリングを進めた背景  WAF設定変更の検討と導入  攻撃性リクエストへの遮断対応
  監視設計とアラート導入  誤遮断検知対応   20 リクエスト状況分析  新機能（アップデート）確認  SREが行っていた作業 

ビズリーチSREはどうイネーブリングしていくか  イネーブリングを進めた背景  インフラに関する知識が特定の担当者に集中し、「その⼈がいないと対応できない」という属⼈化を招く認知負荷が⾼い状態で、不慣れなインフラ作業を⾏った結果、意図しない設定ミスや障害を引き起こすリスクが⾼まるサービス信頼性の  低下リスク  SREはプロダクトチームに  •
WAFの仕組みや使い方を理解できるように共有する  • WAFの作成やチューニング、運用ができるようにスキルトランスファーを行う  21 サービス信頼性の向上活動のオーナーシップをプロダクトチームに持ってもらうべき  

SECIモデルで進めるイネーブリング  22

SECIモデルとは  SECIモデルで進めるイネーブリング  • SECI(セキ)モデル※1  ◦ 個人が持つ知識や経験などの暗黙知を、形式知に変換した上で組織全体で共有・管理し、   それらを組み合わせることでまた新たな知識を生み出すフレームワーク    
    • SECIモデルの4つのプロセス  ◦ 共同化 (Socialization)  ◦ 表出化 (Externalization)  ◦ 連結化 (Combination)  ◦ 内面化 (Internalization)  ※1…野中郁次郎. Knowledge-Creating Company（邦題『知識創造企業』）. 東洋経済新報社, 1995. https://str.toyokeizai.net/books/9784492522325/ Socialization 共同化 Externalization    表出化  Combination    連結化  Internalization    内面化  暗黙知  暗黙知  形式知  形式知  暗黙知  形式知  形式知  暗黙知  23

SECIモデルとは  SECIモデルで進めるイネーブリング  Socialization    共同化  Externalization    表出化  Combination   
連結化  Internalization    内面化  OJTやペアワークなどの体験共有を通じ   個人の勘や感覚などの「暗黙知」を   他者の「暗黙知」として直接伝えるプロセス   暗黙知  暗黙知  形式知  形式知  暗黙知  形式知  形式知  暗黙知  個人の勘やノウハウといった「暗黙知」を  マニュアルや図解などの「形式知」へと  変換（言語化）するプロセス  言語化された「形式知」同士を  組み合わせ体系化することで、より高度な  新しい「形式知」を創り出すプロセス  「形式知」を実践や反復練習を通じて  使いこなし、個人のスキルという  「暗黙知」として体得するプロセス  24

ケーススタディ：WAF運用を「できる」ようになるため  Socialization    共同化  Externalization 表出化 Combination 連結化 Internalization 内⾯化
SREがプロダクトチームの開発者と  WAF運用のペア作業を実施  暗黙知  暗黙知形式知形式知暗黙知  形式知形式知暗黙知個⼈の勘やノウハウといった「暗黙知」をマニュアルや図解などの「形式知」へと変換（⾔語化）するプロセス SREが⾔語化‧図式化した情報をプロダクトチームの使いやすい形に変化させたり、組み合わせる提案をした開発者がオーナーシップを持って WAFの運⽤を進めることで⾃分⾃⾝のスキルとして体得した説明を聞いてもらう  WAFについての説明や、具体的な仕組みを共有する。   全てをここで理解してもらう必要はなく、まずは情報を浴びてもらう。   一緒に手を動かす  説明や共有が済んだら、ペア作業を行う。   SREの実作業を見せつつ、対話を通じて、   思考プロセス(暗黙知)のスキルトランスファーを行う。   25

ケーススタディ：WAF運用を「できる」ようになるため  Socialization 共同化 Externalization    表出化  Combination 連結化 Internalization 内⾯化
SREがプロダクトチームの開発者と WAF運⽤のペア作業を実施暗黙知暗黙知  形式知形式知暗黙知形式知  形式知暗黙知 SREが持つWAF運用の手順を  言語化してドキュメントに記した  SREが⾔語化‧図式化した情報をプロダクトチームの使いやすい形に変化させたり、組み合わせる提案をした開発者がオーナーシップを持って WAFの運⽤を進めることで⾃分⾃⾝のスキルとして体得した属人化していたWAFの運用を、チームとして対応できるようにする。   「どのような通信を怪しいと判断するか」といった   基準や調査の手順を明確にしたマニュアルを作成した。   26

定期的、突発的なWAF運用の中身を言語化し、ドキュメントとして残す   ケーススタディ：WAF運用を「できる」ようになるため  表出化の例  27

ケーススタディ：WAF運用を「できる」ようになるため  Socialization 共同化 Externalization 表出化 Combination    連結化  Internalization 内⾯化
SREがプロダクトチームの開発者と WAF運⽤のペア作業を実施暗黙知暗黙知形式知  形式知暗黙知形式知形式知  暗黙知 SREが持つWAF運⽤の⼿順を⾔語化してドキュメントに記した表出化した情報を使って  プロダクトチームの使いやすい形に  変化させたり、組み合わせる提案をした  「形式知」を実践や反復練習を通じて使いこなし、個⼈のスキルという「暗黙知」として体得するプロセス改善活動の開始  運用後に振り返りを行い、改善策を検討する取り組みを始めた。     課題  調査の仕方や道具は既にある状態だったが、   複数の資料を行き来することが、運用の手間となっていた。     解決策  表出化した調査手順とツールをまとめ、   運用しやすくするためにダッシュボードの作成を行った。   28

運用振り返り  • より効果的に運用するために、   実施してきた手順を見直しを行った   • 当初4時間かかっていた運用作業は、 2時間まで削減できた  →調査基準を落とさなかったので品質は維持
  ケーススタディ：WAF運用を「できる」ようになるため  ダッシュボード作成  連結化の例  振り返り例 29

ケーススタディ：WAF運用を「できる」ようになるため  Socialization 共同化 Externalization 表出化 Combination 連結化 Internalization    内面化 
SREがプロダクトチームの開発者と WAF運⽤のペア作業を実施暗黙知暗黙知形式知  形式知  暗黙知形式知形式知暗黙知  SREが持つWAF運⽤の⼿順を⾔語化してドキュメントに記した SREが⾔語化‧図式化した情報をプロダクトチームの使いやすい形に変化させたり、組み合わせる提案をした開発者がオーナーシップを持って  WAFの運用を進めることで  自分自身のスキルとして体得した  理解して運用出来る状態になっている   プロダクトチームの開発者が主体的に   WAFルールのチューニングを提案、実施することで、   知識を自分自身のスキル（新たな暗黙知）として体得した。   新しい状況に対して適用できる   プロダクトチームの開発者が自主的にリクエスト分析を行い、   必要であれば遮断対応を進めている。   30

オーナーシップを持った取り組み   • 実際にアラートが鳴った際、   プロダクトチームの開発者がオーナーシップを   持ってリクエスト分析を行っている   •
WAFルールやモニタを、このようにチューニングしてはどうか、という対応や提案を自主的に行っている   ケーススタディ：WAF運用を「できる」ようになるため  内面化の例  31

イネーブリングがもたらす価値  • 意思決定の高速化  ◦ SREに聞かなくても判断できることが増え、開発がスピードアップする      • オーナーシップ  ◦
「自分たちが自分たちのサービスを守る」という自律性を養い、  それを実現するための技術的なナレッジの蓄積が加速する      • コミュニケーションの効率化   ◦ プロダクトチームの認知・技術レベルが高まることで、前提を省略して迅速にコミュニケーションが取れる    32

最後に  33

最後に  なぜイネーブリングが必要か  イネーブリングが必要だった背景はなにか   イネーブリングを進めることによって生まれる変化はなにか   どのようにプロダクトチームのオーナーシップを向上させたか   ビズリーチSREによるプラクティスや具体的アプローチを伴うイネーブリングによって  
どのようにプロダクトチームがオーナーシップを向上したか   今日分かること  34

最後に  なぜイネーブリングが必要か  課題「システムの複雑化が進む中で『開発速度』と『信頼性』を両立させたい」   →認知負荷を下げ、属人化を解消し、開発チーム全体の自律性を高めるとともに   　本質的な価値創造に集中させ、開発サイクルの高速化する必要がある   どのようにプロダクトチームのオーナーシップを向上させたか  
「なぜ◯◯が必要か」を説明し、こうしてほしい、どういう状態になって欲しいかを共有する   →ペアで作業したり、暗黙知となっているナレッジを表出化することで、   　知っている状態からできる状態に変化させる   今日分かること  35

最後に  あなたのチームの掲げる未来像を共有してみませんか   「各チームで自己完結できるようにしたい」   「自チームがサービス価値向上に集中できる環境を構築したい」   未来像を共有することで、チーム間でどう取り組んで行けば実現できるかのステップに繋げられます   あなたや、あなたのチームの「暗黙知」を書き出してみませんか
  「特定の誰か」しか知らない手順や判断基準を一つだけでもドキュメント化してみましょう   属人化の解消は、サービスの信頼性向上に繋がります   明日からできること  36

伴走から自律へ：形式知へと導くSREイネーブリングによるプロダクトチームの信頼性オーナーシ...

伴走から自律へ：形式知へと導くSREイネーブリングによるプロダクトチームの信頼性オーナーシップ向上 / SRE NEXT 2025

Visional Engineering ＆ Design

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript