I ❤️ Kubernetes

f:id:tei1988:20171206163009j:plain こんにちは!プロジェクト推進室でエンジニアをしているTei1988です。

先日開催したSpeeeKaigi #3で「I ❤️ Kubernetes」を発表しました。

tech.speee.jp

Kubernetesは、コンテナオーケストレーションツールです。 コンテナ化されたアプリケーションの管理やデプロイ、スケールなどを一手に引き受けます。

Google Container EngineからGoogle Kubernetes Engineに名称変更されたり、EKS(Amazon Elastic Container Service for Kubernetes)も始まったりと、スタンダードなツールになりつつあるので、Kubernetesを学んでおいても損にはならないかと思います。

DockerもKubernetesもほぼ初めてだったのですが、触っていくうちにいつのまにか❤️ になっていました。

ここでは、今回やってみたことを紹介します。

0. そもそも

最近、自部署近辺でKubernetesというワードがちらほら出てきました。これまで、Dockerにもあまり触れられていなかったので、勉強のためにRailsでアプリケーションを作り、Kubernetes上で動かしてみることにしました。

1. Kubernetesを構築してみる

KubernetesはOSSなので、自分で構築することができます。どのような仕組みで動くのか興味があったので、IDCFさんの500円サーバを3台使って自分で構築することにしました。

構築するにあたって、下記の記事を参考にしました。
kubernetesによるDockerコンテナ管理入門 | さくらのナレッジ
丁寧に導入方法が書かれていて、とても助かりました。 また、文中のマスター-ノード間や、ノード-ノード間の動きの図がわかりやすく、動きの理解もしやすかったです。

ただ、オプションの命名規則が_から-に変更されていたようで、一通り設定を終えていざPodをデプロイしようという段階でデプロイに失敗してしまう現象に悩まされました。 マスター-ノードの認証をしている部分で、service-account-private-key-fileのオプションが効いておらず、認証のための秘密鍵が設定されていないために認証に失敗してしまうことが原因でした。 kubectl cluster-infoや、kubectl get nodesでクラスタやノードの状態を調べても正常な場合と差が見当たらず、原因がなかなか特定できませんでした。

とりあえず、kubectl create -f ...などはできて、nginxのwelcomeページは表示できるようになりました。 なんとなく仕組みを理解できたものの、 Railsアプリケーションに全然着手できていなかったので、自分で構築することを諦めて、GCPで提供されているKubernetes(GKE)を使うことにしました。

ちなみに、Kubernetes自体を試す場合には、GitHub - kubernetes/minikube: Run Kubernetes locallyというものがあり、こちらを使えばすぐに環境が作れます。

2. Railsアプリケーションをつくってみる

ウェブサイトとその管理画面、バッチ、非同期処理を一つのRailsアプリケーションとしました。

アプリケーションの詳細は特に変わったことをしているわけではないので省きますが、ウェブサイトとその管理画面を起動時の環境変数によって切り替えられるようにしました。

全体のシステム構成図は以下を想定しました。 f:id:tei1988:20171205203319p:plain

Railsアプリケーションの前にnginxを入れて、非同期処理にSidekiqを利用する、よくある構成だと思います。

3. Redisを導入してみる

Sidekiqで使うために、Redisを導入することにしました。

AWSにはElastiCacheがあるのですが、GCPには今のところありません。そのため、 Kubernetes上でRedisを動かすことにしました。 本格的にサービスに導入する場合は、冗長構成などを検討すると思いますが、今回はマスター1台としました。

下記のように、 readinessProbelivenessProbe で、Podが落ちていても再起動がかかるようにしました。

...
        readinessProbe:
          tcpSocket:
            port: 6379
          initialDelaySeconds: 5
          periodSeconds: 1
        livenessProbe:
          tcpSocket:
            port: 6379
          initialDelaySeconds: 10
          periodSeconds: 30
...

4. CloudSQLのプロキシを設定してみる

データベースは、GCPのCloudSQLを利用することにしました。Kubernetesからの接続にはいくつか方法があります。

今回は以下を参考にプロキシを挟むことにしました。

Connecting from Google Kubernetes Engine  |  Cloud SQL for MySQL  |  Google Cloud Platform

サイドカーコンテナを使うことが書かれているのですが、アプリ本体や、管理ツール、バッチ、Sidekiqでそれぞれサイドカーコンテナを設定するのはなんとなく避けたいと思ってしまったので、プロキシ単体でPodを作ってみました。

引数で、tcp:3306tcp:0.0.0.0:3306 に変えることでローカル接続以外も受け付けるようになります。

...
        - -instances=<project_name>:<zone>:<instance_name>=tcp:0.0.0.0:3306
...

あとは、 3306expose する設定をデプロイしてあげれば、Kubernetesの内部であればどのPodからでも接続が可能になります。

5. Railsアプリケーションをコンテナ化してみる

