Eat, Play, Nap and Code

食とあそびと昼寝とプログラミング学習

フィヨルドブートキャンプを卒業してWebエンジニアとして就職しました

はじめに

こんにちは。トミーと申します。掲題の通りフィヨルドブートキャンプ(以下FBC)というプログラミングスクールを卒業後、Webエンジニアとして自社開発の会社に内定し、今日から働くことになりました。

内定をいただいたのはTebiki株式会社という、デスクレスワーカー向けの動画教育のSaaSを作っているスタートアップです。 技術スタックはRailsとVue.jsで、FBCでずっと触ってきた技術なので馴染み深い!

もしかしたら未経験からWebエンジニアを目指している方、FBCに入るか迷っている方などに役に立つかも知れないと思うので自分の経験を書き記しておこうかと思います。

もくじ

私について

似たバックグラウンドの方の参考になるかもしれないので、一応私の簡単な経歴を書いておきます。

  • 1993年3月生まれ(2022年時点で29歳)
  • 早稲田大学文化構想学部 文芸・ジャーナリズム論系卒業
  • 前職(2社目)は商社でワインの輸入業と英語関係の雑用
  • 2020年4月末で前職を退職後、2020年10月〜2022年8月までFBCにてプログラミングの学習

経歴はめちゃくちゃ不利でもないし、有利な特性も別にないって感じだと思います。

なぜか年齢を気にする会社は日本では2022年の現在も多いようなので、ギリ20代なのは有利だったのかもしれません。

離職期間は約2年半なのでかなり長いと思いますが、受けていたのがスクールの提携先企業ということもあり、選考に際し特に不利にはならなかったと思います。選考中もそこに関しての質問はされませんでした。

転職について

Webエンジニアを目指した理由

私はもともと大学では文学や映画を勉強していて、仕事というものへのイメージが全く持てないし意欲もないという早稲田の文キャンにはよくいるタイプのアホ学生でした。

まあ芸術を仕事にするほどの根性も能力もないし、食べていけるだけの最低限の仕事ができればいいというナメた態度で就活をしていたので、新卒時の就活は大失敗し入った会社は1ヶ月で退職することになりました。

それから半年後、英語ができる人材を探していた前職(小さな商社)で拾ってもらい、好きな英語を生かせる環境で自由にいろんなことを経験させてもらいました。小さな会社だったのですが教育に力を入れていて、なんの実績もないときからラスベガスや香港などの海外の展示会に「勉強のため」に連れて行ってもらったり、高額な英会話のコーチングスクールに通わせてもらったりしていました。

得意な英語に関しては頼られる一方で、あまり仕事を通じた成長を感じづらくなっていました。 特に新規事業であるワインの輸入というミッションを達成したあとは日々のルーチンワークに面白さを感じられなくなり、「もっと勉強したいのにな」とフラストレーションを感じていました。

そんな中唯一面白いと思えていたのが、社内のシステム開発部が作っている基幹システムに、システムを使う側として機能改善の意見を伝えたりバグ報告を行うことでした。最初はプログラムがどういうふうに出来ているのかも分からず、曖昧な提案をして却下されたり、バグの再現手順を細かく問われたりすることに苛立ちを感じていましたが、現実の問題から規則性を導き出し、解決策を考え出す作業が「これって大学でやってたことと一緒だ」と気づいてからプログラミングに面白さを感じるようになり、だんだん自分もこういう仕事をしたいなと考えるようになりました。

(余談: 理系の人にはもしかしたら偏見があるかもしれませんが、人文学の分野でもテクストを読んで表象されたものを正確に抽出し、方法論に則って論理を組み立て新しい理論を確立させていくという作業を行います。研究対象が芸術作品だからといって論理的な作業を行わないわけではないし、私は謎の学部出身ですが大学で学んだことはプログラミング学習にも大いに役に立ちました)

小さい会社だったため、前職に在籍したまま部署移動しSEとして働くというキャリアパスはあまり現実的ではなかったので、自分で学習してキャリアチェンジしようと思い、2020年4月末に退職しました。この時点ではWeb系という概念を知らず、何でもいいからプログラムを書く仕事がしたいという気持ちでした。

FBCに入った理由

仕事を辞めてからしばらくは独学でプログラミングを学んだり、Wantedlyなどで完全未経験でも採用してくれる会社がないか探したり、大学に戻るのがいいのかも?みたいに右往左往していました。

前職はIT業界でない上に身近に相談できる人もおらず、何を学習すべきか・どんな会社に入るべきかみたいな指針を全く持っていない状態だったため、現実的な選択肢はプログラミングスクールに入ることだろうな、と思っていました。プログラミングスクールを調べている中でやっとWebエンジニアという職種を知り、風通しがよさそうで理想の働き方かもと感じました。

私は英語がわかるので、3ヶ月で英語でWeb開発を学べる某スクールを検討していたのですが、いくらよいカリキュラムでも3ヶ月の詰め込み学習が根性のない自分には向いているとはどうしても思えず(多分途中でやる気が尽きて、3ヶ月を惰性でやり過ごす方にシフトチェンジしそう)、またとても高額(FBCの学費で換算したら40ヶ月分くらい)だったため申し込みを思いとどまりました。

そんな中、あるオンラインのイベントで(当時FBCのメンターをされていた)りほやんさんの存在を知り、「なんていい人なんだ!」と感激してTwitterをフォローしたところ、FBCというプログラミングスクールのメンターをされていることを知りました。

FBCのサイトを開くと、普通のプログラミングスクールみたいな大量の広告がなくて、手作りっぽいデザインと率直な文章でサービスの説明がされていて、「なんかわかんないけどプロフェッショナルな気がするし信頼できそう」と感じました。

