- Developers Summit 2020（1日目）に参加してきました。
タイムテーブル
10:00～10:45
| タイトル | 発表者 |
|---|---|
| 出勤から企業開発者を解放し、エンジニアの働き方改革を実現するリモート開発環境構築 | 増渕 大輔[日本マイクロソフト] |
| 起業家的？！エンジニアのススメ | 玉川 憲[ソラコム] |
| 最新のブラウザで変わるCookieの取扱いやプライバシーの考え方 | 古川 陽介さん[リクルートテクノロジーズ] |
| LINEがプライベートクラウドを選ぶ理由 | 室井 雅仁[LINE] |
| UXデザインが大事なのはわかるけどエンジニアの私ができることってなんでしょう？ | 安藤 昌也[千葉工業大学] |
| ITがモビリティを創る：MaaSに向けた技術とエンジニア像 | 伊藤 昌毅[東京大学] |
11:05～11:50
| タイトル | 発表者 |
|---|---|
| ノーコードPower？だけど開発者だからこそ知っておきたい、Power Platformの使いこなしかた～〜W王子より愛を込めて | 廣瀬 一海[日本マイクロソフト] 清水 優吾[セカンドファクトリー] |
| モノタロウがGCPで挑戦するデータドリブン・ECプラットフォーム〜持続的成長の舞台裏 | 普川 泰如[MonotaRO] 藤本 洋一[MonotaRO] |
| CircleCIの3000 万件のワークフローから得られたDevOpsに関する知見 | 車井 登[CircleCI] |
| ぼくらの六十日間戦争 ～ｵﾝﾌﾟﾚからｸﾗｳﾄﾞへの移行～ | 左近充 裕樹[ブロードリーフ] |
| doda開発者が語る IoT＆サーバレスでビジネスサイド変革に挑戦した話～イノベ観点のダッシュボタン＆負債から進化したアーキテクチャ～ | 上源 勇朗[パーソルキャリア] |
| アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？ | 松岡 正人[日本シノプシス] |
12:10〜12:40
| タイトル | 発表者 |
|---|---|
| Let's Dive in Developer Community! | 小田 祥平[日本マイクロソフト] 加藤 健大[テイ・デイ・エス] |
| Kubernetes未経験者がGKEの本番リリース〜障害対応を経験して苦悩した話 | 泉水 朝匡[grasys] |
| noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦 | 今 雄一[ピースオブケイク] |
| サーバーレスなPCI DSS対応クレジットカード決済基盤システムを運用しながら、みんなでわいわいDIYの精神で、新しいモバイル決済サービス6gramを作っている話 | 田岡 文利[ミクシィ] |
| 常識を破壊するティール組織とエンジニアリング組織論 | 片岡 俊行[ゆめみ] |
| 音声認識で質の高い議事録を！議事録サービス「GIJI」 | 川端 光義[アジャイルウェア] |
13:05～13:50
| タイトル | 発表者 |
|---|---|
| 我々はZOZOTOWNのクラウドジャーニーを通じて何を学んだのか？ | 川崎 庸市[ZOZOテクノロジーズ] |
| 質とスピード | 和田 卓人[タワーズ・クエスト] |
| インターネットが変えた世界・変える未来 | 伊勢 幸一[さくらインターネット] |
| 創業105年の旅館運営企業が実現した毎週リリースするチームの作り方 | 藤井 崇介[星野リゾート] |
| Webパフォーマンスガチ勢が本当に使っている技術 | 中村 けん牛[プライム・ストラテジー] |
| 若年層におけるプログラミング的思考の学びの場づくりと動機づけ | 鷲崎 弘宜[早稲田大学] 齋藤 大輔[早稲田大学] 坂本 一憲[早稲田大学] |
14:10～14:55
| タイトル | 発表者 |
|---|---|
| 楽天がモノリス→マイクロサービス & オンプレ→クラウドで経験した光と闇 | 柳本 浩一[楽天] 新井 庸介[日本マイクロソフト] |
| Best Practices In Implementing Container Image Promotion Pipelines -知っておくべきコンテナイメージ・プロモーションの方法 | Baruch Sadogursky[JFrog] |
| 批評家不要！気がつきゃ全員エンジニアリング。アジャイルなTeamでプロダクトを生み出し続けるスマレジとEBILABの挑戦とこれからの企業の存在意義 | 小田島 春樹[EBILAB] 常盤木 龍治[EBILAB] 山本 博士[スマレジ] 宮崎 龍平[スマレジ] |
| ともにつくる「DX」〜事業会社、スタートアップ、グローバル、そして・・・「あなた」〜 | 福井 勝史[Insight Edge] |
| Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜 | 中井 悦司[グーグル・クラウド・ジャパン] |
| Salesforceで変わるこれからのアプリケーション開発と開発者の働き方 | 田中 宏樹[セールスフォース・ドットコム] |
15:15～16:00
| タイトル | 発表者 |
|---|---|
| GitHubやMicrosoftが機能リリースする舞台裏 | 服部 佑樹[日本マイクロソフト] 田中 裕一[ギットハブ・ジャパン] |
| Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦 | 岩根 義忠[ホンダエンジニアリング] 松浦 洋介[NECソリューションイノベータ] 星 直人[ホンダエンジニアリング] 矢田 将[ホンダエンジニアリング] |
| 礼節から育てるチームの健康と信頼性 | 塩谷 啓[クラスメソッド] |
| テストエンジニアが教える テストコードを書き始める前に考えるべきテスト | 風間 裕也[ビズリーチ] |
| なぜ技術力評価会の評価者はペアなのか？ー 8年半で378組の評価者ペアが835回評価した事例からみるペアの効果 ー | 小賀 昌法[VOYAGE GROUP] |
| 「厳密な共通言語」としての形式手法 | チェシャ猫[ProofCafe] |
16:20～17:05
| タイトル | 発表者 |
|---|---|
| GateboxにおけるAzure AD/AD B2Cを基盤としたID Centricな組織・サービス・プラットフォームの設計 | 久森 達郎[Gatebox] |
| コンテナをシンプルに使おう 〜 Cloud Run のすゝめ 2020 冬 | 篠原 一徳[グーグル・クラウド・ジャパン] |
| InterSystems IRIS Data Platformで高度なデータ分析のための基盤を整備しよう | 堀田 稔[インターシステムズジャパン] |
| エンジニアはものづくりの夢を見るか - AWS Loft Tokyo 入館アプリの開発事例 - | 西谷 圭介[アマゾン ウェブ サービス ジャパン] 今村 優太[アマゾン ウェブ サービス ジャパン] |
| クラウドサービスとゲーミフィケーション:「TwilioQuest 3」を用いた開発者オンボーディング | 池原 大然[Twilio Japan] |
| 少量データで軽量な機械学習の手法について | 秋吉 信吾[QuantumCore] |
17:25～18:45
| タイトル | 発表者 |
|---|---|
| 俺たち一生楽しい厨二病〜トッキー、ジニアス、漆原の赤裸々トーク〜 | 漆原 茂[ウルシステムズ] 常盤木 龍治[EBILAB] ジニアス平井[日本マイクロソフト] |
| 「ITエンジニア本大賞 2020」プレゼン大会 | 【司会】高柳 謙/【特別ゲスト】永瀬 美穂[アトラクタ] 【特別ゲスト】広木 大地[レクター] 【特別ゲスト】山下 智也[英治出版] |
| 若手エンジニアの登竜門「Developers Boost 2019」優秀セッション再演！ 組織にモヤッとしたら聞く話 エンジニア×〇〇 ～職種を「越境」して希少性を出すキャリア～ 入社2年目からスクラムマスターとしてチーム改善に取り組んだ話 |
蜂須賀 大貴[IMAGICA Lab.] 池上 純平[プレイド] 西山 慧[ヤフー] |
| エンジニアと人事がともに考えるエンジニア採用 エンジニアと企業、それぞれの立場から見た採用市場の実情 エンジニアが人事と一緒に採用活動する時に考えたいジョブディスクリプション 認識ギャップが不幸の始まり・・・不思議な造語「カジュアル面談」を考える |
【モデレーター】金山 貴泰[うるる] てぃーびー（田部井 勝彦）[スタディスト] 伊藤 哲弥[LAPRAS] 安立 沙耶佳[ヌーラボ] 梶原 成親[ヤプリ] |
| チームをつくるモブプログラミング ～内側と外側から語る～ | 及部 敬雄[デンソー] 安井 力 |
| あのイベントの裏側が知れる！？カンファレンス運営者LT | 西馬 一郎[Backlog World] 島根 義和[JaSST Tokyo] 岸川 孝明[JAWS DAYS] 高橋 慎一[明日の開発カンファレンス] 谷本 心[JJUG CCC] 細澤 あゆみ[XP祭り] 柏岡 秀男[PHPカンファレンス] 【司会】鍋島 英莉[翔泳社] |
最新のブラウザで変わるCookieの取扱いやプライバシーの考え方
最近のブラウザ
- セキュリティ/プライバシー周りの変更が多い
- Safari
- ITP
- Firefox
- ETP
- Chrome
- 3rd party Cookieに関してはChromeが一番厳しい対応
- 他は非推奨に対してChromeは廃止という語気
3rd Party Cookie
- 表示しているページのoriginと異なるなるoriginのCookie
- これを制限しようという動きが広まってる
Cookieとは
Cookieを使ったトラッキング
- a.comのページでb.comの広告を見た
- b.comにアクセスしたという情報がCookieに保存される
- b.comにアクセスすると過去にアクセスしたことがわかる
- c.comでb.comの広告を見る
- 過去にa.comにも行っている人だと紐付けられる
- Cookieを使うことで広告の最適化などしていた
JavaScriptによるCookieのセット
- JSダウンロードさせて
document.cookie使ってcookieセットできる - この場合1st Party扱いになる
- ただしこれは1dayの期限付き
- ブラウザによって動きは違うが3rd Party Cookieによるトラッキングはできない
- サブドメインとして登録して1st Paryになるようにすればトラッキングできる
- ずっといたちごっこ
トラッキング
- トラッキング全てNGにするとWebの収益モデルが崩れる
- Cookieでトラッキングするのがダメと言われてる
- なんでもCookieを使うのがよくない
- プライバシーに配慮した利便性のいい仕組みが必要
- Safari
- Private Click Measurement
- 広告をクリックしてそこから購入したことをCookieなしで検知できるようになる
- コンバージョンしたかどうかだけしか分からず何を買ったかなどは削られる
- Private Click Measurement
- Chrome
どう対応すればよいか
アプリケーションやシステムが悪い奴らに攻撃されたらどうなる？
- 松岡 正人さん[日本シノプシス]
サイバーインシデントはなぜ起こる
- サイバーインシデント
- ある調査によるとビジネス上の課題でサイバーインシデントはトップ要因
- ソフトウェアの品質がビジネスに直結する
- サイバーインシデントの要因
- 悪い人が意図して起こす
- 悪意のない人が意図せず起こす
- コード量が増えるとリスクは増える
- サイバーインシデントによる影響
- 制御プログラムの不具合によるリコールが増大
- 生命の危機や社会インフラの停止につながることもある
- 飛行機の墜落の事故
- => 攻撃されたときの影響も甚大
- 現代のソフトウェア開発の課題
よりセキュアなアプリケーションの開発
- 解決すべき課題を明確にする
- どんな脆弱性を持っていてどういう危険性があるのかちゃんと理解して対策をとる
品質を向上しセキュリティリスクを低減する
- 脅威モデル
- 攻撃の入り口
- 外部から
- 内部から
- 事例の7割は内部に協力者がいる
- アセットの配置を整理
- 人を想定
- 管理策を構成
- 攻撃の入り口
- Microsoft: STRIDE
- OWASP: Application Threat Modeling
- Openid Foundation: OAuth 2.0 Treat Model/IETF RFC6819
noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦
- 今 雄一さん[ピースオブケイク]
noteのグロースモデル
- 作者が集まる -> コンテンツが集まる -> 読者が集まる -> コンテンツが売れる -> 作者が集まる
- 矢印の数値を監視して数字が落ちているところを補強していく
- 単一のKPIを追わない
- バランス良く勝手に伸びるような構造
noteのチーム
- 基盤チーム
- グロースモデル全体を活性化
- KPIの監視
- プッシュ通知の基盤
- 機能開発チーム
- MAX3ヶ月くらいのスパンで主要な機能を開発
- カイゼンチーム
- アジリティ重視でPDCAをひたすら回す
- 長くても2週間くらいのスピード感
noteのデータ
- noteが成長してきてグロースモデルの状態が把握しづらくなってきた
- 人も増えて関係者が増えてきた
- データ活用の機運が高まった
- データの取得
- 言葉の定義
- 離脱とはなんなのか？などなど
- 言葉の定義
- データ収集のための分析基盤構築
今後何をやっていくのか
我々はZOZOTOWNのクラウドジャーニーを通じて何を学んだのか？
ZOZOTWONのリプレース
課題
- 時間がかかるリソース調達
- インフラ構築運用の手間増大
- システム負荷に波がある
- セールのタイミングで負荷が大きくかかる
- 一番使われる量に合わえせてサーバを毎年買い足さないといけない
- オンプレからクラウドへ
リプレース戦略
- リプレース前は超密結合
戦略
アクセスを受けるサーバはそのまま(いろいろあるので)
- そこから呼び出すAPIをクラウド/コンテナ化
- 負荷の増減が激しいところなので
- Nginx+SpringBoot
- マルチクラウド
- SPOFを回避したい
- AzureとAWSで
- 最初にAzure選んだのはID周りがいいから
ZOZOのクラウドジャーニー
堅牢性より回復性
- ダウンタイムやデータ損失を回避してサービスを維持できるシステムに
- 参照系APIの回復性機能
クラウドリソースは有限
- 抽象化してるだけで有限である
- 想定を上回るような利用をする場合は注意
- ピーク時にキャパシティ確保失敗した事例あり
クラウドは決して安くない
- オンプレとはモデルが違う
- 減価償却モデル/従量課金モデル
- 長期的にみると割高になることも
- コスト削減の取り組み
- アクセス少ないタイミングでDBのコア数を調整
- リソースの使用率を平準化させる
- できれば動的にこれをやりたい
学習の基本姿勢
Googleにおける「ソフトウェア×インフラ」デザイン〜マイクロサービス・アーキテクトの視点から〜
- 中井 悦司さん[グーグル・クラウド・ジャパン]
テーマ
- デブサミで毎回インフラの話しをしてる
- インフラの次を考える時代になってきてるので今回のテーマにした
- マイクロサービスアーキテクト
- SREとペアになるような考え方
GCPの魅力
- Googleのソフトウェアエンジンと同じ体験を一般のデベロッパーに提供するもの
- Googleの考え方
- 世界中の情報を整理し世界中の人ボトがアクセスできて使えるようにする
- 専用回線によるグローバルネットワーク
- 社内でコンテナ管理Borg
GCPを使っていく上での悩み
- どう組み合わせればいいの？中の人はどうやって使ってるの？
- Google社内ではマイクロサービスという言葉は使わない
- 最初に作った検索エンジンがマイクロサービスだった
- それが当たり前なのでわざわざマイクロサービスって呼ばない
- インフラの中の話はいろんな論文がたくさんでてる
- どういう風にサービスを組み合わせるといいかはほとんどない
- 社内にはあるけど公開できない
マイクロサービスWebアーキテクチャ
- Web3層アーキテクチャ
- クライアント - Webサーバ - Appサーバ
- マイクロサービスWebアーキテクチャ
- クライアント - reverse proxy - BFF - 同期系サービス(n個) - 非同期系サービス(n個)
- BFFで外部に見せるAPIとサービス実装を分離
- Googleにおけるマイクロサービス基盤の構成
- Magleb - GFE - (grpc) - 同期系Borg Job(n個 - 非同期系Borg Job(n個)
- だいたい同じ
- GCPのサービスに置き換えて考えることもできる
- スクラッチで新しく作るならこれでできるかもね
既存アプリのマイクロサービス化
- マイクロサービスのメリット
- スケーラビリティ
- サービス単位での開発デプロイ
- 新異能のリリースを安全に素早く
- 依存関係を気にせずに特定機能の改修に集中
- チームごとの独立性、並行開発並行リリース
- 何か改修する時に色んな所に手を加えなくて良いのがメリット
- 人間がマイクロサービス単位で捉えられるので理解しやすい
- トラブルシュートもやりやすくなる
- 他のチームと合わせて開発リリースするのは大変
- マイクロサービスのデメリット
- サービスの独立性を確保した設計を初期段階で行うのは難しい
- 将来の機能拡張なんて予想できない
- サービス全体をリファクタリングする瞬間はどうしてもでてくる
- 既存アプリがMVCで実装されている場合
- 特定のコントローラーを外だししてみよう
- 既存モデルの参照を必要としない機能を外出ししてみる
- 既存モデルの参照が必要な部分は残す
- オンプレ塩漬けの場合
- BFF作って既存システムを抽象化して機能単位でリプレース
- 既存クライアントは廃止して新規クライアントからBFFを叩く
- 塩漬けオンプレがサービスの一つととらえることができるようになる
マイクロサービスによるシステム設計
- アプリケーションの機能を適切に分割する作業
- BFFで外部公開する機能とサービスとして内部実装する機能の切り分け
- サービス感の連携方式
- 同期非同期
- プロトコル
- それぞれのマイクロサービスを実装する方式を考える作業
- 実行プラットフォーム
- xxx
Hondaの生産技術屋さんがソフトウェア開発でアジャイルを初導入し組織変革に挑戦
- 岩根 義忠さん[ホンダエンジニアリング]
- 松浦 洋介さん[NECソリューションイノベータ]
- 星 直人さん[ホンダエンジニアリング]
- 矢田 将さん[ホンダエンジニアリング]
登壇者
従来
- プロジェクト制だとカットオーバー後の変化に追従できなかった
- OneTeamでやっていくには属人化を防がないといけない
- 動くソフトウェアこそが要求を洗練させる最善の方法
アジャイル開発
スクラム開発スタート
- 振り返りに力を入れた
- 自ら考えるチームへ
- 各スプリントで課題を何か一つでも解決させようとした
- いつでもNowが自己ベスト
スクラムマスターから7つの質問
- 最初からチームとして成立していた？
- さまざまな部門の人がかかわっていた
- それぞれ優先するものが違う
- 同じ方を向くことが難しかった
- さまざまな部門の人がかかわっていた
- PO/SMはどうやって決めた？
- 入社したての人を選定
- 新しいことをやるなら新しい人がいい
- 入社したての人を選定
- チーム編成は何が一番大切？
- ロールに対してどんな期待値があるのか
- 同じ方向を向くために価値観をあわせる
- ベロシティって上がらないし周りに見せにくいどう管理したらいい？
- xxx
- ベロシティを下げるプラクティスってどうなの？
- モブプロやペアプロ
- どういった課題にたいするアプローチか共有してやってくといい
- 開発チームに全て委ねるって怖いのでは？
- 開発チーム以外も含めてみんなで議論して進めていったから大丈夫だった
- チームの成長を促す方法ってどんなことをすればいいの？
- 学びのスピードフィードバックを得るまでのスピード
不確実性のコーン
- 最初はウォーターフォールでやろうとしてたから仕様書があった
- 突き合わせてみたら25%程度しか必要なものは残らなかった
- 不確実性のコーンが実証できた
今後の展開
- 対象を広げる
- 他のプロジェクトでも
- フェーズを広げる
- 運用段階でも
- DevOpsを回せるように
少量データで軽量な機械学習の手法について
- 秋吉 信吾さん[QuantumCore]
リザーバコンピューティング
- 特徴
- 簡単かつ高精度
- 少ないデータでも十分な精度を出せる
- とにかく速い
- 安価
- 簡単かつ高精度
- もともと物理学
- 複雑系力学
- 特徴抽出で活用する
- 線形分岐不可能な問題を分類できるようになる
なぜリザーバコンピューティング
- 市場規模
- 2030年に国内AI市場2兆円超え
- データの質と量
- データ不足/ユーザからの利用許諾
- データクレンジング/偏り
- 軸
- ターゲット
- 個人に合わせる必要がある分野
- 環境に合わせる必要がある分野
活用例
- スマートウォッチ
- 加速度データ
- 泳法判定など
- 画像データ
- 骨格情報抽出/骨格の動き波形
- モーション判定など
- 振動データ
- 振動センサー
- 寝姿勢はんていなど
課題
- ビジネス上の課題
- なぜうまくいくのか説明するのが難しい
- 技術的な課題
- 音声などノイズが多いものは難しい
エンジニアと人事がともに考えるエンジニア採用
転職透明化ラボ
- 採用担当者と求職者の間の情報の非対称性
- 採用担当者の知識を求職者へ還元する取り組みをやっている
- 今回はエンジニアと人事との間
エンジニアにとって採用はなぜ重要？
- 会社にとって重要なのはわかる
- 個人にとって何が嬉しい？
- 給料
- 優秀な人を採用できると事業が成功して自分の給料が上がる
- 職場体験
- コミュニケーション能力の高い人が入って組織内の関係性が良くなると職場体験が向上する
- キャリアアップ
- 自分にはないスキルを持った人が入ってきたら新しいスキルを教えてもらえる
- 直接的ではないが大きな影響がある
エンジニアと企業、それぞれの立場から見た採用市場の実情
- 伊藤 哲弥さん[LAPRAS]
エンジニア側から見た採用市場
- 超売り手市場の実態
- IT人材が不足している
- エンジニアの質
- 課題解決型から価値創造型へ
- 一極集中の構図
- n数の企業から1候補者に送られてスカウトメールの数
- 1企業:22%
- 2-5企業: 50%
- 6-10企業: 18%
- 11-20企業: 8%
- n数の企業から1候補者に送られてスカウトメールの数
- Laprasに53万人エンジニアが登録してる
- スカウトメールを受け取ってるのは1%
- 企業の採用要件も特定の技術領域に集中してる
企業側から見た採用市場
- エンジニアが採用に関わるべき背景
- ディスコーズを形成することが重要
- TechBlogなど
- エンジニアは採用担当と面談したいと思っていない
- 技術のわかるエンジニアと話したい
- エンジニアのキャリア
- Engineering Manager
- Tech Lead
- Product Manager
- こいったキャリアを目指すのであれば採用に関わるべき
まとめ
- IT市場は今後も超売り手市場
- ただし引く手あまたの人とそうでない人がいる
- 人事がエンジニア採用のフロントに立つことの弊害
- エンジニアも協力していく必要性
エンジニアが人事と一緒に採用活動する時に考えたいジョブディスクリプション
- 梶原 成親さん[ヤプリ]
ジョブディスクリプション
- 具体的な職務内容
- 必要とされるスキルなど
- 企業側の情報開示のひとつ
- 業務の内容や進め方までイメージできたら最高
書いておきたいポイント
- やってほしい職務
- 採用している言語技術関連ツール
- 応募資格(前提条件)
- 歓迎要件
書いてあるとなおよいもの
- 仕事の進め方
- 案件開始から終了まで
- 仕事で関わる人
- 直面している課題
- 採用している背景
いいジョブディスクリプションの書き方
- いろんな会社のJDを読みまくる
- 30くらい見ると良いものと悪いものが見えてくる
- 現場の課題をヒアリングしてそれが欲しい人材ということ
認識ギャップが不幸の始まり・・・不思議な造語「カジュアル面談」
- 安立 沙耶佳さん[ヌーラボ]
IT業界市場
- エンジニアが足りない
- 企業の側から声を掛けていかないと人がとれない
- => カジュアル面談
カジュアル面談
- 面談？面接？
- Wantedlyが作った用語という説
- カジュアル面談ブームで困ったこと
- いきなり志望動機を聞かれる
- 逆パターンもあって興味あるからメール送っただけでなぜ採用しようと思ったか聞かれることも
- 両者の認識齟齬が起きる
ヌーラボでは
- 面談の定義を決めて候補者に伝える
- 候補者と企業のギャップを埋められるように何を話すか決めておく
- 興味があったら応募してくださいと一回相手にボールを渡す
- 選考フローを設計ししゃないで共有する
- 面談の前後で採用担当者と面談担当のエンジニアで認識合わせの打ち合わせをしてる
