旧自作PCにUbuntuをインストールして、Windowsとデュアルブートにした。
そこらへんに転がっていたNVIDIA TeslaをPCIeに刺してOllamaインストールした。これで暖が取れそう。
Ubuntuでの古いグラフィックボードのドライバ管理面倒だということを初めて知った。
物理マシンを通して、どんどん低レイヤーの知識獲得につながるように感じていてとても楽しい。
鉄は熱いうちに打て（コミュニケーションのタイミング）
自分より忙しそうな人や、他社の人が返事を返してくれたことに気がついたら即レスを心がけるようにしている。
今返さないでおくことももちろんできるのだが、相手が次にいつ自分の返事に気を向けてくれるかわからない。また、相手が通知を巡回するタイプなのか、その人の中での重要度に応じて順次反応するタイプなのかなど、相手が通知をどのように処理するのかはもちろん相手に委ねられている。
とはいえ、相手が反応をくれた直後であれば何かしらリアクションが返ってくる可能性が高いのではないかと思ってこのような行動をしている。
統計はとってないので、正確なところはわからないが、即レスしてくれる人は仕事ができる人が多いような気がしている。(超多忙な人は除く
質問をするときは、どうしてその質問をするのかも合わせて聞く
他の人がSlackで投稿した質問を見ていて、それだと欲しい回答を得られるんだろうか？と思って指導というか補足をしてもらうことがあった。
（組織が違うなど、文化や音楽性の違いなど様々な理由により）コンテキストが失われた結果、相手方に行間を読ませてしまったり、望んでいない方向の回答を得るかもしれない。
特にチャットではやりとりの往復回数が増えてしまい、質問する人もされる人もお互いに不幸になりうる。
聞きたい対象についての認識をできるだけ合わせるために略語や、省略はされるべきではないと自分は考える。略語を使って良いのは、組織内でその略語についての認識が合うことに確信があるときだけだと思っている。
自分は望んでいる方向の回答を得るために、どうしてその質問をするのかを（可能な限り）添えるようにしている。
キャッチアップの量と質とタイミング
onkさんに教えてもらった、"新しいチームに配属されたらドキュメントとGitの履歴くらい全部読むでしょ"
— hokkai7go (@hokkai7go) 2025年11月6日
というキャッチアップの姿勢にいつも助けられている。ありがたい
一気にガッと読んでおく。詳しく読むものとサラッと読むものとの差はつけるけど、だいたい読む。
全体感を掴むためにツリー構造を把握したりとかもやる
わからない単語が出てきたらとことん調べる
物量を前にして怯まないことが重要でかつ、最初に手抜きをすると良いことは無い。
量を読むことが、質に転化するというか、良質なアウトプットを将来的にできるようにするためにも最初に頭に入れておくのが重要だと思う。
キャッチアップというのは、その仕事に対するオーナーシップを得るための行為と言える。
エクストリームなオーナーシップを持ちたいなら、いつか全部読むわけだし、余すところなく全部読むぞ！というその姿勢がプロフェッショナルな姿勢なのだと思う。
SREから経営者になって4年が経ちました
はじめに
SRE NEXT 2025に行き、下記の発表を聞きました。そういえば自分もSREから経営者になってたけど、ろくに情報発信してなかったと気がつかせてもらえたのでアウトプットします。子育てや実務に忙殺されて、対外的なアウトプットが足りていないことには反省しかないです。歯を食いしばっています。
経営者になったときの簡易なアウトプット
前提
2021年4月から 株式会社I-Styleの取締役CTOをしています。アイスタイルといってもアットコスメさんの方ではないです。ややこしくてすみません。今現在取締役含めて7人の小さな会社です。取締役以外はエンジニアのみです。
事業としては、情報システム部門のコンサルティングと、プロジェクトとしてSIerから構築や移行案件をやったり、医療情報システムのコンサルティングをしています。
きっかけ
はてなでSREをしていた頃から、社長の板垣からは声をかけてもらっていましたが、SREが楽しいから待ってくれと言い続けていました。オンプレミスの撤退作業や、社内DNS更新の仕組みをAWS Lambdaで動くようRubyで書く仕事が落ち着いて一息ついたころにはてなを辞めたと記憶しています。
4年間何をしていたか
経営者になりたての頃
自分を経営者に引き上げてくれたのは社長です。また自分は創業者ではないので社長と考えや認識がズレるのはよくないだろうと考え、密に話すように心がけていました。
チャンスを掴む
SRE NEXT 2025の飲み会やAsk the speakerコーナーに発表者の方と座談会として話していたことですが、社会人をやっていると急にチャンスがやってきます。そのチャンスを掴む勇気が必要です。また、チャンスをくれた人には説明責任があるのでその人とよく話すと良いと思います。自分の場合はChef実践入門という本を書く機会をもらえたことと、経営者になったことがこのチャンスにあたるものでした。こうしたチャンスを掴んだあとはこれまでに経験したことのないことへの挑戦が待っています。様々な能力の向上が必要だったり、思考の様式をアップデートしていく必要があったりします。つまるところゲームチェンジですね。生存戦略を変化させる必要性が生じたと言えると思います。チャンスを掴んだらあとは腹を括ってやっていくしかないですね。
一つ上のレイヤー、レベルに上がるというのは相当なことであり、情報収集・発信、仕事の仕方、話し方、思考の仕方、素振りなどのコソ練などすべてにおいて向上させていかねばならんよな
— hokkai7go (@hokkai7go) 2025年5月27日
今日ゲームチェンジと何度言ったかわからないくらい言った
— hokkai7go (@hokkai7go) 2025年7月11日
昇格とかマネージャーになるとか、経営者になるとか全部ゲームチェンジだと思う
文化づくり
当時は書きやすいWiki的なツールがまだ社内になかったので、Confluenceを導入しました。前職のはてなはアウトプット文化が強烈に根付いていたし、自分もシュッとアウトプットしたいのでこのようなツールが必要でした。その上で技術情報置き場をConfluenceに作り、自分がまず細々と社内向け技術記事を書いていくということをしていました。
当時はふりかえりの文化がありませんでした。前職のはてなでは、すくすく開発会という名前でスクラムマスターやふりかえりの支援をやっていました。仕事を通して強くなりたいし、メンバーのみんなにも強くなってほしいので、ふりかえりの文化を導入しました。
はてなでは通称ギベンと呼ばれる技術勉強会がありました。これを完全に真似ているわけではないのですが、会社に技術勉強会を導入しました。これも動機としては仕事を通して強くなりたいし、アウトプットの習慣をみんなにつけてもらいたいからです。
これらのことは技術者文化つくりだと思っていて、この記事に書いたように一朝一夕ではどうにもなりませんね。とはいえこれまでの会社でのやり方を参考にできますし、自分がやりたいようにできるのは楽しいことでした。すでにあるツールを使うとか、稟議書を書いて提案を上げるという従業員のときとは違う動きなのでこれもゲームチェンジだなと思いました。
ここまでかいた上記の内容はこれまでの会社で得た知見を適用しているものばかりです。独創性はあまりないと思います。
心構え
会社や事業の責任を負うことになりますし、自分の後ろにはもう任せられる人がいないという意識が重要になります。この意識や姿勢は、はてなを辞める際、はてなの大西さんに教えてもらいました。ありがたい餞の言葉だったと思っています。
取締役はfinally節です。tryやcatchがないパターンもあります。
そーだいさんと飲んでます！決まり手は「取締役はfinally節」です！ pic.twitter.com/R4j9K0rGIK
— Kiyoshi Yoshida (@kiyosick) 2025年7月10日
変化したこと
取締役になることで労務管理の対象から外れるので勤怠をつける必要性がなくなります。従業員ではなく使用人になります。雇用保険からも外れます。私は24時間365日働き放題プランと揶揄して呼んでいます。これもゲームチェンジな出来事ですね。
そんな中、1人目の子どもが生まれました。ここからは子育て中の経営者となります。この話は後述します。
職歴についてですが新卒で就職してから14年で現在7社目と転職を繰り返してきました。従業員でいる間は仕事の範囲はある程度限られています。メンバーシップ型の雇用であっても無限の責任を追うことはまずありません。困ったときは上長に相談すればいいし、最悪辞めるというカードを常に持つことができます。これは非常に強いカードです。しかし取締役はそうはいきません。辞めることはできますが、従業人よりも辞めるハードルは高く感じています。取締役になることで仕事を続けることについての意識が相当大きく変わりました。
セールス
セールス専任はいないので社長と自分が中心にセールスをやっていく必要があります。難易度高めの案件をブログや事例インタビューにしてもらうことで露出を増やすということを少しずつやっています。
クックパッドさんのGoogrenameでは、Acknowledgementsに社名と名前を載せてもらいました。 techlife.cookpad.com
クラスメソッドさん事例インタビュー（ちなみにAFLSというサービスは終了になっています…） classmethod.jp
このような外部露出はたくさんできるものではないですが、今後も少しずつ増やしていきたいです。
新規事業
これまでのことを続けているだけでは未来がないし、発展もなければ成長しにくいです。新しいことをやる必要があります。情報システム部門のコンサルティング案件や、クラウド移行の案件では自分としては新しく学ぶことがあればラッキーという感じがありました。自分は知的好奇心ドリブンで動くタイプなのと、学ぶことがたくさんあるような鉱脈または泉とも言えるテーマが必要でした。自分にとっては医療情報がこのテーマです。
医療情報を学ぼうと思ったモチベーションに感して下記記事で書ききれなかった背景があります。医工学を学びたいと大学時代にぼんやり思っていたのが再燃したと言えそうです。インフラエンジニアやSREの経験で情報工学の実践はある程度しているので、この知識を医療情報分野に持ち込んだら役立つのではないか？という考えがありました。情報システム部門のエンジニアの採用に各社が苦戦しているのと同様かそれ以上に医療機関でのエンジニア確保に苦労するだろうと思ったからです。そしてこれはどうやら事実のようです。
また、会社の今後の展開を考えたときにIT系以外の会社からお仕事をもらえると良いなと考えていたので、医療系のIT業務について理解を深められそうな医療情報技師に興味を持った。本業の方で時間が確保しやすい状況だったから資格取るかと言いやすかったという背景もある。他にもあるけど、書ききれないので省略。
そして医療情報技師の資格をとり、医療情報学会に行くようになりました。この分野での最新動向や、業界の雰囲気を感じ取ることができました。こうした動きをしていると、実際に医療情報分野のお仕事をいただくことができました。一つ目の案件を開始するまでには苦労があると予想していたので、うれしい誤算でした。これで医療情報分野の実務を学ぶことができるようになりました。
会社としてプロダクトを持っているわけではないので、新規事業のイメージが違うかもしれませんがうちの会社ではこんな感じの新規事業立ち上げでした。新規事業という単語の指す意味や定義が非常に曖昧なので仕方がないかもしれません。
新しい事業を始めると毎日のように知らないことに触れられて刺激的かつ、知的好奇心を満たせて楽しい
— hokkai7go (@hokkai7go) 2025年6月4日
資金繰り、税金や社会保険料
社長や、経営者の悩みについて情報収集するために経営中毒というポッドキャストを聞くようになりました。自分の専門領域ではないものも自分ごととして興味を持つようになりました。直近の経営中毒のテーマが資金繰りでした。税金や社会保険料が高いですね。給料を上げても税金や社会保険料に化けてしまうので手取りを増やしにくい…。
子育て中の経営者の苦悩
経営者という立場上、品質の最終責任を持つことが多いです。また、現場ではレベル的に厳しい難易度の高い案件を処理する役として呼ばれることもあります。しかし子育て中のため時間は限られています。その中で品質チェックをしたり、難易度高め案件のキャッチアップをする必要があります。そのため自分は情報のI/O速度を高める必要に駆られました。今思えばゲームチェンジだったなと思います
さいごに
目標や評価、マネジメントの話も書きたかったけど省略しました。アウトプットが上手ではないのですべてを網羅するのは時間的にもモチベーション的にも難しかったです。
SRE NEXT 2025の会場や飲み会では経営者のみなさんとお悩み相談会ができて非常に有意義でした。会社のFinOpsの話ができたのがよかったです。会社や事業の戦略を考えると言うDeepWorkをやりたいが足元の実務に時間がとられなかなか深く考える時間を確保しにくいのは経営者あるあるなのだなとわかりました。さらには子育て中の経営者トークができたのもありがたかったです。
SREの考え方やプラクティスを会社や事業や組織に適用していくということは全然できていないので、まだまだやること/やれることがたくさんあるなと思いました。やっていきましょう。
DICOM入門とruby-dicomのRubyバージョンアップ対応検討
はじめに
医療情報技師の資格を取って1年半以上がたった。
医療情報システムの支援先でMWMサーバについての調査が必要となり、DICOMという医用画像のフォーマットや通信に関する規格について学んでいる。規格について知るだけでなく、DICOM自体のソフトウェア的な実装についても学びたいと考え、OSSの実装に触れてみている。一旦、現在の理解度や立ち位置について書き残しておきたい。
DICOMという規格について
JIRA（日本画像医療システム工業会）がボランティアベースで日本語訳を公開してくれているのでこれを読みつつ、Gemini 2.5 Proに質問を投げていく感じで勉強をしている。SCUとか、AEとか英略語が大変多いので自分なりの用語集を作るのが初手として必要なことっぽい。
後述する実装の読み解きや、実際に動かしてみることの方に時間をたくさん割いているので、ここについてはまだ書けることが少ない。
DICOMのOSS実装について
MWMサーバについての調査が必要になり、ChatGPTに以下のように聞いてみた。医療機関で動かすことを考えると脆弱性への対応が素早く行われてほしいので開発の活発さは重要だし、Docker上で動かせると大変便利なので以下のようになった。
あなたは医療情報システムの専門家です。MWMサーバのオープンソース実装のうち有用なものを教えてください。また開発が活発に行われているかどうか、実装言語、dockerイメージの提供があるかどうかそれぞれ教えてください
そうすると、Orthancとdcm4chee-arc-lightを教えてくれた。Orthancのサイトは実にUbuntu的な配色をしていて謎の既視感があり面白い。
dcm4chee-arc-light
以前からdcm4cheというツールキットがあるらしい。(cheはチェ・ゲバラから来ていて革命を意味しているらしい。）これとJBoSSを使いWebの画面が生え、dcm4cheeが生まれたらしい。DICOMのストレージとして動きWebUIがあるのはもちろん、IHEのアクターとして動くとか、HL7を喋れたり、DICOMwebにも対応していたらしい。というのも自分はdcm4chee-arc-light（on Docker)しか使ったことがないので詳しくない。
（リンク先は直PDFであることに注意。OSSのDICOMサーバ実装についての歴史が書かれている）https://www.fujita-hu.ac.jp/~kmuto/webdas/CyberRad2007-T3-kmuto.pdf
dcm4chee-arc-lightは、HL7 FHIRにも対応しているようだし設定をOpenLDAPに置くことで集中管理ができるようになっているそうだが、その分重厚に感じる。調べていてもまだ全体像を把握しきれていない。学べば学ぶほどその重厚さが必要だったとなるのかもしれないが。（実用のためには重厚に見えるような仕組みが必要と気がつくときがありそうという意味）
Dockerを利用する場合の一番シンプルな構成である、"Run minimum set of archive services on a single host" にある docker-compose.ymlはこんな感じで結構長い。これだけでも重厚さが垣間見えるかもしれない。 github.com
ちなみに、rootless dockerで試したところイメージから起動はするのだが、ブラウザでアクセスしても何も表示されないという事象が発生した。詳しく調べても良かったのだが、正直ダルいと感じたので調査できていない。
version: "3"
services:
ldap:
image: dcm4che/slapd-dcm4chee:2.6.7-33.1
logging:
driver: json-file
options:
max-size: "10m"
ports:
- "389:389"
environment:
STORAGE_DIR: /storage/fs1
volumes:
- /var/local/dcm4chee-arc/ldap:/var/lib/openldap/openldap-data
- /var/local/dcm4chee-arc/slapd.d:/etc/openldap/slapd.d
db:
image: dcm4che/postgres-dcm4chee:17.1-33
logging:
driver: json-file
options:
max-size: "10m"
ports:
- "5432:5432"
environment:
POSTGRES_DB: pacsdb
POSTGRES_USER: pacs
POSTGRES_PASSWORD: pacs
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
- /var/local/dcm4chee-arc/db:/var/lib/postgresql/data
arc:
image: dcm4che/dcm4chee-arc-psql:5.33.1
logging:
driver: json-file
options:
max-size: "10m"
ports:
- "8080:8080"
- "8443:8443"
- "9990:9990"
- "9993:9993"
- "11112:11112"
- "2762:2762"
- "2575:2575"
- "12575:12575"
environment:
POSTGRES_DB: pacsdb
POSTGRES_USER: pacs
POSTGRES_PASSWORD: pacs
WILDFLY_CHOWN: /storage
WILDFLY_WAIT_FOR: ldap:389 db:5432
depends_on:
- ldap
- db
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
- /var/local/dcm4chee-arc/wildfly:/opt/wildfly/standalone
- /var/local/dcm4chee-arc/storage:/storage
Orthanc
OrthancはChatGPTによると、軽量・REST連携・柔軟性ありという特徴があるようだ。実際公式サイトにも"Open-source, lightweight DICOM server."という記述がある。
Orthancのdockerイメージデプロイはシンプルだった
version: '3.1' # Secrets are only available since this version of Docker Compose
services:
orthanc:
image: jodogne/orthanc-plugins:1.12.7
command: /run/secrets/ # Path to the configuration files (stored as secrets)
ports:
- 4242:4242
- 8042:8042
secrets:
- orthanc.json
environment:
- ORTHANC_NAME=HelloWorld
secrets:
orthanc.json:
file: orthanc.json
上記のdocker-compose.ymlと、下記のorthanc.jsonを置くだけで簡単に使い始めることができた。画面もシンプル
{
"Name" : "${ORTHANC_NAME} in Docker Compose",
"RemoteAccessAllowed" : true
}
ruby-dicomについて
自分はRubyが好きだし、RubyでDICOMを扱えるソフトウェアがないかと探したところruby-dicomというのを発見した。しかし、last commitは5年前だし、RequirementsにはRuby 1.9.3とありもうメンテナンスがされていないようだ。
先述の歴史資料にもあるDCMTKやdcm4che-toolなどを使えばDICOM画像の送信はできるのだが、せっかくruby-dicomを知ったのでこれを使ってDocker上のOrthancやdcm4chee-arc-lightにDICOM画像を送りつけたいと考えた。実際にDICOM画像を送ろうとしても、DICOM画像持っていないなと思ったが、ruby-dicomにはsamplesフォルダ内にDICOM画像がありこれを使った。
やってみると実際むずかしいことはなく、送る手順としては苦労しなかった。dcm4chee-arc-lightは、host_aeが必要かつ、指定するAEはDCM4CHEE上で登録されている必要があった。
require "dicom"
include DICOM
node = DClient.new("<docker host ip>", 4242)
node.send("./samples/explicit-big-endian_us_8bit_rgb.dcm")
I, [2025-06-11T00:56:17.118573 #124473] INFO -- DICOM: Association successfully negotiated with host DEFAULT (<docker host ip>).
I, [2025-06-11T00:56:17.118666 #124473] INFO -- DICOM: The presentation context was accepted by host DEFAULT.
I, [2025-06-11T00:56:17.255220 #124473] INFO -- DICOM: Receipt for successful execution of the desired operation has been received.
I, [2025-06-11T00:56:17.255769 #124473] INFO -- DICOM: Association released properly from host DEFAULT.
=> false
# dcm4chee-arc-lightにDICOM画像を送りつけるには、host_aeが必要かつ、指定するAEはDCM4CHEE上で登録されている必要がある
irb(main):003:0> che = DClient.new("<docker host ip>", 11112, host_ae: "DCM4CHEE")
irb(main):004:0> che.send("./samples/explicit-big-endian_us_8bit_rgb.dcm")
W, [2025-06-11T04:51:34.528162 #126256] WARN -- DICOM: A presentation context was rejected by the host, reason: 'Transfer syntax not supported'
I, [2025-06-11T04:51:34.528701 #126256] INFO -- DICOM: Association successfully negotiated with host DCM4CHEE (<docker host ip>).
I, [2025-06-11T04:51:34.528942 #126256] INFO -- DICOM: APPROVED: Ultrasound Image Storage (Implicit VR Little Endian: Default Transfer Syntax for DICOM)
W, [2025-06-11T04:51:34.529085 #126256] WARN -- DICOM: REJECTED: Ultrasound Image Storage (Explicit VR Big Endian)
W, [2025-06-11T04:51:34.529164 #126256] WARN -- DICOM: 1 of 2 your presentation contexts were rejected by host DCM4CHEE!
I, [2025-06-11T04:51:34.750754 #126256] INFO -- DICOM: Receipt for successful execution of the desired operation has been received.
I, [2025-06-11T04:51:34.751531 #126256] INFO -- DICOM: Association released properly from host DCM4CHEE.
=> false
irb(main):005:0> che.send("./samples/CR_JPG_IR6a.dcm")
I, [2025-06-11T04:52:00.967245 #126256] INFO -- DICOM: Association successfully negotiated with host DCM4CHEE (<docker host ip>).
I, [2025-06-11T04:52:00.967339 #126256] INFO -- DICOM: The presentation context was accepted by host DCM4CHEE.
I, [2025-06-11T04:52:01.101037 #126256] INFO -- DICOM: Receipt for successful execution of the desired operation has been received.
I, [2025-06-11T04:52:01.101775 #126256] INFO -- DICOM: Association released properly from host DCM4CHEE.
=> false
# host_aeが無いとASSOCIATEがrejectされる
irb(main):006:0> che = DClient.new("<docker host ip>", 11112)
irb(main):007:0> che.send("./samples/CR_JPG_IR6a.dcm")
W, [2025-06-11T04:56:39.540970 #126256] WARN -- DICOM: ASSOCIATE Request was rejected by the host. Error codes: Result: 1, Source: 1, Reason: 7 (See DICOM PS3.8: Table 9-21 for details.)
E, [2025-06-11T04:56:39.541058 #126256] ERROR -- DICOM: Association was denied from host DEFAULT (<docker host ip>)!
E, [2025-06-11T04:56:39.591888 #126256] ERROR -- DICOM: Association released from host DEFAULT, but a release response was not registered.
ruby-dicomのRuby3対応について
自分の詳しいところや得意分野ではないのだが、せっかく見つけたgemがRuby 1.9.3までしか対応していないのはさみしいと思い、Rubyバージョンアップ対応をしてみようかなと思っている。実際思っているだけではなく、調べたり対応を試しているのだがDICOM自体の知識がまだ足りないうえに、Ruby自体やバージョンアップ対応のノウハウが足りてなくて現状うまくいっていない。Gemini 2.5 Proに相談しているものの、アドバイスをしてくれる人がほしいところだ。
RSpecのテストコードはすでにあるが、GitHub ActionsとかCIは無いようだったのでバージョンアップ対応の初手としてGitHub Actionsでテストを実行させるようにしてみたのがこちら。
RubyKaigi2025にNOC helperとして参加した
RubyKaigiについて
RubyKaigiは2010の当日スタッフが初めての参加で、気がつけば15年近く経っていた。レポート班をやり、るびまのことをやったり、地域Ruby会議のオーガナイザーをやったりした。そのような経験からか、Rubyistとしての起源みたいなものを感じた。実家より居心地の良いホームのような感じがある。形を変えてずっと続いていることに感謝の気持ちが絶えない。
NOCとしての活動
NOCというのは、Network Operation Centreのこと。NOCチームは雰囲気が良かったと思う。年齢気にせず楽しめた。(たぶん自分が最年長だが、そんなことは実際どうでも良いと思えた)
今回のNOCチームでの自分の仕事としては、L1の敷設と撤収に専念していた。日頃数十メートルの光ファイバーやLANケーブルの敷設と撤収をやることはないので良い経験となった。また、下見を通した設計のプロセスについて思いを馳せることができた。各種機器の設定や、ソフトウェア部分についてはほんのりとしか掴めていないので今後の課題とする。
みんながいなくなったホール？を撮った。 「つわものどもが夢の跡」などと詠みたくなる。
NOCだけではないが、helperとかをやらないと得られない会話の機会とか人脈とかがあると思う。スタッフ部屋にてそう思える会話があり、やはり良い体験だと感じた。
参加者として
どの日もKeynoteが大変良かったと感じた。また自分の英語リスニング能力の高まりを感じた。しかしそれにしても、話している内容はわかるのだけれど、自分が普段読み書きしている部分ではないので、もどかしさを感じるところがたくさんあった。普段からコードを読み書きしていくことでこのもどかしさの解消をはかりたい。趣味としている技術領域に関するコードの読み書きをやっていけそうなので、習慣化しようという気持ちになった。
育児の先輩たちと、たくさん育児の話をした。ライフステージが変わっても、先輩方と雑談できているので、少し先の話題を仕入れることができて大変ありがたい。去年は2人目の子供のリリースから数ヶ月だったので参加もhelperも無理だったのだけれど、かつての会社の先輩、専務、社長とかと話していて、切れ目なく交流が続いていることのありがたさを感じた。エモい話するとアレなんだけど、実際これらの体験は人生だなとしか言いようがないなという気持ちになった。細々とRubyistを続けてきてよかったなと思った。
予習復習
日々のインプット、アウトプットを続けて、RubyKaigiの予習につなげることで RubyKaigiの熱量、深さに当てられないように準備するということができるようになった。これができるようになるまでに自分は10年以上かかった。一過性の熱量の高まりにしてしまわないように、日々をやっていく必要がある。
そう考えるとこの数年でコミッターになった人たちののめり込み具合といったら半端ないなと思った。
会期中の運動
今回はボルダリングとランニングをした。元気いっぱい、という感じだがNOC helperで無限スクワットした(ケーブル敷設して、養生テープ貼ってという動きがほぼスクワット)後に、ボルダリングをやったことで、あちこちの筋肉がほぐれた。最終日の翌日にランニングをしたことで、パンパンになってた足が軽くなった。どうせ暴飲暴食するからと、ボルダリングやランニングの予定を事前に入れておいたのだった。実際良かった。
写真が雑すぎて何のことかわからないと思うけど、弘法大師像を下から撮った写真…。ランニングでこの像の下まで行ったのだった。その後朝ラーメンした
会社の若手引率
北海道に住んでいる若手を引率する役割もやった。いろんな人との会話をさせてもらった。エンジニア人生において、何らかのよい機会となっていることを祈りたい。
次回開催地について
会期中に北海道にゆかりのある人たちと飲んだり、集合写真を撮っていた。次回開催地予想についても話し合っていたのだが、RubyKaigiが一度終わった後に札幌で一度やって以来、北海道はご無沙汰だったのでそろそろ北海道、もしくは北陸あたりでしょ〜などと話していた。そのような流れからの函館開催を知ることになり、嬉しいのと、やはりか〜という気持ちが入り混じった。
函館は良いところだし、YAPC函館に出たので少し前に予習済みだし、海外からのRubyistも含めて函館で会えるのかと思うととても楽しみな気持ちがある。
