強いチームの作り方

吉羽氏 @ryzee

実際のとこor、ソフトウェア開発上の問題の多くは，技術的と言うより社会学的なものである

極端な話、技術的な問題は勉強したりできる人を連れてくれば問題ない

チームの課題と改善

よくある課題

仕事が多すぎて新しい技術やプロセスを試す時間がない
必要なスキルを持った人が足りない
アイデアが出てこない
人が入れ替わる
メンバーのやる気がない

課題を認識してて改善してないのはたちが悪い

改善は着実にやっていかないと行けない
終わりはない

進め方

仕事の流れに注目する
- リリースして使うまでのフローを見る
- 自分の周りだけを見てると部分最適のみが進んでしまう
知恵を使う。
- ツールの話に行きがちだけど、人間のことを考える
最高だと思わないで変わり続ける
イチから全部やろうとしないで他でうまくいってることをパクる
目標を立てる。
- 数字ではかれるようにすることが大事
- 見えないものは改善できない
チームでやる
- 一人でやると心が折れる
- 現場が考えてこうしたらいいと思うものをやる

Learn -> Build -> Measure -> Learn...

フィードバックサイクルは組織運営にも使える

なぜチームが必要か

人が集まっただけではチームにはならない
一人でできないことをするためのチーム
チームでフルスタックになればいい

強いチームは「続けられる」

ビジネス上の結果を出す
変化に対応する
成長を維持する

強いチームの形成

-仕事は単純か？
ばらつきを減らす方向に向かう
しょっちゅう頻繁に新しいやり方を提案することもない
機械化されやすい

ソフトウェアの仕事は複雑
多様性は必要
バックグラウンドは別々のものを持っていた方が良い
性別とか国籍以上の広い意味の多様性

複雑な問題の解決を目指す
多角的な視点が必要
フィードバックによる修正

多様性がないと？

文句が外に向けるだけ
うまくいってないことを他の人やツールの製にする
思考停止して諦める
モチベーションが下がり辞める人もでてくる

チーム形成のステージ

タックマンモデル

形成期
- コミュニケーション少ない
混乱期
- 自分と違う意見を言われるとムッとしちゃう
統一期
機能期
解散期
- 当初上の4つだったけど後からこれが増えた

時間がかかるのに最後解散するのがすごいムダ

初期段階で必要なことは何か？

合意とアコモデーション

ゴール
- 最終的に実現すること
目標
- 短期的
価値観

いきなりはできない
まずは

相手のことをよく知ろうとする
現時点で合意できないことを合意する
検討を一緒に継続することを合意する

初期の段階であるほど必要になる
いきなりリーダーシップ発揮してやるのは難しい

amazonのリーダーシップの原則
社員全員がリーダー
違うと思ったら言え

多数決の罠

知らない人同士で多数決でやることはリスキー

五本指で意見を聞く

0本決定を行うこと自体反対
1本重大な問題がある
2本問題があるから元話し合いたい
3本よいとは思わないけど賛成 → 大体これになる

プランニングポーカー
フィードバックを行わないと共通理解は得られない。
YES/NOだけでは全然足りない

チームの責任

説明責任
- チーム全員が説明できるように
改善責任
- 完成責任は言ってもできないことがある

チームのルール

うまくやろうとすると障害になることもある
盲目的にルールだからと思考停止しない
糸川からないもの、形骸化してるものがある
不要なものは廃棄するよう働きかける
ルールにないものを「やってはいけない」わけではない
- ないから「やってもいい」と考えるか「やってはいけない」と考えるか
- どう考えるかはけっこう重要

硬い会社は脊髄反射的にルールでやれませんって言うんじゃなく、
それに対するこうしたらいけるんじゃないかを考える

マネージャーがルールだからといってそれをはねつけるんならマネージャーとしての職責を果たしていない

チームのスキル育成

スキル表を作って、1週間とか1ヶ月とかで随時更新する
注意するのは、これを人事評価に使ってはいけない

そういうことし始めると、◎つけはじめる

個人としてどうスキルアップ？

個人の価値観の問題
変化しないは自分が生きるか死ぬかを人に委ねること
会社が守ってくれるわけじゃない

変われない理由
過去の成功体験に縛られる、未来は怖い。だから変わりたくない

チームの単一障害点

ある人がいなかったらどうなる？
夜も眠れない問題
リーダーが倒れたらプロジェクトは終了してしまうとかは何かおかしい

チーム作っていくと外からプッシュしないとうまくいかない？

SL理論

