サッカーと旅を愛するエンジニア

新米のRubyエンジニアが、フリーランスで生活できる一流エンジニアを目指す! ※発言はすべて個人的なものであり、属する企業の意見を代表するものではありません。🇯🇵🇺🇸🇭🇰🇲🇴🇲🇾🇮🇩🇸🇪🇩🇰🇫🇮🇳🇴🇧🇪🇦🇹🇨🇿🇩🇪🇪🇪🇪🇸🇬🇷🇭🇺🇳🇱🇸🇰🇷🇺🇵🇪🇧🇴🇦🇷🇵🇾🇧🇷🇰🇷🇻🇳🇹🇭🇸🇬

【後編】他の駆け出しエンジニアと差別化するために必要な5つのこと

f:id:knsg16:20190309171549p:plain

この記事は前回のこちらの続きとなっています。

knsg16.hatenablog.com

駆け出しエンジニアには、マストな知識ではないが、知っておいたり、頭の片隅においておいて実装すれば、他の駆け出しエンジニアと差別化できる5つのことを紹介している記事となっています。

前回は、

  • RubyRailsの便利メソッドを使いこなす
  • 保守性への意識

この2点について説明させて頂いたので、今回は残りの3つについて説明します。

  • 速度
  • データを安全にDBに入れる
  • 拡張性

速度への意識

業務レベルになると、速度を意識したコードを書く必要がでてきます。特にtoCの領域だと、「ボタンをクリックしたら、画面遷移するのに1秒くらいかかるから、もう見るのやめよう。」みたいな感じで、折角興味を持ってくれたユーザーの方を逃してしまったりします。

駆け出しエンジニアの頃は、その辺を意識していません。 というよりは、意識してコードを書くだけの余裕がないので、速度を意識すれば差別化できるはずです。

駆け出しエンジニアのレベルで意識できたら、かなりいいなと思うのは、以下の2つです。

  • N+1問題
  • SQLの発行回数

N+1問題はかなり有名なのでご存知の方もいらっしゃるかもしれません。詳細な解決方法はいかに譲ります。

Rails で includes して N+1 問題対策 - Qiita

簡単にまとめると、 indexのページで、レコードをJOINして、情報を表示させたい時に、多くのSQLを発行してしまい、速度が遅くなってしまうということです。

そして、BulletというGemも用意されていますので、N+1を検知して警告をしてくれます。以下の記事で説明されています。

N+1問題を発見しDBのクエリを改善するBullet | 酒と涙とRubyとRailsと

SQLの発行回数にも気をつけなければいけません。 Ruby on Railsで書いている方は、Active RecordというO/R マッパーを利用しているので、意識している方は少ないかもしれません。 しかし、Active Recordの裏側ではSQLを発行しているので、どのActive Recordのメソッドを書けば、 どのようなSQLのクエリが投げられるのかを把握する必要があります。

https://lets.postgresql.jp/documents/tutorial/dos-and-donts/3

こちらのブログから引用すると、

アプリケーションの内部で、特定の条件でレコード数をカウントし、FORループを回してレコード数分のSELECTクエリを実行するようなコードを見かけることがあります

とあります。 これを読んでギクッとした人もいるのではないでしょうか?

SQLの発行回数について、特に意識しないと、SQLをむやみに発行してしまう、速度が遅いアプリケーションになってしまいます。

データを安全にDBに入れる

なにか情報を登録したい時に、MySQLなどを使ってDBにデータを登録する必要があります。その時に、実際に入力してほしいデータが本当に登録されるようにコードを書いてあるか、複数モデルにまたがった時に、リレーションのズレがないように登録するようにできているのかということは非常に重要な観点になります。

この辺の知識とスキルは業務レベルでは必須であるものの、スクールレベルでは解説程度に留められてしまっている印象です。なぜなら、少し高度な内容になってくるので、駆け出しエンジニアの方には、少し難しいと感じる方が多いはずです。こういう難しい話で挫折するよりは、この辺の話は飛ばして、コードを書くことが楽しいと思ってもらった方がよいとの判断でしょう。 駆け出しエンジニアでは以下の2つを意識できれば十分でしょう

  • Transactionロック
  • validationをどこでどのようにかけるか

例えば、Transactionロックとは以下のようなものです。 authorのsaveとbookのupdateの両方が成功しないと、DBに登録できないといった書き方です。 どちらか一方が登録に失敗したら、両方が失敗をするといった感じです。

anthor = Author.new(author_create_params)
book = Book.find(params[:id])
begin
  ActiveRecord::Base.transaction do
    author.save!
    book.update(book_update_params)!
  end
  p '登録完了しました' # トランザクション処理を確定
rescue => e
  p '登録に失敗しました' # トランザクション処理を失敗させて、DBのデータの整合性を守る
end

