@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

#RSGT2026 でスタッフしてきた

RSGT2026 が羽田で行われ、今年も無事にボランティアスタッフを終えることができた。

2026.scrumgatheringtokyo.org

今年の活動

場所が御茶ノ水から羽田になるのでわからないことだらけになるだろうなと思っていた。動線が変わるので人の流し方をどうしようとか、お弁当出す場所どこにしようとか。ただ、そんなことはこちらで考えなくてもプロの参加者の方々がすぐにうまく歩き回ってくれていた。
ただ、変わらないメンバーでの作業だと大きな失敗もなくイベントも終わらすことができていたので、プロの集団ってすごいなと感動した。

今年はフォトブースに長時間いてみた。写真を普段撮ることも撮られることもないのでポーズを聞かれても思い浮かぶことがなかった。みなさんが楽しそうに撮っているのを近くで見れるのはとても良い場所だった。来年はなんかこれというポーズをスタッフで考えておきたい。

反省点

今年は場所が変わったこと以外にも変更点がいくつかあったのでそれに伴ってオペレーションを変更する必要があった。
たとえばお弁当箱の回収が会社を間違うと改修してもらえないことがあるなどから間違わずに回収する方法を模索していた。そのため、3日間ともゴミの回収場所を変更してしまい迷っている人をたくさん見かけた。来年はわかりやすいようにしたい。
ただ、1日目の夜に今日の集める場所悪かったから変えていこうかって話がすぐ出ていたのは流石だなと思っていた。

個人的な反省点はセッションの邪魔をしてしまったこと。クリッカを忘れてしまったのでスライド操作をとお願いされたのだがスライド操作も、Zoom も慣れてなくて失敗してしまった。発表者の方にも参加者の方にも悪いことをしてしまったなと反省している。
来年までには慣れておけるようにしたいところ。また、無理なことは無理と返答するようにする。自分を信じすぎていた。

今年の歩数

もともとフラフラすることを目標としていたが1箇所にいることが多かったので歩き回ることなかったなと感覚では思っていたが歩数計を見ると歩き回っていた。
年々みんな減らすことを目標にしているので逆に来年は2万歩超える日をいれてみたい。

Day0 : 14,055 歩
Day1 : 16,988 歩
Day2 : 16,806 歩
Day3 : 16.368 歩

来年は

RSGT2027 は またベルサール羽田空港での開催らしい。日程は確定次第どこかで案内されるだろう。
来年はもっと活動できるように体を絞っておきたいし、歩くのに良い靴を買っておきたい。この靴良いよという情報をお持ちの方は教えて下さい ><

来年に向けて今年はもっといろんな人と関わっておきたいと思ってもいるので、どこかのイベントでスタッフが足りてないなどあればお声がけいただければ参加できる範囲で申し込みなどをさせていただければと思っている。
なんとなくの仕事はできるかと思いますので、気軽にお声がけください。

また、来年羽田でみんなに会えるよう*1に頑張ろうと思います。

*1:来年はみんなが行ってる飲み会にも行くようにしよ

「プラットフォームエンジニアリング」を読んだ

プラットフォームっぽい立ち位置にずっといる気がするけど、全然わからないので読んでみることにした。

目次は以下。

  • 第Ⅰ部 プラットフォームエンジニアリングとは何であり、なぜプラットフォームエンジニアリングなのか
    • 1章 プラットフォームエンジニアリングが重要になりつつある理由
    • 2章 プラットフォームエンジニアリングの柱
  • 第Ⅱ部 プラットフォームエンジニアリングの実践
    • 3章 どのように、そしていつ始めるか
    • 4章 素晴らしいプラットフォームチームを作る
    • 5章 プロダクトとしてのプラットフォーム
    • 6章 プラットフォームの運用
    • 7章 計画とデリバリ
    • 8章 プラットフォームのリアーキテクチャ
    • 9章 プラットフォームのマイグレーションと廃止
    • 10章 ステークホルダとの関係管理
  • 第Ⅲ部 プラットフォームエンジニアリングの成功指標
    • 11章 プラットフォームに整合性がある
    • 12章 プラットフォームが信頼されている
    • 13章 プラットフォームが複雑性を管理している
    • 14章 プラットフォームが愛されている

プラットフォームエンジニアリングで出てくるプラットフォームってどういうものなんだろうかと思っていた。本書を読んだ限りだとセルフサービスAPIやツール、ナレッジ、サポートを含む基盤を、アプリケーション開発チームの生産性を向上させるために提供するものになるのだろうか。たくさんの人が一緒に使うものだけではなく、生産性が向上することが目的となっていることが大事なのかなと思った。そして生産性を向上させるだけでなく、運用の負担を軽減し、最終的には全体の効率を高めるという観点はなるほどと思った。