そして、月額29800円のサブスク方式が、以前検討していたスクールと比較すると破格だし、学習を続け身につけていくためにも理にかなっていると感じたので2020年10月より入会を決めたのでした。

FBC在籍中のことについては、リアルタイムでたくさんブログを書いているので割愛させてください。

就活の流れ

FBC経由で紹介していただいた1社で決まったので、カジュアル面談〜技術試験〜CTO面接〜体験入社+CEO面接〜内定まで1ヶ月半くらいで終わりました。

就活を本格的に始めたのは自作サービスのShadoneをリリースした1週間後くらいです。FBCの紹介企業の中にはチーム開発(自作サービス作成の前のプラクティス)の途中などからでも選考に進めるところもあるようですが、基本はリリースしてからの方が受けられる企業の選択肢が広がるイメージです。

Tebikiの技術試験やCTO面接では、プログラミングの知識というよりチームで働く姿勢を見られている感じがしました。これは会社によって違うとは思います。

ちなみに私の自作サービスはそこそこバズったんですが、そこはあんまり就活では関係なかったかなって感じです。これも会社によって違うとは思います。ただちゃんとサービスを作り切ったことで技術に関する理解が深まったしプロダクト開発へのイメージも湧いたので、作ったことは無駄ではなかったですね。

Tebikiを選んだ理由

いろいろあるので箇条書きで書いてみます。

  • tebikiというプロダクトが魅力的
  • FBCの先輩が2名働いている
  • 全ての開発をペアプロ・モブプロで行うノンソロ開発が超楽しそう

私は養う家族がおらず東京へ通勤可能な関東の実家に住んでいて、かつ別に引っ越してもいいとも思っていて、給与にも特別強いこだわりがないので、待遇でFBCの紹介企業から受けたい会社を絞り込むのはかなり難しかったです。

受託開発の会社か自社開発の会社かという問題については、他のプログラミングスクールの場合とは違うかもしれませんが、FBCでは「受託は技術志向の人が行くもの」みたいなイメージがあり、私は自分がプロダクト志向だと思っていたし周りの人にも「受託は向いてなさそう」みたいに言われたので、自社開発企業から選ぶことにしました。

自社開発の紹介企業もたくさんあるので、その中でFBCのメンターさんのアドバイスを参考にしつつ、1番嘘のない志望動機が書けたのがTebikiだった(他の会社は書けても嘘っぽくなってしまった)ので、あまり自信はなかったのですが試しに受けてみるか〜!と受けてみたら幸運なことに決まってしまったという感じでした。

あとは体験入社のときに実際のIssueのモブプロに参加させてもらい、ドメイン知識がゼロなので難しいとは思ったのですが、先輩とずっと一緒に開発できるため手も足も出なくてつらいみたいなことはなかったので、ジュニアとして1社目に入る会社として効率的に成長できるすごくありがたい環境だと感じたのもTebikiを選んだ理由の一つです。

フィヨルドブートキャンプについて

やってよかったこと

いろいろあるんですが、プロのエンジニアの人とたくさん交流できたことはよかったことのひとつだと思います。 「エンジニア」がどういう人たちなのかっていう実態?を知っていたから、相手からどういう視点でジャッジされているのか分からなくて不安、みたいにむやみに怖がることなく面接に臨むことができました。

あとは、長い時間をかけてのんびり学習できる環境のおかげで、自分が仕事や人生に求めているものがわかり、エンジニアとして働くことを楽しむことができるという確信が持てたこともよかったです。

反省点

学習後半は結構金銭的に余裕がなかったので、仕事を辞めてすぐにFBCに入っていればよかったな〜とは何度も思いました。もっと言うなら仕事を辞める前にFBCに出会っていたら、チーム開発のプラクティスまでは仕事をしながらでもできた気がします。

離職期間が就活に影響がないとしても、あんまり長い間無職でいると自己肯定感が少しずつ下がるので、もうちょっと効率よく学習を進めて1年くらいで卒業できたらよかったなとも思います。まあ自分の能力にも限界があるし、考えてもしょうがないことではあるんですが。

全体的な感想

私には合っていたので、入って良かったなと思っています。FBCのWebサイトのデザインを見たりkomagataさんのブログを読んで「なんかいいな」と感じたら合ってる可能性が高いと思います。

私は卒業生だからバイアスがかかっているかもしれないけど、今でもフィヨルドブートキャンプというWebサービスのファンです。好きなところは「(理にかなっているという意味で)reasonableな価格設定」と「カスタマイズ性が高いところ」です。

カスタマイズ性は、スクールでありながら学習コミュニティなので、輪読会を開催したり、モブプロで遊んだり、メンターではない野良エンジニアの方の話を聞いたりみたいな形で自由に学習体験を拡張できるのが自分にはとてもあっていました。

一方で、めちゃくちゃ高いレベルの技術力が身に付くみたいなのは私はあまり感じていないです。

卒業までにもっと高いレベルの技術力が求められるスクールもあると思うし、Ruby/Railsが現在のエンジニア市場で1番求められている技術なのかはよく分からないし、身も蓋もないことを言うと大学とかに行くのが「技術力」を身につけるために必要なものなのでは?と思うので、そういう意味でのつよさを身につけるために適した場所だとは感じませんでした。

一方で、エンジニアとしてのコミュニケーションの仕方、勉強の続け方、疑問の解決の仕方、OSSとの関わり方みたいな「仕事の現場で役に立つスキル」を身につけるためには、これ以上適したスクールはあまりないのではないかと感じます。

そして未経験エンジニアとして企業に求められているものって、モダンな技術で作ったかっこいいポートフォリオではなくて、こういった泥臭いスキルとそれを証明する成果物(FBCのチーム開発でのPRとか)の方なんじゃないかなあとも思います。