validationに関しては、 データは、ほしい形で登録したいよという話です。 例えば、会員登録する画面では、メールアドレスの登録が必須だと思いますが、 @マークがないメールアドレスは存在しないので、 taro_yamada.google.jp というメールアドレスが入力されたら、「そのメールアドレスは無効です!」といったアラートを出したりします。

そのように、DBにほしい形で登録したいという設定をする箇所が大きく分けて3箇所あります。

  1. javascriptでクライアント側で防ぐ
  2. applicationレイヤーで防ぐ(modelにvalidationを実装する)
  3. DBのschemaの設定防ぐ

駆け出しエンジニアは、たぶん2のapplicationのレイヤーでmodelにvalidationを実装するという形しか知らないのではない、もしくは実装したことないのかもしれませんが、色んな方法があるということを知っておくと差別化につながると思います。

拡張性

拡張性については、DBの話とメソッドの話があります。 業務に入ると、コードレビューで、どうしてこのテーブル構成にしたのか、どうしてこんなメソッドにしたのかを説明が求められることがあります。

その時に、今の仕様を満たしているだけで、拡張性がないコードを書くと、レビューで通らないなんてこともあります。一度書いたコードは残り続けるので、たとえ、今の仕様を満たしていても、未来のことを考慮できていない書き方だと、新たな機能を追加する時や、業務が変更になった時に対応できなくなってしまいます。

駆け出しエンジニアの時代では、そこまで長期で使用することを考慮してコードを書く訳ではなく、勉強のためとか、ポートフォリオのためとか、発表のためとかいった目的でコードを書くと思います。

実際の業務との大きな違いは、コードを書いて動かすソフトウェアは、業務がなくなったり、仕様が変わったり、会社が潰れたりするまでは一生使い続けます。その点を考慮したコードを書くことができるか、DB設計ができるかが現場では重要になります。

ここをこういう構成にしたのは、将来この業務がこういう変更されることも考慮しています。この仕様がこのように変更する可能性も考慮しています。などといったことが説明できるようなコードを書くことができれば、他の駆け出しエンジニアと1歩も2歩も差がつくのではないかと思います。

まとめ

私自身が、駆け出しエンジニアをやや卒業気味になり、先輩のエンジニアからも面倒をほとんど見てもらうことなく、現場で楽しくコードをかけるようになってきて、その経験を多くの方に伝えようと思って今回の記事を書きました。

他の駆け出しエンジニアと差別化するために必要な5つのことは、自分が現場に入ってから、スクールや独学では理解することができなかったことを抽象化してまとめました。

これからエンジニアになりたい人、エンジニアになるために勉強してる人の役に立つことができればと思います。

【前編】他の駆け出しエンジニアと差別化するために必要な5つのこと

f:id:knsg16:20190224111921p:plain 今回の話は、駆け出しエンジニア時代に知っておきたかった5つのことについてです。

会社にRubyエンジニアとして入社して、はじめは非常に苦労しました。それは、独学ではなかなか身につかないような知識を高速でキャッチアップしなければならなかったからです。

これから話す内容の技術的な知識のほとんどは、会社に入社してから獲得しても遅くはありません。しかし、もし、入社前の駆け出しエンジニア時代に、これらの知識を身に着けておいて、採用面接時にアピールできたら、他の駆け出しエンジニアと大きく差別化できると思います。

独学と業務レベルのコードの違いは以下の5つのことが考慮されたコードになっているかどうかだと、自分は学びました。

  • RubyRailsの便利メソッドを使いこなす
  • 保守性への意識
  • 速度への意識
  • データを安全にDBに入れる
  • 拡張性への意識

RubyRailsの便利メソッドをつかいこなせているか

RubyRailsには多くの便利メソッドが用意されています。たぶん、多くの駆け出しエンジニアは、実装物を動かすのに必死で、どんな場合にどんなメソッドを使うことができるのかということまでに頭が回っていないと思います。自分自身も謎のエラーでハマって、ずっとググっていて、その問題を解決するのに必死だったので、「もっといいメソッドないかな」と思うことなど1度もありませんでした。

しかし、業務レベルでは動くのは、当たり前でもっと完結に書けるのではないかといったレベルの話になってきます。この辺は、場数をこなして業務経験を積みまくって、最適なメソッドを選択できるようになればいいと思います。

Railsの便利なメソッドたち - Qiita

[初心者向け] RubyやRailsでリファクタリングに使えそうなイディオムとか便利メソッドとか - Qiita

こういう記事を見ると、そんな書き方があるのかと勉強になります。自分が業務に入り初めてこんなメソッドあるのかと勉強になったのは例えば、以下です。

駆け出しエンジニア時代には、全く使うことができなかったメソッド達です。

駆け出し時代に少しでも、便利メソッドの存在を頭に入れておけば、他の駆け出しエンジニアとの差別化できると思います。

Rubyエンジニアのバイブルとなっているチェリー本には、色んなメソッドが紹介されていて、その説明が非常にわかりやすいので一度手にとって読んでみることをオススメします。

