Slide 1

Slide 1 text

1 エンジニアが事業責任者になる メリットとデメリット なぜエンジニアが事業責任者を志向するのか 柳川 慶太

Slide 2

Slide 2 text

2 自己紹介 所属 BASE 株式会社 BASE BANKチーム PdM 事業責任者 経歴 SIer→広告配信システム→BASEエンジニア→BASE BANK PdM 最初のエンジニアとしてBASEBANKに参加し、現在まで関わる キーワード 新規事業 プロダクト開発 設計 組織開発 PDCA みんなでアジャイル ストーリーテリング 趣味 アクアリウム 園芸 ファッション 音楽 SNS     Twitter : @gimupop 柳川慶太 (やながわ けいた)

Slide 3

Slide 3 text

3 キャッシュフローのコントロール = 経営 この10年でECが簡単に開けるは常識になりました でもすべての立ち上がったECが成功するわけではない ECは簡単になっても経営の難しさは変わっていません BASEBANKはキャッシュフローのコントロール側面から ショップをエンパワメントし経営をサポートし 誰でもやりたいことがやりやすくなる社会に貢献します 「銀行をかんたんにし、全ての人が挑戦できる世の中に」 担当している事業の説明を簡単に

Slide 4

Slide 4 text

4 担当している事業の説明を簡単に 現在は、即座に資金調達ができる「YELL BANK」、ショップの売上がそのまま支払いに使える「BASEカード」、 最短翌営業日に売上金が振り込まれる「お急ぎ振込」を提供しています。 3つのサービスで総合的に加盟店のお金周りのサポートをしています。 3つの提供サービス 振込申請 BASEカード YELL BANK かんたん、即座に資金調達が可能 売上をそのままお即時に支払いに使える 最短翌営業日に売上を振込 

Slide 5

Slide 5 text

5 直近こういう記事も書きました https://note.com/base_group/n/nd447f09de42a BASEグループ公式noteです。よろしければご確認ください

Slide 6

Slide 6 text

6 1 2 3 バックグラウンドと意思 エンジニアが事業責任者になると信用の ショートカットができる プロダクト開発 ざっくりメニュー

Slide 7

Slide 7 text

7 エンジニアから 新規事業立ち上げと事業責任者 と変化した人間の一つの類型として 見ていただけますと幸いです

Slide 8

Slide 8 text

8 バックグラウンドと意思

Slide 9

Slide 9 text

9 新規事業の開発に携わり4年 プロダクトマネージャーになり3年 事業責任者になり2年ほど経過しました

Slide 10

Slide 10 text

10 僕の仕事に対する初期衝動としては 納得したことしかやりたくない 理屈の通らないことはしたくない 世の中にポジティブな影響を最大限出していきたい 仕事は仕事と割り切れない かなり傲慢でわがままなものでした

Slide 11

Slide 11 text

11 なので現職までで短期で2回転職しています 受託開発だと意思を反映しにくい 自社開発でも社内受託のような状況が起きうる その経験を経ての現職でした

Slide 12

Slide 12 text

12 しかもタイミングよく新規事業が始まりました なんとしても参加したくて アピールしました 新規プロダクトの仕様のヒアリングをして勝手に設計してみたり そういうことをしていました

Slide 13

Slide 13 text

13 そしてエンジニアとして新規プロダクトに関わる中で 更に影響範囲を広げたいと思うようになりました 「どんなチームでどんな価値を届けるのか」 そこにコミットしたいと考えました

Slide 14

Slide 14 text

14 職種によるスペシャリティはあります でもプロダクトを作るということの前に置いては平等です よりプロダクトづくりのコアをリードできるように どんどんさかのぼっていく中で 気がついたら事業責任者を志向していました

Slide 15

Slide 15 text

15 エンジニアが事業責任者になると 信用のショートカットができる

Slide 16

Slide 16 text

16 事業というのは双方向の信用のやり取りが 絶えずいろいろなところでなされることにより 進行していきます

Slide 17

Slide 17 text

17 エンジニアが事業責任者になると 無意識でしたが ステイクホルダー間の 信用のショートカット という側面があります

Slide 18

Slide 18 text

