ASMのきもち

DBとAnsibleが気になって仕方ない人のブログ

SRE NEXT 2026 参加レポート

SRE NEXT 2026

今年もSRE NEXT 2026に参加してきました！
ということで、参加報告までがSRE NEXT。
呟いていたTwitterの投稿メインですが、ご報告です(｢・ω・)｢

前提

  • 現地参加
  • Day1は朝からバーまで
  • Day2はほぼ閉会式から懇親会、二次会
    • Day2何しに来たんだっていうツッコミはヤメテー



Day1

Reliability is a Question (Keynote)

Davidさんがユーモアおありすぎて、もう本当に面白かった！
Tシャツネタは、登壇者がマネしたい技になりましたね。素敵すぎる。

もちろん、学びもたくさん。英語が出来ないことを今日も悔やんだ悔しい。




GitHub Actions runnerの運用から見るニンテンドーシステムズのチーム体制

ニンテンドーシステムズさんだから話せる、といって、とても有益なお話をしていただきました。
資料サイトがすでに素敵。ブランドデザイン素敵。最高。

やっぱり規模違うな、と。GitHubのジョブ実行数が1日、32000ジョブってレベルが違う。
どうやって統制しているのだろうと思ったら、この考えが目から鱗でした。私の視座の低さを痛感。




ABEMAにおけるIncident Management再設計

インシデントマネジメントを学びに。
障害発生時の役割分担、インシデントコマンダーの重要性を改めて感じました。
ちょうど運用設計を作っていたので、参考になること盛沢山。




テクニカルプロジェクトマネージャーとSREが協働して構築する信頼性

最後の最後まで菱田さんのご登壇と迷ったのですが、今テクニカルプロジェクトマネージャーみたいなこともしてるので、こちら。

菱田さんのお話はYoutubeを後でガン見します。資料拝見しました、共感の嵐でした。
なんで私の身体は一つしかないんだ、MultiAZ構成まだですか。

"正しいはずの依頼"が届かなかった理由 ― 依頼設計を見直す

SRE時代に悩んでいた内容だったので、拝聴。大事なセンテンス三つを丁寧に説明いただき、改めて大事にしようと思いました。



ポストモーテム！DDoSからサイトは守れた。でもビジネスは守れなかった。

タイトルが強すぎる。EDoSの恐ろしさを改めて痛感しました。
クラウド使う皆さん、対策入れないとですよ。



分散システム、なんですぐ死んでしまうん？耐障害性を高めたいあなたのためのレジリエンスパターン入門

タイトルが強すぎる（二度目）。DBREとしてはここは改めて痛感。DBがボトルネックになるにしても、防御を考えないと。



「ちゃんとやっている」は独りよがりだった ― 不安に寄り添うインシデント対応へ

この辺でTwitter（X）にbot判定されて、投稿できなくなりました…ひどい！笑
「うまく回っている」は作った側の思い込みかもしれない。というフレーズに、首がもげるほどうなずき。
そうなんですよ、事業側に行った今、過去の自分は「独りよがりだった」と痛感したので。
関係性大事ですよね。

LT拝聴


SRE NEXT初の試み？飛び込みLTの枠があって、拝聴してきました！

スナックメアリー

最後はスナックメアリーへお邪魔しました！みなさんとわいわい！！
メアリーさんの浴衣姿が素敵すぎました✨
（よしたけさんに素敵写真撮ってもらったので、掲載OKになったら載せます）


Day2

夕方まで家族対応だったので、終わり次第電車に乗りながら拝聴！

CSに"SLO"は要らない、経営層に"99.9%"は伝わらない - SREを全社に"翻訳"する3原則

ゆーたさんのお話を現地できけなかった…
Ask the speakerでもお話させていただきました！ありがとうございます。



ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略

ソニー銀行さん、勘定系までAWSとかつっっっよすぎませんか、というお話。
技術ももちろんなんですが、規約。省庁への説明とか、本当に大変なんですよ。その労力で頓挫することもあるのに、やり切られたのがすごい。かっこいい。

そしてAWSの大阪リージョンはソニー銀行さんがAWSさんに調整して下っていたのも理由にあったとか。日本のAWSユーザの救いです、ありがとうございます…！



拝聴できなかったけど

聞きたかったー！が多すぎました！！
動画配信ありはあとで拝聴するとして、パネルはないので後で本人に突撃しました←




懇親会