保守性への意識

前述の通り、駆け出しエンジニア時代はとにかく実装物を動かすのに必死なので、あまり保守性について意識はされないかもしれません。しかし、実際の業務では、一度書いたソースコードは、リファクタリングや不具合修正などで、ソースコードを消さない限り、残り続けます。

そして、そのソースコードは自分だけではなく、自分以外の開発者が読むことになります。したがって、自分以外の人が読んでもソースコードが理解できるような状態にしなければなりません。

具体的には以下の2点をちゃんと考慮できているかという点です。

  • 変数、メソッド名の命名
  • 深すぎないネスト

変数、メソッド名の命名

1点目に関しては、変数やメソッドの命名が分かりやすいものになっているかという話です。変数名から、その変数に格納されている値が、連想できる名前になっていますか?たとえば、Bookクラスのレコードを全件取得して、ある変数に格納したい時に、

#変数名が単数
book = Book.all

このように書いていませんか?これだと、獲得してる値は複数なのに、変数名が単数系なので、変数名と格納されている値がうまく連想できません。

そうではなく、

#複数系にする
books = Book.all

#Arrayで取ってくるなら接尾辞に"list"をつける
book_list = Book.all.to_a

などとして上げるとわかりやすいでしょう。

深すぎないネスト

2点目についても、自分以外の開発者が自分の書いたソースを読んだ時にどう思うのかという点です。

ネストが深すぎるとは、

def hoge
  if(a == 1){
    if(b == 2){
      if(c == 3){
        if(d == 4){
          ...
        }
      }else(c == 5){
        ...
      }
    }
  }
end

こんな状態を指します。これだと、自分で書いてるにも関わらず、どこで、どんな分岐をしているのかどうか分からなくなってしまうことは容易にありえます。

ましては、他の開発者が読んだら、分からないですし、分かったとしても、理解するのに、相当の時間がかかると思います。

そうではなく、そもそもメソッドを切り分けたり、早期returnしてネストが深くならないように工夫しなければなりません。詳細は、他の記事に譲りますが、弊社だとネストは2段階までと決めて実装しています。

以下の記事は、ネストについて詳細に書かれているので非常に参考になります。

新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 - Qiita

コードのネストを深くするな | anopara

「リーダブルコード」を読むと非常に勉強になるでしょう。

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

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

最後に

今回は前編ということで、ここまでにします。

  • 速度への意識
  • データを安全にDBに入れる
  • 拡張性への意識

上記の3点については、後編にてお伝えします。

正直、駆け出しエンジニア時代は、動かすのに必死なのでここまで余裕がないかもしれません。

自分が駆け出しエンジニア時代には、全く知らなかった知識なので、あくまで他の駆け出しエンジニアと差別化したいという意欲の強い方は勉強されていてもいいかもしれません。

Rubyエンジニアになって、新規機能をリリースするまでの10ヶ月 〜TechCampに通う編〜

f:id:knsg16:20190211095220j:plain
image

駆け出しエンジニアはTechCampに通う必要はない

今回はTechCampというプログラミングスクールに自分が実際に通って良かったこと、良くなかったことの共有することによって、プログラミングスクールに通おうかどうか迷われてる方の助けになればなと思いながら記事を書いています。

結論としては、

自分はTechCampに通う必要はなかった

会社のお金で研修として通わせて頂いたので、個人のスキルアップのために会社のお金を使ってくれたことに非常に感謝していますが、TechCampに通って半年たった今振り返ってみると、他の勉強方法で補うことができたのではないかと思います。

Rubyエンジニアになるまでの流れは以下の記事を参考にしてください。

knsg16.hatenablog.com

knsg16.hatenablog.com

TechCampに通う必要のない3つの理由

1.カリキュラムが自分で勉強できる内容だった

TechCampに通う必要がないなと思った一番の理由は、これって自分で勉強できる内容だと気づいたことです。

Tech::CampのWebサービス開発コースに参加して、その後にオリジナルアプリの開発をしたのですが、Webサービス開発コースの内容はほとんど、Rails TutorialやProgateの内容と同じでした。

なので、オンライン教材を使ってRuby on Railsの勉強をしてた自分にとっては非常に物足りない内容でした。

自分もまだ駆け出しエンジニアなのですが、エンジニアになってみて自分で勉強しなければならないことがかなりあると毎日実感してます。そういった学び続けなければいけないWeb系エンジニアになりたいのであれば、これくらいは自分で勉強できないとWebエンジニアとしてキャリアを続けていけないのではないでしょうか。

2.メンターが質問に答えることができない

Tech::Campには学生と思われるメンターが常時待機していて、わからないことがあったら質問をするというシステムでした。

Webサービス開発コースに参加して、その後にオリジナルアプリの開発をしたのですが、オリジナルアプリの開発というように、カリキュラムから外れたような質問になってくると、メンターの方が自分のした質問に答えてくれませんでした。