18 [洗練中]信用の委託の図 エンジニア デザイナー Biz オペレーション 事業責任者 経営 株主 ユーザー PdM 現場 事業数字 実行 エンジニア経験を通して 工数の決めの細かいところまでわかる PdMの経験を通してユーザーの要望の反映の勘所がわかる どういう組織で実行していけばうまくいくかの勘所が分かる 経営とのPLを介しての数字のやり取りがわかるので 投資とリターンの期待値調整ができる

Slide 19

Slide 19 text

19 要するに プロダクトをどう作るかと 金をどこから持ってくるか 両方わかれば話しが早いのでは ということを考えた なので事業責任者を目指したという自己分析があります

Slide 20

Slide 20 text

20 現場に対する打ち手を はずさない メリット

Slide 21

Slide 21 text

21 現チームの役割 「より早くプロダクトを成長させること」を重視してそれぞれの役割を設置しています。 プロダクトのフェーズによって必要な役割は変化していくため、適時見直しを行っています。 PMM プロダクトマーケティングマネージャーです。プロダクトグロースのための、施策の企画、実行、振り返りを 行っています。各サービスにつき1名の体制を目指しています。 PdM プロダクトマネージャーです。事業計画と、それを達成するための企画立案と仕様策定、推進を行っています。 現在はBASE BANK全体で1名です。 デザイナー ユーザーの課題は何かをPdMと共に考えてUI/UXデザインに落とし込む役割を担っています。 現在はBASE BANKで1名です。 EPM Engineering Program Managerです。サービスのデリバリーとクオリティに責任を持つ役割です。 各サービスにつき1名です。 エンジニア フルサイクルエンジニアとして、サービス開発から運用までの全行程に関わります。 各サービスに4名以上の体制を目指しています。

Slide 22

Slide 22 text

22 特にPdMの仕事を PMMとEPMに分割したのはうまく行っていると感じます PdMの仕事の範囲は放っておくと際限なく広がります プロダクトフェーズや特性に合わせて 切り分けるべきと考えています

Slide 23

Slide 23 text

23 誰もが最初から何でもはできないので あえてスコープを狭める スコープを狭める中で確実に成果を出して 徐々にスコープを広げていく つまりPDCAを基礎にやれることを広げていく 非常に大事なポイントだと思っています

Slide 24

Slide 24 text

24 みんなでアジャイル アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践あるいは実践を手助けする活動を通じて、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。 すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 https://agilemanifesto.org/iso/ja/manifesto.html ちょうどチームについて考えるタイミングでこの本がでたので読みました。 正直アジャイルとかスクラムとか形から入るというイメージが合って苦手だったのですが、 この本は本質的な考え方の本で職種に閉じない形の志向を持っているところが良いなと思いました。 アジャイルはムーブメントであるというのが金言ですね。アジャイルというムーブメントを作りたい。 そしてなんやかんやアジャイルソフトウェア宣言がいい。

Slide 25

Slide 25 text

25 話が早い メリット

Slide 26

Slide 26 text

26 全体が分かるので決断が早い どこかで止まることもない とにかく早い

Slide 27

Slide 27 text

27 スケールの限界がある デメリット

Slide 28

Slide 28 text

28 早く行きたいなら一人で 遠くに行きたいならみんなで

Slide 29

Slide 29 text

29 そもそもこうなるのが大変 デメリット

Slide 30

Slide 30 text

30 領域を広げていくのはしんどいし 機会も運もある 再現性がない

Slide 31

Slide 31 text

31 次に行くにはやり方を 変えないといけない

Slide 32

Slide 32 text

32 これからやりたいこと

Slide 33

Slide 33 text

33 より強固でスケールする プロダクト開発「組織」ができることを 設計する 環境を作る

Slide 34

Slide 34 text

34 プロダクト開発はとても難しい 暗中模索の連続 その中でも新規事業は更に難しい 変数も多い 誰も正解はわからない

Slide 35

Slide 35 text

35 そのようなかで 何を作るか 誰と作るか どう作るか

Slide 36

Slide 36 text

36 不確実性の連続をどう乗りこなすか

Slide 37

Slide 37 text

37 予定通りに作れるかわからない 作っても使われるかわからない ちゃんとデリバリーできてかつ ちゃんと使われるのは 奇跡みたいなもの

Slide 38

Slide 38 text

