この記事はフィヨルドブートキャンプ Advent Calendar 2025の14日目の記事です。
昨日は、いつもお世話になっているayu-0505さんのふわふわと理解するgit、Rails、DBの関係性 - 子育て中の勉強ログなどでした。
migrationファイルとschema.rbが発注書と領収書というのは言い得て妙だなと思いましたし、ブランチの部分をレストランで考えたら、フロントオフィス(ブランチA)とバックオフィス(ブランチB)がそれぞれ発注していた(migrationファイル)場合、1つの領収書(schema.rb)になるのかなと思いました。
とても良い記事だったので、何度も読み直させていただきます🙇
こんにちは、ひろきです。
2023年12月14日にフィヨルドブートキャンプ(以下、FBC)に入会し、2025年12月14日の今日、入会してちょうど2年を迎えました。
そして今日、無事、自作サービスをリリースし卒業することができました。
去年も同じ日にアドベントカレンダーを書きました。
去年と同じ内容で書くのも面白いかなと思い、モチベについて書いていきます。
去年の内容
モチベーションに左右されまくり、完全ライバルだったようです。
- スマホを遠ざける
- メモを取るようにする
- わからなくなったときはわかるところまで戻る
- やらない
的なことを書いていました。
1年の変化
この1年間は一瞬で過ぎましたが、色々なことがありました。
- FBCのコミュニティにどっぷり浸かった
- 所属地域rbができた
- カンファレンスに参加できた
1年目の私は、ひたすら1人でプラクティスを進めていたので、この1年の変化は自分でも信じられません。
FBCのコミュニティにどっぷり浸かった
去年はFBCのオフラインイベントには参加していましたが、オンラインのイベントには一切参加したことがありませんでした。
突然現れて、空気を悪くしないか不安だったからです。
今ではオンラインイベントはもちろん、Discordのボイスチャンネルにも気軽に参加しています。
イベント企画をしていたら気づいたらできるようになっていました。
年に数回のオフラインイベントもいいですが、定期的にオンラインで会話をすることは学習効果的にも良かったです。
所属地域rbができた
「三浦半島.rbのメンバー」って呼んでもらえるようになりました。
三浦半島.rbは東京Ruby会議12をきっかけに発足されました。
本当に初心者にも優しいコミュニティで、チーム開発で調べ尽くしてもわからなかった時に、 何度か質問もさせてもらっていました。
みなさん、前のめりになって答えてくださるので大感謝です。
主催の桐生あんずさんには、技術書店でもお世話になりました。
桐生あんずさんのブログ
1人で学習していたのが、イベントに参加していたら気づいたら色んな人たちに助けてもらいながら学習をするようになっていました。
あれから1年
とはいえ、やはりモチベーションが低い時期も多々ありました。
プラクティスを進めたい気持ちはあるのに、なかなかPCと向き合うことができませんでした。
原因としてFBCのプラクティスの「チーム開発まで」と「チーム開発から」で判明できる気がしました。
チーム開発まで
チーム開発直前のReactで一度大きくモチベが下がっています。
課題がはっきりしていた
チーム開発までのプラクティスでは、そのプラクティスの課題を作成し提出するだけの日々でした。
- 課題を確認しタスクを分解する
- 課題を完成させる
- レビューを待つ
- 待っている間に次に進む
- レビューが返ってきたら修正する
こんな感じです。
PCに座った瞬間にやることが決まっていた気がします。
一度手を動かしてしまえば、あとは続けるだけなのでまだモチベーションは下がりづらいです。
Reactは個人的に強敵だった
Reactのプラクティスでモチベーションが下がりました。
というのも、公式リファレンスをひたすら読むタームが個人的に大変だったからです。
難しいのはもちろんですが、とても長く、日本語訳が独特の文章なので頭に入ってきづらいのも理由の一つでした。
難しい&長いというダブルパンチで大分やっつけられました。
電車の中で読み進めていたことも悪手で、愚直に手を動かすべきだったかもしれません。
(結局、よくわからなくなって読み直しました)
Reactまでは単元ごとにプラクティスを修了する期間を決めていたのですが、ここで一度やめてしまった気がします。
ただ、公式リファレンスを読む作業をここまででたくさんしてきたので、リファレンス恐怖症は無くなっていきました。
[反省]
- 長い課題は小さく分割するべきでした
- 期間を意識するべきでした
- 手を動かすべきでした
チーム開発から
一方、チーム開発からはガラッと作業スタイルが変わります。
- issue(課題)を割り振ってもらう
- 何をするべきか調べる
- 該当コードを探す
- レビューをお願いされる
- タスクを分解する
- 実装する
- 開発MTGの準備をする
- 開発MTGに参加する
- チームメンバーにレビューを依頼する
- issueを割り振ってもらう連絡をする
- レビューが返ってきて対応する
- レビューをお願いされる
- スクラムマスターにレビューをお願いする
- 新しいissueの準備をする
- 新しいissueの実装する
- スクラムマスターのレビューが返ってきて対応する
- 自作サービス案を考える
などなど、多方面へ意識が分散されます。
今までと違い、1人だけの作業ではなくなるので、そっちに意識を取られてしまい集中が途切れる、ということがありました。
一度集中が切れると、なかなか戻りづらくコントロールが難しかったです。
キリの良いところで作業を終えるのと、突然、(別件を思い出し)作業が止まるのとでは全く違うので、いつでも気持ちを切り替えられるようにタスクの粒度を小さくするのが重要なのかなーと思いました。
チーム開発は長期戦なので、慣れてくるとモチベもペースも落ちがちです。
そうなると、脳内で色々対応しようとしてしまうため、タスクもざっくりになりがちな気がします。
私の場合は、issueに関してのタスクだけ残していて、その他は全て脳内管理をしていたのが間違いでした。
毎回作業前に、時間を測って5-10分程度「タスクを洗い出す」、「タスクをさらに細かくする」を書けるだけ書けば良かったなと思いました。
メモを取れば一旦忘れていいので、タスクに集中できます。
ただ、チーム開発ではモチベを維持できる部分もありました。
それは、開発ミーティングです。
開発MTGでは作ったものを画面共有でデモをします。
「それまでに仕上げないといけない」という気持ちが、モチベーションアップに繋がりました。
チーム開発は点数制でゴールが見えづらいのでモチベーション管理が難しいですが、開発MTGを一つに区切りにするのは効果的でした。
[反省]
- タスクの粒度をなるべく小さくして、急な中断に対応できるようにするべきでした
- 対応する相手とのタスクもメモに残して、集中するために脳内から排除すべきでした
- タスクを書く時間を無駄と思わず確保すべきでした
- 開発MTGまでに成果を出したいという気持ちが良い方向に通じました
余談ですが、
FBCのチーム開発で経験したことを三浦半島.rbで話すと、「あるあるw」といつも言われていたので、本当に実践向けのプラクティスなのだと思いました。
自作サービス
10月の中旬からミニアプリを作り始めました。
ちょうど10月の下旬に有給をまとめて取っていたので、この期間でいけるところまで作り切ってやろう、と決めました。
あわよくば11月中旬にはリリースしたかったのですが、考えが甘すぎました。
アプリとして機能するようにし、一旦デプロイまでしたのですが、そこから先がまだまだ長すぎました。
チーム開発時は、集中力も途切れやすく1日数時間しか作業できなかったのですが、自作サービスでは12時間、日によってはそれ以上作業していた気がします。
正直、めちゃめちゃきつくて休みたい時もあったのですが、なんとかリリースまでできました。
「カンバンでissueを作り消化する作業」が自分には向いていたのと、「終わりを意識していたこと」がモチベーション維持の大きな要因だったと思います。
おわりに
この記事では、「タスク分解」と「期間を意識する」という部分を何度も書きました。 自作サービスでは自然とこの2つができていました。
実はFBCでは「タスクばらし」を推奨しています。
私自身が実践できているのかわからないので、「タスク分解」と言っていますが、これから「タスクばらし」が実践できている人間になっていけたらと思います。
まとめです。
2年間学習を続けた結果、
- タスクをできるだけ小さく分割する
- 気持ち短めに期間を設定する
が私の中のモチベーションを維持する方法でした。
参考になれば幸いです。
最後に、FBCの完走は本当に大変です。
学ぶことが多いので長期戦ですし、オンラインに不慣れだと色々苦労することもあるかもですし、メンタルにも影響があるかもしれません。
辛いときは、仲間に相談して欲しいですし、意図的に休みを作って思いっきり休んで欲しいです。
ちなみに私は休むのが下手だったので、これからは上手に休んでいきたいです！
これからも頑張ります！
明日は、フィヨルドブートキャンプ Advent Calendar 2025 | Fjord Calendarの開発者、hagiya0121さんと、
FBCメンターのjnchitoさんのベテランプログラマは生成AIをどう活用しているのか？そして初学者は生成AIをどう活用すべきか？ - give IT a tryです！
それでは、さようなら
