NAKKA-Kの技術ブログ

技術に関する知見や考え方などを投稿します。

「超一流になるのは才能か努力か？」を読んで己の限界を越えよう

書籍

この書は人々が才能と呼ぶ生まれ持った資質と全面から闘い、己の道を切り開くための本だ。

超一流になるのは才能か努力か?

超一流になるのは才能か努力か?

対象読者

プレイヤー、教育者、親、己の才能の無さに苦しめられる者

言うなれば全ての人だ

結論

才能とは誰かに決められるものでも、遺伝子によって生まれた時から決まっているものでもない。

才能とは自ら創り出すものだ。

努力すること

心から強く念じ、努力しさえすれば、目標を達成できる。

これは間違っている。

目標を達成するには目的を明確にし、自らを向上させる為にもっとも効果がある方法を考え、絶えず自らに挑戦を挑み続けることが重要だ。 これらは目的ある練習、また限界的練習などと言う練習法の原則の一部だ。

目的ある練習、限界的練習について

これらにはそれぞれ複数の原則がある。 詳しい話は実際に書を読んでもらいたいが、一部をまとめる。

  • 集中して行う
  • 明確な目標を持つ
  • フィードバックが不可欠
  • 居心地のいい領域から飛び出すことが必要

トッププレイヤーとは？

トッププレイヤーとは誰よりも努力する人だ。 そしてただ努力するだけではない。 目的ある練習、限界的練習、それに加えて多くの要素が必要だ。

例えばこの本に出てくるバイオリニストの話だ。

将来傑出したプレイヤーとなるバイオリニストの卵(書ではSランクとされる)は、18才の音楽学校時代までには2万時間〜2万5千時間程度の練習を積んでいる。 これより一段劣るがそれでも素晴らしいバイオリニストの卵(Aランク)は1万5千時間〜2万時間程度の練習を積んでいる。 このAランクとSランクの差がただの才能と言い切れる根拠はあるだろうか？

いや、無い。 あるのは膨大で有益な練習の差だ。

年齢は関係あるのか？

残念ながら子供の頃の方が同じ訓練でも成長率が高い場合が多い、という事実はある。 およそ子供の脳の方が変化に柔軟で適応力が高いからだろう。

しかし書には、30歳にしてゴルフのど素人がプロゴルファーとして全米プロゴルフ協会のツアーに参加できるよう訓練する話や、69歳で空手を始めて黒帯を目指す話なども書かれている。 最近では定年をゆうに超えた方がスマホアプリを作りリリースしたなどの話もよく聞く。

年齢を理由に夢を諦める必要はないのだ。 大抵の場合はまだまだ道が開かれている。

まとめ

練習に膨大な時間を費やさなければ、並外れた能力は手に入らない。 そして才能とは生まれ持つものではなく、後天的に身に付けるものだと分かった。

恐らく多くの人は己の才能に悩んだことがあるのでは無いだろうか。 私もその一人だ。 だがもう諦める必要などない。 自分の道は自分で創れると書から学んだのだ。

「夢を追いかけない理由などない 」 。限界的練習は 、絶対に自分には手が届かないと思っていたさまざまな可能性への扉を開いてくれる 。その扉を開けようじゃないか 。

ダムを見てオブジェクト指向に思いを馳せた話

技術

先日旅行に行った時、ダムを見てオブジェクト指向に思いを馳せたことをここにまとめてみます。

ダムについて

雨が少ない時に渇水してしまわないようにダムに雨水などを貯めておき、いつでも必要な時に水を確保できるようにする役割を担っています。

その後、ダムから出た水は取水口を通して浄水場に送られます。 そして浄水場で綺麗にされた水は各配水池に貯められます。

ダムとオブジェクト指向

ダムは水の綺麗さに関わらずただ水を貯めるだけの役割を担っています。 もしこれが綺麗な水だけを貯めるようにした場合、水を貯める機能と綺麗にする機能を兼ねる事になり、今ほどの水量を貯めることができなかったでしょう。 そして水を貯めるだけの機能に限定したため、ダムの拡張が圧倒的に簡単です。

例えば水を貯めるだけのダムをイメージにするとこんな感じになります。

水を貯めるだけの場合のイメージ

これが綺麗な水だけ貯めるダムをイメージにするとこんな感じです。

綺麗な水を貯めた時のイメージ

