エイチームインターンシップ

8月28日から9月1日の5日間で、名古屋本社でライフデザイン部でのインターンシップを参加した。主なテーマは実際のサービスのユーザーにヒアリングを行い、機能を提案し、開発してリリースするという流れ。

全体の流れ

day 1「ビジネス・組織・プロダクトの理解を深めよう」
オリエン・環境構築・ゴール設定

day 2「issueを作ってみよう」
調査をしたり、関係者にヒアリングをして課題設定・仮説立てをしてみよう

day 3「設計・開発」
issueを実現するためのアプローチと具体的な変更内容を設計しよう

day 4「開発」
設計に合わせて開発してみよう

day 5「ふりかえり」
インターン全体の振り返りと設定したゴールに対して自己評価を記載・メンターとのFB面談・お片付け

一日の流れ

出勤打刻
チームの朝会に参加（ハドル）
メンターとその日の動きをすり合わせ
〜　タスクを実施　〜
メンターと1on1
振り返りを記入
退勤打刻

Day 1

朝会で自己紹介をして、WSL2でnodeをインストールしたりやレポをクローンしたりして環境構築を行った。お墓の種類などのドメイン知識で事業を説明した。最後に1on1面談を行った。そこで、まずはゴールを設定をした。今回のインターンでの目標は3つの観点に分ける

ビジネスドメインや課題解決（インターンの課題を成功させたい）

価値がある提案をして、リリースまでやりたい（結果を残したいと思っている）
課題に対して提案できる

技術的に成長

フロントエンドがメインなので、やる機会が少ないユニットテストやe2eを書きたい
リリースまで見たい
コードをたくさん読む

会社を知る

エイチームのエンジニアの働き方を知る
前のインターンでは受託、今回は自社、違いはどういう感じなのかな？
色々な人と話す
たくさんメモして、アウトプットでのブログを書く

第一印象

オフィスがきれいで、社員とのお話が楽しくて、すごくフレンドリー。また、自由度が高く、やりたいことがあって伝えたらやらせてもらう感じがある。
しかし、一日目で何をやるのかまだちょっとわからないし、明日の課題をヒアリングが結構心配。

今日はインプットが多くて、コードを読んだり、お墓の話を聞けたりできた。
この5日間は、技術的な成長よりも、いろいろな事例を知った方が成長するだろうと感じた。

受託系ー＞何かに困って課題を用意してー＞機能の提案をするけど、自社開発は違う。

要求と要件が違う。お客さんから要件がいきなり出てくるのが多いけどそれはエンジニアが考える。要求を聞いて。エンジニアは要件を出し、深堀をする形で行われるべき。

技術半面

Kibanaを使ってみて、クエリーをしてみた。GraphQLがTSとcompatibilityが良く、スキーマで取得でき、パスが増えても心配ないのね。

サービスはVercelにデプロイしたが、ページにアプリを分け、高速化できたらしい。
めっちゃ面白いから、これを読んでみて！

検索にかかわる静的なメディアがOpen Searchに入れて、readのスピードが爆速できるが、アクセシビリティの関係ないwriteのスピードが同じになっている。

Day 2

サービスのadminページの課題をヒアリングして、設計をして、issueを切って、開発に入る。ヒアリングする前に面談などで準備をした。

ヒアリング準備

WhyとHowの観点でヒアリングを行う

Why から聞くとき

なんの作業が多いのか
どういうところに困っているのか
よく使う部分で、インパクトが大きい部分はどこなのか

Howからアプローチ

開発コストが少なく、簡単に実装できる細かいところ
手段がいくつか出して、実装が簡単にできる

コスパを考えた上でヒアリングするべき

コスト：開発工数
パーフォーマンス：インパクト

「なぜやるのかの背景を知る。それで要求を知る。じゃ、それはXじゃなくて、Yでやったほうがいいじゃない？と提案する」という流れで実施したい。

自社サービスは、事業部の提案できるエンジニアの活躍が評価される
学生の間にいろいろな会社の話を聞く、視野を広げる

