9
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

お題は不問!Qiita Engineer Festa 2023で記事投稿!

【Qiita 初投稿】実務未経験の文系大学生がエンジニアインターンを始めてから半年経って学んだこと 3選

Last updated at Posted at 2023-07-18

はじめに

こんにちは。私はMatcher株式会社でエンジニアインターンをしています文系大学生の@ck_33です。

エンジニアインターン生として入社してから先月で半年が経ち、

・できるようになったこと
・学んでおいてよかったこと
・技術力を上げるために取り組んできたこと

などなど、この半年間で成長や課題を実感できるものが増えてきたので、一度振り返りをしつつ、共有していきたいと思います。

※もっとこうするといいかもなど実体験やアドバイスがあれば、ご指摘いただけると助かります🙏

エンジニアインターンを始めるまで

まず、エンジニアインターンを始めるに至るまでの筆者のレベル感について、ざっと共有いたします。

開発インターンを始めるまでの筆者

大学2年の夏頃からプログラミング(Ruby)の学習を開始し、DMM WebCampというプログラミングスクールのメンターとして、主にRuby on Railsを教えながら、WebアプリケーションやECサイトを開発していました。

実務で開発した経験はなく、メンター業務と並行して個人でrailsのスキルアップに取り組んでおり、APIやエンドポイントなどを特に意識することもなく、ただひたすらコーディングしていたような感じでした。
また、JavaScriptの開発経験も無かったため、フロントはrailsのMVCフレームワークに則ってERBのみで開発をしていたような状態です。

そんな中で、大学3年の1月頃にご縁あってMatcher株式会社にインターン生として参加し、現在に至ります。

できるようになったこと・学んで良かったこと

ここから本題ですが、この半年間で成長を実感した点を広義に分割すると以下3点になります。

① フロントエンドフレームワークにおける知見の広がり

② PCの視点でプログラムを構築する思考

③ チーム開発のフローとLinux,Docker周りの知識

① フロントエンドフレームワークにおける知見の広がり

冒頭でもさらっと触れた通り、私はフロントエンド言語での開発経験が一切なかったため
フロントエンドとバックエンドを分けて開発することの利点について、一切理解できておらず、そもそもの基礎知識も圧倒的に不足していました。

そのため、0からフロントエンドフレームワークであるVue.jsに取り組み、基礎的な知識をインプットすることから始まりましたが、タスクをこなす中で今では全体像をある程度掴むことができるようになりました。同時に、Bootstrapに頼り切っていたことで苦手意識があったCSSにも愚直に向き合い、自信を持って取り組むことができるになっています。

また、フロントエンドとバックエンドの開発が分離されてから、開発する際にはフロント側とバック側の各役割を意識しながら開発する癖がつき、これまで曖昧だった各用語についても、その意味を理解することができるようになりました。

頭の中での思考回路として以下のような変化が起きた。といった方が伝わりやすいかもしれません。

rails単体時の思考回路
「データをとってきて、画面に表示したいから、ルーティングやコントローラーに処理を記述して、それをviewに渡そう」

フロント(vue)とバック(rails)を分離するようになってからの思考回路

「フロントからaxiosを使用してリクエストを送り、JSON形式でレスポンス返して欲しい→バックエンドでAPI作ろう。そのために、エンドポイントを設定し、目的に応じたデータベース操作や処理を実装してパラメータに合わせたレスポンスを返そう。」

ここまで書くと、以前の思考が如何に丸暗記した文法に沿ってコーディングしていたのか一目瞭然だと思います。

もちろん、フロントエンドフレームワークに触れたからという1要因のみでここまで変化が起きたわけではないですが、
明確に役割が二分されている状況の中でその意味を考えるきっかけが生まれ、思考過程をより原理や目的に応じて考えられるようになったことには寄与していると思っています。

② PCの視点でプログラムを構築する思考

もう少し詳細に区別すると、以下2点に整理できます。

① 適切な粒度に分解するための思考
② 実現したい処理をデータ型に合わせて構築する

① 適切な粒度に分解するための思考

要するに、プログラミング脳を構築しようということなのですが、それについては以下の記事がとても勉強になるため、プログラミング初学者の方は特に目を通しておくことをお勧めします。

コピペするプログラマに足りないもの 〜 プログラミング脳の鍛え方

本記事において、プログラミング脳とは
「頭の中にコンピュータがあるようなものだ。自分の頭の中のコンピュータでうまく実行させられるロジックが出せたら、あとは手を動かすだけになる。」

と述べられていますが、
私はプログラミング脳の定義について、
「目的の処理を適切な粒度に分解し、最終的に1つに統合することでPCが実現できる処理を作成するための思考手順を踏むこと」
であると解釈しています。
ここでいう適切な粒度とはPCがそれを実現するために必要としている粒度になります。

具体例を挙げると、並べ替えのソートプログラムをPCにお願いしたくても、0と1しか理解できない彼にとって、「最新データに沿って並べ替えてほしい」なんて傲慢なお願い事は罷り通りません。
彼らは何を持って最新データと判断するのか、並べ替えとはそもそも何か、こちら側で求める処理の定義を定めてから要求する必要があるのです。

