ツナワタリマイライフ

日常ネタから技術ネタ、音楽ネタまで何でも書きます。

勉強会参加メモ -【PLAID×NewsPicks共同開催】ABテストの理論と実践〜成果にコミットするプロダクト開発〜

uzabase-tech.connpass.com

参加した。ちょうど今年の2月からプロダクトエンハンスを A/B テストを活用するチームを立ち上げたばかりで関心の高いトピックだった。

中身も非常に学びが多く、開催してくれて本当に感謝。

動画も残っていて感謝。

www.youtube.com

ABテストのための統計的検定理論(序論)

統計的検定理論について理解が浅いままやっている(所属組織については専門のデータアナリストについてもらっている)ので、その入り口として非常にありがたかった。紹介された本も買ったのでこれから読む予定。

最初に紹介されていたスライドはこれ。

blog.recruit.co.jp

  • ABテストとは
    • ABテストとは分析の一種である
    • 「分けて、比較する」が分析
  • AB テストの前提条件
    • どちらに割り振られるかはランダム
    • 片方に割り振られたらもう片方には割り振られない
    • 2つの群で同時に実施される
    • ABC テスト
      • うっ
  • AB テストの結果の見方
    • 量ではなく CVR をみていく
    • 棒グラフで出してもあまり意味がない、スケールを変えればどうとでも見れるので
    • 何をもって近い、遠いかを判断するには「統計的仮設検定」が必要になる
    • 「CVR の発生確率」を分布していく、重複が離れていくと有意と言える
  • 注意点
    • サンプルサイズを大きくすると、確率分布が尖る(幅が小さくなる)
    • サンプルサイズを大きくすると、小さな差でも有意になってくる
  • 統計的仮設検定の手順
    • ABの差が棄却域が有意水準より離れていれば棄却できる、と考える
    • 差があるといえる確率を検出力という

時間があったら話すことを聞きたかった!続編に期待。

120回分のABテスト結果を分析して見つけたアンチパターン/成果が出たパターン

約2年で120回、すごい。

  • 失敗事例から学ぶ
    • いつまでも終わらないABテスト
      • Android ではじめて、あとで iOS で適用すればいいのでは?ー>サンプル数が足りないのでいつまでも終わらない
      • わかる...
      • サンプル母数が少ないと改善サイクルが遅くなる
      • 人数が多いプラットフォームで先にやるべき
    • 差分が少ないテスト
      • これ難しいですね。差分が大きすぎるとどの要素が効いたかわからないという問題はありそう
      • あまりに些細すぎると、効果は出ないというのはありそう
  • 成功事例
    • 施策のタイミングを考える
      • ユーザが感情が動くタイミングでやる   * インストール直後の初期画面 -> プレミアムを訴求する
        • サブスク開始後に通知許諾を促す
        • 良さそう
    • 判断に必要な情報を整理して伝える
      • めちゃくちゃ大事。..
      • 結局いくらお得なのかを整理する、やりたい
      • 解約画面で訴求するのいい例だと思った
        • もしやめて、また入ると高くなるよ、ということを通知   * 値段だけじゃなくても解約防止のための情報を伝えるのは大事
  • サービスの種類や特性によって違う、それはそう
    • これが難しいし実験あるのみというところだなと思った
    • 実験サイクルを回し、学習量を増やすことが一番大事だと思った

Notionを軸にABテストを効率化する

Notion, 仕事では使っていないんだけど、データベースになるのでテンプレート + 結果の分析に役立つなーと思いました

A/B テスト自体のテンプレートは GitHub Issue Template を使っているけど、分析はそのまま使えないので確かになーと思った。

A/B テスト自体の分析ができるほど施策ができてないなーというところはぐぬぬとなりつつ、いずれ必要になるので考えておきたい。

AB テストの if 文の残留はタスクマネジメント上しっかり Issue 化しているので忘れずにできているなと思った。

