25年卒ソフトウェアエンジニアのインターンシップを開催しました！
みなさん、こんにちは！エンジニアリングチームリーダーの杉山です。
2024年1月22日(月)から26日(金)までの五日間、25年卒ソフトウェアエンジニアのインターンシップを当チームで開催しました！
この記事では、インターンシップの内容を紹介すると共に、参加いただいた2名の学生：宮武さん、風折さんが最終日にまとめてくれた取り組みレポートも紹介したいと思います！
インターンシップ概要
今回のインターンシップは
Next.js / React を利用した myTOKYOGAS フロントエンド開発チーム
Flutter を利用した新規モバイルアプリ開発チーム
の 2チームに分かれて開催しました。
また、開催にあたって、以下の観点を重視しております。
実際のプロダクト開発に携わること。
参加者一人ひとりにメンターがついてサポートすること。
スクラムのイベントに参加してもらうこと。
ビジネス部門となるべく多くの交流を持つこと。
ワークショップ形式も検討しましたが、やはり実際のプロダクト、さらに今後リリースを予定している画面や機能の開発を行う機会を得られる方が良いのではないか、と考えました。そのため、チームから2名、メンターとして参加してもらい、適宜ペアプロなども行いながら、五日間で機能をリリースできる状態までもっていけることを重視してタイムスケジュールを組んでいます。
myTOKYOGAS フロントエンドチームで開発していただいたものは、次スプリントでリリースすることを目指しています！（モバイルアプリ側は初回リリース時に取り込めるようレビュー中です！）
また、開発チームではスクラムを取り入れているため、デイリースタンドアップや、スプリントレビュー、レトロスペクティブにも参加いただき、エンジニアチームの雰囲気を感じてもらうことも重視しました。そして最後に、やはり事業部門の中に発足した内製開発チームの特徴として、ビジネス部門との距離が近いというのもありますので、できるだけ交流を持てるイベント（ランチ会やミーティングなど）に参加してもらうことで、エンジニアチームだけでなく、会社としての雰囲気も感じてもらえたら、と考えていました。
最終日の発表会🎉
いきなり時間が飛んでしまいますが（汗）、メインはインターンシップに参加いただいたお二人からのレポートということで・・・ここでインターンシップ最終日の発表会の様子を！
発表会には、マネージャーの及川をはじめ、当グループのビジネス担当、デザイナー、ソフトウェアエンジニア、そして人事部が参加してくれました🙌
スライドにまとめたものを発表し、プロダクトのデモを動かすなど、短い時間で作成したにも関わらず、素晴らしい発表でした👏👏
当日は現地の会議室で大きい場所が無いこともあり、オンライン参加の方が多かった（オフィスに来ているのに画面越しの方も・・・）ですが、みなさん口を揃えて「良かったですね〜！」と言ってくれました！（ということを宮武さん、風折さんにも届けたいっっっ📢
参加者：宮武さん、風折さんからの寄稿
それでは本題としまして…ここで参加いただいたお二人からの取り組みレポートをご紹介します！まずはモバイルアプリチームの宮武さんからです！
モバイルアプリチーム：宮武さん
初めまして。大阪大学大学院の宮武碧です。
趣味はピアノやバイク、キャンプです。BUMP OF CHICKENを崇拝しています。普段は音の信号処理を扱う研究室で、音楽情報処理をテーマに研究しています。東京ガスで5日間のインターンシップに参加し、本稿を執筆させていただいています。
インターンシップに応募した理由
夏に他社のインターンシップに参加してFlutterに出会いました。そこで、書いたプログラムが普段自分が使っているiPhoneで実際に動作することに喜びを覚え、アプリ開発に興味を持ちました。
趣味でアプリを作ったりする中で、東京ガスでFlutterを使ったアプリ開発のインターンシップが開催されることを知りました。「実際の現場でどのようにアプリが開発されているのか知りたい。」「自分の力がどれほど通用するのか挑戦したい。」といった気持ちでインターンシップに応募しました。
スクラムの実践
開発はスクラムというフレームワークで進められました。チーム開発の経験が乏しい私は、スクラムを初めて知ったので簡単に説明します。
ソフトウェア開発の方法として
上流工程から下流工程まで、順番にこなしていく「ウォーターフォール開発」
小さい単位での開発を繰り返す「アジャイル開発」
の2つが主流だと思います。
スクラムはアジャイル開発の派生のようなもので、「スプリント」と呼ばれる一定の期間（本チームでは2週間）ごとに目標の設定から要件定義、実装、リリースまで行います。
主なスクラムのイベントは以下の通りです。
デイリースクラム
スプリントゴールを満たせるかの確認のため「昨日やったこと」「今日やること」「課題」を毎日共有
必要に応じて「課題」をみんなで考える
プロダクトバックログリファインメント
受け入れ条件を明確にし、タスクを見積つもることができる状態にする
タスクの見積もりを行う
スプリントプランニング
スプリントゴールに向けてタスクの割り振り
スプリントレビュー
ビジネスサイドから達成したタスクのフィードバックをもらう
次回以降のスプリントのリリース計画や戦略を考える
スプリントレトロスペクティブ
スプリントを振り返り、チームの改善を目指す
短い期間で開発を回して、価値を最大化する。というのがスクラムの特徴だと感じました。
開発について
開発した細かい内容は非公開情報のため書くことができませんが（杉山注釈：リリースをお待ちいただければ幸いです…！）私が体験した開発の流れなどを書きたいと思います。ざっくりと書き下すと
必要な機能を考える
機能の実装に必要な要素を考える
コーディング
リファクタリング
テスト
レビュー
という順になります。以下に詳細を記します。
1. 必要な機能を考える
本来はスプリントバックログというスクラムにおけるタスクの一覧から、優先度の高いものを選択します。しかし、今回はインターンシップということもあり、自分で必要な機能を考えることからスタートしました。
「お客さまはアプリに何を求めるか？」を考え、与えられた時間や自分の技術力を考慮し、少々挑戦的なタスクを目標に設定しました。
考えたタスクは当然（？）スプリントバックログに存在し、担当させていただくことになりました。
2. 機能の実装に必要な要素を考える
要するに設計をします。機能の要素を分割して、それぞれの要素はどのような要素から構成されて…といったことを考えて書き出していきます。UIの配置はもちろん、ウィジェットにどのようなプロパティを持たせるかということまで考えます。振り返ると、ここが一番大切だったと思います。
3. コーディング
実際にコードを書いていきます。
「チーム内での決まりごと」のようなものがたくさんあり、『これが本当のチーム開発だ』と勉強になりました。例えば Text ウィジェット一つにしても、独自のウィジェットを定義しています。他にも、フォントサイズやUIの幅なども厳密に定義されています。
コーディングで詰まると社員さんが、「ここは本質じゃないから答え教えるね」「ここは大切だから自分で考えようか」と、私が成長できるように助けてくださりました。
4. リファクタリング
後述しますが、チームによるソフトウェア開発は、個人の趣味のアプリ開発とは次元が違うものでした。ソフトウェア開発は「保守性が高い」ことが大切で、コードの可読性が求められます。
恥ずかしながら、最初に私が書いたコードは「とりあえず想定通りに動けばOK」のようなものであり、お世辞にも保守管理に優れているとは言えないものでした。
とりあえずの動くものを書いた後、可読性を高める作業にあたります。（最初から綺麗なコードをかけるべきではありますが。。。）ロジックをシンプルなものにするのは当然として、コンポーネント分割の考えが特に自分に足りていないと感じました。
5. テスト
作成したアプリの挙動をテストコードを書いて実証します。一見すると正しく動作すると思っていたプログラムでも、実際にテストを通すと多くのエラーが出て驚きました。そもそもテストコードという概念を知らなかったので、これも学びの一つでした。
6. レビュー
実際に作成したアプリをビジネスサイドの人に見てもらい、OKか判定してもらいます。エンジニアの方にも意見をいただき、より良いものにしていきます。
学んだこと
スクラムのフレームワークを教えていただき、実際にチーム参加して開発を進めました。今回は5日間というスプリントの中の一部の期間でしたが、チーム全体として成長できるフレームワークであると実感しました。
また、チームのソフトウェア開発を通して、自分が書くコードは誰もが理解しやすいものであり、保守性に優れる必要があると学びました。リファクタリングの考えはソフトウェア開発のみならず、日頃の研究のコーディングにも役立てることができるので、練習して身につけたいと思います。
本筋から逸れますが、多くの社員さんと交流する機会を設けていただきました。多くの会社を渡り歩いたつよつよエンジニアの方だらけで、会社選びなどの観点などでとても説得力のあるお話を伺うことができました。
感想
私が過去に参加したインターンシップでは、「業務の雰囲気を理解すること」であり、インターンシップ用の課題が与えられていました。しかし、このインターンシップでは実際の業務に携わるという大変貴重な体験をさせていただきました。
また、私が書いたコードがメインにマージされたときは「本当に私が書いたコードがリリースされるんだ。」と達成感を覚えました。
ソフトウェア開発をする上で、知っておくと良い考え方や本をたくさん教えていただいたので、これからも勉強を続けたいと思います。
宮武さん、執筆ありがとうございました！メンターのモバイルアプリ開発チームリーダー：北沢とともに、熱いディスカッションを交わしながらプロダクト開発をしている様子が印象的でした！実際の開発現場での経験を、ぜひ今後のエンジニアライフで活かせてもらえたら嬉しいです！
続いて、myTOKYOGAS フロントエンド開発チームの風折さんです！
フロントエンド開発チーム：風折さん
インターン応募動機
これまで経験してきた技術的バックグラウンドとしてCやPython, PHP などの主にバックエンド側の技術を使ってきました。その中でフロントエンド側の技術に自分自身の課題があると感じ、React の勉強を始めました。ちょうどそのタイミングで本インターンシップに出会い応募させていただきました。また、note の内製開発の記事を拝読し、大きな企業・組織の中でも立ち上げフェーズがあるというギャップ感と、そのチームでどのような開発やチームビルディングが行われているのかを知りたいという思いも応募動機の一つです。
インターン業務内容
業務内容としてはスクラムの一環としてスタンドアップやスプリントレビュー、レトロスペクティブに参加させていただきました。また、開発では新しくコンポーネントを実装しました。（開発内容セクションにて詳細を書きます。）
朝に開催されるデイリースタンドアップでは、昨日まで取り組んだことや今日取り組むこと、課題として感じていることを共有しました。課題を共有し、それに対してわかる人が適宜答える和やかな雰囲気で、チーム全体としての温度感を一番知ることができた機会だったなと感じています。
スプリントレビューではスプリントプランニングに対する振り返りをしました。その中の議題としてサニタイズの話題が非常に興味深く、myTOKYOGAS の開発についてのリアルを知ることができました。
開発内容
実装したこと
具体的な実装内容としては、PageTitle コンポーネントと CautionTitle コンポーネントの作成です。それぞれ、UIのページタイトルに当たる部分とエラーメッセージ表示時のタイトルに当たる部分をコンポーネントとして共通化しました。
実装するに至った背景
実装するにいたった背景としては、タイトル部分のUIが統一されていないという問題があった点です。従来の PageHeading コンポーネントではタイトルのほか、その前後のカテゴリとキーメッセージを表示するコンポーネントとして機能していましたが、キーメッセージがコンポーネントに含まれていたり、そうでなかったりと統一されていませんでした。そのことによって変更するためのコストがかかったり、適用されている CSS が微妙に異なったりする事象が発生していました。
また、UIが一通りまとめられている Figma と、実際のソースコードとで props 名の相違がありました。Figma ではタイトル、カテゴリ、キーメッセージと命名されている一方で、従来の PageHeading コンポーネントの props 名は、タイトルが subject, キーメッセージが caption と定義されている状態でした。それらの文言を統一するという意味でもこの実装に意義があったのかなと思います。
開発プロセス
まず、すべてのパスに対してタイトル・カテゴリ・キーメッセージにどのような文言が表示されているのかを確認するために、Notion にリストアップしました。
次にその Notion を確認しながら、タイトル・カテゴリ・キーメッセージを共通化した PageTitle コンポーネントと、エラーアイコン・エラーメッセージを共通化した CautionTitle コンポーネントを実装しました。
実装後は結合テスト、Lint によるコーディング規約の確認、Prittier によるコード整形、不要なインポートファイルの削除、E2E テストなどのテストコードやフォーマット等を確認し、プルリクエストを作成し、適宜レビューして頂きました。
この部分に関しては、自分自身TDDについて勉強し始めたタイミングで、どこに対してどのようなテストを書くべきなのかを少し考えたりテストコードを書いてみたり、それに伴ってテストコードの難しさやありがたさを感じていました。
myTOKYOGAS のコードではテストコードがかなり整備されているんだなと感じました。今後プロダクトをグロースしていくフェーズでも保守する際にも開発しやすそうだと感じました。
実装したことによるメリット
今回の実装でコンポーネントを共通化したことによって、ページごとに統一されていなかった UI を統一することができました。
UI をコンポーネントとして統一できたことによって変更の必要があった際にもコンポーネントを変更することで対応することができます。
また、DOM 構造も統一することができたため、エンジニアとデザイナーとの今後のコミュニケーションコストを低下させることが期待できるかなと感じています。
風折さん、執筆ありがとうございました！React の勉強をし始めたばかりにも関わらず果敢にインターンシップへ挑戦する姿勢は素晴らしく、私も見習いたいです！また、楽しみながらコードを書いており、時にものすごい集中力で開発していた姿も印象的でした！
おわりに
改めて、インターンシップに参加いただいた宮武さん、風折さん、ご参加ありがとうございました！＆おつかれさまでした！この場を借りて、改めて御礼申し上げます。
そしてインターンシップのメンターを務めてくれたフロントエンド開発チームリーダーの中嶋さん、モバイルアプリ開発チームリーダーの北沢さんも、本当にありがとうございました！
当チーム初のインターンシップ開催ということで、まだまだ至らない点も多かったかと思いますが、少しでも学生の方々にとって学びとなったのであれば幸いです✨
私もお二人から刺激を受け、ますます頑張っていこうと思いました！それでは今回はこのあたりで・・・また次回の投稿でお会いしましょう！