スクラム初学者が『SCRUM BOOT CAMP THE BOOK』を読んで学んだスクラムの考え方

はじめに

こんにちは、Yoshiwoです。
私は現在、フィヨルドブートキャンプ（FBC）でWebエンジニアへの転職を目指して学習しています。

これまで『アジャイル開発』について学ぶ機会はありましたが、「スクラム」という言葉は知っていても、具体的に何をするのかまでは理解できていませんでした。
フィヨルドブートキャンプではチーム開発の機会もあるため、その前にスクラムの基礎を学んでおきたいと考え、本書を手に取りました。

本書はスクラムのルールだけでなく、「なぜそのやり方をするのか」まで丁寧に解説されており、初学者の私でもスクラム開発の全体像をイメージできる内容でした。
今回は特に印象に残ったことをまとめます。

ソフトウェアを作ることが目的ではない

本書を読んで最初に印象に残ったのは、

ソフトウェアを作ること自体が目的ではない

という考え方です。

開発というと「機能を作ること」に意識が向きがちですが、本当に大切なのは、

• 利用者の課題を解決すること
• 顧客に価値を届けること
• ビジネスとして成果を出すこと

です。

そのため、最初に立てた計画を最後まで守ることよりも、
「今作っているものは本当に価値があるのか？」
を継続的に確認しながら進めることが重要なのだと学びました。

スクラムは変化を前提にしている

スクラムでは、

• 事前にすべてを正確に予測することはできない
• 開発を進める中で状況は変わる

という考え方を前提にしています。

そのため、

1. 短い期間で開発する
2. 成果物を確認する
3. フィードバックを受ける
4. 改善する

という流れを繰り返します。

私はこれまで「最初に完璧な計画を立てることが大事」だと思っていました。
しかし実際には、最初から完璧な計画を作ることは難しく、むしろ変化に対応しながら進める方が現実的なのだと感じました。

スクラムはチーム全員で進める

本書では、

• プロダクトオーナー
• 開発チーム
• スクラムマスター

といったロール（役割）が登場します。
それぞれ役割は異なりますが、どれか一つが偉いわけではありません。

特に印象に残ったのは、

ロールは肩書きではなく目印である

という考え方です。

役職や経験年数ではなく、
「その役割に必要なことへ真剣に取り組めるか」
が重要だと書かれていました。

チーム開発では技術力だけでなく、人との協力やコミュニケーションも大切なのだと感じました。

振り返りを仕組み化しているのが面白い

スクラムには「スプリントレトロスペクティブ（振り返り）」があります。
ここでは、

• うまくいったこと
• 改善したいこと
• 次に試すこと

を話し合います。

本書では、

バグを直すのではなく、バグが生まれるプロセスを直す

という考え方が紹介されていました。

私は普段の学習でも、

• なぜ理解できなかったのか
• なぜ時間がかかったのか

を振り返ることがあります。
スクラムの考え方は、プログラミング学習そのものにも応用できそうだと感じました。

見積もりは予言ではない

スクラムでは見積もりを行いますが、本書では

見積もりは推測である

と繰り返し説明されています。

最初は「正確な見積もりを出さなければならない」と思っていました。
しかし実際には、

• 不確実なことは当然ある
• 完璧な予測はできない
• だからこそ定期的に状況を確認する

という考え方でした。
見積もりを絶対視するのではなく、より良い判断をするための材料として使うという発想が印象的でした。

スクラムの5つの価値基準

本書の基礎編の最後で紹介されていたスクラムの価値基準も印象に残りました。

• 確約：それぞれの人がゴールの達成に全力を尽くすことを確約する
• 勇気：正しいことをする勇気を持ち、困難な問題に取り組む
• 集中：全員がスプリントでの作業やゴールの達成に集中する
• 公開：すべての仕事や問題を公開することに合意する
• 尊敬：お互いを能力ある個人として尊敬する

スクラムはイベントやルールだけを守れば良いわけではありません。
チーム全員がこれらの価値観を共有して行動することで、より良い成果につながるのだと理解しました。

特に「公開」と「尊敬」は印象に残りました。
問題を隠さず共有し、お互いを尊重しながら改善（カイゼン）を続けるという考え方は、開発だけでなく日々の学習にも活かせそうだと感じました。

おわりに

基礎編と実践編の2部構成で「スクラム」について学べる『SCRUM BOOT CAMP THE BOOK』は、スクラムの入門書として非常に読みやすい一冊でした。

私はこれまでスクラムについて断片的な知識しかありませんでしたが、本書を読んだことで、

• スクラムが何を目指しているのか
• なぜ短い期間で開発を繰り返すのか
• なぜ振り返りを重視するのか

などを理解できたように思います。
現在は個人学習が中心ですが、今後フィヨルドブートキャンプでのチーム開発に携わる際には、本書で学んだ考え方を実践しながら経験を積んでいきたいと思います。

スクラムをこれから学ぶ方や、アジャイル開発の全体像を知りたい方に、ぜひ手に取っていただきたい一冊です。

www.shoeisha.co.jp

実務未経験の私が『いちばんやさしいアジャイル開発の教本』を読んで学んだこと 〜 アジャイル開発の考え方がイメージできた一冊 〜

はじめに

Webエンジニアへの転職を目指して学習している中で、最近よく耳にするようになったのが「アジャイル開発」という言葉です。
ただ、最初の印象は正直こんな感じでした。

• 「なんとなくチームで進める開発手法？」
• 「スクラムとかスプリントとか、なんか横文字が多くて難しそう......」

