カップ焼きそばの新しい食べ方
Takaya Deguchi
こんにちは、Deguchiです。
kudakurage
こんにちは、Motoyamaです。
resizefmは、MotoyamaとDeguchiが最近気になっているサービスやデザイントピックスを取り上げて、のんびり話すポッドキャストです。
よろしくお願いします。
Takaya Deguchi
お願いします。
kudakurage
Deguchi君、最近、直近でさ、
うん。
あの、カップ焼きそばを食べたのって、いつ?
Takaya Deguchi
うーん、いつだろう。
遥か前ですね。
遥か前。
記憶にないレベル。
kudakurage
いつぐらい、大体なんか、この時の記憶はあるな、みたいな。
Takaya Deguchi
うーん、ここ5年ぐらい食べてないんじゃないですか?
kudakurage
多分。
いや、僕多分、最近僕食べたんですけど、
うん。
その前ってなると、たぶんもう小学生か中学生ぐらいのレベルなんだよね。
Takaya Deguchi
あー。確実に記憶あるのは大学生までですね、僕は。
kudakurage
あー。いや、なんかカップ焼きそばってあんま好きな人いるけどさ、よく。
Takaya Deguchi
うん。
kudakurage
なんかやっぱあんま僕食べなくて、
うん。
なんか、その、いわゆるカップ麺、ラーメン方面のカップ麺よりも、なんか焼きそばジャンみたいな、なんかあるじゃん、なんかその焼きそばジャンみたいな。
Takaya Deguchi
どういう意味?
kudakurage
いや、なんか焼きそばだったら作ればいいかなみたいな気持ちになっちゃうというかさ。
Takaya Deguchi
あー。
まあ、それがめんどくさいからじゃないですか。
kudakurage
まあ、そうなんだけどね。
うん。
あとなんかさ、いまいちじゃない?なんか、作ったほうが確実においしいみたいなない?なんかその。
Takaya Deguchi
まあ、それはどれもそうじゃん。
kudakurage
いや、でもさ、カップ麺は割とお湯注いで食べたら、もうそれで割とおいしいってなるじゃん、なんか。
Takaya Deguchi
あー。
kudakurage
なんか、僕の感覚的にカップ焼きそばは、なんか作ったほうが絶対、もう段違いでおいしいなっていう気持ちになっちゃって。
Takaya Deguchi
あー。
kudakurage
食べないかったんだよね。
Takaya Deguchi
うん。カップ麺は食べるんですか?
kudakurage
カップ麺はまあ、そんなにカップ焼きそばはもうあれだけど、カップ麺もそんな食べないですよ。
でも、ただ、なんかたまにさすがにめんどくさいなっていうとき、なんか作るの。
だるいなとか、もう早く食べたいなとか、忙しくてなんかやってる暇ないなっていうときは、たまにこう常備してるやつをまあ食べるぐらい。
Takaya Deguchi
うーん。
kudakurage
そんなしょっちゅうじゃないけど、カップ麺も。
Takaya Deguchi
カップ麺ちょっとあんま食べないんだよな。
kudakurage
いや、なんかカップ焼きそばを最近なんか食べたんだよ。
うん。
その、僕はもうカップ焼きそば二度と食べないと思ってたんだけど。
うん。
その食べた理由が、なんかなんかで、何で見たのかな?
たぶんYouTubeなんだろうな。YouTubeショートとか。
Takaya Deguchi
うん。
kudakurage
なんかこの、カップ焼きそば作るときってさ、まあお湯を入れるじゃん、まず。
うん。
で、待って、3分ぐらい待って、で、なんかあの湯切りして、で、ソースかけてとか、で、混ぜてとか、ふりかけかけてみたいな、そんな感じじゃないですか、だいたい。
うん。
でも、ソースをかけて、混ぜて、で、そこで電子レンジ入れるとうまくなるっていうのをなんか見たんだよ、情報で。
Takaya Deguchi
うんうん。
kudakurage
電子レンジ1分ぐらいかな、まあ加熱するみたいな。
うん。
で、試してみた。まあ、ほんとかなとか思って、まあ、最近のそのカップ焼きそばそもそも食べてないから、なんかもしかしたらなんかすごい別の進化をしてるのかなとかっていう期待もありつつ。
Takaya Deguchi
うん。
kudakurage
食べてみたんです、その家で。
Takaya Deguchi
うん。
kudakurage
そしたら、レンチンするのやばいっすよ。
Takaya Deguchi
おいしい。
kudakurage
まじで変わる。
Takaya Deguchi
へえ。
kudakurage
すごい変わった、なんか。
Takaya Deguchi
え、どこでレンチンするって言いました?
kudakurage
お湯入れて、
うん。
湯切りして、で、ソースかけて、混ぜて、レンチン。
Takaya Deguchi
えー、蒸すってこと?
kudakurage
なんかね、たぶんやっぱり湯切りがまず甘いんだよね、その大体、大体の場合において。
Takaya Deguchi
うん。
kudakurage
湯切りが甘いから、その水分をなんかこう飛ばすっていうのと、あとその麺自体にそのお湯以上の火力で加熱するっていうのがすごく重要なんじゃないかなと思ってね。
Takaya Deguchi
うーん。
kudakurage
別にレンチンじゃなくてもたぶんいいと思うんだよ、普通にフライパンで焼くのでもいいと思うんだけど、まあレンチンの方が楽っていうだけなんですけど。
Takaya Deguchi
うん。
kudakurage
それやるともう全然麺の食感が違うんですよ、なんか。
Takaya Deguchi
うーん。
kudakurage
とかあの、そのなんかちょっとやっぱりさ、湯切り大体ちょっと甘い感じになるじゃん、なんか。
うん。
なんかちょっとビチャハッとした感じになるからさ。
うん。
なりがちじゃないですか、なんか大体カップ焼きそばって。
Takaya Deguchi
うん。
kudakurage
あの感覚が全くなくなるから、すごいうまくなる。
Takaya Deguchi
うーん。
kudakurage
これね、試してみてもらいたい、ほんとに。
Takaya Deguchi
なるほど。
kudakurage
めちゃくちゃ変わるから。
僕、これ最初その食べたときに、まあ普通に作って、でレンチンして食べたらうまかったから、これはレンチンがうまかったのか、それともなんか今のカップ焼きそばが進化してるからうまいのかって分かんなくなっちゃったんだよ、その。
Takaya Deguchi
うん。
kudakurage
だからちょっともう一個買ってきて、でそのレンチンする前のやつとそのレンチンしたやつ食べ比べできるようにして食べたら全然違った。
そこまでやった。
Takaya Deguchi
うん。
kudakurage
全く違った。
これほんとね、試してみてもらいたい。
へえ。
マジで1分レンチンするだけで全然違うから。
へえ。
Takaya Deguchi
確かにべっちゃべちゃになるもんな。
kudakurage
そうそう、なんかすっげえ頑張って振ってさ、こう湯切りしてもやっぱりちょっとべちゃっとした感じになりがちじゃん。
あれがなくなって、麺がなんかね、もちもちってした感じになるんだよ、なんか。
Takaya Deguchi
うーん。
kudakurage
レンチンすると。
へえ。
これね、ほんと1回試してみてもらいたいんだよね。
カップ焼きそばとカップ麺の違い
kudakurage
へえ。
っていう最近の驚きの話でした。
Takaya Deguchi
UFOは割と好きですけども。
kudakurage
ああ、僕もUFOかな、一番好きなやつ選べって言われたら。
Takaya Deguchi
焼きそば弁当って知ってます?
kudakurage
ああ、知ってる、焼きそば弁当。
Takaya Deguchi
うん。北海道に限定なのか。
kudakurage
あれ北海道限定なの?
Takaya Deguchi
いや、よくわかんないけど、北海道によくあるカップ焼きそばなんですけど。
うん。
まあ、なんか湯切りした湯でスープを作るっていうやつね。
kudakurage
ああ、はいはい、スープ作るやつね。
Takaya Deguchi
うん。
それはよく食べてましたね、大学の時。
ああ。
kudakurage
なんか僕も大学生の頃食べてた気がするな、焼きそば弁当を何回かスープ作れるやつ。
Takaya Deguchi
焼きそばすごい匂いするじゃないですか、カップ弁。
kudakurage
すごい匂いするね。
Takaya Deguchi
なんかあれを大学の教室の中で食べてる人がめっちゃいて、めっちゃ匂いが充満してたなっていう思い出がある。
焼きそばの方がむしろ好きだったな、カップ弁より。
kudakurage
あ、そうなんだ。
うん。
Takaya Deguchi
今考えると単に味が濃いからな気がするけど。
kudakurage
ああ。
Takaya Deguchi
ちょっと今のはちょっと重いですね、なんか。
重い?
重くないですか?UFO食べたいなってならないな。
kudakurage
まあ、焼きそば食べたいなってならないってことじゃん。
Takaya Deguchi
いや、焼きそばはたまにありますけど、カップ弁特に重いイメージがあるんです。
kudakurage
そんな買わないと思うけどな。
Takaya Deguchi
なんか具が少ないからソースの味が出る気がくるじゃないですか。
kudakurage
まあまあそれはそうかもね。
なんかでも本末転倒なかもしれないけどさ、具が少ないじゃん。
だから具を炒めて追加しましたからね。
Takaya Deguchi
もう焼きそばでいいじゃん、そこまでやるなら。
kudakurage
焼きそば作れって話してたんだけど。
Takaya Deguchi
そこまでやるなら焼きそばでいいじゃん。
kudakurage
だからね、美味しかったね。
Takaya Deguchi
そこまでやるならもういいじゃん。
kudakurage
キャベツと豚肉炒めて追加して。
Takaya Deguchi
いや、そこまでやるなら単なるカンメンでしょ。
kudakurage
美味しい焼きそばになったね。
レンチンもしてもちろん。
Takaya Deguchi
ソースは?
kudakurage
ソースはソースとかは全部あるよ。
Takaya Deguchi
ついてるやつ。
kudakurage
そのまんまでついてるやつだけど、具だけね。
まあちょっと塩コショウ。
Takaya Deguchi
ソースもあるでしょ。
kudakurage
なんならあれだもんね。
だってもう生麺から焼きそば作ってるような人間だからね。
じゃあなんで。
いや、でもいい。
これはね、ほんと発見だったね。
Takaya Deguchi
電子レンジのやつは。
kudakurage
ソースをかけてからチンする?
そうだね。
Takaya Deguchi
ソースかけてからだね。
kudakurage
なるほどね。
一応ソース分のやっぱ水分もあるからさ。
その辺もいい感じに麺に吸わせるのと蒸発させるのみたいなで。
Takaya Deguchi
それはありますよね。
湯切りしすぎてあんまソースが混ざんないみたいな。
kudakurage
あー、ある?
Takaya Deguchi
ある気がする。
kudakurage
そうなんだ。
あんまりわかんないけど。
Takaya Deguchi
あったような気がする。
kudakurage
カップ麺でもあんま食べないんだね。
Takaya Deguchi
食べないっすね。
kudakurage
僕あの丼麺割と好きだから。
割と常備していること多いですけどね。
Takaya Deguchi
カップ麺、こないだあの日の子行った時?
うん。
あの時食べたのが数年ぶりだった気がする。
kudakurage
数年ぶり?
Takaya Deguchi
うん。
kudakurage
それは食べてないね、だいぶ。
Takaya Deguchi
うーん、なかなか食べるなんないっすね。
kudakurage
じゃあどうすんの?なんかすごいめんどくさいけどどうしようかなみたいな食べよっかなみたいな。
外食べに行くの?
Takaya Deguchi
食べない。
kudakurage
いやでもお腹空いてるけどみたいな。
Takaya Deguchi
まあ、ウーバーしますね。
kudakurage
あ、ウーバーするんだ。
うん。
ウーバーか。
ウーバーはしないな。
Takaya Deguchi
うん。
まあ、あとはなんかホットモッドとかそういうとこ。
kudakurage
あー。
Takaya Deguchi
うん。
kudakurage
近くにある?
あるある。
Takaya Deguchi
はいはいはい。
kudakurage
まあまあまあ、そういうのもあるか。
Takaya Deguchi
うん。逃げ出るのめんどくさい時はウーバーですね。
まあ最近ナッシュ食べてるから。
まあナッシュだいたい家にあるから。
kudakurage
うん。
Takaya Deguchi
あれが一番手軽ですね。
kudakurage
まあでも常備してないとあんまり食べないのかもな。
まあそんなこともないのかな。
コンビニ行って買ってくるとかっていう人もいるのかな。
Takaya Deguchi
うーん。
あえて食べようってならないな。
いやー、もてまさんはそんな好きだったと。
kudakurage
え?
Takaya Deguchi
そんな好きだったと。
カップ麺は。
kudakurage
カップ麺は別に食べますけどね。
そんなめちゃくちゃ食べるわけじゃないけど。
どん兵衛は割と常備してあるからね。
Takaya Deguchi
やっぱ結局なんか物足りなくて何か追加したくなっちゃうんだよな。
あー。
そうすると、いやー作ったほうが良くないってならない。
さっきもてまさんが言ってた。
kudakurage
うーん。そうかな。
どん兵衛…焼きそばはちょっとね具があれだったからあれだけど
どん兵衛は割と具がちゃんとしてんじゃん。
だからそんな追加して…
Takaya Deguchi
それで言うとやっぱカップ麺食べるなら焼きそば派だったかもしれないですね、僕。
kudakurage
あ、そうなんだ。
Takaya Deguchi
カップ麺はあんま食べてこなかったかもしんない。
kudakurage
なんかでもそれもそれで珍しくない?
そうなのかな。
珍しい気もする。
塩焼きそばとかよく食べてましたね。
塩焼きそばね。はいはいはい。
どん兵衛のさ、どん兵衛の話ばっかなっちゃうんだけどさ、僕の場合。
どん兵衛のさ、かき揚げあるじゃん。
Takaya Deguchi
はいはいはい。
kudakurage
あれの食べ方に僕結構こだわりがあってさ。
多分食べ方いろいろあるじゃん、あれって人それぞれ。
出口かなったらどう食べる?
Takaya Deguchi
かき揚げをどうするかって話?
kudakurage
かき揚げをどうするか。
できました。で、かき揚げがまだ外にあります状態なのか、
作る時にもう入れるのかとか。
Takaya Deguchi
後から入れますね。
後から、もう。
見積もりの責任分岐点
Takaya Deguchi
全部入れるか。
ボンと入れる。
全部浸らないように入れる。
kudakurage
どういうこと?どういうこと?
Takaya Deguchi
全部浸らないように入れる。
下、なんていうの、ジョボンとはしないっていう。
kudakurage
軽く乗せるぐらいの感じだよね。
僕、昔からなんですけど、軽く乗せるのも嫌なんだよね。
Takaya Deguchi
だから、食べる時につけるみたいな。
分かりますよ、そういう気持ちは。
kudakurage
食べる時につけて、つけたとこだけ食べるみたいな。
Takaya Deguchi
うん、分かるよ。
kudakurage
ことをやってて、あんまりでもそういう人もいないから、ちょっと特殊なのかなっていう気も。
Takaya Deguchi
面倒くさいですからね。
kudakurage
面倒くさいかな。
Takaya Deguchi
一回置いとかなきゃいけないじゃないですか。
kudakurage
まあまあまあ、そうね。
蓋とかに置いてね。
Takaya Deguchi
基本サクサクで食べたいのは何でもそうですけどね。
かき揚げも、一回軽く油で炒めると、よりかき揚げっぽくなるとかあるんだよね。
kudakurage
よくやりますね。
普段はやんないよ、そんな別に。
Takaya Deguchi
でも一回そういう情報を見て、ちょっとやってみるかってやったことある。
kudakurage
そのうちカップ麺なのに鍋で煮出したりするから。
Takaya Deguchi
意味わかんない。
kudakurage
意味わかんないよね。
Takaya Deguchi
普段からそんなことはしないよね、さすがに。
そこまでやるなら、作ればいいじゃんって。
kudakurage
いや、その通りなんだよ。
それは。
でも、焼きそばの1分レンチは試してみてもらいたいですね。
Takaya Deguchi
それぐらいだったら手軽でいいですね。
kudakurage
そうそう、それぐらいだったらね。
それはね、ほんと違ったんで、これはやる価値あるなと思いましたね。
Takaya Deguchi
なるほど。発想がなかったですね。
kudakurage
発想ないよね、そんな。
Takaya Deguchi
じゃあ、本編に行きますか。
kudakurage
はい。
Takaya Deguchi
今日ちょっと渋い話しようかなと思って。
kudakurage
うん。
Takaya Deguchi
三つ盛りの話。三つ盛りのデザイン。
kudakurage
渋いね。
Takaya Deguchi
渋いですよね。
kudakurage
渋いな。
でも結構最近、この三つ盛りのデザイン大事だなって思ってて。
Takaya Deguchi
クライアントワークやり始めて、真面目にやり始めて1年ぐらいなんですけど、個人も合わせてね。
で、やっぱその三つ盛りのデザインって言ってるのは、三つ盛りショーのデザインのことなわけじゃなくて、三つ盛りという行為全体のことなんだけど、
広い意味での三つ盛りね、金額とかもそうだし、座組、誰とどうやるのかってところもそうだし、
どうスコープ切るのとか、あとはスケジュールどうするのとか、そういうことを全体合わせて三つ盛りって今言ってるんですけど、
そこミスって炎上を仕掛けるとか、品質下がるとかっていう風になるなっていうのを結構思うことが多くて、この1年ぐらい。
で、僕自身個人でやる仕事とかだと、ここがPMというか、契約する立場というか。
で、他の人も合わせて一緒にチーム組んでやるみたいなケースもあるんですけど、そういう時にどういう三つ盛りにするのか、座組にするのかっていうところをミスって後悔するみたいなことがちょいちょいあったんですよ。
だからこの三つ盛りっていうのをどう設計するのかっていうのが、回り回っていいものを作るっていうところにつながってくるなという風に、より思うようになったんですよね。
で、とはいえそれ以前もちょいちょいフリーランスでクライアントワークやってたけど、あんまそういうこと考える必要なかったんですよっていうのは、一人で完結してたし、大体の仕事が。
あと大体順位任でやってたから、月いくらで終わりみたいな。
だからそんな別に見積もる必要もなかったというか、だったんですけど、最近割と農品型、委任型の仕事とか、あと複数人で、自分だけじゃなくて他の業務委託の人とか、合わせてチーム組んで複数人でやるとかっていうのが増えてきてて、
そうするとやっぱりどう見積もるかとか、どういう作業でやるかっていうところを考える必要になったんですよね。
てかもたやまさんそういう仕事あります?
kudakurage
あんまりないですね。
Takaya Deguchi
順位任が多い?
kudakurage
そうですね。
だから、もちろん順位任だから見積もらなくていいって話じゃないんだけど、大体どれぐらいのスケジュール感とかさ、どれぐらいのコースかかりそうかみたいなのは考えないといけないじゃないですか。
無限にだからお金使っていいみたいなことじゃないから。
だからその辺はもちろんある程度考えたりはすることはあるけど、でも基本納品ベースではないようにしてることが多いからな。
Takaya Deguchi
そういうポリシーでやってるっていう感じですよね。
kudakurage
場合によっては全然あり得ますけどね、その納品ベースにするっていうことも可能性はなくはないけど、
でもその仕事のスタイルとしてどういうふうにやるかっていうところだと思うんだよね。
作って終わりにするのか、ある程度継続的にやっていくのかとか、その辺も絡んでくるような気がするから、
だから僕はどっちかっていうと時間ベースでっていうふうにして長く付き合うっていうとか、
一緒になって考えていくっていうふうにした方がいいかなっていうふうに思ってるみたいなところがあるような気がしますね。
Takaya Deguchi
この辺も結構やるものによって変わってくることもあるじゃないですか。
サービス立ち上げとかだとだいたい継続していくから最初から順位にしたほうがよかったりするけど、
ブランディングとかだと割と切り出しやすかったりするから、
またブランディング完了まで一回委任形式でドンとやって、
あと必要であれば美しくサポートしますみたいな。
こういうのなんかクックパッドにいるときとか、
要はでかい会社にいるときってそんな考えもしなかったんですけど、
っていうのはやっぱあの会社は内製の会社だったしデザインエンジニアも基本多かったから、
外の人とあんま仕事するってこと、物作る上ではそんななかったと思うんですけど、
スタートアップ行って前の会社とかキベラとかそうなんだけど、
発注者の立場になると徐々にそういうの考えることが増えていってて、
正社員作業そもそもむずいから、
エンジニアデザイナーを外から手伝ってもらうみたいな形式じゃないと仕事が進まないなっていうことになってきて、
今僕は受託の立場ですけど、逆に当時は発注側の立場だったんですけど、
そういうときもやっぱこうどういう座組みを作るかとか、
そもそも相場がどれくらいか掴むとかそういうところを考えることが増えていったなと思ってて、
これまで一応昔スタートアップにいた頃は発注側の視点に立てたし、
今タクラムとかだとデザイン会社っていう視点で見てるし、
逆にWeb3のタネっていう会社やってるのは、
あそこは今開発ベンダーとして立ち回ってることもあるんですよね。
デザインはやらずに開発Web3周りの開発だけを受けようみたいな。
それぞれの視点で視点切り替えながら見ることが多いんですけど、
やっぱりむずいなと思うのは見積もりの中でもどこまで責任を負うのかっていうところ、
責任分岐点をどこに置くかっていうところが結構難しいなと思うところがあって、
っていうのは今自分がデザインもエンジニアリングも一部やるからっていうことなんですけど、
デザイン会社だったらデザインに責任を持つのはそうなんですけど、
でも結局デザイン納品したものがどこかで実装されるわけで、
実装されたところで品質が落ちるとかそういうところもあるからそこもサポートしたいよねってなるじゃないですか。
開発ベンダーっていう立場だとやっぱり誰かがデザインしたものを実装するってことになるから、
そもそもデザインに関しても責任を持つ、
デザインに関しても口出しできるような体制じゃないと言われたものを作るだけみたいになって、
その言われたものがすげえ品質良ければいいんですけど、
品質悪いデザインが渡ってきた場合、それで開発するのはめちゃ大変になるみたいな。
だからデザイン会社であっても開発ベンダーであっても、デザインにも開発にも両方責任を持ちますっていうことができたらいいんだけど、
でもそれって単に責任が大きくなるってことだから、
なかなか組織の体制的にできなかったりとか金額的にできなかったりとかするわけなんですよね。
持たない、開発会社がデザインにも責任を持ちますっていう、
フルで責任を持つか開発にしか責任を持ちませんっていうゼロか一かじゃなくて、
どこまで責任分岐点を置くかっていうところが結構見積もりする上で大事だなって思うことが最近あるんですよね。
そうだね。
最近思うのはそういうときに、例えば開発ベンダーとして僕がWeb3の会社だと立ってて、
そうするとデザインがどっかの他の会社に入ってくるわけなんですよ。
そのときに完全に僕らデザインも関して責任を持ちますっていうケイパビリティは今僕らがやってるWeb3の会社にはないので、
どっかに依頼するんですけど、
そういうときに完全にお任せするっていうよりは多少は僕がディレクションするとか、
マネジメント多少デザイン会社に対してもするとか、
そういうところでマネジメントとかディレクションのフィーをいただくとか、
そういうような多少力が及ぼせるというか、多少サポートできるみたいな関係性を作るのが結構大事だな。
それはデザイン会社という立場でもそうなんですけどね。
一社での受託の有用性
Takaya Deguchi
開発ベンダー側に多少サポートするとか、
その責任分岐点をどうするかって悩むっていうところがまず一つあるのと、
あともう一個悩むポイントとして、
一社で全部を受けるのか、あるいはクライアントに一部をつけてもらうのかっていうところ。
例えばエンジニアが自分の会社に3人いますと、
でも人が足りなくなってきてデザイナーも追加してくださいとか言われたと先方からね。
そういう時に自分の会社の下につけるのか、クライアント側で契約してもらうのかっていうところとかも結構悩ましいなと思うところで、
自分の会社で例えば誰かデザイナーを探してきてデザインに契約しますってなると、
コントロールはしやすいわけなんですよ。
マネジメントはしやすくなるんですけど、
責任は増えるわけなんですよ。
逆にクライアント側につけてもらうと責任は増えないけど、
その分なかなか直接何かを依頼するってことが関係性的に難しくなって、
ディレクションとかマネジメントがしづらくなるみたいな。
僕の最近の結論としては、一社でなるべく受けた方がいいなってところ。
雑組をなるべくシンプルにした方がトータルいいだろうなっていう風なことを思うに至ったんですけど、
それもなかなか難しいなと思うところなんですよね。
さっきの責任分岐点の話と同じように。
プロジェクトマネジメントの重要性
Takaya Deguchi
結局最近思うのは、この間エヴァの本、プロジェクトシーンエヴァンゲリオンの時も話した気がするけど、
PMに立つ人がどこまでケツ持ちできるかっていうところに尽きるなと思うようになっていて、
ケツ持ちしてあげられるなって思うなら、やっぱり一社で受けてなるべく雑組をシンプルにするっていうことの方が
トータルの回り回っていい結果になるなというのを最近思う。
今日この頃なんですよ。
この辺のプロジェクトのいろんな課題とか目的によって、
自分ができることと自分が責任を持てることっていうのが結構違うなって思うようになって、
自分がどこまで責任を持つべきかっていうところの分岐点をどうデザインするのかっていうのが、
ものづくりの良し悪しに関わってくるなと思うことが最近多々あるんですよね。
っていう中でちょっとPM、平拓也はプロジェクトマネジメントみたいな話なんですけど、
それをどうやるのかっていうのを改めてちょっと最近興味が湧いている、
今日この頃で人が増えても早くならないっていう本を読んだっていう話で、
それをちょっと紹介しようかなという感じですね。
kudakurage
ちなみに一社の方がいいっていう話って、
2つ観点があると思う、思い当たるところであって、
お金っていう部分とマネジメントっていう部分があるじゃないですか、多分。
その両方って話なんですか?
Takaya Deguchi
両方ですね。
kudakurage
そう?
見積もりのデザインについて
Takaya Deguchi
大きいのはマネジメントだと思いますけどね。
kudakurage
それはそうだよね。
Takaya Deguchi
関わる会社が増えれば増えるほど見えないマネジメントが発生してくるから。
僕が思うに至ったのは関係者が増えれば増えるほど見えないマネジメントとか見えないディレクションが発生するから、
そこも含めてやるのであればお金をもらった方が適切だと思ったんですよ。
そうするとやっぱり一社で受けた方がいいなというのに至った。
kudakurage
実際みんなどういうふうにしてるかわかんないけど、
やっぱりお金、最初に予算つけてもらうの結構難しいじゃないですか、多分。
適切に見積もるのって。
難しいですね。
だから割と僕はそういうふうにいろいろ他の人に手伝ってもらうときも、
ちょっと理由とかを説明しつつ、
この人にもちょっと新しく伺って手伝ってもらおうと思ってるんですけどみたいな形で、
追加ですよね、どっちかっていうと。
僕ら、仕組み上というか、
経理上、僕らのところに追加で予算というか見積もりをつける場合もあるし、
別で契約してもらうっていう場合もあるんだけど、
そこはそんなに自由にできる方がいいなと僕は思ってるっていうかね、
完全にお金をひとまとめにするっていうふうにガッチリやるよりは。
もちろんクライアントさんがどう考えてるかとかっていう意向もあるから、
一概にどうするのがいいとかどうしたいっていうふうに思って、
それがコントロールできるわけでもないんだけど、
みんなでもどうしてるんだろうね。
最初にガッツリ見積もり作って、ある程度予算持って、
それを分配していく感じでやっていくのか。
Takaya Deguchi
次回って言うと僕が今言ったのは、後から追加するにしても、
自分の会社の下についてもらった方がいいなという感じね。
kudakurage
それは何か責任的な部分みたいなこと?
Takaya Deguchi
相手に、クライアント側についてもらってもいいんだけど、
結局自分たちがマネージメントしたりディレクションすることになりやすいと思ってるから。
そこが完全にもう手離れしてて、ディレクション、マネージメントしなくていいですよ。
完全にクライアント側でよしなにやってくれますよだったら、
完全に別れてもいいのかなと思うんですけど。
例えば一つのエンジニア、一つのプロダクトを立ち上げますっていうプロジェクトがあったとして、
僕が例えばPMなりをやってるとするじゃないですか。
そこにデザイナーが足りないからデザイナー追加してくださいってクライアントが言ってきたとして、
クライアント側の契約についてもらったとしても、
結局僕がディレクションなり、マネージメントをデザイナーしなきゃいけなくなるわけじゃないですか。
ってなると、なんか意思決めた方がよくわかんなくなるというか。
kudakurage
なんか割とそこうまくやっちゃってたのかな。
Takaya Deguchi
そこは関係性があるところだったら別に何でもいいと思いますけどね。
kudakurage
なんか割とプロジェクトチームとしてみんな一緒にやってくっていうような感じの目線で仕事やってることが多かったから、
なんかそんなにそこを意識しなくても契約の話でしょみたいな。
それ自体はみたいな。
それでしかないみたいな感じだったからあんまり意識することがなかったんだよな。
まあでも厳密に言うとあるのだとは思うけどね。
Takaya Deguchi
最近はこう初めましてでやるプロジェクトが多くて、厳密なそういうところを意識しなきゃいけなかったのが多かったんですよね、最近は。
なんかふんわりやれるのが理想ではあるんですけど、ふんわりなかなかやれないなと思うことが多かった。
だから僕もお盆に至るまでのやってたプロジェクトは割とさっきも田山さんが言ったような感じでやってたんですけど、
なんかなかなか難しいなと思うことが増えてったんですよね。
kudakurage
お金の取り回しの部分で難しいって感じたことないから、それは気になるなと逆に。
Takaya Deguchi
お金の取り回しというか、クライアント側についてる人のマネジメントやディレクションもこっちがやってるなみたいな感覚。
で、それって正当にフィーをもらうべきだろうなと思うことがあるというか。
kudakurage
それもらってなかったの逆に?
そこがなかなか相手につけついてるともらいづらいなと思ったっていう感じ。
どういう立場で入ったかによるよね、でもそれって。
最初に別に誰か他の人にいるかどうか別としてプロジェクトマネジメントもやりますっていう形で入ったのか、
単純に開発しますって感じで入ったのかによって多分変わってくるんじゃないかな。
Takaya Deguchi
あと僕が今言ってる話、前提そうだ。
異人型の話なんで。
10人じゃなくて、10人だったら結構何でもやれますみたいな感じで入るじゃないですか。
kudakurage
はいはいはい、まあそうだね。
Takaya Deguchi
でも異人だとある程度こうこうこうやります。
見積もりでこれこれいくらですみたいな見積もった上でやるじゃないですか。
kudakurage
で、その状態で追加があった場合にどうするのかっていう。
なんかでもそれは僕の場合もでも適宜相談するような気がするな多分。
やってたやつとしては、相談するか切るかどっちかじゃない。
Takaya Deguchi
切る。
kudakurage
切るっていうのはもう諦める。
Takaya Deguchi
どういうこと?
kudakurage
まあ要はだからPMやんなきゃいけないなっていう感じになってもやらないってことだね。
契約上できないからね。
Takaya Deguchi
まあそれはありますよね。
kudakurage
まあそれを選ぶことはあんまりないと思うけど、
まあでもどっちかだよね、だから追加するか。
でもそこはやっぱ説明してやってるような気がするな過去やってたやつで言うと。
Takaya Deguchi
いやまあ大体説明したらなんとかなるんですけど、
まあならない相手もいたりすることあるので、
まあ原理原則的に考えるとどうかなっていう話ですね。
kudakurage
そうだね。
まあそういう相手の場合はだからさっきの切るっていう方向になっちゃうんですよね。
なんかちょっと残念な結果になるみたいな。
Takaya Deguchi
いやでも切れる立場ならいいけど、
そのそこもやっぱ責任分岐という話だと思ってて、
自分デザイナーエンジンに入っていたら、
そこは切るっていう選択肢ができると思うんですけど、
例えば自分がPMみたいな立場でやってたとしたら、
なかなか難しいじゃないですか、そこって。
kudakurage
いやPMで入ってるんだったらその分取ってるでしょって。
取ってなかったのかそれを。
Takaya Deguchi
いや、なのでなんか公式というか、
分かりやすい状態で取れるようにした方がいいんじゃないかっていう話ですね。
その交渉とかそういうことじゃなくて、
例えば自分の会社の方に契約主体を
自分のところの一時受けに全部まとめてしまって、
その方が自分がコントロールしやすいっていう話。
相手の方につけると一時交渉なり何なり、
相談なり何なりが発生するので、
そういうのはなくした方がシンプルになるっていうような話です。
kudakurage
でもPMとして最初入ってるんだったら、
最初に時点で割と見積もり取ってるんじゃないですかその分。
Takaya Deguchi
取ってて追加が発生したらっていうケースの話。
kudakurage
さらに追加がってことか。
Takaya Deguchi
だいたい追加が発生すると思ってて、こういうのって。
kudakurage
そう?分かんない。
追加の要素と管理
kudakurage
でも発生してんのかもな。
割と僕の場合はエイエでやっちゃうときあるからなそういうの。
Takaya Deguchi
エイエイヤ。
kudakurage
もう頑張る。
頑張って埋める。
Takaya Deguchi
頑張らないっていう。
頑張りをしないっていう。
Takaya Deguchi
適切にやるんだったらその方がいいんだと思う。
結局頑張りは必要なんだけど、どっかで。
だけど最初からそれ前提にしちゃうとダメなんで。
だから結構最近追加もだいたい追加発生するから、
最初に見積もってても、後々こういう機能欲しいとか、
スケジュール元キュッとして欲しいとか、
追加の要素が発生するじゃないですか、だいたい。
kudakurage
それをどうしようかなっていうのも悩ましいところではありますよね。
そうね。
割と最近だったらどうなのか分かんないとか、
もうちょっと大きい、たとえばタクラみたいな、
大きい会社だったらどうかとかっていうのは分かんないけど、
僕も一応昔、自宅会社で仕事してたんで。
で、自宅会社って言っても田舎の広告代理店みたいなとこだったから、
相手してるお客さんがそこらのお店のおっちゃんみたいな、
そんな人ばっかなわけですよ。
だからもうみんな好き勝手言うんだよね、やっぱり。
だから見積もりは割と正しくある程度取って、
若干多めに取ったりする場合もあるけど、
その余裕、時間的に余裕を持ってって。
ただ見積もり自体でどうこうするっていうよりは、
もう割と工数をどう管理していくかみたいなのをやってた気がするな、
その時はね。
Takaya Deguchi
そうですよね、分かります。
kudakurage
だからある程度もうスケジュールで、
僕ら自体もスケジュールの稼があるけど、
お客さんにもその稼を理解してもらって、
こういう感じで進めないともうここまでにリリースできませんみたいな。
とかある程度お金がかかっちゃいます、それ以上いくとみたいな。
っていうのを理解してもらって進めていく。
で、ある程度どっかで節目を作って、
もうここまではフィックスですみたいな。
どんどんやっていくみたいな。
やり方はすごいやってた気がするね。
Takaya Deguchi
僕も最近それに至りましたね。
kudakurage
いや、そうだよ。
そうしないと結構厳しい、
移任契約とかっていうのは。
Takaya Deguchi
結局時間とか予算とか品質とかスポープとか、
そういう変数あるじゃないですか。
一番厳しいのは時間だから。
kudakurage
そうだね。
Takaya Deguchi
予算は増やそうと思えば増やせたりする可能性もあったりするけど、
時間はどうやってもどうにもならないところが多い。
kudakurage
そうだよね。
お客さんがいいって言っても僕らがダメの場合もあるしね。
次の仕事が入っちゃってみたいなとか。
だから結構時間をどうやっていくかっていうのは難しいよね。
その辺はだからできるだけもう理解してもらって、
もうトレードオフですよね。
これ入れたかったらこれ外すとか。
そうですよね。
Takaya Deguchi
そういう感じになりがちですよね。
あとなんか全然違うところでなるほどなと思ったのは、
自分がリノベしたとき、内装業者にリノベを依頼したとき、
施工を依頼したときに、
kudakurage
その内装業者は前金と後金で2分割請求だったんですよ。
Takaya Deguchi
で、前金でおそらく内装業者の下についてる職人さんたちに対して、
もうやっぱお金払ったりしてると思うんで、
そういうところにキャッシュフローを回しつつ、
後金で現場解体してみたらわかる、
上ぶれとか下ぶれとかあったりするじゃないですか。
そういうところを吸収しますみたいな話をしてて、
なるほどなとそこで思いましたね。
キャッシュフローの課題
Takaya Deguchi
なんでまあそういうような、
さっき言った1社でまるっと受けますみたいな対戦した場合、
キャッシュフローをどうするかっていうのは結構悩ましいなと思うところがあって、
元はその住民で、移民でガツッとやってたとしても、
自分の会社から誰かエンジニアなりデザイナーに依頼するって時に、
住民でやるケースとかもあったりするから、
そうすると支払いサイクルが合わなくて、
払えなかったりとかちょっと待ってもらったりとか、
まあ資金に余裕があればいいからね。
会社に運転資金があればいいんだけどない場合とか、
どうしようかなとかね、思うケースがあって。
だから本当は上ぶれ下ぶれとか、
フェアの場合もあるから、
後請求の方がやりやすかったりするかもしれないけど、
なかなかそれ難しいなと思うから、
内装業者みたいに二分割請求とかそういうのもあったりするのかなっていうのは、
やったことないけど思ったりしましたね。
一度完成しても終わりではない
kudakurage
まあ確かにね、キャッシュフローをうまく回すっていう意味では、
それも一つの選択肢としてはあるかもね、確かに。
Takaya Deguchi
最近1年ぐらいお付き合いしてるクライアントは、
割と3ヶ月で、3、4ヶ月で契約切ったり、
3、4ヶ月単位で委任でやってたりするんですけど、
そこはもう上ぶれしますよっていう前提でやってたりしますね。
kudakurage
まあなんかでもいろいろですけどね、
やっぱりそれ契約どうするかって、
僕もいろいろな会社さんとお仕事をさせてもらったけど、
逆になんかめちゃくちゃ大きいところだと、
Takaya Deguchi
ある程度もうざっくりとした予算で、
kudakurage
ある程度上ぶれ下ぶれしても問題ないみたいな感じだったりするし、
もちろんね、ガッチリしてるとか、
ある程度予算決まってるっていう会社さんもあったりするから。
Takaya Deguchi
逆に超大きい会社だと予算消化したいみたいなモチベーションの場合もあるし。
kudakurage
そういう場合もあるからね。
僕らもそういうので1回依頼を受けたことあるしね。
予算消化のために研究開発したいんだけどみたいな。
Takaya Deguchi
超大きい会社だとね、そういうのもある。
スタートアップ会社だと結構コストパフォーマンス厳しいところが多いから。
kudakurage
そうだね。できるだけコンパクトにどうスピードを早く出せるかみたいなところが大きいからね。
スタートアップの場合はだいたい移任契約にするってことはあんま少ないんじゃないですかね。
だからそういう意味でも。
Takaya Deguchi
そうね。
kudakurage
なんか何でもやらなきゃいけないことの方が多いからさ。
Takaya Deguchi
そうですね。
っていうので前抜きが長くなったんですけど、
人が増えても早くならないという。
kudakurage
なんか僕その本最近見たな。
何で見たんだろう、SNSかなんかで見たな。
Takaya Deguchi
ちょっと話題になってたかもしれないですね。
この本を書いてる人はソニックガーデンっていう会社の代表の人で、
ソニックガーデンっていうのがSIRなのかな、カテゴリー的には。
なんですけど、納品型でやるのじゃなくて、月額で付き合い続けるっていうスタイルでSIRをやるっていうのの先駆けみたいな会社ですね。
北欧暮らしの道具店の社外取締役とかそういうところもやってるみたいですね。
でなんかその、自分がもともとソニックガーデンっていうソフトウェア開発の会社をやってたんだけど、
北欧暮らしの道具店っていう物売りの会社に付き合うようになって、
そういう人たちに対してどうソフトウェア開発とか差別開発ってどういう考え方でやっていくのがいいのだろうかっていうのを改めて言語化してみたっていうのの本らしいですね、これが。
だから割とノンエンジニア向けにソフトウェア開発ってこういう側面があるよねっていうのを説明してるっていうような感じですね。
一応ソフトウェア開発の本なんですけど、デザインとかでも共通する部分はかなり多いんじゃないかなっていうふうに思ってて。
で、結構ソフトウェア開発って歴史的に建築とかそういう業界からいろいろメタファーを参照してる部分があって、
例えばウォーターフォールで作るみたいなものとかも建築とかそういうところが来てたり、
あとは業界構造的にも、SIRという独特の会社がいるのって日本ぐらいだと思うんですけど、
それもゼネコンとかそういうところの構造から来てたりするし、
あとは職能的にもシステムエンジニアとプログラマーみたいな存在が分割されて存在してたりとか、
中にはもっと細かくアーキテクトとかそういうのがたくさんいたりするっていう水平分割に物事をやって、
最後にガッとまとめましょうみたいなそういう進め方が割と建築とかそういう施工業界から参照されてきてるみたいなところが歴史的にあると思うんですけど、
それとはやっぱ違うよねっていうところを主に話してるような感じですね。
で、ざっくり気になったことを言うと、まず一生で完成しても終わりでないっていう話があって、
これはもう当たり前、僕らにとって当たり前の話であるんだけど、
やっぱこの辺、僕も直近1年くらい付き合いしてる会社の人が、もともとファッションとかそっちの文脈の人で、
で、スタートアップ、Web3系のスタートアップ立ち上げてやるみたいな人と一緒にやってるやつがあるんですけど、1個。
それとそこの人と接してると、やっぱこういう完成しても終わりではないみたいな感覚って、
僕らにとって当たり前だけど、当たり前じゃないんだなと改めて思うことがあって、
だから結構一度仕上げたら終わりですみたいなスコープの切り方を最初相談されることが結構あるんですよ。
でもやっぱここって最初いらないよねとか、ここは後から育てていけばいいから、
バージョン1はこれぐらい留めとけばいいんじゃないですかみたいな、
そういう要件定義をもう一回やり直すみたいなところから立ち返った方がいいなと思うことが結構あって、
ここはスタートアップとかに長くいると当たり前すぎるんだけど、
kudakurage
やっぱまだまだそうじゃない感覚ってあるなというのは改めて。
Takaya Deguchi
あとはこの本として結構言われてるのは、人を増やしても早く作れるわけじゃないっていうところで、
さっきの時間の成果が一番厳しいよねっていう話に通じるんですけど、
だったら人を増やしたらいいじゃないっていうような発想で相談されることが結構あるんですけど、
だからそこの感覚が結構、フィジカルなものづくりの感覚だと、
人を増やしたら2倍早く作れたりとかする可能性もあったりするのかもしれないけど、
職人さんを増やしたらそれだけ早く家ができるとかね。
やっぱソフトウェアの場合はそこが一番違うっていうところで、
結構このペースでこのニーズだとこのスケジュール間に合わないんで、
この機能を減らしましょうみたいな話を持ってきたいなと思ってても、
いやちょっと人じゃあ僕が連れてくるんで、
このエンジンのデザイナーも追加でお願いしますとか言われることがあって、
でもそれマネージメントするの結局僕だよなみたいな気分になって、
それはさすがに断ったりするんですけど。
kudakurage
なんかでも極論言うと建築も一緒だと思うんだよね。
Takaya Deguchi
そうそう、分かりやすくそうだと思うんですけど、言ったけどそうだと思います。
kudakurage
だよね。
だってね、じゃあ100階建てのビル作りますって言って、
じゃあ何か100倍に増やしたら一気に何かできるかって言ったらできないわけじゃないですか、やっぱり。
その何か1階ができないと2階は作れないわけでとかっていう風になってくから。
だからそれ切り分けできると思うけどね、ある程度。
切り分けできる部分はあると思うけど、増やせばめちゃくちゃ速くなるとは絶対ならないよね。
Takaya Deguchi
基本100人増やしたら100倍になりますとかそういうことはないですよ、基本は。
だけど倍率というか、人が増やしたら速くなる係数みたいなものは、
ソフトウェアは極端に低い、もしくは位置を割る可能性があるというか、
kudakurage
人が増やした結果生産性が落ちるとか、そうなりやすい構造はソフトウェアならではな気はしますけどね。
Takaya Deguchi
本当に切り分けできる部分っていうのが少ないのかもしれないけどね。
この本にも猫の手を借りたいシーンっていうのが、
フィジカルなリアルな何か製造とか農家とかそういうところではあるのかもしれないけど、
ソフトウェアの場合は猫の手も借りたいケースっていうのはあんまないっていうか、
猫がいた方がむしろ邪魔になるケースの方が多いっていう。
その辺の感覚がこういう業界で仕事しないと分かんないのかもしれないなっていう。
kudakurage
ソフトウェアの場合だと切り分けできてる時点でもうだいぶ完成してるからな。
人増やしたら必ずしも速くならない
Takaya Deguchi
そうそう。
あとはやるだけっていうフェーズに持っていくのが大変な。
kudakurage
とかある程度モジュール化されてる想定の構造がもうできてあって、
切り分けできるようになってるみたいな感じになってるとかね。
Takaya Deguchi
そうそう。
SIとかはSEの人たちがモジュール化みたいなのを頑張ってめちゃめちゃしてて、
その結果下請けとか二次請けとかそういう会社にプログラミングをお願いして、
人を純粋に増やしていけばできますよみたいなのを頑張って持っていってると思うんですけど、
めちゃめちゃ頑張って。
なかなかそこまではできないし、っていうところの違いはリアルなものづくりとはあるだろうなっていう。
だからこの辺、人増やしたいって言われた場合どうするかっていうのを
自分がPMやる立場になった時に考えとかなきゃいけないなっていうふうに思って。
まあそうだよね。
で、とはいえ確かに人増やしたら速くなるシーンもソフトウェアにおいてあると思うんですよ。
その速くなるシーンっていうのはやっぱ優秀な人、端的に言えば。
で、一緒にやり慣れてる人だと思うんですよ。増える、増えた時にね。
だからそう言われた時には自分からそういう人を自分がじゃあ僕がじゃあ見つけてきますよつって、
誘ってやり慣れてる人を呼ぶっていうのが一番いいなっていうふうに思ってて。
kudakurage
まあそれはそうだね。
スコープの切り方が重要
Takaya Deguchi
だからそこで相手任せにしないっていうところ。
多少自分の責任が増えたとしても自分でケツ持ちできる人を連れてくるってところが大事だなと思いますね最近。
で、あとはスコープの切り方の話として、
なんかこれもありがちなのがたくさん作っても生産性が高いとは言えないっていうところで、
一度にたくさん作っておくみたいなことってあんまソフトウェアにおいて良きに働かなかったりするじゃないですか。
kudakurage
一度にたくさん作るってどういうこと?
Takaya Deguchi
事前にいろんなものを想定して作っておく。
kudakurage
事前にいろんなものを想定して作る。
Takaya Deguchi
未来こういう機能が必要かもしれないからこう作っておきましょうとか。
kudakurage
そういうやり方はあんましないね。
Takaya Deguchi
その辺もこの本で書いてあったのは小売りにおいて在庫を抱えるような感じ。
使わない機能を作るっていう。
将来1年後これが必要だから今の段階からもう用意しておきましょうみたいなのは、
本当にそれが必要なケースもあるようするとは思うんだけど、
大体の場合必要なときに必要なものを作ればそれで良いっていうことの方が多いなという。
kudakurage
予定されてればいい。
それを想定するのはいいけどね。
Takaya Deguchi
その予定が変わる可能性が高いっていうことですよね。
kudakurage
本当に予定してる可能性もあるじゃないですか。
絶対これは1年後に追加するみたいな。
それだったら多分ある程度後から追加できるようになってれば別にいいんだけど、
全く無視してやっちゃうとダメな場合ってあるじゃないですか。
そういうのだったらありかもしれないけど、
でも基本あれだよね。
そんなにいろんなことを想定して作るっていうことはしないよね。
必要以上に。
Takaya Deguchi
だから多分未来のロードマップみたいなのは聞いとくのは大事だと思うんですよ。
SaaSだったら将来的に1つのSaaSを成長させていくモデルじゃなくて、
いろんな機能ごとのSaaS、マネ法みたいな。
予算管理用のSaaS、経費生産用のSaaSみたいな。
いろんなものがたくさんあった結果、1つの商品群を構成しますみたいな考え方なんですって聞いてれば、
それ前提にしたそれぞれのプロダクトが連携するようなのを思い描いた上で作り始めるとか。
でも実際作りはしないみたいな。
必要になるときまで。
だからその辺の未来の構想は聞きたいけど、
実際の計画は変わる可能性があるから実行しないみたいな。
なんかその辺が大事なんだろうなっていう気がします。
kudakurage
そうね。
なんかこういうふうに言うと、すごいこう悪いみたいなダーキーな感じに聞こえちゃうかもしれないけどさ。
割となんか僕が自宅、今もやってるんだけど、
昔いた製作会社で自宅やってたときは、
良い意味でクライアントを丸め込んでた気がするね。
良い意味で丸め込むってなんだよっていう話かもしれないけど。
見積もりのデザインに関する話
kudakurage
なんかそこの緩急みたいなのがあるような気がしてて僕。
緩急って言うのかな。
なんて言うんだろう。分かんないけど。
なんかこうやっぱりお客さんとしては、
すごいなんか想定外なことぐらいやってくれた方が嬉しかったりするわけじゃん。
もちろん見積もり通りにできてるのも重要なんだけど、
それ以上になんかこうこれもやっときましたよみたいな感じの方がやっぱ嬉しいわけですよ。
それをいかにこう計画的に作っていくかみたいな。
Takaya Deguchi
なるほどね。
kudakurage
っていう意味でなんかこう、
良い意味で丸め込むみたいなのがある。
僕あるような気がしてて。
Takaya Deguchi
先回りしてこれ必要になりそうだなみたいな。
そうそうそうそう。
まあその辺はエンジニア・デザイナーの力の見せ所な感じです。
kudakurage
あとはそこも見積もりに含まれてるんだけど、
見積もりに多さ、すごい細かいとこまで説明しないじゃん大体。
Takaya Deguchi
はいはいはい、しないです。
kudakurage
ざっくりじゃないですか。
だからそれを実はこう、
これもやる予定なかったんだけどやっときましたよみたいな、
ここも考えてやっときましたみたいな感じで言うと結構喜んでもらえるみたいな。
プレゼンテーションの仕方っていうんですかね、なんかそういう。
Takaya Deguchi
はいはいはい。
kudakurage
っていうなんかテクニックみたいな、
細かいテクニックみたいなのがいっぱいあるような気がする、そこになんか。
それだけじゃないんだけど、
僕はいろいろやってたそういうのなんか昔。
Takaya Deguchi
逆にそれ聞かれたことあったな。
直近やってた案件で、
第1段階、第2段階、第3段階みたいなフェーズが3つに分かれてて、
一見してみると開発項目は後ろのフェーズに行くほど多いんですよ。
機能を羅列するとね。
でも密もった費用的には第1段階が一番かかってて、
第3段階が一番かからなかったりするんですよ。
それ何でですかっていうふうに聞かれて。
でもそれってエンジニアリング的には自然じゃないですか。
最初にいろんなことを想定しておいたりで基盤作っておくから、
そこでは時間かからないけど、
それが一旦出来上がっちゃったら、あんまそんな時間かかんないみたいな。
kudakurage
やるだけみたいになる。
Takaya Deguchi
そう、やるだけ状態に持ってくれば持ってくるほどそんな時間かかんないから、
コースも少なくなってお金もかかんないみたいな。
その辺の感覚ってやっぱ分かんないよなっていう。
そこをね、もてもたに言えば丸め込みじゃないけど、
kudakurage
プレイもちょっとサプライズとして伝えることもできるかもしれない。
あるかな。
Takaya Deguchi
でもその辺の感覚って確かに分かんないよなと思って聞かれて思いましたね、それは。
あとは確かになーと思ったのが、
マネジメントの話で、
社内におけるマネジメントの話で、
人に依存せずに同じ品質で作ることができないっていう話があって、
同じものを作ってもやっぱり何かしら作り方が多少変わってきたりとか、
完全に同じ品質のものを量産するってことができそうに見えて難しいっていうかソフトウェアって。
同じ機能を実現できていたとしても、
やっぱコードの品質がこの人はすごい高いとか低いとかあるじゃないですか。
同じUI作ってもこの人のデザインは変更に強いけど、
この人のデザインは変更に弱いとかあったりするじゃないですか。
で、それが時間が経ってみて分かってきたりするとか、
そういうのってあると思う。
でも一見してみると同じものできてるじゃんみたいに見える。
で、ソフトウェアの場合なんか触ったりとかできるわけじゃないから、
その品質の違いっていうのが表に出てきづらいというか分かりづらかったりするじゃないですか。
椅子だったらね、同じ機能を座れるって椅子だったとしても、
この人の椅子は美しいとか美しくないとか、
この人に座り心地がいいとか悪いとかっていうのは座ったら分かるかもしれないけど、
Twitterクローンみたいなサービスを作ろうってなった場合に、
この人はいいけどこの人は悪いっていうのがなかなか分かりづらかったりするっていうのがソフトウェアだと思うんですよね。
で、そういう時に生産性を測るみたいな時に、
例えばコードを書いた行数で生産性を測るとか、
そういうのはできないよっていうような当たり前の話が書かれてて、
どれだけ手を動かした回数で、どれだけ手を動かした時間でかっていうのでコースを測ることが難しいし、
むしろ一人一人違うっていう前提で、
プロスポーツのアスリートとかそういう人をマネージングするような考え方で取り組む方がいいみたいな、
そういうことが書いてあって。
一人一人同じようなものを作る、完全に同じものを作る職人として、
職人というか生産するロボットみたいな感じでマネージメントすることができないっていう当たり前の話なんですけど、こう言っちゃえば。
こう言っちゃうと当たり前なんだけど、
ソフトウェアの品質と生産性
Takaya Deguchi
ビジネスが強めの会社で働いてたりするとそうなんだけど、
割とエンジニアとかデザイナー組織のマネージメントを、
どれぐらいの生産性があるのかっていうのを客観的に示してくれみたいなことを言われることがたまにあるんですよね、
ビジネス寄りの人からね。
それを間に受け止めてやろうとすると、コードを書いた行数とかデプロイ回数とかそういうような話になってくるんだけど、
そういうのは法律的に無理だよねっていう話。
まだやるとしたら、機能をどれだけデリバリーしたとか、その結果としてKPAがどれぐらい改善したとか、そういうことならいいと思うんですけど、
なかなかこの生産性を測るっていうのはそもそも難しいよっていう話をしてましたね。
だからそれを基にして見積もりをするっていうのがそもそも無理筋っていう。
ソフトウェアが一品ものじゃなくて量産ものというか、同じものが大量、完全に同じものが作れるっていう風な見え方に誤解してしまう。
それなんかすごく難しいと思うんですよ。ソフトウェアってコピーできるから。
同じものを作れるっちゃ作れるじゃないですか、その完全に同じもの。
なんだけど、やってる人のやってる姿というか、あり方としてはソフトウェア工場みたいなものっていうよりは、
一人一人違う人たちがよりクリエイティブな仕事だと思うんですよね。
その工場っていうものとかイメージするものよりも。
kudakurage
だからその辺が見積もりっていうところから見てみると、工場的な見積もりの仕方になってしまうんだけど、そうじゃないよねっていう話がされてました。
見積もりに乗せるのは難しいよな。
Takaya Deguchi
だから工数とか便宜上使うけど、見積もりするときにも。
結局どうやるのがスタンダードかも僕も分かってないけど、結局なんか時間かける単価、最小単位はなのかなって思うんですよ。
この機能作る、この機能デザインするのにどれくらいかかるか、かける時間かける自分の単価。
で、それの積み上げで見積もることが多いんだけど、
kudakurage
まあそれって便宜上操をやってるだけであって、本当は違うよねとも思ったりするじゃないですか。
Takaya Deguchi
そこはもうちょいうまくやれる方法があればいいなとも思うんですけどね。
kudakurage
そうね。難しいな。見積もりに乗せるのは難しいな、ほんと。
見積もりを作ること自体は簡単だけど、それを説明するのが結構難しいんだよな。
そうですよね。
Takaya Deguchi
で、まあ説明するとしたらもう、まあでも説明するのか、説明してるか、やるとしたら。
まあそれで結局納得してもらえるかどうかっていうだけだな、やっぱり。クライアントが。
kudakurage
まあそこでもっと安くって言われたら、まあそうかみたいになっちゃうみたいな。
あれだけど。
まあなんかただ、受ける側の視点の方が僕は多いから、受ける側からの視点からで言うと、
ある程度見積もりは、まあ見積もり、これをもし普通にやるとしたらどれぐらいかかるかっていうのは作るんだけど普通に。
ただなんかやっぱりそれ以上の何かを乗せたいっていう気持ちもあるから、やっぱりその辺がなんか品質が一定でないって話になるのかなと思ったんだけどね。
Takaya Deguchi
それ以上乗せたい?言われたこと以上のことってこと?
kudakurage
まあそういうことですね。まあ簡単に言うと。
Takaya Deguchi
そうだよね。だから僕結構発注側の視点からしてみると、相手のデザイナーやエンジニアがめちゃめちゃ乗り気になってくれた方がいいと思ってるんですよ。
だから下手な値切りは絶対しない。むしろなんか相場より安かったらちょっと上げてやってもらうとか、
なんかそれぐらいにして相手が乗り気な状態になってプラスアルファを作ってくれた方が絶対にいいと思ってる。
っていう意味で高いか安いか判断する相場感を自分が持っておく、発注側が持っておくっていうのも大事なんですけど、
変に1000円安くするとかそういうことをやるぐらいだったら、全然なんかこう気分よくやってもらった方が絶対いいものができるだろうなっていうふうに思うんですよ。
プレッシャーと不採の積み方
Takaya Deguchi
あとはその人が興味ありそうな案件をお願いするとか、好きそうなやつをお願いするとか、
いかに見積もりに乗ってこない部分のテンションみたいな部分を引き出せるかどうかっていうのが大事だと思ってて。
この本で言うとプロスポーツのアスリートやアーティストのマネジメントみたいなことって書いてあったんだけど、確かにそうだなと思ったんですよね。
kudakurage
プロジェクトシーンエヴァンゲリオンも同じこと書いてあったよね、確か。結局、もちろん金銭的な部分もあるけど、もうちょっと訂正的な部分をすごくケアしてやってたみたいな、他の人に依頼するときに。
何を重要視するのかとかっていう、仕事を受ける上でね。そういうのはあるよな。
Takaya Deguchi
どの仕事でも一緒だと思うけど、結構ソフトウェアはそこが大きく違いを生むところなんじゃないかなっていうふうな気がしてて。
これが一番真逆になった場合って言われたことだけやるみたいな。言われたことを最低限だけ満たすことをやるみたいな。
デザインは分かんないけど、ソフトウェア開発の場合それは言われたことだけやる、最低限品質満たすでも超短期的には問題なかったりするかもしれないんだけど。
でも長期で見てみると、コードの品質がすげえ悪くて追加開発しづらいとかバグがすげえ出てくるとか、そういうところから現れてきて。
kudakurage
結局長期でコストがかかってきたりとかすると思うんですよね。人をうまく乗らせるっていうところって結構大事なんじゃないかなっていうふうに思いますよ。
Takaya Deguchi
その逆の話として、プレッシャーをかけても生産性が上がらないっていうことも触れられてて。
一時的な妥協が永遠の妥協になるみたいな、永遠の不採になるみたいな話で。
一時的にすげえプレッシャーかけて何とか間に合わせるみたいなことをした結果、後から追加しづらいような構造になってたりとか。
それでその不採を後から回収することになるみたいな。よくある話ではあるし。
この辺って適切に分かってて不採を積むなら全然いいと僕は思うんですけどね。
分かってていい借金をするなら。それでタイミングが大事なこともあるじゃないですか。
ここでリリースしないとみたいな。
だからプレッシャーを一時的にかけなきゃいけないっていうのは、特に事業会社だとどうしてもあるかなと思うんですけど。
その結果として何が起こるのかっていうのは分かった上でそれをやるっていうのが結構大事かなっていうふうに思ってて。
悪い不採の積み方をしたとしても、その返済を返済しないと前に進めないっていう状況と、返済を何とか間とか遅延して前に進めるってやり方もあるかなっていうふうに思うんですよね。
ありますね。
なんか結構前のSaaSとかだと、前の会社だとSaaSで、B2B SaaSの場合ってユーザー数がそんなに多くなかったりするんですよね。
B2Cに比べると。だからその分単価は大きいんですけど、減られる価格、値段は大きいんですけど。
見積もりのデザイン
Takaya Deguchi
多少不採を積みまくって日も札もいかなくなって追加開発できなくなったとしたら、それを頑張ってメンテナンスしまくるよりは新しくものを作った方が早いんじゃないっていうふうに思ったことがあって。
で、そこの状態でお客さんにどこのタイミングで乗り換えてもらう、新プロジェクトで乗り換えてもらうとか、そういうやり方で、それを式年戦偶とか呼んでたんですけど、前の会社でスコープを適切に切るというか、
同じものを作り続けて育てていくのがソフトウェアなんだけど、あえてそこで別の場所に家を建ててそっちに移ってもらうみたいな。
それによって前の不採用を一旦、別の形で返してるんだけど、開発っていう観点で返さずに移行コストって感じで不採用の返し方を変えて新しいプロジェクトを育てるみたいな、
そういうようなアプローチとかもあるなっていうふうにやってたなっていうことを思いましたね。
kudakurage
移行は移行で大変なんですけどね。
Takaya Deguchi
B2Cだとそれが芸術的じゃないんですけど、ユーザー数がめちゃ多いからね。
kudakurage
B2Bでも、物によるか。
Takaya Deguchi
物によります、それは。
kudakurage
なんかね、僕も今真っ只中だから、ああなって思ってますけどね。
Takaya Deguchi
もてもさんがやってるやつは多分できない、やりづらいケースかもしれないけど。
kudakurage
いや、本当に物によると思うんですよ。
例えば、料金体系とかまで手を入れるとか、その辺もやっていくとすごい大変、移行って。
Takaya Deguchi
料金体系。
kudakurage
いや、もちろんリニューアル自体も難しいんだけど、料金体系、だからどういうプランやってるのかっていうところまで手を入れてやっていく。
Takaya Deguchi
そうね。
kudakurage
すごい移行をどうしていく、このパターンがあってこのパターンがあるみたいなのがすごいいっぱいになってきて、
すごい大変なんだけど、なんかでも徐々にやるしかないよねみたいな感じで頑張るみたいな。
なかなかでも進まないよね、プロジェクト自体はすごく難しいなって思う。
Takaya Deguchi
一社の単価がめっちゃでかくて、ユーザー数少ないエンタープライズのBtoBとかだったら移行はそんな。
お客さんとの関係性にもよるけどね。
お客さんが本当に少なければまだ楽かもね。
kudakurage
BtoBでもSlackとかNotionとかそういうやつだと難しかったりすると思う。
Takaya Deguchi
あとはバッファーの話ね。
バッファーはやっぱつい含めちゃうじゃないですか、時間的なバッファー。
kudakurage
それは含めるべきなのかと思ってます。
Takaya Deguchi
含めるべきですよね、対クライアントだったら。
kudakurage
だけどそれを社内でもやっぱ受発中構造がある会社がなぜ悪いかって言ったらそこだと思うんですよね。
Takaya Deguchi
社内において営業が、SaaSの会社とかでよくあるんですけど、こういう機能欲しいみたいな。
こういう機能がいついつまでにお客さんが求めてるからみたいな。
エンジニアがいついつまでできますっていう。
いついつまでに見積もりって行為をしてて、そこにバッファーが含めて、
それが約束みたいな見られ方になって。
悪いケースではそれが評価とかにひも付いててみたいな。
ってなるとどんどんどんどんコンサバなバッファーの包み方をしていって、
めちゃめちゃ時間かかるように見えちゃうみたいな。
そこが冒頭に言ってた、そうじゃなくて、それは機関で見積もるとそうなる。
機能ありきで見積もるとそうなるから、機関ありきで見積もる方がいいんじゃないかみたいな話が書いてありましたね。
時間が結局一番どうしようもないケースが多いので、時間から逆算して何やるか決めるっていう。
時間から逆算して、この機能やるかやらないかとか、
この機能これぐらいの品質でとどめとくとか。
なんかこれは一般的じゃないんですけど、
kudakurage
なんか今考えるとめちゃくちゃなやり方を僕が昔やってて、
Takaya Deguchi
普通に受注した案件とかを徹夜で1日で終わらせるみたいなことよくやってたんですよね。
kudakurage
若いです。
めちゃくちゃなやり方してるんだけど。
で、見積もりとしては5日間ぐらい撮ってるんだけど、
それを1日で終わらして、3日で納品するっていう。
で、お客さんもハッピーになるみたいな。
Takaya Deguchi
そういうやり方を昔やってた気がするな。
kudakurage
それでもお金はいつか分もらうんですか?
お金っていう意味では、ほぼほぼあんまり関係ないかな。
そこまで大きく関係ないかな。
ある程度これをやらなきゃいけないっていう、
異人契約だからさっきの納品ベースだから、
これはこの費用ですよみたいなのが割と部品で決められてたからその時はね。
ウェブサイト作るとかホームページ作るみたいな話だったら。
だからそれはもうだいたい決まってて、
それをどれぐらいのスケジュールでやるかみたいなところを、
例えば5日ぐらいかかりますみたいな。
しておいて、1日で終わらして、
で、社内でも僕はもうほとんど終わってんだけど、
ちょっとあと明日ぐらいまで待った方がいいんじゃないですかねみたいな感じで言って。
で、3日で終わらせましたみたいな感じで。
あんまりこれねやりすぎると良くないんだけどね逆に。
Takaya Deguchi
あ、3日でやってくれるんだみたいになっちゃうから。
kudakurage
そうだよね。
そうそう。
それもあって、僕はちょっと止めたりしてたんだけど、
僕が終わらしても、
Takaya Deguchi
これはまだちょっと持っていかない方がいいと思いますみたいな感じで。
いや、あとあれですよ。
あれもうできてるならじゃあ追加でこれもとか。
kudakurage
ああ、そうそうそうそう。
まあでも追加でやったらその分また予算取るんだけどね。
その契約の場合だったら。
時間契約じゃないんで。
まあでも、昔そういうやり方してたな。
っていうかだからさっきの良くないって話だと思うんだけど、
良くないのかわかんないな。
終わってんだけど、
社内の人にも終わったってこと言ってない場合もあったからね。
Takaya Deguchi
まあクライアントワークの会社ならまあいいんじゃないですか。
kudakurage
営業に言わずにもう終わってんだけど、
僕もだから自分のプライベートっていうか好き勝手開発してる時があったから、
その会社で。
それやってんだけど、
それなんかまだ仕事してる風な感じに営業には見せてて、
実はもう終わってるみたいな。
はいはい。
っていうふざけた働き方してたね。
Takaya Deguchi
まあ別に最終売上が変わんないならいいんじゃないかなって思うけどね。
クライアントワークは。
kudakurage
負担かかってんのは僕だしね。
完全に。
Takaya Deguchi
まあそれをなんか事業返しでやるとあれっていう話。
kudakurage
まあまあまあ。
まあそれもね、
なんか4,5人っていうか5,6人でやってる会社だったんで、
まあ成り立ってたけど、
もっと大きくなったらね、
そんなことでやってられないと思いますけどね。
もちろん。
大きい会社だったら。
なんか僕はでもそのやり方をして、
残りの2日で自分の好き勝手なことやって、
あわよくば、
いやまでそれ乗せるどこまでいかなかったなさすがに。
それをお金かけ取った方がいいなと思ってたから。
どっちかっていうと多分営業の、
営業ツールを作ってた気がするな、
その時間に。
お金こういう風にやったら売れますよみたいなところを作るみたいな、
開発するみたいな。
まあ普通はそんなやり方はしない方がいいと思うし、
Takaya Deguchi
しないと思いますけどね。
っていうまあ見積もりを求められるのね。
事業会社でもよく見積もりを求められる立場にいたんですけど、
正直分かんないなって、
分かんないって回答しちゃうことが多かったですけどね。
なんか約束をしたくない、
約束になっちゃうのがすごい嫌だったんだよな。
kudakurage
まあでも、
Takaya Deguchi
いや分かるんですよ、
そのビジネス側の気持ちはね。
だから、
分かんないって言っちゃうことが多かった。
kudakurage
僕は割と答えてるかもな。
Takaya Deguchi
なんか答えて、
その辺の温度感が分かってくれる人ならいいんですけど、
真面目に受け取られちゃうとちょっと困るなみたいな、
思うことがあったんですよね。
でそれが、
僕が自分でやるならいいんだけど、
他のエンジニアとかデザイナーのプレッシャーになるとちょっと、
あれだなっていう。
kudakurage
まあそれはあるかもね。
Takaya Deguchi
自分がだったらいいんですけど。
手を動かすのは他の人なのに、
自分が答えたことによってプレッシャーを作ってしまうっていうのがちょっとなんか嫌だなと思って。
kudakurage
それは難しいね。
営業とのコミュニケーション
kudakurage
どっかで欠伏かみたいになるな、たぶん。
Takaya Deguchi
いやそうっすよ。
痛つまったら。
そういう時はやっぱどうしても、
まあそれでもわっきょも分かんないとかはぐらすんだけど、
それでも求められたら、
まあなんかすげえバッファー見積もっていっちゃったりとかしますよね。
kudakurage
まあそうだよね。
まあでも、
まあそうなるしかないと思うけどな。
もちろんだから、
その気が知れた人だったら、
まあこれぐらいかなと思うけど、
もしかしたらもっと長くなるかもみたいなさ、
そういうニュアンスにすることは可能じゃないですか、たぶん。
あの気が知れてる間からだったら。
Takaya Deguchi
そうそうそうそう。
kudakurage
でもそれがないんだったら、
もうバッファーつけるしかないと思うけどね。
さすがに。
Takaya Deguchi
あとずるいかもだけど、
逆にいつまで欲しいとか聞いて。
kudakurage
ああそうそうそうそう。
まあでもそうだと思うよ。
Takaya Deguchi
そうすると案外なる早でとか言って、
ああこれあんま、
実はそんな時間が厳しくないやつだなとかね、
分かったり。
kudakurage
だからやっぱ結構、
そういう意味でも、
まあその相手が営業だったら、
その営業とうまくコミュニケーション、
普段からしておくとかっていうのも重要だったりするみたいな。
Takaya Deguchi
そうね。
あるよね。
ある。
実はそんな大事じゃないってこと結構あるから。
kudakurage
ああ。
Takaya Deguchi
これでめっちゃ売れますとか言うんだけど、
本当に?みたいなところ詰めていくと、
全然希望的観測だったりする。
プリセールスの重要性
kudakurage
こんなこと言うと怒られそうだけど、
Takaya Deguchi
なんか営業の人は割とその人のさじ加減で言ってることが多いみたいな。
そうそうそうそう。
kudakurage
多いからね、本当に。
Takaya Deguchi
そうそうそうそう。
あとこっちが約束するなら、
じゃあそっちも約束したよねっていうことで、
はいじゃあこれでいくらいくら売れるんですかみたいなこと聞いたりとかね。
ちょっといやらしいけど。
kudakurage
割と僕最終的に、
昔いた製作会社で、
最初はもう営業と、
営業が持ってきたものを僕が作るみたいな関係だったんだけど、
だんだん僕がもう営業ツール、
売れるものを作り始めたりとかして、
一緒にお客さんのところに行ったりもし始めて、
そのだんだん僕が営業をコントロールするような感じになってたもんね最終的に。
これはこういうふうに言っといた方がいいよみたいな感じで。
Takaya Deguchi
結構それありだと思うんですよね。
エンジニアデザイナー的な、
プリセールスみたいなことだと思うんですけど、
プリセールスエンジニア、
セールスエンジニアとかそういう人いると思うんだけど、
一緒に動向するとか、一緒に営業プラン考えるとか、
そういうの大事だと思うんだよね。
kudakurage
そうだよね。
Takaya Deguchi
し意外に面白いしそういうの。
kudakurage
お金稼いでる感あるからね。
Takaya Deguchi
そうそうそうね。
あとは、
あとはそうですね、
ソフトウェア開発の不確実性と手数の増加
Takaya Deguchi
最後の方は物理的な製造と何が違うのかっていう話に触れられてて、
極端な話、一番違うのは不確実性との戦いであるっていうところ、ソフトウェアは。
極論ソフトウェア開発はギャンブルだみたいなことが書いてあって、
そうだと思うんだけど僕も。
ギャンブルというか投資とかそういうのに近いかなと思うんですけど、
一発勝負するよりは分散して手数を増やして、
一発勝負よりは分散して手数を増やすって話だとか、
またさっき言った小さく育ててだんだん徐々に育てていくとか、
そういう不確実なものだからこそ一発勝負するんじゃなくて手数を増やしていくとか、
時間的に長くするとか、
そういったところが大事だよっていうことが書いてあって、
それはその通りだなと思いましたね。
kudakurage
手数増やすっていうのはアジャイル的なことだよね。
Takaya Deguchi
そうそう。
結局この会社、この本を書いている倉木さんがアジャイルの会社をやってるから、
そういう話につながっていくんだけど、
結構やっぱりとはいえ小さく作るっていう、
要はMVPを作るっていうところ、
そこがやっぱり結構PMの腕の見せどころっていうかミソというかだなと思うんですよ。
どう小さくするかってところ。
kudakurage
そうだね。
どこをやるかとかも見極めるかがあるから、
MVPにするポイントみたいな。
Takaya Deguchi
そうそうそうそう。
悪いMVPはMVP出したけど、
これじゃ何の魅力も伝わんないじゃんみたいなやつ。
単なる機能劣化に見えてしまうというか。
だから良いMVPはMVP単体でもプロダクトとして魅力があって、
かつ後々のロードマップに連続性があるというか、
後々つけるより大きい機能とかにもそれが接続されてるというか。
よくカップケーキとか言われますけど、
ホールケーキを作る前に魅力あるカップケーキを作るみたいな話。
kudakurage
だから僕はやったことないんだけど、
やり方として何かで見たことあるんだけど、
知ってるんだけど見たことあるのか忘れたけど、
最初のMVPのフェーズと、
そこからそれが上手くいった場合のフェーズで三つ盛り分けるみたいな。
最初のMVPをやってみるところまでの三つ盛りをまず出して、
それで動きます。
そこからまた計画変えていくっていうかさ。
また別のフェーズにして契約しましょうみたいな。
やり方も確かやってる会社があったような気がする。
MVPの作成方法と重要性
kudakurage
何か忘れたけど。
Takaya Deguchi
なるほどね。
kudakurage
でもそれは割と正しい姿な気がしない?
Takaya Deguchi
そうですね。
kudakurage
そこをじゃあもしかしたらピボットするかもしれないし、
上手くいってどういう風に形を成長させていくかっていうのが、
まだ最初の段階だと見えないけど、
ある程度見えてきた段階で、
ちゃんとこう、より正確な構図を見積もってみたいな感じになるから。
Takaya Deguchi
確かにな。いいですね。そういうの知りたいんだよな。
何かそういう三つ盛りのデザインパターンじゃないけど、
何かそういうのっていろいろある気がして。
まあそうだね。
今もてがやまさんが言ったのもそうだし、
さっき施工会社の話した前金後金で2分割でやるっていうのもそうだし。
まあよく2人か11人かとかにパターンがあるけど、
それだけじゃなくて、その中でもいろいろやり方があると思って。
何かそういうパターンってあんま表に出てこないから、
そういうの知りたいなと思いますね、最近。
kudakurage
まあでも結果的にやってないけど、
とりあえずMVPまでのっていう契約にして、
もしそこから必要だったらさらにまた別途契約しましょうみたいなのは
よくやってるような気がするな。
Takaya Deguchi
改めて、割とここに書いてある、この本に書いてある話って、
何かソフトウェア工学みたいな話で、
人欠の神話とか、なんかデッドラインとか、
何かそういう古典的な本がいくつかあったりするんだけど。
てか何か僕大学がそういう系の大学というか専攻だったんですよ。
でも正直全然面白くないなと当時は思ってて。
SEとかそういうところに就職する人が多いような大学だったんで、
大学というか専攻だったんで、僕の専攻がね。
研究室もソフトウェア工学の研究室だったから、
こういう系の話がゼミとかでも多かったんだけど、
kudakurage
全然興味通じもてなかったんで。
Takaya Deguchi
これ学生でも面白がる人相当珍しいと思う。
kudakurage
本当にね。
たぶんSIや大手に行っても楽しめないと思う。
Takaya Deguchi
楽しめる人あんまりいないと思う。
こんなのより物を作ってたら楽しいじゃんって思って。
kudakurage
僕が経験したからなのかもしれないけど、
Takaya Deguchi
小さい会社の方がこういうのを楽しめるんだよね。
そうかもね。
kudakurage
というのはお金に近いからとかそういう部分もあるんだけど、
お金稼いでる感みたいな部分とかそういうのもあるんだけど、
割と自由度が高いから大きい会社に比べると採用が大きいというか。
営業と一緒に組んで、
これもうちょっと見積もりこれくらい大きくしようぜみたいなとか。
やりたい放題できるっちゃできるから。
そういう意味でも小さい会社の方が楽しいんだよねこういうのはね。
Takaya Deguchi
そうね。
だから僕も改めて今そういう割と実際会社の中で
そういうことをPMみたいな立場に立つようになり、
大事だなと思うように至ったって感じですね。
小さな会社の楽しみ方
kudakurage
いやだから大学の時こういうのやったわとかすげえ思い出しましたね。
僕いつも言ってるけどさ、
社会に出る人は僕1,2年で大学行った中断して社会に出て、
出てちょっと3,4年ぐらいしてからまた大学に戻ったほうがいいと思ってるんだよね。
Takaya Deguchi
ね。
kudakurage
じゃないとやっぱりどの部分が社会で必要とされてるかとか、
面白いかってなかなか分かんないじゃん。
ただ働きもせずに勉強だけしてるような感じだと。
Takaya Deguchi
分かんないですよ。
kudakurage
そういうところだと思うんだよな。
Takaya Deguchi
なんかよくケーススタジリみたいな感じで、
数千人いるようなプロジェクトにアサインされたとしてSEとしてね。
どう技術通りマネージメントするかみたいなことをやられたりしたんですけど、
全く面白くねえなと思って、
こんなのやるんだったらコード書いてた方が良くないとか思って、
全然興味持てなかったんだけど当時は。
kudakurage
そうだよね。
僕も大学の時に産学共同みたいなので、
地元の経営者みたいな人がいろいろ集まってきて、
僕はどっちかっていうとデザイン系の大学だったんで、
デザイナーと一緒にサービス作るみたいなのをやって、
僕はその中でわりと中心的なPM的な感じですよね。
お金方面も見るPM的な感じのチームに入っていろいろやってたんだけど、
全然面白くなかったもんね。
Takaya Deguchi
そうね。
kudakurage
めんどくせえなあと思って。
Takaya Deguchi
そうっすね。手動かした方が楽しいですからね。
kudakurage
絶対そっちの方が楽しいよ。
Takaya Deguchi
そう思ってウェブの会社に行って、いろいろあって今またここに戻ってきましたね。
はい、っていう感じで。
ちょっと渋い話でしたが。
渋い話だけど、結構いいものを作るためには大事だなと最近よく思いますね。
この見積もりっていうのは。
kudakurage
そうだね。見積もりだけじゃないけどね。
いろいろ絡んでくるけどその中に見積もりもあるよね。
Takaya Deguchi
そうそうそうそう。
っていう話でした。
kudakurage
じゃあ、中の人っていうか、俺を聞いてる人の中には製作会社とか、
フリーランスやってる人の中にはいるのかな。
Takaya Deguchi
そういうノウハウを交換したいですね、僕。
kudakurage
見積もりデザインパターンの情報交換。
じゃあ、もしこういうやり方もありますよっていうのがあればね、
コメント?ツイート?
Xね。
Xでツイートもらったりとか、リスンでコメントもらったりとか、
お便りでもいいんですけど、送っていただければなと思いますね。
なので、そういうツイッターXだったら、
ハッシュタグリサイゼフンで呟いていただけると嬉しいですし、
お便りの場合はショーノートにあるお便りのリンクから送っていただければ、
配信内で取り上げたりしますので、どしどしいただければと思います。
リサイゼフンは毎週金曜日に配信しています。
Spotify、Apple Podcasts、Google Podcasts、YouTubeなどで配信していますので、
よかったらチェックしてみてください。
ということで、今回はここまで。また次回お会いしましょう。
Takaya Deguchi
さよなら。
