give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

リモートワーカーの外耳炎防止!?AirPods ProからAfterShokz OpenComm(骨伝導ヘッドセット)に乗り換えた

はじめに

僕はコロナ禍の影響でリモートワークが流行る前から、長年自宅でリモートワークしていました。
ビデオ会議ではMac本体のマイクとスピーカーを使うより、ヘッドセットを使った方が音質が良いのでヘッドセットは必要不可欠です。

AirPods Proで外耳炎になる!?(注:非専門家の意見です)

ここ数年はApple AirPodsを使っていて、半年前ぐらいからAirPods Proを使っていました。
AirPods Proはノイズキャンセリング機能が付いているので周囲にノイズがシャットアウトされ、快適にビデオ会議ができます。
というわけで、最近までずっと「AirPods Pro最高!」と思いながら使っていました。

が、日によっては4〜5時間ぐらいAirPods Proを付けてビデオ会議をしている日があります。
そうすると、だんだん耳の中が少し痛いような、気持ち悪いような、何とも言えない違和感を覚えるようになってきました。

また、社内にはちょっと前に「外耳炎になっちゃって大変」と言ってる同僚がいました。
彼もAirPods Proユーザーだったのですが、外耳炎になると耳の中に物が入れられないのでAirPods Proが使えなくなります。

AirPods Proはノイズキャンセリング機能を重視しているせいか、イヤーチップが耳の穴に密着して「ずっと耳の穴に指を突っ込んでるような感覚」になります。
どうもこれが耳の不調の原因になっている気がしてなりません。
"AirPods Pro 外耳炎”みたいなキーワードでググると、やっぱりAirPods Proユーザーで外耳炎になってしまった人が少なからずいるようです。

なので、「このままAirPods Proを使い続けると僕も外耳炎になっちゃうかもしれない・・・」と、ちょっと怖くなってきました。

f:id:JunichiIto:20201222150051j:plain
AirPods Pro、とっても気に入ってたんですが、だんだん耳の調子が・・・。
骨伝導ヘッドセットなら大丈夫かも?

そんなとき、ちょうど僕がメンターをやっているフィヨルドブートキャンプのSlackチャンネルで「骨伝導ヘッドセットがいいよ」という噂を耳にしました。
最初は「骨伝導?何それ、ちょっと胡散臭い😑」とか思ってたのですが(すいません)、骨伝導ヘッドセットは耳の穴には何も入れないので、実は僕のようなビデオ会議が多いリモートワーカーには打ってつけなのかもしれません。

フィヨルドブートキャンプのSlackチャンネルで実際に使っている人に話を聞いてみると、骨伝導ヘッドセットはAfterShokzというメーカーのものが有名だそうです。
(余談ですが、骨伝導ヘッドセットには詳しくないので、Amazonでメーカー名を見ても有名か無名か判断できないんですよね〜)

僕が話を聞いたのはちょうどOpenCommという最新モデルが発売された直後で、実際に使ってる人の話も聞けたので、僕もこの製品を購入してみました。

f:id:JunichiIto:20201222092842j:plain

OpenCommが届いてから1ヶ月近く経過したので、このエントリでは使用レビューを書いてみようと思います。

OpenCommの良いところ

最初にOpenCommの良いところをまとめます。

怖くない骨伝導

骨伝導ヘッドセットというのはみなさんあまり馴染みがないかもしれません。
僕も名前だけしか聞いたことがありませんでした。

それにしても「骨伝導」っていう名前がおどろおどろしいですよね。「骨」って!「伝導」って!☠️
使うと脳みそがブルブルと揺さぶられるような、そんなイメージを持つ人もいるんじゃないでしょうか。

しかし、大丈夫です!脳みそがブルブルすることはありません(笑)。
僕個人の感想としては、普通のヘッドセットと違和感なく使えると思っています。意外と自然です。

感じ方は個人差があるかもしれませんが、僕の場合は使っていて「あー、骨伝導してる〜(ブルブルブル)」みたいな特殊な感覚はありません。

外耳炎になる心配はなさそう

AirPods ProからOpenCommに乗り換えた一番の理由は外耳炎の予防です。
すでに書いたとおり、OpenCommは耳の中には何も入れないので外耳炎になる心配はありません。
実際、OpenCommに乗り換えたことで耳の違和感はなくなっていきました。
この点はとても良かったです😄

f:id:JunichiIto:20201222131332j:plain
Image: https://aftershokz.jp/products/bone-conduction-headphone-opencomm
電池の持ちが良い

AirPods Proは3〜4時間連続で使っていると、電池が減って充電が必要になってきます。
OpenCommはAirPods Proに比べるとかなり電池が持ちます。
満充電にしてから数日にわたってビデオ会議で使用してみましたが、合計12時間ぐらい使ってもまだ電池が残っていました。

ビデオ会議が多いときでも2日に1回ぐらいの充電で良いので、会議中に電池切れの心配をしなくて良くなったのはOpenCommのメリットです。

十分軽い、折り曲げにも強い