Railsアプリケーションをコンテナ化する際に、動作に必要の無いパッケージを極力含めたくなかったので、ruby:alpineからイメージを作ることにしました。

とはいえ、Gemの中にはNative Extensionを利用するものもあり、それらをインストールするためには開発用パッケージが必要になります。 最初の頃はDockerfileのRUNを一つにまとめて頑張っていたのですが、毎回パッケージインストールやらコンパイルやらが走ってしまい、イメージのビルドに時間がかかってしまっていました。 そんな時に、ECSとGoとDocker multistage build - Speee DEVELOPER BLOGでも紹介されているmultistage buildを知り、二段構えにすることにしました。

流れとしては以下のような形です。
f:id:tei1988:20171012203815p:plain

  1. Railsアプリケーションで使うGemのコンパイルをするためのapp:bundle-buildをビルドします。
  2. 実際に動かすためのapp:latestをビルドします。この時、app:bundle-buildからインストールしたGemのディレクトリをまるっとCOPYしてきます。

これにより、不要な開発ツールを実行用のイメージに含めなくてよくなると同時に、Gemの更新が無い場合はapp:bundle-buildはキャッシュされたものが使われるので、毎回nokogiriのコンパイルを待つ必要が無くなりました。

6. Railsアプリケーションを起動してみる

#5で作ったイメージには、ウェブサイトとその管理画面、バッチ(Rakeタスク)、非同期処理(Sidkeq)が含まれています。

そこで、Kubernetesのデプロイの設定にそれぞれの起動時のコマンド変えて、一つのイメージから起動させることにしました。

ウェブサイトは以下のようにしました。(部分抜粋)

...
      containers:
      - name: web
        image: gcr.io/<project_name>/app:latest
        imagePullPolicy: Always
        command:
        - bundle
        args:
        - exec
        - pumactl
        - -F
        - config/puma.rb
        - start
        ports:
        - containerPort: 3000
          protocol: TCP
        env:
        - name: RAILS_ENV
          value: production
        - name: RAILS_LOG_TO_STDOUT
          value: "1"
        - name: RAILS_SERVE_STATIC_FILES
          value: "1"
...

管理画面は以下のようにしました。(部分抜粋)

...
      - name: admin
        image: gcr.io/<project_name>/app:latest
        imagePullPolicy: Always
        command:
        - bundle
        args:
        - exec
        - pumactl
        - -F
        - config/puma.rb
        - start
        ports:
        - containerPort: 3000
          protocol: TCP
        env:
        - name: RAILS_ENV
          value: production
        - name: ADMIN
          value: "1"
        - name: RAILS_LOG_TO_STDOUT
          value: "1"
        - name: RAILS_SERVE_STATIC_FILES
          value: "1"
...

管理画面とウェブサイトの差分は、起動時に環境変数ADMINがセットされているかどうか、です。

Sidekiqは以下のようにしました。(部分抜粋)

      containers:
      - name: sidekiq
        image: gcr.io/<project_name>/app:latest
        imagePullPolicy: Always
        command:
        - bundle
        args:
        - exec
        - sidekiq
        - -C
        - config/sidekiq.yml
        env:
        - name: RAILS_ENV
          value: production
        - name: RAILS_LOG_TO_STDOUT
          value: "1"

ウェブサイトや管理画面との違いは、pumaではなく、sidekiqを立ち上げていることです。

kubernetesだけが解消できるという訳ではありませんが、環境変数を設定に書くことで、実はxxの環境変数が動作に影響していて、それはooの奥底で定義されていた!の様な、辛い経験とはおさらばです。

そのままでは他のPodから繋がらないのでapp3000番ポートをexposeするような設定を作って、デプロイします。

adminはそのままお外からも繋げるようにしました。 とはいえ、アクセス元は制限したいので、以下のような設定を追加しました。

...
spec:
  ports:
    - name: admin
      port: 80
      targetPort: 3000
  selector:
    app: admin
  type: LoadBalancer
  loadBalancerIP: <事前に取得した静的IP>
  loadBalancerSourceRanges:
  - <許可するアクセス元のIP/CIDR>
...

直接GCPのコンソールから設定を追加することもできるのですが、Kubernetes側で再度デプロイすると、当然ながら手動で入れた設定も上書きしてしまいます。 いつのまにか全世界に公開していた、ということになるかもしれないので、設定に含めるのが良いと思います。

7. nginxに設定を追加してみる

システム構成図の nginx の部分です。 Kubernetesでは、Serviceを作ると、そのServiceにつけた名前で名前解決ができるようになります。 *1

そこで、以下のような設定にしてみました。 この設定で、ちゃんとRailsアプリへアクセスが行きます。

