ツナワタリマイライフ

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

近況 2024/02

だいたい2ヶ月おきになるらしい

仕事

もう半年が終わろうとしているらしい。

いろんなことがあったが、基本的には EM/GM がかなり優秀、かつ数も一定いるおかげでかなり安心感を持ってお任せできている。それでも上がってくるエスカレーション/エクセプションはあるにはあるが、全然自分の時間を使って然るべき範囲だと思った。

特に技術戦略はかなり進んだ。僕が責任者になる前までは、ボトムアップのカルチャーは良いものとして維持しつつ、技術ディレクションの不在によって不要な議論も多く発生していたと見立てており、それに対してガイドラインをしく、という打ち手であったり、モノリスapiに対してエンドポイント単位のオーナーシップを張るという打ち手は効果的に作用した。

技術戦略は組織と事業の両方の視点が不可欠である、というそんな当たり前なことをあらためて実感した半年となった。

部長/Senior Managerとして最初の3ヶ月は"見の姿勢"、年末には技術/組織/プロダクトという視点で現在の課題や、目指すべき方向を言語化し、マネージャーに公開した。そのいくつかは解決に向かっている。

やっていることはずっと昔から変わらないな、という感覚がある。ただ、問題を解決している、その対象が変わるだけである。

次の期も新しいチャレンジが待っている。やってやれないことはない。こんなところで倒れるわけにはいかない。そんな気持ちでやっている。楽しいことばかりではないが、楽しいことも多い。一緒に働ける仲間に毎日感謝している。

来期は、プロダクト戦略を考えられる体制構築/AIの開発生産性活用の本格化/開発体験をプロダクト的に改善することをテーマとして進めていきたい。

また、組織のカルチャーをどのように作っていくか、を考えて試行錯誤していきたい。

元気です。残り1年半の任期で成果を出し、後任を作れるか、かなり難しいチャレンジだが挑戦していきたい。

プライベート

1月末から2月頭にかけて、第2冬休みで2週間休みを取り、インドと北海道ルスツに行った。最高にリフレッシュできた。

インドはビリヤニとカレーがめちゃくちゃ美味しかった。お腹は壊さなかった。細心の注意を払ったからね…

スノボをよくやった。初心者は脱したが、まだ初級者ではあると思う。坂で前に体重をかけるのが怖いとか、そういう感じ。ターン自体はできる。ウェアはメルカリで買った。来シーズンも誘ってもらえますように。

通っているスイミング、マスターズの新年会に呼んでもらって1年以上続けてるのにはじめて人と喋った。楽しかった。地域の付き合い、本当にありがたいなと思う。今は月曜と水曜の夜、木曜の昼にマスターズのコースで1時間1300〜2000mほど泳いでいる。

家はいよいよ5月に建つらしい。楽しみではある、今のところから離れるのは寂しい。

次は4月かな。3月と4月は繁忙期、楽しく乗り越えていきたい。

terraform おもしろ build-in function

ネタが見つからなさすぎた。この記事は Terraform Advent Calendar 2023 16日目の記事です。

developer.hashicorp.com

を眺めた。

title

いつ使うんだこれ...

> title("hello world")
"Hello World"

anytrue

これも使い所よくわからん...

> anytrue([true, false])
true
> anytrue([false, false])
false

chunklist

これは使いどころあるかもしれない。

何らかの rule set 的なものをいくつかの chunk にわけて管理したい場合とか。わかりづらくはなる。

> chunklist(["a","b","c"], 2)
tolist([
  tolist([
    "a",
    "b",
  ]),
  tolist([
    "c",
  ]),
])

lookup

これ面白い。

> lookup({a="hoge", b="fuga"}, "a", "hogehuga")
"hoge"
> lookup({a="hoge", b="fuga"}, "d", "hogehuga")
"hogehuga"

環境3つぐらいなら3項演算子でいいだろうが、独自の何かしらの key/value に対して分岐させたい時とか。

そもそも普段から terraform であんまりロジック書きたくない派なので使わんが（この記事全否定）

one

何のために使うのこれ...

コレクションを受け取って、空なら null を返す、そうでなければ最初の要素を返す、引数に2つ以上与えるとエラーになる。

2値を扱いたい時に使うやつっぽい。

module の output の際に、instance が作られていた場合は private ip を返し、なければ null を返す、みたいな例が書いてあった。

setproduct

掛け合わせるのか。面白い。