多様なOSSクラウドサービスを各チームが個別に選択し自由に組み合わせて使ってしまうと、それぞれをつなぐためのシステム開発も必要になるためどんどん複雑性が増大してしまう。これではメンテナンス性も下がってしまうため、統一をして運用まで見据えた設計をしたプラットフォームを提供することが大事。

プラットフォームエンジニアリングの成功に不可欠な4つの柱が紹介されている。「プロダクトアプローチ」「ソフトウェア開発」「幅広い開発者対応」「運用基盤」の4要素で構成されており、複雑なシステムを管理し、ビジネス基盤としての運用をするための必要なポイントとして紹介されている。ソフトウェア開発は普通にアプリケーションを作成するものではなく、複雑なシステムをユーザーにとって使いやすく、効果的に抽象化するための開発の重要性を感じた。

プラットフォームを作るタイミングやチームに必要なメンバ、文化についてもたくさんの記載がある。その中でも自分の分野や好みに、今までの経験に引きずられてしまうため、複数のエンジニアが所属するチーム編成にするというのはたしかになと思った。バランスがとても大事。
プラットフォームのアーキテクチャとして設計についてや移行と終了についての記載もある。V2 構築とリアーキテクトについての比較も面白かった。リアーキの方が稼働しているシステムに対して段階的に再実装する反復的なプロセスになるため、無駄な機能追加を避け、顧客への影響やリスクを最小限に抑えられると説明されている。

Ⅲ部では信頼されているか、愛されているかなどプラットフォームが組織に受け入れられていることがいかに大事かが説明されている。プラットフォームが成功するためには使ってもらう方からの信頼が不可欠。信頼を得るために運用をしっかりする、ボトルネックにならない、気に入ってもらえているか、無駄なコストがかかってないかなどの指標があるらしい。自分たちの提供しているシステムがどう思われているかを定期的に情報収集してみたい。

まとめ

  • アーキテクチャ、設計パターン、組織づくりと幅広い要素がぎゅっとまとまっている
  • 1度だけではまだ混乱しているので何回か読んで話し合ってみたい
  • 自分たちのシステムが愛されているかは確認していきたい

「Apache Iceberg 活用入門」を読んだ

盛り上がっているよね Iceberg 。この流れにのれるように準備しておこう。
もう1冊夏くらいにでていたのだが読んだ気がしていたが、あれー?

目次は以下。

  • 第1部 Apache Iceberg の基礎
    • 第1章 Apache Iceberg へようこそ
    • 第2章 Apache Iceberg のアーキテクチャ
    • 第3章 読み書きを行なうクエリのライフサイクル
    • 第4章 Iceberg テーブルの最適化
    • 第5章 Iceberg カタログ
  • 第2部 Apache Iceberg ハンズオン
    • 第6章 Apache Spark
    • 第7章 Dremio SQL クエリエンジン
    • 第8章 AWS Glue
    • 第9章 Apache Flink
  • 第3部 Apache Iceberg ハンズオン
    • 第10章 Apache Iceberg の本番利用
    • 第11章 Apache Iceberg とストリーミング処理
    • 第12章 ガバナスおよびセキュリティ
    • 第13章 Apache Iceberg への移行
    • 第14章 Apache Iceberg のユースケース

第1部ではIceberg のフォーマットなどについてこれでもかってくらい説明されている。Iceberg って何が良くてどうしてそんなにいろいろできるのってことがわかるような説明がされている。アーキテクチャやSpark、Trino、Hive でのハンズオンがいくつかあり実際に触ってみる感触が得れると思う。
他にも、PyIcebergやIceberg Rust についても記載がある。自分のPC でローカルでいじることがこれでとてもしやすくなる。Rust はやっぱりちょっと触ってみるのが良さそうだな。

Iceberg テーブルのプロパティだけではなくメンテナンスについても記載があるのがとても役に立つ。重要なSpark プロシージャについてパラメータ含めて厚めに解説があった。パラメータについて詳しく記載があるので本番運用するにはとても良さそう。

他にも本番利用をするために気にするべきことの記載があったり、セキュリティについての記載など実運用で考えなければとなる部分での記載があるので勉強になった。他にインプレース移行、シャドウ移行などの移行方法については知らないことだったので学びになった。実際にIceberg でなければ解決できなくなった際には考えるべき一つになるだろうと思う。

また、ユースケースの章ではデータレイクにおけるデータ品質の確保方法やBIレポートの構築、CDC についてなどが記載されており読んでいてワクワクした。
また、日本語版だけの特典としてLINEヤフーでの活用事例が結構細かく記載されている。実際に運用していたり触っている人たちに話を聞いてみたいと思った。