チームの成熟度によってマネジメントの方法が変わる

S1 指示型リーダーが決める
S2 説得型意見を言う
S3 参加型ファシリーテーションしてあげる
S4 委任型任せる

権限委譲の7段階マネジメント3.0
いきなり全てを任せるって言うのはタダの丸投げ
どこは任せるとかそういうのを合意するのが大事

チームメンバーの入れ替え

半数を入れ替えると大変
4分の1くらい

チームメンバーの採用

一緒に働くことになる人が採用の判断をする
たった数回のインタビューではお互いのことは分からない
その人に対する期待することは明確にしとく
文化の適合性も判断基準にいれる
- チームがぶっ壊れたらしょうがない
チームの平均より上であることを基準で入れるといいかんじ
優秀な人の知り合いは大体優秀

退職

やめる理由は生々しく聞いた方がいい。
同じ理由で退職することを防げる可能性

コンウェイの法則

組織構造はアーキテクチャに影響を与える
例えばマイクロサービスは組織構造に合ってないとできない

チームの外側を見る必要性

チームの中だけを見ててもしょうがない場合も

速いサイクルで開発してても、デプロイが決まった日にしかできないとOpsがボトルネックになる

チームのコミュニケーション

なぜコミュニケーションが必要か？
コミュニケーションはHow
目的ではなく手段

基本モデル

何かを伝えたからと言って行動が起きるとは限らない
伝えるだけ伝えるのはあまり意味ない。
その後行動になって初めてコミュニケーション成立

伝える側が伝えられる側に行動するまで伝えないといけない

同期型コミュニケーション

障害対策会議
振り返り
何かを中断しないといけない問題

非同期型コミュニケーション

割り込みになりにくい
相手が増えると手間と時間が増える
伝わったかどうか顔色が分からない

どういうものをどっちのコミュニケーションでやるかは考えた方が良い

会議

会議の目的は明らかか
チームが生産性を維持するためには減らしていった方が良い

時間の4分の1以上が会議に費やされているならば、組織構造に欠陥があるとみてよい

外部とのコミュニケーション

コンテキストが共有されていないことを前提にする
自分たちのやり方を見えるようにする
- 見えるようにしてそれにのってもらう

必ずしもリアルコミュニケーションをリアルコミュニケーションである必要はない
Amazonはサーバー調達をAPIに置き換えた

評価とフィードバック

価値観・優先度・期待値・求める成果を先に合意して後出しを避ける
公平/公正であること
定量評価と定性評価の組み合わせ。
- 数字だけで判断するとちょろまかすやつ出てくる。おれはやる。
評価すること自体が目的じゃない
- キミはどんな仕事してるんだっけ？って上司がいったらそれはおかしい
ピアレビュー 1週間に1回30分

フィードバックの方法

もっと頻繁にやる
アジャイルなら振り返りの中で
ネガティブなフィードバックも必要
個人攻撃ではないので
密室でやらない
問題 vs わたし
I messageを使う
- × お前の書いた仕様書はクソだ
- ○ 私にはお前の書いた仕様書が分からんから説明してくれ

ニューラルネットワークによる近未来の画像認識技術を体験し、IoTの知られざるパワーを知る

Oracle 中島氏

100％ライブデモでした
ニューラルネットワークと画像認識技術、IoTの話
http://www.slideshare.net/nkjm/iot-58447760

ニューラルネットワーク

マシンラーニング-> ニューラルネットワーク -> でぃーぷらーにんぐ
よくある図は正直分からんｗ

これでできるようになる面白いこと

画像認識

自動運転で物体認識は画像認識によるもの

今回はニューラルネットワークを使った画像認識はどの程度の精度になるか

キーになるライブラリ

TensorFlow
ImageNet
- TEDのプレゼンで一躍有名になった
- スタンフォード大学のフェイフェイ/リーさんの講演
- このビデオめっちゃわかりやすい
- これで何ができるのか、今まで何が難しかったのかが説明されてる
NeauralTalk2
- けっこう面白い

TensorFlow +　ImageNetを組み合わせて使ってみる

暖炉と薪ストーブは違うらしいｗ

IoTの知られざるパワー

ニューラルネットワークとIoTがどうつながるのか

防犯カメラ＋機械学習
画像は検索できないけど、画像を自然言語に落とし込んでおけば検索ができる

画像解析→データベースに格納→異常検出モデルで検知

カメラ
REST API (Node.js + TensorFlow)
REST API (Oracle Database Cloud + 機械学習の機能)

Oracle SQL Developer

