2021-11-08

「JAWS-UG朝会 #27」 #jawsug_asa 受講メモ

AWS 勉強会

JAWS-UG朝会 #27

jawsug-asa.connpass.com

今回は月初めだったので、前回から結構すぐの開催ですね。

セッション

セッション① ノンプログラマーがAmazon Honeycodeでアプリを作ってみた

emiさん

speakerdeck.com

Honeycode

ノーコードでアプリが構築できる
1年半β版のまま
オレゴンリージョンのみ

Honeycode アカウント準備

https://builder.honeycode.aws/
AWS とは別に専用アカウント作成が必要
メールだけで作れる

Honeycode 主要概念

Table
- 構造型データストア
- csv/tsv, スプレッドシートからコピー
Builder
- アプリ開発ツール
- ボタンやリストを配置することでノーコードでアプリを作成できる
Automations
- アプリ操作を起点に実行
Workbook
- Table/Builder/Automations を包括する枠組み

外部連携

API
- Table データの CRUD ができる
AppFlow
- S3 との連携
Webhook

セッション② マルチアカウントでhealth情報を集約した

富松広太さん

aws health organizations notifications from kota tomimatsu

AWS からのメール

めっちゃくる、見逃すと困るのもある
24時間以内に対応してという依頼がきた
- 不正利用関連など

AWS Health

Personal Health Dashboard で AWS からの通知を確認できる
- ここから通知したい
EventBridge(push)
- PG記述量少ない、全アカウント全リージョンに配置が必要
- 子から親アカウントに push
Health + Organization(pull)
- 子アカウントでリソース作成不要、Bussiness以上のサポートプラン必要
- 親から子アカウントを pull
- API
  - describe-events-for-organization
    - 全 event を取得
    - Health の EventArn を取得
  - describe-affected-accounts-for-organization
    - event に関連する AWS アカウントを取得
  - describe-affected-entities-for-organization
    - event に関連する AWS リソースを取得
  - describe-event-details-for-organization
    - 上記で取得できない項目を取得したい場合

緊急度を高めとく EventTypeCode

AWS_ABUSE_XXX: 不正利用
AWS_CLOUDWATCH_XXX: CloudWatch 死ぬと監視できない
AWS_SES_XXX: SES 止める関連
AWSサービス名OPERATIONAL_ISSUE: サービス障害

LT① QuickSIghtでCUR分析

アイディーエス小寺加奈子さん

Jawsug asakai27 kanako_kodera from Kanako Kodera

CUR とは

コストと使用状況を包括なデータとして確認できるレポート
csv などで S3/Ahtena/Redshift に出力可能
月次、日次、毎時作成可能

可視化方法

Cost & Usage Reports
- 「AWS のコストと使用状況レポート」(CUR) を S3 へ出力するように設定
  - QuickSight で可視化できる

LT② Control TowerとSIEM on OSSであっちこっちした件

小林未来さん

Control towerとsie monossであっちこっちした件 from ssuser868e2d

www.slideshare.net

ログを追うのが大変
- セキュリティはちゃんとしたい
- SIEM on OSS 使ってみる
  - AWS が OSS で公開している脅威検知の可視化ツール
  - Lambda で ETL して可視化できる

LT③ AWS SSOでもアカウントエイリアスを表示したい！に応えるChrome拡張を作りました

小笠原寛明さん

docs.google.com

作成した Chrome 拡張機能はこちら。

chrome.google.com

Switch ロールの履歴少ない問題を解決する拡張機能も便利。

chrome.google.com

所感

今回は使ったこと無いサービスだらけでした。
マルチアカウント普通に使ってる人多いですね。 Control Tower とかちょっとだけ触るとかしにくいからチャレンジできてません。
QuickSight は使えるようになりたいなぁ。

2021-11-01

「AWSの基礎を学ぼう第六十五回 Amazon Lightsail」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

AWS の VPS となる Amazon Lightsail です。

セッション

Amazon Lightsail

講師：アマゾンウェブサービスジャパン、シニアエバンジェリスト亀田氏

シンプルな Web サイト運営に必要な機能を全て提供

VPS
SSD のブロックストレージ
Snapshots 機能
- EC2 へ復元、移行可能

わかりやすい定額な利用プラン