これをオブジェクト指向的に言うと単一責務の原則です！(本当だろうか)

ダムをコーディングしてみる

ダム、浄水場、配水池の関係を実際にオブジェクト指向でコーディングしてみます。 ここではGo言語を使用しますが、雰囲気やコメントである程度読めるかと思います。

コードを後述していますが、先に概要をまとめます。 ダム、浄水場、配水池それぞれにインターフェースを設けます。 そしてそれぞれの機能を構造化して、順番に水の受け渡しをコーディングします。

と、このようにそれぞれの役割に徹し機能を分割してやると、外からのことを気にすることなく拡張が出来ます。 今回は拡張のしやすさをインターフェースでも表現しています。

まとめ

拡張しやすいように設計するのは大事だぞ！という教訓を得た話でした。 それと同時に、どんなことからでも学びに繋げることができる！という教訓も同時に得たのでした。

「テスト駆動開発」を読んでTDDについてまとめた

書籍 技術

kent beck 著、和田卓人 訳「テスト駆動開発」を読んだ感想を書く。

 

TDD(テスト駆動開発)とは

  • 自動化されたテストを書く。
  • テストが失敗した時のみ新しいコードを書く。
  • 重複を消去する。

テスト駆動開発とはこれらのシンプルな制約のもとになりたつ。

これにより多くの利点がもたらされる。

 

TDDの利点

  • 開発が予測可能になる。(バグが残っているか心配する必要が減る)
  • コードが伝えようとしている事を余すところなく受け取れる。
  • 作るソフトウェアのユーザーを快適にする。
  • チームメイトはあなたを信頼し、あなたもチームメイトを信頼する。
  • 書いていて気持ち良い

 

概要

テスト駆動開発とはなんたるか、どうすべきなのかを細かく理解させてくれる。    

この本内の開発は全てTDDで進んで行く。  

その中でTDDを進める上での流れや、感覚というものを多く共有してくれる。著者が隣にいて、ペアプロをしているような感覚で見ることが出来る。  

その時感じていること、こうした理由、いまこう思っている、と言った心情まで全て伺える。  

それによって今までTDDが実用的では無いと思っていた人達にもTDDの有用性や実践方法、弱点が見えてくるだろう。  

 

まとめ

この本を読めば、すぐにTDDを始められるだろう。

TDDの事を知りたい人、実践が難しいと思っている人にオススメできる本だ。

単純にコーディングの勉強本としても設計の仕方や多くのコードを書く過程が見られるので良書である。

 

 

業務で扱った技術について個人ブログを書くのは有り？無し？についてアンケートしてみた結果

プログラマ

Twitterで技術ブログの投稿を見た時にふと「業務で扱った技術について業務時間に個人ブログを書くのは有りなのか、はたまた無しなのか？」という疑問を持ちました。 その疑問をTwitterの投票機能によって集計した結果と意見をここに記します。

対象読者

自企業に何かしらの技術者を要する人、または技術者

投票内容について

※投票期間は終わっていませんが、完全に投票数が停滞しているため記事にしました。

(当ブログ編集時) 業務時間中に業務で扱った技術について個人ブログを書くのは有り？無し？

技術者、非技術者に対してそれぞれ有り、無しを質問しました。 この段階では「業務時間中に書く」という想定で投票を実施しました。

しかしこの時、文章に2つの解釈を持つ書き方をしてしまったため、「"業務時間中に扱った技術"について書く」という解釈と、「業務で扱った技術について"業務時間中に書く"」という解釈に2分してしまいました。

投票結果

ここでは一旦、「"業務時間中に扱った技術"について書く」という事に焦点を置くことにします。 この投票では正確に聞きたかったことが聞けておらず明確な数字に強い意味は持ちませんので、ツイートに対しての返信や引用リツイート等の意見に重きを置いて、数字は参考程度に見ていきたいと思います。

一言でまとめると、返信等の意見を見る限りブログを書くということ自体にはほとんどの人が有りという意見を持っていました。

この有りという意見を持っている人たちは、基本的に機密情報などは書かない前提のもとで有りとしています。 おそらく技術者として普段情報発信をしている人たちにはこの意見を持つ人が多いかもしれませんね。

対して、無しと答えた人の多くは機密情報や会社の秘匿技術、個人情報が特定できそうな内容などを書くのはダメだと言う意味を持っていそうでした。

