はじめに
こんにちは！2025年9月の一ヶ月間､エキサイト株式会社のBB事業部で就業型インター ンシップ｢booost!!｣でバックエンドコースでインターンに参加させていただいた小椋遼 太郎です｡今回はインターンで学んだことを振り返り､紹介します｡
自己紹介
私は大学３年生で､大学では情報系の学部に通っています｡これまでは大学のプログラミ ングサークルやハッカソンでチーム開発をしながら､個人開発としてビジネス的視点も身 につけながら音楽関連のwebアプリを作成をしていました｡サークルに入って本格的に勉 強をし始めたのは大学2回生の秋冬からだったのもあり､バックエンドのエンジニアとし ては初めてのインターンシップでした｡
インターンシップの業務内容
BB事業部のAPIがBEAR.SaturdayというPHPの独自フレームワークを使用しており､ そのAPIをLaravelに移行するという業務に取り組みました｡私はRuby on Railsや Next.jsなどは使用したことあったのですが､Laravelに触れるのは初めてでした｡しかし 後にも触れる設計のおかげもあり､PHPも特段ストレスなく書くことができました｡
学んだこと
このインターンで得られた学びはとても大きいものでした｡以下にバックエンドエンジニ アとしての根本的な知識の部分と､それらを元にした実践の設計的な知識の二つに分けて まとめようと思います｡
原則的な知識
まずインターンの中で共有していただいた資料であったり､書籍であったりからエンジニ アとしての基本的な考え方を身につけることができました｡その中から重要であると感じ たものをまとめます｡
命名規則の重要性
関数や変数の名付け行為は最重要であり､関数や変数がどんな役割を持っているのか関数 名で把握ができると可読性が大幅に向上します｡名付けが適切でない場合､コードを詳し く読み､実装内容を理解する時間が必要になってしまいます｡今後の修正するときの時間 を減らすためにも命名は重要だと学びました｡
YAGNIの原則
YAGNIは｢You Aren't Going to Need It.｣の略で､日本語訳で｢それはきっと必要にな らない｡｣という意味です｡多分必要になるだろうでコードを書いてはいけない､というこ とを表しています｡拡張性を考慮したコードを最初から書く必要はなく､必要になってか ら書くという大切だという基本的な原則を学びました｡
KISSの原則
KISSは｢Keep It Simple, Stupid｣の略であり､日本語訳で｢シンプルにしておけ､愚か 者よ｡｣という意味です｡これはコードを書く時､最優先の価値を単純性や簡潔性におく､ というものです｡常に複雑にならないようにシンプルに保ち続けるという根本的な原則を 示しています｡覚えた技術を無理に披露しない､将来の必要に備えた過剰なコードを書か ない､わかりやすい簡潔なコードを書くという意識を持たせてくれました｡
SOLIDの原則
SOLIDの原則はS(SingleResponsibility):単一責任の原則､O(Open-Closed):オープン クローズドの原則､L(Liskov Substitution):リスコフの置換原則､I(Interface Segregation):インターフェース分離の原則､D(Dependency Inversion):依存性逆転の 原則の頭文字であり､これらはコードを書くうえで問題を起さずにコードを書く､チーム 開発では必須の知識だと感じました｡その中でも重要だと感じたものを説明します｡
- 単一責任の原則はクラスが一つの責任(変更可能性)しか持たないようにするというもの です｡これにより変更が発生した場合､他のクラスやファイルも変更しなければいけない という自体を防ぐことができます｡
- オープンクローズドの原則は､拡張にはオープンで変更にはクローズドであるべきだ､ というものです｡クラスの内容は変更せず､機能を追加することでそのクラスが使われて いるクラスのエラーを防ぐことができます｡
- 依存性逆転の原則は､上位モジュールは下位モジュールに依存してはならない､どちら も抽象化に依存するべきだ｡というものです｡まずここでいう上位モジュールは動作を実 行するクラス､下位モジュールは動作を定めているツールです｡抽象化とはインターフェ ースを指します｡この原則ではクラスはツールの内容を知るべきではなく､ツールはイン ターフェースの要件を満たすべきであり､そのインターフェースにクラスは依存するべき である､というものです｡この原則ではインターフェースを導入し､上位クラスが下位ク ラスに依存することを目的とした原則で､重要な考えだと感じました｡
設計的な知識
開発するにあたって､先に挙げた原則的な知識を前提としてアーキテクチャについて考 え､実装していく必要がありました｡実装するにあたって重要だと感じた知識をまとめま す｡
関心の分離
関心とはソフトウェアの機能や目的のことを意味します｡つまり関心の分離とは､それぞ れの機能や目的に関連するコードをまとめて､他のコードから分離するということです｡ 設計技法においてはMVCなどのパターンが挙げられます｡(ビジネスロジック､ユーザー 表示､入力処理のように分離)｡またこのときビジネスロジックをコントローラーにまとめ て書いてしまうとfat-controllerになってしまいます｡これだと先ほど挙げた単一責任の 原則に反してしまったり､可読性が下がったりなどのデメリットがあります｡可読性が下 がると､保守を行なっていく際に莫大な労力がかかってしまうので､多少開発の時の手間 を考えても､repositoryやserviceなどでビジネスロジックやDBロジックのように分離 することで解決するべきだと感じました｡
インターフェースと実装の分離
先に挙げた依存性逆転の原則から､インターフェースを実装することが望ましいことを学 びました｡具体的にはRepositoryのinterfaceやServiceのinterfaceを実装すること で､クライアントへの影響を考えず､実装の修正を行うことができます｡具体的なコード 例に関しては他の方が記事で書いているので､ぜひ読んでみてください｡
変更容易性
変更容易性とはどれだけ容易に変更することができるかを表す度合いです｡設計を行う際 は､簡単に修正､拡張できるか意識する必要があります｡特に保守を行うサービスでは変 更が容易である必要があると実感する場面がありました｡変更容易性を高めるために､設 計や開発の中で特に意識すべきだと思うのは､ 1. 変更があったときに副作用を最小にできるアーキテクチャであるかを考えながら開発を行うこと 2. ソフトウェアの開発環境を変化させた時の移動のしやすさを考慮すること だと感じました｡また､単一責任の原則を守っていれば変更容易性も高く保つことができ ます｡
再利用性
プログラミングにおいて重複したコードはよろしくないです｡それは意味的でも機能的で も当てはまりますが､それを避けるため共通部分はなるべく切り出してメソッドを作成し たり､一般化したメソッドを書く必要があります｡モジュールごとに関心を分け､再利用 ができるメソッドが望ましいとコードを書く中で学びました｡
MVC+RSの学びやすさ
今回､これまであげたようなエンジニアとしての前提知識であったり､設計する上での基 本的な知識を身につけることができたのは､API移行先の設計がクリーンアーキテクチャ ベースのMVC+RSであったことが大きいと感じています｡このアーキテクチャでは､こ れまであげたような原則的な知識の実践例が示されており､得た知識を適切な形で活かす ことができました｡これまでは､設計に対して何も知らなかった私が､一つの正解例のよ うな設計を勉強しながら知識をつけることができたので､ある程度設計における理想と､ 自分のコードの良し悪しの基準を持つことができるようになりました｡
最後に
最後になりますが､本インターンでメンターをしてくださった方々､面接をしてくださっ た人事やエンジニアの方々､お時間をいただきインタビューをさせて下さった方､面談を 重ねてインターンをサポートしていただいた人事の方､インターンの開催に尽力していた だいた株式会社エキサイトの方々､本当にありがとうございました｡ 丁寧なバックアップ体制と環境でバックエンドエンジニアとして成長できたと感じていま す｡ 他の予定と重なってしまいほぼ２週間と少しの短い間でしたが､本当にお世話になりまし た｡充実したインターンシップをありがとうございました｡