想像でしかないのですが、たぶんカリキュラムよりも少し高度な内容になると、質問に答えることができないのではないでしょうか。

もちろん、メンターさんの中にはあらゆる質問にすぐに回答してくれるような技術力・技術知識の高いメンターさんはいらっしゃったのですが、その割合は5%以下くらいでした。

どうせ質問しても回答してくれないなら、自分で調べた方が早かったので、教室には毎日通っていましたが、後半はほとんど全く質問をしませんでした。

3.詰まったところを解消するというメタなスキルを学んだ方が早い

駆け出しエンジニアが詰まるところは、経験上2つのパターンに分けられます。

  1. ググり方が下手
  2. ベストプラクティスを把握していないので、知ってる知識の組み合わせで開発をしてしまい、構造的におかしなソースになってしまう。

Ruby on Railsの日本語の情報はありがたいことにかなり豊富です。正しくググることができたら、ほぼ確実に詰まったところの解消方法が見つかります。

しかし、前述した2つの理由で正しくググれないので、ほしい情報にありつくことができないのです。

エンジニアとしてキャリアを積んでいくには、「魚をもらう」のではなく、「魚の釣り方」を学ぶ必要があります。それが、「詰まったところを調べて自分で解決するスキル」です。最初の方はなんで詰まってるのかも分からない状態だと思うので非常に苦しいですが、ここで逃げ出さずに自分で調べ抜くことで、エンジニアとして非常に大切なスキルが身につきます。

誰も教えてくれないググり方 - Qiita

TechCampに通うメリット

自分はTechCampに通うメリットは少ないなと感じたのですが、もちろんメリットがない訳ではありません。

1.教材は超初心者にとってはわかりやすい

TechCampの教材はTechCampに入会した方だけが見ることのできるオンラインカリキュラムです。

【徹底レビュー】TECH::CAMP(テックキャンプ)全コース受講した感想まとめ | ロボット・IT雑食日記

こちらの記事にあるように、TechCampのカリキュラムはオンラインのカリキュラムなので、受講生から質問が多かった箇所などを随時分かりやすくするために更新しています。

なので、超初心者にとっては、カリキュラムが非常にわかりやすいのでありがたいと思います。

2.自分だけで自習だとモチベーションが続かない人にとっては良い環境なのかな?

TechcCampの教室は、非常に集中できる空間でした。自分は渋谷校に通ったのですが、あまり混雑してることもなく、受講生は黙々とプログラミングの学習をしていたので、環境面では非常に良かったです。

自分は自宅でも集中して勉強できるタイプなので、特にメリットを感じなかったのですが、自分の家だと集中できないとか、一人だと勉強を続けることができない人にとっては、プログラミングの学習に集中できる良い環境なのかなと。

まとめ

個人的な意見としては、TechCampで勉強できることはすべてオンラインカリキュラムを使って自分で勉強できます。実際に通うタイプのプログラミングスクールは、金銭的コストが非常に高いので、そこまでオススメできません。

エンジニアとして活躍するためには、常に自分で勉強し続けることが求められます。そうしたトレーニングも兼ねて自分で勉強する力も身に着けたほうが、エンジニアとして成長できると、自分はTechCampに通って感じた次第です。

次は...

次の記事は、実際に業務に入って細かいバグ修正をした話を書こうかなと考えています。

Rubyエンジニアになって、新規機能をリリースするまでの10ヶ月 〜転職活動編〜

転職準備期間から転職活動へ

転職の意志が固まったら、あとは思い切って転職活動をするだけです。実際に自分は、転職活動で2社の内定を獲得したのですが、前職の先輩から誘って頂いた会社に入社することに決めました。

転職活動の準備は事前に完了しているので、怖いことはありません。自信を持って挑戦しましょう。転職準備の方法は以下を参照。

knsg16.hatenablog.com

本記事で伝えたいことは以下の3点です。 - やりたいことをぶらさない - 「やりたい」ではなく「やってる」をアピール - 自分が与えることができることをアピール

転職の準備をしっかりして、転職活動中に以上のようなアピールができれば、きっと結果はついてくるはずです。

エージェントに登録

自分は、まずは転職エージェントの話を聞くことにしました。具体的には、 - ビズリーチ - Wantedly - リクルート

に登録をしました。 まずは、リクルートに登録をしたのですが、こちらが就業しているにも関わらず、繰り返し電話をしてくるので、うざかったので、リクルートをつかって転職活動をするのはやめました。

ビズリーチWantedlyには、自己紹介や自分の経歴などを書くことが求められるのですが、そこは丁寧にしっかりと書きました。具体的には、自分には何ができるのか、どんな思いがあって転職活動をしているのかが読み手に伝わるように書きました。

