チームだからこそ「僕はやれる」感を醸成できて乗り越えられる　いちエンジニアが事業責任者になって考えていること

柳川氏の自己紹介

柳川慶太氏（以下、柳川）：柳川です。発表します。タイトルが「私の履歴書」みたいな感じでかなりインパクトのあるというか、即時的な内容の話にはなってしまいますが、僕がエンジニアから事業責任者に変遷した1つの類型として、いろいろ起きたことや考えていたことを話せたらなと思います。よろしくお願いします。

（スライドを示して）最初に自己紹介をします。僕は今は、BASE株式会社という会社で「BASE BANK」という金融系事業をやっているチームで、プロダクトマネージャーと事業責任者をしています。

経歴は、もともと受託開発の会社でエンジニアをしていましたが、そこから変遷して広告配信システムを作る会社を経て、BASEに参画しています。

キーワードはいろいろ書いていますが、最近僕の中でホットな話は、ストーリーテリングみたいなもので、最近「会社で起きていることや、プロダクトの事業上の立ち位置を話すことがもしかして得意なのかも」と気づいて、けっこう積極的に発信するようにしています。

趣味はアクアリウムや園芸、変数の多いものをコントロールするのが好きです。仕事にも通じているのかなと思っています。そういう感じの人間です。

（スライドを示して）本当に簡単にですが、担当している事業の説明です。我々BASEはECを簡単に提供する会社です。ECを使ってくれているショップオーナーさん向けに、その会社がキャッシュフローをコントロールできる手段。（スライドに）「キャッシュフローのコントロール＝経営」と書いてありますが、自分のショップをどう伸ばすかという柔軟な手段を提供しています。

（スライドを示して）「3プロダクトぐらいありますよ」ということでプロダクトの説明は飛ばしていきます。

直近の事業の話を書いたnoteもあるので、もし興味があれば見てもらえるとうれしいです。

エンジニアから事業責任者に変遷していった過程

（スライドを示して）ざっくりメニューです。1番にバックグラウンド系の話、2番は具体的にうまくいったことと難しかったこと系の話で、3番はプロダクト開発全般の話をしようと思っています。

最初に話しましたが、1つの類型として温かい目で見てもらえるとうれしいです。

バックグラウンドと意思です。新規事業の開発に携わって4年、プロダクトマネージャーになって3年、事業責任者になって2年という感じのプロフィールになっています。

もともとSIerから始まった話ですが、仕事に対する初期衝動としては、（僕は）けっこう頑固な部分もあって、納得したことしかやりたくないし、理屈のとおらないこともやりたくない。でも世の中にポジティブな影響を最大限出していきたいなと思い、かなりもがきながら進んできた半生だったかなと思います。

現職までで2回転職していますが、これも先ほど言ったポリシーみたいなところにかなり則ってやっています。「受託開発だとなかなか意思は反映しにくいんだな」みたいなことを感じて、2社目で「自社の開発でも、社内のパワーバランスによっては社内受託みたいな状況はけっこう起こり得るんだな」とすごく感じて、その経験を経ての現職になっています。

現職に入ったタイミングはエンジニアをやっていて。（その時は）タイミング良く新規事業が始まることになり最初のエンジニアを募集している段階だったのですが、すごく参加したいなと思いました。

今まで（の仕事で）みなさんが作ってくれた土台の中でいろいろバリューを発揮しようとやってきましたが、自分でゼロから土台を作るところから関わっていくことをすごくやりたいなと思っていました。

なんとしても参加したくて、新規プロダクトの仕様のヒアリングを勝手にして、「これはこういう感じで実現していくのがいいんじゃないですか」みたいなプレゼンをしながら参加させてもらいました。

エンジニアとして新規プロダクト開発に関わる中で、手を動かして作るのもすごく楽しかったのですが、さらに影響範囲を広げたいと思うようになりました。「どんなチームでどんな価値を届けるか」ということにコミットしたいと考えるようになりました。

