siroemk’s blog

フィヨルドブートキャンプで学んでいます(2020/11〜)

応用情報技術者試験に合格した時の勉強法

この記事はフィヨルドブートキャンプ Part 1 Advent Calendar 2023 - Adventarの24日目の記事です。

昨日は@maimux2xさんのzshのプロンプトカスタマイズを理解したい - 出る杭は打たれないでした。

私は先日受けた応用情報技術者試験の勉強方法などを紹介したいと思います。

応用情報技術者を受けようと思っているフィヨルドブートキャンプ生もいると思うので参考になれば嬉しいです。

目次

なぜ受けたのか

先日、フィヨルドブートキャンプを卒業したsiroです。 令和5年度秋期の応用情報技術者試験を受験して、無事合格できました。

私は文系大学出身で、理系とは全くの無縁だった人間です。

フィヨルドブートキャンプでプログラミングを学習する中で、もう少し幅広く基礎的な知識を付けたいと思い、応用情報技術者試験を受けることにしました。

応用情報技術者試験について

応用情報技術者試験は毎年4月と10月に実施される国家試験です。 午前と午後の問題が用意されており、どちらも合格ラインに到達できれば合格になります。

午前問題 午後問題
試験時間 9:30~12:00(150分) 13:00~15:30(150分)
試験方式 多肢選択式(四肢択一) 記述式
問題数 80問 10問中から4問選択 + 必須科目の情報セキュリティ1問の計5問
合格ライン 60%(48問正答で合格) 60%
  • 午前問題は四肢択一で、過去問から40問近く出題される
  • 午後問題は『情報セキュリティ』が必須科目
  • 午後問題は10問中4問選択する

という特徴があります。

試験勉強はとりあえずこれをやる

私は3回目でようやく合格できたのですが、3回受けてみて一番効率が良い勉強法はこれかなと思います。

【午前問題】

  • 試験の出題傾向を掴む
  • 参考書の前に過去問2回分で全体把握
  • 過去問道場を活用、わからない問題を中心に解く
  • 単語リストを作る

【午後問題】

  • 自分が得意な分野を見つける
  • 1問15分で解く練習をする

一つ一つ説明してきます。

午前問題の勉強法

応用情報技術者試験の午前問題は四肢択一の80問の問題が出されます。

80問と聞くと、「大変そう...」と思うかもしれないですが、その中の約40問は応用情報技術者試験基本情報技術者試験などの過去問から出題されます。

合格ラインが80問中48問(6割)正答なので、過去問を完璧にこなせれば午前問題は合格に近づくと思います。

...ただ、がむしゃらに過去問を何周もやっても効率的ではないです。

私は仕事や子育ての合間に勉強していたので、できるだけ効率的に進めたい!

ということで、以下の手順で進めていきました。

1. 試験の出題傾向を掴む(試験3ヶ月前)

まずは試験の出題傾向を掴むために、受験した方の体験記や過去の統計を読んで、応用情報技術者の出題傾向を分析しました。

以下のサイトの過去問統計がとても参考になりました。

午前問題は直近2回の過去問題からは出題されていないようです。

www.ap-siken.com

2. 過去問2回分で全体把握(試験3ヶ月前)

次に問題の全体像を掴むために過去問を2回分やりました。

2回分やってみて、わからない単語を参考書で調べます。

ここでは完璧に理解するのではなく、「そういう単語なんだ」「そんな考え方があるんだな」と出題範囲を把握するくらいの理解でOKです。

3. 過去問道場の活用法(試験2ヶ月前〜受験直前)

過去問2回で全体像が分かったら、本格的に過去問を解いていきます。

応用情報技術者試験を受ける人なら必ず利用しているであろう、過去問道場という過去問を集めた便利なサービスがあるので、こちらを利用しました。空き時間にスマホで問題を解くことができてとても助かりました。

www.ap-siken.com

過去問道場でアカウント登録すると、問題を色分けする機能が利用できます。

問題に対して、赤・黄・緑の色をつけることができるので、

  • 絶対に解けるであろう問題 → 緑のチェックをつける

  • 自信がない問題 → 赤のチェックをつける

というように過去問を仕分けながら解きます。

チェックをつけたら、

【赤がついている問題を再度解く→ わからなかったら参考書を読む → 理解できたら緑のチェックに変える】というのを受験直前までやっていきます。

理解できていない問題だけを効率的に勉強できますし、赤のチェックを減らすのがゲーム感覚になり、楽しかったです。

忙しい人でも空き時間に数問ずつトライできるのが良いですね。

古い問題よりも最近の問題が出題されやすいので、まず直近3年分、その後5年分、余裕があれば10年分解いてみてください。

10年分を解ければ午前問題は(絶対)合格できると思います。私は試験勉強の7割をこの過去問に費やしました。

4. 単語リストを作る

余裕があれば問題を解きながら単語リストを作ることもオススメです。

問題で出てきてわからなかった単語を一覧にします。単語を書くだけです。

