DeNAで1ヶ月半本気で働いてみて感じたこと

自己紹介

はじめまして、2023年の8月~9月末でDeNA就業型インターンに参加した池垣です。筑波大学で情報学を専攻し、機械学習・言語創発周りの研究をしています。

この記事では、インターンとして本気で1ヶ月半働いてみて感じたことを書き記していきます。

インターン応募の動機

DeNA就業型インターンに応募した動機は２つありました。

1. 技術者としての自分の位置を知りたかった

これまでの約2年間、慣れ親しんだ環境で長期インターンをしてきました。
そこで慣れたエンジニア業務の経験からスムーズに開発ができているのか、それとも私がそもそも技術者として力があるからこなすことが出来ているのかが分からない状態でした。

つまり、今技術者としてどのような位置にいるのか分からない、という状態でした。

なので、別環境のなかで自分は技術者としてどこまでできるのかを試したかったのに加え、強いエンジニアに会いにいきたいというのが1つ目のモチベーションでした。

また、今までの自分のコンフォートゾーンから抜け出すきっかけとしても新しい環境で自分の本気と向き合おうと考えていました。

2. 第一線で働いているエンジニア集団の中で働いてみたい

私はこれまで別の会社のエンジニアさんと2人での開発しかやったことがありませんでした。
そのため、実際の大規模開発の現場でDeNAクオリティの技術力を持ったエンジニア集団が、どのようなコミュニケーションをしていてどんなことを意識しているのかを知りたい。それらを再現可能な知識に落とし込んで自分のものにしたい。というのが2つ目のモチベーションでした。

インターンの概要

私が参加したコースは「【就業型】ソフトウェアエンジニアリングコース」でした。
期間は8/14から9/29で、夏休み中だったため、平日は毎日朝から夜までフルタイムでコミットすることが出来ました。

私が配属されたのは、「メディカル事業本部プロダクト開発部DXソリューション開発グループ」という部署です。新規プロジェクトチームの一員として業務を行うことになりました。
チームの規模は20人程度で、20代前半の若い方が多い、フレッシュでエネルギッシュな環境でした。
インターン生として私を含めて3人が配属されていました。プロジェクトとしてはあまり詳しくは書けないですが、プロダクトの0→1フェーズに関わることが出来ました。

他社インターンでは業務には携わらないハッカソン形式のものや、インターン生用に組まれたカリキュラムをこなすものが多い中で、このような生のプロジェクトにチャレンジできる環境はまさに私が求めていたものでした。

ジョインしてすぐにプロジェクト状況のキャッチアップをして、1週間後には実際にタスクにアサインされて業務の中に入っていく、という凄まじいスピード感でした。

このような刺激的な環境での様々な経験を通じ、技術と業務の両面で多くのことを学ぶことができました。

1ヶ月半本気で働いてみて感じたDeNAの凄みとは？

それではようやく本題に入っていきます。

DeNAのメンバーと一緒に働いていく中で学んだことは沢山ありますが、このセクションでは私が感じたDeNAの凄みについて以下の3つに絞って書いていきます。

エンジニアとしての意識
目標設計が生み出す熱量
スクラムの本質とチームビルディング

1. エンジニアとしての意識

まず最初に感じたDeNAの凄みは、エンジニアとしてプロジェクトを進めていく中での「徹底された不確実性を削減する意識」でした。あらゆる会議の中で以下の言葉たちを口にされることが多かったです。

「今この曖昧性を潰しておかないと先に進めないよね」
「今どの文脈にいて、何が課題？」
「結論をもっとシャープにしたいね」

プロジェクトの中の曖昧なことをそのままにしておくとそれはやがて将来的にもっと大きな不安要素として迫ってきます。

また、複雑なドメインや難しいプロジェクトの議題について話し合うときに、知らぬうちに論点がズレてしまったり文脈によって言葉の意味が変わってしまったりするものです。

そのような難しい議論の中でも「不確実性は徹底的に削減していく」という意識を絶やさず常に建設的でロジカルな会話を積み重ねながらネクストアクションが明確に決まるような結論が出されているのが印象的でした。

例えば「〇〇をチーム全体で意識する」といった輪郭が曖昧な結論ではなく、「このスプリント内で、ある数値が到達点に達するように動く」などの具体的な解決策のイメージです。

