新人エンジニアが振り返る、学生・インターン・正社員におけるエンジニアリングの違いと3つの学び

はじめに

こんにちは、2022年新卒の河原です。

突然ですが、皆さんは今までどのような開発体験をされてきましたか？
学生時代からゴリゴリに開発していた人もいれば、全く違う職種から独学やプログラミングスクールで学んでエンジニアリングに携わっている人など、人によってキャリアは多種多様だと思います。

私の場合はこれまで、学生・インターン・正社員としてシステムの開発に携わってきました。まだ社会人になってから1年と少ししか経っておらず、学生時代の経験もある程度は新鮮に覚えています。

この記事では、そんな私が学生・インターン・正社員でのエンジニアリングを通して痛感した『開発体験の差』と、今後に活かしたい『3つの学び』をご紹介したいと思います。

日々の業務に追われ、過去を振り返ることを忘れがちになっている方々が「私もこんな経験があったな」「僕はどう成長してきただろうか」と思い出す・考えてみるきっかけになるような記事になれば嬉しく思います。

自己紹介

まずはじめに、自分の経歴を軽く紹介させていただきます。

学生時代、高専でコンピューターサイエンスを広く浅く学び、情報系の大学・大学院へ進学して情報系に特化したことを学んできました。
研究は、自然言語と音声といった複数の感覚次元を機械学習させるマルチモーダル感情認識を題目として扱っていました。当時はまだ最近話題のGPTの「GPT-2」が論文として発表され、様々なベンチマークを更新し、GeneralなLLMの台頭にワクワクしていた思い出があります。

その後レバレジーズに内定し、「早くから社会で通用する本格的な開発経験を積みたい」と思い、2021年の8月からエンジニアとして早期のインターンを始めます。
インターンでは、未経験のエンジニアが中心で構成された教育目的のチームにて、小さめの社内システムを要件定義・技術選定から設計・開発まで一通り経験させてもらえました。

そして、去年4月に正社員として入社し、現在は正社員として、若年層領域の事業を展開する『ハタラクティブ』や『キャリアチケット』というサービスで、営業職が使用するSFA（Sales Force Automation）開発に携わっています。
今のチームに移動してきて1年ほど経った状態です。

学生と社会人の違い

開発の『目的』

私が学生と社会人（インターン・正社員含む）で感じた開発体験の最も大きな違いは、開発の『目的』です。
どのように目的が違うのでしょうか？私の経験と合わせて、具体的に説明していきたいと思います。

私の学生時代は趣味や学業の一環で、簡単な

2Dゲーム
組み込みシステム
Webシステム
AIモデル構築

など様々な開発をしていました。
これらは、学業で必要になったり、興味関心が沸けば「開発してみる！」といった具合で、特に大きな目標はなく『開発を楽しむ目的』でいろんな開発をしてみていました。

しかし、どれも『システムが完成して目的を達成すれば、開発も終わり』のような拡張性がなく、モチベーション頼りの単発な開発でした。
結果として、作り上げたシステムとしての品質は高いとは言えず、技術的な深掘りもあまりできておらず、また自身の能力的が成長した実感もあまりありませんでした。

それに対して、社会人での開発目的は『利益を生み出す目的』へと変わりました。
社会人は全員「ビジネス的な視点」を持つ必要があります。
それはエンジニアも例外ではなく、開発したシステムを含めて、最終的には市場において競合優位性を確保する「サービス」を作り上げて『利益を生み出す目的』に合致したシステムを開発していく必要があります。

観点の多さと責任範囲

目的に付随して『責任』や『観点』にも違いが生まれてきました。
学生時代の開発観点は、システムの機能性ばかりに注目し、「とりあえず動けばOK！」のような考えが先行していた記憶です。

対して、社会人では利益を生み出すために正確で安全なシステムが、迅速にリリースされる必要があります。
そのため、開発観点はさらに多角的になり、

コードの可読性
保守性
スケーラビリティ
アジリティ
セキュリティ

などの品質を満たした開発が必要になりました。

責任の変化なども加えて、感じた特徴の違いをまとめると以下になります。

	学生	社会人
