はじめに:「僕にもそんな頃があった」
先日、西脇.rb&神戸.rbの合同勉強会として「RailsプログラマのためのSQL勉強会」を開催しました。
この勉強会は出題者(=僕)が出したSQL問題を他の参加者が解く、というスタイルの勉強会です。
参加者の方の中には最近プログラミングを始めた、という人も何人かいました。
そういう人にとっては問題がちょっと難しかったので、ときどき僕がサポートに回って質問に答えたり、解き方をある程度教えたりしていました。
また、話がちょっと脱線して「僕が作ったこれぐらいのWebアプリは、伊藤さんなら何時間ぐらいで作れますか?」みたいな質問を受けたりもしました。
その中で言われたのが、
「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」
「えっ、そんな短い時間で作れるんですか」
といったようなコメントです。
そういったコメントを聞くと、「あー、僕にもそんな頃があったわ」と昔の思い出がよみがえってきました。
何年かしたら、質問をしてきた初心者さんが「xxさん、すごいですね」と言われる側に回ってほしいな~と思うんですが、そうなるためにはどうしたらよいでしょうか?
自分の経験をふまえていろいろ考えてみたので、今回はそんな話を書いてみます。
もくじ
ちょっと長いので、先に目次を載せておきます。
それでは以下が本編です。
「xxさん、すごい」という心理は相対的
まず、質問をしてきた初心者さんから見ると、おそらく僕は「伊藤さんってすごい」と思われてるんじゃないかなーと思います。
ですが、どの世界にも上には上がいるもので、僕自身も「xxさんってすごい。どうやったらあのレベルになれるんだ」と思うような人がたくさんいます。
僕は初心者さんよりも積み重ねてきた経験や書いてきたコードの量が多いですし、僕が「すごい」と思ってる人は僕よりもさらに積み重ねてきた経験や書いてきたコード量が多いのでしょう。
まあ、世の中そんなものです。
誰かが誰かに憧れてしまう(ときにはすごすぎて絶望してしまう)のは当然ですし、「すごい人」も最初からすごいんじゃなくて、その人ががんばってきた結果そうなってるんだと思います。
何が言いたいのかというと、「伊藤さんってすごい」って思うかもしれないけど、努力次第で何とかなるからあなたも頑張って、ということです。
プログラマとしてスキルを上げるための前提条件
プログラマとしてスキルを上げるためには、そもそもの前提条件がある気がします。
それは「技術が大好きで、楽しんで学べること」です。
それを判断する方法のひとつは「プライベートの時間やお金をつぎ込んでもストレスにならないか?」と自問することです。
答えがYESなら大丈夫でしょう。
もし「プライベートの時間に仕事のことなんて考えたくない」「本を買ったりするのはお金がもったいない」と考えてしまうのであれば、その人はなかなか成長できないと思います。
別にこれは「プライベートの時間とお金を使って勉強しろ」と言いたいのではなく、主体的な学習意欲があるかどうかを確認するための質問です。
学習意欲があればどんどん成長するし、なければなかなか成長できません。
これも当たり前の話ですよね。
僕が技術好きになったきっかけ
技術が好きになるきっかけは人それぞれだと思います。
ちなみに、僕の場合は簡単にいうと「現場でたくさんの天国と地獄を見てきたから」です。
つまり、
「なんて読みやすくて作りやすいコードなんだ!すばらしい!!(歓喜)」
という経験と、
「なんというヒドいコードだ。。。超読みにくいし、ちょっとした改造もひと苦労だ(怒り)」
という経験をたくさんしてきたのが大きいと思います。
どうせ仕事をするならラクに楽しく仕事したいので、作りやすさや開発効率の良さを徹底追求しようと考えていろんな勉強を始めました。
「今まではこんなに苦労しながら作ってきたけど、実はこんなショートカットがあったのか!」という発見をするのが大好きなので、僕は楽しんで技術を学べています。
成長するための方法あれこれ
さて、ここからは初心者さんから熟練者に成長するための具体的な方法をあれこれ考えてみましょう。
独学でコードを書きまくる
コードをたくさん書くことは非常に良いことです。
自分の頭で考え、壁にぶつかり、問題を解決すれば、確実に自分の血肉となってくれます。
一方で、時間は非常にかかるので効率はあまりよくないかもしれません。
また、完全独学だと間違った方法に進んで変なクセが付く恐れもあるので、注意が必要です。
技術書を読む
技術書には著者が長年かけて習得した知識や経験が詰め込まれています。
本を読めば、その知識と経験を少しのお金と少しの時間で吸収することができます。
また、体系的な知識を身につける場合にも技術書は最適です。
一方、本を読んだだけでいきなり「できる人」にはなれません。
特に、わかりやすい本を読むと分かった気になってしまい、「これならできる気がする」と思ってしまいがちですが、たいていは勘違いです。
自分の手と頭を動かす「実践」をしないと、自分のスキルになってくれません。
勉強会に参加する
セミナー形式(登壇者とオーディエンスに分かれる形式)の勉強会は技術書を読む場合と似ています。
登壇者の知識や経験を効率よく吸収できますが、話を聞くだけでは自分のスキルにはなりません。
一方、少人数で特定のテーマについてディスカッションしたり、自分でコードを書く時間が用意されたりするタイプの勉強会であれば、自分のスキルになりやすいでしょう。
何度も繰り返していますが、スキルを習得するためには自分の手と頭を動かすことが重要です。
勉強会や懇親会に参加すれば人脈が広がりやすいです。
また、有名な技術者やスキルの高い人とお話ししたり、気になっていることを質問したりすることもできます。
自分のスキル向上には直結しないかもしれませんが、自分のモチベーションをアップさせるのに役立ったりするので、間接的な効果は期待できます。
ただし、自分の希望する勉強会が近くで開催されるとは限りません。
それに、初対面でいきなり登壇者に話しかけたり、他の参加者とおしゃべりしたりするのは結構勇気がいります。
とはいえ、思い切ってトライしてみれば意外となんとかなったりするものです。
現場に潜り込む
「現場に潜り込む=就職する(学生の人はインターン?)」ですね。
未経験者でも何とか採用してもらえれば、お金をもらいながら(!)技術の勉強をすることができます。
ただし、自分の思い通りに事が進むとは限りません。
希望する会社に入れなかった、希望する現場に配属されなかった、いざ入ってみたら期待していた環境・待遇と違っていた、思った以上にブラックだった・・・などなど、ネガティブな現実が待ち受けている可能性もあるため、博打的な要素がやや強いかもしれません。
有料のトレーニングを受講する
ここまではほとんどお金をかけずに学習する方法を紹介してきましたが、お金を使って学習する、という選択肢もあります。
独学ではあまりにも効率が悪い、でも本気でスキルアップしたい、と考えているのであれば「時間をお金で買う」という選択肢は別に悪くないと思います。
ただし、トレーニングの内容や講師の質は十分吟味しましょう。
実践的な内容になっているか(座学中心であればNG)、講師に自由に質問できるか、受講者の評価はどうか、といった点を確認する必要があるでしょう。
受講料の高い・安いはあまり関係ありません。
安くても内容が悪ければ、時間とお金のムダですし、高くても有益な内容であればお金を払った価値があります。
お金をかけたとしても、そのコストを短期間で回収することができれば、投資としては「勝ち」になるので、「絶対に元を取ってやる!」という気概で参加するのが良いと思います。
ブログやQiitaに技術記事を書く、勉強会で講演する
インプットすることだけがスキル習得の唯一の方法ではありません。
アウトプットすることもまた、自分のスキル習得に有効です。
ブログやQiitaに技術記事を書いたり、勉強会で講演したりすると、そのアウトプットをまとめていく過程で自分の知識が整理されていきます。
また、適当なことを書くと上級者から厳しいツッコミ(「マサカリ」とよく呼ばれます)が入ります。
そうならないように記事やスライドの内容をブラッシュアップしていくと、それ自体がいい勉強になります。
また、厳しいツッコミが入ったとしても、その指摘が適切なものであれば自分の勉強になります。
いいアウトプットをするとネット上で話題になり、あなたの知名度や評価が上がります。
うまくいけば、それがいい会社に転職できるきっかけになったりします。
ただし、アウトプットでスキルを向上させるためには、それなりのクオリティに仕上げることが重要です。
「自分用メモ」みたいな形でサンプルコードを貼り付けるだけでは、スキル向上には役立ちません。
その知識を知らなかった「2ヶ月前の自分」を想像して、その自分が泣いて喜ぶような説明の仕方を考えてください。
いろんな方法をバランス良く組み合わせる
ここまでいろいろとスキル向上の方法を紹介してきましたが、当然「どれかひとつを選べ」と言っているわけではありません。
むしろ、いろんな方法をバランス良く組み合わせるのが大事です。
本を読みながら、自分でコードも書く。
新しく学んだことがあれば技術記事にまとめる。
現場でコードを書きつつ、週末は勉強会に参加する。
・・・といったふうに、特定の方法に偏らない勉強法を考えてみましょう。
時間はかかる。目安は「3年」。
スキルを習得するための効率はある程度までなら上げることができますが、放物線を描くように急上昇することはありません。
絶対的な時間はかかるものです。
僕は今年でプログラマ歴13年になります。
Rails歴も5年ぐらいです。
いっぱいコードを書いたし、いっぱい本を読んだし、いろんな現場を体験したし、大変な苦労もいっぱいしました。
それだけの年数を経ているのでプログラミングやRailsを始めて間もない人から見れば「伊藤さんってすげー」と思われても、なんら不思議ではないでしょう。
(僕自身が生まれながらの天才ではない、凡人プログラマだったとしても)
ただし、こうやって書くと「うわあ、先は長いんだな。大変そうだな・・・」とビビってしまう人も出てきそうなので、目安となる数字を上げましょう。
3年です。
プログラミングに限らず、どんな技芸でも完全未経験の初心者から「他人から認めてもらえるレベル」に達するには3年あれば何とかなります。
僕自身も「Railsが結構できるようになってきた」と思えたのは3年目ぐらいです。
僕は音楽好きなのでギターをよく弾いたりするんですが、学生時代にギターをゼロから始めた友人が3年後に「うお、結構弾けるようになってるやん!」とビックリするぐらい上達しているのを見ました。
また、僕の義父は一時期中国に単身赴任していたのですが、3年ぐらいすると現地の人と普通に意思疎通できる程度の中国語が話せるようになっていました。
こうした経験から、僕は何事も3年あれば「他人から認めてもらえるレベル」に達することができると考えています。
ただし、そのためには並々ならぬ努力が必要です。
ぼーっと続けて3年、ではなく、必死でやり続けて3年、だと思ってください。
そして、そのために必要なのが、冒頭に挙げた「技術が大好きで、楽しんで学べること」という前提条件です。
大変だけど楽しい、大変だけど好き、という感覚がないと「必死で3年」を続けることはできないと思います。
オールマイティを目指すとしんどい
Railsをやっていてときどき思うのは、勉強しなければいけない技術分野が非常に幅広い、むしろ幅が広すぎる!ということです。
たとえば以下のブログ記事(英語)にはRailsが関連している数多くの技術分野がマインドマップとしてまとめられています。
This is Why Learning Rails is Hard - Learn to Code | Code Fellows
もちろん、なんでもできるのが理想的ですが、インフラからフロントエンド、Webデザインまで全部完璧に一人でこなすのはほぼ不可能です。
最初からそこを目指すと燃え尽きてしまいそうになるので、自分の好きな分野・得意な分野と自分の苦手な分野を自覚するようにしましょう。
そして、好きな分野・得意な分野を伸ばす方に注力した方が技術者として評価されやすくなるはずです。
苦手な分野・不得意な分野は得意な人に手伝ってもらった方が、全体で見たときに効率が良くなります。
5年後、どうなっていたいか(どうなりたくないか)を考える
あと、やみくもに「スキルを上げたい!」と考えていても、進むべき方向がいまいち定まらないと思います。
そういう場合は5年後の自分を想像してみるのがオススメです。
「5年後、自分はこんなことができるようになっていたい」「こういう現場で働けたら楽しそう」と想像してみると、「じゃあそのためにはこんな努力がいるな」という具体的なイメージがわいてきやすいです。
反対に「このままだと5年後にはこんなことになってそう。そんなのはイヤだ!!」とネガティブ方向に想像してみるのも有効です。
むしろ僕はそっちの方向で考えることが多かったりします(苦笑)。
社会人になりたての人は想像しにくいかもしれませんが、働き始めて2~3年ぐらいすると、いろいろと現実が見えて「こういう仕事が好き」「こういう仕事はイヤ」というのがよく見えてくると思います。
そんなタイミングで「自分の5年後」を想像すると、なかなかよい思考実験になります。
スキルを上げると待遇も上げやすい
プログラマの仕事はまさに「手に職」が付けられる仕事です。
スキルを上げれば上げるほど、お給料が増えたり、転職しやすくなったりします。
うまくいけば僕のように好きな場所に住みながらリモートワークすることもできる時代です。
もちろん全員が全員そうじゃない、頑張ってるけど報われない、というケースもあると思いますが、僕はこれまで自分の努力を待遇面に還元できていると感じています。
なので、それが「もっとスキルを上げよう」と考えるモチベーションの一つになっています。
理系文系は関係ない。必要なのは論理的に考える力。
プログラマは理系じゃないとできない仕事だと思われがちですが、別にそうではありません。
僕は10年以上プログラマをやっていますが、プログラミングで微分積分や難しい物理の公式が必要になったことは今のところ一度もありません。
たとえば、ECサイトの在庫管理や料金計算システムを作るぐらいであれば、中学校数学の知識で十分です。(ヘタしたら算数レベルかも??)
もちろん、これはプログラミングの対象分野によると思います。
たとえば、宇宙科学関連のプログラミングをするのであれば、理系の知識は必要になってきそうです。(実際にやったことはないのでわかりませんが。。)
じゃあ誰でもできるのか?というと、そうとも言い切れません。
プログラマとして最低限持っておきたい素質は「論理的に考える力」です。
「AだからB、BだからC。つまり、AだからC。」という理屈を当たり前と思えて、なおかつ自分で導き出せるかどうかが重要です。
この力が無いと自分で複雑なロジックを組み立てたり、自力でデバッグをやったりすることができません。
とはいえ、これを「理系にしかない能力だ」と言い切ってしまったら、「そんなわけはない」ってみなさん思うでしょう?
えっ、思わない??
おかしいなあ。僕は文学部出身なんですが。。
まとめ
というわけで、このエントリではプログラマとしてスキルを向上させるためにはどうしたらいいか、という内容を僕自身の経験をふまえていろいろ書いてみました。
まとめるとだいたいこんな感じでしょうか。
- 技術が本当に好きかどうか自問しよう
- いろんな学習方法を試してみよう
- 3年必死で続けてみよう
- 5年後の自分を想像してみよう
すぐにはできなくても、コツコツ続ければなんとかなります。
その昔、
「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」
「えっ、そんな短い時間で作れるんですか」
とみたいなことを言っていた僕が言うんだから、たぶん大丈夫です!
参考文献あれこれ
今回書いた内容はこれが初めてというわけではなく、これまでにいろんなところで書いてきた話を改めて再編集したような内容になっています。
深く掘り下げてみたい内容があれば、以下の記事を読んでみてください。
これまでどんな経験をしてきたの?
これまでどんな技術書を読んできたの?
2ヶ月前の自分が喜ぶような記事ってどんな記事?
Railsを習得するのってどれくらい大変なの?
5年後の不安ってたとえばどんなの?
自分の得意分野ってどうやったらわかるの?
なんでリモートワークやってるの?
有料のトレーニングって本当に効果あるの?
オススメの本
技術者として自分はこれからどうしたいか、どうすべきかを考えたい人はこちらの本がオススメです。
僕もこの本を読んでかなり影響を受けました。
- 作者: Chad Fowler,でびあんぐる
- 出版社/メーカー: オーム社
- 発売日: 2010/02/26
- メディア: 単行本(ソフトカバー)
- 購入: 24人 クリック: 683回
- この商品を含むブログ (126件) を見る
[PR] ソニックガーデンでもRailsトレーニングを開催します
別に狙ったわけではないですが、2016/5/9 (月) ~ 2016/5/26 (金)に僕が勤めている株式会社ソニックガーデンで若手エンジニア向けの集中特訓講座を開催します。
もしかしたら僕も講師として参加するかもしれません。
興味のある方はぜひ下記リンクからお問い合わせください。