未経験エンジニア転職において評価されやすいポートフォリオの作り方

 

未経験の状態からエンジニア転職を目指す場合、ほぼ必ずといって良いほどポートフォリオが必要になります。

もちろん、採用においては面接を通じてわかる人柄なども材料視されるため、ポートフォリオの出来が良かったからといって100％内定をもらえるとは限りません。

ですが、ただですら「未経験」という圧倒的なハンデを背負っている中で唯一平等に自分をアピールできるのがポートフォリオなので、なるべく強いこだわりを持って作るに越した事はないでしょう。

 

そこで今回は、2020年1月～3月に就職活動を行った自分の経験をもとに、他のライバルたちと差別化を図るためのポートフォリオ作成戦略について考えてみたいと思います。

あくまで体感ベースなのでバイアスが強くなってしまっている部分もあるかもしれませんが、その辺についてはご容赦いただると幸いです。

 

上辺を飾っただけのポートフォリオはNG

 

まず大前提として、上辺を飾っただけのポートフォリオというのは評価されにくくなっているという点にご注意ください。

たとえば、Railsチュートリアルに沿って作ったアプリだったり、スクールのカリキュラム内で作ったアプリなどはそれに該当する可能性が高いです。

 

確かに、そういったアプリは見た目こそ小綺麗かもしれませんが、ただそれだけなんですよね。

• つぶやき機能を実装しました
• ログイン機能を実装しました
• ユーザー同士のフォロー機能を実装しました

 

実際に深堀りしていくと、「えっ、それで終わり！？」となってしまうような作り込みしかされていなかったりします。

 

別に「画期的な機能を実装しろ」と言っているわけではありません。

ただ、これでは明らかに熱意に欠けていると思われても仕方がないですし、すでにライバルが飽和している環境において「誰でも作れるもの」を持っていったところで勝算は薄いでしょう。

Rails企業の採用基準

2018/07
チュートリアルやってる！採用！

2019/01
ポートフォリオheroku上げてる！採用！

2019/07
ポートフォリオRSpec書いてDocker/AWS触れてる！採用！

2020/01
オリジナリティ溢れるポートフォリオにVue.js/RSpec/Docker/AWS、terraformまで触れてる！…ただコミュ力がなあ

— わん ▽ ミニマルエンジニア (@minimaldisciple) January 22, 2020

特にここ最近はプログラミングスクールのブームも凄いですから、僕たちと同じように未経験からエンジニア転職を目指す人間はゴロゴロといるはず。

 

数年前であればチュートリアル系の教材で作ったアプリにちょこっと手を加えただけでも評価されたかもしれませんが、少なくとも2020年現在においてはそうではないなという風に自分も感じます。

 

実際、僕が選考で訪れたとある企業の面接官は「毎日メルカリやインスタグラム風の個性の無いポートフォリオが送られてきてウンザリ…」といった事を言っていました。

おそらく、スクールの卒業課題などで皆同じようなものを作ってしまいがちなんでしょうね。

多くの企業は「主体性があって自立できる人材」を求めているはずなので、単に「課題の一環として作りました」みたいな姿勢だとなかなか良い印象を与えるのは難しいでしょう。

何かしらの強いこだわりを持って作る事

 

採用担当者は毎日たくさんのポートフォリオをチェックしています。

となれば、ある程度コードを見ればそれがどんな思いで書かれたものなのかも筒抜けに違いありません。

 

いわゆる量産型ポートフォリオというのは、どれもコピペで作ったような内容になってしまいがちです。

たとえば、「ログイン機能にはdeviseを使って…、ページネーションにはkaminariを使って、見た目はBootstrapで整えて…」みたいな感じに。

決してそれがダメというわけではありませんが、皆がやっているのと同じ事をしただけでは高評価にはつながりにくいですし、大勢の中からわざわざ自分を選んでもらうにはやはり説得力が弱くなってしまうでしょう。

むしろ、「主体性の無い人」とマイナスなイメージを与えてしまいかねません。

 

重要なのは、「しっかりと自分の頭で考え抜いてコードを書いた形跡が見えるかどうか」だと個人的には考えています。

 

 

