ツナワタリマイライフ

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

「SRE の知識地図」本が出版されました!

こんにちは。chaspy です。こっちの世界では近藤と言います。

ドン!

gihyo.jp

というわけで先日 9/10 に世の中にでました。わいわい。買ってくれた人読んでくれた人ありがとう。まだの人はこれからよろしくお願いします。

いい本です!

あらためてパラパラ読んだんですけど、SRE の要素が過不足なく詰まっていて、日本語の書籍は他にないんじゃないかと思います。SRE Book を読める人は読んだらいいと思うし、SRE をはじめようは結構精神論もある。その中で手っ取り早く要素をキャッチアップできるので、SRE に関心がある幅広い人に手に取ってもらえるといいなと思ってます!いい本だ!

担当は SLO

自分は第2章「信頼性を定義して組織で運用する」を担当しました。自分自身が経験してきたこと、血肉になったことをあらためて言葉にして、これから学ぶ人にぎゅっと重要なことを詰めたつもりです。

自分のキャリアは SRE Lounge / SRE NEXT というコミュニティとともにありました。その運営メンバーと一緒に書けて嬉しかったな。機会をいただけて感謝です!

本書の前書きやレビューに関わってくれた人もたくさんいて、本当に感謝です。ありがとうございます!

読んだ人、フィードバックお待ちしています!

X でのつぶやき、ブログ、Amazon のレビュー等感想どんなに些細でも残してもらえると嬉しいです。よろしくお願いします。 #SREの知識地図 でよろしくお願いします!!!

これに合わせて企画等あればなんでもウェルカムです。声かけてください。

おまけ

嬉しい!

今日は著者人で打ち上げ(1)でした!

マネージングアップ(上司への働きかけ) #あらたまいくお 感想

聴いた。とても良かった。中間管理職(管理するもされるもある)からこそわかることで、これってマネジメントキャリアこそは興味がないが、自分のキャリアをいい感じにしたい人にとって有益だと思う。

色々良いなと思った点はあるが、

  • (お互いに)心から信頼すること
  • 忙しそうな上司からの仕事の巻き取り方、巻き取られた側の心情
  • 巻き取った仕事がうまくいっても行かなくても悪いことにはならない

というのはその通りだと思う。巻き取ろうとしてくれた・やってくれた時点で1つ視点を共有できたことになるし、それは今後何かを任せやすい、ビジネスパートナーとしてのありがたさが増すのは間違いない。

徒然と話すのもラジオっぽくて良かった。

自分自身の経験として、メンバーの時はあまり「上司の仕事を巻き取る」ということは上手にできてなくて、どちらかというと勝手にやる、に近かった。今思うととてもよろしくない。

自分がマネージャになると、適切に巻き取ろうとしてくれるメンバーのありがたさを感じたし、自分自身も上司に対してこれは巻き取れそうか?と考えて、(勝手にではなく)対話をした上で巻き取ったり逆に分担(上司にお任せ)したりすることが少しずつできるようになった。

マネージャとしては、巻き取られability を上げるのは重要だと思う。その1つに自分自身のやってることや考えていることを発信することがある。任せればいいでしょというのは正論だが、何でもかんでも任せるのは丸投げと紙一重である。人間なので、誰にどう任せるかというのは日々すごい勢いで過ごす中でそれなりに悩む。

そんな中で、こうしたいと考えている、ここをなんとかしたいと思っているというのを話すと、巻き取り可能範囲(?)を開示できていることにもなると思う。

全体への発信は最近あまりできてないと反省しつつ、自分は日々の 1on1 はもちろんメンバーのための時間であることは大前提だが、自分自身も話を聞きながらこうすればいいのでは、という思考の整理になったり、結果自分の考えを話すことで任せたり任されたりができるようになっている。自分にとってもありがたい時間である。

超発散した。良い回でした。他の回も聞いて感想書きます!

やりたいこと

「やりたいことはなんですか?」「人の役に立ちたい!!!!!」だとアレなので続きを綴る

