事業とエンジニアリングのミスマッチ
はい、趣味でOSSをやっている者だ。引き続き、しんぺいさんをゲストに迎えてお話をしていきます。
じゃあ、後半スタートですが。
はい、よろしくお願いします。
大丈夫ですかね。
はい。
何から始めますかね。
ちょっと難しい書き方しちゃったけど、事業とエンジニアリングのインピーダンスミスマッチあるあるの話をしたいなと思ってまして。
事業とエンジニアリングって言うと、ちょっと言葉がでかすぎるかもしれないんですけど、プロダクトマネジメントとエンジニアリングでもいいかもしれないっていうくらいではあるんですけど。
結構いろんなところであるあるの話として、ある程度成功を収めて、例えばある領域で成功を収めた、バーティカルサーズとかでも、こういうターゲットのユーザー、こういうセグメントのユーザーさんにはだいぶもう使ってもらえるようになった。
4年みたいな話になってきたときに、サーズそこからさらに成長していくためにはどうしたらいいってなってくると、今まではターゲットになってなかった、今までは使ってもらえてなかったセグメントのところにどうやってリーチしていこうかみたいな話にどうしてもなっていくっていうのは絶対にある話だなと思ってますと。
なったときに、これある種気まじめに新しいセグメントの人たちの抱えている課題、これをどういうふうに解こうかっていうのは、ある種気まじめにあるセグメントのユーザーさんの課題に対して、ではこういう打ち手をしましょう、あるセグメントのユーザーさんに対してこういう打ち手をしましょうみたいなことをやっていくのって、真面目に考えるとそれはそうだよねって話になってくるんですけど、
これをやったときに、プロダクトってどんどん複雑化していくじゃないですか。いろんなセグメントのユーザーさんに使ってもらうためには、じゃあこういう機能が必要だよねみたいな話とかが出てきて、で、そのある機能Aとある機能B、実はこの使ってるユーザーさんのセグメントは違うんだけど、でも仕様的にはどうしても同じアプリとして結合していってなってくると、
プロダクトの当然運用保証にかかるコストっていうのは、絡まる要素が多ければ多いだけ、指数関数的にコストは伸びていきますよねって話があります。一方で売り上げって、じゃあこのセグメント、このセグメントのユーザーさん、このセグメントのユーザーさんってやってるときに、売り上げって値上げをしない限り、先継にしか伸びないと。
売り上げは先継に伸びていくんだけど、先継なんだけど、かかるコストあるいは追加開発にかかってくるコストみたいなものって、指数関数的に伸びていくよねっていう問題っていろんなところで起こってると思っていて、この辺結構エンジニアの腕の見せ所でもある、実は。
より良い抽象へのインターフェースを提供できるように、エンジニアの提案力の見せ所でもあるみたいなところがすごいあると思ってて、この辺結構困ってる人たち多いんじゃないですかって思ってちょっと話してみたいなって感じですね。
たぶん、今僕はすごいピンときてるんだけど、たぶんちょっと抽象的な話だったからあるけど、ある意味、顧客のセグメントがドンピシャの人たちだったらすごいミニマムな機能セットで済んでたものを、もうちょっと顧客のターゲットを広げていくってなったときに、
問題解決の視点
その人たち向けの機能みたいなものを結構作る必要が出てきて、そうすると、プロダクトの複雑度みたいなのが上がってしまうし、1個の顧客を獲得するために、逆にプロダクトの複雑度みたいなのが指数的に増えてしまうっていう、そういう話ですよね。
そうなんです。
よくあるのは、割と緩いウェブ企業しか使ってなかったようなエンジニア向けプロダクトみたいなものがあるけど、それをちゃんとエンプラ向けとかに売っていきたい、ちゃんとしたしカッチリした大企業に売っていきたいってなると、
例えば、よくあるのは権限管理の話だったりとか、セキュリティの話とか、そういったのもそうだし、例えばワークフロー的な、そういうところをちゃんと実現したいみたいな、そういう話が出てきて、そういった要求に対してどこまで向き合うかとか、みたいな話がありますよね。
そうなんですよね。
その辺って、何か回答っていうか、何らかの対応方法みたいなのって思ってるものはあるんですか。
僕はこれ、二方向から解決策があるなって僕は思っていて、この問題だけじゃないんですけど、こういう問題もあるから、やっぱり経営にエンジニアが入るっていうことの必要性の一つがここにあると思っているっていうのが一個ですね。
経営にエンジニアリングの視点を入れる必要がある理由の一個がこれで、これ経営だけじゃなくて、プロダクトマネジメントにエンジニアリングの視点を入れる必要がある理由の一つでもあるなと思っています。
これは要するに、これだけ技術的なコストがかかるようになるけど、それにペイできるだけの売り上げ、あるいはユーザー数の増加につながるのっていう方面からの問いをきちんと投げかけること。
それで取れるセグメントとかってそんなに大きくない、あるいはそこを天秤にかけた時にこれ本当にやるべきですかっていう方面からのアプローチが一つと、もう一個は、うん、やるべきなんだよってなることって絶対あると思ってて。
そうなった時に、やっぱり一つはどのように問題をほぐして、なるべく素結合になるようにサービスの使用、あるいはシステムのコンポーネントの分け方とか、なるべく素結合になるようにするにはどうするかっていうところでエンジニアが頭に汗かくみたいなところだったり、
あるいはそもそも素結合にするどころか、この一個の仕組みを作っておけば、いろんなユーザーさんのニーズに応えられるよねっていうすごく筋のいい解決策。
今まではこのユーザー向けの仕様だったからこうなってたけど、この仕様をこういうふうにちょっと拡張するだけで、より多くの解決策を導けるよねみたいなところにプロダクト仕様を落とし込んでいくみたいな、そういうそれをやっぱりやるべきなんですってなったらいかに素結合にシンプルに実現するかみたいなところを
本当にここはなんだろうな。じゃあどうやったら素結合になって、じゃあどうやったらシンプルになるのっていうのはすごいケースバイケース過ぎて一般界ってないと思うんですけど、一般界にないからこそそこが結構エンジニアの頭の汗のかきどころだなっていう感覚がすごいありますねって感じかな。
そうだよね。やっぱりやらないといけないみたいなことはあるから、やりたいみたいな時もあるから、そういった時にすごく設計とか難しさが問われる部分ではあるかなっていうのはありますね。
ちょうど最近、僕が関わってるヘンリーっていう会社のポッドキャストでも、やっぱりすごく複雑度の高いシステムを作ってるからどういうふうにそれをうまく実装していくのか難しいよねみたいなことをちょうど別のポッドキャストでも話したりしたんだけど、
やっぱりそういう、そこで実はエンジニアの技術力とか実力が問われる部分があるから、やっぱりそこすごい面白いところではあるよなっていうのは思ったりはしています。
そうなんですよね。面白いところだし、結構事業が伸びていくためのボトルネックとしてになりがちな部分でもある、実はと思っていて。売上げを先行に伸ばしていく。売上げ伸びても結局コストが何倍もかかるようになっているんだったら、利益としてはどうしても伸びないわけじゃないですかっていうことを考えたときに、
結構その、そこの能力が実は事業にとってのボトルネックだったりするみたいなケースって結構あると思ってて、まずそれに気づける必要があるっていうところから結構すでに難しいっていうのが、なんか事業って難しいなっていつも思うポイントっすね。
そうだよね。あと、やっぱりちょっと機能を追加するときとかに、もちろんある一部のお客様しか使わない機能とかそういうのは当然あるとは思うんだけど、それによってやっぱり既存の顧客が損をしないかどうかっていうのはすごく考えたほうがいいと思っていて、その機能を作って複雑度を上げたりとか、
システムが不安定になるリスクみたいなものがあったとして、やっぱそれって既存のお客様に迷惑をかけることになるから、やっぱそういうとこ観点も含めてある意味やるべきじゃないっていう話をしたり、どううまくやるかっていう話をするみたいなのはあるのかなっていうのは思ってますね。
サーズとかだと、ある特定のお客様に肩入れすることが、やっぱりそれって他のお客様に対するサポートを薄くするっていうことになっちゃうので、もちろんだからそういう特別扱いするとか、そういうところに対してアドでペイを払ってもらえるなら、それはそれで対応したほうがいいと思うんだけど、
不真面目な開発プロセス
そうじゃないのであれば、やっぱりそこはあんまりちゃんと不公平にならないようにしたほうがいいよなっていうのは思ったりはしてはいます。
まあとはいえね、結構特に初期でもそうだけど、ソフトウェアとかサーズ開発で、初期の大型顧客みたいなのをいかにしっかりグリップするかとか、そのために多少ソフトウェアを歪めるみたいなこともやっぱりやったほうがいいとは僕は思うので、やっぱそういうところに難しさはあるかなっていうのは思いますね。
そうですね、結構この悩みを持てるっていうこと自体が、実は結構贅沢な話で、ある程度成功してというか、きちんと既存のお客さんに満足して使っていただいてみたいな状態になってないと、この悩みって持てないので、
だし、ある程度の成功してもっと成長したいっていう風にならないと、なかなかこの悩みって持てないので、こういう悩みが持ってってる時点で実は結構幸せな環境ではあるみたいな話もあるかもしれない。
そうね、そう思います。なんかやっぱりよく言われることとして、百得ナイフを作らないとか、ソフトウェアに運用を合わせてもらうんだみたいなことを言うし、それはやっぱ一定の妥当性はあるとは思うんですけど、それってすごいもっともらしい比例ごとで、もっとちゃんと顧客に向き合えよみたいなのもあったりするわけじゃないですか。
わかります。
ただ、結構大事なのは、できないものはできないっていうのを認識することがやっぱり大事だし、ちゃんとそれを伝えることって大事だと思うんですよね。
だから今、ある課題があった時に、それ今僕らは解決できないよねっていうことを、ある意味認めることも結構大事なんじゃないかなっていうのは思うんですよね。
なんか、それを無理やりいい解決方法が思いつかないときに、やっぱりワークアラウンド的に頑張りすぎちゃうと、やっぱりうまくいかないことっていうのは結構あるよなっていうのは思っているので。
やっぱり、医師とかそういう、例えば病院とかだと、患者さんに不老不死にしてくださいみたいなこと言われても、それはできませんよっていう話じゃないですか。それでフランケンシュタインみたいなものを作ってもしょうがないので、結構課題があったら解決できるかもしれないけど、それは今じゃないよねっていうものって結構あると思うんですよね。
あと、ある課題に対して、あるハウに対して、あるホワイに対して、ハウみたいな、ホワットとかハウを一対一対応させない方が良いと思っているんですよね。
やっぱりそういう意味では、結構宮本茂さんのアイデアとは複数の問題を一気に解決するものであるっていう言葉があると思うんですけど、やっぱり一つのホワイとか課題に対して、一個一個機能を作っていくみたいなことをしちゃうと、やっぱり途端に複雑度が上がっちゃうので、そういったところが結構、それって筋が悪いんじゃないかとか、
その問題だけを解決するものを作らない方がいいんじゃないか、今はそれは作れないんじゃないかみたいな、そういう話をするのが結構大事だよなって思います。
これは今できません、できませんとか、まあそれはどううまく言うかはあるんだけど、あとなんか僕は結構言うのは、これは結構発明が必要だよね、みたいなことを言うことはあって、やっぱりできないことってあると思うんですよっていうのが結構前提としてあって、やりたいけどできないこともあるっていうのを認める。
自分たちも認めるし、お客さんにもわかってもらうというか、みたいなのはあるんじゃないかなって思ったりはしてますね。
そうなんですよ。表現が合ってるかわかんないんですけど、プロダクトを長くきちんと伸ばしていくために、ある種の不真面目さって結構大事だと思っていて、その不真面目さって何かっていうと、今言ってた、ソンムーさんの言ってた、まさにそれが言いたかったことの一つなんですけど、
ホワイ一つに対して、ハウ一つを気真面目に対応させてやっていく。それって結構真面目に考えるとそうなりがちじゃないですかっていうのはあって、それは結構、それやってるとでもそれこそプロダクトは指数関数的に複雑になるんだけど、解決できるホワイの数は線形にしか伸びないっていうことが起こってくることになっちゃうんで、そこは気真面目にやらないみたいな。
不真面目さの重要性
もうちょっと、タイダーは美徳みたいな話で、もうちょっと一気にいろいろ解決できる発明仕組みってないかなって考えることがすごい大事っていうのは本当そうだよねっていうのは、ある意味気真面目にやらないみたいな話がそうだし。
もう一個は、1個ホワイがあったときに、これは今じゃないかもみたいなふうに、気真面目に1個1個これを必ず解決しなきゃって気真面目にやっていかないみたいなのも、ある種の不真面目さみたいな。不真面目さっていう言葉が正しいのかわかんないけど、っていうのは結構大事かもなっていうのは結構僕思うところですね。
すごく真面目に1個1個の問題に解決に当たろうとしたりすると、結構この死が待ってることが多いよねって話はあると思ってて、不真面目さっていうと言葉があれだったら、柔軟さというかっていうのは、そういう、なんだろうね、気真面目に1個1個やって死に至らないためには重要だよねみたいな話をしてたんですよね。
そう、そうだよね。そう。なんか結構やっぱり、今倒せない敵みたいなのがいるっていうことの認識も大事だなと思っているので、やっぱり今倒せない課題みたいなのがあるっていうことを、それを多分無理に解決しないほうがいいみたいなのとか、なんかあんまりいい解決方法が思いついてないのに、やっぱり無理やり実装してしまうみたいなのが、やっぱりそういう気真面目さみたいな。
あんまり良くない気真面目さみたいな時に起こりがちで、やっぱりそういった時に無理やりひねり出した機能みたいなものが、後々結構小骨みたいに不採的な感じになって困るみたいなことは結構あるよなっていうのは思っているので。
あとなんかそういう、今倒せない課題みたいなものも、時間が経つと、あ、これってこうやればいいよねとか、思いついたりすることってあったりするし、あとは今、もうこれとこれとこれが揃ってるから、これって実はすぐできるじゃんみたいになることも結構あるから、なんか結構そういうふうに、この問題を解くのは今じゃないみたいなのってすごくある。
実はあって、そういう企業、機会を伺うみたいなのとかは大事なのかなって思ったりしてます。
開発プロセスの型化
いや、わかります。そうなんですよね。気まじめさの話、僕もう一個したい話があって、結構僕その、個人的にはっていう話なんですけど、開発プロセスとか、あるいは企画プロセスみたいなのをきちんと型化しましょうみたいな気まじめさも、僕結構反対派というか、会議的なんだよね。
その気まじめさは本当に、その事業にとって、あるいはプロダクトにとってプラスになるのだろうかみたいな、結構会議的なことが多くて、その、やっぱね、気まじめにやる、気まじめに考えると確かに、そのなんだろうな、きちんと型を作って、その型に沿ってやれば一定のクオリティがちゃんと担保されることにして、例えば俗人性をきちんと排除していってみたいな話って、真面目に考えるとそれはそうっていう話ではあるんですよ。
ではあるんだけど、結構その、特にソフトウェアエジニアとか、ソフトウェアを使って問題を解決するドメインって、その、それで型化することで解決することが実は結構少ないんじゃないかって僕は思っていて、
何でもそうなんですけど、型化することによって何がいいかっていうと、ボトムラインが上がるっていうのはすごいやっぱあると思うんですよ。その、型を作る、ルールを作ることによって、その、ボトムラインは上がるんだけど、トップラインって引き上がらないじゃないですか。
そうなんだけど、さっき言った問題を解くみたいな、そういう、発明が必要だよね、ここはとか、アイディアはその、一気に複数の問題を解決するものがアイディアだみたいな話って、ボトムライン上げても実はあんまり解決することが多くなくて、トップライン上げないと解決しないことがあると思うんですよね。
なった時に、実は、例えばこの開発プロセスの改善を頑張りました、その結果として型がきちんとできて、みたいなことって、すげえ言い方悪いけど、仕事してる感はすごい出るんだけど、でも実は問題は解決していないみたいな、問題のボトルネックは実は解決していない。
そこを型化することで解決、なんか良くなったことは、そこは実はボトルネックではなかった。事業にとって、あるいは組織にとってボトルネックではなかった、みたいなことってすごいあると思ってて、この辺も気真面目にきちんと型を作って、その型の通りに運用しましょう、みたいな気真面目さみたいな、結構捨ててもいいタイプの気真面目さだよねっていう、結構過激な思想を持っている。
そうね、いやそれねすげえわかるなぁ、でもVPがそんなこと言っていいんですか?みたいな感じになっちゃうけど、いやでもね多分その感覚は結構僕の近いものはあって、やっぱり誰でもできるようにすることとかってすごく大事だし、それで多分ベースのスピードはすごく上がるんだけど、
その、まあカタカによってやっぱりそのもちろんみんなの生産性が上がるみたいなのはすごくあると思うので、結構ある意味投資する価値があるところだとは思うんですよね。まあただそれでそういったことをやることが逆にそのこうユニークな人の生産性みたいなものを奪うことになるのが問題だなっていうのは僕は思っていて、
その誰でもできるようにしましょうってした結果、この人にしかできないことは悪ですってなっちゃうと良くないなっていうのは思っているので、でもなんかエンジニアのこう活動とか仕事みたいなのって結構クリエイティブな部分があると思うから、この人がその思いついたからできたとか、この人のこのスキルだったりがあったからできたとか、やっぱそういうのって割とその人が持つユニークさだったり、
アジャイル開発の思想
まあさっききちんぺいさんトップラインって言ったけど、やっぱそういったものをどう発揮してもらうかみたいなところはすごくこうあると思うので、そうだね、なんかそこをどう
そういう創造性だったり発明だったりが生み出されるようにするかみたいなところにもっと投資をしてもいいかなって思うことはあるね。
非常に大人にまとめていただいてありがとうございます。でもそういう話なんですよね、結構そのカタカサすることで、カタカサされるべきところって結構あると思うんですよ。
例えばなんですけど、うちのクラッシーっていうサービスは学校に使っていただくサービスなんですよ、基本的には。そうするとやっぱその年度が変わるたびに何かやらなきゃいけないことがあるみたいな。
これは年度が変わるたびに必ずやらなきゃいけないことなんだよ、みたいなものはやっぱりきちんと型を作っておくっていうのはすごく大事で、毎回そこを再発明する必要はないというか、毎回それ再発明したらそれだけで1年終わっちゃうでしょって話がやっぱあるんで、そういうところっていうのはカタカサした方がいいところってあるんですよね。
なんだけど、そういうところはカタカサした方がいいってすごく強く思うんですけど、一方で結構プロセスをカタカサしようみたいなところは、その創造性を殺す方にやっぱり型の東だなと思っていて、そのガイドラインとしてプロセスがある、プロセスの型があるっていうのは結構大事かもしれないって思う。
例えば、スクラムっていうフレームワークは僕すごいよくできてるなって思うことが多いんですよね。あれとかも、そういう型を知っているっていうことはすごい大事なんだけど、これってスクラム通りに動いてないよねっていう発言にはあんまり意味がないと思ってる。
そうだね。
って感じかな。
それはあるんだよな。やっぱカタカスるとかそういったものがあると、そこに安住してしまって、改善するインセンティブが生まれづらいみたいなところがすごくあるから、やっぱ改善サイクルをどう回すかみたいなところもあるよなっていうのは思うし、
やっぱり属人性を排除するみたいな言葉については僕はかなり気を使っているというか、割と気をつけたほうがいいなって思っているので、それってある意味、ユニーク性みたいな、ある人のユニーク性、それによる価値みたいなものを既存することにならないかっていうのはすごく気をつけてることではあるね。
エンジニアはやっぱり取り替え可能な、誰でもできるようにすることに価値がありますみたいなのって、すごく善意の舗装道路みたいな感じがするから、地獄につながる舗装道路みたいな感じがするから、ちょっとそこはあんまり気をつけたほうがいいなっていうのは僕もすごく思っている。
そうなんですよ、そうなんですよ。
ちゃんとエンジニアだったり、それに限らないけど、やっぱりそういう創造性を出すことも大事なんだよっていう、もちろんそういったある程度落ち着いたらカタカシして、その引き継いだりとか、他の人にもわかるようにするとか、そういうのは大事なんだけど、最初から別に属人性を排除しなきゃいけないみたいに思うのは結構危ないよなっていうのは思っては。
まあ、いますね。なんかその人にしか書けないコードであっても、まあ最終的には捨てるなり引き継ぐなりできればいいだけの話だから。
そうなんですよね。僕はアジャイルソフトウェア開発宣言すごい大好きで、アジャイルソフトウェア開発宣言にもプロセスやつよりも個人と対話をっていう一説があるじゃないですか。
結構ね、このアジャイルにやってますみたいなことを言うときに、やっぱりこのアジャイルソフトウェア開発宣言って立ち返っていい、すごいいい宣言だよなって思ってるんですよねっていう話。
わかる。そう、いや本当そうなんだよね。なんか本当にプロセスやツールよりも個人と対話をだから、別にこう本来のスクラムはどうこうとか言い出す人がいるのが信じられないというか。
あなた、そもそもアジャイル開発をやろうとしてるんですよねっていうのを思うから、なんか基本的に、アジャイルソフトウェア開発宣言僕もすごい好きなんだけど、
なんかもう、なんか当たり前のことじゃん。当たり前のことというか、すごく大事な話をしてるじゃん。なんかそのアジャイルに、なんだろうな、アジャイルにやってますやってませんみたいな話ってあんまないと思ってて、
普通にソフトウェア開発することが、やっぱりそのある意味アジャイルソフトウェア開発宣言に書かれてるようなことを、やっぱりその意識してやっていくことが大事なんですよっていうことだと思うから、
なんか僕、そのアジャイルでやってますやってませんみたいな、そういうのピンとこないっていうか、アジャイルでやるに決まってんじゃんみたいな、そういうふうに思うんですよね。
うん、そうですね。
なんかそこで言うアジャイルがなんかスクラムのことを指してたりするから、すごく混乱を生むみたいなのがあると思ってて、いやそこは多分その根本的な思想としての、そのアジャイルソフトウェア開発宣言があって、
で、その上のフレームワークとしての、なんか手法としてのスクラムがあるから、なんかそのアジャイルでやってますみたいな話をスクラムでやってますみたいなところに、やっぱみんなすごく、やっぱスクラムっていうものの影響力が強すぎるから、強すぎるっていうか、やっぱもうデファクトスタンダードみたいになってるから、
実際よくできたフレームワークですから。
いやいや、そうそうそうそう、よくできてるし、僕は別に全然好きなんだけど、そう、なんか、こう、
まあでも壮大さんの言葉を借りて言えば、それはハウないよっていう話なんですよね。
そう、そうだし、なんかもうすぐウォーターフォールとアジャイルの比較みたいな話になって、
いやもうウォーターフォールもアジャイルでやってるからいいじゃんみたいな感じになるんですよね。なんかそこって別に対立概念じゃないからっていう、そういう気持ちによくなります。
いや、超わかるな。
はい、そうね、なんか、結構そういう、堅苦しく、どんどん堅苦しくなっていくみたいなのに対して結構敏感にでありたいっていうか、
ちょっと、なんかもうちょっといい方法を、なんか、うん、やっぱ考え、やっぱ発明が必要なんじゃないのって思うことはあるよね。
やっぱその、一個一個全部きっちり、きっちりこう守っていくっていうよりかは、なんかそういう複数のやらないといけないことと解決しないことといけないことに対して、
やっぱりその、一個のこれださえあればOKみたいなことをしていかないと、もうなんかその、こう、やらなきゃいけないみたいな、とみんながこう思ってることがどんどん積み重なって、すごく身が重くなってしまうみたいなのはあるよね。
そうなんですよね。やっぱなんか、それって本当にちゃんと、最終的に顧客に価値が届くところに寄与してるの?っていうのって、その視点ってすごい大事だと思ってて。
気真面目にやると、どうしてもこの、やらなければならないことっていうふうに向き合いがちになっちゃう。
で、やらなきゃいけないことはやらなきゃいけないことなんで、気真面目になる瞬間っていうのも大事なんですけど、同時に不真面目な自分もどっかにいたほうが良くって、
不真面目な姿勢の重要性
その不真面目な自分は、今やってることからパッと目を背けて、本当にこれって顧客の価値にどういうふうに繋がってるんだっけ。繋がってるからどういうふうに繋がってるんだっけ。
その時、本当に今ここが取り組むべきことなんだっけみたいな視点っていうのは、もっと言ったほうがいいよねっていう感じがしますよね。
そう、真面目にやればやるほど、それこそ複雑な法令とかセキュリティとかそういったものが関わるものになってくると、
やらなきゃいけない理由みたいなのがどんどん出てくるんですよね。
し、これもやっておくに越したことはないみたいなものがどんどん増えてきちゃって、すごく身重になっちゃうんだけど、
そういった時ほど、やっぱりMVP的にミニマムでやることは何なのかっていうのをちゃんと考えたほうが良くて、
やらなくていいことみたいなのをちゃんと洗い出す必要があるし、
なんでもそうだけど、ナイスとハブなものがいつの間にかやらなきゃいけないことになってるみたいなことが多いから、
これやらなくていいですよねっていうのを、やっぱりすごく言って言うなり、そういうやらなきゃいけないですよねみたいな、
圧にいかに負けないかみたいなのは大事だなっていうふうに思いますね。
わかります。
普通にね、日々の習慣とかでもね、今日はこれやらなくていいじゃんみたいなのあったりするから、
でも、これやらないと気持ち悪いとか、そういうのもあったりするけど、
例えば歯磨きの後にフロスとかをしてるとして、今日フロスやらなくてもいいじゃんみたいな、そういうのあると思うんですよ。
これが良いかどうかなのかわかんないけど、何にしてもミニマムにやらなきゃいけないことを洗い出す、
やらなくていいことをしっかり主張するっていうか、ちゃんと言うみたいなのが大事だなって思いますね。
いやーわかるなー、これ息子の勉強とか見てても、真面目にやるとしたらそれこそ先生に言われたことをきちんとやりましょうとか、
すげーわかるんですけど、僕結構不真面目な学生だったので、
だってもう理解してるし、演習やっても解けるんだからこんなのやらなくていいじゃんっていうのをいかにサボるかってことをすごい考えてたんですよ。
だし、高校生の頃、ノート提出課題っていうのがあって、これ身につけるっていうワットに対して、こんなハウの指定の仕方、許せんわって僕思ってて、高校の時にノート提出課題。
教科書提出したことがあるんですよ、ノート提出課題に。すっごい怒られたんですけども。
でもそういう不真面目さって結構、ソフトウェア開発で想像的な仕事だと思ってて、そういうのって結構大事だよねって思うんですよね。
そう、そうなんだよね。うん。まあわかるな。やっぱそこでも結局、やりたいかどうかみたいなのが大事な気がしていて、やっぱりやりたくないけどやんなきゃいけないみたいなものが出てきたときに、
そのままいかないといけないときもあるんだけど、それをやりたいと思えるようにすればどうすればいいかみたいなのを結構僕は考えるようにしてるし、むしろやりたくならないんだったら、むしろこれってやんないほうがいいと自分の直感が言ってるのではないかみたいな、そういうのはあるよなーっていうのは思っているので。
結局、やっぱりスパークジョイじゃないけど、やっぱ結構、プロダクトのイシューリストとかそういったバックログとかを見てても、結構やりたいものやりたくないものとかもあるし、突然いい開放が思い浮かんで、すごくやりたくなるときとかがあるんでしょうね。
なんか、やっぱそういう、結構そういう意味で本当にやりたくなるかとか、最初の発信の話とかにちょっとつながるかもしれないけど、なるべくそういった方にできないかなっていうふうに思ってる。すべてそれでうまくいくわけではないと思うけど。
そうですね。
この話はそんなとこかな。
キャリアプランに関する悩み
そんなとこっすかね。
じゃあ何、最後キャリアプランの話しますか。
しますか。
多分これ、そんぺさんと個人的にこの話はしたことがあるのかな、多分、なんですけど、僕キャリアプランって考えたことがないんですよ。ほとんどなかったんですよ。
キャリアプランって具体的には例えばね、何年後にはこういう仕事をしていたいから、だから今はこの仕事をするべきでとか、そういうことってずっと考えたことがなくて、なかったんですよ。
なかったんですけど、実は1、2年前ちょっと悩んでた時期があって、それが何かっていうと、結構今から考えるとちょっと視線が、視線がというか視野が狭かったなって思うんですけど、エンジニアリングの人として食っていくのか、事業の人として食っていくのかっていうことをちょっと意識したんですよね、その時。
なるほど。
結構、今までキャリアプランを考えたことがないっていうのは、確かにプランはしてなかったんですけど、じゃあ何やってたかっていうと、今、例えばこの会社あるいはこのチームで、自分がやるべきだし自分がやりたいと思えることって何だろうっていうのを考えて、
で、自分がやるべきだしって思えたことに集中してただけっていうのはすごい、それは言っていいと思ってて、なんでその自分が今解くべき問題だし自分が解きたいと思える問題っていうのに集中してたら、なんかだんだんいろんなことを経験できて、結果としていろんなことが経験できてすごい成長できたから、キャリアプランっていうのは描いてなかったんだけど、結果としてはいろんなキャリアが積まれてきたみたいな感じだったんですよね。
で、それをやってたときに、結構その、今の会社ってすごいありがたいことに結構強いエンジニアに恵まれていて、で、結構その、なんかのスペシャリストみたいな人が結構いるんですよね。この分野に関してはこの人に聞けばいいみたいなことが結構あって、で、結構その、しゃべるのは難しいんですけど、事業的な、事業的なというか、親会社。
これはオープンになった情報だから言っていいって話なんですけど、もともとうちの会社ってジョイントベンチャーって、2社が資本を出し合って作ってた会社だったんですけど、ある会社の、ある会社のところは100%子会社になりましたよみたいなところで、親会社との関係性っていうのが変わっていく中で、自分が技術預かってる人間ですよっていう顔を、帽子をかぶってやるべきことっていうのが、
結構その、その事業を、金握ってる人とかそういった人との間で、きちんとその理解していただく。自分たちが何をやっているのかどういうふうに進んでいきたいのかっていうのを理解していただいて、金を出し続けていただくとか、そういったところにきちんと、そこに僕は課題を、課題というか、そこを自分がやるべきだなって思ったから、そこにちょっとこう、自分を張るみたいなことを、
1年くらい前からかな、に結構やろうとしてて、で結構、その時に思ったのが、これって本当にエンジニアリングの仕事からだいぶ離れたところにいるよねっていう気持ちも同時にあったんですね。もちろんさっきも言ったとおり、その、事業に、あるいは事業とか経営とかにエンジニアリングの視点を入れるっていうのは、エンジニアのバックグラウンドがないとできないんで、全くエンジニアリングと関係ないからそんなことないんですけど、
結構、その、事業寄りのことっていうところに、自分をこう別途しに行くみたいなことを、やるのか、やらんのかみたいなことを結構悩んだ時期があって、その時に初めて、この、今自分がやるべきだと思うことをやっていったら、その、自分のキャリアとして、こう、なんだろう、ある可能性を思いっきり捨てて、
キャリア選択をしなければいけない時期が来たのか、ついにって思ってたんですよね。で、これって、その、あるキャリアを捨ててこっちを選択するみたいな話、キャリアプランを立てるっていうことだなって思って、なんかこう、その、悩んだ時期があったんですよねっていう話なんですけど、
結果、その後、いろいろやってみたんですけど、結局、自分がやりたいって思って、本当に心からやりたいって思ってないことって、やっぱり成果なかなか出せないし、その、なんだろうな、そうやってキャリアプランに捨てて悩んだんですけど、で、一回そっちに別途したんですけど、今、自分何やってるかっていうと、結構社内のプロダクト作りの方に自分をまた、その、寄り戻し的に、今、そっちの仕事をしてたりしてて、
結局、あの時、キャリアプランについて悩んだのって、何だったんだろうっていうのが現状なんですよね。結局、キャリアプランに並んだんだけど、やってみて、なんかこう、やっぱり自分そっちで、すごく本気になれたかっていうと、難しいところもやっぱりあったりとかして、なんか、結果、あの時悩んだけど、結果、なるようにしかなってないし、
そうやって、自分がやりたいことと、その、今やるべきこと、の積集後を本気で見つけようと思えば、結局、それをやることになるんだなあ、あんまり考えても、僕の場合は意味がなかったなあ、っていう結論になったっていう話ですね、これは。
変化へのアプローチ
おだしょー なるほどね。まあ、確かに、その、ほんと、やりたいことだけっていうか、まあ、やりたいことで一番成果出せるっていうのは、やっぱすごいそうだなって僕は思っているし、いかにやっぱそういうふうに前向きになれるように自分を持っていくかみたいなのが、こう、大事だよなっていうのは思うところではあるよね。
おだしょー まあ、でもその、やっぱり最近はね、その計画的偶発性理論っていう便利な言葉があるから、なんか、そう、ずっと前、僕としんぺいさんと総代さんでね、3人で、デブサミでそのパネルトークで、その話を出したけど、もうなんか、そう、去年のね、デベロッパーズキャリアブーストっていう同じ招営者さんのイベントでは、もう、なんか、どのセッションでもみんな計画的偶発性理論の話をしてて、なんかもう、最近みんな、
この言葉を便利に使うようになったなっていうのをこう思ってはいますね。
おだしょー 確かに。
おだしょー まあ、でも、なんか、キャリアプランっていうか、その、こう、結局、なんか、自分がこっちに進みたいとか、こういうここを極めたいとか、そういうのがあれば、その、突き進んでもいいと思うし、そういうのはすごいあると思うんだけど、なんか、明確な道筋がないときに、
てか、まあ、それが常々だと僕は思ってるんだけど、特に僕の場合は、なんか、こう、やっぱり迷うときって単に、その、変化を怖がって、それによる失敗を恐れてるみたいなのがすごくあるよなっていうのを思ってるんですよね。
だから、なんか、結局、こう、ずっとエンジニアとかで開発してきた人とかが、やっぱその、マネージャーとかになりたがらないみたいなのとかって、もちろんまだエンジニアとしてやり残したことがあるからみたいなのはあると思うんだけど、結構その、変化をやっぱり怖がってるだけなんじゃないのって思うことはありますね。
今のその、悩んじゃうときって結構変化を怖がってるだけなんじゃないのっていうのは、結構僕今刺さりましたね。確かにって思って。
そう、やっぱり、わからないこと知らないことやるときって、やっぱり、こう、やっぱり失敗の確率が上がっちゃうから、やっぱそれってすごい怖いことだし、人間ってやっぱすごい失敗を恐れる動物だから、
っていう、なんか、自覚がすごい大事だと僕は思っていて、まあそうだね。でも、今って、変化しても戻ってこれる4年みたいなのがあると思ってるし、やっぱそういうふうに思っておくことがかなり大事なんじゃないかなっていうのは思ってはいますね。
そうですね。そうそうそう。まさに今の、今やってみたんだけど、やっぱり、まあ正直あんまり成果出せてなかったなって思ってて、ここ1年くらいは。
で、まあ、その、より自分ができるところをやったほうがいいよねっていうのが、周りの人にも自分にもわかったっていうのだって、その失敗も1個の成果だと思うんですよね。
みたいなことを考えると、結構その失敗も1個の成果だし、さっきそうむさんがおっしゃった通り、戻ってこれるみたいなのが全然あるから、まあ気楽に失敗していいよねっていうのが、その結論そうで、気楽に失敗していいよねっていう話はあって。
で、その、そう考えると、やっぱその、あんまりこう、それこそ気真面目にキャリアプランとか、こっちに行ったら自分のキャリアどうなるのかなみたいなことを気真面目にやらなくてもいいって話は、まあありそうだなって、ちょっと今また思ってる感じですね。
あと、同僚が言ってくれた言葉がすごい僕ずっと誘ってる話があって、もし新平さんが今それをやるべきだって思って、新平さんがそれをやるって言って、みんながじゃあお願いねって新平さんに言うんだったら、
で、その時にそれを一番うまくできるのが新平さんなんだから、新平さんがやってみてダメだったっていう時に、じゃあ、でもそれがその時の最前線だったよねっていう事実は変わんないじゃんみたいなこと言ってくれた人がいて。
いい話じゃん。
目標設定と振り返りの重要性
そう、それはね、ずっと僕の行動の指針として今一個あるな。
でもそれはあるよね。うん、それいい話だな。そうそうそう。その時に思いついた最前線をやっただけのことで、まあ失敗したかもしれないけどっていうのはあるよね。
まあ、そう、やっぱりちゃんとそれ振り返るのとかも大事だけど、やっぱりそうなんだよな。あと、やっぱり人間が失敗を恐れる生き物だっていうのがすごく大事だなっていうのはすごく僕は最近思っていることで、だからこそ目標設定とかから逃げてしまうみたいなのもあるなと思っているので、
そこはもうちょっとなんか、僕自身の在り方としても見直した方がいいのかなって思うところはあるかな。別に達成できないゴールであっても、実は仮置きしておいた方が良くなることも結構あるのかもなっていうのは思ったりはしてますね。
なんかそれは定期的に見直すみたいなのは大事なんだけど、目標って立てた途端に失敗する確率がゼロから一定確率に行くから、やっぱなんかそう、失敗するっていうことが人間の生物的にリスクだと思っちゃうから、わざわざリスクを増やすことをやっぱりしたくないっていうのが、やっぱり人間の本能的な部分にあるなっていうのは最近思っていて。
まあでもそこであえて別に目標立てる方がいいこともやっぱあるよなっていうのは思うので、そこの目標を立てて、何らかのゴールとかこうなりたいみたいなのを自分なりに定義して、後から淡々と振り返るとかできればいいのかなっていうのを最近思ってることですね。
そうですね。難しいなあ。僕も結構目標設定逃げがち。逃げがちのタイプで。そうなんだよな。でも確かになって、今の話聞いてて思いましたね。振り返りはすごいするんですよ。
不死身の時に必ずしてると僕は思っていて、振り返りがないと成長はないじゃないですか。振り返りにとって、明確に失敗したか成功したかわかるようにしておくっていうことが実は結構大事っていうのは確かにあると思っていて、目標って多分そのためのツールなんですよね。どっちかっていうと。
今の話聞いてて思ったのが、なりたい姿みたいな話って、動くゴールポストじゃないですか。変な話。未知で成功失敗がわからないというか、解釈の仕方次第で、いくらでも実は失敗だったもの成功だったって思い込むことができてしまうみたいな。
あるから、それをそういう逃げができないにしとくのは結構重要だよねっていう話として僕は今受け取ってて、それはそうかもって今ちょっと思ってるって感じですかね。
そうだね。だし、そこも含めて、目標の立て方がよくなかったよねとか、たぶん目標って計画だから計画って間違ってることもあるに決まっていて、ある目標だったり定量的な目標を達成できたとしても、じゃあそれってその目標設定って正しかったんでしたっけっていうのは、やっぱり振り返るべきだよなっていうのは思ったりはしてますね。
キャリアプランの再考
計画に従うことよりも変化への対応をですね。
そうなんですよ。計画は大事だけど、それを達成したからとか達成できなかったみたいなところに対して、じゃあそれってそもそもの最初の問いの立て方が正しかったのかどうかっていうのはやっぱり振り返った方がいいし、そうなって思いますね。
なんかそう、キャリアプランとかについて、やっぱり僕もこう思うところはあって、やっぱり自分のやりたいことをやるみたいなところを、なんかもっと振り切れないかなっていう、もっとタガを外してそういったことをできないかなっていうのを最近ちょっと思ってるところはあるなと思っているので。
なんとなくやっぱり会社に属して、ちゃんとその会社の中でいろいろやるのもすごく楽しいし、わりとスタートアップみたいな暴れ馬みたいなものを乗りこなすみたいなのもすごくスリリングで楽しいんだけど、
なんか、本当にそれが自分がやりたいことなんだっけみたいなことが思うことも結構増えてきたみたいなのとか、あとやっぱり僕はすごくわがままな部分があるから、なんかその、なんか自分にしかできないことっていうか、がなくなっちゃうと飽きちゃうみたいなのがあって、
なんかもうこれ、僕がやったくてもいいなみたいなのとか、なんかプロダクトとかでも別にこれ僕がいなくても、たぶんちゃんとうまくいくなみたいになったら、もういいかなってなっちゃうみたいなのがあるなっていうのを思ったんですよ。
そう、めちゃめちゃわかるんだよな、それ。
うん、そう。なので、結構僕は最近、まあ、思ってることとしては、なんかその長年キャリアをなんか歩んできた中で、文章を書くみたいなのが結構僕は好きだし、評価してもらえることも多いから、
まあもうちょっと、やっぱ文章を書くみたいなところとかとエンジニアリングみたいなのを掛け合わせて、何かやるみたいなのをもう少し考えたいなっていうのを最近考えてることがありますね。
めちゃめちゃいいですね。それもそう、なりたい姿として。
そう。まあ、なので、そう、あの、なのでちょっと最近独立したみたいなのがあったりはしますね。
はいはいはい、なるほどですね。そういう背景があったんですね。
あとまあやっぱり、子供とかそういったところもあって、なんか、その、やっぱ子供とか家族みたいなものも、やっぱ自分がやりたいことっていうか、みたいなところはすごくあるから、そこにどう向き合うかみたいなのもあるかなっていうふうに思っていて、
まあ僕の子供とかも、なんか、やっぱり面白いし変な子なので、変な部分もある子供なので、やっぱ僕の子供だけあって、なんかその、まあそういう子供をうまく育てて、なんていうか幸せに生きるようにとか、まあ社会に何か価値を提供できるような人になってもらうみたいなふうになってもらうのも、なんか僕が、
僕にしかできないわけじゃないけど、まあ僕がうまくできることだなっていうふうに思うので、そこにもうちょっと投資したいなって思ってるみたいなのもある、ありますね。
人生と家族の価値
なるほど。そうだ、やっぱり子供と家族って変数は、でかい変数ですよね。
でかい変数ですね。なんか、まあ家事とか家族とかもそうだけど、なんかそれって人生そのものだから、なんかそのアウトソースしないほうがいいと思うんですよね。アウトソースしすぎないとか、あんまりその効率で考えすぎないほうがいいみたいなのはあると思ってるから、あんまりそのそういったもの、コスパとかそういったもので考えないほうがいいよなってのは思ったりはしてますね。
なんかその、ちゃんと料理とか食べるの好きだったら、まあ僕が食べるの好きだったらそうだけど、その栄養のことばっか考えるんじゃなくて、やっぱ美味しいものをなんかこう、食べたいみたいなのがあるから、そういったところに近いものがあるかなって思ったりはしてます。
なるほど。
はい。こんなとこかな。まあ、普通に、なんていうか、人生を楽しく謳歌していければいいかなっていうふうには思ってはいるってとこかな。
それは本当にそうですね。最大の目的ですからね、人生を楽しく謳歌すのは。
いやいや、ほんと、ほんとそうですよ。幸せであるかどうかみたいなのが大事だなって思いますし。
それは本当にそう。
なんか、その、AIとかもやっぱそれを使って、なんかこう、なんか自分たちが幸せかどうかとか楽しいかどうかみたいなのがすごくこう大事だと思うんですよね。なんかこう、その、まあだからそう、そういったところをやっぱ見失わないようにするっていうのが大事だなって余計思いますね、AIとかが出てきてると。
確かに。
なんかそれこそ最近だと、そのマインスイーパーとかはもう機械が解けちゃうから、最後にこう、なんていうか、機械で解けないところを人間が決断するだけになるみたいな、そういう、なんかこと言ってる人いるじゃないですか。
はいはいはいはい。
なんかその、マインスイーパーってまあある程度最初は解けるけど、
最後運ゲーのところだけが残ってみたいなね。
そうそうそう、運ゲーのところだけが残ってみたいな。そう。
じゃあなんかその赤い線と青い線どっちを切りますかみたいなところしか残んなくなるみたいな。いやでもそれってそうじゃないよなって思うんですよね。それ楽しいんかってなるわけじゃん。
なんかむしろそういうさ、その前のところをさ、楽しみたいわけじゃん。
なんかそれを、そういう楽しいところを、なんかこう、なんかすべてそういうAIとかになんかやらせない方がいいっていうか、なんかむしろ楽しいことは自分たちがこうやるべきで、なんかむしろなんか最後のね、なんかこうむしろランダムでどっちでもいい、どうなるかわかんないんだったら、むしろそこAIにやらせて、やらせりゃいいじゃんみたいなのもあるから、
なんかそう、そういう自分が楽しいかどうかみたいなのをやっぱ大事にした方がいいよなっていうの思いますね。
趣味でやってる音楽、僕音楽結構趣味で結構真面目にやってるんですけど、最近ね、生成技術、音楽もかなりすごくて、っていう話があるんですけど、これ話し始めると5時間かかるから、ここで切りましょう。
まあそうだね、そうしよっか。まああと、ロールモデルとかの話もあるけど、まあちょっとだいぶ話したかな。ちょっとだけ話す?この話。
いや、いいかな。結構これね、むしろなんか、なんつうんすかね。まあいいっす、いいっす、大丈夫っす、大丈夫っす、これは。いいですか。
いいっす。
まあ、そう。まあでも、なんかその、たぶんロールモデルっていうか憧れのロックスターエンジニアみたいなのが、結構昔はいたけど今はどうなってるんだろうなっていう話。
そうですね。
を、まあ持ってきてくれたっていう感じなんだけど、まあ結局やっぱ登壇とかそういったのが増えてくると、そういうやっぱりこの人みたいになりたいとか、この人発表いいなみたいなのは出てくると思うから、そういうやっぱなんか、そういうのって大事だと思うんですよね。
憧れね。
憧れとか。やっぱそういうなんか、なんかテックリードになってシニアになってプリンシパルになってみたいなのはあるかもしれないけど、なんかそういう抽象的な話よりも、この人がテックリードなんですよとか、この人がなんかプリンシパルなんですよみたいな方が、
あ、てかまあ、そういう具体があった方がやっぱり、なんかこう、あ、この人の、なんかこの人だったらちょっと目指してみようとか真似してみようってなるから、そういうのすごく大事だし、なんかそういう個が見えてこないと、その、なんかそうなんです、なんかそれこそプロセスとかそういうハウみたいなものに、なんかこう、なんていうか。
目が行きがちになっちゃう。
目が行きがちになっちゃって、そう、なんか、こう、この、そうなんだよね。なんかなんかこの人、なんかこういう人になりたいみたいなのとか、こういう人になれないかもしれないけど、この人いいなって思うみたいなのは、まあ大事だなって思うし、そういう人がやっぱり結構定期的に、こう、排出される業界であってほしいなっていうふうに思ってはいますね。
いやそれは本当にそうですね。
なんか、ごめんなさい、僕が話してしまった。やっぱしんべいさんちょっと。
そういう話がしたかったって話だったんです。
ちょっと話してよ。
そうですね、そうなんだ、ロールモデルと憧れのロックスターって僕別のものだと思ってて、なんかロールモデルっていうと、その人はどうやって、それほどキャリアプランに近い話で、どうやってその役割を果たしていくようになったんだろう。
役割のモデルなわけじゃないですか、ロールモデルって。
なんだけど、憧れのロックスターって役割の話じゃないんですよね。
やっぱこの人のプロダクトギラギラに輝いてるとか、役割をやるための話じゃなくて、こうありたい、魂のあり方みたいな話があると思ってて。
結構ね、エンジニアの世界って結構魂のあり方みたいなやつとか、誰々上や、みたいなものが結構その、全然輝けるのがエンジニアリングの良さの一つとしてやっぱあるよねって僕は結構思ってて、そういうのが連綿と続いていくといいなとは思ってるって感じですかね。
それはありますね。
ちょっと話し足りない感じはあるが、っていうか、たぶんずっと話せちゃうんで、一旦その辺で終わるとして、またちょっと飲みにでも行きましょうよって感じですかね。
はい、じゃあ終わろう。終わりにしましょう。
はい、お疲れ様でした。
