RubyKaigi 2026でikuraのLTをしました

RubyKaigi 2026でLTをしました、つじたと申します。普段は仕事でRailsを書いています。LTではRuby製のHotwireを作っていくらを追加するgemを作った話をしました。少し時間が経ってしまいましたが、せっかくなのでブログを書きます。

speakerdeck.com

モチベーション

私が初めてRubyKaigiに参加したのは2022年の津での開催の年でした。当時の私はフィヨルドブートキャンプを卒業したてで、エンジニアになって3ヶ月目でした。初めてRubyKaigiの参加者として聞いたトークは kateinoigakukunさんの Ruby meets WebAssembly で、なんかめちゃくちゃすごい人がめちゃくちゃすごいことをやってるっぽい!すごい!と思いました。

rubykaigi.org

全てのトーク内容が全くわからなかったですが、当時会社の先輩だったしおいさんがトークしているのは控えめに言ってもかっこよすぎて、私もいつかああなりたいと思いました。そのときの感情は今でも覚えています。

ただ、普段の業務をしているとわかるじゃないですか、初心者の自分の技術レベルはそんなところにはないし、自分の余暇時間は業務に関連する事を勉強したくなる。器用でも優秀でもない私は、RubyKaigiのCFPのネタになるような活動をする余裕も気力も持てず、時間が経つにつれて少しずつ『かっこいいけど自分には遠い世界だな』と思うようになりました。

翌年の松本は参加しましたが、去年より知ってるワードがほんの少し増えたな、という感想だった記憶。

その次の沖縄開催、私にとって3回目のRubyKaigiの頃には、自分が仕事でできることが増え、コミュニティの知り合いも少しずつ増えていて、Rubyに出会って自分は幸せだなと思うようになり、RubyKaigiにかかわらずではありますが、コミュニティにもらったものを私も返したいなと思う気持ちが出てきた時期でした。そんなわけで当時ヘルパーに応募するか少しだけ悩みましたが、なんとなく自分がヘルパーをしている姿を想像してもしっくりこなかったので応募はせず。

コミュニティに何かを返したい気持ちはあっても、誰に何を返せたらベストなのかがわかりませんでした。ただ、私が初めてのRubyKaigiでスピーカーからもらった『すごい!私もいつかこうなりたい!』という憧れや純粋なわくわく、そしてここから頑張ろうの気持ちを、私も他の誰かに渡すことができたなら、それが自分としては一番理想的だしかっこいいなと思いました。

そこで少しだけ登壇を意識した学習を始めました。 ただ、当時の私は自分の興味よりも『これをやったらウケるんじゃないか』を軸に行動をしてしまい、結果何も生み出せないループにハマりました。RubyKaigi 2025のLTにも何か出したかったのですが前述の理由で何も出せず。

その悩みを去年のRubyKaigi 2025のオフィシャルパーティで大先輩に話してみたところ、『ウケるウケないではなく、つじたさんの好きなことをすると道が開けると思いますよ』と言っていただいたので、去年の会期中は 私は何に興味があるのかな と考えながらトークを聞きました。 結果、突然Rubyのコアに興味を持つことはできなかったのですが、『今は目の前の仕事を頑張って、そこで何か見つかったらラッキーかな』と思えたので、去年はとにかく仕事を頑張りました。実際に成果が出ましたし(社内で表彰していただきました)、登壇しなくても会社で活躍できる人材になれたならそれでいいのかも、と思うようになりました。それと同時に、エンジニアで居続けて、コミュニティに細々と参加し続けることも一つの貢献なのかな、と。

そんな調子で過ごしていたのでRubyKaigi 2026のLTに何か出すつもりはありませんでしたが、登壇への第一歩はCFPの記念受験だと思っているので、せっかくのチャンスだしと考えて今の自分のやりたいことを色々考えました。その結果、自分が初めてRubyKaigi参加者として聞いたキーノートで取り上げられていた ruby.wasm を使ってみたい気持ち、またそれを使えば自分の好きなHotwireをRubyだけで実装できるのでは?と思うに至りました。

そこからどういくらになったの…?というと

gemの題材を考えていた時にClaudeから『TurboとRubyで turby はどう?』などと提案されていたわけですが、ちょうどその時近所のスタバでいちごのフラペチーノを飲んでいて、 『turby なんて全然かわいくない、もういっそichigoとかにしたい。赤いし。あれっ赤い…?Rubyも…赤いね??でも函館要素あったらおもしろいけど、いちごは違うね…… いくら?!』みたいな感じで思いつきました。

ちなみにClaudeに『gemの名前、ikuraはどうかな?』と聞いたら、『Rubyと函館の要素が入ってて良いと思うけど、初めてのRubyKaigiのLTでウケ狙いすぎてスベったら悲しいから正統派なturby がいいよ』という旨を出力されました。が、 そんなの知らん私のやりたいことをやります と思ってikuraにしました。結果的に本番でちゃんと笑っていただけたので、今回の命名に関しては人間の私とRubyコミュニティのあたたかさがOpus4.6に勝ちました。 ちなみにこのCFPを提出したときは自分の中での最高傑作ではありましたが、まさか通るとはつゆにも思わず、せめて審査員の方が少しでも笑ってくれたらいいな…と思っていました。