38 でもプロダクトを作ることで価値提供するプロとして デリバリーとクオリティの精度を上げていくことから 逃げてはいけない

Slide 39

Slide 39 text

39 どういうプロダクトや施策がヒットするかはわからないが チームとしての進化は 続けていかないといけない それがプロダクト開発のプロ集団

Slide 40

Slide 40 text

40 どう挑めばいいか 細かく振り返りながら 手を取り 進んでいく他ない

Slide 41

Slide 41 text

41 不確実性に向き合える 良い習慣を持った いいチームを作る これしかない

Slide 42

Slide 42 text

42 職種によらず 全職種 全ステークホルダ一丸で挑む

Slide 43

Slide 43 text

43 フィードバックループに価値を置く開発プロセス 各チームが独立してイテレーションを回しながらも、開発状況やそれぞれ得たプラクティスを共有する場を設けています。 イテレーション駆動開発 ● 現在は各チーム2週間のイテレーションに区切り、 チームやプロダクトに対するフィードバックループを 回しています チーム横断の知見、情報共有の場 ● チーム横断のDaily StandingやYOT* で開発状況や チーム運営のプラクティスを共有し、各チームが独立 してイテレーションを回すメリットを最大限に享受す るための取り組みを行っています * 「出来事ベースでお気持ちを話しやすい振り返りワーク「YOT」」 https://devblog.thebase.in/entry/yot 振込申請 Product Back Log Sprint Back Log Sprint Planning Sprint Review Retrospective Daily Scrum Backlog Refinement 2 Week 障害対応 顧客問い合わせ チーム横断のDaily Scrum などの協働 Next Sprint BASE BANK YOT

Slide 44

Slide 44 text

44 そういう構造を作っていくためには事業責任者になって 引っ張っていくのが一番いい選択肢だと考えました ただしここから更に伸ばしていくためには 事業責任者になって得たことを 還元していく必要があります

Slide 45

Slide 45 text

45 [洗練中]信用の委託の図 ここに着目した発表をpmconf2023でしたく言語化の最中 エンジニア デザイナー Biz オペレーション 事業責任者 経営 株主 ユーザー PdM 現場 事業数字 実行 エンジニア経験を通して 工数の決めの細かいところまでわかる PdMの経験を通してユーザーの要望の反映の勘所がわかる どういう組織で実行していけばうまくいくかの勘所が分かる 経営とのPLを介しての数字のやり取りがわかるので 投資とリターンの期待値調整ができる

Slide 46

Slide 46 text

46 FB それは愛

Slide 47

Slide 47 text

47 日々の開発だけでなく みんながみんなに向き合える組織 挑戦し続けられる組織

Slide 48

Slide 48 text

48 生存性バイアスもあると思うが 打席に立つことの重要性はあると感じている 抜擢が起こりサポートが生まれる環境を作る 当たり前だが やらないとできない

Slide 49

Slide 49 text

49 一番大切にしているのは 「やれる感」 ユーザーにも良い循環を チームにも良い循環を

Slide 50

Slide 50 text

50 事業としても良い循環をつくる チームの成長と事業の成長の反復横とびを繰り返して 成長していくしかないと思っています

Slide 51

Slide 51 text

51 僕自身がいい経験をつめていると思うからこそ それを伝播させていきたいと思っています

Slide 52

Slide 52 text

52 再現性のために信頼のメカニズムを体系化していく必要があります 体系化してpmconf2023を始めとして いろいろなところで話す 僕個人的には発表等のアウトプットが思想を洗練させるために 良い手段になっている

Slide 53

Slide 53 text

53 どうしてこの話が通じないのだろうかとか 無関心なのではないのだろうかとか 過干渉なのではないのだろうかとか そういうことをできるだけなくしたい なくしたいというよりはそれで終わってしまうことをなくしたい

Slide 54

Slide 54 text

54 組織の大きさも扱う問題の大きさも日々変わりますが みんなでワイワイプロダクト開発が 天職だと思っていますので みんなのパワーを結集できるように 引き続きやっていきます

Slide 55

Slide 55 text

55 プロダクトの思想にも連なりますが みんなやればできるというのを大切にしたい 自信がある人が溢れる社会にしたい オーナーズを増やしたい

Slide 56

Slide 56 text

56 終わり