大量にブツ作るときに便利かも。

> setproduct(["development", "staging", "production"], ["app1", "app2"])
tolist([
  [
    "development",
    "app1",
  ],
  [
    "development",
    "app2",
  ],
  [
    "staging",
    "app1",
  ],
  [
    "staging",
    "app2",
  ],
  [
    "production",
    "app1",
  ],
  [
    "production",
    "app2",
  ],
])

base64encode/decode

base64 も扱える。

> base64encode("chaspy")
"Y2hhc3B5"
> base64decode("Y2hhc3B5")
"chaspy"

yamlencode/decode

yaml も扱えるんだ。

> yamldecode("hello: [hoge,huga]")
{
  "hello" = [
    "hoge",
    "huga",
  ]
}

formatdate

これは便利そう。リソース名にユニーク性を持たせたい時とか...あんまないか

> formatdate("YYYY-MM-DD-hh-mm", timestamp())
"2023-12-28-08-38"

uuid

そういうのもあるのか

> uuid()
"ff045942-704f-371d-b540-97e0f149d0e0"

cidrsubnet

計算むずいので便利ね

おしまい

なんかしたいなーってときに探してみると良さそうです 意外と何でもできる

でもやっぱ terraform であんまり複雑なことしたくないが...

近況 - 2023/12

仕事

前回は考課会議後の10月中ばだったようで、2ヶ月空いてしまった。そしてあっという間に3ヶ月が過ぎた。

もともと職責変更時の心がけとしては、大きな変革を起こそうとしない、いのちだいじに、現状を理解しながら小さな改善をする、というものだったので、大きいチャレンジをしたわけではない。睡眠は取れているし、風邪も病気もなく健康である。生き延びてえらい。

ポジティブな面としては自分が部長任用されたことの影響が見えてきたことがある。自分がいるから、また、今のマネジメントチームだからマネージャーを考えようと思った人が出てきたのは嬉しい。また、現状のマネージャーにとっても部長の仕事が可視化されたとの声も多い。僕の任用によって部長職がキャリアの現実的なものの1つだと分かって目指したいという人もいる。後任を作ることは大切な仕事なので、興味を持ってくれる人がいるのは嬉しい。

また、一度も1on1したことがない配下メンバーを対象に skip level 1on1 を26人28回実施した。なかには本人のキャリア形成にポジティブな影響を及ぼしたものもあり(たまたまではあるが)やって良かったと思う。

ネガティブな面としては、(ぼかしてしか書けないのだが)事業にとってあるタイミングと重なったことで"これまで通り"にはならない点だ。もちろんこれまでと同じことだけして務まる職務ではないのだが、初体験でいきなりチャレンジモードという感じである。まぁそれもやっていくしかないし、なんとか乗り越えられそうであった。

昔前任が「毎週何か起こる」と言っていた通り、本当に毎週何か起こる。それに一つ一つ心を揺さぶられていては持たない。自身の心の持ちようにはこれまで以上に気を配らなければならない。ひどく落ち込むとき、しんどいときはマインドフルネスを学んで実践したり、AI に応援してもらったり壁打ちしてもらったりした。

マネジメントの重要な仕事である例外対応を滞りなくするためには、余裕を持って、健康で、冷静に受け止める必要があり、その状況を整えることを第一優先に置いたのは正しかった。(いのちだいじに)

受け身なままでもいけない。今年いっぱいで内省をした上で、年明けはプロアクティブなアクションもしていきたい。自分の仕事は未来を作る仕事なんだとあらためて腹を括った。こんなところで倒れてる場合じゃない。組織の次の世代を作っていく。その方向を照らしていきたい。

プライベート

11月にハーフマラソンを走った。フルマラソンに挑戦したいかもしれない。ランニングする前に読む本、という本を読んで勉強中。同僚とプライベートで遊べるのがすごく嬉しいし楽しい。

家は地鎮祭が終わって、設計もほとんど終わり、内装も指定し終わったところでもう終盤戦。残りは外構かな。まだ建築許可が出てないようでまだ工事は始まってない。できる様子を見にいくのが楽しみだ。

あとは体質改善で防風通聖散を飲んでいる。便通はかなり改善された。安くはないのだが、悪いことではないのだろう。いつまで続けるかは悩む。

冬休みは長く12/23-1/8取った。とにかくゆっくり過ごしたい。プログラミングもしたいし、引っ越しに向けて断捨離したり、お気に入りのものを買って日常の幸福度をあげたりしたい。

