shiloの素人日記

素人考えを書きます

2025年振り返り

2026年になっちゃったけど、2025年に振り返りができていなかったので、この場でしたいと思う。総じて初めてのことにいろいろチャレンジできたので、良かったと思う。2026年はこれらの取り組みを継続していけると良さそう。

仕事

開発

2025 年はバックエンドというよりインフラメインのタスクが圧倒的に多かった。特に EC2 を Fargate に載せ替えるという案件の要件定義や基本設計をここ数ヶ月はやっていたおかげで ECS 周りの知識は一定ついたと思う。これまではどちらかというとバックエンドのタスクが多かったので、そういう意味ではインフラの知識や経験を増やせた一年だったと思う。2026年も基本はそこの詳細設計や実装を進めていくことになるので、引き続き頑張っていきたい。

一方でバックエンドのコードを触る機会があまりないので、そこは課題だと思っている。今後も自分のタスク的にしばらくはバックエンドのコードは触れなさそうなので、レビュー担当として自分なりの実装を思い描いてみたり、個人開発とかで補っていくしかなさそう。ここは意識しながら日々過ごしていかないとなかなか自分のスキルを伸ばしていける状況ではないと思うので、頑張らねば。

あとは今年気づいたけど自分はお客さんの要望をヒアリングして要件を詰めていくような超上流は苦手らしい。どこまでお客さんの要望を要件に落とし込んでいくか、どこを諦めてもらうかの顧客折衝が難しいなと思うことが多かった。ただ、苦手とはいえ嫌いではなく、むしろうまく調整できた時は嬉しいので、2025年に経験したことはしっかり自分のスキルとして今後も顧客折衝とかにも積極的にチャレンジしていけるとよりエンジニアとしての幅が広がったりするのかなと思ったりする。

その他

上記の開発以外に2025年はいろいろなことに手を挙げて参加させてもらった。会社のテックブログの編集委員（＝運営担当）になったり、新卒の技術面接やインターン（サマーインターンや 1week インターン）のメンターとかやった。上記開発タスクの他のチームの人や学生と関わる機会が多かったので、新しい学びが多かった気がする。

あとは会社として RubyKaigi や Kaigi on Rails といったカンファレンスにも手を挙げて参加した。RubyKaigi は初参加でセッションの内容とかほぼ理解できなかったけど、普段何気なく使っている Ruby を作っている人たちがどのようなことを考えて Ruby という言語を育てているかというところを感じることができて自分も OSS に対するモチベーションが上がった。

hogarakaryo.hatenablog.com

Kaigi on Rails ではうちの会社から1人登壇することになってすごいなあと思う一方で、自分も頑張って一度くらいは登壇してみたいなという気持ちにもなったので来年はぜひプロポーザル出してみたいと思う。（今くらいからネタ探しはしておいた方がいいのかも）

hogarakaryo.hatenablog.com

外部発信

技術ブログ執筆や社外の勉強会でのLTは今年も何回かできたので良かったと思うが、それ以上に YAPC::Fukuoka 2025 にプロポーザル出したのはいい経験だったと思う。結果的に落選だったけど、自分でもプロポーザル書けるんだということとプロポーザルは準備がめちゃめちゃ大切という学びがあった。 詳しくは以下に書いた。

speakerdeck.com

2026年は今回の学びを活かして、積極的にプロポーザル出していきたいと思う。

OSS 活動

2025年は初めて社外のリポジトリにコントリビュートできた。普段技術ブログ周りでお世話になっているはてなブログワークフローのコードを読んでいたときにたまたま発見した修正で大した内容ではないが、ずっと OSS 活動してみたいと思っていたので、はじめの一歩を踏み出せてよかった。

github.com

今回の対応で OSS 活動をしていくためにはやっぱりコードをたくさん地道に読んでいくことが大切であることがわかったのと、なんとなくの OSS 活動の進め方みたいなところを感じ取れたので、2026年はもっとたくさんのコントリビュートができたらいいなあと思う。

英語

英語はちょこちょこといろいろやったけど、これといった成果みたいなのはなかった。英語に関してはモチベーションの波が大きいので、ある程度しっかりとした目標を2026年は立てないと成果には結びつかないのではないかと思う。 とりあえず目標を立てるところからかな。

（直近、妹に留学先で知り合ったイタリア人の彼氏ができたらしく、この間その彼氏を紹介された時にカタコトの英語でしか挨拶できなかったので、その彼氏とコミュニケーションをとることを目標としようかなと思っている。）

その他

上記にも書いたが、圧倒的にバックエンドのコードを書く機会が少ないので年末から久しぶりに個人開発をやり始めた。テーマは今どのカンファレンスのプロポーザルが受付期間なのか分かりづらく、そこら辺の情報が一元的にまとまっているサイトがあるといいなと YAPC::Fukuoka 2025 にプロポーザルを出した後から感じているので、そこら辺の課題を解決できるような Web サービスを作りたいと思っている。とりあえずサイトの最低限の雛形はできたので、これの機能拡張を2026年の頭はやっていければと思う。