1TB の下り通信量金も含まれているから非常に安い
- EC2 なら1TBは 16,000円ぐらいかかる通信料
- EC2 は1GBまで無料
DNS は 300万クエリまで無料
- EC2 は 10億クエリまで無料

OSとアプリテンプレート

OS: AmazonLinux, Ubuntu, Windows...
アプリ: Wordpress, Drupal...
スタック: Node.js, GitLab, LAMP, Nginx...

データベースバンドル

MySQL, PostgreSQL
必要に応じて RDS 使う

ネットワーキング

静的IP（EIPではない）
ロードバランサー
- http がデフォルト
CDN
- 静的IP設定必要
DNS

コンテナ起動可能

App Runner のほうがコンテナドリブン（CI/CDとか）が充実している
通信料を気にするなら Lightsail が有利

専用 VPC 内で起動する

Lambda と同じ
default VPC に対してピアリングできる
- VPC Endpoint で S3 に接続するとプライベートで閉じることができる
- この構成で Lightsail 経由で S3 ファイルを落とすと1TB無料金額で落とせる
  - ただし回線は細い

所感

Lightsail はわかりやすくていいですよね。
テストしたいときに使ったり、海外からのアクセスをしたいときに立ててそこ経由で試したりつかったりしてました。

2021-10-28

「JAWS-UG朝会 #26」 #jawsug_asa 登壇＆受講メモ

AWS 勉強会

JAWS-UG朝会 #26

jawsug-asa.connpass.com

前回の朝会のまとめブログで

この辺りは、色んな意見を聴いてみたいから、次回登壇しようかなと深く考えずに申し込んでみる。

と書いたとおり、今回は登壇しました。

セッション

セッション① AWSソリューションのCFnで学ぶNaC

NTTデータ山本泰士さん

NaC: Network as Code
TransitVPC: VPC やオンプレミス間を中継する Hub ネットワーク
- VGW のタグ名で自動接続
TransitVPC の CloudFormation
- Parameters: デフォルトで動くがパラメータを自由に設定できるように
  - スタックごとに設定できるので重複にはケアが必要
  - VGW のタグ名などは重複しないように変えてもらう
- Resource: 中継機能や SpokeVPC 自動接続化機能を具備するコンポーネント
  - カスタムリソース + Lambda で柔軟に
カスタムリソース: 関連付けた Lambda 等を呼び出し、自由度の高いロジックを実装可能
TransitVPC のカスタムリソース
- S3へのパラメータ格納をトリガーとして Lambda 起動
- RSA キーの作成
失敗談
- AWS Marketplace の AMI が更新されていた
  - ステージ環境時には成功してたのに本番で失敗

セッション② AWS IoTのスゴいところご紹介

アイレット株式会社本間崇平さん

AWS IoT: IoT デバイスを AWS と接続するサービス
- 例）ドローンとアプリが AWS IoT に接続し MQTT 通信を確立
デバイス通信プロトコルメッセージブローカー
- MQTT
  - 制約のあるデバイス向けの軽量メッセージプロトコル
- MQTT over WSS
- HTTPS
- LoRaWAN
メッセージブローカー
- AWS IoT はメッセージブローカーを通じてデバイス通信を管理
モノの管理
- IoT のモノとは、クラウド内部の物理デバイスの表現と記録
すごいところ
- 証明書とポリシー
  - モノから特定のトピックだけ PubSub 接続を可能にしたり制御できる
- ルールアクション
  - ルールがトリガーされたときに行う動作を指定可能
- FleetProvisioning
  - デバイスに必要なリソースを記述したテンプレートを使用してデバイスのプロビジョニング可能
- DeviceShadow
  - デバイスやアプリのデータをクラウドで共有するためのデータストア
    - デバイスの状態に関係ない

LT① 辛くない CloudFormation

株式会社モリサワ小室貴史

speakerdeck.com

個人的に本日のベストアクト#jawsug_asa #jawsug pic.twitter.com/rzlTdstJbe
— hisa_u (@hisa_u) 2021年10月27日

ベストアクトに選んでいただきありがたいです！

LT② Quick Sight Qを使ってみよう

アイディーエス　小寺加奈子さん

20211028_jaws_ug_asa_26_LT2 from Kanako Kodera

www.slideshare.net

QuickSight Q
- QuickSight を自然言語応答ができる機能
- 英語のみ対応

