見出し画像

転職するからと"安易に"ポートフォリオに手を付けるのはやめよう

こちらの記事は特にサーバサイドエンジニアに向けて記載した内容です。フロントエンド志望の方にとっては目的が違うので参考程度に読んでもらえればと思います。

この記事は ジンジニア マガジン のマガジンとして書いています。(MENTAのナレッジとしても寄稿しました)

こんなことを考えていたので書いてみました。

ポートフォリオ作成における注意

過去に note で 「で?」と言われないためのポートフォリオという記事を作成しました。詳しくは下記をごらんください。

上記のポートフォリオ作成におけるポイントを要約すると

下記のうちどれを見せたいかを考えて作ろう
・ソースコード(カタチにする力、質)
・プロセス(考え方、こなせる力)
・プロダクト(アイデア、表現力)
成長の可能性である加速度を見せよう

ということでした。

エンジニアにポートフォリオは必要なのか

MENTAの募集でも、ポートフォリオを作りたいのですが、というものをよく見かけます。

確かに、職務経歴として未経験であり自主制作したものがない方は書類選考すら通らないことが多くなっています。一方で私がいくつか拝見したポートフォリオは、むしろその方の足を引っ張っているように思える制作物がちらほら見つかります。

(というわけでついついかっとなってこの記事を書いている次第です)

フロントエンドエンジニアの方についてはUI/UXに関わるパーツとしての制作力が問われるので、経験者であっても制作物の提出が求められるケースが多いと思います。しっかりとポートフォリオを作成し、かつそれをメンテナンスしていくことは重要だと思います。

一方でサーバサイドエンジニアはどうでしょうか。

上記で挙げた

○ ソースコード(カタチにする力、質)
○ プロセス(考え方、こなせる力)
△ プロダクト(アイデア、表現力)

のうち、プロダクト軸が重視して求められるポジションではないと思います。

したがってポートフォリオで表現されるべきなのは

・プロセス(考え方、こなせる力)
 ・フレームワークを用いているのであればその基本的な利用法を調べつつ実装できるのは当たり前
 ・チュートリアルではなくやりたいことを自分の頭で考え、自分の力で実装できる力
 ・最低限、自分で設計したデータベースが存在すること
・ソースコード(カタチにする力、質)
 ・上記ポイントにおいて、チュートリアル的な内容の他にソースコードのボリュームが一定割合あること
 ・それがわかるよう、自分でつけた意味のあるコメントがついている こと
・ テストが書かれていること

これが、最低限だと思います。

加えて、「いきなりコードを書かずに設計書を作る」こともしておくと良いと思います。設計書と言ってもかっちりしたものを作る必要はありません。それぞれの機能または画面に対して、それが何をするものなのかというユーザ視点の仕様で構わないと思います。(言葉で言えば外部仕様書です)

その上で言葉で言えば内部仕様書にあたるデータベースの構造について検討し、その仕様が書かれているとよいでしょう。

ポイントとなってくる力

未経験者が最初に要求される業務について考えてみましょう。

だいたい、以下のようなポイントに絞られるのではないでしょうか。

・ チームのエンジニアが作った機能のテスト
 ・ 可能であればバグの原因をつきとめ、自分でFixできる力
・ 既存の機能を理解した上で小規模な改修
・ 先輩と組んでサポートを受けながら機能開発・改修

最初の2つについては 自走して できることが求められます。ある程度難しい機能について先輩の力を借りることは当然必要かと思います。そうでもない業務については、できるだけ独力で先輩の時間を取らないようにしないと足を引っ張るだけの存在となってしまいます。

※志望動機に「プログラミングが楽しいから」と書いている人。本当にこれで耐えきれそうかどうかはちゃんとイメージしておきましょう。ここを乗り越えられないと楽しい領域へ進むのは難しい可能性が高いです。諦めるなら余計な費用と時間を失わない早いタイミングをおすすめします。

ここでポイントとなるのは

・ 既存のコードを読んで理解する力
 ・実務では書くよりも読むほうが多かったりします
・ わからないことは自分で調べて解決する力
・だめなときは人を頼る力

ですね。いわゆるチュートリアルをやってみる(≠ポートフォリオをつくる)のはこの力を養うことに一番意味があります。

・ なんかわからんけど動かない
・ 書いてあることの意味がわからない

これを、すぐに誰かに聞いてしまうと、その力を身につけるチャンスを失ってしまいます。もちろんある程度頑張ったけれどわからない、ということは時間の効率化のためには必要で、そのためにサービスを利用するのは悪くありません。

書いてあるのを脳死してコピペしていくだけ、というのも意味がありません。それをやっていいのは一定似たような経験がすでにある(例えばRailsはわかっているがDjangoは初めてだという人)だけです。

せっかくチュートリアルやったのだから、という戦略