新規ワークフローで機械学習の作業スペースを作成
分析対象のテーブルを指定
異常検出
適用で結果を出す

データベースに機能が組み込まれているので、新しく入ってきたデータをリアルタイムに解析できる
SQLでそのまま取れる

PREDICTION 関数が使える

Oracle Database Cloud

機械学習機能がついてる

Oracle Cluod Deelopers
第2回 Meetup 3/4

常時SSL/TLS化の実装ポイント

常時SSl/TLSとは

通信相手が本物ではない可能性
フィッシングサイト？
なりすまし、盗聴のリスク
相手が誰か分からない、顔が見えない
↓
インターネットの弱点

本物がやってるかどうかを確認する手段＝証明書

HTTPSですね。

Webサイトを全部HTTPS化する
TLSはSSLの進化版
利点
- 中間者攻撃から盗聴/なりすましを防ぐ
- ウェブアプリ開発の効率が高まる
- SEOの優遇
- Webサイトの信頼性が高まる

必要なのか？

銀行やECサイトでもないのにそこまでする必要があるのか？
クレジットカード、パスワードを入力させていない、個人情報を扱っていない
静的ページのみだ

規模にかかわらずWebサイトへの攻撃は起きている
大手サイトは強固なため、中小サイトを狙ってそこから大手をハッキングとかしてくる

賽は投げられた

HTTPS化が急増中
インターネットの全トラフィックの20%がHTTPS
アメリカの3割くらいのサイトがHTTPS化してる

HTTPS化の流れは確実に来ている

HTTPSトラフィックの歩み

フォームのみ
常時SSL/TLSの増加
全HTTPS時代

Googleの取り組み

SSL/TLSはSEO順位の向上要素の一つ
Google検索サイトを常時SSL/TLS化
ChromeでSSLにするのを検討中

Mozilla

FirefoxはHTTP/2サイトの向上
Let's EncryptでSSL/TLSの裾野を広げる
DV認証レベルの証明書
FirefoxでHTTP接続の警告対応実装

オーバーヘッドは

体感速度に影響するのでは？
2000年代前半は遅いという体感が会ったけど、今は別にない
HTTP/2の登場でスピードは向上した

課題

SSL証明書の費用
- Let's Encrypt
- DVレベルならわりと安い
サイトアクセス遅延
- マルチコアCPUの普及
- ハードウェアの進化で大幅に低減
証明書管理負荷の増大
- 一元管理するソリューションの提供
IPv4 アドレスの不足
- テクノロジーの進歩でカバー
暗号化で十分か？

今できること

いきなりSSL化するのは難しい
ノウハウを貯める目的でリニューアルなどのタイミングで検討してみては

SSL/TLSの実装方法

正しいコンテンツを作る

ソースの記述
- 相対パスにするとか
ビーコンタグの利用
- なるべく同じドメイン、サブドメインのサーバーに置く
- ネゴシエーションの負荷を軽減

混在エラーを回避するための注意点

http://とかフルパスで出力しないようにしましょう
Cookieにセキュア属性を付けましょう
- HTTPではCookieを読み込ませない
HTTPSへの転送設定をしましょう
印刷物にはhttps://で記載する

Cookieにセキュア属性を付けなかった場合
→完全SSL化されてるからと言って、安心ではない。
偽のアクセスポイントを使って経由させられると、Cookieが漏れる。

証明書の選び方

信頼できる認証局の証明書を選ぶ
長く使えば使うほど、認証局のサーバーの信頼性は重要

世界最高水準の運用体制

認証レベルに応じた証明書を選ぶ

EV
- OVの拡張
OV
DV
- 用途が限定的
- ドメインのみ

注意すべきサーバー設定

セキュリティ強化

再ネゴシエーションの禁止
DDoS攻撃に利用される
HSTS

ネゴシエーションの負荷を下げる設定

OCSPステープリング
Certufucate Tranparency すかしみたいなもん

さらなる強化

Public Key Pinning
適切なCipher Suite
- RC4の禁止
- SSL3.0

プロトコルバージョンの安全性の違い

SSLと呼ばれてる物は使うべきじゃない
TLS1.0以下はクレジットカードなどの決済で使うなとアナウンスされている
IPAのガイダンスを参考にするべし

なぜ

今やる理由

プリミティブなもの
- 暗号化、サーバー認証
- 改ざん検知
デファクトスタンダード
- HTTPが古いもの
- 検索エンジンの順位付け

自動運転を支える技術