話しきれなかった部分

個人的な見所としては、Turbo Streamはidで指定された特定の場所にHTML要素を表示すると言う技術なので、今回私が実装したような、CSSで指定した親要素を基準にランダムな場所に子要素を表示する、というのはなかなかトリッキーなアイデアだったのではと思っています。 実際のプロダクトでのユースケースは思いつかないですが、HotwireはCSSに詳しくなると使い道がもっと増えそうでまだまだ可能性があるんじゃないかと改めて思いました。(と言いつつ、CSSに色々と託しすぎるのはどうなんだろうか。あとHotwireはシンプルに作れる可能性に溢れているところが好きなんですが、なんでもHotwireで作ろうみたいな欲望はないです。適材適所ですよね)

一番の反省点はruby.wasmをうまく使えなかったところです。 理想はDOM操作をRubyぽく書くところまで頑張りたかったのですが、これだ!と思う実装に辿り着けず、ruby.wasmの無駄遣いになってしまいました。Rubyで require ‘js’ できるのはすごいことだなと思いましたし、「ほぼRubyで書けた」は事実ではありましたが、もっとRubyのよさを活かしたかったですし、何よりJSに魂を売った感がすごかったです。『技術を使ってみた』と『使いこなせる』の差を実感した出来事でした、次に生かします。

準備から当日について

CFPを書くところも、実装する部分も、LTが通ってからも、今の私にやれることは全部やれたと思います。

スライドは文言のチェックはLLMを使いましたが、構成については何から何まで全て自分で作りました。せっかく私が5分話す時間をいただいたので120%私の世界観でいきたいなと思い。もう少しLLMのうまい使い方もあったのではと思いますが、悔いはないです。

当日の時間配分については5分を使い切りたかったので、かなり攻めの姿勢でいきました。特にデモに関しては、残り15秒あればデモができて尚且つ間延びしない丁度良いタイミングで銅鑼を鳴らしていただけると想定していたので、その通りにトークできてよかったです。 最初から早口で話すと気持ちが焦りそうだったので導入は自分のペースでいくと決め、終盤は時間調整のために駆け足でも仕方ないと割り切りました。余裕のない感じの攻めたLTができていたなら嬉しいです。

色々書きましたが、もうトーク中の5分間ずっと楽しかったです!CFPを考え始めて、通ってからスライドを作り、当日トークした全ての時間、一分一秒が本当に幸せでした。

最後に

一つ自慢してもいいでしょうか。ずっと背中を見てきた憧れのしおいさんに「同じ場所に立って登壇しましたね」と言っていただいたのが嬉しすぎて、初めて参加したRubyKaigi 2022から、エンジニアとしてここまで一歩ずつ歩いてきてよかった…と思いました。同じTシャツが着たいですとお伝えしたので、また頑張ろうと思います。何年で着れるかな。

そして、毎年RubyKaigiに連れてきてくださる会社の上司と、いつも一緒に走り続けてくれる会社の同僚に感謝を伝えたいです。普段はあまり気持ちが揺れない自分でもLT直前はびっくりするくらい気が気じゃなかったのですが、会社のメンバーの顔を見たら『きっとなんとかなるな』と心から思えて、ここで働いていてよかったと思いました。今年もちゃんと仕事で成果を出して返します。

Kaigi on Rails 2024に Hotwire or React? というタイトルで登壇しました

何から話そう、何から書こう、と悩みますが、まずは昨年のことから書こうかなと思います。ちなみに今回Hotwireの技術的な話は出てきません。

去年のこと〜プロポーザル提出まで

昨年のKaigi on Rails 2023には一般参加者として参加しました。というのも、初めて提出したプロポーザルを通せなかったからです。

当時は何度か地域rbなどでLTをしたことはあるものの、多数の応募から選ばれて登壇するという経験はなく、ドキドキしながら提出したプロポーザルは、あえなく not accepted となりました。 普通に悲しかったし悔しかったです。

プロポーザルが通らなかったイベントに参加するというのも初めての経験だったので、昨年の会期中は『良いトークだったな(私はこのトークのプロポーザルよりおもしろい内容を書けなかったんだな)』という気持ちでいました。 なのでKaigi on Rails 2023が終わるとき、来年は絶対にプロポーザルを通す、と心に決めていました。

我ながら強く決心していたので、自分が目標から逃げられないように会社の先輩や友人を含めた色んな方にそう宣言しつつ、常にテーマを探す日々を送りました。 なんでもやろうという気持ちでいたので、過去のトークはほぼ全部見て傾向を分析しましたし、何を話すと面白いかなあと日々考える反面、 仕事ではReactを書くことが比較的多かったこともあり、Rails関連の『これだ!』と思えるテーマになかなか出会えませんでした。

しかし、あるときHotwireを使う機会に恵まれました。「書いていて楽しいし、自分の中でHotwireはかなり好きかも」と率直に思ったのが、Hotwireを題材に決めた理由でした。

