こんにちは、現役沖縄フリーランスエンジニアのmah（MaLanka）です。
このブログでは、
僕がIT未経験から約1年でフリーランスエンジニアになるまでの過程、
ノウハウなどを書いていきます。
今回は、
- 【2023年1月最新】バグが多い駆け出しエンジニアの特徴【だから未経験は消える】
について書いていきます。
バグが多い実務未経験の駆け出しエンジニアのみなさんは、
こんな悩みや不安を持っていませんか？
「実務未経験から駆け出しエンジニアとして働いているけど、よくバグが多いと指摘される...」
「駆け出しエンジニアでバグが多い人ってどんな人？反面教師にしてIT業界から消えないようにしたい...」
「バグが多過ぎて上司から「もはやお前が一番のバグだ！未経験バグ生産型エンジニアめ！」とか言われた...もう消えるしか無いのかな...」
といった感じ。
最近、
プログラミングの勉強をする駆け出しエンジニアの人が増えましたが、
駆け出しの頃ってバグ多いですよね...笑
（そんなことないですかね笑）
自分はよく、
自分の作ったポートフォリオやWEBアプリのバグが多過ぎてなかなか潰しきれず、
イライラしてました（笑）
（1つ直したらまた別のバグが3つくらい出てくるw あるあるですよね）
実務においても、
じっくり時間がある時ならまだしも、
時間の取れないカッツカツのスケジュールで設計やら実装していくので、
どうしてもバグが多くなりがち。
自分はプログラミングの勉強を始めてからは約3年、
実務経験は2年半ほどですが、
どちらかというとバグが多い方だと思います笑
（たとえ実装が早くできたように見えてもバグが多かったら台無しです笑）
しかし幸い、
僕はフリーランスエンジニアになってから、
「バグが多過ぎてクビを切られた」みたいなことはないです。
（小さいミスは腐るほどありましたが...笑）
ですが、
あまりにバグが多いと、
フリーランスエンジニアならクビを切られて案件が無くなったり、
駆け出しエンジニアの方だと、
せっかく実務未経験で入れた会社から消えることになる可能性は十分あります。
なので今回は、
僕がよくやりがちなミスを、
「【あるある】バグが多い駆け出しエンジニアの特徴」として紹介します。
みなさんは僕を反面教師にして、
「バグの多い駆け出しエンジニアあるある」を踏まないように成長していってくださいね！
【2023年1月最新】バグが多い駆け出しエンジニアの特徴【だから未経験は消える】
- 【2023年1月最新】バグが多い駆け出しエンジニアの特徴【だから未経験は消える】
- 駆け出しエンジニアのバグに対するリアルな意見
- RSpecをしっかり書いてバグを減らしたい方へ
- RailsやRubyを学びたい人へ
- まとめ
- あわせて読みたい
1. テストケースの洗い出しが足りない
バグが多い駆け出しエンジニアの特徴、
1つ目は「テストケースの洗い出しが足りない」です。
時間がない中で設計や実装をしてると、
考慮漏れって絶対あるんですよね...
どうしても、
「あ、このパターン考慮してなかったわ...」
という状況が発生します。
どれだけ洗い出ししても、
動かしてから気づくことはあるので多少は仕方ないですが、
「明らかに事前に発見できたバグ」はテストケースをきっちり洗い出して防ぎたいものです。
2. テストコードを書かない
バグが多い駆け出しエンジニアの特徴、
2つ目は「テストコードを書かない」です。
駆け出しエンジニアとして最初の方に作った自分のWEBアプリは、
バグの温床でひどい感じでした笑
「1つバグを直したら別のバグが3つ出てくる」
みたいな感じです笑
（駆け出しエンジニアあるあるですよね）
しかし、
これはテストコードを書いていくと大分マシになりました。
自分は、
実務未経験から入った最初のRails
の受託開発企業が、
「RSpec
をしっかり書きましょう」という現場で、
テストコードの大事さを最初に叩き込んでもらうことができたので本当に感謝です。
その分、
「RSpec」も半分一つの言語みたいな感じで、
最初は覚えることも書く量も多くて大変でしたが...
（3000行のテストファイルを3つ書かないといけない時は泣きました笑）
最初の段階で、
細かくテストコードを書くという習慣が身についてよかったです。
逆に細かく書きすぎて、
フリーランスになってからは「「RSpec」のE2Eテストが重くなるので、細かすぎるテストは削除して欲しい」
と言われることもありました笑
もちろん、
テストコードで全部の機能をカバーできるというわけではないので、
100%手放しで安心ではありませんが、
あって困ることはありません。
何か修正するたびに全部手で動作確認してたら、
いくら時間あっても足りないですし漏れが出ますからね。
なので、
「普段テストコードを書かない...」
「RSpecは聞いたことあるけど勉強してない...」
という方はぜひ、
「Udemy
」などのオンライン教材で学習してみてください。
もしRailsをやっている方は「「RSpec」」を学習すると良いです。
「「RSpec」」を身につけていると、
駆け出しエンジニアの就職やフリーランス案件の面談でも高評価に繋がりますのでぜひ。
（というか逆に「「RSpec」」の経験が無いとキツい案件もあります）
3. 仕様を理解していない
3つ目は、
「仕様を理解していない」です。
大抵の場合は途中からプロジェクトにジョインするので、
仕様のキャッチアップが必要ですが、
これ結構大変ですよね...
リリース前のサービスや立ち上がったばかりの新規サービスならまだしも、
巨大なプロジェクトや古くから動いているプロジェクトだとなおのこと。
自分が実務未経験から半年で入った会社は、
4、5年稼働しているプロジェクトで、
しかもかなり巨大でした。
そのため、
「数行の修正でもバグ原因になったりしないかな...？」
といつもヒヤヒヤしていました笑
目先のコードだけパッと修正しても、
仕様を理解していないと全体を動かした時にあっさりバグになってしまうので、
ジョインしたばかりの時期は要注意。
周りの人に「細かすぎるくらいしつこく仕様の確認」をして、
バグを出さないようにしてくださいね。
（疑問に思ったら即確認です）
4. そもそも動作確認をしていない
4つ目は、
「そもそも動作確認をしていない」です。
これはひどいですねw
（駆け出しエンジニアなら一発で消える案件じゃないでしょうか笑）
僕自身は流石にないですが、
フリーランスになってからの現場で、
「エンジニアが全く目視での動作確認しておらず、本番環境でエラーが出てサービス運営に支障が出た」という事象がありました。
（怖過ぎ...笑）
そのエンジニア曰く、
「自動テストが通っていたから目視での動作確認をしなかった」
ということらしいですがこれはヤバいですよね。
「自動テストがパスしているから」云々の話ではなく、
自分がコードを修正した範囲の動作確認は最低限やりましょう。
（流石に論外です）
5. 何かを修正したらその部分だけをテストしている（デグレード）
5つ目は、
「何かを修正したらその部分だけをテストしている」です。
いわゆる「デグレード（品質低下のトラブル事象）」ですね。
これもかなりあるあるネタ。
「修正箇所ばかりに気を取られて、関連する別の場所が動かなくなった...」
「全く関係ないと思っていた機能がなぜか動かなくなった...」
「修正箇所をリリースしてから、お客さんから〇〇〇が動いていないと連絡があった...」
みたいな感じ。
デグレードってげんなりしますし、
それがリリース直前とかに発覚すると本当に消えたくなります笑
（エンジニアなら誰もが経験ありますよね笑）
ここで、
2で述べたテストコードが大事になってくるんですよね。
もし、
テストコードがなくてエクセルのチェックシートでテストしていると、
デグレを修正したらまた最初から一からテストしないといけないし、
そのテストの際にも漏れが発生する可能性もあります。
（「大丈夫だろー」って感じで適当に早く終わらせたくなるからです）
なので、
修正箇所ばかりに気を取られず全体をくまなくテストしつつ、
「テストコード」をしっかり書いてデグレードを防止しましょう。
「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)」という、
全エンジニア必読の技術書で「バグの少ないコードの書き方」を学ぶのもおすすめです。
6. 勉強時間が足りない
6つ目は、
「勉強時間が足りない」です。
自分が思うに、
勉強時間が足りない駆け出しエンジニアの人は下記のような状態なのだと思います。
「忙しいを言い訳にして、プログラミングの勉強時間を確保しようとしていない」
「一日何時間プログラミングの学習時間を取ればいいのかばかり気にして、全然勉強していない」
「心のどこかでプログラミングは時間の無駄だと思っている」
といった感じ。
みなさんも思い当たるところはありませんか？
僕から言わせると、
駆け出しエンジニアでプログラミングの勉強時間が少ないのは、
はっきり言って論外です。
（勉強しないならもう消えるしかないとさえ言えます）
知識も経験もないのだから、
やる気や勉強時間を使っていくしかないです。
それに、
駆け出しエンジニアではなくなっても、
プログラマーとして働いている限り「一生勉強」です。
（どんな業界もそうですね）
もし、
「プログラミングの勉強時間を確保するのがすでに辛い...」
という方は、
未経験からプログラミング転職することをやめた方がよいかも知れませんね。
7. Twitterに気を取られている
バグが多い駆け出しエンジニアの特徴、
7つ目は「Twitterに気を取られている」です。
これは論外ですねw
「フォロワー数減ってないか気になってテストが手に付かない...」
みたいなね笑
（でも今の時代かなり多そう...笑）
SNSには中毒性があるので、
「集中したい時には絶対やっちゃいけないこと」だと思うんですよね。
自分は実際、
プログラミング学習を始めて１年でフリーランスのエンジニアになる少し後までは、
Twitterを封印していました。
（ノイズばかりで邪魔なだけですからね）
毎日与沢さんの動画や音声、
コンサルタントの「石原明先生」の本やポッドキャストで極上の情報を頭に叩き込んでいたので、
「わざわざノイズの多いTwitterから情報を得る」という選択肢がありませんでした。
Twitterを頑張って影響力をつけるのも良いですが、
そもそも本業のプログラミングでバグまみれな状態だと、
「かなりイタい奴認定」なので注意してくださいね笑
駆け出しエンジニアのバグに対するリアルな意見
ここで、
駆け出しエンジニアのバグに対するリアルな意見をご紹介します。
肯定派の意見と否定派の意見がありますが、
どちらも非常に納得できる意見なのでぜひ参考にしてみてください。
1. 駆け出しエンジニアは流行を追うよりバグ修正やテストなど、目の前の仕事を丁寧にやるべき
【駆け出しエンジニアは目の前の仕事を丁寧にやるべき】
流行りの技術追い求めて足元ガタガタエンジニアより、
地味だけども、
✅ 目の前のバグ修正
✅ 目の前のテスト
こういう小さな事をきっちり丁寧にやれるエンジニアの方が重宝されますね。
#駆け出しエンジニアと繋がりたい #プログラミング
https://twitter.com/RailsRubyMah6h/status/1234086252581965825?s=20
2. 自分が書くコードの向こう側にいるのはお客さん
【コードの向こう側にいるのはお客さん】
自分が書いているコード、それを使うのはお客さんです。
自分の書いたコードで楽しい気持ちになるかも知れないし、バグってクレームになるかもしれない。
#駆け出しエンジニア #駆け出しエンジニアと繋がりたい #プログラミング
https://twitter.com/RailsRubyMah6h/status/1220652785013678080?s=20
3. バグが出たら一旦視点を外して散歩すること
バグが発生してどうしても抜け出せない時、駆け出しエンジニアが問題の起こっているコードを見て永遠に頭を抱える一方で、ベテランエンジニアは正常に動いている類似コードを見て差分を探しにいきます。
ハマってる時こそ問題の箇所から視点を離すことが大事。
もっというなら一旦散歩するのが大事。
https://twitter.com/okaeri_ryoma/status/1359117098916540418?s=20
4. お願いだからグダグダ言わずにリーダブルコードを読んで！
駆け出しエンジニアの皆さんには、是非リーダブルコードを読んでみてほしいです！
読みやすいコードは、
✅ バグを減る
✅ 改修がしやすい
✅ 説明コストが減る
等メリット沢山なので、是非読みやすく書けるようにしましょう！ #駆け出しエンジニアと繋がりたい #プログラミング初心者
https://twitter.com/takanobu1993/status/1328987326232489984?s=20
RSpecをしっかり書いてバグを減らしたい方へ
「「RSpec」」をしっかり書いてバグを減らしたい方は、
Udemy
で下記のコースを受講すると良いです★
また、
Udemy
は定期的にセールをやっていますし（90%OFFとかもザラ）、
「30日間なら返金できる」ので、
満足できなかった時でも安心です。
【公式】RailsHack(レイルズハック)
【公式】Udemyで学んでみる
RailsやRubyを学びたい人へ
RailsやRubyを学びたい人は、
RailsHack(レイルズハック)という、
最近できた新しいプログラミングスクール（今なら通常価格69,800円が、早期割で29,800円！）か、
Udemy
で下記のコースを受講すると良いです★
✅1. フルスタックエンジニアが教える 即戦力Railsエンジニア養成講座
✅2. 【はむ式】ハンズオンで学ぶRuby on Rails 6【Dockerにも触れられる】
<- おすすめ。ハムさんはReactやTypeScriptの教材も非常に丁寧。
✅3. はじめてのRuby on Rails入門-RubyとRailsを基礎から学びWebアプリケーションをネットに公開しよう
また、
Udemy
は定期的にセールをやっていますし（90%OFFとかもザラ）、
「30日間なら返金できる」ので、
満足できなかった時でも安心です。
【公式】RailsHack(レイルズハック)
【公式】Udemyで学んでみる
まとめ
- 【あるある】バグが多い駆け出しエンジニアの特徴【だから未経験は消える】
をまとめます。
✅ 1. テストケースの洗い出しが足りない ✅ 2. テストコードを書かない ✅ 3. 仕様を理解していない ✅ 4. そもそも動作確認をしていない ✅ 5. 何かを修正したらその部分だけをテストしている ✅ 6. 勉強時間が足りない ✅ 7. Twitterに気を取られている
以上です。
「「RSpec」」をしっかり書いてバグを減らしたい方は、
Udemy
で「「Testing Ruby with RSpec: The Complete Guide」」を受講しましょう★
「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)」という、
全エンジニア必読の技術書で「バグの少ないコードの書き方」を学ぶのもおすすめです。
あわせて読みたい
プログラミング学習で挫折しないために知っておくべき８つのコト【まとめ記事】 - スリ飯屋MaLankaのフリーエンジニアな日々
【厳しい現実】プログラミングの朝活が続かない駆け出しエンジニアの特徴 - スリ飯屋MaLankaのフリーエンジニアな日々
【40代、50代】もう遅い？中高年が今からプログラミングを始めても間に合う？【プログラマーなった人はいるのか？】 - スリ飯屋MaLankaのフリーエンジニアな日々
【マジやめとけ！】駆け出しエンジニアがブログを書くメリット、デメリットは？ - スリ飯屋MaLankaのフリーエンジニアな日々
【６つの理由】フリーランスエンジニアになる夢に挫折する駆け出しエンジニアの特徴 - スリ飯屋MaLankaのフリーエンジニアな日々