FBCへの希望

統計を取ったわけではないのでもしかしたら違うのかも知れませんが、自分を含めFBCに参加されている方の多くは「プログラミング未経験かつIT業界での就労も未経験」というバックグラウンドだと感じます。 私自身、IT業界でのキャリアを考えた時に「エンジニア」以外の選択肢が思い浮かびませんでした。が、実際にIT業界を知ると、エンジニア以外の選択肢もたくさんあり、もしかしたらエンジニアにならなくても自分の理想の働き方が選べたり、より向いている職務もあるかもしれないとも感じました。

なので別にコースが用意されていたりその職種への就職の斡旋がなくてもいいので、エンジニア職以外の職務のIT業界の方ともっと交流を持てたらいいなと感じました。

最後に

文系未経験の人がエンジニアを目指すことについて

私は権威主義とゲートキーピングが大嫌いなので、プログラミングスクールへの偏見がなくなってほしいと切に願っています。

卒業生の活躍のおかげで、Ruby界隈でFBCに偏見を持っている方はほぼいないと体感しています。しかしIT業界全体を見ると、FBCに関わらずプログラミングスクールを卒業した人に対して偏見を持っている人は少なくないと感じます。

私は女子・ジェンダーマイノリティの学生がSTEM分野へ進学する後押しをするNPOであるWaffleを少しだけお手伝いしています。ジェンダーバイアスのせいで若い人たちの将来の可能性が狭まってしまうことはありえないことだと思いつつ、自分自身が全然潰しの効かない人文系の勉強をして、結局社会人になってから時間とお金をつかってプログラミングを学び直したことには後悔はないんですよね。

何歳になっても勉強しなおして望む職に偏見なく就けるような社会にしていけるようにしていきたいし、キャリアチェンジのひとつの手段としてプログラミングスクールがもっと一般的になったらいいなと思うし、その中でFBCをいいなと思う人が増えたらいいな〜と思ってます!

Web業界はいまは社会のインフラを担っているのだから、いろんなバックグラウンドの人がいるのが当然だしより健全な姿だと思います🤗Diversity is Good!

どんなエンジニアになっていきたいか

Tebikiではペアプロ、モブプロで開発のほぼ全てを行うスタイルを現在採用しているそうです。なので私とペアワークをした相手が、楽しい、勉強になった、助けられたと思ってくれるようなエンジニアになりたいなと思います。

その上で、他の部署の方々の仕事をリスペクトし協働しつつ、プロダクトをよりよくするための提案をエンジニア目線で考え出せるようになりたいです。

社内では↑のようなエンジニアとして一人前になれるようがんばり、長い学習期間で培った社外のコミュニティとの縁も大事にしていけるように活動していこうと思います。

あとは無職期間が長過ぎて社会的信用ゼロ人間になってしまったので、失われた信用をなるはやで取り戻したいです🥺🥺🥺

Practicing Railsの良さを広めたい

はじめに

www.justinweiss.com

ちょっとずつ読んでいたPracticing Railsという本を読み終えたので、簡単な書評でも書いてみようかと思います。 日本語になっていないけど、本当にためになるよい本なのでみんな読んでほしい。

伊藤淳一 (id:JunichiIto)さん(この本の存在を教えてくれたのも伊藤さん)がいつか翻訳してくれるかもですが、その日が来るまでは英語で読んでもいいかも…👀

もくじ

Practicing Railsについて

どんな本?

Rails初学者が「楽しくRailsの学習を続ける」ためのTipsを集めた本です。 公式Docsを読め、ソースコードを読め、エラーログを読め、みたいな言説はもちろん正論なんですが、正しさだけじゃ人は学び続けられないのだ…!

誰が書いた?

Justin Weissというシアトル在住のエンジニアの方だそうです。

Ruby/Railsのカンファレンスでも多数登壇されているみたい。 詳しくはご本人のWebサイトを参考にされるとよさそうです。

どんな人におすすめ?

  • Rails始めたての人(FBCで言うとSinatraでメモアプリを作ったくらいの人)
  • rails newしたあと膨大にファイルができるのがなんか怖いと思っている人
  • 英語でなんか技術書を読んでみたいと思っている人
  • プログラミング学習のモチベーションをあげたい人

私が実際に読むのにかかった期間

1日30分くらい読んだり読まなかったりって感じで、1ヶ月くらい読んでいました。

複雑な話もなくて分量もそこまで多くないので、真面目に時間をさけば1-3日で読み切れると思います。

Practicing Railsの魅力

1. 英語が怖くない

Tests allow you to safely defer design decisions. As your design skills improve you will begin to write applications that are sprinkled with places where you know the design needs something but you don’t yet have enough information to know exactly what. These are the places where you are awaiting additional information, valiantly resisting the forces that compel you to commit to a specific design.

Sandi, Metz. Practical Object-Oriented Design (p.195). Pearson Education

www.poodr.com

↑の文章読んでみてどう思われますか? 私はめちゃくちゃこゎぃ🥺って思います。知らない単語ばかりだし文法も難しいし…

この本aka POODRは輪読会で読んでいてとてもいい本なんですが、設計についての抽象的な話が難しいということもありますが、比喩や装飾的な言い回しが多く、英語が第二言語の人にとっては認知負荷の高い本なのではないかと感じます。

その点Practicing Railsの英語はこんな感じ。↓

Testing doesn’t have to be intimidating. It turns out that with a few tips about how to write and organize your tests, testing your code isn’t so much different than writing your code. So as you build up your coding skills, you can improve your testing skills at the same time.

Justin Weiss Practicing Rails (p.118)

ワ〜簡潔で分かりやすい!終始これくらいの英語なので、ほとんどストレスを感じずに読むことができます。

