CTOとしての役割と組織の状況
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、チーフなんでも拾うオフィサーとしてのCTOです。
今回はゲストをお迎えして、CTOとしての役割だったりだとか、面白さだとか、こんなことやってますよ、みたいなところをちょっとカジュアルな感じでいろいろお話ししていければいいなと思っております。
エンジニアリングマネージャーの問題集。では本日のゲストをご紹介します。株式会社レアジョブテクノロジーズCTO兼プロダクトマネージャーのジャンボさんです。
ジャンボさん軽く自己紹介をお願いできますか。
本日はよろしくお願いいたします。ご紹介預かりました、株式会社レアジョブテクノロジーズのジャンボ羽田と申します。よろしくお願いいたします。
ポッドキャストだと音声で全然わからないと思います。体が大きくてジャンボと呼ばれていたりします。
今の会社でこのあだ名を流行らせるの失敗してて羽田さんって会社に呼ばれちゃってるんですけど、インターネットではジャンボでやらせていただいてます。よろしくお願いいたします。
業務としてはレアジョブというプロダクトであったりとか、プロゴスマートメソッドといった英会話をメインとしたプロダクトを運営するレアジョブの技術子会社でCTOを担当していまして、関連するプロダクトであったりとかプロジェクトの責任者の担当をしております。
もともとは前職ヤフーにいましてモバイルアプリの開発であったりとかインフラをやってきた中で、今レアジョブというところに7年目になってましてCTOの役割で全体のシステムの鑑賞であったりとか、プロダクトマネージャー、デザイン料金も鑑賞しているそのあたりの責任者としても担当しております。本日はよろしくお願いいたします。
ありがとうございます。よろしくお願いします。
ジャンボというワードの由来が、実は体が大きいということだったと初めて知りました。
一番シンプルな理由になっております。
なんと。ありがとうございます。親しみを込めてジャンボさんと。
よろしくお願いします。
そんなわけで、CTO兼プロダクトマネージャーみたいなところで、私がCTO、COOというのを兼ねているのとすごく親近感が湧くなと思いつつ、今日いろんなお話ができるのを楽しみにしております。
とはいえ最初に、まずジャンボさんが置かれている状況みたいなところを、ある程度網羅的にサクッと伺いたいなと思っているので、今の役割で、組織の状況とか、定量訂正みたいなところを最初にさまってお話しいただけると嬉しいなと思います。
わかりました。
私は今、レアジョブテクノロジーズというところでまだ、子会社としては立ち上げ2年目の会社になっていまして、もともとはレアジョブと一つの会社があって、そこに7年前に入社をしています。
当時レアジョブというプロダクトがモバイルアプリがなかったので、私が1人目のモバイルアプリエンジニアとして事業の立ち上げをしながら、モバイルアプリの事業を始めたところが入社のきっかけと、入った後の最初にやっていたことになっています。
アプリも作って、プロダクトがユーザーさんも増えてきて、ウェブだけだったところがアプリでも予約ができたりとか、レッスンができたりとかっていう世界観を作れていく中で、自分の職域をどんどん広げていこうというところで、徐々にマネージャーであったりとか、
モバイルアプリだけではなくて、フロントエンドのウェブであったりとかというふうにどんどん職域を広げていきました。その中でデザインであったりとか、プロダクトマネジメントであったりとかも同じように広げていく過程で増えていって、現在はシールドとして役割になっています。
鑑賞している領域としては、さっき言ったとおりシステムのプロジェクトだったりだけではなくて、デザインであったりとかプロダクトマネジメントだったりとかも見ています。直続のメンバーとしては社員だったりとか業務委託さん含めてだいたい20名から30名ぐらいのチームだったりとかプロジェクトを担当しています。
会社は株式会社レアジブというところが母体になるんですが、既に上昇もしていまして、グループ経営の体制になって、各会社も非常に多い関係者も多いような状況になっていく中での、上場している上の難しさであったりとか、セキュリティとか統制的に守らないといけないところをしっかり守りつつ、どうやったら新しいテクノロジーだったりとか技術を教育に落としていけるかというところを日々考えて学びアップデートというところを掲げながら、
プロジェクトの推進であったりとか、プロダクトの改善というところをやっていたりします。
なるほど。ありがとうございます。
そんな感じですかね。
ちょっと素朴な質問なんですけれども、レアジョブさん本体側とレアジョブテクノロジーさんで、その本体側にもシステム部門とかいうのはあったりするんですか?
そうですね。子会社化したのがちょうど一昨年になってまして、その時点でプロダクトを推進するような部門は、もう子会社として切り出して、それ独自の人事形態だったりとか、評価体制だったりとか、報酬制度だったりとかを作りましょう。
エンジニアがよりやりやすい、デザイナーとかPDもやりやすいような会社を作りましょうというところが元にあって、今レアジョブテクノロジーズというところを立ち上げています。
我々がグループとして開発をメインになっているのは、なんで我々だけという形になりますが、協業する形で、もともと弊社が開発をフィリピンでも一部やっていたりとか、
あと最近グループに上院した会社にもほとんど開発部門があったりして、ちょっとまだ何個かに分かれるところはあるんですが、
大きな、もともと持っていたレアジョブ英会話というプロダクトであったりとか、スマートメソッド、あとAIのスピーキングテストになるプロゴスというプロダクトであったりとかは、
レアジョブテクノロジーズのほうで開発と運営を担当しております。
なるほど、なるほど。ということは、レアジョブテクノロジーズさんが基本的にはグループの技術みたいなところは基本的になっていて、
会社としてもプロダクトづくりをするための会社のような、そういった位置づけになっているということですね。
なるほど、わかりました。ありがとうございます。
その中で、ジャモさん、CTO兼プロダクトマネージャーだったり、もう少し別のところも鑑賞していらっしゃるということなんですけれども、
まずはやっぱりCTOという役職で、どんな責任を持っていたり、日々どんな仕事をしていたりというところから、掘り始めていきたいなと思うんですけれども、
とはいえ、プロダクトを持っている会社でのCTOというところだと、技術にもちろん責任を持たなければいけないんだけど、
一方でプロダクトというものをいかに伸ばしていくかとか、そういうところも技術サイドからしっかり見なければいけないだろうというのは、僕自身はすごく思っているわけなんですよ。
という意味でのプロダクト自体への関わり方というのは、プロダクトマネージャーというタイトルも持ってらっしゃるので、相当そこに入り込んでいらっしゃるんだろうなと思いつつ、
プロダクト作り体制の中でのジャンボさんの位置づけというか、関わり方みたいなところって具体的にどんな感じだったりするんですかね。
もちろんタイトルとして持つ役割、責任というところでは、全ての技術の鑑賞というところをしながら、それを責任を持ってプロダクトを推進するために活用していくことですね。
技術を使ってしっかりプロダクトを伸ばしていくところが、メイン大きく私の主たる責任範囲になっています。
ただですね、結構僕自身がその解釈をすごく広くしていたりとか、実際こう持っている権限裁量としても広くデザインとかプロダクトマネジメントも監修領域に持っていることからですね、
プロダクトマネージャーとしての関わり方
実際に動いていることは技術だけではないというところがですね、結構変わっているところとかになるのかなと個人的には思っています。
関わり方としてはですね、本当にもうプロダクトに関する入り口から出口で、一つのプロダクトリアージブエーカーというものがある中でですね、
その中で今市場としてどういった状況であるかであったりとか、僕らのお客様って先生と生徒両方いるんですけど、
先生とか生徒にとってどういったプロダクトの状態、機能の状態がすごい辛い、使いにくいかというところの連携を必要としながらですね、
お客様をサクセスとしながら課題を吸い上げたりとか、時にはインタビューアンケートみたいなことを比較したりとかっていう、
本当にプロダクトマネジメントの領域の業務もやっていますし、あとはそれをですね、実際にメンバーと協業しながらですね、
施策を進めたりとか、企画に落とし込んだりプロジェクト化したりとかっていうところのマネジメント領域もになっています。
なので、自分でその課題を吸い上げて、実際にPRDみたいなものを自分で作って、簡単な仕様を書き上げて、実際にそれを詰めて、
リリースしてから運用してまでっていうところもプロジェクトに行ったら自分で全部担当してですね、回してることもあります。
で、これはまあ、それが効果的、結果的にやってるところも正直なくはないんですけど、
ただやっぱりやっている、自分がその広く領域を持つことで出せてるバリューだったりとか、
特にその技術、今新しくChatGPTであったりとか、セセアみたいなところが入っていく中で、
これをどう入れていくのか、どう入れるのが望ましいかっていうところをですね、
なんか現時点で考えてみると、その両方の鑑賞領域を持っている人が動けることって、
すごいスピード感を出せるなって結構自分自身での実感もあります。
なのでそういった、特に教育の業界だったりとか、プロダクトってなかなか革新がしにくいとか、
技術的な新しいもの入れにくいところがあったりとか、いろいろな背景がある中で、
そこのスピード感を出すためには、僕がCTOとして兼プロダクトマネジャーとして、
そのテクノロジー、技術だけではなくて、実際その施策を何するべきかとか、
どういったものが適切かとかっていうところのですね、プロダクトマネジメント、
デザインっていうところを持っていた方がですね、効果的な芯があるなと思いながらですね、
関わりを持ってそういったプロジェクトとか役割も担当しております。
なんかそのめちゃくちゃわかるなっていうところだらけなんですけれども、
プロダクトへの入り込み方は若干僕とその程度が違うかなとは思いつつも、
ただその僕の方のやっているプロダクトもかなりの度合いで、
その技術のことを本当に土台にしながらプロダクトを作っていくみたいなところが必要なので、
なんか本当に一体となって、技術とプロダクト側が本当に一つであるかのように動いて、
プロダクトづくりをしていくってことが本当に必要になってるんですよね。
そういう意味ではエンジニアバックグラウンドみたいなものをきちんと、
強く持った上でプロダクトのことも考えていくっていうのが一番、
そうじゃない人ももちろん活躍できるんですけれども、
技術バックグラウンドを持ってる方がやりやすい部分も結構な割合であるのかなと思ったりしているので、
ジャンボさんの仕事の仕方は本当に共感しますね。
共感を持った上で、そこもめちゃくちゃ話したいんですけれども、
もう少し状況を聞きたいなと思っていまして、
他のプロダクトマネージャーの存在とその役割
ジャンボさん以外にもプロダクトマネジメントをしている方がいらっしゃるってことですかね。
おっしゃる通りです。
僕が見ている範囲だとですね、プロダクトが弊社いくつかあって、
マルチプロダクトなものの上のプロダクトマネジメント領域を、
私が全体の監修はするんですけど、各プロダクトに1名とか2名とかですね、
プロダクトマネージャーをアサインしつつ、
プロジェクトとか状況によってはそこを一緒に支援したりとか、
一緒に入り込んでいくっていうスタイルを取っています。
なので各担当のプロダクトを見てくれているメンバーはもちろんいて、
彼らがメインでは担当してくれてるんですが、
現場から動きにくいような意思決定であったりとか、
他の部と横断するような動きがあった際は、私が入っていって、
一緒にリスクであったりとかですね、技術的に通し攻めたい部分だったりとか、
あとユーザーの課題に対しての深掘りみたいなところをですね、
一緒にやることが多いですね。
けっこうジャンボさんの立ち位置が、
すごくメインでこのKPI持ってますみたいな感じではなくて、
傭兵的に何かが必要そうな時に入っていくみたいな、
そういったニュアンスだったりするんですかね。
そうですね、本当に何でもやる傭兵だと思っていただいて、
ありがたいかなと思っています。
僕自身、CTOの役割をこの2年ぐらいタイトルとして持って考えていく中で、
結局そのプロダクトを推進するために何でもするっていうことは間違いないのかなと思っています。
けっこう僕らマルチプロダクトかつですね、
担当の専任のメンバーもいたりとか、逆に横断のメンバーもいたりとかする中で、
どうしたらコラボレーションが一番しやすい状態なのかとか、
何がボトルネックになっちゃうのかとか、
他のプロダクト、プロジェクト良かったことってどう展開したらいいのかみたいなところは、
結構自分自身が言語化のフォローをしたりとか、
実際に手を動かしてそれを導入したりとかってことをやっていますね。
何でも本当に傭兵って言い方は僕自身もしっきりくるかなと思っていますね。
なるほど、なるほど。
そうですよね、しっくり聞いています。
でもそのあり方が一般的かどうかはそうじゃないケースもあるなって思っていまして、
他社さんですと、例えばCTO兼CPOみたいになって、
プロダクトのほうも完全にトップとして
引いていくみたいな形も実際にあるかなと思いまして、
でもジャンボさんはそうではなく、
こぼれているボールだったり、
急に立ち上がってきたトレンドみたいなところを拾ってさっと動くとか、
そういうところをやってらっしゃるんだろうなっていうふうに理解しましたね。
そうですね、やっぱり事業の要求に対してだったりとか、
事業が持つ課題に対して、
それが番人がすべて綺麗に、
例えばジラニーバックログを作れますとか、
ロードマップを書けますってことはなかなか難しいかなと思ってまして、
プロダクト認識決定をしたりとか、
プロジェクトを推進するための共通言語を作る部分ですね。
結構そういったことに役割を自分が保管をしたりとか、
一緒に作ったりとか、
また優先順位を考え直したりとか、
技術をベースにしてやったりとかっていうことを、
非常に多くやらせていただいているかなと思ってますね。
ちょっとそこも興味深いんですけれども、
共通言語っていう言葉を使われましたけれども、
何でしょうか、仕組みだったりだとか、
ルール、ガイドラインだったりだとか、
そういうものの整備だったりもするんですか?
そうですね、僕らが結構情状も知っているのもありまして、
統制観点でしっかり抑えなきゃいけないポイントだったりとかですね、
逆に考えすぎないでよくて、どの攻めてほしいポイントって、
結構状況をちゃんと言語化しないといけない部分って非常に多いかなと思っています。
共通言語の作成
細かいことだと、リリースの証跡ちゃんと残さなきゃいけないよね、
誰かが承認者として立てないといけないし、
そのルールも言語化されないといけないよねっていうところが、
どのレベルで言語化されていればよくてとか、
逆にここは全然しなくてよくてとかっていうところって、
なかなか現場から分かりにくいし、
もともと明文化されている部分があったりいなかったりだと思うので、
そのされていない部分をしっかり保管していったりとか、
あとそれはテクノロジー部門のメンバーだけではなくて、
他の部門のメンバーにも展開をしたりとか、
全体が自己組織的に意思決定できる状態を作るってことは、
結構よくやっているのかなと自分でも思っていますね。
なるほど。
そうですね。
そういう役割の人がいると、
本当は組織ってうまく、
その人が潤滑油のようにいろんなところをきれいにしながら、
他の人がスムーズにパフォーマンスできるみたいな人だと思うので、
絶対組織に一人はいてほしいなっていう感じの人が、
ジャンボさんなんだろうなっていうイメージがだんだん膨らんできております。
そうですね。
それが自分でもやりすぎてしまってもいいのかなと思ってもあって、
メンバーの成長を奪ってないかとか、
この体制は再現性があるのかとかですね、
すごい考えたりしていて、
最近はこの再現性であったりとか、
横断することの成功体験みたいなものを自分でも少しずつ、
この1年、2年通し見えてきたので、
CTO室っていうものを最近は立ち上げてですね、
その役割を担ってくれる方も新しく入ってもらって、
横断した支援だったりとかを広くやってもらうようなことを
最近動き始めましたね。
なるほど。
CTO室はそういう役割設定みたいになっているってことですかね。
期待値っていうかジョブディスクリプションみたいなのが。
なるほど。
僕も1年前にこのポジションに就いたときに、
自分のチームみたいなのを作って、
それがデジタルサービスユニットっていう名前を付けたんですけれども、
そこに入ってくる人の期待値としては、
そのチームの仕事だけやるっていうことではなくて、
基本会社全体のデジタル化っていうか、
ものすごく抽象的なミッションを設定していて、
みんなの役に立つような動き方をしてくれっていう期待値で採用したりしていたんですね。
そういうエンジニアだったり、プロダクトマネージャーだったり、
いろんなポジションの人を採用したんですけれども、
どれくらいいるのかって分からなかったんですよね。
僕自身はそれが会社にとっていいと思っているし、
自分がそういう動き方をしたいとも思っているので、
自分はこれが理想だと思ってたんだけど、
本当に他の人も共感してくれるのかは、
若干自信がない状態でスタートしたんですけれども、
意外とやっぱりそれに共感してくれる人がいて、
かつ会社の中にそういう人が入ってきて、
ものすごく会社の動きが良くなった部分とかもあったので、
こういうのはやっぱり必要なんだなっていうのは、
1年やってみてすごく分かった点があったりしましたね。
若干似たような部分があるのかなと思いながら、
もう少しCTO室のどんな方がいらっしゃって、
どんなことやってらっしゃるのかなみたいなのを聞きたいですね。
そうですね。CTO室は本当に立ち上げたばかりで、
もともとはインフラ領域とかプラットフォームって
僕ら呼んでいるベースのあるAPI群を管理しているチームが
あったりするんですけど、そこを担当してくれたメンバーが
今はCTO室として活躍してくれていて、
本当に一緒にプロジェクトのスクラムの中に入っていて、
ボトルネックになりそうな技術的な課題であったりとか、
結構彼自身が出自がインフラだったりするので、
AWS周りの設定周りでデベロッパーが分かりにくいところとか
詰まりやすいところとかを事前にフォローしてあげたりとか、
あとはプロジェクトのコミュニケーションの中で、
これはこういうコミュニケーションしたほうがいいですねとか、
こういったものはドキュメント化しましょうねみたいなところを
本当に広く動いてくれててですね。
僕自身も結構そういったプロジェクトの中で動いていく中での
課題の吸い上げをしたりとか、解決するためのアクションをしたりって、
結構サービスエンジニアリングっぽい領域がすごい好きだったので、
同じような働き方をしてくれる方がですね、
C2Sとして活躍してくれてすごい嬉しいですね。
いやーいいっすね。
そういう人がいるっていう話を聞くだけで、
僕はなんか嬉しくなっちゃいますね。
本当そういう人いてほしいんですよね、会社に。
すごい助かるなって思いましたね。
自分もやっぱりいろんな方を助けていけたなって、
実績もある程度自分で自信もあったので、
絶対必要だなって確信を持って始めた手前ちょっと心配ではあったので、
この1、2ヶ月すごい活躍してくれてるのを見てですね、
すごい嬉しいなと思ってますね。
ですよね。
それがめっちゃワークするっていうか、
必要だなっていうところに確信はありつつも、
今後考えなきゃいけないなって思ってるのが、
他のチームだとかからした時に、
最初のフェーズではめちゃくちゃありがたい人として、
いろいろみんなにとってウィンウィンになるんですけれども、
一定経った後にその人に依存しちゃうというか、
最終的にはチームが自分たちで問題解決できる、
CTO室なり、僕だったらデジタルサービスユニットなりの人から
技術を盗んでというか、
自分でできるようになってるような状態が理想かなって思ったりもしてるんですけど、
そこまでのトランスフォームみたいなのって、
やっぱりもう1段2段壁があるのかなみたいなところも感じたりしてるんですよね。
その辺ってどうです?ジャンボさんの方では。
役割の範囲と線引き
そうですね。おっしゃる通りで、
専任部隊がいるのに横やりを入れるじゃないですけど、
また別の部隊が入ってきてやんやするのって、
見え方として良くない見え方もなくはないなと思っているんですよね。
それが独人化っていうものは新しく生んでしまったりとか、
コミュニケーションが偏ってしまって分断を生んでしまったりとかっていうのもあるかなと思っています。
そこはただ本当にやり方とか目的の定義の仕方だったりとか
振る舞いの仕方ですごい重要になってくるなと思っていて、
僕らだと本当に横断して何でもやることをですね、
CTO室のミッションとして最初に明確に定義をして、
プロジェクトとしても全体に対してどういうことをやっていきますよっていうのも公開はしているんですね。
かつ逆にやらないこととかの選挙もすごく一方で重要かなと思っていまして、
メインのリード機能の開発も全部やってしまうみたいなことをやり始めると、
どっちが先人なんだみたいなことになっていったりとか、
本来担うべき横断で出すべきバリューが出しにくくなってくると思うので、
本当に必要があってそのスポットでとかっていうのはなくはないと思いつつも、
例えばプロジェクトがあったときにメインの機能をCTO室で全部作っちゃいますってやってしまうと、
やっぱり現場のモチベーションも下がるだろうし、
何よりプロジェクト面白くなくなっていくと思うので、
なんでやっぱりそのプロジェクトはその担当者が成功対象をしっかり積みつつ、
それを効果的に作ることであったりとか、
より安全にチャレンジしてもらえるような体制を作ること、
その役割を提供することがCTO室だったりとか、
横断する部隊にはすごい重要なんじゃないかなと思ってますね。
なるほど、そこは結構明確に切り分けるというか線引きする意志を持ってらっしゃるってことですね。
そうですね、時にちょっと言語化が足りてなくて、
やった方が都合がいいなって思う瞬間もあるので、
やってしまうことも正直ゼロではないんですけど、
その役割を広げすぎないことっていうのはすごい重要だなっていうのは考えていますね。
なるほどな。そこは確かに私の方ですと一部、
CTO、プロダクトマネージャーとしてのミッション
中長期のためのプロジェクトみたいなものも持っている状態だったりしたので、
そうするとやっぱりそこだけに知識が偏るみたいなことが実は起きているんですよね。
なのでそれはやっぱりちょっと役割設定をもう少し限定するとかが、
僕の方だと必要なのかもしれないですね。
なるほど、参考になります。
難しいですね。絶対やった方がいいなっていう謎の確信はあるんですけど、
謎の不安も一方であるみたいな状況なので、
僕らまだチャレンジしてから2ヶ月、3ヶ月っていうふうな感じなんで、
まだまだ解像度は上げていける必要があるなと思いますね。
本当にどういうチームを作ってどういう役割を持たせていいかなんて本当に答えがないですし、難しいですよね。
そうですね、状況でも変わっていっちゃうと思いますしね、そこは。
ジャンボさんのCTO、プロダクトマネージャーとしてのメインのミッションみたいなところを色々お話を聞いて、
まだまだ話したいなとそこも思っているんですが、
一方でチラッと話題に出たデザイナーのところも見ているようだったりだとか、
そういうところも気になっておりまして、
なんでかというと、私もCTOとかCOO、役割がそれを示しているかもしれないんですけれども、
そんなこともやってるんですか?みたいなことも色々やってたりして、
そういうところも、ジャンボさんとなら苦労の共有みたいなのができそうなので、
ちょっとそういうお話もしてみたいなと思っております。
まずちょっとデザインのところからお話を聞いてみたいなと思っていて、
実は僕も今の会社で、今々デザイナーの部門も鑑賞していたりして、
採用にも入っていたりするんですけれども、
ジャンボさんもやってらっしゃるというところで、
どういう経緯でそんなことになったんですか?みたいなところから教えていただけますか?
そうですね。もともと僕が出自がネイティブアプリのIOSエンジニアというのをやっていた中で、
どんどん職域を広げてウェブのフロントエンドということを持っていって、
TypeScriptであったりとか、Vue.jsの開発みたいなのをやっていた中で、
もともと弊社がデザイン部隊というのはあったんですけど、
どちらかというと制作っぽい役割が多くて、
今のUXであったりとか、UIをしっかりデザインするみたいな役割が結構弱かったんですよね。
明確に定義としてもなかったですし、
そこに力入れていこうみたいな考えもそんなに強くなかったというのが背景としてあります。
ただ、今、モダンフロントエンドという中では、
そういったUXとしっかりコミュニケーションを取るべきであったりとか、
あとコンポーネントリストみたいなのもしっかり作っていて、
デザインを汎用的にしていくみたいな思想がすごい重要になっていく中で、
デザインとの協業、UXとの融合みたいなのって間違いなく重要だよねというのが考えとしてありましたと。
ただ一方、現行のスタイル、デザインチームのスタイルっていうのがあってなかった。
ちょっと制作っぽい役割が多すぎて、やりにくい部分が正直あったので、
あればもう自分が責任を持つ形で、
そこの部分としての役割をしっかり果たしつつ、
逆にそういった制作プロセスをテクノロジーズで改善したりとか、
あとやりやすくしたりとか、パフォーマンスを出したりとかっていうのになっていきながら、
UXっていうものをどんどん注入していこうみたいな考えを持ってですね、
当時デザインチームが営業本部の参加に。
そっち側だったんですね。
そうなんですよ。営業本部、技術本部で役割の分け方があって、
営業側にあったので、いろいろ考えたんですけど、
結局僕がそっちの営業本部に入るってことですね、
あと兼務でやって、デザインチームのリーダーに無理やりやらせていただいて、
各コミュニケーションをしながらですね、デザインチームの干渉領域をいただいて、
デザイン組織の構築
1年ぐらいそこを担当させていただいて、
こういった状況なんであれば、開発部、技術部に移しても問題ないでしょうというところでですね、
プロダクト開発の中にですね、デザインチームを持ってきて、
かつフロントエンドとの役割を澄み分けたりとか融合したりしながら、
かつそれに合わせた必要なマネージャーの採用をしたりしながらですね、
プロダクト開発を強くしていくためのデザイン組織を徐々に作っていったというのがあったりします。
今はですね、現場のマネージャーが、
クリエイティブ室という形で新しくデザインとフロントエンドをしっかり融合していく役割を持った組織を、
僕以外のメンバーが持ってくれているので、
今はかなり彼女らがですね、そこを担当してくれているんですけど、
走り出しはそういった形でですね、よりプロダクトを強くしていくための役割に、
少しずつデザインを変えたかったので、
僕自身が担当したというような経緯でやってきましたというところですね。
いやー面白いですね。
もともとが営業組織の方に、
政策的なチームとして存在したということなんですけれども、
やっぱりそれなりの理由があってそっちに配属されて、
そういう構造だったっていうことだと思うんですけれども、
一旦それはそうだとして、
それを移動させてくるっていう時に、
結構いろんなコンフリクトっていうか、
そういうものもあったんじゃないのかなと思うんですけれども、
一切どんなご苦労があったりされたんでしょうか。
そうですね、広く営業組織と言いつつも、
その干渉範囲に小さくマーケティング部みたいなものがあって、
厳密に営業本部、マーケティング、その次はデザインみたいな形だったんですよね。
その中でいうところの政策っていうところは、
バナーだったりとか、LPだったりとかですね、
そういったものの政策が含まれていました。
結構その時の役割ですでに、
コーディングをする部分だったりとかっていうのは存在していて、
そのですね、政策結果で売上が出ていったりとか、
プロモーションができていくっていうのはあったんですけど、
そのプロセスもしっかり見直す必要があるよね、だったりとか、
そういったことはなかなか現場のエンジニアリング関わってないような、
干渉範囲のマネージャーとか分からないので、
僕は逆にそこに入っていくことで、
効率化をしたりとかですね、
ビルドシステムを入れてあげたりとか、
政策を簡略化できるような技術改善をしたりとか、
デザインも含めたリファクタリングを一緒に、
マトリックス書いてどこからやっていこうという作戦を立てたりとかしながらですね、
ちゃんと現場のスループットも上げつつ、
役割の分け方を言語化しつつ、
それをデザイナーたちにもそうですし、
あとはそれをもともと持ってくれていたマネージャーのほかの皆さん、
マーケティングだったりとか、
こういう業法の皆さんにもご説明をしていきながらですね、
どういった形にしていきたいんだ、だったりとか、
どういった構成になっていたほうが結果的にトータルいいんですよ、
みたいなのを言語化していきながらですね、
やっていた形ですね。
結構そこを皆さんすごい理解もしてくれていたし、
やっぱりデザインをもっと積極的に変えていける、
そのスピード感を出せる、もっとよくしていけるんだったら、
全然大丈夫です、
みたいに言ってくれている方がありがたいことに多くてですね、
そんなすごくハレーションがあったりとかっていうのはむしろ全然なくてですね、
皆さんだいぶ心よく助けてくれた感じでしたね。
なるほど。
なんか今すごいさらっといろんなエピソードをお話しされてますけれども、
なんか僕からすると簡単にできることじゃないよなっていうのはすごく思うわけですよ。
多分やってらっしゃったことって、
営業組織側にというか、これまでやってきたこと、
やり方そのものではないけれども、
何か必要があってその構造になっていて、
そこで何らかの成果というか、
価値を出していったっていうところがあると思うので、
その価値を損なわずに、
むしろ価値をさらに大きく出せるような補助だとか、
そういうことをしながら、
でも新しい形の方がいいよねっていう理解を、
一緒にインストールするようなことをされていたように聞こえたので、
なんかこれは結構何ですかね、
多方面のコミュニケーションになっている理解だとかいうのも必要ですし、
一方で何か新しいデザインがどうその人たちに見えるのか、
敵のように見えないようにうまくコミュニケーションしていかないといけないと思うので、
これはすごく困難なことをさらっとやられたんだなっていうのは、
結構リスペクトですね、それは。
それは何か一定のそういったことをされるときの何ですかね、
当然デザインがどうあるべきみたいなのを、
ジャンボさんの中で一定の確信みたいなものだったり、
ご経験みたいなものを持った上で、
何かそういったアプローチをされていったってことなんですかね。
そうですね、僕自身がもともといろんな課題解決みたいなのが大好きで、
それはエンジニアリングにとっての話だけではなくて、
プロセスの改善であったりとかコミュニケーション改善みたいなのを含まれる中で、
結構その制作領域みたいなところにも同じような課題はたくさんあって、
例えば何かLPを作るってあたってのプロセスでどういう技術を使って、
例えばそのLPのコードってどう管理してとかっていうところから何なら入っていって、
効率的に汎用的に使えるようなリポジトリやこういう設計にしましょうだったりとか、
結構それって制作領域とはいつつエンジニアリング領域だと思っているので、
そこでのもともと持ってた知見を活用できたりとか、
あとは依頼のフローとかですね、制作されるバナーを作ってくださいとか、
LP作ってくださいっていうところのフォーマットをしっかり整える部分だったりとかっていうのも、
スクラムであったりとかですね、最低限アイテムを達成するための項目の定義の作り方みたいなところから流用している知識ですし、
もともと結構僕自身がいろいろ広くエンジニアリングしてきたところの課題解決の手段っていうところが、
制作とかデザインとかでもよくはまっていって、
実際それでいろいろ依頼を受ける流れが整理されたりとか、
あとは制作のプロセスの中でのページを作るスピードが上がったりとか、
画像を出していくときに必要なツールが新しく入れやすかったりとかですね。
で、バリューが出していけたところがですね、他の方から見てもよく見えてたんじゃないかなというふうには想像してますね。
いやー、なるほど。めちゃくちゃ分かりますと言いつつ、なんか本当に簡単にはできないなっていうのは思ったりしますね。
すごいですわ。
ちなみに何ですかね、それやってる時ってエンジニアリングの方の仕事もやりながらそれをやってらっしゃったんですか?
もちろんやってましたね。
それやってた頃がちょうど多分私が今のレアジブっていうプロダクトがですね、
レッスンルームっていうですね、もともとは我々スカイプ英会話っていうブランドを持って始めたぐらいですね、
スカイプに依存したプロダクトだったんですけど、それ自社プロダクトに置き換えるみたいなプロジェクトですね。
WebRTCを使ったSPAのアプリケーションとかネイティブアプリを作るっていうのも走ってた時期なので、
デザインチームと統制の変化
そこのプロジェクトと並行しながらですね、デザインチームを受け取るみたいなことはやってましたね。
なるほどなぁ、なんかすごい大変だなと思うんですけどね、それぐらい幅を広げながら。
物量的に結構ありますよね。
はい、なんかすごい大変でしたね。
そういう時の何ですか、時間の使い方の管理とかのなんかティップスはあったりするんですか?
いや恥ずかしいんですけど、なんかあんまり思いつかなくてですね、
なんか気合で全部言ったらあんまりメンバーとかにも怒られそうなんですけど、
ただ会話をしっかりすることっていうのは、どんな状況かでもすごい大事だなとは思っていました。
さっき言ったような、見え方としては例えばデザインが自分の鑑賞範囲だったのに持ってかれてしまうこと、
やりにくい部分が出るんじゃないかとか、
あとはこう今まで統制が取れてた部分が変わってしまうんじゃないかとか、
コミュニケーションパスが変わっちゃうんじゃないかみたいな懸念だったりとかって
想像することはできるんですけど、実際にそれがあるかっていうことだったりとか、
どこまでが本当に向き合わなきゃいけない課題かっていうのは、
本当に会話しなきゃ出てこないと思っていますし、
会話プラスその事実、自分で調べれること、データだったりとか、
あとは実際のコミュニケーションログとか見ながらですね、
精査をした上で付き合わせていくしかないと思っているので、
課題がすごいホットだったりとか、自分が忙しい状況でも人と話すことだったりとか、
会話することは絶対に無くしてはいけないのかなと思っていますね。
なるほど、今最後の方でジャンボさんのマネジメントの秘訣というか、
結構信念みたいなところが聞けたのかなっていうふうにも思ったりするんですけど、
ありがとうございます。
そうですね、なるほど。
僕はデザインのところも鑑賞しているとはいえ、
そこまでドラスティックに今あるものを変えるっていうような鑑賞が必要なわけではないので、
どっちかというとこれから僕の会社であればグローバルに向けて展開しようとしているところなので、
デザインのチームもグローバル化していくとかいうところでどういうふうに大きくしているのか、
スケールさせていくのかみたいなところを持っているような感じだったりします。
ちょっと違うのかなというのはありますけどね。
それもそれでめちゃくちゃ難しそうに思いますけどね。
プロダクトマネージャーの役割
一言で言うと採用みたいな感じになっちゃいますけどね。
一番むずいですね、結局それが。
どこから集めてこればいいのかなみたいになっちゃいますけどね。
特に自分がスペシャリティを持っていない領域の採用ってめちゃくちゃ難しいなって僕もいろいろ思いましたね、やってみて。
あとはエンジニアだけでもグローバルに採用するとなったときに結構考え方を変えないといけないところもあったりするんですけど、
デザイナーの方ってどんな感じなんだろうっていうのは全くインプットがなかったりするので、
そのあたりをちょっと拾い集めながらとかだったりしますけどね。
そんな話は一旦さておき、デザイナーの部分もやりつつ、
他にも何ですかね、拾ったり、こんなものも実は拾ってますよみたいなものってあったりしますか。
そうですね、私が鑑賞している領域だと、コートでお伝えしたようにプロダクトマネジメントっていう領域だったりとかもやっていますし、
あとはデザイン、実際にクリエイティブに良し悪しを判断するわけではなくて、
そのプロセスとかそれを実現するための採用だったりとか人材だったりとか、
コラボレーションみたいなところに対してのフォローとかサポートをしているというところですかね。
それ以外で言うとですね、今ではCTOという役割は当然なんですけど、
もちろん管轄する部門のPLを見たりとかですね、
僕ら自身はレアジョブとして働いた時から部長がみんな事務部門のPLを見るみたいな役割を持っていたので、
当時からPLを鑑賞して、見込みを出して、予算との実績を精査してとかということもいろいろやってましたね。
なるほど、なるほど。PLはレアジョブさんの業態の場合はお金の入りと出みたいなところから、
割とシンプルに計算できるようなものなんでしょうかね。
そうですね、例えばただインフラの費用であったりとか、
もちろんプロダクトの状況に沿って動的に動いていく中で、
続きで引いた予算に対してどこまでフィットするのとか、
ギャップがあるのであればその見込みはどういう動きになるのであったりとかを、
もちろんインフラメンサーの利用料だったりとか、
あとは業務委託の方の費用だったりとかも含めてですね、
どういう戦略とか戦術とか、状況をもとにそれを決めていくんだという裏付けを作ったりとか、
あとそれをもとにいかに政治の見込みを作ったりとかというところでですね、
そこは結構自分自身も苦心したところですかね。
なるほど、そのあたりPLの単純な売上と利益とか、
ものすごい単純な足し算引き算だけで出るものとかであれば、
そんなに難しいこともないと思うんですけれども、
何か会計的な知識が必要だったりした部分とかはあるんでしょうか。
そうですね、僕らだと結構厳密にやっている部分として、
ソフトウェア借り勘定みたいなですね、ソフトウェアの会計処理みたいなものがあって、
この辺は僕ら上場もしている都合もあってですね、
しっかり倫義だったりとか決算書籍も残しながら、
どういうプロジェクトにどういう費用を貼るのとか、
あとそこに対しての考え方、捉え方、監査とのコミュニケーションみたいなところをですね、
僕らだけでは完結しないので、経理のメンバーであったりとかですね、
社内の財務部門と一緒に話しながら、どういった状態が望ましいんだっけとか、
どれぐらいそのソフトウェア環状として目標を持つべきなんだっけとか、
日々議論しながらですね、会話しているので、
この辺は全然僕も知らなかった領域でしたし、
ゼロからいろんなメンバーに教えてもらったりとかフォローしてもらったりして、
少し分かってきたというところですかね。
PLと会計の管理
なるほど、そっち系、確かにそうですよね、そこは必要になってきますもんね。
今までなんかいろんな会社さんの話を伺ったり見たりしてきた中だと、
タイムカードベースからうまく算出したりだとか、
そういうことをやっていらっしゃったり、
もしくは一定ソフトウェアエンジニアの人数とリリースしているものの数だとか、
そういうものを根拠に計算しているとか、いくつか伺ったことがありますけど、
どうでしょう、話せる範囲でなんですけど、
レアジオブさんの場合はプロジェクトに何人月みたいなのを出しているんですかね。
そうですね、ただ見込みでは見込みでしかないので、
それがどういったボリューム感でだったりとかを決済だったりとかの中でご説明をしたりとか、
あとはそれを実際に稼働とさっき言っていただいたような形にすり合わせて、
どれくらい実際に動いたかというところを整理したりとかというところですかね。
ただそこまですごい厳しすぎるようなことは扱ってはいなくて、
可能な限り上場企業としての責任を果たせるような取り扱いをしているという具合ですかね。
ビジネスモデル的にもそんなに急に何かが仕入れが大きく変動しますみたいなとかは、
ある程度も生徒さんが受講していらっしゃる数だとかに依存しながら、
滑らかに変わっていくみたいな感じなんですかね。
僕も入社前はそう思っていたんですけど、
イベントサブスクの英会は非常に複雑でして、
例えば考え方として、
我々先生にスロットと言われる開講ですね、授業を準備していただいて、
それに生徒様が予約をしてレッスンを実際に提供するみたいな仕組みになっていて、
そのレッスンの提供数に応じて先生にお支払いをしているわけなんですね。
ただ皆さんが皆さん朝6時から夜24時半まで、
均一にレッスンを常に準備してくれるわけではなくて、
例えばフィリピンだとキリスト教のところがすごく強いので、
その前後であったり、
キリスト教で非常に重要な日が何個かあるんですけど、
その日もそうですし、その前後でお休みをする傾向が国として強いっていうのもあったりとか、
あとフィリピンって急に祝日ができたりするんですよ。
意味わからないと思うんですけど、急に祝日ができるんですよ。
できるとみんな休むんですよ、とてもお休みになると。
そうすると僕らサブスクで毎月これくらいレッスン提供できますよというふうな売り方をしているのに、
先生がいないという状況が生まれちゃうんですよね。
そういったところに対しては先生にインセンティブをお支払いしたりとか、
プロモーションしていったりとかしてちゃんと開講してもらえるような、
生徒さんが満足してもらえるような予約状況を作るみたいなチューニングがオペレーションがあってですね。
そうなってくると費用変動も当然それに応じて変わってきますし、
生徒さんも常に僕らだと毎日英会話受けれるようなパッケージもあるんですけど、
それでも全部受ける方とそうじゃない方ってばらつきもあったりするので、
実際のPL上のデイリーみたいなところがきれいになるかというと、
実はそうじゃなくて複雑なところが非常に多いというのが、
僕も触り始めて関わってPLも管理したりして初めて分かってきたところでした。
なるほど。その意味では僕のやっているビジネスと非常に近しいところがありますよね。
お金自体はサブスクでいただいているんだけれども、
サービスとしては1個1個予約して授業を受けたというところで、
駅務が提供されるみたいな形になっているので、
私たちの方もお金自体はサブスクで月額とかでいただくんですけれども、
実際お客様が宿泊してっていうところでお金が動くみたいなところになっているので、
その会計処理をいろいろ我々のところは会計士とあだこだ言いながら定義したりしていますけれどね。
なるほど。確かにそれはややこしそうですね。
ややこしいですね。何も分からなすぎて、本当に迷ってビジネススクール通ったりしてましたからね。
なるほど。僕も一緒ですね。
会計が分からなすぎて通うかって通い始めたりして。
分かりますわ。
なので今の僕が話してたようなところも、
社内の会計システムを作るプロジェクトみたいなのが必要になったので、
それをデジタルサービスユニットで持って作ったりしてたんですけれども、
もうそんな会計の知識なんて、プロダクト作ってる方のエンジニアに
とてもじゃないけどお前ら勉強しろみたいな風に言えないので、
本当に分かりそうなメンバーだけ集めて何とかそこはやってるみたいにしてやってるんですけれども、
本当にそこの知識って特殊すぎて、
この先これをどう運用していこうかなっていうのは今まだ決めかねてるところですね。
全員にモテてるものでもないので。
そうですね。たまたま持ってる知見でもないですからね。
勉強してましたって会計に超詳しいです。
元管理会計師ですみたいなエンジニアってほぼいない。
いないですよ。
勉強する必要ないのかなっていうの。
すごい愚直なんですけど。
ただそれはそれでやっぱり事業を進めていくにあたって、
必要なことだったりもするし、
何ならお金の単純な定義ではなくて、
会計のやり方に則って定義したようなPLがどうなっているのかを見ながら、
事業の意思決定していくっていう意味でも必要だったりもするので、
CTOの役割と重要性
そこはそこで大事な機能というかドメインというかという見方もしていたりするんですよね。
なので本当にプロダクトだけじゃなくてそこも合わせて事業に必要なシステムだなという見方もしていて、
脇役とはいえ結構重要みたいな感じですね。
すごい大事なところだと思いますね。
そういうのもCTOとしてはそこも一定の理解をもとに進めていかなくちゃいけなくて大変だなって感じですよね。
やること多いですね。
やること多いですよね。
本当なんか何でもやらなきゃいけないみたいな感じで。
とはいえジャンボさんもきっとそうなんだろうなと思うんですけれども、
何でもやらなきゃいけないみたいな使命感というか、
人によって違うかもしれないんですけど、僕はそのように思っていて、
それ自体がすごく僕の価値観に合っているというか、やってて楽しいなって思うわけですよ。
会社全体だったり事業を前に進めるために会計みたいなことも必要とあらば勉強してでもやらなきゃいけないし、
他のデザインみたいなところも一定の知識をさっとインプットして、
ちゃんとチームを前に進めるみたいなこともやらなきゃいけないし。
でもそういうことが自分としてはすごく楽しいしやりがいがあるなと思ったりしてるんですけれども、
ジャンボさんもそこって同じような感じなんですかね。
僕自身はすごくいろんな課題を会議するのがもともと好きで、
その中で技術が一番自分に合っていたとか、これまでもすごい興味があって、
それを主にした解決をしてきたという背景がありはするんですけど、
ただただ目線を少し上げてみたりとか横に広げたりとかしていくと、
それ以外の課題もたくさんプロダクト開発とか事業開発では発生しているのが分かってきて、
そこに徐々に自分は踏み込んでいった形になります。
その一つがさっき言ったデザイン部門を鑑賞していくことであったりとか、
プロダクトマネジメントであったりとか、管理会計みたいなところだったりするかなと思っていて、
自分自身もそういったものをとにかく掛け算していって、
他にないような強みを自分のキャリアパスとして作りたいという気持ちもあるし、
本当どんなことをしてでも今一緒に働いてくれているメンバーだったりとか、
プロダクトが伸びていくことっていうのは僕自身もすごく嬉しいので、
あそこに貢献できるのであれば何でもできていく、何でもやるし、
何でも対応するような、自分自身それを問題解決ブルドーザーと呼んだりするんですけど、
本当に全部向き合うようなスタンスを自分としては持ち続けたいなと思っていますね。
そうですね。ブルドーザーのように何でも解決していくみたいなパワーというか、
そこも気合いなのかもしれないですけれども、本当にそれが大事ですよね。
気合いというか、どんなものでもやってやろうぜ的なのって、
少なからず結構な人が持ってらっしゃるんじゃないのかなと思いつつ、
とはいえ、もし自分が今、僕だったらCOO兼CTOっていうタイトルがついた状態で、
こういう仕事の仕方をしているっていうところがあって、
やっぱり一定の権限というか、それなりのパワーみたいなものがないとできないこともあるのかなというところがありまして。
なるほど。
これジャンボさん、ご自身の経験としてはどうでしょうかね。
おっしゃる通りだと思いますね。やっぱり職域を広げること、できることを広げるのってすごい辛いと思うんですよね。
できないことをやるわけなので、これまで自分が自信を持ってて順調にやらせたことを急にやめて、
新しいことにチャレンジしたりとか、まだできたことのないことにチャレンジしていくのは当然辛いと思うし、
特に例えばメンバーからマネージャーになったタイミングとかそうですよね。
マネジメント1年生なのにあたかもできるような期待をされて、それにチャレンジしないといけないし、
なかなか成果が出ないのも当然なのにそれに苦心したりとかっていうこともある中でですね。
そういったただチャレンジをしていることって当然辛いよね、だったりとか。
成長のために成長通だよねっていうところを理解した上で向き合うこととそうでないことってすごい違うのかなと思っています。
もちろん立場を先に作って立場が人を作るという考えもあると思うんですけど、
常にそういった立場が用意されているわけではないし、成長したい方向がそっちではないこともあると思うので、
まずは自分が自分の職域を広げるためのアクションをしたりとか、
実際にそれをやっていく中の過程はすごい大変なこともあるし、学ばなきゃいけないこともあるし、
ストレスに感じることもあるんだけど、結果それが強くなっていって成功体験になっていくことをですね、
自分だけではなくて、なるべく他のメンバーも経験としてとかキャリアとして積んでもらえるようにですね、
動くのが大事かなと思っています。
ジャモさんも言っていただいたように、確かに世の中には先に椅子を用意して座らせてしまって、
権限を与えた上でそこに見合うように頑張れみたいなやり方も一定あるかなとは思いつつも、
必ずしもそれは100パーはワークしないなというか、ワークしないケースは結構あるなというふうにも思うので、
そうではなくて、やっぱり今ある役割、持ってるパワーというか、オフィシャルにはこの役割ですよみたいな中でいかに広げられるか、
その与えられたものの外側まで結構染み出していくような動きっていうのも、
何ですかね、抑えきれないぐらいやった上で、やっぱりこいつにはもっと力を与えたほうがいいなみたいなふうに組織から、
追認されるような形がベストなのかなっていうのは僕的には思ったりしますね。
うん、確かに。染み出すみたいなすごくいい表現だったなって今思っていて、
なんか染み出してるのってすごい周りから見てわかると思うんですよね。
この人すごいチャレンジしてるなとか広げていってるなとか、
それってその直続の冗長から見てもそうだし、そうじゃない、周りのメンバーから見てもそうだし、
それでその方が実際にチャレンジをして、それが評価されて昇進とかしていくとすごくいいと思うんですよね。
結構やっぱり事業会社とかになってくると、当然まだ定義されてない役割、誰かやらないといけないシーンっていっぱいあると思うし、
それやることで本当にプロダクトが今までとは違うような速度感で作れることもたくさんあるので、
そういったチャンスをものにしていくためには、自分の与えられた立場からどんどん染み出していって、
新しいことができるようになったりとか、チャレンジして実績を作っていったほうがお得だなと僕自身は思いますね。
そうですね。僕もすごく同意しかないっていう感じですね。
みたいな考え方をしつつ、自分が今たまたまCTOとCOOみたいなロール、CTOっていうロールを持ってはいるんですけれども、
この役割に他の方々がこのパスに進んでいただくみたいな時に、
何を勉強したらいいんですかとか、どんな経験をしたらいいんですかみたいなアドバイスが僕にはできるんだろうかっていうのはなかなかわからなくて、
なかなかこの再現性のあるようなやり方でここに到達するってものでもないような気がしてはいるんですけれども、
とはいえ、聞いてらっしゃる方に何かこういうふうにやったらCTOに近づけますよみたいなのを一言でも言えるといいのかなと思ったりしてるんですけど、
何かあったりしますか?
そうですね、僕は結構今考えると恥ずかしいんですけど、
もう本当に今僕らレアジブテクノロジーズっていう形ではですね、CEOがいて、僕がCTOを担当していて、
今のCEOが元々グループ全体でCTOだった方なんですよね。
その方が入ってくれたタイミングで僕はもうCTOになりたいですって言ってたんですよ、当時自分が。
その頃って多分6、7年前ぐらいなので、僕がまだ20後半ぐらいの時ですかね。
もうCTOになりたいですって何もわからないながら言い続けていて。
ただ、もしどうしたらなれるかっていう話をした時になりたいのであれば、
なる集団とにかく聞いていくことがすごい大事なのかなと思っています。
CTOっていう役割ってインターネットで調べるといろんな定義があるし、いろんな共通された言語化されたものはあるんですけど、
正直会社の状況でも、プロダクトの状況でも、チームの状況でも役割って全然違ってくるので、
その時々で今、俯瞰してプロダクトとかシステムとかチームを見ている方が課題に思っていることっていうのを
しっかりコミュニケーションして吸い上げて、それをもうとにかく解決する。
その手段はどんなことでもやっていくことっていうのが、結局は裁量であったりとか実績だったりとか、
権限とか立場を作るってことに繋がってくるんじゃないかなと思うので。
なので、課題を本当に、データだったりとかもすごい大事だし、もちろんプロダクトも大事だと思うんですけど、
それをメインで職責として持っているような人と会話をしていくことも同じくらい大事になってくるので、
ちゃんと今、チームとかプロダクトとか組織の課題というところと向き合うというすごい普通のことを言ったらいいなんですけど、
大事になるんじゃないかなと僕は思います。
CTOになるためのアドバイス
その通りなんでしょうね。
今、3つのことを言っていただいたんだなというふうに思っていて、
まずCTOになりたいと思うこと、宣言することみたいなところと、
あとは自分に対して慣れるパスをアドバイスしてくれる人にひたすら聞くみたいなこと。
それからとにかく課題を解決すること。
この3つということなのかなと。
確かにもうそうだよなとしか言えないですね。
僕自身も一定その道を辿ったんだろうなというふうに今振り返って思いますね。
本当はもうこの本読めば慣れますよとか言いたいんですけど。
思いつかなくてですね。
本当に会話して苦労して頑張ってみたいなことになっちゃう。
言うのちょっと淀みましたけど。
そうだと思いますね。
でもあれですね。
やっぱり多くの方にこのCTOみたいな役割の面白さというかチャレンジの大きさというか、
味わってもらいたいなというふうに僕自身も思うので、
何かなりたいなって思う人はぜひ宣言して、
ジャンボさんや僕に話を聞きに来てくれたらいいかなと思っております。
ぜひぜひお願いします。
ジャンボさんありがとうございました。
もしお知らせなどありましたら一言二言お願いします。
はい。
株式会社デイブジオテクノロジーズはですね。
絶賛学びをアップデートしたい方に
新しいものを作りたい方というところをお待ちしてますので。
本当にプロダクトマネージャーからデザイナーからエンジニアからですね。
全方位採用してますので。
ぜひぜひお話聞きに来ていただければと思っております。
採用フォームでもいいですし、私のツイッタージャンボでですね。
お寄せいただいても大丈夫なのでよろしくお願いいたします。
はい。
そんなわけで今日はジャンボさんとCTO談義みたいな感じで
いろいろなお話をさせていただきました。
そうですね。
いろいろ再現性のないような部分とかも多く感じられたかもしれませんが。
やってみると本当に事業会社を前に進めていくっていうところの面白さみたいなのは。
この役割でしか味わえないようなものがありますので。
ぜひ本当に多くの方がここに向かってチャレンジしていただけるといいなと思っております。
さてこの番組では感想や質問リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
TwitterではハッシュタグEM問題集をつけてツイートしてください。
レアジョブテクノロジーズCTOの経験と考え
EMはアルファベット問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので。
こちらにも感想を書いてもらえると嬉しいです。
お相手は株式会社株区スタイルCOO兼CTOの後藤秀典でした。