重量は33gでとても軽いです。製品素材も柔軟なので、折り曲げにも強いです。
ですので、使用頻度が多くても重さでストレスが溜まったり、すぐに壊れたりすることはないように思います。

OpenCommのいまいちなところ

次にOpenCommのいまいちなところを書きます。
ただ、いまいちと言っても、どれも深刻な問題ではないので、メリットとデメリットを比べればメリットの方が上回る、と考えています。

音楽を聴くのには向いていない

AirPods Proに比べると音質はちょっと軽くて薄っぺらいです。というか、音楽を高音質で楽しむためのヘッドセットではないと考えた方がいいです。
でも、人間の声を聞くぶんには必要十分な音質です。
音楽鑑賞用としては△、ビデオ会議用ヘッドセットとしては◎、という感じですね。

ちなみに音楽鑑賞については、僕はDynaudio Musicというちょっと高級なBluetoothスピーカーを愛用しているので、OpenCommが音楽向きでなくても特に気にしていません。
blog.jnito.com

電池の残量を細かく把握できない

AirPods ProはMacの画面上で電離の残量をパーセント表示できました。
OpenCommではそのような表示はありません。

f:id:JunichiIto:20201222144642p:plain:w300

OpenCommではスピーカーやマイクを使っていない状態で音量の+ボタンを押すと、音声で残量が通知されます。
ただし、「充電されています / およそ半分です / 残りわずかです / 充電してください」の4パターンしかないので、AirPods Proの便利さに慣れていると「残量はパーセントでお知らせしてほしい!」と思ってしまいます。

(2021.12.6追記)
macOS MontereyにアップデートしたらOpenCommのバッテリー残量も表示されるようになってました!
f:id:JunichiIto:20211206172141p:plain:w300

電源のON/OFFが面倒

AirPods Proはイヤホンを耳に取り付けた瞬間にMacとBluetooth接続され、外すと接続が解除されていました。
OpenCommではそういった便利機能はありません。
音量スイッチを数秒間長押しすることで電源ON/OFFになります。

電源がONになると自動的にMacと接続されるものの、毎回自分でON/OFFしなきゃいけないのはAirPods Proの手軽さに比べるとちょっと不便だな〜という印象です。

机の上が少しかさばる

どうしようもない、といえばどうしようもないのですが、ケースにパシッと収まるAirPods Proに比べると、使ってないときの「ちょっとかさばる感」はあります。
机の上はなるべくスッキリさせたいのですが、これはいかんともしがたいですね。

f:id:JunichiIto:20201222130657j:plain

追記:フックに引っかけてみた
百均で買った小さなフックをモニタの側面に取り付けて、そこにOpenCommを引っかけてみました。
これで机の上がかさばる問題は解消しました😄

f:id:JunichiIto:20201224073708j:plain

周囲の雑音はそこそこ拾うかも(が、Krispを使えば問題なし)

OpenCommの製品ページには

DSPノイズキャンセリング・ブームマイクを搭載。
使用者に合わせて角度を調整できます。バックグラウンド・ノイズを排除し、
騒がしい環境でのクリアなコミュニケーションを実現します。

とあるのですが、同僚に協力してもらって確認する限り、キーボードの打鍵音を完全に打ち消すほどの能力はないようです。
(カタカタ音は相手に聞こえるらしい)

ただ、僕はAirPods Proを使ってた頃からKrispを使ってノイズキャンセリングしてるので、この点は特に気にしていません。
Krispを使えば、OpenCommでもキーボードの打鍵音は無音にできます。(Krispすごい!)

krisp.ai

あと、こちらの声はクリアに相手に聞こえてるみたいです。

メガネの人は相性を確認した方がいいかも

僕は裸眼なので気になっていませんが、メガネの人はOpenCommの耳に引っかけるフレームがメガネと干渉して邪魔、と感じる場合があるようです。
気になる・気にならないは人それぞれ(メガネそれぞれ?)みたいですが、普段メガネを使っている人はできれば購入前に自分の使っているメガネとの相性を確認した方がいいかもしれません。

ちなみに、OpenCommを持って外出する人はメガネとOpenCommに加えて、マスクも耳に引っかけないといけないみたいです。
耳に3つも引っかけるのはなかなか大変ですね・・・。

ノイズキャンセリング能力は皆無(が、裏技で回避可能?)

当然のことながらOpenCommは耳の中に何も入れないので、ノイズキャンセリング能力はゼロです。
とはいえ、ふだん使っているときはOpenCommから聞こえる音声に意識が集中しているせいか、意外と周囲の音は気になりません。

それでもたまに周りの音がうるさい、と感じることもあります。
そんなときは市販の耳栓を耳の穴に突っ込みましょう。
するとあら不思議、骨伝導ヘッドセットなのになぜかノイズキャンセリング機能が実現します(苦笑)。

Earplugs

ですが、あまり頻繁に耳栓を使うと結局外耳炎のリスクが再び上がってきてしまうので、「どうしても」というときだけ耳栓を使うようにしています。
(というか、そういうときだけAirPods Proを使えばいい気も・・・)