...
upstream backend {
  server web:3000;
}
...
server {
...
  location / {
    proxy_pass http://backend;
    proxy_set_header  Host $host;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  X-Forwarded-Port $server_port;
    proxy_set_header  X-Forwarded-Host $host;
...
}

スケールしてRailsアプリを複数デプロイしてある場合でも、Serviceで複数のPodにマッチするように設定を書いている場合はこのままでアクセスが分散されます。すごい。

セッションなどを使う場合は、少し考えないとダメそうですね。

8. 定期的にジョブを実行する

Kubernetesには、cron的なものがあります。ズバリ、CronJobです。 1.8以降でAPIがbetaになったのですが、1.8以前はalpha版で、GCPでは使えませんでした。

自分が試した時はまだalpha版だったため、busyboxのcrondをフォアグラウンドで動かすことにしました。 バッチとbusyboxをイメージに入れて、crontabを書くだけなので、手軽だと思います。

kind: ConfigMap
apiVersion: v1
metadata:
  name: crontab
data:
  root: |-
    10,40 0-18 * * * echo "hoge"
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: cron
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cron
  template:
    metadata:
      labels:
        app: cron
    spec:
      containers:
      - name: cron
        image: gcr.io/<project_name>/app:latest
        imagePullPolicy: Always
        command:
        - busybox
        args:
        - crond
        - -d
        - '6'
        - -f
        volumeMounts:
        - name: crontab
          mountPath: /var/spool/cron/crontabs
          readOnly: true
      volumes:
      - name: crontab
        configMap:
          name: crontab

9. Sidekiqのスケール

Kubernetesを使っていて、とても感動したことがこれです。

非同期処理をたくさん行う場合、Skidekiqのノードの数をたくさん増やしたくなると思います。

Kubernetesでは、
kubectl scale --replicas 3 deployment sidekiq
で、Podを3つに増やせます *2。 とても簡単でした。

10.さいご

SpeeeKaigiをきっかけに、KubernetesやDockerに触れられて、本当によかったと思いました。

自分でKubernetesを建ててみたことは無駄ではなく、下記「Be Docker Day」ですでに使い始めていた他のメンバーと同じぐらいKubernetesやDockerの話を深くすることもできました。
tech.speee.jp

ここ最近では、Java + AkkaなシステムをDocker化してKubernetesで動かしました。 今後も、DockerとKubernetesの良さをもっと広めていきたいなぁ、と思います。

*1:GCPで動かしている場合はデフォルトで動いているのですが、自前で構築した場合はkube-dnsを導入する必要があります。

*2:sidekiqという名前でSidekiqのDeploymentを作成していた場合

日報を感情分析して良いチームワークを作れないか。

この記事は、 SpeeeKaigiで発表した内容についてのまとめ記事です。 SpeeeKaigiについては、こちらを御覧ください。

打刻機エンジニアの山本です。

人間の行動って面白いですよね。 自分の行動一つで、その日の過ごし方が代わり、 プライベートや仕事のパフォーマンスが変わってくる気もします。

良いこともあれば、悪いこともある。 環境に左右されて気分が変わることは、実に人間らしく生活できている証拠であり、 良い面/悪い面があると思いますが、僕はポジティブに受け取っています。

私たちはいろいろな感情を持って仕事に取り組む

人間の最大の罪は不機嫌である

偉人「ゲーテ」の語るとおり、人には機嫌の波や調子の善し悪しがあるものです。 しかしプロフェッショナルとして、その姿を他の人に感じさせないような努力をしている人もいると思います。

仕事上/プライベートでも、少し調子の悪いとき、 それを察知して、声を掛けてあげられるチームって、すごくすてきだと思っています。 「イケてるね」「イケてないね」と、互いの調子の良し悪しを敏感に察知して、声を掛けるわけです。

感情を読み取りやすい場所

ところで、弊社には「日報をSlackに全社員が送る」という決まりがあります。 実際に日報を見てみると、さまざまなテーマで自身の思いを赤裸々に語る姿が見られます。

  • 友人の結婚式が週末にあって感動した
  • スプラトゥーンをやりたくて仕方がない
  • メンバとのちょっとしたやり取りへの感謝

弊社の日報は、単に「その日にあったこと」を書くだけではなく、 そのときに感じたことや週末にあった完全なプライベートなことも書いてしまえる場なのです。

社員数も増え、どんな人材が社内で働いているかの全容の把握が難しくなった今、 日報は「全社員が平等に双方向な交流を持つことができる場所」となっているのです。

日報はさまざまな感情を垣間見られる交差点

日報の場で、お互いの状態を知ることで、効率的に楽しく働けられるチームワークを創出できるのではないか。

今回の取り組みは、「日報を感情分析器に掛けてみる」ということでした。

取り組みの成果

感情分析の結果を基に本当に良いチームワークの創出ができるのか。 スライドでも語られませんでしたが、長い道のりになりそうです。

技術を駆使して目的を達成する志は変わりませんが、 いかんせん、感情分析をした結果から何をコンピューターは導いてくれるか。 そもそも、声掛けしているチームはチームワークが良いと言えるのか。測るのは難しいですね...。

日報の可能性を探ってみることにする

例えば、日報に必ずランチの情報を載せたり、筋トレの良さを語ったり...。 良いチームワークを創造する緒は、他にもあるかもしれません。 社内の話題を提供するような情報を可視化することで、 社内コミュニケーションをもっと活発に行えるかもしれない。と、開発しながら思っていました。

今回、開発した仕組みは、アプリケーションの体裁を取っているので、 もう少しデータの活用方法を考えてみて、いろいろと表現できないか試してみたいなと思います。 日報はいろいろな分析のベースになる素養も持っているものだと思うので、何かしら面白い結果を導ける...ハズ!

以上です!

復習するまでがISUCONです

ヒップホップにハマって要所要所で韻を踏もうとするがあまり、言いたいことも言えないようになった
エンジニアの @mnc です。

いよいよ明日、ISUCON7本戦が開催されます。
今からドキドキがとまりませんが、よく考えたら予選で惨敗していたので明日は何もすることがありませんでした。
「遠足は帰るまでが遠足だ」とはよくいったもので、ISUCONも復習するまでがISUCONだと自分を戒めISUCON予選の復習を行いましたので、そのことについてレポートいたします。

@gfxさんに上位陣の戦略について講義をしていただきました

詳しくは以下のBit Journey社の記事をご参照ください。

blog.bitjourney.com

講義ではISUCON上位陣の戦略の違いを説明していただきました。
3台のサーバーの使い方はそれぞれ異なっていましたが、帯域問題をクリアするために3台全てでリクエストを受け付けているという点では共通していました。 僕のチームは帯域問題を全くクリアできなかったため、上位陣の帯域問題をクリアするための戦略は非常に勉強になりました。

また、

N+1問題は秒速で解決できるくらいになっておかないといけない

という趣旨のアドバイスがあり、 ActiveRecordのincludesメソッドやjoinsメソッドでN+1を解決するということしかしてこなかった結果、SQLでN+1を解決するのに多くの時間を浪費した僕にとっては非常に耳が痛くためになるお話でした。

@gfxさんの講義の様子

f:id:manchose:20171124111900j:plainf:id:manchose:20171124111955j:plain

時間無制限でISUCON7予選の問題を再度1人で解いてみた

勉強しただけでは本番でいきなり成果を出すことは難しいので、
@gfxさんに教えていただいた内容を血肉とすべく1人でもくもくとチューニングしました。
環境はMacBook Pro (Retina, 15-inch, Mid 2015) のmacOS上にVirtualBoxで以下の2台のサーバーを立ち上げて行いました。
matsuu/vagrant-isucon のVagrantFileを使用させていただいております。)

  • Benchサーバー(ubuntu/メモリ2GB/CPU1コア) × 1
  • Applicationサーバー(ubuntu/メモリ2GB/CPU1コア) × 1