より具体的に説明するために、僕が就活に使用したポートフォリオを例に見ていきましょう。

僕のポートフォリオ

こちらはラーメンのレビューサイトで、一見、特にこれと言って特徴があるわけではありません。ですが、細かくコードを見てみると、実は見えない部分で多くの工夫がされていたりします。

 

たとえば、

• Adminユーザーだけがアクセスできる管理画面
• いたずら登録を防ぐためのメール認証機能
• サイトマップ、メタタグ、パンくずリストなどを用いたSEO対策
• DoS攻撃などに備えたセキュリティ対策
• 万が一例外が発生した場合の通知機能（Slackへ送信）
• 各種APIを利用した便利機能（ソーシャルログインやGoogleマップなど）

 

といった感じで、実際の運用を想定した機能をたくさん盛り込みました。

こういった機能はチュートリアル系の教材でなかなか触れられる事はありませんが、一つのサービスを運用しようと思ったらどれも必要になってくるものです。

 

エンジニアとして働く以上、ただサービスを作って終わりではなく、その後長期にわたって運用していく事も視野に入れなければなりません。

そう考えると、簡単なCRUD機能を実装して終わりとか、CSSでちょこっとデザインを良くして終わりとか、それだけで満足する事はできなかったんですよね。

 

表面的な部分で他のライバルたちと差をつけるには限りがある…。

であるならば、多くの人が見落としがちな「運用」という視点に着目して差別化を図ろう。

そういったコンセプトのもと、僕はポートフォリオを作る事にしました。

 

実際、ただ作るだけでなくその先の運用まで重視した姿勢はどの面接においても褒められましたし、内定をいただく上でかなり有力な判断材料になったのではないかなと今では思います。

 

必ずしも技術的に最高の作品を作れと言ってるわけではありません。

現に僕が作ったポートフォリオより優れたものを作られている方なんて数えきれないほどいるでしょう。

 

ただ、やはり未経験からエンジニアを目指す場合、苦労して試行錯誤を重ねた事がハッキリとわかるポートフォリオの方が好印象を与えられると思うので、何かしらの強いこだわりを持った上で作成に取り掛かるべきだと思います。

僕の場合はそれが「サービス志向」であったという話ですね。

ポートフォリオに取り入れると良い技術

 

ここからは、僕が個人的にポートフォリオに取り入れた方が良いと考えている技術についていくつか取り上げていきたいと思います。

企業側の採用基準は年々上がっていると言われているため、いつまで通用するかはわかりませんが、参考までに。

Git-flow

今は一人での開発が中心になっているかもしれませんが、将来的に転職が決まった場合はほぼ100％チーム開発を行う事になると思います。先の事を考えた場合、Gitを活用した開発手法についても学んでおくべきでしょう。

参照記事：Git-flowって何？

 

また、ただ単にソースコードをGitHubへアップするだけでなく、「Issues」「Pull requests」「Projects」といったあらかじめ備わっている機能も使いこなせると良いかなと思います。

 

たとえば、僕はこんな感じでやるべき事をIssuesにリストアップし、作業内容の明確化を行ってました。

その後、新たにbranchを切って開発を行いpush、最終的にpull requestとして送信してmergeまで持っていくというのが一連のプロセスです。

今回は全て一人で行いましたが、実際の現場でもこのようにそれぞれ役割分担をしながら開発が進んでいくのではないかなと思います。

多少面倒ではあるものの、こんな感じで疑似的なチーム開発を再現するなど一手間かけた工夫を残せると他とだいぶ差別化できるのではないでしょうか。

Rspec

テストをしっかり書いているかどうかも個人的には注目すべき点だと考えています。というのも、実際に未経験者のポートフォリオを見てみると結構な割合で書かれていなかったりするからです。

その重要性の割には疎かにしている方が多い印象を受けるテスト。確かに、文法がやや独特だったりするため、取っ付きにくさを感じるのはわかります。

事実、僕も一番最初にRailsチュートリアルを勉強した際はテストを書く部分でやけに苦戦しましたし、あの教材が難しいと言われているのは他ならぬテストの存在が大きいと思います。