LT③ EC2の起動テンプレートをAWS CLIで作ってみた

藤田直幸さん

speakerdeck.com

起動テンプレート： EC2インスタンスを起動するための設定情報
ユーザーデータ
- CLI だと base64 エンコードが必要
  - 改行を取り除く必要あり
- GUI だと見やすいように base64 デコードしていると記載されている
GUI と CLI で両方で確認すると納得

所感

「CloudFormation も上手く使えば、再利用性もあがるし便利だよ」ということを話したくて登壇しました。
自分があまりしてないのでアレですが、便利で小さめなテンプレートを共有して使い回すといいんだろうなとは思います。
CloudFormation テンプレートも、PG を書くのと同じく小さい単位で見通しよくするととても便利に使えます！

2021-10-25

Lambda で Go の S3 イベント駆動を試す

小ネタ Go AWS

Lambda で Go のめっちゃ基礎の続きです。
S3 イベントでファイル取得して、別 S3 に出力してみます。

GitHub

github.com

この README のサンプルを参考に実装。

開発環境

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.15.7
BuildVersion:   19H1419

$ go version
go version go1.17 darwin/amd64

Lambda にトリガーを追加

Lambda 関数の「関数の概要」で S3 イベント駆動で動かすためにトリガーを追加。

f:id:omron:20211025102128p:plain

トリガー元のバケットを指定して保存。

f:id:omron:20211025102239p:plain

トリガー元バケットに Lambda からの参照を許可

トリガー元のバケットの「アクセス許可」から

f:id:omron:20211025102453p:plain

バケットポリシーを設定。

f:id:omron:20211025103156p:plain

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::AWSアカウントID:role/service-role/Lambdaの実行ロール"
            },
            "Action": [
                "s3:GetObject",
                "s3:GetObjectAcl"
            ],
            "Resource": "arn:aws:s3:::インプットバケット名/*"
        }
    ]
}

Lambda の実行ロールは、Lambda 関数の「設定」から参照できるので、この ARN を設定する。

f:id:omron:20211025103417p:plain

出力先バケットに Lambda からの保存を許可

