株式会社OMJテクノソリューションズ Advent Calendar 2023 22日目の記事です。
こんな方向けの記事です
・Webエンジニアになりたい方
・これから学習していくWebエンジニア志望の方
・Webエンジニアの長期インターンを控えている方
インターンさせていただいたきっかけが特殊なため、長期インターンの面接、志望動機など採用試験の参考になる記事ではありません。
はじめに
初めまして、kio_hackです。
「大学生が実務案件に参加したレポ」と題しまして、自分がIT企業のインターン生として実際の受託案件に入り、無事に完走いたしましたので、そこに至るまでに取り組んできたことや、それぞれの後悔などをお話しできればと思います。自戒的な内容になりそうですが、もし興味があればお付き合いいただけたらと思います。
簡単なプロフィール
・文系学部の大学4年生
主な使用技術
・フロントエンド → React.js, Next.js, Typescript
・バックエンド → Node.js, Python
・学習経験 → PHP, Java
目次
- 駆け出し期（学習し始め）
- 駆け出し期の後悔
- インターン前期（学習ベース）
- インターン前期の後悔
- インターン後期（実案件）
- インターン後期の後悔
- おわりに
1. 駆け出し期（学習し始め）
1. Progate
まず、最初に取り組んでいたことはProgateです。
初めはフロントエンドに興味があったため、
・HTML/CSS
・JavaScript
といったフロントエンドには必須の言語と、
・PHP
・Python
のように比較的初学者でも入りやすい言語、
・SQL
・Git
・コマンドライン
等のシステムエンジニアとして必須な知識等に関する学習を行いました。
また、JavaScriptのフレームワークの中で非常に人気のある、React.jsも学び、
TypeScriptと合わせて動画等のコンテンツで、成果物を作りながら学習するなどしていました。
2.React ,Typescriptで簡単に成果物を作ってみる
作ったのは大きく２種類です。
1. サイトでよく使われるような挙動を真似する。
例）ショッピングサイト(画質悪くてすみません）
2.公開されているAPIを使ってサービスを作ってみる。
例）PokeAPI
ポケモンのデータを取得できるAPIです。
最近はQiita上でもPokeAPIを使用した記事が多くみられるので、
調べて参考にしてみてください。
2. 駆け出し期の後悔
駆け出し期の後悔としては、大きく二点あります。
1.プログラミング以外の周辺知識を定着させるべきだった。
ここまで読んでくださった方の中でお気づきの方もいらっしゃるかと思いますが、
フロントエンドの技術に傾倒してしまっていました。
後になって、キャッチアップする量が増えてしまった経験があるので、
せめて基本情報レベルの知識を身につけておくと、後で困らなかったなと思います。
2. バックエンドも含めた簡単なアプリ開発
Todoアプリなど、簡単なものをPHPなどを用いて作るということをやっておくと、
データベース等も含めた実務で役にたつ経験を得られるので、この時期にやるべきだったと後悔しています。
環境構築などハードルは比較的高めなので、動画を見ながら作成することをお勧めします。
3. インターン前期 （学習ベース）
1. インターンでやっていたこと
この時期は、社内で使用するツールの開発を行っておりました。
概要としては、シンプルなフォームがメインで、登録された情報が確認できるような
10ページほどのWebアプリケーションです。
フロントエンドエンジニアで、React.jsとTypescriptを主に使用しておりました。
2. この時期にキャッチアップしていたこと
◯Reactの便利なライブラリの学習
フォームなどを作成していましたので、yupなどのReactで使えるバリデーションのライブラリは自由に使えるように学習していました。また、Reactのテストライブラリなども扱えるようにしました。
◯基本情報の学習
少しずつではありますが、DBやネットワークなど、実務でも生きるであろう周辺知識を学習し始めました。動画を見たり、過去問道場をやったりがメインでした。
4. インターン前期の後悔
少し早いような気もしますがもう後悔のお時間です。
この時期は後悔、反省するべきことが山積みなのです。
1. リーダブルなコードが書けない
主な原因は、とにかく実装することや、画面上で動作することを最重要だとしてしまっていたことだと思います。プログラマーはコードを書けるのは当たり前で、保守しやすいシンプルでリーダブルなコードや、理にかなったディレクトリ構造などの理解や学習が圧倒的に欠如していました。また、変に自分を信じすぎていたのかもしれません。この辺りは、Qiitaにも多数の記事がありますし、有名な「リーダブルコード」や、「良いコード悪いコードで学ぶ設計入門」などの書籍で理解を深めるなどを、僭越ながら初学者の方にはお勧めしたいです。
2. 報連相、コミュニケーションエラー
学生と、社会人のギャップについて行けず、ご迷惑をおかけすることがしばしばありました。
◯進捗報告
自分の作業に夢中になって、進捗状況などをこまめに報告することができず、上職の方から進捗の確認をさせてしまうことが多発。また、エラー等で手詰まりの際など、自力で解決できない際に１時間を超えて、報告せずに作業することも。。
◯個人的な見解
「何分おきに報告する」というように進捗報告をするルールを上職の方とすり合わせる必要があると思います。自分一人で作業したいという方もいらっしゃるかもしれませんが、場合によっては周りの人の時間を奪ってしまう結果になる可能性もありますので、早めの報告を心がけるべきだと思いました。ただ、エラー時など、わからない時に人任せになってしまうのも全く良いことではないので、エラーの対処法も併せて徐々に身につけていき、自走できるエンジニアを目指すべきですね。
5. インターン後期（実案件）
いよいよ実案件に移っていきます。
実案件で主に使用していたものは以下です。
実案件に関しては念の為詳細には記載しません。
◯React、TypeScript、Next.js
◯Python3、 Node.js（Lambda）
◯AWS（Lambda、APIGateway、S3、StepFunctions、RDS、DynamoDB etc..）
1. 案件時特に印象に残った技術的なこと
案件をしているときに印象に残った技術です。具体的に技術的なことに触れる記事ではないので簡単にですが、参考にした記事などを合わせて紹介します。
①Lambda内で、DynamoDBとRDSのトランザクション
この案件では、DynamoDBとRDSの両DBに同時にINSERT等する処理が必要だったため、どちらか一方で失敗した場合もう一方もロールバックする必要がありました。以下のような記事を参考にしてDynamoDBのトランザクション処理を実装できました。RDS(MySQL)では、MySQLと同じようにしてトランザクションできます。
②StepFunctionsでバッチ処理
StepFunctions内にLambdaを配置して、バッチ処理の実装をしました。仮にどこかの処理中にエラーが発生し、再実行されてもなおエラーが発生する場合、中断しロールバックする必要があります。 S3やRDS、DynamoDBとのやりとりも含まれていたため、バッチ処理の基本を理解するだけではなく、AWSの他の機能とのやり取りの仕方を調べながらの実装になったので個人的に苦労しました。特に理解に役に立った記事は以下です。
2.この時期にキャッチアップしていたこと
①Next.jsのキャッチアップ
Next.jsは、Reactをやっていれば入りやすいですが、ちゃんと癖がありますし、独自の便利な書き方などいろいろありますので、今までReact.jsで作ったものをNext.jsを交えて書いてみるなどしました。といっても結局自分のメインのタスクはLambdaでStepFunctionsを使ったバッチ処理や、APIの量産で、実際ににはあまり書いていないですが。。
②Pythonのキャッチアップ
Pythonも案件内で使用していたので、Pythonに関してもキャッチアップしていました。Pythonは今回が初挑戦だったのですが、NumpyやPandasなどの有名なライブラリをいじったり、FlaskでAPIを作ってみたり、最低限のことはやって案件に臨みました。
2. 個人的な実務のインターンのメリット
①プロのコードが見れる。
今回、フロントエンドに関してはほとんどコーディングしませんでしたが、React歴の長い方のコードを見ることができ、結果的に自分のコーディングを見直す良いきっかけになりました。案件にもよると思いますが、自分よりも歴の長い人のコードを読めるのはかなりのメリットだと感じました。
②より自分の仕事に責任を持てる。
対社外で仕事をするのは初だったため、いつもより重い責任感で仕事ができました。明確なスケジュールがある中で安定してアウトプットをする(できていない)というようなプレッシャーを体験することができたことは、自分の大きな強みになると思います。
6.インターン後期の後悔
①公式のリファレンスに弱すぎた。
文字通り公式のリファレンスに弱すぎました。もちろん物によるのですが、欲しい情報を探してくる力が足りず、画面と睨めっこする時間が長かったかと思います。日本人がリファレンスを解釈して記事にしたようなものに頼りがちだったことも要因かと思います（よくない）。今後は公式のリファレンスも積極的に読んで慣れて行くべきです。。
②アルゴリズムがちょっと弱かった。
コードを書くうえで、目標となる処理の結果があり、それを実現するために、どのようなコードを書くかを考えてからコードを書くのが一般的かと思いますが、コーディング後、テストしているときに条件分岐の抜けもれに気づいたりすることが偶にありました。これまで、複雑な処理を書いた経験はそれほどなく、ある程度考えてすぐ手を動かしてしまっていましたが、事前に細かく明示的に、処理のフローを表してから手を動かして、手戻りの少なく、効率的で見やすいコードを書くということをまずは意識することとしました。これを繰り返し、以前よりも手戻りの少ないコードを書くことができるようになってきていると思います。
7. おわりに
ここまで読んでいただきありがとうございます。自分の経験ベースの話になってしまいましたが、もしどなたかの役に立てば幸いです。これがQiita初投稿となりますが、今後は初学者向けの技術的なことについて文章にしていきたいと思いますので、よろしくお願いいたします。
最後まで読んでいただきありがとうございました。