著者の方が非英語圏の読者向けに書いたのかどうかは分からないのですが、少しでも読者の「怖い」「とっつきづらい」という気持ちを軽減するために平易な文章で書かれているのかなと推測しています。

余談ですが、「読みやすい英語と読みにくい英語」について面白い記事を見つけたので貼っておきます。 私は人文系出身で、言語芸術に馴染みがあるためわかりやすい言葉が全ての場面で正義だとは全く思わないですが、誰でもアクセスしやすい言葉とそうではない言葉の違いについて分析されていて面白いです。

pudding.cool

2. 無駄に写経させない

ハンズオンでアプリを作りながら学ぶ系の本ではないので、コードは文章の説明程度にしか出てきません。 ただ全く手を動かさないで一方的に教わる本というわけではなく、要件を簡潔な文章にし、そこからUIを描き出したり、そのUIから必要なモデルやコントローラーを見つけていくというエクササイズに1章が割かれています。 現実をコードに落とし込む1歩手前のモデリングの作業について、具体例を使って詳しく教えてくれている印象です。

自分の経験に当てはめて考えると、何を書いているのかもよくわかっていない時点でコードをひたすら写経してアプリを作るのは「これは単にうつしてるだけで勉強になっているのか?」という気持ちになりがちだったので、こういう段階を挟んでくれるのはありがたいと思いました。

あと写経が必須の技術書は、PCが手元にない環境で読むのがだるくなりがち(=読むハードルが上がる)なので、その点この本は寝ながらとか外出中とかにも気軽に読めるのがいいなと思いました。

3. 新しいことを学ぶこと全般について学べる

Railsを学ぶということは、Railsだけを学ぶわけではなく膨大な数の付随知識を求められることになります。

Railsに限らずプログラミングを学習していると、Aを知りたいと思っただけなのにBに関する知識を求められて、Bについて調べたら全然聞いたこともないCについて調べることになって、もともとのAになかなか辿り着けない…みたいなことってよくあると思います。

私は分からないという状態にはだいぶ慣れたとは思いますが、それでも自分の無知にがっかりしたり、学ぶべきことの膨大さに疲弊してしまうことはまだよくあります。

この本で紹介されているTipsをひとことで表すと「難しいタスクは細かく分解しろ」なのですが、新しい分野を学ぶときの心構えとしてもこのTipは応用されています。 例えばRailsが分からない!と一言で言っても、ActiveRecordがわからないのか、Rubyが分からないのか、JSが分からないのかetc...によって取るべき対処は変わってきます。そして学ぶ優先順位も変わってきます。 漠然とした「Rails分からなくてつらい」も、細かく分解すればひとつひとつは乗り越えられなくはない難易度のタスクだと分かってきます。著者は本当に何でも見事なタスク分解を繰り返し例示してくれるので、「難しくてつらい」と思ったら何でもタスク分解してみようという気持ちになってきます。

また、個人的にとても好きなのが、「何かをやるということは、それ以外の別の何かをやらないことでもある。不安かもしれないけど、やらない何かはあくまで今はやらないことであって、一生やらないわけじゃないから、一旦忘れておいて今やるべきことに集中しよう」という考え方です。

今すぐにできることには限りがある一方で今進んでいる道が正解か分からないため、あれもこれも勉強しなきゃと焦ってしまいがちなので心に留めておきたいなと思っています。

4. Tipsがとにかく具体的

最近アジャイル開発の本を複数読んでいるのですが、TDDでコードを書いていない自分をダメ人間のように感じてつらいんです…。 でもTDDで書こうと思っても設計の経験が乏しすぎて手が止まってしまい、何も書き始められないことにもどかしさを感じます。

この本は初学者の気持ちに寄り添ってくれるので、最初からTDDに取り組むことは勧めていません。一方でTDDはやらなくていいとも言っていません。

TDDだって難しいタスクのひとつなのだから分割すればいい、例えば以下のような段階を踏めば少しずつ慣れることができるのでは?と提案しています。

  1. テストなしでアプリケーションのコードを書く
  2. アプリケーションのコードを読んで、コードが壊れる可能性を列挙する
  3. すでに存在するアプリケーションのコードへのテストを書いてみる
  4. TDDで一部のコードを書いてみる

1に慣れていないうちに4を目指すのは無謀なので、少しずつコンフォートゾーンを広げていき段階的に出来ることを増やしていこうとのことです。

この本はとにかく提案される解決策が現実的で具体的なので、自分でもできそうなことに今日から挑戦してみようって気持ちになれます。

Practicing Railsの不満点

1. お高い🥲

$49なので、現在の日本円だと7000円強…?

日本の技術書も本としてそこそこ高い部類だと思いますが、それでも4000円を超えることはなかなかないので、$1が100円だとしても$49はちょっとひるんじゃう価格だなと思ってしまいました。加えて言うまでもなく円安でもあるのでとってもとっても高い(つらい)。

私は著者のメルマガも定期購読しているのですが、メルマガをしばらく読んで良さそうだなと思ったら買うのもいいかもです。

2. 若干typoがある(許容範囲内)

インスタンス変数が普通の変数になっている箇所を何箇所か見かけました。

まあコードを写経して動かす本ではないのでほとんど気にならないです。

こういうこともあるんですね👀

3. 完全なRails初心者のときの自分が読んでどう思ったかは分からない

曲がりなりにもRailsで一度自分のサービスを作った現在だからこそ、「タメになる」「役に立つ」と思えている点は否めないかもとは思いました。

UIから設計を開始するみたいな考え方は、今思うと所属していたプログラミングスクールのフィヨルドブートキャンプRailsのプラクティスでも推奨されていました。しかしRailsが提供する7つのアクションについてあまり理解できていなかった当時の私は、scaffoldで出来るような1番ベーシックなUIを想像することすらとても難しく感じました。