私はノートにまとめてましたが、PCのメモでも良いと思います。

そして、試験前日にその一覧を見返して、単語の意味を思い浮かべます。

「この単語、全くわからないなー」と思ったら、参考書で確認します。

出題範囲がかなり広いので、序盤に勉強したことは大抵忘れています。最後にメモを見直して忘れているところを思い出せるようにしていました。

午後問題の勉強法

応用情報の午後問題は記述問題になります。

11の分野から5問を解く試験方法となっています。

情報セキュリティという分野が必須で、残りの4問は自分で選択して受験します。

問題に対して試験時間がかなり短いので、事前に選択分野を絞っておくと良いです。

選択問題の目星をつける

私は解けそうな分野を6つくらいに絞って勉強しました。

文系出身の人は文脈を読むのが得意だと思うので、経営戦略やプロジェクトマネジメントなどが解きやすいかもしれません。理系の人はプログラミングあたりが安定的に点数取れそうです。

フィヨルドブートキャンプ生の場合、データベースのプラクティスが終わっていればデータベースも良いと思います。データベースの問題はある程度パターンが決まっているので、満点は取れなくても6~7割くらいは安定して取れそうです。(ER図の穴埋めなどが出題されます)

逆に経営戦略などのストラテジ系は簡単な問題と難しい問題の差が激しいので、これに絞るとリスキーだなと思います。

今までの経験や知識で解きやすい分野は変わってくると思うので、自分の得意な分野を見つけてみてください。

私はこの6つに絞って学習していました。

15分で解く練習を

そして、午後問題は時間勝負になります。

5問を2時間半で解くので1問30分の計算です。問題を選んだり見返したりする時間も含めると、もっと短いですね。

なので、練習段階から1問15分タイマーをかけて解くようにしていました。

実際に解いてみるとわかるのですが、15分で解くのは至難の業です。 まずは15分で問題の8割を解く気持ちでやってみると良さそうです。

時間を区切ることで問題を解くスピードが上がることはもちろん、時間の感覚がつくので、問題を解きながら「ここまでは10分でいけそうだな」など予測を立てることができるようなりました。

時間の予測ができると心の余裕につながるので、落ち着いて解くことができるようになります。

また、忙しくても「仕事前の15分だけやるか〜」と学習スタートのハードルが下がるので、継続的な学習にもつながりました。

15分タイマーをぜひ試してみてください!

(おまけ)当日にやっておくと良いこと

時計は忘れずに

私が試験を受けた会場には時計がありませんでした。

午後問題は時間との戦いなので、必ず腕時計を忘れないようにしましょう。

私は午後試験の途中で腕時計が止まってすごく焦ったので、腕時計の点検も忘れずに!

午後問題は冊子を折り曲げる

午後問題は11の問題が問題冊子に掲載されているので、迷子になりやすいです。試験を受けるときに自分が解く問題の最初のページを折り曲げて進めていきました。

見直しの時に戻りやすくて便利です。

小さいことですが、時間勝負な試験なのでやって損はないはず!

お昼ご飯は用意していこう

私が受験した会場は某大学でした。

「午前の試験が終わったら、近くのコンビニでお昼ご飯を買おう」と考えていたのですが、大学の構内が広く試験会場からコンビニまでが15分ほどかかってしまいました。

私はギリギリまで午後の問題を見直す予定で準備していたので、この15分がかなり痛手でした。

お昼ご飯や飲み物、おやつなどは事前に用意しておくと安心です。(あと、会場の下調べ大事ですね!!!)

さいごに

応用情報技術者試験を受けた時の勉強法などを書いてきました。 これから受験する方の参考になれば嬉しいです。

次は高度分野の試験やRubyの資格である、Ruby Silver、Goldをあたりを狙っていきたいです。

こどもの面白い名言を記録できるサービス「Cotomemory」をリリースしました

目次

はじめに

こどもの面白い名言を記録できるサービス「Cotomemory(コトメモリー)」をリリースしました。

cotomemory.com

github.com

今回の記事ではサービスの説明や苦労したことなどについて書きたいと思います。

自己紹介

フィヨルドブートキャンプでプログラミングの学習しているsiroです。 普段は自社サービスのカスタマーサポートなどのお仕事をしています。

プライベートでは3姉妹の母として日々子育てに奮闘中です。 今回、子育てに関するWEBアプリを作成しました。

Cotomemoryについて

今回リリースしたCotomemory(コトメモリー)はこどもの面白い名言を記録できるサービスです。

子育てをしていると、こどもの可愛い発言に癒されたり、ふとした言葉で成長を感じることはありませんか?

子育て中の方なら、きっと可愛い名言に出くわしたことがあると思います。

Cotomemoryはそんな可愛い名言を忘れてしまわぬように 名言と発言した時のこどもの年齢を記録できるサービスです。

Cotomemoryの使い方

Cotomemoryの使い方を簡単に紹介します。