わいわい！イツメン方から、お久しぶりの皆さんまで！
沢山声かけていただき、ありがとうございます！！
まさかの、DB界隈の皆さんとも会えたのが、大分嬉しかったです(*´꒳`*)

広島！なみなさんと会話をさせて頂いたり。実は数年前、広島で二回もお話させていただいたんですよ。
登壇者tomoにとって、広島は第二の故郷です。
今年は行くと決めたのでいきます。というか私だと面白くないので、だれか連れていきましょ。ね、ぐりもおさん！

yuuk1さんとこえむさんともお話させて頂いたり。
Twitter上では拝見している皆さんとお話させていただき、とても有意義なお話させていただきました。


雑記




参加したその後

  • 仕事のモチベが大分上がりました！やっぱり外の空気を吸うのは大事ですね
    • 半年、社内に引きこもっていたんですが、酸欠状態でした。もしくは溺れかけ
    • 去年は「来年にCFP出すぞ！」って思っていたのにできなかったのは、そこまで仕事で成果出せていない状態なので、反省。話せる状態まで、あともう少し。がんばろ
  • 以下やることリスト、やっていき！
    • あわっちさんとの漫才、どこでやろうほんとｗ

「憧れは止められない」 - 2025年振り返りと2026年

あけましておめでとうございます！
2026年もどうぞ、よろしくお願いいたします🏇

年末年始に旅行や移動でバタバタしていたといういい訳をしながら、2025年の振り返りと2026年の抱負を、まとめて記事にします。
今回もAI一切使わない、個性あふれすぎる記事をお送りします。誤記誤字はお許しください。

2025年の振り返り

まとめると以下です。

  • 転職して1年経った
  • Software Designさんに記事を書かせていただいた
  • イベント登壇させていただいた
  • イベント登壇ラッシュの後は本業でチャレンジに集中（現在進行中）

以下、端的に感想を。

記事を書くことの難しさ

Software Designさんにイベント参加レポートを書くという機会を、まさかのMySQLコミュニティからいただきました。
大好きなDBエンジンであるMySQL、そのコミュニティからお声がけいただくなんて、本当にうれしかったです。
ただ、記事を書くことの難しさを学びました。編集さんとのメールのやり取りをしながら、単著で本書かれる方の偉大さを痛感しました。すごすぎる…

OracleDBへの想いを昇華

ちょこちょこイベント登壇させていただいているのですが、未だに一度も「OracleDB」を冠するイベントで話していなかったんですよ。OracleDB歴が一番長いのに。
これはまずいなぁと思っていたら、ちょうどJPOUGの登壇募集があったので参加させていただきました。これはもう自己満足です。
このイベント、当時一緒にお仕事させていただいた方が何名かいらっしゃって、イベント終わった後に感想のメッセージをいただきました。恥ずかしい。

LT枠が豪華すぎるdb tech showcase

突然TwitterにDMが来たので何かなぁと思ったら、まさかのdb tech showcaseのLT枠のお誘いでした。
このイベントには何度か一般参加させていただいていたので、まさか自分がしゃべる側になるとは思わず。DBエンジニア辞めてからDBの話をここですると思いませんでした。感無量。
これまでしてこなかった「失敗談」を、可能な範囲でお話させていただきました。失敗の話の方が響くと思いまして。
ただ、このLT枠強すぎませんでした？LTにするの、もったいなさすぎましたよね？？周りが豪華すぎて、恐縮でした本当…

憧れは止められない「SRE NEXT」

約5年前、初めての転職を決意した頃にあこがれたイベントは「AWS Summit」と「SRE NEXT」でした。もちろん当時は、一般参加することだけを夢見ていました。
AWS Summitは初回参加がコロナ期で、オンラインのみ参加。それでも嬉しかったのに、翌年には事例登壇させていただきました。その後さらにもう一回。
これだけでも十分、エンジニア人生において幸せなことだと思っていました。

SRE NEXTも過去、一般参加をさせて頂きまして。活き活きと事例を語られる皆さんに多くの学びをいただきました。
これもまたある日、TwitterにDMが来たんです。SRE NEXTで話をしませんか、と。
そのDM見た後、半日ほど仕事に手がつかずに途方に暮れてました。実感がなかったんです。
それでも何度も見直して、SRE NEXTと書かれているので…断る理由、無いですよね？憧れなんですよ。脳内でナナチが「憧れは止められねぇんだ」って言ってました。

ただ、ちゃんと概要を読んでいなかった（認める）ので、「招待枠」という「基調講演」と同等枠であることを知ったのは、スケジュール出た後でした。スケジュールみて叫びました。
これだから、説明書をちゃんと読まずにとりあえず適当に触る人は。ちょっと反省しました。でもたぶんまたやります。

そんなこともあって、ゆるSREでもパネルディスカッションさせて頂いたり。
SRE NEXTで仲良くなった方とも、またコラボできたらうれしいなぁと思っています。

本業も頑張ってます

詳細は何も言えないのですが、登壇ラッシュの後は本業でチャレンジの機会をいただき、文字通り「挑戦」をさせて頂いておりました。
過去の経験、失敗を生かしたチャレンジです。こんな機会、頑張らなきゃ絶対後悔する挑戦でして、現在進行中で頑張っています。
いつかこの話もできればいいなと思っています。


2026年の抱負

2つほど。

  • 健康第一
  • 英語

健康はまぁ、説明不要ですよね。生きる上で本当に大切なので。
特に私多趣味でして、1日24時間全然足りないー！って毎日のように思っているので、長く楽しむには健康です。運動と食事と睡眠。基本ですね。

英語は、いい加減逃げるのをやめようかと。ただこれは長期戦になるのを覚悟で取り組みます。
PM系や組織マネジメント、EM等も考えていたのですが、それはまぁ後からでもなんとかなるか。と楽観視しています。現状、全くできていないわけではないので。
ただ英語は致命的にダメなので、さすがにまずいなと思い腰を上げることにしました。これはQ単位ぐらいで成果を報告したいなと思います。


すごいことを成し遂げたい！なんていう野望はございません。
ただ、自分の無力さやスキルの無さ、日々の失敗に向き合いながらも。思うことはただ一つです。


「そんなものじゃ、憧れは止められねぇんだ」


今年もよろしくお願いします！

SRE NEXT 2025 で登壇した話の、本音のはなし

画像へのツッコミはあとで


本当は楽しい話がしたかった。聞いている人が、みんな笑ってくれる話がしたかった。
でもそれは、私に求められているものじゃない。

はじまり

ことの始まりは、Twitter(X)に来たDMでした。ちょうど会社のオフィスにいて、会議の合間の休憩時間に気づきました。
何が書いてあるのか頭に入らなかった。入った単語は「SRE NEXT」と「登壇」だけ。
思わず机にうずくまった私に、同僚が「どこか体調悪いんですか？」と聞いてきました。頭が真っ白で、頭を横にふるしかできませんでした。

DBREに憧れ、SREを目指した私が最も憧れたイベントが、SRE NEXTでした。
ようやくSREになって初めて参加できたのが、2023年。勿論GUEST参加。
本当に楽しくて、こんなやり方があるんだ！こんな技術手法があるんだ！と、とにかく夢中になりました。
当時持ち帰った「リリース時にはみんなで同じダッシュボードを見よう」という試みは、今もやってくれているそうです。嬉しいな。
私には眩しすぎたSRE NEXT。登壇するにはCFPを出す必要があります。
出そうよ、なんて社内で話があっても、遠い世界の話でした。私にそんなすごい事例も技術的な話もできない。

その後、SRE/DBREを辞めることを選びました。
様々な後悔がありました。大好きなDBを手放す、技術を手放す。もうSQLは当分打てない。sqlplusもmysqlも打たない。
あぁ憧れていたのにな、SRE NEXTにはもう一度は参加したかった。CFPを出すなんておこがましいけど、だめでも出してみたかった。
その後悔を持ったまま。それでも今、自分が変わらなければならないと信じて、転職をしてまで事業サイドに行きました。

そんな憧れのSRE NEXT。そこから、招待をいただいたのです。
一体何が起きてるのか、パニックにならない人間がいないですよね。

テーマは「Talk NEXT」。
指定されていたURLは、このブログの記事でした。
t.co

あぁそうか。そこで何を求められているか理解して、承諾の旨を返信しました。

最初の気付きの話

最初のキャリアのSIerの会社はなんだかんだ挑戦が大好きで、お客様も同様に挑戦好きな方だったこともあり、「世界初！」という事例を何度か体験しました。
その度に表彰や評価をしてもらった私は「なるほど、新しい挑戦、社外事例に載るようなことは評価されるのか」と、頭の片隅で変な考えを持っていました。
そんな私があるとき実施した挑戦が、MySQL InnoDB Clusterの導入でした。まだ5.Xの段階から検討を開始し、8.0で実装までこぎつけました。
今となっては珍しくもないですが、相当初期に実装、相当なミッションクリティカルなシステムへの導入、既存クラスタソフトの廃止などの成果を同僚達の努力のもと、実現しました。
しかしこれは、評価されませんでした。当時の上司はDBに知見はなかったので「それが何がすごいの？」という回答でした。（数年後に気づいてましたが時すでに遅し）

お客様にとってそれは、何の価値があったの？

当時は「上司が知らないって辛いな〜」なんて思ってました。
それも0ではないですが。
私はその時、少し感じた「もやもや」について何の深堀りも気づきも得ることもなく、ほんの少し浮かんだ疑問をそのままにしていました。
なにせ自分の評価には無頓着でして。
でも管理職になると変わるんですよ。なにせ管理職とは、同僚の評価を上げることが存在意義の一つであり、私にとっての喜びですから。
今でも自分の評価はどうでもいいです。同僚の評価を上げたい。部下って言い方は嫌い。

あの話をするまでの葛藤

資料を作り出したのは、いつもの通りギリギリでした。相変わらず追い込まれないと書かない人です。
ただ、何をどう書くかは、ずっと考えていました。なので書き始めて資料自体はすぐ完成しました。

これを、あのSRE NEXTで話す？

周りはそもそも、SREのことを知らない人ばかりです。相談できる相手はいません。
相談に乗ってくれたのはたった一人、ChatGPTだけでした。
イベント情報、経緯、ブログ記事を伝えた上で、ChatGPTに質問をしました。

技術イベントに、こんな内容話ししていいのかな？
登壇者のリストみてよ、本の著者や研究者、著名人、CFPの中で選ばれるような素晴らしい内容ばかりだよ。
そんな中こんな内容を、DAY1の最後に話すなんて。聞いて楽しい話じゃないよね。

まぁもちろん、ChatGPTは基本肯定する返答を返すわけで、そう作られていますが。
それでも、私の背中を後押ししてくれる言葉は選んでくれました。

「評価されない作業」「システムだけ見ていた」「事業目線がわからなかった」これ、技術者なら誰もが一度は思い当たることなんですよ。
他の登壇者の方々は確かに素晴らしいです。ただ、あなたが選ばれたのは、あなたの経験と視点が今のSREのコミュニティにとって必要とされているからです。
このセッションは「SREとして何を守り、そして何に向かって進むか」を問い直す、最高の問いかけになっています。

嫌なものには蓋をしたいです。
こんな話聞いたって、楽しくないのはわかってはいます。
憧れのSRE NEXTで、わたし、こんな話するのか。と、壇上で会場を眺めながら考えていました。話をする直前の、最後のさいごまで。

それでも向き合わずに逃げていたら、何も前に進まない。
それは私も、あの会場にいたすべての人にも。
だったら。たとえ嫌な話だったと思われたとしても、興味がないと思われたとしても。
いつかその人が同じ課題にぶつかったとき、この話を思い出してくれたらいい。その時、何か助けになれたらいい。
あぁそんな人もいたな、そう思い出してもらえるように。

そう思って、この話をしました。
あの頃の自分を、救える自分になれますように。
speakerdeck.com


おわりに

いつもどこかで失敗して、同じ失敗を次起こさないように。
どうも私は、「あの頃の自分を救えるように」という信念で、仕事をしているようです。
PMになったのも、DBエンジニアになったのも、過去全て「この職種を起因に思い悩んだ」からでした。（色々ありました）
PMもDBも、なんだかんだできるようになったので。いつかは事業サイドも平気でできるようになれるかな。
とすると、新規事業起案から保守運用までできるようになれるね。私、なんでもできちゃいますね。

そこまでできるようになったら、誰かを助けられるようになるかな。
一人でも誰かを幸せにできるようになったら、いいな。


そうそう、タイトルの画像ですが。

スペシャルサンクス：ミミック

蓋をあけたら、ミミックだったりしてね。
わかってても、開けたいんですよ。

だって開けずに進んだ方がずっと後悔するの、分かってるじゃないですか。

db tech showcase 2025に参加しました

LT登壇してきました！

db tech showcase 2025に参加してきましたので、簡単にですがレポートを書かせていただきます！

db tech showcase 2025 イベント概要

イベント名：db tech showcase 2025
主催：株式会社インサイトテクノロジー
開催日：2025年7月10日（木）〜7月11日（金）
開催形式：フルオフライン開催（オンライン配信なし）
※アーカイブ配信は8月中旬以降に予定
会場：TKP市ヶ谷カンファレンスセンター
参加費：無料（事前登録制）

参加した背景

1日目のLT枠

過去何度かGuestとして参加させていただいていましたが、今回は1日目のLT枠に参加させていただきました。
2日目の7/11は別イベント（SRE NEXT 2025）への登壇予定があったため、今年はdb techは諦めようか〜と思っていたのですが、まさかの開催前週にお声がけ頂き、7/10なら！というご相談をして、こちらの枠に入れていただきました。
運営の皆様、ありがとうございます！

ただ正直、LTの枠をみたところ…

何このすごい豪華なスピーカー（一名除く）

な　に　こ　れ
聞いてないYOOOOOOOOOという物理シャウトを添えての参加でした。

なお、2日目も豪華すぎるスピーカー勢なので見てください。

2日目も豪華すぎて直視できない眩しさ

DB界隈に一歩でも踏み込んでいればわかるであろう、豪華さ。
コントリビューターか、本書いてるか、有名企業のテックリードのオンパレードです。なんだこの強すぎるLT。
翌日のSRE NEXT 2025に参加した際も「db techのLT枠、何あれ？」と言われましたが、間違い無い。
お一人だけでもイベントの目玉になるぐらいの業界有名人揃いです。
強すぎるLT枠に参加できたこと、良い人生経験をさせていただいたと前向きに捉えておきました。

登壇資料

資料はこちら。
speakerdeck.com
慌てて書いた感が見え見えですが、過去の自身の失敗かつ、ぼかしても世の中に出していいレベルのものを選びました。大人ですので、ハイ。
勿論とんでもないのもありましたが、会社名有無かかわらず、書けないレベルのものは除いています。それが本当は面白いんですけど、仕方ない。
色々恥ずかしい失敗はありますが、直近で一番恥ずかしいのはこれです↓

勇◯ヒンメルなら、トランザクション分離レベル移行漏れなんてしない

拝聴させていただいた内容

speakerdeck.com
最後のOracleDBのシーケンスRESTARTの挙動が意味がわからない。
なんでそんな動きするの君…！

speakerdeck.com
そーだいさん、15分じゃもったいないです1時間枠でお願いします。

speakerdeck.com
yokuさんが難しいなら、人類に非同期レプリケーションは無理です。

反省
  • ScalarDBの山田さんのお話、聞き耳立てるレベルしかできなくて「やってしまった」と後悔
  • 事前に登録していたはずができておらず、会場入りする際に登録からやるというダサいスピーカー
    • その結果、慌ててセッション選んだので誤って意図せず登録したセッションにしてしまい、あわっちさんの登壇が耳しか聞けず（後でアーカイブ見る）

すごくいいな

  • やっぱり「DB特化」のイベントっていいな。どこみてもDBに関連する話ばかりなので、楽しい
  • 運営のインサイトテクノロジーさんが、写真などをXに投稿してくれたりして、盛り上げてくれていたのがよき
  • ボードに書いてね！もよかった。写真となりに貼ってあるのが見ていて楽しい



ちょっと気になったこと

  • スケジュール詰め過ぎて、休憩時間がない。休憩時間のLTを聞くか、セッション聞くかの2択は辛い
  • （休憩時間がほぼないこともあり）スポンサーブースに人が来ないので、スポンサーの皆様が終始暇そうだった。あれはもったいない
    • 特に翌日のSRE NEXTのスポンサーブースがすごすぎたので、余計顕著に差が出たように思う
  • わがまま言い放題で申し訳ないのですが、上に上がったり下がったりと、階段の上下移動が大変


昔は3日間ぐらいやっていたような？
色々課題も散見されたので、是非改善されていってほしいなぁと思いました。

AWS Summit Japan 2025 に参加しました

AWS Summit Japan 2025

2日目の半日だけでしたが、AWS Summit Japan 2025に参加してきました。
2024年は参加できず、今年の初日も家庭の事情で参加できなかったのですが。
なんとか2日目の午後だけ少し顔出ししてきました。

参加できたのは以下の2つのセッションでした。
正直他にも拝聴したいものが沢山あったのですが、時間の都合上この2つに絞らざるをえなかったので、やむなし。

それぞれ簡単に感想を。

GenU × Amazon Bedrock による実装への挑戦-オイシックス・ラ・大地が実現した 333 時間の工数削減の技術解説 -

GenUの概要説明
コマンド3発で作れるのはすごい

GenU自体は以前から知っていたものの、実用レベルなんだろうか？という疑問があったので、拝聴。
随分進化しており、正直おどろきました。勿論そのまま本番/商用に使えるレベルにはなっていないかもですが、それでもベースができているだけで随分嬉しいですよね。

すごいなと思ったのはここ
これを実現できるのがすごい

チーム外のメンバーを巻き込んで進めている。ここがすごいなと思いました。
まさにSREがやっていく「他者を巻き込んでいく」ができており、それが業務/プロダクト側という点が素晴らしいと思いました。

定量効果
定性効果
業務フローが変わってる！

そう簡単にできないんですよ、業務フローを変えるって。
それがSRE発信出できていることに、とにかく感動しました。素晴らしい事例ですね。真似したいなぁ


「変化を競争力に変える」アジャイルとクラウドで実現する、自律的に成長し続ける組織のつくり方

技術ではなく、組織論の話を。
組織を立ち上げするポイントはなにかという点において、以下3つのポイントが非常に参考になりました。

①リーダーのトーンセッティング

リーダーのトーンセッティング

　「お客様に誠実に！」など、端的なフレーズがメンバーに浸透しやすさを感じました。
　また明文化されていることでチーム間で共通認識がされると思いました。

②「仕組み」と「場づくり」による実践

「仕組み」と「場づくり」による実践
「仕組み」と「場づくり」による実践

　後半に細かく説明がありましたが、個人的にSECIモデルを全然知らなかったので、これはいいなとだいぶ前のめりになって聞いていました。
　>

特にこの点が共感できた

　特にこの三点が非常に共感しました。事業価値と紐づける、皆で作るということで、事業貢献が確実に達成されますよね。

③経営とブリッジ

経営とブリッジ

　プロダクトを作る、生み出す上では経営とのブリッジは必須ですよね。


前後合間にAWSさん、スポンサーさんのブースに立ち寄ったりと、色々回らせていただきまして。
久しぶりにお会いする方と話の花が咲いたり、短時間ですが同窓会に参加したような気持ちになりました。

来年こそは2日間しっっかり回りたい。そんな野望を抱いた、今年のAWS Summitでした。

SRE＆DBREというエンジニアをやめて、事業企画になった話


転職して、1年経ちました。

tomomo1015.hatenablog.com

ということで「いつか記事に書く」と言い続けた事を書こうと思います。
SREを「エンジニア」をやめて、何故事業企画になったのかという話。

SRE、DBREの事業貢献とは

SRE、DBREとして事業会社で働く中で、何度かこの問いにぶつかることがありました。

その可観測化に、その可用性向上に、その信頼性向上は、事業にとってどのような貢献をされているのか説明しろ。

例えばEKSのバージョンアップ。年に一度は実施しなければいけないこの作業の為に、担当してくれていたSREメンバーはUPDATE内容を読み込み、マニュフェストを見直し、システム影響を考慮したバージョンアップ方法を検討し、それらを検証し…等、相当なタスクに追われることになります。傍から見ていてもそれは大変な作業で、間違いなく評価されるべきだと思います。
他にも情シス部門の皆さん、NWを支えてくれていたエンジニア…沢山、溢れんばかりの事業貢献をしてくれていた、エンジニアのみんながいました。
ただそれを経営陣にぶつけたところで「マイナスをゼロにした、ね。でもプラスを産んでいないじゃない。評価できないね。それよりコスト下げられないの？いくら円安とはいえ、年々上がっているクラウド費用をどうにかしてよ。」と突っ返される訳です。

これと似たような経験をされたマネジメント層の皆さん、いらっしゃいませんか。
何も言い返せなかった私は悔しくて、くやしくて仕方なかったです。担当者がどれほど苦労して、システムを通じて事業のことを考えているのか、知っていたからこそ悔しかった。

でも経営陣が言うことにも、もっともでした。事業会社のエンジニアの癖に、このEKSクラスタが生み出す価値を、私は曖昧にしか知りません。このシステムの、この機能を実現している、しか。
で？じゃあこの機能はこの事業、このサービスにおいてどのような価値を提供しているの？そのROIは？
例えばROIが定量的に分かれば、それはEKSである必要もなかった、EC2で良かったかもしれない。他にもっと価値を生み出している、顧客のユーザビリティを提供している重要な機能があれば、それこそEKSであるべきだったかもしれない。

事業企画が提示した機能を、サービスを実現するだけのエンジニア。それが私がやりたかったことなんだろうか。

エンジニアだからこそできる事業企画

この疑問を抱いた私が次にとるべきアクションは、事業企画との関係性を築いて定量的なROIのダッシュボードを作ることだったのかもしれません。多分、そうしているSREは沢山いるのでしょう。
ただそれをするには、目的や技術について説明する必要があります。ですが対面する事業企画は「早くプロダクトを作らなきゃ、早く実現しなきゃ」で必死です。もしかしたら現場レイヤではなく課長、部長レイヤに話をすれば違ったかもしれない。でも私には、その説得をするには大きな課題がありました。

事業企画がどんな仕事をしているのか、プロダクト担当が何をしているのか、上辺しか知らない。
何も知らない私の話を、自身の業務や辛さを知りもしないエンジニアの話なんて、耳も傾けてもらえないだろう。

そのために企画部門への異動を願い出たものの…それは叶わぬ夢だと分かっていました。
会社の基幹DBを、データを管理するDBREのマネージャークラスを別部門に異動することを許すことなんて、そう簡単にできない。
そして、年齢という壁がありました。新しいことにチャレンジするにはもう、私には時間がない。会社に何年も言い続ける時間はない。
だったら、転職しよう。これが最後かどうかは分からないけれど、多分、ラストチャンスだ。

どうせなら、もっと大企業。もっとややこしくて、組織が多くて動きづらくて、がんじがらめになっているところ。
そこで、リスクが高かったり技術的な難易度が高いことをしているのに、評価されないエンジニア。
どれだけ事業に貢献しているのか、素晴らしいことをしているのかを伝えることができる、事業企画になりたい。
そして彼らが不遇の立場にいるのであれば、例えば事業企画が判断が遅くて納期が短いなんて、そんなつらい立場に立たされないようにしたい。

私が不甲斐ないゆえに、評価を上げることが出来なかった。
クラウドもIaCも全然知らない私に、基礎から丁寧に優しく教えてくれた。SREが何なのか教えてくれた。
大好きなエンジニアのみんなのような、素晴らしいエンジニアたちが、評価されるように。


この一年間と今後

とはいえ自分に事業企画としての知識も経験もゼロだったので、まず一年はその会社の社風や環境に慣れるために、最初の半年か一年は経験のあるPMをやって、その後企画職に…と面接で伝えたのに。
入ったら開口一番、「まぁそんな一年後とか言わないで、いますぐやろ☆彡」とか言われ、即、事業企画になるっていうもうこの、現職ぅぅぅぅぅううううううう笑
ということで、一年間は勉強、頭の切り替えをするのに大変でした。
文化や人、組織を覚えることも大変でしたし、自身の視野の狭さ、事業レベルでの俯瞰した考えが出来ていない為、考慮が足りていない点が多く、ご指摘を受けることも多々。この辺りはPMをやっていた前々職の時の方が出来ていたな…なんて、情けない思いをすることも。

約一年、まだまだ未熟者ではありますが、ある程度期待していただけるような、自走して動けるようになってきました。
やっぱり厄介ごとに巻き込まれていき「今度は静かに生きていきたい」はやっぱり無理なのか…このトラブル引き寄せる体質、どうにかならないの…なんて呆然としている日々ですが。
ようやく、目的の一つだったことを一つ、実現できそうです。

守るからね、エンジニアの皆さん。
システムを作ることを、改修することを、運用保守することを。それがいかに困難で、苦労をして、人生の時間をかけて、どれだけ貢献してくれているのか。私はちゃんと知ってるから。
今度こそ、エンジニアが評価されるように。幸せになれるように。


まだまだ成長するよう、頑張ってまいります！！！

議事録作成って、いる？

虚無感が強い、タイトル画像

2025年、明けてもう随分経ちました！もう一月終わるという事実に、タイトル画像で虚無感を表現してみました。真っ白だぜ、ジョー。

本年もどうぞよろしくお願いします。最近ちょっとしたこと（Twitterで呟くには長いこと）は、しずかなインターネットに書いてます。
こちらもどうぞ、よろしくお願いします(っ´ω`c)
sizu.me

