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さんの フィヨルドブートキャンプに３か月参加してみた感想 - 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

技術スタック

作った経緯

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

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

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

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

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

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

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

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

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

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

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

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

FBCでRuby 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秒も無駄にするなって言われてきました。飛んできた球はとにかく早く打ち返せ、飛んでくるかもしれない球も予測しろ！みたいな。そして、それが正しいと思って生きてきました。 しかしものづくりにおいては、今までの自分の考え方は変えなくてはいけないのかもしれない、と気付いてしまいました。

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

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

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

良かったこと

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

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

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

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

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

色々思うこと

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

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

Railsのpluralizeメソッドの挙動が気になる

今日初めて見たメソッドpluralize

  • 英訳すると意味は「複数（形）にする」

その名の通り、レシーバにとった文字列を複数形にしてくれます

 'adult'.pluralize
=> "adults"

すごい〜、でも、これでchildの複数形がchildsとか言ってきたらおもしろいな…と思いながら試してみる

 'child'.pluralize
=> "children"

おっ👀末尾がsじゃない複数形もちゃんと対応してくれている！！

そして、何やら引数count にオプションで数字を指定できるらしいのでやってみる

文字列.pluralize(count)

'day'.pluralize(2)
=> "days"

ちなみにオプションに1を取ると、単数形のままにしてくれる

'day'.pluralize(1)
=> "day"

0とか負の数でもちゃんと単数・複数を認識できるのか実験

 'day'.pluralize(0)
 => "days"

'day'.pluralize(-1)
 => "days"

 'day'.pluralize(-2)
 => "days"

🤔そこまではしてくれないらしいので調べてみると、Railsガイドに載ってた

railsguides.jp

pluralizeメソッドではオプションでcountパラメータを使えます。count == 1を指定すると単数形が返されます。countがそれ以外の値の場合は複数形を返します（訳注: 英語では個数がゼロや小数や負の数の場合は複数形で表されます）。

なるほど〜単純に1の場合しか単数にしてくれないみたい。ていうかそもそも、0とか-1とかって普通に英語だと単数なのか複数なのかわからないや。0day ? 0days ? -1day ? -1days ?

そして

Active Recordでは、モデル名に対応するデフォルトのテーブル名を求めるときにこのメソッドを使います。

らしいので、0とか負の数に対応してなくても、Rails的には困らないのかなと思った。 もし、別の用途で0と-1にどうしても対応させたかったとしても、自分で条件分岐書けばなんとかできてしまいそうだしね。それか、私が知らないだけで別のもっと使えるメソッドがあるのかも。

久々にメソッドの挙動とか見てたらおもしろかった…新しい技術のキャッチアップもしなくちゃいけないけど、こういう時間も大事にしたいと思った今日でした

エンジニアになって1ヶ月経ったよ！

こんにちは〜こんばんは〜いかがお過ごしですか

1年nヶ月無職をしていた私ですが、晴れてwebエンジニアになって1ヶ月経ちました。正直、「ブログ書いてる暇があるなら自作サービスをやったほうがいいのでは…？」と心の中の自分が言っていますが、今の気持ちは今しか書けないもんっ🥺ということで筆を走らせています。前置きが長い。

6月は基本的に仕事9割・自作サービスとJS Primer輪読会とその他が1割くらいな感じで過ごしていました。なので仕事に関することばかり書いていきます。なんかフィヨルドブートキャンプでの経験的なところを絡めてしまいましたが、誰かの参考になったら嬉しい系ではなく、私個人の感想です。（他の会社に入社した方のお話も聞きたい！）

仕事について

フィヨルドブートキャンプの経験が役に立ったこと