出力先バケットにも同様にバケットポリシーを設定。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::AWSアカウントID:role/service-role/Lambdaの実行ロール"
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::アウトプットバケット名/*"
        }
    ]
}

これで、AWS 側の準備は整いました。

Lambda の実装

エラー処理などは考えずに、取りあえず動くだけの実装。

// main.go
package main

import (
    "bytes"
    "context"
    "io/ioutil"
    "log"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"

    "github.com/aws/aws-sdk-go/aws"
    "github.com/aws/aws-sdk-go/aws/session"
    "github.com/aws/aws-sdk-go/service/s3"
)

// 出力バケット
const S3Output = "出力バケット名"

// https://github.com/aws/aws-lambda-go/blob/main/events/README_S3.md を参考
func handler(ctx context.Context, s3Event events.S3Event) {
    // セッション獲得
    sess := session.Must(session.NewSession())
    // S3 clientを作成
    svc := s3.New(sess)

    for _, record := range s3Event.Records {
        s3rec := record.S3
        log.Printf("[%s - %s] Bucket = %s, Key = %s \n", record.EventSource, record.EventTime, s3rec.Bucket.Name, s3rec.Object.Key)

        // オブジェクト取得
        obj, err := svc.GetObject(&s3.GetObjectInput{
            Bucket: aws.String(s3rec.Bucket.Name),
            Key:    aws.String(s3rec.Object.Key),
        })
        if err != nil {
            log.Fatal(err)
        }

        // オブジェクト読み込み
        rc := obj.Body
        defer rc.Close()
        content, err := ioutil.ReadAll(rc)
        if err != nil {
            log.Fatal(err)
        }

        // オブジェクト書き込み
        _, err = svc.PutObject(&s3.PutObjectInput{
            Body:   bytes.NewReader(content),
            Bucket: aws.String(S3Output), // バケットは適宜変更
            Key:    aws.String(s3rec.Object.Key),
        })
        if err != nil {
            log.Fatal(err)
        }
    }

}

func main() {
    // Make the handler available for Remote Procedure Call by AWS Lambda
    lambda.Start(handler)
}

試す

ビルドして Lambda にアップロードして、

$ go mod init sample
$ go get
$ GOOS=linux GOARCH=amd64 go build -o main main.go
$ zip main.zip main

インプット側の S3 に何かファイルを置けば、コピーがアウトプット側のS3 に出力されるはず。

ソース

github.com

さいごに

Lambda で Go は、後から追加されたランタイムなので、Python や Node.js と比べてサンプルが少ないですね。
サクッとコピペで試そうとしたけど、断片的にしか見つけられなかったので、自分の試したかったことだけをまとめました。

参考にしたサイト

s3 - Amazon Web Services - Go SDK
s3manager package - github.com/aws/aws-sdk-go/service/s3/s3manager - pkg.go.dev
session package - github.com/aws/aws-sdk-go/aws/session - pkg.go.dev
Go言語(golang)でS3へファイルをアップロードする | DevelopersIO
Go言語(golang)でS3からファイルを取得する | DevelopersIO
3分で作る、S3イベントで実行するLambda | DevelopersIO
クレデンシャルの適切な扱い方ー AWS SDK for Goの場合 | DevelopersIO
【Golang】AWSLambdaからS3にアップロードする - 怠慢プログラマーの備忘録
 【Go】AWS SDK GoのGetObjectの返り値が16進数になった...!

2021-10-25

「AWSの基礎を学ぼう第六十四回 AWS Wavelength」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

5G と AWS を直接連携する Wavelength です。

セッション

AWS Wavelength

講師：アマゾンウェブサービスジャパン、シニアエバンジェリスト亀田氏

クラウドインフラの延伸ソリューション

Outposs
- 自社の DC に置く
local zones
- 自社の近くに配置
  - 日本未対応、日本はインターネットが優秀なので基本不要
Wavelength
- 5Gのメリットをフルに享受するために5Gネットワーク内に置く
  - 日本は KDDI を利用
- VPC のサブネットが増える形で見える

Wavelength って何？

5Gからインターネットに出ないことで低遅延を実現するサービス
- いわゆる MEC
  - マルチアクセスエッジコンピューティング
- 数十ミリ秒が数ミリ秒になる
- KDDI キャリアからインターネットを介さずに AWS へ接続する
  - au 以外は結局遅いのでユースケースに困ることも
東京リージョンにある
- NRT Wavelength Zone
- KIX Wavelength Zone: 大阪リージョンではない
  - 東京リージョンの一部が大阪にある状態
対応サービスは Outposts より少ない
- 中身は Outposts ではない
利用料は Wavelength 用があるので通常の値段とは異なる

ユースケース

ネットワークの要件ありきで発生する
- 工場の時計を厳密に合わせる
- リアルタイムマルチアクセスゲーム
  - ゲームストリーミング分散アーキテクチャ
- メディア＆コンテンツ
  - Live 配信する場合はインターネット回線を引き込んでいる
    - 回線を引き込まなくても5Gで可能になる
- エッジ推論

所感

今は KDDI 限定なので、専用環境でしか使いみちがなさそうですが、5G な世界が来てどのキャリアでも使うようになると、コンシューマー利用もできて一気に夢が広がりそうですね。

2021-10-21

Lambda で Go のめっちゃ基礎

小ネタ Go AWS

最近はインフラエンジニアな仕事しているから YAML ばっかり書いてて、すっかりプログラム書かなくなって久しいです。
ちょっと Lambda で遊ぼうとして「せっかくなら Go で書くか」ということで、チュートリアル終わらせるのにも思い出すこと多かったので備忘録を残します。

GitHub

github.com

この README のサンプルを動かすだけです。

開発環境

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.15.7
BuildVersion:   19H1419

$ go version
go version go1.17 darwin/amd64

Getting Started

作業ディレクトリ作って、main.go ファイル作成して、ソースをコピペ。

$ mkdir sample && cd sample
$ touch main.go

go mod init で初期化して、go get で module 取得。
Go のバージョン上げて、この辺りのお作法が変わってたので調べるところからでした。

$ go mod init sample
go: creating new go.mod: module sample
go: to add module requirements and sums:
    go mod tidy

$ go get -u github.com/aws/aws-lambda-go/lambda
go get: added github.com/aws/aws-lambda-go v1.27.0

Building your function

ビルドして圧縮して、sha256 ハッシュ値確認。

$ GOOS=linux GOARCH=amd64 go build -o main main.go

$ zip main.zip main
  adding: main (deflated 47%)

$ shasum -a 256 main.zip | awk '{print $1}' | xxd -r -p | base64
MQAIpPIIhoWIxBdTk1sv0x9hIxUZ29Qn4MBap+cFwUg=

Lambda 作成と確認

sample の Lambda を、ランタイム Go 1.x で作成。

f:id:omron:20211021113507p:plain

「コード」タブの「コードソース」-「アップロード元」-「.zip ファイル」から、main.zip をアップロード。
SHA256 ハッシュが正しいか確認。

f:id:omron:20211021113523p:plain

「テスト」タブの「テスト」をそのまま実行して確認すると、見事にエラーがでましたね。

{
  "errorMessage": "fork/exec /var/task/hello: no such file or directory",
  "errorType": "PathError"
}

hello が無いから実行できないようです。

対応策その1

f:id:omron:20211021113550p:plain

「コード」タブの「ランタイム設定」がデフォルトで hello になっているので、main に修正して再度テストしてみます。
そうすると無事成功しました。

"Hello ƛ!"

対応策その2

「コード」タブの「ランタイム設定」がデフォルトで hello になっているのでここは直さずに、バイナリを hello で作ります。

$ GOOS=linux GOARCH=amd64 go build -o hello main.go
$ zip hello.zip hello
  adding: hello (deflated 47%)

再度アップロードして試すと、こちらでも成功しました。

バイナリはファイル名が違うだけで中身は同じなのに、圧縮するとサイズが倍ぐらい違ってるのが気になってしまった。
ファイル名だけなのにここまで圧縮率変わるんだ。

$ shasum -a 256 main | awk '{print $1}' | xxd -r -p | base64    
dEvHQRrM2vEsi2cH0ghONFIHIUl6KnztHLAA6bNARbA=

$ shasum -a 256 hello | awk '{print $1}' | xxd -r -p | base64
dEvHQRrM2vEsi2cH0ghONFIHIUl6KnztHLAA6bNARbA=

$ ls -la *.zip
-rw-r--r--  1 omuron  staff  4446178 10 21 21:24 hello.zip
-rw-r--r--  1 omuron  staff  8892332 10 21 21:23 main.zip

さいごに

Go のバージョン上げて、モジュールの管理方法とかが変わったから「初期化どうするんだっけ？」とか、README 通りに動かしたはずなのに初回エラーになって少し悩んでしまったりしたので、忘れないためにメモっておきます。

2021-10-20

「VPoEが語るエンジニア組織づくり最前線vol.2」 #vpoe_findy 受講メモ

勉強会

【エムスリー×マネーフォワード】VPoEが語るエンジニア組織づくり最前線vol.2

findy.connpass.com

「エンジニア組織ってどうやって作っていくの？」ということで聞いてました。

登壇者

スピーカー
- 山崎聡さん/(エムスリー株式会社) @yamamuteking
- 渋谷亮さん/(株式会社マネーフォワード) @ryoff
モデレーター
- 佐藤将高(ファインディ株式会社)/ @ma3tk

パネルディスカッション

VPoE ってどんな職種？ミッションや課題と取り組みは？

山崎さん
- ざっくり2種類に分けれる
  - 創業 CTO の責務を分割して VPoE が配置される
    - エンジニアリングマネージャーよりの人
  - 創業 CTO が卒業していなくなり VPoE が組織を引っ張る
    - 山崎さんはこっちのパターン
    - エンジニアリング組織と経営を結びつける
    - エンジニアリング組織のパフォーマンスを出す/収益を出す
    - 収益責任を持つ立場
- 課題は自分で見つけて解決する
  - 自分で考えるのがミッション、上から指示しない
  - 成果が出るチャンスを与える、一緒に考えてあげる
- エンジニアは売れなくても作るのは楽しい
  - 顧客に良いサービスを届けるために売れる方向に導くようにする
渋谷さん
- 山崎さんと同じく課題は自分で見つける、経営にコミット
- VPoE は正解がない問に立ち向かう仕事
  - 時代や世の中によって正解が変わる
  - 壁打ち相手になる
山崎さん
- VPoE に気軽にチャレンジしてほしい
  - 重要だけどいないと困る仕事

エンジニア組織で困ったことやこうすればよかったというエピソードは？

渋谷さん
- 目の前の仕事に夢中になっているとき課題があるはずなのに見えてない
  - 上手くいってそうなときは課題が見つけられてない可能性
  - 例えば新卒採用でバランスをとるのが難しかった
    - 数年後にマネジメント層が足りなくなる
    - プロダクトの構造と同じ
      - 個別最適で採用を続けたりすると数年後に困る
      - 2〜3年後の組織構造を意識する
- エンジニア70名ほどで VPoE を複数名配置
  - 任命されたけど多すぎじゃないかと思った
    - 採用を増やして組織を大きくしたときに CTO と同じ目線になるように増やしておきたかったと
  - 現場で見えない課題を見ることができる人が増えるのは大事
山崎さん
- エンジニアが退職するとき
  - エースが抜けると困るが、辞める人の応援はしたい
  - 退職原因は我々側にあるから反省すべき
    - 就職するためには厳しい条件があるのに辞めてしまう
  - チームリーダーなどの中間層の育成問題
    - 中間層でチャレンジが十分に行き渡ってない
    - リーダー育成を早いうちに行うべきだった
    - CTO がアーキテクトを育てるというのと同じ
    - 勇気を持って任せていく、自分で何でも解決しない

EM やテックリードの育成についてどのような取り組み？

山崎さん
- 小さいチームをたくさん作る
  - 縦じゃなくて横方向へ広げる
  - チームリーダーがチームの数だけ必要になる
    - 16チームある
    - 事業が新規に立ち上がるとチームを増やす
      - 最初は兼任チーム、起動にのると事業専任チーム
      - 半分は兼任で横断（QA,インフラ,AIなど）、半分は事業付きチーム
- 技術が好きで入る人が多い
  - CTO タイプが多い、マネージャーを嫌がる
  - VPoE がいなくなる、チームリーダーは貴重
  - EM 適正がある人をマークして協力依頼する
渋谷さん
- 四半期に一度合宿して1日中未来を考える日がある
  - エンジニア組織とアーキテクチャを考える
  - EM やテックリードの数の候補が見える
    - 数年後そこに行けそうな人がチャレンジできる機会を作る

いいエンジニア組織に共通する要素は？

渋谷さん
- 事業がちゃんと伸びている
- 組織と自分の成長が感じられる
- 課題を一気に解決できる人
  - 問題解決ブルドーザー
  - ここをこなせる人が多いといい
  - 最後まで巻き込んで持っていく力がある人
山崎さん
- 医療を前進させるのが我々にとって良い組織
- ミッションに楽しくヒットするのが条件
  - ビジネスと噛み合わずエンジニアが満足するだけな状況は避ける
  - エンジニアが尊敬されているのは、ビジネスを支えているからこそ
  - ビジネスサイドに認められる働きをしている
    - とにかくスピードが大事
    - ビジネスサイドの考えるスピード感を超えると何より喜ばれる

FAQ

CTO と VPoE で違う点は？
- 山崎さん
  - 技術ははっきりしていることが多い
  - ピープルマネジメントは曖昧なケースが多い
EM やテックリードにもとめていることは？
- 渋谷さん
  - おまかせしたい領域の理想と現実のギャップを把握して解決していく人
  - EM とテックリードは領域が違う
    - ギャップを探すという点では同じ
- 山崎さん
  - メンバーがイキイキ働く仕掛けをしていくことが大事
    - メンバーにチャレンジを与えれるようにする
経営経験の無い人が EM になったとき売上/利益をどうコミット？
- 山崎さん
  - 会社の利益を背負ってもらう
  - 利益の何割を達成するのを目標にするとか
EM ってなりたくてなれる？
- 渋谷さん
  - なりたい人ならチャレンジの機会を与える
  - なろうと思ってもらうのが大変
  - 資質は生まれ持ったものではないので経験すればつく
    - Try&Error で学びの機会を与えて成長してもらう

所感

VPoE ってなりたい人を見つけるのが本当に難しそう。
EM も VPoE も「現場で手を動かすエンジニアを続けるのが辛くなった」から逃げて向かう先ではなさそうだし。
チームを動かしてピープルマネジメントもして、この辺りの仕事がおもしろいと感じれて、経営人との橋渡しをできるコミュ/語彙力も必要だろうし。
1か0で動かせない世界の仕事は大変だ。