仕事観の話。


ひとの役に立ちたい #とは

どちらかというと目の前の人の役に立ちたい。

例えば教育プロダクトとは人の役に立ってると思う。たまにユーザの声を聞く。あってよかったと言われる。それはとても嬉しいし誇らしい。自分自身が学生時代あったらよかったと思えるプロダクト。

事業やプロダクトの目指す先に共感できるかは大事だ。でも、その大義を自分自身で実現してやる、みたいなところまではいかない。アントレプレナーではないのだろうな、そういう人は多分身体が動いている。今一緒に新規事業やってる友人を見てもそう思う。自分はそうではない。

その代わり、やりたいことがあるその人に賭けて、その人のために何かをやりたいし、助けになりたい。

そういえば最初の就職先を選んだ時は一緒で働く人で選んだ。インターンを経験して、みんな専門性をもつプロでありながら、なんて素敵な人たちなんだと思った。

やっぱり一緒に働きたいと思える人と働きたい。現職はみんな話せば話せる、いい人たちで恵まれている。

自分のキャリアの大部分を占める、SRE としての働き方が今も大きい影響を持っている。目の前にいる開発者が、信頼性をコントロールできるようにする、快適に開発できるようにする。ちょっとした困りごとをすぐ解決できる、いてくれてありがたいという存在でありたい。

今は SRE から立場は離れたが、マネジメントをやりながら、開発部門以外の人たちの役に立ちたいと思っている。これは正式な仕事というよりは、自分がやりたいので、自分で決めて自分でやっている。

これは簡単ではない。ツールを導入したら終わりという話でもない。適応課題である。人に向き合う仕事である。そういう意味ではマネジメントがやるべき仕事でもある。

自分は根がネガティブである。ネガティブネイティブ、後天的ポジティブである。「どうせ自分なんて」が口癖で、めんどくさかった。

今もそれ自体はあまり変わってない。うまく折り合いをつけられた、とも言える。自分は自分でできることをやっていて、それは自分でも認められるようになった。でもベースが"自分なんて…"なので、基本「みんな最高じゃん」がスタートライン。だから、そんな最高のみんながさらに1.1倍、1.5倍、10倍活躍できる舞台を作ること、支援することをやりたいと思う。

つれづれ書いた。

例えば営業をする人は99%顧客に会いに行ける時間に使えたらいい。(資料作成の時間は寝てる間にやっておいたらいい) コンテンツを制作する人はソフトウェアのように試行錯誤を高速に繰り返して、顧客のフィードバックを受けながら作っていけるといい。事業戦略を考える人はビジネスに関するあらゆるデータと、それから得られる分析を得て、次の作戦を考えられるといい。

それには広義の技術が必要で、それを手助けしたい。このあたりが will か。

Can とかできること

とはいえ市場が求めるもの、需要があるもので自分のスキルが発揮できる方がありがたがられるよね。

マネジメントの仕事は、この3年半やって、それなりにやりがいを感じながらやれている。難しいこと、失敗したことも多々あるが。

マネジメントの仕事もまた、目の前の人に役にたつ仕事ではあると思う。感謝されるためにしているというとなんかちょっと違う気はするんだけど。目の前の人が新しいチャレンジができると嬉しい。成果を出して表彰されてると嬉しい。活躍していると嬉しい。そこにはまったく自分も…!みたいな気持ちはない。本当に。ネガティブネイティブなので…

このマネージャーのおかげ、と思われないぐらい、でも力を発揮できる場作りができるのが大切だと思う。これは美学かもしれない。自分の中の美学、ある。

あと AI と、手を動かすこと。これは続けている。普遍的な意味としては、マネジメントは定期的に現場感をキャッチアップしないと判断を誤るぞということ。間接マネジメントだけで判断はできなくはないんだが、現場感が離れすぎると説明コストが跳ね上がるので、そうなる前に取りに行ったほうがみんないいよね、という理解をしている。