チーム開発頑張ってよかった
  • すごい普通じゃんと思われそうですが、本当にチーム開発のおかげで特に迷うこともなく仕事でIssueに取り組めています。入社2日目で小さいPRをマージしてもらったのですが、チーム開発で、開発に関するちょっとしたお作法やGit操作に慣れていたのが本当に大きいなと思いました。
  • そして、生徒同士でレビューをしていたのがすごく良い経験だったと思います。会社のFBC卒の先輩も「昔はその取り組みはなかったけど、生徒同士でレビューするのすごく良いよね」と仰っていました。 チーム開発に入った当時は、「レビュー ＝ メンターさんがするもの」という意識があったので、「レビューを自分がやるとは…？！」と衝撃を受けましたが、コードをより良くするために
    • 提案（時には指摘）をする
    • テキストでのやりとりに慣れる
    • そしてレビュー依頼すること・されること自体に慣れる

というのは必要な経験だったのだなと気づきました。 仕事ではまだ、私にレビュー依頼が来るのは「他の先輩と一緒に（勉強を兼ねて）」か「かなり粒度が小さいもの」ですが、チーム開発で経験したことがなかったらレビュー依頼するのもされるのも、とても緊張していただろうな〜と思います。

真剣にRubyを勉強していてよかった
  • 受講生同士の輪読会で「ゼロからわかる Ruby超入門」「プロを目指す人のためのRuby入門（通称・チェリー本）」をみんなで舐めるように読んでいたのが大きな財産になったな、と仕事を始めてからも日々思っています。
  • 特に、会社の先輩達と週1ペースで読書会があり、その時はやっぱり技術の話で盛り上がり、時には難しい話になることもあります。そういう時は聞く専門に徹していますが、9割方の高確率で「これ、チェリー本でやった内容だ…！！私にもわかる、わかるぞ…！！」と内心思いながら先輩の話を聞いています。ちなみに先日はeql? equal? ==から派生した話で盛り上がりました。ばっちりチェリー本に載っている内容で感動しました。チェリー本は偉大です。
  • そして、これはRubyに限った話ではありませんが、技術の深掘りがいつも当たり前のように行われます。ちょっとしたコードを手元で試す、デバッグして原因を探す、gemのソースコードまで見にいく、、など。 それがエンジニアとして当たり前のことだとは思いますし、私にはまだまだ足りていないスキルだなあとも実感していますが、FBC時代から疑問を持っては納得するまで答えを探す、というサイクルを回す癖がついていたのは大きな財産だったように思います。（これは人から影響されたおかげですが）
質問すること
  • テキストでも口頭でも、自分の状況を相手に伝え、その上でわからないことを適切に聞くのって、正直今でも難しいです。私はいつも、質問する時間より質問するための準備の方に時間がかかります。そして仕事になると、聞くタイミングも大事だったりします。 FBCで勉強中、「質問するのが恥ずかしい、、」と思っていた時期もありましたが、質問するスキルはエンジニアにとって必要不可欠だなあと働き始めてからより実感しています。まだまだ質問スキルは上達の余地ありですが、「質問することそのもの」には慣れていてよかったなと思います。
自分の考えを素直に話すこと
  • これはもうそのままです。言葉のチョイスは大事ですが、本心を隠していて良いことはないと思っています。

フィヨルドブートキャンプでの開発と違うところ

え、じゃあ何の苦労もしてないの？と言われるとそうではないです。仕事中に「しんどい、何もわからん」みたいことは今の所ないですが、これが働くということか！と思うところもあります。

プロダクトの方向性を捉える
  • まず、率直に一番違うなあと思うのは、ビジネスを見据えながら、今後どのようにプロダクトを発展させていくか考える必要があるということです。
  • チーム開発ではもちろんプロダクトのことを考えながら開発を進めていましたが、なんだかんだでその主体はプロダクトでなく自分だったなあと思います。「担当したIssueのこの機能、使いやすくするぞ！」と思ってはいても、フィヨルドブートキャンプの展望を考えて「〜〜の時期までにこの機能をつけて生徒数を〇〇人増やす！」「だからこのIssueはいつまでにやって、優先順位は〜〜」みたいな気持ちはほぼなかったし、なんだかんだで「自分がいつまでにチーム開発を終わりたい」「自分の経験の一つ」とかそういったところに目を向けていました。しかし、それが悪だとは思っていなくて、むしろプラクティスでは開発の流れを掴んだり、経験することが目標だと思うので抱く感情としては普通で、ただし仕事との大きな違いかなと思いました。
