僕の初Contributionは 2016年12月22日

序文

⚠ すごく 当たり前のことを書くかもしれません
⚠ 僕自身の偏りな意見が多く見られるかもしれません

はじめに

Gashoo inc. Engineer の しゅんです。 今でこそプロダクト( gashoo.jp ) の コードを 書いたり, 修正したり, 提案したり していますが、 僕の Gashoo プロダクトへの 初 Contribution は 2016年 12月22日でした。 ( だいたい1年と感覚でしか 掴めていなかったので、GIthubで 確認してみた 笑 )

どういう内容の Contributionなのか気になったので、確認してみたところ、 すっごい しょうもない PR を出していたので , 実際のところ 貢献もクソもない。 詳しくいうと , error が 出ているところを コメントアウトする という 情弱っぷり。

その次, いつ 稼働したのかな と , 気になったので 見てみると 2017年 1月8日 とかでした。しかも, View など 文言 の修正ばかり….orz w

結論 なにが言いたいかというと, エンジニアになって まだ 1年未満ということ。

Advent Calendar を 書くと話が上がって来た際に, がむしゃらに コードを書いてきたので 一度 落ち着いて, 今年を 振り返ってみようかと思ったので、振り返ってみる。 ( これまで, きちんと どういう経緯など どういう人なのか 人に 話したこともなかったので… )

プラス これまで 自身が 勉強するにあたって 気をつけたことや, 心がけたことを記載していきます。 ( 今後の 成長や 育成のためにも )

んで、どんな人なの - ぷち経歴

大阪芸術大学を超絶ギリギリで卒業

↓　↓　↓　↓　↓　↓

卒業式 当日 盛大に 寝坊し、式典に不参加
僕が到着したころには, 盛り上がり終えたあとで 落ち着いていた
改めて, 証書を取りに行くハメに

↓　↓　↓　↓　↓　↓

卒業後, 通信業界で働きながら 株式会社ガシューの立ち上げに携わる

↓　↓　↓　↓　↓　↓

Gashoo βver. リリースに携わる(ユーザーマーケティング的なことしてた, いわゆる何でも屋サン)
β版時は, 非エンジニアの ただの人

↓　↓　↓　↓　↓　↓

正式リリースに向けてサービスの開発リソースが欲しいし、足りない

↓　↓　↓　↓　↓　↓

じゃったら, わい エンジニアになるわ

↓　↓　↓　↓　↓　↓

3日後, 金髪にする

↓　↓　↓　↓　↓　↓

毎日 15時間以上 pcを眺める日々

↓　↓　↓　↓　↓　↓

いま ココ

2017年1月 ~ 3月

1月

   毎日  10時間以上は 勉強してた
   初めての Gashoo での PR
   主にRoR, github の基礎を勉強

経験者がそばにいて, 比較的 質問しやすい環境ではあったが, わからないことが, わからない 現象になり そもそも なにを 質問 していいのか わからないので, 成長速度は クソみたいなスピードだった。

実は , 金髪にした 本当の意味は, 逃げ道を 断った という 通信の仕事の方を 完全に 断つためでも 僕の中で あった。

結果論でしかありませんが、実際のところ コードを書くことに 本気で取り組めた。

2月

   プロダクトを形成していくのを手伝う
   大方 基本を理解してきた気になる(勘違い)

   わからないことが具体化してきたので, 先輩エンジニアに質問をなげ
   自分なりでいいので 理解できるようになるまで
   聞き続けた、恐らくうざかった

超基礎が 大方理解できてきた時期でもあり, それらを どう使うのか, どう使えば 何が実現できるのか が 少しずつ分かり始めた時期

0 から 1 を 行う ことの 難しさ を 感じた ここでいう 難しさ というのは、1にすれば 完了でなく, 1 → 2, 3, … へと 想定しなければいけない 点において ということ。

3月

   リリースにむけて, 訳のわからないことに立ち向かう
   aws, Linux, dns, route53, nginx, unicorn, httpsの知見を増やす

デプロイなどをするにあたって, 必要な知識が 一気に増える…. https化させるのに 最強につまったり, ドメインの紐付けに なにを 直せばいいのか エラーが出ても, 解決方法が さっぱり な時期。 全くわからなかったので, 知見がありそうな人に 訪ねまくったり, 深夜に サポートセンターに 電話したこともあった(笑)

勉強する際に 心がけたこと

僕自身 ここまで できるようになったのは、周りの 先輩方に 協力してもらったことも もちろんありますが、 勉強する際に 意識していたことは ある。

「 慣れろ 」 より 「 理解しろ 」

体育会系で よくある 「とりあえず やる!!!」みたいなのがあるのだが、

僕はそれが キライだし, ほぼ 意味ないと思っている。

理由としては、コードを書く際に 今 自分が なにしているのか , なんのために それを しているのか わからず, やっていると ,

なんか 知らんけど できた

ここに こうかいてあったから こう書いた

上記のような 状態になる。

いわゆる, コピペ実装。

理解!? そんなの 当たり前じゃん。って思うかもしれませんが、 これまでに , プログラミングしたいです~。 と 教わりに 来たりする人は 意外と そういう人が 多い印象。

理解だ とか 偉そうにいってますが、まずは 自分なりの解釈レベルでの 理解でも問題ないと 思っている。

自分は どう理解したのか 人に 説明できるとなると, 知見のある人と 話を している際に 「それの理解は少し間違っていて ….. と, これは こうで こうなっているから……」と わからないことが 明確化しているので, 両者共に win win な関係になっている。

「これ わからないです。」

って 質問しか出来ない時期は まだ 質問する段階ではない。

そもそも 自分の 実現したいことへの, 必要なものを 細分化できていない。 もっと 自身で 悩むべきだ ( 人や 状況によりけり )

「これの ここって こうだと思うのですけど, ここで このように 詰まってしまって….」

という 自身の見解, 理解ありきの質問ができるようになって 初めて 質問になるの ではないのかな と思う。

もう、小学生じゃないんだから。

あと なぜ はじめに 自分なりの解釈, 理解が 大切なのかというと、

パターン 1

Aというモノ(機能)を 理解せずに 組み立てていると, Aというモノしか 生み出せない。

パターン 2

Aというモノ(機能)の 仕組み を 少しでも理解し、Aというモノを 生み出した。

すると , Aというモノ(機能)の 仕組みは もしかしたら,  B にも 応用が効くかもしれないな...という発想になる。

パターン 2の 方法を 取っているだけで, 「B」という モノ や 機能については、もう 先輩エンジニアと 提案レベルで 話すことができるので、

「それはね、こうあった方がいいから、こういう理由で…」と 別の知識を 学ばさせてくれたり、

「あ、それいいね!! なら, お願いできる!?」っていう 信頼や 楽しさの 発見にも 繋がる。

だから、

何年も コードを 書いてきたが, 変化のない人は

まずは 自分で why を 考えてみよう。

追記 : 僕らの会社規模感, スピード感 での 話ばかりなので 諸説あります。