こんにちは〜こんばんは〜いかがお過ごしですか
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）または領域知識は、はっきり限定された、ある専門分野に特化した分野の知識であり、一般知識またはドメイン独立の知識と対比される。
ブートキャンプアプリは、チーム開発に辿り着くまで自分自身が何度も触るアプリです。なので、ほとんどの機能やユーザーロール（生徒、メンター、管理者など）を知っている状態で開発に参加します。しかし、当たり前ですが仕事ではそんなわけにはいかず… まず仕事で一番大変だったのはアプリの機能を知ることでした。それに加えてドメイン知識がないのでモデル同士の関係やコードを読み取るのがすごく難しいです。（挙げたらキリがないので割愛）自社開発で働くのなら、その分野に興味があるというのは結構大切な気がしました。
仕事で感じていること
取り留めがなく、文章で書くと難しかったので箇条書きします。
自分が、「ビジネス思考か技術思考か」の答えは出ない。ただ、自社開発なのでビジネス思考からは抜け出せないと思う。それでも、技術もこだわりたい、良いコード書くぞ！という強い意志が会社の先輩達から感じられるのでとても影響を受けている。自分も胸を張ってそう言えるようになりたいし、この会社に入れてよかったと思うことの一つ。
Railsが大好きだったけど、UIをもっと頑張りたい。Reactを書く日が来るまでに、知識の貯金をしておきたい。（できるかな…）
社内で人見知りを発揮していたけど徐々に解消されつつある。
優秀な人は例え話が上手い。
非エンジニアという言い方は好きではないのでしたくないが、会社の人はほとんどがエンジニアではないので、プロダクトに関する技術の話をわかりやすく噛み砕いて伝えるのは本当に難しい。
（上記に関連して）開発コストはどれくらいですか？と聞かれた時の最適解ってなんだろう。
一緒にものづくりをしている、エンジニアに機能追加を要望する側の方々からすれば、希望のものを早く生み出して欲しいだろうし、多方面に融通の効くプロダクトを求めているのではないかと思う。
エンジニアだけでものづくりをしていると、現状の設計ありき（もしくは使っているフレームワークありき）でプロダクトについて考えてしまうことが多いのではと思っている。技術のことを知らない、別の方向からの視点がある人たちとプロダクトについて話したり、ものづくりをするのは難しくて楽しい。そして、相手にもそう思ってもらえるような仕事をしなきゃいけないなと思う。
そして、色々書きましたが一番に言いたいのはこれで、『上司と先輩がすごい、私もこうなりたい！』。本当に、これに尽きます。 やっぱり優秀な人たちは努力している、ということをひしと感じた1ヶ月間でした。
その他
- アホみたいにまじめなことばかり書き連ねて恥ずかしいですが、この1ヶ月はまじめなことしか考えていなかったらしく、面白い話は特にありません。
- 上司からの今日のお言葉：「なりたいことに対して、『なれないかも、できないかも』と思うのではなくて、常になりたい自分として振る舞うべき」
- この間の卒業式に影響を受けて、私は自作サービスについて何を話そうかな〜などと考えましたが、まずリリースをしなくてはいけないらしいです。
- ファイト私
- もっと思っていることはありそうですが今日はこの辺で
- 1年後の自分がこれを見たらすごい恥ずかしいんだろうな、と思いながらこの文章を世に放ちます。
