CTOの役割と挑戦
日本最大級のエンジニアコミュニティQiita プロダクト開発部部長の清野俊文です。
この番組では、日本で活躍するエンジニアをゲストへ迎え、
キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに役立つ話題を発信していきます。
前回に引き続き、ゲストは株式会社一休、執行役員CTOの伊藤直也さんです。よろしくお願いします。
よろしくお願いします。
はい、ということで2回目はですね、CTOとしてのお仕事についていろいろお伺いをしていきたいなと思っております。
前回もですね、軽く触れていただいたところはあるかなと思うんですが、もうちょっとですね、深掘りしてお伺いできるとありがたいです。
伊藤さんとお送りする2回目のテーマは、CTOは課題解決より理解が先、伊藤さんが語る本質的な仕事です。
最初にお伺いしたいのが、まずCTOとしてやってることってどういうことなのかなってところをお伺いしたいなと思っていて。
今ですか。
はい。
なんか一言で言うと難しいけど、なんかすごくざっくり言うと、経営人の中でテクノロジーに一番詳しい人じゃないですか。
はい。
それに関してその役割を担うというか、例えば会社で技術的な何というかその課題を解消しなきゃいけなかったら僕のところに当然降ってくるし、セキュリティの問題があったら僕のところに降ってくるし、みたいなそこの最初の入り口っていう感じですよ。
で、当然そのための手段としてその問題を解決するためには強い開発チームがあった方がいいに決まってるから、だから日々その開発チームを強くするためにいろんなこともやるし、場合によっては自分で開発をして新しいプロダクトの最初の部分を自分で作ることもあって、で採用もやるしなりもあるし。
ただまあ、講座の方で話したのは全て手段であって、一番重要なことはそのエンジニアというか技術的なバックグラウンドを持って経営に参画するっていうそこの部分っていう感じですかね。
ありがとうございます。
CTOとしてお仕事されている方にお伺いすると結構似たようなお話というかバックグラウンドとしてエンジニア技術者として経営に携わるっていうお話あるかなと思うんですけど、それのもうちょっと具体的なその価値というか意味みたいなところをお伺いしたいなと思っていて、
バックグラウンドにエンジニアとか技術者っていうものがあることでその経営に携わることのメリットというかそれによって何が会社としてできるようになるのかみたいなところをちょっとお伺いしたいなと思ったんですけど。
具体的にね。
でも例えばその1Qという会社はもともとどっちかというとエンジニアリングの会社では全然なくて営業の会社なんですよ。
最初のその創業者の森さんという方がもともと生命保険かなの会社の営業マンでそれで起業した会社なので営業が強い会社だったんですよ。
ただ最近はやっぱりその我々そのホテル予約とかっていうのはそのすごくデジタル化が進んでるんで、
プロダクトも頑張らなきゃいけない会社になったと。
そうするとだからざっくり言うと経営者としてはこれからもDXの時代だからだよ。
だからそのそれを頑張らなければならんと名古屋さんよろしくって言われたらはいわかりましたって言って仕事するみたいな。
いやこんな感じじゃないですよ。
でもそういうことであそっかじゃあデジタル頑張らなきゃいけないからもっとプロダクトうまく作れるようにならなきゃいけないなって言ってもっといい人採用しようとか
なんかコードが汚くて古いなって言ったら綺麗にしなきゃいけないとか新サービス立ち上げるぞって言ったらこれやるぞって言うし、
あとまぁ事業の人からこんなことやりたいんだけどって言ったらこれはこうやってこうやってこういう風にやればいいから
じゃあ作るよとかあのチーム当てるから頑張ってって言うとかなんかそういうこと全部やっていくっていう。
それがCTOとしての仕事かなっていう感じです。
なるほど。
じゃあもう本当にやっぱりこう知識を持ってこう会社としてやっていきたいということに対して技術的なこう側面からいろいろこう。
それに必要なことを全部やる。
はいもう全部やるんですか。
全部やります。
なるほど。
もちろん僕が全部やるわけじゃないですよ。
僕という人を入り口にとりあえず経営人からするとまあそれは直屋さんだよねって当然思ってるから経営の会議の中で
これはちょっと開発関係ありますねって話ができた分かりましたやっておきますみたいな感じでやっていくっていうそういう役割ざっくり言うと。
なるほどありがとうございます。
技術的理解と経営
ただもう少しその実務としてどういう作業をするかみたいな意外なことで言うと
CTOの存在というのは特にやっぱりその内製のエンジンを抱えている組織においてはそれなりの多分意味があって
まあ簡単に言うと僕の価値観がそのものがその組織に大きく反映されるんですよね。
例えばどんなプログラミング言語を一つ使うかある程度僕の判断というか趣味とかが反映されるわけですよ。
それは別に僕のエゴで選んでるわけじゃなくて最終的にその意思決定しなきゃいけないからそのタイミングで僕がどっちかっていうので決まるじゃないですか。
その時にだから僕も自分の中の価値観に照らし合わせて判断をするんで
それの蓄積で会社のやってることが決まっていくって考えるとそういう大きな影響を与えるポジションであるっていう感じです。
本当に組織全体の内側から見るとやっぱり組織全体の判断ってところをやっていく立場でありつつ
やっぱり会社全体ってところで見ると会社でやりたいことを技術面からいろいろ動いていくっていう。
今の役割みたいなところって今一休さんでそういう立ち回りされてると思うんですけど
はてなさんの頃から結構動きとしてベースは変わらない感じなんですかね。
ベースは変わらないんですけどそれこそ一緒に働いているその役員の組み合わせによっても多分ちょっと変わってくるなと思っていて
それこそはてなの近藤さん、近藤さん自身が当時はまだ開発してたんで
全部を全部僕がその役員の中で開発のボタンになるわけじゃなくてある程度手分けはできるわけですよね。
っていう状況と今の会社みたいに今の一休の社長坂木さんもある程度は書くんですけど
アプリケーションのコードを書くわけじゃなくてちょっと計算のモデル作ったりとかその程度なんで
そうすると今の一休ではもう開発に関することは基本直屋さんっていう感じになるんで
そこで全然話が違ってくるっていう感じですかね。
なるほど。じゃあ結構やっぱ会社ごとにCTOとして何ですかね立ち回りとしてというかそういうのは変わってくるんですか。
会社のサイズでも全然やること違うし、その役員の誰がどのぐらいのことできるかっていうのでも変わってくるし
全然同じになることはないとは思うんですよね。ただまあ本質的なことは一緒って感じはしますけど。
そうなんです。本当に結構その名古屋さんっていろんな会社さんでそういうCTO的な立ち回りされてらっしゃると思うんですけど
そこでこういろいろ立ち回りとかやっぱり会社によって違う中でどうそこにアジャストしていくんですか。
まあ多分それはねエンジニア的思考での人はそういう質問をやっぱするなっていうのが僕の印象で
まずプロセスが先にあってCTOとはこういう仕事をしなければならないっていうなんかその前段が多分なんかイメージがあって
それをどう組み立てればいろんな会社に適応できるかみたいなふうに多分考えているような印象があるんですよ。
でも実際そうじゃなくてそこに行く問題を理解する。理解できたじゃあこういうふうにアプローチしましょうねっていう結構トップダウン思考なんで
あんまりその事前に自分にこういうケイパビリティがあればああいう会社もこういう会社も対応できるとか自分のやり方はこうだって決めていくんじゃなくて
本当にその会社の問題をきちんと聞いて理解してそれに対して適切なアプローチを処方していくっていうただそれだけっていう感じ。
そしたらどっちかっていうと突破力というかとにかくその場で自分がこう何とかしていくみたいな
そっちの力の方が大事っていう感じですかね。
その時も解決力よりもやっぱり問題を理解する力の方が重要だと思うんですよ。
やっぱりこれは会社でもよく話すんですけどそれこそみんなに。
なんか人間やっぱり目の前に問題があるとすぐ解決したい気持ちになるじゃないですか。
例えばある社員Aさんが辞めたいって言ってきましたって言ったらみんなびっくりしてなんでなんでみたいなとりあえずワンワンしようみたいになるじゃないですか。
だけどまずその人が辞めたいって言った時にその人が辞めたら困るのかっていうことをまず考えなきゃいけないじゃないですか。
困るってみんなに聞くと困りますって言うんだけど本当にみたいな。
だってエンジニア100人ぐらいいるんだよみたいな。
一人辞めるかもしれないと。
もちろんその人が辞めることにネガティブな理由があってそれが会社に起因したものだったらそれを直さなきゃいけないみたいなこともあるかもしれないけど
そういうことも含めて全部ちゃんと理解してからどうするかって考えるべきじゃないですか。
だけどみんなは誰それさんが辞めたいって言ってますって言った瞬間すっごい慌ててその問題を解決したきゃならないって言って
飲みに行こうとかワンワンしようとかどうやったらその会社のその良くないところ直せるかとかわーわーわー考え始めて
すぐそっちに行っちゃうんですよ。
でもCTOっていうのは多分それじゃダメで
もうちょっとその引いた目で全体を見て
この会社が今開発がうまくいってないとか人がよく辞めているとか
あるいはなんか開発スピードが遅いっていうのがあったら
なんでそれが起こってるのかとか今どういうやり方をしていてみたいな全部を理解して
で全体が理解できたらあー多分あの辺が問題だなとかって言って
じゃあそこを直していくかっていうアプローチを取っていくみたいなそういう感じなんですよ。
なるほど。
じゃあなんかこう馬車馬のようにとにかくその場その場で何とかしていくというよりも
まずはこの全部知った上でどこが一番こう自分自分というか
まず最初に動いていくべきかってところをちゃんとついていくっていうような動きってことですか。
そうです。それはどこの会社に行っても変わらない。
評価と改善のプロセス
そうなんです。
仕事のアプローチとしては。
なるほど。
なんかこの型みたいなものを直屋さんがこう身につけたのってなんかどういうタイミングだったんですかね。
どういうタイミングだろうでもこればっかりはなんか徐々にそういう風になっていったっていう感じかな。
それこそ馬車馬のように目の前の問題を片付けているだけだと
1回目の話でサーバーが夜中によく落ちるようになったって話があるじゃないですか。
はい。
前の時にだからそれこそ最初は落ちたやつを直すみたいなやり方で言ってるんだけど
一向に良くならないみたいな感じだったんですよね。
それはだからその全体のシステムでどこがボトルネックなのか分かってなくて
だからその人間で言うと風邪ひいたら熱が出てるから下熱剤処方してるだけみたいな。
でも熱が出てるのは実際にはそのどこかがおかしいから熱が炎症起こしてるから熱が出るわけで
その炎症起こしている場所を探し当てることが重要じゃないですか。
だからそれをやってないわけですよ。
みたいなことを繰り返しているうちに
そもそもこのインフラをちゃんとするには日頃からメトリクスをきちんと取って
まず何が起こっているかを理解できない、直せないってことに気づくわけじゃないですか。
みたいなことを繰り返しているうちに
そもそも問題っていうのは理解する前に解くべきではないだっていう思考が鍛えられていくっていう感じですよね。
なるほど。解きたくはならないですか?
なります。でも今はならないかな。
そんなよくわかってない時に適当なアプローチで問題を解ったって解けるわけないっていう気持ちの方が先行するんで
それか理解できてないまま問題を解くことが気持ち悪すぎて
解きたいという気持ちに僕はもうならないっていう体になってしまったっていう感じかな。
なるほど。ありがとうございます。
結構CTOとしてお仕事されていると
ここが問題だなと思ってそこに対してアプローチをする。
そういう動きは実際やってはいくと思うんですけど
それが実際良くなったかどうかって目に見えてわかるよりも
じんわりわかってくるシーンの方が多いかなと思うんですけど
そこをどう評価していらっしゃるのかなっていうのもちょっと気になっていて
自分のいわゆる自己考慮感というか
これは上手くできたなとかこれはなんかわかんないなとか
結構いろいろあると思うんですけど
どっちかというとCTOとしての動きみたいな大きさまでなってくると
なんかわかんないシーンの方が増えるんじゃないかなって印象があって
そうですね。特に人間に関することは手を打ったからって言って
マネジメントの本質
翌日にいきなり良くなるってことは稀なんで
半年くらい経ったらあのチームすごい良くなってるなみたいなことに気が付くみたいな感じで
わかっていくので
そればっかりやっぱ経験ですかね
過去にこういう風に良くなかったチームが良くなっていく経過を見てたから
多分その時に似てるなとかそういうことに多分脳みその中で照らし合わせてるんじゃないですかね
あんまり意識してないですよ
そうなんですね
もう結構そのままそのままでこう何て言うんですかね
使ってきたものをベースにこれはこうすればうまくいくだろうってところを増やしていってるみたいな感じですかね
あるし究極何のためにマネジメントしてるかって話になると思うんですけど
別にそのみんなが笑顔でハッピーで働くためにマネジメントしてるわけじゃなくて
良いサービス良いプロダクトを作り出すためにマネジメントするんですよね
もっと言うと事業を伸ばすためなんですけど
だからチームをマネジメントして出来上がってきたプロダクトが
なんか以前はこんなに良い品質で作れなかったものが
このチームは作れるようになってるっていう時点で
上手くいってるっていう感じなんですよ僕からすると
なんかそこの感覚をすごく重視していますね
それは自分のキャリアにものすごく関係があって
僕はそのブログサービスの開発をやったり
ハテナブックマークのディレクターとかプロダクトマネジメントの開発を自分でやってたんで
なんかプロダクトが上手く開発できて
良いものが作れてる時の匂いというか雰囲気が
経験的によく分かるんですよ
そうなんですね
だからチームがきちんとやってることが噛み合って
このままいくと多分すごい良い機能ができると
ユーザーに流行るかどうかは別ですよ
でも少なくとも自分たちがこうであってほしいと思ったものが
そのイメージ通りものが生まれてくるみたいな時の
高揚感とかリズム感とか
ディスカッションが上手くメンバーとして噛み合っているかみたいな
経験的に僕ものすごくよく分かっていて
というか僕はその状態にならないと
ものが上手く作れないんで
それを目指してるっていう感じなんですよ
だからチームが出てきたアウトプットを見ると
これはすごくちゃんと作ってるなって分かると
あのチームが上手くできてると
以前はできてなかった
だからこのマネジメントは多分上手くいったみたいな
それが僕の中のベンチマークっていう感じですね
これちょっと特殊かもしれない
結構本当にアウトプットベースで
本当にそれぞれの
自分がやってきたこととか
チームの変化みたいなところをモニタリングしてるみたいな
そうです
そこを全然だから僕数字とかには頼らないんですよね
数字見てもよく分からないんで
なんか4keysとか見て
いやデプロイの数が増えてるからいいとか
っていうのは思ったことは一度もなくて
全く見てないですそういうの
そうなんですね
それよりも各チームのプロジェクトの進捗状況とか見て
これはいいやり方をしてるとか
これはなんか多分個々人が一人一人で仕事してて
多分チームとして機能してないとか
いうのを自分の感覚に照らし合わせて
見ていくっていう感じですかね
チームの判断と経験
なるほどありがとうございます
なんかそこってこうなんて言うんですかね
パターンとしてはある程度もう決まってるものなんですかね
それともなんかこう
こういう時はなんかこういう感じで
こうだと上手くいってるなみたいな感じですかね
うーんちょっと分からないですね
自分の頭の中ですごく抽象化されちゃってるんで
そうなんですね
直感的に分かるっていう感じ
なるほど
いやただそんなに特殊なことでもないんじゃないかな
例えばものづくりの話をするからちょっとわけ分かんなくなるんですけど
皆さんが例えばその学園祭の実行メンバーだとするじゃないですか
高校生ぐらいで
で5,6人でその学園祭実行委員を組んで
来年の学園祭に向けて準備をするぞと
でなんかその学園祭に向けて
なんかすごいいい企画がどんどん生まれていって
しかもそのメンバー同士でこう遠慮なく議論をして
妥協のないものが用意できていってるみたいなのは
多分感覚的に分かりますよね
だからその状態をちゃんと作れてるかどうかみたいなのを
ちゃんとその自分のなんていうかな
主観でいいので認識していくっていうか
なるほど
でなんか世の中の人たちを見ていると
そこの判断を自分ですることを怖がってる人が多いなって
僕なんか思っちゃうんですよね
だから自分の主観に照らせてこの人たちはうまくやってるかやってないか
っていうのをジャッジすることに
すごくみんなそれを自分がやっていいのかって恐れていて
だから客観的なデータを見ないとわからないとか言って
フォーキーズとかそういうメトリックスに頼るみたいな
感じの人が多いんですけど
いやなんか開発がうまくいってるかなって
デプロイの頻度とかじゃなくて
うまくいってるかどうかを見れば分かるよっていう
感覚なんですよね僕はすると
なんかすごいなるほどなーって思った一方
組織の規模が大きくなってきた場合って
全部見るのって結構難しいんじゃないかなって気はしていて
そこって直屋さんどうやってそのこう何ですかね
見ていっているんですかね
でも今僕言うて
エンジニアの人数が100人超えた組織は
僕逆に言うとマネージしたことがないので
今の1級でも80人ぐらいなんですよ
そのぐらいであればなんか見れるかなっていう感じ
そうなんですね
もちろん全部一人で見るわけじゃないですよ
そのミドルマネジメントの人たちと協力しながら
やっていくんですけど
そんなに難しいことじゃないかな
そうなんですね
なんかそこの感覚みたいの
今お話の中にあったミドルマネジメントというか
他のマネージャーとかに任せていくところもあるかなと思うんですけど
そこでのコミュニケーションは
どういうコミュニケーションを取ってたりするんですか
ミドルマネジメントの人たちとですか
はい
なんかそのこう
多分直屋さんが見ていきたい
でも今話してるみたいなことを
すごくよく話しますね
ミドルマネジメントのEMの人たちが
今EM3人と一緒にやってくれてる人事の人が1人いるんですけど
その4人と週に1回2週間に1回ミーティングして
そういうどういう考え方でやっていくかみたいなことは
すごくよく話しますね今みたいに
あそこのチームはオーナーシップが持ててないのは何でだろうねみたいな話をして
それこそ理解するためにどういうやり方でやってるかとか
ミーティングってどういう風に開催してるとか
なんかそもそも開発するときのタスクのアサインの仕方とか
どういう感じなのとかっていうのをみんなで話して
そのやり方だと多分うまくいかないねとか言って
じゃあこういうやり方に転換してみようとかっていうのを相談しながら
その過程で今みたいなその哲学っていうか
根本になる考え方みたいなのをみんなで揃えてやっていくっていうのを
繰り返してる感じですか
なるほど
それをみんなで話すんですか
そうですそうです
もう必ずみんなで集まってどういう状況かっていう話をして
ついさっきもそれやってましたよ
そうなんですね
そのアサインの仕方だとオーナーシップおかしくないからダメだよみたいな話をして
すごい勉強になりましたありがとうございます
僕が聞きたいことばっかり聞いちゃってるんですが
どうぞお好きなように
ありがとうございます
ちょっと話が変わっちゃうんですけど
名古屋さんその生成AIについてどう思ってるかなみたいなところ
どう思ってるか
どう思ってるかというかそうですね
いろいろ生成AIツールとかも出てきてたりするじゃないですか
やっぱり生産性を高める方法にももちろん使いますし
エンジニアとしての役割みたいなところを
逆に買い売るぐらいのパワーを持ちたいとすると思うんですけど
生成AI系のツールとかを今どうキャッチアップしてて
それをIQさんでもいいですし名古屋さんとしてでもいいんですけど
どういうふうに捉えてどうアクション取ってるのか聞きたいなと思って
とりあえずすごいなっていうまず普通に
業界全体巻き込んでいろいろ変わっていくだろうなっていうのは
当然そう俺は思いますよね
だけどこれでエンジニアの役割が変わるとか
自分の仕事の仕方をこういうふうに
ししとしなければならないみたいなことの判断を
むしろ逆に急がないようにしてます
そうなんですね
だけど一方で会社では触ってないと解像度が上がらないんで
判断してから触るんじゃなくて
とりあえず触ろうっていうことをやっているみたいな感じ
これは未来がよく分からないっていうことなんですよ
大きく言うとすごく多分大きくいろんなことが変わるんで
だから今現時点で未来予測したってその通りに必ずならないから
未来を予測してこうなるんじゃないかって言って
それに合わせるんじゃなくて
細かくなんて言うんですか
微分していって
ちっちゃくちっちゃく自分たちの動き方を
その場その場で適用していけば
おそらく正しい未来にフィットしていけるだろうっていう
考え方でやってるっていう感じです
だからなんかエンジニアがいらなくなるんじゃないかとか
エンジニアももっと要件的に時間を使うべきじゃないか
みたいなこととかを
みんなわわ言ってるけど
そうなるかもしれないしならないかもしれないと思って
冷静に判断するみたいな感じの心持ちでいますかね
お話の中で触るってお話はあったかなと思うんですけど
その触る度合いってどれぐらいのイメージですか
普通に例えば家で自分で何か作りたいときは
もう普通にクロードコードで全部作ったりとかもしますし
会社の障害治すときとかも
AI使って直したりとかするし
割と普通に使ってるっていう感じですかね
でも逆にその感じで使ってると
ああなんかエンジニアいらなくなるとかって
まだ起こんないなっていうのはよくわかるじゃないですか
そういう感じですかね
それをみんなでやっていくみたいな感じですね
そこはやっぱり僕が号令かけることが
やっぱり結構それなりに意味があって
やれって言うとみんなやってくれるんで
とりあえずやろうとか
あと君はじゃあちょっとAI縛りで
ちょっとプロトタイプでいいから作ってみてとか
あとそうやってやってもらったチームから
ちょっと1ヶ月やった結果どうっていうのを
話聞かせてもらったりとかして
そうやってこうなんていうんですか
盛り上げていくっていうか組織の自体を
やっぱり言うてみんな会社なんで
まあ役員がどういうことに興味を持っているか
みたいなことに対して
ある程度みんな関心があるじゃないですか
そこで僕がそうやって動いていれば
ああなんかAIやっていくつもりでいるんだなっていうのが
なんとなく雰囲気で伝わっていくんで
そういうことも含めてっていう感じですかね
ありがとうございます
結構今聞いたもん
そこら辺のこう動き方どうしようかなって
ちょっと悩んでたりをしたので
生成AIへのアプローチ
すごい参考になりました
そうです こういう局面こそやっぱり
テクノロジーのリーダーとしてどう動くかってのは
問われるかなって気はやっぱりすると思うんですよね
僕がそのAIに対するスタンスを
あんまりこうよく分からないまま
判断保留判断保留って言って
みんな使いたければ使っていいよみたいな
中途半端な感じでいると
みんなもこれは何使うべきなのか
使わないべきなのかみたいな
よく分からないじゃないですか
だからそこは僕はいやとりあえずやるんだと
このペースでは手段と目的逆転させていいから
みんなAIでやってみてみたいなことを言えば
やってくれるじゃないですか
そこははっきりメッセージやっぱり
AIの役割と理解の深化
打ち出した方がいいなって思ったっていう感じですかね
だからそこら辺の目的みたいなのも
伝えていってる感じですかね
それも伝えている
だから今はそのAIっていうのがどうなるか分からないから
とりあえず使ってみようっていう話をしていて
そんなこと言わなくても結構みんな使う人は使うんで
ただ全体としてみんな使わせるためには
そういうことをちゃんと発信していくっていう感じですかね
なるほど ありがとうございます
だから現時点で直屋さんは不確実ではある一方で
その生成AIツールどういうポジションというか
どういう役割のものになっていくかみたいなところって
何かあったりしますか
なんかですね ここ最近思っていることは
自分がやってたことを代替させる相手として
AIを使うのはあんま筋が良くないと思ってるんですよ
っていうのはAIは確率的な存在なんで
自分がやったことをそっくりそのまま再現させたいと思っても
そのとおりにやってくれなくて
かえってマネジメントコストがかかるんですよね
じゃなくて自分の力を増幅させるものだっていうふうに
捉えて使っていくっていう方が
何か使い勝手がいいなって思ってるっていう感じですかね
で その延長でいくとですよ
未来予測当たらないと思うんですけど
エンジニアはいらなくなるんじゃなくて
より重要な仕事ができるようになるっていう感じかな
っていう気はしていると思ってます
確かに何か必要なくなるというより
やれること自体はいろいろ増えたりすると思うので
逆に世の中のスピードというか
そういうのがまた変わってくるみたいな
それもそうですし
例えば僕後で話すかもしれないんですけど
競技プログラミングをやってるんですよね
競技プログラミングの問題を
AIに解かせることができるんですよ
昨今はもう
当たり前ですけど
それをAIに解かせて何の意味があるのかって
あるじゃないですか
だからその点でいくと
自分が解ける問題をAIに解かせても
多分ゼロなんですよね
そこで何か生み出される価値は
だけどその問題を
より深く理解するために
AIとブレインストーミングを一緒にやって
僕はこういう風に問えたんだけどどう思うって聞いて
こういう解き方もありますねみたいな
でもそれってこういうことみたいな会話をすることで
より理解を深めていくみたいな
パートナーとしては最高なんですよ
AIは
それはだから僕自身の能力を増幅させるために
AIを使ってるじゃないですか
そっちの方が僕にとっては
すごく重要な役割っていう感じですね
チームメイトとしてのAI
なるほどありがとうございます
本当にこう一人で出せる
なんていうんですかね
思考的な出力もそうですし
クオリティ的な出力もいろいろあると思うんですけど
そこを増幅させるみたいな
そうですね
ただロジックがそれどおりにやればいいものをやらせても
あんまりそこで生み出されてもらわないみたいな
そうですね
最近さっきよく障害直したみたいな話を
してるんですけど
一緒に直していくみたいな感じですよ
だから僕もなんとなく
あそこで問題が起きてるんだろうなって分かっていて
でもそれを知らみつぶしに探すってなると
大変だから
多分あの辺で問題が起きてるから問題が起きてそうな
箇所のソースコードを全部列挙してって言って
クールオードにこう列挙させて
じゃあそれのパラメーターをこのぐらいにしてほしいって
お願いして分かりましたって言ってパラメーターをチューニングさせて
じゃあデプロイしようって言って
デプロイして穴を折ったみたいな
いう感じなんで
自分が全然分からないことをAIにやらせて
うまくいくかどうかを試してるんじゃなくて
なんて言ったらいいんですかね
AIと一緒に協力して
チームメイトみたいな感じですよね
そういう感覚がものすごく
僕にとっては重要で
筋がいいなと思っている感じかな
自動化とか
あんまAIにやらせるというよりは
普通のプログラムでやらせた方がいいっていう感じですね
はいはい
自動化するプログラムを
一緒に作っていくみたいな
それをやらせるというより
一緒にソリューションを作っていくみたいな
その方が筋がいいってことですかね
なるほどありがとうございます
すごい勉強になりました
正しいか分かんないですよ
そう思ってるっていうだけで
ありがとうございます
なかなかこういう話をいろんな人とできるわけではないので
長谷さん
今日はありがとうございました
まだまだお話ししたりないので
次回も長谷さんとお送りします
ということで今回は
CTOのお仕事についていろいろお伺いをしてきました
結構僕が
部長になってから
悩んでることとか
全部言語化してくれたような感じがあって
非常に僕が
勉強になったような感じなんですが
リスナーの皆さんにとっても発見のある回になっていたら
良いなと思っております
さて
この番組では感想や次回ゲストの質問
リクエストなどお待ちしております
番組詳細欄にあるリンクより
お気軽にご投稿ください
Xではハッシュタグ聞いたFMをつけて
ポストしてください
表記は番組名と一緒でQFMが大文字
残りは小文字です
そしてApple PodcastやSpotifyのPodcastでは
レビューもできますので
こちらにも感想書いてもらえると嬉しいです
Kiita株式会社は
エンジニアを最高に幸せにするというミッションのもと
エンジニアに関する知識を記録
共有するためのサービス
Kiita社内向け情報共有サービス
Kiitaチームを運営しています
ぜひカタカナでKiitaと検索して
チェックしてみてください
来週も火曜日の朝6時に最新話が更新されます
番組のフォローをして
最新話もお聞きください
Kiitaプロダクト開発部部長の清野敏文と
株式会社一級CTOの伊藤直哉でした