機密情報などについてはもちろん書かないことが前提ですが、固有情報などについては判例の分析や医学論文のように伏せて一般化するのが良いという意見も頂けました。

そして投票の結果をみる限り無しに投票している人がそれなりに多いですが、これは「業務で扱った技術について"業務時間中に書く"」という内容に対しての投票が多そうでした。 これについてはこの後に書きます。

結果、「"業務時間中に扱った技術"について書く」という内容に関しては圧倒的に有りが多いという結果で収束しそうです。

再投票結果

前章では一旦置いておいた「業務で扱った技術について"業務時間中に書く"」という内容に関しても返信内容などを元に見ていきますが、この内容について再投票も実施しました。

前回の投票と比べて少人数の意見となってしまいましたが、投票結果としては大体想定内という思いです。

前回アンケートでも意見がありましたが、基本的にはグレーで社風や会社の仕組みなどによってどちらに転ぶか左右されそうです。 工数管理にズレを生じさせる可能性などを考慮した場合ではアウトになりがちという意見でした。

まとめ

基本的に学んだ技術について整理して何かにまとめると言う行為は、技術の定着や後から取り出せる情報の引き出しを増やす事につながります。 この学びを続ける事はその後の技術者の能力にも大きく影響を及ぼす事です。

これらの学びを仕事以外の時間で実践すれば、もちろんその人の実力は伸びていく事でしょう。 しかしそれを、仕事の中で学びを定着させる機会として、業務時間中の技術まとめを許容するかどうかは会社やチームの方針によって大きく異なりそうです。 これらを会社で実践しようと考える場合、チームのリーダーなどに話して許可を貰っておくことをお勧めします。 場合によってはデータやスライドを用いて、会社の仕組みとして取り入れるように働きかけるのも面白いと思います。

学ぶことを止めた時が死ぬ時であり、かつ「学習の最大の敵は、すでに学んだこと - (ジョン・マクスウェル)」です。 学び続け、学んだことをまとめ記すことが大事です。

追伸

再投票の投票数が少なく、どうにもデータとして使えそうな集計を諦めきれないので再々投票を実施しました。 出来るだけ多くの投票お願い致します！！！！(結果は当ブログにフィードバックします)

専門学校生がプログラマーとして新卒月収41万で入社するまでにやったこと

プログラマ

専門学校に入学した頃はまともに就職できるのかすら不安でしたが、なんやかんやでちゃんとした会社に入れたという事実に困惑しています。 実際に業界の人たちと話してみないと案外わからないことだらけだなという印象を持ちました。 なので、プログラミングほぼ初心者で専門学校に入学し、そこから約2年半で内定に至るまでに役立った情報を書こうと思います。

※あくまでも新卒目線から見た個人的意見です。

記事を書こうと思い立った理由は、ゲーム系のこの手の記事を見たからです。 ai-gaminglife.hatenablog.com

対象読者

俗に言う今を時めくWeb系企業とやらにプログラマーとして入社したい人

筆者の経歴

  • 出身高校

    地元では1、2を争う低レベル校

  • 専門学校

    関西にある某デジタル分野の専門学校

  • 専門入学当初のPC経験

    PCゲームにはどハマりして最低限扱えたが、プログラミングはほぼネットでコピーした20行程度のじゃんけんゲームが最大作品(1日勉強したら作れる)

専門入学からの経歴(半年毎)

1年目前期

この頃はプログラミングなんて全然わかってなかったので、学校で配られたC言語の課題をただひたすらに進めていました。 課題とは言っても10〜20行程度でAtCoderに出てくる一番簡単な問題くらいの難易度。 それと同時期になんか成長できそう、くらいの感覚でプログラミング系の部活に入部しました。

テストの点数は悪かった......

1年目後期

部活の活動で、文化祭に出すための作品を作ることになりました。高校時代まではグループになると端っこで一言も喋らず傍観している私でしたが、何か変わらねばと焦燥感にかられプロジェクトリーダーに立候補。(なんでそんな決断ができたのか今でも謎に包まれています) 初めてのゲーム作成に携わり、当時はC言語とDxライブラリでクイズゲームを作成。 デスマーチを重ね、見るも無残ながら完成させたゲームはなんとか展示され多くの人にプレイしていただきました。

この時期には体力の持つ限り開発をし続け、冬休みにサボりつつも大小合わせて4本のゲームを作りました。

2年目前半

