- Developers Summit 2020（2日目）に参加してきました。
タイムテーブル
10:00～10:45
| タイトル | 発表者 |
|---|---|
| チーム・ジャーニー 〜逆境を越える変化に強いチームをつくりあげるまで〜 | 市谷 聡啓[DevLOVE] |
| 「ともにつくる」を実践するドメイン駆動設計 | 成瀬 允宣[GMOインターネット] |
| レガシーコードからの脱却 | 吉羽 龍太郎[アトラクタ] |
| エンジニアよ、今こそ社会課題に立ち向かおう！ | 関 治之[Code for Japan] |
| AWS障害で考えさせられた、アプリケーションインフラ構成の注意ポイント | 城 航太[サーバーワークス] 佐藤 豊[サーバーワークス] |
| 組織の創造性を高めるために必要なこと | 伊藤 直樹[PARTY] |
11:05～11:50
| タイトル | 発表者 |
|---|---|
新しいHTML<portal>を利用した画面遷移設計 〜PayPayモールとYahoo!ニュースの事例を添えて〜 |
萩野 誠一[ヤフー] 関 真由美[ヤフー] |
| 守りのモニタリングから攻めのモニタリングへ | 大谷 和紀[New Relic] |
| 開発に集中するためのJava on Serverless | 下川 賢介[アマゾン ウェブ サービス ジャパン] |
| エンプラアジャイル導入の守破離 | 小俣 剛貴[Pivotalジャパン] 安西 結[Pivotalジャパン] |
| プリンシプル・オブ・"ともにつくる"～ Web Performerを支えるドクトリン ～ | 上田 勲[キヤノンITソリューションズ] |
| 職種の垣根を越えるコミュニケーションのススメ | 池村 和剛[ゆめみ] 吉田 理穂[ゆめみ] 小川 段[ゆめみ] 戸田 修輔[ゆめみ] |
12:10〜12:40
| タイトル | 発表者 |
|---|---|
| A retro on agile ー アジャイルをふりかえる | Jason Wong[Atlassian] |
| K8S使ってますか？リテールテック（小売・決済等）でのコンテナ活用例と「2025年の崖」克服に向けたコンテナ導入のススメ！ | 程 建強[Rancher Labs] 山澤 一仁[スーパーソフトウエア] 井川 知幸[カゴヤ・ジャパン] |
| Python基礎試験とデータ分析の例題解説～稟議に使えるPython市場データと試験も紹介～ | 吉政 忠志[Pythonエンジニア育成推進協会] 寺田 学[Pythonエンジニア育成推進協会] |
| 全アプリ開発者に伝えたい、レガシーコードから脱却するための具体的な手法、"ルール駆動開発" | 松田 絵里奈[レッドハット] |
| 自己組織的な開発チームを如何にして作り上げるか | 木利 友一[TIS] |
| アジャイルのプロセスとデザイナーの変化-開発チームに欠かせないデザイナーになるために- | 樋田 勇也[サイボウズ] |
13:05～13:50
| タイトル | 発表者 |
|---|---|
| 問題から目を背けず取り組んでいく ･･･ 一休のこれまで | 伊藤 直也[一休] |
| プロダクトを10年運用するチームをつくる | 粕谷 大輔 [はてな] |
| エッジコンピューティング、エッジAIの可能性 | 中村 晃一[Idein] |
| 日本にJoy,Incを創る！どん底からスタートしたぼくらのジョイインクジャーニー7年間の軌跡 | 安田 忠弘[クリエーションライン] |
| アジャイル開発の原則を守りつつ、マルチサイト開発を行なう！ ～ベトナムのメンバーとともにつくる～ | 藤村 新[クラスメソッド] |
| デザイナー/リサーチャー/エンジニアが語る、UXとの関わりかた | 松薗 美帆[メルペイ] 山本 興一[スマートニュース] 重田 桂誓[クックパッド] |
14:10～14:55
| タイトル | 発表者 |
|---|---|
| 事業グロースを加速させる「分析基盤」の作り方【JapanTaxi/ホワイトプラス事例】 1ヶ月でデータ基盤を整え経営の解像度を変えた話 |
森谷 光雄[ホワイトプラス] 伊田 正寿[JapanTaxi] 小林 寛和[primeNumber] |
| グランブルーファンタジーを支えるサーバーサイドの技術 | 小松 美穂[Cygames] 大橋 庸[Cygames] |
| クラウド・ネイティブ時代に最適なJavaベースのマイクロサービス・フレームワーク ～ Helidonの実力を見極めろ！ | 古手川 忠久[日本オラクル] |
| マルチクラウドに向けてNGINX活用促進する為に知っておいてほしいこと | 鈴木 孝彰[NGINX (Part of F5)] |
| AI3分クッキング | グティエレス パウロ[Databricks Japan] |
| テクノロジーとクリエイティブがコマース体験を変革する | 河野 貴伸[フラクタ] |
15:15～16:00
| タイトル | 発表者 |
|---|---|
| 世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた | 鈴木 雄介[アイムデジタルラボ] 河村 明彦[アイムデジタルラボ] |
| サービスメッシュは本当に必要なのか、何を解決するのか | Yasuhiro Tori Hara[Amazon Web Services Japan] |
| オープンソースのこれまでとこれから | 川口 耕介[Launchable] |
| メルペイリリースとその後一年間の裏側と学び | 木村 秀夫[メルペイ] |
| 生涯イチ・エンジニアとして好きな技術でジャンプアップし続けよう - 夢のつづきはビッグデータで | 中川 伸一[JX通信社] |
| クリエイティブとブランディングの関係 | 山口 義宏[インサイトフォース] 枌谷 力[ベイジ] |
16:20～17:05
| タイトル | 発表者 |
|---|---|
| TOYOTA x Serverless x Microservices 〜 グローバル展開のコネクティッドカーを支えるアーキテクチャとエンジニアリングチーム | 浦山 雄也[トヨタ自動車] 松本 崇之[トヨタコネクティッド] 内海 英一郎[アマゾン ウェブ サービス ジャパン] |
| エッジコンピューティングの時代にサーバーはどこにいくのか、自社製品をハッキングしてもらった話 | 及川 信一郎[日本ヒューレット・パッカード] |
| Hackが好きなエンジニアが組織をHackしてみる考えと実践を経てきたヒストリー | 萩原 北斗[うるる] |
| イケてるコードが書けるITコンサル最強説。 知る人ぞ知るエンジニアの楽園。 | 真野 隼記[フューチャー] 澁川 喜規[フューチャー] 塚本 祥太[フューチャー] |
| 月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？ | 仲井 裕紀[FROSK] |
17:25～18:45
| タイトル | 発表者 |
|---|---|
| キャリアトランスフォーメーションをみんなで考えよう～開発者から事業責任者、役員へのキャリアパスはどうよ～ エンジニアの事業継承 自分のハンドルは自分で握れ 偶然の出来事の流れに身を任せエンジニアからマネジメントの道に進んだ話。 |
【司会】岩切 晃子[翔泳社] 石井 智康[石井食品] 市谷 聡啓[ギルドワークス/エナジャイル] 黒田 樹[リクルートテクノロジーズ] |
| 雲の中心で愛を叫ぶ！ クラウド横断パネルディスカッション | 濱田 孝治[クラスメソッド] 松村 優大[オルターブース] 高野 遼[クラウドエース] 【司会】近藤 佑子[翔泳社] |
| IT業界で誰もが輝くために：ダイバーシティを考える 技術書におけるジェンダーと 「わからない」を掘り下げる価値 女性向けテックコミュニティが必要な理由とポイント |
川口 耕介[Launchable] 職業「戸倉彩」/湊川 あい[湊川プロジェクト] |
| 今ものづくりは非エンジニアが面白い！～IoTLT・ProtoOut StudioスピンオフLT | 【司会】菅原 のびすけ/土井 勝之[千葉厚生会] 三木 啓司/小池 誠[小池農園] ななみん/農上 裕子/土田 哲哉[Surface&Architecture] |
| 家族型ロボット「LOVOT」から考えるテクノロジーの裏側とその未来 | 林 要[GROOVE X] |
エンジニアよ、今こそ社会課題に立ち向かおう！
- 関 治之さん[Code for Japan]
Code for Japan
- 「ともに考え、ともにつくる」
- 行政と市民がともに考える
- Civic Tech
社会課題とテクノロジー
伽藍 vs バザール
- 伽藍
- 緻密な計画
- 中央集権
- 長いリリース期間
- バザール
- 変更を受け入れる
- 自律的な小さい集団
- 早めに細かくリリース
- 市区町村などのシステムは伽藍でそれぞれisolate
- 行政の仕組みもバザールモデルの形にできるんじゃないか
- 市区町村同士も連携していけるのでは
- 市民の意見を取り入れていけるのでは
新しいHTML<portal>を利用した画面遷移設計 〜PayPayモールとYahoo!ニュースの事例を添えて〜
- 萩野 誠一さん[ヤフー]
- 関 真由美さん[ヤフー]
Portalsとは
- ページの体感速度が速い方がよい
- アプリのような遷移体験をWebでも実現できる
の特徴
<a> |
<iframe> |
<portal> |
|
|---|---|---|---|
| ページ遷移 | ○ | x | ○ |
| ページを表示 | x | ○ | ○ |
導入事例
- PayPayモール
- 検索ページから商品ページへの遷移にPortalsを使用
- List to Detail
- Yahooニュース
- 記事から記事への遷移にPortalsを使用
- Detail to Detail
Portalsのデザイン
- ページのつながりをシームレスにできる
- Portalsを使えば音声の再生を継続したままページ遷移できる
- iframeではできない
- アプリの設計に似ている
- SPAでなくMPAであってもリッチな体験を提供できる
- 意識しておくといいところ
- プログレッシブエンハンスメント
- グレースフルデグラデーション
- 非対応のブラウザを使ってる人にどう見せるかの考慮も必要
Portalsの実装例
- JSでPortalタグを埋め込む
- 非対応ブラウザのための分岐も入れておく
- アニメーションで全画面化する(この時点ではページ遷移してない)
.activate()を実行するとでページ遷移する- 遷移が完了すると
portalactivateイベントが発火する
- 遷移が完了すると
- portalタグに対して引数も渡すことができる
event.dataで受け取れる
event.adoptPredeccessor().activate()で自分が埋め込まれていたもとのページに戻ることができるwindow.portalHost.postMessage(...)でportalとして埋め込まれたページから埋め込んでいるページにメッセージを送れる- portal内のページのロードが完了してから表示するといった感じで使うといい
Portalsの良い点/悪い点
- 良い点
- MPAでもシームレスな画面遷移が実現できる
- 悪い点
エッジコンピューティング、エッジAIの可能性
- 中村 晃一さん[Idein]
Idein
- 機械学習技術 -> 高い壁 -> プロダクト化/ビジネス化 -> 高い壁 -> ビジネスのスケール
- 高い壁を取り除く会社
エッジコンピューティング
- クラウドコンピューティング
- データがデータセンターに集約されて処理される
- エッジコンピューティング
エッジコンピューティングがなぜ注目されてる？
- データセンター・回線のキャパオーバー
- プライバシーへの関心の高まり
- 超低遅延化の需要増加
データセンター・回線のキャパオーバー
- コネクテッドデバイスの急増
- 今後も増える傾向
- 計算負荷・データ量の大きいアプリの需要増加
- 画像を扱うなど
- DeepLearning
- 必要最小限のメタ情報だけ送信することで通信コスト削減
プライバシーへの関心の高まり
超低遅延化の需要増加
ソフトウェア産業
- インターネットエコシステムが物理的なところまで拡大していく
- 小売、製造業、物流、医療
- 複雑化する計算機システムをうまく扱う技術やプロダクトが登場する
- 既存産業から見ると危機的状況と言えるかもしれない
- ハード -> ソフト・サービス・データ
- 組み込み -> 配信
- 売り切り -> サブスク
Actcast
- Ideinの提供するサービス
- SDK
- 安価なデバイスで高速に動くエッジAIアプリを開発できる
- Dashboard
- 多数のデバイスからなるシステムの運用に必要なものを備える
- Marketplace
- エッジデバイス向けAppStore
SDK
Dashboard
Marketplace
ユースケース
- セキュリティ
- 製造業IoT
- 小売・決済等- スマート氏r費
- デジタルサイネージ
- 受付システム
- インフラ監視
テクノロジーとクリエイティブがコマース体験を変革する
- 河野 貴伸さん[フラクタ]
Eコマース
- 制約が多い？
- O2O,OMOが求められるのであればクリエイティブもオンラインオフラインの結合が求められる
- O2O・・・Online to Offline
- OMO・・・Online Merges Offline
- 実際に体験してもらう
- これらをどう低コストにしていくか
- Eコマース -> コマース
- リアルとデジタル(OfflineとOnline)の境目がなくなってきてる
デザイナーとデータサイエンティストの共創
- データを持ってるのでそれを活用していく
- 1st Partyなデータを持っているのが強い
- データをクリエイティブに活かす
- クリエイティブに説得力を持たせる
クリエイティブリバランス
- ECは作るものが多い
- どこに力を入れてどこの力を抜くか
- テンプレートを使えるものはそれを活用していく
- 商品の360度プレビュー
- ARで配置してサイズ感を確認
シンボリックエクスペリエンス
- 視覚だけでなく音や匂いや手触りなども含む
- Slackの通知の音をきいたらSlackだなってすぐに思える
- 音なども含んだブランド設計
これからのコマース
- 日本だけではジリ貧
- 世界に目を向けないといけない
- 日本のものを世界に売っていく力が足りていない
- デザイナーやエンジニアが持っている知見を投入していくことが必要
サービスメッシュは本当に必要なのか、何を解決するのか
- Yasuhiro Haraさん[Amazon Web Services Japan]
アプリの成長
- 最初は小さなアプリ
- 成長するにつれて大きくなる
- うまく動かないところも出てくる
- 障害が起きると夜中に叩き起こされる人もでてくる
- ある日マイクロサービス化しよう、と言い出したとき既存アプリはモノリスとなる
モノリスとマイクロサービス
- Monolithという呼称に込められるニュアンス
- 関係者調整にオーバーヘッドがある
- 変更による影響範囲が広い
- モジュール構造維持が難しい
- スケーリングが効率的にできない
- テスト・ビルドに要する時間が長い
- マイクロサービスに期待される効果
- 変更による影響範囲の局所化
- モジュール協会の維持しやすさ
- 独立したデプロイとスケーリング
- 自律的なチームによる開発・運用
- Polyglot(-able)
モノリスの考察
- 現実世界のモノリスは複雑
マイクロサービスの考察
- マイクロサービスの課題
- サービス分割の適切な粒度が分からない(正解がない)
- 依存物との連携を考えるとテストが難しい
- 影響範囲を自サービス内に収めるのが難しい(使ってる人が使い続けられる状態での改修)
- サービス間通信の信頼性(Reliability)
- ネットワークを経由して連携するということは失敗することは考えないといけない
- サービス間通信の可観測性(Observability)
- 各サービスでログがはかれるのでシステム全体として何が起きているか把握しづらい
サービス間通信の信頼性(Reliability)
- ネットワーク経由で通信 = 失敗が前提
- => 各サービスで防御的実装が必要
信頼性を高める防御的実装
- 呼び出し先の場所は一定ではないのでダイナミックに場所を特定できるようにしたい
- サービスディスカバリ
- 呼び出し先の都合によって一時的な失敗も起きる
- リトライ
- 障害などで継続した呼び出しの失敗が起きていたらアクセスしないようにしたい
- サーキットブレーカー
- SLOを守るために呼び出し先サービスのパフォーマンスが悪ければ接続を切りたい
- 呼び出し元システムの不具合で失敗するアクセスばかり受けることを防ぎたい
サービス間通信の可観測性(Observability)
- マイクロサービス群は外から見ると1つのシステム
- どこでなぜ失敗したか追えるようにしておかないといけない
可観測性を高める実装
- ログ/メトリクス/トレース情報の出力
- 各サービスで出力フォーマットが不揃いだとコンテキストが見えない
- => 全サービスの出力フォーマットを統一したい
- => 考え方もスキルもフレームワークも違うので難しいし変更コストも高い
- 共通ライブラリを作ってとりこんでもらう？
- アプリに手を入れないといけない
- 共通ライブラリのせいでパフォーマンス劣化
- 言語やフレームワークのバージョンに広く対応する？
- 共通ライブラリのメンテ側も大変
- マイクロサービス化して疎結合な実装で自律的なチームで開発したかった
- 共通ライブラリを作ると結局密結合になってしまう
- => そこでプロキシ
サービスメッシュ
- 全ての通信を通るプロキシを置いてそこで共通的な処理をする
- =>これがサービスメッシュ
- プロキシにサービスディスカバリ、タイムアウト、リトライ、ログ出力など全て入れる
- 各サービスにマイクロサービス用の実装をいれなくてよくなる
- EnvoyProxy
- プロキシとアプリケーションの密結合
- AWS App Mesh
- Envoyがダウンタイムなしで動的に設定変更できる
月間約10億件のクラッシュデータから見えたアプリ品質の実態！ エンジニアが仕掛ける、『ONE TEAMで挑む、賢いアプリの品質管理』とは？
- 仲井 裕紀さん[FROSK]
スマホアプリの品質
- 品質(UX)
- UI/速度/不具合
アプリの不具合
- よくある不具合
- クラッシュ
- UIが崩れる
- かたまる
- 仕様と異なる
- アプリ品質が悪いと継続率に10%影響が出る
- エンジニアだけの問題ではない
アプリのクラッシュ
- 4割以上が週1回以上アプリクラッシュ経験してる
- クラッシュすると
- ユーザが離脱する
- 7割以上の人がクラッシュが原因で使わなくなったことがある
- 長期的な継続率に10%くらい差が出る
- 新規ユーザの獲得率を下げる
- レビュー見てダウンロードやめちゃう
- レビューに「落ちる」を含むアプリ:☆1.9
- 一般的なアプリ:☆3.5
- GooglePlayではクラッシュ数に応じて順位を降格させている
- ユーザが離脱する
- クラッシュを放置することは穴の空いたバケツに水を溜めようとしてるようなもの
なぜクラッシュが起きるのか
- すべての環境でデバッグ/テストできない
- 不具合検知の仕組み
- 正確にエラーを取るのは困難
- 保存しておいて次回起動時に送信とかが多い
- クラッシュしたのに次回起動があるのか？
- クラッシュの対応
- 情報量が少ないと対応しようがない
- 端末依存？
- OS依存？
- 環境が特殊？
- ユーザの勘違い？
- 再現できないとなおせない
- 情報量が少ないと対応しようがない
クラッシュ問題への向き合い方
- 以下のサイクルを回す
- 自社アプリの品質を正確に把握
- クラッシュ率をKPIとして管理
- 影響範囲の大きい不具合から効率的に修正
- 品質問題の影響範囲を最小限に留める工夫
- 週1回くらいのサイクルで回していくといい
- 評価のいいアプリはそれくらいで回してる
自社アプリの品質を正確に把握
- 不具合を「社内で気づく」に
- 日常的に品質をモニタリング
クラッシュ率をKPIとして管理
- レビューとクラッシュ率の相関が見えている
- 落ちるのレビューがないと1.5%くらい
- 落ちるのレビューがあると7%くらい
- 1%以下を目指すと良い
影響範囲の大きい不具合から効率的に修正
- どの不具合から改善するか
- 定量的にどれからやるか決めるよい
- 発生回数など
品質問題の影響範囲を最小限に留める工夫
- レビュー依頼はクラッシュ率の高いときは出さない
- 不具合が分かってるならアナウンスすると低評価を防げる
- 親切心で報告として☆1つけてレビュー書いてくれる人もいる
- エラーの情報とユーザの情報を紐付けて管理
- 改善したことを報告できるように