https://cfpartner.onrender.com/

Kaigi on Rails 2025 に参加してきました

はじめに

こんにちは、shilo です。 先週 Kaigi on Rails 2025 に参加してきました。 今回は昨年に引き続き2回目の参加です。 個人的な所感をレポートとしてざっくりまとめておきたいと思います。

印象に残ったセッション

どのセッションもスピーカーの方の熱意と深い知見に溢れており、多くの学びを得られました。 ここでは、特に印象に残ったセッションをいくつか振り返ります（メモの取りこぼしや認識誤りなどあれば、ぜひご指摘ください！）。 （聴講を泣く泣く諦めたセッションも多いため、YouTube での公開を心待ちにしています！）

5年間のFintech × Rails実践に学ぶ - 基本に忠実な運用で築く高信頼性システム（ ohba さん）

本セッションは以下の内容でした。

  • Fintech 領域では高い信頼性が求められるシステムを運用する必要がある。運用とは本質的にビジネスを可能とすること。
  • そのために開発段階では要件に特化したシステムコンポーネントを分離するアーキテクチャ設計やConcern / Concering を活用した積極的なモジュール化等の工夫を行った。
  • 運用段階では資金移動業者向けガイドラインを確認し、異常検知の仕組み整備、パフォーマンスモニタリング、SLIやSLOの導入、アラートトリアージの徹底、障害対応フロー整備など様々な取り組みを行っている。
  • 結果としてスケールに耐えうる高信頼性を開発/運用を通じて確保できている。

私が担当するプロダクトもスマートバンクさんと同様に決済処理があり、求められる品質特性が近いため、毎回非常に参考にさせていただいています。 今回の発表も私のチームでも取り入れると効果がありそうなアイデアがたくさんありましたので、今後ぜひ取り入れに向けて検討したいと思います。

Railsによる人工的「設計」入門（ 大場 さん）

本セッションは以下の内容でした。

  • 設計はコードレベルで考えることではない。全部のコードを考えるのは実装であり、実装より抽象度高いレベルで考えることが設計。
  • 人工的なメソッドとして設計を行うためにすることは「逆算」。
    • 完成したいシステムを思い浮かべ、そこから思考の起点となるゴール（最も実現したい本質的な事柄）を見定める。さらにそのゴールを達するためには何を検討しなければいけないかを必要かをブレイクダウンしていく。
    • ポイントは上記のゴールや課題などのそれぞれのトピックに短い名前をつける。
    • 本質的なところではない部分の課題も一旦洗い出すだけ洗い出しておくと後から考えやすい。

私自身、設計の進め方って言語化が難しいなと感じていたところがあったのですが、今回のセッションではそこを見事に言語化していただいた内容だったのでとても参考になりました。 特に「逆算的に本質的なものから考える」というのは瑣末なものに意識を取られずに本質的な面を検討ができるので、それだけでその設計自体が大外れすることはなくなり、非常に重要な思考だと再認識しました。 最近、新卒のエンジニアの方と一緒に仕事をする機会が増えてきており、より大きな観点での設計というところも今後一緒にしていくと思うので、その時に進め方で迷った場合などは今回学んだことはアドバイスとして伝えてあげたいなと思いました。

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜（ joker1007 さん）

本セッションは以下の内容でした。

  • Service クラスに関しては実際の仕事の現場ではなるべく使わないほうがいいというのが最近の認識。なぜなら開発統制の困難さを上回るメリットが見当たらない。
    • Rails は Service クラスなしの場合、レイヤー分類がよくできている。そこにService クラスを入れると逆に構造がわかりづらくなり、Rails のレイヤー構造がわかりやすいというメリットが失われる。
    • これは継続的に開発のペースを維持するためには読みやすく想像しやすい構造を作ることが大事だが、Service クラスは上記のように構造をわかりにくくしてしまう。
  • 結局のところ、Service クラスだの Form Object はあまり重要ではなく、ちゃんとシンプルさを求めることから逃げていないことが重要。
    • 複雑なシステムを設計するときに重要なのはコンテキストマップを作り、コンテキスト同士は境界を超えた先に影響を与えないようにする。
  • 結局大切なのは開発者にとって想像がつき、驚きが少ない開発。そこに対して常にいい判断をし続けることが重要で、それができる環境というのがいわゆる設計できている状況である。

私の担当しているプロダクトでは一部に Service クラスを使っています。ただ、今回の発表があったように Model側に処理が書いてあるのか、Service クラス側に処理が書いてあるのか明確な線引きがないため、手を入れるたびにどちらにコードが書いてあるか確認が必要な場合があります(そのおかげでFat ModelというほどModelのコードが肥大化していないというメリットももちろんあります)。ここら辺は発表にもあった通り正解は無くて、今後も常にどうして行けたらいいかを逃げずに考えることが何よりも重要なのかなと思いました。

2重リクエスト完全攻略HANDBOOK（ mitani さん）