とはいえ、最初は今回話したトークとはかなり違う角度の話をしようとしていました。社内でプロポーザルを何度もレビューしていただく中で『HotwireとReactを使う損益分岐点はどこか?という内容を含めてみたら』と提案していただき、それが今回のトークの柱となりました。完全にレビューありきの案だったので、私1人ではきっと今年もプロポーザルを通せていなかったと思います…。

紆余曲折がありプロポーザルが完成しましたが、トーク中に話したように、7月末のプロポーザル提出段階の結論は “Stimulusはあんまり便利じゃないから、私のチームはReactでいくよ”でした。 『プロポーザルを通すためにはこの結論はぼかして書いたほうが審査員のウケがいいんじゃないか』とそれはそれは悩んだのですが、誤魔化した内容や嘘を書くのはフェアじゃないですし、そんなことはしたくないので、当時チームで出した結論を全てありのまま書きました。

自分の中では最善を尽くしたものの、結論が絶妙にイケてないプロポーザルを提出し、かつ最終提出数193の数字を見て、フィードバックをたくさんくださった上司には申し訳なさを感じつつ、これは絶対に落ちたなと思いました。

プロポーザルが通った

前述の通りの心境だったので、今年も落選のメールが来るんだろうなと心の準備を済ませていました。

確か8月下旬に差し掛かった頃に結果のメールをいただいたと記憶しています。私と同じフィヨルドブートキャンプの卒業生であり友人のやなぎさんがacceptedされたツイート(今はポストと言うのでしょうか)をしていたのをきっかけに私もメールを確認したところ、なんだか昨年の落選時とは様子の違う文面が見え、「えっまさか?」と思いつつ、メールのタイトル "Your proposal for Kaigi on Rails 2024 has been accepted" の一文に "not"が入っていないか30回くらい確認しました。

本当に信じられなかったですが本当に嬉しかったです。そしてプレッシャーがすごかったです。

そして、前述の微妙な結論 "うちはReactでいくよ" をプロポーザルに書いたものの、 『Railsのカンファレンスでそれはないじゃないか』 の一心で、ありとあらゆる情報に触れてHotwireを触りまくりました。そうして今回の結論に辿り着きましたが、その道中は気が気じゃなかったです。

結果としてハッピーエンドを迎えたストーリーとして認知していただきましたが、悩んでいる最中は、 『仮に導入に失敗した結末のトークをしても、光の道を歩む大場さんの素晴らしいトークと対比していただけそうだし、それはそれでありかも😭』(いや、全然本心じゃないけど)と自分をなだめたりもしていました。

もし次もプロポーザルを出すのなら、こういう危ない橋はもう渡りたくないな…と心から思います。

資料準備について

プロポーザルを提出しているのでトークの大枠は決まっていましたが、難易度は "卒業間際のフィヨルドブートキャンプ生が理解できるのでは…!" というレベルを目指しました。(私は卒業生です)

理由はいくつかあるのですが、昨年Kaigi on Railsに参加した際、フィヨルドブートキャンプの受講生に『参加してみてどうですか?』と聞くと『ちょっと内容が難しいです』という声をちらほらと聞きました。 毎年参加してトークに対する理解度が上がっていくのも成長の指標のひとつだと思っているので、わからない・難しい、という気持ちを否定するつもりは1ミリもありません(私もそうだったので!)しかし、初学者の参加がわかっているカンファレンスなので、数あるトークの中で1つくらいは「これは理解できた(気がする)!」と思えるトークがあったらいいな、そして私のトークがそうなれたら良いな、と考えていたのが理由としては大きかったです。

また、別軸ではReactを含む他のフロントエンドフレームワークを扱う方々へのリスペクトが伝わるトークにしたいと考えていました。 個人としてはHotwireを推していきたい気持ちはもちろんありましたが、Reactも素晴らしい技術だと思っています。 両者を比較して『こっちは良くてこっちはダメ』という話をする気は全くなかったので、インパクト重視でやや強めなタイトルをつけてしまったことに後悔しつつ、誰も不快になってほしくないという一心でHotwireとReactの比較についてのスライドを作り上げました。

登壇後はさまざまな方から感想をいただけて、誰かにとっての意味ある15分にできたのかなと思えて心の底から安心しました。 また、スライド公開後にフロントエンド界隈の方々からも反響をいただけたのが率直に嬉しかったです。

後日ブログなどでトークの感想を書いてくださった方には、にこにこしながらいいねしてます^^

登壇してみて

登壇をしたらすごく自分に自信がついたりするのかなあ、とぼんやり期待していたのですが、登壇前に思い描いていたものとは全く違う心境でいます。

いま振り返るとトークに対しての反省点はありますが、今回の登壇にあたって全力どころか120%くらいの力を使って準備をしました。 それでもまだまだ全然手が届かない大御所の先輩方の存在を、これまでとは違う形で実感できたことが一番の収穫だと思っています。 妙な自信をつけている場合ではないし、また一年、一歩ずつ歩いていこうと思えました。

会期中、ここには書いていない嬉しかったことが数えきれないくらいあるのですが、ひっそりと心にしまっておいて、いつか自分が挫けそうになった時の支えにしようと思います。

