はじめに
7月から8月にかけてAteamエンジニアインターンシップに参加させて頂き、主にフロントエンド開発に携わりました。
業務や社員の方々との対話を通じて、技術だけではなくエンジニアとしての方向性について「ふっと霧が晴れたかのような」体験がありました。
簡単にではありますが、インターンでの体験や得たものについて記録を残そうと思います。この記事が次のような方々の役に立てれば幸いです。
本記事の主旨は以下２つです。
- Ateamインターンの業務内容と学び
- Ateam社員の方々との対話と学び
読んでほしい人
- 大学生や高専生
- インターンの雰囲気を知りたい人
- エンジニアとしての方向性に悩んでいる人
- エンジニアになりたいけどプログラミングを始めたのが遅かった人
- Ateamへのインターンや就職に興味がある人
Ateamの簡単な紹介
Ateamは名古屋に本社、大阪とベトナムに支社を持つ総合IT企業です。
実は、このQiitaもAteamが運営するサービスの一つです！
私が勤務したのは名古屋で、名駅からわずか徒歩30秒の大名古屋ビルヂング31F,32Fにオフィスがあります。景色もオフィスも綺麗、名駅から近い、食堂のご飯が美味しい、と非常にありがたい環境でした。
書いている人
- 大学3年, 物理系 (主に量子力学まわり)
- プログラミングの類を始めて１年未満
Github / Notion Blog
プログラミングの類は、大学２年の秋頃に始めました。
それまでは「やりたいこと探し」と称してアフィリエイト・ライティング・記事販売...などなどを目標設定・達成して「やりたい」と感じなかったら次へ、というのを繰り返していました。そこで最終的に辿り着いたのがウェブエンジニアでした。
現在はバックエンド・フロントエンドを中心に業務と個人開発をしています。
公開しているものだと、例えば以下があります。
- 熱中症搬送者数予測サイト
- NIT研究室HP (現在改修中)
Ateamインターン参加の目的
結論から言うと、以下4つがAteamインターン参加の目的でした。しかしながら、インターンではこの目的以上に得るものがありました。
- 効率よくフロントエンドのモダン技術を身につける
- 共通化を意識したコードを身につける
- 実務に触れる
- 多様な職種の社員さんから話を聞く
詳細は少し長いのでこちらに
1.効率よくフロントエンドのモダン技術を身につける
インターン応募当時、プログラミングの類を始めて約半年の私はReactやTS等にあまり触れていませんでした。当時もそれらの便利さは感じていましたが、諸事情で技術を学ぶ十分な時間がありませんでした。そこで、時間対効果の高いやり方としてインターンを選び、実務のなかで身につけようと考えました。
結果としては、業務で使用したTS,React,ReactAdmin,Mui,OpenSearchはそれなりの自信をもって書けるようになりました！
2.共通化を意識したコードを身につける
これは単純明快で、時間対効果の高いコードを書いた方が事業利益を高めやすいからです。現場のコードから学び、実際の課題解決の中で意識してコードを書くことで、共通化の思考を磨くことができると考えました。
結果としては、共通化はある程度身につきましたが、それ以上に「不要な副作用のないコード」「根本から改善しようとすること」などの大切さに気付かされました。詳しくは後述。
3.実務に触れる
これは自分がエンジニアとして働く姿をイメージし、どう働きたいかを考える材料とすることが目的です。今まで少人数でのチーム開発と個人開発、小規模開発しかしてこなかった自分にとっては、まさに必須の思考材料です。
結果としては、実務を経験すること(正社員と完全に同様な業務という訳ではない)と他のエンジニアの方の実務を見ることで、自分が働く姿をイメージできましたし、仕事にポジティブな感情を持つことができました。
4.多様な職種の社員さんから話を聞く
これは視野を広げることが目的です。エンジニアだけでなく、例えばマーケや人事の方から話を聞くことで、広く事業に対する視座を高めたいと考えていました。また、エンジニア以外の職務にも興味があったため、仕事内容やどうやって成長したかについて聞きたいと考えていました。
結果としては、エンジニア・デザイナー・マーケ・人事・CTOなどの方とお話をして、自分の「エンジニアとしての方向性」を再定義することができました。詳しくは後述。
業務内容
配属先はライフスタイルサポート事業のライフエンディングで、Life.というお墓・葬儀・仏壇・相続などのサービスに関する業務です。
時間 → 大体10:00~19:00で1週間に3日勤務
お昼 → 大体13:00~14:00にランチと昼休憩
具体的には、とある検索ツールの機能拡張を行いました。このツールは、ユーザへ最適な提案するために主にコールセンターが使用します。
業務スタイルとしては、挙げられたイシューを選んで着手していくスタイルです。自分の場合は、自ら提案してイシューを立てることもありました。
使用技術
- Lang/FW → TS, React, ReactAdmin(以下RA)
- Other → Mui, OpenSearch(以下OPS)
ちなみに、インターン応募時に上記技術をすべて身につけている必要はないと思います。
実際、私はインターン参加が決まってからTS,React,Muiを始めましたし、RA,OPSに至ってはインターンで業務をしながら身に付けました。
具体的なイシューと作業
Ateamインターンの雰囲気をイメージしやすいように、具体的にどんなイシューでどんな作業をしたのかを、かいつまんで紹介します。
イシューにはおよその難易度が低/中/高でラベル付けされており、難易度:高のなかでもOPSが絡んでいるとそもそも「実現可能性の調査からお願いします」というものもありました。そのイシューにはかなり苦戦させられましたが、どう解決するかのPDCAの回し方を洗練させることができ、非常に良い経験になりました。
最初は難易度:低のものから始めるので、チーム開発などをあまりしたことがない人でも肩を慣らしながらスタートできると思います。
例1) マップ/リスト表示の改善
前提として、RAによってGoogleマップやリストを表示しています。
そこで「リスト上でトグルを開いたレコードをマップで強調表示」「条件にあったレコードをマップで強調表示」などのイシューを遂行しました。
これらは「ある条件下であるコンポーネントにあるスタイルを追加するもの」として抽象化し、コードを共通化させて対応しました。例えば、マップアイコンのコンポーネントのpropsを追加し、特定条件下ではそのpropsによってスタイリングされる、など。
例2) 選択categoryの最小価格の最小価格でソート
前提として、OPSによってデータ取得・検索を行っています。
選択categoryの最小価格の最小価格とはなんぞや？
→下記テーブルならば、categoryのA,Bを選択した場合はid:1がB:10万円、id:2がA:80万円のことです。ただし、categoryを選択しなかった場合は全てのcategoryを対象としてソートします。
*下記テーブルは簡単なイメージです
| id | category | min_price | group |
|---|---|---|---|
| 1 | 種類A,種類B | 種類A:20万円 種類B:10万円 |
elemA(flagX) |
| 2 | 種類A,種類C,種類D | 種類A:80万円 種類C:5万円 種類D:30万円 |
elemA(flagX) elemB elemC(flagX,Y) elemD(flagY) |
これ、難しそうには見えないのですがかなり時間がかかりました。なぜかというと...
🧐categoryにあってもmin_priceにない場合がある(既存フィルターではダメ)
😢既存のgroupに関するソートでバグが見つかる
💡min_priceの取得にはOPSでexists,nullチェックで２重のチェックが必要だった
😱APIと3回通信しており2回目の通信でcategoryを指定するidがnullになる
😇OPSのインラインスクリプトでエラー祭り
などの点でつまづいたからです。苦しい時間でしたが、地道にデバッグして原因を分割・特定・解決し完成にこぎつけました。このイシューでは例えば、以下の作業を行いました。
- Postmanで複数パターンのクエリを投げて原因推定、エラー原因レコードの推定
- OPSで使用しているpainless言語で使用しているJavaの言語仕様を読んで原因推定
- フロント側で使用可能なパラメタを利用してnullになってしまうidを復元する (OPSのバックエンドは権限上いじらせてもらえませんでした...)
- 既存機能を壊さないようにしつつ既存ソートの責任を切り分けて実装する
- categoryのOR検索の実装
例3) groupカラム内の特定要素を表示
これもOPS絡みのイシューです。
groupカラム要素のうち、flagXまたはflagYをもつ要素のみを表示します。例えば、下記テーブルのelemBは表示されなくなります。ただし、それだけではgroupカラムの要素が一切表示されていない(フィルターされている)レコードも表示されてしまうため、レコードに対してもフィルターする必要がありました。
*下記テーブルは簡単なイメージです
| id | category | min_price | group |
|---|---|---|---|
| 1 | 種類A,種類B | 種類A:20万円 種類B:10万円 |
elemA(flagX) |
| 2 | 種類A,種類C,種類D | 種類A:80万円 種類C:5万円 種類D:30万円 |
elemA(flagX) elemB elemC(flagX,Y) elemD(flagY) |
このイシューでは例えば、以下の作業を行いました。
- OPSの_sourceでgroupカラムを取得しないようにし、inner_hitsでgroupカラム内の要素をフィルターして取得
- フロント側でレコードにinner_hitsをあたかもgroupカラムかのように結合
- OR検索でレコードをフィルターする
- フィルター用のUIを追加してパラメタをRAのdata-providerに渡す
例4) キー操作のみでの検索入力機能
これは自分で提案して立てたイシューです。
既存の検索入力欄では以下の問題があったため、入力作業の時間短縮を目的として「候補の1つ目をEnter1つで選択できる」ようにします。
問題1) 候補の1つ目が空白で、邪魔な上にこれを選択するとエラーになる
問題2) 候補を1つに絞れていても、↓を押してからEnterしないと選択できない
1はRAの公式ドキュメントを読んで適切な属性(allowEmpty)を設定すれば解決できました。
しかし、2はインターン期間中に解決することができませんでした...。
onKeyDownをコンポーネントにつければ良いと軽く考えていましたが、対象コンポーネントのAutocompleteArrayInputでは、onKeyDownでイベントが発火しませんでした。原因を探るためにRAの公式ドキュメントを読み漁るも原因は分からず。更に、RAによると本コンポーネントはMuiのAutocompleteを使用しているそうなのでMuiの公式ドキュメントを読むも原因分からず。仕方なく、RAとMuiのGithub上のコードを読みましたが、原因解明には至りませんでした。
1入力あたり1秒短縮→1回につき4つ入力→1日に100回使用、と仮定すれば、本機能の実現によって1ヶ月でおよそ2.4時間の短縮になっていました。実現したかった...。
今思えば、そもそもAutocompleteArrayInputをonKeyDownが適用可能なコンポーネントに置き換えるという戦略も試せばよかった、と後悔しています。
業務から得た学び
1. バグと正面から戦おう
そのバグの対処法だけを考えるよりも、まじめに原因を探った方が結果的には効率がいい、という話です。前者は0→1でしかない一方で、後者は0→10を実現します。良いコードが書ける上に、同質の問題を秒殺できるようになります。実際、OPS関連のイシューについて、まじめに調べたからこそ、1つ目のイシューは6日かかりましたが2つ目のイシューは1日で終えられました。さらに、既存コードの効率化も実施できましたし、再度似た機能実装をやるとしても順調に実装できる自信がついています。まじめに原因を探ると時間がかかりますが、それは一時的なものに過ぎません。私のようにプログラミング歴が浅い人やコンピュータサイエンスの知識がない人ほど、まじめに調べよう。
インターン中の実例で、バグの解決方法をクイズ形式で出してみます。
[Quiz] OPSのインラインスクリプトを用いて、あるレコード内のカラムの最小値でソートします。このとき、対象にする値の数が1~2つの場合は正常動作します。しかし、3~4つになると400エラーを返します。インラインスクリプトは以下のように書かれています(簡略化)。さて、どうやってバグを解消しますか？
// エラーが出るインラインスクリプト
_script: {
script: {
inline:`
def prices = [<値段を1~4つ取得>]
return Math.min(prices)
`
},
order: 'asc',
type: 'number'
}
[回答の1例] 私がこのバグを解消したやり方
(1) developer toolのネットワークのFetch/XHRからレスポンスのエラーメッセージを見る。すると、math.Min([price1,price2,...])の部分に問題があると示されている。
(2) Math.minの仕様をOPSの公式ドキュメントで調べる。特に問題はなさそうだ...原因わからず。しかし、OPSではインラインスクリプトを(デフォルトでは)painless言語というもので記述していると分かる。
(3) OPSのpainless言語を定義するGithub上のソースコードを読む。原因わからず。しかし、painless言語はJavaで開発されており、painlessのMath.minはJavaのMath.minを内部で使用していると分かる。
(4) Javaのmin関数について調べる。Javaのmin関数は引数が2つまでと分かる!!!
(5) min関数を使わない書き方をして解決!!!
min/maxが引数を2つしか取らないというのは全く思いつきませんでした。自分が今までに扱った言語では全て3つ以上取れるため、完全に意識の外になっていたようです(ts,rails,python,php,goは3つ以上取れる)。
ちなみに、min(A,min(B,C))な実装は値段をリクエストするためのパラメタ文字列の処理が面倒になるため避けました。
上記の例はまじめに調べたからこそたどり着けたものです。これを筆頭とするインターン中の経験から、具体的なアクションとして以下を意識するようになりました。
- まじめに公式ドキュメントを読む
- それでダメならGithubのソースコードを読む(node_modulesなどのファイルでも同様)
- それでダメならバージョン特有のバグを疑ってGithubのイシューを調べる
以下も便利なツールです。今まで全く使っていませんでしたが、業務の中でその強力さに気づきました。
- Githubのディスカッション
- stack overflow
2. 不要な副作用のないコードを書こう
不要な副作用があると、コード量に比例してコードが書きにくくなると考えられます。なぜなら、既存の副作用へ配慮したコードは大きく回り道をしたコードであり、そんなコードもまたコードを書きにくくしうるからです。プロジェクトに新しく参入したエンジニアにとって、副作用は未知数の化け物にすら見えるかもしれません。少なくとも私にはそう見えました。
実例が、「APIと3回通信しており2回目の通信でcategoryを指定するidがnullになる」という問題です(2回目)。これが、私がインターン中に遭遇した最も恐ろしい副作用です。このプロダクトがそんな恐ろしい副作用を孕んでいることには気づけず、別イシュー対応中に謎のバグとしてかなり時間を取られました。
結論として自分が得た学びは「不要な副作用のないコードを書こう」「不要な副作用を持つコードはいち早く対処しよう」というものです。
副作用 == 悪ではありません。あくまで、不要な副作用についての主張です。
関連資料
3. 根底からの改善は優先度が高い
以下の状況を想定しています。
事業上の改善が必要になり、新機能を実装をすることとなりました。しかし、機能実装の大きな障害となる悪いコードがありました。ここを変更せず大きく回り道して機能実装することは可能ですが、それを続ければ悪いコードはさらに増え、悪いコードの上に悪いコードが積み重なった地獄が生じえます。(その結果、開発速度は低下し、競合に先行され、その事業に回せる資金は低下し、さらにコードは悪くなり...という負の循環が生じえます。)
そんな、根底から改善する必要がある問題にインターンで出会いました。
「APIと3回通信しており2回目の通信でcategoryを指定するidがnullになる」という問題です(3回目)。この根底問題を直そうとせずに「まず今のイシューを解決しよう」と大きく回り道をして機能実装をしたのです。根底に巣食う問題を直さなかったが故に、次のイシューでも割を喰う羽目になりました。
根底問題に気付いた時にいち早くイシューを立て、メンターとレビュアーに承認を受けてすぐにでも着手すべきでした。インターン中に残りのイシューはできなくなるかもしれませんが、今後エンジニアがこのプロダクトを保守/拡張するときの手間を減らす、将来的な悪いコードを減らすというインパクトの大きい取り組みだからです。
もちろん状況によって問題解決の優先度は異なりますが「根底にある問題は優先的に解決せよ」という思想として保持しておきたい事象です。
4. パッケージのバージョンアップは大事
本プロダクトにおいて、最新版よりかなり古いパッケージがありました。それゆえに自分が持っている知識が使えなかったり、最新版の新機能の恩恵を受けられない場面がありました。かといって、パッケージのバージョンアップは他パッケージとの依存性の調査、既存コードのチェックの上で行う必要があるので、残りインターン期間が僅かだった自分にはできず、既存バージョンで四苦八苦することとなりました。
以上から、リリース後のバージョンアップは定期的に行うべき、という学びを得ました。
学びのうち2, 3, 4は、自分が関わっていなかった既存プロダクトを改善する、という今までなかった経験をしたからこそ得られた学びですね。
5. 作業効率が低い原因
他インターン生の方々と比べて、私は完了イシュー数が少なかったです。イシュー内容が異なるので単純な比較はできませんが、これは考察の価値がありそうです。そこで、自分は作業効率が周りより低いと仮定し、原因を探ってみました。私のように歴が浅いエンジニアには当てはまる人が多いかもしれません。
1) イシューと無関係なコードへの目移り
私は特定イシューの作業中でも、直接的には関係ないコードに目移りしていました。「ここ直した方が良さそうだな〜」「ここはなんでこんな書き方なんだ？」と意識が散ってしまっていたのです。
解決策
- 関係ないコードはメモを残して一旦無視する
- そのコードに重大なバグや副作用がありそうならすぐイシューを立てて着手する（「3.根底からの改善は優先度が高い」）
2) 根本の理解が疎か
私は今まで、まず動くものが作れるようになることを優先していたため、根本の理解が疎かになっていました。例えば、TSの言語仕様を話せと言われても話せず、Reactの概念についてもよく分かっていません...。この根本理解の不足により、同質の２つの問題が異質な２つに見えて、解決に２倍の労力を要する場合もあり得ます。
解決策
- その技術の思想、作られた経緯を理解する
- 普段の開発とは別で、公式ドキュメントをまじめに読む時間を作る
3) 今まで書いたコード量の不足
周りのインターン生を見てみると、プログラミング歴4~6年、情報系の学部生・院生しかいませんでした。対して自分は１年未満で物理系、今まで書いたコードの絶対量が圧倒的に少ないと考えられます。その結果、周りが「このパターンならこう書けばいいよね」とすぐにできる部分を、私は手探りでやっている可能性があります。
解決策として、以下２つを並行でやれば学習効率が高まりそうです。並行でやれば、根本概念(抽象)とパターン(具体)を行き来することができます。これにより、このパターンはこの概念によればこう説明できる、という思考から理解が深まると考えられるからです。
解決策
- 根本理解をもってしてコードを書く（上述）
- パターンに落とし込まれたものを把握していく
Ateam社員の方々との対話と学び
多様な社員の方々との1on1やランチ
1on1やランチをSlackで直接お願いしたり、メンターの方・人事の方を通してお願いしていました。皆さん快く応じて下さりましたし、「どんどん頼んでいいよ！」と言って下さってとてもありがたかったです。
エンジニアとしての技術面と事業面、ビジネス職での事業への関わり方やビジネスモデルなど、幅広くお話を聞かせて頂きました。その例を以下に示します。
例の他にも、新卒１年目のエンジニアの方、デザイナーの方、異なる事業領域のエンジニアの方、デザインマネージャの方など、多くの方々とお話しさせて頂きました。本当に、ありがたい限りです。
例1) マーケ→事業責任者→人事の方
新卒でマーケとしてSEO記事ライティング、次に新規事業の責任者、現在は人事をしている方です。
最近だと、人事として新卒採用に関する人事評価のオペレーションの新規策定および効果測定を行っているそうです。これについて、オペレーション刷新の経緯・新卒社員の評価方法・オペレーションの評価方法などを詳細にお聞きしました。このお話から、自分はやはりオペレーション、やり方づくりにも面白さを感じると再発見しました。
また、Ateamの新卒採用での重要項目についてお話し下さいました。記事公開もされている部分のみを書くと、情報を構造的に理解できる・思考の体力がある、などを満たす人を求めている、とのこと。これらは「後天的(生後３ヶ月以降)に獲得することが難しい特質」という指標で選ばれています。さまざまなパラメタを用いてAteam内で社員評価を行ったところ、その指標の有意性と他指標の非有意性を得たことから、上記指標の導入を開始したとのことです。
こういった制度づくり・やり方づくりには、それまで存在した曖昧さや不満感を破壊して全体の生産性を引き上げるポテンシャルがあるので、やはり私はワクワクします。
他にも、最近見られるようになったビジネスモデルであったり、SaaSの目指すところと投資家の思想についてお聞きしました。前者のビジネスモデルについては衝撃を受け、マネタイズ部分を抽出して自分が開発中のサービスに組み込もうと決めました。SaaSの話題でも、自分が今まで気づかなかった思考に気づくことができ、他の領域にも転用可能な思考を得られました。
関連資料
例2) 技術開発室のエンジニアの方
技術開発室というAteamの精鋭集団的な部門のエンジニアの方です。
技術開発室では現在、CMSの刷新やAI関連に取り組んでいるそうで、Ateam全体で使用されるシステムなので生産性向上に大きく貢献する開発です。AI関連は、この方がAIブーム以前に「絶対にこの技術は必要だ」と提唱して始めた領域なのだそうです。AI領域というとアカデミアのイメージが私は強く、論文を読むことが主なキャッチアップかと思っていましたが現在はその限りではないそうです。現在では、SNS上において開発者のコメントからプロンプトに関するTipsまで、有用な情報がたくさんあるとのことでした。
Ateamで使用されている技術としてGCP・Railsがあるのですが、私が技術的な不安を相談すると、この二つを勧めて下さりました。GCPは比較的簡単な設定でインフラを稼働させることができるし、例えばKubernetesの複雑さを内部に隠蔽して使えるようにしてくれる、とのことで、その簡単さを推していました(一方で、バグが生じた際は隠蔽によって中身の理解が難しい、とも)。Railsについては、単体でできることの幅広さが魅力で、自身もよく業務で使っているとのことです。Railsを一通りやれば大体のことはできるようになるから、もし1つ技術を選ぶならRailsがいいよ、と推して下さりました。Railsは私の次のインターンでも使用するので学習により熱が入る言葉でした。
関連資料
例3) CTOの方
Ateamに長年勤め、現在ではCTOなどをしている方です。
とても気さくに話してくださる方で、緊張していた自分をリラックスさせて下さりました。
CTOという役職の方が何をしているのか、私は調べても判然としませんでした。ですので、CTOとしてのお仕事をまず尋ねたところ「特に決まった仕事があるわけではない。インパクトが大きく、その時に必要なこと、将来的に必要になるであろうことを実施する、いわば便利屋的なもの」という返答をいただきました。熟練の技術を持ち、組織全体を把握している立場だからこそ、定型化できない非連続的な成長を実現するのがCTOの役割なのだと理解しました。
次に、私の抽象的な悩みを相談させて頂きました。私は当時、エンジニアとして今後どう進むのかを迷っていました。これは例えば、自分が興味のあるドメインを重視するのか、また新卒からそのドメインをやりたいのか、技術を身につけることを重視するのか、などです。また、私は技術スタックがとっ散らかって「これが一番得意です！」と言えない状態にあり、このままでいいのだろうかという漠然とした不安もありました。これらを相談したところ、「やりたいことにあったことをすればいいんじゃない？」と。非常にシンプルではありますが、私は、そんなシンプルなことを見失っていたんだと気付かされました。
その後、エンジニアとしての在り方を見習うために、その方のエンジニアとしての今までをお聞きしました。その方は、その時その時の仕事をやり切ることで技術を身につける、という自分とは異なる考え方を持っていました。今まで自分は、まるで技術は体系的に学ばないと身につけないかのように思っていましたが、ここで考えを改めました。
関連資料
メンターの方との定期的な面談。
インターン初日には目標、目標達成のためのアクションを話し合いながら作成し、その後も1on1だけでなく毎日15~30分の相談などをさせて頂いていました。
着手中のイシューで困っているところがあれば、レビュアーだけでなくメンターの方にもよく相談していました。メンターの方は、ただ解決策を教えるのではなく、方法と理由を伝えるというスタンスでした。そのおかげで、1を聞くだけで後の10に活かすことができます。また、その方があまり業務で使用していない技術の場合でも、仮説を立てた上でその考え方を共有して下さっていました。
イシューのことだけではなく、広範に技術や業務についてもお聞きしていました。例えば以下があります。
- ABテスト
- CI/CD
- AWS
- ステージングとリリースのフロー
- リリース失敗時の対応
- 事業者側でデータ連携してもらう方法
- 実装、設計、要件定義の各レイヤーで意識していること
etc...
関連資料
コーディングに集中するためのTipsとして、メンターの方は「会議をまとめて入れる」「スケジュールにコーディングの時間も入れてしまう」等をしているそうです。会議やミーティングにコーディング時間を奪われるという経験が私には少なかったため、なるほどと得心しました。他にも業務のやり方として、特定タスクだけ時間がかかりそうな場合は先に他を終わらせて、そのタスクだけ期限を延長してもらうよう依頼する、ということもあるそうです。
また、エンジニアとして企画へ十分に意見を述べることの重要性もお話しして下さりました。Ateamでは、マーケ・営業・デザイナー・エンジニアなどが一緒になって企画を考えていくスタイルで、最初から固まった企画が下りてくる訳ではありません。また、エンジニアは特定の技術領域に責任を持つのではなく事業に対して責任を持ちます。これらAteamの体制から、また、三方よし(ユーザ・事業者・Ateam)を実現するためにも積極的に指摘する必要がある、と説明して下さりました。
また、スキル面とスタンス面についてのフィードバックも頂きました。私の強みだと考えている部分が確かに良く評価されていて続けようと思いましたし、意識外の部分も良く評価されていて意外な自分の強みも認識できました。
また、「自分より経験のあるエンジニアへもっと聞きにいけるスタンスと環境づくりをすべき」という評価も頂きました。これはクリティカルな指摘だと感じます。なぜなら、日常生活では自分の周りにエンジニア(学生含む)はほぼおらず、また、基準を引き上げてくれる存在が身近にいると成長速度が高まることを私は体感していたからです。「聞きに行けるスタンス」については、インターン中は社員の方の時間を奪いすぎぬよう自粛していましたが、程度が誤っていたと反省。「環境づくり」については、コミュニティなどの場に飛び込む必要があると感じました。コード品質を上げるための基礎知識を得ようと考えているので、輪読会に行ってコネクションを持つというのも良さそうです。
人事の方との定期的な面談
週1で1時間ほど面談をさせて頂き、業務のことやAteamのこと、広くビジネスのことや就職のことなどについて聞かせて頂いていました。
こんなことを相談させて頂いたこともあります。
インターンはじめの頃、私は「人の名前が覚えられない」という自分の悪癖に悩まされていました。ランチをご一緒したり、すぐ近くの席で喋ったりしたのに名前が思い出せない...。この悩みを相談すると、社員の方々の所属・名前・顔写真が纏められたものを見せて下さり、人を覚えるためのコツまで教えて下さいました。今まで私は自分の悪癖を改善するため、Notionにそれ専用のDBを作って人の名前や特徴、どこで会ったかなど色々メモしていましたが、その方のコツは真逆で、１つ２つだけ特徴や何を話したかを覚えておくというものでした。今もそれを実践させてもらっています。この相談に端を発して、私は自分が人の名前が覚えられない理由の仮説を立てることもできました。
また、最終週には少し答えにくいであろうことも相談させて頂きました。
自分はインターンの中で、自己評価と他者評価に乖離を感じていました。自己評価は低めで、理由としては他インターン生より完了イシュー数が少ない(「5. 作業効率が低い原因」)ことや作業効率の低いタイミングがあることを感じていたからです。しかし、他者評価は高めで「〇〇君なら大丈夫だね」「〇〇君ならできると思うけど~」と言う言葉をよく受けていました。この乖離についての悩みも、その方は明確に返答して下さりました。まず自分が抱えている悩みを切り分けた上で、エンジニア側から受けている自分についての報告、その方からの人事的な評価等について教えて下さりました。その説明によって納得でき、悩み1つを消すことができました。
また、その方もAteam文化も部下が上司に「これはなぜ？」と積極的に聞くことを推奨しているため、聞きにくいことを聞くという自分の行動に対して、Ateam内の実例を挙げて正の強化(positive reinforcement)をして下さりました。
おわりに
インターンの雰囲気を伝えるために具体例を多く挙げましたが、イメージできましたか？私が体感した楽しさや興奮、感動が伝わり、この記事がエンジニアになる学生の方、Ateamへのインターンや就職を考えている方などのお役に立てれば幸いです。
Ateamインターンで得たものはとても大きいです。技術的に成長しただけでなく、多くの社員さんとの対話によって、エンジニアとしての方向性も再定義することができました。
Ateamの社員の方々、1.5ヶ月という短い間ではありましたが、多くのことを学ばせて頂きありがとうございました。
そして何より、メンターの方、人事の方、お二人のおかげで最高に学びの多いインターン期間を過ごすことができました。本当にお世話になりました、ありがとうございます。
余談
インターン最終日にはお疲れ様会を開いて下さり、Ateamの食堂に15名ほどのエンジニアや人事の方、3名のインターン生が集まりました！なんとケーキも用意して下さり、ケーキを前に全員で写真を撮りました。余興としてインターン生VSメンターの寿司打対決も行われ、私はメンターさんをボコボコにして勝利しました😆
他の方のAteamインターン体験記もご参考に(2024年)
熱中症搬送者数サイトで一緒に働いている子です。
プログラミング歴が私の約7倍(!!)かつ情報系の学部生で、とても参考になると思います。
Qiitaインターンについて詳細かつ網羅的に書かれているため、インターンを考えている方は一読をオススメします！
同じ時期に2週間ほど参加していた情報系の院生の方です。
ランチでご一緒したのですが、和風な趣味をお持ちでした。なんて雅な人なんだろう。
大阪オフィス勤務で1.5ヶ月参加していた情報系の院生の方です。
自分(名古屋)とは異なるオフィスでの勤務ですが、お疲れ様会でお会いできました！
Ateam企業サイト