00:01
日本最大級のエンジニアコミュニティ、Qiita プロダクトマネージャーの清野俊文です。
この番組では、日本で活躍するエンジニアをゲストに迎え、キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに役立つヒントを発信していきます。
今回のテーマは、エンジニア組織作りと技術戦略になります。
そうですね。今回も組織作りと技術戦略について、僕自身も関わっているところがあるので、いろいろお話しできたらなと思っています。
ゲストには前回に続いて、株式会社レクター代表取締役で一般社団法人日本CTO協会理事の広木大地さんにお越しいただきます。
今回もですね、いろいろお話ししていければなと思っています。
では本日のゲストをご紹介します。レクター代表取締役でCTO協会理事の広木大地さんです。
広木です。よろしくお願いします。
よろしくお願いします。前回は広木さんとエンジニアとマネージャーのキャリアについてお話ししました。
今回はエンジニア組織作りと技術戦略についてお話ししていきます。
ということで、今回エンジニア組織作りと技術戦略についてお話ししていければなと思うんですが、最初に僕自身も読ませていただいたんですが、
エンジニアリング組織論への招待というところ出版されていて、技術賞大賞とブックログでビジネス賞大賞を受賞されていると思います。
でもまさに僕自身も読んでいる中で、本当にエンジニアリングというところとビジネスが密接にかかっているんだなというのは、
すごい勉強させていただいたんですけど、ここの技術とビジネスの距離みたいなところが最近より縮まっているというか、
ここら辺の雰囲気、世の中全体での雰囲気みたいなところがどうなっているのかなみたいなところを、今回本を書いていらっしゃるひろきさんにお伺いしてみたいなと思っているんですが、いかがでしょうか。
ひろきさん はい。僕自身の考えとしては、そもそもエンジニアリング、コンピューターに仕事をさせるという行為と、
人間に仕事をしてもらうという行為の境目がどんどんなくなっていくと思っているんですね。
経営学とか組織学を考えたときに、どうしても過去の人間が働くということをベースに考えて設計されているものがあって、そうではなくて一部がコンピューターに置き換わり、
今まさにチャットGPTもそうですし、ああいった大規模言語モデルを使ったアプリケーションとかどんどん出ていく中で、
より多くの領域が人間ではなくてコンピューターによって代替されて、コンピューターと共存しながら仕事をしていくという領域が増えていくと考えています。
そうなったときに組織の構造やビジネスの構造とソフトウェアが持つべき構造というのが似通ってしまうといういわゆるコンウェイの法則というのは、
より強固に世の中に意味を持って追われていくだろうと思っていて、エンジニアリング組織論への招待というのはエンジニアの組織にターゲットした話だけではなくて、
03:07
エンジニアリングソフトウェアを作っていって、それを事業に活かしていくということそのものと向き合っていったときに、新しい経営学の形、組織学の形というのが見えてくるはずで、
だからこの2つがあまり絡まりあってはいないというタイミングに入り口としての本を書こうというところで、
私はエンジニアリング組織論への招待というタイトルをつけて、それがまさにビジネス書として読まれたとか、あるいは技術書として読まれたというのは、
僕にとっては我が意を得たりというか、よかったなと思っているところではあって、よりどんどんこういうふうにコンピューター、シリコンがというか、
CPU、半導体が仕事をしていく領域というのがどんどん増えていく中で、そこに携わる行為そのものが実はエンジニアリングで、
昔これ例で出すのは、昔エジプトの書記官という職業があって、これは文字を書くという能力だったんだけど、この人たちはすごい高級取りで、
あまり重宝されていて成り手も多かったみたいな話があって、それと今のコンピューターの話に似てるなと思ってるんですね。
ソフトウェアを文字というのを扱える人というのは少なくて希少だった時代というのがどんどんきっと変わっていって、文字を当たり前のものとして扱うようになって、
今文字書けない人が仕事を取るって大変な時代だと思うんですけど、それと同じようにソフトウェアに触れ合ってソフトウェアを何かに生かしていくということは、
より広い範囲に社会にとって必要なものになってくると思っています。それが今のプログラミング言語と同じものかどうかはそれこそわからないけれども、
当たり前のように人間に対して支持するの代わりにコンピューターに対して支持するということが社会に広がっていくと考えていて、
その中で今現在のステージで存在しているソフトウェアエンジニアリングの話というのをまとめて総括して書けたらなというのがこの本のコアコンセプトだったというところがあるので、
何かそういうところが伝わればいいなと思っています。
なるほどありがとうございます。まさにお話聞いていて感じたんですけど、いわゆる本当にソフトウェアって一つのツールではなくなってきているなというか、
もうそれそのものが経営というか組織のもう一つの一部になっているとか、それがもう何だったら組織自体を表している業務自体を表しているみたいなところもこうなってきているなというのは、
僕自身も日々仕事している中でも感じるので、それだけ今エンジニアリングみたいなところの役割とか、
こう責務みたいなところがある意味で広がってきているというところが今回このひろきさんの本が注目されているところの理由にもつながっているのかもなというお話を聞いていて今感じました。
06:02
続いてという感じになるんですが、まさに今ソフトウェアっていうところの役割とかが大きくなっていて、
それをベースにしたやっぱり組織作りとかそういうところも必要になっていくというところは本の中にも書いてらっしゃると思うんですけど、
組織構築みたいなところをそもそも現代のいわゆる企業とか組織としてソフトウェアを使っている組織としてどういう形にしていくべきなのかとか、
どういうふうにデザインをしていくのかみたいなところをもしアイデアがあったらお伺いしてみたいです。
まず1個目のステージとして、ソフトウェアを活用していくときの捉え方として、
昔ってソフトウェアでできることが少なかったので、ハードウェアを少し柔らかくいろいろ使いやすくしようっていうものとして制御できるものとしてソフトウェアって用意されてきた。
まさに僕が前回に組み込みの話をやったときは、組み込みでOSに近いものから単なる信号としてやってくるデジタルな信号を音声コーデックにするところとかってやってた時代に比べて、
今アプリケーションを開発しようと思ったら、とても簡単に音声は音声として扱って文字起こしもできてとか、そういうことができるようになってきている中で、
ソフトウェアで扱う領域っていうのが、実はハードウェアを柔らかくするっていう発想からウェットウェアと言われる人間の脳みその中にある様々なノウハウをちょっと固くしてソフトウェアにするっていう、
そういった構造に変わってきてるんだと思うんですね。
なので、我々が企業活動の中でノウハウとして持っているものをクリスタル化するというか凝縮していって結晶にしていくと、それがソフトウェアと呼ばれるものになりますと。
そういった発想で組織に向き合っていくと、マニュアルを書いてそれを例えばフランチャイズの人たちにやってもらおうみたいな営みとかなり近いような営みにソフトウェアを作る行為は近づいていくんだと思うんですね。
そういったウェットウェアを固くしてソフトウェアにしていくっていう行為って、企業活動の知的な営みの中心にあるわけじゃないですか。
にも関わらず外のベンダーさんとか外の人たちにそれを頼らなきゃいけないっていうのって、マクドナルドがマニュアル作りを外注化しますかっていう話と同じできっとしないでしょうと。
まずならそれが自分たちのコアなノウハウになっていくもので、それを外部に任せて、当然製本するとか外注化するかもしれないけど、テキストの中身っていうのはとかあるいは業務の指示書をどういうふうに作っていくかっていうのはきっと自分たちで作るでしょうと。
そういったものからコアじゃなくてハードウェアをちょっと柔らかくしているものとか業務の一部を設備として効率化しているものっていう捉え方を全部日本企業はしてしまった結果、なかなか自分たちのノウハウを凝縮するものとしてのソフトウェアっていう認知が広まっていなくて。
09:15
まずはここのマインドチェンジっていうところから日本社会が変わっていかないとソフトウェアエンジニアリングとの向き合い方っていうのがアップデートされないなと思っていて、そういったところが一番大事なポイントかなと思ってます。
いわゆる外注っていうところだと、やっぱりプロダクトマネジメントみたいなところの話にも通じてくるかなと思うんですけど、やっぱりそのものづくりって本当にただ依頼されたものを作るだけではなくて、日々の業務の中を観察して、その中からいわゆるドメインみたいなところを見つけていって、それを形にしていくみたいなところ全てがエンジニアリングだと思うので、
まさにやっぱり組織の中でそれができるようになっていかないと、まずその次のステップというか、より強い組織っていうところを作っていく中では結構大変なのかなっていうのは今お話聞いてて感じました。
ちなみになんですけど、そういう状態を作っていかないといけないよねっていうのはありつつ、まず何から始めていこうかっていうのを結構悩んでらっしゃる方もいらっしゃるんじゃないかなと思っていて、そもそもエンジニアがゼロの状態からどうやって採用していこうとか例えば、そういうところって最初どういうことから始めていくと良さそうかみたいなところって何かあったりしますか。
そうですね。本当にゼロだった時って、本当に内製化をしたりとか、その事業に使えるようになるかっていうところの当たりもつかないっていう状態になっちゃうと思うんですよね。何ができて何ができないか。
こういうのをエンタープライズの人たちとかとコミュニケーションしてる時に、コンピューターで何ができるかっていうのは大体分かってるんだよっていう人っていうのは結構多いんですよ。だけど僕らしたらそんなに分かってないんじゃないかなって思ったりするんですね。それはどういうギャップがあるかっていうと、
エンジニアの現場で働いてる人は、そのライブラリーとか触った時に何がどれぐらい簡単になったかっていうダウンサイズされてる度合いが分かるんですよ。そうじゃなくて、現場の知識になかなか距離が遠くなってくる。
これ僕もエンジニアじゃなくて、こういったアドバイザリーのことをしてるとずっと注意しながらキャッチアップしてるところではあるんですけど、肌触り、触ってみた感触っていうものを知らないと、それが本当の問題は何を解決したのかっていうところが分からないまま、よしよしの話をしてしまうところがあって。
実は、例えばリアクトって古いけど、リアクトが出てきた時のことを考えてみると、言葉の上ではJavaScript、MVCってその当時に似たようなものがあったんだけど、それとできそうな機能って一緒っちゃ一緒で、技術的な詳細に入り込んでいかないと差別化って難しい要素があったんですね。
12:04
それをなんとなく早いらしいよっていうことで突破したところもあると思うんですけど、本当にパフォーマンス必要かっていうと、そうじゃない場面もあった中でも突破してきたのは、そこに使っていったら今まで以上に楽にアプリケーション構築ができて、リッチなアプリケーションって作れるじゃんっていう簡単になったなっていう感触があったからこそ、あれだけ多くの人が飛びついて、それがエコノミクスとして成り立っていったっていう背景があると思うんですね。
そこって実は触ってないとリッチなアプリケーションを作るためのフレームワークって固めてしまうと同じものなんですよ。
これがクラウドとかで利用できる何かも一緒で、今までもやろうと思えばできたけれども、あるところまで民主化されてきてなかったっていうものが、それがこれ簡単になったぞと。
ここから先はいろいろできるようになるぞっていうこの感触っていうのをキャッチアップしないと、今までの当たり前水準が変わってしまうんですね。
今までの作り方で作ると、やっぱり大きなコストがかかって大変だったねっていう話になるから、我々はビジネスの課題と技術の一個一個の詳細な手触り肌触りっていうものを両方両立させた上で判断ができるっていうような力を手に入れないと、やっぱり手の内にできないなと思っていて。
この感触が今宿ってる箇所っていうのが、そういうベンチャーであったりとか、そういうところに集中してしまってるために、今ならこれが簡単にできるが、どんどんわからなくなってきてしまっているって、ここが問題なんだと思ってます。
なるほど。いわゆる経営っていう文脈で言うと、それをまさに経営者とかがそういうリテラシーとかを持ったりとか知識を身につけていく必要があるのかなってお話聞いてて感じたんですけど、実際そこをどう身につけていってもらうかみたいな、結構今話聞いてて、それはそれで難しそうだなっていうのは感じて。
そういうのって段階で言うと、まず無知であることに気づいてないっていう状態から、無知であることに気づく、それを習得するっていう段階がある気がするんですけど、今のお話だと無知であることに気づいてないから始まってる気がしてて、そういうところに対して、ひろきさん社外CTOみたいな形でいろんな会社さんとかにも携わってたりはすると思うんですけど、そういうところでどういうコミュニケーションを取ったりとか、どういうアクションを取っているのかみたいなところもお伺いしてもいいですか。
旗から見ると、ステロタイプとして経営者の人、おじいちゃんで優秀じゃなくて、なんか新しいことキャッチアップしてない人みたいな感じが出てくると思うんですけど、実は意外とそんなことはないっていうところはあって、特に創業経営者の方がリスクを感じて、社会が変わろうとしているから自分たちはこのままじゃいけないんだよということを認識して、誰かに権限を委ねて任せていこうという意識っていうのは、
15:08
より強い方の方が多いかなと。逆にサラリーマン社長的に内部から上がってきてたと、なかなかそういう意識って持ちづらいなとか。実は真鱈模様で、一概にステロタイプ化してみるものではないなというのがまず一点ありますと。
で、その中で経営自体が上昇気流に乗ってるところは、もう上昇気流に乗ってるんで予算もあるし、新しいこといろいろ試してアップデートしていけばいいやっていうところではあると思うし、なかなか立ち行かなくなってきたぞ、難しくなってきたぞっていうところはどうやって変革していこうかっていうことを外部の力に頼らざるを得ない部分もあるだろうし、いろいろ考えていかなきゃいけないこともあるんだろうなと。
で、そこは見極めというか、全部の会社が同じシチュエーションではないなというのが正直なところとしてはあって、だから全ての会社がそういったDXのために内政化すべきだっていう極論を持っているわけではなくて、むしろ自分たちが10年後のビジネスをやっていく上に、今の共則環境だとして10年後、我々っていうのは何か窮地に立たせられるのかっていう問いに対して、
いや、そんなことはないって堂々と今までの事業をやっていくっていう方であれば、別にデジタル化する必要もないし、ソフトウェアを内部化する必要もないと思ってるんですね。
だけど、共則環境が変わったときに別のものに乗っていかないとディスラップされてしまうよっていうことに対して、危機感を持ってるんであればアクションは早いほうがいいし、そのためには今の当たり前っていうのを受け入れていかなきゃいけないしっていう、そういうステップなんだと思います。
なんで、その中で一番厄介なのは、今ぐらいの感じだったら、あと数年ぐらいは今ぐらいの感じでいけるだろうから、そこまで熱心に変革しなくてもいいかなっていう中だるみの時期みたいなものが一番経営としては大変な部分かなと思っていて、
その時期を意思したことで経営変革のスピードっていうのを上げなきゃいけなくなるっていうのが僕が感じている一番のリスクかなと思っていて、それこそミクシーに関しても危ないなと思ってから変革するまでのほんの数年のタイムラグが結構大きな決断を必要とするような事態を招いたなとか、
そういうのがあって、やっぱりスピード感が早い業界だと、よりそのスピード感に対して早く対応していかなきゃいけないし、逆にそれがゆっくりでも全然平気だよっていう業界はちゃんと地に足つけながらやっていくとか、そういうことをしても全然いいかなと。
むしろ自分たちはどうだっていうスタンスを決めれずに、時間が経つのを様子見ようということが一番良くないのかなというふうには思ってますね。
18:12
なるほど。じゃあなんとなく課題は感じているけど動き出せない状態ってところがまず一番課題というか、まずは見えている状態になっているんだったらまず動いていくってところが重要みたいなところなんですかね。
グリーンにかけない転職ウロ話ラジオ、略してグリテンラジオは、転職アプリグリーンの運営メンバーが個人的一押し企業について語ったり、現場で感じる転職や中途採用のリアルについて話す音声番組です。
毎週月曜朝6時更新です。通勤や休憩時間のお供にぜひお聞きください。
詳細はカタカナでグリテンラジオと検索してチェックしてください。
And now, a short commercial break.
逆になんですけど、今、どちらかというと経営目線でのお話いろいろあったと思うんですけど、逆にエンジニアとして、今ソフトウェアとかの役割が大きくなっていくみたいなお話ずっとあったと思うんですけど、
その中でそのエンジニアリングにずっと携わり続けている、いわゆるソフトウェアエンジニアの人たちが、どういうマインドセットを持っているべきかとか、どういう動きをしていったほうがいいのかみたいなところも、もし何かあればお伺いしてみたいです。
そうですね、どういうマインドセットを持っているべきかみたいなべき論に関して言うと、別にどんなマインドセットを持っていてもいいんじゃないっていうふうには思っていて、それは多分何らかの目的によると思うんですね。
それは多くの場合は評価されたいとか、市場で生き残れればいいとか、あるいはその給料が上がったらいいとかっていう話になってくると思っていますと。
給料が上がったらいいの話をする場合に、やっぱり一番大事なのは需要と供給のギャップを作ることで。
需要と供給のギャップを作るためには、今流行っているからといって、流行っていることだけできたらいいのかっていうと、そうじゃないっていう。
つまりその供給が追いついてしまうから、そうしたらそれを追いかけ続けないと、その需要のアービトライザーが生まれないっていうことになってしまって、追い立てられるように勉強し続けなきゃいけない人生になってしまうと。
それぞれで幸せなんですかっていうふうになると思ってて。
そうなったときに、自分の中で楽しんで学び、そしてその中でユニークになっていくことを恐れないっていうことが一番大事なのかなと思っていて。
僕の場合、たまたまスペシャリストとしてのエンジニアをやりながら、組織の経営改革であったりとか、事業の改革であったりとか、あるいは新規事業にたくさん触れ合うとか、そういうことをしていく経験があって、ちょっとレアな人間になりましたと。
それに関して技術と経営の本を書くことも含めて、ちょっとレアなことをしましたと。
21:03
それがレアリティになって、市場であったりとか、そういう話を聞かせてくださいという話になってきたりする。
それが商売であったりとか、仕事につながったりする。
これは本当に再現性のない単なる生存者バイアスの話かなと思っていて。
それは僕がたまたま大学時代の話を前回したみたいに、いろんなことに興味があって、たくさんのことを技術の枠にとらわれずコミュニティをやってみたりとか、そういうことをしていた結果、そういうことがなんとなくできるようになったりとか、なんとなくそういう知識を得られるようになったっていう話なんだと思うんですね。
なので、そこにべき論を持ってくるところは全然、ナンセンスな部分出てくるかなと思っていて。
むしろ、自分自身の役割を否定してしまうっていうことっていうのは、そのレアリティを獲得するためのチャンスを棒に振ってしまうんじゃないかなと思っていて。
例えば、自分はフロントエンドエンジニアですっていうふうな自己認識を持つって、ウェブ例明記にはあんまりなくて、特にフロントエンドって領域がはっきりしてなかったから余計だと思うんですけど、バックエンドのエンジニアもフロントエンドのエンジニアも一緒で、データベースも設計しなきゃいけないし、運用しなきゃいけないし、インフラを作るために場合によってはデータセンターに行ってセットアップしなきゃいけないしっていうのは、昔はそうだっただけ。
それはそこに区別はつかなかった。だけど今は分業化してった方が効率がいいから、分業するっていうのは単に世の中がそれを求めているというデマンドサイドの話なんですね。
サプライサイドとしてはどう対策するかというと、デマンドサイドの要求に対してそのままその潮流に乗るということが一番最適なんですかというと、そうではないっていうのが単純に経済の関係だと思っています。
なので自分のことをフロントエンドエンジニアだと規定して、何年間かそれのスペシャリティを得ようと思うこと自体は何ら問題はないんだけれども、どう考えたってフロントエンドもバックエンドもかける人が一人で採用できるなら、その人のほうが欲しいってなる場合っていうのはありますと。
一方で大企業の場合、フロントエンドならフロントエンドのことだけやってくれる人がピタッとはまるほうがコスパは良くなるかもしれないっていう領域がありますと。
その中で自分自身のキャリアを作っていくんだっていう感覚があったときに、あんまりそういった企業サイド、デマンド側が要求しているスキルセットの定義みたいなものとかキャリアの枠にはまろうはまろうとすればするほど、ありふれた人間になりませんかっていうところはあって。
24:00
それを必死にキャッチアップしようとするのって、果てのない競争の中にいきなり追いやられてる感じはあって、それはそれでつらいのかなと思っていて。むしろ、ある特定の領域にめちゃめちゃ詳しい、それが技術だけではなくて。
例えば、お花にすごい詳しいっていうのがあったとするじゃないですか。で、花って花屋さんのドメインにすごい詳しかったときに、花屋さんベンチャーを作ろうと思ったときには、なんかめちゃくちゃこの人引きがあるな、だって花にめっちゃ詳しいもん。しかもそれ技術で問題解決してきた実績もあるんでしょ。
じゃあこの人入ってくれたら、花屋ベンチャーをよくできるかもしれないってなるわけじゃないですか。で、これってレアリティの作り方の一個だと思っていて。なので、こういった社会の中でどうあるべきかっていう話のべき論で言うと、
そういう需要と供給の関係でギャップが出やすいところに行けばお金はもう得られる、儲かりますっていう話になると思うんですけど。それの得方っていうのはいろいろあるし、逆に得たら得たで大変なところっていうのはいくつかあって、
フロントエンドエンジニアですって言った状態で、フロントエンドエンジニア軍団に囲まれてフロントエンドエンジニアやってると、言葉が通じやすくて楽なんですよ。NPMがさって言えばNPMのコツだなってわかるわけ。略語を使ったって何のことかわかるわけ。その状態でコミュニケーションすると楽なんですよ。常識が近いから。
一方で、それとお花屋さんと触れ合ってコミュニケーションしようとしたら、常識の距離が遠いんですよね。常識の距離が遠い分、コミュニケーションが大変になるんですよ。この大変な分、アービトラジも生まれるんですよ。その分、お金になるかもしれないし、ならないかもしれないですね。
フロントエンドエンジニアとして極めていったら、極めていくというレースの中で勝者になれば結構良くなりますと。じゃあ100メートル層っていうジャンルに出場して出るのか、層じゃなくて多形層の5種みたいなところに出るのかみたいな話で競争環境って違ってくるわけじゃないですか。
そういうのを考えるのが、本当はキャリアを考えるとかそういうことなんだと思うんですけど、そこを戦略的にやろうやろうとやれば、思えば思うほど、すごい既存の競争レースに乗っていく話になっていて、それって受験戦争的なやつとあんまり変わらないっちゃ変わらなくて、それ本当に面白いですかみたいな。
そうじゃないから、僕の感覚だとね。僕が当初そうだったのは、ウェブとかITとかインターネットってあんまりおしゃれな業界じゃなかったわけですよ。すごいねっていう感じの就職先でもないわけですよ。なんだけど、面白いからやってたんですよね。
27:13
競争環境激しい。だから今本当にITなのかみたいな話もあると思ってて、別にそれだったらグリーンテックっぽいところに飛び込んでもいいかもしれないし、機械学習を利用したアプリケーションを作ろうっていうところだったら、そっちにキャリアを移してもいいかもしれないし、
そういう自分の中で確実に楽しんでことに臨めるような場所っていうのが一体何なのかって見つけていくことの方が重要かなと思ってて、またキャリアの話になっちゃったけど。
いわゆるトップを目指すのか、いわゆるオンリーワンを目指すというか、リアリティを高めていくかみたいな話は、なるほどなっていうお話聞いてて僕もすごい感じたので、なんか僕自身も結構やっぱり正直言うとエンジニアでありながら今マネジメントとかいわゆるプロダクトマネジメントとかのほうがメインになってきたりするので、
だからそれがエンジニアとしての価値どうなんだろうなみたいな思うことあったんですけど、なんか今のお話聞いてすごい吹っ切れました。
いや、相当今日のレアな人ですよ。
ありがとうございます。
ひろきさん、今回もありがとうございました。
まだまだお話足りないので次回もひろきさんとお送りします。
今回はひろきさんと経営だったりとかキャリアみたいなところについていろいろお話ししました。
僕自身もいろいろ発見があって、すごいためになる時間だったなと思ってます。
ありがとうございます。
ひろきさんとはですね、エンジニアとマネージャーのキャリアについてお話しした前回のエピソードもあるのでぜひお聞きください。
さて、この番組では感想や質問、リクエストなどお待ちしております。
番組詳細欄にあるリンクよりお気軽にご投稿ください。
Twitterではハッシュタグエンジニアストーリーをつけてツイートしてください。
そしてApple PodcastやSpotifyのPodcastではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
Kiita株式会社はエンジニアを最高に幸せにするというミッションのもと、
エンジニアに関する知識を記録・共有するためのサービスKiita、
エンジニアと企業のマッチングサービスKiitaJobs、
社内向け情報共有サービスKiitaチームを運営しています。
ぜひカタカナでKiitaと検索してチェックしてみてください。
お相手はKiitaプロダクトマネージャーの清野俊文でした。