そのため、完全なRails初心者の方が読んだら、特に最初のころの章は難しいと感じるかもしれません。

それでも「難しいタスクを細かく分割する」や「学習ルーティーンを作る」、「新しい技術情報をどうやって・どこまで追いかけるか」など、どの学習段階の方が読んでも役に立つTipsが紹介されているので気になる章だけでも読んでほしいです。

おまけ(私の読んでる時のメモ)

英語の文章はどこに何を書いてあったのかを後から探すのが大変なので、紙のノートにいいなと思ったことを書き留めながら読みました。 まあ紙である必然性は特にないので、好きなような方法でメモしながら記憶のトリガーを作っていくのがいいのかな〜と思います。

手書きメモ

おわりに

1冊英語の技術書を読み切れたって経験があると、わりとなんでも手を出せるようになる気がするので、そういう用途でもこの本はかなりおすすめです。

私の場合はFBCの輪読会で『リーダブルコード』の原著を読んだのが英語で技術書を読む自信を持てるきっかけになったので、この本も興味のある方は有志を募って読書会をやってみるのもいいんじゃないかと思います。

教えてくださった伊藤さん、著者のJustin Weissさんに感謝です!

YouTubeを使ってシャドーイングを行い学習記録を作るアプリをリリースしました

20220912003815

はじめに

こんにちは。所属するフィヨルドブートキャンプ(以下FBC)の最終課題である自作サービスにて、Shadone(しゃどーん)というWebアプリを作成しリリースしました。 このアプリについて紹介させていただくとともに、作る過程で学んだこと、苦労したことなどを共有できればと思います。

目次

自己紹介

2020年10月からFBCで学習を続けてきたトミーと申します。

趣味は語学の勉強で、DuolingoのStreakは1205(2022年9月12日時点)です。

英語をもっと流暢に喋れるようになりたいと思っているので、語学学習のモチベーションを保ち続けるために自分が欲しいと思っていたシャドーイングのためのWebアプリを作成しました。

サービス概要

www.shadone.net

github.com

YouTubeの動画を使ってシャドーイング学習を行うためのアプリです。 フォームからURL、ループ開始・終了時間、ループ回数、再生速度を指定して動画を再生させ、その間シャドーイング学習を行うことができます。 学習が完了(=設定したループが終了)すると学習記録が作られ、学習に使ったYouTubeのURLと学習時間を集計し記録することができます。

サービス名の「Shadone」は「Shadowing」と「Done」を掛け合わせたものです。シャドーイング学習後にDONEのスタンプがカレンダーに付くというアプリの特徴を表しています。 サービスの名前が思いつかずFBCのDiscord上で募集した際、友人のudaさんが「しゃどーん」という名前を考えてくれて、最初はダサすぎて絶対イヤだと思っていたのですが、どうしてもキャッチーさが耳から離れずいつの間にか採用していました。

使い方デモ動画

野菜についている「私が作りましたマーク」的な動画です。 がんばって英語でサービスの使い方を説明しているので、良かったら見てみてください!(日本語字幕もあります)

使用技術

Vue.jsの2系を選択した理由は、使いたいと思っていたvue-youtubeというライブラリが2系にしか対応していなかったためです。 近い将来、Vue3系へのアップデートは必須で行わなければいけなくなってしまったので、2→3へのアップデートの練習素材としてこれからもメンテしていこうと思っています。

サービスを作った理由

私は毎日シャドーイングの学習を30分行っているのですが、やり方はわりと特殊なんじゃないかと思っています。

  • 1分弱の音声教材を用意
  • その音声教材を30回ループ
  • 実際にかかった学習時間と学習したコンテンツを記録

この際ネックになるのが、まず「1分弱の音声教材」がなかなか見つからないことです。以前は知人に作ってもらったMP-3の音声教材を使っていたのですが、毎日学習しているためストックはすぐに切れてしまいました。 この問題はYouTubeを使うということで解決しました。

YouTubeのABループが行えるChrome拡張機能を入れて学習していたものの、モチベーションはどんどん下がってしまい、学習しない日が増えてしまいました。 理由を考えてみると、以下が思いつきました。

  • 一旦YouTubeを開くと別の動画に気を取られて学習に集中できない
  • 学習記録を作るアナログな作業に億劫さを感じ、やりっぱなしになってしまう

思えば私は収集癖があるためか、DuolingoのStreak、GitHubの草、FBCの学習カレンダーなど、過去に作った記録を見返すことで「こんなにがんばったんだな」とモチベーションを保てていると思い当たりました。

そのため、シャドーイング学習のモチベーションを保つことに特化したアプリケーションを自分のために作りたいと考え、YouTubeシャドーイングを行なって、そのまま学習記録が勝手に作られるという機能を持つShadoneを作成しました。

こんな人に使ってほしい

  • 語学学習のモチベーションを維持したい方
  • 自分のレベルに合ったシャドーイング用教材を探している方
  • 英語以外の言語を勉強している方

私はYouTubeのループは外国語学習にしか使う予定はなかったのですが、機能を説明すると楽器やダンスを練習している方に「使ってみたい」と言ってもらえることがあったのは意外でした。あともっと意外だったのは「落語の練習にもよさそう」と言ってくれた方がいたことです。落語もシャドーイングして練習するものなんでしょうか?

なのでYouTubeの一部を繰り返して技術を習得したいと思っている人全てに使ってもらえたら嬉しいです!

技術面で苦労したこと

Vue.jsが難しい

