CLOSE

技術スペシャリストなエンジニアの仕事やキャリアとは?(全2記事)

2022.01.31

Brand Topics

PR

共通しているのは、技術を軸に突き詰めていくところ DeNAのスペシャリストが大切にする「質」と「速度」

提供:株式会社ディー・エヌ・エー

「DeNA TechCon 2021 Winter」は、学生に向けて、DeNAを軸に「エンジニアとして企業で働くこと」について、先輩たちが紹介するイベントです。そこで、4人の技術スペシャリストが、エンジニアとしてどのようなキャリアを積んできたかを赤裸々に語りました。後半は、DeNAでの研修とメンバーについて。前半はこちら。

けっこうハードな「エンジニア全体研修」

鈴木天音氏(以下、鈴木):それでは、次のトークテーマに移りたいと思います。次のトークテーマは、「OJTについて」です。OJTというのは、実際に仕事をしながら研修を受けるみたいな話です。

我々は「スペシャリスト」みたいな、大層な名前で登壇しているわけなんですけど。学生が入社して、いきなりスペシャリストとして自信を持ってやっていけるかというと、必ずしもそういうわけではないじゃないですか。

なので、研修やどういう訓練を受けたかみたいな話をしていきたいと思うんです。まず、その前提からみなさんにお話していきますと、DeNAに新卒で入社すると、最初に全職種共通で2週間の研修みたいなものがあるんですね。

これは何をするかというと、DeNAにはどんな事業があって、それぞれでどんなプロダクトを持っていて、みたいなことを全体で学ぶと。そのあとに、エンジニアは「エンジニア全体研修」みたいなものがあって。

井早匠平氏(以下、井早):ありましたね。

鈴木:この研修は、けっこうすごかったですよね。プログラミング言語だと5個か6個ぐらいやるんじゃないですか。GoとかPythonとかもやる?

石塚凌氏(以下、石塚):やりましたね。

鈴木:Rubyとか。

井早:あとはDart、Flutterとか。

(一同笑)

鈴木:本当にいろいろな言語を学ぶし、技術の領域としてもフロントエンドもバックエンドも設計もやるし、クラウドもやるしみたいな感じですよね。

井早:そうですね。けっこう幅広くやっている。

鈴木:そういった幅広いことを学べる「エンジニア全体研修」があって、それが終わったら、晴れて各部署に配属されてOJTを進めていくことになるんですね。そのOJTの中身について、これから聞いていければと思います。

セキュリティ部のOJT

鈴木:最初にセキュリティ部の石塚さんから。OJTの期間とどんなことをやったのかをざっくりと教えてもらってもいいですか?

石塚:配属された方がセキュリティ未経験かどうかにもよりますが、1ヶ月から3ヶ月間ぐらいで、セキュリティの一通りの知識を覚えていく感じです。ただそれって、とても大変じゃないですか。

(一同笑)

なので、業務の中心となっている脆弱性診断から勉強を始めて、そこから自分の興味のあることについて勉強を進めていく感じですね。

鈴木:最初は脆弱性診断がメインの仕事だから、みんなそこから始めるみたいな感じですかね?

石塚:そんな感じですね。

鈴木:なるほど。

石塚:脆弱性診断を学んだ後は、自分の興味があるセキュリティ技術について学んでいくスタイルですね。

稲垣和真氏(以下、稲垣):ちなみに、座学というよりは実践寄り、というかコードを書くよりは体系的に学ぶ感じなんですか?

石塚:そうですね。セキュリティ部の中で、あらかじめ研修の内容を用意しているので、実践をしながらセキュリティについて学ぶことができます。例えば脆弱性診断の場合は、脆弱性が残っているアプリやサービスを用意しています。クロスサイトスクリプティングやSQLインジェクションなど、代表的なセキュリティ攻撃ができてしまう状態になっているので、

実際に自分でアプリに潜んでいる脆弱性を探し出すことで、実際に脆弱性とは何かということや、脆弱性診断の進め方を学んでいく感じでしたね。

稲垣:なるほど。攻撃しながら学べるのはいいですね。

(一同笑)

鈴木:チートなどをやりながら学ぶ、攻撃側と防御側を両方学ぶみたいな感じですかね。

石塚:そうですね。一石二鳥という感じでした。

稲垣:おもしろそうですね。

鈴木:おもしろそう! やってみたいですね。

石塚:他にも興味があったマルウェアの解析をやってみたり、インターンで関わったチート対策ツールのコードを読んでキャッチアップすることもやっていました。