Rails Girls Tokyo 16thでコーチとして参加しました

3月1日、2日で行われたRails Girls Tokyo 16thでコーチとして参加してきました。 良い!が詰まりすぎているイベントだったので、記録に残そうと思います。 初めてコーチをしてみたい方の参考にもなったら嬉しいです。

参加したいと思ったきっかけ

私はフィヨルドブートキャンプの卒業生です。エンジニアを目指して学習しているときから Rails Girlsという単語は聞いたことはあったものの、どういうイベント?団体?なのかはよく知らない状態で卒業を迎えました。 そしてエンジニアになってからRails Gilrsにようやく興味を持った私は、2022年のRails Girls Gathering JapanでLTをさせていただきました。

その後2024年4月にTokyo 15thの参加者募集があり、普段仕事でお世話になっている方から「コーチに応募してみたらどう?」と背中を押していただいたことがありました。しかし、その時点では入社1年も経っておらず、誰かに教えるというのはまだ心許ないな・・と思い、応募するには至りませんでした。 ただ、自分の中でコーチ業というものに興味は持ったらしく、その後各地でRails Girlsが開催されているのを眺めては、少しずつ「チャンスがあればコーチをしてみたいな」と思うようになりました。

そしてTokyoで開催される情報を得た私は、かなりの気合を入れた意気込み文と共に、Doorkeeperでコーチ募集の申し込みのボタンを震える指で押しました。

後日コーチに選ばれましたのメールが来たときは本当に嬉しかったです。

ワークショップに向けて準備したこと

まず、素振りと呼ばれるコーチだけで当日の流れや内容についてミーティングをする日があります。そこで大まかに当日のことを教えていただけます。

また、Rails GirlsのワークショップではこちらのRails Girlsガイドを使います。

railsgirls.jp

ガイド中の"Help from the coach" の内容についても素振りの中で話をするので、コーチの大先輩たちがガールズさんたちにどう教えるのかも参考にすることができます。

私は素振りだけだと不安だったので、当日までにガイドを一通り見て自分でも手を動かしてみました。 ワークショップでは難しいことはしませんが、"Help from the coach" の内容は、初見だとどう教えたらいいの・・?!と言語化するのが難しい箇所もあったので、目を通しておきました。 当日の自分の安心感につながったので準備してよかったです。

当日の感想

いろんな思いがあるのですが、本当に参加してよかった!の一言でした。

ガールズとコーチがマンツーマンでアプリのデプロイまで一緒に完走するのが最高すぎました。本当に空気感があたたかいイベントでした。

私がコーチをさせていただいたガールズさんは、偶然にも未経験からエンジニア転職したい方でした。 Progateでお手軽写経プログラミングをしてからプログラミングスクールにステップアップ…と、自分と同じような道を歩んでいて、話に花が咲いたのもほんとうに楽しかったです🌸

会社では私に後輩という存在がいないので、お仕事で誰かに教えるという経験をしたことがありません。 どのように教えたらプログラミングが楽しいことや、すごくおもしろいことが伝わるのかな〜と、当日までの準備段階ですごく考えました。 そこで、自分がRails(というか技術)とどう向き合ってきたかを振り返りました。

完全な初心者だった私がRailsとの距離を縮めてこれたのは、コンソールであれこれコードを試し、ひたすらログを読んで、エラーを読んで・・の日々を諦めずに過ごしたおかげなんじゃないかなと思いました。 ワークショップで作ったアプリについての知識をその1日だけで完全に理解してもらうことは、(どんなにコーチが教え上手だとしても)難しいと思います。 なので完璧を目指すというよりは、私にとって新しい学びと発見の連続だった日々の一部を、ガールズさんがワークショップの中で体験できるようにサポートできたらいいなと思って当日に臨みました。

実際ガールズさんにとってどんな1日になったのかはわからないのですが、楽しかった、と思ってもらえていたらすごくすごく嬉しいです。

また、同じグループの方々と色んなお話ができたり、環境構築周りでつまづいたときに同じグループのコーチに助けてもらったり・・と自分自身にもすごく刺激がありました。 そして、また絶対にコーチとして参加したいです。もっと成長しなければ、と思わせてくれたイベントでした。

オーガナイザーのえんじぇるさんとまいむさん、素敵なイベントをありがとうございました🍒💎

2022年末に思うこと

色んな方の2022年の振り返りを読んでいて自分の中で気づきあったので簡単に記録。

自分で言うのもアレですが、私は小さい頃から優等生タイプでした。 成績も良かったし、先生の言うこともよく聞いている良い子タイプ。

それが関係しているかはわかりませんが、基本的に敷かれたレールの中で「これができたら優秀だ」みたいなものに惹かれがちでした。

中学の時は「この高校に行ったらすごい」、とか、高校のときは「国公立大学に入ったらすごい」とか。

大学でも紆余曲折したものの、数年看護師したら大学院に戻って勉強したいと思っていたし、そういう「上を目指す」夢を持っている自分はすごいんだ!みたいな気持ちがありました。

でも、社会人になって自分で生きていくうちに、「今までやりたいと思っていたことは、本当に自分がやりたかったのか?」と思うようになりました。

