https://namonakimichi.hatenablog.com/entry/2025/02/08/011827

burikaigi に初めて行ったので、その感想を書きます。なお、富山に行くのも初めてでした。その感想については下記の記事を参照してください。

namonakimichi.hatenablog.com

勉強会URL

本編 BuriKaigi2025 - connpass
懇親会 BuriKaigi2025 懇親会編 - connpass

移動編

朝7時の新幹線に乗る予定でしたが、間に合わない判断になり昼までにつくように移動するプランに変更しました。新幹線のチケットについてはえきねっとで購入しましたが、新幹線を後ろの時間にずらすなどをうまく出来てよかったと思います。なおこの時点で送迎バスは間に合わないことがわかったので、連絡をしました…。

富山には11時頃ついたようです。この時期はスキーが活発ということもあり、長野まで新幹線で乗られている方が多かったです。あと長野から富山も結構時間がかかったので、思ったより時間がかかるということを覚えておこうと思いました。（2時間以上かかるので、東京と名古屋くらいの感覚でいないといけない。各停だと更に時間がかかるようです）。

富山駅で困ったことといえばロッカー代わりと少ないことです。なんとか見つけることは出来ましたが、ICカードで施錠・解錠するタイプのものが少なく、現金の用意が必要でした。逆に現金式のロッカーであればそこそこ空いているように見受けられたので、現金を持っていったほうがいいかもしれません。

その後はあいの風とやま鉄道で富山駅から小杉駅まで移動しました。街を離れていくと、一面の雪景色が広がる場面もあり、新鮮でした。小杉駅からは徒歩で会場に向かいました。30分くらい歩きましたが当日は暖かったこともあり、足場も想像より悪くなかったです。良い運動になりました。

小杉駅で一枚写真撮ってたみたいです。こんな場所でした。

ついでに住宅街を超えるといきなり大きく新しい建物が出てきたのは少し驚きでした（富山県立大学はいきなり現れる）。

お昼ご飯

近隣に食事どころがないということでお弁当でした。どれも美味しそうでした。

お弁当の一つはこんな感じ。

セッション

午後からはセッションをいくつか聞きました。

もし今からGraphQLを採用するなら

https://fortee.jp/burikaigi-2025/proposal/7e7edb36-752e-4743-b3e9-71fc3a356b95

資料公開されていました。

speakerdeck.com

GraphQL の導入を試した話
聞いている感じフロントエンドチームが中心となって設計を進めてそうな感じ
プロダクト特性やサービス特性とマッチするかが選定の鍵になりそう
- 単純な CRUD 操作が多いケースなど
- データ構造が複雑なケースについてはデータ取得やインターフェース定義が難しくなるため、GraphQLは向いていないように思えた
利用している技術スタックをあまり終えていなかったので、メモ
- gqlgen
- GraphQL Code Generator
- graphql-eslint
- Hasura
- urql
  - Apollo Client より軽量
  - Apollo Client の機能が多く、暗黙的な動作に依存するよりはシンプルな実装のもののほうが良いという話
スキーマファースト vs テーブルファースト
- 採用されているチームではスキーマファーストで開発したかった
- テーブル構造から GraphQL を生成する Hasura は今回マッチせず
チームで取り組んでいく大切さ
- わからないことを何とかしてチームで乗り越える力が大切

マルチクラウド向けクラウドセキュリティ対策のCNAPPと企業利用における運用課題

https://fortee.jp/burikaigi-2025/proposal/d0dde585-2832-4bef-8442-63538d2870d2

資料公開されていました。

www.slideshare.net

クラウドセキュリティ対策に関して定義されたものを追っていく話
そもそも CNAPP とは何か
- Cloud Native Application Protection Platform のこと
- Gartner が初めて定義した
- そもそもこれ自体を知らなかった
あとは定義系の話が続く
- 正直知らないことがほとんどで、資料の殆どが学びだった
普段 AWS で何気なく設定している GardeDuty や Security Hub などのサービスがどのような位置づけにあるのかがわかった
また当時の定義よりも更に広範囲になりつつある
- k8s なども含めた話もある
正直使うばかりで手一杯になっているので、この定義に当てはまるサービスが何でどう活用・検知・防御できるのかをしっかりと学ばないといけないと感じた
普段触れていない分野であり言葉や定義ばかりで頭の中が追いついていないけど、CNAPP というものがあり基準が存在していることをしっかりと認識できたことが学びだった

2024年のフロントエンド振り返りと2025年

https://fortee.jp/burikaigi-2025/proposal/e29003c1-e9e4-4004-9b23-e9c16c83ae75

資料公開されていました。

speakerdeck.com

フロントエンド普段触ってないので変化の量に驚きました
そしてあんまり理解できてない
Baseline が整備されて標準的な実装状況がよくなっているように思う
Headless UI 気になったけどすでにいろいろ課題感が出てきている
- スピードが早すぎてこのあたりは全然追いつけていない
なんとなく触れているところの知識すぎるので、ここ数年分を深堀して理解しないといけないということを理解した