【名言の登録について】

https://cotomemory.com

まずはGoogleでログインします。ログインしたらこどもの情報を登録する画面が表示されるので、こどもの名前と誕生日を入力してください。

こどもの情報を登録すると名言一覧が表示され、名言を登録できるようになります。

【招待機能について】

家族を招待する機能も用意しており、家族を招待すると同じ名言見ることができるようになります。

招待する人は「家族を招待する」のページから招待URLを取得し、家族に伝えてください。招待された人は招待URLからログインすると家族と紐づきます。

名言にはコメントを残すことができるので、家族を招待するときっと盛り上がるはずです!是非一度使ってみてください!

Cotomemoryをつくったきっかけ

このサービスのきっかけになったのは、同じフィヨルドブートキャンプ受講生のかわかみさんです。かわかみさんも子育て中のママさんです。

以前、かわかみさんから「こどもの名言を忘れないようにスプレッドシートにメモしている」という話を聞いたことがありました。

かわかみさんは 家族と一緒に名言を読み返して盛り上がっていたり、お子さんも名言の記録を楽しんでいたりと、こどもの名言が家族のコミュニケーションにつながっていて素敵だなと思ったことを覚えています。

かわかみさんの話を聞いて、「こどもの名言記録のサービスを作ればスプレッドシートよりも簡単に記録できるのでは?」と思ったのがきっかけです。

私もこども達の面白い発言を聞く機会は多いのですが、時が経つにつれて忘れてしまうことが多く、大事な思い出が薄れていくことに寂しさを感じていたので、こどもの名言を記録できるサービスを作ることにしました!

ユーザーへのヒアリング

サービスをつくる前に 名言をスプレッドシートで記録していたかわかみさんに記録状況などをヒアリングしました。

名言は突然生まれて、生まれた側から忘れられていく

お話を聞くなかで

  • スプレッドシートに名言を記録しているが、シートを開くのに時間がかかる
  • 名言を書く時間がない時は名言自体を忘れてしまうことがある

という課題があることがわかりました。

この課題を解決するために

  • 名言が生まれた瞬間に簡単に記録できる
  • スマホユーザーが使うことを前提にする

という方針を決めてサービスをつくることにしました。

(かわかみさんとお話しする中で「名言は突然生まれて、生まれた側から忘れられていく」という名言をいただきました✨)

ユーザーの目線でつくる

ヒアリングした内容からユーザーの目線に立って実装していきました。

一例で言うと、名言の入力フォームです。 最初の案では名言を記録するだけでなく、「名言を発言した状況」など、複数の項目を細かく記録できるようにするつもりでした。

ただ、ユーザーヒアリングの内容から「名言が生まれた瞬間に簡単にメモしたい」という方針があったので、複数の登録項目を用意するのではなく、名言の内容だけを登録できるシンプルな入力フォームにしました。

実際に使ってみると、名言をサクッとメモできるので項目を減らして良かったなと思っています。

苦労したところ

技術選定の難しさ

自作サービスを作るにあたり、技術選定で右往左往しました。

今回のサービスでは最終的にRails7とHotwireで実装したのですが、序盤では

  • 自分の技術力をつけたい
  • 技術的要素を組み込みたい

という理由からまだ触ったことのないNext.jsを使って実装しようとしていました。

バックエンドはRails、フロントエンドはNext.jsという構成で作り始めていたのですが、リソース設計をメンターの方に見てもらっている中で自分の技術不足で考慮していなかった点が見つかったり、一つの機能を作るにもかなり時間がかかっている状況でした。

  • このままではリリースまでの期間が延びてしまう
  • Cotomemoryの機能はRailsだけでも作ることができる
  • Next.jsで実装するのに比べHotwireでの実装は学習コストが低そう
  • Railsでリリースした後に少しずつ新しい技術を取り入れるのも良さそう

という理由から、最終的にRailsとHotwireの組み合わせで進めることにしました。 技術選定で右往左往したのですが、結果的にはRailsの技術を深めることができたので良かったと感じています。

また、Hotwireに関してはSPAのような動きをJavaScriptをあまり書かずに作成できて驚きでした。名言を登録するとリロードせずとも名言一覧に表示させたり、名言一覧の無限スクロール機能などもHotwireで実装しました。

Hotwireについては「猫でもわかるHotwire入門」がとても参考になりました。

zenn.dev

また、フィヨルドブートキャンプのカリキュラムではminitestを勉強していたのですが、実際の現場ではRSpecを使うことが多いと聞いていたので、RSpecでテストを書きました。

最終的には以下の技術スタックで作成しております。

自作サービスはやること盛り沢山

1つのサービスをリリースするまでにはたくさんのタスクがありました。(CotomemoryのリリースまでのIssueは150件ほど)

  • どの技術を使うか選定する
  • DB設計、リソース設計
  • 機能の実装
  • テストを書く
  • サービス名を決める
  • ロゴをつくる ...