WebDAVを使ってpublicディレクトリに画像をアップロードする

今回の復習ではサーバーが1台なのでWebDAVを使う必要はなかったのですが、過去のISUCONでも使う機会があったそうなので勉強を兼ねて導入してみました。
WebDAVとはHTTP1.1を拡張したプロトコルでサーバー上のファイル操作を行う技術です。
Rubyレイヤーでファイルアップロードを実装するよりも短時間で実装できる場合があるため、このやり方に慣れておくと今後のISUCONで役に立つかもしれません。
nginx.confを以下のように設定しWebDAVで画像のアップロードができるようにしました。

dav_methods PUT; # 許可するメソッド
create_full_put_path on; # 必要な全ての中間ディレクトリの作成を許可する。
dav_access group:rw all:r; # WebDAV経由で作成したファイル/ディレクトリのパーミッション設定
# アクセス制限
limit_except PUT DELETE MKCOL MOVE {
    allow   172.28.128.4;
    deny    all;
}

この実装とnginx.confのキャッシュまわりの設定によって GET /icons のパフォーマンス問題はクリアできました。

N+1を解消する①

GET /icons を倒すことができたら次に立ちはだかるのは GET /fetch です。
未読数をチャンネルごとに計算している処理がN+1問題を引き起こしています。
スギャブロエックスチームの実装を参考に、既に読んだ数を別テーブルに格納しておくように変更しました。 GET /fetch ではそれを参照することでN+1問題を解決することができました。 このようなN+1問題の解決方法もさらっと実装できるようになる必要があるので、精進あるのみです。

N+1を解消する②

GET /message でも同様にN+1問題を引き起こしていたのでこちらも対応しました。
こちらは①とは異なりSQLのJoinを用いて解消しました。
ActiveRecordを用いずMysql2を用いて解決することに手間取ってしまったので、このあたりを深く考えずに実装できてしまうくらい鍛錬を積もうと思います。

結果

スコア

初期スコア 最終スコア
11425 37583