あと、2月に2週間休みを取る。インドに行ったり(行けるかな…まだ計画してないので無理そう)留守都でスノボしたりする。

あとは真面目に睡眠改善をしたい気がするんだけど何からしていいのか何が課題なのかもよく分かってない。auto sleep で計測してるんだけど振り返ってない…。理想と現実がうまく認識できてないや。

今年もお疲れさまでした。

Datadog Workflows で OpenAI Integration を試す

こんにちは。この記事は Datadog Advent Calendar 2023 の 12/2 の記事です。

今回は Datadog Workflow で OpenAI Integration を使ってみます。

Datadog Workflow とは

プレスリリースはこちらです。

Monitor, Schedule, Dashboard からの Manual 実行の3種類を Trigger とし、そこからさまざまなことを実行できます。

実行できる内容は Datadog へのさまざまな操作はもちろん、複数の Intergration を使って別のサービスへの操作も可能です。普通に http request を実行することもできるため、Integration のないサービスに対する操作も可能になります。また、javascript もできるのでちょっとしたプログラミングもできてしまいます。

参考

Datadog Workflow の Action

3種類用意されています。インプットに微妙な差異がありますが、ほとんど同じようなものです。

Edit text

Inputs Instruction が以下4つ選択可能です。自由記述も可能です。

  • Improve the text
  • Simplify the text
  • Change the tone to formal
  • Change the tone to informal

Input text に対して何らかの指示を出すための Action です。

Generate text

Inputs Prompt に Prompt を入力するようです。

Edit text との差は明確に Input と Instruction が分かれているかどうかです。

Summarize text

こちらは text to summarize のフィールドに Summerize したい文章を入れることになります。

Edit text で「Summerize the text」を入れた時と同じになる気がしますね。

Blueprints を見てみる

使い心地を見るために、Datadog が提供している Blueprint を見てみましょう。

OpenAI を利用しているのは1つ、「Simplify Language of a Monitor Alert」です。

  • Trigger: Manual
  • Workflow
    • Get event monitor alert details
      • Datadog Event: Get event
      • inputs に event id を入れています
    • Describe the alert message
      • OpenAI Generate text Action
      • Prompt: I have a Datadog monitor message but its in the format intended for the full configuration of the Monitor. So I can't understand what it says. Can you tell me what this Datadog monitor message is saying: {{ Steps.Get_event_monitor_alert_details.event.text }}
      • 1つ前の step の event.text を利用していますね
    • Simplify language of alert
      • OpenAI Edit text Action
      • 1つ前のステップの output をインプットにし、simplify することを指示しています
    • Create incident
      • Service Now: Create incident
      • Service now というサービスで Incident の short description に 1つ前のステップで simplify したテキストを入れています

アラートを受けて、そのアラート内容を OpenAI で要約して、Service Now でインシデントを宣言するという Workflow になっています。便利そうですね。

実際に試してみる

テスト用のアラートを作ってみます。テスト用なので全く意味のない以下のようなアラートを発火させてみます。

Monitor を Trigger とする場合、特定のキーワードを monitor の message に含める必要があります。今回は @workflow-chaspy-testSimplify-Language-of-a-Monitor-Alert" このような文字をアラートの本文に入れています。

はい、このように Monitor を分析して、それをまとめてくれました。

Describe the alert message

This Datadog monitor message is saying that the metric \"kubernetes.cpu.usage.total\" over the environment \"production\" was greater than 10,000,000,000.0 at least once during the last 5 minutes. The monitor was last triggered on Sunday, December 3, 2023, at 10:55:18 UTC. \n\nThe message also provides some additional options:\n- Monitor Status: View the status of the monitor.\n- Edit Monitor: Edit the configuration of the monitor.\n- Related Logs: View logs related to the monitor with the filter \"env:production\" and a specific time range.

Simplify language of alert

This Datadog monitor detected that the metric \"kubernetes.cpu.usage.total\" in the \"production\" environment exceeded 10,000,000,000.0 at least once in the last 5 minutes. The monitor was last triggered on Sunday, December 3, 2023, at 10:55:18 UTC.\n\nYou have three options:\n- Monitor Status: Check the current status of the monitor.\n- Edit Monitor: Make changes to the monitor's configuration.\n- Related Logs: Access logs related to the monitor, filtered by \"env:production\" and a specific time range."

