リーダブルコードを読んで実践したいと思ったこと feat. ChatGPT
先日、会社の技術書ライブラリーで『リーダブルコード』を借りた。 実務でわりと大きめのソースコードを触っていて、可読性って大事だなと感じたのがきっかけだ。
今のところ8割ほど読み終えた段階なのだけど、すぐに実践できる内容でとてもありがたかった。これは良いなと思ったポイントを忘れないうちに書いておく。
説明変数を入れる
8章 p.100で登場する概念。サンプルコードとしては以下のように書かれている。
if line.split(':')[0].strip() == "root":
...
このコードは一体何をしようとしているんだろう？ぱっと見では分からない。
これならどうだろうか。
username = line.split(':')[0].strip()
if username == "root":
...
なるほど、ある文字列を整形したものがusernameで、それがrootであるかを見ているんだなと分かる。
これまでは命名を意識するのはメソッドを定義する時がほとんどだった。 例のような初見だと何をしようとしているのか分かりづらい処理に対しては、概念を説明する変数を定義してあげればいいんだなと勉強になった。
でもコードの行数が増えるよね？
大前提として1章 p.4に重要なことが書かれている。
コードは短くしたほうがいい。だけど、「理解するまでにかかる時間」を短くするほうが大切だ。
メソッドチェーンなどを駆使して、複雑な処理を1行で書くのがクールなのかもと思っていた時期もあったけど、実務で保守・改修を経験したことで、考えが変わった。
今はエディタが優秀なので、行数が長くなってもメソッドジャンプや文字列検索で必要な情報に素早く辿りつけるのもあり、行数を短くすることに固執して可読性を損なうのはナンセンスなように思う。
もちろん、不必要に冗長な書き方をしないようには気をつけたい。ここはまだまだ技術力不足の面があるので精進したいところ。
無関係の下位問題を抽出する
10章 p.129からp.141まで丸々この手法について書かれている。サンプルコードを手で書き写すのも疲れてきたので、ChatGPTさんにお手伝いしてもらうことにする。
質問
Rubyを使用して、一つの長いメソッドから無関係の下位問題を抽出するサンプルコードを、beforeとafterで二つ提示してください。リーダブルコードのQiita記事を参照してください。
回答
以下は、Rubyの一つの長いメソッドから無関係の下位問題を抽出するサンプルコードの例です。
Before
def send_email_to_users(users)
users.each do |user|
if user.active?
if user.email_confirmed?
if user.subscribed_to_newsletter?
NewsletterMailer.send_newsletter(user)
end
end
end
end
end
このコードは、ユーザーのアクティブ状態、メールアドレスの確認状態、およびニュースレターの購読状態を確認し、ニュースレターを購読しているアクティブなユーザーにニュースレターを送信します。
しかし、このコードはネストが深くなっており、理解しにくく、テストも困難です。
そこで、以下のように無関係の下位問題を抽出することで、コードを改善することができます。
After
def send_email_to_users(users)
subscribed_users = subscribed_and_active_users(users)
subscribed_users.each do |user|
NewsletterMailer.send_newsletter(user)
end
end
def subscribed_and_active_users(users)
users.select do |user|
user.active? && user.email_confirmed? && user.subscribed_to_newsletter?
end
end
この改善されたコードでは、send_email_to_usersメソッドは、ニュースレターを購読しているアクティブなユーザーに対してのみsubscribed_and_active_usersメソッドを使って絞り込んでいます。
subscribed_and_active_usersメソッドは、アクティブでメールアドレスが確認され、かつニュースレターを購読しているユーザーを選択します。これにより、コードが読みやすくなり、テストも容易になります。
お分かりいただけただろうか
beforeの例では、send_email_to_usersメソッド内で2つのことをやろうとしていた。
- メールを送っても良いユーザーか判定する
- メールを送信する
「ユーザーの状態確認」は、「メールを送信する」という高レベルの目標（本当にやりたいこと）とは無関係の下位問題であるとChatGPTさんは言ってます。
このように下位問題を切り分けることで、このメソッドで最も重要な「メールを送る」という処理に素早くフォーカスをあてられるようになった。つまり読みやすい。
ちなみにリーダブルコードでは、「与えられた地点から最も近い場所を見つける」関数内で、「2つの距離の球面距離を算出する」という下位問題を抽出する例が挙げられていた。（こっちの例の方が適切かも）
ともあれ、ChatGPTさんありがとうございました。
まとめ
リーダブルコードにはここで書いた2つの手法以外にも、すぐ実践できてかつ効果的な手法がたくさん紹介されている。リーダブルコードのまとめ記事はQiitaを始めとしてたくさん良質なものがあるので、n番煎じ感が否めないが、自身の学びを強化するのと「これをやっていきます」という決意表明的な意味で書いてみた。
本記事とは関係ないけど、個人開発でChatGPTさんにコードレビューしてもらいたい。
また最後まで読んだら感想書くかもしれません。おわり。
2月の振り返りと3月の目標
3月に入ってから5日経った。すでに気持ちは3月だけど、忘れないうちに2月の振り返りをしておきたい。あと色々とやりたいことがあるので、3月の目標についても書く。
2月の振り返り
エンタメ
- 澤野弘之のライブ
- 前職の後輩たちとサウナ
- プログラミングスクールの友人とサウナ
- 小田原のゲームセンターでプリクラ&ぬいぐるみGET
仕事
- Railsの設計思想や重要概念を学ぶ
- CoC（設定より規約）
- コールバック
- トランザクション
- テストダブル
- インターフェース
- GraphQLへの入門
- はじめてのGraphQLを読む
- Mutation関連の実装を行う
- Next.jsへの入門
- チュートリアルを少しだけ進める
- 社内ランチお誘いNotionを作る
- あまりワークしなかったけど学びになった
- カジュアル面談（同じプログラミングスクールの方）
その他
- 「運動脳」を読んでランニングを始める
- 友人の転職相談に乗る
総括
前職の後輩たちと久々に会うなど先月は人との交流がいつもより多かった。2週連続でサウナに行ったのは初めてだけどその次の週に体調を崩したのであまり行き過ぎはよくないのかも？因果関係は不明。 プリクラを撮ったのは久々で、青春気分を味わえて満足でした。
仕事に関しては、Railsをもっとちゃんとやっていかないとなと感じた。あるPRを2月にオープンして3月頭にapproveをいただいたが、コメント総数が100件になっていて驚きだった。先輩方にはお手数をかけてしまったが、個人としてはかなり濃い学びを得られてとても良かった。
また、texta.fmを聴き始めて、Railsだけでなくソフトウェア開発の歴史や設計などもっと抽象的なレベルでも学んでいくとより美しいコードが書けるようになるんだろうなと気づき始めた。
2月後半で少し体調を崩したのは、良い評価を得たいが故の焦りの気持ちと、運動不足による体調不良が原因だったと考えている。前者については、今は着実に技術力を高めていこうと地に足の着いた考えに落ち着いたので大丈夫そう。後者はちょうど昨日からジム（エニタイム）を契約して最低週3日は通って30分以上のランニングをすることで解消しようとしている。「運動脳」を読んで、運動が最強すぎてやらない理由が見つからなくなったので、科学を信じてこれからも続けていきたい。（長期的に続けないと現れない効果がたくさんある、集中力や記憶力の改善など）
3月の目標
- 要件・仕様整理をしっかり行ってから実装する
- 週に3日以上ジムに通う
- texta.fmを一周した感想をブログにまとめる
- GraphQLのチュートリアルを進める
- 社内で技術勉強会を開く
- GASで自動化プログラムを書く
今思いつく目標はこんなところ。定期的な運動で健康な精神と肉体を手に入れつつ、着実に技術力を高めていきたい。
要件・仕様整理については、先月のPRで正常系・異常系の洗い出しや成果物を明確化できていない状態でコードを書き始めたことで、手戻りが発生してしまう問題があったから目標に入れた。t-wadaさんのように瞬時に頭の中で適切な設計を構築できるレベルになればいきなりコードを書き始めても問題ないかもしれないが、現状の自分はそのレベルにはほど遠いので、急がば回れの気持ちで実装プロセスも丁寧にやっていきたい。
3月も意味ある学びと成果を目指して頑張ろう。
はじめてのGraphQLを読んだ&実務でちょっと書いた
実務でGraphQL関連のコードを触ることになったので、友人に「はじめてのGraphQL」を借りて先週読み終わった。
（普通に買えばよかったけど、作業会をした時にたまたま持っていて今読んでないからということでお借りした）
原著の英語版が2018年9月発行なので情報は少し古いかもしれない。ただ、GraphQLの元となっているグラフ理論（ここは特に面白かった）、Schema、Query、Mutation、Subscriptionなど基礎概念の説明、ReactにおけるApollo Clientの使い方といった内容が網羅的にまとまっているので頭の中にインデックスを作るための本として適しているのではないかと思う。
「GraphQLとは何か」などここでまとめ直すといいかもしれないが、そのような内容の記事は公式ドキュメント含め質の高いものがネット上にたくさん存在しているので今回はやらないことにする。これ以上概念的な理解に時間を割くよりもコードを書く中でキャッチアップしていく方が効率的だと思う。
正確性や網羅性は気にせず、印象に残っていることを以下にまとめる。
RESTとGraphQLの比較
以下の記事に非常に分かりやすくまとまっていた。（はじめてのGraphQL読後）
大きく3点、特徴を取り上げたい。
- RESTのエンドポイントは複数なのに対して、GraphQLのエンドポイントは一つであること
RESTの問題点の一つとして、リクエスト時に不要なデータまで取得してしまうことが挙げられる。逆に欲しい情報がそのエンドポイントだけでは取れず、複数回のリクエストを送らないといけなくなることもある。
その点、GraphQLではクライアント側で欲しいデータだけを問い合わせるようなクエリを書けるため、このような「オーバーフェッチ、アンダーフェッチ」の問題を避けることができる。
ただ、エンドポイントごとに分けて処理を書くことができないが故に、コード量が増えるにつれてGraphQLのクエリは徐々に複雑になっていくデメリットもある。
- 型付けができること
昨今のWebフロントエンドにおいては可読性や安全性などの観点で型付けができるTypeScriptが採用されることが多くなっているが、GraphQLも同様に型付けを採用している。TypeScriptとの相性が非常に良いため、セットで使用されているプロジェクトが多く見受けられる。
今はMutation周りを少し触った程度なので、型付けの恩恵を実感できていないが、型付けできるからこそそのままドキュメントとしても活用できるような可読性の高いSchemaが定義できるのだと思う。また、データを問い合わせた際に、どのような型のデータが返ってくるか分からない場合、型判定や型変換の処理を書かなければならないため冗長になる。（そういった処理を書かないとバグの原因になる）
ふだんRubyばかり書いているので（といっても1年弱）、この型付けのメリットを正しく説明できているかちょっと怪しい。間違っているポイントがあればそれはそれで勉強になるのでマサカリをお待ちすることにする。
- フロントエンド側で柔軟にクエリを書ける
開発マネージャーからおすすめされたtexta.fmの4話の後半5分でこの特徴について語られている。
バックエンドとフロントエンドの開発担当を分けているプロジェクトの場合、RESTであれば両者がどのようなデータが必要かエンドポイントごとにすり合わせをしながら実装していく必要がある一方で、GraphQLならフロントエンド側で柔軟にクエリを書き換えることができるため、バックエンド側に逐一用意してもらう必要がなくなるとのことだ。
開発（リリース）スピードがビジネス上の重要なファクタとなるWeb業界においては、このGraphQLの柔軟性がとても重宝されているようだ。ただ、小規模アプリにはRESTのシンプルなインターフェースで十分ということに注意した方がよさそう。規模が大きくなり、バックエンドとフロントエンドの開発プロセスが分離され始めたフェーズにおいてGraphQLを積極採用すると良いのだと思う。
MutationのRSpecを書いてみた感想
ここは経験が浅いので合ってるか分からないが、書き方はrequest_specに似ているものの、テストダブル（スタブやモック）が使いづらいなと感じた。これは今回実装したテストが、更新対象のModel内でbefore_createコールバックを使用していたことに起因しているかもしれないが、オブジェクトとして渡せる引数がcurrent_userのみ（contextを使用）なことも原因なように思う。
また、エラーハンドリングも慣れなくて難しかった。普段書いてるerrors.addのようにRails内だけで完結しない。例えばインスタンスsave時の条件分岐で以下のようなGraphQL::ExecutionErrorというGraphQL特有のエラーを返す必要があった。
raise GraphQL::ExecutionError.new("Something went wrong", extensions: { "code" => "BROKEN" })
graphql-ruby/execution_errors.md at master · rmosolgo/graphql-ruby · GitHubより
この段落に書いたことは印象論の域を出ないので、これからGraphQLと仲良くなる中でここで感じた印象が正しかったのかどうか検証していきたい。
これからやりたいこと
とにかく実務でGraphQL周りのコードをたくさん書きたい。そのために個人開発やチュートリアルなどでgraphql-rubyの書き方に慣れていこうと思う。フロントエンドの先輩いわくgraphql-rubyは公式ドキュメントが親切らしいので、これもちゃんと読んでいきたい。
もちろんGraphQL本体の公式ドキュメントも読み進める。英語リーディングの題材にもできてよさそう。
あとは以下を500円お支払いして進めている。処理内容の解説はほとんどなく、サンプルコード通りに書いてくださいという感じなので、こんな感じで書くんだなあという感覚が掴めればそれでOKかなと思う。
【GraphQL 開発超入門】React × GraphQL × Rails でアプリケーションを作る
一応はGraphQLについてまとめられたので、ここらで終わりにする。新しい技術を学ぶのはなんだかワクワクしますね。
参照
エンジニアとして働く上で英語ができると何が嬉しいのか
技術的には現状、特筆したものはないけども、英語力に関してはわりと良い感じに磨けているのではないかと思うので、エンジニアと英語学習について今感じていることをまとめておく。
今の英語力
まだWeb広告の会社で働いていた頃（2019年）に友人とTOEICやるかという話になって、英語を学ぶことにした。モチベーションは800点以上を取って月5000円の資格補助を得たいという浅はかなものだったが、2020年12月に905点を取って達成することができた。ちなみに2019年10月に初めて受けた時は645点だったので、1年ぐらいかけて260点ぐらい上げたことになる。けっこう頑張ったと思う。えらい。
TOEICで良い点は取れたもののスピーキングがてんでダメだったのでNative Campでオンライン英会話を始めた。2020年から辞めたりまた始めたりを繰り返していたが、だいたい英会話も2年近く続けた感じだ。いまだにスピーディな会話はできないが、簡単な内容であれば1時間以上好きなように話せるようになった。
また、プライベートな話で恐縮だけど、今年の1月からフィリピン出身の方とお付き合いしていて、毎晩英語で電話をしている。その子はもともと自分の英会話の先生をしてくれていて、一緒にオンラインゲームをしたりする中で仲良くなり、日本で働くことになったのをきっかけにお付き合いすることができた。個人ブログなのでちょっと自慢すると、その子はTOEICをノー勉で1回受けて満点を取ってしまうレベルの英語力だ。発音も綺麗だし、英語ネイティブの国で使われているスラングから学術的な単語まで知っている。デートする時も全て英会話なので、彼女のおかげで自分の英語力はこれからも伸びていくと思う。（振られないかぎり）
英語がある程度できることのメリット
インプットの観点
英語を読んだり聞いたりすることに抵抗がなくなること、これが最大のメリットだと感じている。日本でエンジニアとして働く上で英語を話せる必要はないけど、英語を読むことは言うまでもなく必要になる。
ソースコードもログも英語だし、海外のOSSだとREADMEは英語で書かれているし、今流行のGraphQLやNext.jsの公式ドキュメントも英語で書かれている。正直な話、急いでいる時はDeepLやChromeの翻訳を使ってしまうが、プライベートの学習時間は英語のまま読んでいて、より深く理解できている気がする。
動画教材に関しては日本語字幕がないものが多く、リスニング力が無いとけっこう辛いことになる。自分もまだ100%理解できるレベルではないが、ざっくりとは理解できている。英語の動画を見ること自体が英語学習になるので、動画を最後まで見る強いモチベーションになっている。飽き性のせいで日本語の動画だと途中でみるのを辞めてしまいがちなので、このメリットはとても大きい。さらに言うと、英語のコンテンツの方が圧倒的に量が多いので、YouTubeに転がっている有料級の英語動画を選択肢に入れることができるのも大きい。例えば以下の動画はRails × GraphQLを学習中の自分にはとても良いコンテンツだった。
アウトプットの観点
業務委託の仕事をしている時に、ベトナムのオフショア開発チームの方に対して、2ヶ月ほど英語でコードレビューしたりしていた。変なこと言っていないかDeepLで和訳してから恐る恐る送っていたが、英語をかじっていたことであまり負担を感じることなくコミュニケーションできたのがよかった。英語でレビューしてる俺かっけえという気持ちが内心あったことは秘密だ。
プログラミング言語は英語で書かれているので、もちろんコーディングでも活かせる。違和感のない変数名を付けたり、RSpecのテストケースを正しい英文法で記述できたりといったことだ。この先ずっと日本人だけで開発するようなプロジェクトであれば、多少おかしい英語で書かれていても問題ないかもしれないが、将来的に海外人材がジョインする可能性を考慮すると、正しい英語で書いた方がいいのではないだろうか。実際に熟練のエンジニアほど正しい英語表記を心がけている印象がある。（コードレビューで何度か指摘いただいた）
やはりエンジニアとして働く上で英語力はあった方がよさそうだ。仕事の幅が広がるし、学習効率を上げることができる。また、ログやドキュメントを読んだり、変数名を考えたりするのにかかる時間を短縮することができるので、開発スピードの向上が期待できる。
その他よかったこと
自分は音楽が好きで、洋楽の歌詞にも感情移入できるようになったのが嬉しい。先日はColdplayのライブ映像をYouTubeで字幕付きでみてみると、この曲ってこういうことを歌ってたんだと分かって、美しい歌詞に感動することができた。（字幕なしだとまだちょっと何言ってるかわからない）
その他には、メンタリストDaigoか誰かが言っていたけど、第二言語で思考した方がより客観的な視点で考えることができるそうだ。母国語は人生の感情的な経験と強く結びついているから、第二言語と比較してより主観的になってしまうのだろう。実感として彼女に「愛してる」と言うのは気恥ずかしいけど、「I love you」と言うのはそれほど抵抗なく言えてしまう。これにはメリット・デメリットがありそうだが、英語という新たな言語体系を獲得することでより柔軟に思考できるようになるのは間違いない。こんなに堅苦しい話じゃなくても、英語で話す時は別人になれて普段思いつけないことや言えないことが表現できるようになるのが面白い。サッカーの長友選手とかイタリア語の方が日本語より自分らしくいられてるような気がする、たぶん。
TOEICの点数と実際の英語力について
本題についてはすでに書いたので、ここからは蛇足。TOEICで900点を取るまでやった上で言えるのは、900点を取るだけでは全然大した英語力ではないということ。TOEICというゲームを攻略することにフォーカスすれば、900点を取るのはそれほど難しくない。とにかく模試を何度も解いて、問題形式に慣れ、時間配分の感覚を掴むことが最も得点に繋がる。もちろん彼女のように英語ができる人であれば、このような攻略などしなくとも容易く高得点を取ることができる。つまりは「英語力がある -> TOEICで高得点が取れる」は真だけど、「TOEICで高得点が取れる -> 英語力がある」は必ずしも真と言えないということだ。自分は後者のパターンだったので、錯覚資産だけを得て英語ができる風に見せかけているなんちゃって野郎だった。もちろんTOEIC学習の過程で語彙を増やしたり、リスニング・リーディング力を伸ばすことができたので無駄だとは思っていない。
今後の目標
最後はポジティブなことを書いて終わりにする。
- 英語のドキュメントをサッと流し読みして理解できるようになる
- 海外のエンジニア友達を作って一緒に開発する
- OSSコントリビュートに挑戦する
- 英語力を生かした仕事をする（海外向けプロダクト、ブリッジエンジニア的なことなど）
長々と書いたけど、結論として英語学習はエンジニアの仕事に少なからずメリットがあるのでおすすめだし、今後も続けていきたいと思う。Let's enjoy learning English.
〜おわり〜
これわからんけど知りたいなってことを5分で書き連ねてみる
先ほどScrapboxにこんな記事を書いた。
テックブログ書かないといけないなと思いつつも、下手なこと書いてよわよわだなと思われたくなくて筆が重くなってしまっていた。 なのでリハビリも兼ねて、今わからないけどこれ知りたいなできるようになりたいなということをただただ書き連ねてみる。風呂を沸かす5分以内で。
Next.jsが書けるようになりたいな
- SSR/SSGとか言われてるけどいまいちよく分からんな
- Reactだけじゃだめなん？
- そもそもReactの書き方ぜんぜんわからんな
GraphQL書けるようになりたいな
シェルスクリプトが書けるようになりたいな
Webの基礎をもっと理解したいな
インフラをもっと理解したいな
- AWSデプロイしたことない。S3とEC2しかぽちぽちしたことない。もう全然わかってない
- Dockerコマンドはいまだに呪文。チーム開発で役立つのねあなた
- Kubernetes。綴り難しいよあなた。でもマイクロサービスでは必須っぽい。コマンドが覚えづらい。でも仲良くなりたい。
- nginxって何がすごいんだろう。ルーティングを整理してくれる的な役割しか理解できてない。これはインフラ分類で合ってるのか
5分とか言いながら10分ぐらいかかってしまった。まだまだ恥を捨てきれていない。この土日はGraphQLについて学習する予定。またゆるい感じで記事にしたい。
〜おわり〜
2022年の振り返り
自分も流れに乗って1年の振り返り記事を書いてみることにした。実家で頭がぼけているので、ゆるめに書く。
1月
初めていただいた業務委託の仕事でRailsアプリのバグ修正などを行う。この頃までTable PlusなどGUIのDBツールを全く知らなかった。rails consoleより手軽だしSQLも叩けて素敵、と感動した思い出。後半からエンジニアとしての転職活動を開始する。
2月
友人の紹介でLaravelのアプリ開発の仕事をいただく。つよつよの先輩にショートカットやコマンド操作など色々と教わる。もたついてペアプロで冷や汗かくまくった記憶が蘇る。転職活動で6社ほど内定をいただき、超絶迷った末に内定承諾。
3月
Laravelのお仕事にほぼ時間を費やす。コードベースも理解でき始めて、開発した機能がリリースされたりエンジニアの仕事楽しすぎると思い始めた頃。内定承諾後にやっぱり別の会社かも・・・とジタバタしてしまって色んな方に迷惑をかけてしまった。
4月
受託開発企業に契約社員として入社。フルリモートで9:30~18:00で働きつつ、夜は業務委託の仕事をする毎日。インドア属性高めなので、全然つらくなかった。4月後半からもう1社、業務委託でRailsアプリの開発を始めて三足のわらじになる。
5月
GWを丸々費やしてLaravelでカレンダー機能を開発。ちゃんと動いた時の感動は忘れられない。5月なのに本業と合わせて200時間ぐらい働いた。自社開発(副業)と受託開発(本業)の違いを感じて、プロダクトの運用やマーケティングまで関わるには自社開発の方がいいのかもと思い始めた。
6月
色々と悩んだ末にプロジェクトがひと段落つく7月末で受託開発企業を離れる決断をした。お互いのマッチ度を測るための契約社員入社とは言え、申し訳ない気持ちで一杯だった。次こそは100%納得のいく企業を探そうと決意を固めた。
7月
受託開発プロダクトのリリースに向けてラストスパート。お客さんとちょっとしたトラブルがありつつも、リードエンジニアの方を中心とした働きにより無事にリリースまで漕ぎ着けた。受託開発はSESと同じくどの案件に関わるかによって明暗が分かれるんだろうなと感じた4ヶ月だった。中旬から転職活動を始めた。
8月
2社の業務委託の仕事を受けつつ、選考を進める。レジュメを具体的なものに更新すると、かなり企業の反応が良くなった。自分をどう売り込むかはエンジニアの世界においても重要みたいだ。複数社から良いオファーをいただいて、かなり悩んだ末に学生時代からファンだったGMOペパボに入社を決めた。
9月
引き続き業務委託の仕事をしつつ、引っ越しの準備を進める。通勤をできるだけ楽にするために会社から徒歩5分ぐらいのところに住むことにした。引っ越し当初は首都高の騒音であまり眠れない日々が続いた。渋谷のおしゃれピーポーに馴染めるかも少し不安だった。正社員で働きつつ、2社で副業は体力的に厳しいだろうと思い、1社からは離れることにした。
10月
3日に初出社した。初日からとても親切にしていただき、技術的にすごい方とも出会えてペパボに入社して正解だったなと思った。先輩方を見習ってアウトプット量を増やすべくこのブログを書き始めた。ツイートの頻度も上げるようにした。研修で使用するフィヨルド・ブートキャンプのカリキュラムが素晴らしく、さらに社内メンターの方もついてくださって、こんなに良くしてもらっていいんですかという気分だった。本業に集中するため、もう1社も11月一杯で辞めさせてもらうことに。
11月
フィヨルド・ブートキャンプの教材で「lsコマンドをRubyで作る」というものがあり、オブジェクト指向の理解が深まったおかげで、プログラミングが以前よりも楽しくなった。レビューの質も高く、お世辞抜きで素晴らしいスクールだと思う。Scrapboxを毎日更新した。
12月
フィヨルド・ブートキャンプの研修を修了し、ついに開発に入らせてもらうことに。前半は環境構築とコードレビューを行い、中旬から小規模な機能開発を担当することになった。開発チームの方々とも打ち解けてきて、毎日の夕会がとても楽しい。年末に3ヶ月間お世話になった方との別れもあった。いただいた学びを今後のエンジニア人生の血肉にしていこうと心に誓った。映画館を貸し切って行われた年末総会は気合が入っていてとても楽しかった。RUNTEQのアドベントカレンダー用に投稿したQiita記事がプチバズりして嬉しかった。これがクリぼっちの意地。
おわりに
2022年はプログラミングで始まり、プログラミングで終わった。来年もきっとそうなるだろう。そして技術的なアウトプットをもっと増やしていきたい。1年後の自分がどうなってるか楽しみだ。
【入社エントリー】ペパボカレッジを全力でおすすめしてみる
この記事は🎅GMOペパボエンジニア Advent Calendar 2022 - Adventarの3日目の記事です。
昨日はやんまー @yammerjpさんのjpro: JavaScriptで書くJSON processorでした。コマンドラインでJSONを抽出するためのライブラリを自作されたそうです。すごい！自分も来週からプロダクト開発に入っていくので、使わせてもらおうと思います。
本題
いわゆる入社エントリー的なものを書きます。自分は2022年10月に「ペパボカレッジ」という枠でGMOペパボ株式会社に入社しました。
フィヨルドブートキャンプというプログラミングスクールのカリキュラムを研修生という形で利用させてもらいながら、社内メンターに毎日相談し放題という至れり尽くせりの内容です。つい先日、フィヨルドブートキャンプの受講予定カリキュラムを全て修了し、晴れて卒業することができました。
今日でフィヨルドブートキャンプのカリキュラムを終え研修修了となりました〜。学びが濃すぎる2ヶ月で、だいぶ成長できた実感がありますなり〜。
— inoway (@inoway46) 2022年12月1日
（語尾が変なことになってますが気にしないでください）
この2ヶ月で技術的な成長はもちろん、プログラミングが以前よりも断然楽しくなりました。ここからはペパボカレッジは最高なのでみんなもおいでよという内容をひたすら書いていきます。
ペパボのいいところ
この2ヶ月で本当にいい会社だなとつくづく思いましたが、すべて書くと字数が大変なことになりそうなので、自分が特にいいなと思ったことに絞って書きます。minneやSUZURIやカラーミーショップやロリポップといったサービスの素晴らしさはユーザーの皆さんが自分よりも理解されていると思うので割愛させていただきます。あくまで主観ということをご承知おきください。
その１ みんながやさしい
毎日Slackに分報スレを自動投稿できるワークフローがあり、ここで自分が今やっていることについて好きなように呟いたり、困りごとがあれば先輩方が相談に乗ってくださったりします。
さらにjune29さん、kurehajimeさんというやさしくてつよつよなお二人が技術メンターとして様々なフィードバックをくれたりします。
以下はフィヨルドブートキャンプの「Rubyでlsコマンドを作る」カリキュラムに対して手厚いレビューをいただいたPR。適切な命名をすることの大事を痛感しました。
lsコマンドを作るシリーズは1~5まであり長大なのですが、フィヨルドブートキャンプメンターのyuuuさんが以降も粘り強くレビューしてくださいました。 どれだけレビューが手厚いのかは以下のPR群を見ていただければ一目瞭然かと思います。（※ 受講生で未クリアの方はネタバレになってしまうので見ないようにしてください🙏）
開発チームマネージャーのkeokenさんは入社初日から毎日のように「inowayさん今日は調子どうですか？」と声をかけてくださって、不明点などいつでも質問できる雰囲気を作ってもらえたのがとてもありがたかったです。ここには書ききれないぐらい、ペパボの皆さんは親切すぎる！自分も新しい方を迎えた際には、できることは何でもしようと思っています。
その２ みんながつよつよ
僕のステレオタイプかもしれませんが、Rust使いはつよつよであるという認識があります。作りたいものに対して他の言語では満足のいくものにならないから、処理速度を重視してRustを使う方が多い印象です。そしてペパボにはRust使いがゴロゴロいて、Rustで自作のライブラリを作った方がいたりしてとても驚きました。 僕のメンターのkurehajimeさんも趣味でRustを触ったりされているそうです。
ペパボでは毎月Pepabo Tech Fridayという社内LTが開催されていて、そこで各事業部のエンジニアたちが技術的知見をシェアしたりしています。 以下は9月の開催内容。
僕がこれから開発に関わらせてもらうminne事業部の皆さんも度々登壇されていて、新卒1年目の方や前述のnissyiさんもつい先日のPTFで発表されていたので積極性を見習いたいなと思いました。とにかく皆さん技術が大好きで、やる気に溢れてます。
（nissyiさんのインタビュー記事を勝手に貼らせてもらう。僕の推しです）
社外のカンファレンスにも積極的に登壇されていて、今年のRuby Kaigiでは2名の方がスピーカーを務めていたり、Kaigi on Railsでも複数名の方が登壇されていたりしました。入社前からRuby界隈でペパボは有名な会社のイメージがありましたが、こういった主要なカンファレンスにも定期的に登壇されているのはすごいことだなと思います。
つい先日もペパボの方が主催でShibuya.rbというオフラインコミュニティイベントが開かれました。自分も会場にお邪魔して、すごく楽しい時間でした。
Shibuya.rb x PHP勉強会
— inoway (@inoway46) 2022年11月28日
話に夢中になりすぎてツイートできてなかったけど、すごく楽しかった。
irbの vim機能とbundle/inlineとfish使ってみよう。#shibuyarb #phpstudy
その３ 福利厚生がすごい
自分は渋谷にある東京オフィスで働いているのですが、GMOグループの福利厚生が本当にすごいです。例えば毎週金曜日に「バータイム」というグループ社員の交流会があり、なんと飲食無料（お酒含む）です。渋谷フクラスという非常に綺麗なビル内に、作業スペースやジムや食堂などが入っていて、知り合いの方を招いたりすると皆さん「すごいっすね」という感想をつぶやかれます。（自分も初めて来たとき先輩にすごいっすねって言いました）
また、本社の10階にはマッサージスペースがあり、業務時間内でも10分500円でマッサージを受けることができます。最近肩こりがひどかったので、先週受けてきましたが生まれ変わったように身体が軽くなりました。教えてくださったペパボカレッジ出身のhoriyuさんに感謝です。
この2ヶ月で変わったこと
何か色々書きすぎて若干疲れてきましたが、これだけだとペパボカレッジならびにフィヨルドブートキャンプの魅力が伝えきれていないので、実際この2ヶ月で自分がどう変わったかを最後に書きたいと思います。
プログラミングが楽しくなった
フィヨルドブートキャンプでは「Rubyでlsコマンドを作る」というカリキュラムに取り組んだと書きました。最初は冗長なコードを書いていたのですが、メンターの方々にレビューをいただき徐々にリファクタリングしていきました。その過程で、いわゆるオブジェクト指向的な感覚が磨かれていき、どうすればスッキリとした見通しの良いコードが書けるのかというチャレンジに夢中になりました。
ペパボに入社する前は10ヶ月ほど業務委託でスタートアップ企業のプロダクト開発をお手伝いしたり、契約社員として受託開発企業でECサイトのリプレイス開発を行ったりしていましたが、正直なところ全くもってオブジェクト指向的なコードを書けていませんでした。Railsを使用したあるプロジェクトで、僕があまりにも冗長で整理されていないコードを書いていたために、テックリードの方から「inowayさんはもっとRubyっぽい書き方を意識したほうがいいよ」と苦言を呈されたこともありました。
当時はRubyっぽい書き方が何か分かっていませんでしたが、フィヨルドブートキャンプで2ヶ月間、ハンズオン形式でオブジェクト指向的な書き方を学べたことで、やっとその感覚が掴めてきたような気がします。そして、ただ動くコードを書くだけではなく、合理的で美しいコードを書きたいという欲が芽生えたことで、プログラミングが以前よりも楽しくなりました。半年ほど手をつけていなかった個人開発アプリ（Rails5）を最近触り始めたのも、純粋にコードを書きたいという気持ちからです。本当に良い経験をさせてもらったなと思います。
アウトプット量が増えた
ペパボにはわたしたちが大切にしている3つのことがあります。その内の1つである「アウトプットすること」を体現されているパートナー（社員）が非常に多いです。
各パートナーの技術ブログの更新がSlackで通知されるようになっているのですが、毎日のようにたくさんの更新があります。
アウトプット欲旺盛な皆さんに刺激を受け、自分もこの技術ブログを書いたり、Scrapboxで日記を書いたり、Twitterで日常のことを呟いたりするようにするようになりました。それに加えて、社内用のNotionでも業務終わりに日報を書くようにしています。
日々感じていることや学んだことを言語化することで、頭の中を整理できたり、さらなるアイデアが思い浮かんだりして良いことずくしだなと思います。それに、アウトプットには自己開示の側面もあります。inowayってこんなやつなんだと周囲の人が興味を持ってくれるようになり、いろんな方と仲良くなれました。
自分はストレングス・ファインダーで「内省」や「収集心」という資質が上位にあるような性格で、インプット偏重になりがちでした。アウトプットの習慣を身につけられたことは、今後のエンジニア人生において重要な変化だと感じています。
終わりに
つい熱が入って気づけば5000字を超えてしまいました。まだこれを読んでくれている方はどれぐらいいるのでしょうか。 GMOペパボとフィヨルドブートキャンプの良さが少しでも伝わっていれば嬉しいです。最後までお付き合いいただきありがとうございました！
お知らせ
ペパボカレッジではまだまだ新たな仲間を募集しています！Webアプリケーション開発にチャレンジしたい方はぜひご検討ください！（実務未経験者も対象です）迷ったらお気軽にDMどうぞ〜 inoway (@inoway46) / Twitter
次回予告
🎅GMOペパボエンジニア Advent Calendar 2022 - Adventar4日目はakichan @ch11akiさんです！更新が楽しみですね！