ここでちゃんと書くと、ビズリーチの場合は、エージェントから、Wantedlyの場合は会社から直接スカウトという形で連絡が来ます。

ビズリーチの場合は、エージェントなので、ここからどんな会社に転職したいのかといったヒアリングを受けます。こちらから、いまの転職市場の状況がどのような状況なのかを積極的に掴みにいきましょう。

カジュアルに話したいという1次面談

Wantedlyでスカウトが来たり、話を聞きたいといったアクションをすると、次は「カジュアルに」話したいという連絡が来ます。お茶でも飲みながら、気楽にお互いのことを知れたらいいですね、といった内容で連絡がくるのですが、惑わされないでください。これは紛れもない1次面接です。

会社は、転職したい人の相談に無料で相談に乗ってくれるほど余裕がないし、暇じゃありません。転職したい人にとっては、話を聞きに行くだけだからという甘い気持ちでいくと、もうその会社から次の連絡はきません。

カジュアルに話たいという連絡がきても、これは1次面接なんだという覚悟を持って、なぜ自分はこの会社で働きたいのかということをしっかり伝えましょう。

なぜ、ここまで言えるかって? 自分が失敗したからです。(笑) カジュアル面談だからといって、何も相手企業のことを調べないで行ったらコテンパンにやられたからです...

印象の良かったアピール

印象の良かったアピールは、自分はどういった貢献ができるかを伝えることができたことと、コードが書きたいだけじゃなくて、実際に書いて勉強しているということを伝えることができたことです。

前者に関しては、自分を雇うことで相手の会社はどういうメリットがあるのかということを認識してもうらう必要があるということです。自分の場合は、社内の業務を効率化できますということを伝えました。自分で問題点を見つけて、実際にコードを書いて、しょぼいツールでしたけど、みんなの工数を70%削減したという話は、成果として認めてもらうことができました。

たとえ社会人歴が短いとしても、なにか自分が会社のために工夫したことがあるはずなので、それを伝えましょう。逆に、自分を雇うメリットを伝えることができない状態ならば、まだ転職の準備が完了してないはずです。いまの環境でできることは何かしらあるはずです。しっかり準備しましょう。

何よりも手を動かすことが重要

自分がRubyエンジニアになりたいということを証明するために、いかに独学で勉強したのかということを示しました。Githubのソースを見せたり、実装物の画面を見せたり、企画書を見せたりもしました。

これがかなり良い評価に繋がったのではないかと実感してます。

エンジニアになりたい人は、やはり手を動かすことが重要です。実際に自分でプログラミングを書いて、何か動くものを作ってみる経験が必要です。

エンジニアになりたいのに、プログラミングを実際にやったことのない人は信用できません。

そして実際に第二新卒の採用に携わって実感したことですが、エンジニアになりたいと言ってるが、実際に手を動かさない人は、なんとなくエンジニアとしてのポテンシャルが低く見えてしまいます。自分でやってみるといいう能力が低い人は、エンジニアになってから直面するであろう問題の数々に乗り越えることができないのではないかと思います。

「やってみたい」と、「やってみた」のあいだにある、大きな差。 | Books&Apps

こちらのブログでなるほどなと思うことが書いてありました。

「やってみた」は、科学。「やってみたい」は、迷信。やってみれば、データが取れる。それを基に、もっとうまいやり方を考えられる。実験ができて、きちんと検証できれば科学だ。

やってみたいでは、先に進めないけど、やってみたらたとえ失敗したとしても先に進めることができる。

Twitterでも、こんなフィードが流れてきて、「その通り」って思いました。

魅力的なオファーという誘惑

ここでは、自分の軸をぶらさないことが大事と思った理由を話ます。ビズリーチで知り合うことができたエージェントからは、自分の進みたい方向(プログラミングを実際にして技術力を高めて、社会の問題を解決する)とは、少し違った方向の職種からのオファーが多かったです。

具体的には、コンサル系や品質保証系のお仕事でした。 勝手にオファーがきたので、特に無視すればいいだけだったのですが、それらがかなり魅力的なオファーだったのが問題でした。誰もが知ってるような会社から、年俸が上がるようなオファーを頂いて、一緒に働いてみないかと言われると、非常に心が揺らぎます。

ただでさえ、転職活動で疲弊しているのに、そんな甘い誘惑をされると、自分が本当に進みたい方向を見失ってしまいます。だから、自分の軸を言語化して、常に確認することが必要です。その軸に沿ってないようであったら、心苦しいですが、オファーを断る勇気が必要です。

失敗談

成功談ばかり話しても面白くないですから、失敗談も話します。Wantedlyで求人を探していたところ、ここで働きたいと思える会社を見つけることができたのですが、ここを乗り越えれば、残りは最終面接という3次面接で落ちてしまいました。

なぜかというと3次面接の内容は技術面談だったからです。実際に画面を作成して、DB構成を考えて、好きな言語で実装をして、自動テストを書くという内容でした。