そんな状態で読んだのが『いちばんやさしいアジャイル開発の教本』です。
タイトル通り、アジャイル開発を「初学者向け」にかなり丁寧に解説してくれていて、「なぜ今アジャイルなのか」「どうやって進めるのか」が少しずつイメージできるようになりました。
今回は、特に印象に残ったポイントを中心に感想を書いてみます。

「アジャイル＝短いサイクルで改善を繰り返す」という考え方が腑に落ちた

本書の中で何度も出てくるのが、アジャイル開発は「改善を続けること」が前提であるという考え方です。
ソフトウェアは一度リリースして終わりではなく、ユーザーの反応を見ながら改善を続けるもの。
だから、

• 短い期間で開発する
• リリースする
• フィードバックをもらう
• 改善する

というサイクルを回していく。
この説明を読んで、「完璧なものを最初から作る」のではなく、「まず動くものを出して学びながら良くしていく」のがアジャイルなんだ、と理解できました。

「顧客が本当に欲しかったもの」という話が印象的だった

Chapter 2 の「顧客が本当に欲しかったもの」の話が特に印象に残りました。

本では、

• 完成したソフトウェアの多くの機能は実際には使われていない
• ユーザー自身も「本当に必要なもの」を最初から明確に言語化できるとは限らない

と説明されています。

つまり、「要望通りに作ればOK」ではなく、実際に使ってもらいながら本当に必要な機能を見つけていくことが大切です。

これは学習中の自分にも通じる話だと感じました。
コードを書いていても、

• 「こういう実装でいいはず」
• 「この設計がベストだろう」

と思って進めても、あとから「もっとシンプルにできた」「別のやり方のほうが読みやすい」と気付くことがよくあります。

「動くソフトウェア」が大事という考え方

アジャイル宣言の中にある、「包括的なドキュメントよりも動くソフトウェアを」という価値観も、初学者の自分には新鮮でした。

もちろん、設計やドキュメントは大事ですが、「まず動くものを作って確かめる」ことを大切にしています。
本書では MVP（Minimum Viable Product：顧客に価値を提供できる最小限のプロダクト）の考え方も紹介されていて、

• 必要なものだけを作る
• 早くリリースする
• ユーザーの反応から学ぶ

という流れがわかりやすく説明されていました。

「チーム」が中心にある開発手法だとわかった

読み進めて特に感じたのは、アジャイル開発は単なる「開発手法」ではなく、チームでどう働くかの考え方でもあるということです。

本書では、

• 職能横断型チーム
• 自己組織化チーム
• 対話
• 振り返り（レトロスペクティブ）
• 心理的安全性
• HRT（謙虚・尊敬・信頼）

といった話が多く出てきます。

特に「対話」の章では、

• 議論：自分の主張を通す
• 対話：相手を理解しながら一緒に考える

という違いが説明されていて、チーム開発では後者が大事だと学びました。

私が現在学習しているオンラインスクールFBCでも、Discord で質問したり、レビューを受けたりしていますが、まさに「対話」が学習を進める鍵なんだなと感じます。

「見える化」の重要性は今すぐ実践できそう

Chapter 5 では、アジャイルを小さく始める方法として

• タスクの見える化
• タスクボード
• 朝会
• 振り返り（KPT）

などが紹介されていました。

中でも「見えていないタスクが遅れの原因になる」という話は納得感がありました。

学習でも、

• 「調べる」
• 「エラーを切り分ける」
• 「レビュー対応する」

といった作業は、最初は見積もりに入れ忘れがちです。
タスクを細かく書き出して見える化するだけでも、かなり進めやすくなりそうだと感じました。

初学者として感じたこと

この本を読む前は、アジャイル開発に対して

• 「なんとなく勢いで進める方法なのかな......？」

という誤解を少し持っていました。
でも実際には、

• 変化に素早く対応するための仕組み
• チームで学び続けるための考え方
• ユーザー価値を中心に置く開発スタイル

だということがわかりました。

また、アジャイルは「魔法の方法」ではなく、

• チームの対話
• 振り返り
• 見える化
• 継続的な改善

を地道に積み重ねることが大切なんだと感じました。

おわりに

『いちばんやさしいアジャイル開発の教本』は、

• アジャイル開発とは何かを知りたい
• チーム開発の考え方を学びたい

という初学者にとてもおすすめできる一冊です。

専門用語も出てきますが、背景から丁寧に説明されていたり、図解も多く使われています。
まさに「見える化」された構成で、イメージしやすい作りになっています。
「横文字が多くてさっぱりわからない......」という方でも読み進めやすいと思います。

自分自身、まだ実務経験はありませんが、この本を通して「アジャイル開発の世界」が少し具体的にイメージできるようになりました。
また、今回学んだアジャイルの考え方は、個人で学習している現在でも活かせるものだと感じました。

今後、Rails やチーム開発を学ぶ中で、今回学んだ

• 見える化
• 対話
• 振り返り
• 小さく改善する姿勢

を意識しながら学習を続けていきたいと思います！

book.impress.co.jp

技術記事を書くのが怖くなってしまった私が、『技術記事を書く技術』を読んで前向きになれた話

はじめに

私は現在、オンラインスクールフィヨルドブートキャンプ（以下、FBC）で学習しながら、Webエンジニアへの転職を目指しています。

FBC に入る前から、学んだことを整理するために Qiita へ技術記事を投稿していました。
学習した内容を整理できますし、自分と同じように困っている人の役に立てたら嬉しいと思っていたからです。