自作サービスは考えていた以上の作業量があり、先のことを考えると「本当に完成するのか」と不安になることがありました。

仕事や子育てが忙しくなると進捗も出せなくなっていたので、できる限り一つのIssueを細かく設定し、少しずつでも前に進めるようにしました。 大きなIssueは30分くらいで終わるレベルのIssueに分けると取り掛かりのハードルも下がり、結果的に進捗が出ていることが多かったです。

小さいことをどんどん積み上げて完成まで辿り着きました。

リリースまで終えた感想

自信がついた

リリースまでを終えて一番感じていることは自信がついたなということです。

サービスを作り終えるまでに何度も分からないことに遭遇したり、次から次にバグが出てきたりと心が折れそうになることもありましたが、「絶対にリリースするぞ」という気持ちでどうにか自分で解決したり、メンターの方に相談しながらサービスをつくりあげました。

自作サービスを通して「どんなことでも継続すればやり遂げられる」という自信がついたのが大きいです。

英語を読むのが苦ではなくなった

フィヨルドブートキャンプに入ったばかりの頃は「英語のドキュメントを読むのは大変だな」と思っていたのですが、自作サービスを作っていくうちに「欲しい情報が英語でしか書いていない」「公式ドキュメントが英語のみ」という場面によく遭遇しました。

英語のドキュメントも読まざるを得ない状況になって、読んでいくうちに苦手意識も薄れてきた気がします。

子育てとの両立は大変だ

昨年の秋頃からCotomemoryを作り始めていたのですが、今年の1月に第三子を出産したことで、その前後はほとんど作業ができずリリースまでかなり時間がかかってしまいました。

「子育てと勉強を両立もできる!」と自信満々に言いたかったんですが、特に裏技的なものはありませんでした。

一つ、気をつけたことといえば無理しすぎないことです。

以前、メンターの方からフィヨルドブートキャンプは長距離マラソンのようなものだから息切れしないように、自分のペースで無理なく続けると良い」というコメントをいただいたことがありました。

私の中でこの言葉にすごく腑に落ちていて「周りの人と比べるとスローだけど少しずつ前に進むぞ」という気持ちで走り切りました。子育ての期間にもこれだけ頑張れたのは今後の糧になると思います。

さいごに

2020年11月にフィヨルドブートキャンプに入会して時間はかかりましたが、自分のサービスを作ることができるようになりました。

komagataさん、machidaさん、メンターの方々、協力してくれたかわかみさん、いつも雑談してくれた受講生の皆さん、日報にコメントくださった皆さん、たくさんお世話になりました!

これからも、もっと技術力をつけて活躍できるように頑張ります。

はじめてのRubyKaigi

目次

フィヨルドブートキャンプでプログラミングを学習中のsiroです!

2023年5月11日〜13日に開催されたRubyKaigi 2023に参加してきたので、思ったことを記録しておきます。

はじめてのRubyKaigi

RubyKaigiには去年一昨年とオンラインで参加していました。今回もオンラインで参加しようかなーと迷っていたところ、Rails Girls JapanのRubyKaigi参加支援を見つけたので思い切って応募して現地参加してみました!

聞いたセッション

Day1

Day2

Day3

3日間でこれだけのセッションを聴きました。

セッションの内容は分からないことが多かったですが、「生き生きと話していて楽しそう!」「私の知らないことがたくさんある!」と世界が広がった気分です。

RubyKaigiは「分からないことを楽しむ場」という話を事前に聞いていたのですが、こういうことかーと実感できました。

また、会場で登壇していた方に感想を伝えたり、さらに深い話を聞くことができたので、松本まで来て良かったー!と何度も思っていましたね。

フィヨルドブートキャンプ生と会えた

私が普段学習しているフィヨルドブートキャンプのみなさんもRubyKaigiに多く参加していました。

初めてリアルでお会いできて「お〜、〇〇さんだ!」「〇〇さんもいる!」と1人感動していました。一緒にチーム開発していたメンバーとは取り組んだissueの話もできて楽しかったです。

フィヨルドブートキャンプ関係者だけでも40人以上参加していたので、ぶらぶら歩いているうちに仲間と遭遇して、いつの間にか深い話をしていたりと楽しく過ごすことができました。

Rails Girls Japan

2日目のお昼にはRails Girls Japanの方々とランチしました!

最近開催したRails Girls Nagasakiが大成功だったようで、開催の様子を聞くのが楽しかったです。私の地元も長崎なので次回開催することがあったらコーチとして参加したいな〜という思いが高まりました。

自作キーボードが気になる

そして、私のkaigieffectは自作キーボードです。

RubyKaigiの前日に開催されたKeebKaigiで「何も分からない状態からキーボードを作った話」をかわかみさんが発表していて、自分もキーボードを作る気満々になりました。

早速、登壇者のかわかみさんに色々教えてもらってハンダゴテをゲットし、meishi(自作キーボード入門キット)を作っている最中です。分割キーボードもつくってみたいな〜!

