1. Yokohama North AM
  2. ep 76 @for__3 @okashoiと自社..

池添さん、おかしょいさんをお招きして、自社サービスを作って運営していく上で、ポイントポイントで何を考えていけば、エンジニア組織が幸せになっていけるのか?エンジニアの教育論、成長論などについて話しました。

00:01
こんばんは、横浜North AM第76回です。
横浜North AMは、ウェブ系エンジニアがテック系のキーワードをネタにして雑談をするポッドキャストです。
ホスト役は、自称PHPRのハンハイ1978です。
本日の相手は、池添さんと岡添さんです。よろしくお願いします。
よろしくお願いします。
お二人ともですね、カンファレンス知り合いですかね。直接お仕事したりとかないんですが、
主にPHPR会議ですかね。
多分、PHPカンファレンスでも、もしかしたらお会いしたことがあるかもしれない。
まあ、どっかしらですれ違っていた。
どっかしらですれ違っている、PHP界隈仲間という感じですね。
今回はですね、なんと池添さんも岡添さんも、会社名言って大丈夫でしたっけ。
大丈夫です。
株式会社はウィルゲートさんで、池添さんはバックエンド兼インフラみたいなSREみたいなお仕事をされていて、
岡添さんは主にミロとスプレッドシートを操るバックエンドエンジニアに回っているという噂を先ほど出てきました。
とても便利ですよね。
今日はですね、シニアエンジニアの皆さんをお招きしてですね、
3人とも自社サービスに今携わっているので、
サービスを作っていく上で、さまざまな立場の上で、
ポイントポイントでね、何を考えていくとエンジニアも組織もサービスも幸せになっていけるのかみたいなところをね、
考えられたらいいなと思い、おじさんを3人で雑談しようということになりましたと。
幸せなのがいいですからね。
そうなんですよね。幸せになりたいですね。
幸せに開発したい。
そうですね。
ちょっと聞きたいんですけど、いわゆるクリーンアーキテクチャの本とかって、
ボブが幸せになりましたみたいな話を書いてあるわけじゃないですか。
最高にクールなソフトウェアになって、変更は用意だぜみたいな。
依存はいくらでもいじれるぜみたいな感じになってる。
なんで笑うんですか。
いや、笑うっていうよりかは、自分が携わってるサービスでそこまで行けたことってありますか。
そうですね。
みんな笑ってるぞ。
そこがやっぱり事情面でうまくやりながらやっていく難しさというか、面白さというか、そうですよね。
03:02
なんていうか、2つ観点があって、
1つ目は、今まで自分がこれがクリーンアーキテクチャだって言ってやってきた頃って、
私自身の理解が足りてなくて、実はなんちゃってだったりしていて、
結果なんか不細となって残ってしまったみたいな観点が1つと、
2つ目が、結局初期の頃に何かを考えて作ったとしても、
その意図とか設計の思想みたいなものをちゃんと伝えていけないと、
てかまあ多分これ本当に伝えられるのかっていうあれはあるんですけど、
じゃないと形骸化していったりとか、逆に変な後続への足枷になっていってしまってるな、
みたいなことはやっぱり私の目から見ると感じているなと思います。
いやー、ですよね。
いやもう、心に染み入るような話ですよね。
大丈夫ですか?またこの回重くなったりしないですか?
いやもう全然重くないです。
みんなこの苦しみを味わえばいいんだと。
もう重いじゃないか。
大丈夫ですか?幸せになれますか?この話。
いや、この話は結局、
なんていうか、みんなどうしてもやっぱ連動が低い状態からスタートするわけじゃないですか。
何事も。
そうそう、何事も何事も。
僕とかキャリアのスタートがSIだったりするんで、
人様のシステムをいじってるみたいなところから自社サービスみたいになって、
ようやく自分のサービスとしてまともに責任をかもって見れるようになって、
これじゃいかんっていっていろいろ試して、
大体さっき岡添さんが言ったみたいに失敗して、
その経験を経てからじゃないとできないことはあるような気がするんで、
それも含めて、
それも含めてかなーみたいなところはあります。
失敗を経ないとわからないことはあるなーっていうのと、
とはいえ、じゃあ授業、仕事でどれだけ失敗を許容できるんだっていう話と、
そこって常にジレンマというか、
常にバランスっていうとちょっと変ですけど、
どれぐらい失敗が許されるんだみたいなのを常に思っていたりしますね。
06:02
どうしてもやっぱり事業をやってるんで、
許される失敗と許されない失敗とタイミングとかもやっぱりあったりするんで、
そこらへんはやっぱり何でも失敗していいわけじゃないところがあったりするんで、
難しさですよね。
いやー、そうなんですよね。
失敗もちょっとセンスみたいのもあるじゃないですか。
あ、この子はこう、いいこけ方するなーみたいなことを、
あ、お前またそのこけ方をしたのかみたいな。
分かる、分かりますよね。
我々は多分いい転び方を更新には伝えていかなければならないと、みたいなところですね。
こける余地みたいな事業をやりながら与えられるのかみたいなところも、
ちょっとテーマになりますよね。
そうですね。
うまくマップレスを敷いてあげたりだとか、
危なそうなこけ方をする前に手を引いてあげるとか。
そうですよね。
いかようにデータベースが破壊されても、
ちゃんとバックアップが取られてるから大丈夫みたいな、
フェールセーフな仕組みとかを入れておくとかですよね。
分かるな。
じゃあさて、我々は失敗もしてきました。
経験もしてきました。
我々はボブと同じ体験をこれから得ることができるのかどうなのか。
いやー。
技術動向もビジネスの動向も常に変わってってるじゃないですか。
だから幸せも常に変わってってるんだろうなと思っていて、
そこに追いつくって言ったらちょっと言い方あれですけど、
言い続けるのってかなり難しいというか、
だからこそ頑張りたいと思うんですけど。
そこに対して技術動向だったりとかビジネス動向だったりとか、
そういうのを勉強し続けるみたいなのが、
我々の職責でもありやりがいでもあるのかなっていうふうに思っていて。
なのでまだたどり着くのはかなり遠いなって。
まとめると。
ボブにはなれないと。
ボブね。
ボブの新刊が今年出てて、クリーンシリーズですね。
クリーンクラフトマンシップってやつ。
来月かな、和訳が出るんですよね。
09:00
和訳が出るんで焦って、今インドからやってるんですけど、
英語のほうが出る前に読もうって言うんですけど、
中に入ってるのはやっぱりこんがらがらせちゃダメだよと。
それをシンプルにしていくっていうことが一番大切で。
それはもう僕も今ずっと会社でリアーキテクチャリングとか認知負荷下げようってことをずっとやっていて、
もうめちゃくちゃわかるなって。
依存性逆転のところに出てくる図とかで依存の方向を一個に揃えようみたいな話あるじゃないですか。
あれを割と愚直にやると実にすっきりわかるんですよね。
それと今さっき池澤さんが言ってたみたいに、勉強しろってことが書いてありました。
常に勉強し続けるみたいな。そうですよねーって。
分かります。勉強し続ける。
いろんな設計の手法であったりとか、あるいは開発手法、開発プロセスみたいなのっていろいろ言われてるじゃないですか。
それこそTDDがなんだとか、アジャイルがどうかとか。
なんていうか、ああいうのに対して一定アレルギー反応を示す人も割といるわけじゃないですか。
手法ばっかりが先行していて、本当にそれをやる時間があるのかとか、それをやっているぐらいだったら、
他の普通に開発した方が早いじゃんみたいなとか、いろいろあると思うんですけど。
最近思うのは、さっきの勉強し続けろって話と関連付けて思うのが、
大事なのって例えばテストコードを書くの大事だよねっていう話をする以上に、
テストコードを書くという行為を例えばほぼノーコストで書けるぐらいに、
習得する、あるいは習得できる環境を作るみたいな、そっちの話をまずしていかないと、
いかにテストを書けとは言わないですけど、書いた方が早くなるんだよとか、
テストを書くことのメリットをいくら歌ったとしても、
いやでも結局時間がかかるでしょみたいなのになっちゃうと書かれないので、
そこをいかにノーコストにできるか。
ノーコストは言い過ぎですけど、そこのコストをいかに下げるかみたいな部分が多分鍵なんだろうな。
それは自ら学ぶであったり、教育なのかな、そのやり方を伝播していくとか、
12:00
そっちの方向性に進めていくことが大事なのかな。
あれだな、これ。なんか組織論に行きそうな気がする。
いや、組織論にはいかないですよ。大丈夫です。
まだまだまだ自分が勉強してる。
まだまだもう全然。
ただこの勉強って言うけど、僕も含めて、やりたいときにやりたいことしかやんなくて。
最近はもうだから思うのは、若手の子も例えばいろんな家庭事情とか、体調だったりとか、個人の事情っていうものがあって、
そのタイミングでやる気が出たときに、いかに利用できるリソースが周りにあって伸びやすいかみたいな土壌をいかに用意できるかみたいなところだと。
あとは、僕はそんなにアジャイルアジャイルいう人間ではないけど、やっぱり事業活動を支えるエンジニアだから、
やっぱり顧客にきちんと価値を提供するっていうところを北極性にして、その方向に俺たちは技術を研鑽してやれることとかを増やしていくみたいな。
そんな方向で面白い感じでやっていけたらなと。
そのバランスとかがまたね、難しいところではあるんですが。
やっぱりシニアというか、教える機会が増えてくるんで、教えることもいろんなジャンルというか立ちに渡るんで、
その人が興味持ったやつを、じゃあこれが興味あるんだったら、これを読んでみるといいよとか、そういう引き出しを広げるとかっていうのがすごい大事ですよね。
そこで学んでいくと、また違うところに興味持ってくれたりするんで、そしたらじゃあまた今度こっちでと言って、どんどん一回一回のファイラルが咲いてあるなと。
誰かが必要になったタイミングで、必要なパスを出してあげられるっていうのがものすごく大手数ですよね。
大事ですね。
そう、それって結構あれなんですね。こういうカリキュラも用意しましたってそうなるんじゃなくて、なんかこうジャズというか。
ありますよね。
あります。評価精度と作るとか、育成の型を作るみたいになった時にも、もちろんすごい基礎の部分を固めてあげるのに、
こういう体系だった知識はいるねみたいなところまでは整えられるんですけど、割と早い段階でその枠組みが全然収集つかなくなるというか、
15:12
整えようとすると。そこから先って要はスペシャリティなんで、その人の興味に尖っていった方がいい。
尖っていくというと語弊があるかもしれないですね。その人の興味を赴くままにやっていかないと、いつまで経ってもそのカリキュラムを用意した人の介護官でしかあり続けられないので、
その人の自分自身の動機で進んで深掘っていかないと、いつまで経ってもある程度のスペシャリストというか、職業プロにはなっていかないなっていうのは思う。
そうなると適切なパスを出すっていう話は大事だなと思います。
そう言いつつ、職業人のエンジニアとして求められるスタンダードみたいなものは割とあって、そのバランスが難しいんだよなと。
とはいえお前セキュリティはこれぐらいは分かってないとちょっと世には出せんぞっていうのがあるとか。
その割とセキュリティのスタンダードが結構ムービングターゲットというか年々変わっていく。
しかも積み上げ方式じゃないですか、我々の世界は最悪のことに。
最悪のことに。
前提となっているもうちょっと簡単なやり方とか知識っていうものがあって、それにさらに積み上げ積み上げでちょっと難しい知識が必要になってくる。
難しい攻撃手法が入ってくるみたいな。
いやーっていう感じ。
なんか便利なものとかもすごい増えていく一方で、それも使い方覚えないといけなかったりして意外と覚えること多いんですよね。
改めてこうやると。
そうですよね。
我々はすごく複雑なシステム、ウェブシステムでも作れるようになってきて、その過程でフロントエンダーもっと便利に分離独立して発展していって。
デザインツールもつって、ほら最近はMirodaがMiroda Figmaがつって大変扱いやすいツールが出てきて。
我々がやれることは増えているはずなんだが、全体的には砂漠に水を撒いている感が出てくるようになっちゃった。
手段が豊かになるとやれる可能性はさらに数倍で広がっていくので。
そうなんですよね。
立ち合わせだから。
18:00
いやほんとそうで、僕あのファイナルファンタジー6とかやった時に、もうこんなに綺麗な画像あり得ないと。
なんかこれ夢みたいだと思ってたんですけど。
最近のなんかゲームやるともう、あれ?みたいな。現実なのか?こんなこれみたいな。
新しいハードが出るたびに実写じゃんって言い続ける。
そうそうそうそう。
もう実写超えてるんじゃないかなって。
そうですよね。昔見たポリゴンとか今見るとヤバみたいな。
あれがリアルに見える。
そうなんです。スタンダードどんどん上がっていくんですねやっぱりね。
そうですね。
リアクトタイプスクリプトで作られたSPAのアプリってやっぱ気が利いてますよね。
ですね。
ジェイクエリーではないっていう感じはやっぱり必至。
まあまあ。
スタンダードのレベルが上がってきているので、
本当に一番最初のものを作るみたいなもののハードルもどんどん上がってきていて、
なおかつ失敗の寛容さもどんどん下がってきてるので、
新しい人ほど辛そうだな、辛いように見える場面は多い気がする。
そうだよね。
今だと多分昔とかは多少セキュリティ的に甘い部分があっても、
なんとかなってた。なんとかなってたはちょっと語弊があるな。
結構こう、今の世の中はちょっとでも脆弱性のあるものがあれば、
攻撃されたりはたまたさらし上げられたりみたいな、
出すからには完璧にしないといけないみたいなものがかなりはみこっているような気がしていて、
それもさっきの失敗をする経験みたいなのが積みにくくなってるなとは感じますね。
まあそうですね。ちょっと今日の放送始まる前に、
フレームワーク使わないでスリム使ってみたいなコンポーネント1個1個自分でみたいな話をしてたじゃないですか。
でもそれよりはたぶんララベル使ってみたいなのをして開発した方が、
たぶんセキュアにできるんですよねきっと。
そうですね。
みたいな世界線もあって、巨人の肩に乗るじゃないですけど、
ララベル使っとけばとりあえず守られてるっていうところがありますよみたいな。
のもあるから、そこらへんのバランス感覚ってとても難しいなとは思いますね。
21:01
まさにバランス感覚で。
じゃあララベルみたいなフルスタックなものを使っていれば失敗しないかというと、
ララベルとかを使うことによって見えなくなっている部分がまた存在していて、
するとじゃあそこの知識がなかったが故に、
元々なんというかそういうフレームワークを経由せずにというか、
そうじゃない部分を知っている人だとちゃんと自分で気づいて、
ここをこうすると転ぶからこうしないとなみたいな部分を知らずに、
暗くというか隠されていた部分に思わぬつまづき意志があって転ぶみたいなこともあったりしていて、
そうなるとどっちで転ぶのがいいのかなとは、
それもある程度バランスの話だとは思うんですけど。
転けられるっていうのは割とすごく贅沢な話で、
世の中に出てきたサービスはほとんどは転ける間もなく、
値段が。
無くなっていくというものになりまして。
レガシーシステムとはレガシーになれたのであって、
そうレガシーになる。
世の中にはレガシーになる前に消え去っていったものがたくさんあるんだという。
そんなにモダンでめっちゃクリーンなサービスでもお金が生まれなければ死んでいくっていう。
そうですよね。
僕やっぱり綺麗で儲かっているサービスは見たことなくて、儲かっているのは汚いんですよね。
たぶんビジネスのスピードに合わせていびつな成長をしていたがゆえにビジネスチャンスをつかめていて、
それがゆえにレガシーになっているみたいな。
そこを儲けられるスキームはキープしたままにやれるだけの改造をしていくみたいな感じになるんですね。
必ずしもそこが綺麗さかどうかみたいなのがある。
トレードオフになるのが綺麗さかどうか。
綺麗がまずとても抽象的な言葉なので、下手に使うと危ないんですけど。
危ないですね。これは非常に危ないと思います。
さっきもちょっと私が言及した通り、
じゃあちょっとあえて綺麗という言葉を使いますけど、
時間をかけて綺麗にするか汚く早くやるかみたいなトレードオフではないのかなと思っていて、
結局は綺麗に描く、描くというか作る方法をいかにノーコストでできるように自分を計算していきますかっていう話だと思っています。
汚く早くというよりも、あえて汚く描くとか作るとかって多分できなくて。
この界隈にいると散々見ることになるスライドの話ですけど。
24:05
うなぎのタレのようにどんどん愛の参照が追加されていっている質とスピードですね。
たぶん犠牲にしている部分はその綺麗さみたいな品質というよりかは、
ちゃんと正しくドメインを捉えているかどうかみたいなところかなとは思っていて。
ドメインへの理解が足りないとか、あとは実際に世に出してみたら形が変わっていく。
そうすると作っていく中で考えていた、あるいはそう認識していたドメインの、
ドメインモデルって言うとちょっと安直な気がしますけど。
ビジネスの領域であったり概念というものが、
ビジネス事業活動を続けていく中で変わっていくとか、
実はこの解釈って間違っていたねみたいなものが多分積み重なっていくんだと思うんですね。
そこに対して最初の話に戻ると、
リファクタリング、リアーキテクチャリングみたいなことが果たしてできるのかいっていう話なのかなという。
ちょっとまあ何かありきたりというか教科書に書いてあるようなことなので。
まあまあ聞いてるとまたこの話かみたいな。
ちょっと今すごい思いついたんですけど、
今岡社さんから話してるのって、今まで僕らが話したってソフトウェアの話じゃないですか。
今池戸さんSREとかインフラやってるって話だったんで、
僕実はソフトウェアは割となんとかなると思ってるんですよ。
なんとかなるって。
ならないところもあるって。
そうならないところもあるけど、ソフトウェアはまあなんとかできると。
で、インフラは初手間違うと、
莫大な作用を追うと僕は思っていて。
この初手の間違い方が、
アプリケーションの日ではないつらみを生むなとは思っていて。
そこら辺って今気をつけたりとかってしていますか。
そうですね。新規とかの場合、
どうサービスがスケールするかわからなかったりするんで、
できるだけ小さくというかミニマムというか、
変更しやすい単位で作るとかってのは考えてたりはしますよね。
コンテナとかもそうですけれど。
27:00
今だとそれこそソフトとハードの話で出てきましたけど、
クラウドとかは使えるようになったおかげで、
おかげではないか、IACとかっていう技術とかも出てきたので、
ある程度ソフト的に扱えるような部分とかってのも増えてきてるので、
そういうのをできるだけ使うとかってのはやっぱりやってるところですよね。
最初の選択が間違うことは絶対あるので、
全部正しく選択するなんて無理なので。
その意味では定期的に今状況を確認して間違ってないんだっけみたいなのをチェックしつつ、
ちょっと間違ってそうだなみたいなのを見つけたら、
早期にソフトウェアとちょっと違うな、
そこが前によってはメンテナンスというか、そういうのを取った上で、
エリアアーキテクチャというか構成変更するみたいな選択をして、
ちょっとずつ正解に近づけていくみたいなのはやっぱり意識してますかね。
僕は割とインフラも面倒見ることが多かったんで、
とにかく念仏のように唱えるのは12ファクターAPPをやろうみたいなところはずっと言って、
そうするとだいたいインフラとソフトウェアにある程度の腐敗防止みたいな分割ができるんで、
そうすると何とかインフラも差し替えれるし、
何とかソフトウェアもインフラに引っ張られずに何とかなるみたいな状態は作れると。
そこら辺が割と実によくできた落としどころかなとは思っていて。
ソフトウェアと腐敗防止との作り方はちょっと違かったりするんですよね。
そうですよね。
依存するものをうまく差し替えるというか、どうするかではあるんですけど、
それのやり方のというか考え方がちょっと違う部分はあるかもしれない。
PHPとかだとデフォルトだとファイルセッションとかを使っていて、
そのまんまのものでEC2とかで作られてしまったものだと、
とりあえずスケールさせたときに困っちゃうなみたいな。
最初の難関ですね。
そうそうそうそう。最初の難関が出てしまう。
そうするとやっぱり気の利いた開発者だとそこをとりあえずデータベースセッションにしてしまったりとか、
エラスティキャッシュ、ちょっと初手から若干お高いですが使いましょうみたいな話になってたりして、
そうすると遠慮なくスケールできますみたいな。
それってやぐにではなく転ばう先の杖みたいな。
そうなんですよね。
30:01
そうそうそうそう。
そういったところをうまく伝えていきたいなって。
若者に会うために俺はこうやって、
12ファクター、12ファクターだよって。
開発環境をコンテナにして12ファクターにすれば多分大丈夫だから。
一通り入ってますね。
そうそう、一通り入ってますね。
その辺の知見、表面的には12ファクターでよくて、
じゃあなぜ12ファクターかみたいなのは追って学んでくださいみたいな。
あるとき、あるときああってなるから。
これか、これが辛いからこうなってたんだみたいな。
確かにその知識と。
教科書的な知識と、じゃあそれがなぜ必要なのかみたいな話も、
経験というか、話としてこういう時困るでしょみたいな話はいくらでもできるものの、
結局それは自分のものにするかどうかは、
もちろんその話を聞いてある程度ピンとくる人ももしかしたらいるかもしれないけど、
やっぱり自分の痛い目に見ないと。
その人の頭の中で、その人の文脈で、
その人から発せられる形としてそれが説明できるようになったタイミングで、
それがものになってるんですよね。
その状態まで持っていくっていう風に考えなきゃいけない。
やっぱり失敗させないといけないんですよね。
無理くり失敗する必要ないと思うけど、
失敗までも一番心に残りますよね。
失敗の成見というか体験をうまく作ってあげるというか、チャンスというか。
僕もだってデリート文をとあるテーブルに流した時の、
エンターキーを押した時の記憶も含めて全部覚えてます。
その瞬間にアドレナリンがたぶんいっぱい出たんだと思う。
強烈な記憶として残りますね。
あっ!っていう時のこのスローモーション全部覚えてます。
その時の現場の匂いまで戻ってくるようになって。
ここら辺はサービスを開発していく上の話で、
33:02
ちょっと面白いなと思ったのが、今岡淳さんがやってるのは、
そもそもサービス必要ですかみたいなところを新規開発の時にやっているという話があって、
そこら辺の話も伺いたいなと思って。
とりあえずやってみようよみたいな話ってあるじゃないですか。
なんというかこういうのができると嬉しいんだよねみたいな話がポッと出てきたりするわけじゃないですか。
それはやっぱり未来のことをめちゃくちゃ考えてる目線とかから、
事業を考えてる人とかからこういうのができると嬉しいですよねっていう話は上がってくるとして、
もちろんそれはできると嬉しいのは前提として、
じゃあでもそれっていきなり結構手段がガチガチに固まってるような状態で出てきたりすることもあって、
こういうのを入力したらこういうのが出てくるのができると、
これができるからめっちゃいいよねみたいな話とかが出てきたとして、
エンジニアの観点として、ちょっとこれ私の考えとしていかに作らないかを考えるのが、
エンジニアの出せる価値の一つだと思っていて、
それはなぜなら作った後の苦しみというか、
定量的にコストであったりとかね、運用コストとかサーバーのコストとか、
あるいは作ったことによってその不具合が発生するリスクとか、
そういったものが身をもってわかっている立場なので、
ただそれってこういうコストがかかりますよとか、
それであれば大体手段としてやりたいことを噛み砕いて、
これってこういうことがやりたいわけだから、
そういうシステムじゃなくても、例えばこういったサービスを使えばできますよねとか、
こういったツールあるんで、これをちょっと使ってみて手で回しになると、
でもDUBをやっていてどの方法でも彼らさんだと気持ち違わないから、
サービスを残してもどっちにしようか、
それまでやってきた事がふたつの業障でもあるように、
あとワタリアンさんがやらなかったり、
正当がなけたとか、
誰かが種子を削らせ果たしてそれはいわく汚い人だなと、
エンジニアとして思ったりはしてます
いや そうですね だってインフラ はね 大変ですもんね 池添さん
ね 新規サービス作るって言われて 用意しろって言われてね
急に依頼された気がしたらね
そうですね ウィリゲットももう 立派な会社だから 開発環境 じゃあ
ステージ環境 本番環境で AWSだったら じゃあVPCをこんな感じでって
ここから繋ぐように考えて セキュリティ を考えるとみたいな それが多分
36:01
一気に脳内にブワってきて そうすると検証も含めてこれぐらい
の日数は欲しいなみたいな そうですね 多分岡社さんが言ってる
作るっていう決断には そういう 新しいドババババっていうコスト
も済んでるみたいな
プログラムとして実装するものは 全然いいですよ 1日ぐらいでやります
けど じゃあそれを運用に組み込める ように しっかりものとしてシステム
として作るのはまた全然話が違う もちろん作るコストもそうです
し 後々の運用していくコスト あるいはリファクタリング リアクテクチャ
リングみたいな話とかも出てくる と定期的にそういうものも必要
になってくるとなると 究極作らず に済むのが一番合理的な判断ではある
と 一エンジニアとしてはちょっと 寂しいというかつまらない感じ
ではありますけれども でもそこの 判断ができるというのも一つの
エンジニアの腕の見せどころでは あるかなとは思ってます
いわゆるMVPみたいなミニマム な割を出すためのプロダクト
みたいなのって 割とGoogleフォーム とスプレッドシートと
めっちゃ分かりますよ
分かりますよね あとガスでいけるん じゃねみたいな
ガスも
ガスでいけるからね
ガス
ガスが一切できる
ガスなんでもできないんで
そうすると だから仮説検証は割と それでできちゃうから
それでまでやろうよみたいな話 って
めちゃくちゃ有益だと思うんだけど 実に人気がないですよね
なんでなんだろう
分かりますよ なんか特に
なんだろうな 別になんか文句がある ところじゃないですけど
若い層ほどちょっとこう
ちょっとかなんか嫌そうな顔したな みたいなのだったりは
ガスか うんみたいな
ガスか そうそうそう
イケてないぜみたいなね こう
まあまあまあみたいなのは内心あるん じゃないかなみたいなの
邪推かもしれないですけど 感じ取ることはありますね
でもそれってすごく大切なことで 価値提供にフォーカスしてないから
手段にこだわるんだよなとは思っちゃう
解決したい課題にフォーカスしてたら 多分手段は気にならないはずで
とは思っちゃうな
そうですね いやいい話だな そうなんですよね
いっぱい作ってきたからこそ
とりあえずガスで溜めそうよっていう 気持ちになる
39:01
なるなるすごい分かる そうなんですよね
ちゃんとしたステージング環境と ちゃんとした本番環境が生み出す
メンテナンスのめんどくささとか認知 負荷のやばさみたいなところって
ありますよね
そうだな
オブジェクトストレージいるもんね
そうですよね
仕事だからRDSのバックアップのことも 考えなきゃいけないし
みたいにね
スプレッドシートはすごいですからね
いやでもスプレッドシートはほんと 見事だと思いますね
あれを使ってできるカテステーションの量って
スプレッドシートはソフトウェアとしての 完成度が素晴らしいでいいなっていう
何でもできる
コンピューターってああいうことなんだな みたいなのをすごい思います
スプレッドシートに対しては
なんかすごい変な方向に行きましたけど
大丈夫ですよ 大丈夫です 俺はスプレッドシート好きです
だいたい解決できるんで
スプレッドシートとガスで だいたいのことできてしまうと
そうですね このポッドキャストもだいたい
だいぶスプレッドシートに依存して 作られてるんで
出林の感じとか
いやそうなんですよね スプレッドシートすごいですよね
表計算みたいなのって誰が思いついたんでしょうね
ABCDEとか123456とか
どうなんすかね
元ネタ Excelよりもさらに元となるアイデアあったんですかね
僕が一番初めて見たのが Lotus123ってやつです
表計算ソフトで初めて見て
全然その時は知らなくて
なんだろうこれみたいな
一体これ何するものなんだろうって最初は思ってて
その後SIAに入った後は
5番の目のようにめちゃめちゃ小さくした Excel
方眼紙ですね
そうそう方眼紙
こんな使い方がって言って感動したんですよ
そしてこれがそんなに辛い目に俺を合わせるのかみたいな
話がスプレッドシートにいってしまった
今日のテーマは何だったかというと
サービスを作っていく上でポイントポイントで何を考えていくと
エンジニアは幸せになれるのかと
末長くサービスを続けていって
エンジニアも成長して会社も儲かるみたいな幸せな世界です
42:04
教育ってどうしてます?
あえてやってます?
うちはすごい教育には力を入れてやってる方だと思います
エルジェットって新卒作業やってきてたので
エンジニアも新卒の割合が高くて
そこを戦力化していくのにやっぱ一定教育が必要だよねっていう感じで
ずっとやってきてる感じで
主に僕と岡添がそこは教育面は入って
若手とかにいろいろ教えたりとかっていうのはやってるって感じです
その中でさっき言ってた基礎のスキルがどうのとか
スキルどういうスキルを身につけるんだみたいな話とかは
よく話してるところですね
よく仕事でも話すし
飲み行った時とかも話してるし
やっぱりさっきの話でもチラッと出てきてましたけど
我々がお前らできるエンジニアになるために
こういうのを勉強しないとダメなんだっていくら言っても
本人がやりたいっていうタイミングというか
モチベーションが来ないとなかなかうまく伸びないんで
最近はそこをどう刺激するかとか
それをうまく思ってそうな人にうまく両手を押さえて
それを伝えるかとかそういうところは結構気にしてますよね
じゃあどうやってそれを刺激していくかみたいな話は
私とイケゾエ
普段ゾエって呼んでるんでゾエって言いますけど
私とゾエだと明確に役割がはっきりと分かれていて
ゾエなんかは結構個々一人一人にしっかり向き合って
その人の特性を把握して
ワンオンワンとかでフィードバックをしていくタイプなんですね
かなり丁寧にというかしっかり向き合っていくタイプ
私はそういう対こうじゃなくても対他というか
全体魔法みたいな形で
全体効果力みたいな
広く知らしめていくとかビジョンを示すとか
あとはアウトプットをしていくっていう中で
外の世界を見せてそこに連れていくみたいな
そっちの方向そっちに引っ張っていくとか
そういう対他とか対組織みたいな
そういう方向性で見せていって
そういう役割分担っていうのかな
45:03
お互いの得意なところ特性を補ってやってるみたいな感じはありますね
仲間がいるといいですよね社内協力ってやつはやっぱり
いや本当にそれは思います
一人でやると結構しんどい
しんどいんですよね
自分がやってることが正しいかもわからないし
幸いうちの会社たくさんいるんですよ
割と勉強会とかをやろうみたいなのとか
人に何かを教えるみたいなことが好きな人が割といらっしゃるので
今その辺は全然困っていなくて
逆に僕が今何考えてるかっていうと
僕なんかはあれですねとにかく楽しそうに
PHPの話をする
大事ですね
楽しそうにしてる姿を見せて
自分もなりたいなみたいな思わせるのも大事ですからね
大事ですよ本当それ
マネージャーとか辛いんで
辛いんでっていうとあれですけど
辛そうにしちゃいがちなんですけど
マネージャーとかそれぐらいのクラスの人間って
でもなんかそれをしちゃうと
グレードが上がっていくとああいう辛い思いをするのかみたいなのになっちゃうじゃないですか
後続の人が
初心が罰ゲームになっちゃうからね
機会が増えていくとか自分たちの手で
組織だったり別に事業でも何でもいいんですけど
作っていくっていう部分に対して面白いとか
専門性を高めていく中で
PHPは最近こういう話が面白くてなみたいなのを本当に楽しそうに語っていく
っていう姿を見せていくとああいう風になっていきたいなとか
そういう背中を見せるじゃないですけど
そういうのを見せていくのはすごい大事だなって本当に思いますね
そうですね
それを演じてやっちゃうと演じてる感が出ちゃうので
そうですね僕はとりあえずめちゃくちゃ楽しいんで
僕はもう楽しさアピール
反対力
そうですねその辺かな
今さっき壮大さんがつぶやいてて
返信してたんですけど
私たちはどう学んでいるのかっていう本が今年出てる本なんですけど
これめちゃくちゃ面白くて知識っていうのがどういう風に構築されて
48:03
上達していくかみたいな話の本なんですね
こいつがですね
すごく良くてですねこれじゃんって思って
俺は今この本を断るごとに人にオススメしている
ちょっと待って今放流します
とりあえず今こっちにロートしてます
この本に何か書いてあること
能力は虚構ですよみたいな
力っていうものがあるわけじゃなくて
知識は本を読めば得られるけど
それは情報と記憶っていうだけで
実際にそれが例えば仕事の場面とか引き落とされた場面で
自分の中からそれをきちんと使って
何かの問題を解決するとか使う
その場で何かを作り出したっていうのを本の中では心境に
って言ってたんですけどそういったことができたら
それが身についたっていうことだよみたいな
それを繰り返すことで成長とか育つみたいな行為が
行われるみたいなことが書いてあってなるほどそういうことかと思って
ってなるとやっぱりただ人に教えてもあんまり意味なくて
その人自身がどこかでそれを何ていうか
技を繰り出さないことにはどうしようもない
はいそうです
あくまでできるだけ知識を教えたりとか経験させるための
場所を作ってあげて背中を押してあげるとか
こけそうになったときの仲間にしてあげるとかそういうところなんですよね
結局自分で何かをしてそこから何か
学びを得るっていうのはやっぱり自分でやらないといけなくて
僕は結構そこを知識と経験みたいな感じで考えてるんですけど
経験をさせてあげることによってそれもいっぱい
家具こなしていかないといけなくてそれによって
意識的有能から無意識的有能になっていくと思っていて
そこのポイントをどういかに我々が
後押すかみたいなんだなってすごい思ってて
今まさに同じ話でいてちょっと嬉しかったです
いやそうなんですよねだから何のなく僕たちが
自覚してることがきちんと文章化というか言語化されてたので
もうすごい痛く感動してしまって
状況と経験と環境みたいなものの
無茶苦茶になったやつが我々の
いわゆるスキルと認識されているもの
あと結構思い込むのって大事だなって僕も思ってて
最近例えばファシリテーションとかも
51:00
最初苦手でオドオドしちゃったりとかするんですけど
そうすると余計うまくいかなくて
自分はファシリテーションのプロだと思ってやると結構うまくいったりするんですよね
そういう
あたかもできるように振る舞う
それは大事だし根拠のない自信を持つというか
できるイメージを自分に下ろすというか
そういうのも大事
これも経験がないとなかなか発揮できないところではあるけれども
なので一旦やってみるとか
大丈夫、いけるいけるって
ある程度コーニングでやらせるみたいなところもあるかな
そうなんですよね
その人がドラクエに例えるならば
メラを初めて打ったときに素晴らしいメラだねみたいな感じで
きちんと認めてあげるっていうことがめちゃめちゃ大事
ほんと褒めるの大事
過剰に持ち上げる必要はもちろんなくて
そうそうそれそれみたいな
みんなそこからだからみたいな感じできちんと認識してあげるとか
その時点でいきなり落としにいくと
もう全然悪いイメージをつけてしまって成長も阻害するし
チームとして弱くなっちゃうなっていう感じはあるんで
そこですよね
成功体験をちゃんと積ませて
ちょっとずつの成功体験をちゃんと積ませて
ちょっとずつ成長を実感させるっていうのがやっぱり大事だな
教育では思いますけど
僕スノーボードを教えるときにそれは思いました
スノーボード大好きなんだ
俺習いたかったなめちゃくちゃ下手くそだよ
僕もう2日間くらい
ほんと死ぬんじゃないかってくらい頭打ってそれでようやく滑れるようになって
もうちょっといい先生がいたらなと
めちゃくちゃすごいんですよね
体の使い方とかをきちんと言語化できるんですよ
そこがすごいなと思ってて
私とかが教えようとするとすごい感覚で
いいねいいねとか
もうちょっとこういう感じみたいになっちゃう
もうちょっとグッとみたいな感じになりがちなんですけど
そうじゃなくてちゃんと今こういう状態だから
じゃあもう少しこういう状態にするために
じゃあこういう意識をしてみようかみたいなのかなり
細分化した言語化がされていてそういうふうにフィードバックしているのが
54:00
めちゃくちゃ上手いしさっき言った教育の特性みたいなところも
そういうとこが出るんだろうなっていうのが見てて感じました
教えるときに
ダメなポイントを言うんじゃなくて
できてるポイントをちょっと強調しつつ
じゃあ次ここを意識してみようかみたいなのがすごいやると
やっぱ伸びるんですよね面白いことに
それでこれ教育技術の教育とかも一緒だなってすごい思って
活かせるなっていうふうに
スポーツって結構教えるのと
あとさっき言った意識的有能無意識的有能も全く一緒で
同時に複数のことをやるっていうのが結構スポーツ多いんで
無意識的有能になっていかないとできないんですよね
それって実はエンジニアも一緒でいちいちファイルの中身見るのに
レスを使うとかって考えてないじゃないですか
タイピングだってそうですよねってのと一緒で
やっぱり一個一個無意識的有能に消化していくって大事だなって
思いましたね
僕あれなんですよ小学校の時に逆上がりできない子だったんですよ
できるようになるのに1ヶ月かかったんですよ
1ヶ月間なて休みずっと毎日神社の鉄棒3時間ぐらいやって
ようやく最終日ぐらいにできるようになったんですけど
おかげで僕逆上がりの仕組み全部わかるんですよ
なんでできないのかっていうその仕組みが
すべてわかってて逆上がりが人間が逆上がりを行うには
まず腕を引きつけて視点を真ん中に寄せて
重心を鉄棒の中心に近づけてあげないといけない
飛ぶ時は足を前方に持って行きがちなんだけど
実はそうではなくて上に飛ばなきゃいけないんですよ
最後は足を引っ掛ければ勝ちで
そうすると後は遠心力でもあるんです勝手に
そうすると力がなくても太ってても割といけるんですよ
僕はこの理論で数々の逆上がりできない子を逆上がりできるようになりました
素晴らしい
それはできなかったから説明できないっていう
無意識と意識のたぶんちょうど中間ぐらいにいたからできた
多分技術も割とそうだなと思って
いきなり無意識になっちゃうと分かんない
分かんないですよね
できるじゃんとか分かるじゃんっていう人が
結構今までいらっしゃったんですけど
僕はそれでは分かんなくて
ってなると
僕は意識しなきゃできないが無意識になっていく過程
やったらそのやり方を
同じ段階にいる人には多分刺さる
57:01
たぶん池戸さんがやられている無意識と意識みたいな話も
たぶんきっと同じところにあるかなって気がして
いやーなんで
当たり前の話かもしれないですけど
優れたプレイヤーが優れた教育者になれるかというと
そこは相関はないというか
前提条件みたいなところはあるかもしれないけど
必ずしもいい教育者になれるかは別で
それこそやっぱいきなり無意識のレベルにいくとか
あるいはかなり先に行ってしまって
その頃の意識的有能の頃を忘れてしまっていたりすると
教える
そこを言語化して分解して教えるのが非常に難しいので
それはそういう人は本当に
本当に一スペシャリストとして価値を発揮してもらえば
それはいいかなっていうのを思っていて
多分その人じゃないと解決できない問題も多分あるし
それだけのスピードで先に行ってる人なんで
それはもう最前線でバリバリ戦ってもらえるのが
一番価値が出せるところで
それはそれとしてこうやって言語化したりとか
いろいろ分解したり
体系的に整えて知識を伝えていくみたいなことを
やっていく必要がある部分もあるので
そういった役割を担う
我々って言うとおこがましいのかな
そういう役割を持った人たちも
それはそれで必要かなって感じですよね
そうなんですよ
って思って最近は頑張ってるんで
頑張ってるなってみんな思ってね
思ってるわけではないな
単純に楽しいからPHPやってるだけだな俺は
まあまあ楽しいんで
楽しいんですよ
楽しいのを存分に楽しくやるためには
やっぱり周りの人間を巻き込んでやっていかないといけなくて
そのためにはやっぱり教育と組織作りが必要になってくる
いい感じにラップラップが
そうですね
このポッドキャストでも何回も言ってましたけど
ログホライゾンのニャンタ班長が
第4話ぐらいで言ってたんですけど
やっぱりみんなが一生懸命組織を良くするとか
物を良くしていこうみたいな
全員が織り重なってちゃんとした物ができてくれるってところが
誰もそこではさぼらずにきちんと前を見ていく
ところがやっぱりすごい大事
今日一日真面目だったな
私が関わると真面目になってしまう
いやーそうですね岡章さんはいる場合ですね
1:00:02
あと私は参加すると毎回何かを
本を勧められて買わされている気がしますが
あー大丈夫それはね僕は
自主的に買っている
僕と話すと大体その時読んでて
一番推しの本を勝手に勧めてくるんで
そうですねあのね最近の一押しは
意外と技術書じゃないんですよね一押しは
いやでも分かります分かります
結局勧めるのは技術書よりももうちょっと
エッセンシャルなというか
もう少し抽象的な
題材になりがちな気がします
抽象だから適用範囲が広いからですね
そうなんですよね
技術から学べっていうかさっきのその
Snowballの教育から学んだりだとか
例えばドキュメントの整理から逆に
コード綺麗なコードの書き方を学んだりとか
やっぱそれを勧めると
そういう概念なんだろうなーって
やっぱすごい思いますね
日本語で
ただそこここにいろんな抽象というか
メタファーとかそういったものがあって
そういったものをやり取りしながら
自分たちの中にうまく適用できる形ができる
みたいなそういったことをたぶん日々
みんなたぶん真剣に頑張ってるからやるんでしょうね
なんかそんな気がします
ということであっという間に1時間が
経ってしまいましたのでそろそろ
いやー早いですね
今日早かったですね
いつも結構あっという間に過ぎてる感じが
今日はさらに早い感じがした
充実した時間でした
ありがとうございました
明日もまた頑張れそうです
今週も放送を聞いただきありがとうございます
番組のフィードバックや要望は
ハッシュタグ横浜の声もつけてツイートしてください
ライブを聞きの方は高評価ボタンをクリック
次回も聞きたい方はぜひチャンネル登録をお願いしますと
本日のお相手は池戸江さんと岡添さんでした
ありがとうございました
ありがとうございました
横浜の声
01:02:39

コメント

スクロール