こんにちは。かっさんと申します。EC事業部でWebアプリケーションエンジニアとして開発業務を行っています。今日は、合同会社フィヨルドさんが企画、運営しているフィヨルドブートキャンプに参加した話を紹介します。
フィヨルドブートキャンプとは
プログラマーとして就職を希望する方のための就職支援サービス。プログラマーとして就職するためのスキルを身につけるための学習支援と、就職支援を行います。学費は就職時に就職する企業が支払うので無料でスキルを身につけられます。
とあるように本来はプログラマーを目指す人のための就職支援サービスとなっています。私は今年の7月にWeb業界未経験で入社しました。そして、Webアプリケーション周りの知識、経験をつけるために上記のサービスを運営されているフィヨルドさんで1ヶ月間研修を受ける事になりました。
メンターとして、フィヨルドの駒形さん(@komagata)と町田さん(@machida)、そして弊社からはけんちゃんさん(@kenchan)、じゅーんさん(@june29)、やまちゃんさん(@kymmt90)も加わり、設計やコードについて相談にのって頂いたり、コードレビューをお願いしました。
何をしたか
研修初日に研修内容を相談しました。
- Rails Tutorialは一周した程度
- データベースについては業務で使用していた
- 趣味でLinuxを使用してHTTP/2に対応したサーバーを立てて運用している
という自分のスキルを駒形さんと町田さんに伝えたところ、Ruby on Railsを使用したWebサービスの開発フローを学ぶのが良いのではないかという話になりました。そして、フィヨルドブートキャンプの中で運用されているE-Learningシステムの改修を行うことになりました。
開発は1週間をスプリントとした簡易的なスクラムで行いました。また、フィヨルドブートキャンプの受講生の中には、E-Learningシステムの改修をカリキュラムとしている方々がいらっしゃいます。私は、その方々と一緒にチームとなって「振り返り・計画ミーティング」と呼ばれるミーティングを週1で開催し、見積もりやプロダクトオーナーへの成果物説明を行いました。
私はこの開発中に以下の改修を行い、システムの利便性向上に貢献しました。
オフィスの環境
フィヨルドさんは初台にオフィスがあります。私は週3日をフィヨルドさんのオフィス、残りをペパボのオフィスで過ごしました。フィヨルドさんのオフィスには、受講生が自由に使用できる席が用意されています。また、大きなディスプレイがあり、駒形さんとペアプロする機会を設けていただいた際にはこのディスプレイでペアプロするという貴重な経験を得ることができました。そして、フィヨルドさんのオフィスで学んでいる他の受講生の方々は皆さんモチベーションが高く、とても良い刺激を受けることができました。
学び
私は今回の研修を通して、以下の学びや気付きを得ることができました。
GitHubを使用したチーム開発フローを学ぶことができた
私は今までGitHubを用いたチーム開発を行ったことがありませんでした。今回、初めてGitHubのIssueやPull Requestを活用したチーム開発フローを学ぶことができました。
運用されているデータのマイグレーションの手法を学ぶことができた
今回の改修の中には、入力項目のバリデーションを変更したことに起因するデータのマイグレーションを行うものが存在しました。簡単な内容ではありますが、データベースのデータをマイグレーションするRakeタスクを作成し、本番環境で実行する機会をいただけました。駒形さんから、Rakeファイルにoneshotというnamespaceを作成してその中にタスクを定義することにより、「一度だけ実行するスプリクトである」ことを明示しつつマイグレーションのタスクが書けることを教わりました。
コードレビューのありかたについて見直すことができた
今回のメンターとのコードレビューで自分のコードレビューのあり方について見直すことができました。
最初、1つのPull Requestにはある程度の変更をまとめて、それを確認頂くのが望ましいと考えていました。1つのモデルに対する画面表示や追加、編集の実装程度なら、まとめておくことでレビューの回数が減りレビュアーの負荷が下がると考えていたためです。しかし、今回のメンターとのレビューをやりとりすることでその考えを改めることになりました。
1つのPull Requestはシンプルにする
1つのレビューを依頼するときのコードの粒度を見直すきっかけになりました。1つのPull Requestで異なる観点の修正を複数入れてしまうと、そのPull Request上でコメントのやり取りが散らかってしまい速やかなマージには繋がりません。
人とレビューを行うのではなく、課題に対してレビューを行う意識を改めて持つ
「レビューは人(レビュアー)と行うのではなく、今ある問題に対してレビュアーとレビュイーで協力して解決を行うもの」と何度かインターネット上で見かけることがありました。それを頭に入れてるつもりだったのですが、「レビュアーの負荷が下がる」という記述から見て取れるように、「人と行うレビュー」を意識していたのでした。そのような発言をしていたところメンターのじゅーんさんから以下の指摘をいただき、はっとさせられる場面がありました。
お仕事をしていると「ご迷惑をおかけして云々」「お手数をおかけして云々」「お忙しいところ云々」のようなやりとりに出会うことがちょくちょくあります。 「迷惑をかけない」「手間をかけない」などを最重視するとしたら「なにも相談しない、なにも依頼しない」が最適解になってしまうので、ぼくはそういう方向に向かうコミュニケーションは避けたいという意識を持って過ごしています。別にみんな、迷惑をかけないためにお仕事しているわけじゃないと思うんですよ。 Pull Request のゴールはとってもわかりやすくて「マージ」ですよね。スムーズに早くマージできるというのはレビュイーにとってもレビュアーにとってもうれしいことなので、そこを目指して双方がコミュニケーションをとっていくとよいと思います。 少しでもスムーズに少しでも早くマージを達成できるように。そういう観点をもってレビュアーを巻き込んでほしいとぼくは願っていますし、それを満たしやすくなるテンプレートであってほしいと思います。
私は、このメッセージやそれまでのレビューのやり取りを通して、よりスムーズなマージができるよう取り組みました。具体的には、やらないこと、自信がなく、確認がほしいところをPull Request内でレビュアーに伝えるようにしました。これは自分とレビュアーとの情報量の差を埋めるために欠かせない、とても大事なことだと感じました。
まとめ
私は、今回の研修でWebアプリケーションエンジニアとしてやっていけるという確かな手応えを感じることができました。もちろん、この1ヶ月でなんでもできるようになったわけではありません。あくまで開発に参加できるスタートラインに立てたという認識です。
これからも精進し、素早い正確なアウトプットでチームに貢献できるよう努めます!