松本が最高だった

開催地の長野県松本もお洒落なカフェがあったり、美味しい日本酒があったりと街の雰囲気が最高でした。特急しなのから見えた川の景色も綺麗で感動しました。

現地に行くまでは松本のことは全く知らなかったのですが、もっと滞在したくなるくらい素敵な街です。今度は家族も連れていきたいな。

おわり

今回はRails Girls Japanの参加支援でRubyKaigiに参加することができました。このような機会をくださり、ありがとうございます!RubyKaigiでは普段お話しできない方ともお話しできて想像以上に楽しい3日間でした。

そして、RubyKaigiのオーガナイザー、運営スタッフのみなさまも素敵なカンファレンスをありがとうございました~!!!!

Rails Girls Gathering Japan 2022のスタッフとして参加しました

こちらの記事はRails Girls Japan Advent Calendar 2022 の16日目の記事です。

qiita.com

昨日はthatblueさんの「#rgjp10th を支える技術・ツイート収集バッチ実装編 - イノたまごラボ・あのぶる の「こんなの作ったよ!」」でした。収集バッチの実装ありがとうございました!

目次

Rails Girls Gathering Japanの開催

今年も12/3にRails Girls のオンラインイベントのRails Girls Gathering Japan を開催しました。

gathering.railsgirls.jp

キーノートやライトニングトークで登壇いただいた皆さま、参加していただいた皆さま、イベントを盛り上げていただきありがとうございました!

今年もスタッフをやってみた

昨年に続き、今年もRails Girls Gathering Japanの運営スタッフとして参加しました。今年はInstagramでイベントの告知をしたり、LT参加者への連絡や当日のオープニングトーク、タイムキーパーなどを担当しました。

特にInstagramの運用は初めての取り組みで「Twitterを使っていない、プログラミングを始めたばかりの人たち」にもRails Girlsのことが届くと良いなということで始めました。まだまだフォローや反応をいただくことは少ないですが、頑張って投稿していました。

参加したことがないコミュニティへの初めての参加はハードルが高いので、これからもInstagramなどのSNSを使ってRails Girlsの雰囲気を伝えていき、初めての方でも気軽に参加できるようにしたいです。

Rails Girls 10周年

そして、今年はRails Girlsのイベントを日本で初めて開催してから10周年です。

私がRails Girlsのことを知ったのは2年前のRails Girls Gathering Japanでした。これまでの10年のことは正直あまりわからないのですが、Rails Girlsに関わる人々は優しくて温かいコミュニティだなと感じています。私は "この温かいコミュニティのこれからの10年" を作っていきたいです。機会があればRails Gilrsのコーチなどでもイベントに参加したいですね。

さいごに

昨年はスタッフの皆さんも初めましての方ばかりでイベントまで緊張してばかりだったのですが、今回は2回目のスタッフだったので昨年よりも力になれたかなと思いました。

スタッフの皆さん、事前準備やイベント当日などで色々お助けいただきありがとうございました。お疲れ様でした!!

フィヨルドブートキャンプのチーム開発に参加した話

この記事はフィヨルドブートキャンプ Part 1 Advent Calendar 2022 - Adventarの1日目の記事です。

今年もPart 1、Part 2のアドベントカレンダーが用意されているので、これから毎日記事を読んでいくのが楽しみです!

目次

はじめに

フィヨルドブートキャンプで学習しているsiroです。普段は2人の女の子を育てながら、自社サービスのカスタマーサポートとして働いております。

フィヨルドブートキャンプには2020年の11月頃から参加し、ちょうど2年が経過しました。(進みはゆっくりな方)

ちょうどフィヨルドブートキャンプのカリキュラムの終盤にあるチーム開発が終わったので、感想を書いていこうと思います。

フィヨルドブートキャンプのチーム開発

フィヨルドブートキャンプでは終盤にチーム開発というカリキュラムが用意されています。チーム開発では普段フィヨルドブートキャンプで使っているEラーニングシステムの開発に参加します。

github.com

Issueにポイントが付与されていて、20ポイント分のIssueを担当し、closeになったらチーム開発のカリキュラムが完了になります。

EラーニングシステムはRails、Vue.jsで構成されていて、ここまで学んできたRubyRails、Vue.jsはもちろん、Git、データベース、オブジェクト指向、テスト技法など全ての力を結集して開発していくので点と点が繋がってく感覚があり、とても楽しかったです。

実際に担当したIssue

以下のIssueを実際に担当しました。

  • 簡単な文言修正
  • バグ修正
  • Vue.jsに関するもの
  • 新機能の開発(定期イベント)
  • 外部のOSSにPRを送って解決したもの

徐々にレベルが上がるIssueを割り振ってもらえるので、スムーズに進めることができました。