ただ全体的に自動化の余地はあるので、Zapier 使うとか知見共有するよとかそういうのは真似していきたい。

質疑応答

  • KPI の分解についてはかなりできてないなと思った
    • 実際売上に近い、課金率を目標に取っている
    • 課金率を KPI ツリーに分解し、より近いところを目標していくことで高速にサイクルを回せるようになると思った

まとめ

  • A/B テストテーマの勉強会、めちゃくちゃありがたかった、またやりたい
  • 自分たちも発信できるようにしないとなーと思った、ブログ書こう。。。

入社してから5年

前回 https://blog.chaspy.me/entry/2022/12/24/120000

約半年ごとに書いている勤続(?)エントリー。ついに丸5年となった。

節目ということもあり、5年を振り返ってみる。

5年間を振り返る

1年目

2018/06-2019/05

とにかくパフォーマンスが出なかった。出なかった、というか、低かった、というのが正しい。求められる期待値と現在のギャップを正しく認知できず、間違った方向にがむしゃらで、パニックゾーンだった。

今でもたまに思い出す。辛い時期だった。

半年経ったころから Microservices Readiness な仕組みつくりをはじめたり、deis からの Platform 移行にともなう Kubernetes の勉強会や、起きる変更を文章にしたり、特別講習と呼ばれる live サービスのインフラを担当したりと、少しずつ自分ができることが増えてきた。

同時にオンボーディングカルチャーを WebDev と一緒になって醸成した。

ブログ筋があったおかげで、わかることもわからないことも文章にするスキルがこの時自分を助けてくれた。

SRE Lounge のコミュニティに顔を出したり、同僚と勉強会に行ったりの時間が癒しだった。

2年目

2019/06-2020/05

自分でできることも増えてきた。ユーザも増え、パフォーマンスの問題を顕在化してきた。MongoDB のスケールアップのための負荷試験をやったり、Kubernetes 上で HPA を導入したりしていたかな。

あとは SLO をやっていくんだ、と宣言して、最初は1人でコツコツと、それから開発チームと一緒に少しずつ。現れる技術的問題をクリアしながら"文化を作る"体験をしたのは自分にとって稀有な経験だった。

この時の体験は最善だったとは思わない。もうやらないし、もうやれないな、とも思う。しかし組織としての仕組みがない中で個人が1つのことを成し遂げることができる土壌そのものの尊さを感じたのを覚えている。

英語を真剣にやっていたのもこの時期だと思う。悔しい思いをたくさんした。嬉しい思いもたくさんした。現地に行って会話したこと、それがリモートであれ普段の仕事のしやすさにつながること、今、時代柄見直されていることだが、オフラインコミュケーションの重要さを実感した。

1番ハードに働いていたと思うし、でも夢中だった時期だと思う。

3年目

2020/06-2021/05

Lead Engineer というタイトルがついた。チームが前に進むためにできることを考えた。とにかく考え尽くした。

言語の壁もあった。チームメンバーの価値観の違いもある。SRE チームの担当範囲の広さもある。難しかったが、この頃からメンバー全員と1on1をはじめて、課題解決に時間を割いた。

同時に IC として技術力の壁を1つ超えられたのもこの時期かこのちょっと前だったように思う。"技術力が課題"という言葉に、これ以上の解像度を持っていなかった。

しかしとにかくコードを書くことをミッションにしたり、"わからなさ"をわかることができた、この認知の変化によって自分が技術的に成し遂げられることが格段に変化した。

https://blog.chaspy.me/entry/2021/05/08/120000

Platform に関する大きな変更にもチャレンジした。company wide に影響する migration をサポートをもらいながら主体的に成し遂げられたのは自信につながった。

この頃から"エンジニアリングでビジネスに貢献したい"という気持ちが強くなってきていた。

4年目

2021/06-2022/05