しかし、ある出来事をきっかけに、私は技術記事を書くことが怖くなってしまいました。
そんな私の考え方を変えてくれたのが『技術記事を書く技術』という一冊です。

今回は、私が技術記事を書くことに苦手意識を持つようになった経緯と、この本を読んでどのように気持ちが変化したのかを書いてみたいと思います。

Qiitaに記事を書くのが怖くなった出来事

以前、私は Linux に関する初学者向けの記事を Qiita へ投稿しました。
当時の私は「私と同じようにわからないことに悩んでいる人の役に立てたらいいな」という気持ちで記事を書いていました。
ところが、その記事に対して指摘をいただきました。

誤解のないように書いておくと、私はそのときのコメントをくださった方を責めたいわけではありません。
よりよい調べ方についてアドバイスしてくださったと思っています。
ただ、そのときの私には右も左もわからない状態でした。
技術記事の書き方もわからず、記事の粒度や範囲、一次情報の重要性についても十分に理解できていませんでした。
もちろん、コメントをくださった方々が当時の私の知識レベルや学習状況を知ることは難しかったと思います。

指摘を冷静に受け止めようと、コメントを何度も読み返しました。
（なお、コメントの内容そのものについては、本記事の主題ではないため割愛させていただきます。）
ただ、読み返すたびに次のような考えが頭の中を巡りました。

「『情報を鵜呑みにしない』ということは、どこで正しい情報を調べるのか？」
「『マズそう』という指摘は具体的にどうマズいのか？」
「『中途半端』『調べ直したほうがいい』って具体的にどういったところが中途半端なのだろう？調べ直すとはどのようにして調べ直せばいいのだろうか？」
「結局、どう考えればよかったのだろうか？どうすれば信頼できる情報にたどり着けたのだろうか？」
「私の記事は価値がなかったのではないか？」
「そもそも記事を書いてはいけなかったのではないか？」
「私はエンジニアに向いていないのではないか？」

と不安や悔しさ、つらさでいっぱいになり、いつしか記事への指摘そのものよりも「私には技術記事を発信する資格がないのではないか」と考えるようになってしまったのです。
それ以降、Qiita へ記事を投稿することをやめ、記事やブログを書くことに対して苦手意識を持つようになりました。

記事を削除しようか悩んだこともあった

記事を削除してしまおうかと何度も考えました。
記事を見るたびに、当時いただいた指摘や落ち込んだ気持ちを思い出してしまうからです。

しかし、その記事は当時の自分なりに調べ、理解し、一生懸命書いた記事でもありました。
プログラミング未経験で Webエンジニアを目指すと決めたからこそ、この記事とそこでいただいたフィードバックは、私自身を振り返るための大切な記録になるのではないかと考えました。

結果、私は記事を削除しないことにしました。
過去の自分の未熟さを隠すためではなく、そのときの自分が何を学び、何を考えていたのかを残しておきたいと思ったからです。
失敗も含めて、自分の学習の軌跡だからです。

『技術記事を書く技術』を読み終えた今は、その記事は自分の成長過程を支えてくれた大切な記録の一つだと受け止められるようになりました。

『技術記事を書く技術』との出会い

実は著者の伊藤淳一さんは、私が現在学習している FBC のメンターでもあります。
プラクティスのレビューでもお世話になっており、これまで何度も丁寧なフィードバックをいただいてきました。
そんなご縁もあり、『技術記事を書く技術』は「必ず読みたい」と思っていた一冊でした。

実際に読んでみると、この本は単なる「技術記事の書き方」の本ではありませんでした。
技術記事を書く目的や考え方、アウトプットとの向き合い方、そして反応との向き合い方まで丁寧に書かれていました。
読み進めるうちに、抱えていた不安や悩みに対する答えがたくさん見つかりました。

「誰か1人ぐらいは喜んでくれるはず」という考え方

本の中で特に印象に残ったのが、技術記事を書く目的についての考え方です。
著者は技術記事を書くことを「インターネットへの恩返し」と表現していました。
そして、

「この記事を書けば、きっと世界中で誰か1人ぐらいは喜んでくれるはず」

という考え方を紹介していました。

この言葉を読んだとき、肩の力がふっと抜けるような感覚がありました。
これまでの私は、

• 誰からも否定されない記事を書かなければならない
• 完璧な内容にしなければならない

という気持ちが強かったように思います。

しかし、本当に大切なのは完璧な記事を書くことではなく、自分が学んだことを次の誰かへ渡していくことなのかもしれません（正しい情報を伝えることは大前提として！）。
たった1人でも役に立てるなら、その記事には十分価値があるのだと思えるようになりました。

初心者だからこそ書ける記事がある

もう一つ印象的だったのが、第12章 アウトプットを習慣化する技術にある『初心者だからこそ書ける記事もある』という項目です。
私は現在、FBC で Ruby のカリキュラムを終え、データベースの学習に取り組み始めたところです。
まだまだ学ぶことばかりで、自分より詳しい人はたくさんいます。
そのため「もっと詳しい人がいるのだから、自分が記事を書く意味はないのではないか」と感じることもありました。

本では「数か月前の自分に向けて記事を書く」という考え方が紹介されていました。
確かに、学習したばかりの人だからこそ

• どこでつまずいたのか
• 何がわかりにくかったのか
• どんな説明で理解できたのか

などを鮮明に覚えています。