学校ではJavaの授業が始まっていましたが、学校で習うレベルのことは1~2週間程度でさっさと済ませてしまいました。

java.sevendays-study.com

地域のイベントに無料WiFiを敷設するボランティアの手伝いをして、インフラの知識とネットワークの知識を学びました。

この頃は言語開発に興味が出てC言語でなんやかんやしてました。

2年目後半

この時期にリーダブルコードという綺麗にプログラミングするための要素が詰まった本を読みました。 この本のおかげで一つのブレイクスルーが起きて、ガリガリコードを書けるようになりリファクタリングが趣味になりました。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

この時期からインターンというものに興味を持ち始めて探すんですが、関西にはこの時期からインターンをやっている会社は非常に少なくて見つけるのに苦労しました。 しかし1社だけ2dayのインターンに参加してwebアプリケーションの勉強をしてきました。 勉強会にもハマって週1で大阪の勉強会に出没していました。 この頃はPythonにハマってフレームワークを作る勉強をしていました。

3年目前半

春休みの時期にサポーターズの1on1逆求人イベントに参加して、多くの企業さんとつながりを作って7,8月には学校を1ヶ月サボった上で東京にある3社のインターンに参加しました。 ここでインターンに参加した3社のうち、1社ではその後にリモートアルバイトをやらせていただき、1社には入社することになりました。 Railsをやったり、Goをやったり、Reactをやったり、Scalaやったり。

3年後半

インターンに参加した企業さんの面談やらアルバイトやらをこなしながら10,11月に内定が出ました。 その後もインターンで学んだことを怒涛のアウトプットで作品を作りまくりました。

4年目前半

// TODO: これから

就活について

この時代にプログラマーとして就活をするなら逆求人イベントが一番です。私はほぼこれでしか就活をしていません。 サポーターズさんやジースタイラスさんのイベントしか参加していませんが、自分にあったイベントに出会うとトントン拍子に話が進んでいきます。 参加条件は簡単で何か作品を作っておくことさえできれば大丈夫だと思います。

インターンについて

逆求人イベントからの流れが一番早いと思いますが、特に夏のインターンに参加することをお勧めします。 夏のインターンは多くの人が就活を始めるよりも随分と早い時期に開催されますので、その分レベルの高い人材が集まっている傾向があります。 インターンに参加すると濃縮された学習ができたり、インターンに参加するための勉強でもっと強くなれたり、他のインターン生とのつながりができたり、結構なお金がもらえたり、とメリットが多すぎるので絶対に参加した方がいいです。 Webアプリ、スマホアプリ、ゲーム、AIなどかなり幅広い分野での募集があるので、自分にあったインターンに参加するといいです。

面接について

企業さんから遠い場合、Skypeなどのツールを使って顔を写しながら遠距離面談をやることが多いです。上がりやすい人は遠距離面談だと余計緊張してしまうかもしれないので、少し慣れが必要かもしれません。思っているよりカジュアルな面談であることが多いのであまり気負いすぎないのがいいです。

SNSツールについて

企業さんと連絡先を交換するときは複数のパターンがあります。単純に電話やメール、Facebook、Lineなどが多いです。特に特定の人事さんと繋がる場合はFacebookが使われやすいのでできれば登録しておきましょう。

業界の情報収集にはTwitterが一番だと思います。 数は力、とはよく言ったもので、フォローした人たちの調べた情報が一箇所に集結して日夜有益な情報が流れ続けるわけですから、情報の宝石箱やーと叫びたくなるような素晴らしい情報ツールです。 そのほかにも、自分でインプットした内容をアウトプットしてみたり、他の人からモチベーションをもらったり、素敵な画像や動画で癒されたり、炎上ツイートを眺めて癒されてみたり、たまにはDMでスカウトが来たりとTwitterさまさまです。

Web系に就職するには何をすべきか

めっちゃアウトプットしましょう

インプットはもちろんTwitterやQiita、はてなブログなどなんでもいいですが常にする必要があります。 でもインプット3割：アウトプット7割が一番いい比率と言われますから、やっぱりアウトプットをどんどんしていかないとせっかくインプットした知識も使えないんですよね。 具体的なアウトプットの例というと、アプリを1年で5本作ってみるだとか、技術ブログを1月に1本投稿してみるだとか、目に見える作品をどんどん作っていく必要があります。