本セッションは以下の内容でした。

  • 2重リクエストの対策は意外に難しい。なぜなら上記のように2重リクエストが起こりうるシチュエーションは幅広いため、それらのシチュエーション全てに対応できる対策は存在しないためです。そのため、クライアント側（フロントエンド）とサーバー側（バックエンド）の両方で多重に防御を仕掛ける必要がある。
  • さまざまなシチュエーションに応じた防御策がクライアント側とサーバー側に分けて主に9つあり、それらを組み合わせて対策する必要がある。
  • Fintech 領域でサービスを展開するスマートバンク社では、排他制御、Idempotency-Key ヘッダーやワンタイムトークン、レートリミット等を機能や処理の特徴に合わせて採用しており、実サービスで有効に機能している。

発表の中で mitani さんが話していた「2重リクエストは単なるバグではなく、ビジネス的な損失に直結するセキュリティ・信頼性の問題である」と言う言葉がとても印象的でした。なんだかんだ自分としてもこのセッションを聴くまでは2重リクエストを他の障害より若干軽視している節はあったかもしれないです。 改めて色々なエンドポイントで考慮しなくてはならない2重リクエスト対策を軽んじず、ユースケースやアプリケーションの特性に応じて防御策を組み合わせて2重リクエスト対策することが重要だと認識しました。

また、こちらの mitani さんのセッションを聴講して、自分が普段担当しているプロダクトの2重リクエスト対策を振り返るという記事を会社のテックブログで執筆中です。 そちらもまた近いうちに公開いたします。

オフィシャルパーティー

オフィシャルパーティーはまさかの東京国際フォーラムでした。 建築学科出身で元々好きな建物だったこともあり、非常にテンションが上がりました。 （大部分がガラス張りで、夜には宇宙船のデッキのように見えるあの雰囲気が特に好きです）

オフィシャルパーティー自体は今回もたくさんの Rubyist の方とお話しすることができました！ 登壇者の方ともたくさん話させていただいたんですが、特に katakyo さん（@katakyo_51）や Koya さん（@koxya）、daichi さん（@da1chi24）と話した際に「どのようにプロポーザル書いたり、発表準備したか」という生の話をたくさん伺うことができました。 今年は弊社でも mugi さん（@mugi_1359）が登壇されて、そういった意味でも多くの登壇者の方の話を聞けてとても刺激になったので、来年は私もプロポーザル提出＆登壇を目指したいと思います！

また、会の途中ではKashiwa.rb でお世話になっている koji さん（@kozy4324）の会社と弊社の新卒エンジニア同士の交流も生まれており、そういう意味でもすごく良い場だったなと思います。 みなさん、ありがとうございました！

まとめ

今年もすごく楽しく、たくさんの学びがあった2日間でした！ 今から来年の Kaigi on Rails が楽しみです！

ここまで読んでいただきありがとうございました！

弊社の新卒エンジニアが書いた参加レポートもぜひ

tech.giftee.co.jp

3日坊主の私が5年間、毎日日報を書き続けた3つの理由

はじめに

こんにちは。shilo です。

突然ですが、私は新卒の頃から毎日、日報を書いています（数少ない自慢です）。

自分でもここまで長く続けられるとは思っていなかったので、自分が一番驚いています。

でも振り返ってみると自分なりに訳があって続けているんだなということがわかったので、この記事では、3日坊主で定評のある私がなぜ日報を続けてこられたのか等を紹介できればと思います。

なぜ日報を書くようになったのか

日報を書くようになった経緯は正直あまり覚えていませんが、そんな大した理由はなく、業務報告ということでやり始めたのかなと思っています。

しかし、今も日報を書き続けている理由は明確にあります。それは作業コストに対して圧倒的にメリットが大きく、コスパが最強だと考えるからです。

日報のメリット

5年間続けてみての感じた日報のメリットは主に以下の3つです。

学んだことが知識やスキルとして定着しやすくなる。

業務で学んだことや考えたことをその日のうちに日報という形で半強制的にアウトプットするので知識やスキルの定着がしやすくなります。

「インプット」と「アウトプット」は、知識を定着させるためには必要不可欠です。しかし、日々の業務の中ではインプットに偏りがちで、せっかく得た知識も「わかったつもり」で終わってしまうことが少なくありません。

日報は、この「わかったつもり」を解消し、ちゃんと学びを自分のものにするために有用なツールだと思っています。どういうことかというと業務で経験したことやその時考えたことを自分の言葉で書き出すことで、あいまいで抽象的で感覚的だった学びが具体的な学びに変わります。この具体的に文字に起こすというのがチリツモで効いてきて、だんだんと学んだことを自分の言葉で語れるようになり、そこで初めて自分の血肉にすることができます。