この頃はマネジメントの割合が増えてきていた。もちろん OSS を書くなどコードを書く機会は増やしつつ、いかに組織の課題を fact をもとに解くのか、計測するのか。SRE は何を目指すべきなのかを考えていた。

そして10月からは EM になった。

この頃は組織全体の技術戦略にも関わることになり、視座が一段上がったように思う。そのことが SRE としての活動の幅を広げるにも役立った。

5年目

2022/06-2023/05

SRE だけでなく web チームのマネージャーも兼任することになり、マネジメントとしての難易度を一段上げた。

リクルートグループ入りしたこともあり、交流も増えた。大企業での泳ぎ方みたいなのはわりと適応能力があったみたいでなんとかなっている。

マネジメントをうまくやればやるほど、自分個人の成果が見えづらくなる、マネージャーあるあるだが、そういったことはあまり気にせず、自分の成長できる環境を自分で作っていけたと思う。

このときやりたかった Web 技術そのものを仕事でやることは残念ながらほとんどできていない。まぁ、複数グループ兼任してたらマネジメントだけで終わるのはそれはそうよね。

そのことが今後足枷になるのかはわからない。ただ、評価する立場としては技術との距離はこれ以上離れてはならないと思うので、1軍のコードは書かないまでも、2軍3軍のコードを書く、副業で書くなどして食らいつきたいし、自分自身も技術を楽しみたい。

今後

10月で SRE のマネージャーをやって2年である。2年で引退するつもりだったが、Web のマネージャーもはじめたため寿命が伸びた。

今自分が1番面白いと思うのは"Engineering Management"だ。これは文字通りであり、マネージャーという仕事が面白いとか、人と話すのが楽しいとかという側面ではなく、どのように技術をビジネスに活かすのか、ここにより直接的に関与できる立場にある。

変わらず国内と海外の両方のビジネスを支えていきたい。

国内については SRE と開発チーム両方見れる立場として、技術戦略をよりうまくなる、3年後5年後のサプリの未来を作ることに貢献したいし、それを主体的に行う Engineering Manager や Lead/Senior Engineer をサポートしたい。

海外についてはインフラ面でビジネスが継続できるようコストや開発生産性でサポートしていきたい。

外部コーチングを受けることで自分の強みはある程度わかってきた。広く見て、仕組みを作って、ひとりひとりの成長をサポートして、重要な課題について、レバレッジポイントを見つけて介入したい。そういうことを、もうしばらく今の組織でやる。

それ以外の個人的な興味だと、プロダクトエンハンスをA/Bテストをやって仮説検証をやるチームの検証サイクルを爆速にしたいと思っており、これを成し遂げるには超えるべき壁がたくさんあるので、自分が貢献できるポイントも多いと感じている。やっていきたい。

次の10月で Engineering Manager 3年目になる。引き続きよろしくお願いします。飲みに行きましょう。

エンジニアリングマネージャーの成果

なんかタイトルを一般化すればするほどブクマがつくことがわかった。これも十分一般的だが。

エンジニアリングマネージャーのしごと本には確かマネージャーの成果について、

  • マネージャーのアウトプット = 自分のチームのアウトプット + 影響を与えた他のチームのアウトプット

とかかれている。

さて、これについての自己評価、あるいは他者評価の難しさについて。

2つに分けて考える。

  1. 自分のチームのアウトプット
  2. 影響を与えた他のチームのアウトプット

まず、1から考える。マネージャーは目標に対する資源分配最適化の役割であるとする。チームのコミュニケーションがうまくいってないものを対話によってうまくいくようにしたり、個人の目標設定を変えたり、役割を変えたり、大小いろいろある。

その場合、ここで書かれてないことであるが、

  • 1-1 マネージャーが存在しなかった場合のチームの成果
  • 1-2 マネージャーがいたことで想定できる最大のチームの成果

現実はこの両者の間にチームのパフォーマンスが落ち着くと思われる。しかし、その期におけるチームの成果が想定通りか想定外かを計測することは難しい。よって評価も難しい。