Vue.jsにもJavaScriptにも苦手意識があったのに、アプリの大部分をVueで書く必要があったのは大変でした。 チーム開発のプラクティスでは、Rails側のデータをjbuilderを介してVue側で受け取り使用するというコードは何度も見かけましたが、自分のアプリではVue側で作成したデータをRails側のDBに送るという逆の操作を行う必要があり、データの受け渡し処理の流れを理解できていなかったためコードを修正するたびにリクエストを送り、ネットワークタブでステータスコードペイロードを確認しながら理解を進めていきました。

またVueのコンポーネント間のデータの受け渡しが必要で、以前チーム開発で使ったVuex(Pinia)を使って非・親子間のデータ受け渡しを行うつもりでしたが、Piniaのドキュメントを読み進めたところ「同一ページ内での処理の場合は使うべきではない」と記載されていたため、コンポーネントの設計を考え直す必要があったのも大変でした。 ブートキャンプのチーム開発だと、すでに大部分ができているところに機能を追加するため技術的にある程度の制約があり、その分考えなくていい面もあるのかなと思います。一方いちからアプリを作るとなると、全てが自由である分、設計からよりよいものを考え選択する必要があるという難しさがあることも学びました。結局クラシックなVueのコンポーネント間データ受け渡し手法である親子間でのバケツリレーを選択しました。

Vue.jsにはとにかく苦しめられましたが、その分力もついたかなと自負しています。機能の実装が完了し、デザインを入れるタイミングで学習記録の編集画面は消し、編集フォームを付与したSPAにしたいと思った時、その場でさほど苦労せずに編集フォームのコンポーネントを作れている自分がいて、ちょっとびっくりしました。

timezoneが難しい

コードレビューを受けている途中で、Railsでtimezoneの設定を行なっていなかったためアプリ内の時間がUTCになっており、日本時間午前0時〜8時59分(8月時点)の間に学習記録を作ると前日の日付で学習記録が作られてしまうというバグを発見しました。

このサービスは日本に限らずいろんな国の方に使ってもらえたら嬉しいな〜と思って開発したので、ユーザーに合わせてtimezoneを変更する必要があると判断したのですが、Railsアプリのtimezoneを動的に変更する方法に関する資料がなかなか見つからず苦労しました。

結局、アプリ内のtimezoneはUTCに統一し、学習記録のレコードが作成されるタイミングでブラウザから受け取ったユーザー固有のtimezoneを反映させることで解決しました。

timezoneに関しては実装についてもテストについても知らないことばかりだったので、近いうちに自分が調べたことを別記事でまとめたいと思っています。

開発を続けるために役に立ったもの

人と比べたり将来が不安で落ち込むことは多かったんですが、その度に具体的なアクションに結びつけることは気をつけていました。 私がやっていた珍しい取り組みとしては、フィードバックのためのペアプロを週1ペースでお願いしていたのと、ポイント付け会とYouTubeでの進捗報告くらいでしょうか。

週1のペアプロ

メインとなるYouTubeのループ機能が完成したあと、バグっている部分がどうしても解決できずペアプロで見てもらった際、自分では壊れていると思っていなかったRailsの基礎的な部分がガタガタで壊れているという事実を指摘され、とても自信を失い落ち込みました。

というのも、私はチーム開発のプラクティスでは色んな方にペアプロしてもらってIssueをこなしたため、その分自作サービスでは自分で調べ勉強しながら作っていきたいと思い、(そのときのペアプロまで)ほぼ人に頼らずに好きなように書いて、動くものを自分で作れるのはなんて楽しいんだろ〜!と思っていたためです。

このペアプロのあとは、頭が真っ白になってしばらく呆然としてしまうくらいには落ち込んだのですが、でも冷静になると全て言われた通りでした。とりあえず私に分かっていたのは、現時点の自分はRailsにもVueにも知識の穴がたくさんあること、卒業までになんとか目につく穴は埋める必要があること、そのために今の自分にできることをするしかないということでした。

落ち込んでいる中で思いついたのが、とにかくフィードバックループを早く回し、傷の浅いうちに修正していくという方法でした。そのため、メンターさんのご厚意に甘え、少しでもコードが書けたらペアプロをお願いしていました。6月末からほぼ週1ペースでペアプロしてもらったので、少なくとも5〜6回はしてもらったと思います。

プロのエンジニアの問題解決の姿勢を学べたので、本当にペアプロしてもらってよかったと思っています。1行ずつコードやドキュメントを読み、HTTPリクエストの中身を確認し、適宜byebugやdebuggerを使ってデバッグし、変数の名前ひとつ取っても磨き抜かれた最適な言葉を選ぶ、みたいな基本の作業を何度も根気強く教えていただき、教えていただいたことはひとりでコードを書くときも気をつけるようにしているので、まあ当社比ではあるものの少しはすごいエンジニアの定石・哲学・思想に近づけたんじゃないかな〜と思っています。

進捗YouTube

後半になるにつれあまりアップロードしなくなってしまったのですが、YouTubeでの進捗報告も続けていました。 珍しい試みだったので、メンターさんや受講生の方がたまに見て感想をくれるのがとても嬉しかったです。

少しずつアプリが作られていく様子に興味がある方は、↓の再生リストからぜひ動画を見てみてください〜!音が小さいらしいので大きめにしてもらえるといいかもです。

www.youtube.com

ポイント付け会

同じ時期に自作サービスに取り組んでいたFBC受講生4人で、週1回各々のGitHubのかんばんを使って今週取り組むIssueについて説明し、自分以外の3人にポイントをつけてもらうという会を行っていました。

これは以下の点でとてもよい取り組みだったと自負しています。

  • 情報交換の場になる
  • 自分のIssueについて他人に説明するため、やるべきことがよりクリアになる
  • 励まし合える
  • 他の人のよいやり方を学ぶことができる

自作サービスのプラクティスではどうしても孤独に陥りやすいという話をFBCを卒業した先輩方から聞いていましたが、私はこの会があったためか、孤独を感じることはほとんどなかったです。

