CyberAgentのインターンシップに参加した話
みなさんごきげんよう.chigichan24です.
今日はCyberAgentでの就業形インターンシップに参加したことを書こうと思います.
受けるまで
実は遠い昔,一度インターンシップの選考を受けたときお祈り🙏🙏🙏🙏を頂きました.それもあって風土と自分の思考・思想が異なるんじゃないかとそこそこ渋りましたが,やっぱり気になっていたので受けてみました.
実際に選考に通るまでの流れは以下の感じです.コーディングテストとかはなかったんですが,私のGitHubにpublicで上げてるコードは見られてたっぽい(ぽい).
書類審査📝
一次面接🤓
- 人事の方とお話しました.The 面接みたいな堅い感じではなかったです.
- 設計(アーキテクチャ)とかを意識したサムシングを勉強したいです.と言いました.
- 「どういうものを作りたいのかの具体性がないのでどの部署を勧めていいかわからない」とクリティカルにありがたい指摘を頂いたので,まあ落ちたのだろうと思いました.
- 技術面談かと思ってたので,これは見当違いなことを口走ったなと思いました.
働いてみた
AbemaTVのAndroidエンジニアとしてのインターンを受け入れてもらえました🎉🎉🎉 SNSやブログ上で知っている人が存在していて,おもろかったです(何様)
実はインターンの期間はもともと一ヶ月の予定でしたが,楽しかったしリリースまでいたいという思いが高まったので二ヶ月お世話になりました.
やったこと
走っていた新機能開発のプロジェクトにぽんと突っ込まれました.ここにタスクがまとまっているから自分をassignしてPR出してみたいな感じで雑にタスクが降ってきました.そこそこ不安がっていましたが,実際にはPR上で丁寧にレビューをしていただき私の理解度に合わせて適切な粒度で方針を示してもらいめちゃくちゃ良かったです.takahiromさんは神.
基本的にはコードを書いてPRを出すという感じのスタイルだったのですが,不明瞭な点について,別のチームの人やデザイナーさん等と話すということをしたり,チームの人が出したPRに対してレビューをしたりと社員さんとほとんど対等みたいな感じで働かせていただけたのは非常にやりやすかったです.
書いたコードのジャンル(?)も多種多様で,
- ロジックっぽい部分.
- UIに近い部分.
- Kotlin化
- バグ修正
等,AbemaTV-Androidのいろんなところに手を出させていただきました.
最終日に何気なくみてみたら,合計で30個くらいのPRを出していました.当然各PRの重さはバラバラなので単純に個数で計測することに意味はないんですが,「おおーっ」となりました.
そのほか
- CA.apkというイベントや,社内で行われていたLT会での発表の機会をいただきました.タイミング的に,両者ともたまたまという感じだったんですが,機会提供をしてもらえて嬉しかったです.
- AbemaTVの番組を実際に作っているスタジオの見学に行きました.コンテンツを提供する側での現場を見れて面白かったです.
- 引っ越しを経験しました.会社の引っ越しの経験なんてそうそうすることないので,良かったです.てっきり自分の荷物は自分で運べみたいな感じかと思っていましたが,そんなことはなくて,普通に業者さんが運んでくれました(それはそう)
感じた
いくつかの企業でこれまでもインターンシップをした事があったのですが,そのどこにもなかった(いい意味での)異質さがCyberAgentにはありました.
それは速度感と規模感を両立しているところでした.ものすごいスピードで開発を進めつつ,その市場の規模をどんどん拡大していく姿は2ヶ月しかいなかったインターン生でもものすごく感じました.
また,いろんなチームがこだわりとチーム観を持って仕事をしているなとも思いました.デザインではこのように表現したいけど,クライアントにとってそれを実現するのはものすごく工数がかかる問題をどうしようというケースがあります.そのときに「ここは妥協したくない」というデザイナーさんの意見と,「ここはこういうふうに実装したい」というクライアントチームの声が毎度いい改善案(解決策)を生み出していて,すごいと思いました(小並感) .
反省点
私の考えていることが基本的に浅はかで,それちゃんと考えてるの?というPRを出してしまったことがいくつかありました.
- 動くは動くけど,それでいいのか?という部分をもっと深く追う必要があり,なにがどのように動くのかをもっと意識する必要があるなあと改めて感じました.
- 例えば,AOSPでのコードをちゃんと参照して問題ないということを示されたりしたので,Androidそのものがどのようなコードで書かれているかを深めたいです.
コードを書く速度が社員さんと比べて遅い.
- ドメイン知識がないだけだとはじめは思っていましたが,明らかに遅い.
- ある機能を追加したいときに何をどこに,どう書くかを高速にイメージする訓練をしたいです.そのためにはもっともっと引き出しを増やす必要があると深く痛感しました.
おわりに
インターンに参加したときに裏テーマとして,「人日計算の頭数に入れられるくらい一人前のエンジニアとして力になりたい」というのがありました.これを最終日に打ち明けたら,それは初日から達成していたよ(?)と言われたときはめちゃくちゃ嬉しかったです.
すごくいい環境で働かせてもらえて,CyberAgent(というかAbemaTV)の雰囲気を感じ取ることができ,また自分の技術力の向上も得られたので本当に良かったです.もっと精進します.
どうでもいいこと
渋谷のランチ事情に詳しくなった.
2018年を振り返る
chigichan24です.研究のプログラムの出力待ちにちょこちょこ記事を書いています論文を書け. 一年早いですね.今年もいろいろ成長した気がするので,成長記録として見てください.
昨年に比べoutputや評価される機会は減っているが,純度が上がっていると信じてる.
今年の大きな開発
- 1 ~ 3 月 SyncPodのレビュー作業(iOS, Swift)
- 2 ~ 4月 SyncPodのリプレース作業(Android, Kotlin)
- 3 ~ 10月 長期インターンシップ (詳細)
- 6 ~ 9月 Androidアプリ改修 (Android, Java)
- ?? ~ 10月 高専プロコン(Kotlin, TypeScript, Python)
- 11 ~ 12月 にぎるくん (dart, flutter)
- ?? ~ 12月 卒業研究用プログラム (C++, Python)
所感
- ネイティブアプリのエンジニアとして極めたいという思いが詰まった一年.
- それでもって,インフラのお仕事やバックエンドを書く機会もしっかり持てている.
- Kotlin,awsに関する知見が増えた.
発表したLT等
- kosen12s LT #1
- kosen12s LT #2
- yakiniku-LT(?) #2
- KosenLT会
- 第17回 学生LT
- shibuya.apk #30
所感
- kosen界隈に関わり過ぎでは...
- 目標にしていたshibuya.apkで話せてよかった
出場したコンテスト
所感
- 予選落ちが多かったので精進.
読んだ本(よかったやつ)
- 作者: Dmitry Jemerov,Svetlana Isakova,長澤太郎,藤原聖,山本純平,yy_yank
- 出版社/メーカー: マイナビ出版
- 発売日: 2017/10/31
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
Androidアプリ開発のためのKotlin実践プログラミング
- 作者: 船曳崇也
- 出版社/メーカー: 秀和システム
- 発売日: 2017/12/26
- メディア: 単行本
- この商品を含むブログ (1件) を見る
- 作者: Sam Newman,佐藤直生,木下哲也
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/02/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
EXTREME TEAMS(エクストリーム・チームズ)--- アップル、グーグルに続く次世代最先端企業の成功の秘訣
- 作者: ロバート・ブルース・ショー,上原裕美子
- 出版社/メーカー: すばる舎
- 発売日: 2017/11/19
- メディア: 単行本
- この商品を含むブログ (1件) を見る
所感
- Android周りの話が多い.
研究関連
- Mendeleyによると65本論文を読んだらしい.まとめる以前や打ち込んでない論文を入れると多分100行かないくらい読み込んだっぽい.
- きれいなC++17書けてない.頑張ろう...
ブログ
テクノロジーな記事を何本か書けた.二番煎じにならないことを目標にしていたが....
その他
- いろんなカンファレンスや勉強会に行って知見を広めた.
- 設計論について色んな人と議論できた.
- kosen12s LTはadminとして頑張った.
- 何本かギークな記事を書いた.
- OSSに貢献できた.
- キャッシュレスが加速した.
来年に向けて
技術へのこだわりとプロダクトを作り上げるバランスを忘れない
この記事はmast Another Advent Calendar 2018の19日目の記事です.
18日目は同級生kawaguchikoくんの記事でした.彼の記事おもろいので読んでみてください.
mast15の @chigichan24 です.四年生ですが,大学は二年目です.のらりくらりとプログラムを書いて遊んでいたらこんな感じになりました.mast15では自称プログラムが書けるマンとしてイキってます(ごめんなさい)
さて,いろいろと書きたいことを迷いました.迷ったけどこれにしました.理由はmastの人の多くは,ものづくりやメディア表現等を通して社会になんらかのメッセージを残すことを試みる集団であるからです.
技術へのこだわりとプロダクトを(ry
この言葉は私自身が,ものづくりをする上で大切にしている言葉です.(以前は「まずは手を動かしてみる」という言葉が好きでした)
誰かの偉人の言葉とかではたぶんないと思われます.このワードでぐぐってみる*1と,私のTwitterアカウントやWantedlyプロフールが見つかります.多分私が産み出した言葉なんだと思います.
さて,この言葉前半パート(1),後半パート(2)そして,結合パート(3)によって成り立っています.それぞれ分解して,解説していきましょう.
(1) 技術へのこだわり
私にはソフトウェアエンジニアとしての経験しかないため,ソフトウェアエンジニアが関係する「技術」についてのみ話すことにします.
一般論ではなく,個人的な見解として,程度の差はあれ多くのソフトウェアエンジニアはこだわりを持っています.
例えば,どの言語で開発を進めるのか?という議題.
PHPでしか経験がないから〜*2という人もいれば,スクリプト言語っぽいもので〜という人,今回は型をちゃんと使って〜とか,今Rustがキテるっぽいらしいよとかいろんなこだわりがあると思う.そのこだわりには
- 純粋なる知的欲求からくる希望
- 様々な開発現場で使ってきた経験からくる推し
- このほうが最新の規格だから,いろんな機能が使える
などなど様々.みんな技術に対して誇りや欲求をもって生きてます.
言語がやっと決まったら次は使うフレームワーク,使いたいアーキテクチャ,開発手法,CI/CDは回すの?レビューの進め方は?コーディングの規約は?使うIDEは?と言っていろんな決めごとに対して,開発するチーム(または個人)で同じようにこだわりを議論していきます.
(2) プロダクトを作り上げる
プロダクトには納期があるものがあります.納期は,学生のうちであればコンテストの締切とか,インターンシップでの期限とか,自分の熱が冷めないまでとかです.
納期までにものを作り上げることは,ものづくりをする上で常に付き纏います.完成させない状態でやっぱりだめでした😪と芸で済ませることも経験の一つです.*3
しかし,その質を客観的に見たときにどの程度まで詰められているのか?というのも求められる機会は多いです.会社に入ってソフトウェアエンジニアとして開発をしているならば,それは絶対的なものに近しいです.
これを達成するには入念なスケジューリングと進捗確認が大切です.これらを適切に管理できていれば,やっぱり駄目でしたとなることは少ないはずです.なぜならば見通しをある程度立てて計画をするため,このままだとまずいスケジュール感だとわかるはずだから.
(3) バランスを忘れない
これは(1)と(2) の取捨選択を適切に行いましょうというものです.
例えば,究極にスケジュールに余裕がない状態で絶対に使い捨てのプロダクトを作り上げないといけない状況があったとしましょう.こんなときに新しい言語で挑戦的にプログラムを作っていくことができるでしょうか?
答えはNoです.
実績のある言語を使って突貫的にでも完成を優先するべき.つまり,この場合は(2)の「プロダクトを作り上げる」を優先するべきということです.
他の例として,長期的に保守していく必要があるプロダクトを作る時,また,メンバーが新しく追加されるケースも多いとしましょう.品質も,多くのユーザがいるので高く保つ必要があるとしましょう.
このときに,上記のように突貫で作っていいでしょうか?
答えはNoです.
この場合は長期的に保守していける体制を保つために,どういった言語であれば良くて,どのようなアーキテクチャであればバグが少なく,また発生しても容易に特定できるか?を意識する必要があります.
現実の問題は上の2つの例のように単純ではありません.しかし,根本にあるのは技術をどう使っていくのか?どこまでこだわるのか?ということのはずです.
自分の立場を明確にする
さて,上の議論は「自分自身がものづくりに対してどういう気持ちで向き合っているか?」を考える上でも役に立ちます.
ちょうど式にするならば 0 ≦ α ≦ 1とするときに,
自分のお気持ち = α × 技術へのこだわり+ (1-α) × プロダクトへのこだわり
といった形で表わされる事ができます.
この言葉が自分の中で生まれた背景として「プログラミングは手段か?目的か?」という議論があります.
昔,特に高専時代は,私は絶対的にプログラミングは手段でしか無いと思っていました.けれど,プログラムそのものを学ぶうちにソフトウェアエンジニアであるならこれは目的であるべきだとも思うようにもなりました.
しかし,この議論自体0,1でどちらかの表明をする事はできない.時としてどちらかを優先するべきだなぁといろんなプロジェクトでコードを書いていくうちに思うようになりました.その上で,自分のマインドはαがだいたいこの辺りだと表明していくことが大事だという結論で,自分の中では決着がついています.*4
おわりに
今日は私がソフトウェアエンジニアとして,大事にしている言葉の紹介と詳解でした.みなさんも,ぜひ意識してみてはいかがでしょう?また,上の式の訂正や議論などもぜひ...
それでは.