経験豊富なエンジニアだからこそ書ける記事があります。
一方で、学び始めたばかりの人だからこそ書ける記事もあります。

私はこれまで、「初心者だから書けない」「初心者だから書いてはいけない」「誰でもわかるようなレベルの内容をブログに書いてはいけない」と思っていました。
しかし、本を読んでからは「初心者だからこそ届けられる情報もある」と考えられるようになりました。

第11章「反応と向き合う技術」に救われた

私が最も心を動かされたのは、第11章の「反応と向き合う技術」でした。
特に印象に残ったのは次のような内容です。

• ネガティブコメントを気にしすぎない
• マサカリが飛んできたら納得できる部分だけ受け取ればよい
• 返信に困るコメントは無理に相手をしなくてもよい
• ネガティブコメントが付くのは、多くの人に読まれている証拠でもある

コメントは記事への反応であって、人間としての価値を評価されているわけではありません。
改善すべき点があれば学びとして受け取ればよいですし、納得できないものまで抱え込む必要はありません。
この考え方に触れたことで、長い間抱えていた重荷が少し軽くなった気がしました。

過去の出来事を少しずつ手放したい

FBC で学習を始めてからは、FBC の日報やはてなブログを中心に学習記録や振り返りを書くようになりました。
それでも記事を書こうとすると、あのときの出来事を思い出してしまうことがあります。
「また同じようなことを言われたらどうしよう」そんな不安が頭をよぎることもありました。
ですが、この本を読み終えたときに感じたのは、「過去の出来事に縛られ続ける必要はない」ということでした。

技術的な指摘から学ぶ姿勢は大切です。
一方で、反応を恐れるあまりアウトプットをやめてしまえば、自分の成長の機会まで失ってしまいます。
だからこそ、過去の出来事を引きずり続けるのではなく「次はもっと良い記事を書こう」という方向に気持ちを向けたいと思いました。

そして、そのためにもこれからは完璧さよりも継続を大切にしながら、自分なりのアウトプットを続けていきたいと思います。

これからの私のアウトプット

本を読んで改めて思ったのは、技術記事を書くことは誰かのためだけではなく、「自分自身の成長のためでもある」ということです。

記事を書くためには調べ、理解し、自分の言葉で説明する必要があります。
このプロセスそのものが学習になります。

私は FBC で学習を続ける中で、まだまだわからないことだらけです。
それでも「数か月前の自分だったら知りたかったこと」「同じところで悩んでいる初学者の役に立ちそうなこと」を少しずつ言葉にしていきたいと思います。

完璧な記事を書くことを目指すのではなく、調べ、理解したことをアウトプットしていきたいです。

まとめ

当時、Qiita でいただいたフィードバックをきっかけに、私は技術記事を書くことが怖くなりました。
しかし、『技術記事を書く技術』を読んだことで、アウトプットに対する考え方が大きく変わりました。

特に

• 誰か1人の役に立てば十分
• 初心者だからこそ書ける記事がある
• ネガティブな反応を過度に恐れなくてよい

という考え方は、これからも大切にしていきたいと思います。
また、削除しようか悩んだ過去の記事も、今では自分の成長の記録として残しておきたいと思えるようになりました。

私にとってこの本は、技術記事に対する苦手意識と向き合い、もう一度アウトプットを続けてみようと思わせてくれる一冊でした。
私自身も肩の力を抜きながら、細く長くアウトプットを続けていこうと思います。

そしていつか、過去の自分が誰かの記事に助けられたように、今度は自分の記事が誰か1人の助けになれば嬉しいです。

www.shoeisha.co.jp

前へ進むための準備：グループコーチング参加と MacBook Air 購入

はじめに

これはフィヨルドブートキャンプ Advent Calendar 2025 の11日目の記事です。
昨日 12月10日は、 田中ボーンさんの『自己紹介を兼ねた2025年振り返り』でした。

tanakabone.hatenablog.com

さまざまなことに挑戦し続ける姿勢がとても素敵で、私自身のモットーである「何事にも挑戦」とも通じるものがあり、強く共感しました。
田中ボーンさんの挑戦と今後のご活躍を心より応援しております。

Advent Calendar のリンクはこちらです。

fjord-calendar.jp

目次

挨拶 & 自己紹介

初めまして、Yoshiwo（よしを）と申します。
現在フィヨルドブートキャンプ（以下 FBC）で学習を進め、エンジニアとしての就職を目指しています。

bootcamp.fjord.jp

今年は学習ペースが乱れがちで、「もう一度しっかり土台を固めたい」と考え、グループコーチングへの参加と、MacBook Air の購入による学習環境を整えることを決めました。
小さな一歩かもしれませんが、前に進むための大切な準備です。

どちらを書こうか迷いましたが、迷うくらいなら両方書いてしまえ、ということで、まとめてお届けします。
拙い部分があるかもしれませんが、最後までお付き合いいただければ嬉しいです。

グループコーチングの参加

🤔 グループコーチングとは？

参加者が立てた目標や進捗を発表し、質疑応答やフィードバックから理解を深める場です。
発表内容は事前に Discord の分報に投稿して共有します。

以下は実際に発表した内容です。

📜 グループコーチング発表内容

2025/11/18 Yoshiwo

【🎯大目標（1年後 2026/04/01まで）】
・できるだけ多くのプラクティスを修了し、しっかり実力を身に付ける！

【⏳中目標（3ヶ月後 2026/01/01まで）】
・Ruby のプラクティス修了
・RubySilver の学習 & ChatGPT の問題演習