鈴木:なるほど。

IT基盤部のOJT

石塚:僕はそんな感じで進めていたんですけど、井早さんはOJTでざっくりどんなことをやっていました?

井早:そうですね。自分の場合は、入社した時は本当にインフラ運用者としてはぜんぜんペーペーだったので、本当に基礎の基礎から1ヶ月ぐらいかけて、ゆっくり学ぶことをしていましたね。

石塚:1ヶ月間はだいぶ短いですね。それが終わったらすぐに実践に入っていくんですか?

井早:さすがにそういうことはなくて、いったんある程度失敗しても大丈夫な開発環境で最初に経験を積んで、一定の経験を積んでいくと、本番権限取得みたいな、インフラエンジニアにとっては、免許皆伝みたいなイベントがあって。そこで本番権限を手にして、数千台のサーバーを一気に落とす権限を手にする感じですね。

(一同笑)

稲垣:怖いですね(笑)。

井早:怖いですね(笑)。怖いので、本番環境に入ってからもゆっくり一歩ずつやっていく感じです。最初は小さめのタスクから、徐々に大きめのタスクになっていく感じです。

石塚:最初はアマチュアから始めて、最終的にプロになっていくみたいな感じですよね。

(一同笑)

井早:今、はたしてプロになっているかというのはあれですけど、今後もやっていきたいという感じです。自分の場合だと、入ってから5ヶ月、4ヶ月ぐらいで、さっきもちょっと話した「Anyca」というサービスのインフラをオンプレからクラウドにまるっと移行してね、というすごいものを丸投げされて、「まじか」と思いながら進めた感じですね。

鈴木:けっこうそれは大仕事ですよね。

井早:3ヶ月ぐらいずっとやっていましたね。

鈴木:けっこうまるっと投げられるということは、それで身に付くことはいっぱいあったんですか?

井早:やはり1つのサービスのインフラすべてを移行するので、すごい体系的に知識が付くというか。今振り返ってみても、メチャクチャ良いタスクをもらえたんだな、という気はしています。

静的解析器とは何か

鈴木:稲垣さんは、このトークセッションの顔合わせをした時に、先輩かなと思えるぐらい貫禄があったんですけど。

(一同笑)

実際にはまだ1年目ということで。

稲垣:そうですね。

鈴木:OJTと本番の仕事みたいなところの境界線がまだ曖昧かもしれませんが、どういうことをやられていました?

稲垣:そうですね。お題を与えられたというよりは、いきなりUniyプロジェクトを対象とした静的解析器の開発をやり始めた感じですね。

石塚:仕事紹介の時から聞いていて思ったんですけど、静的解析器とは何かを詳しく聞いてもいいですか?

稲垣:これは、コードを実際に実行せずに各種コードの異常を検査するツールのことを言っていて、例えばOSSだと、JavaScriptならESLintや、RubyならRuboCopなどがあると思うんですけど、そういうものを想像するとわかりやすいかなと思います。

これは、社内フレームワークに依存する問題だったり、オープンソースでは検査できない項目を検査したい時にどうしても実装しなければならないので、それらを実装してDeNAで使っていくために、今のSWETがやっている業務の1つになりますね。

鈴木:じゃあオープンソース化されているやつじゃなくて、社内で作らないといけない事情がやはりある?

稲垣:そうですね。

鈴木:研修のお題というよりは実際に仕事で使っていくものを作っている感じなんですね。

稲垣:そうですね。実際はただ実装するだけではなくて、実装したら、さまざまなプロダクトのところに持っていって使ってもらうんですよね。

それが有用だということを示した上で、事業部の方に「こうやって実装するんですよ」という、実装するためのノウハウを伝えて、次に仮にこんな静的解析ツールがほしいなと事業部が思った時に、その事業部独自で実装してもらえるように、どんどん社内に浸透することを目標にしていますね。

鈴木:なるほど。静的解析器は、僕は実装したことがないんですけど、実装する時はどういう感じのことを意識してやっているんですか?

稲垣:けっこうSWETらしさというのがあると思うんですけど、やはり静的解析器というのは正確に検査したいのでテストを大事に書くことは意識しましたね。というか「大事に書け」と言われたというか。

(一同笑)

やはり書く時にもいくつか意識する観点があります。例えば、テストをするということは、テストをするための環境を作らないといけないんですけど、依存性が多かったり、テストをするのが難しいとすぐに動かなくなってしまったりするので、依存性が低く簡単にテストできるようにしたり。

