saku_238のログ

子育てのことで頭いっぱい

僕の歓迎会ログ

今夜は本当に楽しかったので、ログを残す。

 

腹の底から笑った、ってこういうことだなと思った。

 


僕はやっぱり、純粋に「いいモノをつくりたい」だけなんだと思う。

 

歳だから、才能がないから、家族がいるから、お金がないから、今じゃないから。という言葉を、無意識に盾にしていただけだった。

 

リスクにおびえ踏み込まない理由を、きれいな言葉に言い換えていただけだった気がする。

 

今いるメンバーは本気でモノづくりついて考えている。無論上司からの評価が下がるとかもいない。退勤後や休日でも僕たちのモノづくりに取り組んでいるメンバーがいる。

 

今の僕にはできないことやわかっていない事が山ほどある。

本気で考えてもそれを恥だと思わずに「わからない」と言える環境が、ここにはある。

 

キャリア2週目とか、正直どうでもよい。モノづくりについて、誰かと比べて評価される場じゃなくて、一緒に前を向いて考えてくれる人たちがいる。それだけで、人はこんなにも前向きになれるんだなと思った。

 


そんなことを、言葉にしなくても伝わってきた歓迎会の時間でした。

 

いい夜でした。

 

早くバリューを出したい!心底思いました。

 

後書き、終電帰宅でも妻が起きてたし、はなまるにしっぽぶんぶん振って吠えられた。

技術勉強ログ:GitHubとかIaCとかAWSとか

入社して早々、QA指摘潰しやリファクタリングの作業に取り掛かっているのですが、正直なところ言語系のチュートリアルをまともにやっていない状態だと何もわからない…。 というわけで、休日を使って基礎から勉強したので、ログを残す。

今日は実際に手を動かして何か作ってみよう!ということで、2つのWebアプリを作ってGitHub Pagesに公開するところまでした。


作ったもの(1)寿司タイピング

遊べます: https://238sakurai.github.io/sushi-typing-game/

お寿司のネタをローマ字でタイピングするシンプルなゲームです。

主な機能

  • 30秒/60秒のゲームモード
  • マグロ、サーモン、ネギトロなど10種類のネタ
  • WPM(1分間あたりの単語数)やタイプ率の計測
  • 3...2...1のカウントダウン演出

技術スタック

  • Next.js 15 (App Router)
  • TypeScript
  • Tailwind CSS

作ったもの(2)九九タイムアタック

遊べます: https://238sakurai.github.io/kuku-time-attack/

子どもが楽しく九九を学べるWebアプリです。うちの子と一緒に遊べるように作ってみた。

主な機能

  • タイムアタック&練習モード
  • キャラクター選択(犬・猫・鳥・恐竜・車)
  • 正解するたびにキャラクターが走る演出
  • 青空と草原の背景
  • 効果音(ON/OFF可能)
  • ベストタイム保存
  • 間違えた問題の復習モード

技術スタック

  • Next.js 15 (App Router)
  • TypeScript
  • Tailwind CSS
  • Web Audio API(効果音)

作ったもの(3)Minecraft サーバ管理 LINE Bot(プライベートリポジトリ)

LINE から Minecraft サーバを操作できる Bot を開発中。

参考にした記事

AWSで低コストなMod環境のMinecraftサーバー構築[前編] - クロスパワークラウドブログ

元記事では Discord Bot を使っているが、今回は LINE Bot に置き換えて実装している。スポットインスタンスを使ったコスト削減や、EBSスナップショットでのワールドデータ永続化など、インフラ構成の部分が参考になった。

構成の概要

  • LINE BotAWS Lambda 上で動かす
  • LINE からメッセージを送信してサーバを起動/停止
  • スポットインスタンスでコスト削減
  • EBS スナップショットでワールドデータを永続化
  • AWS CDK(TypeScript)でインフラをコード管理

学んだこと

  • LINE ビジネスアカウントの登録(初めて登録した)
  • LINE Messaging API の設定
  • AWS CDK を使った Infrastructure as Code
  • Lambda + API Gateway の構成

Cursor に MCP を接続した

ここまでできたのは、Cursor エディタに MCP(Model Context Protocol)を接続して、AIアシスタントから外部ツールを直接操作できるようしたから。

接続した MCP サーバ

MCP サーバ 用途
Context7 ライブラリの最新ドキュメントを取得
Notion Notion との連携
Figma Figma デザインの参照・操作
GitHub リポジトリ、Issue、PR、Actions の操作
spec-workflow 仕様書ワークフローの管理
aws AWS リソースの操作
terraform Terraform ドキュメント検索、コマンド実行