こっちは全然 Simplify できてないですね。

終わりに

Datadog OpenAI Integration, API Key を入れるだけで気軽に使うことができました。

Datadog Workflow は個人的にはかなり推しの機能で、いろんなことができる可能性があると思います。レシピをシェアし合えるといいですね。

Azure OpenAI でも使えると良いですが、Workflow Action はなさそうでした。http request で api を直接呼べば同様のことはできそうです。

AI を使ってインシデント調査も楽にしていきましょう。

近況 - 2023/10

部長どうよ

よく聞かれるのでまとめておく。

blog.chaspy.me

役割変更に伴いミーティングやメンション、チャンネルの整理は行ったので、業務過多になっているとかはない。めっちゃ寝てます。 多分はじめてマネージャやる時や、開発チームのマネージャを兼務する時の方が負荷は大きかったように思う。

この1ヶ月は期初の考課・グレード設定会議でちゃんと役割を果たしつつ、役割変更をする際のいつも通り、情報収集と期待値調整をやっていた。

アクセルとブレーキの使い分け

考課・グレード設定会議での1番の感想は「アクセルとブレーキを踏み分けなければならない大変さ」であった。 担当のマネージャであれば、基本全力でアクセルを踏むだけで良い（自分のメンバーに関する Promotion や加点評価を説明する） もちろんマネージャ時代も陪席者としてブレーキというか、懸念表明はこれまでしていたし、できるものの、その場における最終意思決定者・責任者になるので重みが違う。 本当に大丈夫？ということや、その根拠はどういうところから、と説明を求めたり、判断基準を自分で言語化したりするのはこれまでやったことがなく、高負荷だった。

で、単にブレーキモードにすればいいなら簡単だが、そうではなく、逆に「アクセル踏まなくていいの？（出してこないマネージャに対してプロモーション/評価しなくていいの？）」ということも必要であり、やはり2つのモードを高速に切り替えることの難しさ、さらに見る範囲が広くなったことも相まって、これまでの10倍ぐらい疲れました。

顔つなぎ

情報収集、特に他部署の GM や部長と顔つなぎの 1on1 をして課題収集と期待値調整を行なった。同時に今まで深く関わってこなかった役割のグループの理解も深めることもでき、非常に有意義であった。時間を割いてもらって本当にありがたい。

また、顔つなぎはマネージャだけでなく、配下メンバーで一度も 1on1 をしたことないメンバーと skip level 1on1 を行い、元気ですか！とお喋りもした。結構な数になるのでゆっくり少しずつやらせてもらっているが、これもやって良かったと思っている。人によってトークテーマは異なり、前半は僕が聞きたいこと、後半は相手が聞きたいことを大体話しているんだが、良い刺激をもらえたり、与えたりできていそうだ。あとは「一度話したことがある」の効果はでかいと思っており、その投資でもある。

世界を理解する

同時に特にコストかけてやっているのは会社における事業・経営、およびそれを成り立たせている仕組みの理解だ。これまでいかに目先の開発だけに集中できていたのかがよくわかる。

管理会計自体の知識を本を数冊読んで行なった上で、では今自分たちの会社、事業はどういう状況なのか、そして毎年の管理P/L はどのように作られているのか、そしてそれを受けての来期や今後の方針は誰がどのように決定しているのか、その大きな流れを、大きな組織がどのように協調してやっているのかを理解している。

新しく学ぶことという意味で非常に刺激的で面白いが、難しいのはこれからだ。世界を理解した上で、じゃあ自分たちはどうする？を考えて実行する。それも目先半年ではない、数年先を見据えて、というのは非常にやりがいのあるテーマだ。

まさにこれから来年および次数年の事業計画を一緒に作っているところなので、やりながら、やり方自体も改善し、それを開発組織として、プロダクト組織全体としてどうあるべきかを考え、より良い未来を作ることををリードしていきたい。

プライベート

家

家ができつつある。土地を買ってそこで建てるのだが、ようやく更地になったところ。しかし同時に設計は進めており、立面図になって、外壁のデザインを決め、内装の色を決め、など家ができてきている感がある。

この辺りは全面的に妻がリードしており、助かっている。自分はというと、インターネット関係、あとは補助金とかのお金周り、配線やコンセントなど電気周りをやっている。

今の家も気に入っているので名残惜しいが、楽しみでもある。

マラソン