まとめ

というわけで、このエントリでは最近買った骨伝導ヘッドセット、AfterShokz OpenCommの紹介をしてみました。
AirPods Proに限らず、イヤホン、ヘッドホンの使いすぎで耳の調子が悪くなってきた人は骨伝導ヘッドセットに乗り換えてみるといいかもしれません。ぜひ検討してみてください!

フィヨルドブートキャンプのメンターとしてやっていること、感じていること #fjordbootcamp

はじめに

このエントリはフィヨルドブートキャンプ Part 2 Advent Calendar 2020 22日目の記事です。
昨日はYuki Watanabeさんの「Gitちんぷんかんぷんな私がGitを学ぶ!そこから学習のコツを見つけるところまで」という記事でした。
フィヨルドブートキャンプのアドベントカレンダーにはPart 1もあります。

さて、僕は2020年2月からフィヨルドブートキャンプでメンターをやっています。
僕がメンターをやってみようと思ったのは、プログラマ界隈で定期的に話題になる「プログラミングスクールって、ちょっとどうなのよ?」というややネガティブな評価について、実際に中の人の立場で体験していろいろ考えてみたいと思ったからです。

フィヨルドのお二人とは以前から知り合いですし、フィヨルドブートキャンプについてはネット上であまり悪い噂を聞かない(むしろポジティブな評価の方が多い)ので、「ちょっと混ぜて〜」的なノリでメンターとして参加してみました。

というわけで、このエントリでは10ヶ月ほどフィヨルドブートキャンプでメンターをやってみた感想をあれこれ書いてみようと思います。

用語や人物関係の整理

フィヨルドブートキャンプをあまりご存じでない方のために、用語や人物関係を少し説明しておきます。

フィヨルドブートキャンプ
株式会社フィヨルドが提供するプログラミングスクール
フィヨルド
株式会社フィヨルドを指す(フィヨルドブートキャンプはプログラミングスクール、フィヨルドは企業)
駒形さん
株式会社フィヨルドのプログラマであり、フィヨルドブートキャンプのメンターでもある
町田さん
株式会社フィヨルドのデザイナーであり、フィヨルドブートキャンプのメンターでもある
メンター
フィヨルドブートキャンプで生徒の指導にあたるプログラマ。駒形さんと町田さん以外は現役プログラマが副業としてやっている
筆者(僕)
株式会社ソニックガーデンで本業のRubyプログラマをやりつつ、副業としてフィヨルドブートキャンプでメンターをやっている
f:id:JunichiIto:20201222155549j:plain
フィヨルドブートキャンプのマスコットキャラクター、ピヨルド(本文とは関係ありません)

【もくじ】

メンターとしてやっていること

提出物のレビュー

フィヨルドブートキャンプでは様々な実践的なプラクティスが用意されています。「Rubyでlsコマンドを再実装する」といったプログラミング問題はメンターがコードレビューをします。

僕も生徒さんが書いたコードをレビューして、ここがどうだ、あそこがどうだ、といろいろ細かいレビューをやってます。
ちなみに僕はテキストで書くのが面倒なので、スクリーンキャスト形式の動画を収録し、口頭で改善点を指摘することが多いですw

f:id:JunichiIto:20201222075939p:plain

日報の確認、およびコメントの記入

フィヨルドブートキャンプの生徒さんは勉強が終わったら毎日日報を提出するように言われています。
メンターにはその日報を確認し、確認済みボタンを押していく業務があります。

日報の中で生徒さんが困りごとを書いていたり、とてもいい話を書いていたりしたときは、コメントを返します。
生徒さんの心の内がわかるような日報は読んでいて興味深く、とても面白いです。

Q&Aの回答

フィヨルドブートキャンプにはスクール内teratail、またはStackOverflowともいうべきQ&Aコーナーがあります。
生徒さんが書き込んだ疑問点に答えられそうな場合は回答を書き込みます。
メンターが回答を書く前に生徒さん同士で疑問を解決してしまうときもあります。
生徒さんが書いた回答もしっかり内容が書けているので、さすがだなー、すばらしいなーと思いながら見ています。

Slackで雑談

フィヨルドブートキャンプには生徒さんやメンターが自由にやりとりできるSlackがあります。
卒業生やアドバイザー(フィヨルドブートキャンプとご縁のある企業のエンジニア)の人たちもSlackに参加しています。
ときには真面目な話を、ときには他愛もない雑談を、みんなでキャッキャウフフと楽しんでいます。

オンラインミートアップへの参加

フィヨルドブートキャンプでは毎月オンラインミートアップを開催しています。
都合が合うときは僕もミートアップに参加して受講生のみなさんとオンラインでお話ししたりしています。

メンターミーティングへの参加

フィヨルドブートキャンプでは毎月メンターだけで集まるメンターミーティングを開催しています。
このミーティング内でKPTふりかえりを行い、今の課題を共有したり、今後の具体的な改善策を考えたりしています。