できるようにはなってないけど、触れた事。

  • AI に指示するだけで GitHub の Issue 作成や PR 確認ができる
  • Terraform のリソース情報を調べながらインフラコードを書ける
  • ライブラリの最新ドキュメントを参照しながらコーディングできる
  • Figma のデザインを見ながら実装できる

学んだこと

1. GitHub Actions による自動デプロイ(IaC/CI/CD)

今回初めて GitHub Actions を使って自動デプロイを設定した。

.github/workflows/deploy.yml にワークフローを書くと、main ブランチにプッシュするたびに自動でビルド → GitHub Pages にデプロイされる。

これが Infrastructure as Code (IaC) の考え方。手動でやっていた作業を「コードで定義」して自動化できるのは便利。

2. Next.js の静的エクスポート

GitHub Pages で Next.js アプリを公開するには、next.config.ts に以下の設定が必要だった:

const nextConfig = { output: 'export', basePath: '/リポジトリ名', images: { unoptimized: true }, };

3. GitHub Pages 公開

個人的に一番嬉しかったのがこれ。

今まで作ったものをローカルで動かすだけで終わっていたが、GitHub Pages を使えば無料でインターネットに公開できる。

友達や家族に「これ作ったよ」と見せられるのが良い。

4. AWS CDK と IaC

Minecraft サーバの構築で AWS CDK を触ってみた。TypeScript でインフラを定義できるのは、普段のコーディングと同じ感覚で書けて良い。

まとめ

12月20日は、2つのWebアプリを作成してGitHub Pagesに公開するという流れを一通り体験できた充実した1日だった。

業務ではいきなりコードを触っているけど、やっぱり基礎から手を動かして学ぶのは大事だと実感。これからも休日に少しずつ勉強を続けていきたい。


リポジトリ - https://github.com/238sakurai/sushi-typing-game - https://github.com/238sakurai/kuku-time-attack

転職4日目。

今日の落ち着かなさも、ここから前へ進むための過程としてログを残しておきたい。


新しい環境に身を置いてから、4日間しか経っていない。

前の環境は人が多く、事業も多く、情報があふれていた。Slack のチャンネルも膨大で、常に何かが流れていた。 その中で忙しさに流されるまま、手を動かし続けていれば成果に近づける感覚があった。

今の環境は対照的だ。

事業のフォーカスは明確。Slack も最小限。自分が向き合うべきタスクもシンプル。 集中できるはずの環境なのに、なぜか落ち着かない。 雑談の場で「わからない」と弱音を吐いてしまう。

理由を考えてみる。

  • スマホSNSの通知がうるさく気になってしまう。
  • まだ業務の全体が見えていない。
  • 使われている技術の理解も全くできない。
  • どこからキャッチアップすべきか、足場が定まらない。

そんな状況かで、周囲のメンバーは迷いなく進めている。 その姿に、自分だけが“入口”に立っている感覚になる。

ここ数年、技術広報として働いてきた。 エンジニアから離れた期間は約5年。 技術広報からエンジニアに戻った。 このブランクが影響しているのだろうか。

キャッチアップすべき知識は多い。 理解が追いつかず、視線だけが前へ急いでいく。 モチベーションは高い。 早く追いつきたいし、貢献したい。 ただそれ以上に、「まだ知らないこと」が圧倒的に多い。

まだ4日目。

未熟であることに理由はいらない。 会議の時は電源をOFFにしてみよう。メモを取ってみよう。 少しずつ理解し、少しずつ積み重ねていく。

転職ログ

弁護士ドットコム退職and 転職のログを残す。

 

2025年11月末をもって、2年間お世話になった弁護士ドットコム株式会社を退職しました。
そして12月1日より、Dress Code株式会社というスタートアップにエンジニアとしてジョインしました。

 

弁護士ドットコム/クラウドサインには、ご縁あって技術広報・DevRelまわりの役割で関わり始めました。
テックブログの企画・編集、アドベントカレンダー、カンファレンス出展、コミュニティとの連携、社内外の勉強会づくり…などなど、ここには書ききれないくらい、濃い2年間でした。

 

特に最初の1年くらいは、本当に「週7でずっと弁護士ドットコムのことを考えていた」と言っても大げさじゃないくらいで、

 

・どんなエンジニアやデザイナーが社内にいるのか?
・そして、彼ら彼女らの取り組みはどんな人に刺さるか
・どうことを伝えれば社内の人が出やすくなるか
・イベントを“しんどい”じゃなく“楽しい”に変える

 

にはどうするか