本当に自分がやりたいこと、というよりは、目指したいと思う先がないためになんとなく「これがすごいなら、これにするか」みたいな気持ちを抱いていたのでは?と。

そして、自分のレールの外で本当にやってみたいことはなんだろうと考えた結果、密かにやってみたいと思っていたものづくりに挑戦してみようと思い、こうしてエンジニアになったわけですが、

私はエンジニアになった今、また、同じような思考を辿っていたなと気づきました。

自分の中で(というかこの界隈の中で)こういう人がすごいと言われがち、みたいなポジションってあると思うんですが、やっぱり無意識のうちに憧れを持っていたような気がします。(いや、悪いことじゃないんだけど)

しかし、それを達成するためにする勉強や行動は、自分が今本当にやりたいことや興味関心に直結するわけではなく・・

私はなんのために頑張るんだっけ?と最近考えていたのですが、色んな方の振り返りを読ませてもらって、それぞれの道があっていいんだよな、と今日ふと思えました。

上司にも同じような話をしたのですが、そのときに「僕は雑食をやっていくぞ、と気合を入れて色々やってます」と仰っていたのが忘れられず、私も、無理に自分を型に嵌めすぎずにやっていこうと思います。

2022年は大変良い年になりました。2023年もおもしろいことがたくさんあるといいな。

また一年、どうぞよろしくお願いします。

自作サービス、ボツにしたサービス案たちをご紹介

こんにちは、つじたです。 フィヨルドブートキャンプ卒業生です。 現役生時代は napple29 とか はるな とかを名乗っていました。

これは フィヨルドブートキャンプ Part 1 Advent Calendar 2022 - Adventar の8日目の記事です。 昨日はmoegiさんの フィヨルドブートキャンプに3か月参加してみた感想 - DIVKA でした。

今日の話

私は今年9月に子どものワクチンの予定を自動で計算するサービス、ワクチンプランを作ってリリースしました。

しかし、Railsラクティスくらいから自作サービス案を考えていたので、人知れずボツにしたサービス案が大量にあります。

今日はその案たちとボツにした理由を書いていこうと思います。

階段、エスカレーターの近くなどお気に入りの電車の降車口を登録できるサービス

  • 鉄道会社のサイトに階段やエレベーターの近くという情報が載っていて苦労して作る必要性を感じなかった

  • 現在工事中だが数ヶ月後や数年後に階段などの位置が変わる、ということに対応できる気がしなかった

  • 電車に乗るたびにわざわざサービスを開いて登録するか?と自問自答した結果、私にはいらないなと思った

友達、家族、恋人にほしい物をリサーチできるサービス

自分の中では良いかも!と思っていたが、 夫に、こういうサービスがあったら使う?と聞いたら

「ワクワク感って知ってる?」

と言われボツになった。

フィヨルドラクティスで、良かった勉強法を登録していけるサービス

  • 書籍やWebサイトなどが登録できたり、そこに各々受講生が役に立ったよマークとかつけられたりするものを想定

  • しかし、フィヨルド自体が、外部のサイトやサービスに関する質問には答えられない、という姿勢であることをどこかで見た

  • サービスの治安を守れる自信もない

  • わざわざサービスにしなくてもDocsなどで管理できる、その方が何倍も安全

  • だが、そういうものがない時点でフィヨルドの思想に反すると思い、ボツ

可愛いターミナル特集

  • お気に入りのターミナルデザインを保存しておいて、いつでも切り替えられるサービス

  • そんな頻繁にターミナルのデザインを変えたいわけじゃないな・・と思い、ボツ

買い出しが楽になるようなサービス

  • よく買う食料品、日用品の名前やブランド名を登録しておいて、そこから選択するだけで買い物リストが簡単に出来上がるサービス

  • 買い出し系はアプリがたくさんあったので既存のものを使ってみた後で、欲しい機能を探して実装するでもいいな、と思った

  • が、、1回使ったきりそのアプリを使わなくなったので、結局私にはメモ帳に欲しいものを書き出す方式で事足りている事に気づき、ボツ

ディズニーでアトラクションに乗る順番を自動で決めてくれるサービス

  • このサービスの提案のせいで、ユーザーが乗りたいアトラクションに乗れなかったときに責任が取れないと思った

  • 私自身はディズニーは気ままにまわりたい派だった・・と思い出し、ボツ

欲しいコスメを金額やカラー、容量などいろいろな点で比較してくれるサービス

  • 具体的にこれが実現されて何が嬉しいのか見出せなくなった

  • 雑誌で十分、そしてボツ

最後に

いかがでしたでしょうか💡

Railsのプラクティスをやると、どんなサービスが作れるようになるのか少しイメージが湧くと思うので、時間のある時にサービスの案を少しずつ考えておくのをおすすめしたいです☺️たくさんの案の中から見つけ出した自分のサービスを、私は結構気に入っています。

また、いろんなサービス案を考えることで、自分がどんなことをしたいか、どんなことに興味関心があるのか、ということについて考えるきっかけにもなりました。

明日は goruchan さんです🎉

子どもの予防接種の予定を自動計算するサービスを作りました

自己紹介

