00:00
日本最大級のエンジニアコミュニティQiita、プロダクトマネージャーのKiyono Toshifumiです。
この番組では、日本で活躍するエンジニアをゲストに迎え、キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに役立つ話題を発信していきます。
前回に引き続き、ゲストは株式会社Kyash執行役員VP of Engineering小西裕介さんことKoniferさんです。よろしくお願いします。
よろしくお願いします。今回はKoniferさんが今されているVPoEというお仕事について、いろいろお伺いをしていきたいなと思います。
Koniferさんとお送りする2回目のテーマは、役職が変わると何が変わる?VPoEから執行役員へのキャリアチェンジです。
前回でも軽くお話しいただいたかなと思うんですが、VPoEとしてどういうお仕事をされているかみたいなところをお伺いしてもいいですか。
VPoEって結構他社によって違いますよね、各社。CTOと切り分けているところもあれば、VPoEだけというところもあるし、置いていないところもあって。
Kyashの場合はVPoEだけなんですね。CTOが今いないので、実質その開発部門全体を取りまとめるのが仕事ですね。
やっぱり開発組織のことは一番分かっている人として、ビジネスだったり経営ともやり取りするっていうのが、すごい抽象的に言うと仕事の内容ですね。
具体的に言うと、開発の中で、これは授業のやるべきこととは関係なく、このぐらいまでにやっとかないとまずいよみたいなのあると思うんですけど、
それを明確にして、経営なり他の開発の経験がない方たちにも分かるように伝えて、ちゃんとその計画に織り込んでいくとか、そういう翻訳っぽいような仕事もあれば、
開発の中で言うと、採用を含めて何かをできるようにしていくために採用化、育てていくか、外部から引っ張ってくるなりするか、外注とかも含めて、それをどうしていくのかを考えたりしてますね。
っていうのが、綺麗に言うとそうで、そんなに綺麗にいかないことの方が多いんで、そんなスマートに問題を整理して、一個一個こうしたらいいからって言って、バシバシ決めていってる感じではない、正直。
常に問題が起きるんで、それに対して自分が手を動かすっていうのを選択肢に入れながら、じゃあどうしよう、ずっと続けてっていう感じですね、愚直に。
03:02
ありがとうございます。イメージで言うと、エンジニアリングマネージャーみたいなものは役割として存在すると思うんですけど、それのもう一個上のレイヤーというか、そこを包括して本当に開発組織全体の方向性を決めていくとか、組織をどうスケールさせていくかみたいなところとかを決めていくみたいなイメージなんですか?
そうですね。EMだけで考えるよりも、広い視野で物事が考えられるようにしていかなきゃいけないところはありますね。
例えば、全体のモチベーションが下がっているように見えるとか、採用がうまくいかないみたいになったときに、いろんな理由があって、ちゃんと意義を伝えられていないみたいなのはもちろんあるかもしれないですね。
それはEMでも一定できるところはそういう観点はあると思うんですけど、明らかに市場環境に負けているみたいになったときに、じゃあエンジニア自体の報酬の見直し、全体的に考えようかみたいな話って、各チームのエンジニアリングマネージャーからは出るかもしれないけど、力強くお勧めにくいと思うんですね。
なので、そこはもうちょっと干渉の広い立場でグイッと推し進めた方がやりやすいっていうのはあるんで、あくまで一例ですけど、考えられたとしても推進がやりにくいっていうところを全部カバーするっていうのはこの役割ですね。
マネジメント全般そうかもしれないですけど、その中小度合いがより高い感じはしますね。
より中小度っていうところと、広さというか組織一つではなくて会社全体のところの方針もアプローチとしては。
そうですね。
エンジニアリング自体の難しさとか課題以外のところで頭を悩ませることの方が多いかもしれないですね。
ありがとうございます。
ちなみに今エンジニアリングマネージャーのお話もあったと思うんですけど、役割というかやることとしてどういう切り分けというか墨焼けをしてますか。
EMとってことですか。
そうです。逆にこういうところはもう任せてるとか、こういうところは自分がオーナーを持ってやってるみたいなのがちょっと気になりました。
今のEMは事業部制を強いてるんで、事業部ごとにマネージャーを置いているっていう体制ではあるんですけど、実際職のごとにモバイルとかサーバーサイドとかごとにやっぱり得意分野があるEMなんですね。
モバイルサーバーとあとSREとか。なのでそこのナレッジとか経験に関しては自分より全然あるんで、技術的な意思決定だったり課題の抽出、職のごとに見えている課題の抽出とかは完全に頼ってますね。
あとは採用の見極めも完全に頼ってますね。
06:02
やっぱり自分よりプレイヤーとして長く行動を書く立場により近い人の方が正しい意思決定もできるっていうのはあるんで、ちょっと分からない部分はなるべくお願いするようにしてますね。
ありがとうございます。じゃあ詳細みたいなより現場に近いところは任せしてるっていうイメージですね。
そうですね。
ありがとうございます。今のお話聞いて、ちょっと僕も参考にお伺いしたいなと思ったんですけど、いわゆるマネジメントのレイヤーっていうのが上がれば上がるほど、それこそ本当に現場の課題とかそういうところってなかなか見えづらくはなってくるかなと思います。
とはいえ会社として、開発組織全体として旗振り方向を決めていくってなると、そういうところの現場レベルでの課題みたいなところを吸い上げて、いろいろ判断をする必要がある場面も多いんじゃないかなと思うんですが、そこら辺の課題の把握ってどうやってされてますか。
多分今はそこまで仕組みで工夫しなくてもなんとかなる希望ではあると思いますね。
30人以下なんで、エンジニアの数といっても、スラックの様子とかを眺めてるだけでもある程度キャッチアップできるぐらいだから、こういう風にエスカレーションの仕組み作ってるみたいなのはそんなに実はないんですよ。
作れてないって言ってもいいかもしれないですけど、雑談とか接点がある中で話すことが多いですね。
今だと1on1を直接見ている部署のメンバーとEMとで定期的にやってるんですけど、そこで最近この人が疲れてるもそうだし、このプロジェクトちょっとヤバそうとか、この辺ちょっと不安に感じてるみたいなのを話して一時情報で聞いていくっていうのがありますね。
レポートラインを作るっていうよりも日々いろんな方から情報キャッチアップして情報を集めてるってことですね。
ちょっと作った方がいいんだろうなとは思ってますね。なかなかそこがうまくできてない分、全部自分がこう一時情報まで見ていくっていうのがあんまり良くないんじゃないのっていう指摘は他の部署のいわゆる部長だったり役員の方から言われたりがしますね。結構言われますね。
ありがとうございます。ちょうどKiitaも今開発組織全体で20人弱ぐらいの結構小さめの組織があって、その中で僕も開発組織のマネージャーとかをいろいろやってはいるんですけど、やっぱりKiitaもそういうレポートラインみたいなの全然なくて、日々僕も頑張っていろいろキャッチアップしてるみたいな中なんですけど、いろいろ情報把握するって中で意識していることとか、それこそ例えば101とかでも言ってくれる人もいれば言ってくれない人もいれば。
そういうところをどうやって情報を引き出すかって言い方が正しいかわかんないんですけど、うまく自分に集まるようにするみたいなところで工夫してることとかありますか。
09:04
引き出しではないんですけど、言ってくれたらとにかく感謝はしますね。これは本心からですけど、悪いニュースほど集まってこないんで、自分は見えてないから教えてほしいっていうスタンスっていうのは何とも伝えるようにするっていうのは一つあるかもしれないですね。
ただそれだけで言ってくれない人っていうのは当然いるんで、そういう人からは無理に聞こうとはしなかったりもしますね。特に課題に関してはそうなんですけど、1on1とかで何か課題あるかみたいな話をすると、ない課題まで探しに行っちゃうみたいなのがあって、
すごいネガティブな方向に自分が誘導しているような感覚になるのも嫌なんで、言ってくれない人は別にそんなに追わないようにはしてますね。逆に言う人に関しては視野をもっと広げていろいろ教えてもらったりとかっていうのはありますね。
じゃあ言ってくれる人から積極的にコミュニケーションをとってしっかりとっていくというのはすごい参考になります。あともう一個ちょっと話が変わっちゃうかもしれないんですけど、先ほどもお話の中にあったVPOEとCTOっていう言葉があるじゃないですか。
この役職結構似てる側面もあれば、やっぱり違う役職として置いているって会社も多いなと思っていて、VPOEとCTOの違いってどういうところなのかなみたいなのをお伺いしたいなと思っています。
これも各社違うと思いますけど、よくあるのはVPOEが組織的なところを見てCTOが技術的なところを見るみたいな話はありますね。
自分は今VPOEだけなんで、名前としてはエンジニアリング組織の取りまとめとか成果の最大化っていうところなんで、技術かどうかみたいなのは名前には入ってはいないんで、最終的には技術も含めていろんな意思決定していくっていうのが今の役割なんで。
他社でいうCTOみたいなこともちょいちょいやってはいると思いますね。カバーしきれてるかわからないですけど、この2つをあんまり分けてうまくいくかっていうとどうなんですかね。
一緒に全部一人でやった方がやりやすいっていうことも結構あるんじゃないかとは思ってますね。
組織の取りまとめとか、組織を拡大していくみたいなところとか、組織を作るっていうところと技術的な話ってあんまり切っても切り離せないところがあるんで、
2人いた時に、割と毎日レベルでいろんなことをシンクしていかないとボールが落ちてしまったり、ちょっと考えが合わなくて逆にスピードが落ちたりすることもありそうなんで、分けるとしたらきっちり役割を分けるというよりも役割の分け方も常に変わると思うんで、
12:04
それをいかに頻度高く動機取るかっていう風に工夫した方がいいんじゃないかなって思ったりはしますね。毎日飯食うとかそれぐらいのことやった方がきっとうまくいくのかなって想像はしますね。
ありがとうございます。いわゆる婚委の法則とかいう組織とシステムって結構表裏一体だよねみたいな話は結構有名だと思うので、僕も結構そこが気になっていて。
逆にVPOE、CTOっていう2つの役割を置くことのメリットみたいなところってどういうところにあったりすると思いますか。
うまく分けて考え方の根っこのところとかが合ってたらメリットはすごいあると思いますね。やることがとにかく多いんで、VPOEだと採用の部分とかに力を入れたり育成に力を入れたりみたいなのも結構あると思うんですけど、
それ以外のその技術的なところもできなくはないですけどもっと高いレベルのことをやろうとしたら多分一人でキャパが収まらないとかになると思うんで、分けることによってそれぞれがより高いレベルの組織の部分と技術の部分の道を指し示すみたいなことができるようになるとは思うんで、うまくいけばすごい良いとは思いますね。
ちなみにキャッシュ室さんだと今の希望館とかだと組織系のいろいろ課題か技術系の課題かでいうとどっちのほうが頭悩ませることが多いですか。
技術的な課題が組織のところから来るっていうのもあったりはするんで、あんまりどっちっていうのは言いにくいかもしれないですけど、解決したいのは技術的な課題ですね。そのやり方として組織の部分も補強したり採用もやったりしていかなきゃいけないっていうのが今の状況のような気はしますね。
技術の課題がまずあって、そこのソリューションとして組織をうまく変えていくとか改善していくところがあるってことですか。
そうですね。それより前にこの事業的な課題があって、それを技術でなんとかできそうとか、先に技術面の課題解決しとかないとっていうのがあって、で、組織のところをなんか手声でしていくっていう順番な気はするんで、組織のほうをまず解決しなきゃみたいな感じではない気はしますね。少なくともエンジニアリングの組織に関しては。
ありがとうございます。今のお話ここまで聞いてみると、現時点でのキャッシュさんでいうと、肩書きとしてVPOEを使うかCTOを使うかって結構役割的にはあんまり相違がない感じなんじゃないかなって思うんですけど、今ここにファーさんとしてVPOEという肩書きを使い続けているなんていうんですかね。気持ち的な理由ってありますか。
いや、ないですね。もともとCTOに脱進されてVPOEになって、いろいろあってこのCTOが割と前に退任されたっていうのがあるんで、そのまま肩書きとしては維持しているっていうだけなので、あとCTOかどうかっていうのは、なりたいっていう意思は言っていったほうがね、ある人は言っていったほうがいいと思うんですけど、自分で名乗ってなれるものじゃないと思うんですね。
15:19
役員だったと思うんで、市医なんで、そうするとプロセスとしては役員会で決議して取締役会で承認されてっていうプロセスだと思うんで、あくまで経営のほうからCTOがいないことによる課題っていうのが明らかになった上で、それを誰にお願いするのかって考えたときに提案されるものだと思うんで。
なんか自分からCTOに名乗ったほうがみたいな感じはあんまりまだなかったですね。
そこはそんなに重要じゃないって感じですね。
おそらく、でもちょっと考え切れてないと思いますね。やっぱりCTOがいるっていう会社、例えば求人のサービスとかでも、その人の指向性を入力するフィルターの欄にCTOがいるみたいなチェックボックスがあったりもするんで、その対外的な影響とかもそうですし、やっぱりVPOEとCTO、役割としては似てても、
ほぼほぼCTOみたいなことをやってますっていう状態と、CTOになりましたって全然違うんですよ、多分。
これは僕もVPOEから執行役にVPOEになって、何も変わらず粛々とやるだけやって思ってたら全然変わったっていう経験はあるんで、やっぱり名前が変わることによって意識も見られ方も変わるっていうのはあるんで、多分自分がもっと考えたほうがいい話なんだと思います。
ありがとうございます。
あんまり言語化できてないところだと思います。
今のお話の中にあった、執行役員になって変わったって話だったじゃないですか。具体的に何が変わったかみたいなところをお伺いしたいんですか。
見られ方が結構変わりますね、やっぱり。この人はこういうふうに、こういうようなことをしてくれるはずだとか、こういう責任を持っているはずだっていうのが、やっぱり名前が付くと各人の中で具体化されるんだと思うんですね。
執行役員もそうですし、エンジニアリングマネージャーとかテックリードとか何でもそうだと思うんですけど、なんかテックリードっぽいことをやってますからテックリードになると、多分プレッシャーはだいぶ変わると思ってて。
執行役員になったときの変化としては、やっぱり見られ方。どういう見られ方かっていうと、印象的だったのはエンジニアじゃないですけど、役員としての意見ですかって言われたことがあって、何か言ったときにああーって思って。
今までは何かを前に進めたり問題解決するために別に立場とか関係なく物事を言って進めてたんだけど、ポンって言った一言がそういうふうに重く捉えられることもあるんだって思って、結構衝撃を受けてそこから注意するようになりましたね。
18:11
別にそれ自体が良い悪いとかではなくて、そういうふうに感じる人も社内にもいるし、きっと社外にもいるだろうと思うんで、ちょっとこれはスタンスを変えねばって思った良いきっかけだったりはしますね。
ありがとうございます。今のお話だと、やっぱり肩書きが変わって責務も変わって見られ方も変わるっていうお話かなと思うんですけど、それはコニファーさんにとって何て言うんですかね。良いことか悪いことかって聞くのは難しいかもしれないですけど。
これはでも明確に良いことだと思いますね。
そうなんですね。
これ事象でも良いと思うんですけど、何かを担ったり何かをやるって決めた時は肩書きを名乗った方が良いと思いますね。肩書きが付いてないんだったら付けに行くような動きをした方が多分自分のためにもなると思いますね。
やっぱりプレッシャーがかかるとそのために何とかしようとして全体のクオリティが上がるんで、自分の一挙手一投足、発言、何かをドキュメントを書くとかもそうですし、何かより成長するというか良い方向に進むと思うんで、名付けは自分にした方が良いと思いますね。
じゃあ考えることとか責任っていうのは変わった一方、ある意味でやれることとかも変わってきたというか、そういうところはコニファさんにとってはいいことだったってことですね。
そうですね。なんでこれからも積極的に名付けは結構意識した方がいいなと思ってますね。先ほどのあんまり考えられていないCTOの話もそうですし、チームの中で役割作る時とかもそうですね。
はい、コニファさん今日はありがとうございました。
ありがとうございました。
まだまだお話ししたりないので、次回もコニファさんとお送りします。
はい、ということで今回はですね、VPOEというお仕事についていろいろお伺いをしてきました。
何かこういう仕事なんだろうなっていう印象は僕の中であったんですけど、やっぱりその印象の解像度がすごい上がったというか、
肩書きっていうもので変わるものもあれば、やれることも変わるし、その中で新しく考えることとかもいろいろ増えていくんだろうなっていうのがすごい感じました。
僕も今は社内の肩書きで言うとマネージャーではあるんですが、多分これからもこう変わっていく可能性は全然あるかなと思うので、
今日のお話はすごい参考にしてこれからもいろいろ考えていきたいと思います。
ありがとうございます。
さてこの番組で完成次回ゲストへの質問、リクエストなどをお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
Xではハッシュタグ聞いたFMをつけてポストしてください。
表記は番組名と一緒でQFMが大文字、残りは小文字です。
そしてAppleポッドキャストやSpotifyのポッドキャストではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
Kiita株式会社はエンジニアを最高に幸せにするというミッションのもと、
エンジニアに関する知識を記録、共有するためのサービスKiita、
社内向け情報共有サービスKiitaチームを運営しています。
21:01
ぜひカタカナでKiitaと検索してチェックしてみてください。
来週も火曜日の朝6時に最新話が更新されます。
番組のフォローをして最新話もお聞きください。
お相手はKiitaプロダクトマネージャーの清野利文と、
株式会社キャッシュコニファーでした。