ロジカルシンキングも必要になる。ここでMECE (Mutually Exclusive, Collectively Exhaustive)を知った。

トップダウン（全体からブレイクダウン）：分類方法が想定しやすい
ボトムアップ（詳細を集めて全体像を書く）：全体像が見えてない、存在しない
これめっちゃわかりやすい

ヒアリング

実際にヒアリングを行うとこういうフローの流れを用意しといた

CSの仕事フローを教えてもらう（ここでどういう働き方があるのかを知る）

インパクト

そのフローで一番時間がかかる所はどこ？（What、インパクトが一番大きい）
そこでは問題とか課題を感じる点はあるのか？（Where）
感じたらなぜ？ー＞どんどん深堀をする
それはどう解決できるのかを提案する

コスト（インパクトをヒアリングしつつ、提案する）

各手段の面倒くさいところをいくつかをあげる
それぞれは深堀をする
要件提案

また、機能のリストアップをして、それを参考にして行った。

結果

実際サービス・仕事・事業などの理解が浅く、イメージしづらいところはある（どういうところがイメージつかないのかがわからない）

重要視点、一番時間がかかるページ、どういう感じで仕事フローがあるなどを聞けた。
ヒアリングを通してサービスの理解とカスタマーサポートの仕事の理解が上がった。また、バグや追加してほしい機能の要求ももらった。ここで、顕在ニーズと潜在ニーズという言葉を知った。

しかし、実際サービス・仕事・事業などの理解が浅く、イメージしづらいところはある（どういうところがイメージつかないのかがわからない）

顕在ニーズ

そのまま質問を投げる

潜在ニーズ

ほしい所だけど、気づいていない
状況とか過去の経緯、事実の部分を並べる
例：年齢、嫌いなもの、好きなもの、事実から仮説をして提案する
業務フロー、ボタンを押したら他のページに行くとかの順番。それはユーザーが気づいていないけど、実際は不便だとか

フィードバック

顕在ニーズがあまりできなかったが、主に潜在ニーズを聞いた。顕在ニーズから聞く順番の方がいいかもしれない。そして、前提などヒアリングの目的を最初に話すといいかも（ミーティングも一緒で、今日はここまでやって、達成するとOKという感じ）
今回は社内システムのため、ヒアリングが簡単にできるけど、事業者などに変えたらもっとややこしい。しかし、一般消費者や事業者に変えてもアプローチがあまり変わらない。手段としては、例えば

実際に話を聞く
消費者とかだとGoogle Analyticsなどで数字をとって、仮説を立て、マーケティングとかUXデザイナーなどと一緒に考える

反省点

会話の流れで、どういう質問をして、質問をしたらどういうつながりをするのかみたいなのはできなかった
どういう質問をすればいいのかあまり得意じゃなかったので、頑張ります！
やっぱりいい経験だし、将来こういうことするのが多くなるでしょう。

気づいたヒアリング方法

まず、ゴール設定、何をしてヒアリングするのかを最初にアジェンダを伝える。質問するときに、事情を話してから質問をする。たまに、そのまま質問をして、どんどん深堀をする

言っておきたいところを聞く
見た目情報
などなど

そして、潜在ニーズという気づいていないところを探り出す。最後に重要ポイントを番号付けて、重要度を決める。そこから、エンジニアはコスパを考えて、機能提案をする。

開発

今日はformのvalidationを書いて、テストコードを書いた。事前にRTLとJestを使ってみてよかった。

Day 3

今日は開発集中タイムだ！昨日のタスクの続きをやる。

主に3つのタスクに取り組む

フォームのvalidation
フィールドの表示
紐づきが難しい設計の提案・実装

issueをきる→プロトタイプ→実装→テスト→レビュー→フィードバック
という流れで開発をしている。サービスはいろいろな事業との連携があるため、設計したプロトタイプをお客さん（今回は社内システムのため、社員）に提案して、フィードバックをもらう。フィードバックによって仕様の変更や追加開発もある。