DeNA 八代氏
ロボットタクシー株式会社サービス開発部

自動運転技術について浅く広く紹介

自動運転を取り巻く環境

技術
- あらゆる道路環境を走れるまでには至ってない
- 限定エリアでのサービス
法規制
- 運転者の存在を規定
- 法規制の改訂の動き
社会受容性
- 新しい技術に対する安全性への不安
- 人間より安全であることをアピール

自動運転の実現は移動サービスから？

想定しているサービス

オンデマンド
- 乗りたいときには医者
- 予約、決済前完結したサービス
無人運転
エリア限定
- 限定することで問題を解決しやすく

これまで

官民対話

2020年オリンピックでの無人自動走行を実現する
今は藤沢市で実証実験中

ロボットタクシーの周辺技術

サービス
- アプリ
- 運用システム
自動運転技術
- センサー
- 人工知能

自動運転とは？

人がやってる運転をロボットにやらせる

認知
- Localization
- Static Object Detection
- DATMO
判断
制御
- アクセル
- ブレーキ
- ステアリング

自動運転のレベル定義
NHTSA

最終的にはレベル4を目指す
ロボットタクシーが実現するのは無人のレベル4

構成技術

Localization:Sensing

GPS
- RTK-GPS通常のGPSと違う
- 補正情報を使って数cm単位での精度が出る
IMU
- 加速度と角速度を取得
- 慣性航法に用いるセンサー

Localization:Matching

Map Matching
Lane Matching
- 道路のどのレーンにいるかがわからないので、白線を検知して自己位置を推定する

自己位置の特定

Localization:Particle Filter

予測
重み付け
離サンプリング

Object Detection: Deep Learning

現在はオブジェクト検出に利用
次はアクション検出

もう一つの自動運転を支える技術

V2X

三位一体で自動化で壊せDevとOpsの壁

楽天荻野氏、古川氏

DevとOpsの越えられない壁
DevとOpsの壁を5年くらいかけて壊した話

コンウェイの法則

レイヤを共通化してそれぞれのレイヤにチームがある状態
悪いことばっかりじゃない
インフラの専門家、DBの専門家になったりできる

スピード感を阻害

自動化によって壊した話

Fearless Change
ちょっとしたテクニックとかを紹介した本

Fearless Change side dev

サーチプラットフォーム開発
開発/テスト/運用全てやってた
この頃の経験が今の糧になっている

自分自身でバグをたくさん作ってバグやだなって思うようになった

2013 Fearless Changeの始まり

課題
テストの再現性に問題がある

何をしたか？
Vagrantを使ってクリーン環境でテストするようにした
部署の勉強会で提案した

勉強会やってくにあたり、XP祭り、DevLoveとかも参加してタネマキした
本業以外の学習

仲間ができた

2014 個人の価値から組織の価値へ

外部のお墨付き
外部のセミナーなどで発表

社内勉強会に著名人を招いて話をしてもらったりしてた

挫折

挫折の内容

組織的な評価
勉強会のROI
- いくらがんばっても良いことないな…
- それだけじゃ給料は上がらない

考えた

ヘッドハンターに相談
人事や執行役員に相談
- 自分の組織を作れと怒られる
勉強会コミュニティに相談
- 勉強会は準備ができていることが大事
- すぐに役に立つかどうかは重要じゃない

結論
部署異動

部署異動

正式な自動化担当部署に

2015 チーム作り

テストエンジニアを舐めてる！？
テストなんて誰でもできる→バグなんて誰でもできるｗ

Fearless Change side ops

楽天のインフラ

プライベートクラウド上で稼働
サーバー台数3万
管理する部署400以上
サーバープロビジョニング専門グループに所属

楽天プライベートクラウドの歴史

2010 Xen Project
- スケールさせるのが難しい
2012 VMWare
- 絶賛稼働中
2015 OpenStack
- 次期プラットフォーム

2010-2012

物理サーバーのプロビジョニングが主流だった
手順書によるマニュアル作業
コピペスキルが身についたｗ

構成管理ツールを導入した
ここからがFearless Changeの始まり

構成管理ツールの提案
Chef Soloでスモールスタート
Chefは敷居が高い

→ 定型作業にかかる工数が低減！

2013-2014

社内勉強会開いた
他部署にも展開していこう

Chefに対して懐疑的な意見を持つ人が
エンジニアが受け身な文化

→あまり浸透しなかった

2014-2015

Chefでカバーできない部分のコード化
Chef以外の構成管理ツールの導入
Devとのコラボレーション