「何もわからないし何もやりたくない」みたいなただの愚痴を聞いてもらったり、同じ技術を使った経験のある方からアドバイスをいただけるような面でありがたかったのはもちろん、自分の無知に直面し自信を失っていたとき、(すでに乗り越えた課題について)自分の経験をシェアしたことで他の方の役に立つことができ自信を取り戻すことができたのが何よりも心の支えとなりました。

アジャイルサムライ』輪読会

開発を始めた途中で開催された輪読会に参加していたのですが、自分がちょうど個人開発を行っているタイミングで読んだため、机上の空論としてではなくより具体的な「今日から使えるTips集」として読むことができたと感じています。

shop.ohmsha.co.jp

私のサービスは開発当初想定していたよりも1ヶ月完成が伸びてしまい、最初の締切を過ぎた時点でもやるべきことが山のようにあり、途方にくれていました。

このままどんどん後ろ倒しになって、いつまでも卒業できないのかもしれないと絶望していたのですが、ちょうど輪読会で8章(「アジャイルな計画づくり: 現実と向きあう」)を読み、計画が予定通りにいかないのは当たり前で、ままならない現実のなかでいかにやるべきことを成すかがアジャイル開発だと学びました。

そうじゃなくて、抱えている悩みが、とにかく早く成果をあげることなんだとしたら、今のプロジェクト計画を捨てよう。そして新しい計画を、信じることのできる計画を立て直すんだ。あたかもゼロからアジャイルな計画を立てるかのように進めよう。マスターストーリーリストを作って、リストの規模を見極め、そこに載せているフィーチャに優先順位をつける。そうしたら、最小限の機能でいいから、とにかくお客さんのところへフィーチャを届けよう。全体から見れば一部であってもいい。とにかく仕事を完了させるんだ。

Jonathan Rasmusson『アジャイルサムライ――達人開発者への道』西村直人・角谷信太郎 監訳/近藤修平・角掛拓未 訳、オーム社、2011年、170頁

↑を読んで、自作アプリの完成に必要なのは能力や予算ではなくて「締切」そのものだったのか、締切をいつまでも伸ばしていいものだと心のどこかで思ってるから優先順位もつけられないし完成しないんだ…!と目から鱗が落ちた気持ちになりました。

それからは再設定した締切は動かせないものとみなして、タスクの優先順位を見直したり、不安のある分野は積極的に質問するように意識を変えたことで、締切までにサービスをレビュー依頼できる状態まで作り込むことができました。

このように週1回のこの輪読会は、自分の行っている開発プロセスや開発者としての姿勢を、本の文章や輪読会での会話を通じて反省し、改善していくためのまたとない機会だったなと思います。

本に書いてあることの一部については「こんなこと自分が出来るようになるとは思えない」という気持ちになることもありましたが、頻繁なペアプロフィードバックループを素早く回す、他人にIssueのポイントをつけてもらうみたいなアイディアは、この本を通じて得た知見を自分の開発に取り入れる過程で生まれたものだと思っています。

余談: Discord Botを作った経験

自分が使いたいからという理由で1年前にDiscord Botを作ってリリースした経験には、作った当時には予想もできなかった形で勇気づけられたなと思います。

Railsアプリを0から作るのは今回が初めてだったので、取り組み始めた時点で全体像は想像できなかったし、作る中でも自分の知識・能力に大いに疑問が湧きましたが、「でも1年前はあんなに何も分かってなかったのに、いろんな人の助けを借りながらDiscord APIやdiscordrbのドキュメントを読んでデプロイまでできたんだから何とかなる」と思えたので完成まで至れたのだと思っています。

github.com

だから今回作ったShadoneも、ごく小さなサービスではありますが、これから先困難な問題を前にして暗中模索状態になったとしても、「あのときもなんとか作れたんだから大丈夫」と思える北極星のような存在になるんじゃないかなと期待しています。

さいごに

こうやって振り返ってみると、自作サービスのプラクティスは、チーム開発のときに初めて触れたアジャイル開発の手法を学び直し、自分なりの解釈で実践してみた期間だったという印象が強いです。 コードを書いて動くものを作ることはもちろん面白かったのですが、それ以上に自分で自分のモチベーションや生産性を上げるための具体的な工夫をすることがとても楽しく、やりがいを感じました。

FBCで2年近く学習する中で、ずーーっと「私はエンジニアに向いているんだろうか?」という疑問を持ち続けてきたのですが、チーム開発を終えても自作サービスを作り終えても、自分がエンジニアに向いてるのかはぜ〜んぜん分かりませんでした笑。

むしろ自作サービスを作る中で、自分が何も分かっていなかったということを思い知ったり、すごいエンジニアの人の考え方を目の当たりにし、自分が向いてない理由は100個くらい思いつくようになってしまいました。Web開発は楽しいけど厳しい世界だ!

でも仮に私がエンジニアに向いてないというのが客観的事実だとしたら、そんな人でも0からWebアプリを作り切れるような開発の方法論があるということはすごいことだと思います。

なので例え私がエンジニアにならなくても、どんな職種でどんな働き方をしても、アジャイル開発手法を含めエンジニアリングについて学んだことは無駄にならないと思っています。 むしろ就活を含む、この先の人生の問題解決の場で最善の選択をするための道具を手に入れることができたので、これから先どうなるか全然分からないしめちゃくちゃ怖いけど、持ち前の蛮勇で自分にとってより良いと思える道を進んでいこうと思っています!

