学生時代にDeNAのつよつよエンジニアに1年半もまれた話

はじめに

こんにちは！24卒のエンジニアのちゃなべ ( @chanabe1212 ) と申します。この記事では私がDeNAでの1年半のインターンを通じてどういうことに成長を感じてワクワクしたかを書きたいと思います。

この記事は、当社への入社を検討されている学生の方向けに、私がどういう人間で、インターンを通してどのように成長をしたのかをお伝えします。DeNAでのキャリアを想像する手助けになれば幸いです。

ちゃなべってどういう人？

私が仕事でワクワクすることは「技術者としての成長」です。大学が工学部機械科だったのもあり、情報技術に関する知識や経験が周りよりも劣っている自覚があります。そのため技術者としての成長を感じることはとても喜びを感じます。

私が好きな成長するための環境は「自分以外全員強いメンバーがいる環境で実力を試されながら、うちのめされて、日々学びを経験ベースで感じる」ような場所です。これは、一歩一歩ステップアップで実力が上がっていくよりも、二段飛ばし、三段飛ばしで成長してくようなスピード感をより感じることができるためです。

自分だけ成長したら満足かと言われたらそうではありません。自分が成長を感じるために全力で課題解決に立ち向かっていくことが、何か周りの助けになればこれ以上のことはありません。難易度の高い・規模の大きい課題には、大きな成長と大きな周りへの良い影響があると思っているため、より複雑で大きな課題に立ち向かいたいです。

どこでインターンしたの？

健康診断に関するDXの新規プロジェクトメンバーとして携わっていました。新規プロジェクトなので当初は7人前後のチームでしたが、時期を追うにつれて増加し最終的にはエンジニアだけで20名弱のチームとなりました。また健康診断領域は複雑で奥が深い業務知識が存在するため、ビジネスの方はもちろんエンジニア全員が複雑なドメイン知識を理解する必要がありました。

本プロジェクト独特の難しさについては以下のブログと2023年に弊社で開催したTechConというイベントで発信されているので、ぜひご覧ください。

そんな環境に2022年9月からの2ヶ月間、サマーインターンとして参加させていただいた後、2022年12月から2024年3月までの期間もお世話になり、合計1年半インターンをさせていただきました。そこでの経験を「3つの成長ポイント」というように抑えながら話していければと思います。

成長①: 技術力

サマーインターン開始当時は、とてもじゃないですが私の技術力は「Web開発の現場で通用するレベル」には達していませんでした。TypescriptやReact、Golang、Dockerも6ヶ月間以上触ったことがなく、SOLID原則などのエンジニアとしての意識、DDD・クリーン・レイヤードなどのアーキテクチャについても全く知りませんでした。そんな私でしたが、1年半仕事を通じて鍛えていただき、「Web開発の現場で通用するレベル」には達したんじゃないかなと実感しています。上記で紹介した言語やライブラリなどの実践的な知識と経験を得ることはもちろんできたのですが、それ以上に次で紹介する考え方をしっかりと理解できたことが私にとってとても大きかったです。

SOLID原則：単一責任の原則
- FE・BE通じて通用した考え方
- 読みやすい・テストしやすいコードを書くために大切と理解した
SOLID原則：インターフェース分離の原則
- 特にBEの時特にお世話になった考え方
- 不確実性が高い本プロジェクトにおいて、無駄なコードを書かない意識を磨けた
SOLID原則：依存性逆転の原則
- BEの時特にお世話になった考え方
- モジュールごとの結合度を下げることで、コードに変更があった時に楽に修正ができた
YAGNI
- インターフェース分離の原則と得たメリットは同じ
- 不確実性が高い本プロジェクトにおいて、無駄なコードを書かない意識を磨けた
アーキテクチャの理解
- BEで特に助かった
- 関心の分離などを通じてどの層で何をすべきで、逆に何をしてはいけないのかを抑えながらコードを書けた

これらを理解できたことで、所属している部署や技術に限定されないような汎用的なエンジニアリング力を上げることができました。そして、これらを体得できたのは部署に以下二つの文化があったからだと思います。

本質的な質問をしやすい環境
1段階上の視点から指摘してもらえる

