Platformに“ちょうどいい”責務ってどこ？ 関心の熱さにあわせて考える、責務分担のプラクティス

はい、ではプラットフォームにちょうどいい責務ってどこ、関心の厚さに合わせて考える責務分担のプラクティスというところで、Tokuhara が発表させていただきます。
今日は貴重な場をご用意いただきありがとうございます。
ではまず自己紹介をさせていただきます。
私、株式会社エスティでSREとかプラットフォームエンジニアリング領域を担当しているTokuharaと申します。
こういった大きな場で発表するのを実は結構初めて、2回目とかなのかな。
なので結構緊張していて、ちょっとうまくしゃべれるか分かりませんが、温かい目で見守っていただければと思います。
では内容に入っていこうと思います。
プラットフォームエンジニアリングって具体的に何をすればいいのでしょうか。
ソフトウェア開発とデリバリを対象にセルフサービス型のプラットフォームを提供することになります。
その提供形式はこちらに書いてある。
皆さんもすでにご存知だと思うんですけれども、こういった形で社内、IaaSだったりとか、PaaSとか、プロダクトから利用される共通機能とか、
あとはCICDのパイプライン、また開発ドキュメントの管理とかといったところをやっていく。
いわゆる多岐にわたる機能とか基盤を提供する領域のことになっております。
実際に自分が何かプラットフォーム機能を作りますよとなったときに、どのレベルまで作り込んで、
どこからどういう運用の線引きをしていくといいのだろうかとかっていうところで困ったことないですかね。
結構自分は困ったことがあって、今STでこんな感じにしたらうまく回っているぞっていうところがわかったので、
今日はその話をしていきたいなと思っております。
今日話すことですね、アジェンダになります。
じゃあどこで責務、責任範囲の線引きをするかという話をしていく前に、
STの事例をちょっと紹介させていただこうと思っております。
まずはSTのプラットフォームチームの紹介をさせていただいて、
次にプロダクトチームとの関わり方ですね。
そこからちょうどいい責務、責任範囲って何だろうっていう風な流れで話をしていければなと思っております。
よろしくお願いします。
ではまずSTのプラットフォームチームについて話をしていきます。
我々のミッションですね、開発者の開発がプロダクトの価値になるというものをミッションとさせてもらっております。
STはコンパウンド戦略を実践しているスタートアップになっています。
スタートアップでありながら、複数プロダクトを同時展開して、
顧客が持つ複雑な課題を解決していくっていう戦略を取っているスタートアップになっています。
プラットフォームチームはその中で何をやっているかっていうと、
その実現に向けて顧客向けにプロダクトを作っているわけではないんですけれども、
その顧客向けプロダクトを作っているそのプロダクトチームに向けて、
組織横断で必要な機能提供と、
組織全体の開発フローの整備をしている形になっております。
そういったものを通じて、プロダクト開発がプロダクトの価値に直結する状態を作り出すというのが、
我々のミッションとなっております。
プラットフォームチームの遠隔についても少し触れさせていただくと、
最初はチームがあったわけではなくて、
どの組織、チームにも属さず、組織間で発生するボール、
対応した方がやささのボールを対処するボランティア的な集まりから始まった形になっています。
そのボランティア的なメンバーが最初、認証基盤の構築だったりとか、
プロダクト立ち上げにおけるフットワークの軽さを作り出すために、
プロトタイピングアプリをボタン一つで爆速に立ち上げるというようなツールを作るというところから、
機能提供を始めた形になっております。
そういったものを繰り返していって、プロダクト数が増えていって、
また認証認可を始めたとする基盤機能がしっかり使われ始めたというところもあって、
同時に同じく横断的に組織課題を対応していたSREチームと合流して、
プラットフォームチームとして正式に動き出したというような遠隔になっております。
次にですね、我々今プラットフォームチームが提供しているものを紹介したいと思います。
ちょっとですね、どういうふうに紹介しようかなと思ったんですけれども、
ちょっといったいどんなインタラクションをしながらプラットフォームを提供しているといい、
っていうところを見せたかったので、ちょっとこのような図にさせてもらっております。
どの状況においてもこの図の通りではないんですけれども、
平均するとこんな形の関わり方を持ってプロダクトを提供してますよっていうところで、
機能を配置させてもらってます。
ちょっと説明していくと、X Other Serviceと分類されるものですね。
こちらは結構シンプルな機能とかが多くてですね、
例えばリリースとデプロイを分離するフィーチャートグルの機能だったりとか、
あとはプロリックベースで環境を作るプレビュー環境とかっていうふうな
単機能のものが多くなっております。
次にコラボレーションですね。
こちらはプロダクトチームと共に共同して育てていくというか、
作り上げていく、運用していくっていうような、
そういうふうなコラボレーションをしている機能とか基盤なものが入っていて、
だいたいオブザーバビリティだったりとか、
データアクセス基盤とかっていうようなところがこちらに入っております。
最後にファシリテーションですね。
こちらは他のチームを支援している形の機能になっていて、
具体的にはテラフォームみたいな形で、
低いレイヤーのものだったりとか、
認証認可とかっていうセキュリティの結構厳しいものっていうものに関しては、
ファシリテーション的な形で提供しているふうになっております。
そして、プロダクトチームとプラットフォームチームの関わりについて、
ここから話していこうと思います。
すいません。
まずチーム体制とプロダクトですね。
大会的に発表している顧客向け提供プロダクト数は10になっております。
未公表も含まれています。
その裏にですね、先ほど話した認証基盤とか、
フィーチャーとグル環境とかっていうのがあって、
そういった裏側の支えるためのプロダクトも含めると、
もうすごい数、実はあったりします。
それをどういうふうな形で開発しているかっていうと、
エスティアの事業部制をとっていて、各事業部に開発ユニットがいて、
その開発ユニットがですね、
1ユニットあたり1プロダクト、もしくは複数プロダクトを持って面倒を見ているような形になっております。
我々プラットフォームチームは横断になっているので、
この事業部に所属せず、事業部をまたぐ形で存在するようなチームですね。
こちらの形になっております。
そして、プロダクト、次にソフトウェア開発の割合のことも少し話しておきますと、
プロダクトチームはですね、インフラを含めて担当プロダクトに関わる行動を
全てに責務を持っているというような形で定義させてもらっております。
実際のリポジトリの形式ですね、
プロダクトごとにモノレポ形式でリポジトリを作っていて、
このリポジトリの形式も我々が作っているツールからですね、
ボタンを押して立ち上げると、
この形でリポジトリが払い出されるようなことになっております。
で、GitHub Actionsを使っているので、
そのCICDフローですね、アプリケーションのデプライだったりとか、
インフラのアプライとか、これも全て含まれている形になっています。
あとバックエンドとかですね、フロントエンドも我々が持っている認証基盤と連携する形の
セッコードが入った必要最低限の実装がされていたりとかっていうような状況になっております。
ちょっとゴールデンパスを実装して使ってもらうような形でツールを提供している状況です。
ではですね、プロダクト開発者の方々にどういう観点でプラットフォームを届けるかを説明すると、
こちらの書いた基準、4つの基準ですね。
からどういったものが必要かっていうのをリストアップしていき、
会社の戦略とか開発状況ですね。
これから会社としてどういうふうな方向性でプロダクトを展開していくかとか、
直近半年でこういうふうなインシデントが起きてるよねっていうところから、
もっとここ強化しなきゃいけないねっていうものを見つけて、
それを並べた上でリストアップして、
プロダクト何を作っていくかっていうのを決めていくことになっております。
例えばですね、プレビュー環境とかの話を出すと、
これ日常の会話から拾い上げた課題になっていて、
チャットツールですね、プロダクトチームのチャットの中で、
ステージング環境をちょっとこのブランチをデプロイしたんで貸してくださいみたいな
コミュニケーションが結構起きていて、
それがですね、一つのプロダクトじゃなくて複数のプロダクトチームで起きていたっていうところで、
もうちょっとプレビュー環境がないと開発効率すごい悪いなっていうところとか、
そういった潜在的なニーズが見つかったので、
これを実装せたというような形になっております。
ではですね、作るものが決まったら、
じゃあどこまで作り込んでいくのが良いか、
プラットフォームとしてどこまで提供していくのが良いかっていうのを
考えていかなければいけません。
ここから実際の事例を見ながら、
その辺りの説明をしていければと思っております。
まずはデータアクセス基盤を作ったときの例ですね。
まずは背景です。
エスティーではデータアズアサービス、
ダースに分類されるプロダクトを多く提供しております。
ダースですね、エスティーが持つエスティーの強みであるデータ、
データベースをいい感じのUIをつけてお客様に提供して、
その上でお客様は分析をしたり調査をしたり、
日常業務で必要な情報を調査していただくようなサービスとなっております。
なので、エスティーではこのデータをコアにしたプロダクトがすごく多く存在していまして、
なので、そのデータをどう取りますかっていうのは、
かなりうまくいけば結構いろんなところに効いてくる施策となります。
データ自体はですね、データチームというところがデータを作ってくれていて、
そのデータチームの方々が持っているデータ基盤ですね。
そちらにありまして、各チームがこれまではですね、
このデータアクセス基盤ができるまでは、
バッチ処理的に各プロダクトのデータベースの方にロードしているっていうのが、
この基盤ができる前の状況でした。
なので、他のプロダクトでもですね、
例えば同様のデータを使いたいっていう場合は、
その分同じ処理を書いて、
同じデータ基盤にある特定のデータが、
複数プロダクトの方のデータベースに入っていくっていうような、
同じデータなのに複数プロダクトのデータベースに入っているっていう、
ちょっと残念な状況だったっていうような状況になっております。
その背景からですね、
課題として、このままプロダクト数が増えてくると、
データの取り回せで開発効率に影響が出るよねっていうのが、
もう分かっていた形になっております。
例えば開発効率もそうですし、
処理の複雑感も出てくるっていうような形になっております。
さらにはそのデータもですね、
どのプロダクトならこのデータを使っているかっていうような、
いわゆるデータガバナンスとかっていうのもあったりするので、
その運用が破綻しないためにもですね、
やっぱり一箇所で管理した方がいいよねっていうところから、
データアクセスキーワンを作ろうというような話になりました。
実際にデザインドックスですね、
STでは基本的に大きな変更をする場合は、
デザインドックスを書く習慣があって、
こういった場合もデザインドックスを書いて、
全体から意見を募っていた形になります。
実際に書いて出すとですね、
すごく反響があってっていうのも、
ほとんど全てのプロダクトに関わってくるコア機能ってなってくるので、
すごく関心が高かったっていうような形になっております。
さらに、そのデザインドックをベースに検討を進めると、
問題も出てきまして、
共通化に伴うよくあるスポフだったりとか、
いわゆるデータを整合性の問題とかっていうところですね。
スポフに関しては、
できる限りインフラメンでの常直化を行うことや、
データベースのパラメータチューニングですね、
セレクト本の最大長さとか、
メモリをすごい使うクエリが来たら、
クエリをキルするようなパラメータをチューニングしたりとかっていうのをして、
一旦は一通り改善はできたかなっていうところはあるんですけれども、
まだまだやっぱし、
そこそこメモリを使うクエリが大量に飛んでくると、
やっぱしOMとか置けちゃうので、
そこら辺はまだ一定改善が必要になってくるところかなというふうな形です。
さらに整合性に関しても、
これまでは直接DBを見ていたっていうところから、
一個間にプロダクトが入るって形になるので、
プロダクトチームが期待するデータの形、
型っていうところと、
その差分が出ないようにするような対処が必要になってくるっていうところでですね、
ここはデータ基盤側の方々と、
協力して、サーキットブレーカー的な実装とかをして、
おかしいデータが連携されないような仕組みなどで対処している形になっております。
さらにですね、
2点目ですね、
データの提供範囲っていうところも、
かなり責務の範囲ですね、
線引きが難しくて、
ここをもう少し具体的な話をさせていただくと、
データ範囲については、
全部提供したいプラットフォームチームっていうところと、
やっぱし開発効率的に懸念があるので、
柔軟性が欲しいプロダクトチームというような形になっています。
我々としても開発効率を落としたくはないというのはあったので、
条件付きという形で方針を定めてやっていった形になっております。
その条件がこちらに書いた形になるんですけれども、
例えば既存処理の時間によってロジックが複雑化したり、
開発へのデメリットが大きい場合は、
基本例外として、
データアクセス基盤を使わなくてもいいですよというような例外を作ったりとかですね。
あと1箇所に処理が集まるので、
やっぱり開発が遅くなるんじゃないかっていうようなところに関しては、
必要に応じてプロダクトチームからのプロジェクトも受け入れ、
そこの整合不正はプラットフォームチームが担保するみたいな形にとっております。
なのでこの3点目とか結構良くて、
プラットフォームチームが整合不正担保して、
プロダクトチームからのプロジェクトを受け入れるっていう風なやり方にしたのは、
結構このコラボレーションの形にしたのは、
結構個人的には成功だったのかなと思っております。
次にですね、インフラ基盤の事例の話になっていきます。
SDではプロダクトごとにVPCを持っていて、
VPCレベルで分離されている状態になっています。
さらにそのインフラコードもですね、先ほど話した通り、
各リポジトリにあって、
そのCICDフローもそのプロダクトリポジトリに紐づくような形になっていました。
この設計をしたときは、まだプロダクト数も少なくて、
特に大きな問題はありませんでした。
しかし、プロダクト数がどんどんどんどん増えてきたっていうところもあって、
課題が現在化してきて、
今、VPC間の接続にトランジットゲートウェイですね、
AWSのトランジットゲートウェイを使っていたりするんですけど、
特にVPNも専用性も使っていないのに、
トランジットゲートウェイだけでVPCをつなぐので、
コストがどんどん高くなってくるとかですね、
あとインフラ更新ですね、
テラホームモジュールとかでいろいろ共通監査機能とかを提供してたりするんですけれども、
そういったところの変更が入ったときに、
プロリクを出してアプライを投げるっていうところが、
どんどん数が増えてきていて、
すごく運用がつらいみたいなところがあって、
VPC統合してインフラのモノリポーズクローズみたいな話が、
これ結構直近の話ですね、起きてたりします。
同様にですね、
なんでこの変更もデザインのクソを書いて共有したらですね、
皆さん、よし、何、お願いしますみたいな感じになっております。
っていうのも、もともとアプリケーションからレイヤーが遠いところにはなるっていうのももちろんありますし、
あと、やっぱりインフラをかける人っていうのは、
まだS2には少ないっていうところがあって、
なんで、もともと私、SREとしてもですね、
テラホームを覚えるよりかは、
きっちりビジネスロジックのコードを書いて、
価値を出してくれと思っているので、
そこは全然私の方でやりますよっていうのはよく言ったりするんですけども、
そういったところもあってですね、
基本的になんかインフラの設計がどのプロダクトにおいても、
全然、なんでしょうね、ブレがないというか、
そういうふうな形になっているので、
もう皆さん、よし、何、お願いしますっていうような形になっていたっていう状況になっております。
で、ですね、そういった事例から、
じゃあ本題のプラットフォームにちょうどいい責務ってどうだろうっていうのを、
ちょっとここから話していきたいなというふうに思います。
先ほどの事例でも話しましたが、
提供する基盤とか機能に対しての関心というものの差があります。
それはですね、提供する機能がどのレイヤーのものなのかっていうところだったりとか、
いわゆるそのプロダクトの事業状況ですね、
PMF前なのか、それとも後なのか、
それとももう成熟しきって安定運用状況なのかとかですね、
あとはチームの状況ですね、チームの人数とか、
チームの今の状況、開発状況とかっていう課題とかですね、
そういったところからですね、やっぱりその時の出したデザインドックスに対する関心が
全然違うなっていうのが見えてきております。
なので、プラットフォームチームとしては、
じゃあその温度差を前提に、
どういった責務をすればビジネスをどんどんどんどん前に進められるかっていうのを考える必要があります。
最初ですね、私が想定していた責務の線引きの図がこちらになるんですけれども、
ちょっとすみません、これすごいイメージ図ですね、
クラウド責任分解モデルっていう図があると思うんですけど、
ちょっとそれを無理やりプラットフォームに当てはめてみたら、
ちょっとコシャツになっちゃったっていうやつなんですけれども、
機能単位でもちろん変わるとは思っているものの、
同じ機能、基盤の中ではですね、
この線引きって一律だと思ってたんですね。
っていうのも、ちょっともともとSに来るまでは結構大きな企業で働いていて、
基本的に責任分解点、すごいきっちり分けるような環境にいたので、
なんかそれを全然いけるかなと思ったら、
やっぱりISTみたいなスタートアップとかだと、
全然その事業の体制も、プロダクトの状況も違うので、
全然この考え方とうまくいかなかったっていうふうなことになっております。
なので早々にこの考え方を捨てた形になっております。
実際にですね、責務の線引き、固定ではなくて、
柔軟に変えていこうっていうふうな考え方に仕事をしていって、
同じ基盤とか機能を提供するにしても、
対面するプロダクトだったりとか、
プロダクトチームごとに関わり方を変えていくってことが大事なのかなっていうふうに思って、
このような図になっております。
それはですね、プロダクト状況、それによって我々プラットフォームの地域提供する機能に関しても、
関心の度が変わってくるので、例えば、成熟して安定のようになっていれば、
データアクセス基盤からデータを取得して、そこのビジネスロジックだけを作り込んでいただくような、
その責務との線引きだったりとか、
また、PMF全顧とかってすごい機能拡張とかが入ったりするので、
どんどん機能を拡充して顧客に提供できる価値を増やしていくっていうところからですね、
自分たちで欲しいデータ、欲しい機能、欲しい機能を実装してプロディークを出してもらい、
プラットフォームチームとしては、そこの整合性だけを担保するような形ですね、
この真ん中のやつですね、かなりプロダクトBチームが持ってくださっているような形だったりとか、
はたまた本当に立ち上げ機ですね、
とりあえずなんかいけるかもしれないから立ち上げてやってみるかっていうときには、
全然人がいないので、
ちょっとすみません、ここの実質を全部お願いしたい、
こういうふうなロジックなんですっていうのを全部お願いするような関わり方ですね、
いわゆるちょっと、どちらかというとコラボレーションというよりかは、
もうファシリテーションになっちゃうんですけれども、
そういった関わり方でやっていくというような形でですね、
チームに合わせて、その状況に合わせて、
そのスキームとかインタラクションを微妙に変えつつ対応していくことで、
なんかうまく回るぞっていうところが見えてきた形になっております。
ただですね、一律で線が引けるものもあって、
それはシンプルで単機能を提供するようなものですね。
例えば、最初に話したフィーチャートグルの例とかなんですけれども、
こういったものはですね、本当にすごいシンプルな機能ですね。
APIに投げて、その結果、ブールで返ってくるとかっていうのは、
単純な機能とかであれば、これは責務の変更の仕様がなく、
もう全て一律みたいな感じの考え方ができるので、
作る機能とかによって、本当ここら辺の考え方を柔軟に変えていかなきゃいけないなというような形になっております。
まとめるとですね、機能ごとに責務は一律でないことの方が多いですよっていうふうな形になっております。
プラットフォームチームとしては、そのプロダクトの事業状況とか、
開発チームの状況、両方を見つつ、関わり方ですね。
それがXアザサービスなのか、ファシリテーションなのか、
コラボレーションなのかを柔軟に見定めていく必要があります。
プラットフォームはみんなで育てていくべきものであって、
適切にいったチームを巻き込みながら利用者ですね。
巻き込む、コラボレーションをしながら利用者とかをプラットフォームしてんで、
ちょうどいい責務を作っていくことっていうのが大事になっております。
最初の方でプロダクトの図を出したと思うんですけど、
チーム、関わるチームによって、このデータアクセス基盤のものが
ファシリテーションの方にあったりとか、
ちょっとXアザサービスの方に近づいていったりとかっていうような形になっていて、
そういった形でですね、結構柔軟にいろいろ責務を考えていかなきゃいけないなっていうのが
最近分かってきたことになっております。
どこのページまで話したっけ。
ですね。
ただですね、そういうふうな柔軟にやっていくっていうところもあるんですけれども、
ちょっとプラットフォームチームが責務をしっかり握っておくべきものもあって、
それが何かっていうと、基本的にはセキュリティ周りとか監査周りですね、
アクセス権限と守るべき要件があって、
それを継続して運用していく必要があるものとかは、
基本的にはプラットフォームチームで一箇所で管理しておきましょうっていうのは、
これは間違いなくやっておいたほうが良いものになっております。
さらにもう一個ですね、組織で共通化しておくことで、
プロダクトの価値とか開発効率に直結するようなもの、
例えばアプリケーションのエコシステムの設計だったりとか、
開発フローとかはしっかりプラットフォームチームが握って、
どの組織にいても、どのチームにいても同じ形で開発ができるっていうのは、
しっかり会社として一つ握っておくほうが良いかなと思っております。
逆にそれ以外は柔軟に見つつ、状況を見つつですね、
柔軟に変えていって良さそうな気がしております。
じゃあ最後まとめですね。
責務の線引きは固定ではなく、
プロダクトを取り巻く状況に合わせて柔軟に変えていきましょう。
それに行くとうまくいく感じがしております。
守るべきところはプラットフォームチームは、
責務をしっかり握っておきましょう。
それ以外はチームの状況に委ねて、
共同しながらやっていきましょうというような形になっております。
ただですね、今個人的にちょっとふわって思っているのが、
エスティでもですね、
今はこの状態でうまくいっているんですけれども、
今後プロダクト数がまだまだ増えてくるとか、
組織数がまだまだどんどん拡大していった場合に、
多分この通りでいくと結構運用破綻するんじゃなかろうかと思っていて、
ちょっとなんで、これから先どうやっていこうかなっていうのは、
引き続き模索していくような形になっております。
最後ちょっと時間がありますので、
ちょっとエスティについて、少しだけ。
エスティですね、産業の進化をさらに開くというパーパスで、
日々業務に当たらせてもらっております。
エスティ何をやっているかというと、
商業用不動産のサース、ダースを作っている会社になりまして、
商業用不動産というとオフィスビルだったりとか、
ホテルだったりとか、物流施設だったりとかっていうようなものを作っている会社になっております。
そういったものをちょっといろいろやってたりするんですけれども、
ちょっと時間がなくなってきた。
最後ですね、ちょっとエスティをしろっていうところでですね、
エスティも常にカジュアル面談を受けていたりとか、
エスティのブログも結構活発にブログを書かせてもらっております。
最近はですね、ポッドキャストも結構頻繁に更新していて、
YouTubeミュージックとか、他のポッドキャストのやつとかでも全然聞けるので、
もし興味があればぜひぜひ聞いてみていただければと思います。
はい、私の発表は以上になります。
ありがとうございます。
はい、ありがとうございます。
ではですね、何点かQAが来ているので、
ご回答いただきたいなと思っております。
はい、まずはじめに、データアクセス基盤に対して、
プロダクトがデータを新規に追加する場合、
データアクセス基盤へのスキーマ変更や、
データアクセス基盤へのインサートロジックの実装は、
プロダクト側で実装されているのですか?
そうですね、これはどちらもあるかなと思っていて、
立ち上げる方が結構強めの方とかであれば、
もう全部自分でやっちゃいますし、
そうじゃない方とかに関しては、
プラットフォームチームでサポートしながら、
一緒にやったりとか、
時間がなければこちらでやるというような形で、
やらせてもらっております。
はい、ありがとうございます。
悪く言うなら、
プラットフォームチームが全体の生産性の、
ボトルネックになりそうだなと思いました。
プラットフォームチームがサイロ化せずに、
開発チームと上手にコミュニケーションを取るために、
工夫していることはありますか?
確かにおっしゃるとおりだなぁー。
会話を結構しっかり密にとっているのかな。
オフィスに結構行くことが多くてですね、
オフィスに行くと、自分もだし、
他のチームメンバーもそうなんですけど、
業務しているというよりかは、
いろんなチームの方々と話して、
困っていることとかっていうのを、
先回りして聞くような動きをよくしているので、
そういったところからですね、
急に話が上がって困ったっていうところじゃなくて、
ちょっと粒っていうんですかね、
そういう課題の粒とか早めに拾い上げておいて、
それに備えるみたいなことはやっているかなと思います。
はい、ありがとうございます。
プレビュー環境の構築はどのように実現していますか?
プレビュー専用のクラスを自動構築するのか、
データ基盤からリソースを全部作成するのか、
どのように知るのか、気になりました。
はい、プレビュー環境はですね、
ブログにも実は書いていて、
実はデータベースはですね、
ステージングのものをそのまま流用させてもらってます。
っていうのも、先ほど言ったの、
ダースっていう形になるので、
あまりデータを書くような処理がないんですね。
なので、データベースはステージングのものを共有しつつ、
同じECSクラスターにECSサービスと、
ALBのターゲットグループとリスナルールを
早すみたいな形でやらせてもらってます。
はい、ありがとうございます。
プラットフォームの現状に満足せず、
今後もいい関わり方を模索するとのことでしたが、
定量的にプラットフォームの状態を図るアプローチは何かありますか?
いやー、いい人なんですね。
すごく、
そうですね、
過去にホーキー図だったりとか、
いわゆる障害発生率とかっていうのを計測していたことがあるんですけれども、
なんか結局、
ハックができちゃうじゃないですか、
っていうところもあって、
なんかどれもしっくりこなかったねっていうところになって、
現状そういうような答えを言うと今ないっていうところになるんですけれども、
ちょっと今、
いろいろ試した結果ないっていうような状況ですね、
なんかちょっとまだ模索してるような形になってます。
はい、ありがとうございます。
コンテナロードバランサーの増減などインフラ構成を変更する場合は、
エンジニアだけで自由にできるのでしょうか?
以前、アプリインフラチームでDockerコンボズヤブルを共同管理して、
リリース体験が悪くなったことがあります。
基本的には増減は特に関係なくやっていただいている形になってます。
そうですね、コンテナロードバランサーの増減、
そうですね、
コンテナ数はオートスケーリングもあったりとかして、
ロードバランサーは、
新しい環境を立ち上げれば勝手にロードバランサーも入ってくるっていうので、
全然やってもらっているような状況ですね。
ありがとうございます。
おそらくコミュニケーション主体に責務協会を引いていると思うのですが、
メンテされてない機能が発生しそうなことはありませんでしたか?
ここのメンテされない懸念への対処方法等はありますか?
そうですね、メンテされてない。
信用がされていないものとかっていうのに関しては、
結構EOL通知とかが飛んできたりするので、
そういったものを見つつ、
これまだ潰せないんだっけっていうのを調べて、
ちょっと後手後手にはなるもののきちんとチェックをして潰しているような形ですね。
はい、ありがとうございます。
プロだことことに責務を分けることで、
プラットフォームチームの負担、
ワークロードも求められるスキルセットが増えているように見えます。
チームの皆さんの育成やモチベーションの維持など、
課題はありますでしょうか?
これはおっしゃる通りで負担は結構増えているような形になっていて、
ただですね、プラットフォームチームは、
現状なんですけど、
まだ結構若手とか新人の子っていうのは、
実はいなくて、
結構強い人ばっかりいるような形になっているので、
現状も合わせているような状況ですね。
はい、ありがとうございます。
次に、
インフラの責務がプラットフォームチームが持っていることで、
例えばアプリケーションスキル設定にリードタイムが発生するといった、
デメリットや辛みはあったりしますか?
スケールっていうのは、
オートスケーリングのことでいいのかなとかであれば、
こちらもパラメータ変更とかだけで、
スケーリングの設定が自動的に入るようになっているので、
そこに関しては、
プラットフォームチームとしては、
全然ボトルネックにならず、
やっていただけるような状況になっております。
はい、ありがとうございます。
最後ですね。
プロダクトチームが多くの責務を持ちながら、
チームオーダーのガバナンスを強化する工夫について教えてください。
自分も知りたいですね。
そうですね。
ちょっとここは、
現状ちょっと人力で頑張っているような状況になっているので、
ちょっとここは、
ちょっと後から話しかけてほしい。
一緒に話したい、ここは。
はい、次ですね。
時間的に最後ですかね。
X as a サービスの基盤に対して、
チーム個別の要望など出てきませんか。
そこへ要望対応のバランスはどうしていますか。
そうですね。
例えばプレビュー環境とかでは、
要望が上がってきたりするんですけれども、
そこら辺は、
そうですね、
どれぐらい必要性があるかとかっていうところに応じて、
対応を決めていくような形をとっております。
なんで、
基本的に手が空いていればサクッとやっちゃうし、
実装に時間がかかるのであれば、
ちょっとこのタイミングに守ってほしいっていうような話をしつつ、
スケジュール調整してやっていくような形ですね。
基本的に依頼があったら、
全部受けるような形でやらせてもらっています。
はい、ありがとうございます。
はい、えーと、
スピカーの方に、
今一度拍手をお願いします。
ありがとうございました。
ありがとうございました。