プロダクト開発をする上で職種によるスペシャリティは確実にありますが、“プロダクトを作る”という板の前においてはすごく平等というか、それぞれの職種のスペシャリティをうまく発揮するという意味で、平等だと思っています。

そんな中でよりプロダクト作りをリードできるように、プロダクト作りの工程の中をどんどんさかのぼっていく中で、気がついたら事業責任者みたいなポジションを志向していました。

プロダクト作りの中でうまくいったこと

（事業責任者として）うまくいったことと難しかったことです。うまくいったことは、まずチームを作ることにも最初からコストをある程度かけていました。BASE BANKのチームは今は15名ぐらいですが、それにしてはけっこう役割が多く割り振られているようなところがあります。

考え方は、やれることの守備範囲がある程度決まっている中で、そこをこなしていきながら広げていくほうがスムーズだと自分の経験からすごく感じていたので、ある程度各職種の役割、どの人がどの職種でどういう役割かを細かく定義することにこだわっていました。

特に、プロダクトマネージャーの仕事を、PMMと呼ばれるプロダクトマーケティングマネージャーと、EPMと呼ばれるエンジニアリングプログラムマネージャーに分割をしたのは直近でうまくいっているなと感じています。

プロダクトマネージャーの仕事の範囲は、放っておくと本当に際限なく広がるというか、「あれも、これも、それも、どれもプロダクトマネージャーの仕事じゃない？」みたいな感じになったりします。しかし、プロダクトのフェーズや特性に合わせて切り分けたほうが、バリューを発揮できるんじゃないかなと考えています。

EPMの話はこのあと僕の同僚が発表するので、それも聞いてもらえたらと思います。

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

2番は『みんなでアジャイル』を手本にしたことです。『みんなでアジャイル』は個人的にメチャクチャ良い本だと思っています。正直僕はアジャイルやスクラムはかたちから入るイメージがけっこうあって、「こういう決められたこのイベントをやらなきゃいけないんだよ」みたいな感じで、すごく窮屈なものだと認識していました。

ちょうどチームを考えるタイミングでこの本が出たので読みました。アジャイルの話は「チームを巻き込んで、ふりかえって不確実性と闘っていく」とありました。「アジャイルというムーブメント」みたいな言葉がこの本には出てくるのですが、「なるほど。行動ではなくてムーブメントなんだな」みたいなことがすごくしっくりきて、自分たちでもやりたいなと思い、すごく参考にして組織や日々のチームをやっています。

「アジャイルソフトウェア開発宣言」というものがあって、それがこの本のすべてかなと思って。「なるほど。良いことが書いてあるな」と読む度に思っています。

プロダクト作りの中で苦戦したこと

逆に苦戦したことは、予算を取りに行く感覚を覚えるのにすごく時間がかかったことです。やはりこれはエンジニア出身というのもあると思いますが、どうプロダクトをデリバリーするかみたいな感覚は（もともと）ありましたが、それを実現するために予算を取りに行くところはかなりギャップを感じました。

今もかなり苦戦しているところですが、これもPDCAのPの部分がすごく強くなったものかなと思っています。誰にでもわかりやすく自分たちがやりたいことを説明する。ここに尽きるなと思っています。ここのスキルはやれたほうがいいなと思って、苦しみながらやっている状態です。

この部分についてもフィードバックをもらいながら改善していきます。

苦戦したこと2（番目）です。エンジニアのバックグラウンドに頼り過ぎていた部分があるかなと思いました。プロダクト開発の細かいところまでけっこうわかってしまうがゆえに、いわゆる自分でやったほうが早い問題というか、仕切るところにけっこうちょっかいを出して入ってしまうみたいなことがありますが、それはやはり徐々に離していかなければいけないなと日々感じています。

アクションとしては、縦兼務をなくしました。縦兼務とは下位組織のマネージャーの兼務（のこと）です。

