概要
Battle Conference U30の内容&感想まとめです。
30歳以下のエンジニアによるサイバーエージェント主催の参加型技術カンファレンスで、今年で第3回目となるイベントです。
各セッション10分ごとで、最後にブロックごとに表彰されるという形式でした。
関連リンク
複数プロダクトで利用する共通ライブラリの戦略と運用経験@井上 真吾氏
本日の発表資料です。よろしければ投票をお願いします！！
— れこ | 7/10 TS meetup #2 (@L_e_k_o) 2019年7月6日
複数プロダクトで利用する共通ライブラリの戦略と運用経験 BCU30https://t.co/87nFbafOrL #bcu30
lib, util, common, sharedなど、規模が大きくなるに連れプロダクト内外で似たような共通フォルダで溢れて訳がわからなくことがありがちです。
そういう場合、ライブラリとして公開して管理しようという提案です。
ライブラリ開発において気をつける点
- 使えないものになりがちなのでライブラリ先行で作らない。
- 汎用性がなくなってしまうのでドッグフーディングしすぎない。形骸化しがちなボイラープレートは作らず、ベストプラクティス集にとどめておく。
- アップデートによる情報格差をなくす。 slack通知の自動化など行う。
- １つのプロダクト都合でアップデートしない。issueを活用する。
- 命名規則/型制約/ドキュメント整備/モブプロなどにより後継メンバーのための学習コストを減らす。
ライブラリ開発を行なって良かったこと
- 生産性が上がるライブラリがいくつかできた
- 縦割り感が薄まりチーム間で助け合うようになった
- OSSに貢献するエンジニアが増えた
感想
確かに規模が大きくなるにつれ何が共通なのか、もしくは何が入っているのかわからなくなりますよね。。
パッケージ的な感じなんでしょうか。運用方法についてもっと詳しく聞きたいと思いました。
ライブラリ/パッケージ開発は敷居が高そうなイメージですが、一度慣れてしまえば便利そうです。
OSSのコントリビュータが増えて技術者全体の意識が高まるのもとてもいいですね！
あと何となくUNIX哲学を思い出しました。
JavaScript の AST を扱ってみよう@大原 壯太氏
今日話した資料です〜https://t.co/Hfo8SNvJv5#bcu30 #bcu30_1
— Sota Ohara (@sottar_) 2019年7月6日
**AST(Adstruct Syntax Tree)**とは抽象構文木の一つ。
ASTはソースコードをパースして作られるもので、ソースコードの必要な情報を抽出した木構造。
DOMtreeなんかもその一つ。
ESlintやPrettierなどのコード解析やコンパイラの過程で使われる。
ASTはJavascriptで扱うことができる。
Javascript ASTのデファクトスタンダードはESTree。
パーサーはAcron, Esprima, Babylon, Espreeなどがある。
ASTが使われる一連の流れは以下。
ソースコード->(parser)->AST->(traverser)->New AST->(generetor)->Newソースコード
AST Explorerというツールが見やすくて便利。
プレゼンでは、ASTを用いてJavascriptコードのvarをconstに置き換えるというバベルプラグインを作る紹介がされた。
感想
レイヤー低めの話で難しかったです。
個人的にはESlintやprettierの設定するので精一杯なので😖
実務でどういう場面で使うか想定しづらかったので、実際に実務で使用した場面なども聞いてみたいと思いました。
コンパイラとかその辺はブラックボックス化されていて普段は意識しませんが、掘っていくと勉強になりそうです。
コマンド叩いてからソースコードを実行するまでにどういう過程を経ているのかを説明できるとカッコ良さそう（？）
行動ログを元にコンテンツを自動分類するための機械学習基盤とデータ整形@左野 寛之氏
感想
ユーザの分散表現を画像で得る発想が面白いと思いました。
大量かつ整理されたデータが揃っているのは大手ならではの強みだと思います。
インフラをきちんと整備して、しかも費用も意外と安いのはいいですね。
研究途中な感じなので今後の成果を見てみたいです！
チャットボットプロダクトにおけるリアルなNLP課題@友松 祐太氏
本日の登壇資料です
— tomomatsu_yuta (@tomomatsu_yuta) 2019年7月6日
チャットボットプロダクトにおけるリアルなNLP課題
株式会社サイバーエージェント/アドテク本部/AIメッセンジャーカンパニー/友松祐太https://t.co/9Qp7OyYsCg#BCU30 #bcu30_1
感想
実務で機械学習扱うときはデータの収集方法や量や質が課題になることは多いと思います。
データが偏っていたりノイズが多かったりするとモデルが良くても精度上がりませんよね。。
データの質を高めるために自動化するのはとても良い取り組みだと思いました。
発表を聞いて、目的に沿った活動をされているんだなぁと感じてふと思ったこと。
自分も含めて機械学習を行うことが目的になってしまいがちなので自戒を込めて。
機械学習使うまでもなくVBAやRPAや統計で十分な内容だったり、データ収集方法の検討段階で業務フローが改善して課題が解決するなどはよく聞く話なので、目的を見失わないようにしようと思いました。
話は完全に逸れますが、個人的に政府にはAI人材育成する前に役所のIT化や自動化を進めてほしいです。笑
電子国家エストニアを見習ってほしい🇪🇪
エンジニアがデザインを学ぶことの意義と応用@大木 尊紀氏
次の発表資料です！https://t.co/1Q1l3PLr8C#bcu30 #bcu30_3
— takanorip (@takanoripe) 2019年7月6日
デザインには、グラフィックデザイン・サービスデザイン・Webデザイン・建築デザインなどがある。今回はインターフェースデザインについての説明。
インターフェースデザイン・・・物体と人間の接点となる部分の設計。コンピュータの性質と人間の活動をどう結びつけるか考える。
インターフェースデザインは論理的なものであり感性の世界ではない。
考え方：UIデザイン・ユーザビリティetc..
学術的視点：知科学・心理学・人間工学etc..
エンジニアがデザインを学ぶ理由
- プロダクトがが良いものか判断するため。根拠を持つことができる。
- 何を作るべきかを考えるため。必要なものを見極められ、デザイン的な視点による説得力が増す。
- 共通言語ができコミュニケーションが円滑になる。デザイナーなどの意図を汲みやすくなる。
キャリアの例としては、そのままエンジニア・デザインエンジニア・プロダクトマネージャなど。
デザインの勉強方法
・本を読む
・個人で何か作って見る。雑誌とか名刺とか個人サイトなど。
・専門の人と話す。デザイナーと話してみたり、会議でデザインについて発言してみたり。
・デザインを批評してみる（論理的な根拠づけの練習）。
感想
感性だけでなく、論理的な根拠を持ってデザインを議論できるようになると強いですね。
デザイン勉強しよ。。
勉強したいものがどんどん積み上がっていく😇
4歳からプログラミングに夢中な"テックキッズ"が開発したアプリ「今日の洋服何着てく？」の紹介@澁谷 知希氏
感想
4歳からHTMLを触り始めたとのことで、今時のデジタルネイティブ世代に驚きです。
小学6年生の発表で、最初に習い事や好きな科目の紹介があって小学生の頃を思い出しました。笑
ものづくりを純粋に楽しんでる様子が印象的でした。プレゼンもとても上手でした！
プログラミングコンテストで受賞されてるようでした。
受賞結果発表 | 小学生のためのプログラミングコンテスト「Tech Kids Grand Prix」 | テックキッズスクール
このTech Kids Schoolというスクールもカンファレンス主催であるサイバーエージェントが運営しているようです。
月額21000円か・・・出せなくはない。。
パラレルキャリアがもたらす相乗効果@内立 良介氏
話してきたった#bcu30 #bcu30_2 #heyinchttps://t.co/eEEgsAIYqJ
— Ryosuke Uchitate (@b1a9idps) 2019年7月6日
パラレルキャリアとは、副業とは違って優先順位がない複数のキャリアを持つこと。
2018年、法律が改定され副業・兼業に関する規定が新設されたため、パラレルキャリアを始めやすくなった。
また、多様な副業サービスも沢山生まれている。
登壇者の例
・正社員/8時間×稼働日/報酬あり
・業務委託/月40時間/報酬あり
・カンファレンス運営/空き時間/報酬なし
パラレルキャリアを始めた理由
正社員の現職に不満はないが、様々な環境を経験することによってスキルアップやテックスキルの客観視をしたい
各キャリアの相互作用
・スポンサー
・開発ノウハウの共有
パラレルキャリアのメリット
・プログラミングスキルがつく
・プレゼンスキルがつく
・問題解決力がつく
・会社やフェーズの違いによる施策の打ち方の学び
・人脈が広がる
・固定概念が外れ多角的に物事を見れる
・社外からの刺激を受ける
・様々な角度から社会貢献できる
パラレルキャリアのデメリット
・オンラインが多くなりコミュニケーションコストがかかる
・時間・体調管理が必要
感想
どうやって時間管理してるのか気になりました。
他の副業してる人の話を聞いても、ワーカホリック気味で身体を壊した方の話を聞いたり、土日に仕事をすることがしんどすぎて副業を辞めてしまった方の話を聞いたりするので、時間の捻出や体調管理は課題だなーと思います。
週3~4日の正社員があればいいのにと思います。個人的には会社で給料上がるより休みが増える方が嬉しいです。笑
ログ収集基盤を導入したらエラーログが99%以上削減された話@小芝 涼太氏
感想
やっぱ周りを巻き込むのは大事だし、それも一つのスキルだと思いました。
通知したとしてそのままスルーされてもおかしくないけど、ちゃんと拾ってくれる周りの人も良いなと思いました。
そういう雰囲気が出来上がってるのもチームの力だと思います。
サービスがゼロからN億円規模になるまでに実践した7つのやっていき@菊川 史貴氏
発表の資料こちらになります！https://t.co/f9qYZtKHEQ#bcu30
— キクナントカ (@kikunantoka) 2019年7月6日
ギフティのサービスが成長していく中で得た、実践的なノウハウの紹介です。
企業向けのgiftee campaing platformというプラットフォーム、略してGCPだけどAWS使ってるらしいです。笑
1.プラットフォームを作っていく
toBだと受託になりがち。他のクライアントも必要としているか？を見極め、汎用的なサービス・プラットフォームとして開発することで大きな利益を生み出すことができる。
2.小さく初めていく
想定しすぎず小さく開発、小さく検証することでPDCAを高速に回す。
汎用的にしすぎない。バランスが大事。
「いつか必要かも」の機能はいらない。YAGNI（You ain't gonna need it）の精神。
3.一つのチームで開発していく
ビジネスチームとエンジニアで一つのチームで開発していく。
週１の定例や座席を同じ島にするなどコミュニケーションしやすい環境を整える。
4.プロダクトマーケットフィット達成後はガンガン開発していく
全力でコミットしていく。開発に集中するため、運用など他の人に移乗していく作業も行う。
サービスは運用が始まってからが本番。
5.サービスをスケーラブルにしていく
成長するとサービスを落とせない状態になるため、インフラをいつでもスケールアウト・スケールインできる状態にする。
負荷検証大事。ロック処理やスロークエリに注意。Elastic beanstalkやAWS Auroraなども活用。
6.定期的にDBの制約を見直していく
データの不整合をなくす最後の砦はDBの制約。マイグレーション結果を確認し、検知できるようにする。
7.当たり前のことを当たり前にやっていく
Linterを適用する。独自のルールはなるべく作らない。
Sentryなどのエラートラッキングサービスで健全な状態を保つ。x日以内に対応/通知など、運用面も考える。
バージョンは最新に保つ。言語・フレームワークなど、バージョンアップするだけでセキュリティ/高速化などの非機能面の恩恵を受けれる。技術的負債を防げる。
感想
実際の経験に基づいた、実践的で具体的なノウハウが詰まっていると感じました。
聞く話はどれも本当にその通りだなと思えることばかりでした。
聞くのは簡単だけど、実際に取り組んで継続していくことは大変なので、小さいことをコツコツやり続けていかないとなと思います。
バージョンアップを怠らずに技術的負債を残さないのはシステムの継続に必要なことだと思いました。
30代のキャリアを意識した20代のキャリア戦略@向井 咲人氏
本日の登壇資料です🎉🎉🎉🎉🎉
— Sakito (@__sakito__) 2019年7月6日
20代のみんなに届け〜！
30代のキャリアを意識した⁰20代のキャリア戦略⁰https://t.co/C2WSJV0vtN#bcu30_1 #bcu30
30代を予測しない
ITの未来は不確定で、会社に依存せず個人にフォーカスした時代になってきている。
個人の力を磨き、不確定な未来に向けて対応できるようにする。
土台を増やして経験を掛け合わせ、差別化する戦略を取る。
1.俯瞰してみる
得意なことや経験を客観視する。転職活動のためのレジュメづくりがおすすめ。
常にレジュメを更新する。自分を営業する。
2.自分のブランディング
ブログ、登壇、SNSなどなんでもいいので発信する。情報を流して周りから見れる状態にしておく。
多くの人に知ってもらうことで社内外で声をかけてもらえ、執筆・副業・登壇などの多くのチャンスが得られる。
3.副業や転職をする
違う環境に適応する能力が身に付く。環境がわかることによって自分の強みに気づく。
20代であればリスクも取りやすい。異なる環境においてノウハウの共有ができる。
感想
公開して人目に晒すことは大事ですよね。
スキルの掛け算で差別化していくのは本当にその通りだなーと思います。
レジュメを常にアップデートする案もなるほどと思いました。
勉強会を聞くだけを脱出して何か一つでも登壇したいです。
それかせめて運営に応募します。PHPかJavaScriptかその辺りでおすすめ教えてください。笑
サービスメッシュを導入してよかった話@江頭 宏亮
感想
前提知識がないと難しかったです。
サービスメッシュの概念を知れただけでも良かったです。
マイクロサービス間をサイドカープロキシを経由して接続することで、サービス間の依存関係や情報管理の課題を解決するもので、主にk8sと一緒に使われることが多い
って感じでしょうか。
使ってみてよかった点として、
・ビジネスロジックの実装に集中できた
・インフラ障害の影響を少なくできた
とのことでした。
このプレゼンとは直接関係ないですが、インタラクティブブースでサービスメッシュを紙芝居で説明してくれてる方が面白かったです😊
TerraformとJenkinsによる外形監視管理の自動化@李 一凡氏
感想
内部監視はよくしますが、外形監視というのを初めて聞きました。
可用性のためには確かに必要そうです。
具体的な構築の仕方を聞けて参考になりました。
カンファレンスの所感
登壇する人は入社or転職して1~2年みたいな人も多く、同じような立場の人たちがこうして活躍しているのを見るのはとてもいい刺激になりました。
内容に共感しやすいものも多く、会場の雰囲気も同世代ならではの一体感みたいなのがあり良かったです。
運営の人はみんな平成生まれだったらしいです。笑
こういうカンファレンスって出席したらぐったり疲れること多いですが、各セッション10分くらいでテンポがよく聞きやすかったです。
もっと聞きたいと思えるくらい。
Ask the speakerも用意されていたので、聞きたい人は聞きに行けるような場が用意されているのも良かったです。
プロコンも開催されており、ちょっとだけですが参加できて楽しかったです。
カンファレンス参加者の1/3くらいが参加しており、参加時間自由でセッションを抜け出さなくても参加できる時間帯なのも参加しやすかった要因かなと思いました。
カンファレンスの開始時間が昼からだったのはありがたいです。エンジニアが朝苦手な人が多いのをわかっている・・・？笑
ちなみにわたしは最初の基調講演は寝坊して遅刻したので聞けませんでした😇笑
懇親会では抽選会があり、景品当たりました！嬉しい〜
iOSをやらなければ・・・(使命感)
前回の技術書典で売られてたもののようです。
景品は技術書が多く、技術カンファレンスならでは感がありました。
ご飯もスポンサーが手厚いのか豪華で美味しかったです。あげパンとか🥖
全体的に大満足の内容でとても楽しかったです！
運営の方々に感謝！
最後に
記事に間違いや不明な点があれば遠慮なくご指摘ください。
また、個人が勝手にまとめてるのでもし載せるのがダメな場合も遠慮なく教えてください。