目次
技術飽和時代の生き方
こんにちは。
次から次へと,新しいライブラリやフレームワーク,ひいては,開発言語までが誕生するという,技術飽和時代にある IT 業界。
最先端の技術を使いこなせることは,一つの強みになりますが,流行にキャッチアップすることをストイックに続けていくアプローチだと,(学習コストに対する)費用対効果の面では,あまり望ましいと言えない状況になります。
特に,フレームワークが洗練されてきた今日では,開発ハードルは年々下降傾向にあり,新人であっても(特に専門知識があってそうしたわけでもないのに)セキュアな構造のプロダクトが生み出せるようになっています。
習得した技術の「量」よりも,「質」が問われるトレンドがますます強くなっていくのではないか?
本記事は,エンジニアの好奇心や向学心としての,新規技術を学ぶ姿勢を否定するものではありませんが,あえて刺激的なタイトルを使って,現実的な議論をしたいと思います。
習慣① 積極的にバグを出す(できれば全種類制覇!?)
未経験分野のチュートリアル教材をこなすと,最初は,誰だってバグから学んでいくものです。
必要最低限の CRUD アプリが作れる段階まで上達すると,「ベタープラクティス」が蓄積され,バグを避ける知恵が身につき,安全性の高いロジックを追求しがちです。
ある時点を境に,バグから学ぶことを,無意識のうちに,やめてしまっていませんか?
あえて,多種類のバグ(例:全種類のエラーコード)を意図的に再現させてみる訓練は,その開発言語や,フレームワークの思想を,いっそう深いレベルで理解するために,格好のトレーニング材料となります。
バグを出したことがないエンジニア(そんな人いないと思いますが……)より,全種類のバグの出し方を知っているエンジニアの方が,問題の切り分けスピードも確実に高速化するのではないかと思います。
習慣② チュートリアルでは「消す」
チュートリアルの良くある構成は,基礎から応用へと,レベル順にストーリが進むというもの。
前章で仕上げた画面(例:一覧画面)に,機能追加(例:ページネーション)を追加する,みたいな。
教育的配慮では,優れていると言えますが,技術の本質は,機能追加するよりも,機能削除することで見える場合が多いと思います。
チュートリアルで学ぶ際は,与えられた作業手順通りに組んでみるのも一案ですが,あえて,チュートリアルでは説明されていないようなパターン(一部のコードやオプションを,わざと消して,変化を観察する)をいろいろ試すことで,本質への理解が,一気に加速します。
ステップアップする方向でカリキュラムが組まれているチュートリアル教材で,あえて逆方向という発想を持つことは,意外とできている人は少ないので,それだけでも差をつけられます。
習慣③ 炎上案件でリファクタリングしてみる
めでたくチュートリアルを卒業後,スクラッチでプロダクト開発するような実務体験ができれば,理想的ではあります。
それでも,本当の「ベタープラクティス」や「ベストプラクティス」って,山のようにアンチパターンのコードと遭遇して,(できれば)それをリファクタリングしてみることで,ようやくストンと腑に落ちる,という側面もあります。
人間,大変な目にあったり,苦労をすれば,それは一生忘れない経験になりますし,「こんなトラブル,二度と遭遇したくない」と感じれば,必死に知恵をしぼるようになるものです。
あまり負荷を高めると,メンタル的に病んでしまいますが,炎上案件を志願し,アンチパターンを反面教師として知見を深めることも,一つの成長加速オプション。
自分の失敗から学べることは限られているので,他人の失敗から学ぶということは,本当に効果的です。
同じ学習時間なら,技術習得は,同族よりもジャンル越えを
本記事で紹介したようなアプローチで,「せまく・深く」技術を追求した後は,同じ思想(例:MVC ストラクチャ)に基づく技術は,驚くほどスイスイ理解できるようになっていることに気づくでしょう。
そして,同ジャンルの技術(例:バックエンドのフレームワーク複数種類)ばかりを勉強するよりは,あえて,異ジャンルの技術(例:バックエンドのフレームワーク,フロントエンドのフレームワーク)の習得を目指すほうが,同じ学習時間でも,エンジニアとしての伸びしろが大きく残っており,コスパの良い投資と言えます。
技術バリバリなわけでもない,しがない社内 SE のおじさんですが,技術飽和時代を生きるエンジニアとして日々感じているアイデアを,赤裸々と語らせていただいました。