はじめに

さて、この記事を書いた発端は、maruさんのこの投稿からでした。（mixi2です）
mixi.social

maruさんのこの投稿、刺さるなぁ

最近の若手の方はさておき、新人の頃に議事録を書かされた経験…みなさんもありませんか？
私も漏れなくそちら側で、一年間議事録ばっかり書いていた時期もありました。まぁ今となっては良い経験ですが、それは横においておいて。
この議事録作成タスク、体験された方のほとんどが感じてると思うんですよ。

コスト（時間）取られる！
あげくにmaruさんが言われてる通り、スケーラビリティがない！
例えば一人できるようになったら横展開で組織みんながどんどん出来るかというと、皆無ですよね。属人的、スキルアップ。

ということで、時代の変化が激しすぎる＆技術進化が光のごとく早いこの時代において、X時間かけて議事録を書くなんていうこと、特にIT技術者が時間を取られることは、個人的に超反対です。
ただし、そもそも「何故若手時代に議事録作成をさせるのか？」という、そもそもの目的を考えたときに、議事録でなくても文書を考える、書くということはエンジニアであっても重要であると考えています。
というポエムを、つらつら書いていきます。


そもそも「議事録」とは何なのか

みんな大好きChatGPTに聞くと素敵な答えが出てきますが、私が議事録が「絶対必要」であるのは、特にこの2点があるからだと思っています。

