Sakiのプログラミング学習ブログ

フィヨルドブートキャンプ生。プログラマー転職を目指して学習中。輪読会が好き。最近LTの楽しさに目覚めた。

フィヨルドブートキャンプのシステム開発プラクティスを卒業したので、振返りをしました

はじめに

 1月末〜システム開発のプラクティスに入り、先日自分が作った全てのPRがマージされたので、振返りを書きました。

途中、自作サービスのエレベーターピッチ&ペーパープロトタイプ作成や技術検証に取り組んだり、1月中旬〜3月中旬の2ヶ月間のみ、働いているパートのシフトを週4から週5に増やしたり、FBC内でゴールデンウィークに開催されたEverydayRailsという書籍の短期集中輪読会に参加したり、とこのプラクティス以外にも色んなことに取り組んでいたのもあり、想定していたよりも時間がかかってしまいました。

システム開発に取り組む中で、たくさんの学びや気づきがあったので、「最近月ごとの振返りも書いていないし、自作サービスの開発に本格的に着手する前に、しっかり振返りをしておきたい。今の自分の気持ちは今しか書けないので残しておきたい!」という強い気持ちがあったので書きました。
また、これからシステム開発のプラクティスに入られる受講生の方が、システム開発がどんなものかを知る助けになれば嬉しいです。書きたいこと・伝えたいことを全部詰め込んだら、2万字を超えとんでもない文量になってしまったので、気になった箇所をつまみ食いして読んでいただけたら嬉しいです🙏

目次

そもそもシステム開発ラクティスとは、どんなことをするのか

 システム開発は、FBCのカリキュラム(プラクティス)の、「開発に参加して PR を送りマージする」 の部分に当たります。

学習内容 | FJORD BOOT CAMP(フィヨルドブートキャンプ)より引用

日報の作成・提出、質問の投稿・回答、イベントのお知らせ・申込などでいつもお世話になっているFBCのWebアプリの開発をチームで行います。
OSSなので、リポジトリはこちらで公開されています。もしアプリを使っていて、「あれ?これはもしかしてバグかな?」とか「ここの挙動がこうだったら使いやすいと思うな〜」といったことがあれば、システム開発ラクティスに到達しているかどうか関係なく、誰でもissueを立てたり、PRを作成することができます。

github.com

どのissueを優先して着手していくか、誰にどのissueが割り振られているのかといったissueの管理は、こちらのかんばんでされています。

issueには完成までにかかる時間に応じてポイントが振られることになっており、20ポイント分のPull Request(以降、PRと記載)がマージされれば、このプラクティスは完了となります。
また、自分で作ったPRは、必ず同時期にシステム開発に取り組んでいるFBC受講生の方1名とkomagataさんにレビューしていただき、2名のレビューを通ったらマージされるルールになっています。

毎週水曜日に1時間ミーティングがあり、以下のことを話し合います。

  • この1週間で自分の担当issueについて、やったこと・困っていること・難しかったことを、デモ(自分が作った機能を実際に画面共有して見せること)を交えながら共有する
  • issueに取り組んでいて疑問に思ったことを質問する
  • 次の1週間で取り組むissueを、割り振っていただく
  • 割り振っていただいたissueのうち、ポイントが付いてないものは全員で何ポイントか見積もる

気になる方は、ラジオ参加(マイクオフ、カメラオフで参加)自由なので、見学に行ってみるといいと思います。2022年6月現在は、毎週水曜の15:00-16:00と22:00-23:00に開催されています。(1日に2回開催されていますが、実際にプラクティスに取り組む際は、好きな方の時間帯に出席することになります。)

私が作成したPR一覧

Point 内容 Issue PR
1 ユーザー > 質問 のページタイトルを変更 #3709 #4075
1 ブックマークのタブに合計数を表示 #3749 #4088
1 メンター、アドバイザー、管理者はダッシュボードの学習時間(水草)を非表示にした #4110 #4211
2 管理者でログインしたときに、ユーザー個別ページに相談部屋へのリンクを表示した #4094 #4303
2 ユーザー情報変更ページで、管理者の場合はコース変更ができるようにした #4138 #4596
3 categories.positionを削除した #4245 #4641
2 js-choices-single-selectを使っている箇所において、Railsで渡したデータの並び順がJavaScriptに渡っても保持されるようにした。 #4746 #4748
2 [abstract_notifier] sadアイコンの通知を置き換えた #4682 #4889
5 未完了の提出物一覧を担当メンターで絞り込めるようにした #4853 #4954
2 メンター向け提出物一覧 >未完了 > 未返信 の一覧で表示される提出物を変更した #5028 #4954
2 大名エンジニアカレッジ特有の機能・フラグを削除した #4769 #5012
合計23

レビューしたPR一覧