Ruby on Railsは独学で勉強してきたので、なんとなく動くコードを書くことができるが、それは業務で使用できるレベルではありませんでした。なぜなら、どんな書き方があってて、どんな書き方が間違っているのかを自分では全く判断できなかったからです。

今になって振り返ると、誰かに自分の書いたソースコードを見てもらう必要があったなと思います。つまり、コードレビューをしてもらった方が良かったなと思います。ただ、独学で勉強している段階でソースコードをレビューしてもらう環境を探すのは至難の技です。タイムチケット | 個人の時間を30分単位で売り買い例えば、こういったサイトで、コードレビューをお願いしたりすればいいのですが、なにせお金がかかります。

一番いいのは、仲の良いエンジニアの知り合いに見てもらうかと。

しかし、駆け出しエンジニアには、技術試験のある会社のハードルは非常に高いですね...

まとめ

  • 軸をぶらさない
  • 「やりたい」ではなく「やってる」
  • 自分が与えることができる価値をアピール

これらを実践することで、自分は内定を獲得することができました。転職活動は、採用する立場になって分かったのですが、ただの運ゲーです。

自分がいくら努力しても、自分が影響を及ぼすことができない不確定要素が大きすぎて、ベストを尽くすことはできますが、どんな努力をしてもすべての企業から内定をもらうことができません。

ただ、自分ができるベストを尽くしましょう。 この記事がエンジニアになりたい人への参考になれば幸いです。

Rubyエンジニアになって、新規機能をリリースするまでの10ヶ月 〜転職準備編〜

皆さんは本当に今の仕事に満足していますか?

皆さんは本当に今の仕事に満足していますか? 満足してる人も勿論一定数いるでしょう。 しかし、いざ配属されたら、多くの人が就活で思い描いていた理想の仕事とは異なってることは多いかと思います。

自分は新卒で入社した前職ではやりたいことができずに満足できていませんでした。

knsg16.hatenablog.com

上記のリンクでも紹介したように、 新卒で入社した大企業を1年2ヶ月で退職し、どうやって晴れて希望していたRubyエンジニアになることができたのか?を共有します。

今回は、転職準備編ということで、 前職に在籍していながらも、どうすれば転職への良い準備ができるのかをお話します。

この記事を読むことで、転職活動への良い準備ができて、一人でも多くの人がやりたい仕事(= Rubyエンジニア)に就くことができればと思います。

転職活動を始める前にやった方がいいことまとめ

結論としては以下の4つです。 - 本当にやりたいことが何なのかをはっきりさせる - 家で自分でプログラミング勉強する - 今の環境で自分がやりたい仕事を作り出す - その会社に居続けることで、自分のやりたいことが本当にできるかを判断する。

この記事を読んで伝えたいことはこれらの4つです。 これら4つのことを実践することで、 自分は転職へのいい準備をでき、実際にRubyエンジニアになることができました。

具体的には、転職活動時に以下のような3つのメリットがあります。 1. 転職の決心がつく 2. 転職の軸をブレることがない 3. 転職時の実績を作ることができる

転職活動時に話すことがないのではなくて、自分で事前にじっくり考えて、実際に行動することで、アピールすることができる実績を作りだすのです。

転職の話をする前に自分の新卒での就職の話をします

新卒では、大手ERPパッケージメーカーに入社しました。その理由は、「自分でプログラミングをして開発して社会問題の解決」をできる人材になりたかったからです。

社会人になることってどういうことだろうって自分なりに考えてみて、「社会の問題を解決する人」が社会人だという結論に達しました。

社会の問題のどういう問題を解決したいのかは、その当時決まっていなかったのですが(今もそこまで良くわからないですが...)、自分で問題を見つけて、自分で解決できたら達成感もあって面白いだろうなと考えました。

実際に問題を解決をする手段としては、色んな解決方法があります。自分がITを選んだ理由としては、様々な原体験があるのですが、ここでは割愛させて頂きます。大まかな理由としては、手に職をつけることができインパクトの大きい解決ができる、かつ、市場価値の高い人材になることができるという3点で、エンジニアになることを決意しました。

研修で下手こいて配属先は品質保証部

前職の大手ERPパッケージ会社は面白い会社で、かなり変わった研修でした。研修という名の、テストみたいなもので、「○○を解決するソフトウェアをつくれ」というお題を一文だけださます。そのお題に対して、自分で企画書を書いて、自分でプログラミングをして開発して、審査員に対して、お題の問題を解決することが証明できれば研修が終わりです。

その研修は、順位で競うモノであり、早く解決した人が早く研修を終え、希望の部署へ配属されるというものでした。自分は色々あって、研修で失敗してしまい、自分が希望する実際にプログラミングを書くことのできる部署への配属を逃してしまいました...