例えば、私はエンジニアなので業務中にプログラミングのエラーに遭遇することが日常茶飯事です。自分が知らない未知のエラーと遭遇することもあり、その時はググったり、AIも活用しながら試行錯誤でエラーを解決する必要があります。その時の試行錯誤の経緯は非常に重要な学びになります。ただし、こういった学びは揮発性なので、何かにメモらない限りは数日、数時間で忘れてしまいます。そんな時に日報にそれらの試行錯誤の経緯やそこから得られる学びを文字としてまとめることで、忘れにくい実践的な知識として定着させることができます。（後から同じエラーに遭遇した場合にも参考にすることができるので、そういった意味でもメリットがあります。）

読んでくれる人に自分のことを知ってもらえる

実は日報って反応がないことも多いけど、こっそり読んでくれてる人はたくさんいます（いると信じてる）。 実際、日報自体にコメントや反応はせずとも、日報の内容をきっかけに自分に興味を持ってくれて、オフィスで会った時に話しかけてくれるもたくさんいます。つまり、気軽に話せるくらいの社内の知り合いをコスパよく増やすことができます。

企業に属して仕事をする場合は必ず多かれ少なかれ他の部署とのやりとりが発生するので、その時に他の部署に気軽に相談できる知り合いがいるかどうかはその企業内のやりとりのしやすさに直結します。これはエンジニアに限らず、社会人として仕事をしていく上で非常に大きなメリットになると思います。

後から日報を振り返ることで、自信につながったり、より中長期的な改善アクションを見つけることができる

日報を続けることで、自分がどんなことに挑戦し、どのような課題を乗り越えてきたのか、その成長の軌跡を見える化できます。私自身も定期的に過去の日報を読み返すのですが、当時の自分と今の自分を比較でき、成長を客観的に実感できるため、モチベーションの維持に役立てています。

また、日報を分析することで自分だけの成功法則や失敗法則もなんとなく分かったりします。例えば、私の場合は日報にこれまでに成功したことや失敗したことを記録していいるので、それらをグルーピングして分析してみると、ものごとをうまく進められた時にはチームメンバーに相談を早めにしていたとかとか、ものごとで失敗したときの大半は何かしらが準備不足だったという傾向を掴むことができました。それ以来、準備には時間をかけて取り組むようにするなど改善アクションをとっています。

このような感じで毎日のPDCAだけではなく、もう少し長いスパンでのPDCAを回すためのネタを日報は提供してくれると思います。

普段どのように日報を書いているか

では私が普段、どのように日報を書いているかというと、すごくシンプルな以下のフォーマットで日報を書いています。これを終業前の10〜15分で書き上げて、Slack の自分の分報チャンネル（times チャンネル）に投稿しています。

  • 日付
  • やったこと
  • 思ったこと・学んだこと
  • よもやま

KPT なども試しましたが、KPTはKEEPとPROBLEMを分けて書かないといけなく、どっちか判断が微妙な場合に筆が止まってしまい、日報としては若干の書きづらさを感じることが多々ありました。毎日やる上でストレスなくやることが大事なので、筆が止まらないフォーマットというのは結構大事で最近は自分として書きやすい上記フォーマットに落ち着いています。

書く内容としては「思ったこと・学んだこと」を重視して書くようにしています。理由はその時思ったことや学んだことは忘れてしまう可能性が高いので、忘れないうちに日報でできる限り言語化して振り返ることが成長のためには重要だと考えているからです。

また、よもやま話もネタを見つけて欠かさず書くようにしています。理由はよもやま話も自分を知ってもらうために非常に有用な情報だからです。趣味でやっていることは何なのか、最近の気になっているスポットはどこなのか、そういった情報は読んでくれた人に情報を提供するとともに、共通点を作るためのフックになりえます。

日報を書くうえで大切にしていること

内容を充実させるよりも長く習慣化することが大事

とにかく完璧を目指さずに頑張りすぎないことが大事です。

個人的にはどんなに内容が薄くても別に気にしなくていいし、できない日があってもいいと思います。飲み会がある日は飲み会を優先してもいいし、ゲームの発売日なら書かなくてもいいと思います。

大事なのは書けなかった日や内容が薄くなってしまった日のことを気にせず、その次の日も変わらずに日報を書き続けることだと思います。

自分に嘘をつかない

多少恥ずかしくても日報は自分の思いを吐き出すべきだと思います。 もちろん人の目に触れるように書く場合はチームメンバーの悪口等は控える必要がありますが、自分の熱い思いや考えたことは遠慮せずに書いていいと思います。

最後に

日報って正直胸を張ってやったぞ！って言えるほどのものではないですが、コツコツ続けてみると案外良いことがあったりします。

もしこの記事を読んでみて、少しでも日報について興味を持ってもらえたら嬉しいなと思います。

ここまで読んでくれてありがとうございました！

RubyKaigi 2025に参加してきました！

はじめに

こんにちは。shiloです。 3週間近く前ですが、松山で行われたRubyKaigi2025に参加してきました。 今回はRubyistになって1年、初めてのRubyKaigi参加です。それとない所感ということでレポートとしてまとめておこうと思います。

参加前の準備