自作しようと思ってた所にTerraformが現れた

Chef → サーバーの内側の設定
Terraform → DNSの設定とか外側の設定
一つのリポジトリで管理するのが大事

抽象化されたコードは組織の壁を越える

Fearless Change DevOps

組織がDevOpsな文化になるために

トップの戦略、意思決定は重要
かといってすぐに変わるかは違う
現場の準備ができていることが重要
→アラサーエンジニアパターン

それぞれのチームで成果を出す
信頼貯金がたまる
シニアな人達はマネジメント業務に忙殺されている
現場に入って組織を変えていくのは難しい

そういうことができるのがアラサーエンジニア

Dolphin プロジェクト
Dev, Ops, Testが一体になったプロジェクト

テスト、運用をソフトウェア開発の手法を使えるようにして管理していく

パターン指向自動化
専門性を活かし標準パターンを作成

セルフサービス

自動化できないところは何かを考えた

予算の承認
サーバー構成情報のレビュー

どうしても人間がやらなきゃいけない部分をトリガーにした

DevOpsの責任は変えてない。
プロセスのみを変えた。

若い人達は自動化するのに抵抗がない
パブリッククラウドネイティブな感じ

アラサーエンジニアこそが組織を変えるチャンス！！

Webエンジニアのための並行/非同期プログラミング

ピクシブ川田氏
メルカリ久保氏 Go
DeNA 古川氏 Node.js
ビズリーチ竹添氏 Scala

昔話はしません。
昨今Concurrency系の影響を受けた言語が多い

言語が生まれた背景

Go言語

C++とかJavaがありました
機能を絞った方が良いという要望があった
Genericsがないとか色々言われるけど、並行処理のための機能がある
Cとかでコマンドラインツール作ろうとするとツラい
Cでやろうとしてることを80%くらいカバーしてくれる
21世紀のC言語
ミドルウェアとかオペレーションとかに持って来いな言語
インフラとかにも使える
1バイナリというのはいい！

Node.js

Webアプリケーションよりに作られた言語・仕組み
C10K問題がありまして
1万プロセス、スレッドを立ち上げたら1台のサーバーだとヤバイ問題
時間のかかる処理は非同期にしたい
たくさん接続があっても処理効率がいいのがNode.js
言語自体はJavascript
フロントエンドの人が比較的参入しやすく設計された言語

Scala

Scala自体はJVM上で動く
Javaみたいなオブジェクト指向の言語に関数型言語をミックスしたもの
研究用ではなく実用で使えるように設計されたもの
Erlangのアクターモデルとかもライブラリとして提供
領域としてはJavaがになっている箇所を丸ごと置き換え可能な言語
Scala.jsという闇のプロダクト…

そもそも並行処理って？

並行処理、並列処理は混同しやすい

Go, Scalaの並列処理とNode.jsの並行処理は実は違うよ
Node.jsは一番奥の部分はJavascriptだからシングルスレッドで動いてる。
デッドロックとかマルチスレッド環境でおきそうな問題は起きない
メリットがあるかどうかと言えば、そんなにない？
Goの方がたぶん早い

Goは複数のCPUコアを使えるようにしてる
1.5からデフォルトで指定できるようになった
そのスケジューリングはGoのランタイムがやってくれる

並列…Parallel
並行…Concurrent

ブラウザの話
WebWorkerは低レイヤの話なので1Webエンジニアがやるのは厳しいんじゃ
UIスレッドは多くのOSでは1つしかない
それをうまいこと扱うために生まれてきた
UI作ること前提の人達にはなじみがない
今流行ってるReactとかはUIの話
Javascript業界的にはあんまり並列・並行処理に向かってない

ScalaはJavaのJVMの上で動いてるので、その上の話
マルチスレッドとノンブロッキングIOの組み合わせで動く
うまいことやってくれるのがAkka。
アクターモデル。
マルチコアなマシンリソースをうまく使い切ること

現場で使ってみたメリット

改善されてよかったメリットは？

Go

スマホアプリの通知
通知サーバーはけっこう遠い場所に通信する
けっこうな数がある。
複数通知を非同期で行いたい
アプリケーション側で通知までやっちゃうとブロッキングが遅れてしまう
前はキューに入れてさらに縁キューするPHPがいて送ってた
あんまスピードが出なかった
Goで書いたサーバーにプッシュ通知させた

中央集権なAPIがありまして
複数のAPIを呼び出さないといけないので、Goで作ったプロキシサーバーで
複数API呼び出しを並列にやって最後に一個のレスポンスで返してる
Node.jsの得意な分野でもある