これは自らの成長のためという側面が大きいですが、就活するにあたって目に見えにくいプログラマーの能力を表すには大量のアウトプットがあった方がいいんですよね。 なので就活までに最低でも年1本はちゃんと物を作り、5本くらいは技術記事を書いていると非常にいい感じだと思います。 実際にやってみるとわかりますがこれは難しくもなんともない量です。働きながらでも余裕でこなせる量ですので、とりあえずやってみましょう。

人として最低限の文化的な会話能力をつけましょう

技術があればコミュ力はいらないなんて嘘です。 ここでいうコミュ力とはうぇーい力ではなく、人として最低限の文化的な会話ができるという能力のことです。

物作りを楽しみましょう

結局のところモチベーションの大元は物作り自体を楽しむことです。 ちなみに私は専門入学当初、プログラミング楽しいけど家でやるほどでもないかなー、なんて思ってましたができるようになってくると楽しくなるものです。1年後半や2年前半あたりからはひたすらプログラミングするようになっていました。

そして物作り自体を嫌々やっていると、作ったものにその気持ちが反映されてしまいます。 本当にいいサービスを見ると、作者がこのサービスを本当に愛しているということが伝わってきます。

自己防衛

この業界、死ぬその時まで常に学びが終わりません。 やはり学び続けるにはモチベーションが大事です。 モチベーションを上げる方法はいっぱいありますが、まずは下がりにくい環境に身を置くことが大事だと思います。 もともと学習意欲の高い人たちに囲まれていれば自然とモチベーションは上がりやすくなりますが、逆の環境に身を置けば みかん箱の中のカビのように悪い空気が伝染します。

特に学力の低い学校などにいるとこういう空気を持った人が多いです。 専門学校は悪い空気を持った人が半分、それなりにいい空気を持った人が4割、異常なくらいいい空気に包まれたガチ勢が1割という分類が多いです。 普通の大学以上にこれらのグループが独立するので、一度最高の1割に入ればあとは最高のサイクルをひたすら回すことができるのでどんどん成長できます。 最初のポジション取りは重要です。

自分が思っていた事に答えます(Q&A)

Q. 学歴は必要？

必須ではないです。(必要なところもそれなりにありますが) 日本の優良企業やメガベンチャー、世界でも有数の学歴社会であるアメリカにあるGoogleやAppleやIBMなどでも学歴不問であるという記事が多く見られます。 (とと言いつつ学歴は免許証くらい便利な身分証です)

※実際に日本人がGoogle等の企業で働くのに学歴がいらないとかそういうことではなく、学歴不問で募集しているところもあるよという話です。参考資料

ただ、学歴がいらない == 勉強しなくてもいい、と単純に考えると死にます。 いい学校に入っていると言うことはそれだけ勉強して脳回路が鍛えられている訳ですから、そこに差が出る可能性は高いです。 なので学歴がなかろうと、もう就活まで時間がなかろうと、少しでも自分の頭を鍛える必要はあります。

(補足) もし就労ビザを取得してアメリカ等で働きたい場合は、特殊技能職ビザ(H-1Bビザ)というものを取得する必要があります。 このビザは「４年制大卒以上の専門職、大学の専攻と関連した職種、アメリカ人の雇用を侵さないこと」という条件が必要だと思います（おそらく）。 なのでその場合、4年生大学を出ておく、またはそれ相応の経験(実務3年=大学1年とか)を積んでおく必要がありますのでお気をつけください。 もし後から4年制大卒の資格が欲しければその時に大学に入ればいいと思います。 また4年生専門学校は「高度専門士」という学士相当の資格がもらえるので、これでもいけるのかな？という感じです。

Q. Web系の給料は？

それなりに高いです。世界的にエンジニアの需要や技術力は高まっており、新卒800~1000万なんかも珍しくありません。 しかし日本企業は世界の流れから壊滅的に外れており、いまだに3~500万あたりが多いです。 ですが、ゲームやCGなどの給与水準よりは随分と改革が進んでいます。 400万超の企業はどんどん増えており、優良企業はその流れに取り残されないように徐々にですが水準が上がっています。

ですが優秀な人が低給で働いている事も多いのが現実です。そんな不条理が許されて欲しくないので一人でも多くの人が正当な報酬を貰うために情報発信したい。

Q. 働く環境はブラック？

ブラックな会社が多いのは事実ですが、今時の優良企業であれば一切ブラックとは無縁だと思います。 残業なんてありえない企業も多いですし、まともな企業なら常時月45時間を超えるということはあり得ません。