パブリッククラウドのプロダクトマネジメントとアーキテクト

https://fortee.jp/burikaigi-2025/proposal/65de1d80-5197-48b2-93b0-81e16e923155

資料公開されていました。

speakerdeck.com

パブリッククラウドとガバメントクラウド
ガバメントクラウドに認定されるための要件がとても難しい
- 要件項目数が非常に多く、すべて満たす必要がある
- https://www.digital.go.jp/procurement/3058bc41-ee8f-49bb-8f22-8def725f6f3f
フルスタックの意味合いの違いで会場が湧く
- 拠点構築ができる、レベルで始まるとのこと
- ソフトウェアエンジニアとは範囲が違いすぎて驚愕した
クラウドとしての要件を満たすことの難しさと取り組みが聞けて非常に面白かった

例外処理を理解して、設計段階からエラーを「見つけやすく」「起こりにくく」する

https://fortee.jp/burikaigi-2025/proposal/99b15841-f9b6-40b6-805f-b66582ee3abd

資料公開されてました。

speakerdeck.com

例外設計の話
チームでの合意が取れていることが前提にありそう
早期に失敗させることの良さもあるけれども、全体を通しての整合性を確認した方がいいパターンはありそう
- 例えばフォームのバリデーションなどは早期に失敗してしまうと、あとのチェックがされないことになる
- そういう場合は先にソフトに制御としてエラーを蓄積にしておいて、最後にまとめて例外に渡すみたいなパターンもありそう
- この辺りはチームでの調整が必要そうな部分で、機能にあった例外設計が大事そう
責務訳をするという考え方は良さそうだと思った
- DB接続できない場合などは例外にするしかないため
- またビジネスロジック上想定できるものと、プログラム上想定できるもので分けて考えるというのも良さそう
  - 型のチェックなどは動的型付け言語特有の問題のように思う
Result 型をあとから入れるとめんどくさいことになりそう
- 特に言語機能としてそういうものがない場合、Result 型を採用した実装とそうでない実装が交じる
  - レビュアーの裁量とかチームの認知負荷などが高くなってしまいそう
- また Result 型を自作する or ライブラリに頼るでもまた事情が変わってしまいそう
- なので個人的には Result 型が基本機能として導入されていない言語の場合は、Result 型を入れない方がいいと考えている
後で読む
- https://www.rfc-editor.org/rfc/rfc9457.html

結構このセッションは意見が分かれそうな気がしましたが、例外設計についてチーム方針としてのハンドリング方法を決めておくことの重要性を感じました。

BuriKaigi 名物！C# ドキドキ Live Coding 対決!!

https://fortee.jp/burikaigi-2025/proposal/767b265a-a076-4fd5-b4eb-482542468c0f

後半のAI作る問題の中で C# の新機能を使っていたのですが、すごい強い機能だなぁと思いました。見ごたえがあってよかったです。

最初のライブコーディングは競技プログラミングを思い出すような問題でしたね。自分は C# をその場で書くほどの自信がなかったのですが、スマホで Python で適当に書いて作ってました。

n = int(input())
for i in range(1, n+1):
  b = ' ' * (n-i)
  p = ''.join(map(str, list(range(1,i+1))))
  if i > 1:
    p = p + p[i-2::-1]
  print(f"{b}{p}{b}")

最近こういうのもAIにやらせているので自分で書く能力の鈍りを感じました。（当日はスマホで ideone で書いて動かしてをやっていて素早く手元で失敗するが出来なかったのも大変でしたが…）

ブース

コクチョウさんのブースでコクチョウくんを探すことに必死になっていました。実践的で楽しかったです。

また富山にはAWSという会社があることも知りました。Amazonよりも前からこの社名だったとか。面白いですね。 https://awsnet.co.jp/

あとボードもありました。各地のイベントがたくさんだ！いろいろなコミュニティからの参加があることを感じました。そのうちのひとつ PyCon mini Shizuoka は 2/8、今日開催です！

懇親会

ブリ美味しかったです。あと食事もお酒も十分な量があり、楽しかったです。数年ぶりに合う方などもおり、いろいろな話が出来楽しかったです。

懇親会LTはあんまり覚えていません。ごめんなさい。アニメーションライブラリMotion が面白そうだと思いました。そこだけ覚えています。

まとめ

富山に行くのも初めてで、色々あり遅れてしまったこともありパニックパニックでしたが、楽しい時間を過ごせました。いろいろな場所からいろいろな方が集まってきていて、レベル感の高いセッションが多く技術的にも満足しました。

またブリを楽しみにしていたので本場の新鮮なブリをいただけたのも思い出に残っています。とても美味しい…。

来年も機会が合えば行きたいですね。そうそう帰りはちゃんと送迎バスを利用させていただきました。

このような会を開いていただき、スタッフの皆さまを始め、参加者の皆さんに感謝です。良い思い出をありがとうございました。