Share
Embed
事業ロードマップを意識してアジャイルに向き合ってるSREがメンバーのキャリアマップを考えて1on1をやったら、自ら成長して窮地を切り抜けてくれた話 / 20251126 Naoki Shimada
2025/11/26 株式会社SHIFT、東京ガス株式会社、日鉄ソリューションズ株式会社3社共催OST 第2回
株式会社SHIFT
アジャイル推進部
島田直樹
SHIFT EVOLVE PRO
November 26, 2025
Transcript
31 slides
-
Copyright SHIFT Inc, All Rights Reserved. 2025 / Copyright SHIFT
Inc, All Rights Reserved. 1 チームと組織の人材育成施策について共有しあおう 株式会社SHIFT ソリューション本部 ソリューション事業部 アジャイル推進部 NAOKI SHIMADA 26 11 18:10 ~ 18:15 島田 直樹 事業ロードマップを意識して アジャイルに向き合ってる SREが メンバーの キャリアマップを考えて 1on1をやったら、 自ら成長して窮地を切り抜けてくれた話 (センリツSRE) -
Copyright SHIFT Inc, All Rights Reserved. 2 大阪で誕生 事業側SREになる SHIFTに参加する
結婚&2児の父になる 誰かのSREをアシストするSREになる エンジニア経歴すごろくを 自己紹介にかえて SREを愛し、 センリツSREという名前で 執筆・登壇活動しています。 -
3 Copyright SHIFT Inc, All Rights Reserved. 1. とあるSREの嘆き~なんちゃってはつらいよ~ (2分)
2. ロードマップを意識した1on1で活路を開け! (2分) 3. まとめ (1分) -
4 Copyright SHIFT Inc, All Rights Reserved. 1. とあるSREの嘆き~なんちゃってはつらいよ~ (2分)
2. ロードマップを意識した1on1で活路を開け! (2分) 3. まとめ (1分) -
Copyright SHIFT Inc, All Rights Reserved. 5 アジャイルとSREの関係 引用元 David
N. Blank-Edelman: Becoming SRE, 1st ed., O’REILLY, 2024, 285p オライリー出版の「SREを始めよう」という本には、以下のSRE、DevOps、アジャイル戦略のLimoncelli モデルが載っています。 SREはプロダクションでの運用に集中し、最 終結果を改善する手段としてパイプラインの それに先立つ段階に対応 DevOpsはここからスタートして左から右へステッ プを自動化。完了したら最初に戻ってボトルネック を最適化 アジャイルは ここの問題を解決 -
Copyright SHIFT Inc, All Rights Reserved. 6 アジャイルとSREの関係 オライリー出版の「SREを始めよう」という本には、以下のSRE、DevOps、アジャイル戦略のLimoncelli モデルが載っています。
SREはプロダクションでの運用に集中し、最 終結果を改善する手段としてパイプラインの それに先立つ段階に対応 DevOpsはここからスタートして左から右へステッ プを自動化。完了したら最初に戻ってボトルネック を最適化 アジャイルは ここの問題を解決 う~ん、 なんか違う・・・ -
Copyright SHIFT Inc, All Rights Reserved. 7 アジャイルとSREの関係 実際、私がSREとして働くとき、多くの場合は以下の通り、Limoncelliが提唱したモデルよりも広い領域 の対応をする傾向が強いです。
SREはプロダクションでの運用だけではなく、信頼 性に関わるすべてのことに関わる DevOpsはここからスタートして左から右へステッ プを自動化。完了したら最初に戻ってボトルネック を最適化 アジャイルは ここの問題を解決 Naoki Shimada: 日本のSREの多くの実態 -
Copyright SHIFT Inc, All Rights Reserved. 8 今の時代、素早く開発して素早く市場に投入し、また次の新しいリリースをどんどん投入しつづけるというこ とができなくては勝てません。 運用が開発リリースのブロッカーにならないように、ボトルネックをうまく移動させながら、素早さと品質にト
レードオフを生じさせることなく、サービスを成長させていく必要があります。 「なんちゃってSRE」本当につらいです・・・ -
Copyright SHIFT Inc, All Rights Reserved. 9 「なんちゃってSRE」本当につらいです・・・ 今の時代、素早く開発して素早く市場に投入し、また次の新しいリリースをどんどん投入しつづけるというこ とができなくては勝てません。⇒
だからアジャイル、DevOpsが必要 運用が開発リリースのブロッカーにならないように、ボトルネックをうまく移動させながら、素早さと品質にト レードオフを生じさせることなく、サービスを成長させていく必要があります。 ⇒ だからSRE が必要 -
Copyright SHIFT Inc, All Rights Reserved. 10 今の時代、素早く開発して素早く市場に投入し、また次の新しいリリースをどんどん投入しつづけるというこ とができなくては勝てません。⇒ だからアジャイル、DevOpsが必要
運用が開発リリースのブロッカーにならないように、ボトルネックをうまく移動させながら、素早さと品質にト レードオフを生じさせることなく、サービスを成長させていく必要があります。 ⇒ だからSRE が必要 「なんちゃってSRE」本当につらいです・・・ <宣伝です> 本日は時間制約のなか、語り切れないことがたくさんありますので、 以下の過去登壇アーカイブや弊社技術ブログもご参照いただけますと大変幸甚です。 -
Copyright SHIFT Inc, All Rights Reserved. 11 アジャイル開発もできていなくて、DevOpsも形式なものになっている・・・ リリース頻度も変わってないのに、SREを立ち上げたときに起こること・・・ それは、信頼性向上というお題目を掲げながらも、
その実態は、CloudNativeな便利屋さんなんだろうと思います。 この状態は「なんちゃってSRE」の1例であり、 そのSREチームのメンバーが次々と倒れてしまい、チームが崩壊するでしょう。 だからこそ、本質に根差したアジャイルはSREにとっての救世主です。 またその逆も然りではあります。 「なんちゃってSRE」本当につらいです・・・ -
Copyright SHIFT Inc, All Rights Reserved. 12 以下の登壇イベントでご一緒させていただきましたX-Tech5の馬場さんが、 イベントの後日談として「なんでも屋さん」に対しての肯定的なコメントを出されています。 私も馬場さんのご意見には、マインドとしては365%賛成です。
その一方で、アジャイルもDevOpsも回っていない状況なら、SRE立ち上げの前に 優先的にやるべきことがきっとあるはず、と思っています。 補足:なんでも屋さんを否定しているわけではありません -
13 Copyright SHIFT Inc, All Rights Reserved. 1. とあるSREの嘆き~なんちゃってはつらいよ~ (2分)
2. ロードマップを意識した1on1で活路を開け! (2分) 3. まとめ (1分) -
15 Copyright SHIFT Inc, All Rights Reserved. Task Task Task
Task Task Task Task Task Task Task Task Task ITシステムでは、コネクションリークがメモリリークを引き起こし、最終的にCPU張り付きに至り、どの処理もでき なくなるということが起こりますが、私が率いるSREチームが崩壊し始めたとき、私たち人間の脳にも同様の事 象が発生していたと思われます。 (思考の停止、行動選択の停滞) SREチームが崩壊するときに見えるもの -
16 Copyright SHIFT Inc, All Rights Reserved. Task Task Task
Task Task Task Task Task Task Task Task Task ITシステムでは、コネクションリークがメモリリークを引き起こし、最終的にCPU張り付きに至り、どの処理もでき なくなるということが起こりますが、私が率いるSREチームが崩壊し始めたとき、私たち人間の脳にも同様の事 象が発生していたと思われます。 (思考の停止、行動選択の停滞) SREチームが崩壊するときに見えるもの ・人間の脳はマルチタスクを行うことが苦手 ・マルチタスクを行うには、タスクの切り替えに伴う「切り替えコスト」が発生する ・頻繁にマルチタスクを行う人は、注意力、記憶力、作業効率、精神力、免疫力、体力が低下する (参考文献:Eyal Ophir, Clifford Nass, Anthony D. Wagner ,"Cognitive control in media multitaskers", Proceedings of the National Academy of Sciences Vol. 106 | No. 37 September 15, 2009 PubMed: 19706386) スタンフォード大学の脳科学研究結果 -
17 Copyright SHIFT Inc, All Rights Reserved. アジャイルマニュフェストにも記載がありますが、 SREも対話を重要視します。 事業ロードマップとキャリアマップをリンクさせることを意識しながら、
会話をすることで、思考の停止・行動選択の停滞から抜け出す 意志を取り戻すことができました。 それではさっそく、当時の1on1の再現をご覧ください。 それでも私たちは、会話をやめない https://agilemanifesto.org/iso/ja/manifesto.html アジャイルマニュフェストHPより -
18 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景 ところで、あなたはなぜ、アジャイルの部署に配属を 希望したのですか?
小さなサイクルを回して、ゴールに近づいていくという考 え方が、自分にあっていると思ったからです。 なるほど、とても良い分析ですね。 このアジャイル開発プロジェクトの成功と あなた個人のステップアップが重なる点があるんですね。 やる :別の話題の中で、事業のロードマップとキャリアマップの共通項を見つけること やらない:ロードマップの絵を描いて見せることではない(見せても別に構いはしないけれど) ロードマップとキャリアマップをリンクさせる -
19 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景 そのためにどんなスキルが必要だとお考えですか? ソフトスキルの向上についてはイメージつくのですが、
テクニカルスキルのイメージがわかず、 自分の強みと弱みが自分でわかっていない状態です。 ソフトスキル向上についてイメージが付いていることが とても素晴らしいです。 やる :その人が欲したタイミングで、その言葉を伝える(タイミングじゃなかたら伝えない) やらない:一般論を押し付けない(ソフトスキルの方が抽象度高で習得困難だったとしても) 何をいつ伝えるかは、相手がそれを欲した時 -
20 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景 強みと弱みを知る必要があるとお考えのようですが、 その理由や背景があれば、ぜひ教えてください。
誰かに評価をしてもらう時、自分の強みと弱みが わかっていないと、アピールすることが難しいからです。 なるほど、自分で目標を定める時も、 自分の適性は重要な指標の1つですよね。 やる : 「わからないことがわからない」 から 「”それが” とにかくわからない」のフェーズにSHIFTする やらない:深堀りの内容が本人の口から出る前に言ってしまう アクションプランの背景や理由を深堀する -
21 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景 ちなみに、強みと弱みでは、あなたはどちらを 伸ばすべきだと考えますか?
今の私は強みを伸ばすべきだと考えています。 ですがその伸ばすべきものが何かについて悩んでいます。 それはたくさんのやるべきことが目の前にある。 一方で自分の時間や体力には限りがある。 いったいどの順番で、どれくらいのパワーをかければ 正解かわからない、ということであってますか? やる :このように進めてはどうか?という提案をする やらない:こちらから決めてしまわないこと(自分で決めてもらう共通体験が大切) 背景や理由に対する方向性は示す -
22 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景 はい、その通りです。 あなたがアジャイルの小さなサイクルを回すプロセスが
自分にあっていると言った理由がわかった気がします。 まずはタイムマネジメントとタスクの重み付けから学んで いきましょう。その上でマルチタスクにせずにシングルタス クに集中して消化することを心がけましょう。 やる :具体策を練るが、細かい進め方は本人に委ねる(試行錯誤してもらう) やらない:否定をしない(当たり前) 方向性がすり合わせられたら具体策を練る OKです。 -
23 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景(その後、立てたアクションプラン) STEP1: すべてのToDoをリストアップする
STEP2: すべてのToDoを重要度×緊急度のマトリクス表で分類する STEP3: タイムブロッキングの方法で決めた優先順位別に対応していく バラバラのタスクを種類ごとに整理をする -
24 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景(その後、立てたアクションプラン) 重要度:低 緊急度:高=錯覚の領域
重要度:高 緊急度:高=必須の領域 重要度:低 緊急度:低=浪費・過剰の領域 重要度:高 緊急度:低=効果性の領域 重要度(高) 緊急度(高) 緊急度(低) 第1象限 第2象限 第3象限 第4象限 STEP1: すべてのToDoをリストアップする STEP2: すべてのToDoを重要度×緊急度のマトリクス表で分類する STEP3: タイムブロッキングの方法で決めた優先順位別に対応していく 重要度(低) -
25 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景(その後、立てたアクションプラン) 重要度:低 緊急度:高=錯覚の領域
重要度:高 緊急度:高=必須の領域 重要度:低 緊急度:低=浪費・過剰の領域 重要度:高 緊急度:低=効果性の領域 重要度(高) 緊急度(高) 緊急度(低) 第1象限 第2象限 第3象限 第4象限 STEP1: すべてのToDoをリストアップする STEP2: すべてのToDoを重要度×緊急度のマトリクス表で分類する STEP3: タイムブロッキングの方法で決めた優先順位別に対応していく 重要度(低) -
26 Copyright SHIFT Inc, All Rights Reserved. とある1on1の風景(その後、立てたアクションプラン) STEP1: すべてのToDoをリストアップする
STEP2: すべてのToDoを重要度×緊急度のマトリクス表で分類する STEP3: タイムブロッキングの方法で決めた優先順位別に対応していく 月 火 水 木 金 06:00-07:00 07:00-08:00 08:00-09:00 09:00-10:00 10:00-11:00 11:00-12:00 12:00-13:00 13:00-14:00 14:00-15:00 15:00-16:00 16:00-17:00 17:00-18:00 18:00-19:00 -
27 Copyright SHIFT Inc, All Rights Reserved. 実は、SREを提唱したGoogleも同様に、SREsがどのように時間を使っているかを計測しているそうです。 オライリー出版の「Site Reliability
Engineering: How Google Runs Production Systems」には、 以下の記載があります。 それで、どうなった? Googleにおけるおおまかなルールは、SREチームは残りの50%の時間を実際に 開発を行うために使わなければならないというものです。 このルールはどのように一考されるのでしょうか。 まずはSREがどのように時間を使っているかを計測しなければなりません。 計測ができれば、常に50%以下の時間しか開発作業に費やしていないチーム の習慣を変えることができます。 引用元 Betsy Beyer, Chis Jones Jennifer Petoff, Niall Richard Murphy: Site Reliability Engineering: How Google Runs Production Systems, 2st ed., O’REILLY, 2019, 536p -
28 Copyright SHIFT Inc, All Rights Reserved. 私たちのこの取り組みを実施しながら、効果測定を進めている最中です。 タイムブロッキングをしていても、差し込みタスクや強制的に予定を入れられてしまうなど 思うように行かないこともありますが、現時点で以下の効果が測定できています。
引き続き、フィードバックループを回して、継続的改善につなげていきたいと考えています。 それで、どうなった? 確認観点 導入前 導入後 顧客要望リリースまでに要する 1件あたりの平均リードタイム 5営業日 1.5営業日 MTTR(障害復旧平均時間) 2.5営業日 1.0営業日 チケット在庫率 (未着手チケットの割合) 35.1% 0.5% ストレス(体感) ★★★★☆ ★☆☆☆☆ -
29 Copyright SHIFT Inc, All Rights Reserved. 1. とあるSREの嘆き~なんちゃってはつらいよ~ (2分)
2. ロードマップを意識した1on1で活路を開け! (2分) 3. まとめ (1分) -
30 Copyright SHIFT Inc, All Rights Reserved. ロードマップとキャリアマップをリンクさせた対話をすることで、 チームや組織レベルでの人材育成のアプローチが見つかる、ということをご紹介しました。 改めて言うまでもありませんが、ひとりひとりの成長が私たちのチーム、ひいては組織の成長に他ならず、
その集合知が私たちの価値ということになります。 人の成長は、マクロレベルでみると、緩やかな流線形を描いている様にも見えますが、 ミクロレベルで見ると、ふとしたきっかけで段階的にレベルアップする瞬間があります。 そうした瞬間をつくるきっかけは、アジャイルでもSREでも変わらず、たゆまぬ対話から産まれるものです。 システムの可観測性(オブザーバビリティ)なんていう言葉がありますが、 まずは自分や自チームに対してオブザーバビリティを導入することで突破口が見つかります。 今回の発表が、みなさまのご参考になれば幸いです。 まとめ