他にも極端な例ですがテストケースが1つしかなくても、あまり意味がないじゃないですか。「本当にこれで大丈夫なの?」みたいな。そういうことがないように、網羅率の高いテストケースを考えて実装しなきゃいけなかったり、そういう感じですかね。

井早:テストドリブン開発みたいなものってやったりするんですか?

稲垣:そうですね。ちょっと先に言うべきだったかもしれないんですけど、やはりテストを先に書くことが大事で、テストファーストは常に意識していますね。

鈴木:やはりそうですよね。

(一同笑)

井早:なるほど。

1人の新人に対して1人のメンターが付く

稲垣:ちなみに天音さんは、OJTでどんなことをやられたんですか?

鈴木:冒頭に「エンジニア全体研修があってすごい大変なんですよ」みたいな話をしていたんですけど、実は僕、その大変なエンジニア研修を実は受けていなくてですね(笑)。

(一同笑)

本当に全職種の共通の研修が終わったあとに、即座に今の部署でいきなりプロジェクトに配属されまして、実際にバリバリとタスクをこなす感じでした。

稲垣:いきなりプロジェクトに入った時、僕はメチャクチャ心配だったんですけど。

(一同笑)

いきなり入って「1人でやってください」みたいに、全部丸投げ状態だったんですか?

鈴木:さすがにそんなことはなくて(笑)。メンターの方が一緒に付いてくれました。1人の新人に対して1人のメンターが付くという感じで、メンターはだいたい同じプロジェクトに入っている先輩から選ばれる感じなんですけど、だいたい一緒に仕事しているから、その仕事の様子も学べるし、1 on 1みたいな感じでミーティングを入れてもらって、「最近悩んでいることとかある?」や「どんなスキルを伸ばしていきたい?」みたいな話をしたり。

あとはうちの部署でよくあるのが、「こういう分析をしてこういう結果が出たんですけど、どう思いますか?」みたいにディスカッションする場があって、メンターの人と一緒にやって少しずつ覚えていく感じなので。いきなり突っ込まれたとはいえ、ちゃんと研修されていますね。

稲垣:アフターサポートみたいな感じで。

(一同笑)

機械学習のプロジェクトは不確実性が大きい

井早:先ほどからちょこちょこ「プロジェクト」という単語が出てきていると思いますが、機械学習やデータ分析みたいなところの文脈におけるプロジェクトはどう進めていくものなんですか?

鈴木:メチャクチャ良い質問ですね。

(一同笑)

機械学習のプロジェクトはけっこう不確実性が大きいと言われていて、やってみないとできるかわからないみたいなものがあったりするんですよね。なので、けっこう特有な流れもあって。

最初のプロジェクトの始まり方としては、やはり困っていることベースで始まっていて、事業部やサービス側に「こういうことで困っているんだけど」みたいな相談を受けて、それに対して機械学習が使えるか、使えたとして本当に使う意味があるのか。機械学習を使わなくて済むならそれが一番良いので、機械学習を使わないで済まないのかとか考えたり。

そういうのを考えていって、「こういう方針だったらこういう技術もあるからいけるんじゃないか」みたいなのがある程度わかってきたら、PoCといって、日本語だとたぶん「概念実証」とか訳すんですけど、3ヶ月ぐらいで期間を切って、お試しでデータ分析をしてモデルを作る期間をやって、それでよかったら、最終的にAPIを作って提供していくのが、主なプロジェクトの流れですね。

井早:3ヶ月とかだと、けっこう素早くスパンを回している感じなんですね。

鈴木:お試しのところはスピード感が大事で、できるかできないかを1年間考えて1年間さんざん試したあとに「やはりできませんでした」だと、1年間何やっていたんだという話になるので、けっこう短く区切って、大事なところだけを検証することをけっこう大事にやっている感じですね。

井早:なるほどですね。

リモートでも1人で悩むことなく仕事を進められた

鈴木:ちょっと戻るのですが、僕1人で仕事に突っ込まれて大丈夫だったのかみたいな話をしていたと思うんですけど、これはみなさんにも聞いてみたいと思うんですよね。OJTを進めるにあたってどういうサポートをもらえたか、みたいな話を聞いていきたいと思うんですけど。石塚さんはどうでした? いきなり「セキュリティを勉強しろ」と言われて、それもキツイと思うんですけど、実際はどうでした?