自分ではない、スーパースターのみんなが輝ける場作りをする、という意味だとマネージャーの方が合っている気はする。マネージャーにはリーダーシップも求められるので、それも使い分けね。

経営とか事業とか

これまではミドルマネジメントをやってきた。でも、経営目標に対して強くコミットできている感覚はない。なんというか、求められる職務は果たしてるとは思うが、これでいいんだろうか感というか。

それこそ部長職をやる最初の最初は事業目標のための開発を計画通りに達成することが責務だと思っていた。それ自体は必要だし正しい。今はその結果責任を一緒に追うべきだと思っている。でもそのために全力で働きかけているか、というと、そこに自分の足りなさを感じる。

この辺りもっとやりたいが、雲を掴む感じだ。時間をかけて考えよう。

おしまい

結局こうやって一回考えて、で、目の前の仕事に全力出すんや!となって、その繰り返し。その先にまた新しいチャレンジがあるのだ。それを自分で作るんだ。

近況 2025/05

5ヶ月も開いてしまった。いったい何をしていたのか。記憶がない。

記憶がないので直近のことを振り返る

仕事

4月から部長の一部を後任に引き継ぎつつ、別の部の部長も兼任することになった。直接マネジメントメンバーは変わらず、社員数は+10、コンテキストは2倍という感じ。

落下傘人事(これは社外からのパターンを指すと思うので正確ではないが…社内でもそれなりに大きい組織(部)に内部経験ない状態から横から担当する、というのはそれなりに難しい)ははじめてではない。やってやれないことはないとは思っていた。

とはいえキャッチアップが思ったようにできたかというと、昔ほどは時間はかけられないのも感じた。じっくりしっかり時間をかけて、整理して…という時間は残業しまくらない限りはない。走りながら、それでも要所を見極めて抑えながら、やるべきことをやる、といった感覚である。

生成AIという大きな波に乗る、というのも引き続きやっている。これまた4月から上長の管掌範囲が増えたことにともない、AI の推進もこれまで自分の担当事業以外にもはみだしていくことになった。

自分としてもコンフォートゾーンを出て、今まで培ってきたスキルがしっかりポータブルスキルであることを実感したり、足りなさを感じたりしている。

しかし抽象化してみるとやってることはどれも同じような気はする。「組織目標を達成するために、状況を把握し、仮説を立て、関係者と会話しながら、やるべきことを短期中期定め、実行できる環境を整えて、モニタリングしつつ、(例外には適宜対応し)結果に繋げる」。テーマや事業や組織が変わっても、同じことをしている感覚はある。単純化バイアスかもしれない。マネジメントなんでも屋という感じになってきた。

影響範囲も広がり、エキサイティングな日々を過ごしている。開発組織外との交友も増えてきた。営業、マーケティング、事業企画、コンテンツ制作、そしてこれまでもパートナーとしてやってきたプロダクトマネージャー。4月はこの手のネットワーキングの機会が多く、可能な限り顔を出して顔をつないだ。

部長となり4半期目である。結果を出したい。経営目標に対してコミットする、結果を出す、ということにこれまで以上にこだわりたい。手段にこだわらない。開発組織内部のことは任せることは任せて、1番効くところに効かせていきたい。AI時代、自ら手を動かして感覚を持ち、確からしい未来にBetしていきたい。

来月で入社丸7年。次の10月でマネジメント丸4年、部長は丸2年である。自分も組織も少しずつ変わりながら、この激動の時代の中、新しい教育を届けていきたい。自分自身も新たなチャレンジを今後も探し続け、変わり続けていきたい。

副業

これまで SRE〜マネジメント支援と3年近く長くお世話になっていた業務委託が昨年10月頃終了した。しばらく休んでいたが、また再開しようと思い、縁あって3月後半から新たにお手伝いさせていただくことになった。

