00:07
はい、みなさんこんにちは。株式会社イメミでチャレンジ取締役をしております。 keeth 孤独ヴァーハラと申します。
web 業界のネットボタンスなしでようこそ。この番組ではweb 業界に関する様々なことを発信していきたいと思います。
第91回ですね。第91回はゲストトークですね。ゲストにスポットメイト株式会社の代表取締役大関さんを招待しております。
社名が違う。違いますかね? 社名が変わったんです。あ、そうなんですね。
申し訳ないです。じゃあそのまま流していこうかな。大関さん、今日は一日よろしくお願いします。
お願いします。なんか社名が違ったらしいんで。 社名がそう、優先グループになった。
本格的に優先グループの一員になったので、優先ワーキングっていう社名になっています。もともとはスポットメイトって会社だったんですけど、
去年の9月に優先ネクストグループと商業部提携して、去年の9月に名前も変えて正式にグループになったみたいな感じですね。
なるほどですね。それは把握しておらず。 そうなんですよ。気づいたら大きい会社に所属しちゃってます。
すごいですね。大きいとこにいれば、ある意味で資本的なところが安心はしますよね。
そうですけど、僕ももともとちっちゃいところの方が好きで、いろんなスタートアップを渡り歩いてきてたから、
民民ももともとちっちゃいときに入ってたので、60名ぐらいかな。 だから大きいところだと意思決定が遅いので、そこは変わらないから。
いろんな大きい会社を見てきてるし、常駐とかもしてたんで。 そうですね、なるほど。
もともと大きい会社は合わないなと思ってたので。 まあいい経験じゃいい経験ですけど。
確かに今までこそ200名超えましたけど。 すごいよね。僕が入ったとき60名ぐらいで。
僕が入ったとき、エンジニアで入ったのが1年ぶりか2年ぶりぐらいの感じだったらしいので。
今みたいにバンバン対応しない時期ですね。 そうですよね。
いやー今もでも採用はちょっと苦戦はしてますけどね。 全然そんな風に見えないけどね。
一応お声は結構いただいてて、それは本当にありがたい次第ですけど。 リードレベルとか採用の基準を上げたので。
あーそうなんだ。 内定率は高くなってはいるんですけど、そもそもの数が少ないのと、
案件の規模とか。 規模によって欲しい人とかの量がやっぱり変わる。
僕が開いたときの規模感を回す人が欲しい感じなんですか?
そうですね。大関さんクラスに行ったらすごくありがたいですけど。
デモ取りですか?
03:00
あれですね。でも、悪い習慣というか。 プロジェクトマネージャー1人が一案件みたいなところで。
案件の上限がプロジェクトマネージャーの数と比例するっていうのはよろしくないですね。 これは改善しなきゃなと思います。
なるほどね。
1プロジェクトでも数の大きさにもよるじゃないですか。 僕がクワフワさんやったときは結構数多かったし、
KFCもやったりとかしてたから。 結構いろいろやると面白いけどね。
恥ずかしいなぁ。
そうですね。僕は結局大関さんと一緒の仕事をしたのはほとんどなかったので、あれですけどね。
ナイスね、ナイスね、ナイス!
いきなり大関さんのチームの中の一つに入って、ヤンキーみたいなリーダーがいるんだよって言われて。
本当にヤンキーっているのかなと思って、いざ実際に会社にお見受けしたときに、本当にヤンキーじゃんって。
当時から変わってないんじゃないですかね、僕。 全然、今見た目も変わってないと思いますしね。
そうですよね、直接仕事したことほとんどないですもんね。 うちのチームの中の結構コアのところに入ってもらって、エンジニアでバリバリやって回させたんだもんね。
そうですね。
最初大変だったもんね。
すげえ大変だったもんね。 隣にいるメンバーがレベル高かったってもちろんありますけどね。
レベルも高いし、みんなほらうちのチーム個性的な人が多かったじゃないですか。 正直、良くも悪くもね。
僕、夢見を辞めてからいろんなエンジニアの人とかと話をさせてもらったりとかしてるけど、
夢見にいた時が一番エンジニアの癖強かったなって、今でも思うので。 今やってると、みんなすごい話分かってやってくれるなーって思う時があるもん。
当時だと、結構、たらはくさんとかと言い合いになったりとか結構あったし、 竹内さんもそうだし、そういうのもあったけど、
癖強かった分、ディスカッションもすごくしたので、良いものができたなーって思うんですけど、 なんかみんなこう
いいからやれが通じない人じゃないですか。 中身を理解して、芯がないと動いてくれない人だったから、それは正しいんだけどね。
僕の説明が下手だったってももちろんあるんだけど、 今やってて、それはすごい説明する能力がそこに身についたなってすごく思うし。
でもやっぱ、あの当時の夢見のメンバーみんな若かったって思って、 強かったなってめちゃくちゃ思いますよ。
それが今めちゃくちゃ役に立ってるのは間違いないんだけど。 あるより大変な時に出会ってない。
うーん、なるほど。 いやー面白いですね。
06:04
癖はでも、今もなんだかんだ強い人が登ってる感じはしますね。 夢見全体としてそうですけど。
そうなんですね。 最終的に片岡さんが最終メッセージしますけど。
片岡さんがそもそも普通じゃないからね。 面白い人、笑いが取れそうな人とかを重視してるんですよね。
もちろんスキルは前提ですけど。 僕もそうだと思うよ。僕も多分すごい変わってる方なので、よく僕を取ったなって今でも思うし。
それは。 僕がそこに入っても浮かない感じってことは多分相当変わってたと思う。
だから楽しかったってのもあるんですけど。 それはそうですね。
あれはとちなみに僕、あの案件1回抜けたんですけど。 1回フロントエンドのエンジニアとして、あの案件に別の枠でもう1回6ヶ月7ヶ月
実は常駐してたんですよ。 前も言ってたよね。
いやーめっちゃ大変でしたね。 何が大変だったの?
いやーやっぱりコミュニケーションは本当大変ですね。 僕も英語全然できる方じゃないから。
あの向こうのPMの方がすごくそこはブリッジに入っていただいたのがありがたかったですけど。
常駐すると結構見えてくるもの変わるじゃないですか。 全然変わりましたね。
僕も2回常駐してるんですよ。 最初は何か人が足りないからって常駐したのと、
その後はもっとコアに密にやりたいからって常駐したんですけど。 3ヶ月と1年ぐらいで常駐してたんですよ。
常駐して常駐終わったら夢に帰ってってハードワークしたんですよ。 見えてくるものは全然違くて、お客さんが求めているものだったりとか、
求めてほしいって実感できるじゃないですか。 一方で、
お客さんに許しすぎちゃっていて、メンバーとの距離が遠くなったなぁみたいな反省点も結構あったりとかしてて。
実はその時って売上が上がってきたんだけど、メンバーとの意見の違いみたいなのも結構増えてきたんですよ。
それから僕がお客さんを許しすぎちゃったから。 そこの難しさはそう感じた。
常駐して見えちゃうからこそ、なんかやりたいって思うんだけど。 一方でメンバーからすると、めちゃぶりに見えることが多々出てくるので。
そこのバランスはすごく難しかった。
僕の場合は、ほぼほぼ最終的に作業員でしかなかったんですけど。
正直に言うと、お客さんの内製チームの方々がレベルが本当に高くて、
エンジニアスキルも高いし、チームの作り方とか進め方もめちゃめちゃ勉強になってですね。 そのノウハウは正直知れたのが本当に大きかったなと思います。
この人材はグローバルでいっぱいいるからね。面白いよね。
09:01
なかなか面白かったし、日本人より海外の方がレベル高いなっていう。 海外って言うと趣向が大きいんですけど、特にインド人の方はやっぱりレベル高かったって痛感しました。
ほぼミスなくていいんだ。そうですね、レベル高かった。
それは衝撃だったし、開発ってリファクタリング後でするみたいなのがよくありますけど、彼らは常にやっているっていうのが大きかったとしても、今必要だからと言って断固するんですよね。
いやーでもね、そこでは本当にそうだと思っていて、後からやるって基本みんなやらないじゃん。
テストコードもよくある話で、テストコードは後で書くよって言うんだけど、そもそもテストコードを書く設計になってないから、結局テストコードを書こうと思ったら全部リファクタリングしないといけなくて、あれこれ作り直しはないみたいなケースが結局あるから、
スタートアップやってて、その辺って最初テストコード書かなくてもいいじゃんって、バーって作るんだけど、結局もちろん3ヶ月ぐらいになるよね、これでやると。
だから、最初テストコード書けなくて設計しとくとか、テストコードを書ける範囲は書いておくとかやっておかないと、後からやらんよねみんなね。
マネジメントする側というか、ビニューサイトからしても、テストコードって何度やって話になっちゃうから、そこに書けるコース、リファクターコース取れなくなっちゃうので、もうそれ取れない前提でマネジメントをしていかないと、基本的には難しいよね、やっぱり。
最初の見積もりにもちゃんと積みたいですし。
僕いるときは納品物をそもそもテストコードにしてたから。
でもそれ、先方がOK出すんだったら本当にいいと思いますけど。
そう、だってテストコードを書くっていう視聴時をメンバーにもできるし、お客さんにもできるじゃないですか。もちろん担保できないとかはこういう目標でやればいいと思うんだけど、
基本的には単体テストはテストコードでカバーしますよと。
それ以外の画面のところはテストコードも一緒に作りますよみたいな方が、やっぱりどっちもハッピーになれるので。
そうですね、なんだかんだ言って。
なんだかんだで、そう。
おっしゃる通りなんですよね。
でもテストの話ちょっとすると、やっぱり夢見全体として、テストを絶対書くというか、いろんなテストの何でしょうね。
流度とか基準とか、いろいろそれはプロジェクトとか、内容によってまちまちですけど。
その辺の統一というかガイドライン的なもの、せめてベースここまでやりましょうみたいなのがないので、それは作っていきたいなと思うんですけど。
テストコード書いてないですか?
いや、書いてるプロジェクトもだいぶ増えてきたと思います。
僕がいるときは全然変わりましたね。
僕がいるときはほとんど書いてなかったですもんね。
そうなんですね。
書いてなかったと思います。
一回全体版はみたいなのをやったことがあって、そもそもテストコードを書いてるところがほぼなかったんですよ。
それこそテストコード納品してるのうちぐらいだったんですよね。
はいはいはい。
そもそもテストコード納品してるっていう概念を他のPMがあんまり理解できなかったんですよ。
テストなんてテストコードでいいじゃんみたいな話をしたときに、だいたいお客さんが理解してくれないとか、
12:05
あとはお客さんが理解してくれないっていうよりはそもそも説明がちゃんとできてないとか、
あとはそもそも説明してないとか、そもそもエンジンじゃないとテストコードの良し悪しがわからない部分もあったりするので、
その辺はすごく恐怖に残ってるけどな。
そこを考えるとすごく変わったんですね。
結構そうですね。
コード納品もそうですけど、カバレッジ出すことの方が多いのかなと思ったんですけどね。
カバレッジの数値見てもお客さんがこれどうっていうのは判断できるかまた別の話ですけどね。
別の話だし、でもほら難しいのがさ、カバレッジが高いからいいわけでもなかったりするじゃないですか。
そうそう、それはおっしゃる通りなんですよ。
なんかみんな結構勘違いたまにしてるのが、カバレッジが99%でいいやとか言ってるのも、
それ数字が大丈夫じゃないよねっていう話もあったりするので、
そこは難しいよね。
ありますし、ちゃんとテストコードその本の質を見なきゃいけないっていうのもあるんでね。
そう、テストはちゃんと書こうってことは大変だからね。
本当にそうなんです。
普通にリストするより全然大変だから。
はい、わかります。
そうですね、コードを書いて、書かずに項目書を作って手でやって、その時だけは楽だけど、
あとでもう一回実行し直すとかでクソ大変ですから。
クッソ大変ですね。
書けるなって書いたほうがいいかな。
テストコードの項目書は、結構みんな誰でもできると思いがちじゃないですか。
そう、わかります。
でも、一旦テストコードの項目書に沿って、ちゃんとテストをするってめちゃくちゃスキル高い人だってできなくて、
なぜかというと、同じテストコードの項目書をやっていっても、同じ場所に引っかかる人、引っかからない人って全然出てくる。
ということは、実はあの項目書をそっとやるっていうのも結構スキル高いし、結構本人の集中力にもかなり左右されるので、
やっぱり人間ってずっとテストしてると慣れてきちゃって、見落とすんだよね。
でも、機械ってそれを見落とさないので、なるべくやっぱりテストコードというか、システムにやらせていかないときつらいし、
逆にシステムができるところはシステムをやってて、本来人間だけ見ないといけないところをやるっていう風にやっていかないと、
プロダクトの必要が上がっていかないので、そういう方向性でやらないと厳しいなと思うけどね。
いやー、わかるわ。人がミスするのになんで人がテストするのはずっと。
そうそう、人はミスするんですよ。そんな優秀じゃないんで。
僕も初期の頃とか、めっちゃ手でテストしてたけど、すごい疲れたもんだって。
うん、疲れますね、そもそも。
疲れる。IOSっていっぱいあるからさ、机に3台くらいの端末並べて同時押ししたりとかして、
そちらもめんどくさいなって思うわけよってなったもん。
あれはそうですね。
そういうのをシステムで自動化できることによってだいぶ軽減できるわけですよね。
15:01
本当に見なきゃいけないところを人間がやれるようにしないといった方がみんなハッピーだし。
あれはテストチームってあるの?
テストチームはありますね、1チームだけあって。一応外注してる会社さんもありますけど、社内にもちゃんといます。
テストチームがちゃんとある会社はすごくいいなと思うけどね、やっぱり。
いやー、わかるな。品質はどこまでも見ていかないといけないってのはありますけどね。
あるね。エンジニアがテストをしてる時期もあったから、うちの場合は。
本当はね、実装者のない人がいいんですけどね。
そうそう、それが結構問題だと思って、途中からうちのチームは外部にテストを依頼して、
で、常駐してもらって、うちだけテストチーム作ったじゃないですか。
あれは結構良かったなって今でも思ってます。
そうですね。
そのテストを使うためのツールを作ったりとか結構してたので。
はいはいはい。
分かり身の深い話だ。
みんなね、診察の頃テストやらされるけどね。
一回そうですよね。
そうなんだけど、さっき言ったテストスキル高いから、診察が流れ作業でやれるものじゃなかったりするし、
あとはやっぱりテストしながらこういうミスを人はするんだっていうふうに意識を持ってテストできるとすごい良いと思うんだけど。
ただ紙のものをベースにやってるだけのテストだったら、マジで誰でもいいから。
診察でやれないんです、実は。
そうなんですよね。
さっきちょっと僕は口にしましたけど、品質ってバグゼロとは限らないじゃないですか。
バグゼロは無理だよね。
俺もそう思います。本当に無理だと思います。
僕も元エンジニアで、僕もエンジニアをずっとやってたし、バグを出したくて出してる人間って人も基本いないじゃないですか。
それは間違いないと思うんだけど、でもさっき言った人はミスをするので、バグがある前提で考えないといけないし、
ソフトウェアがバグがないっていうのをみんなちょっと強く思いすぎなんじゃないかなって結構思ってて。
結構厳しいじゃないですか、みんな。
もちろん出ちゃいけないバグもある。クリティカルも潰さなきゃいけないし。
これにいいだろうってももちろんあると思うんだけど、細かいところまで含めたらやっぱバグはどうしても出ちゃう。
出ますね。
そこはね、むずいよね。
わからないお客さんに説明はしますけど、出るものは出るし、出たらなるべく早く対応しますとは言ってるけど。
そこですよね。出血をいかに早く止めるかと、暫定止めから出血早く止めることと、
高級的な対応をちゃんといつやるかっていうのを明示できること。
あとは影響範囲だったりとか影響人数だったりとかっていう事実関係をちゃんと早く明らかにするっていうところをまずやらなきゃいけないじゃないですか。
18:08
結構そこに行くまでに調整調整であって出血が広がっちゃってるみたいなケースがたまにあったりするので、
実はあれが一番良くなくて。
やっぱアクションが早く、あとレスポンスですね。
レスポンスですね。
障害難しいですよね。障害を出して何回も謝りに来たから。
書きましたね。障害報告書書いたりとか。
障害を出して謝りに来たね。そのためによく言いが痛くなったのを覚えてる。
言いたいですよね。
言いたいよね。それはしょうがないことだし、バグだから理由としてちゃんと謝んなきゃいけないからね。
言いが痛くなるよね。
発注する側もある程度バグを全部許せとは言わないけど、やっぱ人が作ってるものだからバグが出てしまうこと。
このバグを出ないためにテストコードっていうシステムを使ってテストをやりたいから、このお金をちゃんと下さいって交渉は僕ら側をするべきだと思うんですね。
起こっている理由としてはHumanがやってるから結局そのエラー、バグが結構出やすかったりするわけじゃないですか。
もしくは作りが時間がなくて特化にやってるから作りが大きいものが作ってしまっていて、本当はこの修正したらこっちに影響なると思ってたけど見誤ってしまって出てしまった。
それって自動化していれば気づけたりするし、時間があったらちゃんと作れるはずだし。
なんでそうなったかっていうところは一緒に考えていかないと、潰せないところなんで。
そういう意味だと発注者側も発注された側も一つのワンチームだったりするから、そこができるといいプロができるなっていうのはすごく思ってるよね。
僕がいたプロジェクトは結構それができてたなって今でも思っているので、お客さんとの関係性もそんな感じだったし、結構お互い思ってること言えたし。
受発注の関係じゃない関係性だったので、だから働いていても楽しかったし。
そうですね、関係性がすごく大事だと思いますよね、お客さんとの。
最初ちょっと赤になるかもしれないけど先にお客さんとの関係性作れて、あとバリバリ巻き取れるんだったら全然先にそっちコミットするのはいいのかなって思ってます。
僕もそっち派なんだよね。
信頼されないと何も進まないから、いかに信頼してもらえるかと、結局ほらプロダクトって作ってから、作って終わりじゃないじゃん。
いやそこスタートして。
リリースしてからがスタートなんだけど、結構日本のお自宅だと保守契約とかで追加開発は何もしないけど保守契約で数十万もらえます。
みたいな感じだと、結局プロダクト前に進まないわけですよ。
お客さんとしてはもちろん保守も大事だけどプロダクトは前に進めないわけだから、そういう関係値でプロダクトとして前に進めていく。
結局僕らの自宅側のゴールドとしてはお客さんビジネスは成功すること。
21:02
それに対して呼ばれて求めているものはプロダクトで貢献することだから。
そこの保守のやり方とかも従来のままだと絶対進まないので、それへ変えていかないと結構お互い辛いですよね。
ちょいちょい話してもらうのが、保守はしてもらってるんだけど、月50万払ってるけどメンテナンス以外何もしてくれないんですみたいな話しわけですよ。
これは契約の内容にもよるけど、やっぱりそれだとプロダクト前に進まないんですよねみたいな話はよくして。
なるほどですね。プロジェクトの規模感とか内容によりますけど、フェースを分けて1次フェース2次フェースでいけるならいいですけど、
でもじゃあ全フェース終わった後どうするかって話ですよ。
でもリリース終わった後メンテナンスだけしてサービス販売って絶対流行らないじゃん今。
そりゃないと思いました。そこからグロースが考えていかない。
そうだし、それこそリリースした後ユーザーの声聞いたりとかクライアントの声聞いた上でブラッシュアップして配信していくっていうのが今のプロダクト絶対必要なわけで、
結局プランが長かったら進まないわけだし、そもそもそこに行くプランがあったとしても保守しか受けてなくて追加開発に毎回お金使うとスピード出ないわけだし。
そこが自宅開発の難しいところだよね。
単なるメンテナンスだけの保守で結ぶから良くないんだと思いますけど。
そうそうそうそう。お客さんもそれでいいって発注するガーブだからそれ分かってないってわけですからね。
せっかくお金もらうんだったらこっちからも、逆に受注側の方が提案をするとかね。
できると多分ベストだし、お客さんからすると分からないから発注してるから。
そうですよね。
そういうものだなって思っちゃうっていうのもあるし、発注する側にそれが分からない人間がいないということも実は問題だったりするよ。
分からないから発注してきてるのは往々にしてあるんで、まだ難しいところがあるんですけどね。
そこを分かってこっちが発祥のコントロールまでやるけど、あくまで下に出てるみたいなところがいいのかなと。
いい業者にぶつかればいいですよ。
ガチャはありますけど。
そう考えると、これからIT使ってDX進めようっていう側に、別にプログラムかけなくてもいいじゃないですか。
それが分かる人間がいることって多分すごい重要で。
見てもらった時にレビューができるだけでも全然いいと思うし、どういう設計で作ったかってある時に一緒にディスカッションできるメンバーが、
多分中に発注側に一人いるだけでは全然違うと思っていて。
それこそクラマーさんが僕と一緒に入った時だったので、お客さんが発注してくれたけど中にITの責任者いたわけじゃないですか。
だから彼らもレビューするし、彼ら自身が責任を持っていいものを作ろうっていうのがすぐ見えたじゃないですか。
そうなっていかないと、結局IT使えないと思うんですよ。
24:02
全く分からないから。
でかい難しいのは分かってるんだけど。
そうしないと結局さっきのガチャが効く感じになっちゃうんだよね。
ガチャは正直規模感の大きいお客さんであるがあるほどガチャの確率が悪くなるイメージは強いんですよ。
言っていいのか悪いのかちょっとあるんですけどね。
それは多分間違ってないと思います。
結局でもそれって考え方的に人が足んない、じゃあ他に発注しようみたいな感じで、プロジェクションに関わる人は愛に増やしてるから発注してるんだと思うけど。
よく言う人を増やせば早く回るわけじゃないじゃないですか。
僕らは分かっているけど、分かってないところって終わってないと人追加しなさいって言われたりするじゃないですか。
人追加したら早く終わらないし。
もちろんマネジメントコースは上がってるし、遅くなる傾向ってあるわけですよ。
ありますよね。
これをちゃんと理解してる人ってまだまだ多くないんじゃないかなって結構感じていて。
あとはそこはもう今すぐ使わないから、ちゃんと作らなくていいんじゃないって軽くライトにいっちゃう人がいたりとか。
その辺は感じるよ。
その辺って結構コミュニケーション能力だと思ってて。
先方の担当者もウェブが好きじゃないとか、システムをアサインされたから今回窓口ですみたいな人がいたりするじゃないですか。
分かった上でこちらとしては若干教育も混ぜつつ、先方を立てつつ、話をどうですかってhowを聞くんじゃなくて、どれの方針できますっていう選択肢を渡して、
ここによって選択、意思決定をさせるっていうのがいいのかなと。
かんさんなんかすごいこっちがめちゃくちゃやってるんですけどね。
こっちの方が好きなんですよね。
実装者よりも僕は人とぶつかる方が好きだなって本当に思ってるんですよね。
最近実装はほとんどしてないですか?
全然してますけど。
してますけど、しちゃってるが正解で、実装は好きっちゃ好きなんですよ。
実装してないとマネージメントできないって証拠あるからね。
それを最近痛感してて、離れると離れるほど。
僕、29くらいからマネージャーやってて、そこからメインでコード書くことほとんどないわけですよ。
スタートアップに転職してから多少変えたけど、今言われる優秀なエンジニアと一緒にやると差を感じることが増えた。
差を感じれば感じるほど、やらないとついていけないなってめちゃくちゃ実感するから。
それがマネージメントやる側からすごく難しいですよね。
しかも多岐に渡ってるじゃないですか。
そうそう。
技術自体が。
そうなんですよ。
ある程度把握しておかないと会話ができない。
会話できないとエンジニアは絶対信頼してくれないじゃないですか。
そうなんですよ。
自分が逆だったらそうだったから。
27:01
話を分かってくれない人を信頼できないから。
いやーもうすっげー痛感してますね。
それは俺も最近すげー思う。
どんどん自分のスキルが劣化していることはよく分かるなって。
多分それは僕もっとひどいんで今。
もっとひどいんで。
経営者までいってるとそっちに振り切るのかなと思ったんですけど、そうじゃないんですか?
大きくないっていうか、小さい会社だとそうなのか。
根本的にものづくりが好きなんだなっていうのをすごく自分でも感じてて。
経営側にゴニョゴニョしてることも別にすごくつまんないとは言えないけど、
やっぱりプロダクト開発とかエンジニアリングとかものづくりに携わってる方が楽しいですね。
っていうのはスタートアップに転職して3年ぐらいか。
CTOとか取締役とかいろいろ今代表らが詰まってるけど、
ものづくり好きだなっていうのはすごく実感してるから。
別に元々取締役やりたいとか、CTOやりたいとか、代表がやりたいと思って別に会社選んでるわけじゃ全然なかったので、
どっちかっていうと気づいたらなってるっていう方が、
有名なマネージャーの時もそうだったけど、多かったので。
いろいろやった結果でも、やっぱりものづくりに携わっている時が一番楽しいなとは思う。
たまに実装するじゃないですか。
その時楽しいなと思うし、わからないことを調べて解決していく時はすごく楽しい。
エンジニアもやってて。
そこはすごくやってても感じるよ。
振り切らなきゃいけないんだろうけど、楽しさっていう意味だとそっちの方が楽しいなって思う。
現場からの距離が遠くなればなるものづくりしてない感が強いですね。
強いね。
強い強い強い。
でも、夢見にいる時も最後の方、僕ほとんど任せてたんだよみんなに。
最後の方はわりと暇だったからね。
一緒にやってた案件で言えばよ。
KFCの方は結構入ってガッツリやってたけど、逆に一緒にやってた方、任せられたからそっちができたっていうのもあるんだけど、
わりとみんなに権限以上して任せて、
相談が来るのは三つ盛りの金額の相談とか、
お客さんとこの辺でちょっとうまくいってないですねって相談とか、
そういうのはあったけど、基本的に任せたと思う。
だから逆に桑原さんとコミュニケーションを取ることがほとんどなかったってことは、任せたから取ってなかった。
チームが4つぐらいあって、基本的にみんなに任せていて、
共有はしてもらうけど別にそれに対してノーってことはほとんどなかったので、
それによっていいチームできたなっていうのはすごく思ったし、
ある意味いいことだったって感じですね。
いいことなんだけど、そうすると自分がやらなくなるので、
どんどん離れていく矛盾がある。
それはそうですね。組織的にはプラスにいってるんだけど、個人としては離れちゃうなみたいなところは。
30:07
エンジニアリング楽しいからな、普通に。
楽しくないです。楽しいでしょって。
全然楽しいですよ。
楽しくなかったらここにいないはずですからね。
そうだよね。僕も新しいことを覚えたりとかするって楽しいので、
今は楽しいことって転がってるじゃないですか。
こういうことを振らったら面白そうだなってすごく思っている。
そういうのがめちゃくちゃ感じるけどね。
最近は技術の学びについては僕も多少諦めが出始めましてですね。
要は原発とか進発の子たち、若い子たちと同じスピード感でやるのは100%無理なわけですよ。
時間もそうだし、持ってる役割もそうなんで。
単純に若い子に頭を下げることが増えたって感じです。
グアラーって今いくつだっけ?
今33ですね。
僕とそんなに変わらないのかな?
結構近いはずですよ。
近いよね。なるほどね。今の若い子でもめちゃくちゃ優秀だよね。
僕もすごく感じてて、僕の会社でも若い子結構いるんだけど、みんな普通にすごい優秀だなって。
理解力も早いし、そもそも僕の時代ってJavaScriptに型があるなんて考えられなかった時代だったじゃないですか。
そもそもJQueryが出始めぐらいだった。JQueryまだなかった時代だよね。
今の子たちってタイプスクリプトでリアクトで書いていて、そもそもフロントとAPIが分離されている状態から始まってるわけじゃないですか。
そうですね。
だからそこがもう、それをすんなり理解してサクッとやっててっていうのはすごいなって思うし、
それこそ昔APIなんて今みたいにGraphQLとか選択肢があんまりない状態だったじゃないですか。
今の子たち普通にリアクトからGraphQL叩いたりとか普通にしてるわけですよね。
そういうのを見ると、それを1週間、2週間くらい覚えてきてます。
それを見ると、すごいな、面白そうだな、やってみようかなと思ってちょっと見ると、すぐ分かんないって思いますからね。
いや、そうなんですよね。
正直ね。
分かりますね。パラダイムが割と現場では結構大きいったりするんで。
僕らが思って、きぬずかで行こうとしたら、こう理解できない状況って結構あったりするんですけどね。
そうなんすよ。そうなんすよ。いや、ほんとそうだよね。
昔に比べたらサーバーもいらないって言った。それこそGCQLはファンクションで使えばいいし、AWSもラムダ使えば別にサーバーいらないわけですよ。
そうなんですよ。
正直。
いや、もう本当に焦る。
焦るよね。アプリ開発もらって、Firebaseを使ったら別にチャークやったらすぐできちゃうしね。
そうなんですよね。
ね。
Firebaseはスケールするにはまた難しい問題があったりするんで、最終的にRDSが欲しいとかもあったりしますけど。
それってでも、ほら、スケールすれば必要だけど、その時に考えればいいじゃん。
33:03
うん、それはそう。
パクッと作れる状態になってるって世の中がすごくすごいなと思っていて。
昔だったらレンタルサーバーがあるじゃん。マイナスケール自分で入れればいいじゃん。
やってますね。
そういう時代じゃないじゃん、もう。
いや、もう懐かしいわ。
この時代が多分できること自体が割ともう年をいってます。
うん。
なんか今、モノリシックな絵設計なんて若い子一回もやったことないんじゃないかと思います。
ないんじゃないですかね。
設計がない?
うーん、ないよね。逆に言うとでも、きれいに描きたいなって欲求が強すぎるなって思うこともある。
あー、それもわからなくはないですね。
そう。
うん、なんでしょうね。
いや、確かにいろんなことを考えたらきれいに描けるに越したことはもちろんないんですけど。
お客さんはきれいさは求めてないじゃないですか。
この話は永遠に。
わからないからね。わからないし、きれいに描くと聞くのは後で聞いてきたりもするので。
長期目線ですね。
スピードとトレードっていうふうに勘弁に言いたくはないんだけど、どうしてもきれいに描こうと思ったら時間がかかるし、
新しいものをやろうと思ったら学習コストもかかるしってなってくると、どうしてもビジネススピード落ちるじゃないですか。
はい。
ビメリーが受けた案件って結構大きいクライアントが多いので、ビジネスがうまくいっているところが多いと思うから、それでもまだいいかもしれないんですけど、
スタートアップってそもそもビジネスがはまるかわからない状態で作り始めるじゃないですか。
はいはいはい。
そこにどこまできれいさを追求するとかって結構難しいなってすごくあって、
逆に言うと早く出して、ローンチして、油画囲って、第一人者になってしまえば、後からお金が得て、そこからファクトリングすることももちろんできるわけですよ。
ただ、そのコースめちゃくちゃ大変だし。
うん、そうなんですね。
結構難易度も高かったりするんですよ。
うん。
ただ、ビジネスをうまくいかせるためにはどっちがいいんだっけっていう結論って結構僕の中でも出てなくて、
はい。
なんかバランス、バランスって言うんだけど、結構バランスを取ると中途半端だなって思いもありつつ、
うん。
でもこう急ぎで作りすぎると今度エンジニア側辛いし、じゃあこのスケジュール全部エンジニア側のスケジュールを飲むとビジネス的に遅いんだよっていうケースもあるじゃないですか。
うん。
いや、ここはほんと難しいバランスの問題ですね。
これはやってていまだに僕も難しいなって思います。
いや、答え僕もないですね。
でも、ありとでもプロジェクト大きいお客さんでも、POCであったりとか一般プロトタイプでいいから見たりとか、結構声はいただくんですよね。
へー、なるほどね。
だからやっぱ気持ち上がろうが、いやスピードって絶対強いなって。
スピードは絶対大事。そうそう、それは間違いない。
結構MMOコンペで負けることは結構あるんですけど。
はいはいはい。
ただ、まあ単価で負けるってあっても、それ以上のスピード感が出せたら高くてもお客さん金払うよなって思ったりしてたんですよね。
それ多分あれ、僕がいたときの一緒にやったプロジェクトがまさにそれだった。
うん。
があるんで、やっぱ早く作れるのはほんとやっぱ正義だなっていうので。
36:02
結構今。
強いよねー。
ちょっとでも社内的には綺麗に作るとか設計に、まあ早く設計できるというのはもちろんこうしたことはないんで、勉強してもらうのは構わんのですけど。
お客さんのことを考えると、何を求めているって絶対早く物が見たいでしょっていうのがあるんで、そっちへのこだわりと技術も勉強してもらうのは良いかなというのはそう思ったりしますね。
スピードは絶対大事ね。ビジネスはまさにでもそうだと思うよ。結局やっぱ早く出さないと分かんないし、いくら綺麗に作ったとしたらうまくいかなかったら捨てられちゃうので。
そうなんですよね。
そこをしっかり見ないといけないからこそ、そこのジャッジメント難しいよね。
本当に難しいですね。不細を作り続けるのかって話になるし。
そうなんだよー。一緒にやってたってさ、まさにさ、全然時間がなくてさ、いろんなものを特化で作った結果、後で苦しんでる人も見てきたし、でも逆にあのスピード感でやったから発注してくれたっていうのもあるし、
それが売り上げに結構繋がったっていうのがあったりするので、そこは難しいよね、本当に。
分かりますね。
難しい。
でも出せる限界とか個人の能力はやっぱり決まってくるので、後は見せ方とか、お客さんとのコミュニケーションをどうとるかで割と安心感を与えることもできなくはないかなと。
全然できると思います。それも全然できると思います。
そこまでしっかり考えると、割とマネジメントも大変だなと思ったりはしますけどね。
マネジメントは大変じゃないですかね。
マネジメントってゴールが正解かないじゃないですか。形式もあったものがまとまってたとしても、結局そこにそこの人たちがその環境といる人たちとその周りの関係性があってそれが成功したって話も結構あって。
マネージメントするときってやっぱり自分でどういう、周りにいる人がどういう人なのかとか、状況によって結構変えないといけないから正解がないじゃないですか。
このケースは必ずこうすればいいってのは基本的にない。
基本感情と戦わなきゃいけないポジションじゃないですか。いろんな人と感情をね。
だからエンジニアリングってよくも悪くも感情と戦わなくてもよかったりするじゃないですか。
物を作るときはそんなに感情と戦わなくてよかったりするので、もちろんできないっていうストレスあるかもしれないけど、でも理不尽な感情とは戦わなくていいじゃないですか。
だからそこの難しさはやっぱりどうしてもあるよね。
だから正解がないから楽しいっていうのもあるしね。
それを楽しいって思えるのはたぶんバレなんじゃないですかね。
そうっすね。難しいというか。ここは好みに入ってくる気がします。
好みじゃないですか。夢見てマネジメントをしたいって言ったら増えたんですか?
39:01
痛い質問でなかなか増えないんですよ、これが。
マネジメントとリードってちょっと言葉の違いはあったりしてあれですけど。
違うしね、現実問題。
違うんですけど、結果求められているものって一緒じゃないって僕たまに思うんですよね。
それが悪いとも思わないしあれですけど、ただいいとも言わなくて、その現場にそれがはまって回るんだったらなんでもいいと思うんですよ。
なるほどね。
リードとテックリードと言葉の違いと役割、ちゃんと線引きできればいいけど。
リードもいてテックリードも両方いるんですか?
一応います。
リードは何やってるんですか?
リードの方がどっちかっつーとプロジェクトのリードをする方に近い。
テックリードはあまりお客さんとか出るじゃなくて、チームをオーダーして技術を総合的に見てレビューしたりとか言われますけど、
結果現場に入ってリードの仕事もしてるじゃんっていう人も多いなって思って。
それはよくなる。
じゃあそのリードメンバーがそんだけちゃんと舞台としていていけるのかっていうのはそれまで違うので。
そのリードの人たちは技術わかる人なの?
わかる人じゃないけど多分名乗ってないはずですね。
なるほどね。じゃあ今あれなんだ。チームがいてリードもいてテックリードがいるんだ。
一応いますね。
なるほどね。そこの線引き結構難しそうですね。
リードとテックリードがいないとPMもさすがに技術全部わかるわけじゃなくて、
技術分野に関してはもう賄ってくれる人がいる方がやっぱりいいよねって思ってるんですよ。
なるほどね。
プロジェクト的にはリードエンジニアがいて、プロジェクトマネージャーもいてって感じですね。
リードとテックリードが本当に両方とも良しそうなのかっていうのは僕の中で若干あるけど、
PMとテックリードが連携すればいいんじゃないのって結構思ったりはするけど、
あえてそこをリード入れてる理由はもっとたぶん知り入れてみたいなって感じはするけど。
何でしょうね。現場とのつなぎ役っていうのが意味ないとして強いのかな。
テックリードもその専属でこのチームに入ってるってわけじゃないので。
そうだよね。
現場と一番近いのはリードでお客さんとも喋れるかっていうところかな。
だからホサってことだよね。PMのホサってことでいいけどね。
そうそうそうそう。
PMOに近いのかな。PMOだってもうPMの上だからちょっと違うのか。
法廷的にはちょっと違うんだよね。逆なんだよな多分。
だと思いますね。
でもその方が誰かに依存しないって意味だっていいかもしれないですね。
多分、僕がいる時って結構そこを僕がリードもPMを僕が全部やってて、
結果僕に依存したっていうのも多分肩ボタンがあったはずなのかな。
それと誰かが辞めてもダメージはでかくないですよね。
それはそうです。
僕の場合は僕のチームって僕以外全員エンジニアで、
42:02
僕が売上見たりとかいろんなこと他全部やったじゃないですか。
だからそうはならないっていうメリットはすごくありそう。
そうはならないはずです。
そうしないとPMにいろんな仕事があったかタスクが溜まりすぎるんで、
疲弊するよね。
楽しかったけどね。
それはね。
いろんなことやれた方が楽しかったので、
逆にすごく感謝してるのはPMやったことないのに基本的に全部仕決定を任せてきて、
ほとんどの僕の肩ボタンはノーって言われたことなかったので、
すごくやりやすかった。
いっぱい失敗もしたけど、その失敗も含めて全部ちゃんと見てくれていて、
失敗したからって外すわけでもなく、相談しに行ったらアドバイスはくれるけど、
片岡さんからこうしなああしなってほぼ言われたことないんですけど、
僕にはそれがすごくよかったんですよね。
ああしなこうしなって言われるのは僕はあんまり好きじゃないタイプ。
そんな気がしますね。
そんな気がします。
結構任せてくれたし、さっき言ったやったことないこといろんなことをやらせてくれたので、
それはいっぱい今辞めた後にスタートアップの取り組んだCTOとかやってる時にすごい活かせたのし、
そうやってなかったら多分そういうポジションつけなかったなとすごく思う。
逆に会社がちっちゃくていろんなことができたらこそ自分の能力が上がったなって思う一方で、
さっき言ったみたいに依存したっていうのは多分会社じゃあるはずなので、
結局分割すればするほど人の成長スピードって限界出てくるじゃないですか。
やれる範囲が手間もあるんだ。
でもそこは難しさを感じます、僕。
僕はたぶんちっちゃい会社やるのはそこなんですよね、きっと。
ちっちゃい会社の方がいっぱい材料を持ててやれることが多いから、たぶんちっちゃい会社が好きなんです。
大きい会社行くと役割が限定的にされるじゃないですか。
例えばSREチームとかIOSチームとかなるじゃないですか。
僕はそういうのが好きじゃないんだろうなっていうのは自分で思います。
なるほどな。
自分の役割としてね。
チームを作る時に強みにやるのは全然いいんだけど、
誰かから見た時にあなたの役割これだよねっていう風に言われて、
例えばPMだからこれやりなさいとか、CTOだからこれやりなさいって言われるのがあんまり好きじゃなくて、
僕が必要だと思ったことがやりたいっていう感じだから、
この役職あるからこれやりなさいって言われると、ちょっとうってなっちゃうなって思う。
片岡さんからPMだからこうしなきゃダメだよとか言われたことほとんど一回もないんだよな、たぶん。
それは僕のことわかっててそう言わなかったので、僕は全然知らないんだけど。
それはすごくありがたかったなって思います。
なるほどですね。
成長の幅が狭まるわ。
最近は全員に裁量権を与えたっていう制度を作ったんですけど、
でもそれをフルに使えてるかっていうと実はそうではない人が多いなって思ってますね。
45:05
裁量権を出すって何でも自分で決めれるんですか?
一応決めれますね。
全社的に影響のある制度を自分で改編したり作ったりすることも新卒でもすれば出来ます。
面白いね。僕も結構裁量をもらってやれてたけど、それがだからもっとみんなやれるようになったみたいな感じなんですか?
そうですね。言ってしまえばそうですね。
だいぶ僕のチームは別の会社みたいって言われてたじゃないですか。
勝手にいろんなことやったし。
だから僕楽しかったんですけど、多分。
結構でも今全チームそんな感じになってきてるかな。
それめっちゃ楽しいですね。
プロジェクト単位で使ってるツールとかもバラバラだったりするし。
それ僕はすごい楽しいなって思うんですけど、やっててここ問題だなとか、ここやりづらいなって思うことは逆にないですか?
バラバラだったりすることによって。
川は何とも言えないですけど、知見の共有とかそっちのチームでせっかくうまくいってるのを他に展開しないのもったいないなみたいな。
今職能型になってるので、フロントエンドとサーバータイプ、iOS、Androidで、
流用できたり展開できるものあるけど、全然交流がないのが今一つの課題ですね。
同じプロジェクトだと接することはあるとしても、
フロントエンドとかAndroidとかないしね。
僕も当時他のチームとあんまり交流しなかったら同じことが起きてる感じですね。
特にコロナで地元になったから要求に加速するんで。
確かにね。
分発性とかコミュニケーションって場があったら、別にプロジェクトがなくてもちょっと気になって話しかけるとかできても、それもうなくなってからそれがむずいなって。
そうなんだよね。トイレ行くとかお茶取りに行くとかだけど全然違うんだよね。
ほんとそうなんですよね。
そう、その時に最近どうとか何やってるのっていうコミュニケーションってオンラインだと取れないから。
それの難しさは確かにあるよね。
感じですね。
大崎さんの会社は今フルリモートですかみんな?
うちは基本的にそうしてます。エンジニアで言うと対面で会ったことない人もいるので。
基本的には僕そもそもスポットメーカーに入ってる時ってちょうど2年くらい前なんですけど、最初からリモート前提の働く時間バラバラ前提の組織を作るって決めた上で入ってます。
確かそれをやった感じです。
非同期コミュニケーションの大変さってあると思うんですけど。
あるけど、それはタスクをちゃんと一周化するとかすれば割と防げる話だって、結構スラックだけでスラックだけのコミュニケーションを終わらせたパターンとか、
コートだけのコミュニケーションでしかやってない人たちって大体リモートうまくいかないっていう。
これってオフラインやり方をそのままオンラインに持ってきてうまくいかないという話であって、それはうまくいくわけねえじゃんと思う。
48:06
それでオフライン、それでリモートダメだってやってほとんどで。
実はそんなことなくて、そこはタスクの分解の仕方だったりとか、あとは働く時間バラバラだったとしても、
この時間帯でこれぐらいの時間帯しか取れない人にはこういうタスクを振るとかっていうか、マネジメント側でコントロールすれば結構割とワークするので。
うちでいうと社員3人なんですよね。
でも他の12人ぐらいって全員業務一択副業なんですよ。
それをGitHubのissueを使ってタスクベースでやっていて、
1週間に1回振り返り会みたいなのやってるんだけど、
ただ基本的には全部看板でやってるから終わって上からやってくださいって言ってるし、
分かんなかったら一緒に帰ってくださいって言ってるので、でもissue見れば分かるようになってるんですよ。
だから何していくか分からないってことは基本的にないんだよね。
issue見てできないなと思ったら次に優先の高いのからやっていくっていう風にやってくださいって言ってるので、
手が止まることがないような状態を作ってる。
大事ですね、確かに。
大きいタスクの時はもちろん全部使って説明したりするんだけど、
基本的にはほとんどの人が非同期コミュニケーション前提でやっているので、
同期コミュニケーション前提って結構辛いじゃないですか。
辛いですね。
子供もいる人もいれば、夜型の人もいれば、朝方の人もいる。
だから働き方って本人が選べばいいとずっと思っていて、
会社が強要するものじゃないとずっと思っているから、
その人たちがどうやったらパフォーマンスが出るかって考えるときに結局その結論に立ったって感じですね。
それこそ夢見にいる時もさ、韓国にいる人とかさ、
一時期留学してやってもいたし、あとインドにいる人もいたし、
そもそもお客さん自体が海外グローバルな企業だったから、
そもそも同期コミュニケーション前提で組織を作ろうと思っていないというか、
だいたいリモートできないっていうところは同期コミュニケーション前提で作っていって、
ダメだって言っていって、結局自分が変わってないパターンが多くて、
っていうのはすごく見ていても実感するかな。
なるほどですね。そこにたどり着くなって感じか。
ただ雑談が減るっていう問題点もあるし、
例えばクリエイティブな会話したいとか、絵を描きながら設計したいときは、
対面のほうがいいなって思うことももちろんある。
それはまさにそうですね。
それはめちゃくちゃあるけど、大変な仕事はリモートにできる。
それはリモートでできるし、新卒とかその人が技術してるかどうかはあんまり関係なくって、
そういう制度とかそういうふうな仕組みに切り替えられてない、
管理する側の問題だと結構思う。僕は。
別に新卒でも別に自立してなくても、
ちゃんとこういうふうにやっていこうって言えば浸透していけば全然できるから、
結局やり方の問題なんじゃないのって結構思ったりするけど。
はい、なるほどですね。
51:01
楽しいんですけど、実はあと5分で16時になるんですよね。
確かにそうだね。
次のミーティングは大関さんあるのかなと思って。
僕は今日はない。
ないんですか。僕もないんですけどね。
僕は今日ないです。
一応一旦1時間の区切りにしようかなと思って。
全然いいです。
喋り倒したら多分延々と喋れるんで。
そうだね。前の飯行った時、結構3時間くらい喋ってたもんね。
そうですよ、結局。
そうなんですけど、河野さんはやめてからの方が喋ってるからな。
そうなんですよね。やめてから2、3回会ってますからね。
そうそうそうそう。
その度に僕がいた頃とは全然違ってて、
マネジメントが楽しいって言ってくれる人が僕の周りもそんな多くないので、
そういう話を聞けたりとか、悩んでることとか逆に面白い考えを受けるのは僕も楽しいです。
僕の周りはエンジニアをやりたい人が集まっちゃうんですよ。
めんどくさいことやってくれるからって。
なるほど。
僕も一緒かな。私がエンジニアの中にいるからかもしれないですけど。
いやいやいや、分かんないですね。僕技術も好きだけど、人の方が面白いと思いますけどね。
人は面白いですね。僕は目立ちたくないけど喋るのは好きなので。
そうそうそうそう。
喋るのは好きなので、人は面白いなと思いますよ。
面白いし、自分一人でやるよりは、
チームを作ってチームの同じ方向に向かって成功した時の方が楽しいなって思うのも事実だし、
みんながこのチームにいて成長できたとか、楽しいなとか、
言ってもらえる方が喜びが強いっていうのも結構実感はしているので。
それはすごい思うけどね。また一緒に働きたいとか言ってもらえるとすごく嬉しいですね。
結構今も離職率が低いんですよ。
すごいじゃないですか。
ほとんど辞めてないです。
誰も辞めない。
業務委託も含めて抜けた人って多分、2年やってて1人か2人くらいしかいないんで。
2回目かな?1回目ないんで。それがみんな継続してくれてたりするので。
そういう意味だと、結構働きやすさを感じてくれてるのかなと思うけどね。
なるほどですね。
いやいやいや、とてもいい話だ。
聞いてみたかったんですけど。
はいはい。
モノスクールで好きだっていうし、現場の方が近いっていうのは感覚で知ってたんですけど。
経営者になってみて何か変わったものとか視点的なものでありますか?
一番は何かを判断するときに、これその質問の答えになるかもわかんないけど、
たまにエンジニアがわかることがあって騙すことは結構ある。
何か判断するときに、これやりたいなと思っても大変だなって思っちゃう。
54:01
ああ、そこはあるかも確かに。
だからそれがあって、むちゃ振りしづらいなって思う感覚がどうしてもあるのか、
よく邪魔をしてるなって思って。
変わったことっていうと、やっぱりもうちょっとビジネスサイドを見るようになったので、
その辺の大変さ、要は綺麗に作るだけでビジネスになるわけじゃないし、
それこそマーケの話だったりとか、
どういう施策って広げていくか含めて、
僕めちゃくちゃその辺が弱いので、一緒にやってる人から学ばせてもらってるので、
その辺の視野が広くなったっていうのはあるし、
あとは従業員にいるときは全然気づかなかった、
例えば総務の大変さだったりとか、
スタートアップだったんで、一時期支払いとか全部自分でやったし、
保険は税理士さんとやり取りとか、
あとはローム周りのやり取りとかも結構自分でやってたんですよ。
全部やって銀行行って支払ったりとかいろいろしたんですけど、
その辺の大変さだったりとか、あとは税金高えなって思ったりとか、
いろんなことをやらないと、いろんなことやって会社って回ってるんだなっていう大変さは
すごく身に染みて分かった。
それで言うと、夢見にいるときって、
総務の人たちいろいろやってくださったじゃないですか。
僕は一番感じたのは、そこでやってもらった総務の人たちとかが
いたからこそ僕らがパフォーマンス出せたんだなっていうのはめちゃくちゃ実感した。
それが一番大きい発見だったんじゃないのかな。
めちゃくちゃこの話は日本中のエンジニアに言いたいなって思います。
自分がパフォーマンス出せるために周りがすごく動いてくれているっていうのは、
自分でいろんな作業をやってみてすごく発見があって、
経営する能力ってとこ、僕まだ8ヶ月くらい経ってないし、全然やれていないんで、
まだまだ足りないものだらけなんてなんとも言えないんですけど、
やっぱり一つのプロダクトを作るとか、エンジニアが開発するための環境を
周りが整えてくれてるんだなっていうのは、自分が経営する側に立って、
しかも人がいなくてやらなきゃいけない状況になってやってみると、
めちゃくちゃありがたかったんだなって思う。
だって実装したいし、設計したいのに、
銀行閉まるから行かなきゃいけないとかあるわけですよ。
給料くれるな、でも今日まで税金払わなきゃいけないなとかあるし。
ありますよね。
そういうことでみんなの社員の給料も自分で払ったし、
あとは税金、さっきの税金が一人雇ったときの社会保険の高さとかさ、
実際やってみるとわかんないじゃないですか。
だって思うからね、やっぱり。
そういうのは、経営する側に回って、
いろんなことが前とは考え方が変わったというか、
エンジニアリングとかプロダクトを作るところしか見てなかったところの視野からは
だいぶ広がったのはあるかな。
57:02
その反応するときにたとたまにエンジニアが邪魔するっていうのも
今すごく感じてる。
エンジニアに無茶振りできないんですよ、私。
僕も苦手ですよね。
分かっちゃうから。
これ大変だなとか、データベースの行動こうなってるから
これ超大変だなと思っちゃうじゃないですか。
でもそれだとビジネス進まないときもあるから。
それが邪魔だなって思うときは結構。
難しいですよね。
大変だけど、エンジニアを守る立場にいるのがリードだったりするので、
判断しづらいけど。
そうなんですよ。僕今代表とCTOを兼務してるんですよ。
CTOでいなきゃいけない自分と代表でいなきゃいけない自分、両方あって。
CTOってエンジニアリング守んなきゃいけないじゃないですか。
守るっていうか、開発しやすい環境を作らなきゃいけないじゃないですか。
VPU的なこともやらなきゃいけない。
代表がやってるから、意思決定として2つしないといけないんですよ。
どうしても比重がCTOに寄りがちになっちゃうのがダメだなって自分ですごく思います。
気持ちはわかるけど、同じじゃないから完全に理解できないのが難しいですね。
これはすごく難しいというか、歯がゆいというか。
逆にCTOを持ってるからこそ、そっち側もちゃんと見なきゃいけないっていうのもあるし、
経営もしないといけないじゃないですか。
経営がどうしても苦手というか経験がないんで、
やっぱCTOの方がやりやすいからそっちの比重が高くなったりとかっていうのも
自分の中で判断しちゃってる時あるので、
あ、逃げてるなって自分でわかるんですよ。
その辺をロール外したほうが本当にいいんだろうなって思いました。
素直にその悩んだ時点で一回メンバーに聞いてみてもいいんじゃないかと思ったんですけど。
正直ベースで多分大変でしょうけど、どこまでならやれるとかっていう。
こうやったらやれるって実は自分でない考えが出てくるかもしれない。
そうですね。それはね、やってるやってる。
最近やってるようになったんですよ。
とりあえず開閉ならわかってるけどやってって言えるようになったんだけど、
言った後の罪悪感がすごいって感じです。
それはありますよね。
言うんですよ。言わなきゃいけない言うんだけど、
言った後に無茶振りしてるよなって思うし、
そういうこと言ってて、あの人最近変わったねって思われてないかなとか、
昔は守ってくれたのに守ってくれないのかっていう不安がある。
しょうがないんだけどね。
それは絶対出てきますよ。みんな言わないだけで。
しょうがないんだけどね。
それは夢見る時もたまにあった。
売り上げ稼ぐために無茶振りして稼げるやつで、
でもそういう時は原田さんとか結構無茶振り答えてくる人だった。
はいはいはい。
結構答えてたんだけど、
でもほら、そういう人だけじゃないじゃない。
1:00:01
で、今ってよりみんなさっき言ったように綺麗に作りたい人がかなり多くなってるし、
ふたえたまってやりたくない人が多いって事実としてはあるので、
無茶振りするとどうしてもふたえが生まれやすくなったりもするじゃないですか。
スケジュール厳しいし。
そういった後の、分かってるけど言わなきゃいけないっていう葛藤はあるよね。
はい。絶対あります。
分からない方が無邪気に見えるんだなっていうのはすごい思います。
それはある。本当に。
メンバーからするとね、代表がエンジニアが分かってるって安心感は多少あるかもしれないんだけど。
それは本当はあると思います。
どっちもどっちな気がしますから。
なるほどですね。
過ぎた時間?
そうですね。一旦そうですね。一時間経ってたので、一旦ここで終わりたいなと思います。
最後に大崎さんから宣伝とかありますか?
宣伝?宣伝か。
もし一緒に働きたいなって思う人がいたら、
くわるはたん経営院で紹介してもらえると嬉しいなと。
うち副業とか業務委託がすごく多いし、
基本的に働く時間だったりとか、メインバラバラだったりとか、
それも受け入れられる組織だし、それでもパフォーマンスできるような環境がある。
スタートアップで働きたいとか、でも転職怖いけどちょっとやってみたいみたいな人がいたら、
全然声かけてもらえれば一緒にできるかなと思って。
これぐらいかな。
はい。ありがとうございます。
優先ネクストグループでしたっけ?
優先ネクストグループですよ。
認識改めておきます。
そっちでもいいし。
ありがとうございました。
じゃあ、一旦これで区切りたいと思います。
今日は大沢さんわざわざ1時間も急ですけども、お時間いただきありがとうございました。
ありがとうございました。