石塚:そんなことはなくて、セキュリティ部の先輩が必ずメンターについてくれて、研修をフォローしてくれました。例えば毎朝ミーティングを開いてくれたり。

一同:へー。

鈴木:毎朝あるんですね。

石塚:仕事の悩みやアドバイスも聞けてとても頼りになりましたし、Slackで質問してもすぐに返事が返ってくるので、リモートでも1人で悩むことなく、仕事を進められました。

鈴木:リモートは特有の大変さがありますよね。相談しようと思っても、なかなか返事がないと1人で悩む時間があるので。すぐに返事が返ってくるのはいいですね。

石塚:そうですね。先輩もすごく気さくに見てくれるので。また、メンターの先輩だけでなく、セキュリティ部の先輩全員がフォローしてくれるので、すごい頼りにしていました。

鈴木:研修期間はそんな感じで、仕事に入ったら1人という感じなんですか?

石塚:研修が終わったあとも先輩と同じタスクにアサインされて、先輩の仕事ぶりを学びながら脆弱性診断やツール開発を進められますね。

セキュリティは、自分たちが脆弱性を見落としたり、間違った実装をしてしまうと、それがセキュリティインシデントやサービスの障害につながってしまうので、テストをしっかり作り込んだり、メンバー同士で仕事内容のレビューを行うようになっています。自分が頑張って実装したコードが、テストであっさり落ちてしまってたり、レビューでダメ出しされてがっくりすることもありますね(笑)。

(一同笑)

そういう感じで、先輩がフォローをしてくれたので、セキュリティ技術をしっかり身に着けられましたね。

鈴木:なるほど。仕事が始まったあとでも、複数人体制というか一緒にやってくれる人がいて、それで一緒にやっていく感じですかね。

石塚:みんなで進めていく感じですね。

鈴木:なるほど。おもしろそうですね。

1個のコマンドのミスが大障害につながる

石塚:ちなみに井早さんはどんな感じですか?

井早:そうですね。石塚君との共通点で言うと、Slackで話したらすぐに先輩からレスポンスをもらえるところは本当に同じだなと思って。それぞれ新卒の日報チャンネルみたいなのがあって、「いやー。ここのコードがわからないなー」「OSを入れても動かないな」みたいなことをつぶやくと、先輩たちが我先にヒントを出してくれる、温かい感じでやっていましたね。

稲垣:温かいですね。

井早:インフラなので、1個のコマンドのミスが大障害につながるので、スピードよりも質を重視するところがあったので、最初の研修期間は特にそれを叩き込むという意味でも、わからないところは、本当に時間をかけてもいいからゆっくり学んでくれ、みたいな感じで、細かいところまで理解することを求められていましたね。

業務以外でいうと麻雀部とかフットサル部とか、新宿とかでフットサルをしていたりするんですよ。

(一同笑)

そういう趣味ベースでもつながったりしていて、けっこうワイワイ楽しくやっている感じですね。

稲垣:いいですね。

井早:稲垣さんはどういう感じなんですか? 共通点とかあったりしますか?

稲垣:もちろん共通点はあって、最初はお二人と一緒なんですけど、Slackでメンションすると、けっこうすぐに返事が返ってきて、ありがたいなと。

井早:ありがたいですよね。隣にいないと、リアルじゃないからなかなか聞きにくいですよね。

稲垣:やはり井早さんと一緒で、スピードより正確性が求められるところがあって、けっこうミスが許されず、テストなどもちゃんと書くので、やはり正確性を求められる。だからコードを書く上でも、全然わからないけどなんとなく動きそうだから書いた、とかじゃなくて、理解した上でちゃんとコードを書くように意識することを求められますね。

違うところでいうと、「静的解析器を実装してね」となったんですけど、いきなり1人でやったんじゃなくて、モブプロを用いて実装していて、3人ぐらいが集まって1つのものを作っていくという感じで。ペアプロとかモブプロは、けっこうできる人がカタカタッとやっていって、それを「おぉー」と見ているだけのイメージがあると思うんですけど、ぜんぜんそんなことはなくて。

カタカタやる人は、他の見ている人の言われたことに従って、ただタイピングするだけ。タイピストと言われるんですけど、だから見ている人は、ただ見ているだけじゃなくて、どういうことをしないといけないかを考えて、そのタイピングする人を導かないといけないんです。

井早:なるほど。ボーっとしていられないんですね。