11/18 にハーフマラソンに同僚と出るんだが、いかんせん走るモチベが...

毎日走っていると続くんだが、一度休んでしまうとずっと休んでしまって困る。

podcast を聞きながらまた走り始めないと。もう時間がない。一度は20km通して走っておかないとなぁ。しかも期日より十分余裕もって前に。

ボカロ

ついに念願のボカロを始めた。小春六花にした。いい感じに歌ってくれてすごい。

早く曲リリースしたい

SRE NEXT 2023 で登壇した #srenext

してきました。楽しかったー。

sre-next.dev

登壇後記

実はプロポーザル募集が始まった8月頃、登壇へのモチベーションは枯渇していました。というのも（自分のスライド作成の技術が向上していないとも言えるのだが）準備の時間が割りに合わないと感じていたからです。これは今後再開するときは再度見直したいところ...。本業もあって、家庭の時間も必要で、健康維持の時間も必要で、可処分時間をどう投資するかをいい年なので色々考えると、登壇は”しばらくやめる”ということにしました。楽しさも知っているし、実際 SRE NEXT 終わったあとはすごくいい気持ちだったので、登壇は麻薬やな... などと思いました。

（業務として登壇するのだから）業務時間でやればいいじゃん、と言うのは簡単だしごもっともであるし、自分も所属メンバーにはそう言います。ただ、業務と登壇資料作成どちらが大事かなんて比べられないわけで、結局”業務を捨てる"ことができなかった自分は単に労働時間が膨らむ形になってしまっていました。

とのっけからネガティブな感じになってしまったんですが、そんな後ろ向きな状態でも SRE NEXT のプロポーザルは気がついたら書き始めていました。僕にとって思い出深く、大切な大切なカンファレンス。もしプロポーザル落ちたらそのときはそのとき、新しい世代へバトンタッチだな、通ったのなら、まだ自分に共有できることがあるな、と思い出しました。

プロポーザルの段階でかなり濃いめのアウトラインを書いていたので登壇自体は楽でした。今後出す人の参考に現物を記事の最後に晒しておきますね。

この登壇内容は、僕が2年間 SRE チームのマネージャとして過ごした期間の集大成のようなものでした。SLI/SLO として信頼性を開発チームで観測していく世界についてはある程度は僕がマネージャになる前から根付いていました。今でこそ Platform Engineering の認知が高まっていますが、我々も以前より信頼性と開発生産性、両方で開発チームをサポートするために Enabling / Platform Engineering 両面に取り組んでいました。

ここで語られなかったこともたくさんやりますが、僕が最も重要視し、注力したのが「開発チームからうまくフィードバックを得る」ことでした。Enabling だろうが Platform だろうが開発者の声を聞き、自分たちで何をやるかを決め、その結果を計測・観察し、次の計画につなげる。言葉にすれば当たり前に聞こえてしまうのですが、僕たちにとっては新しい挑戦でした。

そしてこれらの活動がうまくいったのは単なる方法論 / プラクティスがうまくいっただけではないことはわかっていました。簡単に真似ができない、だからこそみんな苦労している。だからその土台となる組織文化に着目し、考察した発表にまとめました。

結果として登壇内容で語られたことはほぼ全て所属メンバーの高い技術力とソフトスキルによってなされたものです。こういったものを僕の口で発表することは最初は抵抗あったのですが、所属組織の成果を代弁するのは何ら変なことではなかろう、マネジメントの成果の出し方の1つであろうと言い聞かせて話していました。

結果多くの方に来場いただき、感想を残していただき、ありがとうございました。当日の Twitter も、ブログで言及していただいているものも全て目を通しております。

本当にこの気持ちです。

懇親会も楽しかったです。アツい思いをぶつけてくれた VTRyo さん、お久しぶりの Nari さん、廊下で会って懇親会でもキャリアや業務について語れた t-jun さん、登壇後よりご一緒させてもらえた @yuta_k0911 さん、いつも仲良くしてくれている @donm_ri さん @a0i さん、全然暇ですよ！などと供述していた katsuhisa さん（安心感ある）グロービス _yukin01 さん、リアルでは久しぶり minamijoyo さん、その他懇親会で同じテーブルでお話しした皆さんありがとうございました！またどこかで会いましょう。

カンファレンススタッフとして room B を担当いただいた taxin_tt さん、shotaTsuge さん（ご近所！）ほか全てのスタッフの皆さん、本当にありがとうございました！