これくらいまでチューニングしたところで点数は30000点を超えました。
本番の環境とスペック等が異なっていますが、上位陣が行ったチューニングを実際に手で動かして再現することで血肉となった気がします。
やはり頭でわかっているのと、実際に手を動かして効果がでるまで実装できるのとでは大きな違いがあると実感しました。
なにより バグなく実装する というあたりまえのことができていないことが多く、その修正に多くの時間を使ってしまっていることがわかりました。
この 実装力 を身につけることが今後の課題です。

ISUCON予選の実装内容を公開してくださっている上位チームのリポジトリやブログを参考にして再度実装しなおすことで確かな力になりましたので皆さんもぜひ再実装してみてはいかがでしょうか。
引き続きチューニングを進めて次回大会では本戦出場できるように精進していきたいと思います。

※実装はmnc/isucon7-reviewにあります。

Product Manager Conference #pmconfjp 参加レポート(2日目)

こんにちは。エンジニア上がりプロダクトマネージャー見習い橋本です。 Product Manager Conference 2017、2日目のレポートをさせていただきます! 2日目はプロダクトマネージャー視点の組織づくり、Eng上がりのプロダクトマネージャーの話、Googleのプロダクトマネージャーの育成について聞ける1日でした。 f:id:eva-hashimoto:20171116094117j:plain

今いるメンバーで「大金星」を挙げるチームの法則

仲山 進也氏/仲山考材(株)代表取締役・楽天(株)楽天大学学長

今いるメンバーで「大金星」を挙げるチームの法則―『ジャイアントキリング』の流儀
既存のチームで最大の成果を出すためのチーム作りの法則を本の著作者から直接聞けるセッションでした。

チームの成長ステージとして、「フォーミング(形成期)」「ストーミング(混乱期)」「ノーミング(規範期)」「トランスフォーミング(変態期)」があり、各期の間にはコミュ量の壁、コミュ質の壁、納得感の壁がある。

  • フォーミング期:チームが結成されたばかりで、方向性がバラバラなまま目標に向かおうとしている。(グループ)
  • ストーミング期:衝突・対立が起こり、感情もネガティブになり、パフォーマンスが下がる。(グループ)
  • ノーミング期:情報共有が進んで、役割やルールが明確になり、目標がメンバーごとに形成され、成果が出始める。(チーム)
  • トランスフォーミング期:あうんの呼吸で動けるようになる。チームがあたかも一つの生物のように、目覚ましい成果が生まれる。(チーム)

失敗をする秘訣は、「役割分担をしてから意見を言い合う(ストーミング風なことをいう)」、フォーミング期を経て、ストーミング期に入ることが重要とのことでした。

Product strategyによって組織は大きく成長できる

詫間 亮平 氏/楽天株式会社 レジャーサービス開発課 ゴルフプロダクトマネジメントグループ マネージャー

楽天のゴルフサービスにおいてプロダクトマネージャーが果たした成果の紹介がありました。 プロダクトマネージャーとしてProductとOrganizationの2軸で改革を行うことで、日本のゴルフ人口が減りつつも新たな価値を提供することでゴルファーとゴルフ業界の活性化の事例紹介は素晴らしいと思いました。 Productでは主に、各種KPIの可視化(ゴルファー、ゴルフ場、など)、過去リリースの効果を検証し適切な目標設定(ビジョン)をおこなうことで適切なIssuを選択し問題解決をProductで行うこと。Organizationではビジネス側とエンジニア側双方のコミュニケーションブリッジとして事業全体を前進させる働きをすることでProduct作りを進められる組織運営が行われていました。

多様性を成功に導くプロダクトマネジメント 5選

  • 働き方の多様性 | 大阪リモートチームとのプロダクトマネジメント
    尾部 絵里子 氏/Sansan株式会社
  • 働き方の多様性 | プロダクトマネージャー兼エンジニアが語るリモートワークが当たり前の組織
    高木 咲希 氏/株式会社ソニックガーデン
  • 価値観の多様性 | 国籍の違いに見るプロダクトマネジメント
    高橋 りさ 氏/ソニーモバイルコミュニケーションズ株式会社
  • 組織とキャリアの多様性 | PM文化のない組織にPM文化をつくる
    石田 隼 氏/ChatWork株式会社
  • 組織とキャリアの多様性 | プロダクトマネジメントをチームに導入するということのリアル
    篠原 佳奈子 氏/株式会社ビズリーチ

「多様性を成功に導くプロダクトマネジメント 」をテーマに、5社での取り組み事例が紹介されました。 Sansanの尾部氏、SonicGardenの高木氏からは、主にリモートワークについて。リモートワーク導入にあたっての工夫,ポイントなどを紹介されていました。

SonyMobile高橋氏からは、異なる国で結成されたチームにおけるマネジメントについて。ソニーエリクソンが前身であるために、東京とスウェーデンにまたがって進めるために、具体的に各チームの特徴や背景、文化などでどのような差があったのか、どんなことに注意する必要があったのかをお話しされていました。

