はじめに
こんにちは、28卒インターン生の上中野 瑞人です！
エキサイト株式会社のExcitech Camp!!!にてBB事業部(ブロードバンド)で9月から1ヶ月間、参加させていただいております。
インターンを通した個人での開発や学生でのチーム開発との違いと長期的に保守できるシステムに関する考えについて執筆します。
なんで保守されるじゃなくてできるなのかはこれまた後ほど・・・
自己紹介
大阪産業大学 デザイン工学部 情報システム学科の学部3年生です。
小学生の頃からBASICやHTMLに触れてきてJavaやPHPなど様々なプログラミング言語でパソコンを用いて何かを作ることに楽しさを感じていました。しかし、ハッカソンや身内でのチーム開発とは異なる、実際の業務を通じてチームの一員として開発をしていく流れを学びたいと思い、僕の中では初めての長期インターンとしてExcitech Camp!!!に参加させていただいています！
事前学習
- Webを支える技術
- ソフトウェアアーキテクチャの基礎
- 良いコード/悪いコードで学ぶ設計入門
上記の3冊に加え、Laravelの経験もまだまだ浅いため、一度ハンズオンで開発環境構築からやり直してみました。
特にWebを支える技術ではウェブの歴史的な経緯や僕自身が知らないこと、知っていたことをより詳細に深掘りできて面白い1冊でした。
1ヶ月でやったこと
1ヶ月の中で主に「API移行作業」を行いました。流れとしてはメンターの方が記述したチケットの内容から要件を確認してAPI設計書を作成し、相談しながら実装してレビューを経てデプロイするというものでした。
また、実装だけではなく、APIの動作確認やUnit/Featureテストの作成、レビューを受けた上での修正など、実際の開発の流れを一通り経験しました。
終盤近くでは社内ツールの旧ツールから新ツールへの移植と改善なども行いました。
よかったこと
実際に利用されている既存システムを通じて開発できたことです。
これまでは個人での開発やハッカソンなどで開発することはあり、実際にユーザーの持つサービスやソフトウェアを開発、運用する経験もありました。しかし、そこでは自分たちで決めたものを自分たちで作ることが多く、基本的に自分自身がコードや仕様を把握しているので、今回のような自分以外の人たちが継続的に開発をしている既存システムに対して変更を加えるという経験はありませんでした。
今回は既存のAPIを新たなLaravelのAPI開発環境下に移行する作業だったため、単純に動くものを作るだけでなく、既存の処理がどのように使われているか、変更するとどこに影響するのかを考えながら進める必要がありました。
また、実装をする中で疑問点なども発生します。そのため、相談しながら進める中でただ単に質問するだけでなく自分なりの対応案などを考えてから話し合うことで、よりスムーズに進めることができることも学びました。
難しかったこと
こちらは既存システムのコードの理解とテストの設計、作成です。
個人での開発では自分で書いたコードを扱うことが多いため、なぜこの処理が必要なのかを把握しやすいですが、今回は自分が書いたものではない既存のコードを読み解く必要がありました。
また、MVCではなくService、Repositoryといった概念もDBに触れることが少なかった僕にとっては新たなものでした。
そのため、ルーティング、コントローラ、サービス/リポジトリ、モデルというように処理の流れを追いながら、実際にどのような処理が行われているのかを確認していきました。
また、最初はどこまで自分で考えてから相談すればよいのか分からない部分もありました。実際に相談していく中で、分からないことをそのまま聞くのではなく、自分なりに調査してそこから自分なりに対応案を考えて出した上で相談することが重要だと分かりました。
本題とはズレますが、普段WindowsやLinuxユーザーであるため、実はmac特有のキーボード操作にも手こずっていました。バックスラッシュの入力方法が分からず、option + ¥で入力できることを知ったりなど、MacBook自体は持っているものの開発にはあまり用いることがなかったため、macOSをメインに開発すること自体も初めての経験でした。
これから先挑戦したいこと
今回の経験を通して、実装するだけでなく、その後も複数人で維持していけるようなシステムを考えながら開発できるようになりたいと思いました。
これは僕自身が参加している部活動のシステムも同じくトレンド技術を選定してしまったことにもつながるからです。
特に、アーキテクチャや技術スタックを選定するときに、今作りやすいかどうかだけではなく、今後その技術を扱える人がいるのか、学習コストはどの程度なのかなど、将来的なことまで考えられるようになりたいです。
また、今回のような既存システムの移行作業だけでなく、より大きな変更をするときの影響範囲やスコープを考え、どこまで対応するべきなのかを判断できるようになることにも挑戦したいです。
それと、Laravelに関してはまだまだわからないことだらけなので、この頃は休みの合間に個人での開発でも取り入れてます！
学び
個人での開発や学生でのチーム開発との違い
今回のインターンを通して、個人での開発やハッカソンなどの学生同士のチーム開発と、実際の仕事としてのシステム開発では考えることが大きく異なると感じました。
（ただし、これも個人プロジェクトをOSS化する際や部活動のシステムを作る際は効いてくると思います）
個人で開発する場合は、自分が使いたい技術やトレンドの技術などから技術スタックを選ぶことが多く、ある程度自分の判断で自由に進めることができます。
一方で、実務上の既存システムでは自分以外の人も開発や保守に関わっています。そのため、技術の選定だけでなく、既存システムへの影響や開発する範囲、今後の保守なども考える必要があります。
今回のAPI移行では、影響範囲の小さなエンドポイントの移行でした。しかし、レスポンスを変更すればフロント側にも変更が必要になります。１つの変更でも他の部分に影響することがありました。
また、個人での趣味的な開発では移行作業を行うことは滅多になく、既存コードを読み解くというのもオープンソースに関わる以外ではあまり行うことがありませんでした。
今回、実際の既存システムを扱ったことで、コードを書くことだけではなく、「既にあるものをどう変更するか」という視点を持つことができました。
長期的に保守できるシステムについて
僕の大きな学びとしては、長く利用され続けるシステムにおいて「アーキテクチャや技術の選定」が鍵となるということでした。
もともと個人で開発する上ではトレンドである技術や学びたい言語から技術スタックを選ぶことが多かったのですが、ここで重要となるのは、維持できるシステムを作るには金銭的コストだけでなく学習コストや人員なども関わってくるということです。
例えば、どれだけ技術的に優れた構成であったとしても、その技術を扱える人が少なければ、将来的に担当者が変わったときに保守することが難しくなる可能性があります。
この学びから僕自身もアーキテクチャや技術スタックの選定を今後のことも視野に入れて複数人で長期的に維持できるものにする力を身に付けたいという目標も明確になりました。
今回の経験から、そもそもシステムは「保守されるもの」として考えるのではなく、「保守できるもの」として設計することが重要なのではないかと考えるようになりました。
また、既存コードを読み解く上でルーティング、コントローラ、サービス/リポジトリ、モデルの流れで確認し、言葉上の理解だけではわからないため、実際にどのような処理をしているのかを見ていきました。また、なぜRepositoryとInterfaceをそれぞれ別々で作成しているのかを考えるとテスト時に余計なDBアクセスを省いてモックできる利点があると思いました。
デプロイについても、テスト環境、ステージ環境、本番環境という複数の環境を使い分けていることを知り、実際のサービスでは開発したものをそのまま本番へ出すのではなく、安全に変更を適用するための仕組みが必要であることも学びました。
(デプロイ環境のイメージ、アイコンはFont Awesome Freeさまより)
また、今回の作業を振り返って、あらかじめ「共通化できるものの洗い出し」をしておけばよかったと感じました。
技術選定の理由を言語化する習慣
メンターの方とお話しする中で、技術選びの考え方など、自分自身が気づかないうちに技術スタックを選んでいる理由、「なぜ、〇〇を選んだのか？」を「見える化」することの必要性に気づきました。
例えば、僕は「無料でサイトを運用したいからSSGを選ぶ」や「基本一人で開発するが、今後二人ほどOSSにコントリビュートしてくれるかもしれないのでドキュメントを整備しておく」などのように、普段は無意識に判断していることも「なぜその技術スタックや設計、リソースを用いたのか、選んだのか」といったことを言語化し、記録しておく習慣がとても重要であると思いました。
レビューを受けた上での学び
移行作業をする中でAPI移行対応としてフロント側のエンドポイント切り替えでAPI仕様を変更した際に型の考慮など見落としていることがありました。
また、パスパラメータ(例えばGET /api/user/{id})では、そのパラメータがなければそもそもルーティングされないのでパラメータが必須であるというバリデーションは不要であるということも学びました。
このように、同じバリデーションでもどこから値が渡されるのかによって必要な確認が異なり、APIを実装するときには単純に値をチェックするだけではなく、ルーティングや型なども含めて考える必要があると分かりました。
さいごに
今回のインターンの中で開発だけでなく、設計やテストの作成など多くのことを経験し、考え方なども学びました。
リモートであるため、人と関わるのは画面内やSlackでしたので実際にオフィスでも働いてみたい！と思いました。
また、もしかしたらものすごく当たり前のことを言っているのかもしれませんが、AI時代（AI時代じゃなくてもそうだけど）だからこそシステムは保守できる人がいないと維持できないということに気付かされました。
どうしても個人の開発では流行りや好きな技術、アーキテクチャを選びがちになりますが、学習コストや技術を利用できる人員数から考えて維持できるかどうかはまた別であるというのが大きな学びでした。
僕自身の知らない領域、学校の勉強や個人開発、資格試験では得られない、想像以上の実務経験とエンジニアとしての学びがあり、大変良かったです。そのため、リソースなども考慮した長期的に保守できるシステムを設計から考えられるITエンジニアになりたいとより明確に目標が僕の中で定まりました。
BB事業部のメンターの方、エキサイトの皆様、1ヶ月、本当にありがとうございました！！