【📌前回の目標】
・Ruby の基礎をさらに押さえ、少しずつコードの読み書きができるようになる

【✅達成度】
自己評価：4/5（5段階評価：低 1・2・3・4・5 高）
・書籍『たのしいRuby 第6版』
  ➡️新しい知識を学びながら、理解が曖昧な箇所を把握しています。
・ChatGPT に Ruby の問題を作成してもらい解く
  ➡️自分の書いたコード 1行ずつ説明する練習を継続中。
  ➡️「考えて書く」習慣を積み重ねながら、理解を深めています。
・プラクティス『lsコマンドを作る1』課題提出
  ➡️書籍『たのしいRuby』で学んだ内容とこれまでに読んできたテキストを参考に、躓いていたメソッド化にしっかり取り組めました。
  ➡️ChatGPT の演習のおかげで「メソッド化できそうな処理のまとまり」や「メソッドに渡す引数」が意識できるようになってきました。

【⏭️次の目標（2週間後 2025/12/02まで）】
・Ruby の基礎をさらに押さえる / コードの読み書きを継続して練習
  ➡️ChatGPT の問題演習を継続。
  ➡️RubySilver の模擬試験で答えられなかった箇所を中心に復習。
・プラクティス『HTTP の基本について理解する』に取り組む
  ➡️先ずはプラクティスの内容の理解からスタート。
・アドベントカレンダーに投稿するブログの作成
  ➡️昨年同様、早めに草稿を仕上げ、当日までブラッシュアップを続ける。

【😀学習を楽しめているか】
自己評価：4/5（5段階評価：低 1・2・3・4・5 高）
・課題を提出できたのは素直に嬉しい。
・小さな一歩でも、継続して積み上げていきたい！
・理解するまでは大変なところもあるが、分かるとやっぱり楽しい！

【🏋🏻自己管理できているか】
自己評価：4/5（5段階評価：低 1・2・3・4・5 高）
・食事・睡眠・運動を意識して過ごせています。

【🔎今回の工夫】
・書籍で Ruby の知識を深め、ChatGPT で演習をすることで、「読む・書く」の両面を強化
  ➡️このスタイルを継続していきたい。

【❤️‍🔥次に挑戦したいこと】
・『たのしいRuby 第6版」
・ChatGPT の問題演習
・RubySilver
この3つをバランス良く取り組む！（前回と同じ）
  ➡️継続して Ruby と仲良くなりたい！

【🤔現在の悩み】
・まだ Ruby のコードの読み書きがスムーズにできないこと（前回と同じ）
  ➡️書籍・演習・RubySilver の学習で得た知識を結びつけて理解を深めたい。
  ➡️コードの読み書きは一朝一夕では身に付かないので、焦らず効率よく続けていきます。

🧐 参加してみてどうだったか

そもそも参加を決めた理由は、学習に充てる時間を確保したかったからです。

昨年から東京と大阪を往復する生活が続き、今年は特に慌ただしい日々でした。
ようやく落ち着ける時間ができても、疲れが取れず、ただぼーっと過ごすばかり。
学習も思うように進まず、焦りだけが募り、「このままではいけない」という危機感が日ごとに強くなっていました。

一日も早く FBC を卒業してエンジニアに転職するためにも、先ずは環境を整えよう。
その第一歩としてグループコーチングに参加しました。

初参加の日はとても緊張しましたが、それ以上に多くの学びと気付きを得られました。

🕺 グループコーチングで感じたメリット

1. 人前で話す練習になる

自分の考えを言語化して伝えることで、発声や話す間合いにも自然と意識が向くようになりました。

2. コミュニケーション力が向上する

参加者の質問や意見を通して多様な視点に触れ、これまで気付けていなかった課題を発見できました。

3. 多角的なフィードバックが得られる

悩みに対して具体的なアドバイスやアプローチ方法をいただけるため、毎回「なるほど！」と腑に落ちる瞬間があります。

4. 毎回大きな学びがある

学習の進め方、教材、技術知識など、得られるものが非常に多いです。
体感では、はぐれメタル 3体を倒したくらいの経験値です。

5. モチベーションが上がる

参加者の皆さんの前向きな話を聞くことで、「自分ももっと頑張ろう」と自然と思えるようになります。

6. 自分を見つめ直せる

学習の進め方だけでなく、私生活の過ごし方、一日の限られた時間をどう配分するかもより意識するようになりました。

🥳 グループコーチングの効果

参加前に比べて、落ち込んでいた QOL が徐々に回復していきました。

• 筋トレ・ストレッチの再開
• 睡眠時間を確保
• 心身を休める時間を意図的に作る
• 学習時間の増加

また、2週間、3ヶ月、1年とマイルストーンを設定したことで、進む方向が明確になり、不安が軽くなりました。

❤️‍🔥 結論：グループコーチングはいいぞ！

2週間に 1回の開催ですが、内容は濃く、毎回大きな学びがあります。
温かい雰囲気の中で、プライベートの話や趣味の話など、さまざまな話題が飛び交うのも魅力の一つです。
このグループコーチングという場で得られる気付きや学びは、参加するたびに新しい発見があり、自分の成長にも繋がっています。

何より、関わってくださる参加者の皆さんには心から感謝しています🥹🙏🏻

おまけ：MacBook Air を購入しました

数年前にエンジニアを目指して購入した MacBook Pro が限界を迎えました。
バッテリーの劣化、レインボーサークルの連発......これでは学習も一苦労です。