最後に、コードレビューを担当してくださり日報や質問タイムでたくさん疑問に答えてくださった駒形さん、アイディア出しの時点からたくさん励ましてくださりデザインについては何時間もペアプロしてくださった町田さん、根気強く毎週のペアプロに付き合ってくださった梅本さん、なぜか私の作ったTシャツを買ってくださった赤塚さん、ポイント付け会でお世話になったParuさん、ガラムマサラさん、Sakiさん、『アジャイルサムライ』輪読会を主催してくださったいっしーさん、サービス名を考えてくださったudaさん、その他長い間私や私のサービス開発に関わってくれたフィヨルドブートキャンプの皆さんに感謝です!

suzuri.jp

ShadoneTシャツ良かったら買ってねッ

プログラミング初学者向け 英語のおすすめコンテンツ

はじめに

最近少し時間に余裕ができて、英語の勉強をしています。

プログラミング始めたてのころ、プログラミングの学習も英語でしようと思ってたんですが、あまりにリソースの数が膨大でどれが現在の自分に適しているのか分からなくて挫折した記憶があります。

今は2年くらいプログラミング学習を続けて、自分に必要な情報が何なのかが分かってきたので英語学習用のプログラミングに関係するリソースを探すのもうまくなってきました。個人的に面白い、おすすめ!と思ってるコンテンツをPodcastYouTube、本、その他のジャンル別にいくつか紹介してみようかと思います〜。

もくじ

対象読者になりそうな人

  • Web開発に興味がある人
  • FizzBuzzくらいのコードは書いたことがある人
  • 英語学習に興味がある人(高校レベルくらいの英語が分かるとよさそう)

おすすめコンテンツ

Podcast

The Bike Shed

www.bikeshed.fm

FactoryBotで有名なthoughtbot社のエンジニア(コンサルタント?かも)の方がやってる番組。トピックは技術の話と開発文化の話が半々くらい(後者の割合が高め)。 Railsでの開発やペアプロ、勉強会の話など自分の興味に近い話をされているため面白いです。英語は難しいのでスクリプトを読みながら聴いてます。

Command Line Heros

www.redhat.com

Linuxディストリビューションで有名なRedHat社のPodcastCode NewbieのSaron Yitbarekがホスト。この方は声がクリアで英語も聞き取りやすいので、彼女がホストする他のPodcastもおすすめです。 Web開発やプログラミングの歴史を当事者インタビューを交えながら知ることができるので、新しい言語を学習するときとかに「これCommand Line Herosでやったやつだ〜!」という体験ができて楽しいです。

YouTube

The Net Ninja

www.youtube.com

FBCの友人のあんすとさんが激推ししていて知ったYouTubeチャンネルで、FBCのVue.jsのプラクティスではさんざんお世話になりました。 説明がすごく分かりやすい。英語はイギリス英語なのかな、ちょっと私は聞き取りが難しいと思うこともありますが字幕をつければ問題ないです。

Colt Steele

www.youtube.com

UdemyのJSの講座で有名な講師の人のYouTubeチャンネル。アメリカ英語に耳馴染みのある方には、この方の話す英語はすごく聞き取りやすいと思います。飼われている猫が出てくるのでUdemyの講座の方もおすすめです。

The Art Of Readable Code

www.oreilly.com

以前輪読会で読んだのですが、今読み返してみても英語も内容も癖がなくてすごく読みやすい良い本だな〜と思います。

この本に登場する難しい単語、全てプログラミング関連文書に固有のものだったりするので、この本をざっと読んで知らなかった単語をインプットしたらかなり不自由なく技術文書が読めるようになるんじゃないかな〜と思います。

Practicing Rails

www.justinweiss.com

チェリー本の著者でFBCメンターの伊藤淳一さんにおすすめいただいた本(チェリー本の巻末のおすすめ本としても紹介されてます)で、最近読み始めました。 Rails初学者でも今日から使えるTipsがたくさん載っていてためになるし、英語もかなり読みやすいです。リーダブルコードより読みやすいかも。

thoughtbotの出してる本

まだちゃんと読んだことはないんですけど、The Bike Shedを聴いていてthoughtbotが出してる本は全てオンライン上で無料でpdfが公開されていることを知りました。

個人的にはこの2冊が気になっています。Testing RailsRSpec初心者にもとっつきやすそう。

その他

Ruby on Rails Guides

guides.rubyonrails.org

日本語翻訳のRailsガイドは、内容が難しいときは目が滑ることががあり、オリジナルの方が頭に入るような気がします。 英語は癖がなくてとても読みやすいと思います!Railsに馴染みがある方は英語が苦手でも読めると思います。

Upcase

thoughtbot.com

またthoughtbotのコンテンツです(The Bike Shed経由でthoughtbotのことが大好きになってしまったので、ブログとかYouTubeもチェックしています…)。 プログラミングブートキャンプを卒業したレベルの人がレベルアップするための、Q&Aフォーラムや動画教材を中心にした学習リソースみたいです。 昨日見つけたサービスなので隅々まで確認したわけではないのですが、私自身がこのサービスが想定するユーザーに近そうなので、就職に向けた学習にちょうどよさそうって思っています。

プログラミングに関するクイズがフラッシュカードでできるのが面白い。 動画は英語の字幕やスクリプトが見つからないので少しだけハードル高めかもしれません。

さいごに

英語のプログラミング関係のコンテンツは山のようにあるので、ちょっとでも難しい・自分に合わないと思ったら別のものを探すのがいいんじゃないかな〜と思います。 私もPodcastはいくつも聴いてみたけど、結局毎回聴いているのはThe Bike Shedだけかもしれない…。

あと英語かプログラミングの前提知識の量の違いによって、面白いと思ったり理解できるコンテンツは全然違うと感じています。

↑のリストはどちらかというと、英語の知識が多めでプログラミングの知識が少ない人間によるチョイスなので、逆の立場の方だと全然違うんだろうな〜。