これをやると自分の目で見る範囲が広がるだけなので、けっこう楽なんですね。確かに自分はちょっと忙しくなりますが、安心感という意味ではすごく楽です。

しかし、縦兼務は中間のマネージャーが育成できないこととほぼ同義だと思っていて、マネージャーの育成に向き合ってスケールアップすることに、ちゃんと取り組むようにしました。そのほうが難易度が高くて、（でも）よりレバレッジが効くことだとなんとなく気づき始めたので、より強いチームになってみんなで遠くに行くために、それを実際にやりました。

プロダクト開発はプロセスにこだわることも大事

最後にプロダクト開発全般の話をします。プロジェクト開発はみなさんやっていると思いますが、やはりやればやるほどすごく難しいものだなと感じています。本当に暗中模索の連続で、パラメータもすごく多いし、何をもって成功したとするかがすごく難しいし、そのタイムラインも変わってくる。すごく難しいものだなと思っています。

その中でも新規事業はあるかないかもわからない需要に突っ込んでいくということで、本当に難しいと日々感じています。

そのような中で何を作るか、誰と作るか、どう作るかにこだわることはすごく大事です。結果にこだわることも大事ですが、なんだかんだプロセスにこだわることもすごく大事なのかなと思っています。

不確実性の連続をどう乗りこなすかということで、予定どおりに作れるかわからないし、作っても使われるかわかりません。きちんとデリバリーできて、かつきちんと使われることは、当たり前のようでいて奇跡みたいなことなんだなと日々感じています。

でも我々はプロダクトを作ることで価値を提供するプロとして、そういう職能として仕事をしていると思っています。それはプロダクトマネージャーでもエンジニアでもデザイナーでも、プロダクトに関わる以上は当然そうだと思っています。なので、デリバリーとクオリティの精度をどんどん上げていく。以前より上げていくことから逃げてはいけないと日々感じています。

どういうプロダクトや施策がヒットするかはわからないことですが、チームとしての進化にこだわって続けていかないといけません。それがプロダクト開発のプロ集団だと思っています。

それにどう挑めばいいか。やはりここは本当にアジャイルの考え方がすごく助けになると思っていて、細かくふりかえりをしながら、手を取りながら進んでいく他ないかなと思っています。

そういうことがインストールされた「不確実性に向き合える良い習慣を持ったいいチームを作る」ところにこだわっていく。事業の責任者としても、やはりそこに一貫性を持ってこだわっていくことがすごく大事だなと思っています。

職種によらず全職種、全ステークホルダーです。

そういう構造を作っていくためには、プロダクト開発の解像度が高い人間が事業責任者になって引っ張っていくのが、一番良い選択肢だと僕は考えています。かなり傲慢な考え方か（もしれない）とも思うのですが、僕も細かくいろいろチャレンジをして成功と失敗を積み上げていく中で、「実態を持った傲慢さなのでOKだ」と自分の中では解釈しています（笑）。

ポジションを取って進めていくことを、これからもやっていきたいなと思っています。

実際に我々のチームでもフィードバックループに価値を置く開発プロセスをやっていて、あえて“イテレーション駆動開発”という言い方をしています。アジャイルやスクラムという言い方ではなくて「ふりかえりの質を上げるために、日々僕たちは何をやっていったらいいんだろうね」ということを話しながらチーム運営をしています。

なので、あえてプロダクトごとにチームをある程度きちんと分けて、合流地点は合流地点で作ることを工夫してやっています。

フィードバックに価値を置く開発プロセス

フィードバックです。（スライドを示して）「FB それは愛」と書いてあるのですが、日々の開発だけでなく、みんながみんなに向き合える組織を作っていくこともすごく大事かなと思っています。そのためのアジャイルの考え方やプラクティスは大きな力になると思っています。

