00:05
弊社サーバー代の補助もしているんですね。サーバー代ってちょっとみんな抵抗を感じるとこというか、自分でインフラ立ち上げてみようと思ったときに、ちょっと低くじゃないですか。
会社にとって月数千円なんてそんな大した額じゃないんで、それだけで社員が幸せになって成長して、より自分のキャリアが進むんだったら、それに越したことはないかなと思っています。
こんにちは、いわしです。普段は通信事業者で人材開発や組織開発を進める担当者として、またソフトウェアエンジニアとして働いています。
この番組では、スタートアップ企業や誰もが知っている有名企業で活躍するエンジニアの方々にインタビューを行い、彼らの作成ストーリーや人生を変えた出来事など、キャリア形成に役立つ情報を配信していきます。
今回のテーマは、キャディのエンジニアの採用と育成です。
インタビューするのは前回に引き続き、キャディ株式会社CTOの小橋昭文さん。
まずは、キャディ株式会社のエンジニア組織をゼロから作った時のお話をお聞きしました。
エンジニアの今、全然40名程度と期中の中で、結構なケースで伸びているように思えていてですね、
ちょっとエンジニア組織っぽいところも1点聞いてみたいと思っていてですね、今の中で、これエンジニア組織を作るにあたってゼロから立ち上げていく時に、これ辛かったなみたいなところってあったりしますか。
辛いことばかりですね。
特に辛かったものとか教えていただけると。
そうですよね。一番最初がやっぱり一番不確実性が高いと言いますか、ある意味私ずっとアメリカにいたので、そもそも日本に人脈がないところから始めたので、
まず仲間を探したいんだけど、さて仲間はどうやって探すんだって。
友達もいないし、どこで始めるんだっていうところがやっぱり一番大変でしたね。
やっぱりそこからいろんな知り合いの代表につなげてもらったりとか、徐々にネットワークを広げていったりとか、
あと他にもいろんな仲間を探す上でいろんなSNSみたいなものを使ったりとかして、やっといい人とつながって一緒にできるようになる時の嬉しさっていうのはすごく共感いただけたなっていう納得感もありますよね。
そういう組織を作っていく難しさと同時に、組織的な観点は正直社員3人とか4人っていったら、組織以前にまず会社が回っていないので、そっち側もだいぶ大変で、
これちょっともう創業ストーリーっぽいところであるんですけど、社員4,5人ぐらいだと全ての会社を存在させるための業務をその4,5人で回さないといけないですし、
03:04
その上でやっぱり事業成長させるということが必要で、実は私、社員多分25人から30人ぐらいまで総務ローム全部やっていたんですね。
私としてもすごい学びが多かったというか、そういう組織を立ち上げる上で、例えばコーポレートといいますか管理部みたいな方々がいかに会社を支えているかとかを本当に肌で実感できてすごく良かったなと思うんですけど、
それはやっぱり最中はすごく大変ですね。事業伸ばそうというところで追われているのに、いろいろとこういう他の間接業務もしっかりとやっていかないといけないので、そういうところはすごく初期は大変でしたね。
例えばですけど、ビルのオフィスの契約とか、そういうのを踏まえてやっていくってことですよね。
私たち電気止められそうになったこともあります。4,5人でドタバタしていると、もちろん請求書は行方不明になってしまいます。
埋もれる可能性はありますよね。
やべえ、今すぐ振り込まないと来週電気止まるみたいな。
その数人ぐらいから、かつ人脈もないところからSNS止めようみたいな話もあったんですけど、いかにこう、どう集めていって人が集まってきたきっかけとかって何かあるんですか。
そうですね、やっぱりいくつかあると思うんですけど、やろうとしていることに共感いただく方がやっぱり一番多くてですね。
やっぱり製造業出身のエンジニアは弊社少ないんですけれども、業界構造とか社会的な課題みたいなところにテクノロジーがちゃんと生きるというところがつながっているところにすごく共感いただくことが多くてですね。
そういう方々には、私たちがいかにテクノロジー、しかも最先端のテクノロジーをどうやって適用しているのか。
かつ、そのなぜ最先端があるからこそこの業界変わるのかというところをすごく共感いただけていることが多くてですね。
もちろんテクノロジー、ソフトウェア開発ってもう何十年もずっと続いているわけですし、どの会社さんもいろんなツールを入れているので、その中で何でテクノロジーがさらに必要なんですかというところは、最初疑問に思われる方もいらっしゃると思うんですけれども。
実は私たちが作っているテクノロジーっていくつかあるんですけど、やっぱりこの業界が複雑だということが、やっぱりそれをソフトウェアで表現するということがすごく難しいので。
だからこそ、業界に寄り添って考えられるエンジニア、かつエンジニアとしてはどうやってソフトウェア開発という技術、道具をいかに使いこなすかということがすごく重要で。
実は私たちの技術選定とか言語選定とかもそういうところから逆算されているというところで、私たち事業を始めたときには設計図の解析みたいなことで始まって、
06:00
こちらはちょっとライブラリとか速度の関係でC++使ってたりしたんですけど、それ以外の例えば機関システムとか生産管理システムとかになってくると、
型安全なかつWebアプリケーション開発ができる言語が欲しくなって、ちょっとC++はWebアプリケーション開発にはあまり王道ではないというところもあって、
いろんな言語を調べて、型が複雑になりやすいドメインだからこそ、いくつか候補があったんですけど、最終的にはRUSTという言語を選んで、それでアプリケーションを開発してきたんですけど、
徐々にその型がそこまで強烈じゃなくても業回るねとか、実はもっと緩い方がユーザーのためになるねって気づいて、実はRUSTから新しいものは小鳥に使い始めたりしているんですね。
ユーザーが何を求めているか、だからこそどういう技術を使うべきかというところを逆算していくと、やっぱりいろんな徐々に会社のフェーズによって必要なものが変わってくるんだなというのを感じているんですけど、
私たちの会社に仲間として入所される方々は、そういう観点で物事と向き合っていけるような人たちが多いのかなと思っております。
今のお話いただいた内容で2点質問があって、例えば小橋さんの元に採用候補者というか、これから入るかもなというエンジニアが来てお話を聞く場合に、小橋さんはどういう産業課題、業界の課題を説明されるんですか。
この製造業の多重下揚げ構造だったりとか、最適な発注ができない。これはやっぱりソフトウェアの世界にすごく似てるなと思って、そのように説明はするんですけれども、
ソフトウェアのウェブアプリケーションの世界に例えますと、開発者ではないけど企画をECサイトを作りたいですとかすると、誰にお願いすればいいのか、まず一番わからない。
だから大きなSI屋さんとかに頼むことも多いと思うんですけど、それがなぜかというと、例えばECサイトを作るのにはフロントエンドできる人とバックエンドできる人とインフラ強い人が、
あともしかしたらモバイルアプリ、これもiOSとAndroid、こういう人材が必要ですということをまず知る必要があります。それだけじゃなくて、本当に最適に一番マッチする人材を探す上では、
フロントエンドだけじゃなくて、もしかしたらその中でもリアクト派なのか、ビュー派なのか、アンギュラー派なのかとかまで実は特定できると、より不確実性の低い依頼ができる。
これをミスると、例えばリアクトの専門家にCプラのライブラリ作ってくださいと頼むと、拒否されることも多いでしょうし、
仮に拒否されなくても、多分帰ってくる見積もりにすごいバッファーが載っているはずなんですね。
というのもやっぱり本にも不確実性があるので、その不確実性分バッファー載っけているわけなんですけど、製造業もすごく似ている課題があります。
自分たちが慣れていないもの、作ったことがないものに関しては、すごくしっかりと要件が上流で決まっていればいいんですけど、決まっていないことが多いからこそ、
09:08
暗黙値というところを吸収するためのバッファーはやっぱりみんな考えてしまいます。
だからこそ、多重下請け構造になって、自分がちょっとできないものはどんどんまた外出していくから、納期が短くなって、
マージンが乗っかって、70イケとかになってくると、もうほとんどマージンがないみたいな状況になっているんです。
すると今度は下請け叩くみたいな形で、とにかくもっと安くしてくる、みたいな構造になっていきます。
こういう構造自体から開放するのには、そもそも誰がどういうものが得意なのかということをまず理解する必要があります。
だからこそ製造業のドメイン知識を私たちは身につけることが大切であって、
これはソフトウェアの世界に例えると、まずソフトエンジニアリング、一般的に理解ができた上で発注すると、
みんなハッピーになりますよね、ということとすごく似てますよ、というような話をよくしますね。
なるほど。ソフトウェアエンジニアが途中から入るのが多いという話も最初に聞いていたので、
そのソフトウェアエンジニアリングの世界のメタファーというか、例えをしてあげると非常にしっくりきそうですね。
もう1個質問があったポイントとしては、先ほどの言語のところで、途中でC++もありましたけど、
ラストを使っていて、カターンでもう少し広くてもいいかなというところでコトリンに行ったという話がありました。
そうするとやっぱり気になってしまうのは、会社の技術選定ってかなりセンシティブというか、なかなか各社困っている内容だと思っていて、
キャディという会社の中ではどういうふうにこの技術を使おうとか、この言語を使おうというのを選ぶのか、ぜひ聞いてみたくて、
例えば小林さんがこれだって決めるのか、それともさまざまなエンジニアのディスカッションを決めてするとか、
いろんな意思決定の方針があると思うんですけど、どのように決定されているんですか。
ほぼ私、口出ししないです。やっぱり現場というか、今日動かしている方々が一番分かるということがあると思うので、
逆に言語を切り替えようというお話もやっぱり現場から上がってくると言いますか、やっぱりちょっとしんどいよねとか、
実際にトレーニング的にもコスパ本当に合うんだっけとか、この言語機能って本当に我々って使えているのとか、
割とすごく慎重にやりました。一番ベテランな方々が集まって、1、2ヶ月ぐらいずっと検証実験とか含めて、
既存のインフラとか技術との互換性ということを考えていかないと、全く新しい事業を立ち上げているわけではないので、
今までのものもちゃんと尊重しつつ、それの上あるいは横にどうやって接続していくかということを考えながら技術展開をしました。
考慮するものがやっぱり多くてですね、プログラミング言語は単体ではいいんですけど、そのエコシステムだったりとか、
私たち例えばGRPC使っているので、そこのサポートがどうなんだろうとか、グラフィックウェアも使っているので、そこのライブラリどうなのかとか、
私たちインフラは全部Kubernetesで独化化されているので、それと相性はどうなのかとか、諸々確認するものが山ほどあってですね、
12:06
これを一個一個の言語で箇条書きのように軽くメモっていって、そこから徐々にあり得ないところはどんどん消していって、
最後に候補が2、3個ぐらい残って、そこからもう少し深掘りしてリサーチをしていくということを繰り返していました。
なんですけど、経験者がいらっしゃると割と省略できることも多くて、弊社も創業時はJVM系の経験者ほとんどいなかったんですけれども、
今となってはそこそこいらっしゃって、そこの長所短所をあんまり細かく検証しなくても分かっているような方々もいらっしゃるというところがありまして、
比較的楽にファクトベースでお話しすることができたのかなと思っております。
技術的な意思決定をどう進めればいいかというのは各社の色が出るところかと思います。
キャリーではボトムアップ的に現場で実際に手を動かしているエンジニアがリードしている点を伺いました。
他に、これ自社のエンジニア組織として特筆すべきというか、これ面白いなという組織的な特徴のポイントとかってありますか。
みんな勉強好きです。
例えばどんな感じでそれが見えるんですか。
勉強しすぎなんじゃないかなと僕言いたくなるぐらい勉強していってですね。
私たちの事業に共感いただける方々って難しいものが好きな方々なんですね。
難しい課題を解決しようと。
なんかもうやり方だいたい分かっているよねみたいなものには、例えばみんなでアドレス書を作ろうぜみたいなのは多分あんまり興味がない方々が多いんですね。
その不確実性が高いからこそ面白みがあるという方々が多くて、実際に業界が複雑だというところもあるし、
それを解決するために必要な技術自体もだいぶ複雑ということがあります。
なのでキャリーに入社される方々も入社からまず必死で勉強を始めるということがだいたいありまして、
理由としてはキャッチアップする内容が多いというのはもちろんあるんですけれども、
勉強すると面白いというか、その好奇心をもともと持っている方々が多くて、
だからこそ新しいものにも一切抵抗がないし、それをちゃんと検証しようという気持ちもすごい強いし、
今の現状を常に見直しましょうという観点も強いのかなと思っていて、
これで本当にいいのだったりとか、もっといいものないかなと思って、
いろいろとネットで調べ物をしたりとか、すごい気になったものをどんどん調べていくとか、
やっぱり好きな方々が多くてですね、そういう観点で過去にとらわれないというか、
今にとらわれない考え方の方が多いかなと思っています。
結果的に常に勉強して、常にもっといいものがないか探しているような方々が多いかなと思っております。
非常に勉強好きなので、ちょっと残業が危なくなりそうなことがありますね。
15:03
まさにそこを聞いてみたかったポイントで、会社によっては勉強って一種の自己懸賛というふうに捉えるので、
業務じゃないですって捉え方もあると思うんですけど、その勉強することに対して、
キャリーとして会社としてどういう支援をされているんですか。
労働なのかどうかという観点では、自己啓発は基本的には勉強は基本的に自分の時間でやってくださいというスタンスはあるんですけど、
会社として絶対本人の成長につながって、結局業務に還元される、帰ってくることだと思っているので、
勉強にあたっては例えば書籍購入の支援だったりとか、実は弊社サーバー代の補助もしているんですね。
サーバー代って多分一番ちょっとみんな抵抗を感じるところというか、
自分でインフラ立ち上げてみようと思った時にちょっと引くじゃないですか。
よくあるのは事故るとクラウド破産が見えているので怖いですよね。
そういうところを支援しておりまして、なので実は社内では予算、バジェット設けて、
弊社GCPをメインに使っているんですけど、そのプロジェクトをお渡しすると。
管理者権限を渡して自由に遊んでくださいと。
遊ぶことでゆくゆくどこかの障害対応とかでそのチキンが生きるだろうと、
私は信じてお金を注ぎ込んでいます。
会社にとって月数千円なんてそんな大した額じゃないんで、
それだけで社員が幸せになって成長して、より自分のキャリアが進むんだったら、
それに越したことはないかなと思っています。
これすごいシンプルな疑問で、実は意外にこういうの気にするってやつで、
例えばGCPの環境を使いたいって会社のエンジニアが思ったときに、
ローム担当としての質問回答ではないんですけども、
どういう申請が必要なんですか?例えばスラックで一言メンションしてOKとか、
いろんなパターンあると思うんですけど、申請書書くとか。
スラックでメッセージいただいたらそのまま管理者権限を渡します。
すごいですね、じゃあその後にプロジェクトを使っていいみたいな。
あんまりそこはしっかりしていないというか、まだ成長の課題というところでもあるんですけど、
実際にインフラ自体をどういうふうに管理していくか、
最低限すごくしっかりしているところあるんですけど、
壁の中はいろいろと煩雑なところもあったりするので、
これが具体的に何かと言いますと、権限の付与とかもほぼ全部私決済になってしまっているので、
スラックに記録残るけど、もうちょっとそこ記録残した方がいいよねとか、
大企業的な大作法みたいなところはそこまで今ない状態で、
割とリーンに回しているところではあるんですけど、
なるべくこれをトレーサブにするために、
極力全てのインフラはテラフォーム管理したりとかしていて、
実は私たち多分プロジェクトの99%CIとCD入っているんですね。
そういう意味でプロジェクトの命名規則がちょっと曖昧だったりとかもちろんあるんですけど、
18:00
俗人性は極力排除するということは、
割と注力してやっていますので、
実は新卒とかで入られる方々、時々いらっしゃるんですけど、
もう大体まず一番自分のプロジェクトをゼロから組み上げて、
CI、CD全部組んで、
俗人的にはなくてシステムに品質を担保してもらうかということの考え方とかは、
学んでもらっていますね。
新人といってもやっぱり経験に結構差にばらつきがあると思うので、
CI、CDとかある程度組んだことありますっていう人もいれば、
初めてこう学ぶっていう人もいると思っていて、
この時にどのようにその新人に知識というかスキルを習得させていってるんですか。
今の採用としては、全くプログラミングできませんという人は一切いないです。
基本的に何らかの形で経験積んでいらっしゃいます。
これが趣味の開発だったりとか、
アットコーダーみたいなプログラミングコンテストという方もいらっしゃれば、
もうずっとインターンやってましたみたいな業務経験があったりとか、
本当に中途の方々とかもいらっしゃいます。
中途の中でもやっぱり大企業とかになってくると、
自分でCI、CD組まないでも組まれてることもよくあると思うんですけど、
それは本当に私たち採用基準としては年齢とか一切問わず考えております。
なので、そういうところに知見がある方々は、
より高く評価されるような仕組みになっているんですけれども、
経験されていない方々には基本的にはやってみるしかないというか、
手を動かすのが一番手っ取り早いということと、
これは少しスパルタに聞こえるかもしれないけど、
一定は安全なところで失敗をすることが一番学びにつながるということはあると思っていて、
悪い意味ではなくて、例えばNetflixさんが言っているカオスエンジニアリングのところですね。
意図的に何か失敗させて、それのリカバリでみんな強くなっていくみたいなことは
割と大切にしているのかなと思っています。
さっき99%のシステムでCICDのアーキテクチャが組まれているというか、
そのシステム設計になっているというところで、
これいわゆる宣言的なアーキテクチャにしておくとか、
キット管理して後から終えるようにするとか、
いろんなことやられると思っているんですけど、
あれって一種の会社としての技術的な方針の一つだと思っていて、
こういう方針とかガイドライン的なものというのは会社の中にあるんですか。
いい質問ですね。確かに文章には落としていないけど、
みんな息吸うようにやってますね。
すごいですね、それはそれで。
たぶん単にそういうCICDに守られている、
守られているというかいい意味で品質が守られている環境にいると、
新しく何かを立ち上げたときの不安感がすごいんですよね。
なんか晒されている感があるので。
そういう観点でいいものはやっぱりいいとみんな認識して、
だからこそそれを作っていこうという原動力はあるのかなと思いますね。
CICD守られたシステムっていうのはすごいわかります、気持ちが。
防御力全くないですからね。最低限のテストとかはなかったりすると、
21:03
これいじったときにどうなるんだろうってめちゃめちゃ不安になりますからね。
言うて私たちもテストがすごいかばらしいかというと、
実はあんまり良くないんですね。
これ割と単純にリソースが限られているから、
どこにフォーカスするかっていうこともあるんですけど、
私たちは割と型に頼っていることが多くて、
なので型で守れない部分はちょっと漏れがちっていうか、
もうちょっと頑張らないといけないっていうのはあるんですけど、
やっぱり例えばヌルチェックとか別に書かないでも、
大体型で守られているので、
タイプスクリプトのAnyとか使い倒し始めると危ないですけど、
というような形で、これから私たちは徐々にそういうところも
頑張っていかないといけないと思っているので、
実は私たち今までQA部門みたいなものを持っていないんですね。
全員アプリケーション開発というか、
プロダクトを作るというところにフォーカスしていますと。
さすがに今40人弱ぐらいになって、
ぼちぼち車輪の再発明をやめようかなみたいなフェーズにも来ていて、
どういう車輪が必要かどうかが見えてきたっていう、
事業が成長したってことなんですけど、
だからこそプラットフォームエンジニアリングチームというのを
作ろうとしていまして、
そこの共通の部分を集約していったりとか、
これはもちろんミドルウェアみたいなところも、
インフラ的なところもいろんな観点があるんですけど、
そういう組織の在り方ということを今考えながら、
立ち上げを検討しているところですと。
同時に品質の作り込みということも、
よくQAっていうと、
響き的には最後の滑り止めみたいな、
テスターがとりあえず全網羅でテストケースやってくれますみたいな
印象もあったりすると思うんですけど、
もちろんそれも大切だと思うんですけど、
品質の本質的な作り込みって、
結局テスターが入ったところでバグはバグなので、
分かるだけですからね。
分かるだけですよね。
だったらどうやったら品質を継続的に良くできるかという、
開発プロセス自体を見に行かないといけないと。
いろんな方がプロダクトの考え方、進め方、
プロジェクトマネージャー、プロダクトマネージャーもそうですし、
DevOps的な観点もありますし、
いろんな観点で取り組まないといけないということがあって、
あんまりQAを切り出したくなかったという、
私の願望があって今ないんですけど、
徐々にそれも考えられるぐらいの、
組織のフェーズになってきたのかなと思っていて、
まさにそういうところもいろいろと考えていける中も、
探したいなと思っているようなフェーズですね。
ということは新人が始めたときには、
全然失敗してもいいような、
わりと遊びではないですけど、
実際にかなりリスクを取ってもいいようなプロジェクトを
アサインするということですかね。
そうですね。正直私たちも組織40人弱なんで、
そこまでリスクゼロのものがあるわけではないんですけれども、
基本的には何らかのサポート体制を設けて、
24:00
リスクが高いところ、本当に事業インパクトがあり得るところは、
もう少しベテランの方を搬送してもらうとかしたりしています。
極力開発組織としても、
特定領域の知見がないから貢献できないということは、
避けたいんですね。
どちらかというとそこの知見を身につけたいというモチベーション、
原動力に変えたいなと思っていて、
もちろん最低限のスキルは必要だと思うんですけど、
プログラミング一切できませんとつらいと思うんですけど、
別にCICで組んだことがなかったとしても、
それと価値が分かっていることは大切ですし、
価値が分かっていないのだったら、まず価値を知ることで、
それをやっている方々、DevOpsの方々とかの尊敬が生まれる
というふうに思っているので、
専門領域がそこから帰ってすごくたくさんあると思っていて、
やっぱり専門家としてお互いの専門を尊重するということが、
組織の健康にすごく響くんじゃないかなと思っておりまして、
そういう意味で全員が弊社のバリューである卓越、
スペシャリストであると、そこのスペシャリティを探している人もいれば、
保有している方もいらっしゃいますし、
その専門性が幅の広さであるという方もいらっしゃれば、
本当に1個の特定領域で誰にも負けんぞという、
すごい専門性、深さを持っている方もいらっしゃっているので、
そういう観点で新人、新しい方々に関しては、
そういう幅の広さと、好きなところを深掘っていくということを
すごく支えてあげたいなという気持ちはあります。
そういうような体制をなるべく取れるように、
社内ではメンター制度を設けたりとか、
そういう仕組みで組織の強さと言いますか、
組織の力で事業を進めるというところに挑戦しております。
話を聞いていて、入ったら伸びそうだなって思いました。
僕が仮に新人だったとして。
ありがとうございます。
実際にみんなすごく成長してくださってまして、
私もすごく助けられているんですね。
やっぱり人が育つことで、私の仕事が減るので、
私は楽になると。
本当にもちろんベンチャーとして、学校ではないので、
やっぱり事業を推進するために仲間を探しているわけなんですけど、
その中で頑張りたい方々を極力支えてあげたいなという気持ちはありますので、
そういう観点でメンター制度とか、サーバー補助とかやって、
自分の時間でやりたい人はやってくださいと。
そんな形なので、
割とそこの勉強に関しては、
ちょっと表現があれですけど、
放置状態というか、好きにしてる。
別に強制したいわけでもないし、
多分私、勉強の話を全くしない人たちもいるんですけど、
勝手にやってたりとか、
気づいたらあの資格取ってきましたみたいに言われたりとか。
すごくみんなそういうところに好奇心があるんだろうと思います。
最後にキャディ株式会社のエンジニア採用のお話を伺いました。
27:05
そうですね。まさに私たちエンジニア組織40人弱ぐらいで、
まさに事業をさらに拡大しようとしているところです。
そういう中で私たちプロダクトラインだったりとか、
新しい新規事業も考えておりまして、
そういう中で仲間を募集しているんですけれども、
特に今日いろいろとお話しさせていただいたような形で、
難しいものに興味があったりとか、
社会型に興味があったりとか、
技術をすごくリアルな世界に活かしたい、
みたいな気持ちを持ちの方が、
すごく共感いただけるんじゃないかなと思っておりますし、
私もパツっていますので、
ぜひとも助けを求めておりますので、
もし興味がある方でいましたら、
キャディのホームページからぜひ一言ご連絡いただければと思っております。
今回はキャディのエンジニア採用と育成についてお話を伺いました。
個人的にエンジニアは成長意欲が高い人が多い印象があります。
成長意欲を満たすために、
会社としてどのようなサポートがあるかは気になるところであり、
キャディがどのように学習へ投資しているか、
分かるエピソードだったかと思います。
皆様の学習環境構築、改善の種として、
キャディでの実践例を引用してもいいかもしれませんね。
この番組はポッドキャストプロダクションピトパのオリジナルコンテンツです。
番組の感想・リクエストは概要欄のリンクよりお待ちしています。
それではまた次回お会いしましょう。