毎日触れてきたマシンなので愛着が湧き、名残惜しかったですが、「今まで、どうもありがとね」と感謝を伝えて新しい MacBook Air を迎えました。

 旧 MacBook Pro（13インチ 2020）

• Intel Core i5
• 512GB SSD（使用：90.46GB）
• 16GB メモリ

 新しく購入した MacBook Air（15インチ M4 2025）

• Apple M4チップ
• 512GB SSD
• 24GB メモリ

🗣️ 購入に至ったアドバイス

いただいた数々のアドバイスの中で個人的に参考にさせていただいた内容を紹介します。

• シリコンチップになり、メモリの質が向上されたため、メモリはそんなに高くなくても大丈夫。
• メモリは 16GB でも大丈夫......ただし、一度購入するとスペックを上げることはできないので心配ならば、もうひとつ上のスペックを選ぶのも良い。
• ストレージは、写真や動画編集などの作業をしなければ、512GB で大丈夫。
• MacBook Pro は大きいサイズ、MacBook Air は小さいサイズを選ぶ傾向にある。もし、外で作業する頻度が高ければ 13インチが良い。家での作業がメインならば 15インチでも良い。あとは、本人の好み。
• RubyMine 使用はおよそ 12GB。16GB でも大丈夫だが、気持ちとしてやや心許ない。
• RubyMine の使用、FBCプラクティスにおいてのチーム開発やサービス開発では 32GB までする必要はない。
• ストレージは 256GB でも余るので大丈夫。でも、もしものことを考えると 512GB あると安心、十分。
• 動画や写真などを行うなら 1TB。

🎯 MacBook Air を使ってみて

新しい MacBook Air（M4） を使い始めて、まず最初に驚いたのは動作の軽さと静かさでした。
アプリの起動や画面切り替えがとてもスムーズで、ストレスを全く感じません。
レインボーサークルとにらめっこしていた日々が嘘のようです。

特に感動したポイントはこちら

① 処理速度が圧倒的に速い

ターミナルやエディタ、ブラウザを複数立ち上げても重くならず、快適に作業できます。

② ファンレスなのに熱くならない

長時間作業していても熱が気にならず、集中が途切れません。

③ 画面が大きくて見やすい（15インチ最高🫶🏻）

タブを何枚も切り替えなくてもよくなり、作業効率がかなり上がりました。

④ バッテリー持ちがとにかく良い

充電を気にせず長時間学習できるので、気持ちにも余裕が生まれます。

これまで、学習したい意欲はあっても、動作の重さや不具合に気持ちを削がれてしまうことが少なくありませんでした。
しかし、MacBook Air に替えてからは、学習を始めるハードルが大きく下がり、毎日のモチベーションがグッと上がりました。

テックの世界では、環境を整えることも立派な投資だと言われますが、今回の買い替えは本当にその通りだと感じています。
心強い相棒を得た気分です。
これからも大切に使っていきたいと思います。

購入にあたり、アドバイスをくださいましたメンターさん、卒業生・受講生の皆さん、本当にありがとうございました！

まとめ・おわりに

グループコーチングに参加したことで、私は単に学習時間を確保できたというだけでなく、自分自身と向き合い、少しずつ前へ進むための力を取り戻すことができました。

さらに、新しい MacBook Air を迎えたことで、学習環境が整い、「学びたい」という気持ちを行動に繋げやすくなりました。

• 自分の状態を知ること
• 仲間との対話から気付きを得ること
• 使う道具を整えること

これらが学習の継続において本当に重要であると実感しています。

支えてくださるメンター、卒業生、受講生のみなさん。
そして FBC で学ぶ仲間の皆さん。
いつもありがとうございます。

これからも焦らず、コツコツと積み重ねていきます。
またどこかで進捗を共有できたら嬉しいです。

最後まで読んでいただき、ありがとうございました😊✨

---

明日 12月12日の Advent Calendar は、
笑顔が素敵で誰にでも優しく接してくださる r.zamamiさんです🙌🏻✨

引き続きフィヨルドブートキャンプ Advent Calendar 2025 をお楽しみください。
皆さんにとって素敵なクリスマス、そして素晴らしい新年となりますように。

『伝わるコードレビュー』を読んでみて

はじめに

先日、『伝わるコードレビュー』を拝読しました。コードレビューでありがちなコミュニケーションの課題を、豊富な事例を交えながら丁寧に解説している一冊です。本の構成は「心構え」「実践」「TIPS」の3つから成り立っています。

書籍『伝わるコードレビュー』

印象に残ったポイント

1. 可愛いキャラクターたちと読みやすい文章

読書が苦手な方でも可愛らしいキャラクターがあちらこちらに登場しているため飽きにくく、さくさく読み進めることができます。吹き出しや図解があるので内容を咀嚼しやすくなっています。

2. レビュアー / レビュイー両方の視点

新人エンジニアとしてレビューを受ける立場も、レビュアーとしてコメントを書く立場もイメージしやすい構成です。私はまだ Web系企業に就職したこともなければ、実務経験もないのですが、もし新人エンジニアとして現場に立てるようになった時、「現場でどう振る舞えばよいのか」レビューやディスクリプションについてどのようにして取り組んでいけばよいのかがイメージできるようになります。

これらを通じて、「なぜチームで働くうえで人間関係が重要なのか」を学ぶことができます。

3. テキストコミュニケーションの TIPS集