f:id:JunichiIto:20201222071819j:plain
メンターミーティングの様子です
プラクティスの改善

今のプラクティスの内容だとわかりにくい、必要以上に時間がかかる、といった問題点が見つかった場合は、随時改善策を検討して実施しています。
プラクティス上の問題点は生徒さんの日報に書かれた困りごとなどから発覚することが多いです。
また、数ヶ月に一回、生徒さん向けのアンケート調査を行っているので、そこで共通して挙げられている困りごとが改善対象になるケースもあります。

たとえばフィヨルドブートキャンプには「課題図書を読む」というプラクティスがいくつかあるのですが、単に「本を読みましょう」というだけでは、覚えることがたくさんありすぎてしんどい、という苦痛の声がたくさんありました。
そこで、「なんのために読むのか」「大事なポイントはどこか」「最悪読み飛ばしてもいいポイントはどこか」といった説明を、各課題図書について追記していったりしました。

僕が以前作った「チェリー本の読み方」という動画もその一環で作成したものです。

著者自身が語る「プロを目指す人のためのRuby入門」の効果的な読み方 #チェリー本

メンターとして感じていること

ここから下は実際にメンターをやってみて感じていることをつらつらと書いていきます。

総じてみんなのモチベーションが高い

フィヨルドブートキャンプの生徒さんは真面目でモチベーションが高い人が多いな〜、という印象があります。
また生徒さんのみならず、フィヨルドの駒形さんと町田さんをはじめ、他のメンターやアドバイザーのみなさんもモチベーションが高く、みんないい人です。
みんな真面目でいい人でモチベーションが高いので、フィヨルドブートキャンプは雰囲気と居心地がいいコミュニティになっています。

僕が「とりあえずやってみっか」で始めてみたアドベントカレンダー企画があっという間にPart 2まで埋まってしまったところにも、みんなのモチベーションの高さを感じています😊

adventar.org
adventar.org

男女比が非常に良い

IT業界は男性中心なイメージがありますが、フィヨルドブートキャンプは男女比がほぼ半々ぐらいだと思います。(具体的な数字は知らないのでただの推測ですが)
僕はこの業界にもっと女性が増えてほしいと思っているので、フィヨルドブートキャンプの男女比はとても健全だな〜と思うことがよくあります。

僕は去年、TokyoGirls.rbという女性Rubyプログラマのためのイベントを主催しましたが(今年はコロナ禍の影響で未開催😣)、フィヨルドブートキャンプでメンターをやっていると「女性プログラマをたくさん増やす」という目的はもう達成できたんじゃないかと錯覚してしまいます(苦笑)。

Ruby業界とのつながりが強い

フィヨルドブートキャンプではRuby on Railsをメインに据えて教えています。
「プログラミングスクールといえばどこもかしこもRuby on Rails」という雰囲気なので、これだけだと「よそと同じ」に見えるかもしれませんが、フィヨルドブートキャンプでは「Rubyが大好きな人たち」がRubyやRuby on Railsを教えています。

「Rubyが大好きな人たち」は総じて「Ruby界隈のすごい人たち」なので、RubyやRuby on Railsを教えるプログラミングスクールとしては日本一かもしれません。(注:個人の感想です)
Ruby超入門の著者である五十嵐さんも技術顧問として参加されていますし、先日は角谷さんがブートキャンプ生のために「FJORD BOOT CAMP AS A GATE」という講演を開催してくださったりしました。

他にもudzuraさんやjune29さんなど、Ruby界隈ではお馴染みの面々がSlackやミートアップに参加してくれたりしています。

あ、そうそう、僕も「プロを目指す人のためのRuby入門(通称・チェリー本)」の著者なので、「まあまあすごい人」にカウントしてもいいかも(苦笑)。

そんなこんなで、Rubyを学ぶことにおいては、世にたくさんある「Rubyを使っているスクール」の中でもダントツに優れた学習環境が用意されているのではないでしょうか。(注:個人の感想です)

メンター陣が優秀

こう書いちゃうと自画自賛になっちゃいますが、フィヨルドブートキャンプはメンター陣がとても優秀です。
だって、フィヨルドブートキャンプは現役のRubyエンジニアが教えてくれるからです!

・・・と書いちゃうと、IT業界の人は「現役エンジニア?あー、あれね……(意味深)」という反応を示しそうですが、フィヨルドブートキャンプのメンターは正真正銘の現役エンジニアです。はい。

僕もそうですし、他のメンターもみんな、長年Rubyのコードを書いてご飯を食べてきている人たちです。
フィヨルドブートキャンプのメンターはみんな、本職の仕事(もちろんコードを書く仕事です)を持ちつつ、副業としてメンター業をやっています。
ちゃんと開発の現場の仕事を知っているので、開発の現場に即した実戦的な知見を提供してくれます。

スクラム開発のプラクティスがとても実践的

