COOとしてのエンジニアリングへの向き合い方
株式会社株区スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、COOとしてのエンジニアリングへの向き合い方です。
本日はゲストをお呼びして、ちょっと慣れないような役職、立場というんですかね。
そこから、エンジニアリングだったり組織といったところへどのようにアプローチしているのか、いろいろなお話を聞いていきたいと思っています。
エンジニアリングマネージャーの問題集。本日のゲストをご紹介します。Progate取締役COOの宮林さんです。宮林さん、軽く自己紹介をお願いしてもいいですか。
Progateで取締役COOを務めております。宮林と申します。よろしくお願いします。
本日はよろしくお願いします。実は宮林さんとはですね、1年ちょっと前かな。
僕、Meatyさんでいろんな方とお話ししている時があったんですけども、その時にたまたまお話しさせていただいて、
わかんないんですけど、すごく僕的には感性があったというか、いろいろ同じような苦労されている方がいらっしゃるんだなというのを生きとおしたように感じてまして、
それ以来ちょくちょくお話しする機会とかがあって、今回ぜひこのPodcastに出ていただいて、これまであまり深堀りできなかったこととかを聞いてみたいなというふうに思っています。
はい、というわけで、まず最初にProgateさんっていうところでご存知の方も多いと思うんですけれども、改めて宮林さんのほうからProgateさん自身の自体のご紹介だったり、
その中でも宮林さんの現在の役割みたいなところを少しお話しいただけますでしょうか。
はい、わかりました。Progateはですね、もともと弊社代表の加藤が立ち上げた、東京大学在学中に立ち上げたサービスになるんですけれども、
立ち上げのきっかけっていうのが本人の挫折っていうところがありまして、Facebookとかソーシャルネットワーク系のサービスがいっぱい出てきた中で、
自分も世の中に価値を埋めるようなサービスを作りたいと思って、C言語の授業を取ってみたところ、全然面白くなくてつまずいたっていうところが現体験になっている。
環境構築とか、初心者がつまずきやすいポイントっていうのを取り除いてあげることによって、
より多くの人がプログラミングってものをより分かりやすく使えるようになってほしいなって思いを込めて立ち上げたサービスです。
プロゲート自体はオンラインでブラウザ上でプログラミングのコーディング体験ができて、
思ったときにすぐ学べるみたいなところを価値として広げてきたサービスとなります。
今はプロゲートだけだとエンジニアになれないとか、そっから先プログラミングだけできてもダメだよねっていう声が増えてきてしまったので、
プロゲートパスっていうサービスを新しく出していて、
こちらはCLIをダウンロードしてもらって、より実務に即した形で、
例えばNode.jsの環境構築をしているかとか、コードが自動でエラー検出ちゃんと引っかかるようになっているかとか、
FizzBuzz関数動いているかとか、実務に近いような学習とかまでサポートするようなことを目指したサービスを最近は提供しています。
なので、全体として初心者からエンジニアになれるような人たちを育てるということを中心に動いている会社ではあるんですけれども、
僕自身の役割としては、これは僕が勝手に言ってる部分でもあるんですけど、代表の葛藤の夢に橋を架けるみたいなことを結構思いとしては持っていて、
代表者がやっぱりやりたい、こんなサービスを作りたい、プロダクトを作りたいと思っているものの、
実際やっぱり東京大学在学していた学生にとって新しく会社を立ち上げるとか、運営していくとか、お金の管理をするとか、それこそ法律に適応していくとか、
IPOを目指すとかって結構ハードルが高いというか、未知の領域なのかなというふうに思っていて、
そこに至るまでの会社としてのビジョン達成に向けた時に、僕は彼の目標に向けて、例えば今だったら最高のチームを作りたいと思っているし、
もしかしたら今後IPOとか目指すときには、ちゃんとバランスの取れた、コンプライアンス準拠した会社を作りたいというところで、
自分できるところにちゃんとフォローアップして入っていこうというのがミッションとして掲げている内容になります。
ありがとうございます。なんかもういろいろ深掘りたいポイントをいくつもお話しいただいたような気がしてますけれども、
Progateのビジョンと役割
まず最初のあれですね、加藤さんの原体験というか、挫折されたみたいなところから始まっているところってものすごく強い原体験なのかなって思いますし、
世の中に同じような体験を持たれている方がいっぱいいるだろうというふうにも思うので、
そこがコアにあるのってすごく会社の成り立ちとして強い部分があるんだろうなというふうにも思いましたね。
そこは羨ましいなというふうに思います。
実際かなり強いですね。
やっぱり何か新しいサービスとか、ユーザーさんにとってこういうものを出していきたいとか、
プロダクトにこういう変更を加えたいといったときに、やっぱり加藤としてはいいプロダクトかどうか、
自分自身が救われるかどうかというところが基準値にあるので、
お金が儲かるかどうかよりは、自分が救われるかどうかが基準なんですよ。
周囲からすると、すごいビジョナリーというか、プロダクト作りに熱量があるって言えるし、
基準が厳しいので、結構クリアしていくのが大変っていう部分もあるのかなと感じます。
いやー、でもそこはすごい大事ですよね。
単に平たい言い方をすると、初心者の方を救いたいとかかもしれないんですけれども、
どう救われるのかっていうところに、代表の方自身の現体験みたいなのに加わることで、
たぶんちょっと次元の違うクオリティみたいな部分だったり、
言葉にできないような何かっていうのがそこに加わっていくことによって、
より差別化されるようなプロダクトが作れるっていうことかなと思うので、
そこはすごく面白いなと思いました。
それって何ですか?ここばっかり突っ込んじゃうんですけど、
もう少し言語化された価値基準みたいなものに消化されてたりするんですか?
どうですかね。結構バリューっていう単位で落としていて、
デリバーザベストっていう言い方を社内的にはしてるんですけど、
自分の友達とか身近な人にも心からうちのサービスいいよって
勧められるものを作ろうっていうのが一つの価値基準にはなっていて、
なので、物を作ったり何かリリースしたときに、
これ本当に自分の友達とか知り合いとかに勧められるみたいなところは、
一つの水準値としてはやっぱりありますね。
確かに確かに。それもすごくいいですね。
その一言だけでもいろんな判断を迫られるというか、
単にいいものを作るだけじゃなくて、
人に勧められるのって本当に自分がいいと思ってないとできないと思うので、
面白いですね。そこに勧めてるっていうのは。
これデリバーザベストっていう文章があって、
そのサブに心から勧められるっていうのが書いてあるから。
めっちゃ大事っすね。
結構、明星に考えると結構厳しいですよね。
厳しいですよね、心からっていうのは。
Progateのサービスと今後の展望
もうちょっとでも後ろめたいことがあったらもうできないわけですからね。
なるほど、面白いものをコアに持ってらっしゃいますね。
あとなんか気になったというか、
共感した部分としては、やっぱり宮崎さんの立ち位置と言いますか、
すごくビジョンを持っている方の実現をサポートする立場ですかね。
そこが僕自身もある種同じ立場で仕事をしていて、
ただ、なんですかね、専門性は逆なのかなっていうふうに思っていて、
僕の歌舞伎スタイルの場合は、社長もちろんプロダクトのこともかなり幅広く、
テックのこともわかるんですけども、どっちかというと金融とかそっちから来てる人がまずビジョンを持っていて、
その人のビジョンを実現するには技術のところのサポートが圧倒的に必要で、
そこを橋をかけていくっていうようなイメージで僕もやっているので、
まさに同じ仕事なのかなという感じがしますね。
確かに、かなり近いんじゃないですかね。
近そうな感じがしますね。ポジションというか立ち位置の関係性が、
そこはすごく共感しかないという感じです。
今日は宮林さんのお話をもっともっと聞いていきたいので、
もう少し授業だったり中身のところを伺ってみたいなと思っていて、
さっきプロゲートだったりプロゲートパスだったりみたいなところが出てきていたと思うんですけれども、
お話しできる範囲でいいので、もう少し今後の展開だったり、
それぞれがゆくゆくはどんな世界を作っていこうとしているのかだったりだとか、
どんな人をどういうふうに救っていきたいのかだったりだとか、
そのあたりもう少し伺って深掘っていきたいなと思っています。
確かに、ビジョンみたいなところでいくと、
たぶん代表の加藤的なところで言うと、
初心者から作れる人を見出すっていうのを理念としているので、
やっぱりイメージ自身は自分自身だと思うんですよね。
大学に入ってプログラミングの授業を取ってやってみたけど、
先生が前の方でゴニョゴニョしてるだけで、あんまりよくわからなかったみたいなところで、
面白くない、つまんないって思って挫折したものの、
その後自分で頑張って勉強して、実際世の中に動く、
自分の書いたコードが世の中に出た瞬間にパーッと世界が開けた感覚を持った、
みたいなところがカヤの原体験になっていると思っています。
僕はそれを授業に落としていく側の立場の人間で、
本当にいいプロダクト、誰かの可能性を広げるっていう彼の思いを組んだ形で、
僕が今思っているのは、いくつかあるんですけど、
エンジニアの人生に寄り添うサービスを作っていきたいと思っていて、
僕子供がいるんですよ。僕自身もプログラミング挫折者なんですよね。
もともとは40歳なんで、ゲームとかすごい好きで、
小学校の時はファミコンとかスーパーファミコンが出てきたし、
中学にはプレスで、高校ではセガサターンとかプレス2とか出てくるみたいな時代だったんですけど、
自分もゲームを作りたかったんですよ。
高校ぐらいの時にホームページビルダーとかドリームウィーバーとか使って、
ホームページ作りとかを押し始めて、
メモ帳とかの代わりにHTML書いてとか、タグ書いてとかやったりとか、
掲示板にアイコンとかを付けたかったんですけど、
レンタル掲示板だとアイコンが付けられないんで、
自分でCGI組んで掲示板作るとかをしたんですよね。
チャットルーム欲しいと思って、それもレンタルだとお金かかるから作ろうって言って、
作ってきたっていうのがあって、
それをやったんですけど、大学入って、じゃあいざ作ってみよう。
じゃあゲームってなんだ、Javaか、みたいな感じでJavaが流行り始めたので、
作り始めたら挫折したっていう経験があって、
高校ぐらいから始めてもまだ遅いのかなって気がしてます。
全然十分素養があればと思ってるんですけど、
個人的にやっぱり小学校とか中学校とか、
より早く学びたいっていう子たちがプロゲートの触り始めて、
どんどん動かしていった時に、
Progateのゲーミフィケーション
なんとなくプログラミングの概要を理解しているところから、
テキストプログラミングに入ってきて、
急に文字になった時に面白くないって感じないように、
プロゲートはちょっとゲーミフィケーションがあって、
そこから物が作れるようになってくると、
コンテンツ自体の面白さよりは、物が生まれてくる面白さにシフトしていくと思うので、
物作りだったり、実際自分が思い描いたもの、
友達と何かを作りたい、
あるいは自分の周りの何か課題を解消したいって時に、
ちゃんとコードを作って、
じゃあ今度チームを作った時に、
みんなでどういう風にコードリーディングすればいいんだろうとか、
正しいコードを書いていくには、
正しいプロダクト作りをするにはどうしたらいいんだろうってところに、
サポートできるような、
そんな長期的なサービスにしていきたいなっていう思いがあります。
なるほど。
その中でも直近で言うと、
プロゲートっていうサービスで、
初心者から一旦プログラミングが何となく分かる、
ところが今でき始めてるんですけど、
ここから今プロゲートパスっていうサービスを作り始めていて、
こっちはコードをGitで管理してくださいとか、
タスクレベルで何かものができるような、
判断ができるようになってくるんですけど、
これがうまく進んでくると、
一つ目の課題というか目標値として、
僕はエンジニア採用から書類選考をなくすみたいな目標を立てたいんですよ。
今僕、HR出身なんですけど、
よくある、僕割とどっちかっていうと好き側なんで、
エンジニアさんの経歴とか見て、
この人ってフロントだからこうだよね、
バックだからこうだよねとか言っちゃう側なんですけど、
結構エンジニアとHRのコミュニケーションよく聞くのが、
HRはどこどこの学校卒業で経歴何年ぐらいやってるかな、
この人どうですかってエンジニアに持ってくるけど、
エンジニアサイドだとこんなめんどくさいか違うでしょこれ、
プロゲートパスと採用の課題
こんな人連れてくるんだよみたいな、
ギャップが生まれてしまうみたいなのがあって、
それを受けるとHRはいいと思ったんだけど、
持ってくと急に否定されるから怖くて持っていけない、
エンジニアサイドはやっぱりいい人が欲しいし、
仲間を探してくれるHRに対して感謝はしてるけど、
よくわかんない人連れてくるのやめてほしいみたいなところがあって、
じゃあ何ができればいいんですかっていう話だと思うんですけど、
一方でエンジニアサイドもこれができるような人が欲しいんです。
例えばコードデザインパターンに当てはめて考えたことがある人連れてきてよって言っても、
HRはピンとこないんですよね。
そういうときにプロゲートパスってチャレンジタスクっていうのがあるので、
タスクベースでクリアしている、何ができるかっていうのが明確になってくれば、
お互い何ができる人が欲しい。
企業サイドもこのレベル感がある人が欲しいっていうのがわかれば、
学習者もあの会社に行きたいからこのスキルを身につけなきゃいけないんだみたいな、
基準値もわかるっていうところで、双方メリットがあるのかなみたいなことを考えていて、
事業展開的にはもうちょっと就職をあっせんしたいわけじゃないんですけど、
仕事をする人と仕事をしてもらう人をもうちょっと滑らかにつなげてあげるようなサービスにしていくことによって、
個人からお金を中心にもらうんじゃなくて、
法人のユーザーさんからお金をもらって、
より個人に還元していく形でエンジニアを増やしていくことができないかな、
社会課題の解決ができないかなっていう、今現在ちょっと思っているってところです。
なるほど。なんか結構壮大なプランというか、
まだプランとはおっしゃってないかもしれないですけれども、
ビジョンを持っていらっしゃるような感じですね。
特にエンジニアの人生みたいなのをカバーするっていうところは結構長い範囲だし、
たくさんのことが含まれてくると思いますし。
でも確かにその出発点にプロゲッジさんっていうプロダクト、ビジネスがあるっていうのはその通りだと思うので、
そういう広がりで考えていらっしゃるのって面白いなと思いましたね。
宮林さんもそのなんか挫折体験があるというところ。面白いですね。
僕は挫折だらけですけどね。
まあ誰しもありますけどね、確かに。
なんか僕は結構コロコロ変わってたタイプなので、
中学校の時の卒業文集に日本一のプログラマーになると書いてるんですよ。
マジですか。
写真残ってるんですよ、これ。
その時点で。大胆っすね。
大胆なんですよ。小学生の時はなぜか卒業文集にサラリーマンになるって書いてある。
あれ?普通じゃないですか。
何があったんですか、中学校の時。
何があったんですかね。小学生多分ひねくれてたんでしょうね。
普通が一番難しいって書いてあって。
この方がかっこいいみたいな。
変わってたんですよね。
変わってますね、それは。
中学まではプログラマーになりたいで、
情報系の学校に行きたいっていうので、
わざわざ情報系って当時少なかったんで、
商業高校に行って情報学科を受けてるので。
でも挫折しちゃったっていう。
なるほど。
挫折の方面の話に行くと、僕もいっぱいあるんで、
そこはもうお酒を飲みながら語りたいところで終わったりしますけど。
ちょっとそこは一旦置いといて。
あれっすね、プロゲートさんの方で、
最後の方に話されてた採用の書類選考とか、
そこら辺の課題感みたいなのは、確かに
僕自身もかなりの採用をやってきている中で、
課題というか難しさというのがあるなと思ってますし、
現状僕が今の会社でやってることって、
僕が見るみたいなソリューションになっちゃってるんですよ。
それは確かにうまくいくんですけど、
絶対スケールはしないので、
この先どうしていくのっていうのは考えなきゃいけないんですよね。
そういったときにやっぱり、
もう少し言語化されただったり、
システム化されたというか、
そういう基準でもって一定の、
全部じゃないにしても、
この人はこういう経験を持ってますって、
客観的に判断できるものっていうのが、
もうちょっと増えていくと、
確かにいろいろ効率的になるなと。
会社の採用する側の効率化もそうだし、
応募する側の人も、
そんなにたくさんいろんなところに応募しなくても、
よりマッチした会社を見つけやすくなるっていうのは、
絶対的にいいことだと思うので、
その辺は確かに面白いなって思いましたね。
この辺もちょっと面白さを持たせたくて、
エンジニア採用の難しさとプロゲートの提案
ProGateやるじゃないですか、
ProGateパスに入ると環境構築からスタートするんですよ。
CLIダウンロードしてくれとか、
ProGate CLIインストールして環境構築をまずしてください。
それをやると、
自分のローカル上でやった作業が、
全部チェック可能になってくるので、
そうすると動画とかを見ながら、
これやりました、あれやりましたじゃなくて、
ちゃんとできてるかどうかのジャッジが全部走るんですよね。
その求人広告みたいな、
例えば出してもらうとするじゃないですか。
そこの求人広告、
通常は応募するボタンが押せるじゃないですか。
指定されたタスクがクリアされるまで押せないんですよ。
なるほど。
事前チェックが走る形ですね。
そうすると企業が足切りとして、
タスクを作っていけるじゃないですか。
そうすると企業が作ったタスクっていうのが集まってくると、
僕らのデータベースって、
赤本的に、
どういう業界の人たちはこのぐらいのスキル感を求めてるよとか、
一般的にこのぐらいのレベル感のタスクができる人たちは、
応募資格持ってるよとか、
あるいは高難易度の企業に行きたいときは、
このぐらいのレベルのスキル感、実務経験が求められてるよっていうのが、
結構可視化されると思っていて、
それを企業サイドでも、
自社のコンテンツを作れますよというサービスにしていくと、
より企業さん的にも使い勝手が良かったり、
僕らはそれを基に生きた情報というか、
僕らの思い込みで、これが必要とされてるんじゃないかじゃなくて、
企業さんがこういう人が欲しいんだって言ってる、
そのスキルをちゃんと逆算して教えてあげることができる、
っていうのは僕らにとっての一番のメリットかなっていうふうに思っていて、
結構、
例えばウォンテトリーさんとか、
理念とかビジョンでマッチするじゃないですか、
自分の自社の思いとかやりたいこととかなぜやってるかとかを、
共感した人を取れる、理念のマッチした人が取れるってすごくいいサービスだと思うんですけど、
仮にそこにスキルもマッチしてる人が取れたら、
めっちゃ良くないですか、みたいなやつがある。
ですよね。
なるほどな。
思想的にはそういうところですね。
エンジニア採用というか、僕はどっちかというと、
HRの採用にエンジニアも入ってきてほしい側なんですけど、
入ってきてほしいと言いつつ、書類選考からお願いしますって言うと疲弊するんですよね。
ですよね。
数も多いですしね。
転職ドラフトとか、採用サービスとかでも結構皆さんちゃんと書いてくださるじゃないですか、
レジュメを。
レジュメ書いてくださってるから、やっぱりちゃんと隅々まで見たいし、
どんな経歴を持っているんだろうとか、
例えばマイクロサービス化を推し進めた経験がありますとか、
いろんなリファクタリングしたことがあるとか、
サービスだけじゃない、言語だけじゃない経験っていうのを皆さん進められてきてると思うんですけど、
そこに対して、やっぱりちゃんと見て、
あなただからうちは欲しいんですっていうのを企業サイドにはやってほしいんですけど、
あまりにも書類が多いと大体テンプレート化していって。
そうですね、仕方なくせざるを得ないとかがありますよね。
そうすると多読勝負だし、送られてくる方もひたすら山のようにテンプレメールで、
こんにちは、あなたの経歴に聞かれましたみたいなのがひたすら来る。
不幸だよな。
そうですね、お互い不幸なんですよね、それって。
数に圧倒されちゃうばかりで。
中身があると会話につながらないというか、それはありますね。
かといってキャリアを積んでいくというか、エンジニアの方のスキルアップとか、
自分自身の幅を広げていこうって思った時には、
自分の経歴書とかスキルっていうのを定期的に棚下ろししましょうってよく聞く話だと思うんですよ。
エンジニアサイドとHR側のマッチング
エージェント登録してみようとか、いろんな転職活動とかカジュアル面談とかしながら、
時には自分の経歴というか、自分の市場価値がどのぐらいかっていうのを知るのって大事だよって。
僕もそう思ってるんですけど、その都度経歴書アップするのめんどくさいじゃないですか。
ですね。
しかも読んでさえくれない人々相手に、
なんで読まない人が大半なのに経歴書をわざわざ時間かけて書かなきゃいけないのか。
書いてないとなんかいい加減だみたいに言われて落とされるみたいな。
そうですね。
結構不毛だなと思ってて。
であれば日常的な学習とかスキルアップの経験の中から、
それを市場価値の一つとしてできるんだったら、
エンジニアサイドもいちいちそんなめんどくさい経歴書を書かなくてもいいし、
そのHR側もエンジニアさんとか、
こういうこのくらいの基準だよねっていうのがある程度明確に見えてれば、
自分たちも書類選考をめちゃくちゃしなくても、
これができる人なんだっていうのでマッチングができるしみたいな。
双方楽なんじゃないかなって。
そうですね。
そこはプロゲーターさんのアプローチみたいな形も
効率化の一つになると思いますし、
もっといろいろ可能性はありそうですよね。
はい。
IT・インターネット業界に強い転職アプリGreenは、
今話題のテック企業、プロダクト開発、DX案件など、
Greenだけの良質な求人を数多く揃えています。
正式応募前に企業の中の人とカジュアル面談ができるので、
仕事内容やメンバーのことをしっかり理解した後に先行に進めます。
カジュアルに始める転職活動にGreenをご活用ください。
ここめっちゃ楽しくていっぱい聞いちゃいましたけれども、
このポッドキャスト、エンジニアリング観点みたいなところも
テーマとして持っておりまして、
いろいろ広がりのあるビジョンをもとに
授業をやっていくっていう中で、
それを作っていくプロダクト組織なのか、
エンジニアリング組織なのか、いろんな見方があると思いますけど、
そこってどういう設計というか構造というかという形に
今はなってたりするんですか?
そうですね。もともとは結構エンジニア組織と
プロダクト組織を切り分けてしまったんですよ。
ちょっと経緯を説明すると、
創業当初はやっぱりワンチームというか、
結構密にやっていたと思っていて、
10人超えてくるぐらいで、やっぱり分賃型組織というか、
代表とCTOがいて、その他メンバーみたいな形の組織に
構造がちょっと変わってきたと。
そこからやっぱり僕とかも入ってきて、
もう少しシニアなメンバーも入ってきて、
各セクションに責任者を設けて、
権限以上していこうという動きをしましたと。
やりますよね。
やりますよね。
一方で、創業当初ってやっぱりできるエンジニアが
全体を見てたほうがいいので、
モノリスな組織というか、システム設計になりやすいと思うんですよね。
そんなにマイクロサービス化しちゃうと、
逆にコストがかかりすぎるので、
速度感と1人ができるだけ全部見るっていうほうが
分かりやすいというので広げてきた。
そこからマイクロサービス三つ結合になってしまったものを
素にしていこうという動きをプロゲートでは取ってきた
という経緯があってですね。
その過程で1回実はプロダクトと技術を切り分けちゃったんですよ。
これが良くなかったですね。
なるほど。
これはどっちかというとプロダクト企画をするチーム、
プロダクトだったりコンテンツだったりをしっかり前に進めて
ユーザー価値を引き上げていく側のチームと
システム設計とか技術的塞いに向き合うチームをちゃんと分けて
攻めの開発だけじゃなくて
次のサイクルを生み出す開発投資をしていこうという意思決定で
切り分けたんですけど
切り分けてしまうと攻めたい側は
攻めたいでずっと止まってしまうし
エンジニア側では技術的塞いがあるのに
攻めたい攻めたいって何言ってんだになってしまうし
これはちょっと宮林が悪かったなっていうのをしていて
分かります、フェーズがあるっていうのは
攻めと守りが必要になってくるフェーズですよね。
技術的塞いは絶対生まれてしまうと思うんですよ。
これはないと思っているし
それは生まれたことが悪いとか全然ないと思うんですけど
一方で解消に理解のある経営者でいたかったんですよね。
技術的塞いに理解をしたいっていう
ここの解消にエネルギーを使ってください
リソースを使ってくださいってやった結果
壁が生まれてしまったんですよね。
ここを今解消して
じゃあどんな形になったかっていうと
今回もう1回プロダクトとエンジニアがガッチャンコしました。
もう1回ワンチームに戻っていて
その中にファンクションチームとフィーチャーチーム
いわゆるマトリックス型の組織に
もう1回戻したっていう経緯があって
このマトリックス型の組織も
今まだ切り切れてない部分はあるんですけど
OKR別のフィーチャー組織
例えば2C向けのサービスをグロースさせるためのチームだよとか
コンテンツ新しいパス向けのコンテンツを作るチームだよとか
みたいな目的別のチームと
各専門職が所属するファンクションチーム
クロスファンクショナルなチームに切り替えたっていうのが
今の現在のプロゲートです。
プロダクト組織とエンジニアリング組織の構造
なるほど。面白い経緯を辿ってますね。
そうなんですね。
不採が出てきた時にちゃんとそこの会社をやろうっていうのは
例えば僕みたいなエンジニアリング出身で来てる人が
経営者になったとしたら絶対そこやるってすると思うんですよね。
その時にどの程度でやってもらう具合にするのか
っていうのがすごい難しいところかなと思いますね。
そうですよね。
そっちに技術的不採の会社に1年2年かかるぞみたいにしてしまうと
ユーザーへの価値提供が止まるじゃないですか。
一方でユーザー価値提供を優先するぞってなると
技術的不採の上に技術的不採が乗るので
スパゲッティ化していくじゃないですか。
どうしようみたいな。
ここはまさに僕の現職の科学スタイルの方でも
そういう問題が出てきているので。
僕も一応意図としては技術的不採の解消的なことも
やりながらプロダクト前に進めるっていう
どっちの軸も持っている感じでやろうとしてるんですけども
やっぱりすっきりどっちかだけやってねみたいに
分けきれるわけじゃないので
なかなか現場でモヤモヤがあったりだとか
そういうコミュニケーションをしなきゃいけないとか
本当に答えがないですね。
ないですね。
僕はやっぱりプロダクトづくりというか
ユーザーファーストなものづくりをする組織を作りたい
っていうのを常々社内でも言ってるんですよね。
愛されるプロダクトにしたいんだっていう話とか
みんなに使ってもらいたいんだよねっていう話はするんですけど
じゃあ技術的負債を解消しなくていいんですかって言われると
やっちゃおうがいいよねってなるし
じゃあコンテンツとか出さなくていいんですかって言われると
いや出したほうがいいよねってなるので
そうなんですよね。どっちかじゃないですもんねそこって。
時間軸で見たときに技術的負債に投資してれば
例えば2年後3年後には毎週コンテンツが出る
これはユーザーにとって価値がめちゃくちゃ良くなりますよって言われたとして
その代わり3年間はコンテンツが出ません
逆にコンテンツを毎月出したとすると
技術的負債の解消は一切できないので
どこかでコンテンツが1年に1本出すごとに
コンテンツのリリース速度が10%遅くなってきますみたいな
そういうことですよね
半年以内だったら許容できるとか言うけど
その後3年止めるんですかみたいな
っていう意思決定を経営側で求められる
そうですね。この問題って何ですか
技術的不採と経営のバランス
ソフトウェアって目に見えないものだと僕は思っていて
コードっていうのは一旦見えるんですけれども
負債の何かありようというか
何でそういう負債みたいなものができてくるのかって
全然目に見えない世界で起こっているようなものなのかというか
もう一方僕の理解で言うと
ソフトウェアって全てが人間の脳内の物事を
一旦コードみたいなもので表現しているだけだと思っていて
人間の脳の繋がり具合というか
あり方でどんどん難しさが出てきちゃうというか
そういうことなのかなと思ってたりするんですよ
一定期間メンテナンスしないだけで
メンテナンスしづらくなっちゃう
ソフトウェアは何も変わってないのに
人間の方が多分忘れたりしててメンテナンスしづらい
だから塞いだとかなったりするんです
そういうもんだと思っているので
そういう種類の問題って他にあんまりない気もしていて
だからこそソフトウェア特有の問題の扱い方っていうのを
会社として経営としてというか
ちゃんと理解を持たなきゃいけないなと思ってますし
とはいえ答えもない感じだったりするので
難しいなとも思ってますけどね
難しいですよね
言うはやすし
半年かけて技術的不採解消しようっていったところで
物事にやっぱり不確実性がつきまとうので
やり始めたらあれもこれも出てきて
結果2年になりましたとか別にあるじゃないですか
だとすると経営はその2年に広がったタイミングで
どこで止めるべきなのか
損切りしなきゃいけないのか
いやもうここまで来たらやり切るのかみたいな
せめぎ合いを切りしなきゃいけないんですよね
なんかその不採っていうのも
いらないものを捨てるだけみたいな単純なものもあれば
形が古くなっちゃってるから
新しい形にしようみたいな
古いのものもあるかなと思っています
校舎みたいなものだと
結局その不採解消っていう表現をしてるだけで
実際新しいものを作ってるのと似たような活動だったりするので
新しいものを作るときも
必ずしも成功するとは限らないのと一緒で
不採解消自体も本当に解消になるのかが分からなかったりだとか
成功するかどうか分からないみたいな
中でやっていかなきゃいけないと思うので
簡単じゃないですね
簡単じゃないですね
これにしては分かります
でも必要だし
ちょっとそのときの組織設計は本当分からんですね
そうですね
組織設計に正解はないなって思ってるんですけど
取るべき責任を明確にしたくする形の組織構造にはしたいな
みたいなポリシーを持っていて
例えば宮林がいて
CEOとしてしているじゃないですか
エンジニアリングの責任とOKRベースのフィーチャーチーム
例えばその人が負ってる責任って何だっていうと
多分プロゲートっていう会社全体の事業と
プロダクト成長みたいなところを
じゃあ僕は責任持ってますっていう話だと思ってるんですけど
例えばそれをちゃんとOKRに基づいて
さっきOKRに紐づいたフィーチャーチームを作ってるって
お話をしたと思うんですけど
例えばVizチームは売上に対して責任を持ってくださいとか
あるいはユーザー悔い事象みたいなところに責任を持ってほしいとか
あとは例えば2C Growthとかあったら
Growthとして追うべき指標に責任を持ってほしいですとか
まるっとすると宮林が持ってる責任になるんだけど
その中の責任範囲を渡せる範囲で区切って
各チームに渡してってイメージなんですよ
そうするとそこが代わりに失敗したとしても
そこができてるかできてないだけが判断であって
全体としてできたかできなかったの責任を負うのは経営だから
安心してチャレンジしてほしいみたいなことを言いたいんですよね
もちろん手を抜いてたとかできることにやらなかったとかは
ちょっとやめてほしいんですけど
頑張ってちゃんと取り組んでいる向かおうとしている中だったら
やっぱりできる範囲でのミッションを持ってもらう
そのミッションに対して真摯にやってくれたことに対しては
チャレンジは評価するけど失敗は原点はしないところを作っていかないと
技術的塞いだけに限らないと思うんですけど
マイナスを生み出す行動みたいなのをすごい避けてしまうというか
損失回避の意識がすごく強くなるなって気がするので
ちょっと組織構造上過剰な目標値だったり
過剰な目標値を作らないように
なるべくOKRに沿った組織構造に置き換えていこうとしています
なるほどなあ
ちょっとその辺もいろいろ話したい感じではありまして
今のOKRベースのフィーチャーチームっていうんですかね
いった組織にされてるっていうところなんですけど
そのフィーチャーチームは
Viz側っていうのかな 表現ちょっと忘れちゃいましたけれども
プロダクト側とエンジニア側が一体となったチームが
そのOKRを持ってるっていう設計というふうに理解してますけど
これは合ってますか
合ってます合ってます
その時に多分それ以前のチーム構造だと
エンジニアリング側ってそこまで
プロダクトのKPIみたいなものを
責任としては持ってなかったのかもなというふうに思ってるんですが
その時結構エンジニア側からすると
大きな変化なのかなと思うんですよ
これってエンジニア的には
プロゲートさんのビジョンを達成するのに
よりフィットしてる責任の持ち方と言えるのかもしれませんし
いろんなマインドセットなのか
組織の方向性なのか
何らかの説明によって
エンジニアたちも含めてそういった目標の持ち方にするのがいいんだ
っていうような導入の仕方をしてるんじゃないのかと思うんですけど
そのあたりってどんな感じにやられたんですかね
そうですね
結構この辺ちょっと語弊がないように伝えたいんですけど
どっちかというとプロゲートって技術を教える会社だったりとか
技術的にすごい強い人たちが集まった会社だったんですよね
一方でプロダクトをどうしていきたいとかっていうところは
そこまで行こうとしては強くなくて
どっちかというとやっぱり行動に興味があるって人たちが多かった
これは別に悪い話ではないと思うんですけど
技術をもっと極めていきたい 行動を変えていきたいっていう人が多い
一方でやっぱり会社というかプロダクトの性質上を
技術者とプロダクトチームを分けてしまうよりも
エンジニアの方に直接プロダクト作りに意見をもらえたほうが
シンプルにやっぱりプログラミングを教える会社なので
よくなるよねっていうところがあって
そんな気がします
行動を変えてたいっていう気持ちはめちゃくちゃ分かるよと
分かるんですけど
やっぱりプロゲートとしてよりユーザーファースト
ユーザーに価値をどうしたら大きくなるかっていうのを考えるときには
コンテンツチームだけが作るとか
エンジニアはエンジニアリングだけするとかではなくて
一つのチームとして目標に向かって何をしなきゃいけないっていうのを
一緒に持ってほしいんだよねっていう話をして切り替えていった
企業的にも僕の中でエンジニアは今3分割してるんですよ
言っていいか分かんないです3分割してて
これ僕しか言ってないんで
プロゲートが分けてるわけじゃないです
僕個人が分けてます
僕個人は行動を書くのが好き
技術が好きな技術者と
あんま少ないんですけど
組織が好き人が好きみたいな
システムと組織って似てるよねみたいな感じの
組織に興味がある技術者と
シンプルにプロダクトが好きっていう技術者
3タイプに僕は今ざっくり分類をしていて
この中で今僕らのフェーズに合ってるのは
プロダクトが好きっていうエンジニアの方だろうなっていう認識をしていて
プロダクトが好きって方だと
そのプロダクトを通して社会にどうインパクトを与えたいんだとか
そのプロダクトを通してユーザーにどんな状態になってほしいんだとか
プロダクトをどうしたいか強いので
あくまでコードを書くっていうのが
プロダクトをどうしたいのための手法であるのであれば
チームが一緒になっていてもそんなにハレーションが起きないなっていう風に
思って今のフィーチャーチームの形に導入していったっていう
なるほど
でも結構あれですよね
今さらっと話されてますけれども
新しいOKRベースのチームになったことで
多少いらっしゃったエンジニアへの期待値というか
その辺も変えていくような部分もあったのかなとも思いますし
結果としてOKRに向かっていくようなチームになることで
エンジニアが今までやってなかったような仕事をやるようになったとか
そういう部分もあるんじゃないかなと思うんですけれども
どうですか実際は
ありますね
やっぱりエンジニアサイドから実はプロダクトこうしたほうがいいと思ったとか
インフラ周りとかをもっとこういう風にしたほうがいいんじゃないかとか
それこそ学習体験一つとっても新しい演習こういう風に作ったらいいんじゃないかとか
今のProGateだとif文とかfor文みたいな初期の初期しか教えてないけど
デプロイフローとかまでちゃんと分かるようにしてあげたいよねとか
プロゲートのビジョンとコンテンツとエンジニアリングの関わり
例えば他社のサービスに流れてしまっているユーザーさんたち
例えばユーデミーさんとかってすごい良質なコンテンツもあるけど
やっぱり動画学習だから自分の手元で動かすには自分でやらなきゃいけないので
ここは挫折者がまだ多く生まれてしまってるから
もう少し埋めてあげるようなコンテンツ拡充していきたいよねとか
一定任せることによって逆にアイデアが出てくるみたいな変化が出てきました
前はもう少し何したいんですかとか
経営はどういう目標を立てている何をしたいか教えてくださいっていう
言ってくれれば全部実現するよっていう
サポーティブはサポーティブなんですけど
その目標に行きたいんだったらこういうことしないとダメだと思う
意見が出てくるようになったっていうのが最近の変化かなと思います
めちゃくちゃ良い変化ですねオーナーシップみたいなものが出てきたってことですよね
これはすごいありがたいですね
僕もトップダウンだって思ってた意識はないんですけど
とはいえ元々ティール型組織みたいなフラットな関係性を大事にしてたんですよね
フラットな関係性がいきすぎた結果
誰がこれ決めていいんだっけみたいなところで迷ってしまって
明確にノーススターを経営者に決めてほしいっていうアクションだったのかなと思ってます
逆にノーススターさえ明確になっているんだったら
そこに向かっての生き方っていうのは少しは任せてほしい
信じて自分たちに託してほしいっていうところがあるのかなと思っていて
最近だとあまり細かいこと言わないように
なるほど
良い成果が見えているようですごく仲良かった感じですねその変化は
だいぶ良い変化になったなっていう意識はあります
ちょっと違った観点のところも聞いてみたいんですけれども
もともとプロゲートさんのビジネスというかプロダクトって
IDだったりチェックする仕掛けみたいな
よりエンジニアリングサイドで実現していくものと
それからとはいえ何をっていうコンテンツと呼んでらっしゃったと思うんですけれども
何を学習してもらうのかっていう心の中身というか
そちら側この両方がないと成立しないビジネスなのかなというふうに
僕からは思ってまして
このバランス感だったりが意外と難しいのかもしれないというか
僕がやるとしたらなんですけれども
ここが割と経営者の腕の見せ所みたいなところなのかもしれないと思ったりしてるんですが
この辺りは今のOKRベースのチーム構造で言うと
経営とリーダーの役割やOKRの分解について語る
この両方エンジニアリングとコンテンツへの関わり方みたいなところで言うと
どんな感じになってるんですか
ベースとしてはやっぱり経営とリーダーって言う場合たちで
全員傍聴自由とかにはしてるんですけど
最初の叩き台だけは少人数でガッと作ってしまって
一回それを今度全社員の前で傍聴自由でもう一回議論をするみたいなこと
そこから一定の合意というか方向性が見えたら最終的には経営が意思決定する
これでいこうって決めるみたいな動きをしていて
決めたものに対して今度OKRの分割各チームがやるんですよ
もう経営が作るものじゃなくて
経営の指標を達成するために各チームのOKRを各チームで分解してくださいしか言わないです
そうすると各チームで自分たち考えて
このプランだったらOKR達成できるんじゃないか
達成と言えるんじゃないかっていうのを設定してきてくれるんですけど
そこまで分解されてるとコンテンツとエンジニアを一緒にして
結構走ってもらってもそんなにトラブったりとかはないですね
今のお話の中でチームがOKRを決めるっていうところがあったと思うんですが
それはそもそもチーム自体はどこを担当してくださいみたいなミッションというか
そこは組合になってる
それは明確に自分たちはこの領域でやっていくみたいなのがあって
その領域の中で会社が決めてる戦略というか何かの数値目標だったり
に対してどうミートさせるのかは全部自分たちが考えてOKRにしていくということなんですか
例えば採用チームとかだと会社から前者的な採用目標で
この時期にはこういう人たちが欲しい こういうチームを組成したいんだよねっていうのとかはフィックス事項としてある
そこに対して例えばエージェントさんを活用するのか
リファラルをどんどん推進していきたいのか
経営観点と課題
自分たちでダイレクトリクルリング的に動くのかとかは
HRチームで計画を立ててほしいっていう話をしてて
会社がいちいち今週のKPIどうだった 面倒くさくどうだったみたいな
細かいマネジメントは正直したくない
分かりますそこは なるほど
でもその形で各チームがOKRを考えられる状態になってるっていうのは
かなり経営の考え方だったり戦略だったり
ベースとなる知識の共有というか
そういう部分はすごくできてるんだろうなっていうふうに思いました
ありがたいですね
でも実は恥ずかしい話はやっぱり半年1年前とか
一生懸命伝えててもわからないとか
見てる時間軸の違いだったり
メンバーはやっぱり目の前の仕事をどうしようっていう話をしてるけど
経営からすると3年後5年後にここに行きたいみたいな
どっちでもいいよみたいな状況とかやっぱりあるじゃないですか
そういうとこも含めて結構混乱が起きたのが
ビジョンを優先したい会社なのか
売上を優先したい会社なのか
エンジニアリングを優先したい会社なのかみたいな
面白いテーマですねそれ
ぶれたというか
経営的には時間軸で見たらビジョン達成を最優先だっていう話を
ひたすらしてたんですけど
とはいえ今期は売上をちゃんとやるぞっていう
目標通り売上を達成しようっていうメッセージを
出さなきゃいけなかったんですけど
ビジョン達成のためにも売上をやろうねっていう
一生の仕方をしてしまって
結果ビジョンと売上が天秤にかかっちゃったんですよね
なるほど
売上さえできればビジョンから離れてもいいでしょっていう
伝わり方をしてしまった時があって
結構進みかけてから
それだとビジョンから離れるでしょみたいな
ストップを宮林がしたんですけど
その時はあなたが売上って言ったんじゃんみたいな
すいません
なるほどな
その時はキックオフを3ヶ月に1回やってたんですけど
3ヶ月に1回だと不足してるのかなとか
伝え方的にも端的に伝えるっていうよりは
ストーリーで伝えるみたいなことを
ちゃんと意識しなきゃいけないなとか
点で伝えていくとやっぱり伝わりづらいので
線でつなげていかなきゃいけないっていうのを
伝え方の意識を変えたりとか
リーダーにはなるべく手厚く伝えていきつつ
リーダーにこの話はちゃんとメンバーにしといてほしいとか
あと警戒技術力の
センシティブ情報は除いてですけど
全公開とかを取り組んでみたりとか
とにかく混乱がなるべく小さくなるように
っていうのを取り組んで
1年くらいで落ち着いて
なるほど
そこをすごいいい話と言いますか
大事な話ですよね
そこもほんとさらっと話されますけど
やってできることじゃないと思うんですよ
なかなか成功する保証がない取り組みですよね
これやればうまくいくみたいな話じゃないと思うので
でもあれですか
情報をしっかり伝え切るというか
伝わっている状態っていうのが
必要だっていうことに
どっかの時点でものすごく強く気づかれたってことなんですかね
そうですね
結構やっぱり
メンバーワンオンじゃないですけど
時々うちの社内的にも
話さない人とかともなるべく役員的に話したい
話したいとか
前者のサーベイ撮ってるんですよ
組織サーベイ撮ってて
だんだん僕らが見えてる組織風土と
メンバーが見てる組織風土にズレを感じたんですよね
僕らは例えば家庭主義にしたい
チャレンジを後押ししたい
ミスを許容してどんどん大胆にやってほしい
とにかくバッターボックスに立ってほしい
っていう思いを持ってたんですけど
メンバーからすると窮屈とか
意見を言いづらいとか
違う方針に意を唱えづらいとか
原点主義であるみたいな
項目の数値が上がっていっちゃったんですよね
これって何でだろうなっていう風に
考えていて
話した時にも
経営者はキックオフの場とか経営の場では
どんどんみんなのことをチャレンジしろって言うけど
具体で例えばこういう時にはこういう評価をするよとか
別に落としてはいなかったんですよね
そうするとたまたまチャレンジした結果
失敗して居心地が悪くなって辞めちゃった人とか
経営者がクビにしたんじゃないかみたいな見え方になったりとか
そんなことは全然なかったんですけど
経営者の対策理由とかもちゃんとオープンにした方がいいねとか
なるほど
結構
まあ辛かったですね
そうですね
なるほどなるほど
かなりだから現場の皆さんがどういう状態にあるのか
情報の伝達と組織風土
何困ってるのかどんな思いをしてるのかっていうところを
宮林さんの方からもしっかり見に行こうとされた
常にそういうことされてる中で気づかれたというか
そんな感じなんですよね
そうですね僕はどうこうではないと思うんですけど
やっぱり組織において
戦時中の日本じゃないですけど
軽顔な情報隠すと大本営マネジメントというか
上手くいってないのに上手くいってる上手くいってるみたいな
俺たちは勝ってるっていうだけ発表し続けるみたいな
メンバーは何の情報も得られずに
うちすごいいいらしいよだけ信じていくって
すごい不平等じゃないですか
これ逆もでも実は起きるなと思っていて
マネージャーに対してメンバーどう?って聞くと
悪いこと言わないようにってやっぱりみんな
いい人が多いとなるべく悪い話をしないようにするんですよね
そうするとメンバーの正しい声って
一切経営側には伝わんなくなってしまって
マネジメントラインからは大丈夫です順調ですって上がってくる
一方でメンバーの顔色はなんか悪い
実はちょっと違うんじゃないか
この人最近笑わなくなったなみたいな思ってても
なかなかうまくいかなかったり
情報の風通しの悪さというか
良かれと思って止めてしまったものが
逆にお互いを追い詰めていってしまってたりとか
組織サーベイを取るようにして
やっぱりちょっと数字悪いよねとか
言ったけど変わらんみたいなのとか
マネージャーには伝えたけどそれって伝わってんのかな
みたいな声とかが上がってきて
そんなんで別にマイナス評価とかしないから
やっぱり上げてほしいみたいな話とかをしながら
徐々に徐々にちょっと変わっていったっていう
プロゲートの改善と採用
なるほどありがとうございます
だからそれって具体的には
どれくらいの期間のお話になるんですか
この変化がによ結ぶまで
結構リアルな話をすると
2022年1月の12月か12月時点のサーベイでは
すごい劇的に悪くて
23年3月でかなり6割改善とか
60パーぐらい良くなっているみたいな
1年ちょいってことですね
全項目の平均点が一番低かった時が
5点満点中3.4点とかまで下がったんですけど
4.2ぐらいまで戻る
なるほど
粘り強くやっていかないといけないですけどね
これを維持していくのがすごい大変
でもそういってサーベイみたいなもので
客観的な状態を検査したりしながら
改善を継続的にやっていかれてるってことだと思うので
そうですね
今後もそういったものを続けていけばっていうところはあると思います
いろいろまだまだ伺いたい点があるんですが
時間もいろいろ来ておりまして
最後の質問みたいな感じにさせていただこうと思うんですけれども
いろんなこと現場の話から経営の方から
いろいろしようとして取り組んでいらっしゃる中で
今からこの次に解かなければならない課題だったり
やろうと考えているアクションっていったら何になりますか
そうですね今課題感として一番やっぱり大きいのは
古くなってしまったシステムからどう今のモダンな形に持っていくか
っていうところが一番やりたいところです
プラスアルファでプロゲート自体の美術的不細っていう観点から
プロゲートとプロゲートパスってサービスに分かれてしまったんですけど
ユーザーさんから見ると分かりにくいんですよね
そうかもしれない
何が違うのかとか何ができて何が違うのか
っていうのが結構分かりづらくなってしまってるので
ここはやっぱりもう一回統合していきたい
そういう意味ではリファクタリングっていうところが
今一番やっていきたいところになっていて
課金システムの整備だったりアカウント基盤作ろうとかだったり
プロゲート本体の演習体験をもうちょっと今の状態に
さっき後藤さんがIDEを作ってってお話していただいたと思うんですけど
ここ例えばもうちょっとWebAssemblyというか
Wasmとか使ってもうちょっと実現していこう
もうちょっと新しい技術とか使いながら
今のプロゲートとプロゲートパスを近づけていくっていう動きをしていって
ユーザーさんから見たときに総合的に学習できるプラットフォームでもあり
その学習したものが企業にも情報として伝えることができる
希望しなければ伝わんないと思うんですけど伝えることができて
就職だったり転職だったりっていうのがどんどんできるような
プラットフォームになっていくっていうような構想はあるんですけど
人がいない
やっぱり経営がそれやりたいっていうんだったら
ちゃんと人を連れてこいよっていうのはやんなきゃいけないってことかな
なるほどってことは採用ってことですね
採用ですね
そうですね経営の仕事の大部分採用ですね
確かにですね
やっぱり採用のためにもユーザーが幸せにならなきゃいけないし
社員も幸せにならなきゃいけないし
結果満足する人が増えると
ここで働きたいっていう人がより増えるだろうなっていうので
そうですねそこは全部つながってますもんね
いいサービスといい会社を作るっていうところに尽きるのかなっていう
なるほどそこは何の否定もないですわ
お互い採用頑張っていきましょう
頑張りましょう
宮橋さん本日はありがとうございました
もしよろしければ最後にお知らせなどありましたらお願いします
はいプロゲートは今プロゲートとプロゲートパスをリリースしてまして
結構いいサービスはぜひ皆さんにも使っていただきたいなって思ってるのと
最後ありましたけど採用
結構面白いことやろうとしてるんで興味ある方いたらぜひ
ツイッターDMとかも全然構わないので
お声掛けいただけたらなと思います
はいじゃあ宮橋さんありがとうございましたまたお待ちしております
ありがとうございました
というわけで今日は宮橋さんと主に何て言うんですかね
経営観点というかCOOという立場というか
Progate取締役COOの宮林さんの考え方
そういった観点で取り組んだお話みたいなところいろいろお伺いしてですね
僕自身すごく同じ役職を持っているとして
学びのある回だったなと思っていますし
やっぱり何ですかね
まあやっぱりいろんな立場がもちろんあるんですけれども
この仕様をみたいな立場でしてきた意思決定だったり
そこで生じるいろいろな課題というか
事象みたいなところに真摯に向き合ってアプローチされてきたみたいなところも
やっぱり学びになったなというふうに思っております
さてこの番組では感想や質問リクエストなどお待ちしております
番組詳細欄にあるリンクよりお気軽にご投稿ください
TwitterではハッシュタグEM問題集をつけてツイートしてください
EMはアルファベット問題集は漢字でお願いします
そしてApple PodcastやSpotifyのPodcastではレビューもできますので
こちらにも感想を書いてもらえると嬉しいです
お相手は株式会社株区スタイル COO兼CTOの後藤秀典でした