安易に ポートフォリオに手を付けるのはやめよう、と記載しましたが、ではどうすれば?という点について現時点で考えている戦略です。

<0. チュートリアルをやる>
・ここではチュートリアルの段階ごとにGitでコミットしていきましょう
・これをやることで「チュートリアルのコードなのか、自分で考えたコードなのか」を区別することができます
・これはあくまでもチュートリアルなのでGitHubに乗せる必要はありません
<1. プロジェクトを作成し直す>
・この時点で一度コミットしましょう
・ READMEを書きましょう
・ この段階で現在作ろうとしているポートフォリオとしてのプロダクトの内容として目指すことを書きましょう
<2. Issueを作成して機能(feature)を実装していきましょう>
・ Issueとブランチを対応させて、Issueに仕様、設計方針を記載し、実装していきましょう
・ もし自分で解決できなかった点があればそれについて調べたことなどもIssueに書きましょう
・ これをやっておくことで「人に聞く能力」を高めることができます
・下記の参考記事もどうぞ
<3. 一部の機能をREST APIとして実装しましょう>
分業の進んでいる職場ではAPIの開発がサーバサイド(バックエンド)エンジニアの業務になることがあります。そのため、それができることを表現しましょう。
少なくとも認証が必要なAPIとして実装しましょう。クライアント側はjQueryでもaxiosでもなんでもいいです。よりモダンなもののほうがよいかとは思いますが。

<4. 外部ライブラリを利用したものを入れましょう>
ほぼ唯一、ポートフォリオでオリジナリティを発揮すべき部分はここです。あまりQiitaやZennなどに載っていないライブラリで評価が高そうなライブラリを探し、それを使って出来ることを考えてみましょう。READMEも英語しかないもののほうが良いかと思います。

ここだけは、いわゆる「手段と目的が逆」が許されます。プロダクトの目的はないようなものなので、技術力のアピールが目的なのですから、技術的探究心を目的として良いと思います。

そして、解説記事が存在しないライブラリだからこそあなたがその記事を書ける ことを表現するのです。QiitaやZennに書きましょう。これこそがコントリビューションになり得るのです。

ポートフォリオで表現するべきこと

特にフロント系以外のエンジニアにとって、ポートフォリオで表現するべきことは やろうとしたことができるかどうか に尽きます。

やってはいけないのは できることを並べただけのもの です。採用担当は正直、自己満足に溢れた謎のゲーム実装等を見せられることにうんざりしています。興味があるのは それをやるのにどのくらい苦労したのか。そしてやってほしいことに対してはその経験に基づいてこれから何ができるか でしかありません。コピペしてきて動くようなコードを見せられても「コピペするタイプの人なんだなあ」というマイナス印象しかありません。

極端な話、採用担当はあなたのアイデアには興味がありません

※ 最初はプロダクトのチームに入って活躍して、エンジニアリングも学びながらという戦略を取る場合はその限りではありません。
※ 人事担当が書類選考をする場合にもしかしたら見た目等が良ければ面接にこぎつけるチャンスぐらいは得られるかもしれません。
※ 逆に言えば見た目がある程度整っていなければこの時点で足切りを食らう可能性があります。字が汚い履歴書と同じです。見る気にならない。

どんなポートフォリオを作るべきなのか?という問いに対しては、見せたいものが適切に表現されているもの を作るべきです。必ず自己満足になっていないかチェックしましょう。

これは就活における「エントリーシート」と同じです。自分の長所を、具体的なエピソードをもとに、今後のイメージができるように添えて提出するものです。

このような視点で覚悟を持ってポートフォリオ作成に投資しましょう。
スクールに通ったり、メンターを定期につける場合もあてはまります。ゴールイメージをもって、そのために自分にはどんな支援が必要そうなのかを十分検討して投資しましょう。

メンターやスクール・教材選び等について

支援についてもいろんなパターンが存在しますが、過去自身の学習のスタイルを理解し、適した学び方を取る必要があります。(一般に、下に行けば行くほど費用がかかる気がします)

・やる気はあるがサボってしまうタイプ(パーソナルトレーナーまたは周囲の人に監視されたほうが良いタイプ)
・ わからないことだけ答えてもらえれば良いタイプ(職員室に聞きに行くタイプ)
・ まずは説明してもらってから問題に取り組むのが好き(独学ではなく塾に行くタイプ)
・ 独学しても教材の言ってることがさっぱりわからないタイプ(伴走しながらじっくりみてくれる個別指導・家庭教師タイプ)

これらのうち自身がどれなら継続できそうかで投資先を決めると良いと思います。

自身の学習スタイルの理解についてはこちらの記事もご参考にどうぞ。


いいなと思ったら応援しよう!

てつのすけ(@Tetsunosuke) - まなびプランナー
サポートしてくださるような稀有な方にはサポートしてくださった金額分を奢り返したいと思いますw