一人SREが歩んだPlatform Engineeringスモールスタート実践録

はい、みなさんこんにちは
あ、ありがとうございます
返してもらえると思えなかった
はい、ちょっと午後ランチの後で
ということで、ちょっと眠くなるとは思うんですけども
30分ほど、25分か
ちょっとお付き合いいただけるとなと思います
はい、ということで
一人SREが歩んだプラットフォームエンジニアリング
スモールスタート実践録ということで
株式会社ミクシーの井上が発表させていただきます
はい、まず自己紹介なんですが
名前はショッサンと言います
Twitter、Xの方はショッサン2なので
このアイコンでやっております
所属は株式会社ミクシーでして
活動はこんな感じのSRE中心のことをやっております
はい、あと私が関わっているプロダクトなんですけども
ファンスターというのをやっております
こちらのファンスターがですね
スポーツ観戦ができる飲食店に特化した検索予約サービスとなっておりまして
スポーツ観戦ができるですね
飲食店をエリアとかチームとか
あと放映予定、ゲーム、試合ですね
試合の方から検索して予約できます
ハブさんとかがすごい登録されていらっしゃるサービスですね
お店にとってはですね、こういうスポーツの観戦やってますよということを
告知して集客することができるサービスとなっております
はい、前置きなんですが
このセッションではですね、プラットフォームエンジニアリングの必要性に気づいて
その実践をですね、スモールチーム
イメージとしては5、6名とか
そのぐらいのイメージでコツコツやっているお話をさせていただきます
はい、まずは背景なんですが
もう遡ること4年前ですね
2021年3月ぐらいから
ちょっととある機能実装からですね
インフラ周りをちょこちょこと触るようになりまして
そこからですね、負荷計測とかパフォーマンスチューニングとか
インフラデプロイフローの障害時調査とかですね
もろもろやるようになりまして
これらをですね、続けながら
アラートを追加してり整理したり
トイルをなくすように仕組み作りをしたり
インシデント管理をしたりと
いろいろやっていたらですね
これってSREってやつなんじゃないっていうふうに気づきまして
遊撃部隊というものをですね、作りましたと
これがですね、SREの実践したいと
あとは開発リソースがどうしてもちょっと足りないということで
片手間でですね、開発もしないといけないという
この2つのですね、側面があって
単純にSREチームですみたいな感じで
名乗るのはちょっとやめようということで
ちょっとですね、みそか社様がやってらっしゃった遊軍チーム
記事とかに残っていると思うんですけども
遊軍チームの取り組みがですね
自分のやろうとしていることにぴったり来たので
ちょっとお名前を拝借しまして
2021年12月にですね、マネージャーに承認とって
遊撃部隊という名前でやっていいですかということで
誕生しましたと
そこからですね、大体2年後ぐらいしばらく経ちまして
まさしくですね、プラットフォームエンジニアリングミートアップ
勉強会のミートアップの第1回がですね
2023年3月にあったんですが
こちらに参加しましてですね、気づいたことがありましたと
これ一部やってることプラットフォームエンジニアリングじゃね?
っていうことに気づきましたと
で、そもそもの疑問なんですが
じゃあなんでSREやってたやつがプラットフォームエンジニアリング一部知らずにですね
実践できてたのかというとですね
プラットフォームエンジニアリングとSRE
これ交差点で書いてありますけども
重なる部分っていうのがあるんじゃないかということで
ちょっと考えましたと
で、プラットフォームエンジニアリング
そもそも視点が違うとは思うんですけども
プラットフォームエンジニアリングは
ストリームアラインドチームの方を向いてますと
で、SREはですね、プロダクトの信頼性、プロダクトの方向を向いてますと
ただですね、お互いにいろいろタスクのグラデーションってのがあると思うんですけども
その中でですね、トイルという部分については
かなり重なり合う部分があるんじゃないかなということで
プラットフォームエンジニアリングだと
開発者の生産性を下げるようなトイルをなくそうとする
撲滅しようとするというところ
で、SREでいうとですね
信頼性を脅かすようなトイルをなくそうとするという側面があります
ということで
そこら辺をですね、中心に
知らず知らずのうちにトイルを撲滅という
名目でやっておりましたということになります
で、実際にですね
知らず知らずのうちにやっていたといっても
どんなことやってたんだっていうのを
改めて振り返ってみましたと
大きく分けてこの3つですね
ゴールデンパスの整備と
あと開発ワークフローの自動化と効率化
あと最後にセルフサービスの実現という感じを
この3つのカテゴリーでやっておりましたと
で、ゴールデンパスの整備なんですけども
CICDパイプラインの整備だったりとか
あとリリースプロセスの自動化
というのをやっておりまして
で、まあ状況、当時の状況としてはですね
本当はリリース終わってすぐぐらいのタイミングだったんで
必要最低限のものしかなかったんですよね
とりあえずリリースに間に合わせて
必要最低限のリリースのプロセスがあったぐらいの
感じになっておりまして
当時考えていたこととしては
ストリームアラインドチームがですね
価値を提供するまでの間
デプロイ開発から
あとデプロイするまでの道をですね
舗装しないといけないよね
ということを考えていて
こんなことをやっておりましたと
次は開発フローの開発ワークフローの
自動化と効率化ということで
プレビュー開発環境の整備だったりとか
依存関係の管理スクラムプロセスの自動化ということで
状況としてはそういう
さっきも言ったみたいに
ほとんど何もないさらちみたいな感じだったので
開発をですね
より良くする環境づくり
というのをやらないといけないよね
という状況でして
またさらにですね
スクラムちょっとやろうよ
っていう話があって
スクラムをですね
やったことある方は
お気づきだと思うんですけど
スクラムイベントにやっぱり結構時間かかったり
っていうところがあるので
その辺の効率化というか
早く終わらせるための自動化みたいな
ところをツール作ったりとか
しないといけないなということで
当時考えていたこととしては
ストリーマーラインドチームがですね
実際にその開発とか
価値を届けるデプロイまでの部分のところで
他のことに時間を取られないように
集中するための環境づくり
しないといけないよねということで
こんな感じのことをやっておりました
はい
次はセルフサービスの実現ということで
QAチーム向けの支援ツールの開発
これどういうことどういうものかっていうと
例えばQAチームのデータづくりとか
開発環境データづくりして
それを元に確認とかすると思うんですけども
挙動の確認とかすると思うんですけども
そこのですねデータづくりの補佐とか
そういったものになりますね
デバッグツールと呼んでいるものになるんですけども
そういうものをゼロが作ったりとか
あとは開発環境の可視化利用管理ということで
今ですねどんな感じのQAが進んでいて
どういうふうにこの開発環境を使われているのか
みたいな感じのことをですね
誰でも見て分かるような状況にするっていう
ツールを作ったりとかしましたと
でまあ状況としては本当に
こちらもですね何もない状態
セルフサービス何っていう感じの状況だったんで
ストリームアラインドチーム
並びにあのエネーブリングチームで
作業する際にですね
まあそこでこう作業が完結するように
他の例えばチームを巻き込んで
何かやるっていうのは
発生しないような環境づくりっていうのを
やりましたという感じになります
はいでえっと
感じのですねその2023年の3月に
まあプラットフォームエンジニアリング
あこんなもんあるのかっていうので
まあその知った後にですね
まあどう変わったかっていう話をしていくと
まあここにビフォーアフターと書いてあるんですけども
SREに基づいたサービスの信頼性向上を主にしてですね
活動をやっていたんですけども
その中でですね
まあ先ほども言いました通り無自覚に
トイルという交差点の部分で
プラットフォームエンジニアリングをやっておりましたと
でこの時はですね
プラットフォームエンジニアリングっていうものを
まあそもそも知らなかったので
まあトイルっていうすごい点の部分だけの
問題解決をしておりましたと
でこれがですね
まあその知った後にはですね
まあ今までのSREのみの考え方から
よりですね
プラットフォームエンジニアリングっていうものを
やっていかないといけないという
視点のシフトがありまして
まあこれがですね
面の課題解決ということで
プラットフォームエンジニアリングを
まあ全体的にやっていきましょうと
まあ開発者体験を良くするためにやっていきましょうという風に
視点が変わりましたと
はいいう感じになります
じゃあですね
変わった後にお前は何をやったんだということで
まあそれぞれですね
問題点その当時の問題点と
プラットフォームエンジニアリングという視点に立った時の問題点と
あとはですね何を改善したのかっていうものを
まあちょっと上げていきますと
でまず1個目がプラットフォームアーズコードってあるんですけども
まあ問題点がですね
IACなどを含めたまあコード化っていうのがですね
まあ一切されてない状態で
まあストリームアラインドチームが触るとしたら
コンソールからですね
ポチポチポチってやって
まあそれそもそもできんのかっていう話なんですけども
まああのストリームアラインドチームが触るにはですね
まあ非常にハードルの高い状態でありましたと
でまあこれをですね
どうにかしないといけないということで
プラットフォームアーズコードのリポジトリですね
を用意しまして
まあテラフォームなどを使ってですね
プラットフォーム全体のコード化を行いましたと
はいでテラフォームを
まずですねテラフォームを利用したIACの導入をやりました
で開発ステージング本番環境にまたがってですね
GKE、IAM、クラウドラン、クラウドランファンクションズ、クラウドストレージなど
まあ他にもいろいろあるんですけどもそちらですね
各種グーグルクラウドリソースをですねテラフォームで管理するようにしましたと
でこれすげえ便利なんですけども
グーグルクラウドにはですねあの GKEクラウドっていうCLIがあるんですけども
ここにですね今現在利用しているリソースをですね
全部あのテラフォームのコード化したものをバルクエクスポートするっていうのがあって
これをですねあの使ってコード化していましたと
単純に全部それを移植してはい終わりじゃないんですけども
テラフォームの設計をしながらそこに合わせてコード移植していって
まあ構築していきましたという流れになります
はいでえっとあとはですねまあプラットフォーム全体に関するコードもそちらのリポジトリで管理するようにしましたと
で主にですねGitHubアクションとかあとSlackBotとかChromeエクステンション
これ何使ってんだって話なんですけど
Chromeエクステンションあの先ほども言ったスクラムの便利ツールとして作って
皆さんに社内配布したりとかっていうのをやっていたりとか
あとですね一部デプロイにあのシェルスクリプト使ってゴニョゴニョやっているところもあったので
まあその辺のですねスクリプトも管理したり
でまあ一部のものについてはですねそのリポジトリ上でデプロイフローも実装したりとか
もろもろですね全部そのリポジトリで完結するように作りましたというものになります
はいで2つ目なんですがこれはですね権限管理のセルフサービス化ということで
まあ今日もなんかキーノートの方でポリシーシフトって話がありましたけども
まあ権限管理についてもちょっといろいろやりましたということで
まあ問題点がですね
こう PAC によって
IAM も管理してあるんで
まあ権限管理も一応触りやすい
ストリームアラインドチームが触れる状態にはなってましたと
ただですねあのまだまだこう権限自体の認知負荷は高い状態でありました
まあ何を言ってるかっていうとまあその
これをやりたいんだけどどの権限割り振ったら全然割り振ったらいいか全然わかんねーみたいなものがあったので
まあまあそういった声が聞かれたので
あれこれどうにかせんといかんなーということで
まあ改善をちょっと考えましたと
でこの時にですね
まあ一番こう最初に出てきたのやっぱり
AI をちょっと使ったらいいんじゃないかっていうことで
IAM 権限をですね
付与するスラックボットの
AI 機能の実装っていうのをですね
行いましたと
でまああの先ほど言った通り
どの権限ストリーマラインドチームがどの権限付与したらいいのかわかんない
って言ったまあ課題に対してですね
AI がじゃあこれを付与すればこれできるよっていうのをですね
まあ言って実際付与することで解決というものを作りましたと
でどんなものかっていうとですね
えーこんなのになりますと
ざっとあのスクリーンショット撮って持ってきたんですけども
えースラックボットにですね
オープンAI API の中でもあのあれですね
レスポンシーズ API を組み込んで
でえーと他にもですねベクトルストア
あのなんだベクトル検索できるようにそこにあのファイル突っ込むってやつなんですけども
えーここにですねあの g クラウドで
えーそれぞれ権限を権限の名前と
えーあとその説明っていうのがバーっと一覧に取れるんで
えーそのファイルをですね
えーちょこちょこっとこう調整して
でそこに突っ込んでベクトル検索ができるようにっていう風にしましたと
であとはですねファンクションコーリングをえー実装することで
まあその実際にこうメンションを
ペロッとあの自然言語でスラックボット君に送ったらですね
アイアムの権限付与の話だよねーということで実行してくれるみたいなことができるようになりましたと
でまああのこんな感じですね
まるまるさんにえーKubernetesのコンテナに入るための
えー権限を付与してちょということで
えーじゃあこれこれじゃないですかみたいな感じで
でえー出してくれてでまあハイをやったらですね
まあ実際にその権限を付与してくれるというものになります
はいでまあちょっとこれ作った時にびっくりしたのが
絶対無理だろうなーって思ってあのあだ名でやってみたんですよね
あの例えば僕の名前で言うとまあ初産に何々の権限を付与してやってみたら
意外といけたんで
ああAIってすげーなーって思って
あだ名をちゃんと理解するんだーって思って
まあめちゃくちゃあの精度低いっすけどね
3割ぐらいの打率であのあだ名をちゃんと理解してくれるみたいな
はいことができたんでまあそういうのにちょっと今AIを使ってたりとかしてます
でまああのちょっと権限付与だけで終わらせるにはちょっともったいないなーって思って
えードキュメント検索
えーこれもですねちょっとあのプロジェクトのいろんなこう
今までの歴史があって
まあちょっと分散しちゃってるんですよね
いろんなところにこうドキュメントが分散しちゃってるんで
それのこう横断検索っていうのをですね
えー自然言語でできるようにちょっとAI使ってできないかなーっていうのを考えておりますと
でまあそれをですね目指して今実装中でございます
またどっかでちょっと発表したいなと思いますと
でえーと3つ目がゴールデンパスの進化ですね
はいこちらがえーとまず問題点としては
CICDパイプラインっていうのは何回も言ってるんですけど存在していて
でまあとりあえず動いてデプロイができますと
それ以外何も何もやりませんみたいな感じだったんですけども
これもですねまあそんな状態でも
ストリームアラインドチームにとっては
どうやってデプロイまでいってんのみたいなちょっとしたこうブラックボックス化していましたと
でまあこれもですね
えーちょっと改善ということで
まあ会社体験とあと信頼性を軸にですね
信頼性を軸にですね
ゴールデンパスの各要素
えー改良しましたと
まあ多いですね
まあ多いですね
CICDセキュリティ
Kubernetes時系などですね
えー多くの改善をやりました
でえーとまず一番上がですね
えーセキュリティの面でワークロードアイデンティティを導入しましたと
でワークロードアイデンティティを導入してですね
えーサービスアカウントキーの管理っていうのがまあ不要になりまして
セキュリティ上のリスクっていうのが排除できましたと
で主にあのKubernetesのPodとか
えーギター部アクションですね
の方でまあ利用しておりますと
まあこれで一旦セキュアなものはできましたよねーとか
えーあとCICD体験の向上ということで
こうなんかざざざっといっぱい書いてあるんですけども
えーまあE2Eテストの導入とか
まあちょっと当たり前のものから
えーArgo CDのセルフマネージとかによるまあアップグレードの簡略化
えーとかあの
あれですねArgo CDでArgo CDを管理するってやつですね
はいとかあとArgo CD Notificationsの導入によって
あのそもそもデプロイした後に
あれこれ今どういう状況になってるのってわからなかったんで
えーデプロイが成功したのか失敗したのかっていう通知の部分
えーだとかあとテストカバレッジの整備ですね
でこれがテストカバレッジの整備が
なんか普通にテストカバレッジを
えーコメントとしてプロリクトとかに出すとか
えーもやったんですけども
一個ちょっと特集なやったこととして
えっとフラッターアプリをつく
あのー配信してるんですけども
そちらのですね
えー開発を担当していた方と話したときに
えーまああのカバレッジレポートを
GitHub Pagesで最新のものが常に
あの見れたりとかするといいなーっていう話があったんで
まあそちらにですね
えーいろいとこうゴニョゴニョとやって
えーGitHub Pagesに最新のレポートがですね
常に見れるような状態にしたりとかっていうのをやったりしました
はい
こういうあの実際どういうものが欲しいのかっていう意見のですね
取り入れもやりながら整備しましたと
あと静的解析ツールですね
えーうちグラフQL使ってたんで
グラフQL使ってるんで
グラフQLのグラフQLインスペクターによって
えー破壊的変更の検出を早期でやったりとか
あとクベコンフォームによってですね
マニフェストのバリデーションかけたりとか
えー他にももろもろもろあるんですけども
一旦抜き出すとこんな感じのことやってましたと
でえー最後にですね
Kubernetes GKEの安定化ということで
えーインスタンスグループでですね
えーノードを通じたトラフィックのルーティングを
をやっていたんですが
ネットワークエンドポイントグループっていうのを利用して
直接ですね
ポットへのルーティングっていう風に変更をしまして
これがあのコンテナネイティブ負荷分散
またの名をコンテナネイティブロードバランサーみたいなことをやってですね
ちょっとデプロイ時のタイミングによって
若干の疎通が悪くなるっていう現象があったんですけども
それのですね安定化をこういうのでやりましたと
あと本当にあの一時的な問題への対処療法としてですね
あのKubernetesのカスタムコントローラーをぺって作って
でそれを一時的な問題解決として使ったりとか
ここもまあいろいろいろいろいろいろいろやりましたという感じになります
で全体をですね振り返ってみると
まあこういうことって小さな
あのなんだスモールチームでプラットフォームエンジニアができたっていうのは
まあ本当にあの小さなチームだからこそ
私一人でできたんじゃないかなと思っております
そうあの自分一人でずっとこういうのやってましたという話になるんですけども
まあその中ですねまあ一人で進めていけたのはチームの大きさ
あと協力体制があったからじゃないかなと思っておりますと
まあどういうことかっていうとですね
えーまあストーリーマーラインドチームの大きさが
まあ最初に言った通り5、6人ぐらいで推移してまして
本当は辛みの共有っていうのがすごい円滑にできたんですよね
あのー定期的にこうワンオンワンとかも気軽な感じでできますし
あとは本当に雑談という形で
今こういうの辛いんすよねみたいな話ができたりとか
まあすごいこう距離が近いんで
まあそういうのがですねこう
こうスモールチームでプラットフォームエンジニアリングをやる
まあ最大の武器なんじゃないかなと思っておりますと
まああとはこれはあのストリーマーラインドチームがすごい協力的で
あの仕組みの導入しますっていうと
まあ反発とかあの普通はちょっとあったりとかはするんですけども
まあ皆さんのすごいすんなり
あーこういうのやりたいんですねーっていうので理解示してくれて
入れれたいとかえーしましたと
でまあそういうのがあってですねまあSREと同じく
まあチーム間でのコラボレーションっていうのを生むのはですね
やっぱり対話なんじゃないかなと
はい思っております
でまあそうは言ってもそうは言ってもですね
えーまあ辛いところはやっぱりあると
そもそもリソース足りねーとか
えーあとはですねまあ近くに相談する人
同じ視点で相談する人がいねーとかっていうのがありますと
まあリソースの方ではですね
まあ本当にまあバックログがすげー大量にあるんですよね
でそれをですねまああの一から順序でバーってやっていくっていうのは
もうさすがにちょっと無理なので
えー優先順位付けしてですね
やっておりますということになるんですが
そうなった時にまあ理想としてこうしたいけど
えーまあ今やることじゃないよねっていうのが
まあどうしてもありますと
まあそうなった時にですね
あれ俺これやりてんだけどなーみたいなことで
まあちょっともどかしい気持ちになること
まあモチベーションとかそういう話ですね
えーことが多々ありましたと
まああとはですねえー自分と同じ視点で
まああのアイデアのえーまあ練ったりとか
あと壁打ちとかをやるっていう方がいなかったので
まあそこらへんはもう自分の視点頼みで
やらないといけないってところにやっぱり難しさとか
まあ厳しさをですね感じましたと
でえっとまあ本当にあのこれやらなくて
今やらなくていいのかとか
えー他にもなんかスマートなやり方あるんじゃないのかな
みたいな感じのところはですね
あの他のこうプラットフォームエンジニアリングとか
SREの文脈で発信されている方の
えー記事とか見てですね
本当に参考させていただきましたと
ただえー今日もキーノートにもありましたけど
まあ一人でも戦える武器としてですね
AIの福音がありますと
AIくんがやってきましたと
えーということで
まあ先ほど挙げたこの2つで言うとですね
リソースの拡張ということで
まあAIがですね
まあ並列して実行することで
まあ大きくリソースを拡張することができますと
でこれなんだっけ
えっと EMコンか
今年のEMコンフでえっと
広木大志さんが
まあ全てのエンジニアはですね
AIをメンバーに持つ EMになる
っていうことをですね
スライドの中でおっしゃっていたんですけども
本当にあの今一人でやるっていうことはですね
AIを通すと
気迫化してるんじゃないかなと思いますと
でえーあとはですね
本当にAIは良き相談相手で
えー深夜でも早朝でもいつでもですね
壁打ち相手になってくれるっていう
えー素晴らしいものなんですが
まあ全てはですね
鵜呑みにできないですが
まあある程度
自分からですね
こういうことをやりたいんだよね
っていうのを詳しく
えー材料を持っていくとですね
結構資産に富んだ回答してくれるんで
本当に優秀な仲間だなぁと
思っております
でえーとそんな話がですね
あの僕の本当に触りの話なんですけども
えー今日1000円であの本が売ってるということで
あのこちら中身を見るとですね
より詳しいAIの使い方っていうのが
載っておりますと
えーいうものになります
でえーとまあ明日から始める第一歩ということで
プラットフォームエンジニアリングはですね
えー大規模チームや大規模発表
大規模組織だけのものではないですと
えー本当にですね
えー小さなチームでもできますので
えーまずはですね
対話をして
まあちょっとした問題解決っていうのを
えーしていきましょうという
お話になります
はいということで
えーよちよちながらですね
プラットフォームエンジニアリングをやってみた
お話でしたと
えーまだまだ自分の中でやるべきことは
たくさんあるので
えーさらにですね
会社体験を向上させるために
やっていきたいなと思います
はいご清聴ありがとうございました
はいありがとうございました
えーと
いくつか質問が来ているので
えーと回答お願いします
上からですね
スクラムプロセスの自動化は
具体的にどのような自動化があったのですか
というところで
お回答お願いします
えーと
これが
なんだっけ
えーと
えー
えー
Chromeエクステンションの方でやっていたのは
えー
GitHubの
あの
看板のやつ
何でしたっけ
GitHubプロジェクトか
の方であの
いろんなこう
スクラムのPBIとか
いろんなものを管理しているんですけども
そこにですね
えーと
例えば
今のこの
今度やらないといけない
ネクストスプリントでやらないといけないやつが
えー何ポイントですよみたいな
みたいな感じのものを
えーなんだろう
GitHubプロジェクトちょっと拡張する
エクステンション書いたりとか
えーしたり
あとですね
名前が出てこない
えーと
あのー
前のスプリントで
ポイント何個消化したとかっていうのを
えー記録するためにですね
あのその記録
あのーなんだ
えーと
えー
エクセルの方に
エクセル
エクセル
スプレッドシートか
スプレッドシートの方に
あの転記したりとかっていう
まあそういった本当にちっちゃな自動化ですね
えーというものをやってたりとかしてます
はい
ありがとうございます
では次ですね
そもそもの改善事項を洗い出し
優先順位を決めるときに
どのように進めましたか
その判断基準について教えてください
ということです
あー
そうですね
これ
えーと
2つ優先度を分けて
めちゃくちゃ一瞬でできるものの
のリストを作って
皆さんの仕事する上で
やる気ないときとかあると思うんですけども
そういうときにですね
一瞬でできるものを
そっち片付けるっていうものを
リスト作ったりとか
えー
あと
なんだろう
えー
本当にその
ビジネスインパクトとか
そっちを優先して
やらないといけないっていうものは
どうしても優先順位が高くなったりとか
えー
あとはもうその
開発をする上で
めちゃくちゃ
ここが
今
ボトルネックになってるみたいなところは
もう本当に
優先順位高くやるっていう感じで
それ以外のところはちょっと低くなったりとか
あとセキュリティか
セキュリティ周りで
これ対応しないと
すぐ対応しないといけないっていうものは
やっぱ判断基
優先順位の高めになってきますね
っていう感じで
めちゃくちゃこう
フラット
フラットっていうか
なんかざっくりした感じではやってます
はい
はい
ありがとうございます
次の質問として
既存インフラのIAC化をするときに
効率的かつ
確実に進める工夫をされていたら教えてください
あー
これはそうですね
まああの
今回テラフォームでやったんですけど
まあそういうときに設計とかは
多分あの
ベストプラクティスみたいなの
出されている方っていうのは
すごいいっぱいいらっしゃるので
まあそういうのを
参考にしたりとか
あとですね
すげーなって思ったのは
さっき言ったバルクエクスポートした後に
それをですね
IACリポジトリに
これ突っ込まなきゃみたいなことあるんですけども
それも今全部AIで
ペッて指示出して
一発でやってくれてますねっていう感じで
まああの
AIを利用しています
っていうところになります
はい
はい
ありがとうございます
おそらく
次は最後の質問になるかと思うんですが
セルフサービスの実現で
利用管理という言葉が出てきましたが
具体的にどういったことができるものですか
これについては
これについては
QAさんとか
あと開発チームが
その実際の環境で
実際というか
とある環境にデプロイして
開発環境にデプロイして
動きとか見るっていう風にしてるんですけども
その中でですね
その中でですね
実際にその
開発環境にデプロイしたら
その開発管理ツールみたいなものがですね
今これが利用中だよみたいな感じになって
その利用中っていうボタンをペッて押すと
今このプルリクで利用してるんだみたいな感じのところで
そういった管理をしていますっていう感じですね
その辺もほぼほぼ
何かしら手動でポチポチやったりとかっていうのをせずに
自動的に開発環境をデプロイしたりとか
あとは使い終わったら
もう勝手にそれがですね
今使ってない状態になったりとかっていうところを
使ってっていうのを実装しましたっていうところで
利用管理ですね
はい
ありがとうございました
ご清聴ありがとうございました
改めて小瀬さんに拍手をお願いいたします