稲垣:誰もボーっとしていられないんですよ。みんなわらわらと作っていかないといけない。この役割を交代しながら、最初は静的解析器を実装していく感じになって、それで先輩というかメンターの仕事ぶりを見つつ、自分もそのメンターに導かれて実装していく。それで2ヶ月後ぐらいに1人で実装をして、プルリクエストを出してレビューしてもらうかたちにシフトしていきました。

鈴木:じゃあ稲垣さんは、さっきで言うところの、タイピングする側と指示を出す側の両方をやったみたいな。両方経験して学んでいったんですね。

稲垣:そうですね。両方できるのはすごくよかったですね。

鈴木:おもしろいなと思ったのが、僕の部署はスピードも大事にされるタイプの部署なんですが、みなさんはけっこう最後の砦感があるというか、ミスしたらやばい部署の方が3人揃っているので、とにかく質が大事な思想になっている感じなんですよね。そのへんは違いが見られておもしろいですね。

一同:そうですね。

セキュリティグループはメンバーのバックグラウンドも多種多様

鈴木:では次のトークテーマに移っていきたいと思うんですが、ちょうど何を大事にしているかという部署の話も出たので、この話を聞いていこうと思います。やはり部署の雰囲気は学生の方も気になると思うので、どういう方がいるのか、その人が何を大事に仕事をしているのかみたいなところを含めて、聞いていきたいと思います。石塚さんからいいですか?

石塚:セキュリティグループは、業務内容が幅広いので、メンバーのバックグラウンドも多種多様ですね。例えばCTF(Capture The Flag)というセキュリティのコンテストにバリバリ参加していた人が在籍しています。また、ツール開発もセキュリティ部で行っているので、僕みたいな競技プログラミング経験者など、アルゴリズムやコードを書くのが大好きな人も揃っていますね。

他にもインフラやログ監視など、セキュリティの業務は幅が広いので、Webに強い人やネットワークに強い人、低レイヤーに強い人などがそれぞれ強みを活かして仕事をしている感じですね。

鈴木:なるほど。けっこういろいろなことをやってきて、セキュリティに集まってきたという感じなんですね。

石塚:そうですね。ただ共通して感じるのは、いろいろな技術に対して好奇心を持って仕事をしているところですね。新しいチート手法やセキュリティ課題が出てきた時は、みんなで楽しく、楽しく議論しながら対策を進めていますね。例えば最近だと、話題のLog4jとか。

(一同笑)

鈴木:ちょっとタイムリーな話になるかもしれない。

井早:ホットな話題ですね。

石塚:Log4jが出てきた時は、実際にLog4jの脆弱性を調査するために、攻撃を受けるサーバーとexploitという攻撃用のスクリプトを自分たちで用意して、どういう条件で脆弱性が再現されるかなどを学習していました。また、Log4j自体の対策は、話題が出てからすぐに進めていましたね。

一同:へー。

鈴木:メチャクチャ大事ですよね。

いろいろなところから集まってきたテストのスペシャリスト

稲垣:ちなみに自分の部署で言うと、けっこう石塚さんと似ているところも似ていないところもあって。似ているところでいうと、やはり多種多様というところがメチャクチャ似ていて、横断部署なのでけっこういろいろなソフトを扱うんですよね。

だから、iOSだったりAndroidだったり、CI/CDやJenkinsなどもやっている人がいますし、Uniyやのそういうバックエンドのさまざまな知識を持った人がいるのは、けっこう共通点です。

鈴木:同じく、いろいろなところから集まってきたテストのスペシャリストたち、みたいな感じなんですね、なるほど。

稲垣:やはり好奇心旺盛で、いろいろな技術だったりを常に追い求めている姿勢が共通しているかなと思います。違うところというか、SWET特有なところで言うと、けっこうミスが発生したりすると、そのミスが二度と起きないようにすることを重視している感じがありますね。

なのでミスが起きた時に、再発防止策というか、なんでそのミスが起こって、どうしたら起こらなくなるのかをすごく突き詰めるんですよ。だからミスが起こりやすい場所に対してのレビューがすごく激しいというか、丁寧なんですよ。例えば文章とかを書いていても、表記ゆれがあったら「これ表記ゆれしているよね。直したほうがいいよね」「直さない理由ないよね」みたいな。

(一同笑)

あとは、パラメータとアーギュメントの言葉の使い分けをすると、メチャクチャいいみたいな。「これはどっちなの?」みたいなものがあったりして、レビューがすごく丁寧なんですよ。