しかし、例えば営業数値とか、製造の利益とかで出せるチームもあるだろう。内製開発チームにおいてそれはなんだろう。あるいは横断(プラットフォームチーム)だとなおさらなんだろう。

測ろうとすればするほどそれはハックできるわけで、なおさらマネージャーの評価、ないしチームの評価は難しい。

しかし、ただ1つ揺るがない評価は価値提供相手の定性評価である。SRE チームであれば開発チーム、開発チームであればプロダクトマネージャーからフィードバックをもらい、それもなるべく頻度高くもらうことで軌道修正できるようにしたい。

その上で事業を継続できる、投資がもらえる数値も共有して、同じ方向を向けるようにしたい。

難しいねーなんで難しいんだろって話を考えたかったんだけど目標設定が難しいorできてないからだねということがわかったので解決してしまった…。

2 についても同じ方法でフィードバックをもらうべきだろう。

所属組織では360フィードバックという、メンバー同士でフィードバックを送る営みがある。(評価には使わない)

それと同様に、チーム単位のピアフィードバックもすべきだと思うし、これはマネージャーの評価に使ってもいいと思う。

1人のトップマネジメント(VPoE)が各チーム個別あるいはマネージャーの評価ができないならば、評価できる仕組みを作るのがVPoEの仕事なんじゃないの、と思う。

多分、こういう営みそのものがマネージャーのマネジメント業務の理解を深めたり、マネージャのキャリアを作るのに役立つんだと思う。


余談ながら、最近個人でプロのコーチングを受けている。 自分の want to を特定する上で過去のエピソードや好きなワードなど出して深掘りするワークをしたのだが、その中で自分の好きなことに、「少しの労力で大きな成果が出ること」が好き、気持ち良い、という発見があった。

これはソフトウェアの世界でいう UNIX 哲学 Use software leverage to your advantage であるし、組織マネジメントにも同様の要素はあると感じている。

これだけ続いているということは、ソフトウェアの世界、マネジメントの世界、どちらも向いてるのだろうな、と思いつつ、Hazy Double IPA 作って自宅でタップで注いで飲みたいな、とも思う。

リーダーとマネージャの違い

最近見たいくつかのツイートが自分の考えとちょっとズレがあったので考えてみる。

見つけられなかったのだけど、

マネジメントは欠けている要素を増やす、リーダーは目標を決めてチームを前に進める、やることを減らす、なので本来真逆である、みたいなやつ。

こういうのもか。

僕はこれまで以下のような整理をしてきました。(これは最近できたチームでのリーダーとの期待値合わせに利用しました)

  • Manager:
    • 担当メンバーの評価、目標(ミッション)設定
    • 担当メンバーの健康・労働時間管理
    • チームの半年単位での目標設定、戦略策定(採用を含む)
    • チームの結果責任
  • Leader:
    • チームを前に進めるためにリードする
    • チームが前に進めない要素を取り除く
    • 内容例
      • 0->1 のチームビルディング
      • チームが意思決定することをサポートする
        • 決め方を決めるように推進する、観点や選択肢を提示する、問いかけによって気づきを与える、など
      • ステークホルダーとの折衝
      • 開発部内の他のチームとのやりとり

思えば、僕が認識している Manager は所属組織でのロールとしての業務が多いなと。

ここに書いてないが、確かに「チームに不足している要素を(人材育成なり、他のチームに協力依頼するなりして)持ってくる」という動きはしている。

資源配分という意味では「チームの戦略策定や目標設定」もそうだろう。

そしてリーダーがやることを減らす、という意味としては「前に進めない要素を取り除く」にマッチしていそうだ。

そう思うとあんまりズレはなかった気もするが

チームビジョンを策定し、それに向かってメンバーを鼓舞する