自分が配属されたのは、品質保証部でした。 品質保証部は、商品であるソフトウェアのプロダクトの品質を保証するために、テストを実施、設計する部署です。そのテストを作成するために、ユーザーの業務をヒアリングして、ユーザーの業務がバグなく実行できるための動作保証をするためのテスト設計などをメインで行っていました。

仕事はやってみると意外に楽しかったのですが、「本当に自分がやりたいことって何だったっけ?」「自分って何のためにこの会社に入ったのだろう」と考える日が続くようになりました。

自分で勉強する

プログラミングをして実際に開発したいのですが、仕事でできないので、自分の家で勉強してやってみることにしました。

具体的には、ProgateとRails tutorialを始めました。その2つが終わったら、実際に自分でオリジナルのアプリをRuby on Railsで開発していきました。

Ruby on Railsを勉強始めた理由は、よく分からなかったので、なんかRuby on Railsを勉強しておけば色んな仕事が今はあるっぽいくらいの情報をググって見つけたからでした。

Rubyエンジニアとなった今では、RubyPHPの違いとか、Pythonはこういう言語だとか分かるようになったのですが、正直この段階ではそんなに分かっていませんでした。Rubyの情報は日本語で多いから、使ってる人が多い、つまり、Rubyの案件が多いだろうくらいの推定でRubyを始めました。

大事なことは、 「やりたい」ではなくて「やっている」ということです。それを継続して続けることができているか、すなわち、今回の場合に当てはめると、「Rubyをやりたい」ではなくて、「Rubyの勉強を自分でしていて、業務で使ってみたい」と説得力を持たせて他人に説明できるだけの根拠があるかどうかです。

採用担当をしている現職の同僚のエンジニアに聞いた話ですが、「実際に行動できている人、つまり、独学でいいからコードを書いてる人とコードを書きたいと思ってる人の差は大きい。コードを書きたいと思ってるだけの人は、もし採用したとしても、自主的に勉強しないようなタイプだろうし伸びしろが少ない。」と仰っていました。

上司に相談しても、会社で実装できる部署はあまりない

実際にRuby on Railsの勉強を進めて、実績もできてきたので、上司にアピールをして、移動願い(転部)を部長に出しました。

自分の頑張りを部長は認めてくれて、実際にその願いを叶えてあげたいと行ってくれました。しかし、大きな問題があったのです。

全社的な方針として、 実際にプログラミングを書く業務は、インドに発注することに決まっていて、日本では仕様の設計などがメインになるとのことでした。

この知らせを聞いた時は正直途方に暮れました。今まで自分が勉強した意味は何だったのか?そもそもこの会社に入社した理由はなんだったのかを、この事件をきっかけに考えるようになりました。

この会社に残り続けて自分のやりたいことを実現するためには、数少ない日本の開発部署に移動するか、インドに移動するかの2つしか残されていません。

その難易度は非常に高く、いつになったら実現できるのか検討もつきませんでした。そうした時に、初めて転職ということが頭によぎりました。この会社では、プログラミングを書く仕事に就くのは難しいけど、他の会社ではどうなんだろうとか思うようになりました。

自分でツール作成で、無理矢理プログラミングをする仕事を作り出す

実際にプログラミングをする部署へは移動できないどころか、実際にプログラミングをする部署がほとんど国内から消えるという事実を知って、途方にくれていたのですが、ひょんなことから、品質保証部にいたまま、プログラミングをすることができる機会を得ることができました。

品質保証部では、バグの管理を行っているのですが、 3ヶ月ごとにどんな種類のバグがどれくらいあるのかを示す報告書を作成していました。その資料を元に偉い人達が製品をリリースしていいかどうかを判断するといった具合です。

その資料の作成は、かなり憂鬱で、偉い人たちが見るので集計にミスがあっては駄目なのですが、かなり大きい製品を扱っていたので、バグの種類や数は膨大でした。

Redmineというバグを管理するシステムを使用していたのですが、csvでバグの情報を吐き出して、そこからローカルのExcelで集計結果を得るために加工していくという手順でした。

ある日、上司がこれ自動化できたら便利だなと言ってたのを思い出し、全く経験もなかったのですが、自分で自動で報告書を作成するツールを作ることにしました。

業務以外の時間を使って、 ツールを作り出し、3ヶ月後に完成しました。 効果は絶大で、報告書の作成工数を約70%削減することに成功しました。この成果は認められて、品質保証部内で新人賞を獲得することもできました。

この当時は、 自分で開発経験もできたし、部署内の問題も解決できてみんなハッピーだし、表彰もされたしで満足していました。しかし、全く予期していなかったのですが、この成果は転職活動時に最も評価されたポイントでした。

成果のポイントとしては、 1.実際にプログラミングを書きたいという気持ちが伝わる。 2.自分で問題を見つけて解決した。 大きく分けると以上の2点でした。 このことは、別の記事で詳しく触れます。

自分が本当にやりたいことは何だったのかを再認識する