ChatWork石田氏、ビズリーチ篠原氏からは、"プロダクトマネジメント"の導入期の取り組みが紹介されていました。ひとりプロダクトマネージャーという立場の石田氏と、組織としての導入をメンバーとして試行錯誤した篠原氏で違いはありましたが、それぞれの経験、立場で行われたことや、その振り返りを紹介していました。

ユーザーの“心の声”を探るUXリサーチ

奥泉 直子 氏/フリーランス・ユーザーリサーチャー

UXリサーチを10数年やられている奥泉氏からのセッション。 所謂UXリサーチの方法や事例だけではなく、人間の認知特性には知覚刺激による認知処理と知識や経験から推察される認知処理の2つがあること、 特に推察による認知処理を理解する点が難しいことなど、人間がいかに物事を知覚し反応するかという認知特性に則ったUXリサーチ手法を設計することの重要性を説いていらっしゃる点が非常に印象的でした。 また、リサーチをする側の人間も同様の認知特性を持っていることで、事実を歪めて認識してしまう可能性すらも理解して設計すべきとされており、 UXリサーチを本質的に精度高く実施するヒントが散りばめられていました。

PMがUXするために必要なのはおそらくIA

小久保 浩大郎 氏/株式会社CAMPFIRE

今回のカンファレンスでUX/UIをメインテーマとしたセッションは少なかったのですが、このセッションではメインテーマとして扱い、UXの概要からプロダクトへの反映までを順を追いながら紹介していただきました。 テープレコーダーを例に、過去におけるプロダクト作りの課題点をUX、UIを軸にPMが考えるべき視点として説明していただき、とてもわかりやすいセッションだと感じました。

エンジニアがプロダクトマネージャーとしての役割を全うするために何をするべきか

木村 衆平 氏/株式会社サイバーエージェント

f:id:eva-hashimoto:20171116111418j:plain エンジニアからプロダクトマネージャーに転向してプロダクト作りの何に苦労し解決していたかを紹介されました。 私もエンジニア上がりですが共感できる内容が多く、自社や他社のサービスを使い、裏で何が動いて入るのか?を想像できる力はエンジニア特有の能力が生きる場面だと思いました。 またデータを活用し論理的に立てた仕様や、プロダクトの計画が論理的に説明できない結果に陥ることもあり、論理では説明できない内容も受け入れることが重要だと事例紹介がありました。

プロダクトマネージャーの採用と育成(Google)

Capella Yee 氏/Google, Inc.
Bryan Cheng 氏/Google, Inc.

登壇者2名はAPMプログラムを経てプロダクトマネージャーになり、Capella氏はiOSのGoogle MAPをBryan氏はLocal Guidesを担当とのことでした。 Googleのプロダクトマネージャーは様々な部署をまたいで活動しており、営業、マーケティング、デザイン、エンジニアリング、リーガルなどのチームと協力して入るとのことです。 UXデザイン、エンジニアリング、ビジネスの交わるところがGoogleの場合のプロダクトマネージャーが主に行われる意思決定領域で、コミュニケーションに多くの時間を割き、情報の共有に注力していました。 コミュニケーションの中でも共通認識が非常に重要であり、これがないと修復に非常に多くの時間・労力を有するとCapella氏は考えているようです。 続いてプロダクトマネージャーになるためのAPM(Associate Product Manager)プログラムの説明がありました。 コンピュータサイエンス選考した人が2年受けるプロジェクトで、座学ではなく実際のプロジェクトにAPMとして参加し、OJTで学ぶものとのことでした。 「プロダクトマネージャーになるために」のような専門の講座は少ないようです。 これ以上のことは詳しくは書くことができませんが、会場からは多くの質問が飛び交い及川氏が通訳しながらGoogleのプロダクトマネージャーに対しての思想や課題解決の手法について多くの内容が話されました。

「日本のプロダクトマネージャーは今何をすべきか」

今年のテーマ:広げる、深める、日本のプロダクトマネジメント

馬田 隆明 氏/東京大学 産学協創推進本部 東京大学本郷テックガレージ ディレクター
及川 卓也/Product Manager Conference 2017 実行委員 フリーランス
丹野 瑞紀/Product Manager Conference 2017 実行委員 株式会社ビズリーチ プロダクトマネージャー
関 満徳/Product Manager Conference 2017 実行委員長 グロースエクスパートナーズ株式会社 ITアーキテクト

(ワークショップのセッション) 「Sessionを聴講して気づいたこと、自分が大事だと考えたこと」と「2日間では触れられなかったことで、自分では大事だと考えたこと」を記入し、4人でグループを組みお互いに思ったことを話ました。 個人のワークショップでは「自分が重要だと思ったこと」を投稿し、他の方が投稿したものに「いいね」を押すという流れで進みました。 1番いいねがついた投稿は「プロダクトへの愛」。 プロダクトへの愛は何なのか。及川さん曰く、多くの人に愛されている製品を愛することが重要なのではないかとのこと。 自分がワクワクしつつ、まわりをワクワクさせることもプロダクトマネージャーの仕事の一つである。 しかし、愛を持ちながらも様々な観点で冷静にみることも重要。