コードレビューに活用できる TIPS を紹介しています。Goodパターンと Badパターンを用いてレビューやディスクリプションをよりよく書けるための方法を一つ一つ解説してくれています。

私が得た学び

たくさんありすぎて枚挙に遑がないのですが、特に心に残ったのが、p.111に載っている次の2つの文です。

• （わからないことについて相手に聞こうとおもうが）「『相手の時間を無駄にしてしまうのではないか』という遠慮」
• 「自分で考えることは大切ですが、考えてもわからないときは、相手を信頼して率直に尋ねることも大切です」

これまで、悩みや問題を抱えても「人様に迷惑をかけてはいけない」「相手の時間を奪うようなことはしてはいけない」といった気持ちから人に頼らず自分一人で解決してきました。が、困った時に頼れる存在がいるのなら「素直に甘えよう」「助けを求める勇気も大切」と自分に言い聞かせました。もちろん、何も考えずにいきなり「答えを教えてください」と依存するのではなく、まず自分で考えた上で質問する姿勢がポイントですね。

こんな人にこの書籍をおすすめしたい

• 私のようなエンジニアを目指している方
• テキストコミュニケーションでのやり取りに自信がない方
• すでに幾度もレビュー経験はあるけど、「言葉選びを見直したい」と思っている方

おわりに

本書で学んだ「伝え方の本質」は、コードレビューについていろんな角度から語られていて大変参考になりますし、実践的なものも学べます。ですが、教えてくれたコミュニケーションは開発現場に限らず、人と人が交わる環境であれば全てにおいて参考になると思います。家族や友人との会話、職場の同僚や上司とのやり取り、初めて逢った人との些細なやり取り……読み終えた後は人とのコミュニケーションについての意識が読む前に比べてよりよい方向に変わっているはずです。

私はエンジニアになるために FBC でプログラミングについて学んでいますが、自分のテキストコミュニケーションを改めて振り返るきっかけになりました。日報の提出、課題を提出した後のメンターさんとのやり取り、そしてこの先経験するであろうチーム開発に活かしていきたいと思います。

是非皆さんも手に取ってご覧ください😊📚 www.shoeisha.co.jp

『Team Geek - Google のギークたちはいかにしてチームを作るのか 』を読んでみて

はじめに

『Team Geek』は、Google の元エンジニアであるブライアン・W・フィッツパトリック氏とベン・コリンズ＝サスマン氏が執筆した、優れたチームづくりに必要な考え方と実践方法をまとめた一冊です。

技術力だけでなく、チームメンバー同士の人間関係をいかに築くかにフォーカスしており、特に「HRT（謙虚さ Humility・尊敬 Respect・信頼 Trust）」の重要性を説いています。エンジニアリングの現場で得たリアルな知見に基づく内容は、非常に実践的かつ説得力があります。

書籍『Team Geek』

本書の概要

著者

• ブライアン・W・フィッツパトリック：Subversion や Google Code の開発に携わったエンジニア
• ベン・コリンズ＝サスマン：Google Campus Team リーダーとして多数のプロジェクトを推進

テーマ

1. 技術スキルと同等以上に大切な「人間関係」
2. HRT を軸としたチーム文化の構築方法
3. 実際の開発現場で得た具体例

これらを通じて、「なぜチームで働くうえで人間関係が重要なのか」を学ぶことができます。

印象に残ったポイント

1. HRT の解説

• 謙虚さ（Humility）
• 尊敬（Respect）
• 信頼（Trust）

これらが相互に作用することで、チームに「心理的安全性」をもたらします。

2. 失敗から学ぶケーススタディ

著者が実際に経験したチーム運営の成功例・失敗例を紹介しています。実体験を交えた解説は多くの知識と気付きを与えてくれます。

私が得た学び

「学びに早すぎることはない」

実はこの本、以前から気になっていたものの「自分にはまだ早い」と後回しにしていました。しかし、FBC（フィヨルドブートキャンプ）のメンター・駒形さんから勧められて手に取り、読んで本当によかったと実感。学びに「早すぎる」ことはありません。駒形さん、ありがとうございました😊🙏🏻

こんな人にこの書籍をおすすめしたい

この本は、単にエンジニア向けというだけではなく、「人と協力しながら働くすべての人」に通じる普遍的な教訓が詰まっています。エンジニア、デザイナー、PM などの技術チームで働く人はもちろん、私のような完全未経験の学習者にも、強くおすすめしたい内容です。

おわりに

『Team Geek』は、Google という大規模組織で実際に機能したチームづくりのノウハウを、エンジニア視点でわかりやすくまとめた一冊です。

私のような初学者でも、本書の内容を心に留めて FBC のプラクティスに取り組み、メンターさんや卒業生・受講生の皆さんとのやり取りに HRT を取り入れることで、自然と思いやりのあるコミュニケーションが身に付くはずです。

また個人的には、会社経営やサービス開発における心構えを学べただけでなく、IRC、レイテンシー、ユーザーエンゲージメントといった専門用語に触れられ、「知識を持つことの大切さ」を再認識する良いきっかけになりました。

ちなみに
半年前に Notion に草稿を書いたまま、はてブに投稿するのをすっかり忘れてしまったのはここだけの話です......🤫

是非手に取って、HRT の精神に触れてみてください🫶🏻📚 www.oreilly.co.jp

技術書典18：初めての一般参加 & 初売り子レポ📚✨

はじめに

こんにちは、Yoshiwo です。 FBC（フィヨルドブートキャンプ）というオンラインスクールの受講生としてプログラミングを学んでいます。