フィヨルドブートキャンプのカリキュラムの後半には、スクラム開発というプラクティスがあります。
これはフィヨルドブートキャンプ内で実際に利用している、Ruby on Rails製のEラーニングシステムを題材にして、実際のissueをスクラム形式で開発するというものです。

f:id:JunichiIto:20201222190616p:plain
Rails製のEラーニングシステム

対応するissueも「ここに新機能を追加したい」「この不具合を直してほしい」というリアルなissueそのものですし、生徒さんがそのissueを対応すればそれがそのまま自分が使っているEラーニングシステムに反映されます。

コードの規模もそれなりに大きいですし、フロントエンドにはVue.jsを使ったりしているので、あたかも新人として開発の現場に配属されたような気分が味わえます。
個人的にはこの超実践的なプラクティスが、フィヨルドブートキャンプのプログラミングスクールとしての大きな魅力の一つだと考えています。

月謝制なのが良心的

フィヨルドブートキャンプは入会金もなく、まとめて大金を用意する必要もない、月謝制です。
「自分にはちょっと合わないな」「入ってみたけど全然時間がなくて続けられなかった」と思ったら、いつでも退会できます。

最初にどーんと大金を払った方が自分に対するプレッシャーになる、という人もいるかもしれませんが、そうは言っても実際にやってみたら「あれれ??」と思うこともあるはずなので、月謝制になっているのはとても良心的だなと思います。

bootcamp.fjord.jp

退会されるとちょっと寂しい

月謝制ゆえに、途中で退会してしまう生徒さんもときどきいます。
退会した生徒さんの名前を見て「あー、この人、いっぱいコードレビューしたのにな……」と切ない気持ちになることも多々あります。

生徒さんにもそれぞれ事情があるので、ある程度クールに割り切る必要がありますが、それでもやっぱり僕も人の子なので、「○○さんが退会しました」という知らせを聞くのはちょっと寂しいものがあります😢

生徒さんの就職が決まると嬉しい

フィヨルドブートキャンプの生徒さんの多くは、プログラマとして就職するためにフィヨルドブートキャンプに入ってきます。(一部にはそうでない生徒さんもおられますが)

なので、「○○さんの内定が決まりました!という知らせを聞くと、「おお〜、おめでとう!!🎉🎉🎉」という気持ちになります。
そのあともたまに「就職後も楽しくやってます」という報告を聞いたりすると、「うんうん、良かったね〜」と、どこかのお母さんみたいな気持ちになります。

アフィリエイト広告を使っていないところが好き

プログラミングスクールをネットで検索すると、かなりの高確率でアフィリエイトブログに遭遇します。
中には実際にそのスクールを体験した上でアフィリエイトリンクを付けている人もいるのかもしれませんが、僕が見かけるのはホームページに載っている表面的な情報を集めて、「ここがオススメ!」みたいなランキングを勝手に付けているブログばかりです。

その点、フィヨルドブートキャンプは今のところアフィリエイト広告を使っていないので、僕は「誠実なプログラミングスクールだなあ」と思っています。

ただ、その代わりネット上の露出が少なく、「知る人ぞ知るプログラミングスクール」みたいになっている点がちょっと問題です。
この点については、もう少し状況を改善するためのマーケティング施策を打っていこう、という話をメンター内でしています。

(補足)
アフィリエイト広告を利用している=すべて不誠実なスクール、と言いたいわけではありません。ただ、アフィリエイト広告を見るとその情報が真実なのか、成果報酬だけを狙ったサクラ情報なのか見分けが付かなくなるので、僕はそのブログ上に並んだ評価を素直に受け入れられなくなります。

メンターの僕もいろいろ勉強になる

かれこれ15年以上、プログラマとして働いてきた僕ですが、生徒さんから出た何気ない質問に「えっ、そう言われたらたしかに変ですね。考えたこともなかったけど」みたいに思うことがあります。
そういった内容を調べて、答えが見つかって、「なるほど〜!勉強になった!!」と思ったことが何度もあります。

他にもフィヨルドブートキャンプの生徒さんがRubyの仕様に関する質問をQuoraに投稿して、それにMatzさんが答えてくれる、ということもありました。
僕も普通に知らなかった話で「へ〜、そうなんだ!!」と思ったことがあります。

jp.quora.com

jp.quora.com

そんなわけで、メンターである僕もときどき生徒さんから学ばせてもらっております。ありがたや〜🙏

質を上げるとコストがかかる、でも質は下げたくない、というジレンマ

提出物のレビューをしたりするときは、僕はついつい細かいところまで見てしまいます。

なんかイヤなんですよね。
「え、フィヨルドブートキャンプ出てるんでしょ?あの伊藤さんに教えてもらってるのに、そんなことも習わなかったの?」
みたいなツッコミを就職したあとに受けたりしたらどうしよう、なんて想像しちゃうと。

なので、「僕の中では最低限これぐらいはできてほしい」というハードルがあって、そこをクリアできていないと、ついついツッコミを入れてしまいます。