馬田さんは、本イベントを通じてメンターの重要性を感じたそうです。しかし日本にはまだプロダクトマネージャーが少ないのが実情です。 オフラインで集まることも重要であるが、オンラインも活用してほしいと及川さん。 海外ではプロダクトマネージャーだけのslackがある。Mediumでもプロダクトマネージャーに関する情報が記事となっている。 過去の製造業で活躍された西堀栄三郎氏の歴史や、SONYの社史なども参考になるとのことでした。

また会社によって、プロダクトマネージャーの立ち位置が異なるようです。ビジネス寄り、技術寄り、ジェネラル寄りの三種。 具体的にはGoogleは技術寄り、Facebookはジェネラル寄り、salesforceはビジネス寄りなどのようにプロダクトマネージャーは会社によって様々のようです。

まとめ

1日目のLTにて紹介したSpeeeが作成しているプロダクトマネージャーとして虎の巻「Product Management Essentials」に興味を持っていただいた参加者がSpeeeブースに多数来ていただきました。 f:id:eva-hashimoto:20171116095151j:plain

Speeeとしてもプロダクトマネージャー組織が直近できたばかりで、初参加ということもあり、社外のプロダクトマネージャーの文化や施策に触れることができ貴重な二日間を過ごせたと思います。 まだ日本では「プロダクトマネージャー」という言葉、ロールが認知されつつある段階とは思いますが、プロダクトを提供する組織として必要不可欠なロールになると思っています。 f:id:eva-hashimoto:20171116094000p:plain

最後に今回このような機会を提供していただいたProduct Manager Conference 2017実行委員の皆さま、参加者の皆さま、ありがとうございました。

Product Manager Conference 2017 #pmconfjp 参加レポート(1日目)

プロダクト推進室の渡邊です。
先日2日間に渡って実施されたProduct Manager Conference 2017の1日目のレポートをお送りします。

Product Manager Conference 2017
http://2017.pmconf.jp/

Product Manager Conferenceとは?

日本におけるプロダクトマネジメントに関わる人やそれを目指す人が集うカンファレンス。
昨年に続き今年で二回目となり、定員300名に対しキャンセル待ちが200名を超えるなど、
年々、注目度の高まっているカンファレンスになります。(最終的に定員450名まで増員)
今回は参加した講演の簡単なレポートやカンファレンスの雰囲気をお伝えします。

f:id:yt-tanabe:20171115183854j:plain:w500

基調講演

なぜ今プロダクトマネジメントか

齊藤 満 氏/楽天株式会社 Senior Manager

マイクロソフトでWindowsやInternetExplorerなどにも携わっていたという、楽天トラベル齊藤氏のセッション。 プロダクトマネージャーとは、会社やチームによりけりで、これだと定義することは難しい、としながらも、過去のご自身の経験から 複数の切り口で必要な要素を紹介されていました。その中でも、「Generalize」、「Communication Skill」、「Decision Making」の3要素に分けての紹介が印象的でした。

トークン・エコノミー時代のプロダクト設計

宇野 雅晴 氏/Omise Japan株式会社 Business Development Manager

聞き馴染みのある言葉から丁寧に解説いただき、背景についての共通認識を持った上で、これらの技術トレンドをプロダクトマネージャーはどう活かすのか、という問いかけをしていただいたセッションでした。 サービスに閉じない経済圏において、どのような報酬設計を行い価値を流通させるのかなど、これからのプロダクトの潮流を読み解く上で非常に勉強になるお話でした。

プロダクトマネージャートークセッション

楽天、メルカリ、Line、CyberAgent各社のプロダクトマネージャーが参加し、 実行委員の一人でもある及川さんの進行のもと、パネルディスカッションが行われました。 セッションは"sli.do"というサービスを使って、来場者から質問を募りながら進行しました。 「プロダクトマネージャーとプロジェクトマネージャーの違いは?」「プロダクトマネージャーと事業責任者の分担は?」といった よくある質問から、各社でプロダクトマネージャーに求めるものや育成方法が寄せられていました。 共通点のある回答はありつつも、各社で特徴的な回答もありました。 また、現場で困った具体事例について、あなたならどう解消しますか?、といった質問も出ており、各社での過去の事例など交えてお話しされていました。

f:id:yt-tanabe:20171115183905j:plain:w500

プロダクトマネージャーに経営者が期待するもの

佐藤 裕介 氏/株式会社フリークアウト・ホールディングス 代表取締役社長

フリークアウトの佐藤氏が登壇。経営という立場から、プロダクトマネージャーに求められる事項をお話しされていました。 ごく一部の例外を除き、プロダクトバリューの変化はいとわないことの重要性を説明されていました。 実際にフリークアウトでも、過去7年に4度もプロダクトバリューを変化させている、ということでした。 "技術、ユーザー、市場構造の変化を察知し、チームが納得するかたちでこれを取り入れていく"旨をお話しされていました。