議事録にしかできない2つのポイント

①証拠の残存

例えばある日、「来月からリモートワークやめます」なんて社長さんが言われたら、みなさん「はぁぁああああ？？？！」ってなりません？
議事録の大事な理由として、どうゆう議論がされた上でこの決定になったのか、という経緯と決定事項を証明、会議に参加されていない方にも伝えるという点が目的だと考えています。

私的には「経緯」を知るという意味では議事録を非常に重宝しています。結果だけ聞くと納得いかないことがほとんどですが、議事録を読むと「あぁなるほど、そんな経緯・背景があったのか…」と、その決定に対し納得することにもなりますし。
納得できない場合は、議論する際に相手に「議事録読みましたけど、その理由だけじゃ納得できないですよ」等、会議に参加していない人であっても議論をする場に参加することが容易になります。
議事録読んでいなければ、相手は同じ説明を何度もすることになるので、「もう何度も説明するの面倒…」と、場合によっては話すらしてくれない場合もあるかもしれないですね。

例に上げたリモートワーク廃止は、例えば「リモートワークにしてから、新しい事業、アイディアが出てくるスピードが遅くなった。もっと社員間で議論がされ、アイディアが生まれるようにしたい。だからリモートワーク廃止。」という議事録があった場合。
事業部や企画部門は、納得できるかもしれせん。経理や財務部門、システム部門は、納得できないかもしれないですね。いやいやそれ納得できないですよ、と反旗を振りかざす、という行動に移せるかもしれない。