目的	開発を楽しむため	利益を生み出すため
モチベーション	・興味のあるものを作ってみたい・学業で必要になったから	・システム、サービスをグロースさせたい・社会に役立つシステムにしたい
開発物	いろいろ	Webシステム
開発期間	完成すれば終了	継続的な利用がされる
開発観点	・機能性・正確性（上記も品質は低い）	・機能性・正確性・保守性・スケーラビリティ・アジリティ・セキュリティなどなど…
責任	基本自分のみにかかる	システム、サービス、会社全体へ影響することもあるため大きい

開発に向かう姿勢

ここまでで、違いを紹介してみましたが、決して学生時代の開発が良くなかったわけではありません。

学生時代の自由な開発がなければ、そもそもエンジニアリングに携わってみようというモチベーションも発生していなかったかもしれません。また、どんなシステムでも作ってみることで、わかることはたくさんありました。
現在も、興味のある技術があれば、上手く開発できるかどうかはさておき触ってみたりしています。それは、個人開発の自由さと楽しさを知っているからだと思っています。

しかし、私個人としては作成したシステムが利益につながりより多くの役割を果たすことで、社会の役に立っていると実感できる社会人での開発の方が楽しく感じています。
これは、元々アルバイトなどの仕事が好きであった私の性に合っていたのかもしれないですが、システム開発を通して利益を生み出し、サービスをグロースさせるのは社会人ならではの醍醐味だと感じています。

インターンと正社員の違い

続いて、インターンと正社員で感じた開発体験の違いについてです。はじめに、それぞれの業務内容を説明します。

インターン時代は、小さめの社内システムを要件定義・技術選定から設計・開発まで一通り行いました。新規システムであり、かつ規模も小さいことから採用した技術はモダンなものが中心でした。

そして現在は、正社員としてSFA開発に携わっています。 SFAは、営業プロセスの自動化・効率化を行い、業務上の顧客の流入から売上の確定に至るまでの全てのデータを一元化することで、

営業業務の効率向上
データ分析による戦略の立案
施策の効果検討

など多方面に役立てられています。営業・マーケティング・企画・データ戦略室といった関係者が存在し、システム自体も8年ほど前から存在するため、非常に高機能かつ規模も大きめなシステムです。

開発はスクラム体制で、新規機能開発とCakePHP→Laravelへのフレームワークリプレイス作業がメインです。
技術選定やインフラに触れる機会は減りましたが、複雑な要件を把握して適切なソリューションを考案し、設計・開発を通して解決していくことは、良いエンジニアリング経験になっていると感じています。

それぞれの特徴をまとめると以下のようになります。

	インターン	正社員
特徴	社内で利用目的の新規システム	約8年前から開発・運用しているSFAシステム
目的・要件	シンプル	複雑で多種多様
規模	小さめ	大きめ
機能	少なめ	多め
関係者	・主にエンジニア・関係者数が少ない	・営業、企画、マーケティングなど・関係者数が多い
技術	モダンなものが中心	新旧混在
担当業務	・要件定義、技術選定・設計・開発	・運用保守業務（フレームワーク移行・インシデント対応・法務対応）・新規機能設計・開発
開発	FE・BE・インフラ全て	BE中心
開発体制	ウォーターフォール	スクラム

システムの『役割』の理解の深さ

特徴や規模、言語・技術が全く違う2つですが、ここで感じたことは「システムの役割を理解する必要がある」ということです。

インターン時代は、『新規社内向けシステム』ということもあり、純粋にエンジニアとして開発に必要な知識や経験を培い『Webシステムの開発』に注力することができました。
これは当時いたチームの目的が「手を動かしながら学習して、PDCAを回し、システム開発に必要な基礎を身につける」ことにあったためです。
作成していたシステムを振り返ると、未経験中心のチームであったこともあり、決して品質が高いとは言えませんでしたが、チームの目的を達成するための役割は果たしていたと思っています。
私個人としても、当時未経験でありながら、包括的な開発体験をさせていただけたことはとても良いファーストキャリアになったと思っています。この時の

業務で知識不足を痛感する
知識不足と感じたことを学習する
学習した内容を業務に活かす

というエンジニアにとっては当たり前のサイクルが、開発体験上大きな成長実感をくれました。

対して、現在の『SFA開発』は、サービスの根幹を支える基幹システムです。メリットである機能の多さやデータの一元化の対価として、デメリットは、