これは結構両方に混じるところだなぁと思った。「どこへ向かうのか」はマネージャがやると自分は思っている。「向かう先に対してメンバーを鼓舞する」はリーダーの役割で良いのだけれど。

向かう先を決める能力がチームに備わっていれば、マネージャは欠けている資源を調達する、のみになるかもしれないが、実際は組織の階層構造だとか評価制度などが絡んでこれはパッキリ分けられないのだと思う。同じ権限を持ったマネージャとリーダーがチームにいて、そういう役割分担をすると良さそうだと思った。

開発組織でのマネージャ同士の役割分担がこんなふうにできると便利かもな。リーダー的マネージャとマネージャ的マネージャ。

正しいことを正しく言うのは難しい

人間の感情を配慮し尽くすのは難しい。確率を下げる努力はできても、完璧は無理だろう。

 

正しいことを誤って言ってしまうパターンは以下があるだろうか

- 関係性(信頼)の欠如: なんでお前に言われないといかんの?

- コンテキストの欠如: なんで今言うの?

- 期待値調整の欠如: お前何のためにここにいるの?

- 背景理解の欠如: 実はこういうことがあってですね

 

基本的にフィードバックが求められているときにすることであり、それ以外はしないにこしたことはない。求められてないアドバイスはクソバイスだからだ。

 

しかし、組織の生産性は噛み合わせが悪いと1つのことでも大きく劣化するし、最悪人が辞める。逆に言えば、たった1つのことで改善すると組織の生産性が大きく向上することもある。

 

ボトルネックの特定や、根本原因の見極め、問題の評価、という目線でいろんなことを見るようになった。それがマネジメントの仕事だとも思っていた。

 

それは正しいんだが、いかに正しいフィードバックでも届かなければ意味がないどころかマイナスの効果を引き起こしてしまう。

 

正しいフィードバックを見極める姿勢は続けつつ、次は"正しく届ける"ことを意識したい。

 

おそらく、目指すべきゴールはそんなフィードバックがなくてもチームや個人が自律的に課題を見つけられる世界なんだと思う。チームの中からの目線とチームの外からの目線のギャップをなるべく小さくしていきたい。

 

同じものを、同じように見るようにしていきたい。

SRE とプロダクト開発の EM を兼務して半年経った

3ヶ月前の振り返り

https://blog.chaspy.me/entry/2022/12/24/120000

いろいろキツかったがなんとか走り切れたかな、というそんな感じ。うまくいかない時期もあったが、周囲にサポートしてもらいながら、少しずつ前に進むことはできたと思う。

SRE

ややハードになりそうな状況ではあったが、なんとか乗り越えられたと思う。メンバー1人1人の自立性と技術力のおかげだと思う。

11月に1人、2月に1人入社し、メンバーは7人になったところで採用を止めることができた。これにより採用活動にかけていた時間を使わなくなったのは大きい。

新しく入った2名についても順調に立ち上がっていると判断していて、1on1は細かめにやっているものの、マネージャーというよりはメンターとそれを受け入れるチームが正しく機能していたことが大きいと思う。

後半の Q4はリーダーが他のチームに留学したり、AWSのアカウント分割プロジェクトで手戻りが発生したりと不安定気味になったが、それについても留学時期を調整したり、リーダーが作戦変更を素早く意思決定し、段階的に変更を進めたり、開発チームとのインタラクションをコラボレーションモードに変更したりと素早く柔軟な軌道修正ができた点は良かった。

この期はアカウント分割プロジェクトを中心に、開発者との Relation を深く考えることができた期だと思う。これまでも開発者からフィードバックを得る、ということはテーマとして打ち出していたものの、具体的に依頼をいつどのようにしたら良いか、という点で学びが多かったし、その基本的な考え方も整理できた。

成果もかなり出ており、次の期でも引き続きやりたいトピックがたくさん出てきている。

次の期は僕が EM をやって4半期目である。(次の10月でちょうど2年)