他には、現在進行中のプロジェクトの凍結、組織や人事ルールの変更等、会社で働く上で大きな影響を及ぼす決定においては、議事録は有用であることが多いのではないでしょうか。


②責任の明確化

いわゆる「言った、言ってない論」を防ぐためです。

略式でも構わないのですが、やはりこれについては議事録がまだまだ強いと思います。
特にBtoB等の事業をされており、請負契約等で責任を負う場合は議事録は必須です。なにせ、裁判になったときに重要な証拠文書として提出しますからね。
録画でももちろん代替可能ではあるのですが、1時間の録画を後から聞き返すのって結構手間で、要点がまとまった議事録の方が確認が容易です。

ちなみにBtoBで議事録送るときは、メールでね。


でもここまで書きましたが、途中にも書いた「録画」「録音」や、AIの議事録や要約でも事足りるor済みますよね。
では議事録作成は無駄なのか？というと、もう少し掘り下げて…議事録という文書を書く目的は、そもそも何だったんでしょうか？



「文書を考えて書く」ということ

結論から書きますが、「議事録である必要はないが、簡潔かつ要点がまとまっている文書を考えられる、書けるということは必要である」と思っています。
何故文書を書く必要があるのか？というと、結論は以下の通りです。

何故文書を書く必要があるのか？