テーマはAIで、割となんでもやるということでカオスな感じで自由にやらせてもらっている。開発生産性はもちろんだし、開発者以外の生産性向上だったり、プロダクトを通じた新たなビジネスの玉作り/検証だったり、組織にどう浸透させていくかだったり…なんでもなんとかする人という感じ。

今の時代において自分自身手を動かせる機会をいただけるのは素直にありがたい。あと、自分の根本の仕事観としてここ1年強く感じることとしては、目の前の人の役に立ちたい、ということがある。プロダクトや事業を通じて社会を良くしていきたい気持ちはもちろんあるが、目の前の人の助けになりたい思いが自分の中で大きいことに気づいた。なのでそういったこともできるのは自分にとってやりたいことなので嬉しいし楽しい。

あとオフィスに行く機会もたまにあり、これまた新鮮でよかった。コロナ前の懐かしい気持ち。

新規事業(?)

友人が考えてる新規事業の壁打ちしてるうちに、営業できる動くデモ欲しいねってことで作り始めている。まずはフロントエンドとバックエンドがあるWebアプリ。ゆくゆくはNative Appも作りたい。

0->1は自分は経験がなく、AIのおかげて今までできなかったことができるようになってすごく面白い。また、マネタイズのリアリティの検証や、事業成長に伴いどこがコストとして比例していくのかを初期から見極めるのも面白い。また、AI をどう活用し、どのように競争優位を獲得するかを考えるのも難しくも面白い。今は2人ともサイドワークだが、うまくいくといいなー。これまた楽しみである。

書籍執筆

年初からやっていた共著のものがようやく手から離れて校閲フェーズに入った。いい経験になった。

という中で次の共著のお話をいただき、これもまたエキサイティングになりそうだ。書籍執筆は自分の人生の中でどういう位置づけになるか、まだイマイチ定まってはない(声をかけていただいたのでやってる!という感じ。)

少なくとも収入の1つという位置づけにはならない気はしているので、なんでしょうね。バンドみたいになればいいんですかね。誰かと1つのものを作る作業というか。それ自体が楽しめるといいなぁ。

カンファレンススタッフ

SRE NEXT 2025 のスタッフをやっている。CfP と Diversity のリードをしている。CfP は無事先日採択連絡を終え、大きな山場を超えた感。プロポーザル応募イベントはやりたかったことだったので、やれてよかった。1個人の感想ですが、質はかなり上がった感があります。

当日までまだ時間ありますがスタッフみんなで良い日を作ろうとしてるので遊びに来てね!

プライベート

あんまり記憶がない…あとちょっとかなり大変なこともあった。

暖かくなってきたので観葉植物をお世話にする時間を作りたい。

スノボにハマって、そういえば2月はカナダのバンクーバーに行きましたね。ネコママウンテンにも行きました。レンタルの step on が良すぎてもうこれ以外やりたくなくなった。来シーズンが早くも楽しみ。

逆に水泳は通う回数が少なくなってきたので、月額から都度会員に変更。ただ泳ぐのは気持ち良いし、スマホから離れる時間は取りたいので、市民プールに朝通えるようにしたいなぁ。

あとバンド!続いている。尊い。羊文学の Burning、ヨルシカの晴る(ベースマジで難しかった)、アブリルのスケーターボーイときて、次は大好きな Aooo のサラダボウルと B'z の ZERO をやる。楽しみすぎる。スタジオ終わった後飲みにいく時間が最大の幸福です。ライブも秋にやる方向で練習中!

今年もまた何か新しいことをはじめたい。妻がやってるゴルフか、スノボの代わりの夏のサーフィンか。

というわけで元気です!飲みに行きましょう!

開発日記 12/15

試合で 1500m 泳いだ。会場と、家に帰ってから作業した。もんじゃおいしかった。

昨日明日やるっていってたこと

monorepo-dep-doctor の ignore file の仕様変更開発。サービスディレクトリ単位で無視したい要望を社内からもらったので。これね。ちゃんと問題なく動いていて安心した。

やった

妻と料理記録系アプリの要件定義を進める

