00:06
CTOのTが果たしてテクノロジーなのか。
テレフォンもやりますし、特幹工事もやりますし、 創業時はトイレ掃除もやってたんで。
私はリーダーシップ的なスタンスとしても、背中を見せて、 自分ができないことは、人に言っても説得感があんまりないだろうなと思っているタイプなので、
誰かにやれって言うなら、自分でまずできないといけないと思っていると。
こんにちは、いわしです。
普段は通信事業者で、人材開発や組織開発を進める担当者として、 また、ソフトウェアエンジニアとして働いています。
この番組では、スタートアップ企業や、 誰もが知っている有名企業で活躍するエンジニアの方々にインタビューを行い、
彼らの作説ストーリーや人生を変えた出来事など、 キャリア形成に役立つ情報を配信していきます。
今回のテーマは、有名企業からスタートアップのCTOへ。
インタビューするのは、キャディ株式会社CTOの小橋明文さん。
小橋さんは、ダンフォード大学、大学院で電子工学を専攻。
卒業後は、世界最大の軍事企業であるロッキードマーティンや、 アメリカのアップル本社などでエンジニアとして活躍。
2017年に、キャディ株式会社を加藤さんと共同創業。
まずは小橋さんに、ロッキードマーティンや、 アップルでの仕事内容についてお聞きしました。
ロッキードマーティン社の軍事開発とかって、 普通の一般のソフトウェアエンジニアからすると、
多分知り得ないことしかないんだろうなと思っていてですね、
何かそこで得た経験とかで、お話しできるものって何かありますか?
ソフトウェアの開発というところに関しても、
たぶん後で製造業って、私たち関わっている領域にも 繋がってくると思うんですけど、
ソフトウェアの開発って割といろんな産業で利用されていると思いますし、
それの中で軍事企業だったりとか重工ですね。
日本国内ですと三菱重工さんとかIHIとか、
いろんなところで領域に挑戦されている方々も いらっしゃると思うんですけれども、
たぶん一番の特徴というのは、 ハードウェアを扱っているというところで、
もちろんクラウド上の開発もすごく多いんですね。
どの会社も機関システムがあったりとか、
ドキュメント管理が必要だったりとか、 いろんなものがあるので、
そういうところはどの会社行っても共通だと思うんですけど、
特に軍事企業というと、やっぱりみんな戦闘機とかジェットエンジンとか、
そういうところを創造されると思うんですけど、
それの周辺にもすごくいろんなソフトウェアの開発が必要で、
もちろん例えば制御、ASAの制御ソフトがあったりとか、
一応するんですけど、同時にASAとの通信ソフトが必要ですし、
通信となるとインターネットの世界でも利用するUDP、TCPみたいな概念が出てきたりとか、
安全にどうやったら暗号化するかとか、
そういうセキュリティのお話も出てきたりとか、
03:01
実は抽象化するとすごい似てる概念が多いんだろうなとは思っていて、
確かに少しクラウドの世界からすると、
少し遠い存在に感じることもあるかもしれないんですけど、
実はすごく似てることもたくさんあるなと私は個人的に思っています。
今さっきロッキー・ド・マーティンというちょっと軍事的なところっていうところだったんですけど、
例えばAppleの開発とかでこれ特徴的だったなみたいな、
面白かったこととかって何かございますか。
Appleに入社しようと思ったきっかけでもあるんですけれども、
とにかく品質にこだわっているというところはすごく大きくて、
常々これはお客さんのためになりますか、これはユーザーのためになりますか、
というのが全ての開発にあたって問われるところがありまして、
これは本当にそのUIの1ピクセルを直すことで喜ぶ人がいるんだったら絶対やるべきと、
逆に社内の開発者向けの改善はだいたい後回しになるというのはあるんですけれども、
それでもユーザー体験にそれが最終的につながるのであればやりましょうと、
やっぱりそういう意味で本当にユーザーのために全て会社のリソースを尽くすというスタンスがすごくいいなと思っておりまして、
中途半端なものは絶対出さないっていう、リリース遅らせるか、
もう今年諦めるっていう判断もすることあるんですね。
それでもいい体験をちゃんとユーザーにお届けするということにこだわっている、
ということはすごく私としてはいいなと思っております。
この考えはかなりキャディにも応用されているものもあるんですか?
そうですね、本当にユーザーが何を求めているかということはやっぱり常に意識することが重要なんじゃないかなと思っておりまして、
特にAppleとかですと消費者向けなので、消費者がどういうものを求めているか、
もちろん消費者は常にいいものを求めているということがあると思うので、
そういう判断に至っていると思うんですけれども、
エンタープライズとか、弊社キャディですと割とB2B、他の法人とのお取引が多いので、
そういう法人がどういうものを求めているのか。
例えばコップとか、塗装を青く塗ってくださいという注文が来たとします。
青って何ですかという話になり、
ウェブの界隈とかですと、RGBの情報をくださいと。
カラーコードがもらえれば、その通りに作れますよという話なんですけれども、
RGBのコードが分かりませんということもあるんですね。
要は目の前にあるんですと、これをもう1個作りたいんですというときには、
その色というものをどうやってデータ構造として表現するのかとかは、
割と難しくなりやすい。
色は指定はあるけど、RGBでは表現できなくて、色見本というんですけど、
実物を送ってくるみたいなことがあったりするので、
そういう意味で私たち開発上のユーザーが何を求めているか、
それをいかにソフトウェアに反映するかというところに
執着して開発を進めておりますので、
06:01
もちろんAppleの消費者向けの製品ほど、
ピカピカのピクセルパーフェクトのものが必要かというと、
実はそういうものはユーザーが求めていないことも多いですし、
もちろん私たちのビジネスとしては、ソフトウェアを売っているのではなくて、
金属加工品の製造をしているので、やっぱりその商品がいいことが一番重要なんですね。
そういう観点でユーザーに何ができるかと、
そこにいかにリソースをフォーカスさせるかというか、
余計なことをなるべくしないようにするかということを大切にしているというところは
共通かなと思いますね。
ユーザーが何を求めているかというところを探すのって、
かなり実は大変だと思っていて、各社苦労していると思うんですよね。
ユーザーの課題を本当の課題を見つけるために何か工夫されているとか、
これ取り組みされているというポイントってございますか?
そうですね。やっぱりユーザーさんが何を求めているかというのが、
この産業の製造業というところの大きな課題なのかなと思っておりまして、
これが何かと言いますと、
例えばこの部品を作ってくださいという設計者がいます。
設計者は最終的な結果を描きます。
例えば各メーカーさんの中には設計者がいて、
外に発注する、購買担当みたいな方がいたりします。
その方はいろんな加工会社様に、
この特注品のオーダーメイドの設計図、何円で作れますかという質問をするわけです。
そこでいろいろと見積もりを取って、条件がいいところに発注するというような仕組みなんですけれども、
この中でもちろん価格というものはいろんなパラメーターで変動すると、
そのパラメーターが暗黙の理解になっていると、
無意味に上がったり下がったりしやすいということがありまして、
まさにユーザーが何を求めているかが分かりにくかったら、
価格も正しく出せないということがあります。
割と今の産業構造的には、上流のほうが設計とかですね、
そこをめちゃくちゃ厳密に指定しないことが多くて、
空気読んでくださいよみたいな雑に言うと。
これソフトウェアの世界でもSI予算とかでよくあると思うんですね。
比較段階からなんとなくフワッとワイヤーだけ書かれて、
じゃあこれいくらできますかとかワイヤーすらないみたいな。
いい感じにしてみたりとかありますね。
もちろんそれだけだとゼロの桁2,3個以内には多分見積もりできるけど、
ゼロが1個か2個か3個ぐらいは余裕で求めるものによって変わるということがあると思っていて、
製造機はまさに全く同じ構造になっているんですね。
これを理解するということが両方向あって上流の方がちゃんとお伝えするということと、
下流の方でもちゃんとそれを把握しに行くとか、
それを確認しに行くということ、両方向の寄り添いということがすごく重要なんじゃないかなと思っています。
なんですけれども、特に製造業、ソフトウェアだと割といろんな産業と向き合っていることが多いので、
同じSI予算でも例えばECのサイトやってから次はモバイルアプリやって、
09:02
ゲームやってとかいろんな産業とお付き合いがあることが多いと思うんですけど、
製造業ももちろん似たそういう会社さんもいらっしゃるんですけど、
ずっと車やってますみたいな会社さんだったりとか、
ずっと同じ会社の下請けをやってますという会社さんとかいらっしゃると、
やっぱりその外の世界というかその分母がわかりづらいので、
例えばずっと車をやっている会社さんも実は工場の設備も作れるけど、
自分がそういう品質基準で作れることを知らないということがよくあるんですね。
私たちはこういうところがすごくもったいないと言いますか、
例えばこの1年でコロナで少し車業界とか落ち込んでた時に、
もちろん車業界に依存している町工場様とかは売上が当然ですけど下がっていってしまうんですけれども、
でもそういう会社さんって実は能力的には全く別の業界の製品も作れる能力が持っているんです。
けどそこのやっぱり要件の擦り合わせっていうことがすごく難しいからこそ、
なかなか別の産業に栄誉をかけづらいとかかけても、
例えばお互いの品質基準の擦り合わせに時間がかかってお互い警戒してしまうとかいうのがあるので、
私たちキャディではものづくりのポテンシャルを開放しようというミッションを抱えているんですけれども、
ものづくり産業のそのポテンシャルっていうことがやっぱり本質的に持っている能力と、
それが応用できる領域ところが完全にマッチしていないことがあるというか、
全てのポテンシャルに適応できていないというところがあるのかなと思っておりまして、
そういうところをソフトウェアの力と、
あともちろん私たちのオペレーションの社内の受発注というスキルと、
あと製造業のドメイン知識、加工という金属加工の専門知識、
この掛け算で私たちはこの産業にバリを出そうと思っております。
製造業界の中にもきっとサブの様々な細かい区分けがたくさんあると思っていて、
その区分けごとに一種のサイロというか多骨棒化されているような状態が消えている可能性があり、
まさに小林さんのおっしゃっているようなことは、
多骨棒の横通しでもドメイン知識とか流出させるような、
一種の教会に対する大きなインパクトを与えるような仕事もされているような印象ですね。
すごい大きなミッションだなということは理解できました。
本当に複雑な教会構造ですし、多重下請け構造といいますか、
これはすごくSISさんと似ていると思うんですけれども、
そういうところにすごく課題感を感じて、
加藤と3年半前に共同創業したという経緯でございます。
小林さんの話を聞いていると、
例えばキャリア的にはロキドマーチンからアップル本社に行くみたいな話で、
いわゆる一般のエンジニアからすると相当花々しい履歴のように見えていて、
これを手放すのかと思う人もいらっしゃると思うんですよね。
なので、アップルを辞めてまで創業に至ったという、
自分のターニングポイントというか、
どういう思いに至ったというところを教えていただきたいと思うんですけど、いかがでしょう。
創業自体に関して、なぜ創業しようと思ったかというところと、
12:03
あと同時に何を失う覚悟でアップルを辞めたかという、
両方あると思うんですけど、やっぱりもちろん当然大企業ですごく成功している企業なので、
それなりのブランド名があったりとか、いろいろあるんですけれども、
私としては自分の発揮する能力とそれのインパクトを最大化したいという気持ちが強かったというところが一つありまして、
もちろんインパクトを出せるところもたくさんあります。
それを否定しているつもりは一切ないんですけれども、
より大きなことが自分でもできるんじゃなかろうかと思って創業をしました。
もちろん創業にあたって不安なことはいくらでもあるんですけれども、
何もないところからゼロから会社を立ち上げるということなので、
この事業は成功するのかという不安だったり、
そもそも会社ってどうやって回すのかという、まず知識を身につけないといけないという不確実性が非常に高いというところとか、
いろいろとありました。
なんですけれども、やっぱりそういう不確実性と向き合っていくことで一番バリューが出せるんじゃないかなと個人的に思っておりまして、
分かっていることをやっていても分かっている結果しか出てこないので、
大きな変化はないだろうなと思っていたというところが大きいのかなと思っております。
おっしゃっていた大きな変化というのがまさに今体験されている感じですかね。
そうですね、まさにまさに業界構造を変えるとか、産業自体を良くするとか、
人に関してはやはり、もちろん私一人でもできないですし、
たくさんの人の力を借りてやっていかないといけないことなので、
だからこそ会社としても成長させないといけないとか、いろんなところがあるんですけれども、
日々私たちも4年近くキャリーやっていますけれども、本当にいろいろな方々に助けられて、
本当に私たちがこれまで築き上げてきた基盤だったり知識だったりを振り返ってみると、
やっぱりこの産業に私たちがどのようなインパクトを与えているかということがすごく分かってきて、
もちろん始めるときは正直だいぶ無邪気というか、知識がないのでできるでしょうという、
気持ちだけで始まるんですけれども、徐々に実績が積み上がってきて、
ちゃんとお客様のためになっていることが分かったりとか、自分たちの知識がどんどん増えて、
実際にお客様のより難しい設計とかがお役に立てるようになったりとかしてくると、
やっぱり本当に業界にインパクトを出しているんだなというのは感じられて、
特に最近は私たち受発中という金属加工品を作るというところで事業が始まったんですけれども、
その裏では私たちソフトウェアを使って、今までは考えられなかったような効率化だったりとか、
15:00
考えられなかったバリューを出していくというところに挑戦しておりまして、
今までずっとこの2年間ほど社内でそういう技術を使っていたんですけれども、
ぼちぼちそれを社外にも展開できるんじゃないかなというぐらい事業が成長してきたと思っておりまして、
そういう観点でここまで頑張って蓄積してきた知財とかが今後生きるんじゃないかなというのも、
ソフトエンジニアとしてすごく楽しみにしております。
アップルのエンジニアというポジションを実際に手放して、新しい業界課題にチャレンジしていく姿勢はかっこいいですね。
話は小橋さんのCTOとしての仕事内容に変わります。
CTOの仕事って幅が広すぎて、何をやっているかわからないというのって結構みんな思うときがあると思っていて、
今の小橋さんがおっしゃっていたのは、まさにCTOの仕事だと個人的には思いますし、
あえて聞いてみたいのは、他に何かCTOを小橋さんとしてどのようなことをされているんですか。
そうですね。CTOのTが果たしてテクノロジーなのか。
テレフォンもやりますし、突貫工事もやりますし、創業時はトイレ掃除もやっていたので、
CTOとは何かちょっとわからなくなってきているんですけど、いくつかあると思っていて、
私はリーダーシップ的なスタンスとしても、背中を見せて、自分ができないことは人に言っても説得感があまりないだろうなと思っているタイプなので、
誰かにやれって言うなら、自分でまずできないといけないと思っていると。
会社のフェーズが変わっていくと、やっぱりマインドセットを変えていかないといけないことももちろんあるわけですね。
本当にゼロからゼロイチをやっていて、もう何でもありみたいなフェーズから、さすがにぼちぼちちょっと安定させようみたいな。
グロースのフェーズに入ってきたら、どちらかというと少し守りが増えてきたりとかすると思うんですけど、
こういうところのフェーズの変化ということをなるべく検知して、それが開発組織に浸透するということは割と大切にしております。
これやっぱり文化とか考え方って言うのは楽ですけど、
腑に落ちたりとか日々の業務とか会話に現れるまで何ヶ月もかかってくると思うので、
やっぱり常に常に発信していくことが多分重要だと思っていて、
そのためには私としてもどういう文化みたいなものを醸成したいのかということを把握しておかないといけないと思っていて、
それを把握するためには今事業がどこに進んでいるか、その事業の最先端を定期的に体験しておかないといけないと思っているので、
実際私、キャリーの18地の中でお客さんのところに行くことも多いですし、パートナーさんのところに行ったりとか、
つい先週とかも九州まで行って、パートナーさんのところとかお客さんのところとか、
実際生の声を聞いて、それで開発組織にどういうふうに反映していかないといけないんだろうかとかを考えたりして動いています。
18:04
なのでGTOというのは経営観点でどういうふうな組織を作っていかないといけないのか、
中期的に長期的にどういう投資をしていかないといけないのか、これは人への投資もそうですし、技術の投資もそうだと思うんですけど、
そういうところを常に考えて動いているという、基本的に多分数ヶ月は最低先を考えていることが一番いいんだろうなと思いつつ、
やっぱり気合と根性でやらないといけないことも多くて、特幹工事をよくやっています。
今のお話しいただいたところで、2点聞きたいポイントがあります。
1点目としては、今例えば小橋さんがわざわざというか、GTOとしてというか、九州まで行かれてお客様の話を聞くというところで、
実際にエンジニアがお客様のところに行くところって小橋さん以外の方も結構あったりするんですか。
はい、私たちものづくり体験みたいな形で、実際のエンジニアの方々、ソフトウェアのエンジニアの方々に物理の金属加工を体験していただく、
これはエンジニア限らず全社なんですけど、提供していたりするんですけど、正直ここ1年半ぐらい、コロナの関係でやっぱりちょっと外出が難しかったりとかリスクがあるので、
それを最大限抑えるという意味では、どうしてもやりたいほど外に出られていないというところは正直あるんですけど、
基本的にお客さんの声をなるべく生に近い声を聞くだったりとか、できるような状況を作ろうとしておりまして、
実際に外に行けなかったとしてもビデオ会議で入ったりとか、あるいは商談の録音というか録画をしてそれを見れるような状況を作ったりとか、
いろんなことを工夫はしておりまして、とはいえやっぱりお客さん生の声と、
あとそれを社内の用語に翻訳するといいますか、弊社の営業担当がそれをまたまとめて発信するみたいな形で、
私たちの開発組織の定例のミーティングとかで営業の方々とかにお客さんの話をしてもらったりとかをしたりしております。
割とできる範囲でなるべく解像度高くステークホルダーの方々のことを知るような仕組み作りというところは挑戦しております。
今録画、お客様との会話風景を録画してとか話を聞いてみるとかっていうのは結構、録画してる限りだとなかなかない取り組みですね、エンジニアが実際に聞くっていうのは。
はい、そうですね。でも割とお客様もそういうイベントとかに出てきてくださいますし、
全社への登壇というのもお客様がやってくださることもあったりするので。
さっき2つ質問があるって言ったところで、CTOとしての働きのところの質問、2つ目の質問にちょっと行きたいと思うんですけど、
2つ目はお話しいただいた中で発信し続けるからしかない、行動にあられない時間がかかるからっていう部分があったと思っていて、
21:06
あれって一種の企業文化というか行動指針、バリューみたいなものを社員が身につけるというか、
エンジニアたちが実際に体得するというか習得して行動するっていう部分につながると思っていて、
もうお聞きしたいポイントはピンポイントで、その発信し続けて具体的にHowはどんな感じでやられているんですか?
いくつかあるんですけれども、基本的にHowとしてどういうふうに発信していますかっていうことに関しては、
本当にコートで話す、ワノワンとかで話す、スラックで書くとか、あらゆる場面で表現の仕方として、
最終的には理解して納得してもらうことが一番重要なので、ただしつこく言うだけではあんまり意味がないというか、
行動に最終的に反映されるかっていうことが目的だと思うので、そういう意味ではいろんな表現の仕方を変えたりとか、
例えば、今は開発自体にフォーカスしてほしいフェーズがあったり、
あるいはもっとお客さんのことを考えてほしいフェーズとか、もうちょっと抽象度を上げて考えてほしいフェーズがあったりとかすると思うんですけど、
突然、今日からより抽象高く考えましょうって言い続けても、多分行動につながりにくいと思うんで、
そういう意味で、もう少し具体のところから神話性があるようなところにフォーカスして発信はしていますね。
なので、そういう意味でみんながどういうふうに動いているのかというのをなるべく把握するようにして、
それに対して適切な発信をしているというところであります。
発信内容自体としては、もちろん行動規範というか、私たちのエンジニア組織はこのように回したいですというところは、
もちろん言ってあります。ただ、そこまで私は正直マイクロマネージしていないしできないですというか、
人数も人数なので、どちらかというとここは、
よりリーダーシップ的な立場の方々に任せてお願いしているところではあります。
じゃあ、行動規範ってどんなものがあるんですかという話に関して、
めちゃくちゃ文章に落ちているわけではないし、どちらかというと空気で感じるというか、
みんな周りがやっているから自分もやるというのが一番浸透していて、
良い状態なのかなと思っているんですけど、
なんか聖書みたいな絶対これをやるべきみたいなルールがあるわけではなくて、
より輪郭みたいな、だいたいみんなこういうふうに行動するのがいいよねみたいな空気感があることがいいのかなと思っていて、
それを各プロジェクトで作ってもらっています。
各プロジェクトによってやっぱり質が違うので、働き方とか品質の考え方とか違うと思うので、
それは割と各々がお互いを尊重するような形で担保できればいいなと思っております。
24:02
一種のプロジェクト単位でのワーキングアグリメントみたいなのがあるってことですかね。
はい、まさに。
すごいですね、結構エンジニアチームとプロジェクトとしての自立性をかなり優先しているというか、
トップダウンでやれっていう感じには、1時間以上話を聞いていて全く受けないのが面白いなっていうポイントですね。
そうですね、割と民主主義っぽいところはあるんですけど、
同時に民主主義だからこそ困るところもあって、そこはちょっと、
私もまだこれから工夫の余地があるのかなと思うんですけど、
何らかの事情で早く動きたいときに、
そういう割とみんなが自立的に動ける環境の中で、
もしゴリッと急に動かさないといけなかったらどういうふうに動かすのかとか、
そもそもそういう速度で動くべきなのかとかは、
まだまだ組織論的にも考えていかないといけないところなのかなと思っていますね。
めちゃめちゃそれで共感というか理解するところがあって、
民主主義に寄せようとするというか、
必然的に全ての人になるべく意見を聞こうっていうふうに思ったりするので、
意見を聞いて擦り合わせをしている間に、
例えば1週間経っちゃいましたみたいな時もなくはなくてですね、
どの意思決定が今のフェーズにおいて最適なんだろうっていうのは、
結構難しいところではありますね。
そうですね、本当に難しくて、私もためらうんですよね。
やっぱり本当に僕がどうしてもやらなきゃいけなかったらやるんですけど、
それ私がやりすぎると空気が変わるというか、
民主主義っぽい自分たちが自分ごとできている空気感が崩れ始めるので、
どうせ後でひっくり返されるんでしょ、もういいじゃんみたいな感じになり得ると思うので、
CTO権限でひっくり返しますみたいなことは、
すごく慎重にやらないといけないなと思っていて、
もう多分本当に年1回ぐらいしか切り札がないと思って、
私は慎重にやってます。
今回は小橋さんの経歴やキャディにおけるCTOの仕事について伺いました。
CTOの仕事では、エンジニアの組織作り、情報発信の具体的なプラクティスなど、
各社の参考になるトピックが多かったのではないでしょうか。
次回も引き続き、キャディ株式会社TTOの小橋明文さんにお話を伺います。
この番組はPodcast Production Pitopaのオリジナルコンテンツです。
番組の感想、リクエストは概要欄のリンクよりお待ちしています。
それではまた次回お会いしましょう。