鈴木:なるほど。日本語のドキュメントにもけっこうチェックが入るみたいな。

稲垣:チェックが入りますね。チェックがそんなに入ると、厳しいのかなと思うかもしれないんですけど、良いところもあります。

というかここは僕の一押しポイントなんですけど、レビュー対象に良いところがあると「ここ良いね」みたいなコメントがスッと来るんですよ。これはすごくいい文化だな、と思っていましてね。

井早:指摘をメチャクチャ受けちゃうと、本当にプルリクの画面を見るのも嫌になっちゃう。

稲垣:ありますね。「自分はちょっとできないのかな」とか「ダメだったのかな」みたいな気分になっちゃいますけど、そういうコメントが1つあるだけで、ぜんぜん違いますから。

井早:本当ですよね。

どうやってミスが起きないようにするかの仕組みを作る

井早:僕の部署の話でいうと、さっきの稲垣さんの話にもあったんですけど、やはりインフラもミスがあるとけっこう大変な部署なので、どうやって仕組みとしてミスが起きないようにするかに、けっこう力を入れている部署かなと思っていて。

先ほどの南場さんの話にもありましたけど、DeNAの行動指針として「“コト”に向かう」みたいな話があって、その“コト”に向かっていかにファクトベースで、攻撃的にならずに物腰柔らかに議論するかみたいなところを、すごく大切にしています。障害が起きてしまった時も、「起きちゃったものはしょうがないから、次からはどうやったら構造的に起きないようにするかね」みたいな相談をみんなとしたり。

そういうところは、プレッシャーがあまりないというか、障害を起こしても、事実どう直したらいいかみたいな話ができて、「なんで障害を起こしたんだ!」みたいに責められることはないので、そこはけっこう良いところかなと思っています。

鈴木:手厚くフォローというか、バックアップみたいなものがされているという感じなんですね。

井早:そうですね。

1回やってみたあとにディスカッションする

鈴木:僕の部署でも似ているなと思ったのが、けっこう知的好奇心が旺盛な人が多いなと思っていて、新しい論文が出たぞみたいな話をすぐにキャッチアップしていく人がいたり、Kaggleの優勝解法を再現実装してみたりしている人も多いです。

あとは、Kaggleをやっていない人ももちろん内部にいるので、そういう人は例えばデータサイエンスの前後というか、どうデータをきれいにするべきか、逆に作ったモデルをどう届けていくかみたいな、MLOpsなところを中心に学んでいる印象ですね。スキルの幅を広げたり、スキルを深ぼっていくところに熱心な人が多い印象があって、そこがみなさんと同じだと思いましたね。

やはりオープンでフラットなコミュニケーションは共通しているのかなと思って、僕が好きなポイントの1つがそこですね。

ちょっと違うかなと思ったのは、手取り足取りみたいな感じはうちの部署はあまりなくて、どちらかというと、1回やってみたあとに、できたその分析結果やモデルに対してディスカッションする雰囲気がけっこう強くて、それが特徴的かなと思いましたね。

井早:むちゃぶり文化というか、とりあえず任せてみようという文化はありますよね。

(一同笑)

鈴木:そうですね(笑)。まるっと任されるほうが良かったりもしますよね。さっきのAnycaの話でもそうですが、まるっと任せてもらったほうが成長はすると思うので、そういうところはすごく良いなと思いましたね。

お互いの部署を一日体験してみたい

鈴木:こうしてみなさんにお話を聞いていると、技術を軸にしてそれを突き詰めていったり、それを軸にしていろいろなサービスに適用していくみたいな共通点が見えてきました。質をメチャクチャ大事にするのか速度もやはり大事なのかみたいな感じの違いも見れて、おもしろかったですね。

石塚:そうですね。

井早:やはり技術を極めるところは共通している4人だとは思うんですけど、部署の雰囲気とかも色があったりして、1日体験してみたいなと思いましたね。

(一同笑)

鈴木:僕は、SWETもおもしろそうだし、チートをやってみるというか、攻撃側もけっこうおもしろそうだなと思って。

稲垣:そうですね。

石塚:とても良い経験になりそうな気がしますよね。

鈴木:ちょっとお互い交流してもっと深めていけたらいいかなと。

一同:そうですね。

鈴木:ここまでパネルディスカッションを進めていきましたが、本日はこんなところでお開きにしたいと思います。ご視聴いただいたみなさまありがとうございました。

一同:ありがとうございました。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

株式会社ディー・エヌ・エー

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策

人気の記事

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!