00:04
はい、みなさんこんにちは。株式会社ゆめみのキースことくわはらです。この番組では、みなさんのモチベーションが上がることを目指してお届けしていきたいと思っております。
第46回目ですね。46回目の収録はコラボ配信になります。第3弾ですね。今回は弊社のUXUIデザインチームのサービスデザイナーであるそねさんをお呼びしております。
そねさんよろしくお願い致します。
こんにちは。
はい。
よろしくお願いします。
よろしくお願いします。朝早くからもうすいませんね、本当に。
いえいえ。
はい。では軽くですけど、そねさんの役歴を教えていただければなと思っております。
役歴、はい。私は43歳なんですけど、今大阪出身で関西大学卒業して関西で就職したんですけども、東京にウェブディレクターとして図書をやっていて、出版社のウェブディレクターで
印刷物、紙物のデザインもするみたいな感じの仕事をしてたんですけど、とある大手の機械メーカーのお仕事で、その機械メーカーさんが本社が東京に来るって言って東京に一緒に転勤をして、それからずっと20年ぐらいは東京に住んでるって感じになります。
その後いろいろウェブディレクターとかウェブシステムのプロジェクトリーダーとかをやりつつ、転職をしつつだったんですけども、10年ぐらい前にグルメサイトのプロダクトマネージャーを一緒にやろうということでジョインして、そこでいろいろ楽しいことをやってたりとかして、
その授業も売却して、その後B2Bにピボットしたんですね。B2Bの業務システムを入れてるときにいろんなことを学んで、それが今につながってるって感じですね。それのもとにサービスデザインみたいな形でところができてきているので、働き方をしてるって感じです。
なるほどですね。初っ端からあれなんですね、ディレクターをされてたんですね。
そうですね。ディレクターという職種で何でもするっていう感じの、当時まだウェブディレクションというのがウェブができたので、固まっていなかったので、
当時ドリームワークス環境でJavaScriptを書いて公開して、FTPでアップして、そこまでやってましたね。
FTPというワードをもう久しぶりに聞きましたね。久しぶりに聞いたって言っておきながら、僕の知り合いは未だにFTPで上げてるみたいな環境もあったりするので、古き時代がまだ生き残ってんだなっていうのは未だに思いますね。
03:06
ありがとうございます。なぜ夢見に来たかみたいな話は、いろんなところで喋られてる、勝手に思ってるので、知らないけど。
曽根さんがその弊社で行っていること、具体的にどういう仕事をしているとか、どんなポジションでお仕事をされているのかなみたいなところもちょっと深掘りしたいですね。
サービスデザイナーってさっき言いましたけれども、サービスデザイナーってサービスを全体を見るっていうか、全体視点でサービスにこうあるべきを考えて、その要素って何だろうを考えて、それをデザインして、それをシステムとくっつけて、運用もどうだろうを考えてみたいな、全部をデザインする役割だと思ってるんですけど、
特にその中でも後ろのプロジェクトマネジメントも含んで僕はサービスデザインだと思ってるんですけど、そこの部分もできつつ、もうちょっと前段階のところでコンセプト策定フェーズだとか、
もっと前のそのコンセプトを何していいかわかんないっていうお客さんがいたりとかするので、そこを重点的にご支援するっていうような形で、まずお客さんに入り込んで、また物としてどういう物がいいのかっていうところを決めていく、物を作りするところまで。
その前半部分までをメインフィールドとしてやってますというのがサービスデザインとしての役割だと思います。
あとは社内でマーケティングとかプロジェクトマネジメントの委員会に入って、プロセス策定をしたりとか、あとはめみじゅくでいろいろ講座を持ったりとかしているって感じです。
なるほどですね。聞いた感じだと、プランナーと結構グラデーションかかってるポジションかなと思ってたんですけど、プランニングもするって感じですか?
プランニング?企画っていう意味のプランニングですか?
そうですね。プランニングってビッグワードじゃないですか。
ちょっと幅広いというか。
企画って言われたら、それこそ何でもやるみたいな感じはあるので、プランニングっていったらいろんなものを含みますけれども、プランナーって呼ばれたらプランナーだし、ただなんだろうな。
難しいけど、サービスデザインって言ってしまえば本当に全部やるって言っても過言ではない気はしてますね。
06:04
そうですね。
本当にいいシステム、いいサービスとかお客さんにいいものを届けるとかっていう。
そうですね。呼び方の問題ですかね。
エンジニアリングとちょっと対比するんですけど、エンジニアリングっていうのは多分便利なものを作るってことだと思うんですけど、
僕らのやってることっていうのは、お客さんは何を便利って思うんだっけとか、便利ってなんだっけとか、探りに行くような仕事かなって思ってますね。
なるほどですね。言われてみればそうですね。
でもさっき一応前半部分を担当するみたいなお話あったんですけど、プロジェクト始まっても製造のフェーズに入ったところでもやっぱりマネジメントってあると思うので、そこのサポートとかもされたりするんですか?
そうですね。そこの部分も経験があるというか知ってるので、前部分でやりやすいように誘導ができるっていうのが多分強みだと思ってて。
それが多分コンサルとの違いで、コンサルってすっげえいいっすよ。これっすね。あとは知らんって感じでやりがちだと思うんですけれども、
夢見のツールを見て全部見れるってことじゃないですか?そこの後工程へのつなぎ込みみたいなところまでも意識して、デザインとかプロジェクトとかプロダクトの仕様を決めみたいなところも意識してできるかなと思っています。
なるほどですね。はい、なるほど。面白いな。
もうちょっと話聞いてみたいんですけど、僕はディレクターって現実にどういうことやってるか実は全然知らなくてですね。ディレクションと僕エンジニアサイトのマネジメントって何だかんだやってることと実は本質一緒なのかなって思ったりしたんですけど、その辺ってどうですかね?
一緒なんじゃないですか?
一応人とプロジェクトをどう回すかみたいなところだと思うんですけど。
リソースマネジメントと、例えばデザインだったらデザインディレクション、技術的なディレクション、ディレクションっていうのは方向付けなんで、方向付けるそれからリソースとスケジュールを管理するっていうのは大きな仕事だと思うので、やってること行為自体は変わらないんじゃないですか?
対象が多分違うだけで。
やっぱそういう感じですね。じゃあ認識が合ってたな。なるほどなるほど。ただお客さんに近い方なのがディレクターのイメージはありますけどね。
09:05
プロジェクトマネージャーも結局お客さん喋っちゃ喋るんですけども、もっと具体的な話まで行って初めて喋るイメージはあるんでね。
そうですね。プロジェクトマネージャーの方がスキルセット的には多いのかなと思います。
それはそうなんですね。ディレクターは逆にそんなスキルいらないんですか?いらないって言ったらもうご平和あると思うんですけど。
わからないですけど、プロジェクトの中の単一のタスクというかそのスコープの中の、例えばデザインだったらデザインの中のマネジメントするっていうのがディレクションのイメージかな。
なんかでもプロジェクトマネージャーってデザインフェーズも一応あれですね、ガントチャートの中に含めたりするじゃないですか。
そこってバッティングするんじゃないかなと思ったりしたんですよね。
プロジェクトマネージャーが全部見るというよりはプロジェクトマネージャーが委任してその人にマネジメントを任すっていうことだと思いますけどね。
全体工程としてはマネージャーが見てるけど、でもそこから先はディレクターにお願いって感じですかね。
そうですね。スケジュール管理だけじゃなくてそこの方向性を出すとか技術的な選択をするっていうのがプロジェクトマネージャー一人では多分でききれないと思うので、
そこのための専門家っていう区分けで僕はイメージして持ってますね。
なるほどですね。
そうですね。いくつか聞きたいことがいっぱいあるんですけど。
サービスデザイナーっていうか、サービスのデザインですけど、僕らはやっぱりエンジニアはプロジェクト単位で見たいと思っているので、
プロジェクト単位で考えると最終的にビジネスのことを考えなきゃいけないと思ってたりですね。
考えた時にデザインとか、本当は多分突き詰めたらどこまでもいけると思うんですけど、
落としどころとお客さんの要望と開発工程とかリソースの話とか全部含めると、
割と最終的には交渉とかたまに政治力の話になるんじゃないかと思ったんですけど、
その辺で何か苦労していることとか工夫していることってあります?
政治力の話はまさにそうだと思います。
なので、私たちが何を作りたいかっていうのは多分、最後の方に考えることで、
まずはお客さん理解、お客さんというかクライアントを理解して、
そのクライアントの先にいるユーザーを理解しますというところかなと思っています。
なので、それを知るためにすごいヒアリングだったり、
いろんなこと、インタビューをしたりっていうのはすごい大事かなと思っています。
12:00
どっちかというと、依頼が来てサービスデザインやりますっていうよりは、
営業と一緒に乗り込んで、このお客さん、こういうことなんだっていうのを理解して、
そもそも提案していくっていう形になりますね。
なのでどっちかというと、RFPをもらってRFP通りに作るっていうのはあまりはまらないと思います。
RFP、そもそもこれ合ってます?これって。
そんな人いないですよね、みたいな話をしがちで。
それがはまるお客さんもいたりとか。
とはいえここまで考え尽くされているので、これが合っているかどうかまずやりましょうかみたいな話をしたりとか。
そこからいいものができていくのかなと思っていますね。
なるほどですね。
あからさまにというか、明らかにこのRFPじゃ対象ユーザー違うとかはあると思うんです。
そういう時ははっきり言うかもしれないですけど。
まず1回はそのRFP、お客さんの要望を受け入れるっていう感じですね。
そうですね。RFP見たらわかりますか?経験上。
これすごい詰まってるなとか、これ背後にコンサルいるなとか。
見た瞬間にわかるので。
へー、コンサルまでわかるんですね。
コンサル絶対いるでしょこれっていう。
お客さんの部署的な構成、どんな業種っていうのも出るとわかるんですよ。
業種によって、例えば流通小売の会社とかだとしたら、
部署間移動が激しくて、販売員の方が上司室にいて、上司室からまたどっか経営企画に行くみたいな、
そういう育て方をするんですよ。
ってことはスペシャリストは育たないんですよ。
だからその人が、そういうシステムのことを考え尽くせるかって言ったらそうでもなくて、
そこにインセンティブがないんですよ。
ってことは誰かの助けを借りないといけない。
っていう組織図だとしたら、これこの人だけできるはずないよねっていうのはわかるじゃないですか。
そういうのも経験してるとわかりますね。
いやー面白い話だった。
なるほどですね。
コンサルと…
だとすると、それわざわざそこからひっくり返しに行きますかっていう話になるんで、
そこでアプローチが変わるんですよ。
それをこうですよね。
そうだと思う。
まあまあ誰かに頼らなきゃいけなくて、今夢見頼ってもらえるならお仕事もらえるんで。
そうです、はい。
っていうのはありますよね。
うん。そこを物作りに行こうみたいな。
15:01
一方で、本当この担当者さんとかこの部署ができる範囲での思いつきでしかないなみたいなのを見た瞬間わかる。
ロジカルではないので。
はいはいはいはい。
ジャストアイディアみたいな。
どう思うんですか?って。
なんでこう思ってます?って。
突っ込んでいって答えてくれたら、ああそれ理解理解なんですけど、突っ込んでいってポンってなる場合は、
そこを掘り起こしに行こうかなっていうことはすると思います。
掘り起こしとか質問的にはホワイトハウを聞く感じですか?
そうですね。
なるほどね。
まず、そんな人います?って。
大前提からですね。
これくらいいるんですか?
はいはい。
今、競合ってどこになります?競合いないですって言われたら、なんで競合いない?競合いないってことは市場もないってことじゃないですか?みたいな。
痛い質問だ。
独占な可能性もゼロではないですけど、今の時代独占…。
独占状態だったらそんなこと考えない。
そうですよね。おっしゃる通りだな。
いやー面白いですね。
はい、そしたらですね。
コンサルテワードが出たんで、僕の過去のPMに当たったことがある経験があるんですけど、
その人がコンサル出身だったってもちろんあるんですけど、
お客さんの要望をすごい理解はめちゃめちゃする人で、業務知識もたくさん持ってるんですけど、
風呂敷広げるのものすごい上手くて、そのまま閉じないで別のPMに本投げる人がよくいるんですよね。
そうすると社内的にPMと戦わなきゃいけなくなるっていうのがあって、
そういう人を組織でどう扱うかっていうのは今後夢見に出るかわかんないですけど、
考えた時どうしようかなって最近考えたりしてるんですよね。
曽根さんはそういう人ってあったりしました?ちなみに。
あったりとかした?
一緒にお仕事をしたみたいな。
ありますね。
結局僕はエンジニアだったので、従う側にいたんですよね。もちろん意見はしてたんですけど。
してたところで上下関係で発言力がなかったので、そのまま広がった風呂敷を客さんになんとか閉じにいったんですけど、
当初のスコープから全然広がって、見積もり額がうちペイしなくない?みたいなところで終わってしまうこともたまたま度々あったんですよね。
そこはフェーズごとのレビューというか、ゴール設定をちゃんとしないといけないのかなと思うし、
18:00
フェーズごとの関連性っていうのが薄かったんだろうなと思う。
そのコンサルの方って、風呂敷を広げることが仕事なので、そこまでしかしなかったんだろうなと思いますけれども、
その方に実現可能性の担保まで委任すれば、たぶんそこまでできるんじゃないかなと思う。
その方がそこまでやるべきなんじゃないかなとは思いますけどね。
なるほどですね。うん、わかりました。
一応プロジェクトマネージャーというポジションで入ったから、閉じる方もするのが普通だろうなっていうのは個人的な感覚だったんですよね。
そうですね。
もちろんコンサル能力がずば抜けてるんで、むしろそっち専業で移った方がいいんじゃないかと思ったりはしましたけど。
別にコンサルはそれ自体も別に価値ある仕事ではあると思うので。
あとは高速プロジェクトでこういうことを広げましたけど、これから閉じに行きますよと。
閉じに行くのにこういう基準でやりますからということで合流をして、その全部をやりますって言っちゃうんじゃなくて、
全部の中で今できるやつはこれとこれとこれですみたいな感じに閉じに行って1個1個やるとそんなにしんどくないなと思ったんですけど。
もちろんコミュニケーションなんで。
自分の話になりますね。
そうしましたら、ちょっとここからはデザイナーとエンジニアの協業について一緒に歩んでいくみたいなところを深掘りしたいと思っていたんですけど、
曽根さんの話で聞くとあんまりデザイナーメインみたいな感じはなさそうだったので。
全然違いますね。
まあでもとはいえ。
デザイナーと名乗ってなかったんですけど。
そうですよね。
様々なデザイナーたくさんいるチームにはいるけどって感じですよね。
そうなんですよね。
一応一緒にお仕事したことあると思うんでその辺の知見から聞いてみたいところがあるんですけど。
事前に多分相談したかないようになりますけど、一緒に仕事をする上でエンジニアサイドの人間また逆にデザイナーサイドの人間がお互いに知っておいた方がいいことっていうのがあったらちょっと聞いてみたいですね。
知った方がいいこと。あんまり考えていなかったですけど。
まあちゃんと曲のコミュニケーションがちゃんとできていればいいと思うんですけど。
なんかそうだなデザイナーだからエンジニアだからみたいなところも領域はもうなくなってきていると思うんで。
チームとしてはもう完全に一緒に動くみたいな形でやっていくのが理想の形だと思ってます。
デザイナーだからシステムのことわかりませんっていうのはこれからそういうのってあり得るの?みたいな。
もう5年後ぐらいのレベルでそんな世界になっていくと思うし。
21:05
逆にエンジニアもデザインのことはお任せだからみたいな。
魔法使いじゃないのでお互い。
おっしゃる通りですね。
っていう形でどちらもその内容っていうのを勉強していかないといけないんじゃないかなって。
なるほどですね。
躊躇できなくなってくるんだと思う。
だからノーコーディングでサービスできちゃう世界とか、
例えばもうスキーマだけアップロードしたらよろしくやってくれるみたいな、
そんなプロダクトみたいなのができてきている世界において、
どうやってそれに立ち打ちできるんだろう?って。
勉強してても無理だとは思いますので。
なるほどですね。
それを知った上で強みの部分を伸ばしていくのは必要なのかなと思いますね。
知らないはもう完全NGで、せめてお話できるぐらいまでは知っておいてほしいよねって感じで。
そうですね。
どうしてもその専門職種の人にこれはかなわねえなっていうところでリスペクトし合いながら、
そういうところでじゃあお願いしますみたいな感じで、
委任し合うっていうのが美しい形なのかなって思いますね。
そこはでもみんな一緒の認識っぽいですね。
ツイッター見ててもみんなそんなっぽいことを言ってるなって感じはしたけど。
そうですね。
ノーコードが出たから多分エンジニアサイドはだいぶオってなってますけどね。
極論多分その仕事がなくなって楽だっていう人もいるかもしれないですけど、
じゃあどうやって食っていくねんみたいなのしか出てくると思うんで。
その代わり別の仕事が生まれるんでしょうね。
ノーコード生まれたところで変化を起きると思うんでね。
そこのキャッチアップは多分デザイナーサイドもあると思うんで。
どういう風になるか僕は全然デザイナーサイドの想像はできてないんですけど。
だからツールが使えますとか、この言語知ってますっていうレベルだと、
多分そこからその言語がもう一般化した状態になったときに、
そこから次に行くっていうのは難しかったりとかすると思うんです。
ツールって所詮道具でしかないので、
道具が別に使えてれば使えるでしょみたいな話はありますからね。
なるほどですね。
そうするとよりグラデーションが広がっていくイメージはあるんですけど、
最近だとUXエンジニアっていうワードが弊社の代表がよく言ってますけど、
24:02
でもそれは僕も正しいと思ってて。
フロントエンドのエンジニアの人とデザイナーさんは多分UXエンジニアに寄っていくんだろうなって感じはあるんですけど。
完全にバックエンド側の人たちはどうするのかなっていう。
そこだけ僕線が引かれるのかなってなんとなく思ってたんですよね。
UXエンジニアと本当に裏側だけの、何エンジニアになるかちょっと分からないですけど。
っていうところの線引きがあって、
本当バックエンドだけの人ってデザインのことを勉強する場合があるのかなって。
もちろん知識として知るのは全然いいことではありますけど、
例えばAPI作るとしても、情報設計された結果にこういうデータが必要、
そのデータが必要のためにこんなデータベース設計になりますみたいな話がよくあるんで、
そこまでちゃんと想像して勉強するのは必要だと思うんですけど、
そのレベルで良いかなっていう感じはしてるんですよね。
バックエンド側の人はですけど。
どこまで知ればいいかみたいなところって、
僕もそのバックエンド出身になったので、
いざデザイン側の勉強するってなった時に何から始めていいかは本当に分からないんですよね。
そういうところなんかアドバイスいただけたら嬉しいです。
そうですね。
これこそインフラストラクチャーと、
例えばインフラストラクチャーで、
発電所からどう電気を送ってくるっていう仕事をしてる人に、
家の中のこの電球の配置とかどうしたらいいですかみたいな、
そこまで考える必要はないと思うので、
線引きというかそういう役割っていうのは分かれるとは思いますね。
良い例えだな。
何でしたっけ?
インフラストラクチャーの発電所の人が電球をどこに置いたらいいかは別に知らなくていいですけど、
知っておいた方が良いってことで言うと、
どのレイヤーまで、レイヤーっていうのかな、
範囲を知っておくのがいいのかなって感じですね。
さっきの発電所の電球の足だと、
要はレイヤウトぐらいは知っておくべきなのかなとか、
電球もその色とか発電、発光の仕方とかあると思うんで、
それによってユーザーの、部屋によって発光してほしい色とか、
高度、気度かは違うと思うんで、
その辺ぐらいまでは知っていいのかなって感じ。
何ボルトぐらいまでは家の中で使われるべきなんで、
みたいな知識もあったらいいし、
その電球使う側も危ないんだよっていうことを知っておくとか。
なるほどですね。
27:00
難しいな。
最終的にフルスタックっていうワードを使いたくはないんですけど、
に近くなってきちゃうのかなって感じが個人的にはしていて。
そうするともう1回話を、
ディレクターとマネージャーのポジションに戻すと、
彼らは何を知るべきなのかって今後、
知っておいた方がいいのかなとか、
どこまで勉強すべきなのかなっていうところが、
僕はよく分かってないんですけど、
小谷さん的にどうお考えですか?
フルスタックね。
フルスタック積み木を全部積み上げられる人は多分スーパーマンなので、
スーパーマンで置いておいて、
凡人としてはフルスタックの、
完全にフルスタックが難しいという前提において、
何か自分の強みのあるところを何個かスタック積んで、
そこでやっていくんでしょうね。
その延長上にディレクターがあると思っていて、
そこのさらに上に、
マネジメントの方法論だとか、
標準化のやり方だとか、
情報共有をするっていうことはどういうことなのかだったりとか、
そこに対する手法だとかを学んだっていうのをプロジェクトマネージャーだと思っていて、
それによってコントロールができるということになっていくのかなと思うので、
技術を突き詰めて学ぶっていうことがプロジェクトマネージャーのスキルではないと思う。
それはそうですね。
一方で、結局マネージャーにとって決済権を持つと思うんですよ。
決済するためには知らなければエイヤーで決済になって、
現場がまた苦労するみたいな話あると思うので。
そういう意味でいくと、手を動かせるまで言わないですけど、知識レベル。
体験、どういうものだと。
体験的な理解は必要だとは思いますよ。
せめてメリデメぐらいは知っておいてほしいなぐらいの。
なるほどですね。
そこもやっぱり。
今時AWSって言われて分かりませんっていう。
それはさすがに厳しいですね。
さすがにそれは厳しいですね。
そうですね。
デザイナーの人がAWSは何かぐらいは知ってるけど、各サービス?
ラムダデイとか。
そうそうそう。
EC2。
EC2はワードよく出るから知っといても損はないけど、
使うことはないでしょうけどね。
特に我々IT業界の会社にいるので、
特に開発を担当している会社ですので、
せめて営業の人でも知っておいてほしいな感はあったりしますけどね。
思いますね。
営業の人にデザインとかエンジニアの知識があれば、
お客さんの話の引き出し方はもっと変わってくるのかなと思ったりして。
30:00
そう思ってます。
そこは僕マーケティング委員会で課題感を持っていて、
今進めているところになりますね。
知らないからエンジニアの誰かを連れてくるとか、
マネージャーを連れてくるとかがあるんですけど、
一方でその連れていくマネージャーやディレクターの方が
どこまで知っているかっていうのも結構重要になってくると思ってて。
それマッチしてるんだっけっていうところがそもそもありますね。
そうですね。人選もありますし。
売り物をちゃんと理解してほしいし、
その売り物をちゃんと売る方もアピールしないといけないと思っている。
だからこういうお話が来たんですけど企画お願いしますっていう投げ方だとだいぶ厳しくて、
こういうお話が来たんですけど、
ここのお客さんこうで、でもこういうアプローチしてるのがちょっとおかしいんで、
ちょっとそれを覆したいんで、覆す案をもらいたいんで、
プロジェクトを一緒にやってもらえないですかみたいな頼み方だと何していいかわかるじゃないですか。
そうですね。
そこがたぶん戦略っていうか、そこまで決めていかないといけないと思ってて、
そこはたぶんいろんな知識が必要なんで、
営業って難しいと思います。
そうですね。これっていうものが何かなさそう。
売ってしまえば全部ですからね。
たぶん一番難しいと思います。
やっぱりそうですよね。
営業サイドはやっぱりそうなってしまうんだろうな。
営業サイドとか、さっき言ったマーケティングする人も同じかなと思ったりしましたね。
そう思います。
マーケティングと営業ってほぼほぼ依存関係なところあると思うんで。
マーケティング委員会で今後やっていく方針というかアプローチしたい方法とかってあったりします?
アプローチしたい方法はそこのどうやって引き出していくんだっけとか、
引き出していくっていう役割を営業だけに任せるんじゃなくて、
職種とロールを分けましょうみたいなのを社内で全般的に話をされていて、
これは全くそうだなと思っていて、
営業活動のこのロールを例えばPMの誰さん、サービスデザイナーの誰さんに任せるんで一緒にやっていきましょうみたいな。
なるほどですね。
っていう体制になった時に、それがどんな人でも一定レベルできるように標準化するやり方だとか、
標準化に必要な知識だとか、それを勉強会でやってるとか。
それいいですね。
いうのはしていかないといけないなと思って。
人の冗長化は本当に僕も課題だと思ってて。
33:00
そうですね。
持ってる知識レベルとか範囲によって頼める人限られるってのはちょっと。
デリゲートしたいんですけど、できる人が限られるのはなかなか難しいし、
その人リソース埋まってたらこの案件取れないってなったらそれはもったいないってなるんでね。
そうですそうです。
なのでさっきの職種とロールを分けるのはすごくいい話なんですけど、
ただ一方でちょっと前に話出たグラデーションの話、みんなが他のことも知っておいてほうがいいよみたいな話とバッティングすると思ってて、
最終的にその強みをどこに自分が置くかっていうのは個々人で考えてもらいたいと思って。
その強みのところでロールを分けるって感じですか?
そうですね。ロールできる人と分けていくんでしょうね。
なので在的者じゃないですけど、こういうパターンだったらこの人だなみたいなパターンができてくる。
そのパターンを見極めないといけないと思ってるんですよ。
パターンを見極めるっていうロールがあると思ってる。
それは多分限られた人しかできないんじゃないかなと思う。
なんかそれこそヒューマンスキルなイメージがちょっとありますね。
ふわっとした言葉で言うと人を見る目みたいなところがあるのかなみたいな。
人というか案件を見る目みたいなところがふわっとした話ですけどね。
それは多分いろいろ仕事を繰り返していく中でこういうパターンでパターン化されると思って、ある程度は自動化できるんじゃないかなって思ってます。
その言語化はめちゃめちゃしたいなと思ってますし。
できたら自分がこれを身につけていったらそこにたどり着けるっていう道筋が立てられると思うので。
そうですね。
やっていきたいというか僕もそれちょっと待ってます。
その対外スキル僕もあんま得意ではないので。
まあべしゃりは好きですけど得意ではないってところが課題なんですよね。
あとそうですね予備知識も意外と少ないので僕も。
マーケティング委員会ではブランディングも考えるんですか?
一応多分社内組織としてはブランディングは分けていると思ってるんですけど。
そうですね今のスコープとしてはそんなにないですね。
どっちかというと営業活動の課題感みたいなところから入っていて。
それを効率的にしていくにはどう広めていくかっていうところで
マーケティングなどかブランディングっていうところが重なってくると思うんで。
ちょうどそれであれもやってます。
次のウェブサイトもプロジェクトマネジメントも拝命をしていて今ちょっとやってるんですけど
その部分もちょっと理想との差異があって
36:01
それを理想ってなんだっけっていうのを見つめにいって
今合意形成できているので細かいタスクで動いていくのかなと思います。
僕はあのサイトはエンジニア的には好きなんですけどね。
見た目とかっていうよりも本当はパフォーマンスの一点だと思いますけどね。
パフォーマンスいいですよね。
あれだけは話題になってましたね。
そういうことをさせてくれる会社ってだけでエンジニアとしては行きたいなっていう声も2,3件見ましたしね。
そこはたぶん成功したんだと思うので。
そこは成功したんですけど
やっぱりビジネスサイドですよね。
2012年の1月に目標というか目的を設定されていて
その中に大冗談にあったのが
企業の担当者の安心感、信頼感につながる
求職者の安心感につながるっていうことで
後者の部分はね
そういう爆速だとかそういうキーワードで
分かる人には分かるんだけど
企業の担当者は分からないんですよ。
ですよね。一瞬これコーポレーサイドかって。
バランスを上らないと
競合というか他のベンチマークの会社たち
一緒に見られるような会社たちがそれをガンガン出しているのに
こっちは引いているっていう状態になると
もうその時点で差がついてしまうので
そこをちょっと理想に近づけていく必要があるのかな
と思っています。
なんとなく勝手な解釈で
その当時の背景として
1000人に目指すみたいなことをレイさんが発言されたことも
多分だいぶ加味したんだろうなと思って
だから採用サイドに重きを置いたサイトになったのかな
ちょっと思いました。
いやでもね採用
見てみたらわかるんですけど
採用コンテンツほとんどない
そうなんですよね
コンテンツ的にはないんですよね
なのでサイトそのものが一つのコンテンツみたいな
認識になるんだろうけど
そこまで深掘りしてみる人はあんまりいないだろうな
いないですね
正直
僕は
見る人は見るし
私はちなみに見るんですよ
各お客さんのサイト行ったら
まずソースコードを開くんですよブラウザで
そういう変態はいっぱいいるんですけど
じゃない限り刺さらないし
それって一定数しかいないのでね
そういう変態にはもう刺さってるから大丈夫
そこから先に裏組みをやっていきましょう
っていうところですよね
企業への訴求がまだあのサイトだとわからない
そうですよね
わからないなって
面白いサイトではあるんですけどね
一つの見方としては
なるほどですね
営業の話
セールスがうちの課題の大きなものの一つではあるんですけど
39:02
こういう自宅企業だと
他のプロダクトをやってる企業さんだと
いわゆるセールスエンジニアみたいな人もいると思ってて
技術のわかるセールスの人もしくはデザインがわかるセールスの人とか
そこは多分いろんな勉強会とか
イベントどころに登壇したりして
多分波及できてると思うんですけど
なかなかやっぱり自宅企業だとそういうのって置きづらいんだろうなと思ってますし
今特に夢見は専業か
技術に特化したチームになっているので
余計にそういうことはしづらいなと思ってて
そうすると営業の人に知識を持っておられるしかないのかなっていう風に
そう思ってるんですけどマーケティングチームではどういう感じですか
どうなんだろうな
職種間での流動性みたいなのが必要かな
流動性は確かにそうですね
あんまり流動してるようにはしてない
エンジニアからセールスに行ったって聞かないじゃないですか
聞かないですよね
営業からエンジニアに行ったって聞かないじゃないですか
それもないですね
行くとしたらやっぱりプランナーらへんだろうなと思ってますけど
行かないだろうな
そういうのが好きだからそのポジションにいるって言ったと思うんで
そういうのも必要かも
それが何だろうな
さっきの職種とロールの話で
多分エンジニアに営業ロールが求められることもあるので
どっちかっていうとその前に出てくる人みたいな形で動いていくっていうのができてくるんじゃないかなと思います
そういうのもなんだろうな
RFPもらってRFPに応えることが仕事になってると
多分今コロナみたいな状況になった時に
その予算に合う仕事みたいな形で調達をされるので
予算合わないから切られるんですよね
確かにな
そうじゃなくてその予算一緒に作りに行きましょうっていう関わり方ができると
その予算の中でできることを考えられるので切られづらい
それは確かにあるかもしれないですねアプローチとしては
そこになるためには多分その営業というか
いわゆるその旧来からの営業っていうスキルだけじゃなくて
技術わかってますよデザインわかってますよお客さんの課題わかってますよ
どうしたらいいかっていうのが私たち見えてますよっていうポーズっていうか
ポジションにいないといけなくて
42:03
それはできるっていうチームを作っていかないといけないなと思う
なるほどですね
だから営業の職種の人に任せるというよりは
この営業っていうプロジェクトを貫通するリソースをいろんなとこから持ってくるっていう
営業で仕事を獲得するっていうのをプロジェクトと考えると
そういう感じになるんじゃないかな
そういう感じを聞くとひめみはやっぱり
誰かスター選手がいるというよりもみんな組織で解決していこう感がありますね
なんだかんだ
スター選手はスター選手でいたらいいと思う
それは本当にいいよ
その人だけで仕事を取れたらそれが一番効率いいじゃないですか
ご指名
ご指名はめちゃめちゃありがたいですよね
なるほど
ご指名ってでも流派の波動があるじゃないですか
需要を読めないじゃないですか
読めないですよ
読めないというかそんなに需要
断るぐらいの需要は今ないから
そうですねおっしゃる通りです
全体としてはそれを目指すべきなんでしょうけど
そこを目指すためにチームでやっていかないといけないのかな
そうなると多分職種観とかチーム観を超えた
コミュニケーションの場とかがすごい大事になってくると思っていて
先ほどのグラデーションの話もある通り
夢見塾がいろんな分野の勉強会を開いていただいているので
これがたぶん今後もっともっと重要になってくるのかなって
そんな気がいたしますね
正直思ってますやっぱり
でも夢見塾のその代わり講師のできる人もどんどん
いろんな多業種の人を呼んでこないといけないかもありますけどね
そうですね全然足りないと思います
そこでもし営業の範囲の勉強会があるなら
僕はすごく聞いてみたいですけどね
聞きたい
文字通り営業の勉強会って
彼ら多分実体験でいろいろ培ってきたものでやってきてると思うんで
言語化してない人も多分いらっしゃるんだろうなというのがあって
そこをどう伝えてもらえるかって難しそうだなと思ってますね
それこそ交渉アナリストとかいるじゃないですか
あれで言語化されてたりとかすると思いますけど
そういった交渉術だとか
喋ってないけどその人の考えを読む力だとか
どうやったらこの人の考えを覆せるかの戦略だとか
多分あると思っていて
すごいめちゃくちゃ興味あったし
45:02
多分好きそう
営業の技術だと思うので
そうですよね多分あると思うんですよね
すごい聞きたいですよね
でも弊社の交渉アナリスト持ってる人って
意外と営業の人いなかったりするんですよね
多分個人でこのお客さんにはこうアプローチしたらいいだろうみたいな
データベースが個々人の中にあるんでしょうけど
そういうパターン化したものは
っていうのはすごい聞いてみたいんですよねやっぱり
僕もお客さんと喋らないことはないので
それこそさっき一番初めの方に言った
業態によってこういう組織構造になってるから
こういうコミュニケーションすべきみたいなのは
いくつかあると思うので
そういうところからもいいかもしれないですよね
そうですね
今のところでMIMEI塾のカリキュラム見た感じだと
名業もエンジニアもまだいないのかな確か
あんまりいない
そうなんですよね
逆にデザイナーさんがエンジニアのことを知りたいとなった場合
どういうことを知りたいのかっていうのが
僕もよく分かってないんですよね
今だろうね
逆に何が知りたいかって聞いても
向こうは多分何も分からないから
分からないから分からないって聞いてるような
今からな感は正直ありますね
本村君みたいな人は分かりやすく
こういうことを聞きたいんですって
彼は多分聞かないまま知ってると思うんで
勝手に勉強してると思うんで
あれなんですけどね
そこは学び合いするんですけど
学ぶっていう意識がないと
多分難しいかなと思います
すごく僕
勉強会MIMEI塾ですごいいいなと思う
OUIの学部があるんですけど
あれってめちゃくちゃエンジニアとの関係
いや本当に
撤去するところじゃないですか
あれ分かったらクラス図描けるんですよね
そうですそのまんま
そしたらこういうデータの持ち方したら
インフラまで創造できる
そうまさにそうなんですよ
あれ画期的だったんですよね
このデータとこのデータ
多分違うところにあるよな
そしたらこれマージできないよな
どうしよう
中間差がいるよなとか
そこまで創造が広がるんですか
そこまでできるといいと思うっていうのを
前ノートに書いたんですけど
オブジェクトベースUIで作ることが
せいなんじゃなくて
せいではなくて
ただ強い武器としてはいいと思うんですよね
あれを初めてやって
先が創造できるすごい強い
本当そうなんですよびっくりしました
だから一緒にやると
48:01
すごい効率がいいんだと思いました
あの勉強会は何度も何度もループしていただいて
もっとエンジニアも巻き込んでいきたいな
標準技術として
そうですね会社全体として
あれは本当すごかった
もはや情報設計してるようなもんですからね
情報設計ですよね
うちの会社は情報設計を
ちゃんとしてるようでしなかったりする
プロジェクトがちょいちょいあるんで
あとからこのデータ足りませんとか
絡むたさなきゃいけないみたいな
それはまあそうだろうなっていう話です
そもそもデータないですとか
こんなデータないですとか
あるあるある
そこでもあれはもう要件定義の段階で
あそこまでやれると
その後の設計がすごい楽になるし
もう特定できてるんですもんねデータ
そうです本当にそうなんですよね
だから多分デザイナーさんが作った
漢方みたいな
フィグマのデザインの中に
このデータってないですけどっていうものは
多分そういうコミュニケーションすらなくなると思うんで
そうそうそうそう
これはありがたいんですよねやっぱり
これ住所取ってきてますけど
住所どこにあるんですか
住所データどんな形になってるんですか
はい
っていうところですよね
OUIを本当に
今後もっともっと主流にしていきたいところではありますね
そうですね
はい
そしたらですね
時間的に聞きたいことはまだあるんですけど
だいたい1時間いかないぐらいですけど
喋っているので
これ以上長くなるとあれなんで
一旦区切りをつけたいなという風に
すみません
第2弾もまたちょっとお話できる
じゃあ最後にですね
聞きたいことが
全然僕が聞きたいこといっぱいあったので
すごくありがたかったですけど
最後に
曽根さんに聞きたいのは
曽根さんの夢見での
ミッションみたいなのを決めていたら
そのお話は聞いてみたいですね
ミッション
曽根さんがこの会社でどういうミッションを
自分で決めたのかなみたいなのを聞いてみたいですね
ミッション
ミッションね
ミッションなぁ
僕のコピーを作りたいです
それはすごいなぁ
曽根さんのコピーか
ちょっとハードル高そうですね
僕のコピーか
もっと
いいなぁ
本村君のコピーを作りたい
彼のコピー作れたらすげぇなそれも
本当にいたら最強だと思うんですけどね
あの年のコピーを
いや
若干25ですからね
4人ぐらい
いやーあれの人は稀有な存在だからな
稀有な存在ですな
よく生まれたなと思いますねあんなの
51:01
本当に
あんなのって失礼だな
コピーを作りたいって感じ
と思っていて
そういう形でいくと
幅も広がると思います
うんうん
で
なるほど
僕が全部やっちゃうんじゃなくて
うん
ちょっと引いた位置に
やる人っていうのが
何人か来てくると
いいなぁって
はい
そういう組織設計とか
に興味があります
分かりましたありがとうございます
はいじゃあそしたら第1弾は
こちらで
本当に貴重な話というか
ものすごい僕としては学びのある
1時間だったなと思っていて
ありがとうございました
はいまた
話したい聞きたいことありますので
お時間頂戴して
第2弾やらせて頂ければと思います
はいじゃあ今回の
収録はこちらで以上となります
ありがとうございました
