おはよう。
今日は実務でしか学べないことというテーマで書いていく。
イントロダクション
近年、エンジニアという職業は「フリーランス」という働き方が推奨され、
YouTubeでもエンジニアがフリーランスになることを促進させるような広告が流されるほどに浸透してきているようだ。
しかし、そんなフリーランスエンジニアという働き方が注目される中でも、やはり「実務未経験」という場合では任される案件の範囲がとても限られてしまう。
そうでもなるとやはり最低でも1年は何処かしらの企業で会社員としてエンジニアになる必要がある。
かく言う私も1年前にプログラミングスクールに通っていた頃は、「別に実務経験なんていらねーだろw 俺は優秀だから実務未経験でも行けるわ！」と舐めたことを言っていたのだが、
実際に会社員エンジニアとして働き始めてみると「やっぱり実務経験って必要だわぁ、、」と思うことが多々ある。
今日はそんな1年前の私のように「別にプログラミングスクールで勉強すればフリーランスになるの余裕でしょw」と思っている方に向けて
「実務でしか学べないこと」というテーマで書いていく。
将来的にフリーランスエンジニアとして活動することを目標にしている方はぜひ最後まで読んでいただきたい。
実務でしか学べないこと
この3つがプログラミングスクールや独学では絶対に学べないところだろう。
先にこの3つの共通点を挙げておくと、これらのことは「自分以外のエンジニア（開発者）とまとまった数のユーザー」が居ないと学ぶことはできない。
これがフリーランスエンジニアになる際に必要とされる「実務経験」ということでもあるだろう。
それではこれらのことについて1つずつ、私の実務での体験なども含めて書いていく。
Slackで行う進捗管理
まずはSlackで行う進捗管理である。
Slackのこれらの機能を使うことは何ら問題もない。
しかし、実際に私の会社では基本的なソースコード管理は後述するGitHubでおこなっているのだが、
1つの作業が終わり、次の作業に移る時に上司からの指示は必ずこのSlackを通してくる。
仮にSlackが使えなければ、テストコードの修正やデバッグの箇所を説明するのに毎回会議室に足を運んで指示を受けることになる。
これほどまでに馬鹿馬鹿しいことはない。
ならば、やはり最低限のSlackの機能は把握しておくべきだろう。
実際に私も現在の会社に未経験から入社したが、「Slackを使えることが前提」で現場に放り込まれるから
私もSlack完全無知で入社して最初は使い方に手こずった。
やはりSlackの使い方に学習時間を割くというのも何だか馬鹿馬鹿しいので、現場で作業をしていくうちに自然とSlackでチャットを行えるようになるのがベストだろう。
些細なことではあるが、そんな意味合いも込めて「Slackの進捗管理」を実務でしか学べないことに入れた。
GitHubでのチーム開発の手法
このGitHubを用いた様々な作業は会社規模でしか行えないはずだ。
特に私が入社してGitHubを使い始めて訳のわからなかった機能は「プルリクエスト」だ。
現場で上司に「プルリクエスト送っておいて！」と言われた時にサルでもわかるGit入門～プルリクエストとは～を読んだが、私の知能はサル以下だったようで、全く理解できなかった。
しかし、実際にやってみて上司からフィードバックをもらうことでようやく何のためにやっていることなのかできて、サルでもわかるGit入門～プルリクエストとは～
に書いてあった文章の意味も理解できるようになったのだ。
要するに、これらもSlackと同じく「使えることが前提」で現場に放り込まれるものだから、最初は訳がわからなくてもとりあえず雰囲気でやってみるしかない。
そのためにもまずは責任範囲の小さい作業のうちにGitHubの使い方についても実際に使って学んでいくべきだろう。
無論、私も会社で最初に与えられた簡単な課題の際にプルリクエストを使わせてもらったから今では問題なく使えるようになった。
やはりそういった面から見ても実務経験を積む期間というのは侮れない。
ソフトウェアアーキテクチャ
最後はソフトウェアのアーキテクチャについてだ。
最後はソフトウェアアーキテクチャについてだ。
少々これまでのツールを使うということとは違って、概念的なものになるが、
これらを簡単に言えば、「どこのクラスにどのようなメソッドを書くか」などのことだ。
「、、、、？」となる気持ちも分かる。
そう、これこそが実務で体験しなければ意味がわからずに死ぬ最大の部分である。
心して聞いてほしい。
それでは実際の業務の話をすればもう少しイメージが湧くだろう。
私の場合は、自社で開発したネイティブアプリの「エラーメッセージの表示」を任された。
しかし、このアプリはAppStoreやGooglePlayにすでにリリースされており、実際にユーザーも使っている状態であった。
なのでユーザーが不正な入力（ユーザー登録時にユーザー名が空白の状態など）をした際に普通にエラーメッセージは表示されていたのだ。
そこで私は上司がふざけてるのかと思い、「いや、もうエラーメッセージ表示されてますけどww」と言ったところ、
「これはクライアントサイド（iOSやAndroid）が仮のものを出してくれているだけ」という返答がされた。
益々『？？？』となったのだが、実際に作業をやってみると、Rails側では本来では一般的にされているであろう「バリデーション」が全くもって記述されていなかったのだ。
そこで私はまず初めにコントローラーレベルで例外処理を記述し、動作を確認したのちに今度はそれらの処理をモデルのバリデーションに記述した。
ここまでの話を聞いて訳がわからなかっただろう？
私も未だにソフトウェアアーキテクチャに関して訳のわからない部分が多々存在する。
そう、これこそが実務で必要なソフトウェア開発の一番頭を悩ませる部分の「ソフトウェアアーキテクチャ」なのだ。
確かにデザインパターンなどの本も紹介されており、自己学習は可能であるが、この部分は実際にアプリケーションを使うユーザーがいないと検証しようがない部分などもある。
是非ともこの文章を読んでもピンとこなかった方は、実際に入社された会社でソフトウェアアーキテクチャについて頭を悩ませてみてほしい。
まとめ
この3つが実務でしか学べないことだ。
これを読んでみて「そんなこと知らなかった、、」という方は未経験からフリーランスになる前に会社員エンジニアになることも検討してみるといいだろう。
だがどちらにせよ、独立することを目標にして取り組むことは良いことだ。
私も1日でも早くフリーのエンジニアとして活動するのに申し分のない技術力を身に付けるべく、今日も須く学習をしていく。
皆さんも目標に向かって頑張っていこう！
ここまで読んでくれてありがとう！