ただ、そうするとすごく時間がかかります。
僕はメンター業にかける時間を毎日30分から1時間ぐらいに制限しているので、1人か2人ぶんの提出物をレビューするとその日はそれで終わり、ということが多々あります。

ビジネスの観点から言えば、もうちょっと1人あたりのレビュー時間を短く抑えて数をこなした方がいいんでしょうけど、性格上なかなかそれができません😅
他のメンターも僕と同じような悩みを抱えているようです。

今のところは駒形さんと町田さんからは「今のペースでも大丈夫です」と言われているので、とりあえず質重視で提出物のレビューをしています。
いやー、でもなかなか悩ましい問題ですね、これは。

本当に900時間いるの?問題

フィヨルドブートキャンプでは「プラス戦力として就職できるエンジニア」を目指します。
「プラス戦力」と「マイナス戦力」の定義は駒形さんのブログで説明されています。

「多少の教育コストはかかるけど、レビューをしっかりやればトータルで見れば助かる」
このレベルがプラス戦力です。

「Railsのコードは書かせられないけどテスト仕様書を書いててもらおう」
こんな工夫が必要な場合、マイナス戦力です 😅

Railsエンジニアとして就職できるレベルとは - komagataのブログ

そして卒業生が「プラス戦力」となるために、かなりしっかりとしたプラクティスを用意しています。
全プラクティスを修了するためには、人によって大きく前後することはあるものの、一つの目安として「900時間ぐらいの学習時間が必要」と言われています。

Q. 学習を終えるのにどれくらいの時間がかかりますか?
A. かかる時間は人それぞれですが、プログラム経験が全くない人の場合、大体900時間弱の時間がかかります。

FAQ | FJORD BOOT CAMP(フィヨルドブートキャンプ)

生徒さんの中には学習時間が1000時間を超えている人もよく見かけます。

入念にしっかり学習するので、カリキュラムをすべて修了した生徒さんはプラス戦力になりますし、就職先も決まりやすいです。

ですが、もう少し短い時間でプラス戦力になれる方法はないかな〜と漠然と思ったりします。
全プラクティスを完走するまでめちゃくちゃ時間がかかるし、カリキュラムもそれなりにハードなので、それが途中退会してしまう一因になってるんじゃないかな〜、なんて思ったりもしますし。

「1ヶ月でエンジニア転職!」みたいな話は極端ですが、短すぎる「1ヶ月」と長すぎる「900時間」の間に、「もうちょっと効率よく○○時間でプラス戦力になれる勉強方法」が隠れているのでは?ということを考えたりします。
が、具体的な方法についてはまだノーアイデアです・・・😣

関東圏以外の就職先が見つかりにくい問題

フィヨルドブートキャンプはRailsエンジニアを育成しているので、就職先もRailsを使っている企業さんが中心になります。
ただ、Railsを使っている企業さんはやっぱり東京が中心です。
ですので、関東圏に住んでいる人とそれ以外の人を比べると、やはり就職のしやすさが変わってくる感は否めません。(僕も兵庫県に住んでいるので、その問題は肌で良く感じています)

もちろん非関東圏の就職先が皆無というわけではないですし、最近は最初からリモートで就職してしまう人もいます。リモート就職であれば住んでいる地域は関係なくなります。

格差がゼロになることはないかもしれませんが、そういった努力や工夫でその差が少なくなっていくといいなあ、と思っています。

改善のアイデアはたくさん出てくるけど、時間が足りない問題

毎月やっているメンターミーティングでふりかえりをすると、たくさんの改善ポイントが見つかります。
メンター全員で「そうだよね、ここがボトルネックだよね、改善したいね」という話はするのですが、いかんせんメンターも限られた時間の中でメンター業をやっているので、出てきたアイデアを実行に移す時間がなかなか取れません。

費用対効果の高そうな施策は優先順位を上げて取り組んでいるので、日々ちょっとずつは改善していってるのですが、それでもまだまだ時間が足りないと感じています。

とはいえ、「あれもやりたい、これもやりたい」と言ってるだけではいくら時間があっても足りないので、メンター内では「あえて、やらないことを決めていくのも大事なことなのでは」という意見もあります。
これもたしかにそのとおりなので、限られたリソースをうまく使う方法を日々考える必要があるよなーと思っています。

まとめ:フィヨルドブートキャンプはスクールというよりコミュニティっぽい

というわけで、このエントリでは僕がフィヨルドブートキャンプのメンターとしてやっていることと、感じていることをあれこれまとめてみました。
少しネガティブな感想も混じってはいますが、「ネガティブ=ダメ」というよりも、僕としては「これから改善していけばいいよねー」という気持ちでいます。

ちなみにフィヨルドブートキャンプはいちおう「プログラミングスクールのひとつ」という立ち位置になると思うのですが、実際中に入ってみるとあまりスクールっぽくないんですよね。
講師がいて、生徒がいて、教材があって、テストがあって・・・みたいな学校とはちがって、すごくコミュニティっぽいです。