Q. プログラミングを始めるには？

Progateというプログラミング学習サイトでRails、HTML/CSS、JavaScript、SQLなんかをやっていけば取っ掛かりはつかめるので、とりあえず始めてみましょう。

Q. 全てにおいてプログラミングを優先したいほど好きじゃない場合は？

ほとんどの人はそんなのです。その上、ある程度上達した上で言うならまだしも、やり始めてほんの少しではまだまだわかりません。 ゲームをプレイするときにも、上手くなってきてからが一番楽しいのと同じです。

Q. 才能がない場合は？

たいしてやってもないのに才能が〜と言われても困るので、とりあえず10000時間やってから話してくれますか？ それだけやれば才能なくても余裕で稼げます。

もちろん飲み込みが遅いとかはあると思いますが、その分効率の良いやり方を模索したり、脳を鍛えるトレーニングをしたり、人より多くやってみたり、いろんな施策である程度切り抜けられます。 なんならその不向きを武器にしてブログを書いたり、マネジメントしてみたり、教えてみたりするのもアリです。 最早やりたいと言う気持ちが才能です。 私がそうでしたし、3年間でアプリ等を30本以上作ったり、50冊くらい本を読んだら、相当戦えるようになりました。

というか才能ってなんだろうって感じなので、この本にある限界的練習というものを参考にしてください。

超一流になるのは才能か努力か?

超一流になるのは才能か努力か?

Q. 専門学校と大学、どっちにいくべき？

専門学校に通うメリット・デメリット

メリット

  • 通常科目などはなく、技術的なことだけ勉強できる
  • 卒論などもなく結構な自由時間ができる
  • 周りは全員プログラマーなのでその手の話やグループ開発の機会に恵まれる
  • 授業としてプログラミングができるので、独学より最初のハードルが低い
  • 常にその話題で溢れているのでモチベーションを維持しやすい
  • 現場で働いていた先生や同級生から話を聞いたり、人脈作りなどがやりやすい
  • 学割や学校の一括購入でソフトウェアなどが安く手に入る
  • 資格を取りやすい nakka-k.hatenablog.com

デメリット

  • 大体馬鹿(微分・積分？なにそれおいしいの？)
  • 授業進行が遅いので自ら動かないものは落ちていく
  • 授業のスケジュールは全て決まっている
  • 授業時間が固定で大体9時~15,6時などのスケジュール

専門学校とは

結局専門学校だろうが大学だろうが、どこにいっても自ら動かない限り上は目指せないというのは当然な話です。 専門学校は大学以上に自ら動くことが成功への鍵になっています。自ら動くだけの力がない人の落下速度は大学以上に激しいと思います。

どちらがいいのかと聞かれると大学と答えますが、実際に私が大学に行っていたら今ほどプログラミングはできていなかったと思います。 専門学校の方が最初のハードルが低く、そのハードルさえ超えてしまえば自走できるようになるタイプの人は専門学校をお勧めします。

Q. 大体何時間くらい学習時間かけた？

私はいろんな技術に興味が湧いてすぐに取り入れてしまう癖があるので、バックエンド、マネジメント、フロントエンド、アプリ、ゲーム、インフラ、デザイン、認知心理学、教育、英語などこの業界で役に立ちそうなものは片っ端から勉強してしまっています。

なので単純なプログラミングの時間という訳ではありませんが、3年間で最低でも7500時間(~9000時間)はやっていると思います。 明確に数えていた訳ではありませんが、365日×3年×8時間=8760からたまに少ない日や逆に多い日を足し引きして大体こんな感じというものです。 この3分の1も時間をかければ普通に大丈夫だと思います。

まとめ

ここまで頑張る必要があったのは、私がこれまで勉強を随分とサボっていたせいです。 ピカソが30秒で書いた絵について「30年と30秒かかっている」と言っていた理論と同じく、今までの勉強分をここで取り戻すため人より頑張っただけなのです。 今まで頑張っていた人はもっと楽に達成できることだと思います。

  • 専門学校からでも余裕です
  • 逆求人イベント参加しましょう
  • 環境を武器にしましょう
  • アウトプットが命です
  • Twitterは良いぞ

エンジニア志望の学生にオススメする就活らしくない就活方法

プログラマ

昔ながらの就活はいやだ