8年前から存在する古いコードと新規のコードが混在すること
複雑な要件・関係者が多いといった特徴による開発の鈍化

などが挙げられます。これは、例えば、新規機能開発にてテーブル構造を変えれば、そのテーブルを分析に利用しているマーケティング職の業務に影響が生じたりします。

そんなSFAの役割は何に当たるでしょうか？
これは明確で、SFAの利点が上げられると思います。開発した機能や蓄積したデータ活用によってビジネス的な利益に結びついているためです。そのため、『機能性・拡張性・保守性・セキュリティが比重重めに重要視される』反面、相対的に『UI/UXといった使用性は軽視される傾向になる』ことはあります。

システムの役割が明確で、開発に軸があることで、数々の開発タスクの優先度や重要度を振り分け、サービスや組織全体にとってより良い開発を進めることができています。

システム品質特性は様々な観点がありますが、優先・重要視される観点は『システムの役割』によって多面的に変わると思います。皆さんが携わるシステムはどんな特性を重要視されていますでしょうか？

3つの学び

これまでで学生時代から、インターン、正社員での開発体験の違いを説明してきました。

開発のポートフォリオも目的も技術もそれぞれ違いますが、これらを通して痛感した、以下の3つの学びがあります。

新しい技術が最適とは限らない
負債を生む可能性を常に考慮する
基礎が大事

新しい技術が最適とは限らない

インターン時代は、frourioと呼ばれるフルスタックフレームワークで用意したTypeScript・Next.js・Material-UIなどを用いた開発を行っていました。
対してSFAは、BEはphpのフレームワークであるCakePHP・Laravel、FEはscss、jQueryとReact・Graph-ql（JavaScriptとTypeScript）が混在しています。

インターン時代は新しめの技術が中心でしたが、当時は自分やチームのメンバー含めて、Webシステム開発の知識や経験が浅かったこともあり、以下のようなことが起きていました。

インターネット上に参考となる事例が少ないことによる開発のつまづき
発展途上の技術は、カバーされてない箇所もあること
扱う人の知識不足で各技術の利点を活かしきれていないこと

あるあるだと感じる人も多いのではないかと思いますが、特に3つ目はエンジニアにとって無くしていきたいことだと思っています。

対して、SFA開発ではどうでしょうか。

現在主にフレームワーク移行中であるLaravelは、非常に高機能で、開発者としての使い勝手の良さがある
FEで利用しているjQueryは現代の主流とは言えないですが、複雑な業務的な要件を満たす機能は果たしてくれています

これらを通して僕が感じたことは、新しい技術のみが万能ではないということです。

「古い技術の方が良い！」というわけではありませんが、どんな技術も

扱う開発者のスキル
システム（≒サービス）の性質

によってその価値は変わると思っています。

例えば、エンジニアとして、現在のSFAのFEをjQueryからReactなどのモダンなフレームワークへリプレイスさせたいなという気持ちはあります。
しかし、現在のSFAの特徴として、

システムが多機能なことから、リプレイスに要する時間は多大なこと
その他の観点と比べると、UI/UXといった使用性が軽視される傾向にあること

があります。

そんなシステムにおいて、FEコードのリプレイスを行うビジネス的な価値は果たしてどのくらいあるのでしょうか？これはとても難しい判断だと思います。

この疑問は、営業職やマーケティング職が数値を根拠に仮説を立てて業務を行う職種の働き方を間近で感じられるレバレジーズで培われた視点かもしれません。
エンジニアはしばしば手段と目的を逆にしてしまうこと（「この技術を使いたいから、これをしよう！」など）がありますが、その行動の価値を証明する根拠を正しく策定しなければ、この後に書く「負債」につながると思います。

負債を生む可能性を常に考慮する

1年前の自分が書いたコードを見ると恥ずかしい気持ちになる方は、経験が浅い方であれば誰でもあると思います。
私自身もそれは痛感しており、それは自身が成長しているという実績でもあると言えますが、意図しない将来的な技術的負債を残しているという事実にも繋がります。

現在のSFAは古めのシステムであるため、

設計思想が今と合わなくなっていた
機能拡張を繰り返した