ただ、何度も言うように、皆がやらないという事はそれだけでチャンスになり得るので、これを上手く利用しない手はないでしょう。

 

Railsの場合はデフォルトで「minitest」というテスティングフレームワークが備わっていますが、「Rspec」の方がより凝ったテストができるほか、使用人口も多いみたいなのでこちらを習得しておいた方が良いと思います。

 

「Everyday Rails - RSpecによるRailsテスト入門」

 

ちなみに僕は上の書籍で学習しました。

少し高めですが、Quiitaや個人ブログなどで拾える無料の情報よりも体系的に学ぶ事ができるので、未来への投資だと割り切ってお金を払うべきかなと。

コードチェック（rubocopなど）

Rubyを使用するメリットの一つとして「文法の自由度が高い」という点が挙げられると思いますが、これは逆に考えると人によって書き方がバラバラになり得るという不便が生じる可能性もあります。

特にチーム開発を想定した場合、統一感の無いコードは混乱を招くおそれもあるため、あらかじめルールのようなものを定めておく必要があるでしょう。

 

そんな時に便利なのがコードチェック系のgemです。

• rubocop（インデント、文字数の長さ、メソッド内の行数などをチェック）
• rails_best_practices（「http://rails-bestpractices.com」に掲載されているような綺麗で読みやすいコードかどうかをチェック）
• brakeman（SQLインジェクションやXSSなどの脆弱性につながるコードが無いかどうかをチェック）

 

これらを導入する事により、可読性や安全性を高めつつ全体的に統一感のあるコードを維持する事ができます。

 

しっかりとコードの品質チェックを行っているポートフォリオは「意識の高さ」をアピールする事もできると思うので、ぜひとも取り入れてみてください。

CI/CD

最近は「CI/CD」も当たり前に求められる技術になりつつあるそうです。

実際、僕もポートフォリオを持参した際は「CI/CDもしっかり取り入れてるんですね」と触れられる事が結構な確率でありました。

 

CI/CDとは「継続的インテグレーション/継続的デリバリー」の略称で、テスト～ビルド～デプロイまでの流れを自動で行ってくれるシステムの事。これにより、開発効率が格段に上がると言われています。

参照記事：CI/CDとは

 

たとえば、何らかの開発を行い、それをGitHubのリポジトリへpushしたとします。すると、そのリポジトリに紐づけられたCI/CDツールが作動し、あらかじめ設定した内容のテストが実行されます。

無事テストを通過しmergeまで完了した後、最終的にビルド～デプロイまで行ってくれるというのが一連のプロセスです。

 

version: 2
jobs:
  build:
    parameters:
      assets_precompile:
        description: "Whether or not do assets:precompile"
        type: boolean
        default: false
    docker:
      - image: circleci/ruby:2.6.3-node
        environment:
          BUNDLE_PATH: vendor/bundle
          BUNDLER_VERSION: 2.0.1
      - image: circleci/mysql:5.7
        environment:
          MYSQL_DATABASE: base_project_test
    steps:
      - run: gem install bundler -v $BUNDLER_VERSION
      - checkout
      - restore_cache:
          keys:
            - bundle-v2-{{ checksum "Gemfile.lock" }}
            - yarn-v1-{{ checksum "yarn.lock" }}
      - run: bin/bundle check || bin/bundle install --deployment
      - run:
          name: install yarn dependencies
          command: bundle exec yarn install
      - save_cache:
          key: bundle-v2-{{ checksum "Gemfile.lock" }}
          paths:
            - vendor/bundle
      - save_cache:
          key: yarn-v1-{{ checksum "yarn.lock" }}
          paths:
            - node_modules
      - run:
          command: bin/rake db:create db:migrate
          environment:
            RAILS_ENV: test

      - run: bin/bundle exec rubocop
      - run: bin/bundle exec rails_best_practices
      - run: bundle exec brakeman -5 -A -w 1 -e -z
      - run:
          name: run tests
          command: |
            bundle exec rspec --format progress \
                            --format RspecJunitFormatter \
                            --format progress
      - store_artifacts:
          path: coverage

      - persist_to_workspace:
          root: .
          paths:
            - .

  deploy:
    docker:
      - image: circleci/ruby:2.6.3-node
    working_directory: /tmp/repo
    steps:
      - checkout
      - run:
          name: 'Install Heroku CLI, if necessary'
          command: |
            if [[ $(command -v heroku) == "" ]]; then
              curl https://cli-assets.heroku.com/install.sh | sh
            else
              echo "Heroku is already installed. No operation was performed."
            fi
      - run:
          name: heroku maintenance on
          command: heroku maintenance:on --app ${HEROKU_APP_NAME}
      - run:
          name: Deploy to Heroku_Production
          command: |
            git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_APP_NAME.git master
      - run:
          name: heroku maintenance off
          command: heroku maintenance:off --app ${HEROKU_APP_NAME}