はるなと言います🐰🍤 2021年4月から2022年5月までフィヨルドブートキャンプを受講していました。 現在は株式会社キャタルでエンジニアとして働いています。

前職は保育園の看護師をしていました。 好きなRubyのメソッドはobject_idです。

アプリについて

www.vaccination-plan.com

お子さんの予防接種の予定を自動で計算するサービスを作りました。

できること

お子さんのお誕生日と接種履歴から予防接種の予定日を自動で割り出します。

予防接種の規定は国立感染症研究所厚生労働省などで定義されていますが、 今回は小児科学会が推奨している規定日数を使っています。

https://www.jpeds.or.jp/uploads/files/vaccine_schedule.pdf

技術スタック

作った経緯

自己紹介にも書いたように、私は保育園で看護師をしていました。 そんな仕事があるの…?とたまに言われますが、わかりやすくお伝えすると 【学校の保健室の先生】と【0歳児クラス👶🏻の担任】を6:4くらいの割合で請け負っていました。

そんなお仕事から、エンジニアになりたい、とジョブチェンジを決心した理由はいくつかありますが その中の一つに、 『世のお父さん・お母さん、そして子育てに関わる人の孤独感や負担感をもっと減らしたい』 という理由がありました。

少し話は逸れてしまいますが、 私は20代前半で保育園看護師の仕事を始めました。 出産も子育ても経験したことがなく、看護師という資格は持っていたものの、正直最初は赤ちゃんを抱っこすることでさえ怖かったです。 それに加えて、不慣れな私が子どもを寝かしつけようとしても寝ない・食事の介助に入ってもうまいこと食べてもらえない…と、入職して最初の数ヶ月はまるで新米お母さんのような日々を過ごしました。

それでも楽しく仕事ができ、子どもたちを心から大切に思い可愛がれたのは、ベテランの先生たちのお手本があり、困ったときにはいろんなことを教えてもらい、子どもたちの話を他の先生や保護者と共有できたおかげだと思っています。

私は、様々な家庭の子育ての一部を担い、その楽しさや素晴らしさを実感してきましたが、 近くで見てきたぶん、現代の子育てを取り巻く環境は決して良いとは思えず、特に保護者にその皺寄せが来ている実情を多く見てきました。

話そうと思えばキリがありませんが、関係のありそうな話で言えば、保育園の財源の少なさや新しい情報が入ってきづらいことによる全体的なレガシー感、そしてIT化の遅れが、塵も積もれば山となる状態で保護者への負担を慢性的に強いていることが、一つの理由だと思っています。

まだまだ、連絡は電話が当たり前、連絡帳は紙のノート、提出物も紙、もう全部紙、今すぐに利用したいであろう一時保育は電話をしてから一度来園して面接してからまた電話で予約(そして大体直近1ヶ月は予約が取れない)、、、など、正直思い返すと引いてしまうような現状です。

子育てが大変な乳幼児期に、一番もっと楽になったらいいのに、楽であるべきなのに、という部分が なぜか時代2つ分くらい昔のままで全く進んでいないのは、正直大問題です。

ただ、働いているときは何をしたらそれが改善されるのかわからなかった。

せいぜい職位のある先生を巻き込み、園長に提案をしては「それはちょっとねえ…」とゴニョゴニョ言われるのが関の山で、あとはもう無法地帯のExcelの整備をするくらいしかできませんでした。下っ端でいるうちに何かが変わるとは、到底思えなかったです。そして、ずっと働き続けていると、初めは「本当におかしい!」と思っていたことが「これが普通、これが保育園のスタンダード」と慣れてしまっている自分に気づいてしまいました。

仕事は楽しいのに、でも環境は許せないのに、慣れてしまうし、そんな自分に腹が立つ。悩みながら紆余曲折し、色んなきっかけをもとにたどり着いた答えは、自分がものを作る側になってみたら見える世界が変わるかもしれない、ということでした。

どんな形であれ、いつかこの実情を変える一端を担えたらどんなに良いか。 保育に直接関われずとも、どこか子育てや子どもの成長に関わる部分をもっと便利にできないか。 そんな大きすぎる夢を持って飛び込んだFBCで、ターミナルの「タ」の字も、GitHubの「ギ」の字も知らない頃から、 自作サービスは絶対に子育て関係にしたい!と決めていました。

FBCRuby on Railsを勉強し出した頃から案を少しずつ考えていて、最初はあの有名な「みてね」のようなお子さんに関する記録を共有したり振り返ることができるようなサービスがいいなと思っていたのですが、

自分のしていた業務を振り返り、さらにお世話になった保護者の皆様を思い出しながらあれこれ考えてみると

子どもたちの予防接種の接種状況をチェックする仕事が大変だったな、、 複雑な規定のもとに前回の接種日から次の予定を考えるのめんどうだったな、、 「これ打ち終わってますか?」と確認すると、仕事が忙しくてうっかり忘れてました!みたいな保護者も少なくなかったな、、、🤔

なんていったって、子どもの予防接種、複雑なんです。量も多いし規程も複雑です。これが私が知っている中で一番わかりやすいスケジュールの資料なんですが、知識がなかったら解読困難だと思います。