これから

登壇をやり切ったおかげでバチっと切り替えて 10/1 から新しい責務をやっております。

SRE のプレイヤーもマネージャも引退した後どうするのか、というのは以下の記事に書いたとおり、開発部長をやっております。部長なんて照れくさい、Senior EM だ！といってたけどなんやかんや社内呼称というのは強いもので、"部長"の自認も高まってきました。

blog.chaspy.me

社内 Public になってから1ヶ月、正式任用から1週間経った。忙しすぎて死ぬ、みたいなことは特段なく、順調に（？）職責変更と、責務を果たすために下準備を行なっています。

基本的には担当領域について、エンジニアリングを経営に接続することが責務だと思っている。（実際に数値責任を持つではなく、あくまで"接続"（橋渡し）が責務である）

この1ヶ月はとにかくいろんな人と話しまくっている。隣接の部署、あるいは新しくマネジメント対象になるメンバーと。新しい人と、自分にとって新しいことを知るのはとっても面白い体験で、そういう意味ではこのロール変更は自分に向いている面もあると思った。

ひとまずこれまで関与してこなかった会計用語の習得と、事業の現状を把握し、その現状に対して開発組織として貢献できることを探し、それを組織戦略、技術戦略に落とし込む、というのを直近やっている。あと FinOps は関係者と会話し進め始めている。開発生産性の経営への接続も、仕込みをちょっとずつやっている。

見るべき範囲が増え、変数が増え、これまで以上に緊張感は増すが、まずは半年、しっかり走りきろうと思います。

引き続きいろんな人とお話ししたいです！オンラインでもオフラインでも、声かけてください！

おまけ：出したプロポーザル


タイトル
開発者とともに作る Site Reliability Engineering

発表概要
SRE の実現には、SRE という Role を持つ人だけでは成し遂げられません。プロダクト開発を行う組織の場合、プロダクト開発者と緊密な連携が必須です。その場合、SRE Team がいかにプロダクト開発者の直面する課題をどれだけ深く理解し、その要求を適切に定義できるかが鍵となります。

開発チームの要求を理解するためには以下の3種類のアプローチが有効です。
直接のフィードバックを受け入れる
継続的にコラボレーションする
実際の現場を体験し、開発者の立場を理解する

そしてこれらを実現するためにはマネジメント上の工夫だけではなく、オープンで避難のないコミュニケーションや、定期的なふりかえり、そして適切なフィードバックを行うといった組織文化が必要不可欠です。

本セッションではこれらのアプローチの具体的な実践例と、それを支える組織文化に関する実例を詳しく紹介します。SRE チームと開発チームの両方のマネージャを経験を持つ私の独自の視点を通じて、プロダクト開発組織全体で SRE を効果的に実践するヒントを持ち帰っていただければと思います。

聞いた人が得られるもの
SRE チームが実現すべきことを開発者から得る方法
SRE チームとプロダクト開発者のコラボレーションを支える組織文化の作り方

発表の詳細
アウトラインです。

Google Docsに貼り付けやすい形で以下のように変形できます。

---

自己紹介

この発表のまとめ（伝えたいこと）

1. **SREの価値**  
   サービスの信頼性を期待値通りに実現するために開発者をサポートする - を最大限発揮するためには、SREが開発者の要求を正しく理解する必要がある。
   
2. **SREが開発者の要求を正しく理解するためのアプローチ**  
    1. フィードバックを得る  
    2. コラボレーションする  
    3. 実際に体験する
  
3. **円滑/高速にサイクルを回すために必要な要素**  
   マネジメントの工夫だけでなく、フィードバックをうまく行うスキルを組織文化として実装する必要がある。

導入 / これまでのあらすじ