フィードバック

きれいにコードを書けた
単純に機能を完成させるだけでなく、これだと見づらいとか、もっとこうした方がいいなどの提案ができてとてもよかった
デザインの提案いついてはチームのエンジニアと相談したが、実際はデザイナーと相談した方がよかった
- 前のインターンでは自分のチームのエンジニアしか会っていないので、その手があるとは気づいていなかった。今回は勉強になった。
一個一個の実装機能にはどういう手段でやるのか、なぜ実装するのか、なぜこのメソッドや進み方をするのか、論理的に考えるといい
レビューされる、そしてレビューするとどんどんスキルが伸びていく

受託と自社開発の違い

受託開発

ゴリゴリ開発する
いろいろな案件に携わりたい、いろいろな技術触りたい人向け
技術として成長したいなら受託が向いているかも

自社開発

サービスをよくしていきたい
- 機能の提案・いいプロダクトを作りたいのがベスト
ビジネススキルをよくしたい
やっぱ自由だなー
- 自分で調査して、作業を進んで、色々な職種の人と連携して相談して
- 自分で考えるというのがすごく感じた
- 自走力や行動力があればめっちゃ向いてそう

Day 4

今日は開発Dayだ！
RubyとRails初チャレンジ。次のインターンもRails使うので、Railsやってみたいと言ったらissue作ってもらったので、すごくありがたいです！adminの権限ページとrole policyを作成。明日までやるけど間に合うかどうか頑張る！

TSで型書くときはできれるだけundefinedにして、filterをしたら、nullにしてガードケースを書くよりも綺麗にかけたなー

interface Example {
    y?: string
    z?: string
}

Object.values(examples).filter((ex) => ex)

nullにした場合

interface Example {
    y: string | null
    z: string | null
}

const x: Example = [
    x.y
    x.z
]

if(!x) return
if(!x.y) return

Day 5

Rails初からAdminの権限のCRUDと一覧ページが完成できた！
ちょっと仕様の認識がずれて、フィールドが間違ったことテストが未着手ということがあったが、よくできたと思う！

少しサーバーレスの話をした。

人的コスト低い、補修コスト高い
伝統的なものが反対
大きいチーム、事業なら伝統的ー＞フェーズにもよる

メンターフィードバック

技術として問題なし
わからないことがあったら、まずは調べてどこまでできるのかをちゃんと説明して、仮説を立てて提案する形ができた
コミュニケーション（テキストベースと口頭）は問題なし。アピールした方がいい。
小学生のマイクラサーバー立ち上げ経験は面接でうけそう
どういう進み方がわからないときはいろいろプロジェクト内に調べて参考にしたり、PRやコミットを見てみるといい

アドバイス

考え方

ロジカルシンキング
- MECE
- 5w1h
クリティカルシンキング
色々な場面に役に立つ

開発

readable code
SOLID
長期目線
- 新しいメンバーが見てわかりやすいか
- 長期的な運用や変更に耐えられるか

ヒアリング

前提を揃える
ヒアリングの背景や目的を伝えて、ヒアリングのゴール設定をする
顕在ニーズ・潜在ニーズ

今後のアドバイス

コミュニケーション場面問題ないとアピールした方がいい
今やっている就活で色々な会社を見るというのがベストだと思う。学生時代にやっておくべき。
モノづくりで何かを作って、どういう人に提供して、どういう価値をもたらして、なぜそれを作って、なぜこの技術を採用するのかを説明できるととても有利になる

感想

すごく自由で、自己責任が必要
やりたいことがあれば大体何でもできそう
インターンの内容がすごく自由で、何をしたいかをリクエストできる
one on one面談や振り返りが毎日やっていて、社員も日報を書くから、一日何をして何を成長できたかを実感できる
ずっとご飯連れてきたり、色々な人と交流できて、歩んできたキャリアパスや考え方が勉強になった
リリースした改善が高評価で、盛り込んでたらしいから、とてもうれしい！

今回参加したインターン