フィードバックはけっこうしんどいです。言いたくないことも言わなきゃいけない、相手に伝わるように考えてやらないといけないという意味で、フィードバックはするほうもしんどいし、受けるほうもしんどいです。

でも、それが自然にできる組織はすごく良い組織だなと運営して思っています。みんながみんなに向き合える組織、挑戦し続けられる組織を、アジャイルのプラクティスを参考にしながらやっていきたいなと思っています。

一番大切にしているのは「『僕はやれる』感」

生存性バイアスもあると思いますが、打席に立つことの重要性はすごく感じていて。抜擢ですよね。当たり前ですが、やってみないとそれができるかわからないと思っています。

僕もプロダクトマネージャーや事業責任者をやってみるまではできないと思っていて、それに挑戦させてくれたことにすごく感謝している部分があります。抜擢が起こり、サポートが生まれる環境を、僕も作っていかなきゃいけないと思ってチームを運営しています。

一番大切にしているのは、「『僕はやれる』感」です。1人で考えていると「あれもこれも難しくてできないよ」と思ってしまうことが、チームの中で「やれる感」を醸成して乗り越えていけることがすごく大事だし、チームで何かものをやっていくことの良い部分だと思っています。

そんな中で事業としても良い循環を作ることで、チームが成長して、プロダクトをちゃんと伸ばしての反復横跳びをやっていけることを考えると、事業責任者としてポジションを取っていくことが、一番やれることなのかなと思っています。

僕自身が今まで良い経験を積めていると思っているからこそ、それを伝播させていきたいと思っています。

組織の大きさも扱う問題の大きさも日々変わりますが、みんなでワイワイとプロダクト開発をするのが、僕にとっては天職だなと思っています。すごく楽しく日々過ごさせてもらっているので、みんなでパワーを結集できるように、引き続きやっていこうと思います。

こんな感じでかなり“お気持ち”な発表でしたが、これで終わります。ありがとうございます。

予算をうまくとるために工夫していること

司会者：ありがとうございます。まだちょっと時間があるので、何か質問とかがある方はDiscordに書いてもらえれば助かります。そのつなぎといったら何ですが、僕が1点聞きたかったのが、予算の取り方のことです。

今絶賛うまくなっている最中という話がありました。「やってみて予算が取れなかった」というフィードバックを受けてアップデートするのが1つ（のやり方）だと思っていますが、うまくなるやり方をそれ以外にやられていたりしますか？

柳川：そうですね。やはり予算が取れた・取れなかっただけでなくて、予算が取れない時はどういう原因があるかも考えてみました。やはり事業責任者としてその事業を見ている視点と、さらにその一段上の経営として幅広い視点で全プロダクトを見ている視点では、隔たりがあることにある日気づいたんですね。

やはりここでも情報量の格差があるんですよ。僕が一番自分の事業のことは知っていると思っているし、それも経営陣であれば知っていてほしいなと思うのですが、やはり見ている範囲が違うので、そうじゃないところがあることをすごく痛感した出来事でした。

そういうことがあって（からは）「これは客観的に見て理解できる内容でしたか？」とフィードバックをもらうようにしていますね。

司会者：単純に「ダメだった」というのではなくて、さらにどうダメだったのかとか、「どういう状況だったんですか？」みたいなことを突っ込んで（聞いて）いるみたいなことですね。

柳川：そうですね。「何がわからなかったですか？」みたいな。

司会者：なぜ「ダメという判断、意思決定をしたのですか？」みたいな感じ。

柳川：そうですね。

司会者：ありがとうございます。いいですね。勉強させてもらいました。

柳川：本当に日々苦しみながら改善しながらやっています。

（一同笑）

司会者：ありがとうございます。では誰か質問ありますかね。もしあとで思いついたら、柳川さんにDiscord上なりTwitter上で質問してもらえると助かります。

柳川：いつでも。

司会者：ではあらためて、柳川さんありがとうございました。

柳川：ありがとうございました。