Point 内容 Issue PR
1 ユーザー > 日報 のページのタイトルを変更した #3705 #4061
1 ユーザー > コメント のページのタイトルを変更した #3707 #4073
1 相談部屋一覧において、ローディング中にプレースホルダが表示されるようにした #4091 #4111
3 アドバイザーでログイン時、自社の研修生のプロフィールには「自社研修生」と表示されるようにした #2992 #4176
2 Vue.jsで表示されるページにおいて、ページネーションをクリックしたら、そのページの先頭に飛ぶようにした #2677 #4217
2 一度公開したお知らせを、誰でも公開の状態で保存できるように変更した #4127 #4215
1 就職関係のイベントの場合、企業研修生には参加不可と表示されるようにした #4216 #4272
0 お知らせ作成ページに不要な公開ボタンを表示しないようにした
(PR#4215で発生したバグ修正)
#4327 #4328
2 質問投稿時の通知に、質問のタイトルが表示されるようにした #4285 #4350
3 提出物一覧のページの各タブの並びを昇順にした #4312 #4399
1 左メニューの相談ボタンを全員に表示させた #4467 #4560
3 ニコニコカレンダーの日報未投稿の日付をクリックしたら、その日の日報作成画面が表示されるようにした #3295 #4550
1 カテゴリー並び替えページの、URLスラッグの行を削除した #4563 #4639
1 .eslintrcファイルに拡張子を付けた #3508 #4649
2 企業個別ページ > 提出物一覧において、ローディング中にプレースホルダが表示されるようにした #4669 #4706
1 管理画面の企業一覧の企業名に、企業個別ページのリンクを貼った #4665 #4737
2 相談部屋で管理者から受講生にコメントをした時の、通知メッセージを変更した #4409 #4778
1 企業一覧のリンクを、企業個別ページの企業情報タブに追加した #4768 #4785
1 相談部屋のボタンを削除し、タブを設置した #4155 #4830
5 定期イベントの一覧、個別、作成、削除を作成した #4537 #4862
1 日報一覧のtruncateを削除し、日報タイトルを全て表示するようにした #4835 #4911
2 提出物の担当通知の実装を、abstract_notifier(gem)に置き換えた #4681 #4823
1 企業のユーザー一覧ページに、企業一覧リンクを貼った #4773 #4943
2 Q&Aを削除する際に表示する確認ダイアログの文言を変更した #1531 #4981
1 企業の提出物ページに企業一覧リンクを貼った #4775 #4997
1 フッターの「参考書籍一覧」リンクの文言と位置を変更した #4956 #5001
1 リリースのために定期イベントのタブをコメントアウトした #4925 #5034
合計43

 issueに着手していた時に作業していたことの詳細は、Notionのチーム開発の作業ログ置き場に都度書くようにしていました。
基本的に自分がやってきたことを復習するため、振返るために書きましたが、「こんな感じで進めていた人もいるんだ~」と参考になれば嬉しいです🙏

システム開発に入る前の心境&入ってみてどうだったか

システム開発が近づくにつれ、嬉しい反面、不安も感じていた

 プラクティスが進み、システム開発がじわじわと迫ってくるにつれて、とても嬉しい反面、不安も感じていました。 FBC卒業生の方々には、「チーム開発が一番楽しかった」「たしかにこれまでの課題よりも難易度は上がるが、今までやってきたプラクティスでの学び・経験をフル活用するので、プラクティスを乗り越えてきた人なら大丈夫。」といったお話も伺っていましたが、「それでも自分の場合はだめかもしれない」と根拠のない不安を感じることもありました。
そのため、「今までやってきたプラクティスを復習したりもっと深く学んでから、システム開発に挑みたい」と思う時もありました。 ポケモンで例えると、「今の手持ちのポケモンでは勝てる気がしないので、ジムリーダーに挑戦する前に、草むらでレベルアップしてから挑みたい」みたいな心境でした。

実際に入ってみたら、想像していたよりも大丈夫だった

 実際に開発に入ってみたら、「全く何も分からなくて、手も足も出ない。詰んだ。」ということは、無かったです。
たしかにこれまでのプラクティスの課題で作ったアプリよりも、bootcampアプリのコードはずっと量も多くて複雑ですし、APIjbuilderといった、ここで初めて触れるものもありました。自分が作りたい機能の実装方法が思い浮かばず、「どこから手をつけていこう」と途方に暮れることもありました。

しかし、土台となる知識や考え方は、これまでのプラクティスで身についているなと感じました。
システム開発に入る前のプラクティスでは、「この知識は実務でどういう時に使うのだろう」と、あまり実際のお仕事で使う時のイメージが湧かない時もありましたが、開発に入ってみると、「あのプラクティスでやったことが、この機能の実装で使われてる!」「あの知識はここで大事だったのか!」という伏線回収をずっとしている感じでした。

「今までのプラクティスの知識は、実際の開発でどう活きてくるか」は、FBC卒業生のアルトさんがLTで発表してくださっているので、とても参考になると思います。

alto-i0.hatenablog.com

開発に入った頃の失敗いろいろ

 開発に入ったばかりの頃は、初めてのことばかりで慣れておらず、色々と失敗もしました。

例えば、

  • これまでコードを見ていただく側(レビュイー)しか経験したことがなかったので、GitHubのレビュワーの操作がよく分からず、初めてレビューしたPRで、Approveした後に間違えて「Re-request review」ボタンをクリックしてしまった。(本来はレビューをお願いした人が、もう一度同じ人に見ていただく時に押すボタン)

  • 開発環境とテスト環境の違いが分かっていなかったので、db/fixturestest/fixturesの違いも分からなかった
  • FBCシステム開発では、rebase方式を採用していて、merge方式は行わないことをあらかじめFBC内のドキュメントに書かれていて、それを読んだことがあったのに、間違えてmerge方式でコンフリクトの解消を行ってしまった。
  • かんばんの自分のissueのタスクボードを、ステージング環境で動作確認して大丈夫だったら「完了」に移動すると勘違いし、移動させてしまった。本当は「完成」に移動させるのは、本番リリースしてから動作環境確認できたら移動するルール。
  • レビューで、OKだと思って通したら、次の日テストとLintが落ちていたことに気づいた。すでにkomagataさんにレビュー依頼の連絡が行っていたので、慌ててご報告した。

というように、最初色々な失敗をしたので、落ち込むこともありました。

ですが、そういった失敗も自分の分報チャンネルに逐一書いていて、同じ時期にチーム開発に入った方に「自分も同じところを勘違いしていました。」 など仲間の方からコメントいただいたり、 すでにシステム開発ラクティスを終えられたFBC卒業生の方に、アドバイスをいただけたので、そこまで落ち込まずに前向きに行動を変えていく方にシフトしていくことができました。

GitHubの操作でミスをした時に、FBC卒業生の方からいただいたコメント

勿論、失敗しないように事前にしっかり調べることは大事ですが、起こしてしまった時は、反省をしっかりしつつ、気持ちはひきずりすぎないようにして、「次同じ失敗をしないようにするには、どういう工夫ができるか」、これからの行動をどうするかに意識を向けるようになりました。

学んだこと

名前重要を改めて実感

 コードを書く時に、まず自分で一から書く前に、実装するのに使えそうなメソッドが無いか探すのですが、まずメソッド名を見て、「これを使えばほしい情報を取得できそう」と判断して、メソッドの中身のコードを見るので、「名前重要」の大切さを実感しました。
これまでも、Rubyのプログラムの課題をやっていて、「名前付けが下手で、時間を置いて読んだら、自分で書いたコードなのにメソッドの中身が何をしているか分からなくなってしまった😂」ということがありました。ですが、自分一人だけでなくチームで開発するという経験をしたことで、他の人から見ても分かりやすいコードを書く意識の大切さをより実感しました。

コードを書くよりも、読んでいる時間の方がずっと長い

 これは、システム開発に入る前から、メンターさんからよく聞いていた言葉でしたが、本当にその通りでした。
自分が担当しているissueを実装するにあたって、書く前にまず、既存のコードがどうなっているかを理解する必要があります。
例えば、コントローラにインスタンス変数が元々定義されている時、自分のやりたい実装にも使い回せるものか、追記する必要があるかは、コードの中身を読んでみるまでは分かりません。

レビュー依頼された時は、いつ見られるかこまめに連絡する

 自分の作成したPRを、同じ時期にシステム開発をやっている、任意のFBC生1名に、レビューをお願いすることになっています。 お願いされたレビューをなかなか返せず、「レビュー依頼させていただいているのですが、どうなっていますか〜」とご連絡をいただいたことがありました。
最初の頃はレビューを終えるのにどれくらいの時間がかかるのか見積もりができず、「少なくともこれくらいまでには返せるだろう」と思っていたら予想が外れて、予定よりも返すのが遅くなってしまうことがありました。

そのため、もちろんすぐにレビューをお返しするのが一番なのですが、3月末までは、働きながらシステム開発をやっていて、すぐにお返しできなかったり、手持ちのレビュー依頼をすでに複数持っていたりすることがあったので、時間がかかりそうな時は、「すみません、返すのが○日くらいになりそうなのですが、それでもよろしければ、ぜひレビューやらせていただきたいです」というように連絡を取るようになりました。

https://github.com/fjordllc/bootcamp/pull/4215 より

人によって、レビューをいつ頃までに返してほしいかの考え方は異なりますし(もちろん早ければ早いほど良いですが😅)、レビューを依頼した側から、「早くレビューしてほしい」とか「時間がかかりそうなので他の方にお願いしますね」などとは言いにくいと思ったので、「もし▲日にお返しだとちょっと遅いな〜ということであれば、他の方にご依頼いただけましたらありがたいです。せっかくご依頼くださったのに申し訳ないです。」とお伝えするようになりました。


振り返って考えると、お仕事は自分一人で完結するものではなく、ベルトコンベアのように、誰かが止まるとその後ろも止まってしまうので、なるべくこまめにコミュニケーションをとって、流れが止まらないようにすべきだったと思います。
アジャイル開発の考え方も、小さく作って早くユーザーに届けて、反応を見てまた開発を進めて、という風に開発サイクルをどんどん回していくという考え方なので、エンジニアとして働かせていただけることになったら、「早くユーザーの元に届けるには、今自分がどう動くのが最適か」を意識して仕事せねばと思っています。

心がけていたこと・やって良かったこと

大声で作業する

 システム開発ラクティスに入る前から、machidaさんから、「システム開発ラクティスは、周りに自分の状況を伝えたり、詰まった時に素直に頼れたりする人が、順調に卒業していく」と伺っていたので、分報や日報に作業していることを実況しながら取り組むようにしていました。
こちらは、machidaさんから教えていただいた参考記事です。

blog.studysapuri.jp

私の場合は、システム開発に入る前から、自分の分報チャンネル で作業していることやその時の気持ちを、逐一書きながら課題に取り組んでいたので、とくに変わらず続けてやっていたという感じでした。
詰まった時に、この分報チャンネルで数えきれないほど何度も助けていただき、コメントで教えていただいたり、「画面共有してもらって一緒に見ましょうか?」と声をかけていただいたりしました。助けてくださった方々には感謝の気持ちでいっぱいです🙏 本当にありがとうございました!

vueファイルがどのページで使われているか探す方法を教えていただいた時のコメント

CIが通らなくて困っていた際に助けていただいた時のコメント

作業したことを記録しながら進める

 分報とはまた別に、Notionに、取り組んだissue/レビューしたPRごとにページを作って、作業ログを書くようにしていました。
具体的には、調べて理解したこと、分からないこと、自分で考えた実装のロジックや、何が分からないか分からない時は、その時分からないことを全部書き出して現状整理、などなど何でも書いていました。

これを始めたきっかけは、FBC卒業生のikuma-tさんがLTで発表されていたのを聞いて、自分もやってみようと思ったためです。
始めた時の詳細はこちらの記事に書いています。

saki-htr.hatenablog.com

これのおかげで、あんまり実装が進んでなくても、「あんまり進んではないけど、今日もがんばった!」と思えました。
issueに取り組んでいると、「この機能をどうやったら実装できるか」「このテストはどう書けばいいのか」という、分からないことと向き合っている時間が長いです。
そしてできなかったことができて「やったー!」と思っても、すぐにまた分からないことがやってきて、調べるの繰り返しです。 分からないことが出てくるたびに、「自分でできるのか」と不安になるので、本当は進んでいるし、できたこともあるのに、目の前の分からないことに囚われて落ち込む時もありました。
そういう時に、作業ログを見直して、「1週間前はこれも実装できてなかったんだ」「3日前はこれも分からなかったんだ」と、自分の成長を実感できました。

ミーティング前に、デモの準備と報告内容の整理をする

 週1のミーティングでは、必ず15~30分前にはデモのための画面の用意と、報告内容の原稿作成をしていました。原稿を用意していたことで、緊張していても、落ち着いて報告ができ、「伝えようと思っていたのに忘れた😨」という事態も防げました。

事前にMacメモアプリに書いていた報告内容

分かりやすいデモをする

 ふりかえり・計画ミーティングのやり方のドキュメントに、「今週やったissueの報告は、プログラマー以外にもわかるように説明しましょう。」とあったので、デモも見やすいように工夫していました。
例えば、以下のPRのデモをする時は、タブが2つあり、全てタブと未返信タブ両方の表示結果をお見せする必要があったのですが、1画面だと、一度に片方のタブの表示結果しか見ることができないので、画面を分割して同時に2つ共お見せしました。(この時machidaさんに「見やすい」と仰っていただけて嬉しかったです🥳)

github.com

画面を2分割して同時に両方見せた時のデモ画面

仕様について疑問に思ったら、すぐに確認する

 自分の担当issueの仕様について疑問に思ったことは、すぐに質問をして認識のすり合わせをしていました。 雑談タイムをやっている日であればそこで確認して、issueのコメントに記録し、やっていない平日や土日であれば、issueのコメント上で質問していました。

システム開発ラクティスに入る前から、メンターさんに

相手が言ったことを認識の擦り合わせをしないで、「こういうことか!」と思って、全部作り上げてプルリクを送ると「違うそうじゃない」となりがち。
インドカレー」だと思って作ったら、相手は「ビーフシチュー」と思っていることも。
お互いの認識が同じということはごく稀で、認識が違うのが当たり前の毎日

と教えていただいていたので、出戻りを防ぐためにも、仕様で気になったことはこまめに聞くようにしていました。
(参考:顧客が本当に必要だったものから学ぶこと | キャスレーコンサルティング株式会社)

https://github.com/fjordllc/bootcamp/issues/4853 より

ただ、以前ミーティングで、「仕様についてどれくらい自分で考えて、どれくらい確認すればいいのか」という質問が挙がった時に、machidaさんが

一旦自分の考えで実装してみたのを「こんな感じでいいですか」と確認してもらう方法で進める方が多い

と仰っていたので、人によってやり方は違いますし、私も自分のやり方に固執せず、臨機応変にアップデートしていこうと思っています。

自分の意見を持つ

 上述の通り、仕様について疑問に思うことはmachidaさんとkomagataさんに適宜確認していたのですが、エンジニアとして働くことになったら、より主体性が求められ、自分の意見を持つことが大事だと考えていたので、「どうすればいいですか」という丸投げではなく、自分の考えも添えて質問するようにしていました。

仕様について、ユーザーの気持ちをあれこれ想像して考えるのは楽しかったです。また、「こういう理由で、この仕様にしてほしい」と教えてくださるので、とても勉強になりました。

https://github.com/fjordllc/bootcamp/issues/4094 より

テキストコミュニケーションは、受け手の立場に立って書く

 システム開発ラクティスでのコミュニケーションは、テキストでやり取りする割合が多いです。(これまでもテキストコミュニケーションが主だとは思いますが😅)
例えば、仕様について確認したい時に、雑談タイムがやっていない日はGitHubのissueにコメントして聞いたり、自分が作ったPRのdescriptionに、概要・変更点・動作確認手順を書いたり、レビューのやり取りは基本的にPR上のコメントでやり取りをします。

自分の担当issueや作ったPRについては、自分が一番状況を理解しています。理解している側が分かりやすく丁寧に書いた方が、受け手の負担が少なく済み、より少ない時間で効率的に仕事を進められると思ったので、そのようにしていました。
具体的には、以下のことをやっていました。

質問したいことが複数ある時は、最初に「◯点質問したい」と個数を書く

https://github.com/fjordllc/bootcamp/issues/4094 より

見出しをつける

最後まで読まないと内容が分からないのは受け手にとって読みづらいと思います。見出しをつけることで、何を伝えたいかが最初に分かり、「この下の文章にはだいたいこういうことが書いてある」とイメージしやすいと思ったため、コメントに見出しを付けるようにしていました。

https://github.com/fjordllc/bootcamp/issues/4094 より

descriptionには詳細を丁寧に書く

 説明が不十分だと、レビュワーが理解しづらいので、スクリーンショットの変更点を必ず赤い枠で囲ったり、変更点が多い場合は、マークダウンのTableを使って見やすくしたり、動作確認手順を詳細に書くようにしていました。

ちなみに私が作ったPRの中で、一番気合いの入ったdescriptionはこちらです(笑)

github.com

これとほぼ同じ作業を行うであろうissueがもう一つあるため、そのissueの担当になった方のためにも、なるべく理解しやすいように丁寧に書くことを心がけました。ちなみにこちらです。

practices.positionを削除したい · Issue #4246 · fjordllc/bootcamp · GitHub

レビューでは、テキストより口頭でのコミュニケーションが適している時は、ペアレビューの時間をいただく

 以下の3つのPRは、FilesChangedの数が多い等重ためのPRだったので、ペアレビューのお時間をいただきました。

はじめはペアレビューってどんな風に進めていけばいいんだろう💦と進め方が分からなかったですが、何回か重ねていくうちに、コツが掴めてきました。

具体的には、

  • 一緒に動作確認をして、挙動がおかしい点や自分のローカル環境と異なる点があったら2人で原因を調べる
  • RailsとVueの両方を書いていて、コードの流れの理解が難しいPRは、大まかなコードの流れや各コードが何をしているかを説明する
  • レビュワーの方から質問していただいて、それに答える

というようなことをやっていました。これはレビュワーの方によって聞きたいことが異なるので、事前に「これをやるぞ!」とガッチリ決めておくというよりは、当日臨機応変に進めていました。

ペアレビューを何回か経験したことで、開発メンバーの方とコミュニケーションを取る時に、テキストと口頭どちらが適しているかの判断がしやすくなりました。また、ペアレビューでお話したことは、GitHubのPRにも書いて必ず残すようにし、他の開発メンバーや後からこのPRを見る方が話した内容を把握できるようにしていました。

レビューする時は、良いと思った所を伝える

 レビューをやり始めた当初、PRをApproveする時に、何とコメントしてお返しすればいいか迷ったので、「LGTMです〜」と返していました。LGTMとは、「looks good to me」の略で、「私は良いと思います〜」的な意味です。(参考:「looks good to me」)
他の方はどんな風にコメントされているのかな〜と、色んな方のPRを見ていく中で、良いと思った部分を褒めている方がいらしたので、真似をしました。
レビューでどんなことを書くかの考え方は、人それぞれだと思いますが、個人的には、「チームで開発をしているので、開発メンバーの良いと思った所は積極的に伝えたい」と思っているので、メンバーのPRの良いと思った所や、自分が知らなくて勉強になった所を伝えるようにしていました。

https://github.com/fjordllc/bootcamp/pull/4823 より

https://github.com/fjordllc/bootcamp/pull/4215 より

"こうすればよかった"と思うこと

PRが、issueの範囲を超えそうだったら、別PRに切り出す

以下のPRを作成した時に、後から振り返ると、PRを分けるべきだったと思いました。

github.com

これは、categories.positionが使われている部分を削除するissueだったのですが、取り組んでいる過程で、「削除した後、この箇所の表示内容や並び順はどうしたらいいのだろう?」と疑問に思う箇所がありました。
ミーティングで質問したところ、2箇所、カテゴリーの表示内容や並び順を変えることになりました。すぐに実装できるだとうと思って、そのまま同じ一つのPRで作成しましたが、今振り返ると、

  • categories.positionが使われていた部分を削除するPR
  • 表示内容や並び順を変更するPR

に分けるべきだったと思いました。
このことについて日報にかいたところ、メンターさんから、

アジャイル的にはフィードバックサイクルを速くまわすことが善なので、「細かい単位でフィードバックを受けられるようにする」というのは意識してみてもいいかもしれません。

と教えていただきました。
このissueを終えるまでは、PRの範囲について考えたことがなく、「なんとなく1つのissueにつき1つのPR」という思い込みがありましたが、

  • フィードバックサイクルを速く回すことが大事なので、diffが大量になったり、issueの範囲を超えそうな場合は、もともとのPRはレビュー依頼に回し、追加の実装は別PRで行うことも検討する。
  • 変更箇所が多かったり、複数の仕様変更が一つのPRにあると、レビュワーが確認するのが大変なので、自分のPRがレビュワーや後から見た方にとって見やすいかも考える。

という視点を得ました。

自作サービスのアイデア出しを、システム開発に入る前にやっておけばよかった

 自作サービスの案出しを日頃からやっておくことの大切さは、FBC内の色んな所で言われていることですが、本当にその通りでした。
私はシステム開発で10pt程マージされた段階で、元々考えていた自作サービス案のエレベーターピッチ作成、ペーパープロトタイプ作成、技術検証(途中)をやったのですが、システム開発と自作サービスをマルチタスクでやっていくのは頭の切り替えがなかなかできず難しかったです。結局、うまく同時並行できず、自作サービスやっている週はシステム開発の進捗が出ず、システム開発を進めている週は自作サービスが全然できなかった...という感じでした。

システム開発ラクティスに入ると、チームメンバーにレビューをお願いされたり、毎週水曜にミーティングがあったり、自分のPRがマージされたら動作確認やリリースノートの記入をしたりと、これまでのプラクティスの課題とは違って、100%自分のペースでやる、とはいかなくなります

ただ私の場合、システム開発に取り組む中で「こうだったらいいな〜」という部分を発見して、FBCシステム開発ラクティスに取り組まれている方専用のwebサービスを作ることに決めたので、どこでアイディアがふってくるか分からないな、とも思っています。
私から言えるのは、システム開発に取り組みながら、「システム開発が終わる前に、早く自作サービスで作るものを決めなきゃ」と思いながら両方やるのは大変なので、入る前に作るものが決まっていると気持ちに余裕が持てていいのではないかな、ということです😅

課題に感じていること

分からないことがあった時の質問のタイミングが難しい

 issueに取り組んでいて、「どこまで自力でがんばって、どこから周りに助けを求めるか」のバランスが難しかったです。これは、どこで詰まるかも人によって異なる & 人によって考え方も違うため、正解は一つではないんだろうなと思っています。

仕事となると、お給料をいただいてプログラムを書くことになり、かつ締切があるので、自分の力で実装したり理解することよりも、早くユーザーに機能を届けることを優先しなければなりません。なので、「◯分悩んだら質問して、理解が不十分な所は終業後調べる」など、質問するタイミングの基準をはっきり作りやすいと思います。

ですが、今は「エンジニアになるための学習」が目的なので、分からないことに遭遇した時に、「これぐらいできていないと、エンジニアとしてお仕事する時にまずいのでは...もう少し自力でがんばろうかな」と考えたりしてなかなか質問に踏み切れない時もありました。
自作サービス開発でも、このことで悩むことがあると思いますが、「一人で抱え込まない」ことは大事にしたいと思っています。

適切なコミットの粒度が分からない

 レビューで様々なPRを見ましたが、人によってコミットの粒度が違うので、これも何が正解なのか分かりませんでした。
私は何か変更する度に細かくコミットしていましたが、他の方のPRでは、「機能追加」と「テスト追加」でコミットが2つのものもありました。

これは正解が一つだけあるというよりは、会社さんや開発チーム、人によって違うのかなと思うので、勉強して、自作サービスでは色んな方法を試してみようと思っています。

嬉しかったこと

 これはわざわざ自分から言うのもどうなのかなと、書くか迷ったのですが、素直に嬉しかったので書きます🙏
数えて見たら、9名くらいの方に、一番最初のPRのレビュワーとして選んでいただいていました。
自分が周囲から話しかけにくい存在だと、コミュニケーションに支障が出る = 仕事に支障が出ると思っていて、なるべく「話しかけやすそうな人」と思ってもらえるように意識していたので、頼みやすいと思っていただけたのかな〜と感じてとても嬉しかったです🥰

おわりに

 長々と書いてきましたが、システム開発はとても人やタイミングに恵まれたと思っています。ちょうど同じ時期に入ったFBC受講生のトミーさんが、good first issueをモブプロでやる会を主催してくださったり、ペアプロ・ペアレビュー文化を根付かせてくださいました。開発メンバーとコミュニケーションを取る時に、テキストでのやり取りだけでなく、ペアレビューも選択肢として増えたことで、より開発メンバーの方とコミュニケーションが取りやすくなりました

また、平日夜18:00-19:00にFBC内で開催されている輪読会に参加しているのですが、そちらの参加者の方がちょうど同じ時期にシステム開発に取り組まれていたり、すでに終えた方が多かったので、進め方や詰まったことで相談にのっていただくことも多かったです。
「皆さんはこういう時はどういう風にやってましたか?」「この機能を作ってる部分のコードが読み解けなくて詰まってます〜」と相談したり、「▲▲については、自分も同じ所を勉強して日報にまとめたのでよかったら参考にしてみてください」「そのissueは、元々××の実装をされた方が●●さんだから、詰まったら●●さんに聞くといいよ〜」とアドバイスをくださる場が平日毎日あったことは、私にとってとても大きかったです

メンターの方々や、輪読会で助言くださったり私の分報チャンネルにコメントで色々と教えてくださった方々、本当にありがとうございました!
まだ自作サービスという最後の一山が残っているので、このプラクティスで学んだことを存分に活かして、引き続きがんばっていきます。

2月〜チーム開発、なんとか生き延びています〜

 2月は過ぎるのが凄まじく早かった! これまで仕事しながらフィヨルドブートキャンプの学習を進めてきたが、チーム開発と両立するのは大変だった。
カーレースの中で自分だけ自転車で参加していて、置いていかれないように必死に漕いでるような気持ちだった🏎🏎🏎    🚴💦
記憶がほとんど無いため、日報*1を見返して思い出しながら書いている。

ニコニコカレンダー*2を見ると、なんと28日中27日間、学習して日報を書いていた。2月がほぼ全部埋まっていて嬉しい😊✨

f:id:Saki-Htr:20220304114637p:plain
2月のニコニコカレンダー

怒涛のチーム開発 🌊🏄‍♀️

これまでのプラクティスはジェットコースター、チーム開発はフリーフォール

 1月末にチーム開発のプラクティス*3に入ったので、引き続き自分のissueを進めたり、他の受講生の方のプルリクエストのレビューを行ったり、毎週水曜のミーティングに参加したり、予期せぬエラーやコンフリクトとたたかったりしていた。

分からなくて辛い時と分かって嬉しい時の気持ちの揺れ幅を乗り物で表すと、チーム開発に入るまでのプラクティスではジェットコースター🎢 という感じだったが、チーム開発は、気持ちの揺れ幅が大きくなり、何か一つ問題を解決してやっとプルリクエストを作れる(上に上がっていく)と思ったら、すぐにまた違う問題が立ちはだかる(落ちる)ので、フリーフォールのようだな~と感じている。
分からないことばかりで大変だが、その分できるようになると嬉しさも大きい

たくさんつまずき、たくさん助けていただいた🙏

 ニコニコカレンダーは全てオレンジ色(=いい感じ)なので、順調そうに見えるが、チーム開発に入ってから分からないことだらけで、はじめはエラー解消で休日一日が終わってしまうこともあった。
そんなにつまずいているのになぜ毎日日報のマークが笑顔かというと、分報*4に困ったことを呟いた時に同じ開発チームの受講生や卒業生の方が解決法を教えてくださったり、チェリー本輪読会のメンバーに相談にのっていただいたり、メンターさんに質問して丁寧に教えていただいたりして、解決できたためだ。(いつも助けてくださっている皆さま、本当にありがとうございます🙇‍♀️)
つまずいてばかり&助けていただいてばかりで情けなくなることもあったが、失敗してしまったことを無かったことにすることはできないので、しっかり反省した上で、同じ失敗を起こさないように工夫したり、ブログやscrapboxに解決策をアウトプットして他の方(と未来の自分)の役に立てるようにしたりすればいいと思うことにした 💪

休日はトミーさんとペアプロざんまい 🙌

 4週のうち2週ほどは、同じ時期にチーム開発に入ったトミー(id:eatplaynap329)さんと休日にペアプロをしていた。 お互いの簡単な1~2ptのissueを持ち寄って、25分片方がドライバー→5分休憩→25分もう片方がドライバーという感じで進めた。(トミーさんご考案)

これまで経験したペアプロは、分からないことをメンターさんから教わるためのペアプロが主だったので、どんな感じになるか想像がつかなかったが、とってもとっても楽しかった
プルリクエストを作成できた後は、そのレビューをお互いに行うことにした。*5
トミーさんが「ペアプロした人同士でレビューしたらいいのでは」と仰っていて、たしかにその方が、レビュワーが1からコードを読み解く手間が無くなり、コミュニケーションがスムーズになって良いと思ったので、「さすがトミーさん👏👏👏」と思った。

チームメンバー同士のペアプロは、

  • 効率的にレビューができる
  • コミュニケーションが取れる

と良いことばかりなので、ペアプロ文化をフィヨルドブートキャンプに根付かせてくださったトミーさんには本当に感謝の気持ちでいっぱいです🙏✨

進捗がほぼ無くてもミーティングには必ず出る 💪

 毎週水曜日に1スプリント(1週間)でやったこと、難しかったこと、次のスプリントでやることを話し合うミーティングがあるのだが、1スプリントで1つもプルリクエストを作れなかった日もあった。
けれども、やっていなかったわけではなく、issueもちょっとずつだが進めているのでちゃんとミーティングに出た。「進捗無いので欠席します」を一回でもすると、私の場合は逃げ癖がついてしまいそうなので、どんなに進捗が少なくても、絶対に出るつもりだ。

プロダクトバックログを真似てタスク管理してみた 📝

 チーム開発のプラクティスでは、自分のissueや開発メンバーのレビューに加えて、ステージング環境や本番環境での動作確認、mainにマージされた自分のプルリクエストのリリースノートを木曜15時までに作成しなければならないなど、小さいタスクがたくさんあり、忘れてしまうのが怖いので、プロダクトバックログ*6 を真似て、Todoistというタスク管理アプリに、優先順で上から順にタスクを並べて管理することにした。シンプルに一列で、ここだけ見ておけばやるべきことが明確なので重宝している。

f:id:Saki-Htr:20220308002703p:plain
実際に登録したタスク

自分の書いた技術記事が、GoogleSafariの検索結果で最初に表示されるようになっていた🎖

 去年の8月に書いたESLintのインストール&使い方の記事が、GoogleSafariで「eslint インストール」で検索すると、一番最初に表示されていることを知った😳 saki-htr.hatenablog.com


スマートフォンで自分のはてなブログを見る時、いつも注目記事の1位がこの記事で、はてなスターも1個しか付いていないし、フィヨルドの方から感想をいただいたことも無かったので、「そんなに見られているはずないのに、何かのバグかな?」と思っていた。

↑というのをdiscordの自分の分報チャンネルでつぶやいたら、フィヨルドブートキャンプのメンターさんが、「eslint インストール」で検索すると、私の記事が一番上に出てくることを教えてくださり、知ったときはびっくりしすぎて叫んだ 🤯


f:id:Saki-Htr:20220307234120p:plain


気になって自分のブログのアクセス解析を見ると、私のブログはGoogleからのアクセスが75%になっており、Googleから来た方の64%はこの記事にアクセスしていることが分かった。

f:id:Saki-Htr:20220308004333p:plain
はてなブログアクセス解析

私のアウトプットは振返りや自分の考えていることなど、非技術系が多く、昨年出たLTも3回ともすべて非技術系なので、技術系のアウトプットにあまり自信がなかったが、今回のことで少し自信が持てた😁

前にフィヨルドブートキャンプのメンターさんが、

アウトプットの価値は、書き手でなく読み手が決める

と仰っていたことを思い出した。
なので、日報や分報などクローズドな場だけでなく、ブログやscrapboxなどもっとオープンな場所でもアウトプットを積極的にしていこうと思った。

手始めに、Notionに書いているチーム開発の作業ログを、誰でも見られるようにして、フィヨルドブートキャンプを知らない方が見ても分かりやすいように紹介ページを作った

www.notion.so

今の時点ではこれが人の役に立つかはわからないが、せっかくアウトプットしているので外に出していこう & これからチーム開発に入る方の少しでも参考になればいいな〜という気持ちでいる。

3月の抱負

2月は自作サービスは全く進められなかったが、作りたいと思った案が一つ浮かび、チーム開発にも慣れてきたので、その案について深堀りして考えてエレベーターピッチを作りたいと思っている。

*1:フィヨルドブートキャンプでは、学習した日は、やったこと・学んだこと・分からなかったこと等を日報に書いて提出し、メンターさんに見ていただく仕組みがある

*2:日報には「今日の気分」という項目があり、自分のプロフィール画面で、その日の気分がどうだったかを月ごとに見ることができる

*3:フィヨルドブートキャンプの学習で使っているWebアプリはOSSで公開していて、フィヨルドブートキャンプ受講生がチーム開発のプラクティスで機能を追加したり、バグを修正したりなどの開発をしている。Issueにポイントが振られており、20ポイント分のIssueがマージされたら完了となる。受講生同士でお互いのプルリクエストのレビューも行う。リポジトリこちら

*4:自分の状況を逐一実況することで、いわゆるひとり言。フィヨルドブートキャンプではコミュニケーションツールとしてDiscordを使っており、メンターや受講生はそこで自分専用の分報チャンネルを作って好きに書き込むことができる。

*5:チーム開発では、自分が作成したプルリクエストのレビューを、その時一緒に開発を行っている受講生にお願いし、それが通ったらkomagataさんにレビュー依頼をすることになっている

*6:機能や要望など実現したいことを、優先順位順にリストにしたもの

1月〜自作npm&チーム開発にジョイン!〜

今年ももう1ヶ月が経ってしまった! この前、年が明けたばかりだと思っていたのに🙊
今年は一日一日を大事に生きて、自分がやってきたこと・感じたことを丁寧に振り返りたいと思ったので、毎月末振返りと次月の抱負を書くことにした。

やったこと

  • VueCLIの課題の修正
  • アジャイル開発/スクラム開発の本を2冊読んでまとめる
  • 自作npmを公開
  • チーム開発にいよいよジョイン!
    • ローカルの立ち上げに苦戦
    • 同じ時期に入った同期とモブプロでgood first issueを行う

1月のハイライト

自作npmのアイデア出しに苦戦😂

1月の前半は自作npmのアイデア出しで詰まり、ちょっとメンタルが沈んでいた。 その頃の自分の気持ちは以下のような感じだった。

npmのアイデア出しがうまくいかず、帰宅直後ネガティブな気持ちになっていたが、今日は仕事初めで、お腹が空いていて、眠かったのでネガティブになっていたんだな〜と、お風呂から上がった時(疲れがとれた時)に気づいた。 気持ちはその時の環境や自分の状態に結構左右されていると思っていて、なんでネガティブな気持ちになったのか環境要因を探ってみると、マイナスの感情に振り回されずにすむと思った (1/5水の日報)

沈んでいた理由は、「自分がどんなものを作りたいか」を考える前に、他の方のレベルの高い提出物を見て「すごいものを作らなくては」と考えてしまい、アイデア出しに集中できていなかったからだと思う。

自分がその精神に陥ってると気づけてからは、すごいものかどうかという視点を捨てて、純粋に「どんなものを作りたいか・どんな人に使ってほしいか」を楽しんで考えることができた。

コマンドライン上で動かすので、「どういう時に動かしたいかな〜」と考え、今回詰まって沈んでしまった私のように、学習中やコードを書いてる最中に落ち込んだ時に、役に立つものを作りたいと思った。
その時にメンターのりほやんさんがこちらのPodcastで、 www.yancan.tech

学習のモチベーションを握る鍵は自己肯定感だと思う。 一番大事なのは、今自分の自己肯定感がどれくらいの高さにあるか認識すること。認識が低い時はちょっとしたことでも大ごとに感じてしまう。下がっていることが分かれば対策ができる。今日は仕事を早めに切り上げようとか。ヒロアカ見ようとか。

と仰ってたのを思い出した。

なので、今の自分の自己肯定感の高さを診断するnpmを作った。

www.npmjs.com

すごいコードを書いたりすごい技術を使ったりしたわけではないのだが、自分が作りたいものを1から考えて作り上げることができたので、満足している。
案出しが大変なことがわかったので、自作サービスのアイデア出しも今からしっかりやっておかないといけないことにも気づけてよかった。

フィヨルドリポジトリやかんばんを見てワクワク😊

開発に入るための準備で、フィヨルドブートキャンプのリポジトリかんばんに目を通した。
眺めていると、今まで使っていたものが当たり前でなく、だれかが作ってくださったものなんだということを改めて感じた。これまで「使う側」しか経験したことがなかったので、いよいよ「作る側」ができることにワクワクした。

ローカルの立ち上げに苦戦💦

そんなに苦戦しないだろうと思っていたが、Rubyのバージョン2.7.4をインストールするためにrbenvを使ったら、なぜか使えなくなっていて驚いた。遭遇したことのないエラーで焦ったが、しっかりエラーやログを見たらどこに問題があるか分かって、なんとか解決することができた。大変だった分、ローカル立ち上げに成功した時は本当に嬉しかった〜

good first issueを同期と一緒にモブプロでわいわい進めた🥳

私と同じく今週からチーム開発に入ったトミーさんとガラムマサラさんと一緒に、good first issueを、プルリクエストを作ってレビュー依頼するところまでをモブプロで行った。
(主催してくださったトミーさん、一緒にissueをやったガラムマサラさん、参加してくださったメンターさんや受講生の方々、本当にありがとうございました🙏✨)
Ruby on Railsを触るのが久々だったり、今まで使ったことのないGitのコマンドを実行しなければならなかったり、テストを実行する時処理が重たいせいか私の声が皆さんにとぎれとぎれで聞こえなくなったりと、テンパリっぱなしだったが、みなさんが助け舟を出してくださったおかげで、致命的なミスをせずに済んだ。一人でやっていたら解決方法がすぐには分からなかったであろうエラーも何度か起こったので、一番最初のissueをモブプロでやらせていただけて本当に良かった。
なにより、みんなでワイワイしながらコードを書くのが本当に楽しかった!今までメンターさんとペアプロをしたことはあっても、モブプロは初めてだったので、主催のトミーさんに本当に感謝です。

初めて一人でissueをレビュー依頼するところまでやった💪

前回の振返りミーティングでissueをもう一つ振っていただいていたので、今日初めて自分一人でissueに取り組んだ。一人でできるか不安だったが、プルリクエストを送るまでの手順をしっかり予習した後進めたので、レビュー依頼まで完了することができた。
簡単なissueではあるが、自分一人で完了することができて少し自信がついた!

ログ駆動開発を始めてみた✍🏻

先日、フィヨルド受講生のikuma-tさんがLTで、

チーム開発など難しいタスクでは、タスク駆動開発(チェックリストにチェックが入った時に進捗があがる)だと進んだ気がせず、取り組むことが億劫になってしまう。
そこでログ駆動開発(作業に取り組んだことを記録して進捗を管理して、作業ログが書き込まれたと瞬間に進捗があがる)を行ったら、進捗が捗った

という話をされていて、「私もチーム開発に入ったらログ駆動開発をやりたい!」と思っていたので、早速やってみることにした。

(詳しいLTの内容についてはikuma-tさんがこちらで紹介してくださっています。)

ikmbear.hatenablog.com

書き出すこと自体はDiscordの分報によく書いているので記録する癖はあるのだが、その時取り組んでいるissueのこと以外もたくさん呟いていて見づらいので、Notionにissueごとにページを作って、そこにやったことや自分の気持ちを時系列順に書いてみることにした。↓

www.notion.so

おまけ:フィヨルドで培ったことを仕事で活かせた

具体的に何をやったのか

1~3月の間だけ、エクセルに切り出された情報を手打ちでアプリに大量(私含めたパートさん5人で合計3000件!)に入力するお仕事があり、エクセルを入力しやすくカスタマイズした方が正確性もスピードも上がるので、上司に「職場のみんなでどの方法が一番効率的か共有し合いませんか」と勇気を出して切り出してみたら、快くOKを貰えた。
当日、私のやり方を職場の人に見てもらいながら、どういうやり方が1番正確で早いかをワイワイ話し合った。私も知らなかった効率的なやり方を他の人から知れて勉強になった。
そして、元々自分がやっているやり方をドキュメント化したのを皆に共有したり、関数使うなど難しい箇所はマニュアルを作ったりした。

フィヨルドで培ったこととは

これができたのはフィヨルドブートキャンプで

  • 実現したいことを調べ抜く力
  • 気になったらまずとびこんで行動してみる精神

を培ったからできたことだと思っている。
フィヨルドブートキャンプでの学習を通して、「この操作をもっと楽にできないか?」「これをやりたい人は私の他にもいっぱいいるはずだから、調べれば機能が用意されていたり、すでに方法を見つけている人がいるはず」と考えて、調べて実現することができた。
また、主体的に動いて改善策を提案するのは私にとっては少し勇気が要ることで、入社したての頃の私だったら「失敗したらどうしよう」と尻込みしていたかもしれないが、フィヨルフドブートキャンプで「大勢の前で登壇するのは怖いけどLTやってみたい!」「人見知りだけど、輪読会に参加してじっくり理解したり他の受講生と仲良くなりたい」というように、最初怖かったけれど一歩踏み出してみたら、"楽しい!飛び込んでみてよかった!"と思えるようになってきたので、今回行動を起こすことができた。

行動してみて思ったこと

どうしたらもっと良くなるかを職場の皆さんと話し合って改善していくのは、とてもやりがいがあると思った。
他のパートさんに、「自力ではこれ以上スピードアップできないからどうしようかと思ってた、ありがとう」「マニュアル通りにやってみたら入力しやすくなって楽しい」と言っていただけるなど、職場の人に感謝されたのもとても嬉しかった。
このことについてDiscordの自分の分報につぶやいたら、アドバイザーの方に「それはもう完全にエンジニアリングしていますね👏」と仰っていただけたのもとても嬉しかった!

2月の抱負

去年、一週間ごとに学習の目標を立てて、進捗を週報に書いていた時期は学習が捗っていたので、本当は今年も明確な目標を立てたいのだが、チーム開発は未知な部分が多く、「何日まで何ptのissueをやる」等の目標を立てるのは難しそうだなと思ったので、まずチーム開発・振返りミーティングに慣れることと、自分のペースでissueに取り組むことを意識して進めたいと思っている。あと、自作サービスのアイデア出しも、一日でぱっと思いつくものではないので、日常で感じるもやもやを記録したりとちょっとずつでも進めていく。

雑談タイムやペアプロで、スムーズにコミュニケーションを取るために心がけていること

f:id:Saki-Htr:20211224150828p:plain

こんにちは。フィヨルドブートキャンプ生のSakiと申します。

この記事は、フィヨルドブートキャンプで開催されている、フィヨルドブートキャンプ Part 2 Advent Calendar 2021 - Adventarの24日目の記事です🎄🎁

昨日12/23は、azitamaさんの勉強を続けた結果を振り返る ゆっくりでも変化し続けていこう|あじたま家.comでした。
本日Part1の記事は、Maedaさんの輪読会のすすめ - maedaの日記です。私もMaedaさんと同じチェリー本輪読会に参加しています🍒気になった方はラジオ参加で少し覗きに来てもらえると、メンバー全員大喜びします☺

目次

はじめに

フィヨルドブートキャンプで学習をしていて分からないことに遭遇すると、雑談タイムで質問をすることがあると思います。また、コードを書くプラクティスでは、テキストでのやり取りのみだと非効率なので、メンターさんとペアプロをすることがあると思います。

私は元々、雑談タイムやペアプロのような同期型コミュニケーション*1に対して苦手意識があったのですが、場数を踏んで失敗もする中で、「こういうことを意識するとコミュニケーションがスムーズになっていいな」という気づきがありました。

この記事では、

  • 日報やDiscordの#wakaranチャンネルなどテキストで質問したことはあるけれど、雑談タイムで質問するのはハードルが高く、まだしたことがない
  • メンターさんにペアプロをお願いしたいけれど、緊張してなかなか依頼する勇気が出ない

という方に向けて、

  • どんな失敗をしたか
  • どんなことを意識するとコミュニケーションをスムーズにできるか

を書くことで、少しでも背中を押せたら嬉しいです。

なぜ苦手意識を持っていたのか

もともと私は、Discordでの通話など同期型のコミュニケーションに苦手意識を持っていました。
日報などテキストでのコミュニケーションですと、ある程度自分のペースを保って、相手の言葉を理解し、自分が返す言葉を考えて話せますが、Discordで質問をすると、相手の言葉を瞬時に理解して返さないといけないというプレッシャーを感じていたためです。
そのため、「うまく疑問を伝えられなかったらどうしよう」「変なことを言ってしまったらどうしよう」「相手の言ってることが分からなかったらどうしよう」という不安がありました。
質問は日報やQ&Aなどテキストでもできますが、コードに関する質問など、直接お話した方が効率が良い質問もあるので、Rubyのボウリングのスコア計算プログラムでつまずいた時に、初めて勇気を振り絞って雑談タイムで質問しました。

どんな失敗をしたか

雑談タイムで質問し始めた最初の頃は失敗の連続でした。
具体的には、

  • Rubyのボウリングのスコア計算プログラムについて質問した際、あらかじめ現状・解決したいこと・試したことを整理してから挑んだのに、うまく説明できなかった。
  • メンターさんに「ボウリングのゲーム全体のことで困っているのか、それとも10フレーム目の計算で困っているのか」と聞かれたのに、焦ってしまいその問いに答えずに、自分のコードの現状を話してしまった。
  • データベース設計のやり方について質問した際、一からER図を書いて説明していただいたが、途中からついていけなくなってしまい、あまり理解できなかった。

といった失敗をしました。

また、初めてメンターさんとペアプロをした際は、緊張して仰ってることがすぐに理解できなかったり、今何をしようとしているか分からなくなり混乱して会話も手も止めてしまったりと、コミュニケーションを上手く取れませんでした。

最終的には疑問を解消することができたので、厳密には失敗ではないのですが、メンターさんになんとか汲み取っていただいて解決してもらいましたし、「こういう風にコミュニケーションを取ればよかった」「自分が困っていることをうまく伝えられなかった」という落ち込みがすごかったです。

それでも挑み続けて得た気づき

それでもめげずに、雑談タイムで質問したり、メンターさんにペアプロしていただいたりする中で、「こういうことに気をつけるとコミュニケーションがスムーズだな」という気づきがありました。

1. 相手の言ったことと、それを聞いた自分の理解の擦り合せをする

相手の言った内容と、それを聞いて自分が理解した内容が同じかどうかの擦り合わせはとても大事です。
例えば、

AB
BC

という式があるとしたら、A=Cになることが分かります。 A=Cと分かるためには、A = BB = Cを理解していなければなりません。

質問でも、相手の言った内容と、それを聞いた自分の理解が合っていないと、お互いの認識がズレたまま会話が進んでしまいます。 上記の例でいうと、A=BB=Cという前提が分かっていないのをそのままにして進んでしまうと、A=Cが理解できなくなってしまいます。
自分がどこまで分かっているか、メンターさんの言葉をどのように理解しているかは、自分にしか分かりません。 なので、

  • メンターさんの仰った内容に対して、「〇〇という理解で合っていますか??」「〇〇という意味でしょうか??」と自分が理解した内容を逐一伝える
  • メンターさんの仰ってる内容が分からない時は、その場で質問する
  • 仰った内容に対して何が分からないかすぐに言語化できない時は、「〇〇の部分がなぜそうなるのか分からないです」「○○の部分が分からないのですが、何がどう分からないかすぐに説明できないので、少し考えてもよろしいでしょうか」のように、分からない状態であることを伝える

といいと思います。

2. ペアプロでは自分の状況を実況する

ペアプロでは基本的に生徒さんがドライバー(コードを書く人)となり、エディタを画面共有してメンターさんに見ていただきながらコードを書いていきます。

最初はメンターさんとマンツーマンでお話しすること自体に緊張したり、焦ってメンターさんの仰ってることが理解できなかったり、今自分が何を実現しようとしているかが分からなくなってしまったりすると思います。
そういった時に無言で手が止まってしまうと、メンターさんはなぜ生徒さんの手が止まっているか状況が分からず困ってしまいます。

自分の頭の中の状況はメンターさんには見えないので、

  • これから何を実現しようとしているか・どういうコードを書こうとしているか伝える
  • もしコードの書き方が分からない・疑問が浮かんだ等で詰まったら、「これをやりたいと思っているのですが、やり方が分からず止まってしまいました」と現状を伝えたり、「こういう方向性で合ってますか?」と確認する

など、自分の状況をこまめに実況するといいと思います。

最後に私が伝えたいこと

色々書きましたが、初めて質問する時は、

  • そもそもメンターさんと話すことに緊張する
  • 画面共有などDiscordでのやり取りに慣れていない

などで、会話をするので精一杯だと思います。
私も初めて雑談タイムで質問した時は、フィヨルドの質問に関するDocsを読んだり、疑問点の整理を書き出したりと準備をしていきましたが、結果はぼろぼろでした。 でも、何度か挑戦しているうちに慣れてくるので、場数を踏むことが大事だと思います。
慣れるまではしんどいかもしれませんが、質問できるようになると、分からないことがあった時に「まあ自分で調べても解決できなかったら、雑談タイムで聞けばいいか」と思え、分からなくて辛い気持ちが少し楽になると思います。
この記事を読んで、質問することが怖いと思ってる方の背中を少しでも押せたら嬉しいです😊

*1:複数の人が同じ時間を共有してやり取りをするコミュニケーションスタイル。代表的なのは会議や電話。

「素直に質問できることの大切さ」について考えた

f:id:Saki-Htr:20210912122021p:plain

はじめに 

 先日7/17(水)に、フィヨルドブートキャンプのメンターさんがリモートで交流会を開催してくださった。
そこで、「成長できる新人プログラマーは、素直に質問ができる人」というお話を聞いて、たしかに!と自分のこれまでの経験と照らし合わせて共感したので、自分の考えを書いた。

目次

フィヨルドでの学習を通して、質問する力が身についた

 フィヨルドブートキャンプでの学習を通して、質問するタイミングの見極めができるようになり、仕事でも質問することが得意になったと思う。
プログラミング学習で分からないことを質問した時に、調べが不十分だと、これは確認したか?と聞かれるので、しっかり調べる癖がつき、日報*1で毎日学んだこと・分からないことをアウトプットして、疑問を人に分かりやすく伝える訓練をしているからだと思う。

大切さに気づいたきっかけ

 社会人1年目の頃は、「みんな忙しそうだし、時間割いてもらうの申し訳ないし、自分で考えて進めよう」という考えで仕事をしていたことで、早めに報告していれば回避できたミスをしたり、うまく周りに助けを求められなかったり、仕事を終えるのに時間がかかりすぎて結局聞いたほうが早かったり、と失敗することが多かった。
この経験を通して、ホウレンソウをしないで自分一人で仕事を抱え込んでいると、結局は迷惑をかけてしまうことを学んだ。

 2年目から、後輩や新しいパートさんがぞくぞくと入ってきて、自分が仕事を管理したり教えたりする立場になった。
この経験を通して、素直に質問してくる人よりも、分からないことがあった時に気をつかって聞かないで進捗が止まっている方(=1年目の自分と同じ)の教育のほうが大変だということに気づいた。 1年目の自分と働いていた人は、「分からなかったら聞いてほしい」と当時の私に言っていたが、それでもいつどのタイミングで聞けばいいか分からず、相手の時間を奪うようで申し訳なく、それでも聞けなかった。なので、気をつかって質問できない人は、今の私のような気持ちだったのかなと思った。

なぜ大切なのか

教えたりマネジメントをする側の人が、相手が詰まっていて仕事が止まっていることに気づくのは、分からない側が発信しないと難しい。(ずっとじーっと見ていたら手が止まっていることに気づけるかもしれないが、教える側もマネジメント業務に加えて自分のお仕事があるので、それはほぼ不可能だと思う。今はコロナ禍で、フルリモートの会社さんも増えてきており、リモートで仕事をしていたら、相手の仕事をしている姿は全く見えないので、不可能だ。)
なので、話しかけやすい雰囲気を作ったり、「分からなかったらすぐ聞いてください」と言っていた。(今振り返ると、「○分考えても分からなかったら聞いてください」、の方がより聞きやすかったかもしれない)

気を遣って質問できない人に対して、定期的に「大丈夫ですか?」と声がけもしていたが、別に大丈夫な時もあるので、定期的にこちらが分からないことがないか確認するよりも、わからない側が発信してくれる方が効率的だと思った。(自分で全く考えないで質問攻めをするのも良くないと思うが💦)
フィヨルドブートキャンプの「わからないことをメンターや他の受講生に質問をする方法」というドキュメント*2でも、メンターさんの1人が、

質問された方が「この人は何が分からないんだろう?」とか、どこに指摘するべきだろう?と考えるよりラク

と仰っていた。

教える側を経験して学んだこと

 この2年目の経験を通して、「自分がどう動けば、共に働く方から教えていただく時間と、自分が仕事に費やす時間を最小限にできるか」という視点で考えられるようになった。今は、自分がどう動けば、(私を含めた)職場の方全員の時間を、最小限で仕事を終えられるか、と俯瞰して考えられていると思う。
今は、仕事で詰まった時は以下のようにしている。

  • 自力で最大限調べる
  • 調べるのに時間がかかりそうで、その仕事が終わる想定時間(私の会社では、1つ1つの仕事に仕事完了までの目安時間が設定されている)よりも長くなりそうな時や、自分で解決できないと判断した時は、質問する
  • 質問する時は、状況説明と分からない点をなるべく簡潔に伝えるように努力する
  • 同じことを質問しないように、聞いたことはPCにその場でメモ。
    • 紙に書いたメモは無くす可能性があり、管理が大変&PC内にメモしておくと、用語検索で簡単に探せるため。

結論

 プログラマーとして転職して、疑問にぶつかったら、おそらく「こんなことも分からないなんて、失望されるかも...」という感じて、質問することにハードルを感じることがあると思う。そんな時は自分が教える立場だった時のことを思い出して、「どう行動するのが自分にとってかつ共に働く方々にとって最善なのか」という視点を忘れないようにしたい。
後、恥ずかしいのは、分からないこと自体ではなく、分からないことを分かったふりをすることだと思う。そして分かったふりはすぐにバレるとおもう。

おわりに

 この記事はもともとscrapbox:素直に質問できることの大切さについて - Sakiで書いていたものを、清書して書き直したものです。
元々この記事を書いた理由は、誰かに読んでもらうためではなく、自分の頭の整理のためでした。そのため、多くの方が読んで感想をくださったり、会社さんにシェアしてくださったり、フィヨルドブートキャンプのヘルプに載せていただいたりして、非常に驚くとともに嬉しい気持ちでいっぱいになりました。フィヨルドブートキャンプには長い間お世話になっていて、「私も何かしらの形で役に立ちたい」という気持ちがずっとあったので、フィヨルドブートキャンプというコミュニティに少しは貢献できたのかな、と嬉しくなりました。

社会人になったばかりの1年目の頃は、上述の通り失敗ばかりで辛かったですが、この経験があったからこそ、気をつかって質問することができない方の気持ちを理解でき、どのように接したら、"質問することが申し訳ない"→"質問した方がみんなのためになる"と前向きに思っていただけるようになるかを、学ぶことができました。
また、約3年後の今、このように文章にすることで、誰かのお役に立てているので、その瞬間は辛いと感じた経験も、いつどこで役に立つか分からないし、自分の成長の糧にしていける、と、辛い経験に対してポジティブな面を見出せました。これからも、フィヨルドでの学習やお仕事で、「辛い」と思うことはあると思いますが、そんな時はこのことを思い出したいと思います。

読んでくださったみなさま、感想をくださったみなさま、ありがとうございました。

*1:フィヨルドブートキャンプでは、学習した日は必ず日報を書いて提出し、メンターさんに見ていただくことになっています

*2:フィヨルドブートキャンプでは、質問する力を身につけるためにたくさんのドキュメントを書いてくださったり、日々質問しやすい環境をアップデートしてくださっています

"できたこと"に目を向けるために、8月を振り返る

f:id:Saki-Htr:20210902144903p:plain

目次

なぜ振り返ろうと思ったのか

 最近、「あれもこれもやりたいのに、時間がない」と焦る気持ちが強かった。
やりたいことというのは具体的には、プラクティスを進めたい、自作サービスのアイデアを考えたい、もっと勉強会に参加したい、もっとアウトプットしたい、もっとRubyで書く力を身につけたい、もっとフィヨルドブートキャンプの方々と交流したい、などだ。すべて、「本当はやりたくないけどやらなきゃいけないもの」ではなく、「心からやりたいと思っていること」なので、なおさら辛かった。

私は働きながら学習しているので、お仕事を辞められてプログラミング学習に取り組んでいらっしゃる方に比べて、学習に割ける時間が少ないので、「割ける時間が少ない分、もっと頑張らなくては」と、肩に力が入っている状態だった

この精神だと、"できたこと"よりも、"できていないこと"にばかり目が行ってしまい、自己肯定感が下がって良くないと思ったので、自分がやってきたことにも目を向ける機会を設けようと思った。今年の1月~4月まで、学習の振り返りとして週報を書いていたのだが、なかなか書くのに時間がかかるため、やめてしまっていた。
しかし、週報を書いていた時は、「一週間前にはこんなことも知らなかったのか」「最初は"何もわからん"状態だったのに、一週間でこんなに理解が進んだのか」と、成長を実感できていたことを思い出したので、月ごとに振り返りをしてみようと思った。

8月を振り返る

フィヨルドブートキャンプのプラクティス

ラクティス 学んだこと
JavaScript環境の設定 ・Node.jsとは(JavaScriptとの違い)
・nvmとnodebrewの違い
・NodeとNode.jsの違い
・nvmをfishシェル環境下で使う手順
・nvmでnode.jsの最新版をインストール
・デフォルトで利用するNode.jsを最新のバージョンにする
FizzBuzz問題(JavaScript) for文でスマートに書けた
npm ・npmとは何か
・ npmパッケージを検索・インストール・アップデート・アンインストールできる
emojemoji-grassで遊んだり🥳
Linter(ESLint) ・インストール&設定
・ローカルかグローバルどちらにインストールすべきか?
カレンダーのプログラム(JavaScript) Rubyと細かい書き方が違う
非同期処理 ・非同期処理はどういうものか、なぜ使われてるのか
callback , Promise , async/await3つの方法それぞれの特徴と簡単な書き方
・JSPrimerのGitHubのユーザーIDからプロフィール情報を取得するアプリケーションを作成するを一通りやった
JavaScript入門を読む ・外部ファイルを非同期で読み込む(async属性,defer属性)
・ラッパーオブジェクトとプリミティブ型
Node.jsでメモアプリCLI版を作る(未完) ・引数を受け取る
・ユーザーの入力を受け付ける
・パイプラインの詳細を忘れたので復習
・タスクの洗い出し(実装方法が未知なのでざっくり)
・Nodeでsqlite3を使う方法

8月のできごと

日にち できごと
4(水) ぺろ(id:mosshu0703)さん主催のLT発表練習会(登壇者の皆で集まって、気軽に発表してFBをもらう会)に参加
5(木) ・@june29さんとランチ会
詳しくはjune29さんとランチ会をしました - Saki
フィヨルドの「初めてのLT会」の発表リハーサル
・『オブジェクト指向でなぜつくるのか』輪読会2章
・『ガールコード』読書会3章
7(土) 「初めてのLT会」本番
詳しくは:「初めてのLT会」に登壇した感想 - Sakiのプログラミング学習ブログ
12(木) mitaka.rbに初めて参加
18(水) NaITE オンラインもくもく会 vol.19に初めて参加
19(木) ・輪読会B班話し合い
ペパトークに参加
・『ガールコード』読書会4~5章
23(月) ・輪読会B班(平日18:00~19:00にRuby超入門を読む会)がスタート
・『オブジェクト指向でなぜつくるのか』輪読会4章
24(火) フィヨルドのミートアップ🍻
26(木) ペパボエンジニアとメンターが語る、「エンジニアとして働くということ」 - connpassに参加
28(土) Rails Girls Gathering Japan 2021 - railsgirls-japan | Doorkeeperのイベントに参加→懇親会も少し参加
29(日) Rails Girls Tokyo, More!のもくもく会に初めて参加

8月のアウトプット

気づき・考えたこと

  • 語彙をもっと増やしたい。自分が知ってる言葉でしか自分の考えや感情を相手に伝えられないので、もっと語彙を増やして、自分の考えを一番適切に表してくれる言葉を使えるようになりたい。
  • 仕事後は疲れてしまい、学習できないことがほとんどなので、輪読会の予定があると良い意味で強制的に本に向き合えるのでありがたい。去年teshplay女子部の方で輪読会を3冊やっていて、チェリー本輪読会を平日の朝にやっているのを見て"楽しそうだな、またやりたいな"と思っていたので、B班ができて嬉しい。
  • Ruby超入門の輪読会が始まった。初めて読んだ時・一人で読んだ時とはまた違う発見があって面白かった。
  • プログラミングスクールへの期待と提案について - ペパボテックブログを読んだ。今の自分にとって大事だと思ったのでメモ。

    なぜそのようなアプリを作ったのかという、モチベーションの部分が見えにくいことが多い
    エンジニアとしての狭義の技術的スキルはもちろん必須ですが、それに加えて、仲間になるかもしれない方が、どのようなモチベーションや考え方でプログラミングに取り組んできた方なのかという、人となりも知りたいと思います。モチベーションを知ればこそ、お互いがうまくマッチするかどうかを検討もできますし、そのようにして選考過程が進んでいくことは、募集する側にも応募する側にも、双方にとってよりよいことだろうと思います。

  • メモアプリ、分からないことだらけ問題。これは、やはりタスクを細分化することが解決策と思い至った。
    lsコマンドも、最初はそもそもコマンドを作るってどういうこと?とか、ファイルの情報ってどうやったら取得できるの?とか標準入力ってどうやったら受け取れるの?など分からないことだらけで、完成への道が果てしなく遠く思えたけど、 タスクを細分化して、まずは標準入力を受け取るにはどんなライブラリ・クラスを使えばいいのかとか、ファイルの情報をとってくるにはFileクラスやDirクラスをとってくればいいのか!とかちょっとずつできるようになったら、進められてる感を感じられてよかった。
    ということを思い出したのでちょっとずつでもやっていこう!という気持ちになった。 あと、Rubyでは超入門→チェリー本とRubyの知識をかなり丁寧に読んでから課題に移ったので、Rubyの基本的な知識がある状態で課題にのぞめたが、JSは「ふりがなプログラミング」というJavaScript入門というよりはプログラミング自体が初心者な方向けの本しか読んでいないので、単純にJavaScriptについて知らないから分からないのだろうな、と思う。他の方の日報を見ていると、みなさんJSPrimerや初めてのJavaScriptをしっかり読んでいらっしゃるので、私も基礎的なところをもっと知るところから始めようと思った。

  • 今働いている会社で、社員さんが作ったkintoneを使って仕事の進捗管理や顧客管理をしているのだが、入力されているべきデータが空白だったり、入力ルールを間違えていたりなどの不備が多いので、入力方法を分かりやすくまとめたマニュアルを作ってほしいと頼まれた。マニュアル作成にあたってkintoneアプリのデータがどこから飛んでくるのか等仕様を調査していて、「分かりづらいアプリの使い方を丁寧に教えるよりも、使いやすいアプリを作るべきではないか?」と思った。しかし、改善するには、「どこをどのように変えたら使いやすくなるのか」を言語化できないといけない。これがなかなか難しい。プログラマーの方々は、「どのようなデザインだとユーザーが使いやすいか」を、どうやって学んでらっしゃるんだろう?と気になった。

嬉しかったこと・シャウトアウト(感謝)

  • 分報チャンネルで「1個1個丁寧にやるのが癖になっていて、それなりの完成度ですすめるの苦手だ」とつぶやいたら 、uda(id:ud_ike)さんに、

個人的にはSakiさんのすごくいいところだと思いますけどねー。私は時間があってもできないし、アウトプットもいろんな人の役に立ってると思います👏

と言っていただけて嬉しかった。「もっと効率よく進めなきゃ」とか「時間がかかってしまっているなあ」とか、ネガティブな側面だけを見ていたので、ポジティブな面に気づくことができた。

  • こちらのツイートの、

    「これわかんないんですけどなんてキーワードでググったら良いですかね」が最強の質問方法だとずっと思ってる。 社内知見だけで共有されてるのは「一回一緒にやってもらえませんか」(その後知見をドキュメント化すると喜ばれることが多い、自分のために書いたメモなんですけど…って言いながら)

を読んで、ドキュメントを書くのは現職でもマニュアルを作ったり好き&得意なので、プログラマーになってからもお役に立てるかも、と分報チャンネルでつぶやいたら、メンターのりほやんさんから、

かなり稀有な存在でありがたられること多いので推していくといいとおもいます!

とアドバイスをいただいた。プログラマーの方々は几帳面でマメなイメージを持っていたので、稀有なのは意外だった。開発だけでなく、ドキュメント作成でもお役に立てたらいいな、と思った。

  • 8/5(木)のLTのリハーサルでは、udaさんとアルトさんが「スクラム開発大変だけど楽しい!」とお話されてて、モチベーションが上がった。
  • @june29さんにランチ会で、「論理的に考えられる」「前向き」と言っていただけたのがとても嬉しかった。

振り返ってみて

  • もっとやりたい、と思っていたことを、振り返るとすでに結構やっていたことに気づけた。
  • JavaScriptの学習は、7/17から始めたので、まだ始めて1ヶ月半と考えると、「そりゃあまだまだ知らないことだらけだよね」と腑に落ちた。基礎を分かっていないので、焦らずJS Primerを読んでじっくり向き合おうと思う。

9月の目標

【ESLint】インストール&設定の手順と、実行結果の見方

f:id:Saki-Htr:20210826145255p:plain

はじめに

JavaScriptのESLintについて学んだので、

  • インストール&設定の手順
  • 実行結果の見方
  • VSCodeにESLintを設定する手順

をまとめた。

目次

ESLintとは?

公式Docs:https://eslint.org/より。

ESLintは、ECMAScript/JavaScriptのコードに見られるパターンを特定して報告するためのツールで、コードの一貫性を高めてバグを回避することを目的としています。多くの点でJSLintやJSHintと似ていますが、いくつかの例外があります。

  • Linterの一種
    • Linter:コンピュータプログラムなどのソースコードを読み込んで内容を分析し、問題点を指摘してくれる静的解析ツール
  • Rubyのrubocopと同じ役割

実行環境

  • macOS BigSur 11.5
  • Node.js v16.6.0
  • eslint v7.32.0

インストール&設定の手順

公式:https://eslint.org/docs/user-guide/getting-started の通りに実行。

1. npmを使ってインストールする

ESLintはnpmまたはyarnを使ってインストールできる。今回はnpm(Node.jsのパッケージを管理するツール)を使ってインストールした。

// インストール
$ npm install eslint --save-dev // -gを付けていないのでローカルにインストールしている

// インストールできたか確認
$ npm ls
jsbook@ /Users/<ユーザー名>/jsbook
└── eslint@7.32.0 #=>成功!

2. 設定ファイルをセットアップする

※注: package.jsonファイルがすでにあることを前提としているので、そうでない場合は、事前にnpm initを実行しておく。

// package.jsonを生成(既にある場合は実行しない)
$ npm init

// ESLintの設定ファイルをセットアップする
$ npx eslint --init

3. 9個の質問に答える

  • $ npx eslint --initを実行すると9個の質問をされるので、答えていく
  • 選択にあたってこちらの記事を参考にした。
    ESLintのセットアップ方法(Mac) - Qiita
  • フィヨルドブートキャンプのプラクティスでは、

    チェックするルールはプロジェクトごとに違いますが、特になければJavaScript Standard Styleを使いましょう。

とあったので、7個目の質問で「Standard」を選んだ。 どのようなStyleかは、JavaScript Standard Style に日本語で詳しく解説されている。

? How would you like to use ESLint?
  To check syntax only 
  To check syntax and find problems 
> To check syntax, find problems, and enforce code style //これを選んだ

? What type of modules does your project use? (Use arrow keys)
  JavaScript modules (import/export)
  CommonJS (require/exports)
> None of these //これを選んだ

? Which framework does your project use?
  React
  Vue.js
> None of these //これを選んだ

? Does your project use TypeScript? · No / Yes // No を選んだ

? Where does your code run? · browser, node //両方選んだ

? How would you like to define a style for your project?
❯ Use a popular style guide //これを選んだ
  Answer questions about your style
  Inspect your JavaScript file(s)

? Which style guide do you want to follow? 
  Airbnb: https://github.com/airbnb/javascript
> Standard: https://github.com/standard/standard //これがJavaScriptStandardStyle
  Google: https://github.com/google/eslint-config-google

? What format do you want your config file to be in?
   JavaScript
>  YAML
   JSON
// rubyの設定ファイルで一番使い慣れてるのでYAMLにした。

? Would you like to install them now with npm? // Yesにした

4. 設定ファイルができているか確認する

$ cd <インストールした場所>

// 設定ファイルの中身を見る
$ cat .eslintrc.yml
env:
  browser: true
  es2021: true
  node: true
extends:
  - standard
parserOptions:
  ecmaVersion: 12
rules: {}

$ npm ls
jsbook@ /Users/<ユーザー名>/jsbook
├── eslint-config-standard@16.0.3
├── eslint-plugin-import@2.23.4
├── eslint-plugin-node@11.1.0
├── eslint-plugin-promise@5.1.0
└── eslint@7.32.0

//=>成功!

ローカルにインストールした理由

公式のインストール手順では、$ npm install eslint --save-dev = ローカルでインストール方法が載っていたが、ESLint 最初の一歩 - Qiita では、$ npm install -g eslintとグローバルにインストールしていたので、ローカルとグローバルのどちらでインストールすべきか迷った。
考えた結果、ローカルにインストールすることにした。
理由は、

  1. 現場では、プロジェクトごとに違うルールでLinterを通すため、スコープを小さくインストールした方が良いと考えたため
  2. スクラム開発のプラクティスに入るまでは、特定のディレクトリ下でのみJavaScriptを書くため、グローバルにインストールする必要がなかったため
  3. 一次情報が一番信憑性が高いため


(「私はこういう理由でインストールしたよ」,「グローバルにインストールした方がいいよ」、などありましたら、コメントいただけると嬉しいです🙇‍♀️)

npxとは?

ESLintの設定ファイルをセットアップするために、$ npx eslint --initを実行したが、このnpxとは何なのか?

npxは、npmのバージョン5.2.0で導入されたコマンドで、ローカルにインストールしたnpmパッケージ(今回でいうESLint)を、このコマンド一つで簡単に実行してくれる

使い方

基本のコマンド

// ESLintをファイルに通す
$ npx eslint <ファイル名>

// 自動修正は--fixオプションを使う
$ npx eslint <ファイル名> --fix

FizzBuzz問題を例に、実行結果の見方を解説

ESLintを通す前のコード ❗ネタバレ注意❗

// fizzbuzz.jsファイル

for (let num = 1; num <= 20; num++) {
  if (num % 3 == 0 && num % 5 == 0) {
    console.log('FizzBuzz');
  } else if (num % 3 == 0) {
    console.log('Fizz');
  } else if (num % 5 == 0) {
    console.log('Buzz');
  } else {
      console.log(num);  // ここはわざとインデントをずらした
  }
}

これにESlintを通してみると、実行結果は以下のようになった。

$ npx eslint fizzbuzz.js 

/Users/<ユーザー名>/jsbook/fizzbuzz.js 

  2:15       error  Expected '===' and instead saw '=='           eqeqeq
  2:31       error  Expected '===' and instead saw '=='           eqeqeq
  3:28       error  Extra semicolon                               semi
  4:22       error  Expected '===' and instead saw '=='           eqeqeq
  5:24       error  Extra semicolon                               semi
  6:22       error  Expected '===' and instead saw '=='           eqeqeq
  7:24       error  Extra semicolon                               semi
  9:1        error  Expected indentation of 4 spaces but found 5  indent
  9:22       error  Extra semicolon                               semi

✖ 9 problems (9 errors, 0 warnings) 
  5 errors and 0 warnings potentially fixable with the `--fix` option.


rubocopとは実行結果の表示が違い、戸惑ったので、実行結果の見方を以下に追記した。

$ npx eslint fizzbuzz.js 

/Users/<ユーザー名>/jsbook/fizzbuzz.js // ESLintを通したファイルのパス
//行番号:何文字目か  種類    メッセージ                                     ルール名
     2:15         error  Expected '===' and instead saw '=='           eqeqeq
     2:31         error  Expected '===' and instead saw '=='           eqeqeq
     3:28         error  Extra semicolon                               semi
     4:22         error  Expected '===' and instead saw '=='           eqeqeq
     5:24         error  Extra semicolon                               semi
     6:22         error  Expected '===' and instead saw '=='           eqeqeq
     7:24         error  Extra semicolon                               semi
     9:1          error  Expected indentation of 4 spaces but found 5  indent
     9:22         error  Extra semicolon                               semi

✖ 9 problems (9 errors, 0 warnings) // 9つの問題(うち、エラーは9個, 警告は0個)
  5 errors and 0 warnings potentially fixable with the `--fix` option.
  // 5つのエラーと0つの警告が、`--fix`オプションで修正可能な可能性がある

違反の意味が分からないときの調べ方

実行結果を見て、指摘されている違反の意味が分からないときは、以下のサイトでルール名(例:上記のeqeqeq)で検索すると詳細を知ることができる。

errorとwarningのちがい

f:id:Saki-Htr:20210826132603p:plain
「ワーニングとは|「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典」より引用

error

  • 問題があると判断したもの
  • 該当部分の修正が必要

warning

  • ユーザに確認し、判断して欲しいもの
  • 「何とかなったっぽいけど、できれば注意して」「できるけど、できれば止めて」なもの

違反が無かったときの実行結果

違反が無かったときの実行結果が、rubocopとは異なる
rubocopを通して違反が一つも無い時は、no offenses detected(違反は検出されなかった)と表示される。

$ rubocop <ファイル名>
Inspecting 1 file
.

1 file inspected, no offenses detected

しかし、ESLintは何も返ってこない

~/jsbook> $ npx eslint fizzbuzz.js
~/jsbook> 

--fixオプションを使ってみる

上記のコードに--fixオプションを使って自動修正を行うと、以下のコードになった。

自動修正後のコード ❗ネタバレ注意❗

for (let num = 1; num <= 20; num++) {
  if (num % 3 === 0 && num % 5 === 0) {
    console.log('FizzBuzz')
  } else if (num % 3 === 0) {
    console.log('Fizz')
  } else if (num % 5 === 0) {
    console.log('Buzz')
  } else {
    console.log(num)
  }
}

VSCodeにESLintを設定する

VScode拡張機能の検索で、ESLintを探して、Installをクリック。

f:id:Saki-Htr:20210826135515p:plain

これですぐに使えるようになる。

違反がある所にカーソルを当てると、風船のマークが表示される。

f:id:Saki-Htr:20210826135641p:plain

風船をクリックするとメニューが出るので、やりたいことに応じて選ぶ。 f:id:Saki-Htr:20210826135704p:plain

参考記事