僕が当時思い描いていたより遥かに遠いところにきていて、特にこの期はチームが格段に良くなった感覚がある。

僕がマネジメントとして成し遂げたことは数少ないが、意識していたことは、

  • メンバーがハイパフォーマンスを出せる環境

  • Teamとして不足している capability を獲得すること

  • Team としてそれを発見、実行できること

現状はこれが回りつつあり、少なくとも実務面ではマネージャ不要な状態にかなり近づいていると思う。(個人の成長支援として少なからずマネージャに残る役割はあると思っている)

チームがチームをセルフマネジメントしている状態、というのかな。

これには1人1人の技術力だけではなく、ソフトスキルも必要だし、何より同じ方向を向くことが大事で、これについてはビジョンミッションバリューを整理した前任マネージャの功績が大きい。僕はそのレールの上でさらにそこに向かうための改善サイクルを強化するための採用と目標設定を補助したに過ぎない。

引き続き"良い課題を発見する"ことを、SRE チームだけではなく、開発組織全体の技術戦略を通じて与えられるようにしていきたい。

Product Secriry Engineer については来期もう1人取りたい。頑張る。

プロダクト開発

B2Cプロダクトの WebDev のマネジメントをやりはじめた。まだ半年らしい。1年以上前からいる気がします、と言われることもある。よく分からないけど、半年も経てば慣れるもんである。

技術的には WebFrontend を触るようになって0から React を触れたのが良かった。楽しい。実際に軽微な改善、ドッグフーディングで見つけた改善はプロダクションに出した。

Native Team と関わるようになったのも新しい経験だった。どうしても SRE と Native は直接的な関連がなかった。お近づきの印に Jetpack compose の置き換えのリファクタもやらせてもらって、(最後はペアプロでおんぶに抱っこだったがw) 無事1コンポーネント本番に出せた。

インフラや監視面でも(それをしにきたわけではないとはいえ、持ってるスキルセットとして)身近に聞ける人ができた面でも貢献できたと思う。が、それを組織の capability として強化する、みたいなことはできなかった。

3Q でやっていた領域はビジネスの方針転換により縮小することになり、この組織変更には痛みが伴うものとなった。ビジネスの方針変更に対して開発組織はそれに合わせて変更する、それによる痛みは少なからずある、というのは理屈ではわかるが、我々人間、感情の生き物であり、そこはもっとうまくやれたところはあったと思う。(結果としてあの時あの時点では最良の選択をしたと思うが、もっと早く手をつけて回避できなかったのか、ということをたくさん考えた)

PLG チーム

Q4 からは体制変更に伴い、PLG - Product Led Growth チームが立ち上がり、そのチームの担当マネージャーに立候補した。チーム立ち上げのプロポーザル自体は別の EM が行い、まんま引き継いだ感じ。

Growth Enginering, プロダクトをプロダクトによって改善し、仮説検証をデータを元に繰り返していくチームだ。今は Android, Web 開発者が1人ずつと、PM が1人、EM が僕の4人の小さいチームだが、立ち上げは順調で既にいくつかの変更をだし、A/Bテストを行っている。

"事実に基づいて意思決定する" Fact based decision making は信頼性領域における SLI/SLO であり、それを事業指標とプロダクト指標で行うこととなんら変わりはない。分析基盤の構築をしながら、高速にサイクルを回して事業指標を改善していくことは僕が最もやりたかったことだった。次の半年はいよいよ成果を出す期である。楽しみだ。

マネジメントの課題

課題は明確である。

  • PM とのコミュニケーション、期待値調整、情報流通

  • 各チームが自立的に改善を繰り返すための組織設計、およびリーダーの育成やアサイン

1つ目については年明けからかなり状況は良くなっており、PM のマネジメントメンバーとの会話はかなり増えた。

みんな優秀でちゃんと話を聞いてくれる、話せばわかる人たちなのがありがたい。じゃあ話せばいいじゃん。話そう。それだけなのである。でもそれだけのことで結構うまくいかなくなるもんである。