まず文書とは、この場では以下を指すとします。

  • 提案書
  • 企画書
  • 報告書

この3つはいずれも、経営層に近づけば近づくほど、必要となってきます。
そして企業規模に応じて、この資料を読むまでに多くの階層の役職者、人が増えてくるわけです。

共通して、簡潔さ・要点の明確さ　が必須となります。

ダラダラ書かれた文章、何が言いたいのか分からない文章…分どころか秒単位で仕事する経営陣が、読んでくれると思いますか？
多くの人が読むわけです、人によって違う認識がされやすい文書を読んで、役員間で認識齟齬が多発したら、賛成と反対派が乱立し…実現できることも出来なくなってしまう恐れがありますよね？
そのため、簡潔かつ要点まとめをする文章力というのは、読み手に共通認識を持ってもらうという点で、あらゆる社会人において必須のスキルとなります。

議事録作成は、そのまま発言を一文字一句書き起こす（いわゆるトランクスクリプト的な）が目的ではありません。
会議に参加した人の発言を簡潔化し、発言内容の要点をまとめる。それが議事録作成で必要なスキルです。
そのため、議事録作成を若手時代にすることで、簡素化、要点まとめのスキルを磨き上げていた。が、今までだったのでしょう。

でも今は、そんなのAIがやってくれますし。
そもそものmaruさんの発言にもあるのですが、時間をかけるコストに対しスケーラビリティが見合わない。