セッション聞いて全く分からないというのは嫌だったので、去年のセッションの録画を見たり、SmartHRさんの事前勉強会に参加したり、Rubyのしくみ　Ruby Under a Microscopeを読んだりして予習しました。

特に事前勉強会でのudzuraさんの資料が大変参考になりました！Parser周りやJITの概要や現状を知れたのは大きかったです。

docs.google.com

印象に残ったセッション

セッションはParserやJIT、型に関するものを中心に聴講しました。 いずれもハイレベルでとても全てを理解することはできませんでしたが、スピーカーの方の熱意や思いを感じることができてすごく楽しかったです！ ここでじゃいくつか印象に残ったセッションを振り返ろうと思います。

Make Parsers Compatible Using Automata Learning（Fujinamiさん）

本セッションは以下の内容でした。

オートマトン理論の詳しい技術的な話は理解できませんでしたが、parse.yとPrismを比較できる共通のフォーマットを作り、それの差分を比較するアプローチ自体は非常に素直で理解できました。 理論から攻めてみるというユニークな発表でしたが、その理論をもとに実際にツール作って検証およびissueまで立ててしまうという熱意と技術力が本当にすごいなと感じました。

Deoptimization: How YJIT Speeds Up Ruby by Slowing Down（k0kubunさん）

speakerdeck.com

本セッションは以下の内容でした。

  • Ruby3.4ではYJITにdeoptimization機能が追加された。
    • これは最初は「最適化されたコード」で処理を進めるが、動的に予測外の動きがあった場合に「最適化前の遅いコード」に戻すものであり、一見パフォーマンスダウンに見えるが、「間違った最適化によるミス」よりもずっと効率的。
    • 具体的にはEscaped Localsの無効化、Singleton Classの無効化、Lazy Frame Pushなどの機能が追加されている。
  • このようにYJITはRubyの実行を部分的に「遅くする」ことで、全体として「速くする」という戦略を取っている。

YJITは最初は「最適化されたコード」で処理を進めるが、動的に予測外の動きがあった場合に「最適化前の遅いコード」に戻す処理になっており、Rubyの実行を部分的に「遅くする」ことで、全体として「速くする」という戦略を取っているという 聴講前はSlowing DownによってSpeeds Upさせるってどうゆうこと？と疑問でしたが、ちゃんと理解すると理にかなってるアプローチだと感じました。YJITにも個人的に非常にお世話になったので、今後のMaximeさんが発表されていたZJITにも非常に期待しています！k0kubunさんとは3日目のお昼休みに屋台の前で少しお話しすることができて、コミッターの方と身近な距離感で会話することができるのもRubyKaigiの良さなんだろうなと感じました！

Speeding up Class#new（Aaronさん）

こちらの内容は同僚の@tokiさんがセッションレポート書いてくれたので、そちらを参照くださいー！

tech.giftee.co.jp

API for docs（soutaroさん）

Rubyにおける静的型チェックツール「Steep」に、新たにエディタ統合型のドキュメント機能が追加されました。これにより、RBSに書いたコメントが、コード補完やホバー、シグネチャヘルプとしてリアルタイムに表示されるようになりました。 これまでのRubyでは、RDocやYARDといったツールを使ってHTMLなどに出力されたドキュメントを「読む」ことが主流でした。しかしこの機能では、開発中のエディタ上で即座に表示され、補完候補選びにも役立つという、まさに次世代的な体験が実現されています。

発表内容の詳細は以下のブログの方で書きました！こちらもぜひ！

tech.giftee.co.jp

オフィシャルパーティー

オフィシャルパーティーはday1に開催されました。 なんと松山城を仰ぎ見ることができる城山公園でどかーんと開催でした。

私はあまりお酒が飲めないので、みかんジュースをいただいたんですが、みかんジュースも4〜5種類があり味比べができてとても楽しかったです。 また、たくさんのRubyistの方とお話しすることができました！（igarashiさんとかとも話せたの嬉しかったです） 普段お世話になっているKashiwa.rbのメンバーも集まって写真を撮りました！

Drinkup

day2の夜は弊社（ギフティ）主催のDrinkupに参加してきました！写真がないのがとても残念ですが、色々な方と交流することができました！みなさま来てくださりありがとうございました！学生さんともコミュニケーションできたの嬉しい☺️

day3の夜はさくらインターネットさん主催のDrinkupに参加してきました！100名以上の方が参加したみたいで非常に盛り上がっていました。 ちょうどday3に発表しており私も聴講していたコミッターのAlan Wuさんがいらっしゃったので突撃していろいろ話をさせていただきました！ 特に「たとえcRubyに対してコントリビュートしようが、自作のgemにコントリビュートしようがそこにレベル差はほとんどなくて、大事なのはOSSにコントリビュートする姿勢だと思います(意訳)」という言葉をいただきまして、それが個人的にブッ刺さって身近なところから頑張っていこうと思いました！

その他

せっかくの松山ということでday3の夜に道後温泉にも行ってきました！（しっかり観光！） 温泉自体にも温泉情緒たっぷりの雰囲気にもとても癒されました！