これは妻が時間取れなかったので pend

flutter の素振り

やった

やったこと

monorepo-dep-doctor の改修

"monorepo" ってついてるからね。ディレクトリ単位で無視できるようになりました。

github.com

仕様を変えたので v1.0.0 にした。そうしたらビルドがこけたので直した。

flutter (dart) キャッチアップ

Native App 何か1つ年内でリリースしたいのでやる。

で、さすがに何書いているかわからんのはまずいので公式の Learning contents 追いかけながらコード書いて動かして理解してる。

github.com

半端になったけど introdocution の途中まで。

dart.dev

OpenAI Sora

ちょっと触った。まだうまく Story board でのコントロールができてない。いったん社内の Bot のイメージビデオでも作ろうと思っている。

明日やること

やること管理するなんか簡単なものがほしいなあ。個人 Slack の Later かな。とにかく追加が簡単なものがいい。Twitter で fav ったやつとか取り出すのめんどい。

シンクロしたので明日なりさんと飲みに行く。たのしみ

ちなみに前回7月で次回は年末あたり!といってたのが最後のメッセですごいタイミングだった、うける

他感想

  • OpenAI Pro は毎日触ってるし、本当に3万円の専属秘書である。音声入力でも指示できるし最高すぎる
  • Cursor も毎日触っている。dart をキャッチアップしているが、学習効率も格段に上がると感じる
  • 今もお風呂でこの Blog を書いている。風呂グラマーである。湯船に浸かるの好きなんだよなー

開発日記 2024/12/14

今日は久しぶりに元副業先の元同僚の方とお会いしてめちゃくちゃ刺激を受けた。

自分のキャリアとか今後を明確に考えるきっかけになった。

で、帰宅して妻と合流。色々話して、「クラフトビール」の選び方を参考にするためにタイプ診断の Web アプリを作った。

要件定義と、細かい点とか画像あたり時間かかったが、3時間ほどで概ね動くものができた。

OpenAI o1 pro がえぐすぎる。判定のアルゴリズムとか自分でも思い浮かばないものを出してきた。

加えて cursor pro もようやく契約。すごそうだと思っていたが、2ヶ月以上乗り遅れたことを本気で後悔した。これはマジでやばい。

結果 TypeScript のコードを自分自身で1行も書かずに Next.js のアプリを作り、vercel にデプロイ。

残りはクラフトビールジャンルごとにアフィリエイトリンク流して、役に立ったら買ってもらってちゃりんちゃりんなる仕組みは一応作っておきたいので、そこまでやったら公開予定です。

明日やること

  • monorepo-dep-doctor の ignore file の仕様変更開発。サービスディレクトリ単位で無視したい要望を社内からもらったので。これね。ちゃんと問題なく動いていて安心した。

blog.studysapuri.jp

  • 妻と料理記録系アプリの要件定義を進める

  • flutter の素振り

Datadog LLM Observability で custom evaluation を使ってみた

こんにちは!本記事は、Datadog の LLM Observability 機能において、custom evaluation を利用して独自の評価指標を送信した例を紹介します。

この記事は Datadog Advent Calendar 2024 10日目の記事です。

LLM Observability 概要

LLM Observability は、Datadog が提供する LLM(Large Language Model)アプリケーションの観測機能です。
OpenAI や Azure OpenAI、Anthropic といった様々な LLM プロバイダに対するプロンプト・レスポンスを可視化・分析できます。
これにより、LLM に関する以下のような観点での観測が容易になります:

  • LLM への入力(prompt)と出力(response)のトレース化
  • トークン使用量、応答時間、成功・失敗ステータスの可視化
  • ダッシュボード上での総合的な分析

Datadog LLM Observability 概要ページ

さらに、Datadog LLM Observability では、evaluation(評価)を送信することで、モデルの回答が正しいかどうか、ビジネスロジック的に望ましい回答になっているかなどの独自指標を可視化できます。

custom evaluation とは

