インターンとして入社前に取り組んだ内容をブログにしました！！
中谷 亘佑
2025年4月入社（25新卒）
クラウドインテクレーション事業部配属
松田 陽佑
2025年4月入社（25新卒）
DX開発事業部配属
やったこと
新卒研修前のインターン活動として、２人でイベント向けリアルタイムQ&Aアプリを制作しました。
アイレットでは採用や勉強会などの発表の場が多くあり、参加者が気軽に質問を投げられるプラットフォームとして既存のシステムを利用しています。それらのシステムには使わない機能や改善したい点があり、必要な機能のみをブラッシュアップした弊社らしさのあるサイト制作するプロジェクトに参画しました。
インターン生2人で、実際の開発現場でもよく採用されている下記AWSサービスを活用して動作環境を１から構築し、アプリケーションを動作させることができました。
- AWS Lambda
- Amazon API Gateway
- Amazon S3
- Amazon DynamoDB
- Amazon CloudFront
- AWS CloudFormation
活動の動機
内定式で齋藤将平会長とお話をさせていただく機会をいただき、「入社前にインターンができる」と伺って、入社前により実践的な知識を身につけたいと興味を持って応募したのがきっかけでした。AWSを実際に触れてみたかったことと、今の自分はどこまで実践で通用するのかを確認をしてみたかったのも大きな動機でした。
開発の道のりと学びの記録
１１月
活動当初は、「どこまでできるだろう」という不安と、「色々なことを吸収したい」という期待が半々でした。
これまで学生同士でしかプログラミングについて話したことがなかったため、社会人の方々とのやり取りには緊張もありました。
初めは機能のやるやら
上長として先輩社員がついてくださって、２月末までの制作する課題を伝えられました。
課題内容はイベント向けリアルタイムQ&Aアプリ。
会社が開催するイベントなどの場での質問投稿用のシステムとして一覧が表示でき、質問の共有・共感などがしやすいサイトが目標。
チャットアプリはさまざまなツールを触ってきましたが、利用用途が初めて聞くようなもので初めはどこから手をつけていいか分からない…。
アプリ開発の初期段階として、機能要件をブラッシュアップするために課題として上長からあげられたのが機能の「やるやら」でした。
既存の類似システムを参考にして、欲しい機能のリストアップを行い、「こんな機能があったら便利だろう」「イベントが面白区なるだろう」というアイデアを自由に出し合い、否定せずに可能な限り多くの機能を箇条書きで書き出しました。
そこから必要機能の選定を2人で話し合いながら、「これはやる」、「これはやらない」と必要な機能の決定を行いました。
↑こんな感じ
１２月
制作を始めるにあたっての壁
実際に触って構築を始めていくにあたって最初につまづいたのが環境構築でした。
ローカルで実行するためのフレームワークなどを導入したいのですが、何かとエラーで先に進まず、環境設定が分からなくて質問していいものなのかどうなのかで悩んでいる時間で大きくタイムロスになってしまったと思います。最終的に上長からのアドバイスをいただき、解決はできました。
今思うとすぐに報連相を行えば１時間もかからずに終わる作業だったのになと感じます。（笑）
この時からわからないことがあったら少し悩んで訊くを徹底していき、短い期間での開発が間に合うように心がけました。
具体的に、週一のミーティングを上長に相談して実施してもらい、進捗報告と今詰まっていることをまとめる時間をとったり、どこまで自分で考える時間かを明確にしておき、その時間を過ぎたら質問をしたり…
考える時間は確かに大切ですが、そこで進捗がストップすることを思うと、訊く訊かないのメリハリは大切だなと感じます。
１月
ローカルで実行していたコードをAWSのサービスにテスト環境をデプロイ
ローカル環境からAWSでの実行テストに移行した月になります。１月からは作業が急ピッチで進んでいきました。
デプロイするとエラーやCORS設定の修正で時間を取られた印象です。
こまかいスケジュール管理を行なっていれば、残り二ヶ月を早急に進めるということをせずに済んだのになぁと今は思います（笑）
質より量！！
エラーの解決方法を相談しながら進めていき、月末になるにつれ自分たちでも解決していけるような状態になりました。
一度触ったことがあるという経験があると、エラーに対処できることが容易になると実感しました。
座学で学ぶよりも実践を通してエラーの対処を学べた方が私的には一番しっくりきたので、初めのうちは量をこなして段々と質を上げることをオススメします！！（個人的な意見なので参考程度に…）
今までの学校で学んできたローカル環境でのエラー対処と違い、クラウド環境でのエラー対処になるので、新たな知見が必要不可欠と感じました。
月末にはデザイン事業部の1年上の先輩とMTGを重ね、アイレットらしいデザインを依頼し最終月に向けて調整していきました。依頼の際は必要機能をまとめて、ご相談させていただきました。
↑実際に下書きで依頼したときの図
２月
デザインのマークアップと微調整
最終月はマークアップに時間を費やしていきました。
デザイン事業部の先輩とのアポイントをとるのが遅れてしまったため、マークアップの時間をとることが難しくなってしまいました。
デザインにも力を入れていただき、最初のデザインを見た時にみやすいおしゃれなデザインで感動。
デザインとシステムの機能を照らし合わせて、足りない部分をミーティングやメッセージを送り修正案を何回か描いてくださり迅速な対応をしていただきました。
担当してくださったデザインの先輩は違う領域ですが、『１年後にはこれだけシステムのことも深く考え、把握してまとめられるようになるのか…』と先輩方の凄さを実感したと同時に、自分自身も「デザインを気にしながらシステムを作れるようになりたい」と楽しみになりました！
↑進捗報告をしていただいた時のチャット
初めの方はデザインの方々とのミーティングで戸惑い、うまくまとめて話せていなかった節があります。
ミーティングで大事なのは認識のすり合わせがどれだけスムーズに行くかが重要で、ここがスムーズにいかないと新たに時間を作っていただくことになったりするので、依頼したいこと・必要なUIなどを正確に伝えられることが何より大切だと感じます。
具体的には、ミーティング前に話す内容や伝え方を確認して、結論から話すことを意識しておくといいと思いました。
マークアップの知識はある程度ありましたが、初めてReactでのコンポーネントを考えた設計をしたので、慣れるのに手間取りました…
主に使用した技術
Amazon S3
S3の静的Webサイトホスティングを使用してReactを保管してURLからアクセスできた時は感動！
Amazon API Gateway
APIGatewayではリアルタイムチャットを実現するための機能として、Websocketを使用し、そのほか、更新などが必要なものに対してはREST APIを使用しました。
APIGatewayでのwebsocketの設定は簡単にすることができ、全員に反映されているのが見えた時が一番楽しい！
AWS Lambda と Amazon DynamoDB(+Slack)
Lambdaの使用用途はWebSocketの接続・メッセージ送信・切断とDynamoDBの更新などです。
DynamoDBの更新がスムーズに理解できず苦労したことの方が多い印象です。
エラーが出なかった時が一番感動！（でもエラーが出ずに何も変化がない時は結構辛い）
Slackの拡張として、プログラムからSlackにメッセージを送れるため、カスタマイズするために何度もチャットを送り微調整する作業も地味に楽しい！
技術面で苦労したこと
フロントサイドで苦労したデザインの追求とReactの状態管理
できるだけデザイン通りのマークアップを心がけて制作しましたが、想像通りの配置にならなかったりが頻発してかなり大変…。
デザイン事業部の先輩がお忙しい中作っていただいたものを台無しにしてはいけないと考えて、全力で近づけることに注力しました。
Reduxというライブラリを使用して、ページ全体での状態管理を行い、サーバー側へのリクエストを最小限にしたり、読み込み速度を向上させたり、と行おうとしましたが想定通りの挙動が取れず、質問したり視野を広げて別アプローチを検討するなどで時間を割いたかなと。
バックサイドで苦労したAWS LambdaのAmazon DynamoDB更新
今まで直感的にしたいことをSQLにしてできたのですが、NoSQLになると更新するためのコードがわかりづらかったり、設定が違ったりと苦労した箇所が多かった印象です。
短い期間で制作することができた課題成果物の紹介や一緒に進めていってくださった方々のFBなどあるのでぜひ後編もご覧ください！！🙇♂️🙇♂️
↓
簡単30秒