ちなみにこの不確実性を削減するという考え方は広木大地さんの著書である「エンジニアリング組織論への招待」という本に書かれている内容です。詳しく読みたい方はそちらを参考にしてください。
インターン初日にメンターさん( @mizuki_r )にこの本をお勧めしてもらい、毎晩読み進めながら昼は実務をするという感じで抽象と具体を行き来することで身をもって理解することが出来ました。

常に「課題は何で、不確実な要素はどこに潜んでいるか」を意識する姿勢がDeNAのプロジェクト推進力の土台となっているように感じました。

不確実性の削減、大事。

2. 目標設計が生み出す熱量

次に感じたものとしてはメンバー1人1人の成長意欲の高さでした。

正直これまでの自分の成長意欲は決して低くはないと思っていたのですが、チームメンバーを見ているとそう思わざるを得ないほど熱量に差がありました。相当悔しかったのを覚えています。

さて、その熱量についてなのですが、単にやる気がすごくあった、と片付けてしまうのでは何も生まれないので「なぜそのやる気が継続的に続いているのか」について深掘りたいと考えて、メンバーに聞き回ることにしました。

そうして、辿り着いた結論が「明確な目標設計」でした。
メンバーそれぞれが最終的に自分は何がしたいのか、について普段から考え抜いていて自分の目標をしっかりと言語化していました。
「今なぜこのタスクを頑張るのか」を自分の目標から逆算して1本のロジックで繋がるからこそ、このタスクをやり切った先の自分の姿を明確にイメージできます。たとえ一見やる意味が薄そうなタスクだとしても目標に近づく過程で必要なステップだとして認識することが出来る。その認識が一過性のモチベーションで終わらないような持続可能な熱量を生み出す原動力になっているのだと思いました。

そして、その目標設計を軸に自分が今どの位置にいるのかを客観視しながらPDCAサイクルを回して改善していく。それを日々連続的に続けているからこそ、成長角度を上げ続けることが出来ているのだと確信しました。
それを知ってからは私も「自分がなりたい姿・やりたい事」についてじっくり考え始めました。
なるべく「PdM」「CTO」のようなラベルではなく、「自分が実現したいこと」というようなアクションで。

今も悩んでいる状態ですが、何も考えていなかったときと比べると「今自分は何をすべきか」の意識が格段に変わった気がします。

目標設計、大事。

3. スクラムの本質とチームビルディング

スクラム手法は大学の授業や、これまでに行ったインターン先で経験はしてきましたが、そのスクラムの本質についてはずっと分からないままでした。
一応私が考えていた結論としては「スクラムの本質はチームのコミュニケーションを増やすこと」と考えていました。
確かに毎朝のデイリースクラムなどを見ているとメンバー同士が話す機会がスクラムというフレームワークによって確保されるので、潤滑なプロダクト開発ができてるのか、と感じていたのです。

しかし、スクラムが単にコミュニケーションを促すためだけのフレームワークなのであれば別にスクラム手法でなくてもいいわけで、社内でとにかく会議を増やせばいいのではないかと思うようになりました。
私の認識が正しいのか、あるいはスクラムの本質は他の部分にあるのかが気になって、直接メンバーにスクラムについて聞いてみました。

その時に「これが本質か！」と私が思えたのは次の意見でした。

「スクラムの本質は可視化」である。

そのとき説明いただいた内容はざっくりこんな感じです。

そもそもプロジェクトは「現在地点」と「目的地」とそこに至るまでの「スピード」の３つで構成されている
現在プロジェクトはどこにいるのか、いつまでにどこに到達していないといけないのか、目的地まで向かうチームのスピードはどれくらいか、について可視化できればプロジェクトが目的地に期限内に到着するかどうかが分かる
このままでは納期内に間に合わないとなると、改善というアクションに移ることが出来る
最終的に「チームの改善」が可視化できる

この観点でチームの動きを見てみると、これまでの会議の印象が大きく変化しました。
参加する会議において「目的地」「現在地点」「スピード」がどのように話されているかを考えるようなれたと思います。
例えば、毎朝開催されているデイリースクラムでは、最初に今スプリントの目標（目的地）を確認し、メンバーの細かい進捗（現在地点）を共有し、そして毎日の進捗のプロットから進捗度合い（スピード）を可視化して、改善案を出していたんだと理解できます。

この観点を得たことで、漠然としたスケジュールの不安が解消され、チームの一員としてプロジェクトの状況が把握しやすくなったと思います。
個々のメンバーが可視化を意識しているからこそ、単に毎朝出席しなければいけない会議ではなく、プロジェクト進行のために意味のある芯を食った議論をするための場になるのかなと思いました。