Issue PR
テスト用ユーザデータのFacebookURLが、Fjordに関係がなさそうな実在する人のURLになっている · Issue#3601 #4544
未アサインの提出物のDiscordの通知にリンクを付ける · Issue#4313 #4559
卒業生のダッシュボードに「卒業後の目標」の入力を促すブロックは表示しない · Issue#4505 #4597
相談部屋に未ログインでアクセスすると500エラーが出る · Issue#4487 #4601
[通知] ユーザーが退会した時、メンターに通知が飛ぶようにしたい · Issue#4387 #4605
カテゴリー並び替えで空のスラッグの行を削除したい · Issue #4563 #4639
エラーで表示されないメールのプレビュー画面がある · Issue #4441 #4644
[定期イベント]定期イベント一覧、個別、作成、削除がほしい · Issue #4537 #4862
プロフィール画像のファイルアップロードにおけるセキュリティ上の懸念 · Issue #2456 #4963
[定期イベント]定期イベントをコメントアウトしてリリース · Issue #4925 #5034
FirefoxでD&Dによる画像添付ができない · Issue #5332 #5613

最後の方のIssueは初見では全くわからなかったので、自力で調べて、怪しいコードを何度もデバッグして解決していきました。

また、落ちたり落ちなかったりするFlakyなテストもあり、原因を突き止めるために何度もテストを回してkomagataさんに質問しにいったり、「あーでもない、こーでもない」と根気強くやっていた気がします。

私がフィヨルドブートキャンプに入ったばかりの頃は「チーム開発まで進んでいる人はすごい...」「雲の上の存在だ...」と思っていましたが、チーム開発まで進んでも全然そんなことなく、「新しい分からないがどんどん出てくるんだな」と思っていました。

これは多分これからもずっとそうですね。

新機能を開発した

担当したIssueの中で一番思い出深いのは『定期イベント』という機能の開発です。

フィヨルドブートキャンプでは在校生・卒業生が自発的に輪読会を開催しています。最初の頃は輪読会も少なかったので、いつ開催されているか把握できていたのですが、輪読会もどんどん増えてきて「いつ開催されるのか」追えなくなっていました。

そこで輪読会の一覧をフィヨルドブートキャンプのアプリ上でドキュメントにまとめていました。

簡単に書いたドキュメントだったのですが、新しい輪読会が開催されるたびに皆さんに更新いただき、私が思っていたよりもよく使われるドキュメントとなっていました。(ありがとうございます)

このドキュメントの代わりとなる、輪読会などのイベント情報を管理する機能として作ったのが『定期イベント』機能でした。

machidaさんに「輪読会一覧のドキュメントを作ってくれたのがsiroさんなので定期イベント機能もお願いしたい」と言っていただき、嬉しかったのを覚えています。

この定期イベントの新規作成ページや詳細ページ、編集・削除、イベント一覧の一通りの機能を実装しました。

マイグレーションファイルを作るところから、多対多の関連付け、一覧をVue.jsで実装するなど、今まで勉強してきたことがモリモリ入っていて「全てが繋がっているんだな〜」と一番実感したIssueです。

新機能なのでざっくりとしか仕様が決まっていないところもあり、あとで「もう少し詳細に確認しておけばスムーズだったな」と思うところもありました。そこは今後に活かしたいです。

そして、ちょうど昨日、定期イベント機能がリリースされたようです。他のチームメンバーが機能の肉付けをしてくれて、とても使いやすくなっていたので感動しました。

みんなの力を合わせて作った機能を使ってもらえると思うと、嬉しいですね。

はじめてレビューする

チーム開発で一番最初に不安に思っていたのはレビューでした。

チーム開発では最終的にkomagataさんにレビューしていただくのですが、その前にチームメンバー間でレビューするルールになっています。

他の方が書いたコードをレビューするのは初めてだったので、「何を見たら良いのだろう」「そもそも自分が書いたコードでさえあまり自信がないのにレビューできるのかな」と不安を感じていました。

日報にそんなことを書いていたら、メンターさんから

正しいことを書かないととか、間違いを見つけないと、というプレッシャーを感じる必要はなくて、よりよいものを一緒に作っていくための行為と思っていただけるとよいのかなーと思います!

とコメントいただき、気持ちが楽になりました。

レビューを「よりよいもの作るため」だと考えればレビューへの抵抗もなくなり、自分が少しでも疑問に思ったことはコメントするようになりました。レビューで指摘してもらった時も落ち込んだりすることもなく、その内容に向き合うことができた気がします。

他にも、指摘するような文面だけだとキツい印象を感じてしまうかもしれないので、良いと思ったところや勉強になったところも積極的にコメントで残すようにしていました。

komagataさんが「チーム開発ではコードを書くより、コミュニケーションのためのテキストを書く時間の方が長い」というようなことをおっしゃっていたのですが、本当にその通りで、メンバーに「テキストでどう伝えると意図通りに伝わるのだろう」と考えている時間が長かったです。

仕事と子育てとチーム開発

そして、私は日中は仕事をしていて夜は子育てをしているので、空いている時間を見つけて作業していくのがかなり大変でした。