6月1日に開催された「技術書典18」に、初めて一般参加 & 売り子として参加してきました。緊張とワクワクが入り混じった中で、たくさんの出逢いや発見がありました。

目次

技術書典とは？

公式によりますと（以下、公式から「技術書典とはなんですか？ 」「技術書とは何ですか？」を引用）

技術書典（ぎじゅつしょてん）は新しい技術に出会えるお祭りです。

技術書典は「いろんな技術の普及を手伝いたい」という想いではじまりました。技術書を中心として出展者はノウハウを詰め込み、来場者はこの場にしかないおもしろい技術書をさがし求める、そんな技術に関わる人のための場として我々は技術書典を開催しています。

また、

技術書典における「技術書」とは、「ITや機械工作とその周辺領域について書いた本」を指します。ソフトウェア、ハードウェア、開発環境、コンピュータサイエンスから、その他科学・工学全般などのジャンルを対象としています。

情報通信やコンピュータサイエンスに限らず、数学、化学、法学など各種専門分野、通信、アルゴリズムなど各種工学分野も技術書の範疇と考えています。最近はVTuberの方々や自然科学など、さらに様々なジャンルの本が集まってきています。

本当にそうなんですよね。多岐にわたるテーマが一箇所に集まるのは、技術書典の大きな魅力です。技術書典に参加すると、作者と直接お話ができたり、他の来場者との交流を深められるため、オンラインでは得られない体験が得られるのもいいですよね。

ちなみに Wikipedia には技術書典は「技術者たちの『コミケ』とも言われる」と記載されていました（うんうん、わかります😌）。

techbookfest.org

---

参加のきっかけ

TokyoWomen.rb のイベントで 、FBC（フィヨルドブートキャンプ）の受講生の @kota_syan さんから「FBC のファンブック書いてみませんか？」とお誘いをいただきました。とても嬉しかったものの、当時はプライベートが立て込んでいて、「寄稿しても中途半端になり、逆に迷惑をかけてしまうかもしれない」と考え協力することができませんでした。

しかしオフライン開催の数日前に、「売り子スタッフを募集している」という知らせを耳にし、「売り子としてなら接客経験を活かせるのでは？」と思い、応募を決意。これが今回、技術書典に参加する大きなきっかけとなりました。

当日の様子

人と人との"繋がり"を間近で感じる

ブースには多くの方が足を運んでくださいました。

• 初めて「FBC」の名前を聞いた方
• 以前から FBC を知っていたけれど、どんなスクールか詳しくは知らなかった方
• FBC にゆかりのある方
• @kota_syan さんのご家族
• Rubyコミュニティで私が一方的に知っているすごい方
• 技術書典の会場で初めてお逢いし、ご挨拶した方

短時間でこれほど多様な方と直接コミュニケーションできる場は貴重です。「人と人の繋がりって本当に面白いなぁ」と改めて感じました。

反省点：売り子編・一般参加編

売り子編

• 質問にうまく答えられなかった
  前日に献本していただいた本を2回読み返したのですが、「興味を持って手に取ってもらったのに、要点をスムーズに伝えられなかった」と反省しています。

改善策

• 説明の要点を3〜4パターン用意しておく
• FBC のホームページやアプリをすぐに見せられるようにスマートフォンにあらかじめ立ち上げておく

一般参加編

• 閉幕後に気になる本が突如たくさん出現する
  事前に参加サークルと刊行される作品を一つずつ確認していたつもりでしたが、「えっ、なにそれ！めっちゃ気になる！」といった本がわっさわっさと出てきて、実際に手に取れなかったことや作者さんとお話できなかったことが心残りに......これは技術書典あるあるなのでしょうか🤔

参考にさせていただいたブログ

初めて「一般参加」「売り子」として参加するために必要なこと、ブースのレイアウトについてなど、以下のブログを参考にさせていただきました。準備段階から当日のイメージを掴むことができました。先輩方の道標はとってもありがたいです、本当にありがとうございます😊🙏🏻

note.com

note.com

note.com

参加してよかった！

結論から言うと、「参加して本当に良かった！」の一言に尽きます。

あの時の @kota_syan さんのお誘いがなかったら、技術書典を楽しむ自分はいませんでした。もちろん、会場でお逢いした方々との出逢いもありませんでした。ブースでご一緒させていただいた @anzu_mmm さんや @hirokiej さんと、実際に顔を合わせて楽しくお話をしたり、悩みを共有することもできませんでした。

「オンラインだけでは得られない、会場のリアルな熱量と良い雰囲気」を肌で感じられた経験は、FBC のプラクティスに取り組むモチベーションが一段と高まりました。

@kota_syan さん、@anzu_mmm さん、@hirokiej さん、フィヨブーファンブック Vol.1の作成に携わった皆さん、フィヨブースに立ち寄ってくださった皆さん、そして技術書典18の開催に関わってくださったすべての方々へ心から感謝を申し上げます。本当にありがとうございました！

ちなみにオンラインは6月15日まで開催中ですので、ご興味がある方はぜひそちらもチェックしてみてください。そして、『フィヨブーファンブック Vol.1』をどうぞご贔屓に😊📚

techbookfest.org

t.co

📸 最後に

思い出を幾つか残したいと思います。

ポスター！テンション上がりました🕺

FBC とみきゃん（愛媛県のPRキャラクター）の奇跡のコラボレーション！

皆さんと一緒にパシャリ☺️📸

ご覧くださり、ありがとうございました😊🙏🏻