よく「わからないことがあったらいつでも質問をしてください！みんなであなたの質問に答えます」というような「質問をしやすい環境」という素晴らしい環境があると思いますが、私はもう一段階上があると感じました。それが「本質的な質問をしやすい環境」です。質問がしやすい環境はもちろんのこと、「聞くこと自体が気まずくなるような本質的な質問をしやすいという環境」のことを指しています。例えば「いま実装しているアーキテクチャってどうしてこれを選択したんですか？こっちの方がいいと思いますが、どうなんでしょうか？」などという質問です。このような質問ができたからこそ、先輩方の思考回路から理解することができ、より納得感のある技術の体得ができました。

もう一つの「1段階上の視点から指摘してもらえる」ですが、特にPRでのレビューで感じました。自身が書いているコードへの指摘には全てに理由をつけていただけただけでなく、アーキテクチャの観点やSOLID原則などのエンジニア思想、もしくは今の開発フェーズも含めた指摘をいただけたました。ただこうすればいい、ではなく、なぜそうする必要があるのかという理由や考え方から理解と納得をすることができたことで、汎用的なコードの書き方を身につけることができました。

成長②: 不確実性が高い課題にどう立ち向かうか

突然ですが、私は「複雑で難易度が高くて時間がないものを論理をもって解決すること」が好きです。いわゆる「論理的課題解決」ですが、これをすることに人生を捧げていいと思うほどです。そしてそれが一番仕事としてすることができると思ったのが「ソフトウェアエンジニア」だと思っていますし、私の中でのエンジニアリング力の定義は「課題解決力」だと思っています。そしてこの1年半のインターンを通じて、課題解決のための大切な考え方の一つを教えていただきました。それが「不確実性を減らす」ことです。

「不確実性を減らす」ことは、学校ではほとんど教わらない、社会での課題解決への手法です。例えば、学校でててくるテストは問題文に無駄なものがなく、答えもほぼ一つです。しかし実際の社会で認識する課題は不要な情報が入っていたり、答えがいくつもあったり、もしくは答えがなかったりします。そんな状況で最適な答えを出すためには、無駄な情報を減らしたり、もしくは必要な情報を得ないといけません。つまり、不確実性を確実に減らしていかなければ最適な答えに辿りつかないですし、解決に多くの時間が割かれてしまいます。

そして「不確実性を減らす」ことが仕事上ではとても大事である理由があります。それが見積もりという存在です。会社で仕事を行うときは複数人がアサインされ、納期・予算が存在することがほとんどです。そのとき、プロジェクト全体がどのくらいで終わるのか、どのくらいの人が必要なのか、またそれぞれのタスクはどのくらいで終わるのかなどの「見積もり」を引くことが必要になってきます。

もちろん「見積もりを引いてみたけども、実際はその3倍かかりました」なんていうのは好ましくないことです。これはタスクを実行したプレイヤーにとっても、管理するマネージャーにとっても、価値を提供するユーザー・クライアントにとっても良くないことです。じゃあこのような見積もりと実働の齟齬はなぜ起こるか、この原因は多くの場合「不確実性を減らせていなかった」ことだと思っています。

減らすべき不確実性は2種類に大別でき、一つ目は情報の不確実性です。例えば、ログイン機能を実装することになりました。どのような実装方針にするか具体的に決めていないのにも関わらず、どのくらいの工数で完了するか見積もりました。その後実装を始めましたが、使おうと思っていたライブラリが非推奨になっていることに気づき、実装のやり直しをすることになり、結果的に見積もりとの齟齬が生まれてしまいました。なぜ齟齬が生まれてしまったか、それはタスクを完了するまでに何が不明瞭なのか、足りない情報はないかなどの不確実性を残しながら実装を進めてしまったのが原因です。

もう一つは、コミュニケーション上での不確実性です。例えば、とある機能を実装し、上長にレビューを貰いました。しかし「想像と違った、このような実装に変えて欲しい」とレビューされ、実装のやり直しになり、結果的に見積もりとの齟齬が生まれてしまいました。これは上長が何を要求しているのかを十分な粒度で明確にしなかったことや、上長が言ったことを100%理解できているという慢心などに起因するコミュニケーション上での不確実性を残しながら実装を進めてしまったのが原因です。

それではこの不確実性をどう減らせばいいのか。…それはこちらの本に書いてあるのでぜひ読んでみてください笑上長から不確実性の取り扱い方についてを学ぶのに打ってつけと、おすすめされた本です。

https://www.amazon.co.jp/dp/4774196053