リクナビに登録して興味のない企業のオススメメールが山のように届き、スーツで何社もの企業説明会を周り、手書きの履歴書を何枚も書いて...... 今時こんな就活はしたくありません。 ポートフォリオや志望業種などを登録して、自分にあった会社から説明会や面談のお誘いを貰い、私服で面談にのぞみ、実力ややる気を正当に評価されて内定が決まる。 これがベストです。

ポートフォリオは自分で作るのも良いですが、特定のサイトで登録できる情報でも十分です。 私が登録していたものの中で、それなりにお誘いが来たサービスや登録しておいた方が良いと思うサービスを紹介します。

Wantedlyは就活時期になると結構DMが飛んできます。

サポーターズはなんといっても1on1というイベントが強いです。 私はこれで8割くらい就活が終わりました。

Twitterは他のエンジニアがどんなことをやっているのか分かったり、技術の疑問に答えてくれることがあったり、モチベーションをもらったり、バイトや転職の募集があったり、必要な情報はだいたいTwitterで拾ってきました。 普段から技術系の話をつぶやいたりしていると、時折DMにスカウトメールが飛んできます。

Linkedinはちょっと敷居が高いのですが、情報を登録しておくだけでスカウトメールが来てたこともありました。 海外も見据えるなら必須かもしれません。

Facebookは会社の人やインターンで知り合った仲間と連絡するとき、だいたいFacebook交換しよう！と言われます。 使ってなくても良いのでとりあえず登録しておきましょう。 FacebookのMessengerという機能でチャットを使ってやり取りをします。

まとめ

いろいろ登録しておいて、最終的に自分にあったものをメインに使っていきましょう。 他のものは登録情報だけ残しておけばメッセージが来たりするので、なんとなくでおいておけば良いです。

プログラマの行動・意思におけるプラクティス記事を読んで

書籍

どうも、NAKKA-Kです。

Qiitaで、初心者プログラマが犯しがちな過ち25選 - Qiitaという、The Mistakes I Made As a Beginner Programmer – jsComplete EdgeCodersの翻訳記事を読みました。 この記事はそれなりに経験を積んだプログラマとしては当たり前である内容がほとんどです。 ですが、実際に言葉に表してリスト化して見ると案外できていないことも多いかもしれません。 そんな時のために、後から見返すための資料があると便利なので、この記事はありがたいです。

そして、初心者にプラクティスを教えるためにも、記事にまとまっているのは非常に便利です。 皆さんもありがたく活用させてもらいましょう。

内容について

私が特に気にして欲しいと思う項目をまとめてみました。

  • 1) 設計せずに実装する
  • 2) 実装する前に設計しすぎる
  • 4) 最初の解決策に飛びつく
  • 6) ググらない
  • 10) コードを悪化させる
  • 24) エラーを嫌う
  • 25) 休憩を取らない

以上のリストはとりあえず最低限も最低限の項目だけをまとめましたが、これらができるようになれば自ずと他の項目も見えてきたりします。 そういう意味ではこれらだけでもやっておけば、全く見えるものが変わってくるかなと思います。 いきなり全ての項目を実践するというのは、まず無理だと思うので少しずつでも重要な部分から実践していくべきです。

初心者が一番つまずきやすい原因としては、4,6,24の項目が上げられると思います。
これらはとりあえずコピペで対応した汚いコード、意味のわかっていない謎コードを量産します。 それにより、開発が楽しく無くなったり、問題をどんどん難しくしていきます。 これだけは即座に対応すべきだと、私個人としては思います。

それに近いくらい25の休憩は重要です。
詰め過ぎた状態での作業は、無駄な固定思考を生み、簡単な問題で躓き続けます。 ちょっとトイレ休憩やティータイムでも挟めば、何時間も悩んでいた問題が数分で解決するといったことは、プログラマー界隈では日常茶飯事です。
ただし！絶対に履き違えないでもらいたいのは、作業を休憩することとサボることは全く意味が違います。 これを履き違えた結果、死んでいくプロジェクトをいくつ見たか数え切れません。

(たとえば鬱などの場合、数ヶ月以上の単位で休むべきです。その場合はサボりではなく、休憩です！)

まとめ

とりあえず記事を読んで、大事なところから実践していってください。 そして時々記事を読み直し、やるべきことができているか、前と比べて成長できているか確認するのも大事です。
適度に休憩しながら！