プロダクトとお金の関係性
お金を払ってもらうとはどういうことかっていう記事がちょっと話題になってたので、これについて話そうと思います。よろしくお願いします。
よろしくお願いします。
これはですね、プロダクトマネージャーの方が書いてくださった、会社とかでプロダクトを作るときに、
こう、どのようにしたらそのプロダクトが受け入れられてお金を払ってもらえるかっていうことについて書いたというか、それについての思考を深掘った記事になりますね。
いつもの通り、放送の概要欄に記事のリンクを貼っておくので、ぜひ読みながら聞いてみてくださいって感じです。
いい記事ですね。
そう、めちゃくちゃいい記事ですね。これは、紙なしでプロダクトマネージャーをやっていらっしゃる吉岡志織さんが書いてくださった記事ですね、1月の末に。
その紙なしでプロダクトマネジメントをする中で、ちゃんとプロダクトを成功させるためにお金を支払ってもらうっていうことについて向き合って、
そもそもプロダクトが成功するってどういうものなのかとか、お金を払ってもらうってそもそもどういうことが裏でユーザーさんとプロダクトの間に起きているのかとかいうのについて書いてくださった記事ですね。
僕はこれを読んで思ったのは単純にいい記事だなって思ったし、やっぱりプロダクトを作るっていうことだと僕はエンジニアとしていつも開発をしているんですけど、
個人開発をひも付けて考えてもやっぱりすごい学びが多い記事だなと思って、個人開発でプロダクトを作っていても、もちろんそのプロダクトが人に受け入れられなきゃいけないんですけど、
なんかよくあるのは友達に見せて、すごいいいじゃん使ってみたいって言われたけれども、まあ別に実際に出してみるとそのユーザー増えないみたいなのがあると思ってて、
それは記事の中にも出てくるプロダクト選択フィットだったなと思って、僕はなんかそうやって開発しているときにそのプロダクト選択フィットをこう間違ったゴールとして捉えちゃったのでその先に行けなかったんですけど、本当はそれはゴールではなくてちゃんとその先にちゃんと知らない人がお金を払ってくれるのかみたいなものが最初のコミュニティスペクティセンだったんだなぁと思いながらも読んで、
まあいろいろ思うところがあったわけなんですけれども、お二人はちょっと読んでみてどうでしたかこれ。
MVPとMSPの違い
そうですねえっと私はまず共感しかなくて、でもうたまたまねドンピシャで私あの違う記事にえっと概要欄に入らせていただく、えっとプロダクトマネージャーという仕事という記事を貼らせていただいてんですけど、
この記事に書いてあるPDMワークショップっていうものにデザイナーとして、ちょっと今デザインの仕事してるからデザイナーとして参加させてもらってるんですよ、でそこで何か言われてるのがそのMSP、ミニマムセーラブルプロダクト、販売可能な最小限のプロダクト。
販売可能な、初めて聞いた。
そう、それを確定させることの重要さとかが語られてて、その絶対に売れるっていうところをまず仮説検証して、仮説検証しまくって、そこをまず探し求めて、そこにピンした上で可能な限り削ぎ落とすっていうのをやるのね。
で、何か、その時の研修のお話で言うと、ウォークマンって昔、録音機能が必ず入っててんですよ。
若い人が聞いてる、ウォークマンわかんないかもしれない。
ウォークマンの世代じゃないって。
ウォークマンというCDを入れて、高機能な音楽プレイヤーですね。CDを入れて聴くタイプの高機能、その当時高機能だった音楽プレイヤーがあって、後発でiPodっていう音楽プレイヤーが出てきたんですよ。
で、ウォークマンには必ず録音機能が入ってて、もう当たり前のように音楽プレイヤーには録音機能が備わっているっていう時代があったんですよ。
全然知らないわ。
その当時はね。だけど、iPodまだ無名だった頃のAppleが録音機能っていうのを削ぎ落としたんですよ。
で、この音楽プレイヤーはCDとかを入れるので必ずその一つのプレイヤーで1000曲音楽を持ち歩けるっていうコンセプトで売ったのね。もう最小限そこだけを売るポイントとして売り続けたら、もう誰もウォークマンを持たなくなった。
そんなCDをね、何枚も持っていかなきゃいけないから。っていう過去があったんですよ。ウォークマンも今はほぼほぼiPodに近い形になっているけど。
これって自分たちがこのプロダクトのどこのポイントを最も売っていくか。つまりこの記事に書いてあった、機能は捨てるが体験は妥協しないっていうポイントのところに紐づいてるなって思ってて。
最も戦うデッキところに対しての当たり前品質をすごく大事にして、機能たくさんあるだけじゃなくて、そこの体験で勝負するっていう。これめっちゃいいなって思いましたし。
最近、違う会社のエンジニアと話してて、セールスの話とかもしててちょうど。2B系のSaaSって、わりかしユーザーが比較して、この機能がある、なしで、ぺけとか丸とかつけて比較したり、お金で比較したりして、検討したりするんだけど。
そのとある会社が、丸の部分で戦ってて、ぺけの少なさは自分たちの強みじゃないみたいな。
ないことは別にマイナスにはならない。
ぺけの部分に注目して、どんどんどんどん機能を足していくっていう戦略じゃなくて、丸の部分をとにかくとにかく強いものにしていくっていう売り方をしてて。
それすごい素敵だなって思って、この記事に書いてあることもそれに近い部分があるなと思ってて。
それに気づくためには、たくさんたくさん商談とかの場でお客様に会って、自分たちが思っていることが本当にお客様に求められていることかっていうところを、どんどんどんどん仮説検証していく必要があるんだよね。
っていうのを最近ものすごく考えてたりしていますので、めちゃくちゃドンピシャでいい記事ですね。
しかも私、商談の場とかにもわりかし同席させてもらったりとかしてて、すごいいろいろ感じる、この記事に対していろいろ感じることがありますね。
なんかさ、MVPと何が違うんすか、MSPって。すげえ似てるなと思って。ミニマムビアブルプロダクトか、MVPは。
しかしと思うんだけど、それってMVPってとりあえずお金、多分お金というよりかは顧客のフィードバック。
お金を払ってもらうかじゃなくて、出してフィードバックを得るものだと思っていて、ニーズを満たしているかみたいな。
それをより売ることにフォーカスした用語なのかなって私は思っているけど、どうかな。
ただそれにお比較は私ちょっとわかってないかも。
今調べて出てきた海外の記事とかだと、MVPとMSP似てるけど、MVPは特定の問題を解決できる最小限の価値があるプロダクトを言っているんですけれども、
ただMVPはそれ自体がお客様がそれを買うっていうことは意味しない。
MVPよりMSPの方がもうちょっと、本当にお金が得られるかどうか2章で当ててる気がしますね。
お客の問題解決はMVPで最小限の問題解決ができるかもしれないんですけれども、
2B/SaaSビジネスの複雑さ
最小限の問題解決ができた上で本当に売れるか、売れる最小限の構成がMSPなのかなと今読んだ記事で思いました。
確かに確かに。
そうか、だからこのソンタクフィットのところで書いてある欲しいと言った使う約束をしたみたいなところまではMVPとかで検証してみたいな感じだけど、
そこから先のお金を払う約束、お金を払ったみたいなところがMSPとかって話なのかな、このプロダクトソンタクフィットの図でいうと。
そのお金をちゃんと、確かにそうですよね。
なんか単純に他との比較を知る必要がないのであればMVPだけ考えて開発してればいいけど、
実際問題、どうやって継続して会社としてビジネスとして開発していくってなると他の競合に勝った上で、
ユーザーが他のプロダクトと比較した上で選ばれてお金を払ってくれるっていうところまで行かないといけないから、
なんかMVPは確かに僕もよく聞いてて、MSPは今日まで聞いたことなかったんですけど、
何か新しいものを作るってなった時にお金のことをちゃんと含めてMSPになってるかどうかについて注意しながら開発進めていくのは、
なんかその後のビジネスの展開する上でもめちゃくちゃ大事だなと思って、
MVPだけ意識してたら、プロダクトだけ見ればいいんじゃないってなるかもしれないけど、
実際それが生き延びれるかどうかって確かに別次元の話だなって思うので、
確かにこのMSPって大事だなって思った。
そうだね、なんかすごいそれ参考になったな。
自分は今これからまさにプロダクトを作ろうとしてるから、
まさにそのMVPはすごい考えてたけど、何が最小限の機能で、どこを機能として押していくのかみたいなのをすごい考えてたけど、
じゃあそれをどう販売していくか、セレクションを落とし込んでいくかみたいなところはあんまり意識いってなかったから、
結構エンジニアありがちかもしれないけど、作る方に意識いっちゃって、売る方に意識で。
いやー、そうそうそう。
ありがち。
ありがちだし、だからこそエンジニアも商談に同席すべきだと思ってて、
で、そういう声も結構2bSUS系の記事でよく見かけるんだけど、
実際にお客様の声から遠くにいるんだよね、エンジニアって。
まあね、そうだね。
あんまりそれをPDMとか商談するセールスの人が吸い上げて、それをエンジニアに生の声ではなく伝えるっていうことが多くて、
このお金の面とかその生の声とかが、割りかちいい部分が切り落とされて伝わってきてるなって感触が最近商談、
同席することが多くなって感じていて、
実感としてそういうのあるんですね。
めちゃくちゃある。全員行けばいいと思ってるし、
全員行けばいい。
マジで全員ローテーションして一人ずつ同席した方がいい。
うんうんうん。
もうそのレベル。
そんな違うんだ。
絶対成果に繋がると思う。
全然違う。
だって商談ってやっぱり表情も見れたりとか、どういうテンション感で語られてるかとか、
それをただテキストでこういうことをおっしゃってましたって言われるのと、
お客さんがどう感触を得ててどういう表情になったかみたいなのが見れないから、
作ってる側としてどういう価値提供が、
セールスとして売るものとしてちゃんとどう伝わってるかみたいなところって見れてないんですよ。
うんうんうん。
事業が。
そうだね。確かに確かに。
やっぱ結構2B札系のプロダクトは言われますね。
お客様への商談に同席すべきみたいなのは。
なんか書いてあるけど、ここにも書いてあるけどさ、
2Cでも同じような考え方はできると思うんだけどさ、
やっぱ2Bの方がシビアっていうこともこの記事の中には書いてあって。
そう思う。
2Cだと使う人自身に決算の決定権があるみたいな感じだけど、
2Bだと実際に使う人とお金を払うかどうかを決める人って違うことが多いから、
そうだね。
実際にその投資対効果をちゃんと説明できるためのロジックとかっていうのが必要になってくる。
ロジカルに説明できることが必要になってくるというふうに言われてて、
そこら辺も含めて考えると確かに2Bの方がよりシビアというか、
自分で何となく、ユーザーが何となくお金払ってもいいかなって感じで払ってくれるよりも、
もうちょっとさらにハードルが高いのかなと思ってお金を得るところに行ったりとか。
それも、その感触も商談に同席して感じる。
やっぱり営業の力であったりとか、
それこそ多分ね、カスタマーサポートの人とも一緒に仕事したほうがいいと思って、
その後導入後のフォロー体制とかどうなってるかとか、
そういうところも含めてプロダクトってここにも書いてあったと思うんだけど、
マジでそれは実感するんですよね。
だからエンジニアが作ってるものだけで戦うものではない。
例えば、自然流入して使ってくれて、
それでCVしてお金が入るっていう場合だと、
そこの提携先とかはあるかもしれないけど、
そのお客様と接点としては結構薄いものにはなっちゃうんだよね。
けど2Bサースってこれからも使い続けるために、
毎月毎月お金を払ってもらって、
その導入とかサポート費用とかも払ってもらった上で使い続けてもらうものになるから、
マジで接点多いし、
本当にプロダクトイコールものだけではないっていうのはめちゃくちゃ響くし、
だからこそ、
セールスが感じていること、CSが感じていること、
プロダクト開発の重要性
作る側が感じていることって結構認識揃えなきゃ、
売りたいと思っているものと完成物が違うとか、
そういうことが起き売った時に、お客様に迷惑をかけちゃうんだよ。
そういうところも、社内連携大事って書いてあるところも、
なんかどっかにあったような気がするけど、
全員が全員、ちゃんとプロダクトを主語で語れるようになっていないといけないなっていうのは本当に実感する。
プロダクト、ユーザー、お客さんを主語かな。
お客さんとプロダクト、プロダクト、ちょっとわかんなくなってきたけど。
プロダクトイコールものだけではないみたいなところと近いですよね、記事の中だと。
実際のソフトウェアだけじゃなくて、商談自体の体験もそうだし、
その後のセールスとかサポートもカスタマーサポートも含めて一つのプロダクトなので、
それを意識していかないとちょっとズレが感じる。
特にエンジニアだとやっぱり、ソフトウェア自体だけでなんか完結しているような気分にもなっちゃうし、
なんとなくやっぱ人それぞれだと思うんですけど、ソフトウェア開発しているエンジニアがいなければ全て成り立たないから、
一番偉いぜみたいな気持ちがちょっとうっすらあったりとかなかったりとかあると思うんですけど、
完全に間違いではないとはいつもとはいえ、商談とかそういうサポートとかっていうのがないと、
そもそもソフトウェアは使ってくれないっていうのは、いろんなプロダクトであると思うので、
そこら辺認識しておかなきゃという感じですよね。
でもね、そうだよなと思いつつ、エンジニアとしてはやっぱりプロダクト自体の完成度が高いものが人気出てほしいし、
売れてほしいなみたいな感じは常々あるんだけど、
それは大事。その上で成り立つ。パラメータに近いものがあるような気がしてて、
CSの力、エンジニアの製品のクオリティの高さとか安全性とか信頼性とか、
と整列の関係構築とか、それがどれが欠けたとしても結構マイナスには働いちゃうから、
組み合わせで総合力で勝つというか、
ポケットなモンスター的な感じで、一つのパラメータが全ての強さを決めるんじゃなくて、
体力、攻撃力、防御力、特攻、特防、素早さ、技の種類とかいろいろあるけど、
それを組み合わせた上で結果として勝利があるのであって、何か一つのパラメータだけで勝利が決まっているわけではない。
だからこそ、確かにエンジニアしかできないこと、セールスにしかできないこととかそれぞれあると思うんだけど、
それぞれ作っている会社、人によってそのパラメータがどれだけ高いかってそれぞれだと思うし、
プロダクトにおいてもどこを武器として戦うかっていうのもそれぞれじゃないと、
マーケットとしてなんでその製品を選ぶのかみたいな話になってくると思うから、
そういうところの戦略性みたいなところは、やっぱ売っていくっていう意味合いでも大事だなとはめっちゃ思う。
っていうのは最近本当にひしひしと実感しますね。
仮説検証の価値
チーズにめちゃくちゃ刺さる記事っていうね。
めっちゃ熱入っちゃった。
俺もあと数ヶ月くらいしたらめっちゃ刺さってくるかもしれない。
俺なんかこの記事読んだときに鍋ちゃんに刺さるだろうなと僕は思ってたんですよ。
それこそプロダクト選択フィットのあたりの話とかって、
普通に会社をやるにしても、例えばそれが個人開発だったとしても最初人に見せるじゃないですか。
まず最初知り合いに相談して見せるで、
ちゃんとプロダクト自体の質が良ければ、いいじゃんすごい、これリリースしたら買うわみたいなこと言ってくれるとは思うんだけど、
多分なんかそこのフェーズで結構感触良かったけどその後市場に出したら、
なんか思ったより受けが悪くてお金取れないなっていうフェーズは何にせよあると思ってて。
そこら辺の話が書いてるからすごい鍋ちゃん、最近起業してプロダクトこれから作って、
やっぱこれから作ったプロトタイプを人に見せてビルバックを得てっていう面があると思うので、
そういうところで鍋ちゃんに刺さるのかなと思ってこの記事をちょっと読んでたんですよね。
そうだね、将来的には刺さりそうで今の時点で知って良かったなっていう感じかな。
じゃあ今別に全然刺さってないですよと。
そういうわけじゃないけども、これからこういうのめっちゃ多分通貫するときあるなっていう感じかな。
なんか結構こういう訂正的なリサーチって多分今後プロダクト01やる上でめちゃくちゃ鍋ちゃんやっていくと思うんだけど、
さっき言ったところのミニマムセーラブルプロダクトだけ、MSPの部分もそうだし、
リサーチの仕方もめちゃくちゃ工夫する必要があるかなと思ってて。
何を、どこをちゃんと検証したいかのところがブレがちだから検証する上で、
かつそのリサーチの仕方、聞き方によってもお客様はいしか言えない状態になったりとかもするから、
そこらへん01やる上では結構学ぶ価値のある、いわゆる仮説検証とかUXリサーチの分野って学ぶ価値がある領域だなってすごい思うから、
ぜひぜひいろいろ試してみてほしいです。
そうだね、たぶんね、もう少しこれが数ヶ月後になってくると実体験を持ってめちゃくちゃ語れるようになるんで、
マーケティングとの関連
より深い話ができると思っている。
その時にまたその話聞きたいですね。
リサーチもね、一時私はUXリサーチャー的なものを目指してた時があって、
なかなかユーザーに思うように情報を引き出せなかったなって、確かにいいって言ってもらえたけど、
何がそんなに良かったのかみたいなところとか、結果そのプロダクト改善するための情報が得られなかったなっていうことが結構あって、
それって仮説検証としては失敗なんですよ。
仮説検証をするっていう上で一番大事なのは、
どれだけお客様から声を引き上げて、自分に対して、自分プロダクトに対してお土産がもらえるか、
いいって言ってもらえたんじゃなくて、
ここのポイントに一番初心が刺さっていて、お客様はここに感動していて、その感動していた部分がなぜなのか、
どういう体験、どういう課題を持って、どういう体験があって、そのEが出てきたのかとか、
なんか不服に思ってそうだけど、それがどこのポイントが、どういう背景、どういう体験から、
どういう課題感を感じていて、その感情になったのか、そのフィードバックになったのかっていうところを深掘る能力。
めちゃくちゃ大事だなって、いろいろ実感してますね。
それを引き出すために、どういう問いかけをお客さんにすべきかみたいなところであったりとか、
そこを臨機応変にできる力が、そういうお客様にプロダクトを見せるっていう立場になったら、めっちゃ大事だと思う。
ここで、オムロンエキスパートエンジニアリングからのお知らせです。
オムロンエキスパートエンジニアリングは、オムロングループの強みを生かし、プロフェッショナリティの高い正社員エンジニアを派遣している会社です。
特にエンジニアの教育と育成には力を入れているので、日々進化する技術や開発現場で求められることに対し、
エンジニアが継続的に活躍できるよう、丁寧な研修制度も用意されています。
企業のビジョンは、生涯エンジニア。
エンジニアという職業で、生涯現役で活躍し続けたいあなたを全面でサポートし、伴奏してくれるのがオムロンエキスパートエンジニアリングです。
僕は今回、オムロンエキスパートエンジニアリングさんの働く場所についての資料を拝見しました。
活躍できる業界が様々で、産業用機器や情報処理ストフテイヤ開発、アミューズメント関連、半導体集積回路関連などとても滝に渡っていました。
また、配属先はオムロン関連会社が68%を占める層で、グループ社員の仲間として受け入れてもらえる環境が整っている層です。
心配事をせずチームの仲間を信頼して働けるというのは、仕事のパフォーマンスに大きな影響があると思っているので、そういった環境が整っているのはとても素晴らしいなと思いました。
オムロンエキスパートエンジニアリングは、エンジニアが生涯にわたり、開発現場の最前線で活躍し続けることができる生涯エンジニアを体現できる会社です。
エンジニアとしての経営形成はもちろん、生涯エンジニアとして活躍できるフィールドと成長機会が豊富にあります。
気になる方は概要欄のリンクからぜひチェックしてみてください。
以上、オムロンエキスパートエンジニアリングからのお知らせでした。
ITトリオ
これはソフトウェアのプロダクト開発の話の文脈で、記事も書かれているし、今まで話してきたと思うんですけど、
これ、あらゆる創作物に結構似たようなことを言えるのかなと思って。
そうだね。
例えば、ナブちゃんとか僕がやってるって言ったら、YouTubeでも同じこと言えるかもしれないし、
楽曲、音楽作りでも似たようなことが言えると思うんですよ。
趣味とか、趣味程度で自分の予約の時間を使ってやるんだったら、別に好き勝手やればいいと思うんですけど、
そうじゃなくて、ビジネスとしてやって、コストをかけて、お金をかけて、お金をまた回収しなきゃいけないっていう目になってくると、
どういうものづくりであったとしても、徹底的にリサーチをしたりして、市場の理解とかニーズを深く理解して上で、
自分の中で仮説をたくさん作って、その上でさらにまた仮説を高速で回して、
どれが一番角度が高い方向線なのかっていうものを見極めた上で、
きちんと仮説検証の経験を生かしたプロダクトを作って、また作った上でフィードバックを得て作り直してっていう風にして、
一層のMSPを作っていくっていうのは、プロダクト、ソフトウェアに限らず全部で言えるかなと思って。
他なんか、記事読んだ時の自分の中の強化ポイントは、まず個人開発者としてこれそうだよなと思ったケースともあるし、
YouTubeの動画づくりでも本当同じだなと思って。
YouTubeで動画作りたいってなった時って、やっぱりニーズを理解しなきゃいけないから、
それを徹底的にリサーチしますと。リサーチするためにいろんなアカウントを作って、
そのアカウントで女子高生、男子高校生、大学生、社会人、おじいさん、おばあさんになりきった上で動画を見続けると、
YouTube側のアルゴリズムがそれを理解して、そのユーザー層に対しての最適な動画を出してくれるから、
それを自分の中でそれぞれ見てみると、それぞれのユーザー層への理解度が深まって、ニーズが運び出来てっていうのがある。
それを理解した上で、既存で流行っているフォーマットとか内容を見比べて、自分なりに構造化をした上で、
自分が譲れないポイントをフィックスさせて、その方向性で作るけど、作ったらパフォーマンスの問題とかいろいろあると思うんで、
その数値を元に分析して、また改善していくみたいな、この顧客を理解して、仮説を検証して、
仮説を反映させたプロダクトを作って、プロダクトの市場に対する反応から学びを得て、
それをまた次の改善にフィードバックしていくっていう流れは、もうほんと全部そうだなと思って、
なんか普遍的な話だなと思ったし、話しながら思い出したのは、なんかポルカドットスティングレーっていうバンド分かりますか?
はいはいはい。分からんわ。私は分かります。意外とマイナーなところを。
マイナーなのかちょっと。
めちゃくちゃメジャーとは言えないけど、私はバンドが大好きなんで分かるけど。
なんかそういう、たぶん、たまに、たまにっていうかちょくちょく、ちょろちょろ有名、なんて言ったらいいか分からないけど、そこそこ有名で、
なんかアニメのオープニングやらエンディングやらもたまに提供しているみたいなバンドがあるんですけど、
なんかそのボーカルの人が言ってた、というか取材されてた記事、またこれも放送なんかエロに貼っておくんですけど、
そのポルカドットスティングレーっていうバンドの楽曲作りって、すごいマーケティングで曲作ってるってこと言ってるんですよ。
アーティストとしてじゃなくて、もうマーケティングした上でニーズに応える曲を作ってヒットさせていくっていうやり方をしてて、
音楽制作とマーケティング
そもそもこのしずくさんっていう人が、もともとゲーム会社のディレクターをやっていたから、そもそもなんかそういう、
今言ったようなソフトウェアのプロダクトじゃないけど、ゲーム作りっていう中において仮説を検証して、
たぶんニーズに応えて結果を出すっていうことをやってるから、それをこう曲作りにも応用させてやっているっていうことを言ってたんですけど、
だから、アーティストなんすかね、結果とか市場の反応を気にせずに、
アーティストとして自分の作りたいものを作って、なんか偶然売れちゃったパターンがバンドとかでは多いのかなとは思うんですけれども、
とはいえ、そこにもやっぱりちゃんとビジネスライクに物事を考えて、仮説を検証して、成功への道を確実に一歩一歩進んでいくっていうやり方もあるんだなと思って。
俺はなんか、もし何か新しいことをやりたいってなったときに、それをただ単の趣味で終わらせずに、そこからお金を得たいって考える場合は、
もうどんなことにおいても、このあたりの考え方ですごい大事だなぁとか思って。
すごいね、音楽でそれができるっていうのもさ、
わりかし音楽っていうのを主観的に好きでやっているっていうバンドが多いように見えるけど、
こういうマーケティングで、戦略的に売れるバンド、売れる音楽を作っていくっていうのも面白いな。
面白いよね。
なんかこの人はインタビューの中でも、好き勝手やって結果が出る天才じゃない限り、好き勝手やってる場合じゃないってことも言ってた。
いいなぁ。
そうだから、天才になることは諦めたけれども、天才とは違う戦い方できちんと結果を出すってすごいかっこいいことだなと思って。
そう思うとさ、方向性の違いでバンドが解散しましたとかよくあるじゃんね。
あるね。
なんかそれって結構マーケティング戦略の違いによったりとか、会社の方針の違いにより退職しましたとほぼ一緒なんだって、なんか今ふぎ落ちちゃった。
エンジニアの責務
構造として似てるかもしれない。
構造としては。多分表現なんだろう、デザインとアートにも近いような感覚があるな。
アートチックなことをしたいかデザインチックなことをしたいかみたいなのが音楽の世界でもありそうだね。
そういう意味で言うと、エンジニアもビジネスの中での職業だけど、やっぱり技術者としてアーティスト的な側面も気持ちとして持ち合わせることも多いのかなと思って。
逆にそこでモヤモヤする場合は、個人開発とかでお金を気にせずに、自分のアーティストとしての側面をそこで消化させるっていうことにしておいて、会社自体ではちゃんとビジネスライクな考え方を生かした上でやるっていう。
やり方をするとモヤモヤとかをうまくコントロールできるのかなとか思ったりして、僕は言語化はしてなかったけどそういうことをやりたかったんだなと、議事を読んだり話しながら思いましたね。
エンジニアの責務として、そのすべてをお金として考えるのではなく、守るべき信頼とか、プロダクトが売れる、使い続けてもらうために守るべき守備範囲がある、責任があると思ってて。
例えば、すごく早くピャッと作ったけど、それがバグが発生しやすいですとかだったら、エンジニアとしての守る、守備能力を高めるっていうところの責任を果たしてないことになって、売るために早くマーケットに出す。
それもパラメータの話だよね。売るところに行き過ぎると、それは全体的に見ていいプロダクトとは言えない。それは売れるとは言えないものになってしまうから、エンジニアとしても守るべき責務を守りつつ、
自分たちが強みとなっているパラメータの部分をちゃんと守り続けるためにどうあるべきか。これもビジネスライクではあるんだけど、それを考え続ける責任があるなっていうことはすごい話してて思った。
一つのパラメータでことが済むのって、試験勉強以外にそもそもないのかもしれない。現実社会におけるすべてはもう総合格闘技なんだと思って、柔軟にやりつつ、ニーズに対しての自分の内での反応を見つつ、その後の行動を調整していくみたいなことがいるのかなみたいな。
何だこれ。なんかめちゃくちゃ難しい時代に生きてますね。
お金が動くっていうことはね、社会とかいろんなものが絡んできて、一人で完結するものではないから。
一人で完結させられる天才もいるかもしれないけど、だいたい天才じゃないんで、諦めて現実を見ながらやっていく必要があるという。
難しいね、ほんとに。
すごいね、そんな時代の中、なべちゃんは起業したということで。
こっからですよ、BMF。
頑張ってください。
頑張ってください。じゃあ今日はそれくらいかな。
ということで、最後まで聞いてくださりありがとうございました。ITトリオは毎週月曜日に更新されます。Spotify、Apple Podcast、YouTube、Amazon Musicなどで番組のフォローをぜひお願いします。
レビュー、コメント、お便りも募集しております。お便りのフォームのリンクは放送の概要欄にあるので、どしどし送ってください。
また、Xでつぶやきがあるととても嬉しいです。ハッシュタグ、ITトリオでお待ちしてます。
それではまた来週お会いしましょう。ありがとうございました。
ありがとうございました。
