ワークロードを処理しないプラットフォームに専念する

はいそうしましたらLINE Yahoo株式会社から来ました
マルと申します
ワークロードを処理しないプラットフォームに専念するという内容で
ぜひお話しさせていただこうと思うんですけど
最初の最後のセッションですね
来ていただいてありがとうございます
最後のセッションの登壇者あるあるなんですけど
実は他のセッションですねドキドキしすぎてて
あんまり聞けてないので
もし皆さんよかったら他のセッション
面白いのがあったらXとか
投稿しておいてもらえると
後で僕が見直すのにすごく助かるので
こういうよかったセッションとかあったら
ぜひちょっとスラックじゃないXですね
Xの方に投稿してもらえると嬉しいです
というところでじゃあ早速登壇始めたいと思います
ワークロードを処理しないプラットフォームに専念するというので
ちょっと最初にこのタイトルについて説明したいと思ってまして
ここでワークロードを処理するって何ぞやなんですけど
例えばKubernetesクラスターを運用しているとかは
ワークロードを処理しているわけですね
とかあとはCICDのためのツール
タスクランナーであったりとか
ワークフローエンジンであったりとかを運用している人とかも
ワークロードを処理しているわけですね
その他開発者とかエンドユーザーとかのリアルタイム処理を必要とするものを運用しているものは
ワークロードを処理すると呼んでいます
この発表で処理しないって何かというと
ドキュメントとかですね
あとは開発者のローカルで動くようなCLIツールとか
そういったものはワークロードを処理しないものですね
スタンダーローンで動くようなものを処理しないものです
そういった処理しないものに専念しているプラットフォームとは何なのか
みたいな話をちょっと今日この場ではしたいと思っています
この発表で扱う内容ちょっと繰り返しになっちゃうんですけど
組織の構造とか働き方の事例になっていて
EmbeditとEnabling型のプラットフォーム
これちょっとなんかすごく不思議な組み合わせかもしれないですが
そういったプラットフォームのアプローチと成果について紹介したいと思っていて
より具体的な話をするとEmbeditのSREが横断組織のチームにいて
どうやってみたいな話とか何が悩んでるのかみたいな
そんな話をできたらなと思っています
特定の技術は全く扱いません
自己紹介させてください
約5年前ぐらいにLINE株式会社に入社しまして
LINEスタンプとか規制会とか
あとLINEのいろんなタブのSREを担当していて
LYPプレミアムっていうLINEや風PayPayプレミアムの立ち上げを行ったりとか
SREとして行ったりとか
それ以降も新サービスのSREとかいろいろ担当しております
これ見てわかる通り
実はプロダクト開発側なんですよね
横断組織というよりもプロダクト開発側に常にいて
そこのSREとして開発チームと綿密にやり取りをしていましたというところがあります
この発表で使う用語としてはなるべくちょっとチームトップロジーズの用語で説明をしていきたいと思います
共通の言語として一番多分この場では浸透しているのがチームトップロジーズかなと思うので
なるべくその用語を使っていくんですけど
ちょっと微妙にニュアンスが違ったりするところは補足させていただこうと思っています
具体的にはコラボレーションですね
相手チームと密接に協力する
もう一つのチームのように振る舞って一緒にやっていくみたいな方法とか
コンサルタントやエヴァンジェリストのように
相手が持っていない知見とか技術を導入支援する
もしくはエクサースのように
アザーサービスのようにサービスとか責任協会を明確にして
複数チームに同じようなサービスレベルで横展開提供するみたいな
こういった用語をちょっと使っていこうと思っています
もともとの私たちの成り立ちを最初に説明したくてですね
SREチームなんですけど
先ほども説明させていただいた通り
もともとは事業部側にいるエンベディットのSREチームです
それも1プロダクト1SREっていうのを決めてやっているチームで
LINEスタンプっていうプロダクトには1人とか
LYPプレミアムには1人とか
そういった形で開発チームにジョインして
SREとしてでもやっていくみたいな
そういったコラボレーション型でやっています
具体的にどんなことまでやってるのって話なんですけど
企画担当者の会議にも一緒に同席するし
デザイナーとの会議にも同席するし
新機能の仕様とかもしくはアイディア出しから一緒に参加する
リリースとかオンコールも開発チームと一緒に回す
信頼性に関わるイシューとかを一緒に開発していく中で
ヒアリングとかじゃないんですよね
一緒にやっていく中で発見して改善をするみたいなやり方をしています
このやり方が比較的それぞれ回っていて
ヒアリングしてるだけだとなかなか気づけないイシューとかもあったりするのを
勝手に発見してっていうんですかね
改善の提案をしてみたいなのでぐるぐるぐるぐる回ってきて
うまい良い関係とかつ良い成果を出せていたなと思っています
こういった形でも評価していただいたのもあって
2年前くらいからもっともっと欲しいって言われるわけですよね
うまく回ってるチームもっと頑張れって言われるわけなんですよ
そこで突然横断部署に移動するわけですね
もっと広い貢献をやってくれと言われるんですけど
ちょっと待てよと
私たちの強みともっと広い貢献ってすごいヤップがあるんだぞって話があって
プロダクトの開発チームと開発チームの両方に解像度が高いからこそ
できてることなんですよね
一つのプロダクトに専任していて
だから課題をヒアリングして回答をもらうとかじゃなくて
独自に一緒のプロセスを回していく中で
伴奏して発見して解決してるから
本当のイシューみたいなものにアプローチできてるとか
あと1プロダクトにSRE1人だけっていうのは
なんか制約のように思えるかもしれないんですけど
実はこれあえて狙ってやっていることでして
SREが例えば3人4人っていると
そのプロダクトの改善のために議論がSRE内だけでできちゃうんですよ
そうすると何が分かるかっていうと
開発チームを置いてけぼりにしてしまうというか
勝手に改善が終わってる状態でスタートしてしまうとか
そういうので改善するにも開発チームとの相談が必要であるっていう状況にするために
SRE1人だけみたいな状況にしているんですね
これが私たちの強みなんですけど
広く貢献するって何?みたいな話があって
そもそも1プロダクト1SREで
このコラボレーションのスタイルって
採用しない限りスケール一切できないんですよね
他の横断部署にある他のプラットフォームと同じように
エクサースのようにサービスとして提供しますみたいにすると
コラボレーションじゃなくなるので
私たちの強みが失われるわけです
じゃあこの横断部署に来てしまったが
私たちの強みを生かしてどうやって広い貢献をするのかみたいなのを
ひたすら悩んでいくっていうのが
2年前ぐらいの私の状態でした
そこでまず1つ目のプランとしては
トレインとトレーナーっていう考え方でして
いわゆる開発チーム内に
純SREのような
いわゆるSREプラクティスを開発チーム内に
浸透してくれるような人をどんどん育てていけば
開発チーム同士って当然やり取りをしてたり
社内LTがあったりとか
そういうのもあるので
開発チーム内でうまいっこ伝播してくれるんじゃないって期待して
社内開発チーム向けのハンズオンを増やしたりとか
そういったことをやっていたんですが
もちろん効果はあるんですよ
効果はあるんですけど
例えば直接サポートしてない
ちょっと遠い開発チームが
僕たちの例えば何かの参考にして
真似をして何かをやったとして
それを僕たちの成果って言っていいのかみたいな問題があって
やっぱり成果を説明できないと
ちょっとチームとしての持続性に疑問風がつくというか
説明しにくいところがあるので
成果の可視化がしにくくて評価が難しかったり
あとは効力も開発チームに依存しすぎていて
もちろんワンホップ目のチームAまでは
僕たちが何とでもできるんですけど
それ以降のさらに横に伝播していくという流れは
もう開発チームに依存しすぎているというのがあります
方向転換をしました
トレインズトレーナーは当然維持しつつも
それに依存しないようにするために
コラボレーションとファシリテーションを
組み合わせるという形にしました
コラボレーションも無期限にして
プロダクトチームに深く入り込んで
一緒に伴奏して
そこで小さな成功事例を作る
その小さな成功事例をパターン化して
抽象化して
コンサルタントエヴァンジェリストのように
いろんなチームに短期間で
イネーブリングしていく
こういう展開に変更しました
これ結構いいことがあって
実際にエンベディットした先で
何か試行錯誤をしてやったので
そのSREのエンジニアって
ある意味その分野のスペシャリストになっているんです
テラフォームだったり
クーバネティスだったり
もしくはオブザワビリティだったり
なのでイネーブリングするときに
プロダクトBとかCとかに
いろんな説明をするんですけど
当然スペシャリストとして説明ができる
みたいないい点もありました
しかもこれよくやると
成功事例を横に反過させようとすると
プラットフォームの制約にぶつかることがあるんですね
例えばLINEやHooだと
しばしば社内内製プラットフォームっていうのがあるんですけど
内製プラットフォームだと
これちょっと提供まだできてないんですよね
みたいなものがあったりして
そういうのに正確にぶつかるところを
プラットフォームチームに
フィードバックコントリビューションするっていう
まずこういうLGみたいなサイクルが
まず始まる状態になりましたと
特にエネーブリングが始まると
今までのエンベディットと比較して
接点が増えていくんですよね
開発チームとの接点が増えていく
なので実はプラットフォームへの
フィードバックの質も少し上がっていて
いろんなチームでこんなケース
ユースケースがある中で
最低限プラットフォームとしては
ここを担保してほしいです
みたいなフィードバックができるようになってくると
こんな感じでフィードバックの例なんですけど
単純に機能要望を伝えるのは
一番シンプルな例ですよね
あとはプラットフォームチームが
提供してくれているドキュメントが
当然あるんですけど
それってプラットフォーム側視点で書かれていて
使う側で書かれてないこともあるので
そういったドキュメントの修正とか
何ならドキュメントを代わりに書く
みたいなことも結構あります
あとはプラットフォームの
コード自体へのコントリビューション
プルリクエストポンと投げるとか
そういうのも全然やりますし
あとはプラットフォームを中心とした
エコシステムの開発
ちょっと数年前とかと
テラフォームIACみたいな流行っていて
今もやってますけど
社内だと
AWSとかGCP
Googleクラウドではなくて
社内プライベートクラウドなんですね
なのでAPIは提供されてるけど
IACのなんちゃらはないって状態なんで
テラフォームのプロバイダーを開発したりとか
あとは最近だと
そういったクラウドのMCPサーバーを開発したりとか
そういったことをプラットフォームチーム側がやるというよりは
開発チームのために私たちがやってたりもするというのがあります
ちょっとこの取り組みを
今までは具体的な話
僕たちのチームの成り立ちから発展した話をさせていただいたんですけど
ちょっと体系的な位置づけに振り返って戻ってみると
チームトプロジーズっていう本のチャプター8ですかね
組織的センシングっていう章があるんですけど
この実装の例になっていたなと思います
ちょっと読ませていただきますね
素早く行動するには環境に関するフィードバックセンサーが必要だ
このフィードバックセンサーの重要な側面は
IT運用部門のチーム
これ例えば私たちです
IT運用部門のチームを開発部門のチーム
これプラットフォームチームだと思ってください
プラットフォーム側のための高度なセンサー
入力センサーとして使用することだ
プラットフォームチームにとっての私たちがセンサーであるということですね
保守作業のコストを最小限に抑える最適化に取り込むんじゃなくて
そういった保守作業からのシグナルを
ソフトウェア開発稼働
プラットフォーム開発稼働だと思ってください
の入力として使用することが重要だみたいなことの
位置づけと同じことをやってるかなと思っています
さらにプラットフォームからエンベディットへっていうのがあって
こういった先ほどのLGが増えていって
プラットフォームチームにフィードバックをするようになると
今度はプラットフォームチームから私たちに対して
この機能どう?
ちょっと検証したいんだけど実験に手伝ってくんない?
みたいな
いわゆるファーストユーザー、パイロットユーザーとしての
シェアハネアがすごい立つようになってきます
なのでPOCを手伝ったりとか
実際のプロダクトのドックフォーディングをしたりとか
そういったことを頻繁にやるようになります
ここでようやくループが完成するんですね
エンベディットして成功事例を作って
それをパターン化して
いろんなチームに
イネーブリングしていく
イネーブリングして接点をたくさん持った結果
フィードバック、コントリビューションのプラットフォームに行って
そこでいろんな改善、新しい改善を試すために
またエンベディットのチームに
POCとドックフォーディングになる
これがぐるぐる回るようになると
これで4方よし
コラボレーション先としては
当然チームに入って
手を動かして改善してくれる
伴奏者がいることになりますし
ファシリテーション先でいうと
実際に解決された課題
その実例に基づいて
成功事例を整理して支援してくれる
プラットフォームチームはフィードバック
私たちとしては
横断組織に移った結果
いろいろ大変だったんですけど
スケーラビリティ確保して
チームの効力を出すことができると
ここまでは夢物語のような
すごくいいお話をさせていただいたんですけど
全然順調な話ではないです
ここまでは普通のカンファレンスで15分ぐらいですね
ここで終わりなんですけど
プラットフォームエンジニアリング会議は
運よく25分もお時間があるので
あと10分はひたすら辛い話をしようと思います
実際の苦労っていうのは
大体パッと思い付いたのは5つぐらいですね
開発をしたくなるんですよ
プラットフォームのっていう話と
成果評価難しいのは結局変わらないし
チームの活動の可視化ナレッジ継承みたいな話も変わらないし
リーダー育成大変だなとか長期休暇のサポートとか
そういった話がいろいろあります
ちょっとリアルな話をどんどんしたいと思います
これエンベディットしてた時もそうなんですけど
結局僕たちができるのって
あるチームに対して既存のツールとか既にあるプラットフォームの機能とかで
何らかの改善をしたりとか
そこの成功事例を他に横展開するとかなんですけど
結構プラットフォームチームこれ何とかしてくればあるんですよね
何なら自分たちでこれもやった方が早いわみたいなのもある
プラットフォーム作っちゃった方が早いわみたいなのも正直あるんです
でも一度そういったプラットフォームを持つと
皆さんもしプラットフォームを持ってたらすごく分かるかもしれないんですけど
何かメンテナンスし始めると
移行とかサポート問い合わせとかアップグレードとか
いろんな日々の運用タスクの負担が無視できなくなる
そうすると四方良しの根源であったフットワークの軽さですよね
そういうのが僕たちのチームから失われてしまうので
プラットフォームどうしても持てば解決できるのに
持っちゃいけないっていう縛りプレイをある意味してる
新しいツールどうしても導入したくなったら
プロダクトの開発チームがメンテナンスできるような風まで
ちょっとしてサイロなツールとして導入することもありますし
プラットフォームチームがX-Earthとして
社内サービス化をするところまで支援して頑張るしかない
みたいなところは
結構自分が手動かしたいみたいなのはすごいたくさんあります
こういったいわゆる手動かせば解決するじゃんを手動かさないんですよって
説明するのってなかなかやっぱり理解しづらいところもあるので
期待調整が重要だったりしますね
あとは個人成果の評価なんですけど
結局エンベディットもエンベディットもエンベディットも個人技なんですだいぶ
1プロダクトに1人がSREがエンベディットしていて
そこで生まれた成功体験をコンサルタントのように
いろんなチームに紹介するっていう流れなので
個人技が中心で成果が正直見えにくいっていうのはあります
そこの工夫としてはステークホルダーからのフィードバックをもらうっていうのを
すごく意識的にやっていて
半年に一度360度評価とかもあるんですけど
コラボレーション先のマネージャーと定期1on1とか
よく頻繁に持っていて
最近エンベディットしている方の働きはどうですか
期待値に見合ってますかとか
何かここ改善した方がよかったですかとか
そういうのはひたすらインプットとして入れて
それはまた個別にフィードバックしていくというようなことをやっていたりとか
また個人の評価軸を時間方向と空間方向っていう2軸で設定して
各メンバーSREのメンバーにもお願いをしています
エンベディット先を時間 エネーブリングを空間としています
ちょっと分かりにくいと思うのでもう一スライドあるんですけど
無期限で担当プロダクトに深く入り込んで
時間とともに信頼性改善するっていうのを
時間方向の改善と僕は呼んでいて
その成功パターンを横展開するっていうのを
空間方向の改善と呼んでます
最低限満たすゴールは常に時間方向の改善である
その先に余裕があれば空間方向の改善をしてくれっていう話をしていて
要は時間方向の改善をすると基本期待通りでした
空間方向 エネーブリング前できるなら
もう今期は頑張ったねみたいな
そんな評価をするようにしています
これ何でかっていうと
いわゆる僕たちが想像する最悪なコンサルタントを
イメージしてほしいんですけど
机上の空論みたいな
絵に描いた餅だけみたいな状態のって最悪じゃないですか
なので僕たちもそれを避けるために
なるべく実務
必ず実務に目指した改善をまず確保してから
それを横展開するっていうのを意識していますね
次がチーム内の業務
可視化とオンボーディング
これも結局個人技ゆえにという話なんですけど
それぞれのメンバーが何をやってるか分からないんですよ
本当に
ある時は急に会話したら
MCPサーバー作ったんですけどって
僕リーダーなんですけどね
作ったんですけどって言われて
作ったのってなるみたいなことも結構あったりとか
でも開発チームが必要だったんで
って言うとなるほどねってなる
また俗人性が強く
新メンバーの習熟が難しいっていうのも
同じような個人技ゆえの問題ですね
これは必要経費としてチーム内の共有の時間を割くようにしています
毎日1時間ですね
これ結構やりすぎって思われるかもしれないんですけど
結構これでも足りないと思っていて
今日何やった?明日何やる?みたいなミーティングを
大体15分から20分くらい使って
共有する回をした後の
余った時間の40分をモブコードレビューにして
みんなで画面共有して
ひたすら各プロダクトのコードをレビューしていくんですね
プルリクエストとかを
ここは例えば何でこのテラフォームはこうなってるのかとか
マニフェストはこういう観点でレビューした方がいいよね
みたいなのをひたすらやっていくと
例えばテラフォームが得意な人もいれば
Kubernetesが得意な人
いろんな人がいるんですけど
そういったスキルのトランスファーに
つながってるかなと思います
もう一つは
これも本当に繰り返したんですけど
ワークロードのあるプラットフォームを持たないっていう制約が
本当に重要で
運用が必要なプラットフォームを持ち始めるとですね
俗人性の問題が本当に致命的になるんですよね
例えばKubernetesを運用し始めると
Kubernetesの求人が生えてくるんですよ
それはKubernetesを運用できる人を採用しないといけないから
みたいな話で
そういうところで
属人性の問題って割とプラットフォームを持つから
発生するっていうところもあるので
実はジェネラリストとしている分には
あんまり属人性って問題にならなかったりします
新しいメンバーは必ず既存のメンバーとバディを組むというのを
徹底していて
私たちの活動の哲学が割と多分独特というか
強い制約を持っているので
どれだけシニアなエンジニアでも
文化的に馴染むみたいな時間が必要だったりしますね
あとはリーダー育成のジレンマ
これもしかしたらどのチームでもあるかもしれないですね
メンバーはあるプロダクトもしくはある特定の技術に
すごく深く知識を持っている
一方でリーダー
僕とかは今回紹介したような構造を変える
もしくは情報の流れを変える
もしくは何を必要経費として割り切る
とかこれは制約として徹底するみたいな
ちょっと別のものが
別の技能知識が必要になってきたりします
それどうやったら
要はそのギャップを埋められるかという話なんですけど
私たちのこの取り組み
今話したエンベディットとエネーブリングの取り組みを
プラットフォームにするということをやり始めています
そのプラットフォームをサービスのリーダーの育成の場にする
ということなんですけど
もうちょっと詳しくします
いわゆるメタプラットフォームとしての
SRE活動という状態に今していて
例えば今までやっていたコラボレーションですね
成功事例を作る
エンベディットするというのも
サービスです
ファシリテーションとして
コンサルタントのように
ハンズオンしましょうとか
何かそれもサービスです
つまり全てXアザーサービスの形で
サービスができて
要はそれはSREプラットフォームです
という状態にできるわけですね
そうすると各サービスに
オーナーを任命することができて
オーナーを任命するってことは
リーダーの候補の育成の場にできるってことなんですね
そのオーナーの主な仕事って
例えば何かっていうと
小さな成功のパターン化ももちろんやるんですけど
イネーブリング先ですよね
イネーブリング先のチームを見つけるために
社内マーケティングもやります
どういうチームが
どんな課題に困っているのかなとかを調べたり
どうですか
来週から始めてみませんか
みたいなこともやったりする
エヴァンジェリストとして活動して
実際にやってみたりとか
必要に応じて
フィードバックコントリビューションもやるし
あとは他のメンバーが
同じようにエヴァンジェリストとして活動できるように
教育もしたりとかする
なんかこんな感じですね
一番上のがエンベディットの
いわゆるマルって僕なんですけど
僕がオーナーとなってやっているところで
アリスさんは
SLA SLOのブートストラップとか
インフラスコードのオーナーとして
4週間のプロジェクトみたいな回す
みたいなことをやっていて
ボブは多分これはあれなんでしょうね
新卒なのかな
2時間のハンズオンセッションだけをやるとか
そういう感じでちょっとオーナーとして
動いてもらって頑張ると
最後長期休暇のサポート継続なんですけど
これも結局個人利は高い上なんですが
エンベディットを先の場合は
実はSREがサポートするというよりは
開発チームたちの中でサポートしてもらう
どうしても必要なときは私たちも参加するよと
エンディングはこれもリーダーの業務の一環ですよね
チームのリソースマネジメントって
リーダーの業務の一環なので
オーナー考えてねって言って
基本的にはチーム内教育
自分の代替を作ってもらう
っていうのをやってもらったりしてます
最後のスライドですけど
ワークロードを持たないから動ける
動けるから広げられるという形で
この下の図のループですね
このループがうまく回るように
ちょっと作っているというお話でした
ありがとうございます
はいありがとうございました
なんでかQAがあるので
QAに回答していただきたいなと思っております
まずPOCとドックフーディングのサイクルですが
ワンサイクルあたりどれくらいの期間で実施されていましたか
またフィードバックの対応の優先度決めはどのように決めていましたか
はいありがとうございます
すごいいい
しかも結構痛い質問ですね
POCとドックフーディングのサイクルは
そのフィードバックの内容に本当によります
例えばGitHub Actionsのセルフランナーの社内で欲しいですみたいな
プラットフォームとして提供して欲しいですみたいな
ケースがあったりしたんですけど
そういったやつとかも1,2ヶ月ぐらいで終わるし
それも何ならフィードバックから本当に数週間
1,2ヶ月も早いものですね
ただやはりフィードバックって
が受け入れられるかどうかって
プラットフォームチームの状況にもよるんですよ
リソースの状況にもよりますし
ロードマップにあるかないかみたいな話もあるので
基本なんか強制はしないようにしていて
こういう意見がありますっていうフィードバックを
基本的にするのと
コードにコントリビュートした
よかったら僕たち勝手に作っておきますよ
みたいな感じでフルリクエスト投げていいですか
みたいな感じのコミュニケーションをして
あとは決定はプラットフォームチームに任せることが多いですね
はいありがとうございます
次の質問として
成果あるエキスパートとはいえ
チームによってファシリテーションのような
短期の参加で信頼を得るに至らず
うまく機能できないこともあるのではと思いますか
どうなのでしょうか
そのための工夫はあるのでしょうか
いやいいですね
いやでもこれってちょっと逆説的に考えると
他のチームから窓口のように
信頼を得てる人って誰なのかって考えると
割とリーダーだったりしませんか
なんか他のチームの窓口になって信頼得て
この人が言ってるんだからそうなんだろうとか
そういうことができてるってことはリーダーなんで
これがどうやったらできるかみたいなのも実はリーダー育成の一環としてなってます
なので結構苦しんでるメンバーも多いです
ただ基本的に見方が多いので
幸運にも私たちの今までやってきた積み重ねで実績を知っている人もいますし
トレインザトレーナーじゃないですけど
ああいうことをやっている人チームだからまたお願いしたいなみたいなところで
事前に開発者側で理解してもらっているっていうのはあるので
月並みな言葉で言うと信頼貯金が既にあるからに近いと思います
ありがとうございます
エネーブリグについて2から4週間で展開から課題継続するまでなのでしょうか
どこまでサポートするのか気になります
例えば具体例で話させていただくと
CUJ SLI SLOみたいなのを定義しましょうみたいなやつなんですけど
よくあるのはまずCUJとは何ですかとか
これがあると何が嬉しいんですかを最初に期待値調整します
ここまで私たちはサポートをするんだけど
ここはもうこの手離れしてあなたたちがやっていくんですよ
そうなった先には例えばこういうこともできるようになっていくんですよみたいな
さらに成功事例を紹介して
期待値の調整とモチベートするみたいなところをまず第1回でやって
それが合わなければ一旦じゃあ今はタイミングじゃないですねってなります
それでも時間を費やしてやりたいですという話で
合意ができた場合はそうですね基本自走できるまでやるんですけど
定期的にアフターケアじゃないですけど
アフターサポートのような形でミーティングに突発でお邪魔したりとか
SLOとかって定期的にレビューしたりするんですよね
そのSLOが今も境外化されてないかとかそういうのを見に行ったりしますね
最後です
独特な文化とおっしゃられていましたがこの文化に至った考え方はチームトプロジー以外では何か影響を受けたものありますでしょうか
ああ何でしょう何でしょうね
正直僕はこのチームトプロジーズに当てはめたのはこの発表のために持ってきたものなので
もともと思っていたことがたまたまチームトプロジーズの用語で整理できるなと思って話している内容で
もっと言うともともとプラットフォーム前職の方でプラットフォームの開発運営をしていたんですね
そこで開発をするとプラットフォームって思った使われ方をしないケースとか想定外に使われ
もっとこんな使い方してくれたら解決するのになとか結構いろいろあって
うまく使うにフォーカスするチームがいた方がいいなって思ったが一番始まりですね
はいありがとうございます
お時間になりましたので本日は発表ありがとうございます
改めて拍手お願いします