じゃあ、「コミュニティってなんやねん」と聞かれると説明が難しいのですが、メンターも生徒さんもみんなで仲良くわいわいプログラミングの勉強をする集まり、みたいな感じがします。
id:ksmxxxxxxさんが先日書いてくれたアドベントカレンダーの記事が、うまくコミュニティっぽさを説明してくれている気がするので引用します。

オンラインスクールですが、授業とかレッスンみたいなものはありません。

各自でカリキュラムに取り組んで、わからないことがあればまず自分で調べて、わからなければSlackやオンライン上に質問したりするシステムがあるのでそこで質問してみたり、毎日夕方あたりにDiscordで雑談会を開いているのでそこで質問したりします。

つまり、学習はすべて自習ベースです。講師の方がいて、手取り足取り0から100まで教えてもらうという感じではないです。

(中略)

学習中はもくもくと進めますが、詰まったり、発見があったりするとカジュアルに「〇〇がわからんけど、これってどういうことなんだろう」とか独り言をつぶやいています。
つぶやくことで、メンターさんや他の学習している生徒さんが教えてくれたりなどしてくれます。
図書館に集まって、各自自習してるけど、わからないことあったりしてぼそっと呟くと、一緒に学習してる人が気がついてわかる範囲であれば「ここはねぇ」って感じで教えてくれる…みたいな感じです。

プログラミング学習サービスに参加して100日経過した話 - improve.design

カリキュラムは少しハードですが、メンター陣は優しいですし、生徒さん同士の仲もよいので、このノリや雰囲気が合う人は楽しく勉強できるかもしれません。
最初の3日間は無料でお試しできるので、興味を持った方はちょっと様子を覗いてみてください。

bootcamp.fjord.jp

って最後で急にステマっぽくなってしまいましたが(汗)、僕の感想は以上です。
最後まで読んでいただき、どうもありがとうございました!

【アウトライン版】サンプルコードでわかる!Ruby 3.0の主な新機能と変更点

お知らせ

毎年恒例の(?)Rubyの新機能解説記事を公開しました。
型チェックについてまとめたPart 1と、それ以外の新機能についてまとめたPart 2があります。

qiita.com

zenn.dev

お気づきかもしれませんが、Part 2はQiitaではなくZennを使って書きました。
その理由は読者の方が記事に対してお金を振り込めるからです!・・・といっても僕がそのお金を独り占めするわけではありません。
2021年1月31日までに集まったお金はRubyの普及と発展のためにRubyアソシエーションに寄付する予定です。
また、こういった技術記事に対して、どれくらいの人が対価を支払う意思があるのかという、調査・実験の目的も兼ねています。
そんなわけで、上記の記事が良かった、役に立った、と思った人はぜひサポート(対価)の支払いをお願いします🙏

さて、それはそれとして、今回書いた記事はどちらもかなり長いので、このブログではそれぞれの記事の見出しをリストアップしておきます。
記事のアウトラインをざーっと見て面白そう、と思ったら元記事の内容をチェックしてみてください!