チーム開発ではレビューをしたり、ペアプロ・ペアレビューしたり、MTGがあったりと他のメンバーと作業することが多かったので時間の確保に苦労しました。

時間を合わせるために有給を取ったり家族に協力してもらい、なんとかこなすことができた気がします。

特にチーム開発のMTGは、仕事のお昼休みの時間を使って出ていたので体力的にかなりハードでした... (チーム開発のMTGは水曜の昼か夜かを選べるのですが、夜は子どもの寝かしつけがあるので、できる限り昼に出ていました)

「仕事と子育てしてても余裕だった!」と言いたかったですが、全然そんなことなく...「絶対に最後までやるぞ」という気力でなんとか終わらせた気がします。

無事全てのIssueをcloseできて一安心です。

もっと余裕を持ってやっていきたかったですね。(でも仕方なかったかな)

さいごに

今年の春頃からチーム開発をスタートして、肌寒くなるくらいまでやっておりました。数ヶ月で終わる方が多いので、長い方だとおもいます。

記事を書いている時点で今年のFBC contributors、19位でした。

実は夏前に第三子の妊娠が分かり、なかなか思うようなスピードでは進められなかったですが、無事最後のIssueまで終わって良かったです。

今は自作サービスを作るためにReactを絶賛勉強中です。来年の早い段階で(できれば出産前に)自作サービスをリリースしたいなと思っています。

がんばります〜!

おまけ

あと、チーム開発を進めながら、Rails Girls Gathering Japan 2022というイベントのスタッフとしてイベントの準備を進めてきました。こちらのイベントが今週の土曜日(2022/12/3)に開催予定なので、ご参加いただけると嬉しいです。

gathering.railsgirls.jp

子供の誕生日から行事の日付を算出するnpmを作った

最近ずっとカーリングを見ているsiroです。冬季オリンピックの中だとカーリングが一番好きです。カーリングは一瞬で局面が変わるので見ていて面白いですね〜。

npmを公開しました

今回、子供の誕生日から行事の日付を算出するnpmを作りました。

japanese-events-for-child - npm

f:id:siroemk:20220215125325p:plain

npmを作った経緯

フィヨルドブートキャンプの「npmを作る」という課題の提出物として作成しました!

他の方が作成したものを見ると、作業効率化系やゲーム、面白クイズなどが多かったです。

何を作るか悩んだのですが、少し前に自分がつぶやいていた

f:id:siroemk:20220216164302p:plain

これがいいのではと思い、子供の誕生日から行事を算出するものを作りました。

Googleカレンダーまでは実装してないですが...)

子供の行事って誕生日からn日後、n年後に行うものがあるので、その都度みなさん計算していると思います。忘れた頃に行事がやってくるので、一覧で見たいなと思っていました。

今回は誕生日を入力することで小学校入学までの行事の日付が表示されるプログラムを作りました。

難しかったところ

そもそもJavaScriptが難しい

フィヨルドブートキャンプでは前半〜中盤にかけてRubyでプログラムを書いていきます。ちょうどRubyに慣れてきた頃に、JavaScriptのプラクティスが現れます。

  • Rubyだと書けそうだけど、JavaScriptだと分からない
  • JavaScript、{}()が多い...
  • thisの使い所が?
  • 非同期処理の動きが掴めない
  • プロトタイプベースとクラスベースの違いがよくわからない

などなど、JavaScriptに慣れるのに時間がかかりました。JavaScript Primerを何度も読んで、JavaScriptで簡単なプログラムを書いたり、他の人のコードを手元で動かしてみて少しずつJavaScriptに慣れていきました。

今回自分でコードを書いたことで、「thisってこれを指してるんだ」、「非同期処理はここで使うんだ」と理解が深まった気がします。

自分で仕様を考えることの難しさと楽しさ

そして、一から仕様を考えて作ったのは今回が初めてでした。

シンプルなプログラムですが、

  • どの行事にするか
  • 行事の年齢は満年齢と数え年のどちらを採用する?
  • 男の子と女の子で行事の日付が違うものはどうするか
  • 誕生日はどうやって入力させる?YYYYMMDD?
  • 誕生日によって行事の順番が異なる場合、どうソートさせる?
  • 日付の表示形式は?
  • ありえない値が入ってきた時の動きは?

など考えることはたくさんありました。作る時間と同じくらい、仕様を考えるのに時間がかかったと思います。

初めは行事の説明も表示させようと思っていたのですが、書いているうちに使いにくいそう...と思い、辞めました。

その試行錯誤が楽しかったです。

使ってもらえたら嬉しい!!

とても簡単なプログラムですが、使っていただけると喜びます!!

japanese-events-for-child - npm

npmを公開した後にブートキャンプ生から「使ってみたよ〜」と声かけていただきました。自分が作ったものを触ってもらえると嬉しいですね。