この中の、ワクチン名の右に書いてある【定期】は必須で打つべきワクチンです。それぞれ打ち始めるべき日や接種間隔日数が違います。 働き始めた頃は、看護師の私ですら、それまでの仕事では取り扱っていない分野だったので 「名前は聞いたことあるけど接種間隔や推奨年齢はわからない」、という状況でした。

今はかなり覚えてしまっていますが、前回接種から28日空けるとか、21日空けるとか、結構計算するのめんどうですよね。

そこを解消できたら、、と考え、今回このサービスを制作するに至りました。

開発中に苦労したこと

仕様の検討

FBCに入会した頃は自作サービスを作っている自分なんて想像がつかない、が本音でした。 ただ、それは単に機能を作るための莫大なコードを自分が書けるのか?という心配だったと思います。

サービス作りを終えたいま一番難しかったと思うのは、何よりペーパープロトタイプとして 最初の段階で仕様を決定することでした。

「この機能はつけるのか?つけないのか?」 「どういう人に使って欲しいか?」 など、想像以上に考えることばかりで、ものづくりの難しさや大変さを実感しました。

また、最初は何もわからなかったので、すでに存在する子育て関連のアプリを参考にしていました。 しかし、気づくと機能やUIがどんどんそちらに寄ってしまい、 「自分の作りたいものってなんだっけ」と方向性がわからなくなってしまった時もありました。

そんな時、すでに自作サービスを終えた他の受講生から 「私は、‘絶対にこれは作らない’という機能を決めて取り組みました」と教えてもらい、 自分自身のサービスへの自信のなさから、不要な機能をつけ過ぎようとしていることに気づきました。

未経験者の自作サービスではありますが、ペルソナを自分の中でかなり細かく設定し、 あったら一見良さそうに見えていた機能(今回でいうと記録に関する機能)は最大限切り落とすことにしました。

最初にこの思考の過程があったからこそ、その後の開発では大きな迷いがなく進めることができたと思います。

既存のデータを扱うことの怖さ

予防接種の予定を割り出すサービスなので、元データを整理し、計算処理で活用できるようにまとめる必要がありました。 「ここで間違えてはいけない、、」と強迫観念に囚われ、大変というよりはデータ整理の時間が一番辛かったです。

すでにあるデータをもとにアプリを作ることの責任の大きさを知りましたし、大袈裟にいえば人の命に関わる数字を取り扱ったことで、 学生時代から当たり前のように使っていた電子カルテや数々の医療機器メーカーへの感謝と尊敬の気持ちが止みません。

デザインやフロントエンドが大切すぎること

私は、どちらかというとCSSやデザイン、そしてざっくりといえばフロントエンドが苦手でした。 Rubyが大好きだし、Ruby on Railsを書いている時間が一番楽しいし、フロントエンドを頑張る意味ってなんだろう?などと考えていましたが、ユーザー体験の価値を上げるにはフロントエンドを頑張らないと始まらないということを自作サービスを作る過程で実感しました。

なんとなくアプリが重い・遅い・色が微妙・欲しいボタンやリンクがどこにあるかわからない、など そういったUIにはストレスが溜まり、サービスからユーザーが離れてしまうんだなと感じましたし、 逆に、色やデザイン、ボタンのクリック動作など、今まで使ってきた素敵だなと思うサービスには UIやデザインの細部に気づかないうちに心を動かされてきたことに気づきました。

仕事ではフロントエンドも頑張って、Rubyと同じくらい好きと言えるようになりたいです。

最後に

約1年前、一人でRubyを勉強している時にはputsとifしか理解できなかった私が、 こうして世の中にサービスをリリースさせてしまうなんて、FBCって良い意味でめちゃくちゃ狂っていると思います。

自作サービスと向き合うにあたって、 日々私の弱音に付き合ってくれた輪読会でご縁があった友人たち、 分報に反応してくれた皆さま、 落ち込んだ日報を提出するとコメントで励ましてくれたメンターの皆さま、 レビューをしてくださったmaedanaさん、赤塚さん、 就職相談で優しく応援してくれた東郷さん、 いつも暖かく見守りアドバイスをくださった駒形さん、町田さん 本当にありがとうございました。この場を借りて、感謝を申し上げます。

エンジニアになって2ヶ月強たったよ!

8月で、入社して2ヶ月でした。 エンジニアになった自分が何を考えているのか、気持ちの変遷を見返したくて毎月書こうと思ってたのに、気づいたら8月が終わろうとしています…

先月の「1ヶ月にたったよ」ブログを読んだら、「こんな気持ちだったのか〜」とか、「入社できて嬉しかったんだね私」、とか色々思い出しました。それと同時に、その当時は頭の中心にあったようなことも1ヶ月くらいですぐ忘れることに気づいたし、今の気持ちを残しておきたいなと強く思いました。先月より力の入ってない記事になってしまうけど、それでも書こう。

苦手なことが浮き彫りになった

2ヶ月目は、達成できないタスクと遭遇したり、問題解決へのアプローチ方法を見つけるのに時間がかかったり、思いつきで行動して結果的に意味のない作業をしていたりと、苦い経験が多かった気がします。そして、自分のやりたかったことが実は苦手なことかも…と気づいたり、とにかく力のなさを実感しました。