IoT、ビッグデータ、人工知能によるユーザー理解を通じたプロダクト開発

岡田 陽介 氏/株式会社ABEJA 代表取締役CEO

人工知能をプロダクト開発にどう盛り込んでいくべきか、そもそも人工知能の開発に必要なことは何なのかを分かりやすくお話いただいたセッションでした。 Speeeでも機械学習が機能の一つになっているプロダクトもあるので、プロダクトマネージャーがどこまで理解して意思決定をすべきか、どの点で悩むポイントがあるのか、逆に悩む必要のないポイントがどこなのか、一つの基準を示してくださっていた点が今後の指針として参考になりそうです。 また、人工知能を通して精度の高いユーザ理解を行うことができる一方で、どのスピード感で/どこまでの精度で人工知能を活用するかという点を決めるのはプロダクトマネージャーであるというお言葉が印象的でした。 かなり整理して話してくださったので、ディープラーニングに携わっていない方でも、どう開発プロセスに落とすかというイメージが湧きやすかったのではないかと思います。

Salesforceで行われているプロダクトマネジメント

浅田 慎二 氏/株式会社セールスフォース・ドットコム セールスフォース・ベンチャーズ 日本代表
Ken Wakamatsu 氏/株式会社セールスフォース・ドットコム

前半は全世界でSaasへの投資を行うVCとしてプロダクトを見る視点について、後半はSalesforceのUSにてプロダクトマネージャーを担っていらっしゃるWakamatsu氏から、USでの開発プロセスや開発チームの役割についてのお話でした。 Salesforceは400もの開発チームが存在しており、年3回のリリースタイミングでは300程度の機能がリリースされるとのこと。 年3回のリリースに向けてサイクルをシステマチックに回す仕組みを整備したり、バグ数を常時観測したりしている一方で、現場ではアジャイルで柔軟に改善しながら開発を行っており、 この仕組みを意味のあるものとして実行出来ていることに感銘を受けました。

メルカリUKにおけるプロダクトマネジメント

木下 慶 氏/株式会社メルカリ

メルカリUKにおける開発スタイル・開発プロセスについて、 使用しているツールとその活用方法や、海外のユーザに受け入れられるプロダクトを作るために行っていることなども交えてお話がありました。 自分とはバックグラウンドの大きく異なるユーザを理解するために、ユーザテストや街頭インタビューを重点的に行ったり、 街に出てあらゆるモノ・コトを観察したり実際のサービスを使ってみたりと、様々な手段でユーザやマーケットを理解しようと試みていらっしゃり、 プロダクトが海外向けであろうとなかろうときちんと意識的に行うべきだなと改めて感じました。

開発チームが安定したプロダクトマネジメントを実現するための7つのルール

御代田 亮平 氏/LINE株式会社

タイトルの通り、開発チームの7つのルールを用いたプロダクトマネジメントについてのお話。「ownership」や「3つの数字の最大化」など、頭に残りやすい言葉をルールとし、目標達成のためのチームの仕組みを作り上げる考え方は自社のプロダクト開発にも活かせると感じました。中でも「PM=PartyManager」という話が個人的にはとても印象に残っています。

ネットワーキングタイム

懇親会です。食事とともに様々な人と交流できる時間でした。
ネットワーキングタイムは交流と同時に飛び込みLT大会が開催されます。
1人持ち時間5分で15〜20人の方が飛び込みでLTをされていました。

大変、恐れ多いのですが「元人事広報がプロダクトマネジャーを目指して最初の1ヶ月でやったこと」という題目でお話させていただきました。 発表後、何人かの方にお声がけいただき、こういった機会を通じてコミュニティのあたたかさを感じました。貴重な機会をいただき、ありがとうございました。

f:id:yt-tanabe:20171115183913j:plain:w500

その他1:会場の様子

グラフィックレコーディングもありました。
興味のある方はtwitterの#pmconfjp をご覧ください。

お昼はお弁当、疲れの色が出てくる夕方はレッドブルと、
万全のサポート体制で1日中集中してセッションに臨めました。
運営の皆さん、本当にありがとうございます。

その他2:プロダクトマネージャーの略称について

トークセッション中に参加者の方を対象にアンケートを取った結果、プロダクトマネージャーの略称はPMになりました。弊社ではPDMと呼んでいたため、見直しが必要となりました・・・!

Speeeもブーススポンサーとして参加しました

Speeeではコーヒーとクッキーを用意しました。
LTにて告知をさせてもらったこともあり、多くの方が遊びに来てくださいました。

以上、Product Manager Conference 2017の1日目のレポートでした。
繰り返しになりますが、登壇者、運営の皆さん、素敵な場を用意していただき、ありがとうございました。