Node.js

Socket.ioというライブラリがあって、わりとつかってる
リアルタイムに通知を送ったりできる
限定的な使い方が多い
Webとつながるような形で使ってる

ChatOpsとかのBotに使ってる

ミドルウェアとして使うって言うのは聞かない
逆にやめてくださいｗ

AWSのLambda
登録しておいた関数を実行してくれる
データ駆動で動くサービスがNode.jsで動かせる
使いどころはたくさんある

全部非同期だからトランザクションとかやるの超厳しい
コールバック書いてたら地獄になるからPromiseとか使う

Scala

ノンブロッキングIOな処理
APIでパフォーマンス出したいときにScala使ってる
外部につなぎに行くところで並列・並行処理に使われる
JDBCがブロッキングインターフェースなのでそこがネック

これから

Go

非同期処理とかノンブロッキングIOは難しい
実はノンブロッキングでやりたいことってWebアプリケーションでは少ない
少ないけどやっぱやりたいときはある
結果は待たなくて良いけど処理をしたい
少ないリソースで大量の処理を捌けるようにする
パターンとしてはフレームワークとかで隠蔽する。
アプリケーションは気にしなくていいようにしたい

Node.js

終わったら呼ばれる処理の登録っていうのが今までやられてた
すげー複雑になる
今はPromiseがある
非同期処理を統一的に扱うオブジェクト
その先は？
ES2016,17
Async Await
直列に書いてるのとほぼ変わらないような感じで書けるようになる
2018年くらいかな
C#から入ってきてる
連続して処理をしたいとき
ダブルクリックとか、キーボードイベント
連続したデータを扱いたいときはAsync Awaitはまだそこまでいけてない
Streamっていうのがある

Node.jsのいいところは全てノンブロッキング処理
他の言語でノンブロッキング処理にしたら他のライブラリもやるのはすげー大変
最初からノンブロッキングだからNode.jsはいい

非同期処理の入門にはピッタリ

Node.jsの格言
「同期処理の中に非同期処理するな、非同期処理の中で同期処理するな」
バグの温床になる

Scala

Webアプリケーションはノンブロッキング処理が欲しい
ファイルに読んだり書いたり、DBに書いたり
ほとんどIO
ここら辺はノンブロッキングでやりたい
今だと、プログラム書く人が意識して使い分ける必要がある。
それはちょっと難しい
プログラム書く人が意識せずにできるようになると理想的だなあ

アプリケーションレイヤのエンジニアの数は多い
そこに非同期処理のコードを入れちゃうとメンテできなくなってしまう
低レイヤで吸収したい

ノンブロッキング処理を書いてると自分の頭の中でステートを考えながら書くけど、複数人でやったらほぼ破綻する

人にはどう伝えれば良い？

やりたいことの性質による

イベント駆動だったらまあわかりやすい
サーバー処理とかどういうガッツリしたロジックを書くのはツラい
慣れるしかない

非同期にやりたいときはこう書いてね、みたいな感じで伝える
受け側はおまじないみたいに捉えてるかもしれない
意識しないでできるようになるのがやっぱ理想

Scalaは外部接続するようなものは基本的にはFutureで返すようにしてる
トレーニングしてる
書いてる人に浸透してるかどうかは自信ない

プロダクトの開発以外のことは全部やる
インフラもやるし、セキュリティもやるし、技術的に難しいところも肩代わりしたりする

まとめ

非同期処理とかは複数人で開発するのは大変
これからは低レイヤでやれるようになるか
アプリレイヤで全部がんばろうとすると時間がかかりすぎてしまう
基盤周りで使う物
実装で気にしなくていいとは言え、PromiseやらFutureやらそういう仕組みの話は知っておいた方が良い。
ここに来てる人達くらいは知っておいて欲しい！

避けては通れないよ
CPUはコアが増えていく方向に進化していくんだから、リソースを使うためには必要なこと
プログラマには必要になってくる

質問タイム：非同期処理してて困ったこと

例外処理が厳しいんだけど、どうします？
例外がないセカイ→Go

Promise使えばOK。catchに例外処理を集中させる
Async Awaitの時代になれば、try-catchで取れるようになる
嬉しい世界になると思う！
ある程度解決できるんじゃないかな

Scalaも例外が出る
基本的に悪
結果をきちんと返す
Futureだったら値を2個返せるから使う
それでも起きる例外はまるっとcatchする
例外をどう処理するではなく、例外を使わない方向を目指す