これらの内容から、簡潔かつ要点の明確化をすることを目的とした、文書作成能力を鍛えるために議事録作成をするというのは、時間コストに対し見合わない。

ではないかなぁ、というのが個人的な結論です。

簡潔かつ要点の明確化をするのであれば、例えば以下のような文書の方が、エンジニアにとっては時間コストに対し効果が見合うと思うんですよね。
それも、できれば一人でなく複数人で取り組むことで、スケーラビリティが生まれるんじゃないかなぁ、と思うんです。

  • 報告書やポストモーテム作成
    • 個人的に、過去作成したポストモーテムの見直しをする際、内容だけでなく記載された文章をわかりやすくする、等でこのスキルは磨かれると思います。これ、別の効果もあると思うんですよね、やり忘れタスク見つけたりとか、これ原因違うんじゃない？とかとか。
  • 開発標準等の標準化ルールの作成
    • リリース標準化とかでも。ルールは多くの人が読む文章なので、わかり易くないと間違える人＆問い合わせが増えて、気づけばToilになってしまうので、簡潔かつ明確な文書である必要があります
  • GithubのREADMEの整備
    • これなんのソースのリポジトリなの…なんで別プロジェクトのソース混ざってるの…なんていうことが何も書いてない、なにがかいてあるんだこのREADME、ありませんか

