はじめに
Developers Summit 2019 Summer (Developers Summit 2019 Summer)
愛されるプロダクトをつくるエンジニア組織とは――「テクノロジー」「開発プロセス」との緊密な関係
スピーカー：及川 卓也 [Tably]
の聴講メモです。
Twitterのつぶやきがtogetterでまとめられています。併せてご参照ください。
デブサミ2019夏【A-1】愛されるプロダクトをつくるエンジニア組織とは――「テクノロジー」「開発プロセス」との緊密な関係 #devsumiA #devsumi - Togetter
【参考】としている個所は私が挿入しています（補足や参考資料など）。登壇者の講演内容ではありませんので、その旨ご了承ください。
聴講メモ
個人で起業した。
Tably – テクノロジーによる課題解決と価値創造
現在は技術・製品・組織を軸にコンサルティングを行っている。
製品という軸では、どうしたらプロダクトをユーザが使ってくれるかを考えている。力を入れている分野でもある。
技術・製品のいずれも人が重要となる。組織の大きさに合わせて一緒に課題を考えていく。例えば、スタートアップであれば採用戦略を一緒に考える。大きくなった組織であれば評価なども一緒に考えている。
（及川さんは）愛されるプロダクトという視点で考えるようになった。
Product Manager Conference 2018 のテーマは「愛されるプロダクトを創ろう」だった。
プロダクトマネージャー・カンファレンス 2018
リーン開発の用語で MVP (Minimum Viable Product) が有名だが、海外では MLP (Minimum Lovable Product) が広まりつつある。
【参考】
MVPとMLPの違いを端的に説明した記事がありました。
もうMVPでは通用しない。これからはMLP（Minimum Loveable Product）の時代だ！ - 小さなごちそう
MLPを用いたデザイン手法を採用している、Goodpatch Berlin の Boris Jitsukata 氏へのインタービュー記事はこちらです。
MLP(Minimum Lovable Product)を用いたプロダクトデザイン手法 | Goodpatch Blog
なお、"loveable" と "lovable" のどちらが正しいスペルか？ですが、「小学館 ランダムハウス英和大辞典第2版」では両方掲載されており、同じ意味であるとしています。ここではスペルチェッカーの結果なども踏まえ、"lovable" を採用しました。
"ALL THINGS MUST PASS" はタワーレコードの繁栄と衰退を描いた映画だ。
米国タワーレコードのドキュメンタリー映画『オール・シングス・マスト・パス』DVD発売 - TOWER RECORDS ONLINE
今や、レコード屋が減っている。アナログ（レコード）からデジタル(CD)へフォーマットが変わった。次に、iPod, iTunes のような携帯の時代が来て、さらにサブスクリプションの聴き放題が現れた。このように価値が 所有 → 利用 → 体験 へと変化していった。
若い方はお金を持っていることに価値がなくなってきている。昔は「いつかはクラウン」と言われた時代があった。だが、今は車の所有に対する価値が減っている。所有より体験のサービス化の時代になっている。
この価値観の変化はウェブの存在、そしてスマートフォンがさらに後押しした。
ウェブコンテンツにお金を払うという感覚が無い。少なくとも入口ではお金がかからない。だから、マネタイズを考える必要が出てきた。
この考えが（及川さんが働いていたころの）マイクロソフトの時代にはなかった。製品を売ればよかった。だが、Googleの時代にはウェブでどう収益化すればよいかを考えるようになった。
製品は売ったらそこでユーザとのつながりが切れる。でもサブスクリプションやアプリ内課金は使い続けてもらわないといけない。そのためにはユーザに好きで使ってもらわないといけない。ユーザの選択肢は膨大。だから愛されないといけない。
スマートフォンアプリを出せば使ってもらえるというのは幻想だった。認知してもらい、インストールしてもらい、起動してもらい、使い続けてもらい、紹介してもらわないといけない。
これをAARRRモデルという。
【参考】
AARRRモデルについての説明があります。
グロースハックに重要なAARRRモデルで最も勘違いされがちなこと | リブノバ
不確かなものを確かにする。
同世代でも価値観が違う。マスをターゲットに売るという手法が通用しない。
仮説を立て、素早く検証することを繰り返す。これがリーンの考え方だ。
スタートアップは成功するまでに資金枯渇のリスクがある。それまでに良いトラクション、つまりユーザ獲得の証拠が必要となる。例えば、物を作らず仮説を立ててユーザヒアリングを行う、ペーパーモデルを作って試してもらう、など。
アジャイルとは設計と実装を一体化し、手戻りを許される制御された環境下でサイクルを繰り返すことだ。
DevOpsについて。開発と運用の関係は開発プロセスの進化によって変わってきた。
Windowsなら工場出荷に向けたリリースが終われば、次の製品プランニングまで一息つける期間があった。
だが、Googleでは全く変わった。ユーザーの利用状況がリアルタイムにわかる。使われていない機能があればそこから仮説検証を繰り返して改善していく必要がある。
Windowsのようなエンタープライズ製品はユーザの話を聞きたくてもシステム担当者を介することになり、エンドユーザーに直接ヒアリングすることができなかった。
DevOpsではユーザの利用状況をヒアリングしながら開発サイクルを回す。
日本は真面目に型を学ぼうとする。
Microsoftはウォーターフォールを極めたような会社だった。Googleであっても完全にアジャイルしていたわけではない。ここから言えるのは型が重要なのではなく、その中にある魂ということだ。
今やプロダクトは事業と等しくなっている。
また、エンジニア・デザイナー・マーケティング・サポートなどのマトリクス型チームになっている。
プロダクトマネージャーはプロダクトの成功に責任を持つ。「何(WHAT)を」作るかを決定する。「何故(WHY)」「いつ(WHEN)」作るかも決める。
プロダクトマネージャーはプロダクトチームのCEOといえる。ただし、人事権はない。チームの糊のような存在であり、足りないことは何でもやる。
プロダクトマネージャーはプロダクトの成功に責任を持つ。技術に精通している必要はあるが、作り方を決めてはいけない。それはエンジニアの責任になる。
プロダクトマネージャーは高い志が必要だ。
エンジニアリングマネージャーは自分が製品に貢献するより、組織として貢献することを優先する。
エンジニアはプロダクトを技術的に実現することに責任を持つ。「どうやって(HOW)」に責任を持ち、アイデアを実現させる。
プロダクトマネージャー・エンジニアリングマネージャー・エンジニアは別の職種だ。他の職種に移るのは異動に等しい。
職種を明確にするのをジョブ型雇用という。
これまでの日本はメンバーシップ型雇用だった。今はジョブ型雇用へ徐々に移行している。
【参考】
ジョブ型・メンバーシップ型の一つの定義として資料から引用します。
「ジョブ型」：職務、労働時間、勤務地が原則限定される。欠員補充で就「職」、職務消滅は最も正当な解雇理由。欧米アジア諸国すべてこちら。日本の実定法も本来ジョブ型。
https://www.kantei.go.jp/jp/singi/keizaisaisei/bunka/koyou_hearing/dai1/siryou2.pdf
「メンバーシップ型」：職務、労働時間、勤務地が原則無限定。新卒一括採用で「入社」、社内に配転可能である限り解雇は正当とされにくい。一方、残業拒否、配転拒否は解雇の正当な理由。実定法規定にかかわらず、労使慣行として発達したものが判例法理として確立。
上位エンジニアの役割にテックリード(TL)がある。後輩の育成や採用への協力など。
エンジニアだが、例外的にエンジニアリングマネージャーの一部を兼務することがある。少数のメンバーをマネジメントするなど。
マネージャーはエンジニアを評価せねばならず、そのためには技術のバックグラウンドも必要となる。
【参考】
講演では職能別組織・事業部制組織・マトリックス組織の話が出ていました。以下の資料が参考になります。
http://www.waseda.jp/sem-inoue/file/org2011/(17)Functional&divisional2011.pdf
ジョブディスクリプションを作成したほうがよい。やるべきことを文章化する。
ただ、最初は抜け漏れが起こりやすい。なので、リバースエンジニアリングのように、今やっていることから書き出すことも組み合わせたほうがよい。
多能工か単能工か。
全ての業務を少しでも経験することが必要だ。例えば運用経験が開発に生きてくる。
スクラップ＆ビルド。壊れないシステムではなく、すぐに復旧できるシステムを目指す。
ドキュメントもよいが、陳腐化するリスクがある。それよりもコードで記述する。
身の丈に合わない開発をすると運用できなくなるケースがある。
そうしたものを省いていった結果がSaaSなどにつながる。
マイクロサービスは各サービスを好きに作って良いというわけではない。共通基盤や規律をベースに作る。自由というより柔軟性だ。
そこからプロダクトとして何を産み出せるかを考えないといけない。
プロダクトマネージャーは事業サイドと開発サイドの調整役ではない。事業サイドと開発サイドの間に対等な関係を作らねばならない。
愛されるプロダクトのため、プロジェクトマネージャーが企画を温めるだけでなく、チーム全員が考えないといけない。
コードの1行ごとに事業やユーザに対してどんな価値を生み出すかを考えないといけない。エンジニアの自己満足ではいけない。
発表スライドより。
コードの向こうにユーザーを見る
「事業部門に属するメンバーの職務は、全員がまったく同じであります。それは製品を出荷することです。コードを書くことでも、テストをすることでも、仕様書を書くことでもありません。製品を出荷することが仕事なのです。コードを書こうなどと考えることすら避けるべきでしょう。コードを書かずに稼げるのであれば、是非そうしたいものであります。」
元Microsoft VP Chris Peters氏「自分が書いているコードの価値がどこにつながるのかを考えてみようということです。社内のスタッフの作業が効率化するとか、ユーザーに違う体験を与えられるとか。必ず何かにつながっている。目標を決める時に、その技術を使うことでどんな価値につながるのかを考えてもらうようにしています。」
WAmazing 共同創立者 CTO 舘野祐一氏
日本のエンジニアにはユーザにプロダクトを愛してもらいたい、という情熱が少ない。
自分の製品を使ってもらえてうれしいという体験をしてほしい。それがエンジニアのパッションにつながる。
ユーザに愛し続けてもらえるプロダクト作りを目指して欲しい。