ドメイン知識がなくてつらい

ドメイン知識（ドメインちしき、英: Domain knowledge）または領域知識は、はっきり限定された、ある専門分野に特化した分野の知識であり、一般知識またはドメイン独立の知識と対比される。

ドメイン知識 - Wikipedia

ブートキャンプアプリは、チーム開発に辿り着くまで自分自身が何度も触るアプリです。なので、ほとんどの機能やユーザーロール（生徒、メンター、管理者など）を知っている状態で開発に参加します。しかし、当たり前ですが仕事ではそんなわけにはいかず… まず仕事で一番大変だったのはアプリの機能を知ることでした。それに加えてドメイン知識がないのでモデル同士の関係やコードを読み取るのがすごく難しいです。（挙げたらキリがないので割愛）自社開発で働くのなら、その分野に興味があるというのは結構大切な気がしました。

仕事で感じていること

取り留めがなく、文章で書くと難しかったので箇条書きします。

  • 自分が、「ビジネス思考か技術思考か」の答えは出ない。ただ、自社開発なのでビジネス思考からは抜け出せないと思う。それでも、技術もこだわりたい、良いコード書くぞ！という強い意志が会社の先輩達から感じられるのでとても影響を受けている。自分も胸を張ってそう言えるようになりたいし、この会社に入れてよかったと思うことの一つ。

  • Railsが大好きだったけど、UIをもっと頑張りたい。Reactを書く日が来るまでに、知識の貯金をしておきたい。（できるかな…）

  • 社内で人見知りを発揮していたけど徐々に解消されつつある。

  • 優秀な人は例え話が上手い。

  • 非エンジニアという言い方は好きではないのでしたくないが、会社の人はほとんどがエンジニアではないので、プロダクトに関する技術の話をわかりやすく噛み砕いて伝えるのは本当に難しい。

  • （上記に関連して）開発コストはどれくらいですか？と聞かれた時の最適解ってなんだろう。

  • 一緒にものづくりをしている、エンジニアに機能追加を要望する側の方々からすれば、希望のものを早く生み出して欲しいだろうし、多方面に融通の効くプロダクトを求めているのではないかと思う。

  • エンジニアだけでものづくりをしていると、現状の設計ありき（もしくは使っているフレームワークありき）でプロダクトについて考えてしまうことが多いのではと思っている。技術のことを知らない、別の方向からの視点がある人たちとプロダクトについて話したり、ものづくりをするのは難しくて楽しい。そして、相手にもそう思ってもらえるような仕事をしなきゃいけないなと思う。

そして、色々書きましたが一番に言いたいのはこれで、『上司と先輩がすごい、私もこうなりたい！』。本当に、これに尽きます。 やっぱり優秀な人たちは努力している、ということをひしと感じた1ヶ月間でした。

その他

  • アホみたいにまじめなことばかり書き連ねて恥ずかしいですが、この1ヶ月はまじめなことしか考えていなかったらしく、面白い話は特にありません。
  • 上司からの今日のお言葉：「なりたいことに対して、『なれないかも、できないかも』と思うのではなくて、常になりたい自分として振る舞うべき」
  • この間の卒業式に影響を受けて、私は自作サービスについて何を話そうかな〜などと考えましたが、まずリリースをしなくてはいけないらしいです。
  • ファイト私
  • もっと思っていることはありそうですが今日はこの辺で
  • 1年後の自分がこれを見たらすごい恥ずかしいんだろうな、と思いながらこの文章を世に放ちます。