今回は、SHE株式会社 プロダクト本部長 開発ユニット長 森 久太郎さん(https://x.com/qsona)をゲストにお迎えしてお届けします。全3回の対話、お楽しみください。
<今回のトーク内容>
「実践×抽象化」で生み出す、写経で終わらない発信術/炎上経験ありますか?「炎上のロジック」/「人」という変数を扱う難しさ。EM発信の葛藤/AI時代こそ刺さる!n=1の実践知とその人らしさ/生成AIによる自社プロダクトへの影響と向き合い方
# 番組ホスト
清野 隼史:https://twitter.com/getty104
# 番組への感想・メッセージは、Xやフォームでお待ちしています!
Xハッシュタグ:#QiitaFM
フォーム:https://forms.gle/K9HyUGy7phDBGpht7
See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.
感想
まだ感想はありません。最初の1件を書きましょう!
サマリー
本エピソードでは、SHE株式会社の森久太郎さんをゲストに迎え、マネージャーになると発信が難しくなる理由や、アウトプットを続けるための工夫について深掘りします。森さんは、自身の経験に基づいた「実践×抽象化」のアウトプット術や、炎上経験から学んだ「ポジションを取りつつ丁寧に伝える」ことの重要性を語ります。また、AI時代におけるアウトプットのあり方や、コミュニティとしてのQiitaの役割についても議論が交わされます。
アウトプットの始まりと継続の理由
日本最大級のエンジニアコミュニティQiita、プロダクト開発部部長の清野俊文です。
この番組では、日本で活躍するエンジニアをゲストに迎え、キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに抑圧話題を発信していきます。
前回に引き続き、ゲストは、C株式会社プロダクト本部長開発ユニット長の森久太郎さんです。よろしくお願いします。
よろしくお願いします。
ということで、3回目。これも毎回恒例なんですが、最後、アウトプットについて聞いたので、いろいろお話を聞いておきます。
アウトプットまでに、僕もむしろ聞きたいことがいっぱいあるので。
ぜひまたちょっとお話できると嬉しいです。
お願いします。
森久太郎さんとお送りする3回目のテーマは、マネージャーになると発信はなぜ難しくなるのかです。
森久太郎さん、今もアウトプット、ノートだったりとかでもいろいろされてるところは、僕も拝見してるんですけど、
最初にお伺いしたいのが、いつからそもそも外部のアウトプットって始めてますかっていうところなんですが、どうでしょう。
一応、新卒2013年の頃から、当時はちょっとハテナプログを使ってて、今はちょっと動かしてないんですけど、たまに技術記事を書いていました。
それからぼちぼちっていう感じなんですけど、最初にいわゆるその一般的なところで登壇をする機会が2015年のノード学園祭さんでいただくことができて、
それ以来は結構その後転職したんですけど、その転職した後は結構ベンチャー企業に行ったのもあって、
割とブログ書いて盛り上げようみたいな機会もあって、それ以来は結構技術ブログ書いたりとか、登壇したりとかを結構やっていることが多いかなと思います。
ありがとうございます。一番最初のその新卒の時にアウトプットをした理由って何かあるんですか。
かっこよさそうに見えたからじゃないですかね。今見ると別に大したこと書いてないっちゃ大したことないんじゃないんですけど、新卒にしてはまともなことを書いていたというか、
例えばですけど、エクスプレスっていうノードサーバーを使っていて、ボディをちゃんと検証しないでMongoDBに投げると、クエリにドルなんちゃかっていうボディを投げられたら脆弱性になるよねみたいなことを書いていて、
例えばそれはまあそうというか、気をつけたほうがいいねみたいな内容だったりはするんで、ちょっと抽象が甘いですけど、その時そうですね、業務で学んだことを書いてたっていう感じですね。
そうなんですね。当時って何かしらそういうブログみたいなものに対してリアクションとか、周りの方から言及とかもらったりすることってあったんですか。
いやあんまなかったですね。
そうなんですね。
それこそその後にKiitaさんでいくつかブログ書いたりとか、それこそAdvent Calendarとかに書いて、その頃とかはすごいリアクションもらえて嬉しかったというか、思いますね。
なんかまあ結構あるあるなんですけど、最初アウトプットしたけど全然反応もらえないとやめちゃうみたいなことって結構Kiitaのユーザーさんに言って、
はいはい。
その時から今そのKiitaさんをなんやかんや今もアウトプットされてるって話だと思うんですけど、だから続けてこれた理由って何かあるんですか。
いやあ、でもちょっとエンジニアリングマネージャーになってからちょっと滞ってる感あるんで、ちょっと続けてると言えているかどうか怪しいですけどね。
どうだろうなあ、確かに一定のレベルに達するまでの方が難しかったと思いますね。
一定のレベルに達してからはある程度、別に反応をもらうために書いてるわけでもないというか、ある種自分の人生の中で考えたことの記録として出しているっていう部分もあるのと、
なんていうのかな、そんなにこうすごく技術を深掘りした記事をめっちゃ書いていたわけでも今でも昔もないので、
それ一個一個にすごく反応が欲しくてやってるわけでもなかったりとか見られないこともある中で、ある種自分でちゃんと振り返れるみたいなこともあってやっているので、
最近はそんなテンションでやってるんですけど、それでも例えばですけど、これは諸説ありって感じですが、公式ドキュメントに書いてあることをそのまま同じ情報量で自分の記事で書くのって、
僕はあまり意味があるアウトプットだとは思ってなくて、自分なりの実践とその抽象化が重なって初めて意味のあるアウトプットになると、僕は個人では定義している。
自分で何かしら実践して起きたことでない限りは別にそれは意味のないというか、別に一般論なんでそれはどっかの誰かが書いてるよねっていうことと、それを何かしらの形で抽象化というか一般化なのか、あるいは他の事実とつなげ合わせたりとかそういうことがないと、本当にただの経験のそのままになっちまって、
それは自分のそのNイコール1の辞書には当てはまるけど、それをアウトプットしたとしても他の人に意味があるものにはならないと、あとから自分が読んで意味のあるものではなかったりするので、そこの自分の具体の経験とその何かしらの抽象化っていうのを今意識してアウトプットしてるんですけど、
それが結構何か回数こなすと何か自然にできるようになるというか、そこから先は割と考えたことと書きたいことが何かこう身体とつながっている感覚っていうんですかね、があるので割とアウトプットしようと思えばするみたいな感じになれたと思うんですけど、でもちょっとこの辺の定義とかも人によりますよね。
そうですね。
なんかちょっと僕個人としてはその、Kiitaさんとして推奨しているアウトプットのスタイルとか、僕は今勝手にこうなんかちょっと偉そうに自分の経験とそこからの抽象化みたいなこと言っちゃったんですけど、じゃなくても必ずしもアウトプットはいいと思うんですけど、何かこう方針とかあったりするんですか、おすすめの方針。
そうですね。運営のスタンスで言うとやっぱりその人が経験したこととか、その人が感じたことっていうのをやっぱりアウトプットしていただくっていうのがやっぱりいいなっては思ってますね。
まさにそのなんて言うんですかね、例えばエラーとかの内容が何かしらこうトラブルシュートできたって時に、その似たような記事があったとしても別にそれは逆に言うと別に書いてもいいと思うんですね。自分がどう解釈したかとか、それに対してアプローチしてこれはうまくいかなかったとかっていうのがあれば。
ただそのドキュメントをただその通り他のやつを社協するだけだと、それはやっぱりあんまり意味がないですし、普通に著作権できない未来でもあんまり良くないなと思ってはいるので、やっぱその自分がやっぱりどうなのかっていうところを聞いたとしてはどんどんアウトプットしていただきたいなと思ってますし、
聞いたのその理念的なところで、そのアイデンティティを確立していくってところで、そのアウトプットってものが積み重なっていくことで、その人がなんとなく普段どういうことを勉強してるのかとか、どういうことをこだわってるのかとか、そういうのが分かるっていうねみたいなのは言ってたりするので、
ノリとしては結構今、旧村さんがおっしゃってたところに近いのかなとは思ってました。もちろんいろんな方、いろんな使い方されてる方はいるので、いじわりにこれはダメですとかは言いづらいところはあるんですが、運命としての思いとしてはそんな感じっていうイメージです。
実践と抽象化によるアウトプット術
個人的には発信のときはなるべくポジションを取るようにしていますね。僕はちょっとですね、最近は技術記事よりも若干ちょっとポエミな記事を書くことが多くて、媒体としてはノートを使うことが多いんですが、
ちょっとAI時代に物を申すような記事を書いたんですけど、生成AIの成果物に責任を持ってくれっていう記事を書いたんですけど、これが最近すごい読まれて、今770ぐらいについてるんですけど、結構その時代に刺さったっちゃ刺さったんだと思うんですけど、
要は生成AIに出して、これでどうぞみたいな成果物が、世の中的にもそうですし社内的にもそうですし、そういうのが増えた時期があって、それに対して物申したっていう感じなんですけど、ちょっとそういう自分のポジションをちゃんと取るみたいなことを意識するようにしてます。
まさにそうですよね、結局自分がどう思ったのかとかを自信持って言うって、それって結局ポジションを取るっていうことに近いのかなと思うので、例えばこういうドキュメントにはこうやれって書いてあったけど、自分は違うと思うみたいな、例えば。そういうのも全然いい気がするんですよね、例えば。それでポジションを取るってことなのかなっていうのは思います。
ポジションを取ると批判も多いことありますけどね、まさかりと言いますか、それも一つの経験かなという。
ちょっとそこも聞きたいなと思って、やっぱりどうしてもアウトプットを続けてるといろいろこう、特に正解がないものほどいろんな意見が出てきたりするんじゃないかなって思うんですけど、そこら辺でいわゆるちょっと泣いちゃったりテンション落ちちゃったりみたいなことってないんですか?
ありましたね。
あ、そうなんですね。
2019年ぐらいに1ヶ月間毎日ノートを書くっていうのやってたんですけど、言ってしまうとはてなブックマークでめちゃめちゃなんか斜め読みして悪口が書かれるみたいなのがあって、それで僕はちょっとはてなブックマークのChrome拡張を消したとかはありますね。
泣くはないんですけど、ちょっとですね、ある種炎上余計がうまくなったですね。
僕は本当にスタディスアプリを辞めたときに、スタディスアプリのブログを書ける最終日というか、自分が在職している最終日にスプリントプランニングを辞めたみたいな記事を書いたんですけど、これはもう絶対にちゃんとエクスキューズして書かないと、スクラム原理主義者みたいな人にこれはちょっと燃やされてしまうぞと思って、
そんなことをしたらちょっと今から退職する人間がこんな記事を書いて燃やしてしまったらもう残る人申し訳なさすぎると思って、ちょっとちゃんと炎上しないように書いたつもりだったんです。
それでも、やっぱ中身を読んでない人のコメントはいくつかついたんですけど、トータル大丈夫でした。
そうなんですね。先ほどのポジションを取るって話も通してなんですけど、その炎上余計じゃないですけど、ある意味でポジションを取りつつもちゃんと伝えたいことを伝える上で工夫していることが具体的にどういうところなんですか?
やっぱある程度わかるようになってくると、ちゃんと例えばですけど、スプリントプランニングをやめたっていう記事を書くときで言うと、スクラムガイドを参照してそこに書いてあることをちゃんと逐次参照しながら書くようにしました。
それをどっかの野良の言説というかを参考にし書くと、それは原点では違うことが書いてあるとかって言われちゃうので、ちゃんとそこはある種誠実にというか、例えばある概念の批判をするわけじゃないが、ある概念に対して対立することを言おうとしたら、
そのちゃんと概念に関して中立にというか、正しく引用だったりとかするみたいなことは気をつけてますね。
ある意味でやっぱ丁寧にちゃんと雑に記事書かないっていうところですね。そういう特にある程度意見がわかりそうなものとかに対しては。
そうですね。でも基本的に言うとやっぱり雑に記事書きたいじゃないですか。雑に記事書きたいですかっていう言い方がいいのかわかんないんですけど、禁止しすぎるとやっぱ書けないんですよね。
それともう一個思い出しました。過度の一般化をしすぎないことをですね。一般化するんだったらこういうこともあるよなと思いながらも、そういうところまで一般化すると、
逆に主張が薄れたりとか、生々しさが薄れてつまらなくなるっていう面もあるし、いらんところに飛び火しちゃうこともあるんで。
ちゃんと自分の見聞きした状況をちゃんと描写と言いますか、するっていう。変に膨らませるとだいたい薄くなって意味がないっていうのもあるんで。
特にすごく時間をかけてちゃんと書くっていう執筆業みたいなものだったら別なんですけど、個人のアウトプットのベースで言うと、そこまでの責任は求められないと思うんですよね。
なので、ある種広げすぎないというか、自分の対象のドメインをちゃんと明示して、そこに関してポジションを取って書くみたいなことはちょっと意識してるかもしれないですね。
やっぱり一般化と主語を大きくしすぎないってところですかね。あくまで自分のシチュエーションの中でっていうのをやっていきますね。
炎上経験と発信の工夫
そうですね。だいたいソフトウェアエンジニアリングに関してとか、チームビルディングとかに関してとか書いてると、だいたい別にソフトウェアに関係しねえなとか思うんですよね。
だけど、その領域のことはわかんないので、ソフトウェアに関係しないかもしれないけど、ここではソフトウェアの話として書いてるよみたいなことを書くようにしたりしてますね。
はいはいはい。なるほど。ありがとうございます。僕も何回か昔、そういう感じで。
炎上経験ありですかね。
はい、あります。
どんな炎上したんですか。
僕は、文章雑に書きすぎたっていうのはあるのと、一般化しすぎたのと断定を使いすぎたっていうのがありますね。
いいですね。炎上しそう。めちゃめちゃ炎上しそうじゃないですか。
しかも一回とかじゃなくて、アウトプット結構僕もしているので。
何回も炎上してんじゃん。
何回もって言うほどではないですけど、数回ちょっといろいろ変にすごい拡散されちゃったこととか。
気になるんです。何ていう記事が書かれてるんですか。
もう記事の内容ちょっとアップデートしちゃったので。
炎上されないように直してしまった。
そうですね。会社の方々にお伝えしてやるっていうのもあるので。
ちょっと週オフレコでまたちょっとお伝えします。
過度な一般化をすると、やっぱり自分が責任を取れない範囲まで言及しちゃうことになるんで。
やっぱりちょっと難しいというかありますよね。
マネージャーになると発信が難しくなる理由
ちょっと話変わっちゃうんですけど、アウトプットっていう話をすると結構エンジニアリングのコンテキストで話すことって結構多くて。
こういう聞いてる人の中でもそうなんですけど。
でも旧相談さんも含め、やっぱりマネジメントをやりだすとアウトプットをあんましなくなっちゃうんだよねって方結構多い気がするんですよ。
僕も一応キーターをやってるのでキーターでアウトプットはしてるんですけど、一時期前回お話しした通りあんまりアウトプットする年代がなくなっちゃったみたいなのがあったんですけど。
旧相談さんは割りかし今もアウトプットされてたりするじゃないですか。
そこの何て言うんですかね、続けられている理由と続けているモチベーションみたいな、またちょっと繰り返しになっちゃうかもしれないんですけど、そこをもうちょっと聞きたいなと思ってて。
いやーでもまずそもそも何てエンジニアリングマネージャーになるとアウトプットが難しくなるのかについてはちょっと考えたいなと思ってて。
まず一つは個人の話が絡んでくる。最近もなんかツイッターかなんかでありましたよね、ありましたよねとか言ってあんまちょっと人の炎上を掘るのも趣味が良くないんであれですけど。
やっぱりなんかこう組織課題を解決したみたいなのを書いたことがそれが個人のなんていうか悪口じゃないんですけど、あんまり良くないんじゃないかみたいな話とか。
それは別にそのアウトプットが良かった悪かったはさておき。
書く側としては木になっちゃってしょうがないので、やっぱり木を使いますよね。ちょっと今も木使ってますからね。
なんかそのエンジニアリングマネージャーとしてこういうことやりましたみたいなのを言ったら、もしその人が聞いてたら自分のことだなって思うだろうし、
それがしかもなんか僕の手柄みたいなことで言ったらなんかちょっとね、なんかそれが対象がやっぱり技術の課題とかだったらまだ良いですけど、
なんで少なくともやっぱり何か一定のタイムラグとかやっぱ一定の抽象化とかが必要になってくるっていうところが難しいですよね。
あとはもう一個がやっぱりその技術の方だと対象的にしているものが特にシステムなんで固定的であったりするわけなんですけど、
やっぱり人の方が若干その確実というか生物というかなんで単純に一般化できないっていう面もありますよね。
なんで気を使う面はありますよね。例えばですけど、僕はエンジニアリングマネージャーとしてちょっとチャレンジしますけど、
チャレンジっていうのは炎上に当たらないかどうか気をしにしながらしゃべりますけど、例えばシー株式会社という会社はやっぱり女性が多い会社なんですよね。
僕は比較的女性に対してのマネジメントは得意な方なんじゃないかと自認がまずあって、それはなんでかというと比較的男女の僕の経験で言うと女性の方があんまりこう、
例えばですけど、評価面談だった時に自分はこういうふうに活躍したからこういう評価に値するんだとかそういうアピールをしてくるとかは弱い傾向にあると僕は思っていて、
自分の経験から感じていて、それに対してどちらかというとそういう人に対してあなたこういう活躍したじゃないですかとか、あなたこういうとこいいとこあるじゃないですかみたいな、
良いところを発掘したりとか、成果をちゃんと自分の言葉で言語化してあげて気づかせてあげるとかそういうの結構得意なんですよ。
なので割と僕は女性のマネジメントは得意ですとか言ったら、今かなり今喋る中でもだいぶ言葉を見越しながら喋ったと思うんですけど、
やっぱり認識が甘いと言われてもしょうがないとか本当にそんな研究あるのかとか、例えば性差別を助長するんじゃないかとか、実際そういう観点があると思うし、
ちょっとこういう話題の中だから今話せてますけど、やっぱりそのままNイコール1の話題をそのままストレートにアウトプットしていいかどうかで言うと、やっぱりちょっとかなり気を使うわけですよね。
なのでかなりこれはやっぱり個人の感想ですけど、自分の研究がこうですって言えることあるにしても、やっぱりすごく他の技術的なもののコメントすることに対してよりも裏取りとかそういう面で慎重にならざるを得ないっていうのが難しいところ、アウトプットがすごく難しいところだと思うんですよね。
発信を続けるモチベーションと難しさの乗り越え方
で、じゃあなんでそれが続けられているかみたいな、モチベーションは引き続きやっぱりあって、自分の考えを何かしらの形に残すっていうことは後の自分を助けることにもなるし、自分の人生としてやっぱりやってきたことを何か残したいみたいな根源的な欲求って多分あるんじゃないかなって思っていて、
僕は気持ち悪いんですけど、普通に昔の自分が書いた記事とか読んで、なんか普通に面白いなと思ってニヤニヤしてますね。
で、普通によく自分で引用しますね。例えばこういう時こういう記事書いたんだけど、これは別に自分の記事以外にも好きな記事はよく引用するんですけど、やっぱり自分で書いたことはすごく頭に残っているので引用しやすいっていうのはあると思います。
だから結構2019年ぐらいに書いた記事とかを、去年とかもこういう時引用してこういうこと書いたんだけどみたいな話したら、その人にとっては刺さったりとかいうこともあったりしましたので、そういうモチベーションはあるんですけど、やっぱりその難しさってありますよね。
ちょっとその難しさをどう乗り越えてるのか、ちょっとベッディさんにお聞きしたい。
まあそうですね。いや、まあ僕は先ほどお話しした通り、それ何回か言及されたことあるので、あれなんですが、先ほどの話とちょっと逆っぽい感じになっちゃいますけど、だからある意味でちょっとしたやっぱり一般化みたいなのも必要なシーンはあるなとは思ってます。
特に技術的なところではなくて、そういう組織的なところとかマネジメントの話になると、自分のユースケースの具体を話せないシーンもどうしてもあるので、そこで起こったことからの学びとしてちょっと一般化したことをこういろいろ考察して書いてみるとか、そういうところは意識はしますかね。
ただやっぱりそこもそこでいろいろトレードオフはあるかなと思うので、やっぱり難しいなとは思っています。
でもやっぱり本当はエンジニアリングマネージャーの行動というかこそアウトプットになってほしいですよね。
いや、本当にそうですね。やっぱりどうしてもマネージメントって特にやっぱりいわゆる技術、エンジニアリングよりもよりプラクティカルなものというか、やっぱり本当に変数がいっぱいある。外的な変数もあれば内的な変数もいっぱいある中で、こういうシチュエーションのときはこれがうまくいったよみたいなのが欲しいですよね、本来は。
そうですよね。結構その事例の数が大事ですよね、出てくる。
なので、そうやってやっぱりいわゆるインターネットとかでそうやって探ったりするのは難しいなと思っているので、こういう感じでいつも聞いたAMとかで話できるのは非常にありがたいなと思っています。
でも確かに音声での発信って僕はあんまりやれてこなかったんですけど、まだ話しやすい感じは全然ありますね。ちょっと可能性を今感じてますけど。
あると思います。やっぱり一人歩きしないみたいなのは今までのゲストの方もおっしゃってる方多くて、ポッドキャストやられてる方もいらっしゃったので、聞いてるとやっぱりそこが音声のアウトプットの良さだよねみたいなのをおっしゃってる方は多かったですね。
今後の目標とAI時代のアウトプット
ということで、いろいろアウトプットのところから含め、いろいろ悩みのところをいろいろまた情報交換できたというか意見交換できてとても楽しかったなと思ってます。
ありがとうございました。
最後にですね、キュウソナさんの今後の目標について聞きたいなと思ってるんですが、いかがでしょうか。
いやー、完全に何も考えてくるの忘れてしまいましたね。
第一回でも喋ったんですけど、キャリアが川下りすぎて目標設定をちゃんとできたことがないんですね。
なんで、一旦今日できた目標としては、やっぱり発信は頑張りたいですね。
らしい。もっとエンジニアリングマネージメントとか、VP of Engineeringとしての役割、考えていることみたいなのを、なるべく生の形に近い形で発信できるっていうことはすごく価値だよなと思っています。
いやー、難しいですけどね。やっぱり世の中に例えばCTOハンドブックみたいな、すごいそういうのとかあって、参考にしたりすることあるんですけど、
そのハンドブックを読んだりとか本を読んだら、なんか自分と同じ状況にいている人が書いてるわけじゃもちろんないので、日本と海外でも違うし、組織の規模も全然違うし、求められている役割とかも違うので、
やっぱり、一、自分のケースとしてちゃんと果たせるっていうアウトプットはしたいなっていうのは思いました。どうやったらいいんですかね。まあいいや、一旦目標を。
そうですね。聞いたイフェイムなので、やっぱりこういう感じで、何て言うんですかね、やっぱ記事とかだとネタがあって書き出すとか、いろいろインプットしだすってあると思うんですけど、
こうやって音声とかだと話しながらなんか見えてくるとか、発見があるとか、何かしら学びがあるとかって結構多いなって僕は、この聞いたイフェイムを通していつも感じているので、
違う形でのそういうアウトプットの型とかインプットの型みたいなのもやってみるのありかもしれないですね。わかんないですけど。
いや、そうですよね。それでなんかこうアウトロに差し込んで非常に申し訳ないんですけど、僕一個絶対に聞きたいと思って聞き忘れてたことがあったんで、ちょっと聞かせてもらいたいんですけど、
やっぱ、生成AIによってアウトプットって、ある種量を出すだけだと楽になってる部分あるじゃないですか、なんかその現状に対してそのQiitaの運営としては、
なんかこうポジティブ・ネガティブとかこういう変化があるとかどういう風に捉えられてますか。急に全然関係ない質問挟んでしまうんですけど。
そうですね。やっぱポジティブな面もあればネガティブな面どっちもあるなとは思ってはいます。
ポジティブな面で言うと、やっぱりその生成AIというものが登場したことによって、そもそもその生成AIを使ってる人もいっぱい増えてるので、書けるネタが増えているっていうのと、
あとやっぱ今プラクティスをみんな貯めてるタイミングなので、みんな書きやすいっていうのがあるかなと思ってます。
で、もちろん記事を書くってところで生成AIを使って補助的にやってもらうってところもできるようになってきているので、
そういう意味でのアウトプットっていうのは実際増えてるのはデータとしても色々見てるところです。
やっぱネガティブで言うと逆ですよね。そのやっぱAI、あまり意味のない情報がどんどんAIによって生成されちゃうみたいな。
そういう側面もあるなと思っているので、やっぱそこはある意味でのコミュニティマネジメントの難易度はまた一段上がってきている。
いわゆるスパムみたいなのはもちろんこういうサービスなので今までもいたんですけど、
よりこう分かりづらくなってきてたりとか、一見それっぽいんですけどリンクがやばいとか、
そういうのはやっぱ観測はしているので、そこも日々色々対策はしているんですけど、っていうのは感じているところです。
で、Kiitaとして今大事にしているところで言うと、やっぱどこまで行ってもKiitaってコミュニティ的な側面はあるので、
コミュニティとしての良さみたいなところを感じてもらえるようなプロダクトもそうですけど、色々イベントをやったりとか、
今月1でオフラインのイベントとかもやってたりするんですけど、そういうところでの繋がりみたいなのをちゃんと作っていくとか、
人らしさを味わえる体験っていうのは今の時代だからこそKiitaとしては作っていきたいなと思ってたりしますね。
ありがとうございます。
それはちょっと僕の目標の話に戻ると、今話を聞いていてお互い共通しているなって思ったのが、
生成AIがこれだけ流行っている時代において、エンジニアとしてはもちろん活用してやっていくものであると思うんですけど、
作っているサービスへの影響度合いっていうのはお互い結構でかいなと思っていて、
御社でいうとやっぱりアウトプット、記事とかってめちゃめちゃドストレートに影響し得るところだなって思っているのと、
僕らでいうとキャリアですよね。人々のキャリアが今後どう変わっていくのかっていうのは正面から向き合わないといけない課題だったりするので、
そうですね。ちょっとなんで目標というか、このやっぱり数年ぐらいはどうしてもこの波に乗っていかないといけないので、
ちょっと振り落とされないように楽しくAI図家でしない程度に飲まれないようにしたいなって思いますね。
やっぱりちょっと飲まれがちですからね。本質を見失いがちというか、何でもかんでもAIになっちゃうんじゃないかみたいな。
全然そんなことはないんですけど、大事なものはちゃんと見失わずにこの波を乗り切りたいなっていうのはちょっとふわっとした目標としてはあるかもしれないです。
ありがとうございます。いやもう僕も頑張っていきます。
番組の告知とエンディング
はい、ということで、キュウソナさん3回にわたりありがとうございました。
最後に何か告知などありましたらお願いできたらと思います。
告知か。副業も募集してますので、こいつに仕事依頼したいって人いたら声かけてください。そんなやついるんか。
いやもうキュウソナさんの今回のPodcastを通して興味を持たれた方もいらっしゃるんじゃないかなと思うので、ぜひご連絡いただけると嬉しいです。
ありがとうございます。
はい、ということでキュウソナさんまたお待ちしております。
はい、楽しかったです。
いやもうこちらこそ本当にありがとうございました。
ありがとうございます。
はい、ということで今回はですね、アウトプットのところのお話をベースに結構これからのことについてもいろいろ情報交換、傾向感ができて本当に楽しかったなと思ってます。
やっぱりキュウソナさん、いろんなものを言語化じゃないですけど、言語化っていうのは過去課題として感じられたみたいなのもあるかもしれないですけど、言語がすごいうまいなって思いました。
本当ですか。
それはちょっと僕らこの10年間の成長かもしれないですね。
いや本当にすごく感じましたし。
すごい下手だったんで。
共感できるところもすごく多かったですし、発見もあったので本当に楽しかったなと思ってます。
ありがとうございました。
はい。
さてこの番組では感想や次回ゲストへの質問、リクエストなどお待ちしております。
番組詳細欄にはリンクありお気軽にご投稿ください。
Xではハッシュタグ聞いたFMをつけてポストしてください。
表記は番組名と一緒でQFMが大文字、残りは小文字です。
そしてApple PodcastやSpotifyのPodcastではリビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
聞いた株式会社はエンジニアを最高に幸せにするというミッションのもと、
エンジニアに関する知識を記録、共有するためのサービス聞いた、社内向け情報共有サービス聞いたチームを運営しています。
ぜひカタカナで聞いたと検索してチェックしてみてください。
来週も火曜日の朝6時に最新話が更新されます。
番組のフォローして最新話もお聞きください。
お相手は聞いたプロダクト開発部部長の清野俊文と、
C株式会社プロダクト本部長の森球太郎、QSANAでした。
33:20
コメント
スクロール