つまり、適切な粒度に分解できる力分解したピースを一つ一つ構築していく力の2つの力が必要となり、その2点が組み合わさることで最終的に1つの処理となってPC上で実行されるというわけです。

出来る人にとっては当たり前の考え方かもしれないですが、なんでもストレートに当てはめてしまいがちな私にとっては、「困難は分割せよ」的な思考を身に付けるまでにはそれなりの時間がかかりました。

② 実現したい処理をデータ型に合わせて構築する

動的型付け言語であるRubyからプログラミングの学習を始めた私は、
以前までデータ型といえば文字列型と数値型、boolean型を気にする程度で、それ以外は特に気を配ることなく開発をしていました。

そのため、関数作成時に付きまとう配列操作やハッシュ(オブジェクト)操作などに苦手意識が強く、
「何を渡すと何が返ってきて、渡したものをどう処理させるのか、なぜこのメソッドはこのオブジェクトに対しては使えないのか」
など、やりたいことに対して思考回路が煩雑になってしまうことが多々ありました。
机の上が一瞬でごちゃごちゃになり、どこから手をつければいいか分からないようなイメージです。

このような状況に陥った際、先輩社員に質問を重ねるうち、1つ1つ整理して考えることが根付いていることを感じました。

そもそも、メソッドというのは各オブジェクトクラスに生えている関数の1つに過ぎないため、配列操作をしたければ配列型のクラスに定義されているメソッドしか使えないこと。
関数を作成するなら何かの動きを実現したい理由があるはずであり、その対象が
・配列型で、要素を絞り込みたいのか、
・数値型で、計算をして欲しいのか、
・ハッシュやオブジェクト型で、バリューの値を取り出したいのか
等によって、どのようにコーディングするかが変わってくること。

などをきちんと認識できておらず、特に型や引数、返り値などを意識しないまま開発をしてしまっていました。

まずデータ型を認識すること
その型に合わせて実現したい処理を構築することで、実装すべき関数や使用できるメソッド、渡すべき引数と求める返り値を認識でき、クリアな状態で思考できるようになりました。

ただ正直、私もまだまだこのステップを安定して踏めているわけではなく、いまだに整理しきれないことも多々あります。ここは、今後の課題として、アウトプットの量を増やすことで、より高い精度で安定的にこの思考過程を踏む癖付けをしていきたいと思っています。

→きっかけとして、定数ファイルを作成し、その定数を操作していくといった手順を踏むことでとてもいい練習になったため、さわりを掴む土台の練習として、定数を操作してみるのは個人的にかなりお勧めです。

かなり簡素な例ですが、以下の要領で配列などの定数も作成して操作してみるといいと思います。

Index.js
//オブジェクトのデータ型を用意
 const STUDENTS_LIST = {
    1: 'sato',
    2: 'kato',
    3: 'kobayashi',
    4: 'hayashi',
    5: 'shimizu',
};

//名前だけ取り出す変数を作成
const selectOnlyStudentsName = Object.values(STUDENT_LIST);

③ チーム開発のフローとLinux,Docker周りの知識

個人開発しかしたことのない私にとって、環境構築はローカルで行い、GitHub上のプルリク等を使用せずとも何の問題もなく開発してこれました。

ですが、実務では当然の如くチーム開発で行います。
開発環境の構築やGit管理など、以前は表面しか理解しきれていなかった要素が、実務を通じて具体的に流れをイメージすることができるまでになりました。

前提として、チーム開発を行う上では、チーム間で同じ開発環境を揃えておく必要があります。
これをローカルに環境構築をする場合で考えると、言語のバージョンや使用するミドルウェアなど、揃えるべきものが多く、コストがかかることは自明でしょう。

そこで、Dockerなどの仮想環境Gitを用いたバージョン管理チーム開発時の手順や慣わしなど、エンジニアインターンを始めたからこそ体験できる実務ならではの開発環境に学生ながら身を投じれたことは貴重な経験であると身をもって実感しています。

この経験をきっかけとして、環境構築にまつわる仮想環境や、それに付随するコンテナ技術、Linuxなどの学習に取り組むようになり、視座を高められたと思っています。
webの技術は蜘蛛の巣のように他技術と繋がり、支え合って成り立っているのだとしみじみ実感するようにもなりました。

また、私が最も良かったと感じたことは、Git管理による開発体制に馴染んだことでGitのコマンド自体への理解度も向上したことです。以前は、常にGitに対して苦手意識がありましたが、今となってはGitのエラーにビビり散らかすことも無くなりました。この成長は心理的にかなり喜ばしい変化でした。

まとめ

ドキュメントを読むようになったり、技術書を積極的に読むようになったりなど、細かい変化でいえば他にもあったりはしますが、Matcher株式会社でエンジニアインターン生として参加させていただいてから半年間で技術面のみならず、思考面や経験的にも大きく成長する機会を与えていただくことができました。社員の皆様には感謝の気持ちでいっぱいです。

まだまだコーディング自体の質アウトプットの量技術面での知識など、改善していくべき課題は山積みではありますが、今後も着実に1つ1つこなしていきたいと思っています。

9
9
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?