Sochi419のブログ

プログラミング初学者です。Ruby, JavaScriptを学習中です。猫が好きです。フィヨルドブートキャンプというスクールの受講生です。

チーム開発の振り返り

これは「フィヨルドブートキャンプ Advent Calendar 2023」の5日目の記事です。 昨日のエントリーは、LEFさんの「世界一わかりやすいWebSocketのサンプルコード(とその解説)」でした!

はじめに

 私の所属しているフィヨルドブートキャンプでは「システム開発」というプラクティスが用意されています。 5月末 ~ システム開発のプラクティスに入り、もうすぐ終わりが見えてきたので、振り返りを書こうと思います。

今回は以下のことについて書こうと思います。

システム開発とは?

 入会して間もない方は「システム開発」という言葉を聞いても分からないかもしれません。 「システム開発」って何!?という話なのですが、仕事と同じ様な形でチームでフィヨルドブートキャンプのアプリを受講生の手で改善していくプラクティスです。用意されたissueに対してポイントが設定されており、合計20ポイント分のissueを消化するとプラクティス終了となります。(私は今、17ポイントを消化して、最後のissueに取り組んでいる段階となります。) プラクティス名は「システム開発」ですが、「チーム開発」と呼ばれることの方が多いです。

システム開発に入る前後の心境

システム開発に入る前の心境

 正直、チームメンバーのレベルについていけるか心配でした。というのも私は過去のプラクティスの進度は早い方ではなく、プラクティスの提出物について、メンターからのレビューの数が他の受講生に比べて多いと感じていました。 また、今までのプラクティスは合格こそしたものの理解できているか自信があまりなく、昔やったプラクティスの内容をほぼ忘れかけていたためです。

システム開発終盤に来ての心境

 意外となんとかなる、というのが正直な感想です。というのもシステム開発の最初に行う作業は「good first issue」と呼ばれる、すごく簡単なもので、例えばUI上の文字を一部分訂正するだけ、のようなものです。そのため、最初に苦戦することはgit操作だと個人的に感じています。最初こそgithubの使い方に慣れが必要なものの、わからないことはすぐに質問をして解消をしていました。特に月水金の16時からやっている質問タイムで主に疑問の解消をしていました。テキストでの質問は、回答をいただけるまでのタイムラグが生じてしまうのに加えて、口頭で説明するよりも難しいため、主に口頭で質問をして疑問の解決をする、という場面が多かったです。途中で難しいissueを抱えてモチベーションが上がらない期間もありましたが、今もなんとかやっていけています。

システム開発で学んだこと

先人が実装した過去のPRは、自分のPRを実装するときの助けになる。

 実際に難しいissueを振られると、手も足も出ず「どうしたらいいの?」と頭を抱えて悩むときがありました。そんな時に役に立ったのが、過去に似たような実装をしているパターンがあります。例えば簡単な例を出すと、「お知らせページでは管理者かメンターしか編集できないようにする。」という機能を実装したい場合に、過去の他のPRで「質問ページでは質問者しか編集することができないようにする」というissueがあったとします。そのissueを眺めれば、「〇〇しか〇〇できない」という実装はどうやっているのか、知ることができます。上記は簡単な例ですが、過去のPRを見ることは自分の実装の助けにもなる場合があるし、何より他人の実装を眺めているだけで勉強になったりします。

仕事に対するイメージがついた

 システム開発のプラクティスに入るまで、仕事では実際にどんなことをやるのか、まっっっっったくイメージが湧きませんでした。システム開発を通して、実際の仕事でもこういう感じで実装していくのかというイメージを持つことができました。また、今までのプラクティスでは個人で進めていきますが、チームで開発していくことを経験することができました。

testを書けるようになってきた。

 システム開発のプラクティスに入ると、「ミニテスト」を書くケースが増えると思います。一応プラクティスで「ミニテスト」について学ぶのですが、プラクティスを終えても、私は理解した自信がありませんでした。しかし、システム開発に入るとミニテストについて嫌でも書くことになります。初めのうちはテストについてどう書けば良いか苦戦しましたが、システム開発ではたくさんのミニテストのサンプルがあるので、見て学ぶことができます。いろんなテストを書く場面に遭遇してテストを書く練習をすることが、テストを書くことができるようになる近道だなと思いました。

失敗したこと

相手との認識合わせの明確化

 issueを振られた時に、相手がどういう実装を望んでいるかについて認識合わせを明確化しないと、二度手間になりまた実装することになります。僕は失敗しました。実際に実装が完了して、「レビューお願いします!」と意気込んでも、確認者から「私が思っていた実装と違うんだけど。」と言われ、再度実装をする、というケースがありました。 まだ練習の段階だから許されますが、実際の仕事となると「納期」があると思うので、実装前の認識合わせはきちんと行いたいなと教訓になりました。

レビュー

 「システム開発」ももうすぐ終わりますが、いまだに他人のレビューを見ることは苦手です。私が他のチームメンバーにレビュー依頼をした時は、的確なアドバイスを頂けるが、私がレビューする立場となると、アドバイスが思い浮かばないケースが多々あり、アドバイスを捻り出すのに時間を費やしてしまう時がありました。「そもそも初学者なんだから、アドバイスが思い浮かばないのは当たり前」と、以前メンターさんに相談した時にアドバイスをいただきました。レビューはコミュニケーションという意味合いもあるので、アドバイスをするだけではなく、こちらから質問をしてみたり、実装について自分の知見になった場合は褒めたりお礼を言ったり、アドバイスをするだけではない、ということを学びました。

おわりに

 長々と書きましたが最後に感想を書くと、システム開発が他のプラクティスに比べて一番成長している実感があります。そもそも今までのプラクティスの内容を総動員して取り組むことになるので、今までのプラクティスの復習になります。また、卒業生が「実際に仕事をしてみて、システム開発でやったことと仕事でやることは似ている」と良く聞くので、システム開発を乗り越えることができれば、仕事でも最低限やっていけるかなという自信に繋がる気がします。ここまで、システム開発を終えた人みたいな感じでつらつらと書いていますが、まだ最後のissueが残っているので、全力で取り組みたいと思います!