SHE株式会社の現状と組織変革への取り組み
日本最大級のエンジニアコミュニティ Qiita、プロダクト開発部部長の
清野俊文です。この番組では、日本 で活躍するエンジニアをゲスト
に迎え、キャリアやモチベーション の話を深掘りしながら、エンジニア
の皆さんに抑圧話題を発信して いきます。前回に引き続き、ゲスト
は、C株式会社プロダクト本部長 開発ユニット長の森久太郎さんです。
よろしくお願いします。 森久太郎 よろしくお願いします。
森 久太郎 はい、久さんさん、今回も よろしくお願いします。
久太郎 お願いします。ちょっと、 具体に入り込んで、じゃんじゃん
喋っていこうと思うので、よろしくお願いします。
森 久太郎 お願いします。ということで、
2回目は、今やられているところ について、もうちょっといろいろ
深掘りをできたらなと思っております。 森久太郎さんとお送りする2回目の
テーマは、AI時代の開発組織をどう 作るか、です。最初にお伺いしたい
なと思っているのが、ちょっと改めて にはなってしまうかもしれない
んですが、今のC株式会社で取り組ん でらっしゃることについて、ちょっと
お伺いできたらなと思っています。
久太郎 ありがとうございます。ちょっと そうですね、僕最近、自分でよくない
なと思ってるんですけど、1ヶ月 振り返ると、何やったんだろう、
この1ヶ月みたいなんで、分かんなくなる ことがめっちゃあって、何やって
んだろうなみたいな、何も仕事 しない気がする割に忙しいなみたいな
セルフマネジメント下手くそなんです けど、基本はやっぱり課題のもぐら
叩きをしている時間が長いですね。 とはいえ、徐々にプロダクトを戦略
的に伸ばせるようになってきている なと思ってます。僕が入社した
のが、2023年の7月なので、だいたい 3年弱やってきてるんですけど、この
間で特にこだわってやってきた ことっていうのは、組織の壁をなる
べく取っ払って、少人数で多くの ことができる組織に転換していく
みたいなところでした。一例を挙げる と、最初ってソフトウェアエンジニア
とデータエンジニアが別にもちろん 仲悪いとかではないんですけど、
あんまり交流が多くなかったり したんですね。なんで、やっぱり
例えばデータエンジニアとして 分析基盤を作ろうと思ったときに、
基本的にはソフトウェアエンジニア 側、つまりうちでいうとRailsのアプリケーション
がメインなんですけど、Railsの アプリケーションのデータ設計
とかにあんまり口を出すっていう 選択肢はあんまり存在しなくて、
基本データ基盤、Big Queryの定義 側でゴニョゴニョして直すみたいな
感じだったんですけど、やっぱり すごい無駄が多かったりするじゃない
ですか。なんで、そこをなるべく 一緒のユニット配下にして、僕が
両方マネジメントするような形 にして、会話もできるようにして
いくみたいなことをやったりとか。 あと事業部との連携もそうですね。
事業部と開発チームの壁がなるべく ないように、なるべく丁寧であった
りとか、細かいことはクイックに 相談するとか、そういう文化を奨励
したり、そういうのが得意な人を 開発チームのリーダーに置いたり
とか、そういうことを結構やって きたっていうのが1つありますね。
AI時代の開発生産性向上と課題へのアプローチ
あとは、最近でいうと、やっぱり 生成AIの開発生産性の向上に対して
どういうアプローチを取るかみたい なのは結構大きなトピックの1つ
で、これもやっぱり基本的には ボトムアップで改善していくこと
がたくさんあるので、それをやれる ようにしたいんですけど、やっぱり
トップダウンでここはこういう ふうにしようっていう石込みを
やっぱりする必要が出てくる場面 とかはあったりするなと思って
ますね。開発生産性でいうと、いわゆる 本当に開発の総量のことは問題
になることもあるし、開発した ものがいいものであって、ユーザー
とかビジネス価値にどうつながって いくかっていうほうも課題として
あるじゃないですか。そこでいう と基本的にはあんまりうちの組織
で、デリバリー側が課題になった ことそんなにないんですね。どっち
かというとディスカバリーとか 何を作るのか、それの戦略とのアライン
とか、そういうほうが基本的には 課題として上がりやすいんで、そっち
に対してうまく議論を自分がリード するときもあるし、配置で何とか
するときもあるしとかはやってます ね。直近よかった話していいですか。
はい。
プロダクト開発チームと一つの 事業部、ユーザー体験を作ってる
CXっていう事業部の合同で出社 する日でハッカソンをやったん
ですね。ハッカソンをやって6チーム ぐらいに分かれて最近の課題、ユーザー
的な課題をヒアリングして、それから 膨らませて、基本的にはそれをプロダクト
マネージャーとかデザイナーエンジニア が一緒にいる2人2人ぐらい大体
4人ぐらいのチームを6個作ったん ですけど、それで一緒に話を聞き
ながらデザイナーとかPDMとかが 落とし込んで開発者がクロード
コードとかを使ってエンジニアリング して形にするみたいなのを本当に
4、5時間ぐらいとか使ってやったん ですけど、結構形になっていいもの
がめっちゃよかったなと思うん ですけど、それの企画とか。その
時々で組織に対してこういうこと やったほうがいいんだよ。それ言う
と例えばやっぱどっちかという と結構ものづくりがばんばん早く
できるようになっているので、どっち かというとフロー効率というか
動機で喋る時間の確保のほうが今 ちょっと大事だなみたいな感覚
からそういうの企画したんですけど、 時々の課題組織とかプロダクト
サービスの課題とそれに対する アプローチをいろいろ考えて実行
するみたいなことをやってます ね
SHE株式会社への入社動機と初期のミッション
ありがとうございます。本当に 今お話聞いていた感じ、なんていう
んですかね、特定のこれをやって いますというより本当にアウトプット
ベースでいうと本当にいろんな 手段を問わずやられてるんだな
っていうふうにお話を聞いていた 感じなんですけど、もともとC株式
会社に入社されたタイミングでは 何をミッションとして持って
入社されたのかなっていうのちょっと 気になっていて
僕結構今自分の会社 というかCのビジョンは好きで
ビジョンというかそのやってる 事業もですけどね、結局一人一人
の可能性を開放していくみたいな ところに対してはなんか僕自身
もやっぱり自分自身がキャリア の中でうまくいっているときいって
ないときとか見ると自分の努力 できればどうしようもなくて環境
によって変わった部分とかそういう コミュニティによってさっきそれ
こそさっきというか前回JavaScript のコミュニティの話しましたけど
それコミュニティによって自分が 変えてもらったこととかあること
を考えるとやっぱり一人で変わる の難しくてそれをコミュニティ
の体験を通しながらスキルマインド ともに人が変わっていくみたいな
自分自身もそういう体験をしている しすごく大事だと思うんでそれを
やりたい方というのはシンプル に一つありますね創業時とかは
スクール事業というか対面で人を 教えてスキルを伝授していくという
かそういうところから始まって いてそこに対して徐々に後から
ソフトウェアのプロジェクトを 入れていったみたいな感じでそこ
からコロナ禍とかがあって大きく オンラインのほうにシフトして
いったみたいな経緯があるんですが やっぱりソフトウェアのプロジェクト
がすごい好きだったらやっぱり それってある種制約というかリアル
に対してのプロジェクトってある 種種々で言うと自由になりがち
なので僕は結構そういうのが好き というか別にソフトウェアのプロジェクト
だけで何か世の中の課題を解決 できるとそういうものももちろん
あるしテッキーな人とかそういう のが好きなのもあるかもしれない
ですけど結構そういうリアルと ソフトウェアの融合とかそういう
ある種制約っていうんですかね プロダクトづくりする人にとって
はそういうもとでいかにアジャイル にやれるかとかいい体験を作って
いけるかとかリアルとオンライン を融合してどういう体験作って
いけるかとかの結構そういう課題 の方がある種好きだったりもしたん
でそういうのも含めて興味があった っていうのがあります
なるほどありがとうございます 最初は共感だったりとか興味
エンジニアリングマネージャーとしての初期の成功体験
ってところで入られたってお話 かなと思うんですけど今って課題
があってそこに対していろんな 手段で解決をしていくアプローチ
を取ってるみたいな感じじゃない ですかそもそもの入社された当時
からなんですけどそもそもの向き合 っていくべき課題とか問いっていう
のをどうやって探索して設定して いたんだろうなっていうのがちょっと
気になってて 一番最初はミニマム でエンジニアリングマネージャー
としての期待はもらいますっていう ふうにして入りましたシンプル
にエンジニアリングマネージャー 要は特にピープルマネジメント
からワンワンして課題ヒアリング してその課題間に対してアプローチ
するっていうだけでも結構やる ことはあったんですねちょっと
これ発信あるあるですけどエンジニアリング マネージャーとしてやったことって
なかなかちょっと話しにくい人間 からでこういう課題があって解決
しましたとか話しにくいんですけど 当時3人の方のワンワンを最初に
引き受けてワンワンしていく中で 3人それぞれ別の課題を持っていて
それぞれに対して意外とちょっと 偉そうに言うと結構きれいにエンジニアリング
マネージャーとして解決できた っていうのがあってそういうところ
から徐々にエンジニアリングマネージメント の価値みたいなのを組織に持ち
込むことができたなっていうのは 最初の組織における成功体験
になったかなというふうには思います ねそこからどうですかねでもそう
するとだんだんやっぱりプロダクト マネージメントのほうが今全体
を見たときにちょっと課題だよね って思ったらそのプロダクトマネージメント
のほうをどういうふうにしていける といいかとか
AI登場による開発組織の変化と課題の増幅
まあこうもぐらたたきしている 感覚僕もすごい分かる
分かります
いやもう本当に分かります やっぱりとりあえず最初ってこれ
って普通に課題だよねみたいな そもそものベースの世の中全体
のスタンダードから考えるとここ 課題だよねってところからあって
そこ叩いていくとだんだんそこの スタンダードに上っていって次
は会社でやっていきたいことベース とか実現したいことベースでの
ギャップが次は課題になってきて そこ解いていくっていうので
めっちゃそうかも結構 その流れですね僕はちなみに最近
どんなもぐらたたきました
最近のもぐらたたきで言う とやっぱ最近やっぱりトピック
で言うとAI周りは多いかなと思います 何て言うんですかねここ数年間
でメンバーに説いてきた組織的な 論とかアプローチとかフィードバック
っていうのがAIが登場したこと によって結構変わってきてるな
って感じがあって全体が変わった のでそれぞれの求めていくスタンス
とか組織全体で目指していくアプローチ も変わってくるっていう
どう変わったか聞いて もいいですか
そうですねこれはマネジメント あるあるで具体的に言いづらい
みたいなのあるんですがやっぱり AIっていうものが出てきたこと
によってやっぱ1人で出せるアウトプット 量がすごい増えてると思うんですね
良くも悪くも 良いほうはできる だけいかに権限とかしがらみを
なくしてトップスピード走って もらうかってところ考えないと
いけないですし逆に悪いほうで アウトプットが出たときはそれ
マイナスがレバレッジがめっちゃ 効いちゃうって話なのでそれを
どうやってカバーしていくか みたいなところとかどこにガード
レールを引くかとかそういうのは 結構日々メンバーからの意見も
汲み取りながら設計したりはして ますね最近はでもそれはエンジニア
だけじゃなくてやっぱ組織全体 いろんな職種の方もいるのでその
職種が変わるとまた事情もいろいろ 変わってくるみたいなのもあった
りとかでいろいろやってるって 感じですね最近は
AI以前からの継続的な課題とフロントエンド改善の意義
いや確かにちょっとその 話もうちょっと掘っていきたい
なと思うんですけどだから僕が 聞きまくるのなんかね僕も最近
まさにちょっとAIの登場によって 結構叩く課題というか変わって
きてるなっていうのは一個あるん ですけど今変わってきてるなと
言っておいてなんだんですけど 実はそう大きく変わってないっていう
説もあるなと思っていて一個ですね 良かったことで言うと入社して
開発ユニット長というのやるよう になってすぐ後ぐらいに1人その
フロントエンドエンジニアのメンバー がフロントエンドの高度改善に
自分の時間を投資したいとそういう プロジェクトをちゃんと立ち上げ
て自分はある種当時普通にプロダクト 開発をやってたんだけどもその
フロントエンドの基盤の改善の プロジェクトを立ててそこに自分
の時間を使いたいということを 明確に意識表明してくれたんですね
それに対して僕は話を聞いてめ っちゃいいなと思ったし明確に
自分も組織長としてそこにやる ことに意識決定してその上でプロジェクト
の進め方とかアドバイスとかしたん ですけどそれが約2年半前ですよね
2年半前よりさらにもっと前でいう とデザインシステムをちゃんと
作ることにはもともと当時のデザイン メンバーとフロントエンドエンジニア
のメンバーが投資していてそこ からフロントエンド改善に関して
いうと当時Next.jsも入ってない ただのリアクトアプリの結構あと
独自実装がいろいろ入っていて 別にそれがすごい悪いというわけ
じゃないんですけど世の中の標準 から結構違って1回ちょっと大変
だったのはフロントエンドのコード がないことを理由に内定自体されて
フロントエンドエンジニアになって それぐらいちょっと世の中の標準
からかけ離れてた状態から今当時 アップルーターが入ってきたころ
から副業の専門家の方とかと一緒に アップルーターでいこうという
意識決定をしてそこから社内の フロントエンドのコードでめちゃ
めちゃ良くなってるんですけど それから本当にやっぱりここ1年
のぐらいの生成AIの伸びによって めちゃめちゃコードの生産量が
増えてきたんですけどやっぱり それこそ割れ窓理論とかあんまり
そういうことって変わってない その人間にとって認知負荷が高い
コードはAIにとっても良くない みたいなそこのフロントエンド
の改善に投資したこと 今になって みてすごく正解だったなという
ふうに思っていて っていうのは 当時別にAIのことを考えて意識
決定したわけじゃないんですけど より決断が正解だと自信を持っている
状況に今なっているみたいなことが あります
AI時代におけるリソース効率とフロー効率の再考
あとちょっと話長くてやるんですけど 最近で言うとAIがめっちゃ高度
書くようになってるからプルリクエスト のレビューが大変になっていて
そこはボトルネックになっていて プルリクエストのレビューっていう
ものを考え直さなきゃいけないん じゃないかみたいな議論あるじゃない
ですか それとかも別に昔からあった なと思っててGitHubでプルリクエスト
って業ベースで見るUIで見るレビュー っていうのは本当に費用対効果
高いのかっていうの 僕は普通に 5年前ぐらいに疑問を持って記事
を書いてるんですよ プルリクエスト レビューの限界みたいな記事を
書いてるんですけど 結構AIによって 出ている課題の多くは元々大事
だったり元々議論されてるのが すごく増幅されて出てきてるな
っていう感じなんで 個人的には 見覚えのある課題が並んでるな
って思ってたりはします あとフロー 効率重視したほうがいいとか リソース
効率よりフロー効率重視したほう がいいみたいなのよくあるじゃない
ですか AI出てきたこというのって リソース効率を重視する意味が
あんまりなくなってきているので とか そういう雰囲気思います
めちゃくちゃ分かるなっていう 話も聞きながら思ってたんですけど
AIによるアウトプット量の変化とメンバーのモチベーション
本当にやっぱりAIの登場によって 何が変わったかって 今までって
言ってもやっぱりアウトプット の天井が低かったって話だと思
うんですよね だから課題はある けど 運用でカバーができちゃう
とか 別にそこに対してのレバレ 値がそんな効かないみたいな だ
から課題だけど とりあえず今は これでやるかみたいなのがいけ
たんですけど AIが出てきたこと によってアウトプット量もすごい
増えているし 逆に良くないときに アウトプットが出ないときの差
がすごいでかくなる 綺麗なときに 1000倍ぐらい出ちゃうみたいな
だからそこに向き合わざるを得ない 状態になっているんだろうな
っていうのは 僕もすごい組織の メンバーの話を聞いていて すごい
聞いて思ってますね 逆に言うと AIが登場したことによって メンバー
自体もそういうのを解決していこう みたいな モチベーションが上が
ってるみたいな副作用もあるな と思います
おだしょー ありますね
問いが変わったことによって やってること一緒なのに AIが良く
なるなら頑張るかみたいな 謎 のモチベがみんな湧いてるみたいな
おだしょー いいっすね それめっちゃ いいですね
そういうのもあったり しますね
AI時代のプレイングマネージャーと開発体験の変化
おだしょー あとプレイングマネージャー できるようになりましたね
確かに そうですね 本当にそう思います
おだしょー 直で自分が評価者になってる メンバー20人弱ぐらいいると プレイング
マネージャー結構難しかった 評価者 っていうメンバーもそうだし 組織
もいくつか6個とかに分かれてる と 6個全部うまくいってるってことは
ないじゃないですか そうすると その場に入って 組織的な課題から
アプローチしなきゃいけないっていう のがあったんですけど その組織
に入ったときの入り方として 今 普通に実装タスクもらってやり
ながら こういう課題あるよね みたいなことの議論とかをしてるん
ですけど アプローチの深さ変わ ったなと思ってて それは結構感謝
ですよね AI出てくることによって コードを書くのは楽しくなった
人と楽しくなくなった人がいる みたいな話なんですけど 僕は確実
に楽しくなった方ですね
僕もめちゃくちゃなってますね 記事のアウトプット量 聞いたの
アウトプット自体も 絵が登場した ことによってトピックが僕も増
えてるので 何投稿しよっかなと 悩むことがなくなりました 一応
聞いたの上なので みんな投稿しよう ねみたいなやつをやってるんですけど
マネージャーあるあるで 途中から アウトプットすることなくなる
みたいなの 昔はあったんですけど 今 全然ない 無限に書けるっていう
いい時代ですね
AI時代におけるボトルネック可視化とプラットフォームエンジニアリングの重要性
いや でも ボトルネックがめちゃ くちゃ可視化されるみたいな 本当に
僕もそう思いますね だからこそ ここまで見えちゃうと やっぱそれ
解決しなきゃだよねみたいな SREみたいなプラットフォームエンジニアリング
がやっぱりソフトウェア領域において もすごく大事に ソフトウェア領域
って言うんですかね インフラとか にプラットフォームエンジニアリング
が大事なのはもちろんそうなんですけど ソフトウェアとしてのプラットフォーム
エンジニアリングの基盤整備みたいな のがすごく重要になっているっていう
のもあるし それ以外のところで 言うと やっぱり高度のアウトプット
量で言うと 別にすぐ多く出るので 広木大地さんで開発生産性のレベル
2とかレベル3のところにアプローチ する 要は開発の高度の量とか機能
の量ではなくて それが出してくる 付加価値をどういうふうに増やす
かっていうところにアプローチできる エンジニアとかがより必要になって
くるなっていう感覚が持ってます
すごく分かります ありがとうございます ここまでで旧ソナさんがやられてる
AI時代のVPoE/組織リーダーが提供できる価値
こと いろいろお伺いもできました し いろいろ意見交換もできて すごい
面白かったんですけど 最後にお伺い したいなと思ってたのが まさに
今 AIとかが出てきて みんな割り 貸しアウトプットも出せるし 課題
もあるっていう中で いわゆる VPOEだったり組織を見ている人間
が ここからやっていけることって やっていけること 自分たちだから
こそ出せるバリューとかアウトプット って何なんだろうなって 僕も
考えることがあって 最近
自分たちの組織って言ったから ということですか
自分自身
自身ですね
そこを旧ソナさん どうお考えしたら しますか
今で言うと やっぱソフトウェア エンジニアリングとして ちゃんと
10年とかやっているっていうこと とマネジメントのかけ合わせは
なんかめちゃめちゃ 今この瞬間 においてレバレージ効いてるな
と思ってるんですけど なんでか というと ソフトウェアの経験が
浅い人のAIに対して言ってること って めっちゃ浅くないですか
ソフトウェアエンジニアリング経験とAIの正しい向き合い方
めっちゃ浅いと思います
なんかちょっと悪口みたいにな ったんですけど AIによってテスト
駆動開発は死んだみたいな 何言 ってんのみたいなことがめちゃ
くちゃ多くて 逆にちゃんとソフトウェア エンジニアに向き合ってきた
人がAIに対しては もちろん驚くん ですけど 驚いた上で正しい驚き方
というか より本質的な 本質的 って言い方がいいかもしんない
ですけど 正しい未来の予測と 正しい問題解決ができる こんなに
AIのモデルのアップデートも AI例えばクロードコードとかコーデックス
みたいなそういうソフトウェア AIを使った開発ツール ソフトウェア
とかの進化も 両方今 めちゃくちゃ 早い中で 本当にトピックとして
めちゃくちゃ追わなくちゃいけない ことは多いんですけど 全部こと
細かく追うのはやっぱ難しいじゃない ですか の中で 普通に組織として
これやんなきゃいけないよね みたいなのは 当たり前ですけど
テスト書いてなかったら怒られる っていうのが変わんないわけじゃない
ですか
今の時代でも 普通にあれですね 結構 話飛ぶんですけど AIを使って
開発してる上で ソフトウェアの 開発速度って 全員がAI使っても
結構経験の差出るなっていうのは 最近の初感で 例えばですけど エピック
とかユーザーストーリーの単位 になってるものを 実装するとき
って そのまんまユーザーストーリー 1個1個実装するからそうじゃなかった
りとか ある程度まとめてDB設計 したりAPI設計したり ここはちょっと
テスト駆動でいこうとか こっち 先ちょっとUIの確実性高いから
こっちから作ったほうがいいね とか いろいろ考えながら 手順を
変えながら いい流度でやるじゃない ですか 結局 自分のソフトウェア
開発のやり方を割とそのままAI に持ち込んでるなっていう感覚
あるんで 結構 いかせてる感じ は ソフトウェアエンジニアリング
のスキルをいかせているし その 上で そこの感覚がないと 組織
のボトルネックの特定とかミスる なって思うんですよね なんで 今
この瞬間においては 結構 価値 出しやすいなって 自分の経験として
楽観的に思ってますけどね 5年後 とかどうか分かんないですけど
そうですね でも 僕も近しい ことを感じてて AIってまずベース
AIによる学習への投資と能力増幅の意識
のみんな同じだけ出せるアウトプット 量を出すっていう使い方と 自分の
能力にレバレッジを利かせるって やっぱり使い方があるなと思って
いて 後者の使い方をするといい し それをどう そういう使い方
ができるかっていうのを考えて くるのが大事だなと思ってるので
僕もできるだけ 自分の能力っていう ものを増幅できるような感じで
AIを使っていくっていうのをすごい 意識してるところですね
結構 新しいことを学ぶ 余裕が出てきたんですね
確かに
その面でも 結構 楽しい なとは思いますね 僕が
このCの組織の開発をリードする ようになってから 結構 新しく
学べなきゃいけないトピック 結構あって データ分析と機械学習
とか 自分がある程度マネージャー としてやる 自分が手動かせるか
ともかくとして 学ばないとマネージメント できないみたいなことが結構あった
ので そういうふうに学んだり それこそ 呼び乗りたくみさんの
YouTube 数学の授業とかしてくれた んですけど それを読んだりして
見たりして 学んでたりしたんですけど そういう新しいことを学ぶ余地
が 逆にあんまり学んでも自分で 動かせないと使えないかなと思
ったりするんですけど AIによって やっぱり手を動かすことが可能
になってきた現在 結構学びに投資 することができるなと思ってて
その辺とかは学ぶの好きなんで そこは活かしていきたいなと思います
番組の感想と今後の展望
おだしょー キュウソナさん 今日はありがとうございました
キュウソナ ありがとうございました
おだしょー まだまだお話しした いないので 次回もキュウソナさん
とお送りします ということで 今回はマネージメント
というか 課題をどう解決していく かみたいなところで いろいろお話
をできて 本当に楽しかったなと思 ってます 自分がぼんやり思った
これもあるあるな気がするんですけど マネージメントを人と答え合わせ
しづらいみたいな それ機会もない し 言いづらいみたいなのもあって
なかなか機会がなかったんですけど 今日 そこの自分が今ぼんやり考えて
いることとか 思ってたことってところ の ある意味の答え合わせじゃない
ですけど 似たようなことを考えて いらっしゃるキュウソナさんがいて
僕もちょっと自信がついたという か よかったなって
おだしょー お互い 答え合わせ ができて 楽しかったです
さて この番組では 感想や次回 ゲストへの質問 リクエストなど
お待ちしております 番組詳細欄 にはリンクあり お気軽にご投稿
ください Xではハッシュタグ聞いた FMをつけてポストしてください
表記は番組名と一緒でQFMが大文字 残りは小文字です そしてApple Podcast
やSpotifyのPodcastでは リビュー もできますので こちらにも感想
を書いてもらえると嬉しいです キータ株式会社はエンジニアを
最高に幸せにするというミッション のもと エンジニアに関する知識
を記録 共有するためのサービス キータ 社内向け情報共有サービス
キータチームを運営しています ぜひカタカナでキータと検索して
チェックしてみてください 来週も火曜日の朝6時に最新話
が更新されます 番組のフォロー して最新話もお聞きください
お相手はキータプロダクト開発部 部長の清野俊文と
C株式会社プロダクト本部長の森 久太郎 久曽那でした