workflows:
  version: 2
  build-deploy:
    jobs:
      - build
      - deploy:
          requires:
            - build
          filters:
            branches:
              only:
                - master

 

僕の例で言えば、こんな感じで設定ファイルを書いておき、コードチェック（「rubocop」「rails_best_practices」「brakeman」「rspec」）に通過した後、masterブランチに変更が加えられた場合のみ本番環境へデプロイするという形を取っていました。

 

CI/CDはいわゆる「モダンな企業」においてはほぼ確実に採用されていると思うので、学習優先度としてはかなり高めかなと思います。

AWS

初学者の場合、アプリを作った後のデプロイ先はHerokuが定番ですよね。基本的に無料で利用できるほか、ネット上で拾える情報の手順に沿って作業すれば大体は上手くいくので非常に便利です。

ここを一旦のゴールとして勉強を進めている人も多いでしょう。

 

ですが、他ライバルたちとの差別化を図るという意味ではAWSなどの使用も選択肢に入れてみるべきだと思います。

従量課金制という点がネックですが、ある程度丸投げでも何とかなりがちなHerokuとは違って自分で設定しなければならない部分が多く（特にインフラ関連）、非常に勉強になります。

実際、僕もAWSに触れた事でわかった気付き（Webサーバーとアプリケーションサーバーの違いなど）も多数ありました。

【使用技術】

開発言語：Ruby、PHP
サーバーサイドフレームワーク：Ruby on Rails、Laravel
フロントエンド：Vue.js
インフラ：AWS(ECS、Aurora、CloudWatch、S3)
データベース・データストア：MySQL、Redis、Elasticsearch、BigQuery
テスティングフレームワーク：Rspec
CI/CD：CircleCI
タスク管理：Backlog、Waffle.io
社内コミュニケーション：Slack、Trello

 

各企業の技術一覧を見てみてもかなりの頻度でAWS関連のツールが使われており、どのみち学習しなければならない分野でもあるため、早めに触れておくべきかなと。

 

あと、Herokuを無料版で使う場合、アプリの起動に時間がかかる（30秒前後）という点も不安材料の一つです。

ただですら採用担当者は忙しいわけですから、そんなところで余計なストレスを与えたくはありません。

もしHerokuを使うにしても、最悪、就活中は有料版に切り替えておくなどしておいた方が良いかもです。

Docker

自分の場合、恥ずかしながらDockerに関しては学習不足でポートフォリオへ組み込む事はできませんでした。

しかし、実際に面接の中で「Dockerを使った経験はありますか？」と聞かれる事も何度かあったので、もし僕がまた就活をやり直す事になったら必ず取り入れたいと考えている技術です。

その他で評価された部分

 

ここまでの内容だけでもだいぶポートフォリオのクオリティは上がるかと思いますが、僕がその他で評価された細かい部分についても参考までに掲載しておきます。

gemの選定に明確な理由を持っている

面接においては「何でこのgemを使っているんですか？」といった質問もかなりの頻度で飛んできます。

参照記事：未経験からエンジニアへ転職する際に面接で良く聞かれた質問まとめ

 

もちろん「それが一番メジャーで信頼性があるから」と答えるのでもそれほど問題は無いと思いますが、ここで「あえてそれを選んでいる理由」について述べられるとまた印象がグッと変わるはずです。

 

