背景
ここ数年間は、筆者が採用周りの仕事も増えてきて、そしてカジュアル面談などでも特に学生さんを中心に「就職するために必要なスキルやレベルを教えてほしい」とか、「自分のスキルが会社の開発業務でも通用するかわからない」的なご相談を多くいただいております。
確かに学生のうちは、企業での長期アルバイト経験がある方を除いて、ほとんどの人は社会人経験が皆無と言っていいでしょう。そんな中で不安を覚えるのも無理はありません。というわけで少しでも企業でのエンジニアとしての働き方のイメージが明確になれたらと思いながら、この記事を綴らせていただきました。
免責事項
この記事の内容については、あくまで筆者の経験に基づいた話であって、全ての企業に通用するわけではありません。ただ大きくかけ離れたことはおそらくないと思います。
本文
学生のうち、特に情報工学の経験がなく、あくまで趣味駆動でプログラミングを始めた学生さんは、ほとんどの場合ひとり開発をやってきたのではないでしょうか。ひとり開発はとても貴重な経験です、なぜならそれは一つの課題を解決するのに、アプリなりサービスなりを全て一人で終わらせないといけないからです。その過程では UI 構築、スレッド制御、アルゴリズム最適化…などなど、非常にたくさんの分野の知識を必要とするから、目まぐるしい成長をもたらします。
でも当然ながら、社会人エンジニアはそれだけでは足りません。社会人は基本チームで開発しているからです。そして出来上がった成果物を長年掛けて保守する必要もあるからです。というわけでこれから就職して社会人エンジニアとして必要なことをリストアップしていきたいと思います。
国語力
意外かもしれませんが、私がまず一番大事だと思ってるのはプログラミング自身のスキルではなく、国語力です。正確には「コミュ力」かもしれません。これは要するにお互いの意思疎通が不自由なくできる、と意味します。
チーム開発は、要するにチームプレイですので、どんな分野でもチームワークが重要です。そしてそのチームワークをきちんとこなすには、意思伝達が必要で、お互いどんな目標を達成したいのか、どんな制約を受けてるのか、どんな妥協なら許せるかなどなど、コミュニケーションで擦り合わせなくてはならないことがたくさんあります。それができる前提としては国語力が必要です。自分の伝えたいことが相手に伝わらなくてはならないし、逆に相手の伝えたいことも理解しなくてはならないです。
一つわかりやすい例を出すと「オフショア開発」でしょう。別にオフショア開発を否定するつもりはないですが、ただオフショア開発の失敗例が非常に多いのもまた事実です。そして失敗したケースは、ほとんどの場合根本的な原因は「コミュニケーション」にあります。思ってた仕様と違う、納期が守られていない、品質が低い…などなどの結果は、ほとんどの場合現地のエンジニアのレベルが低いからではなく、「そもそもお互い通じ合ってない」からです。逆に言うとコミュニケーションがうまく取れてるオフショア案件は成功率も高くなります。
ちなみに最初に述べた通り、大事なのは「お互いの意思疎通が不自由なくできる」ことであって、別にいわゆる「陽キャ」だったり「パリピ」だったりと言った次元の話ではありません。プログラム仕様レベルで事実を伝えられる、そして伝えられた事実が理解できる、もし不明点があったら勝手に自己解釈せずにすぐその場で聞き返して確認を取る、と言ったコミュニケーションの基本の話です。
コードの可読性／保守性
ようやくプログラミングの話に入りましたね。
ひとり開発、特に学生の頃の趣味駆動のプログラミングのとき、多くの場合何か一つの課題を解決するのが目的です。その場合、ソースコードを書いて欲しかった結果が得られれば十分です。その後、バグ修正を除いて長期的にメンテすることも少ないでしょう。そしてするにしても、自分以外の人がソースコードを読むことあまりないでしょう。
ところがチーム開発の場合は、我々エンジニアはソースコードを書く時間よりも、読む時間の方が多く占めてしまいます。しかもそのソースコードが他人が書いたコードの可能性も高いですし、逆に自分が書いたコードが他人が読むこともたくさんあります。さらに会社は基本的にサービスを長期的に運営し続ける前提で計画を立てているため、出来上がったプログラムも一回きりではなく、何年もかけてメンテしていく必要があります。この時、ソースコード自体の可読性や保守性の重要性が非常に高くなってきます。ソースコードの可読性が低かったらただでさえ限られた時間の多くをコードの解読に割かなくてはいけず、実装に使える時間が減りますし、そして保守性が低かったらコードをいじるたびに思わぬところに影響を及ぼし、バグを生み出したりバグ修正のつもりがさらなるバグを引き出したりします。
コードの可読性を高めるにはぜひ「リーダブルコード」を読んでみるといいでしょう。そして保守性については多くのプログラミング原則を一通り読んでみるといいかもしれません。ただこれらを完全に身につけるために、そしてなぜこう書くと読みやすい、こう書くと保守しやすいかを理解するためには、やはり自分で何か一つのアプリを、最低でも 1 年以上かけてメンテしてあげた方がいいかもしれません。
コードレビュー
学生時代の個人開発は、コードレビューなんてしたこともされたこともないでしょう。自分が書きたいコードだけ書いてコミットして、意識が高かったら形式的に PR 出してそのままマージし、そこまで高くなかったら PR も出さずにそのままマージするなりそもそもブランチ運用すらなかったりするでしょう。（あ、もしかするとそもそもバージョン管理すら使ったことない人もいるかもしれませんが、学生時代の開発としては特に問題はないと思います。）
しかし弊社を含め、ほとんどの会社でのチーム開発はコードレビューがあると思います。それはもちろん自分が提出したコードを誰かベテランエンジニアがレビューしてくれますし、逆にベテランエンジニアの書いたコードも自分がレビューしないといけないかもしれません。
「え？私なんかレベル全然低いのにベテランの書いたコードをレビューする立場あるの？？」と思うかもしれませんが、あります。むしろ必要です。
まずベテランエンジニアも含め、誰でも間違いを犯す可能性があります。軽い typo のような間違いは、初心者エンジニアでも十分に気づくことが可能で、そして気づいたら指摘してあげる必要があります。
そしてコードレビューは、提出されたコードが間違ってないかどうかを見るだけではありません、むしろ逆に書いた人の考え方を読み取ったり、さらにはその書き方を学んだりする機会でもあります。
もちろん最初は緊張したり、そもそもコード差分がよくわからなかったりすることも多々あると思います。でもここで大事なのは自分のことを棚に上げて、そして気になることやわからないことはそのまま聞くことです。繰り返しになりますがチーム開発はコミュニケーションが大事で、チームで共通認識を作ることが必要です。コードレビューはそのための重要なツールの一つです。
そしてこのコードレビューの流れを今のうちに慣れておきたいなら、今からでも全然遅くないので、自分の書いたコードをそのまま反映させるのではなく、一回 PR に出して、その PR の差分を自分で見直してみてください。きっとコードを書く時に気づかなかった発見もたくさんあると思います。
キャッチアップ力
勉強は学生の本分だと思われがちですが、もちろんそれは間違いではないですが、社会人になっても勉強は必要です。
よく「XXXのライブラリー／SDK／設計は学生のうちに勉強した方がいいですか」的な質問を頂きますが、実はそう言った技術的トレンドは移り変わりが非常に早いです。筆者がいる iOS アプリ開発業界を例として挙げても、ほんの数年前までは RxSwift × MVVM が一番ホットなアーキテクチャと言っても過言ではなかったが、SwiftUI と Combine の登場により時代が一気に Redux や TCA を始めとした関数型＆単方向データフローアーキテクチャに移り出しました。今後も新技術の登場が絶えないでしょうから、今現在が学生の皆さんが就職した暁に何が一番トレンディーか我々でも判断が難しいです。
なのでどんな技術スタックを持ってるか以上に、どんな技術スタックでもすぐにキャッチアップできる能力の方が重要になってきます。そのキャッチアップのための情報収集力、ドキュメント解読力、そしてエラー解決力などの方こそ、今のうちに鍛えておいた方がいいと思います。率直に言うとほとんどの企業は学生さんの即戦力を期待していないと思います（もちろんあるに越したことはないが）。期待してるのは「ポテンシャル」です。そのポテンシャルというのは、必要な技術スタックをどれだけ早いスピードでキャッチアップできるかですので、ちょっとメタい言い方になりますが、「勉強の仕方を勉強した方がいい」です。
まとめ
新米社会人エンジニアとして必要なことをひとまずこの 4 つを挙げてみました。もちろんこれだけでは足りないかもしれませんが、筆者としてとりあえず一番大事だと思ったことをリストアップしたまでです。補足等がもしあればぜひコメント欄でいただけたら幸いです。
そして就職活動されてる学生の皆さんも、理想の就職ができますよう陰ながら応援させていただきます。