オープンテーブルフォーマットを見ているとSpark やTrino など自分たちでクエリエンジンを用意しており使っていることが多い。クラウド上のクエリエンジンが強くなっているのでぜひともこれからはBigQuery やRedshift などからの利用実績が増えてくるとさらに面白くなるのではと思っている。その場合カタログはどううまく扱えるのか、扱えずに時前実装を頑張らなきゃいけないのかなど気になるところである。
でもクエリエンジンによる強弱はあったりするので、Single Source of Truth を保ちながら使い分けるなどをしたくなると信じているのでうまく使えるようになってききたいと思っている。

まとめ

  • Iceberg のアーキテクチャや基本について学べた
  • サンプルコードが多いので自分で触れて理解しやすかった
  • もっともっと使ってみた人が増えると面白くなりそうなのでもっと勉強する

202512 振り返り

年末に声が出なくなってしまい周りの人には迷惑をかけてしまったな。エアコンに弱いことはわかっているのだからそろそろ家の環境を揃えておかないといけないのだろうな。

忘年会にいくつか出ることができた。知り合いが何人も増えてとてもありがたかった。
1月からも積極的に人脈構築を頑張っていきたいところではある。

べんきょうかい

申し込んだけど参加をすっかり忘れていた。
今月は勉強会に参加しようという気持ちがあまりなかったので調べることもしてなかった。来月からまた頑張ろ。

ほん

今回は薄い物が多かったので技術本の消化が他の月に比べれば多かったかな。
ラノベもいくつか読んでいるものがでていたので読むことができたので今月は読書欲は満たされた。
本は増え続けてしまっているので減らすか増やさない仕組みを考えていかねば。

えいが

熱を出してしまったので観に行く暇がなかった。
観たいものはいくつかあるので1月にはいくつか行きたいな。

ぶろぐ

MCP について学ぶかと思うことがあったのでまとめて読んでみた。
年末の時間もあるのでもう少しいけるかなと思ったけどそこまでの読書は終えれなかった。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「詳解データレイクハウスアーキテクチャ」を読んだ

データ基盤でも面白いことしたいなと思っているとよくレイクハウスという言葉を見ることがあるので読んでみるかと。

目次は以下。

1章 Delta Lakeにおけるレイクハウスフォーマット 2章 Delta Lakeを導入する 3章 Delta Lakeの操作 4章 Delta Lakeエコシステムの詳細解説 5章 Delta Lakeのメンテナンス 6章 Delta Lakeを利用したネイティブアプリケーションの構築 7章 Delta Lakeへのストリーミングの入出力 8章 高度な機能 9章 レイクハウスのアーキテクチャ設計 10章 パフォーマンスチューニング:Delta Lakeでのデータパイプライン最適化 11章 成功するデザインパターン 12章 レイクハウスのガバナンスとセキュリティの基礎 13章 メタデータ管理、データフロー、リネージ 14章 Delta Sharingプロトコルでのデータ共有

目次からもわかるかと思うがレイクハウスの話というよりはDelta Lake の話。そしてDelta Lake で以下にレイクハウスが作りやすいかの話がされている。
本書の中には実行可能なサンプルコードがたくさん用意されている。そのため、読むだけではなく実際に動作確認をしながら読みすすめることができる。まずは1章でDelta Lake ってなにさって概要を学び、9章のレイクハウスのアーキテクチャを読むことで全体像を把握して3章で実際にDelta Lake を操作してみることで読みやすくなると思った。

しかし読んでみて思ったのだけれどDelta Lake をDatabricks を使わないのでOSS で使うことが本当にあるだろうか?あそこまで揃っているエコシステムの一つだから使うのではないのかと思ってしまった。

ただ、Delta Lake が仕組みとして作っているものはとてもすごいなと感動する。ファイルの設計でここまでメタデータトランザクションの管理を性能出しながらできるんだと。
レイクハウスの考え方は面白かったので7章、9章と11章あたりは面白く学びになった。

自分たちの基盤に取り込むならどうするか、いまから基盤作るならどう作っていくかを考えてみたいところ。

まとめ

  • Delta Lake の機能について学べた
  • Unity Catalog 便利だな
  • オープンテーブルフォーマットをもう少し深堀りしたい

2025年のふりかえり

2025年の感想

3月から日記をつけるようにしてみた。毎日文字を書くことなんてここしばらくなかったので新鮮。書き始めてわかったのは反省する文言が多いこと。もっとポジティブに考える練習をしないと。

人とのつながりを増やしたいと思いながらイベントに参加する際には話をするように頑張った。ただ深くつながるようなことは今年はあまりなかったなと思う。今仲良くさせてもらっている方々とは今年も仲良くさせてもらえていたと自分では思っている。このつながりは本当にありがたいものだ。