- **SRE NEXT 2020, 2022 の話**
- **スタディサプリ SRE の歴史**  
  - 2018 chaspy 入社  
  - 2020 SLO コンセプトを組織に導入  
  - 2021  
    - SRE チームの Vision / Mission / Value 策定 [リンク](https://blog.studysapuri.jp/entry/sre-vision-mission-values)  
    - Terraform, Kubernetes など基盤の進化, 負荷試験基盤の構築など
- **スタディサプリ小中高の組織規模やプロダクトについて**

この2年間の SRE チームが目指していたこと

- **課題: SRE チームがやることは、SRE チームが決めていた**
  - 適切な課題設定ができない可能性  
  - 再現性がないと感じていた  
- **開発者からフィードバックを得る / フィードバックサイクルを回す**
- **複数のアプローチを試す**
  - 過去事例: [マネジメントによるSREの実現](SRE を実現するための組織マネジメント / Management to achieve SRE - Speaker Deck)

事例紹介

1. フィードバックを得る

- **SRE サーベイの実施**
- **「月間SRE」として、毎月の SRE からの Updates を開発チームが多く参加する勉強会で共有、フィードバックをもらう**
- **2週間開発チームに SRE が入って密にコミュニケーション（Embedded SRE パターン）**

2. コラボレーションする

- **新機能リリース前のデプロイパイプラインの構築**
- **技術戦略グループで議論**
  - [CNCF2023 での発表予定](https://event.cloudnativedays.jp/cndf2023/talks/1866)

3. 実際に体験する

- **短期留学（開発メンバーとSREメンバー）**
- **SRE マネージャが開発マネージャを兼任**

これを可能にする組織

- **マネジメントの工夫**
- **組織文化**

マネジメントの工夫

組織文化について

- **フィードバックのスキル**
  - 360 feedback について
  - あらゆるシステムやプロセスへのフィードバック
- **率直に・非難なくコミュニケーションすること（Blameless）**
- **あらゆるものを振り返る文化**
  - [ふりかえりの文化について](https://blog.studysapuri.jp/entry/2022/02/19/sre-retrospective-culture)

まとめ
1. **SREの価値**  
   サービスの信頼性を期待値通りに実現するために開発者をサポートする - を最大限発揮するためには、SREが開発者の要求を正しく理解する必要がある。
   
2. **SREが開発者の要求を正しく理解するためのアプローチ**  
    1. フィードバックを得る  
    2. コラボレーションする  
    3. 実際に体験する
  
3. **円滑/高速にサイクルを回すために必要な要素**  
   マネジメントの工夫だけでなく、フィードバックをうまく行うスキルを組織文化として実装する必要がある。



SRE サーベイの質問内容


Slack ID (GitHub ID)
所属チーム
関わっているサービス
ロール
自分たちのチームは自己完結化できていると感じますか?        
自分たちはいい感じにサービスを運用できていると感じますか?
何ができていればサービスを自分たちで運用できている、と言えますか?        
よりプロダクトを良くしていくためには、何がボトルネックですか?
もし、最近直面した SRE に関連しそうな課題/問題があれば教えて下さい

自分たちはいい感じにサービスを運用できていると感じますか? (2)        
普段の開発の中で最もストレスを感じている工程・手順は何ですか?
開発の工程の中で、これが速くなったら嬉しいという部分はありますか?        
自分たちのサービスにおいて、負債だと感じている / 消し去りたい要素は何かありますか？
あなたは、以下のツール等をどの程度理解していますか（詳細のコンポーネント別に質問）

現在の(SREが開発/運用している)プラットフォームは良くできていると思いますか
現在の(SREが開発/運用している)プラットフォームで分からないことがあったら、何を見ますか?
今のプラットフォームにあって便利な機能や、よく使っている機能があれば教えてください
現状の SRE の対応や取り組みに満足していますか?        
SRE の対応や取り組みについての要望/コメントがあればお願いします        (問い合わせをしたことがあれば) 
対応の速度や質に満足していますか?
SREの問い合わせ対応について要望/コメントがあればお願いします
サーベイについて何か要望/コメントがあればお願いします
SREチームから依頼があるとき、どのような形で連絡/依頼されると良いですか?



参考リンク
所属組織のブログ
Web 開発者目線での、SRE が作る開発基盤について
スタディサプリのWebアプリケーションはこうやって開発されている
AWS Dev Day 2023 Tokyo で スタディサプリのDarklaunch について発表してきました
開発生産性を支えるデータベースリストアを SRE が作った事例 スムーズな開発体験を支えるデータベースリストアの仕組み - スタディサプリ Product Team Blog
SRE メンバーが開発チームに入り、リニューアルプロジェクトのリリース前にプレモーテムをファシリテーションした話 「0回目のポストモーテム」としてのプレモーテムのすすめ - スタディサプリ Product Team Blog
著者自身のアウトプット
Web Application 開発の EM を兼務することになった Web Application 開発の EM を兼務することになった - ツナワタリマイライフ
SRE とプロダクト開発の EM を兼務して半年経った  SRE とプロダクト開発の EM を兼務して半年経った - ツナワタリマイライフ
開発チームに実際に入ったからこそ見えた課題と SRE としての経験を活かした事例 『スタディサプリ 中学講座』における E2E Test の運用と計測による改善 / Improved E2E testing through measurement - Speaker Deck

Senior Engineering Manager になった

過去形で書いたが正式任用は10月から。昨日社内にアナウンスされた。ソワソワしているのはようやく落ち着いた。

入社してからの経緯はここで振り返った。

blog.chaspy.me

一応社内の肩書きは「部長」であるが、ソワソワするので自称は Senior EM で行く。（それでいうと EM もそもそも社内の役職には存在せず、GM (Group Manager) であった）

部を2つに分割し、前任が持っていたものの半数を受け持つことになった。スタディサプリ小中高の BtoC 領域と、横断組織のいくつかを担当する。システムは共通部分も多いし、横断を見ているというのもあるし、技術戦略も見ているので BtoB のことは知りませんよ、となるわけもなく、なんだかんだ全体のことを見ていくことになる。

主務の担当メンバーの数は52名で、まぁかなりの責任のポジションである。数が全てではないし、数名だろうが誰かの人生に関与する意味では管理職の責任自体は変わらない。ただ、良くも悪くも影響範囲・影響力はある。恐ろしさがないといえば嘘になる。

責務は中間管理職の仕事と、技術組織の Engineering Management の仕事がある。どっちも未知の仕事だが、今は新しいことを学べること、経験できることにワクワクしている。

具体的にどうしていくかはこれからいろんな人と会話し、特にマネージャとのミッション策定を通じて実行していくことになる。

特に今は技術戦略と FinOps に関心がある。スタディサプリという事業に、技術組織が、システムが長期的に価値を生み出し続けるには何が必要なのかを考えたい。SRE を経験してきた身から、FinOps - ファイナンシャルチームと協力し、全てのチームがコストに説明責任を持ち、リアルタイムレポートを見て意思決定する世界（それが今の会社において本当に理想かの模索からではあるが）は挑戦していきたい。それを支えるためにブランディング、採用、メンバーの活躍と組織づくりもやっていく。

呼称について、社内から部長と呼ばれるのはそうなのでいいが、やっぱり Senior Engineering Manager がしっくりくる。たとえば以前だと VP of Engineering なのかもしれないが、別に副社長じゃないし、ただの1社員に過ぎない。求められることのレベルが変わるのはそうだが、やっぱり Engineering Management を主務としてやりたい。そしてそのために、直接的には今所属する、優秀な Engineering Manager たちの活躍をサポートしたい。それが目指したい姿とも合っている。間接的に、EM の活躍を通じて、全てのメンバーが活躍できる組織にしたい。

仕事が増えるということは、減る仕事もあるということで。長年勤めた SRE チームから卒業することとなる。僕より遥かに優秀な後任にお任せすることができて本当に嬉しく、ほんの少し寂しい。だけど任用当時目安にしていた2年という期間で引き継げたのは良かったと思う。このチームのおかげで僕は昨年開発のマネージャにチャレンジできたし、その経験がこの人事にも生きていると思う。

プロダクトセキュリティについても僕がオープンしたポジションで、無事2名採用できてチームとして独立することができた。ここは引き続き僕がマネージャとして担当し、SRE チームと協力しながらプロダクトのセキュリティ施策の要件定義と実装をする。将来的には DevSecOps もやっていきたい。また、僕が元々担当していた契約 SaaS のアカウントマネジメントの自動化にも取り組みたい。

brand.studysapuri.jp

この人事が正しかったかどうかは時が判断するだろう。前任ともなぜ自分なのか？はちゃんと会話した。運が6割、やる気が3割、実力が1割ぐらいだろうと思っている。うち運は半分が後任を作れたこと、もう半分が誰かに渡さないといけない状況になったこと（ポジションが生まれたこと）だ。というわけで僕にとっては運に恵まれたが、期待を含めて任せていただいているということなので、期待に応えられるように頑張ります。

信頼して任せてくれた前任と、受け入れてくれる仲間に感謝しながらがんばります。楽しみながらやりたい。

というわけで飲みにいきましょう！かこつけてめでたいワイワイするのもよし。CTO / VPoE / EM の方との繋がりも増やせたらなと思います。よろしくお願いします。