緒言

この記事はマイナビ Advent Calendar 2021の 25 日目の記事となります。

今年の 8 月中旬から株式会社マイナビにて就業型インターンシップに参加させていただいているtoshi-bpと申します。よろしくお願いします。

私がこのインターンに参加してから現在までを振り返って感じたことを書いていきたいと思います。

私自身 Qiita に記事を投稿するのが初めてであり、他の会社でインターンをされている方やこれまでのアドベントカレンダーに記事を投稿されていた社員の方々などの記事と比較して取るに足らないものとなっているかもしれませんがご了承ください。

この記事の目的

この記事は、私が就業型インターンシップにて参画したプロジェクトのことを語れるように思考を整理することを目的としています。そのため、読み物としては些か面白みに欠けている可能性があります。ご了承ください。

注意

この記事に書かれている内容は全て私の偏見及び自戒であるため、その点についてはご容赦ください。
日本語が不適切な点や文章が分かりにくい点は日本語の脳内補完をしたり行間を読んだりしていただければと思います。(~~他力本願~~)
~~この記事のせいで会社のイメージを悪くしないでください(お前が気を付けろ)~~

参画しているプロジェクトについて(ざっくりと)

現在、私は他のインターン生 1 人(以下 SS さん)と社員の方 1 人(以下 SI さん)と 3 人でチームを組んでマイナビさんの内定者研修で使用する「経営シミュレーションゲーム」のウェブアプリケーション化プロジェクトに参画をさせていただいております。

今回作成する経営シミュレーションゲームは従来対面で行われているボードゲーム形式のものだったのですが、コロナ禍によりオンラインで行う形となり、このプロジェクトが始動した、という経緯があったように思います。

使用技術

フロントエンド

React(Create React App)
- 8, 9 月のハッカソン型インターンシップにて React で作られたウェブアプリケーションの改修が課題として出され、SI さんなどの社員の方々がメンターを務めていたこともあり、チームメンバーのほとんどが使い慣れている。
  - 恥ずかしながら当時の僕は主に Vue を触っており、React については初心者でした。。。(今もか。)
- 型判定のしやすさなどの観点から Typescript を利用
  - 型などが不適切であるとコンパイル時にエラーが吐き出されるため Javascript を利用する場合と比較してもエラー修正がしやすいなどのメリットがあると考えられる。
React-Bootstrap
- ゲームに必要な機能の実装を進めつつ、一からボタンやモーダルなどの UI コンポーネントの作成をすることは困難であるため利用
- これについても 8, 9 月のハッカソン型インターンシップにて ry
Sass
- React-Bootstrap などの UI フレームワークではカバーし切れない細かいデザインの調整を行う際に利用
- 表記方法が css に近く、css に慣れていれば比較的容易に誰でも書くことができるようになる
- 私がこれまでに触れたことがあったため、他の技術に比べて書き慣れていたこと(tailwind には当時まだ慣れていませんでした。。。(今もか。))もあり採用されたと考えている

バックエンド

Firebase(Cloud Firestore)
- NoSQL データベース
- React 側で API を叩いてデータの取得及びそれを利用した処理の実装を行なっている
- 当初納期が 11 月末であり、制作期間が 3 ヶ月と短かった(社員の SI さん以外は基本的に週 2 での稼働となっていた)ため、バックエンドも別の言語にして開発を進めて行った際に納期に間に合わせることが困難となる可能性が高くなることが考えられたためこれが採用された(と私は解釈をしています)。
- NoSQL 型としたのは、ゲームにて点数が頻繁に書き換えられ、UX の観点から考えた際に高速な処理が実現される方がベターであると考えられたためであると考えられる

開発を通して学んだこと

ここでは、私が開発を通して学んだことについて書いています。経験者の方などからすれば当たり前に実践していることなどが多々ありかなり薄い内容となっていると思われますが、何卒ご容赦ください。

認識のすり合わせ・質問の仕方

これについては、どこで業務を行うにしても必要となってくるものであるように思われます。
認識のすり合わせを行う相手としては、以下の場合を想定しています。

開発メンバー(私の場合は SI さん、SS さん)
依頼する側(今回は採用部門の方々)

これを行わなければ、仕様を勘違いしたまま開発を進めてしまい、これまでに作成していたものが無駄となってしまう可能性もあるということを痛感しました。

また、それと関連して上で示した相手に確認を取る際などに行う質問の仕方にも気をつける必要があったな、と感じました(~~n 番煎じ~~)。
具体的には、

何を知りたいのか(何ができないのか)
自分で試してみた方法とそれがどこまで上手くいっていたか
なぜそれを知りたいのか(質問の目的)
画面を見せながら説明する(私がテキストベースで説明することがあまり上手くないのも関係していますが。。。)

以上の 4 点を特に意識して質問をすることで、より自分が求めていた解答に近いレスポンスを得られるように感じました。(あくまで一個人の感想ですが。)

フィードバックをいただけることについて

このプロジェクトでは週 1 回、30 分〜1 時間程度で開発側と採用部門の方々とゲームのテストプレイを行なっております。(本番になるべく近い形でのプレイを想定しているものと思われます。)その場で改善しておきたい点などをまとめておくのですが、本番で実際に動かすユーザーの意見はとても貴重です。また、依頼する側と開発側はあるプロダクトを作り上げていくという意味ではある意味で 1 つのチームであるということを肌で感じることができたと思います。とてもありがたいな、と感じながら業務を行っています。

技術力

プロジェクトに使用されている技術をある程度(調べればわかる程度)に使えるようにしておかないと、当然メンバーについていくことができずかなり辛いので、新たな知識に触れる度に自分のものにしていくことの重要性を再認識しました(~~我ながらうっす~~)。

ただ、自分が得意でない分野に長けているメンバーを頼るのもありだとは思います。
これがチーム開発のメリットとして真っ先に挙げられるものであるように思われるので。

※もちろん相手が抱えているタスク量などによります。何でもかんでもおんぶに抱っこでは先ほど述べたチーム開発のメリットが半減してしまうので気を付けましょう(自戒)

最後に

プロジェクト自体がまだ完遂していないこと、画像が少なくテキストベースの説明が多かったこともあり、かなりわかりにくくなってしまっている部分も多々あると思われます。

僕も正直自分の日本語力の低さに辟易しながら書き進めてまいりました。想像以上に内容が薄い上に纏まっていないな、と感じてしまいました。
アウトプットする回数を増やすなどして、これまで以上に言語化の訓練を行う必要がありそうですね。

最後まで読んでくれた方、本当にありがとうございました。

これにて失礼いたします 🙇‍♂️

あ、そういえば今日ってクリスマスですね。予定がある方がとてもうらやましいです 😇

みなさんよいお年を。