体調に関しては良くも悪くもなることなく変わらずという感じだった。去年の終わりには75kg にはなりたいなと言っていたが、気がついたら90kg に戻ってしまっていた。体力がないことを年齢もあるのか感じることが増えている。体力はいろんなところで必要になるので戻していきたい。

仕事はやりたいことが思いつかないんだよなと思っている。
インフラ周りやデータ基盤については得意なのだと思うので、その辺りで新しいことを探してみるのも良いかも。
そして口は禍のもとを今年も起こしてしまった。もう良い年なのだから気をつけよ。

アウトプット

今年もブログを書いた以外はこれといって何もしていない。
誘われた飲み会やイベントにはできるだけ参加をして、人と話すことは積極的に行った気がする。

関西の方のイベントにも遊びに行ったりはできたので、来年はもっと幅広く参加できるようにしたいなというのとそろそろなにか発表できるようなことをしたいなというのと、なにか資格とかを取るように頑張っていきたい。

ブログ

  • ブログ : 38本

相変わらずデータ、クラウド周りの本に対する感想が多かった。
年末の方ではコーディングエージェントやMCP などについての本をまとめて読んでいた。今後ますます関わることが多いだろうから身につけておきたいものの一つではある。

hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.medium.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.medium.com hihihiroro.medium.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.medium.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.medium.com hihihiroro.hatenablog.com hihihiroro.medium.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com hihihiroro.hatenablog.com

インプット

去年減ったなと思っていたけど、今年はもっと減ってしまった。
本を読む体力が減っている気がする。人に会ったときに本をよく読んでいると言っていただくことがある。
コミックが大半なので自分ではあまりたくさん読んだと言うものではないと思っているのだが、来年はもう少し自信が持てるほどの読書量にしたい。

映画は何本か観たいものを観ることができていなかった。もう少し観たいものが観れるような時間の作り方をしたいものだ。

ほん :832冊
えいが:20本

2026年

今年は新しく初めたものがなかったな。去年やろうと思ったことは何も達成できていない気がする。 まずは目標立てたことを実施できるようになってみようと思う。

来年は丁寧な生活を心がけていきたい。体調についても行動についても落ち着いて丁寧にしていきたいと思う。
まずは部屋の模様替えを少しはしてみたいなと思っている。すべてを1箇所で過ごしてしまっているのでそれぞれの行動で過ごす場所を分割してみたりしたい。

また、今年はお金の使い方がとても汚くなってしまっていた。お金もそろそろ貯めておかないと自由が少なくなってしまう。来年はお金を無駄にせずになにかの時のために無駄遣いしないようにするのだ。

これまた来年も人とのつながりを大事にしていきたい。
広げるのも深めるのもできると嬉しいので、飲み会でもイベントでもご飯会でもお誘いさせていただきたいですし、お誘いいただければと思います。

今年も大変お世話になりました。

来年も宜しくお願い致します!

「実務で役立つ ログの教科書」を読んだ

ログって大事だよねと思っているので、発売前から気になっていたので読んでみた。

目次は以下。

  • 第1章 ログの基礎知識
  • 第2章 ログの記録と収集
  • 第3章 ログの分析手法
  • 第4章 セキュリティ面での活用方法
  • 第5章 ビジネス面での活用方法
  • 第6章 AIによるログ分析

なにか起きたときに原因を探すかと思ってまず見に行くのがログ。その際にログがなくてわからないという経験をしたことがある人は少なくないと思う。ログの出し方や種類等ってあまり教わった気がしないので教科書となっているからには教われそうだなと読んでみることにした。

ログというとアプリケーションのログを思い出すが、本書ではそれだけではなくPCのイベントログからWebシステムのアプリケーションログまたはアクセスログなど幅広いログの話が書かれている。そしてログの種類だけではなくログとは何かというところから、その活用法にいたるまで、ログにかかわるトピックが幅広く紹介されていた。
ログの取得、出力、管理について書かれているのでログって身近だけど考えること多いよなということに気がつく。また、それぞれのログを取得できるツールや取得ツールなどの説明から導入方法、基本的な使い方も記載があった。

そして、活用方法についても監査やマーケティングでの使い方やAI を使っての分析の仕方まで記載がある。最近エラーログなどを自分でgrep などで探すよりもLLM に調べてもらうことが増えた。そちらのほうが早いし正確に分析してくれることがある。ただ、これらをさらに加速するためにはログの構造化や文言の調整などが必要になってくるのだろうなと思った。

順調に動いているときは多すぎるとパフォーマンスに影響を出す可能性もあるので邪魔になることもあるが、エラーの際にでてないと何も調べれないという目にあってしまう。そこの見極めをうまくすることで必要最低限のログについて再度整理し直していきたいところである。

まとめ

  • 即効性はないだろうがたしかに教科書
  • アプリケーションだけではなくマーケティングのためのログ設計もやりたい
  • AI に読ませるためのログとは?