custom evaluation とは、LLM の応答結果を独自基準で評価するための仕組みです。
例えば、LLM が出した回答が正解か不正解か、あるいは特定の条件を満たすかどうかを、自分たちで定義したロジックで判定し、その結果を Datadog に送信することで、後からダッシュボード上で分析・可視化できます。

Python SDK であれば利用は簡単ですが、Application が Python でない場合は API 経由で直接 JSON を POST することで評価メトリクスを送信可能です。

docs.datadoghq.com

TypeScript での実装例(抜粋と解説)

以下は、TypeScript から Datadog LLM Observability に独自の評価メトリクスを送信する例の一部抜粋です。

// custom evaluation metric を送信する関数例
export async function submitEvalMetric(
  spanId: string,       // LLM要請に対応するスパンID
  traceId: string,      // トレースID
  timestamp_ms: number, // 評価を行う時刻(ミリ秒)
  evalResponse: string, // "1" なら正解、"0" なら不正解などの独自評価値
  DATADOG_API_KEY: string,
) {
  // "1" -> "true", "0" -> "false" といった形で評価値を変換
  const categorical_value = evalResponse === "1" ? "true" : "false";

  // Datadog へ送信する JSON ボディ
  // metric_type="categorical" とすることで分類メトリクスとして送信
  // label="Answered" は評価対象の指標名
  const body = {
    data: {
      type: "evaluation_metric",
      attributes: {
        metrics: [
          {
            span_id: spanId,
            trace_id: traceId,
            ml_app: "your-llm-app",         // モニタリング中のアプリ名
            timestamp_ms: timestamp_ms,
            metric_type: "categorical",
            label: "Answered",
            categorical_value: categorical_value,
          },
        ],
      },
    },
  };

  const res = await fetch(
    "https://api.datadoghq.com/api/intake/llm-obs/v1/eval-metric",
    {
      method: "POST",
      headers: {
        "DD-API-KEY": DATADOG_API_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(body),
    },
  );

  if (res.status !== 202) {
    const responseBody = await res.text();
    console.error(
      `Failed to send evaluation metric to Datadog. status:${res.status} body:${responseBody}`,
    );
  } else {
    console.log(`Successfully sent evaluation metric to Datadog. status:${res.status}`);
  }
}

ポイント解説

metric_type に "categorical" を指定すると、true/false だったり、ラベル分けによる評価が行えます。 今回は label フィールドで「Answered」という指標名をつけ、回答できたかの True / False を送信しました。

metric_type は他に score もあり、この場合 score_value で number を送信できます。

なお、この 0 or 1 を判定するのに LLM as a Judge を利用しており、LLM によって「質問に回答できているか?」を評価させたものを submit しています。

    // Evaluation
    // TODO: Structured Output を使ってみたい
    // ref: https://techcommunity.microsoft.com/t5/ai-azure-ai-services-blog/introducing-gpt-4o-2024-08-06-api-with-structured-outputs-on/ba-p/4232684
    const evalMessages: Message[] = [
      {
        role: "system",
        content:
          "あなたは質問と回答のセットを評価します。質問に対して回答できているかを判断してください。回答できていない場合は 0、回答できている場合は 1 を返してください。",
      },
      { role: "user", content: `質問: ${content} 回答: ${originalAnswer}` },
    ];
    const evalRes = await evaluateRequest(
      env,
      evalMessages,
      traceId,
      evalSpanId,
      spanId,
    );

スクリーンショット例

今回はとある RAG を利用した Bot で利用しました。このように Answered(名前微妙ですね...)という指標が categorical で TRUE / FALSE で送られています。

感想

API が用意されているので、Python 以外でも送ることができました。

このように簡単に利用できるので、LLM Application を使う場合は最初から入れておくと良いでしょう。モデルを変更した場合の評価もできますし、他のアプリケーション同様 Datadog 上でモニタリングが可能になります。metrics として扱えるのでアラート設定も可能です。 ぜひ使ってみてください。