Part 1 - Rubyで型チェック!動かして理解するRBS入門

  • はじめに
    • 本記事の情報源
    • 動作確認したRubyのバージョン
    • フィードバックお待ちしています
  • Ruby 3.0の概要(というか、個人的な印象)
    • 後方互換性を窓から投げ捨てるような大きな変化はないが、マニアックな仕様変更がちょこちょこある
    • Rubyの未来を担う新機能が導入された
    • その他の注目ポイント
    • Ruby 2.7.2以上を使っている場合は「見えない警告」に注意!
    • 参考情報:アウトライン版もあります
  • 言語上の変更点
    • キーワード引数とハッシュオブジェクトの自動変換が廃止された(キーワード引数と通常の引数の分離)
    • Procの引数展開の仕様が少し変わった
    • ... 引数を使う際に通常の引数も併用できるようになった
    • case/inを使うパターンマッチングが正式に導入された
    • 1行パターンマッチングの構文がin=>の2種類になった(実験的機能)
    • パターンマッチングにFindパターンが追加された(実験的機能)
    • endlessメソッド定義構文が導入された(実験的機能)
    • frozen-string-literal: trueのマジックコメントが有効なとき、式展開された文字列が凍結されなくなった
    • shareable_constant_valueマジックコメントが導入された(実験的機能)
    • 静的型解析の基盤が導入された(RBS、TypeProf)
    • 非推奨警告がデフォルトで出力されなくなった(Ruby 2.7.2から導入された変更点)
    • $SAFE$KCODEがただのグローバル変数になった
    • メソッド内で特異クラスを定義する際にyieldを呼ぶことが禁止された
    • 親クラスと親モジュールで同じクラス変数を書き換えると実行時エラーが発生するようになった
    • トップレベルでクラス変数を読み書きしようとすると実行時エラーが発生するようになった
    • 変数やメソッド名に_1_2を使うと構文エラーが発生するようになった
  • 後方互換性が失われる変更点
    • 正規表現リテラルで作られた正規表現オブジェクトが凍結されるようになった
    • 範囲オブジェクト(Range)が凍結されるようになった
    • Hash#eachが必ず2要素の配列を渡すようになった
    • pipeが閉じられてSTDOUTに書き込みできない場合に、エラーメッセージが出力されなくなった
    • 定数のTRUE/FALSE/NILが削除された
    • 最適化のためInteger#zero?Numeric#zero?をオーバーライドするようになった
    • Enumerable#grepEnumerable#grep_vに正規表現オブジェクトを渡し、ブロックを使わなかった場合、Regexp.last_match/$~を変更しなくなった
    • open-uriをrequireしても、openメソッドではURLが開けなくなった
  • バックトレース出力に関する変更点
    • バックトレースがRuby 2.4以前の表示順に戻った
  • コマンドラインオプションの変更点
    • ヘルプの表示が1画面ずつ表示されるようになった
    • --backtrace-limitでエラー発生時に表示されるバックトレースの行数を制限できるようになった
  • コアライブラリの変更点
    • ArrayクラスのサブクラスもArray#flattenなどのメソッドが常にArrayクラスのインスタンスを返すようになった
    • Array#[]Enumerator::ArithmeticSequenceを受け取って要素をスライスできるようになった
    • Dir.globDir.[]がデフォルトでソートされた結果を返すようになった
    • HashとENVに指定されたキー以外の要素を返すexceptメソッドが追加された
    • WindowsでENVのキーと値がUTF-8になった
    • WindowsでEncoding.default_externalがUTF-8になった
    • Hash#transform_keysHash#transform_keys!でキーの変換ルールをハッシュで指定できるようになた
    • freeze: falseオプション付きでcloneすると、内部的に呼ばれるinitialize_cloneメソッドにもfreeze: falseオプションが渡されるようになった
    • freeze: trueオプション付きでcloneすると、cloneで得られたオブジェクトも凍結されるようになった
    • Bindingオブジェクト付きでevalを呼んだ場合、__FILE____LINE__が、それぞれ"(eval)"の文字列と、評価される文字列内での行番号を返すようになった
    • 引数1個でBinding#evalを呼び出したときの__FILE____LINE__の出力内容が変わった
    • ブロックリテラルを使わずにラムダでないprocオブジェクトをlambdaメソッドに渡すと警告が出るようになった
    • モジュールAにモジュールBをあとからinclude/prependした場合も、すでにモジュールAをincludeしているクラスにモジュールBの内容が反映されるようになった
    • public, protected, private, public_class_method, private_class_methodが引数としてメソッド名を列挙した配列を受け取れるようになった
    • attr_accessor, attr_reader, attr_writer, attrが戻り値として定義されたメソッドのシンボルの配列を返すようになった
    • alias_methodが戻り値として定義されたエイリアスメソッドのシンボルを返すようになった
    • Procクラスに==eql?メソッドが実装された
    • 並行・並列処理プログラミングをサポートする新しいライブラリ、Ractorが追加された(実験的機能)
    • Random::DEFAULTがRandomクラスオブジェクトを返すようになり、なおかつ警告対象となった
    • StringクラスのサブクラスもString#upcaseなどのメソッドが常にStringクラスのインスタンスを返すようになった
    • Symbol#to_procがラムダのProcを返すようになった
    • 凍結された文字列を返すSymbol#nameメソッドが追加された
    • Warning#warncategoryオプション付きで呼ばれるようになった
  • 標準ライブラリの主な変更点
    • OpenStructが遅延初期化されなくなった
    • OpenStructのpublicなビルトインメソッドが!付きで呼び出せるようになった
    • OpenStructのYAMLサポートが改善された
    • OpenStructはなるべく使わない方がよい、という公式見解が出された
    • SortedSetクラスがsetライブラリから削除された
    • 要素を連結して文字列を返すSet#joinが実装された
    • Set同士の大小を比較する<=>演算子が追加された
  • その他
    • ruby2_keywordsを使った場合の空のハッシュを引数に渡したときの挙動が変わった
    • 初期化されていないインスタンス変数にアクセスしても警告が出なくなった
    • マルチスレッド関連/GC関連の変更点(見出しのみ)
    • その他の細かい変更点
  • まとめ
    • お願い:サポート(対価の支払い)をぜひお願いします!

zenn.dev

まとめ

Ruby 3.0は便利な新機能の追加よりも、重箱の隅をつつくような言語仕様の変更が多かったので、NEWS.mdの説明やissueを読んでもぱっと理解できず、何がどう変わったのか、なぜその変更が必要だったのか、といった点を把握するのにとても時間がかかりました。

それだけにプログラミング言語のあるべき仕様を考え、それを実装する大変さをネット越しに感じたので、それが記事の収益を寄付しようと思った大きな理由のひとつになります。

そんなわけで、Rubyコミッタのみなさんに感謝しつつ、僕の書いた記事も参考にしつつ、まもなくやってくるRuby 3.0時代を一緒に楽しみましょう〜😄