たとえば、僕はログイン機能を実装する際、「devise」ではなく「sorcery」というgemを使いました。

人によって好みは分かれると思いますが、やはり世間一般ではdeviseの方が使用人口は多いと思います。

 

なぜ自分はsorceryを使ったのか？それはdeviseに比べてメンテナンス性が高いと感じるからです。

色々な記事でも言われていますが、確かにdeviseは簡単な操作で必要な機能をバーッと実装してくれるものの、必要の無いものまで一気に入ってしまうんですよね。

一方、sorceryは最初に最低限の機能だけ取り入れ、必要に応じて加筆していくというスタイルなので、無駄なコードが混じる事は基本的にありません。

また、自分で逐一コードを書いていくため、内部構造がどんなものになっているのかしっかり把握した上で実装ができます。

 

こんな感じで、なぜそのgemを選んだのかについて細々と話せるようになると、何も考えずにただポートフォリオを作っているライバルたちとの差別化ができそうです。

ルーティングがしっかりと書けている

意外なところで褒められたのが、ルーティングの設定に関してです。

• 「resources」「resource」による記述がメイン
• 「member」「collection」の使い分けができている
• 「namespace」「scope」も必要に応じて使用

 

基本的な部分ではありますが、ぱっと見で何のアクションに結びつくルーティングなのかわかりやすいように書きました。

 

あとは単純に行数が多い事も「熱意」をアピールするのに役立ったと思います。

「routes.rb」を見ればそのプロジェクトの規模が大体わかると言われていますが、未経験者の場合は10行～20行程度しかない事もザラみたいです。

 

もちろん、必ずしも多ければ良いというわけではないでしょうが、それでもやはり実現したい事が多ければそれなりの行数になると思うんですよね。

行数が少ないという事は、それだけ期待できる処理も少なくなってしまうわけで。

routes.rbを見た時にたった数行程度のルーティングしか書かれていなければ、その程度の機能しか付いていないアプリなんだと思われても仕方ありません。

 

僕の例で言うと、最終的な行数は90行くらいありました。

• トップページ
• マイページ
• 管理者ページ
• ログイン機能
• いいね機能
• パスワードリセット機能
• 問い合わせ機能
• 各種API
• etc.

 

一つのサービスを運用する上で必要なものは何か考えて実装していったところ、気付けば増えていたという感じです。

それがどんなアプリなのかを知る上でroutes.rbは頻繁に見られる部分だと思うので、なるべく丁寧に仕上げておくべきだと個人的には考えています。

READMEがちゃんと作り込んである

何度もしつこいようですが、採用担当者は忙しいです。どれだけ自信のあるコードを書いたとしても、それらを全て読んでもらうというのは現実的に不可能でしょう。

となると、ファーストインプレッションとして目にする事になるであろうREADMEは必ず作り込んでおいた方が良いです。

 

• どんなアプリなのか
• どんな思いで作ったのか
• どんな技術か導入されているのか

 

細かくコードを読まずともある程度のサービス概要がわかるようにしておくと、採用担当者も興味を引かれやすくなるはず。

たまにデフォルト状態のままにしている人もいるようですが、どう考えてもヤバいのでちゃんと埋めるべきです。

まとめ

 

以上、未経験エンジニア転職において評価されやすいポートフォリオの作り方について考えてみました。

 

先述のように、あくまで僕の体験ベースなので、必ずしも的を得ているかどうかはわかりません。

ただ、実際に僕はこんな感じのスタンスでポートフォリオを作ったところ、面接へ呼んでいただける事もあったので、ある程度は参考になるのではないかなと思います。

 

細かい技術云々は別に、何よりも大事なのは他のライバルたちと差別化を図る姿勢です。エンジニア転職を狙う未経験者はゴロゴロといるので、彼らと同じ事をしていたのでは勝ち抜く事はできません。

最低限の技術を取り入れつつ、オリジナリティを持たせたポートフォリオを作るのがベストなので、これから作り始めるという方は色々と試行錯誤してみてください。

 

 

この記事が少しでもあなたにとって参考になれば幸いです。