2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
まつもとゆきひろ×クルーズ対談(全1記事)
提供:クルーズ株式会社
リンクをコピー
記事をブックマーク
司会者:まずは、まつもとさんの簡単な経歴をよろしくお願いします。
まつもとゆきひろ氏(以下、まつもと):まつもとゆきひろと言います。プログラミング言語のRubyというのが世にあって、そいつを作ったのが私ということになります。大学を卒業して新卒でソフトウェア開発者、ソフトウェアエンジニアとして就職したのが1990年で、その時は、今でいうとSESという言い方をするんですかね、受託開発する会社に勤めていました。
私の同期が中堅規模のソフトウェアハウスで働いていたので、200人ぐらい同期がいたんですけど。その中で経験があるというかコンピューターサイエンスを専攻している人間が6人しかいなかったんですね。私はそのうちの1人だったので、そういう意味ではちょっと優遇してもらえました。他の人たちはプログラミング研修から始めるんですが、私たちはそれがいらないので。1ヶ月ぐらい社会人研修というのがありまして、電話の出方とか(笑)、そういうのが終わったあとに1ヶ月後に実戦配備みたいな感じで働いていました。
その受託開発会社にいたんですが、私が配属されたところは、社内システムというか、エンジニア側の生産性を高めるためのツールを開発するチームだったので、お客さんもいないし、無茶を言われることもありませんでした。かつ、わりと裁量権が大きくて、新卒であったにもかかわらず、どんなソフトウェアを作るかみたいなところから、あるいはどんなデザインにするかまで新卒が決められたので、わりと機嫌よく働いていたんです。
そうだったんですけど、いわゆるバブル崩壊というのがあって、景気が悪くなった部署は閉鎖になるしメンバーはバラバラになるし、大変なことになったんですけど(笑)。その時に、私は社内ツールを開発するチームのおもりをするだけの仕事になって(笑)。当時は26歳とかぐらいだったんですけど、いわゆる窓際族みたいになっちゃって。
暇な時に、もともとプログラミングはすごい好きだったので「いっちょやるか!」と言って作ったのがRubyだったという感じですね。それからは、普通に働きながらRubyの面倒を見るということをずっとしていたんですが、会社もちょっと景気が悪くなって怪しい感じになってきたので、転職したりしました。
トヨタの子会社でCADシステムを作りながらRubyを作るみたいなことをしていたんですが。そのあともう1回転職をし、2001年か2002年ぐらいからは、オープンソースソフトウェアであるRubyの開発をほぼ専業みたいなかたちでやっています。なので、1993年から作り始めて今年で29年、Rubyを副業だったり本業だったりで開発してきている感じになります。
その他にも、ここ10年近くになりますかね、いろいろな会社の技術顧問をしたりいろいろな人のお手伝いをしたりとか、会社のお手伝いをしたりして副業みたいな感じの収入ももらえるようになってきています。そんな感じのオープンソースソフトウェア開発者兼Rubyというソフトウェアのプロダクトマネージャー兼コミュニティリーダー兼技術顧問兼・・・なんかいっぱいという感じの働き方をしています。よろしくお願いします。
司会者:よろしくお願いします。では、どちらから質問しますか?
まつもと:いいですよ。何でも聞いてください。
山口顕二氏(以下、山口):Rubyの開発を働きながらやり始めたということだったんですが、本気でRubyを開発したいなと思ったのはなぜなんですか?
まつもと:私が最初にプログラミングを始めたのが、だいぶ早かったんですけど中学生の頃で。すごく昔なのでプログラミング環境が今に比べてずっとずっと貧弱だったんですね。そういう意味ですごくフラストレーションを感じたんです。
その中で、本などでプログラミングについて知識を得るうちに、世の中にはもっと良いプログラミング言語があって、プログラミング言語によってはもっと楽なプログラミングというか楽しいプログラミングがあるというのに気が付いて、それ以来すごく関心を持つようになったんですよ。手段と目的が入れ替わっているというのもあるんですけど(笑)。
私の同世代の人たちは、BASICでゲームを作る『マイコンBASICマガジン』という本があって、そこにゲームがあるので、それでゲームをやりたいのでプログラミングをはじめた人が、同世代とかの中でけっこう多いんですが。私自身はゲームをやるよりも、プログラミング言語について学んでいたほうがおもしろいなと。
わりと手段と目的が入れ替わるタイプの(笑)。本当はプログラミングを楽しくやりたいからプログラミング言語を学んでいるはずなのに、あるいはゲームをしたいからプログラミングを学んでいるはずなのに、途中のツールのほうがおもしろくなっちゃって(笑)。
(一同笑)
まつもと:言語がおもしろいなと。プログラミング言語は世の中にいっぱいあるけど、みんな誰かが意図を持って作っているんですよね。そしたら自分が作ってもいいんじゃないかなと思ったのが、高校生ぐらいの時だったんですよ。ですが1980年代というのは、インターネットがないんですよね。そうすると、情報がぜんぜん手に入らないんですよ。
今だと、例えば若い人のプログラミングコンテストの審査員みたいなことを頼まれたりすることがあって、そうすると高校生ぐらいが自分のプログラミング言語を作りました、と持ってくることがありまして。「すごいな」と思うんですが、当時の私はぜんぜんそんなところまで行けてなくて、いつか作れたらいいな、というふうに思ってたんですね。
そのあと大学に入って、コンピューターサイエンスを専攻して卒業して、職業プログラマーとして経験も積んで。だから最初に作りたいと思ってから10年ぐらい経って、時間もできたしスキルも上がったし経験値も得たし、窓際になって暇になったので、会社の目を盗んで「いっちょやるか!」と言ってやったのが、Rubyになったという感じなんですね。
だから、もともとプログラミング言語にはすごく関心があって、チャンスがあれば作りたいなと思っていたんですけど、いろいろな条件が整ってやれるとなったのが、1993年だったということですね。
山口:じゃあ長く自分で作りたいなという思いはチラッとあったと。
まつもと:そうなんですよ。妄想レベルだったので、夢見るだけだったんだけど(笑)。自分の能力がやっと追いついて、10年かかって(笑)。もちろん、その間はずっと作りたいと思っていたわけじゃなくて、無理かなと思っていた時期もけっこう長くあったんですが。だけど実際に働いたりしてプログラミングスキルとかも伸びてきたら、「これ、できるんじゃない?」と思って取りかかったのがRubyになった感じですね。
山口:なるほど!
館山遼氏(以下、館山):まつもとさんがこれまでエンジニアとしてやってきて、何か大きな失敗などされたことはあるんですか?
まつもと:失敗はいろいろあると言えばあるんですけど、一番ひどいなというのは、見積もりミスの失敗があって。正直いうと、僕がやったというよりは僕の部下がやったという感じなんですが、30代ぐらいに「まつもともちょっとマネージャーみたいなことをやってみない?」と言われて、2人チームで開発していたんですね。
だけど、私はマネージするだけでもう1人の人が開発するという局面だったので、1週間に2回ぐらいミーティングというか様子を聞きに行って「ちゃんと進んでる? 締め切りはいつだけど、進んでる?」と聞いていたんですが、「できてます」と言うんですね。そしたら締め切りの3週間ぐらい前になって「すみません、ぜんぜん間に合いそうにありません」と言われて(笑)。「それ、今言う?」と(笑)。
(一同笑)
たぶん、マネージャーというのは「できてます」と聞くだけじゃなくて、もうちょっと踏み込んでおくべきものだったかな、と。コンピューター関係が得意と言われている人がやりがちなんだけど、やはりコミュニケーションを面倒くさがるんですよね(笑)。だから「いい」と言っているからいいと。無関心というか、ちょっとダメなタイプの感じですよね。
それで、あとは開発するほうも「ちょっと思ったように進まなかったけど、今週もうちょっとがんばれば取り返せるや」というのがあったわけです(笑)。この2つが最悪な感じに噛み合って、蓋を開けたらぜんぜん間に合いませんでしたという感じに(笑)。客先のところに行って「すみません、なんかちょっとトラブルがあって間に合わなくて」と言いに行って(笑)。
(一同笑)
締め切りから1週間過ぎてもまだ開発しているという大変なことになったことがあって、これが最大の失敗と言えば最大の失敗ですね。あと他にもいくつかあるんですが、やはりだいたい見積もりが甘くて締め切りに間に合わなかったという一言で終わるような失敗ばかりですね。
館山:その経験以降、エンジニアとコミュニケーションを取る上で、何か変わったことや意識するようになったことってありますか?
まつもと:進捗管理型のマネジメントは受けないようにしようという。
(一同笑)
館山:受けないと(笑)。
まつもと:そもそもやらないと(笑)。リーダーシップを取ったりこういう方向性でみたいな感じのマネジメントだったりは僕でもやろうと思えばできるんだけど。やはり本能的に細かい進捗管理みたいなものは面倒くさがるんですよね。これはダメだと。もうちょっと得意な人にやってもらおうと思って、そういう仕事はそもそも「僕ね、ダメなんですよ」とか言って(笑)。年を取って、わがままを言えるようになっていたので(笑)、幸いというか不幸にもという感じなんだけど。
そうなんですよね。それはお客さんのいる仕事だったので、契約で締め切りが決まっていて面倒くさかったんですが、だんだん厳密な締め切りがない仕事が多くなった。例えばオープンソースの仕事の場合は、リリースの日は決まっているんだけど、その日にどの機能が間に合うか・入れるかみたいなものは、調整の余地があるわけじゃないですか。そうすると、スコープか時間かのどちらかをいじれる立場が多くなったので、そこまでクリティカルにはならない感じではありますね。
例えば自社サービスを作っているところとかはそうですよね。例えば〇月〇日にリリースしますということが決まっているけど、リリースのスコープは契約で取っている仕事ではなくて社内の話だから、調整の余地があるわけですよね。怒られそうだけど(笑)。でも、怒られるくらいで済みそうですよね。
でも〇月〇日までに〇〇のソフトウェアを納入しますという受託開発のような感じだと、そもそも契約で決まっているので、それをひっくり返すのはけっこう大変で……実際に大変だったんですけど(笑)。
そういうことがあるので、そういうのがないというか調整しましょう、みたいな感じですね。特に見積もりに関してはだいぶバッファを積んだり、締め切りがタイトな場合はバッファというかマージンというか、自分でいつまでにできると思っても、予想しない事態は常に発生するじゃないですか。割り込みが入ったり、集中していたのに電話がかかってきたので集中力がガタガタと落ちていきましたみたいなのがいくらでも発生するわけですよね。
そういうのも織り込むと、自分ができると思った時間よりもだいぶ長めに設定しておかないと、あとで痛い目にあうというのは経験としてあります。僕の経験、職業開発者として業務でバリバリソフトウェアを開発していた頃は、2倍から3倍ぐらい積んでいました。
「1週間でできるなと思った仕事は3週間と言っておけ」と。でもだいたいそれで行くんだよね。不思議なことにね。
(一同笑)
館山:クルーズでも、最近未経験からエンジニアに配属となって勉強したりする人がいるんですが、もし今からイチからプログラミングを勉強するとしたら、どう勉強していったら優秀なエンジニアになれますか?
まつもと:プログラミングをしていて、それが楽しいと思えるかどうかはだいぶ人によるんですよね。これが何かと相関みたいなのがあるかは未だに発見されていないんですよ。例えば数学が好きだからプログラミングが得意かというと、必ずしもそうではないし。では、サイエンスが好きだからプログラミングが得意かというと、必ずしもそうでもないし。
じゃあ「私は文系です」と言ったらプログラミングに向いていないかというと、ぜんぜんそんなことはないです。例えば大学を卒業していないとプログラマーに向いていないとか、そういうこともあまりないんですよね。今の社会では、プログラマーとして働いている人の多くは大卒ですが、では高卒がプログラマーになれないかというと、あるいは向いていないかというと、ぜんぜんそんなこともないわけですね。
そうすると、実際にプログラミングをしてみる以外の方法で、この人が事前にプログラマーに向いているかどうかはわからないんですよね、残念ながら。実際にプログラミングをしてみて、それが楽しかったと思える人は適性があるんじゃないかなと思うんですね。
逆にそれに対して「楽しくはないけどお金のためにやるんだ」という人は、やはり伸びないんですよね。「好きこそ物の上手なれ」ということわざもありますが、プログラミングを楽しいと感じられるかが適性なんじゃないかなと、私は今思っています。
館山:そうですね、確かに!
まつもと:どうやって学べばいいかという話なんですが、やはり自分の書いたコードの結果がすぐに見えるような状態で学んでいくのがいいんじゃないかなと思うんです。ソフトウェアによってはコードを書いても達成感がないというか、完成は2年先です、みたいなコードがよくあるわけですよね(笑)。
それはつらくて、かなり高いモチベーションを持っていないと、そういうソフト開発はつらいんですよ。だけど例えば、半完成品のようなのがあって、ちょっと書くとデザインが変わりました、パフォーマンスが変わりました、機能が増えましたみたいなことが、すごい短いサイクルで、可能であれば1日何回も回せるような環境だと、なんというか達成感がありますよね。
僕がこれをやったからこの機能が増えただったり、僕がこれをしたからデザインがよくなったり、ツールが使いやすくなったりなど、そういう「できた」という気持ちがあるじゃないですか。その気持ちというのは、より多く学びたいという気持ちにつながりそうな気がするんですよね。
他にも、スクールの中でいつ終わるかわからないような写経みたいなものをさせられて、100万行ぐらい写経してやっとシステムが動くみたいなのだと、達成感がないんですよね。それは、あまり良くないんじゃないかなと思っています。やはりちょっとやってちょっと動いて、ちょっとやってちょっと変わってというのを高速で繰り返していくことで、モチベーションが上げられるんじゃないかなとは思っています。
館山:確かに僕も最初にプログラミングをやった時は、HTMLとかで「あ」とか「い」とかが画面に映るだけでも達成感があったりしたので。
まつもと:「僕の打った『あ』がここに出た!」と思うんですよね。「この『あ』は他の誰でもない僕の打った『あ』だ!」とかに思うと達成感があるわけですよね。
館山:そうなんですよ!
まつもと:そうするともっと他の文章を入れたら「変わった!」という、そういう細かい繰り返しによる達成感が、モチベーションの源泉になりがちだと思うんですよね。その学び方は良いんじゃないかなと思います。
山口:達成感は僕も大事だなと思っています!僕も未経験で配属されてから開発したのが、新しい新規開発みたいなものだったんです。そうなると、完成までに時間がかかって、達成感を得る前に挫折することが多かったです。挫折をしない方法や挫折をした後に気持ちをどう整理したらいいか悩んだ時期があったので、同じ様な悩みを持った方へのアドバイスがあったらお聞きしたいです。
まつもと:そうですね。チームによるとしか言いようがないので、なかなか答えづらいんですけど。
(一同笑)
心理学で、達成感を覚える、あるいは生産性を高めるためには何が必要かという話をした時に、コントロール意識が必要だということを聞いたことがあるんですね。コントロール意識というのは、自分で決めることができる意識。言われるがままに開発をしていると、そこにコントロール意識がないわけですよ。
下手すると日本語で書いた仕様書があって、その仕様書に対して1行に対応するようなかたちで、CやRubyなど何でもいいんですけど、書き換えていって打ち込みました、以上テスト終わり、みたいな。そこには自分の判断というか決断の余地はあまりないですよね。どこにスペースを入れるかぐらいしかないんですよ(笑)。それがコーディングルールで決まっていたりすると、もう判断の予知はゼロ。
最初に日本語を打った人がそのままRubyで書けばいいじゃん、みたいなことを思ったりするわけですが、そういう働き方はモチベーションが上がりにくいんですよね。「こういうものを作りなさい」と言われてどう作ればいいんだろう、どういう変数の名前にしたらいいんだろう、どういうアルゴリズムを選んだらいいんだろうと決める余地が大きい場合は、責任もある一方で自分がコントロールというか制御したという意識が高まるのでモチベーションが上がりやすいんですって。
選択の余地が狭まってしまうと自発性を奪われるというんですかね、「言われるがままにしておけばいいや」みたいな感じになっちゃうんですよね(笑)。そうするとやる気も下がるし生産性も下がるし、という感じです。
なので、できるかどうかはチームによるから言えないんですけど、自分に任せられたものの中で自分が決めることのできる余地がある部分を見つける。あるいはできるだけ広げる。さらにいうと「良かった」探しじゃないですが、その中に楽しみというか楽しさを見出すみたいなことによって、モチベーションが上がってくるんじゃないかなと思いますね。
例えば僕の友達の中には、仕事としてもらった仕事なので好きなものを作るわけにはいかないですが、ループの回数を少なくしてパフォーマンスを上げるみたいな人がいます。「楽しい」と言いながらベンチマークを取るわけですよね(笑)。そういうかたちの、与えられた仕事の範囲内で楽しさを生み出すみたいなことができると、モチベーションが維持できると思うんですよね。
マネージャーではないので、自分でタスクを割り当てるわけにはいかないんですが、可能であれば相談をして裁量をどこまでできるかについてハッキリさせたり。今「相談」と言っちゃったけど、本当は言わないほうがいいんだよね。
(一同笑)
マネージャーは聞かれると、ダメとか言わなきゃいけないことがあって、「聞かないで勝手にやって」という感じはある(笑)。マネージャーも気持ちがわかるから止めたくはないんだけど、ルール上それをやっていいと言いづらいというのがあるので(笑)。本当は聞かないのが一番いいんだけど(笑)。
「きっと大丈夫」とか言う、なんだっけ。「許可を求めるな、謝罪せよ(Don’t ask for permission, beg for forgiveness)」みたいなことわざがあって、「やってもいいですか?」と言われるとマネージャーとしては「No」と言わざるを得ないところがあって。もちろん仕事はちゃんとしないといけないんだけど、仕事の範囲内でガーッとやっちゃって「お前なんでこんなことをやったんだ」となったら、「すみません、ちょっと……ごめんなさい」と言うほうがいいという話があって。
(一同笑)
それも含めて開発そのものに何らかの楽しみとコントロール意識を生み出せるとモチベーションが上がるんじゃないかなと思います。
山口:これから挑戦したいことがあったりしますか?
まつもと:新しいことに挑戦……。下手すると本当にみなさんのお父さん世代より上なので……。そうだね。1つは言語の周辺という言い方をしてきたんだけど、そこからちょっと出た辺りにも興味があるので、ちょっと勉強したいなと思っていて。例えばOSの部分であったり、あるいはOSに近いライブラリとして、例えばスレッドライブラリなど。あとはデータベースや、そのへんの中身についても興味があるので、少しずつ勉強したいなとは思っています。
山口:自分もエンジニアの経歴を重ねたときに、新しいことを勉強できるモチベーションがあるかというと、すごく不安なんですよね(笑)。
まつもと:どうなんでしょうね(笑)。私は本当は勉強したいなと言っていますが、したいなと言いつつ10年ぐらい経っているので、なかなかできていないんですけど(笑)。
館山:これからエンジニアを目指す方や、それこそ僕らのような1、2年目の方に向けて応援メッセージなどあれば教えてください。
まつもと:そうですね。ソフトウェア開発とその周辺の仕事は、伸びるためにどうしても適性みたいなものがいるみたいで、おもしろいと思える人とそうじゃない人がいるんですよね。なので途中でも話しましたが、どういう人がおもしろいと感じるのかは関連性がないんですけど、おもしろいと思える人にとっては天国みたいなところじゃないかなと。
つまり仕事をしていて楽しいし、お金をもらえるし、その収入も比較的全職種で見るとソフトウェア開発はけっこう高いほうだし。これがもっといってシニアとかになったりすると、けっこうな額になるわけですよね。さらに言うと海外との基準を考えると、海外とかだと、例えばシリコンバレーで大卒の新卒で日本円に直したら一千何百万円スタートも珍しくないことを考えれば、だいぶ夢があるという感じですよね(笑)。
館山:そうですね!夢がありますね!(笑)
まつもと:さらにいうと日本がどうかというのは置いておいて、海外のソフトウェアエンジニアはモテるんですよ。
館山:モテるんですね!(笑)
まつもと:モテるんですよ。そうなんですよ。海外のカンファレンスとか行くでしょ? そうするとエンジニアたちがカンファレンスにみんな集まってくるわけですけど。懇親会で出席者と話してると、カンファレンスのときにはいなかったパートナーを連れてくる人がいたりして。「どうしたの?」と聞いたら、カンファレンス後に1週間とかバカンス取るから連れてきたと。そんな人がけっこういるんです。優雅な暮らしだなとか思うんですけど(笑)。
話を聞いたら、ソフトウェア開発者は頭がいいし、考えることが好きだし、収入がいいし、ものすごい評価が高いんですね。だからモテると言うんですよ。「そうなのか」と(笑)。日本だと暗いとかモテないとか言われるんだけどと思うんだけど。そういう話は置いておいて(笑)。
そういう意味でいうと、ソフトウェア開発関連の仕事、もっと広いエンジニアと言ってもいいかもしれない、ITエンジニアという言い方をしてもいいかもしれないですが、(ITエンジニアは)先ほど言った良い条件がいっぱいある、夢のある職業だと思うんですね。さらに仕事も楽しいとなったら、すごく良い職だと思うんですよ。
ただ残念ながら、全員が全員それを楽しめるか。あるいは成功できるかというとそうでもないかもしれなくて。それでも、もしプログラミングに対してモチベーションが持てるという稀有な才能を持っているならば、ものすごくオススメの職業なんじゃないかなと私は思っています。
山口:最後に聞きたいことがあるんですが、海外だとITの人材がモテるとかキラキラしているという話だったんですが、日本では、IT人材は不足しているじゃないですか。そういった中で、優秀なエンジニアを確保したい企業はいっぱいあると思うんです。そういったエンジニアを採用するために、まつもとさん自身でもいいですし、組織として取り組むべきことというのを最後に聞きたいです。
まつもと:そうねー。ぶっちゃけちゃうと需要と供給の関係なので、給料を上げるのが一番いいんですけど(笑)。いろいろなしがらみがあって上げられないみたいなこともあるみたいですが、究極的には給料が第一になるんじゃないかなと思います。
それ以外にも、例えば情報発信みたいな感じで、エンジニアが例えば「クルーズではこんな仕事をしています」とか、こういう思いをしました、それはプラスでしたマイナスでしたというのを正直に発信していくことで、「じゃあクルーズだったら僕は安心して働けるな」と思えるようであれば、入りたいと思える人が増えるんじゃないかなとは思いますね。
僕が技術顧問をしている時に、他の企業も含めてリクルーティングに苦労していて。私が技術顧問をしている理由の1つも、そういうエンジニアの知的好奇心を満足する福利厚生みたいなところもあるので、そういうのも含めて、自分のところで働くと給料的には満足いくし、さらに住環境的にも満足できるし、あるいは究極的に人間関係は相性もあるから一概には言えないんですが、人間関係もいいしみたいな地道な情報発信が一番有効なんじゃないかなと思っていますね。
山口:すごく貴重なお話、ありがとうございました。
クルーズ株式会社
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05