みたいなことを、ずっと頭の中でぐるぐるさせていました。

 

技術広報は「コンテンツを量産する仕事」ではなくて、エンジニア、デザイナー、Biz、バックオフィス、経営陣…いろんな人たちの想いをつなげて、プロダクトと組織にとって良い循環をつくる仕事なんだ、と実感させてもらった2年間でもありました。

一緒にブログを書いてくれたみなさん、登壇してくれたみなさん、無茶なお願いをしても笑って付き合ってくれた社内外のみなさんには、本当に感謝しかありません🙇‍♂️

 

弁護士ドットコム/クラウドサインは、これからさらに新しいフェーズに進んでいくと思いますが、自分は一ファンとして、外側から全力で応援していきます。

 

 

そして、これからのことを少しだけ。

12月1日からは、DressCode株式会社でエンジニアとして働き始めました。
肩書きはエンジニアですが、これまで培ってきた技術広報・DevRelの経験もフルに活かして、「プロダクトづくり」と「発信・コミュニティづくり」を両輪で回していけたらと思っています。

転職しても、テックブログを書いたり、イベントを企画したり、Xやブログで好き勝手に言語化したりするスタンスは変わりませんので、引き続きゆるくお付き合いいただけると嬉しいです。

 

転職のこと、技術広報やDevRelのこと、新しいチャレンジのことなど、何か気になることがあれば、ぜひ気軽にメッセージをください。

「考え方がおかしい」と言われた夜に

1on1での何気ない会話から感じたことをlogに残す。

---

先日の1on1で、僕のマインドについて話をすると相手からこんな言葉をかけられました。

> 「君の考え方はおかしい」

……ん?
これはバグレポート?それとも仕様変更の提案?
いや、そうじゃない。
これは「価値観」へのコメントだった。

 

 

 

もし、こう言われていたら、みんなはどう感じるだろう?

> 「僕の考え方とは違うね」

この一言だけで、ずいぶんと印象が変わる。

 

違うだけで、間違ってるわけじゃない。
受け取る側の心のログに残るSeverityが、ずっと軽くなる。

 

 

「違い」は世界を広げるけど、 「おかしい」は世界を閉じにかかってくる。

 

 

でも、ふと思った。
僕の考え方は、本当に「違う」だけなんだろうか?
もしかして「おかしい」のかもしれない。
あるいは、「おかしくない」と言い切りたいだけかもしれない。

 

---

思考のPull Requestは、即Mergeされるものじゃない。
Reviewされて、時にはRevertされて、
それでも前よりマシなブランチを生きていく。

---

**言葉は設計だ。**
相手の心にマージできるかどうかは、メッセージの粒度とコンテキストにかかっている。

---

## おわりに

1on1はデバッグの機会であると思っていて、マウントをかける場ではない。

 

批判に受け止めるよりも、分岐条件の整理を。


そして何より、自分の考え方を伝える勇気を忘れないようにしたい。

ネガティブ発言を傾聴する、視野のバグ修正術

「ポジティブだけじゃ、バグは潰せない。」ということを学んだのでログを残す。


きっかけ

ある日、“不満が多いエンジニア”と雑談した。 その方の良いところは「陰口ではなく、パブリックな場で不満を発信してくれる」。組織にとってはかけがえのない人材。
雑談していると時々、メンタルに ドンッ と負荷が来たけど、途中でハッと気づかせてくれる。
「あれ? 僕、都合いいログや発信だけ読んでない?」 と気づかせてくれるのだ。

“不満・課題を言う”人は、欠陥報告をしてくれる。


ネガティブ発言 ≒ 無料ペネトレーションテスト

彼らのセリフ 僕が得た気づき
「このフロー、めんどくさすぎ!」 手順が多段階化→新人が詰む未来
「会議、目的ブレブレじゃん」 アジェンダ未定義=時間泥棒案件
「またポジティブシンキングで押し切るの?」 リスク管理が根拠レスになる危険
「福利厚生の見直し、実質改悪じゃん」 制度変更の影響分析不足→スキルアップ停滞・従業員エンゲージメント低下

ネガティブは バグ報告、 ポジティブは リリースノートになる。 どちらも無いとプロダクトや組織は崩壊、って話なんだなと思った。


まとめ

  • ネガティブ発信人材は 組織のデバッガーになる。
  • ポジティブ一辺倒だと、自分の視野バグに気づけない。
  • メンタルを守りつつ、ログはしっかり回収するのが吉なんだな。(ネガティブばかりに視野を向けていると自分のメンタルも悪くなる。)

不満は資産。捨てるな、活かせ。