湯上がり後のフルーツオレも最高でした・・・!!!!

まとめ

いやー、初めてのRuby Kaigi、最高でした。 色々なセッションを聴講したり、大勢のRubyistの方と交流することでめちゃめちゃたくさんの発見がありました！

悔しかったのちょこちょこセッションでの英語がわからずに内容を理解できなかったというのと、この振り返り記事を書くのが遅くなってしまったことですかね・・・ また来年も必ず参加したいと思うので英語力ももう少しアップできるといいなあ

読んでいただきありがとうございました！

shinjuku.rb初参加

はじめに

こんにちは。shiloです。

1/30にshinjuku.rbに初参加してきました！

今回のshinjuku.rbのテーマは個人開発発表 LT大会！ということで、各自の個人開発の内容を発表し合い、みんなで愛でようという趣旨でした。みんなで愛で合うというのがいいですね！

今回、発表してくださった方々の個人開発内容は全部紹介したいくらいどれも魅力的だったんですが、特に個人的に面白いなあと思ったいくつかをご紹介できればと思います。

Add-on を作って学ぶ Ruby LSP

speakerdeck.com

僕がkashiwa.rbで大変お世話になってるkozyさんが、これまた大変お世話になっているRuby LSPのadd-onを個人開発されているということで、もう感謝しかないLTでした。

開発されているのはRuby LSPにおけるRakeのAdd-onとのことで、Ruby LSPの概要やRuby LSPのAdd-onをどのように開発しているのかを説明いただきました。 個人的にこのAdd-on開発、LSPをよく使っているということもあり、とても気になっています。今後関わっていきたいなと思っていたので、今回そこら辺の話を聞くことができて、とてもためになりました。

リポジトリは以下になります。

t.co

政治資金データベース

political-money-db.com ブルーモ証券の小林さんのLTです。 政治資金問題が毎日のニュースを騒がせている中、個人開発でその資金を可視化するという内容でした。

LTの感想としては政治資金という社会課題ドリブンで開発されているのが本当にすごいなと感じました。私は身の回りの課題に対して課題ドリブンな開発をするのも難しさを感じてしまうので、今回このような政治資金の不透明さという社会課題に対して切り込んだ開発をされているのはとても勉強になりました。

また構成としてはRailsとDjangoを両方使われているとのことで、そこらへんもとてもユニークだなと思いました。 なぜそのような構成にされたのかというとても大切な部分を聞き逃してしまったのでまた今度お会いしたときに聞いてみたいなと思います。

pitboard

pitboard.dev yamataka22さんのLTです。発表いただいたpitboardはプロジェクト中起こりうる変更に対して柔軟に変更ができるプロジェクトタスク管理ツールとのことです。

現在開発中とのことで本番運用は今後とのことですが、デモやLPを見た限り個人開発レベルではなくもう商用のSaaSじゃんっていうレベルでした。 本業ではない時間を使って開発されているぽかったので、そこら辺の時間の使い方とかもすごく上手いんだろうな〜と聞いてて思いました。

またお会いする機会があればぜひそういった面も質問してみたいと思います。

終わりに

発表者の皆さん、発表ありがとうございました！

初めてのshinjuku.rbでしたが、楽しかったです。

私自身、以前から学習目的で作った個人のWebサービスを細々と運営しており、また新しい個人開発にチャレンジしようかなと考えていたところだったので、そういう意味でも今回の参加はすごく刺激になりました。

また参加ぜひ参加したいと思います！ IBJさん会場ありがとうございました！！

よもやま

新宿駅の西口が数年前と変わりすぎていてめちゃ迷いました・・・余計迷路になってる感。

Kashiwa.rb #7 に参加してきました

はじめに

こんにちは。

1/20（月）にパレット柏で開催されたKashiwa.rb#7に今月も参加してきました。 (kozyさんいつもありがとうございます！)

今月は「Ruby 3.4のリリースノート眺める & ソースコードリーディング」ということで、リリースノートやソースコードを画面共有しながらみんなで気になったところがあれば深掘りするという形の会でした。（リリースノートだけではなく、以下の記事が非常にわかりやすいということで、かなり参考にしました。）

product.st.inc

Ruby 3.4のリリースノート眺める & ソースコードリーディング会の感想

私自身、Ruby 3.4のリリースノートをしっかり読むのはこの時が初めてだったので、読み方を含め、みんなでコメントや深掘りしながら読み進めていくスタイルは非常に学びが多かったです。

特にitについて深掘りをした箇所は印象的でした。具体的にはRuby 3.4ではブロックパラメータにitが使用できるようになりますが、すでにitを変数として使用している場合は注意が必要であることが分かりました。ここはせっかくなので具体例を交えて見ていきます。

まず普通にブロックパラメータにitを使うと以下のようになります。

[1, 3].map{ it * 2 }
=> [2, 6]

このように非常に簡潔に書けます。

