就業型インターンシップBooost!!!に参加して学んだこと

はじめに

こんにちは！エキサイト株式会社で1ヶ月の期間、就業型インターンシップ「Booost!!!」に参加させていただいた山根です。今回はインターンシップで取り組んだことや学んだことについてご紹介していきます。

はじめに
自己紹介
インターンシップでの業務内容
学んだこと
まとめ

自己紹介

私は現在情報系の大学に通っている学部3年の学生です。個人やハッカソンでwebアプリケーションを開発した経験はありますが、実務での開発経験はなかったため、夏休みの期間を利用して様々なインターンシップに参加をして経験を積みたいと考えていました。

その中で縁あってエキサイト株式会社のLife&Wellness事業部にインターン生として開発に携わらせていただきました。

インターンシップでの業務内容

Life&Wellness事業部でも様々なサービスがある中、エキサイト電話占いで使われているPHPのフレームワークであるBEAR.Saturdayを最近主流のLaravelへ移行する業務に取り組み、その中でも無料占いページの移植タスクを行いました。

私はPHPでの開発経験がなかったため、初めはロジックを含まないタスクから割り振ってもらいました。2つのページの移植が終了したら、ファイルベースでデータの処理を行うタスクに取り組みました。このプロジェクトではレイヤードアーキテクチャが採用されており、リポジトリやユースケースでロジックの分離を行っています。移植元とは構成が異なるため、メンターの方にサンプルを用意していただき、ディレクトリ構成についても詳しく説明してくださいました。また、PRのレビューも丁寧に行なってくださり、どこが悪いかだけでなく理由や改善案など提案していただけたり、良い点があれば評価もしてくださるため、高いモチベーションを保ったまま開発に取り組むことができました。

学んだこと

私は今回のインターンシップの目標として、実務での開発や会社の雰囲気について知るということを目標としていました。1ヶ月間インターンシップを通して様々なことを経験できましたが、中でもこれまでの開発でできなかったことや実務でのプロジェクトに参加したからこそ学べたと感じたことについてまとめていきます。

コーディング規則

部署内ではコーディング規則が決められており、タスクに取り掛かる前にまずこれを確認しました。特にPHPはPSRに準拠しており、理解が難しいものはありませんでした。記述方法に統一性がないと可読性が低く、変更容易性も失われる可能性が高いです。コーディング規則を決めておくことはチーム開発をする上で非常に重要だと感じました。

その点、本プロジェクトではCIが整備されており、規則に反している箇所を示してくれます。CIでの確認だけでなく、開発環境上でコマンドを叩くことで静的解析を行うこともでき、自動修正をすることまで可能です。短期間でコーディング規則を全て頭に入れることは難しいですが、これらのツールがあるおかげで、非常に開発が進めやすい環境だと感じました。

チーム開発

今回のインターンシップで最も学びが多かったのが、チーム開発になります。
ある実装において、実務でのチーム開発の考えが最も現れた部分について紹介します。

修正前

Laravelではbladeというテンプレートファイルを使用しています。今回のプロジェクトのアーキテクチャではフォーム入力から得た結果をbladeに表示するために、ViewModelでその結果を整形する必要がありました。私は初め、bladeファイル内で変数を表示するために以下のようなコードを書いていました。

// blade
@section
    <p>{{ $vm->getResult()->getPersonality()->toString() }}</p>
@endsection

// ViewModel
<?php

final readonly class ResultViewModel
{
    public function __construct(
        private ResultIndexGetUseCaseOutput $useCaseOutput,
    ) {
    }

    public function getResult(): Result
    {
        return $this->useCaseOutput->getResult();
    }
}

このコードでも結果を表示することはできるのですが、いくつか問題点があります。

変更容易性が低い

もしデータの取り出し元が変更になった場合、bladeでモデルクラスの実装をしていると修正箇所が広くなってしまいます。そのため、ViewModel内でモデルクラスの実装をまとめていた方が変更に対して強くなります。

bladeファイルはデザイナーも触れるため、処理を含まない方がいい

bladeファイルはユーザーの目に見える部分であるため、デザイナーが編集する可能性があります。そのため、bladeファイルに処理が存在する場合、思わぬ障害が発生しかねません。

修正後

先ほどの問題点を踏まえ、bladeではモデルクラスの実装を含まない、デザイナーもbladeに触れることがあるため処理を減らすということをポイントとし、以下のようなコードに修正しました。

// blade
@section
    <p>{{ $vm->getPersonality() }}</p>
@endsection

// ViewModel
<?php

final readonly class ResultViewModel
{
    public function __construct(
        private ResultIndexGetUseCaseOutput $useCaseOutput,
    ) {
    }

    public function getPersonality(): string
    {
        return $this->useCaseOutput->getResult()?->getPersonality()->toString() ?? '';
    }
}

このコードであればbladeでモデルクラスの実装をしないで済み、bladeファイルの変更容易性が高くなります。また、デザイナーへの配慮もできたコードとなっておりViewModelから何を取得しているかの意図が明確になります。

こういった変更容易性やデザイナーとの連携を意識した開発は実務でしか行えないことなので、非常に良い学びになりました。

コミュニケーション

エキサイト株式会社ではコミュニケーションツールとしてSlackを使用しています。インターン生はtimesチャンネルを持つことになっており、今回初めて自分のtimesチャンネルを持ちました。同じタイミングでインターン生として入社している方も頻繁にtimesへ投稿をしていたので、大変刺激を受けました。私も積極的にtimesを活用することでLife&Wellness事業部の方とコミュニケーションを取れるようになりました。

しかし、Slackやビデオツール上でメンターの方に質問をする際、私は説明が冗長になってしまったり、説明が分かりづらく相手に意図を汲み取ってもらっているということに気づきました。上長の方にこの悩みを相談したところ、結論ベースで物事を話すと相手に伝わりやすいというアドバイスを受けました。上長との面談以降、朝会やSlackでの報告はこれを意識して取り組むように心掛けました。まだまだコミュニケーションは自分の課題であるため、今回発見した課題を改善し、より自分からアクションを起こせるようにしていきたいと感じました。

まとめ

今回のインターンシップで関わってくださった皆様に、この場を借りてお礼申し上げます。実際のプロダクトの開発に携わることができ非常に貴重な経験を積むことができました。開発をするだけではなく、他の事業部のインターン生や新卒エンジニアの方との交流会であったり、人事や上長、CTOとの面談まで行うことができ、会社についても知る機会が多く非常に充実した1ヶ月となりました。

2名のメンターの方の手厚いサポートにより、様々な発見や学びのあったインターンシップとなりました。どんな質問でも回答してくださり、理由や手段など丁寧に説明してくださいました。エキサイト株式会社の就業型インターンシップ「Booost!!!」は様々な経験を積みたいという方に是非おすすめしたいインターンシップです。