はじめに
1月末〜システム開発のプラクティスに入り、先日自分が作った全てのPRがマージされたので、振返りを書きました。
途中、自作サービスのエレベーターピッチ&ペーパープロトタイプ作成や技術検証に取り組んだり、1月中旬〜3月中旬の2ヶ月間のみ、働いているパートのシフトを週4から週5に増やしたり、FBC内でゴールデンウィークに開催されたEverydayRailsという書籍の短期集中輪読会に参加したり、とこのプラクティス以外にも色んなことに取り組んでいたのもあり、想定していたよりも時間がかかってしまいました。
システム開発に取り組む中で、たくさんの学びや気づきがあったので、「最近月ごとの振返りも書いていないし、自作サービスの開発に本格的に着手する前に、しっかり振返りをしておきたい。今の自分の気持ちは今しか書けないので残しておきたい!」という強い気持ちがあったので書きました。
また、これからシステム開発のプラクティスに入られる受講生の方が、システム開発がどんなものかを知る助けになれば嬉しいです。書きたいこと・伝えたいことを全部詰め込んだら、2万字を超えとんでもない文量になってしまったので、気になった箇所をつまみ食いして読んでいただけたら嬉しいです🙏
目次
- はじめに
- 目次
- そもそもシステム開発プラクティスとは、どんなことをするのか
- 私が作成したPR一覧
- レビューしたPR一覧
- システム開発に入る前の心境&入ってみてどうだったか
- 開発に入った頃の失敗いろいろ
- 学んだこと
- 心がけていたこと・やって良かったこと
- "こうすればよかった"と思うこと
- 課題に感じていること
- 嬉しかったこと
- おわりに
そもそもシステム開発プラクティスとは、どんなことをするのか
システム開発は、FBCのカリキュラム(プラクティス)の、「開発に参加して PR を送りマージする」 の部分に当たります。
日報の作成・提出、質問の投稿・回答、イベントのお知らせ・申込などでいつもお世話になっているFBCのWebアプリの開発をチームで行います。
OSSなので、リポジトリはこちらで公開されています。もしアプリを使っていて、「あれ？これはもしかしてバグかな?」とか「ここの挙動がこうだったら使いやすいと思うな〜」といったことがあれば、システム開発プラクティスに到達しているかどうか関係なく、誰でもissueを立てたり、PRを作成することができます。
どの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アプリのコードはずっと量も多くて複雑ですし、APIやjbuilderといった、ここで初めて触れるものもありました。自分が作りたい機能の実装方法が思い浮かばず、「どこから手をつけていこう」と途方に暮れることもありました。
しかし、土台となる知識や考え方は、これまでのプラクティスで身についているなと感じました。
システム開発に入る前のプラクティスでは、「この知識は実務でどういう時に使うのだろう」と、あまり実際のお仕事で使う時のイメージが湧かない時もありましたが、開発に入ってみると、「あのプラクティスでやったことが、この機能の実装で使われてる!」「あの知識はここで大事だったのか!」という伏線回収をずっとしている感じでした。
「今までのプラクティスの知識は、実際の開発でどう活きてくるか」は、FBC卒業生のアルトさんがLTで発表してくださっているので、とても参考になると思います。
開発に入った頃の失敗いろいろ
開発に入ったばかりの頃は、初めてのことばかりで慣れておらず、色々と失敗もしました。
例えば、
- これまでコードを見ていただく側(レビュイー)しか経験したことがなかったので、GitHubのレビュワーの操作がよく分からず、初めてレビューしたPRで、Approveした後に間違えて「Re-request review」ボタンをクリックしてしまった。(本来はレビューをお願いした人が、もう一度同じ人に見ていただく時に押すボタン)
- 開発環境とテスト環境の違いが分かっていなかったので、
db/fixturesとtest/fixturesの違いも分からなかった - FBCのシステム開発では、
rebase方式を採用していて、merge方式は行わないことをあらかじめFBC内のドキュメントに書かれていて、それを読んだことがあったのに、間違えてmerge方式でコンフリクトの解消を行ってしまった。 - かんばんの自分のissueのタスクボードを、ステージング環境で動作確認して大丈夫だったら「完了」に移動すると勘違いし、移動させてしまった。本当は「完成」に移動させるのは、本番リリースしてから動作環境確認できたら移動するルール。
- レビューで、OKだと思って通したら、次の日テストとLintが落ちていたことに気づいた。すでにkomagataさんにレビュー依頼の連絡が行っていたので、慌ててご報告した。
というように、最初色々な失敗をしたので、落ち込むこともありました。
ですが、そういった失敗も自分の分報チャンネルに逐一書いていて、同じ時期にチーム開発に入った方に「自分も同じところを勘違いしていました。」 など仲間の方からコメントいただいたり、 すでにシステム開発プラクティスを終えられたFBC卒業生の方に、アドバイスをいただけたので、そこまで落ち込まずに前向きに行動を変えていく方にシフトしていくことができました。
勿論、失敗しないように事前にしっかり調べることは大事ですが、起こしてしまった時は、反省をしっかりしつつ、気持ちはひきずりすぎないようにして、「次同じ失敗をしないようにするには、どういう工夫ができるか」、これからの行動をどうするかに意識を向けるようになりました。
学んだこと
名前重要を改めて実感
コードを書く時に、まず自分で一から書く前に、実装するのに使えそうなメソッドが無いか探すのですが、まずメソッド名を見て、「これを使えばほしい情報を取得できそう」と判断して、メソッドの中身のコードを見るので、「名前重要」の大切さを実感しました。
これまでも、Rubyのプログラムの課題をやっていて、「名前付けが下手で、時間を置いて読んだら、自分で書いたコードなのにメソッドの中身が何をしているか分からなくなってしまった😂」ということがありました。ですが、自分一人だけでなくチームで開発するという経験をしたことで、他の人から見ても分かりやすいコードを書く意識の大切さをより実感しました。
コードを書くよりも、読んでいる時間の方がずっと長い
これは、システム開発に入る前から、メンターさんからよく聞いていた言葉でしたが、本当にその通りでした。
自分が担当しているissueを実装するにあたって、書く前にまず、既存のコードがどうなっているかを理解する必要があります。
例えば、コントローラにインスタンス変数が元々定義されている時、自分のやりたい実装にも使い回せるものか、追記する必要があるかは、コードの中身を読んでみるまでは分かりません。
レビュー依頼された時は、いつ見られるかこまめに連絡する
自分の作成したPRを、同じ時期にシステム開発をやっている、任意のFBC生1名に、レビューをお願いすることになっています。
お願いされたレビューをなかなか返せず、「レビュー依頼させていただいているのですが、どうなっていますか〜」とご連絡をいただいたことがありました。
最初の頃はレビューを終えるのにどれくらいの時間がかかるのか見積もりができず、「少なくともこれくらいまでには返せるだろう」と思っていたら予想が外れて、予定よりも返すのが遅くなってしまうことがありました。
そのため、もちろんすぐにレビューをお返しするのが一番なのですが、3月末までは、働きながらシステム開発をやっていて、すぐにお返しできなかったり、手持ちのレビュー依頼をすでに複数持っていたりすることがあったので、時間がかかりそうな時は、「すみません、返すのが○日くらいになりそうなのですが、それでもよろしければ、ぜひレビューやらせていただきたいです」というように連絡を取るようになりました。
人によって、レビューをいつ頃までに返してほしいかの考え方は異なりますし(もちろん早ければ早いほど良いですが😅)、レビューを依頼した側から、「早くレビューしてほしい」とか「時間がかかりそうなので他の方にお願いしますね」などとは言いにくいと思ったので、「もし▲日にお返しだとちょっと遅いな〜ということであれば、他の方にご依頼いただけましたらありがたいです。せっかくご依頼くださったのに申し訳ないです。」とお伝えするようになりました。
振り返って考えると、お仕事は自分一人で完結するものではなく、ベルトコンベアのように、誰かが止まるとその後ろも止まってしまうので、なるべくこまめにコミュニケーションをとって、流れが止まらないようにすべきだったと思います。
アジャイル開発の考え方も、小さく作って早くユーザーに届けて、反応を見てまた開発を進めて、という風に開発サイクルをどんどん回していくという考え方なので、エンジニアとして働かせていただけることになったら、「早くユーザーの元に届けるには、今自分がどう動くのが最適か」を意識して仕事せねばと思っています。
心がけていたこと・やって良かったこと
大声で作業する
システム開発プラクティスに入る前から、machidaさんから、「システム開発プラクティスは、周りに自分の状況を伝えたり、詰まった時に素直に頼れたりする人が、順調に卒業していく」と伺っていたので、分報や日報に作業していることを実況しながら取り組むようにしていました。
こちらは、machidaさんから教えていただいた参考記事です。
私の場合は、システム開発に入る前から、自分の分報チャンネル で作業していることやその時の気持ちを、逐一書きながら課題に取り組んでいたので、とくに変わらず続けてやっていたという感じでした。
詰まった時に、この分報チャンネルで数えきれないほど何度も助けていただき、コメントで教えていただいたり、「画面共有してもらって一緒に見ましょうか?」と声をかけていただいたりしました。助けてくださった方々には感謝の気持ちでいっぱいです🙏 本当にありがとうございました!
作業したことを記録しながら進める
分報とはまた別に、Notionに、取り組んだissue/レビューしたPRごとにページを作って、作業ログを書くようにしていました。
具体的には、調べて理解したこと、分からないこと、自分で考えた実装のロジックや、何が分からないか分からない時は、その時分からないことを全部書き出して現状整理、などなど何でも書いていました。
これを始めたきっかけは、FBC卒業生のikuma-tさんがLTで発表されていたのを聞いて、自分もやってみようと思ったためです。
始めた時の詳細はこちらの記事に書いています。
これのおかげで、あんまり実装が進んでなくても、「あんまり進んではないけど、今日もがんばった!」と思えました。
issueに取り組んでいると、「この機能をどうやったら実装できるか」「このテストはどう書けばいいのか」という、分からないことと向き合っている時間が長いです。
そしてできなかったことができて「やったー!」と思っても、すぐにまた分からないことがやってきて、調べるの繰り返しです。
分からないことが出てくるたびに、「自分でできるのか」と不安になるので、本当は進んでいるし、できたこともあるのに、目の前の分からないことに囚われて落ち込む時もありました。
そういう時に、作業ログを見直して、「1週間前はこれも実装できてなかったんだ」「3日前はこれも分からなかったんだ」と、自分の成長を実感できました。
ミーティング前に、デモの準備と報告内容の整理をする
週1のミーティングでは、必ず15~30分前にはデモのための画面の用意と、報告内容の原稿作成をしていました。原稿を用意していたことで、緊張していても、落ち着いて報告ができ、「伝えようと思っていたのに忘れた😨」という事態も防げました。
分かりやすいデモをする
ふりかえり・計画ミーティングのやり方のドキュメントに、「今週やったissueの報告は、プログラマー以外にもわかるように説明しましょう。」とあったので、デモも見やすいように工夫していました。
例えば、以下のPRのデモをする時は、タブが２つあり、全てタブと未返信タブ両方の表示結果をお見せする必要があったのですが、1画面だと、一度に片方のタブの表示結果しか見ることができないので、画面を分割して同時に2つ共お見せしました。(この時machidaさんに「見やすい」と仰っていただけて嬉しかったです🥳)
仕様について疑問に思ったら、すぐに確認する
自分の担当issueの仕様について疑問に思ったことは、すぐに質問をして認識のすり合わせをしていました。
雑談タイムをやっている日であればそこで確認して、issueのコメントに記録し、やっていない平日や土日であれば、issueのコメント上で質問していました。
システム開発プラクティスに入る前から、メンターさんに
相手が言ったことを認識の擦り合わせをしないで、「こういうことか！」と思って、全部作り上げてプルリクを送ると「違うそうじゃない」となりがち。
「インドカレー」だと思って作ったら、相手は「ビーフシチュー」と思っていることも。
お互いの認識が同じということはごく稀で、認識が違うのが当たり前の毎日。
と教えていただいていたので、出戻りを防ぐためにも、仕様で気になったことはこまめに聞くようにしていました。
(参考：顧客が本当に必要だったものから学ぶこと | キャスレーコンサルティング株式会社)
ただ、以前ミーティングで、「仕様についてどれくらい自分で考えて、どれくらい確認すればいいのか」という質問が挙がった時に、machidaさんが
一旦自分の考えで実装してみたのを「こんな感じでいいですか」と確認してもらう方法で進める方が多い
と仰っていたので、人によってやり方は違いますし、私も自分のやり方に固執せず、臨機応変にアップデートしていこうと思っています。
自分の意見を持つ
上述の通り、仕様について疑問に思うことはmachidaさんとkomagataさんに適宜確認していたのですが、エンジニアとして働くことになったら、より主体性が求められ、自分の意見を持つことが大事だと考えていたので、「どうすればいいですか」という丸投げではなく、自分の考えも添えて質問するようにしていました。
仕様について、ユーザーの気持ちをあれこれ想像して考えるのは楽しかったです。また、「こういう理由で、この仕様にしてほしい」と教えてくださるので、とても勉強になりました。
テキストコミュニケーションは、受け手の立場に立って書く
システム開発プラクティスでのコミュニケーションは、テキストでやり取りする割合が多いです。(これまでもテキストコミュニケーションが主だとは思いますが😅)
例えば、仕様について確認したい時に、雑談タイムがやっていない日はGitHubのissueにコメントして聞いたり、自分が作ったPRのdescriptionに、概要・変更点・動作確認手順を書いたり、レビューのやり取りは基本的にPR上のコメントでやり取りをします。
自分の担当issueや作ったPRについては、自分が一番状況を理解しています。理解している側が分かりやすく丁寧に書いた方が、受け手の負担が少なく済み、より少ない時間で効率的に仕事を進められると思ったので、そのようにしていました。
具体的には、以下のことをやっていました。
質問したいことが複数ある時は、最初に「◯点質問したい」と個数を書く
見出しをつける
最後まで読まないと内容が分からないのは受け手にとって読みづらいと思います。見出しをつけることで、何を伝えたいかが最初に分かり、「この下の文章にはだいたいこういうことが書いてある」とイメージしやすいと思ったため、コメントに見出しを付けるようにしていました。
descriptionには詳細を丁寧に書く
説明が不十分だと、レビュワーが理解しづらいので、スクリーンショットの変更点を必ず赤い枠で囲ったり、変更点が多い場合は、マークダウンのTableを使って見やすくしたり、動作確認手順を詳細に書くようにしていました。
ちなみに私が作ったPRの中で、一番気合いの入ったdescriptionはこちらです(笑)
これとほぼ同じ作業を行うであろうissueがもう一つあるため、そのissueの担当になった方のためにも、なるべく理解しやすいように丁寧に書くことを心がけました。ちなみにこちらです。
practices.positionを削除したい · Issue #4246 · fjordllc/bootcamp · GitHub
レビューでは、テキストより口頭でのコミュニケーションが適している時は、ペアレビューの時間をいただく
以下の3つのPRは、FilesChangedの数が多い等重ためのPRだったので、ペアレビューのお時間をいただきました。
- categories.positionを削除した by Saki-htr · Pull Request #4641
- 大名エンジニアカレッジ特有の機能・フラグを削除した by Saki-htr · Pull Request #5012
- 未完了の提出物一覧を担当メンターで絞り込めるようにした by Saki-htr · Pull Request #4954
はじめはペアレビューってどんな風に進めていけばいいんだろう💦と進め方が分からなかったですが、何回か重ねていくうちに、コツが掴めてきました。
具体的には、
- 一緒に動作確認をして、挙動がおかしい点や自分のローカル環境と異なる点があったら2人で原因を調べる
- RailsとVueの両方を書いていて、コードの流れの理解が難しいPRは、大まかなコードの流れや各コードが何をしているかを説明する
- レビュワーの方から質問していただいて、それに答える
というようなことをやっていました。これはレビュワーの方によって聞きたいことが異なるので、事前に「これをやるぞ!」とガッチリ決めておくというよりは、当日臨機応変に進めていました。
ペアレビューを何回か経験したことで、開発メンバーの方とコミュニケーションを取る時に、テキストと口頭どちらが適しているかの判断がしやすくなりました。また、ペアレビューでお話したことは、GitHubのPRにも書いて必ず残すようにし、他の開発メンバーや後からこのPRを見る方が話した内容を把握できるようにしていました。
レビューする時は、良いと思った所を伝える
レビューをやり始めた当初、PRをApproveする時に、何とコメントしてお返しすればいいか迷ったので、「LGTMです〜」と返していました。LGTMとは、「looks good to me」の略で、「私は良いと思います〜」的な意味です。(参考:「looks good to me」)
他の方はどんな風にコメントされているのかな〜と、色んな方のPRを見ていく中で、良いと思った部分を褒めている方がいらしたので、真似をしました。
レビューでどんなことを書くかの考え方は、人それぞれだと思いますが、個人的には、「チームで開発をしているので、開発メンバーの良いと思った所は積極的に伝えたい」と思っているので、メンバーのPRの良いと思った所や、自分が知らなくて勉強になった所を伝えるようにしていました。
"こうすればよかった"と思うこと
PRが、issueの範囲を超えそうだったら、別PRに切り出す
以下のPRを作成した時に、後から振り返ると、PRを分けるべきだったと思いました。
これは、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は、元々××の実装をされた方が●●さんだから、詰まったら●●さんに聞くといいよ〜」とアドバイスをくださる場が平日毎日あったことは、私にとってとても大きかったです。
メンターの方々や、輪読会で助言くださったり私の分報チャンネルにコメントで色々と教えてくださった方々、本当にありがとうございました!
まだ自作サービスという最後の一山が残っているので、このプラクティスで学んだことを存分に活かして、引き続きがんばっていきます。