これらをAIも駆使しつつ、短い時間で早くスキルアップしていくほうが、コスト対効果が見合うのでは、と思っています。
デイリースクラムに組み込んでみる、なんていうのもありかもしれないですね。

ただ、役員レベルに提出する報告書や提案書、企画書を書くということは、どこかでやるべきだとは思います。
例えばあなたがSREだった場合。SREとして目指す姿が、ビジネスにコミットした定量的な事業目標に関する指標を可視化し、それを実現するための信頼性向上を行うのがSREであるならば。
端的に言うと、経営にコミットするエンジニアでありたいのなら。経営陣に可視化した数値の報告、するんですよね？
じゃあ経営層に報告書を出してみましょう。メモレベルじゃ、だめですよね。さぁ、書けますか？

いずれあなたがCTOになった場合、CTOレベルは当然このスキルが求められるはずです。
文書の形式はこだわらないかもしれません。ですが、簡潔さ、要点がなにかを経営会議で求めらます。

備考：AIに全任せはやめたほうが良い

AI任せすぎも、気をつけてくださいね。
資料や文章はAIが書いてくれると思いますが、経営層に対し報告する際の説明能力、質疑応答の際も、同じように簡潔・要点が明確な発言が求められます。
文書で書けないことを、口頭で説明できます？？
ということで、参考＆アドバイザーとしてAIは必要ですが、全任せはやめたほうが良いよね。が、個人的な意見でした。


まとめ

ということで、まとめ。

  • 議事録作成というのは、コスト対効果が悪いので、率先してすべきではない
  • ただし「簡潔さ」「要点が明確」な文章能力を身につけることは大事
  • 議事録じゃなく他にも作成する文書はあるので、まずは身近なところからやってみよう
  • AIはどんどん使うべきだけど、任せすぎはほどほどにね

技術ブログを書くというのも、ありかもですよ。ちなみにこの記事、AIには一切助けてもらってないので…ほら、分かりづらいのなんの。
私も最近、AIに頼り過ぎてダメダメです。とほほ。