設計の面白さの本質
日本最大級のエンジニアコミュニティ Qiita プロダクトマネージャーの
清野俊文です。この番組では、日本で活躍するエンジニアをゲスト
に向かい、キャリアやモチベーション の話を深掘りしながら、エンジニア
の皆さんに役立つ話題を発信して いきます。引き続きゲストは、ドメイン
駆動設計入門、ボトムアップで わかるドメイン駆動設計の基本の
調査、ナルセ・マサノブさんです。よろしくお願いします。
ナルセ・マサノブ よろしくお願いします。
清野 よろしくお願いします。ナルセさんとお送りする3回目のテーマは、
設計の面白さと学び方・教え方です。今回は設計メインでいろいろ
語っていきたいなと思っているので、よろしくお願いします。
ナルセ・マサノブ 緊張します。
清野 僕も設計大好きなので、いろいろお話していきたいです。
ナルセ・マサノブ 素晴らしいですね。
清野 最初お伺いしたいところが、設計の面白さについてなんですけど、
前回も設計を始めたきっかけとかいろいろお伺いしましたが、
改めて設計の何が面白いのかみたいなところをお伺いしてもいいですか。
ナルセ・マサノブ この質問、今設計的なところ何が好きなんだろうと聞かれるから
と思って、自分なりに言語化しておいたんですね。何が楽しいかというと、
やっぱり設計自体が、神秘感的な計画行為というのが設計と言われているんですね。
デザインというのがありますよね。設計と全く同じ言葉で使われますよね。
デザインって何かというと、美しさを意図的にやるというのが神秘的な計画なんですよね。
そこが非常に面白い。具体的に言うと、なんで美しいものがいいのかという話から入ってしまうんですけど、
わかりやすく言えば、美しいものは残るんですよ。美しいものは誰も壊したくないんですよ、基本的には。
だから美しさを設計に求めるのは非常に合理的なんですよね。
そういった美しいものをあえて壊そうとは思えないだろう。それに則って同じような美しいものを入れましょうと。
花束の中に急に謎の泥を投げ込む人はいないでしょう。花を添えたいでしょうという話だと思うんですよね。
なので設計に対しては、美しさというのが非常に重要なアプローチだと思っていて、
それを追求するのが非常に楽しいというのが私の一番面白いポイントです。
ですが伝わりづらいと思うので、わかりやすい方で言うと、自分の作戦がうまくいくと嬉しいですから。
設計の面白さの伝え方
ありがとうございます。
本当に神秘的なというところは僕もすごい共感を覚えていて、先ほど僕も設計好きというお話をしたんですけど、
コードって自分たちが書くもので、それが美しく書かれている。
かつ美しいものを自分でいろんな知識さえあれば作ることができるというのがやっぱりプログラミングの面白さだと思っていて、
プログラミングって正直タイピングさえできればできるじゃないですか。
どうしても芸術品ってそれをできるまでのテクニックというのをしっかり身につけていかないといけないと思うんですけど、
そもそも扱い方というところから。
本当にプログラミングってタイピングさえできれば誰でもできるものだと思っているので、
その中で美しさというのを追求できるというのがすごい面白いところでもあり、
まずいろんなレパートリーがあるというか型が1個に決まらないところがあるので、
そこが僕もすごい好きだなって思っていますね。
そうですね。
諸事情で僕今最近アートとかそこら辺を勉強する機会がありまして、
そうなんですね。
やっぱり僕が好きなのは説明できるものが結構好きなんですよね。
例えばプログラムの設計でコードが美しいという言葉がさっきありましたけど、
なんでそれが美しいのかって分かる人しか分からないんですよね。
でも分かる人には分かるということは説明できるんですよ。
これアートの世界も一緒で、後付けですけど説明できることっていっぱいあるんですね。
どうも偉大なアートと偉大なアートを比べるとこういうところが共通しているというのが出てくるんですよね。
おそらく我々がコードに対して美しさを感じているのは同じことを感じているんだと思うんですよね。
偉大なプロジェクトでこれのコードとこのコードに似ているな、その似ている理由は何なんだろう、
それって結局美しさに対するアプローチとかなり似ていて楽しいですよね。
イメージとして数学で公式を使うよりも公式の理屈が知りたい人とかは結構お勧めかなって感じがしますね。
ありがとうございます。
本当に設計の面白さってところが僕だけじゃない人もちゃんと感じてくれているんだなって今お話聞いて、
僕はちょっと安心したんですけど、
結構今日ご相談もちょっとしたいなと思ったんですけど、
僕は設計好きだから勉強しているんですけど、
なかなかみんながやっぱり好きなわけではないっていうのが僕は最近わかってきていて、
特にチームの中で設計力を身につけていこうねみたいな話はして勉強会とかもやったりするんですけど、
みんなやってはいるんですけど楽しんでやっているのかなっていうのがちょっと気になっちゃったりするんですよね。
なので設計の面白さっていうもの自体をどうやって人に伝えていく、
どうやってそこを実感してもらうかみたいなところも結構課題があるなと思っていて、
そういうところももしご経験とかあればお伺いしたいんですけど。
設計力の育成
そうですね。僕が今までいろんな人と関わった感じですけど、やっぱり向き不向きはありますね。
そもそもそんなどうでもよくないって人は絶対いるし、その気持ちもわかるんですよね。
例えば2個より3個の方が安定するとかそういう法則もあったりするんですよ。
アートの世界には。
今2個並べたものより3個並べた方が人間バランスよく見れるんですね。
どうでもいいじゃないですか人によっては。
どうでもいい世界の話で僕らは生きているので、なかなかやっぱり向き不向きっていうのがあって、
ただそのどうでもいいところに面白みを感じれる人がやっぱり向いているのかなっていうのが一つ目なんですよね。
たださっき言った数学の公式を使うよりも中身の理屈が知りたい人向きです。
なので面白さについて伝えるのであれば今みたいな説明ですかね。
公式使って何かプロダクト作るとかそういう話よりも、その公式がどうしてそう成り立っているのか、
そういう仕組みが気になる人にとっては非常に面白い分野だよ。
そこには今感覚でしかないかもしれないけど全部説明できるんだっていうところから、
心理学的アプローチが楽しいって思える人が増えるといいなとは思いますね。
ありがとうございます。
そもそも設計の面白さっていうものを感じれるか感じられないかっていうところはあるなというお話が今あったと思うんですけど、
その一方で設計ってみんなでやっていくものではあるじゃないですか。
一人が設計っていうところに取り組むとかアーキテクチャを導入すればそれだけでソフトウェアっていうのは全部それになるみたいな感じじゃなくて、
みんなで行動っていうのは書くものだと思うので、そこが関心がないなりに一緒にやっていくって必要もあると思っています。
そこら辺は関心ないメンバーにもそういうのにちゃんとやっていこうねっていうのを一緒に足並み揃えてやっていくために工夫していることとかもあります。
そういった意味で言うと興味がない人にあえてやらせようと僕は思っていないです。
そうなんですね。
例えばクリーンアーキテクチャの典型的な実装を使った時どういうふうにやったかっていうと、興味があるメンバーもいるもちろん興味ないメンバーもいるんですよ。
じゃあ彼らがうまく協業するにはどうすればいいだろうか。興味がない人たちは最低限こうしてくださいっていうレールを敷いてあげるんですね。
さっき言ったツールでここ書けばいいから。興味がある人はもちろんそのツール使わなくてもコード書いてみて読んでみると面白いよっていう話を伝えてあげて、
結局それぞれやりたいことは違うんで無理にやらせる必要はないかな。無理にやらなくても済むようなところ、最低限のラインをどこに引くかっていうのを僕はいつも考えてますね。
無理にやっても難しいんですよ。
そうですね。
そして設計とかアーキテクチャっていうもののもちろん全体的なプロダクトはみんなで作っていくものなんですけど、方針を決めるのは基本的には一人です。私がやってる限りですと。
なぜならば民主主義でやっても絶対にうまくいかないんですね。
そうなんですね。
だって同じ知識を持ってないから全員が。僕が見てる先と、きのさんが見てる先と全然違うところかもしれない。
今回は自分が責任を持ってプロダクトのアーキテクチャ、アーキテクトとして動きますっていうのが決まったのであれば、主導権は自分です。
もちろんみんなの意見が来ます。その上で例えば相手が来た否定意見が来て、それはいやでもそこはこういう意見でやろうと思ってるんだ。
でも君が言ってるこの面倒さっていうのはこう自分も今認識したからじゃあそれを何とかする術を用意するよっていうのが僕のアプローチの仕方なんですよね。
なるほど。
なので集団占領って言葉知ってます?集団が浅くオオンパカロって書くんですけど、人がいっぱい集まるとその中で出た意見の中で一番組みしやすいものが選ばれるんですね。
効果が出るかどうかは関わらず。本来であれば例えば6人いました。その1人がすごい偉大な専門家です。彼が言った意見は非常に達成が難しいです。
みんなが言いました。みんなが言った意見はすごく簡単です。じゃあどれ選ぶか。とりあえずこっちから出ていいんじゃない。簡単なほうが選ばれちゃうんですよね。
それを避けるためにリーダー、リード。僕リードってよく言うんですけど役割を添えてアーキテクトなりリードなりそういう人たちに決定権を持たせるんですかね。
前回言ったディスアグリアンドコミットって言葉は僕言ったと思うんですね。それがまさにその話で自分としては勝負できないけどでもチームにコミットしますっていうことがチームに求められるんですよね。
なのでコード自体はみんなで書くけど設計とか方針自体は誰か1人に握らせないとおそらく変な方向進んできます。
扇動を多くして船山登れでしたっけ。扇動を多くして船分解してどっか行っちゃいますよ。バラバラに分解しますよって話ですね。
ありがとうございます。本当に今聞いていて確かになっていうふうに思いました。特にそういうアーキテクトみたいなところはみんなで作るっていうよりもまずフレームをしっかりむしろ突破力ある人が作ってそれにみんなで乗っかっていくっていう方が動きとしてはやりやすいかなっていうふうに思うので。
そうですね。
そういうアプローチが必要なんだろうなって思いましたね。
なのでもしアーキテクトを目指す人がいたら誰よりもまずコードを書けることが必要です。自分が一番にいっぱい書けますと。誰よりも早く書いて誰よりも確かなコードを書きます。その上でみんながどういうふうに動くかっていう人の気持ちに敏感になっておくのが大事ですね。
その一方で設計について面白さを持っているメンバーもいたときにその子をうまく育てていこう。いろんなことを経験させてあげようってなったときにどういう育成の仕方をしますか。
なるほど。設計をやりたい。とりあえず一旦証明してもらわないといけないので何かしら小さなツールでもいいから本人が思っているアーキテクチャーなり何なりを実現してもらうっていうのをやってほしいですね。
なるほど。
設計力の習得と経験
その上でじゃあこういうふうにするといいよねっていう段階的に大きなものを一番最初に任せるんじゃなくてまず小さなもの本当にツールとかでいいと思うんですよ。
そういうところでやりたいことを書いてごらんとか別に家でやるでもいいよっていう感じでとにかくやりたいことを実現してもらう。
そうすると見えてくるやっぱり自分なりの課題って見えてくると思うんですよね。何もなくすんなりできたのはもうやらせればいいです。
逆に課題があるとか言うんであればじゃあ実際に僕もやってるのに一緒にやろうかって。
で、ちくいちじゃないですけど少しずつ本人にできる範囲を増やしていくっていうのをよくやりますかね。
結構人がどう育つかっていうのをよく見ているので前回ここまでやったから次回これやろうかなみたいな再開の振り方をよくしてますね。
そうなんですね。ちょっとずつやらせながらそこの行いを見てうまく育てていくってことですね。
そうですね。やっぱり結局アーキテクトみたいな立場になると人と一緒に動いて人よりも先に道を切り開く仕事が待ってるんですよね。
そのとき切り開いた道を信じてついてきてくれるかってその人の実力とみんなからの信頼なんですよね。
それを得るためにやっぱり確かな実力がないと難しいのでそこを鍛えてあげるってところをまずやっぱり第一にしますかね。
ありがとうございます。ちなみに設計っていうところの設計力いわゆる設計力っていうものを培っていく中で設計で本当に座学でいろんな例えばアーキテクチャもそうだしデザインパターンもそうだしいろんなものを学んでいく必要もあれば
それをうまく組み合わせて一個のソフトウェアを作っていく力も必要かなと思ってます。
インプットで数アウトプットなんでもそれは大事だと思うんですけどその細かい組み合わせってどうしても現場の中でしか学べないみたいなところもあるんじゃないかなと思うんですけど
そういうところはどうやって経験させてあげてたりしますか。
デザインパターンは難しいですよね。もうすでに興奮になっているものもありますからね。
イテレーターパターンとかそういった意味で言うとこれやったことあるやつだっていうのが試験に出てくるパターンですよね。
正直それぞれがどういった概念かっていうのは僕は後から知ったんですよね。
なんでこのコードをここに書くんだろうっていう言語化をしていくとこういうことか。
で自分なりに不願をしてから調べるともう書いてあるじゃないかっていうのが多いんですよ。
なので知識としては毎日予備知識を入れておきながら自分がコードを書いている時になんでここに書いてるんだろう。
あれ自分が知っている法則なのかなっていうのを意識するんですよね。
その法則がないのであればちょっと調べてみようかなっていうところに立ち返ってみるとショートカットできそうな気がしますね。
僕は全部自分で言語化してからそれ探しに行くんでちょっと効率悪いんですけど。
効率悪いなりに破滞金はすごく大きいですね。
コードを書くっていうのもそうですけどコードを読むっていうこと自体も大事ってことですね。
そうですねOSSのコードを書いてなんでここに書いてるんだろう。俺の主義と違うなって思ったらその理由を考えるんですよね。
OSSみたいに人の手がいっぱい入っているコードってやっぱり機能美が結構追求されているんで
そこに書いた方が誰かに伝わりやすいから書いてあるとかそういう理由があるのでそれを思い馳せるんですね。
なんでここに書いてるんだろうって。
もちろん自分がコードを書いた時もそれは言語化していくんですけど
結果的に何とかの法則とかに合ってたりするんじゃないかなってパターンが多いかなと思います。
あとは法則で言うとやっぱり論文を読んだ方が元の意味がわかるかもしれないですね。
結構違約されてしまって伝えたいことは伝わってないパターンとかよくあるんで
依存関係逆転の原則とか。
あそこら辺実は逆転するのが皆さん矢印じゃないですよっていうところを言いたかったりするんですよ。
趣旨ですよね。そういったところの誤解が踏まえたりするんで
この本なんか読まずに論文読んでくださいってことですよね。
読んじゃねえよ。
どちらも読んでいただくのが大事だと思います。
本当に設計って僕は好きで結構一時期夢中でばーって勉強して
今ある程度人に説明するぐらいはできるようになってきたかなって感じの感覚はあるんですけど
ナルセさんの体感的に設計ができるようになるまでどんぐらい時間がかかったりすると思いますか。
どんぐらいかかったか。
一つのプロダクトに関して設計できると言い張れるようになったかなと思うのは
おそらく5年ぐらいだと思います。
その頃にちょうどアーキテクチャをチームに取り入れようとかそういうことができるようになった。
トレンド変わるからそれで終わりではないんですけど
5年もすれば並大抵のことはできるし
ずっとそこについて考えたから全部説明できるかなっていうのがあります。
今はアーキテクチャっていうのが一つのプロダクトじゃなくて
写真撮影と神秘的アプローチ
僕組織レベルになってるんでそこにたどり着いたのは10年ぐらい経ってからですかね。
この大きな組織がこっちに進みたいです。
じゃあそこに対して設計アーキテクチャ設計を敷いて
要するに神秘的な計画行為をするっていうところでどうすればあそこに行けるだろうか
っていうのができるようになったのが多分10年ぐらいかかってる気がしますね。
やっぱりそんだけ時間がかかるってことですね。
でもそれはもちろん時間がかかるのはかかるんですけど
自分の知識よりも手札が増えた感じもしますね。
いろんな人とのコネクションだとか
それこそ業界の仲間の意見とかそういうのも吸収して
自分だけの知識じゃないんですよねおそらくね。
もしかしたらそういうものがないともっと時間がかかるかもしれないし
周りにそういう人たちがいっぱいいる運のいい状況であれば持っていけるかもしれないと。
最近なるせさんが設計分野だけじゃなくても全然いいんですけど
キャッチアップしていることとか
インプットしているものってどういうものがあるんですか。
いいんですか。
ここから50分喋っていいですか。
一応ね今回も持ってきたんですよ。
そうなんですね。
カメラ。
カメラ、写真です。
きっかけは学生支援で僕学生にセミナーとか開いて無料で
会社のエキスパート制度っていうのがあって予算があって
地方に行ったりしてセミナー開いたんですね。
それで動画撮ってプレゼントしようっていうきっかけがあったんですよ。
でGoProをやったんですけどGoProだと熱暴走するんで
じゃあちゃんとしたカメラ買おうって買ったんですね。
で撮ってみたらハマり始めました。
なぜかわかります。
今日ヒントが出てますよ。
いわゆるアート的な面白さがある。
そうそうデザインと同じで神秘的アプローチができるんですよ。
なぜその写真が美しいのかっていうのは
完全に僕が設計で楽しんでる部分と同じことなんですよね。
この写真が美しい理由はこれこれこういう類です。
さっき言った3という数字が綺麗なんだっていうのは
なんでなの人が安定を求めるからなんですよね。
例えば正三角形と逆の三角形だったら
正三角形の方が安定してると思いません?
地面に向かって。
そういったところの神秘的アプローチ。
常に僕は設計という行為を常にやっていたせいで
AI技術とChatGPTの進化
美しさの虜なんですよね。
神秘的なアプローチがしたくてたまらない。
それが僕が生きる理由になってるんです。
でカメラやったら
神秘的アプローチできるじゃないですか。
そこにちょっと偶然が生まれて
さらに面白いものになるっていうんで
ちょっと写真がむちゃくちゃ面白くなってしまった。
そうなんですね。
実は僕も結構カメラとか写真撮るの好きで。
そうなんですか。
そうなんですよ。
一緒に写真見ながら
これがこういう例とかやります?
ぜひ。
最近インスタも始めたりします。
僕と一番無関係だと思った
SNSのインスタを始めたりだとか
あとカンファレンスでカメラマンやったりとかしてます。
そうなんですね。
この間もPHPカンファレンス香川で
写真撮ったりして
提供したりしてますね。
そういった意味でいうと
この間仕事で写真やったんですよ。
会社の仕事で。
そうなんですね。
誰かのインタビュー記事作るから
撮ってきてくれって言われて
たまたま九州行くから
いいよ撮ってきてあげるよって言って
ストロボとか持ち込んで
カメラマンとして行くから
そうです。
機材だけはプロ顔負けなんで。
そうなんですね。
なのでみなさん
設計とかやるんだったら写真おすすめです。
設計を始めるなら
今からヨドバシカメラさんに行きましょう。
今インプットの話もありましたけど
逆にこういうことやっていきたい
みたいなものってありますか?
それはプロカメラマンとして
体制したいんですけど
それは別としてやっていきたいことは
今自分のコンフォートゾーンから
抜け始めてるんで
もうやり始めてるんですけど
技術顧問とか
今グループ会社ですけど
そこでやっていって
自分たちの知らないところで
自分が知ってる知識を
もう一度授けることによって
再現性を取ってみたいな
っていうのはやったりしてますかね。
やりたいと思ったら
もうやっているという
有名な漫画の
各議員にありますけど
まさにそれかなと思います。
あとはずっと詰められているのが
ナルスさんいつになったら
本が書けるんですか?
っていうふうに
編集に詰められているので
頑張らなきゃいけませんね。
本当に次回作も
すごい今から楽しみにしています。
3冊ぐらい書きたいんですけどね。
気持ちは強いんですけどね。
番組ではリスナーの皆さんにも
参加してより楽しんでいただけるよう
ゲストに質問したいことを
番組詳細欄にあるフォームにて
事前に募集しています。
採用されたご質問は
番組内で紹介し
直接ゲストの方にお答えいただきます。
では早速リスナーネーム
ジョニーさんからのご質問です。
設計について相談する相手として
ChatGPTのような
生成AIを活用することについて
どう思いますか?
やめておいた方がいい
orどんどん活用すべき
などっていうのは来ています。
どう思いますか?
そうですね。
今段階でいいですか?
将来のChatGPTくんが
どうなるか分からないので
今段階で言うと
新しい概念を調べるときの
一意見として受け止めるんだったら
ポジティブかなと思います。
それ以外にも
さまりしてもらう
例えば
依存関係逆転の原則ってどうなの?
って聞いて
設計の問題解決
さまりもらってから
調べに行くっていうところの
事前予備知識
OLにはかなり向いてるかなと思います。
逆に向いてないなって思うのが
正解を求めるのが難しい。
依存関係逆転の原則って
どういうものですか?って聞いたら
ChatGPTなり生成AIが作ってくれた答えを
これが正解だと言い張るのは
非常に難しいものがあるかなと思います。
というのもやっぱり
それらしい言葉を並べるのが得意なので
それらしい言葉で
煙にまかれるときが多いんですよね。
本来やりたいことが
論文に書いてあるような
これがこういう目的でこうなんだとか
そういった意見がもらえなかったり
あとは説明としては
あまり良くない説明を
されるときもあったりするんですよね。
それは正解分かってる方だったら
正すことはできるんですけど
正解っていうのは
最もらしい自分なりの答えがある人にとっては
いやそれ違うだろうって
問いかけることができるんですけど
まっさるな皆さんの赤ちゃんのような
まっさるな心で聞いた言葉で
何も質問できないですよね。
そんな感じですと非常に難しい
何なら誤解が得て
あまり良いことにならない
結果として悪くなってしまうことが
多そうだなというのが意見ですかね。
生成AIは。
AIの活用と教え方
ありがとうございます。
本当に特に設計ってやっぱり
これさえやっておけばいいみたいな
銀の弾丸みたいのがあるものではなくて
やっぱ最終的に決めの問題というか
どういういろんなアプローチがある中で
これでいこうっていうのは最後やっぱ
気持ちで選んでいく必要が
ある側面もあると思うので
そこはやっぱり人がやっていく必要が
まだありそうって感じですかね。
結局ソフトウェア開発の世界って
僕がよくいろんな現場で
自分でかっこいいと思って言ってるんですけど
人の要素が強いんですよね。
コストって大部分が人件費なんですよね。
その人のことを無視して
原則を当てはめるってことは
多分できないんですよね。
設計とかアーキテクチャーっていうものは
基本的に相対的なものなので
答えが出てこないかったりするんですよね。
原則ってどうなのとか
そういうのを相談するのはいいんですけど
あと設計についても
課題が明確に分かってるんだったら
何かあるかっていう
意見を出してもらうとかだったら
多分使えるかな。
これこれこういう課題があって
こうなんだけど
コードはこんなもんで
どうすればいいと思う?
って言うと
チャットGBTがいい感じの意見
多分5個ぐらい案を送れって言ったら
5個ぐらい並べてくれるんですよね。
それを参考にするとか
あとよく分かりづらい
この設計の原則とかって
実装してくれよって
投げれば実装してくれたりするんで
そういうところで使っていただくと
いいかなと思います。
ありがとうございます。
ナルセさん3回にわたりありがとうございました。
何か最後にお知らせなどあったらお願いします。
もう私からのお知らせで言うと
写真始めました。
インスタ始めました。
皆さんインスタフォローしてください
という冗談みたいなのもありますけど
それとは別で
普段学生の支援とかもしたりしてるんで
もしそういったところで
無償でセミナーとか用意してますので
必要であれば
大学でも学生でもいただけたら
相談に乗りますっていうのがあります。
ぐらいですかね。
ありがとうございます。
ナルセさん本当にありがとうございました。
ご協力ありがとうございました。
また機会あればお待ちしております。
ぜひ。
ありがとうございました。
ということで今回は
設計についていろいろお伺いしてきました。
僕自身も日々業務やってる中で
いろいろモヤモヤするポイントがあって
誰にも今まであまり相談できなかったんですけど
今日ナルセさんに
そこら辺をご相談することができて
本当にありがとうございました。
すごい勉強になりました。
よかったです。
さてこの番組では
関数や次回ゲストへの質問
リクエストなどお待ちしております。
番組詳細欄にあるリンクより
お気軽にご投稿ください。
XではハッシュタグKiitaFMを付けて
ポストしてください。
表記は番組名と一緒で
QFMが大文字残りは小文字です。
そしてApple Podcastや
SpotifyのPodcastでは
レビューもできますので
こちらにも感想を書いてもらえると嬉しいです。
Kiita株式会社は
エンジニアを最高に幸せにする
というミッションのもと
エンジニアに関する知識を記録
共有するためのサービスKiita
社内向け情報共有サービス
Kiitaチームを運営しています。
ぜひカタカナでKiitaと検索して
チェックしてみてください。
来週も火曜日の朝6時に
最新話が更新されます。
番組のフォローをして
最新話もお聞きください。
お相手はKiitaプロダクトマネージャーの
木岡の俊文と
なるせいまさのぶでした。
