、簡単なOSを開発して補強しました。

その結果基礎を身につけられたと思ったら、次に不足しているスキルの中で取り組むべきなのは何か、と考えて次のスキル取得に向けて動き、という流れでスキルを上げていきました。今でも何か新しいことを学習するときにはこのように体系的に考えて学ぶようにしています。
また、ここでポイントとなるのは、体系的に物事を学ぶには、、その物事に対する”筋(スジ)”を掴むことが必要だと言うことです。既に何かしらの経験があるか、そうでなければ(=ゼロからの学習であれば)とりあえずやってみる、いくつかその物事に関連する事象をランダムでピックアップして調べ物をしてみたりして筋を掴みましょう。筋が無いまま、それっぽく体系的にまとめてみても何かズレたものが出来上がってしまうだけかなと思います。

2.車輪の再発明のススメ

技術や理論、ツールを正しく理解・利用するには、それらが出来た背景を知り、どういう思想のもとに作られたのかを理解することが重要だと僕は考えています。
直近だとWebフロントエンド界隈の技術の複雑化に関してちょっとした話題にもなりましたが、アーキテクチャ、フレームワーク、ライブラリ、ツールをどうするか、みたいなことを考えることが昔に比べて各段に増えていると思います。そんな中、流行りのパターンを真似するだけだったり、

、”標準的にはこう”みたいなベストプラクティスにただ乗っかるだけでは、それらを使った場合のアンチパターンを全て踏むなんてことになりかねません。まずはそれらが作られた背景や思想を理解し、長所・短所/メリット・デメリット/向き・不向きを把握するのが重要だと思います。

そこでオススメしたいのが、車輪の再発明です。先程も少し触れましたが現代は僕がソフトウェアエンジニアになった頃と比べても、便利なツールやライブラリが圧倒的に増えました。そうやって技術のコモディティ化が進んでいる訳ですが、使う側だけにいるとどうしても作る側の思考が見えづらいことがあると思います。
だからこそ「多くの人に使われることが前提の”技術的な何か”を作る」経験が重要だと思います。そしてその何かを作ろうと思った時に”革新的な何か”を作る必要なんてありません。既存のツールに何か毛が生えた程度のものでも良いと思います。もちろん有用なオリジナリティがあるに越したことは無いですが、それに囚われて何も出来ないよりは車輪の再発明でも何でも良いから開発してみることが重要だと思います。

例えば僕は20歳の頃に、自作のWAF(Web Application Framework)を作りました。世に言う「オレオレフレームワーク」というやつです。
当時Ver.1.0が出たばかりのZend Framework(以下ZF)のコードが今までに目にしたことが無いほど美しかったのに惹かれて、このWAFの設計思想を理解したいと思いました。そこで最初はZFのラッパーとして、ガラケー向けのセッション機構、絵文字変換、レンダリング機構などを搭載したWAFを開発しました。まさに既存のWAFに毛が生えた程度のものです。さらにそれを使ううちにより軽量かつ直感的に使いたいと思い、ルーティングなどのコア部分を全て自作し、ZFはメール送信などの外部ライブラリとして使うレベルに留める形のWAFを開発しました。その経験もあり、以来新たにWAFを使うときに背景や思想などを理解しやすくなり、またその思想に則った実装を出来るようになったなと感じています。
フレームワークやツール、各言語のライブラリなど一通り自作してみると”使う側のスキル”も各段にアップする≒学習コストが下がるのでは無いでしょうか。

3.仕事を利用する

これはすごくシンプルな話で、仕事の中に必ず一つ以上チャレンジ要素を入れた方が良いと言うことです。僕は最初の会社がシステムの受託会社だったので分かりやすかったのですが、受託をやっていると案件によっては技術的な面だけで言うと何もチャレンジが無く、既知の知識・スキルだけで案件を完遂することも出来てしまいます。
会社側の立場からするとそれが一番安心だし、むしろそうしてくれと思うかもしれません。でも同じことの繰り返しでは成長に限界があるし、何よりつまらないと僕は思います。なので、どうせやるなら一つや二つ(技術的に)チャレンジングな要素を目の前の仕事に盛り込みましょう。