可視化、大事。

その他

すぐに質問できる雰囲気作り
- 分からないことがあればslackでいつでも質問できる雰囲気作りがされており、話がしたい時はすぐにハドルができる環境だったので、分からないことを自分の中に溜め込む時間が非常に少なくストレスフリーな開発ができました。
タスクの持ち方
- 人は1度にそんなに多くのタスクマネジメントを出来ないという前提に立った上で、3.4時間の刻みでタスクを分割し、１つのPRは最大4時間で締めれるくらいの粒度でタスクをもつように、とよく言われました。
- 1日悩んで出来ていません、という報告はNGで、最低でも1日の中で1,2回は相談しようという決まりがありました。このように明確に決められていると詰まっている時の相談もしやすかったです。

私のエンジニア観の変化

この1ヶ月半のインターンでの経験を通して、想像以上の経験と学びを得ることができました。

まず、案外エンジニアは技術以外の部分に向き合う時間が多く、そしてそれが本質だったりするのだと思いました。
とはいえ成果にとことん向かうには、今回チームで学ばせてもらった不確実性への向き合い方やスクラムの考え方も必要なのですが、それ以上に、自分の技術力が不足していることに気づけました。

自分の技術力不足を痛感したのは、同世代のメンバーと同じタスクに取り組む中で、彼らの進捗やアプローチを見たときでした。
私がソースコードの意図を理解するのに時間を取っている間に、彼らはすでに何箇所かのリファクタリングのポイントを見つけ、タスクの具体的な解決方法をいくつか提案していました。彼らとの明確な差を痛感しました。
どれほどビジネスの要件を把握してようが、チームマネジメントの知識を持っていようが、エンジニアというのは肝心な技術力がないと成果を残すことができないということを思い知った瞬間でもありました。

この経験で自分のエンジニア観は大きく変わりました。
インターンシップに参加する前、私はエンジニアのタイプを大きく2つに分けていました。
1つは「技術を深ぼって専門性を高めていくエンジニア」、もう1つは「ビジネス要件を理解し、プロジェクトに横断的に関わるエンジニア」です。そして、どちらか一方の能力さえあれば、他の部分が不足していても一人前のエンジニアとして成果を出して活躍できると思っていました。

今回の経験を通じて、そうした考え方が間違っていたことが分かりました。

技術力とビジネス視点でのプロジェクト推進能力、この2つは密接に関わり合っていたのです。
そして、この2つの力を掛け合わせて持つのが、成果を生むことができるエンジニアであるという考え方に変わりました。

どれだけユーザが求めているものやビジネスの要件を把握できていたとしても、技術力がなければ具体的な提案や建設的な議論が出来ず、そこで止まってしまいます。
逆にどれだけ技術に詳しくても、ビジネス視点を持って動くことができなければ、プロジェクトに貢献することはできません。

もちろん将来的に、ビジネスに深く入り込みプロジェクトに横断的に関わっていくエンジニアや、技術の深いところを触って専門性を高めていくエンジニアというような個性を持って尖っていくことは大事なことだと思っています。
しかし、今回の経験で自分の技術力の不足を強く実感したというのをキッカケに、今後は「ビジネス寄り」や「技術寄り」などのラベルを考える前に、まずは一人前の強い技術者としての力をつけることに集中していきます。
そして、その「強い技術者」とはどんな技術者なのか、私がこの1ヶ月半の間メンバーを観察しながら考えてきた「強い技術者」の定義について言語化すると以下の3つを満たしている技術者だと言えると考えています。

コードに対してなぜ動くのかという疑問を持つ感度が高い
- 何かしらずっと疑問と自分の考察を持っている。分からないところを放っておかず、すぐに質問する習慣がある
普段のインプットが深く広い
- 1つのインプットに対してどれだけ深い部分まで読み込めるか、質の高いインプットには量が必要不可欠
- 解決方法を考えるときの引き出しの多さは普段のインプットの広さに依存している。どんな領域でもインプットを怠らないこと
実装力と設計力が高い
- まずは筋の良いチームで筋の良いプロダクトを作るという経験を積むこと
- その上で「なぜこれが実装されているのか」「この設計でどんな問題が出てくる可能性があるか」のようなコードの意図を汲む思考回数を増やす意識を持つこと