ただ例えば次のコード例のようにブロックパラメータだけではなく、ブロックの外でitを変数として使っている場合はすでに定義されているitが優先されるので、挙動が変わります。

it = 2
[1, 3].map{ it * 2 }
=> [4, 4]

私自身ブロックの記載を非常に簡単に書けるようになると思っていたので、このitをブロックパラメータとして使える変更は個人的に嬉しいものだったんですが、上記のように落とし穴もあるので気をつける必要があることが分かり、学びでした！（あまりitを変数として使うことはないような気もしますが・・・）

ちなみに上記の注意事項はリリースノートのitに関する記載部分を読みながら、別の参加者の方がitを変数としていた場合はどうなるんだろうねというコメントをされたことでみんなでモブプロしながら挙動を確認した中で判明した内容でした。このように必要に応じてみんなで挙動を確かめながら読み進めていくことで、上記のような細かな挙動の理解にも繋がることが実感できたのも大きかったです。

そのほかにも興味深そうな話題が多かったのですが、その場で理解が追いつかなかった部分が多かったので、そこは自分でリリースノートやソースコードを読んで今後キャッチアップしていきたいと思います。

懇親会

今回は私は不参加でした🙇

中華屋さん美味しそう

終わりに

今回のKashiwa.rbも非常に学びが多かったです。技術的な内容はもちろんなんですが、それ以外にもみんなでリリースノートやソースコードを読むというのは知識共有といった面で非常に効果があるんだなと実感しました。

今所属しているチームではなかなかモブプロとかできていないですが、今後は少し時間を取ってみて、みんなで同じソースコードを読んだり、モブプロをやってみるとかは試みとしてやっても良さそうだなと思いました。

また来月も参加したいと思います〜！読んでいただきありがとうございました！

SIerからWeb系事業会社に転職して半年近く経過したので、ここまでの学びをいくつか振り返る

はじめに

こんにちは。shiloです。 SIerからWeb系事業会社にエンジニアとして転職して半年くらいが経ちました。 年末も近くなってきたので、ここら辺で一回転職してからどのような学びがあったのか振り返ってみます。

簡単に前職のご紹介

  • 大手SIerで4年間、官公庁向け業務システムの開発に従事していました。
    • ロールとしては初め開発メンバーで最後の1年は単年度プロジェクト（20〜30名規模）のPjMを担当しました。
  • オンプレ環境だったので年間の半分くらいは現地への出張でした。
  • この時の技術スタックとしてはC#、Linux、SQL Serverあたりです。
  • 個人でDjangoを使ったWebアプリを公開したりして遊んでいました。
    • 前職も非常に楽しかったですが、Web系の事業会社に興味が出てきてしまい、2024/4に現在の会社にエンジニアとして転職をしました。

近況

  • toC向けのプロダクトの開発を主に担当しています。
    • 私自身幅広い分野に興味があったので、バックエンド中心ではありますが、フロントエンド、インフラも一部担当しています。
    • 設計や実装、テストだけではなく、最近は要件定義のフェーズにも関わったりしています。
  • 技術スタックとしてはRuby on Rails、Vue.js、AWS、MySQL、Dockerあたりが普段よく触っている技術です。前職に比べると幅広くモダンな技術に触れている印象です。

入社して半年の学び

SIerからWeb系事業会社に転職してみてどんな学びがあったのか業務に対する姿勢やマインド面中心の観点で振り返ってみようと思います。 とりあえず先に申し上げておくと、上記の通り環境が大きく変わったこともあり、学びがとても多いです。 ただそれが嫌というわけではなく、むしろ毎日が充実していてとても楽しいです。

そんな中で私は普段、日報を書いているのですが、その中でこれはマインド面の学びだったなあと思うことを一覧化して時々眺めて見返しています。 現状150行くらいになっているのですが、とてもそれらの全てを書くことはできないので、特に個人的に業務に対する姿勢やマインド面から学びだったなあと思うことを挙げていきます。

許可より謝罪

これは一番のマインドシフトかもしれないです。どこで初めて聞いたかわからないですが、初めて聞いた時からとてもしっくりきています。

前職では本当にとにかく絶対大丈夫というもの以外は社内やお客さんに対してとりあえず許可をとっていた気がしています。会社の上司や先輩もみんなそんな感じで仕事を進めていたので、それが当たり前だと思っていました。

それに対し、今は絶対にミスしちゃいけない時は確認するけど、それ以外の時はとりあえず自分の判断でやってみるという感じに自然となっている気がしてます（ダメならごめんなさい精神です）。

なんでこのような変化があったのかなと考えてみると、確認すること自体は間違いではないとは思うのですが、やはり自分や相手を含め時間をとってしまう上にそれだけスピードが遅くなるということにある時気づいたからです。 それよりもとりあえず多少の間違いは大丈夫だからどんどんやってみてバリューを出していこうという雰囲気が今の環境にはあるような気がしており、それが求められている気がします。 なりより個人的にも確認しているよりすぐに手を動かした方が単純に楽しいと思います。