不確実性の扱い方を知ってから私は変わりました。個人タスクで言えばタスクのやり直しが圧倒的に少なくなくなりました。チームタスクではチームとして何を真っ先にやればいいのかの優先順位づけの軸の共通認識ができ、メンバー間での認識の齟齬が少なくなりました。不確実性が高いプロジェクトの中で効率よく動けるようになったのはこれを学んだおかげでした。

成長③: 価値の出し方は常日頃変わる、たとえ立場が変わらなくても

大学1-2年のバイト、大学3年の時のインターン。これらを通じた、私の仕事での価値の出し方は、「メンターが求めることの上をいく」でした。

ただ「メンターからアサインされたタスクをこなしていく」だけのお話ではありません。タスクがアサインされたら、そのタスクをより早く、120%の品質で出すように意識したり、自ら率先して改善に関する意見提案をし、実行するというようなことです。つまり上長が自分自身に求めているイメージを超えていくことを意識していました。

このやり方は今回のインターンでも決して例外ではありませんでした。最初の1年はこのムーブをすることで、結果的にサービスに価値を出せていました。

しかしインターン残り半年になってきた時に話が変わりました。少数の開発チームに分割するように組織体制が変わり、それぞれのチームが特定のコンテキストの機能群を実装するというような形になりました。するとどうでしょう、私にメンターとして指導やタスクの指示をする人がいなくなったのです。そんなことあるかいって思いましたが本当にそうでした。

いままで培ってきたやり方では通用しなくなりました。しかし当たり前ですがやり方がわからなくても、チームに価値を出さなければいけません。そのために自分なりに仮想の上長を作り、考えながら動き続けました。「私はいまどのように動けば、仮想のメンターの想像を超えられるか、チームやプロダクトに価値を出せるか」と自分に問い続けていました。

自分なりに考えながら1週間ほど動き、考えすぎてへとへとになった時に上長に相談しました。「いままでのやり方が通用しないんです。チームのみんなが私に何をして欲しいのかあんまり分かってないけど、現状はチームの為に何をすればいいのかを考えながら動いてます。けど不安です。」と。そしたら上長から「そのままでいい」と言われました。何も腑に落ちてない顔をしていると、続けて上長は私が納得するまで説明をしてくださいました。指示を受けて動くという期待から、探索的に問題を発掘して自律的に動くという期待に変わった。つまり、自分のフェーズが変わったのです。

私がメンターに「こう動け、こういうアウトプットを出せ」と要求したことはありません。それは「私がメンターに指示を出す立場にない」と言えるでしょうが、もう少し深ぼると「チームに価値を出す動きをメンターはしてくれるだろう」と私が暗黙的に思っていたからだと思います。そして残り半年の私にも同じような要求がされ始めたということでした。特別これをしろと言われなくてもチームにとって価値を出すように動いてくれるだろうと。

「メンターが求めることの上をいく」がどこでも通用すると考えていましたがそのようなことはありませんでした。そう、働き方や価値の出し方に銀の弾丸などありません。プロダクトの内容、チームの状況、ステークホルダーとの関係、そして私自身の能力、いろいろなファクターから価値の出し方は変わってきます。決して「立場」だけで決まるものではありません。常日頃からそのファクターを広い視野で観測し、価値の出し方の最適解を考え、流動的に動き方を変えていくことが大事と学べました。

おわりに

ここまで読んでいただきありがとうございました。

私が成長できたのはこのような環境があったからでした。

本質的な質問をしやすい環境
1段階上の視点から指導してもらえる

そして、成長できたことはこのようなことでした。

汎用的な技術力
不確実性と扱い方と減らし方
広い視野で、自分を取り巻く環境を俯瞰し、動きを変えること

いかがだったでしょうか？当時「Web開発の現場で通用するレベル」に達していなかった私に対して、諸先輩方がスキル面や考え方を惜しみなく教えて下さりました。1年半のインターン経験で大きな成長を感じましたし、これはDeNAの文化が後押ししてくれたのだと感じています。私の経験談が、学生の方の当社への入社検討材料に少しでもなれば幸いです。

この1年半を通じてたくさんの方にご指導ご鞭撻いただきました。本当にお世話になりました！とても楽しかったです！

今年の春から新卒研修を頑張っていますが、配属後もDelightを届けられるように頑張りたいと思います。