ことが要因で、コード品質が低下していました。また、業務要件が複雑で綺麗な設計が難しい場合も多いです。
多くのテスト駆動開発や開発アーキテクチャの文献でもそう述べられている通り、将来的な技術的負債を軽減させることは重要です。これがシステムの保守性や拡張性に大きく関わってくることは、フレームワーク移行・新規機能拡張の業務を通して痛感しています。
自分のコードの品質が高いかどうかの判断は難しいですが、品質向上のための学習や仕組みによる解消、適切な指摘が行えるチームビルディング・コミュニケーションを怠らないことが必要だと感じています。

また負債とは、特に技術だけではありません。それは、例えばドキュメンテーションや開発ルール、会議など様々です。

作成したはいいものの、保守されていなくて結局使われていない資料
なぜこうなっているのかわからないけど、みんなで守っている運用・開発ルール
どの立場として参加はしているかわからず、意見のまとまらない会議

開発だけでなく、仕事をする上では様々な将来的な負債が発生している可能性はあり、それは自分だけでなく、チームや組織にも当てはまります。

本当に解決したい課題は何なのか？
その機能はスケールできるのか？アジリティは高いのか？
品質のスコープはどこまでなのか？また、それはなぜなのか？

といった目的と手段の整合性や効果を明確にすることが重要であり、それを正しく行うためには、賛同と同程度に建設的な批判ができるチームや組織が理想であると思っています。

これは開発職以外と関わることが多い自社開発企業におけるメリットであるとも感じます。他職種においても、仮説立てやロジカルシンキングを用いて施策を提案しています。
その姿勢から学べることもたくさんあります。

基礎が大事

全ての体験で共通して感じたことですが、結局基礎が最も大事だなと痛感します。

現代は便利なフレームワークやインフラサービスが豊富な時代ではありますが、最終的にはHTMLやCSS、JavaScript、SQLなど基礎的なWebシステムの技術に帰結すると思います。

インターンやSFA開発、どの開発段階においても、基礎となる部分の知識不足の壁にぶつかり、バグや障害発生の問題の根本を掴めず、適切な対応ができない・対応が遅れることがありました。ですが、逆に基礎を理解していると、新しいフレームワークや技術に対する理解のハードルも下がりました。

つまりは、新しい技術の習得や興味を持つこともとても大事ですが、それ以上に基礎的なスキルが必要不可欠だと感じます。学生時代の勉強や開発が、この基礎の学習において役立っていることは言うまでもありません。

私の場合、最近はBE周りに携わることが多いため、データベースそのものの仕組みや、SQL・データ指向のアプリケーションのようなBEに関わることを

達人に学ぶDB設計徹底指南書初級者で終わりたくないあなたへ
達人に学ぶSQL徹底指南書第2版初級者で終わりたくないあなたへ
データ指向アプリケーションデザイン - 信頼性、拡張性、保守性の高い分散システム設計の原理

等の書籍やWeb上の事例を用いて、基礎から学びなおして応用まで学習の範囲を広げてみています。データ指向アプリケーションデザインはまだ読書中ではありますが、この3冊は非常に有益であったので、BEに関わる方におすすめしたい書籍です。

最後に

学生・インターン・正社員での開発体験の違いと今後に活かしたい3つの学びをご紹介させていただきました。

今回の記事で、自分の体験を忘れないための備忘録と、今後も意識したい学びを書き留めることにより、将来の自分が過去を振り返るきっかけになったと思います。
今後も学んだことをチームや組織に活かせる社会人になるために、BEを中心としてまだまだコンピュータサイエンスを深く学んでいきたいと思います。

読者の皆様も、日々の業務に追われ、新しいことを立て続けに学んでいる日常であると思います。
そんな日々で、過去を振り返る機会が減ってしまってはいないでしょうか？
自分の過去や現在の開発経験のふりかえり、得られた学びをまとめてみることで新たに見えてくるものや自分の目指す方向性を再確認するきっかけになると思っています。

レバレジーズでは、様々な体験ができるシステム開発を行っています。ぜひ、みなさんも一緒にサービスを作っていきませんか？レバレジーズに少しでも興味を持っていただけた方は、是非下記リンクを覗いてみてください！

（詳しくはこちら）