品質保証部内でプログラミングをする機会を得ることができたのは良かったのですが、そのプログラミングは、業務レベルからはほど遠くツールとしては、不完全なモノでした。

周りにプログラミングをかける人がいないので、どうやったらもっとよくなるのかを自分ひとりで実行するのは限界だと思い、やっぱ転職して、開発部署に入りたいと再び思うようになりました。

新卒で入社をしてからは、あまり社外の人と関わることがなかったのですが、少し気持ちが整理できないので、社外の人に会ってみることにしました。

東京ですと、conpassとかサポーターズで勉強会やミートアップを気軽に見つけ、参加できます。また、大学の同期とか、前職を退職されて仲の良かった先輩などにお話を伺ったりして、当時の自分の状況と気持ちを伝え、相談に乗っていただきました。

心のどこかでは、もうこの会社は自分のいるべき場所ではないということは分かっていたのですが、どこか踏ん切りがつかず、それから何ヶ月も退職しようかどうか悩んでいました。

悩んでいる理由としては、こんな早く転職していいものか?ということでした。自分の経験上、辛くても逃げ出さなかったことで、いい大学にも入れたし、交換留学の審査も通ることができたし、練習が辛いサッカー部でも辞めることなく、最後まで続けることができたという成功体験が自分の決断の邪魔をしていました。

そんな時、前職を退職されて仲の良かった先輩に為末大さんの「諦める力」という本を紹介されて読むことで退職を決心できました。本書では、「諦めることは逃げることではなく、戦う場所を変えること」と説明されていました。オリンピックでメダルを取った陸上選手も、100m走でメダルを獲得することを諦めて、400mハードルに種目変更したそうです。為末大さんの目的は、オリンピックでメダルを取ることであったのですが、身体能力的にも学生の段階で100mで世界を取りにいくのは難しいと気づいたそうです。

大切なのは、目的をどう達成するのかであり、目的を諦めなければ、逃げたことにはならないという考え方です。

諦める力 〈勝てないのは努力が足りないからじゃない〉

諦める力 〈勝てないのは努力が足りないからじゃない〉

自分のケースに当てはめると、 「自分でプログラミングをして開発して社会問題の解決」ができるような人材になることを目的として、前職に入社をしたが、前職では目的を達成できそうではない、つまり、プログラミングを実際することができる環境ではないので、転職をする。転職をすることは、目的を達成するのに、いまの会社(前職)にいるよりも、近道だと捉え直すことにしました。

まとめ

繰り返しになりますが、自分はこのような経験や行動をして、以下の4つが重要であると認識しました。 - 本当にやりたいことが何なのかをはっきりさせる - 家で自分でプログラミング勉強する - 今の環境で自分がやりたい仕事を作り出す - その会社に居続けることで、自分のやりたいことが本当にできるかを判断する。

この4つのことをしたことで、後述します転職活動編で、実際に転職することに成功したのではないかと分析しています。

自分の前職と全く同じ環境にいる人は少ないと思いますが、読者の方々の今の環境で実行できることは多くあると思います。この記事を読んで頂き少しでも手助けできればと思います。

次は、転職活動編です。 読んで頂きありがとうございました。

Rubyエンジニアになって、新規機能をリリースするまでの10ヶ月

こんにちは。knsg16です。 新卒で大手ERPパッケージメーカーに入社し、 1年2ヶ月で退職し、 いまは株式会社おかんでエンジニアとして働いています。 主に契約管理、配送管理の社内システムをRuby on Railsで開発しています。

これから複数回に渡って、 どうやって文系卒の自分が 大企業を1年2ヶ月で辞めて、 Rubyのエンジニアになっていったのかを紹介していきます。

この記事を書く目的

テスターだった自分が どうやってRubyのエンジニアになったのかを紹介することで、 未経験からRubyエンジニアになりたい人への少しでもアドバイスになれば と思い記事を書くことにしました。

この記事を読んで欲しい読者

  • 現状の仕事に満足してなくて、未経験からRubyエンジニアになりたい人
  • 転職活動しようとしている人
  • プログラミングのスクールに行こうか悩んでいる人

内容

この記事を読むことによって 転職を考えている人が、 どうやったらRubyのエンジニアになることができるのか の参考になればと考えています。

転職するまでの流れは以下の通りです。

  1. 転職準備
  2. 転職活動
  3. Tech Campに通う編
  4. 株式会社おかん入社

いま株式会社おかんでRubyエンジニアとして働くことで、 会社に行きたくないと思ったことはほとんどなく(全くなかった訳ではない、めっちゃ眠たい時とかはたまに思う)、 豊かな働き方を実践しつつ、 エンジニアリングを通じて、社内の問題解決に取り組んでいます。

読者の方の転職が成功するために、 これをやっといて良かったなと思うこと、 もっとこうしておけば良かったなと思うことを 具体的な事例を紹介しつつ更新していきます。