私はずっと、「エンジニアになったら、ユーザーが本当に求めている機能を作りたい!」とか言っているタイプの人だったんです。それはもう本当に本気で、「プロダクトの先にいるユーザーのために、役に立つことがしたい!」と思っていました。(いや、今もそう思ってるけど)

でも、そういう意味のある仕様を作るためには、ユーザーに対して想像力を働かせたり、体験の良し悪しを吟味したり、「この仕様、こうなったら便利かも!それともこっちかな?それとも…」ということを無限にあれこれ考える必要があって、それって単純に時間がかかるじゃないですか。しかも、もちろん考えたことが全て形になるわけではなく、「考えたけど、何も生み出さなかった時間」が生まれるじゃないですか。

2ヶ月強働いてみて、どうやら私は何も生み出していない時間を過ごすことに対して、異常な恐怖心を覚えてしまうことに気づきました。 「ユーザーのために仕様を考えたり、プロダクトに貢献したい!」と思って会社に入ったのに、「この仕様について考えても無駄になるかもしれない」とか、「やってみたけど実現しないかもしれない」とか、『かけた時間に見合った結果が出ないかもしれない、不確実な時間を過ごす』ことがとても苦手なのです。

それは確実に、大学の頃から受けてきた看護教育、ないしは看護師をしていたせいだと思っていて。 特に病院で働いていた時は、常に患者さんの容体とオペの流れで優先順位を考えて、自分の行動の十手以上先まで読んで、動きの導線まで考えないといけない世界にいました。

例でいうと、目的地に行くついでに物品庫を通るから、そこで次のオペで使う道具も持ってきておこう、そのついでに隣の部屋の先輩ナースに声をかけてオペの終了時間を聞いておいて、その後でこれをして、ついでにあれをして、そのついでにあの人に声をかけて、、、みたいな思考回路で過ごしていました。(うまく例えが書けなかった…)

単純に、1秒も無駄にするなって言われてきました。飛んできた球はとにかく早く打ち返せ、飛んでくるかもしれない球も予測しろ!みたいな。そして、それが正しいと思って生きてきました。 しかしものづくりにおいては、今までの自分の考え方は変えなくてはいけないのかもしれない、と気付いてしまいました。

やってみたけどうまくいかなかったとか、チャレンジしたけど他のアプローチの方が良かったとか、ものづくりをする時には『トライしたのに何も生み出せなかった時間』とたくさん向き合う必要があるのだと思います。飛んできた球をすぐ打ち返すのではなく、一旦キャッチして、いろんなことを考慮して正しい方向に投げ返さなくちゃいけない。しかし、自分の一部と化してしまった「時間を無駄にするな!どんどん打ち返せ!」という考え方を突然変えることができず…。

じっくり考える必要があるタスクでも、「早く作業を進めなきゃ」「毎日成果を出さなきゃ」ということを優先してしまいがちなのです。大袈裟に書くと、やりたいことと自分の特性がマッチしていない気がしました。スピード重視で生きてきてしまったことが裏目に出るとは、という感じです。

プログラミングはめちゃくちゃ好きだし面白いけど、プロダクトとの向き合い方が下手というか未熟なんだろうな。うまくなれる日が来るのかな。と思っています。

良かったこと

成長したかも!!と勝手に思っていることも書いておきます。

少しずつ会社の一員、チームの一員になれている感もあって、開発してるプロダクトのミーティングでも、ちょっとずつ質問したり発言したりもできるようになりました。先月はついていくのに必死だし、緊張しているし、プロダクトのことも何もわかっていなくて「大丈夫です」しか言ってなかったので自分の中では大進歩…

ミーティングを短く!が弊社の決まり事ではあるんですが、フルリモートが故にミーティングはチームの人と話せる数少ない機会なので良い時間の過ごし方をしたいなと思っています。

先輩の提案でチームメンバーとプロダクトマネジメントの本を題材に読書会をし始めたのもありがたいことの一つです。普段のミーティングでは話してこなかったような話題が出たり、先輩がどういう気持ちでプロダクトを見ているか知れて、そこでまた自分の未熟さに気づいたりしています(良かった話のはずなのに、またもや己の未熟さに気づく…)

プログラミングだけじゃなくてプロダクトと向き合う力をつける、というのが今の私の目標かなと思います。もちろんプログラミングの方も成長しないといけないんだけど。

色々思うこと

時間の過ごし方だとか、プロダクトの向き合い方だとか、色々と自分の課題はありますが、苦手でもそれなりにやってみるしかないと思っているのが一番の気持ちです。

これだけ書いておいて思ったんですが、そもそも私、機敏なタイプじゃなかったんですよね。のんびり色んなことを考えるのが好きだったし、動きもゆっくりだった気が…。初めて大学生になってからバイトした時なんて「もっとサクサク動け!」とか言われていた気がする。それが数年でこういう考え方になっているわけだから、人って全然変わるんだな。これからまた数年かけて変わっていく自分を楽しむとしよう…