フィヨルドブートキャンプ歴も1年を超えました。あと少しで最後のシステム開発と自作サービス開発に入れそうです。(卒業が見えてきた)

引き続きやっていきます〜。

完璧じゃなくても良いんじゃない?

これはフィヨルドブートキャンプのアドベントカレンダー17日目の記事です。

フィヨルドブートキャンプ Part 1 Advent Calendar 2021 - Adventar

フィヨルドブートキャンプ Part 2 Advent Calendar 2021 - Adventar

昨日は@konagaさんのフィヨルドブートキャンプでLinux(Ubuntu)を使うときの実情でした!

目次

最近思っていること

フィヨルドブートキャンプで学習中のsiroです。フィヨルドブートキャンプに入って1年経ちました。来年は卒業できたら良いな〜。

今日は最近思っていることについて書いていこうと思います。

結論から言うと「完璧じゃなくても良いんじゃない?」

完璧にしたい気持ち

私は元々は自分に甘く、後先考えずに「ま、いっか」と突き進むタイプです。続けると言ったことはあまり続けれていないし、すぐに飽きることもよくある。

そんな私ですが、フィヨルドブートキャンプで学習中に、いつの間にか完璧主義になっているなと思うことがありました。

「やるからには全部の知識を身につけたい!完璧に理解したい!」という思いから、

  • 技術本は端から端まで理解してから進めよう
  • コードは自分が納得できるまで完璧に作り上げてから提出しよう
  • 日報は凝った内容で毎日書かなくてはいけない etc.

こんなことを頭のどこかで思いながら作業していました。 この完璧を目指すにあまり、1人で悶々と何時間何日も「あーでもない、こーでもない」と悩んであまり進まなかったり、「日報を書かなくては」と思うことがプレッシャーになったりしてパソコンを開くのが億劫になってしまう日もありました。

完璧を目指しすぎるあまり、完璧にできない自分に苛立ってしまったり、焦ってしまったりと悪循環を生んでいました。

自分を苦しめていたのは自分が作り上げているものだったと気づく

そんな時に、ふと「私が目指している完璧とはなんだろう」と思いました。

明確なゴールや答えが決まっているものなら、完璧の基準はみんな同じかもしれない。でも、コードのように人によって答えが違ったり、いろんな答えが正解になる事象に対しての完璧ってなんだろう。

そもそも、現段階で完璧にできなくても、コツコツやっていくうちに自然とできることが増えていくんじゃない?

そして、私が目指していた完璧を客観的に見てみると、そんなことにこだわらなくても...と思うところも多かった。結局自分で作り上げた「こうあるべき」という感情に苦しめられていたんだなと思いました。

nullなり適当な値を突っ込んで実行する勇気

なぜこんなことを書いているのかというと、最近、フィヨルドブートキャンプ内で伊藤さんが紹介していた「nullなり適当な値を突っ込んで実行する勇気」というドキュメントにすごく共感したからです。

提出物の出来を100点満点にしようとがんばって何週間もかけるより、「ちょっとしっくりこないところもあるんだけど」という出来でさくっと提出してフィードバックをもらう、という考え方もあります。

以下の記事に載っている「nullなり適当な値を突っ込んで実行する勇気」という考え方がそれです。

非コミュプログラマーが独立するのに必要なたった2つの勇気【連載:村上福之】 - エンジニアtype | 転職type

(※公開時に出典が抜けていたので2021/12/18に追記しました🙏)

これを読んで、「そうそう、私が思っていたのはこれだ〜」と思いました。何週間も時間をかけて1人で悶々と作業していると、前に進まない状況にだんだん辛くなってきます。

時間が無限にあって忍耐強い人あれば苦ではないかもしれないけれど、時間は有限だし出来ればサクサク進んでいきたい。

特にプログラミング初心者だと「そんなところにこだわらなくても...」「それよりこっちの方が大事じゃない?」みたいなことに対して1人で悶々と悩んでいる方が多いのではと思います。

私も完璧に仕上げたつもりのコードが根本的に見当違いだったみたいなことがよくあります。1日悩んで分からず、泣く泣く質問タイムで聞いてみると、全然違うところが原因だったこともあります。

最近は、1人で完璧を目指すよりも、自分のプライドや気持ちに折り合いをつけて、完璧じゃなくても人に見せてみたり、弱音を吐いたりする方が人間味があって良いんじゃない?と思っています。

コードは動くだけで提出していいし、日報は頑張って書かなくても1行だけでも良い。完璧を求めるあまり、途中で投げ出してしまうなら、1つでも「とりあえずやってみた事実」を作ることが大事だなと感じています。

完璧を目指すのはその後でも遅くはなさそう。

おまけ

ちなみに今回の記事は "あえて" 完璧にできない ように、アドカレ担当日の今日になってから書いてみました。

今日の朝起きた時は「やばい、今日公開できるか分からん」と思っていたけど、意外とどうにかなっている。こういうのでも良いんだよな〜。

完璧じゃなくても良いんじゃない?