またもう少しマクロの会社目線で見ても多少のリスクをとっても中長期で社員を成長させることは考えなければいけないので、そのチャレンジのリスクにもよりますが基本は許容されると思います。むしろそれが許容出来ないような会社であれば人に投資をする気がないまたはその余裕がないということなので、早めにエウレカに転(ry

4.事業の成長にコミットする

これには二つ理由があります。
一つ目はまず社会人の基本スタンスは「権利を主張する前に義務を果たす」だと僕は昔から思っています。ここで言う義務とは結果であり結果も出していないのに権利は主張できない。義務を果たさないで、望む仕事、キャリアパス、年収を得ることはできない。だから「3. 仕事を利用する」で出てきた”成長の為の投資”においても 、会社は学校じゃないので人を育てるのではなく事業を育てる為にあるのだからまずはあなたが事業に貢献しなさい、となってもそれはそれで仕方が無いと思います。もちろん会社の基本スタンスがあまりに一方的だとしたらそれはそれでどうかと思いますが、まずは最初に結果を出すというスタンスでいた方が短期的も中長期的にも成長につながります。

もう一つの理由としては、事業が成長することは自身のスキルアップにも繋がるからです。これはスキル全般に言えるでもありますが、エンジニアリングスキルにおいても同様のことが言えます。
技術は何のためにあるのか。技術はプロダクトを作り、成長させるためにあります。そしてプロダクトがハードに使われれば使われるほど、高度な技術力が求められます。つまり技術力を伸ばすにはプロダクトを成長させるのがてっとり早い。なので サービス開発をするエンジニアであれば、サービスをいかに伸ばすかを考えて実際に伸ばしその結果さらなる技術力が必要になり成長する、というサイクルにいち早く入ることが重要だと思います。

5.言うても知名度は重要

これは僕が心がけてこなかったことなのですが、僕が今から新卒エンジニアとしてキャリアをスタートするのであれば絶対に心がけると思います。
「技術力さえあれば、知名度なんて関係無い、俺はこの腕一本で食べていくぜ。クソブロガー問題なんてのもあったしな。」と思うあなた。
言ってもエンジニアとしての知名度は超重要です(かつ知名度を上げる行為に副産物が色々ある。逆に言えば、その副産物を産み出す取り組みの結果として知名度が付いてくるのであり、こちらが健全な考え方ではある)。なので自分のキャパシティと相談ではありますが、ブログとかQiitaの執筆やOSS活動を行なうにこしたことはありません。

行なった方が良いと思う理由
・自分が全く知らない場所でも 、あの記事を書いた◯◯さん、あのOSSのコミッタの◯◯さん、と言われるようになる。そうやって知名度が上がると人生の選択肢も増える。選択肢が増えるのが豊かなのかというとこれは哲学的は話にはなるが、この先どんどんハードモードになる世の中のことを考えると、選択肢を多く持てるに越したことは無いと思う。
・会社の中というある程度固まった/偏った知識や技術以外に触れることができる(見たことがないアーキテクチャを見ることができるとか)
・OSS活動はある程度の英語力が必要になり、結果英語力が強化される。READMEやコミットログは基本英語だし、海外のエンジニアから英語コメントのプルリクが来ることもあったり。英語力が必要だなんて言うまでも無いので、これも大きなメリットです。
ということで別に知名度だけの話では無いのですが、記事の執筆活動やOSS活動は若いうちの方が時間が取りやすいので、新卒のエンジニアの皆さんは斜に構えず是非取り組んでもらえればなと思います。(僕はめっちゃ斜に構えていましたが、正直後悔しています)

まとめ



色々書きましたが、僕にとってのベストプラクティスが皆さんにとってのベストプラクティスとは限りません。そして、まだまだ未熟で日々反省してばかりの僕が言っていることなんて数ある物事の見方の中の一側面でしか無いと思います。なので”心がけるべき”と言いつつ、僕はエウレカの新卒エンジニアにすらこれを押し付けるつもりは全くありません。
ですが、もしこの記事を見て何か思うところがあれば取り入れていただけると嬉しいです。
それではまた!


エウレカでは、一緒に働いていただける方を絶賛募集中です。募集中の職種はこちらからご確認ください!皆様のエントリーをお待ちしております!