エンジニアが事業責任者になるメリットとデメリット

Transcript

1. 1 エンジニアが事業責任者になる メリットとデメリット なぜエンジニアが事業責任者を志向するのか 柳川 慶太
2. 2 自己紹介 所属 BASE 株式会社 BASE BANKチーム PdM 事業責任者 経歴 SIer→広告配信システム→BASEエンジニア→BASE BANK PdM 最初のエンジニアとしてBASEBANKに参加し、現在まで関わる キーワード 新規事業 プロダクト開発 設計 組織開発 PDCA みんなでアジャイル ストーリーテリング 趣味 アクアリウム 園芸 ファッション 音楽 SNS　　 　　Twitter : @gimupop 柳川慶太 (やながわ けいた）
3. 3 キャッシュフローのコントロール = 経営 この10年でECが簡単に開けるは常識になりました でもすべての立ち上がったECが成功するわけではない ECは簡単になっても経営の難しさは変わっていません BASEBANKはキャッシュフローのコントロール側面から ショップをエンパワメントし経営をサポートし 誰でもやりたいことがやりやすくなる社会に貢献します 「銀行をかんたんにし、全ての人が挑戦できる世の中に」 担当している事業の説明を簡単に
4. 4 担当している事業の説明を簡単に 現在は、即座に資金調達ができる「YELL BANK」、ショップの売上がそのまま支払いに使える「BASEカード」、 最短翌営業日に売上金が振り込まれる「お急ぎ振込」を提供しています。 3つのサービスで総合的に加盟店のお金周りのサポートをしています。 3つの提供サービス 振込申請 BASEカード YELL BANK かんたん、即座に資金調達が可能 売上をそのままお即時に支払いに使える 最短翌営業日に売上を振込　
5. 5 直近こういう記事も書きました https://note.com/base_group/n/nd447f09de42a BASEグループ公式noteです。よろしければご確認ください
6. 6 1 2 3 バックグラウンドと意思 エンジニアが事業責任者になると信用の ショートカットができる プロダクト開発 ざっくりメニュー
7. 7 エンジニアから 新規事業立ち上げと事業責任者 と変化した人間の一つの類型として 見ていただけますと幸いです
8. 8 バックグラウンドと意思
9. 9 新規事業の開発に携わり4年 プロダクトマネージャーになり3年 事業責任者になり2年ほど経過しました
10. 10 僕の仕事に対する初期衝動としては 納得したことしかやりたくない 理屈の通らないことはしたくない 世の中にポジティブな影響を最大限出していきたい 仕事は仕事と割り切れない かなり傲慢でわがままなものでした
11. 11 なので現職までで短期で2回転職しています 受託開発だと意思を反映しにくい 自社開発でも社内受託のような状況が起きうる その経験を経ての現職でした
12. 12 しかもタイミングよく新規事業が始まりました なんとしても参加したくて アピールしました 新規プロダクトの仕様のヒアリングをして勝手に設計してみたり そういうことをしていました
13. 13 そしてエンジニアとして新規プロダクトに関わる中で 更に影響範囲を広げたいと思うようになりました 「どんなチームでどんな価値を届けるのか」 そこにコミットしたいと考えました
14. 14 職種によるスペシャリティはあります でもプロダクトを作るということの前に置いては平等です よりプロダクトづくりのコアをリードできるように どんどんさかのぼっていく中で 気がついたら事業責任者を志向していました
15. 15 エンジニアが事業責任者になると 信用のショートカットができる
16. 16 事業というのは双方向の信用のやり取りが 絶えずいろいろなところでなされることにより 進行していきます
17. 17 エンジニアが事業責任者になると 無意識でしたが ステイクホルダー間の 信用のショートカット という側面があります
18. 18 [洗練中]信用の委託の図 エンジニア デザイナー Biz オペレーション 事業責任者 経営 株主 ユーザー PdM 現場 事業数字 実行 エンジニア経験を通して 工数の決めの細かいところまでわかる PdMの経験を通してユーザーの要望の反映の勘所がわかる どういう組織で実行していけばうまくいくかの勘所が分かる 経営とのPLを介しての数字のやり取りがわかるので 投資とリターンの期待値調整ができる
19. 19 要するに プロダクトをどう作るかと 金をどこから持ってくるか 両方わかれば話しが早いのでは ということを考えた なので事業責任者を目指したという自己分析があります
20. 20 現場に対する打ち手を はずさない メリット
21. 21 現チームの役割 「より早くプロダクトを成長させること」を重視してそれぞれの役割を設置しています。 プロダクトのフェーズによって必要な役割は変化していくため、適時見直しを行っています。 PMM プロダクトマーケティングマネージャーです。プロダクトグロースのための、施策の企画、実行、振り返りを 行っています。各サービスにつき1名の体制を目指しています。 PdM プロダクトマネージャーです。事業計画と、それを達成するための企画立案と仕様策定、推進を行っています。 現在はBASE BANK全体で1名です。 デザイナー ユーザーの課題は何かをPdMと共に考えてUI/UXデザインに落とし込む役割を担っています。 現在はBASE BANKで1名です。 EPM Engineering Program Managerです。サービスのデリバリーとクオリティに責任を持つ役割です。 各サービスにつき1名です。 エンジニア フルサイクルエンジニアとして、サービス開発から運用までの全行程に関わります。 各サービスに4名以上の体制を目指しています。
22. 22 特にPdMの仕事を PMMとEPMに分割したのはうまく行っていると感じます PdMの仕事の範囲は放っておくと際限なく広がります プロダクトフェーズや特性に合わせて 切り分けるべきと考えています
23. 23 誰もが最初から何でもはできないので あえてスコープを狭める スコープを狭める中で確実に成果を出して 徐々にスコープを広げていく つまりPDCAを基礎にやれることを広げていく 非常に大事なポイントだと思っています
24. 24 みんなでアジャイル アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践あるいは実践を手助けする活動を通じて、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。 すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 https://agilemanifesto.org/iso/ja/manifesto.html ちょうどチームについて考えるタイミングでこの本がでたので読みました。 正直アジャイルとかスクラムとか形から入るというイメージが合って苦手だったのですが、 この本は本質的な考え方の本で職種に閉じない形の志向を持っているところが良いなと思いました。 アジャイルはムーブメントであるというのが金言ですね。アジャイルというムーブメントを作りたい。 そしてなんやかんやアジャイルソフトウェア宣言がいい。
25. 25 話が早い メリット
26. 26 全体が分かるので決断が早い どこかで止まることもない とにかく早い
27. 27 スケールの限界がある デメリット
28. 28 早く行きたいなら一人で 遠くに行きたいならみんなで
29. 29 そもそもこうなるのが大変 デメリット
30. 30 領域を広げていくのはしんどいし 機会も運もある 再現性がない
31. 31 次に行くにはやり方を 変えないといけない
32. 32 これからやりたいこと
33. 33 より強固でスケールする プロダクト開発「組織」ができることを 設計する 環境を作る
34. 34 プロダクト開発はとても難しい 暗中模索の連続 その中でも新規事業は更に難しい 変数も多い 誰も正解はわからない
35. 35 そのようなかで 何を作るか 誰と作るか どう作るか
36. 36 不確実性の連続をどう乗りこなすか
37. 37 予定通りに作れるかわからない 作っても使われるかわからない ちゃんとデリバリーできてかつ ちゃんと使われるのは 奇跡みたいなもの
38. 38 でもプロダクトを作ることで価値提供するプロとして デリバリーとクオリティの精度を上げていくことから 逃げてはいけない
39. 39 どういうプロダクトや施策がヒットするかはわからないが チームとしての進化は 続けていかないといけない それがプロダクト開発のプロ集団
40. 40 どう挑めばいいか 細かく振り返りながら 手を取り 進んでいく他ない
41. 41 不確実性に向き合える 良い習慣を持った いいチームを作る これしかない
42. 42 職種によらず 全職種 全ステークホルダ一丸で挑む
43. 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
44. 44 そういう構造を作っていくためには事業責任者になって 引っ張っていくのが一番いい選択肢だと考えました ただしここから更に伸ばしていくためには 事業責任者になって得たことを 還元していく必要があります
45. 45 [洗練中]信用の委託の図　ここに着目した発表をpmconf2023でしたく言語化の最中 エンジニア デザイナー Biz オペレーション 事業責任者 経営 株主 ユーザー PdM 現場 事業数字 実行 エンジニア経験を通して 工数の決めの細かいところまでわかる PdMの経験を通してユーザーの要望の反映の勘所がわかる どういう組織で実行していけばうまくいくかの勘所が分かる 経営とのPLを介しての数字のやり取りがわかるので 投資とリターンの期待値調整ができる
46. 46 FB それは愛
47. 47 日々の開発だけでなく みんながみんなに向き合える組織 挑戦し続けられる組織
48. 48 生存性バイアスもあると思うが 打席に立つことの重要性はあると感じている 抜擢が起こりサポートが生まれる環境を作る 当たり前だが やらないとできない
49. 49 一番大切にしているのは 「やれる感」 ユーザーにも良い循環を チームにも良い循環を
50. 50 事業としても良い循環をつくる チームの成長と事業の成長の反復横とびを繰り返して 成長していくしかないと思っています
51. 51 僕自身がいい経験をつめていると思うからこそ それを伝播させていきたいと思っています
52. 52 再現性のために信頼のメカニズムを体系化していく必要があります 体系化してpmconf2023を始めとして いろいろなところで話す 僕個人的には発表等のアウトプットが思想を洗練させるために 良い手段になっている
53. 53 どうしてこの話が通じないのだろうかとか 無関心なのではないのだろうかとか 過干渉なのではないのだろうかとか そういうことをできるだけなくしたい なくしたいというよりはそれで終わってしまうことをなくしたい
54. 54 組織の大きさも扱う問題の大きさも日々変わりますが みんなでワイワイプロダクト開発が 天職だと思っていますので みんなのパワーを結集できるように 引き続きやっていきます
55. 55 プロダクトの思想にも連なりますが みんなやればできるというのを大切にしたい 自信がある人が溢れる社会にしたい オーナーズを増やしたい
56. 56 終わり