この学びは普段の行動にも大きな影響を及ぼしていると思うので、今回挙げさせていただきました。

ちなみに調べてみると、けんすうさんが10年くらい前に記事になさっているのを発見したので、Web系の業界では割とスタンダードな考えなのかもしれません。

blog.livedoor.jp

振り返りをして共有すること

上記でも少し書きましたが、私は毎日日報を書くようにしています。 入社当初先輩に指示されて実施していましたが、やっていくうちに振り返りの効果を実感することができましたので、最近は自主的に続けています。 やり方としては大体20分くらいでその日をYWTで振り返り、それを自分の分報チャンネルに投稿するというのをやっています。

このような日報がどのような効果があったかというと、一言で言えば、「日々の気づきを学びに昇華できる効果」と「その学びと非常に親和性が高いフィードバックがもらえる可能性が高い効果」があったと思っています。

まず、「日々の気づきを学びに昇華できる効果」についてですが、一般的に人は仕事をしていく中で細かいものを含めれば莫大な数の気づきがあると思います。ただ、それって都度振り返らないと忘れちゃって、気づきがゼロとは言わないまでもゼロに近いところまで戻ってしまうということにある時気づきました。 せっかくの気づきをゼロに戻してしまうのはとてももったいないので、一日の最後にYWTで振り返ることを始めたところ、全ての気づきは無理でも重要な何個かの気づきを学びに昇華できることに気づきました。学びに昇華できれば、それは気づきに比べて忘れづらくなるというのも実感しています。

次に「その学びと非常に親和性が高いフィードバックがもらえる可能性が高い効果」についてですが、これはこのままの意味です。 得た学びを分報チャンネルに投稿することで読んでくれた他の人に対してその学びを贈ることができます。 また逆にその学びに対してより深い知見やフィードバックが返ってくることも多々あり、さらなる学びに繋げられることも大いにありました。 このような学びのサイクルのようなものは前職にもありましたが、前職よりも頻繁にサイクルが発生している気がしており、自分としてはとてもありがたいなと思っています。

はじめは若干学びを共有するのは緊張しますが、次第に慣れてきます。 日報おすすめです！

エンドユーザーの体験(使いやすさ)を1番に考えること

これも前職からのギャップに驚いた部分であり、とても学びになった部分です。

前職では主に業務システムを担当していたので、エンドユーザーは業務やシステムに精通しているオペレーターの方が中心でした。なのでエンドユーザーの体験ももちろん重要視はしていましたが、それより一つの画面でたくさんのことができる機能重視のシステムが求められていたと考えています。

対して現在担当しているプロダクトは toC向けのサービスのプロダクトであるため、機能よりもエンドユーザーの体験が1番優先順位が高いです。具体的には初めてこのサービスを使ったユーザーでも難なくサービスを利用した目的を達成できるかが開発においても1番重要視されています。

なので常にユーザーがこのサービスを使った際にどのように思うかというユーザー共感が開発の前提にあり、ここに関しては前職以上に間違いなく共感力というものが求められています。

私自身も機能の実装に目が入ってしまい、ユーザーの気持ちになりきれていなかったなと改めて感じることもまだまだ多々あります。今後もその辺りの優先順位を間違えないように開発をしていきたいなと思っています。

事業に関わる数字を知ること

私が現在担当しているプロダクトは一般ユーザーによる決済が含まれているので事業KPIの一つに流通量や流通額というものがあります。

私自身は前職の時もこのような事業KPIは時に意識をせずに仕事をしてきたので、転職直後は特に意識もしていませんでした。 ただ、ある時先輩がそれらの事業KPIについて説明をしてくれて、ここはこの案件が反映されたから流通量や流通額が伸びているんだど説明してくれた時がありました。 その時に、自分の業務の出来によって何万といったユーザーや何億といった規模の流通に影響を及ぼすことを初めて実感し、背筋が伸びるとともにとてもワクワクしという出来事がありました。 （前職では、あくまでも官公庁の業務システムが担当だったので、ユーザーは多くとも数百人程度だったのでユーザーの数では比べ物にならないです。）

それ以降は週に1回程度、KPIの数値をBIツールで確認するようになりました。 最近は、「この時取り組んだ〇〇はここで数字として現れていそう」など数字と事業全体に関する勘が少し鋭くなった気がします。 また、自分が関わった案件により流通量や流通額が増えた時は単純に嬉しいですし、下がってしまった時もその要因を分析するのも楽しかったりします。 モチベーションにもつながっているので、個人的にはこのように事業に関わる数字を意識しておくことも重要だなと学びました。

終わりに

若干雑になってしまいましたが、ここまで半年間の特に印象的な学びを振り返ってみました。　

SIerではSIerならではの学びもたくさんありましたが、現在の環境ではまた異なった学びもたくさんあり、とても楽しいです。

またどこかの断面で同じように学びを振り返ってみたいなと思います。 今回の記事が少しでもどなたかの役に立てば幸いです。

ここまで読んでいただきありがとうございました。