2つ目は具体的に現在予定されてる新規プロダクトのリリース後の組織体制の検討がアウトプットになる。この意思決定については早めからありうる未来を考え、メンバーにフィードバックをもらいながら設計し、その設計意図や意思決定については ADR のように残したいと考えている。

3つ目として、技術戦略がある。(システム的な技術課題の解消、組織の技術力向上、ビジネス戦略を見越したシステムならアーキテクチャなど) が、ひとまず次の半年については大玉のリリースおよびチームの再構築によるチームビルディングと安定化が目先大事なので、それが落ち着いてきたら考えたい。

技術戦略

直前で言ったのとは別に、スタディサプリ小中高全体の技術戦略グループがある。このグループもなんと2年だそうだ。よく続いている。尊い。

兼務メンバーで成り立つこのグループは派手さはないものの、地味に成果を出しつつあり、組織としては成熟しつつある。

技術課題を吸い上げて、評価して、計画を立てる。

ただそれだけのことを、1人のリードアーキテクトではなく、ボトムアップでグループで行えるようになっている。これはなかなか凄いことなんじゃないかと思っている。

長年やりたかったシステムアーキテクチャに対するサブグループも立ち上がった。時間はかかったが、着実に良い未来につながる取り組みができていると思う。

自分が担当している DevOps WG も自分たちの様々なことについて、アセスメントを実行してフィードバックを得る、それ自体のサイクルが回っている。

各チームから満遍なく参加してもらっているのはマネージャである自分の唯一の功績である。その多様性により、何気なく持ち込んだら一瞬で課題が解決する、といった良い成果が出ている。このグループの取り組みが SRE チームにも良い影響を与えられており、自分がいて良かったことの1つだと思う。

SRE(2)

BtoB 領域のインフラを何とかしれくれと言われて何とかしにいった。と言っても片手間なので、状況を把握しにいって、方向性を決めて、細々発生するタスクを誰でもできるように標準化したり、意思決定したりする程度。

ちょっとはマシにはなった。

Terraform applyをlocal実行するのドキドキ新鮮だった。

学んだこと

  • 任せた方がいい、だけど丸投げはしない

それはそうなんだけど、でもやっぱり任せた方が結果的には良くなる。でも任せ方は大事で、丁寧に期待値合わせをして任せて、それを最初は結構頻度高く目線合わせとかで会話するとうまく行く。

それはそうということなんだが、やっぱりそうなんだなという感じである。なので、これは続けていきたい。

  • 自分にできないことを自覚し、他者を信頼して、他者を頼る

一時期足りてなかった時期があった。他者を信頼するというのが大事で、今でもちょっと苦手かもしれない。でもうまくいかない時って自分に原因があるので、そういう時はちゃんと内省するってことはできてるので続けたい。

次の半年

  • SRE: チームでチームをマネジメントできるようにする

  • プロダクト開発:

    • 大玉のリリース

    • リリース後の組織設計

    • PM とのコミュニケーション改善

VPoE は席空いてるけど能力が追いつくか余力ができないとできないかもしれない、わからない。

とりあえずこの半年はチャレンジしました。お疲れ様でした自分。

mikefarah/yq 便利

github.com

便利。やや癖ある。

2種類あるらしい。ややこしい。

github.com

本記事では前者のほうの使い方メモしておく。


副業で kubernetes manifest をあれこれオラオラするみたいなときに利用した。

でいろいろ記事を書こうと思ったが example は動く形で GitHub に置いておくかとなり

github.com

こちらを書いて満足した。

一括処理をするときに、同じパターンを複数のサービスに展開する時などは環境変数から入れることが多いと思うのでこれを知っておくと便利。

kustomize のリファクタリングとかよくやると思うのでこれまた便利。

最近こういう学んだことメモやってなかったので GitHub に書いていくスタイルでやっていきたい。