外資系企業での経験
はい、趣味でOSSをやっている者だ。引き続き、シルバーさんとお話をしていこうと思います。
前半は氷の話とかをしてたんですけど、後半はちょっと趣向を変えてっていうところもあって、
なんかまず、結構シルバーさんが僕に聞いてみたいみたいなことがあるっていうことで話題に挙げられてくださってますけど、
そういう、どういったことを聞きたいみたいな感じですか?
そうですね。いろいろ聞きたいことはあるんですけど、どこまで遡って聞いていいものか。
ハテナでいろいろやられてたなーっていうのとかもあるし、その後、いろいろ経験された後に外資に行った話も聞いてみたいし、
その後にヘンリーに入って、VPOEになられて、採用もやられたりしてたんでしたっけ、
あとはそこから少し一歩離れて技術顧問やってるっていう話をお伺いしたりしてるんで、
いろいろこれまでのいろんなご経験がどういう気持ちでやってきたのかなーみたいなのを参考に聞きたいなと思ってます。
なるほど。そうですね。僕、シーバさんがそれこそ外資の会社に入られたときに、
そのあたりもいろいろ1年経ったみたいなエントリー書かれてたりとか、そういうの拝見してて、かなりシンパシーを感じてて。
僕はあんまり割とフラフラ生きてる感じなので、あんまりこうしたいみたいなのがあってやってるわけではないんですけど、
でもそのとき必要なことだったりとか、こうしたいみたいなこととか、そういった感じでやってるっていう感じなんですよね。
割と求められたことと自分がやりたいこととやるべきことみたいなところを掛け合わせて、じゃあこれをやってみるかみたいなそういう感じでやってるので、採用とかもそういう流れでやってるみたいなところがありますね。
シンパシーを感じてくださったのはどういうところですか?
どういうところなんだろうな、ちょっとごめんなさい。ちょっと細かいところは忘れちゃったんですけど、それこそいきなりそういう外資の会社でエンジニアとして働くみたいなところって、かなりジャンプがあったわけじゃないですか。
シーバさんがやられたときも。その辺の心持ちみたいなものが結構似たものがあるなっていうか、割ともうこれまでもう無縁かもしれない。
英語環境で働くとか、なんとなくおぼろげには思うことはあれども、そういう機会はないのかなって思って、例えば40前後とかになって。でもあえてそこでやれるそうなチャレンジがやってきたから、そこに飛び込んでみるみたいな、そういう雰囲気をちょっと感じたので。
僕もそういう、そこには近しいものがあったので、そこはやっぱり40ぐらいになってくると、自分のキャリアの中でなんとなくやり残してたことみたいなのが見えてきて、やりたくなっちゃうことみたいなのあるよなっていうのをなんとなく思ったりしたんです。
ちょっとシーバさんがその時どう思ってたかみたいなのはわかんないですけど。
でもそれは同じ気持ちですかね。もう今しかないかなーっていう気持ちで行ったのはありますね。実際、あれよりあと1年遅れてたらもうそういうチャンスなかったかなと思うので、いいタイミングだったかなと思いますね。
まあ確かにそうですよね。その後やっぱりその外資の状況みたいなのもガラッと変わっちゃいましたからね。そういったことをおっしゃってます。その1年違ったらってそういったことをおっしゃってますか。
組織開発と採用
自分はネイオフがあってやめたんですけど、それからあとは結構日本から外資で働くのはかなり難しい状況になったかなって思ってるし、今だとさらにAIとかの影響もあってもっと難しくなってるんじゃないかなと思うので、特に自分の年齢を考えてもなかなかあの時はベストなタイミングだったなと思ってますね。
うん、そうですよね。やっぱ普通に開発者として働くのはかなり難しくなってきてるんだろうなっていうのは思いますよね。
はい。その後からまあ曽夢さんと辞めちゃったねみたいな話をして、でお互いに医療系のスタートアップに入りましたけど、曽夢さんはそのペンリーでどういうことをやられてたんですか。
僕は最初の半年ぐらいはやっぱ開発に携わっていたんですけれども、まあちょっとちゃんと採用拡大したいとか組織拡大したいみたいなところがあったので、
そういうのもあって、VPOEっていうことで、肩書きつけてもらって、組織開発とか採用みたいなところにフォーカスするっていうことにしたみたいなところがありますね。
コーディングを最初はICで入ったってことですよね。
そうですね。
で、その後まあ半年ぐらい経ってVPOEになって、ちょっとコードからは離れて、全社的な採用とかを見るようになっていったって感じですよね。
そうですね。
それはなんかこう迷ったりはしなかったんですか。
でも、社内に優秀なエンジニアの人がすごくたくさんいるので、そこにコード書くのとかは彼らに全然やってもらえばいいなっていうところがあったので、
それよりかは自分がバリを出せるみたいなところは、そういう採用だったりとか、制度設計とかそういったところなのかなっていうふうに思って、
そうですね、こう始めたっていう感じですね。
今はその技術顧問やって、ちょっと一歩離れて別のことやられてるんですよね。
そうですね。
それはどういったチャレンジとか、気持ちからそうなったんですか。
なんかそれは色々と、家の状況とかもう少しちゃんと家庭に向き合いたいっていうのと、少しちょっと働くリズムっていうかペースを落としたいっていうのがあって、
そうなった時にやっぱVPOEみたいなことをやるのって難しいので、あんまり週に40時間働けませんみたいな感じになっちゃうと、それはそれで良くないなっていうふうに思ったので、
少しそういうパートタイム的な感じで働かせてもらうっていう感じに今なってるっていうところですかね。
クリエイティビティの探求
いいですね、それも。その家のこととか考えると、今子供たちと一緒に過ごせる時間も大切にしたいなっていう気持ちがあったりしながら、でも仕事もしっかりやらなきゃみたいなんでちょっとこう迷ったりしますね。
そうですよ。今8月じゃないですか。僕ちょっと先月末に怪我して足を折っちゃって入院してたみたいなのがあったんですけど、でもなんかそういうアクシデントはあったけど、今月は子供たちが夏休みだからずっと家にいるみたいな状況で、
子供たちとゆっくり過ごせてすごい良かったなっていうのは思ったりしてます。
いいですね。それもすごい大切ですからね。
いやもう、なんかあと何回もないわけじゃないですかっていうのが、あと本当にあと一桁回数しか、一桁回数どころか5回あるかどうかみたいな感じだから、子供10歳と9歳だから、なんか本当にそういったところが普通にそういう意味では良い夏休みだったなっていうのを思ってるところです。
いいですね。僕もちょっとこういろいろ落ち着いたらゆっくり子供たちと遊びたいなみたいな気持ちはありますね。あのぼーっと。
あともうちょっとそうですね、僕がどうなるかわかんないですね、次は。もうちょっとなんか自分でなんか新しいプロダクトを作るかもしれないし、
あと最近やっぱり、プロダクティビティよりもクリエイティビティの方に興味があって、エンジニアとしてどうクリエイティビティを出すかみたいな、そういうところに興味があるなというのは思っているので、
なんかそういったところでなんかチャンスだったり可能性はないかなっていうのをちょっと思ったりはしてますね。
クリエイティビティというとどういったところですか、新しい何かを作り出すとか、そのイノベーション的なものだったり、身近な人の何かを少し便利にするものだったりとか、いろいろあるかなと思うんですけど、
その辺を思い浮かべてますか。
その辺、それぞれだと思うんですけど、だと思っていて、ちょっとわかんないんですけど、でもなんか普通に何か求められるものを作るみたいな、そこの生産性を上げるみたいなのもすごく大事だと思ってるんですけど、
求められていくニーズに対して、新しい発想とかクリエイティビティみたいなもので解決するとか、そういうところをもっとエンジニアができるんじゃないかなっていうのも思ってるし、
AIの力とかでそれがもっとできる状況になってるんじゃないかなって思うので、もっとエンジニアのプロダクティビティだけじゃなくてクリエイティビティにもっと着目すべきなんじゃないかなっていうのを最近思ってて、とはいえ何かそれで何ができるのかみたいなのはわかんないんですけど、
それも含めて、なんかそれこそ最近はだからOSS作家とか名乗ってますけど、最近だからOSSとか多少作ったりとか改めてしてみて、そういう中で自分の作家性みたいなものだったりとか、そういうのを今なんか感じているところですねっていう。
いいですね。僕自身はそんなに、さっき氷の話前半でしましたけど、自分自身はあんまりOSSの活動とかはやってはいなくって、だからアソムさんとかがいろいろ作られてたりするのを見ると、すごいなーと思っていますね、いつも。
そうですね、まあそれぞれ人それぞれの個性みたいなものがあって、僕はそういうのを作るのなんとなく好きだし、なんとなく得意なんだろうなーっていうのは思いますね。まあそれが使われるか使われないかはともかくとしてなんか出してみるみたいなのは結構やってるなっていうのは思いますね。
すごいな。
まあでも全然使われてるツール、ものみたいなのはないんですけどね。いやなくはないけど、自分でセンスターとかいくようなものを生み出したことがないので、そこはなんかそういうのができればいいなっていうのは思ってますね。
うんうん、いいですね。僕はそのうまく作りたいなーっていうのをこの20年ぐらいずっと思ってる感じですかね。なんかクリエイティビティとかはすごいなとは思うんですけど、自分にはあまりそういうのなくって、なんかまあ作るものをもっと上手に作りたいとか、もうちょっといいものを作れるようになりたいとか、
そういう方がモチベーションになってるかなとは思います、自分の。
なるほどなるほど。僕もまあなんかクリエイティビティがあるわけではないと思ってるんですけど、いやわかんないな。
いやありますよ。
そういう、あとなんか僕結構ちゃんと作るみたいなところに結構こだわりがあるなっていうのは最近こうなんか思いましたね。
どういうちゃんと作るですか。
ちゃんと作るっていうか、やっぱなんか結構、クリエイティビティを独自性を発揮する以外のところっていうか、以外のところでは結構セオリーだったりとか、ちゃんとした仕様、スペックみたいなものにちゃんと当たって、そこになんか準拠するみたいなことは結構大事だなっていうふうに、
なんかその思ってるんだなっていうのはその結構感じたところではありますね。
なんか割とやっぱりその、社内にしようOSSで議論にするにしても、割とちゃんとスペックだったりRFCとかそういうのをちゃんと見に行って、それをベースに議論するみたいなことをすることが多いんですよね。
なんかおかしな振る舞いとかしてるところでも、多分スペックではこうだからとか、なんか割とそういう話を僕はしがちだなっていうのを思っちゃってますね。
それは最近気づいた感じなんですか。
最近気づきましたね。気づいたっていうか、結構細部、細かいところで、そういったとこちゃんとしておいたほうが無難だし、むしろそういったところで後でなんていうか、うまくいかない、がかいしちゃうことがあるみたいなふうに思ってるから。
最近そのDECっていうOSSをずっと圭一郎さんって方と開発してるんですけど、その中でもやっぱりマークダウンの仕様だったりとか、そういったものをベースに、ここでマークダウンはこういうふうに解釈されて、こういうふうにレンダリングされるべきだから、ここでもこういうふうにあるべきじゃないですかねっていうような話をすごくすることが多くて。
コードの書き方と意識
それこそ逆に圭一郎さんとかは別に自分のユースケースとかを満たせればいいから、そこまで考慮して作ってないし、それでいいと思うんですね。僕の方がむしろそこにちょっとすごいこだわりを持ってしまうみたいなのを感じて、そこは結構、僕はそういったとこここだわりがちなんだなっていうのをちょっと思ったんですよね。
し、そこをちゃんとやっておく方が、その後の変化も早いし、拡張性とかも全然あるよねっていうふうに思ってるみたいなのが自分の中で思ったりはしました。
そうですね。両方ともわかりますね。自分が使える部分がちゃんと動いたらいいよっていうのがないと作れないし、それをじゃあちょっと仕上げていこうかっていう時には仕様にちゃんと当たりたいですよね。
そうですね。仕上げていくとかは本当にそういうのがありますね。
作家って感じですね。
あと結構、圭一郎さんとそれこそ10年ぐらい前、10年いいすぎかな、5、6年前に話したときに、多分そのときに話したのも、僕が登壇した内容が結構外部コマンドをプログラムから起動するときにどういうふうにハンドリングすべきかみたいなことの発表だったんですけど、
それを話したときに圭一郎さんにすごく正しい行動を書くことへのこだわりが強いですよね、みたいな。そういう言い方じゃないんですけど、そういうことをされたことがあって、
そういうふうに見えてたのかっていう。そのときちょっとよくわかんなかったんですよね。僕結構、行動としては結構はしょるとこははしょって、大事なとこはしっかり書くっていう、そういうふうに思ってるので、あんまり全般的にきっちりした行動を書くわけではないと思ってるんですけど、
今回そういう圭一郎さんとデッキの開発をする中で、引き締めるべきところはちゃんとやるみたいなところへのこだわりは結構強いのかもなっていうのは思ったっていうのがありますね。
それまで思ってなかったの面白いですね。もうちょっと手抜いてると思ってたのに、本当は他の人から見るとしっかり作ってるってなってるってことですよね。
っていうのと、たぶん僕、すごくしっかりとしたコーディング規約とかをバチッと設けて守らせるとか、全部の場所に全部の同じ書き方を適用するとか、そういうのは全然良いと思ってないんですよねっていうのがあって、でもそういうことをしたい人とかそういう流儀の人もいると思うので、
そういう人に比べると僕は不真面目なソフトウェアエンジニアだなと思ってたし、それでいいって思ってたんですけど、でも実はそういう大事なところはしっかりやって、他のところはさらっと書くみたいなのって、実は結構僕のスタイルなんじゃないかなっていうのを最近思ったっていう。
そういうメリハリのあるコードみたいなのが僕のスタイルではあるなっていうのを思ったんですよ。
書き方っていうよりは、使用って感じですよね。この後々拡張しやすいようにとか、後々困らないように、きっちり流儀に従っておこうかっていうふうに、今の話からは自分は印象を受けてますね。
っていうのと、例えば引っ越しなりなんなりでたくさん荷物があって、それを梱包するっていうふうにするとするじゃないですか。
その時に、僕は大事なものはしっかり厳重にやるけど、それ以外のものは別に適当でいいっていう、適当でいいっていうか、ちゃんとその重要度に合わせて、どれぐらい丁寧に梱包するか、ラフに梱包するかみたいなのを分けていいって思ってるんですよ。
でも、たぶん中には全部きっちりきっちり梱包したいっていう人もいて、僕はそういう感じではないよなっていうのを思ってるんですよね。全部きっちり梱包しちゃうと、どれを丁寧に扱うべきか、たぶんその運ぶ人も分かんなくなっちゃうから、それは行動を読む人とかもそうだと思うんですね。
全部すごい重厚に、コメントもバッチリで、全部細かくクラス切ってみたいなのをやりすぎると、たぶんどこが行動として大事なポイントなのかっていうのを見づらいから、でも本当に大事なところはしっかり書いて、しっかりコメントも書いてみたいな、そういうメリハリが大事だよなっていうのをすごく最近改めて思ったし、
僕は結構そういう行動の書き方をするんだなっていうのを最近気づいたっていうのがありました。
アーキテクチャーとリスクヘッジ
面白いですね。アーキテクチャーもそうですか。今行動の話ですけど、システムのアーキテクチャーを考えるときには、この辺は重要だから結構しっかり作り込んで、こっちは言っても大丈夫だからちょっとラフに作っちゃおうかなみたいなのやりますか。
そうですね。そのノリだと結構ラフすぎる感じがしますけど、それに近いのはあるし、結構システム設計って諦めが重要だと思っていて、
何でもそうだけど、事故の確率をゼロにはできないからどこまでリスクヘッジをするかっていう話があると思っているので、じゃあここはもう諦めるとか、ここはもうちゃんとやるみたいなところの線引きってすごく大事だなと思ってるんですよね。
全部ちゃんとやろうとすると、じゃあやっぱりディザスタリカバリのために複数の拠点でちゃんとデータストアを置きましょうとか、それは最近やりやすくなってるからいいと思うんですけど、じゃあ複数のクラウドで動かせるようにしますかとか、そういう話になってくると、じゃあなんか大げさになってきちゃうんで。
じゃあなんかその辺って、どれぐらい自分たちとして、ここは多少落ちてても許容できるとか、そういったところはすごく大事な部分だよなって思ったりはしてるんですよ。
じゃあアーキテクチャーとかシステムもメリハリをしっかりつけて作るって感じですよね。いいですね。
それこそちょっとしたものだったら最初はパッと作って、本番投入して、最近もそういうの減ってきたけど、それでちょっとちゃんと使われて始めてきてから、結構丁寧に作るとか、そういったところはあったりはしますね。
そういう手を動かし続けてるのはいいですよね。同年代とかでも、エンジニアとして手を動かし続けてる人はどんどん減っているのかなと思ったり、でも周りを見ると逆に増えてる感じもするなと思ったり、結構手を動かし続けてる人たちは見てるの好きですね。
そうですよね。最近やっぱり普通に行き来しやすくなってるっていうところはあると思うので、そのマネジメントと開発者として。そこはすごくいろんな可能性みたいなのがまだまだ残ってる状態なので、今後のキャリアにおいてすごくそれはいいことだよなっていうのは思いますね。
また生成AIでちょっとリセットされた感もありますからね。挑戦のスタートラインが。
そうですね。生成AIでやっぱり今は結構そうですね、シニアの人とかもかなりまたコード書く分量が増えたみたいなところも、書ける量も増えたみたいなのはあると思うので、何にしよう、そういうテクノロジーの力で人の能力がエンハンスされる強まるっていうのはすごくいいことですよね。
いいなあと思いますね。
やっぱり何でもそうだけど、スポーツ選手にせよ何でも競技にもよるけど、ありと頑張れば長生きできる、長くパフォーマンス保ち続けられるっていう感じになってきてると思っていて、やっぱりそれって普通に仕事でもそういうことがあるだろうなって思ってるので、そういうAIもそのためのテクノロジーになり得るよなっていうのはすごい思ってはいます。
いいですよね。
AIで思い出してまたちょっと話戻しちゃうんですけど、型を扱うのAI苦手だなってちょっと思ってるんですよね。
結構ドキュメントを生成したりとかコメントを生成したりとか、簡単なテストを書いたりとかはガンガン書かせてるんですけど、コアになってる型を取り回す部分とかは自分の手で書かないといけないなっていう感覚があったりして、
そういうのでも結構メリハリというか、自分はここを書くけどそれ以外の部分はもうAIに任せるみたいなのはやってたりするなって今聞きながら思いました。
確かに。まだね、やっぱり人間の手が必要な部分ってすごく多いし、そういったところこそAIがやってほしいみたいなところを結構やってくれなかったりしますよね。
そうですね。結局自分が手で書いたほうが早いのに、なぜこれはAIを使いながらやってるんだろうなと思いながら書くときもたまにありますね。
そのあたりは結構AIの成長にも期待だし、やっぱりどうしても人間味があるから、そこってAIの特徴でもあるから、割とそういう、それこそ本当に機械的な処理みたいなものって苦手だったりするのが面白いですよね。
妙に人間臭かったりするの面白いですね。
それこそ、何百ケースぐらいあるテストケースの入力のフィールドをちょっと増やす必要があるみたいなのをやらせたときに、先頭の10個ぐらいやって終わらせちゃったんですよね。
残りも同じようにやれば可能ですみたいなことを言い出して、全部、この入力のストラクトにこのフィールドを入れるだけだから機械的にやってくれよって思ったんですけど、全然やんなくて、すごい面白かったです。
途中でやめるときありますよね。後はやってくださいみたいに言われて、いやいやいや、お願いしたんだけどみたいな。
それでじゃあ続きもお願いっていうと、ケース数が多いのでスクリプトを書いてやるようにしますとか言って、そのスクリプトがバグっててうまく動かないので元に戻しますとか言って、ずっと終わんないみたいになっちゃって。面白いなーって思って。
ちょっと大きめの変更とかを依頼するときはその前に一旦コミットしちゃいます。戻せるように。
いや、絶対それはするよね。なんか普通に少なくともGitAddはしといてなり、差分確認できるようにしないと怖いし。
戻してなくなっちゃう。
たまにすごい暴走しちゃって、変なとこ行っちゃうからな。
そうなんですよね。面白いですよね。
チームの力と組織構造
そんなとこかな。なんかあと最近のGoブログ記事だけですと、チームの力が組織を動かすっていうやつの本のレビューみたいなものがちょっとバズってましたけど、これについてちょっとお話をしたいです。
これ多分発売したてで僕はまだ読んでないんですけど、これなんか良さそうな本ですね。
めちゃくちゃ面白かったですよ、これ。
やっぱり今自分がいろんなチーム、これまで前々職くらいからいろんなチームサポートしてきてるんですけど、サポートするときに役に立つのってチームの外側を整えてあげることだったりするんですよね。
チームが困ってるときって、そのチームの中ではいろいろ手を打ってるんだけどどうにもうまくいかないからサポートしてほしいみたいな話になってたりするんですよね。
サポートに入るとチームの中は頑張ってるんだけど、その外側にうまくいかないような仕組みがあることが多いので、そこをちょっと外側のところを整えてあげるとうまく回り始めるっていうのが多くて。
そういうのを考えてたらやっぱり組織の作りとか構造とかから来ることって多いなっていうのを感じてて。
自分がVPOTになってからも組織全体をよく見るようになっているので、そういう観点からも組織の構造をどう定義するかっていうのはすごくチーム開発に重要だなと思ってたところで、この本をいただいて読んでて、そうそうそうってなりながら見てましたね。
いや、そうですよね。すごくこれは色々読んでみたいと思いましたし、なんかやっぱすごい分類の仕方がすごい上手い本だなってパッと見た感じでもやっぱり思いましたね。
アンチパターンとかそれに加えた原則みたいなもの、ガイドラインみたいなものをうまくまとめて解説しているので、これはすごく良さそうな本だし、こういうふうにちゃんと原則、ガイドライン、アンチパターンみたいなのが守ってると書かれてると共通言語にしやすいですよね。
そうなんですよね。それまでもなんとなく感覚ではそういうの良くないよねとか、そのせいでこうなってるよねとは思ってたりするんですけど、それはこう自分は結構感覚派なんで、言葉でうまくまとめられないんですよね。
ピーターの法則とその影響
だけどこの本はいろいろパターンというか名前をつけてくれていたり、説明をしっかりしてくれてたりするので、これちょっと自分が説明するときに使えるなーっていう気持ちで読んでました。
お願いします。
特にまあ、
ねじれコンウェイとか。
あーそうそうそうねじれコンウェイ。ねじれコンウェイはいいですね。あの名前が好きですね。
名前がいいですよね。
コンウェイの法則って言って、組織とアーキテクチャーが結びついてしまうような法則がありますけど、それがちょっとねじれた形になってるといろんなコミュニケーションの負荷とかが上がったりして、そういうのが内部品質にも影響がありますよっていうパターンなんですけどね。
そういう名前の付け方とかも好きだし、あー確かにあるなーって思ったりしながら読んだりしています。
で、その中で推しのパターンはアトミックですね。
推しの原則かなこれ。
チームを、個人をプロジェクトにアサインするんじゃなくて、ちゃんとチームにタスクをアサインするし、チームっていう単位でそれ以上分解して扱わずにチームに対していろんなタスクを与えていきましょうみたいなパターンですかね。
これは確かにそうだなーと思うし、結構開発してても1人サポートで助けてほしいみたいなこと言われることあるんですけど、
そういう時にその1人をいいですよって出しちゃうと、あんまうまくいかないなーと思ってるんですよね。
だからそういう話が来た時は、うちのチームでサポートしますよ、そのタスク引き受けますよみたいな話をしたりするんですけど、
それがここにも書かれていて、いやいや自分も同じ考えだなーと思いながら読んでました。
確かにそうですよね。やっぱなんかそのチームとプロジェクトみたいなものが、なんだろうな、ある程度素結合になってた方が良くて、直行性があった方が良くて、
多分そうしないと、じゃあこのプロジェクト終わったから解体しますみたいなのがやっぱり起きがちなので、そうじゃなくてそうですね、チームにちゃんとプロジェクトをアサインしていくみたいな、
そういう風になってるのは大事なのかなっていうのは思いますね。
チームでうまく開発ができるようになっていくっていうのが大切かなと思ってたりするし、チームの中で関係性がどんどん構築されていったりするので開発が上手になっていくかなと思うんですよね。
だからそういう環境を毎回プロジェクトの度にリセットしてたら、もう本当に個人個人のスキル以上のことは起こらないなと思ってるんですけど、
それがチームとして取り組むので、取り組んで成長していくと、その人たちが持ってる力以上のことがお互いにカバーしながら出せるなと思ってます。
そうですよね。これいいなって思ったのは、僕も結構ちゃんと個人の力で組織に影響を及ぼすとか、組織を変えていくみたいなことってすごく大事だと思ってるんですね。
そういう意識を持てる方がよく働けるし、変に諦めが生まれないと思うんですよね。自分はここまでしかできないから、もう何にも改善できないみたいな、そういうふうにならないと思ってるので、
僕の意識としては、自分の力とか、自分の中で会社全体にどう影響を与えるか、会社を良くしていくかっていうところまで考えたいと思ってるんですけど、たぶんこの本はちゃんとチームの設計とかをちゃんとやることによって、
やっぱりボトムアップ的にチームで組織を変革したりとか動かしたり、そういうバリューストリームにどうつながっていくかみたいなことを意識しやすくするみたいなことがきっと書かれてるんじゃないかなって思ったので。
なんかそれすごい良い発想だなっていう。僕は結構そこをこうで頑張ろうとしてたかもしれないけど、これはちゃんとチームでそういったことをやりやすくする構造化の話なのかなっていうのをなんかパッとオーバービューした感じ思いました。
本当にそうですね。チームがど真ん中にあって、そのチームがうまく力を発揮できるような状況にしていくことで組織全体を良くしていくっていう流れですね。これがすごい自分も好きな取り組みだなと思ってます。
なるほど。ちょっと買って読んでみます。
チームとしての協力の重要性
ぜひぜひ。はい。ちょっとまたその話聞かせてください。
あとなんか最近、しーわさんのブログを拝見してると、4月ぐらいに書かれた旗振りをするときに考えていることみたいな、そういったブログ記事があったんですけど、
これすごく良いなっていうふうに思ったんですけど、これなんかどういったこと書かれたかって今でも思い出すことできます?
そうですね。これはその多分VPOTになってしばらくして、なってすぐぐらいかなに考えてたことかなとは思うんですけど、
一つのチームをリードするときっていうのは、自分は結構その、自分が引っ張るのは結構好きなんですよね。
自分が手を動かして、いろんな人を繋いだりとか、働きやすくしたりとか、行動を見せたりとか、そういうのが好きなんですけど、
もうちょっと広めの範囲をリードするときって、やっぱりいろんな人の力を頼らないと自分一人では何もできないなって感じたのが、
この張ってたフリをするときに考えてることの記事を書いたきっかけかなと思ってます。
みんなを頼りたいみたいなことを書いてるのですごく良いなって思いましたし、
シーバさん結構そういうのが上手そうだなっていうのを勝手に思ってたんですけれども、
でもチームの中では結構引っ張っていくみたいなことが多かったんですか。
多かったっていうか、その辺って実際どうだったんだろうっていうのと、こういうことを書くに至るやっぱきっかけみたいなのって、どういうところにあったんですか。
そうですね、自分がいる立ち位置によってどう自分が動くとその場が一番上手く回るかっていうのは変わるなと思ってるんですよね。
一つのチームのテックリードをやってるときに考えてることと、何チームか全体を見ながら一緒にやっていく立ち位置にいるときとでは考え方が結構違ったり言ってることも違ったりするので、
その辺は明文化しておくかっていう気持ちですかね。
なるほど、そこで結構素早くマインドと切り替えられたのはすごいなっていうのを思いました。
ありがとうございます。あまり自分のこうやってきたみたいなのにはこだわりはなくて、その場で何をするべきかみたいなのを考えてるんですけど、
そういうときに全社的な動きを見ることになったときには、多分自分が行動を見せたところで全体が良くなることはないなと思ってたりして、
それぞれ各チームにいい人たちがいるので、そのみんなの力が出しやすい状況を作るのが自分の一番貢献できることかなって思って、
それを考えるとみんなが力を出しやすいとか、みんなの力を頼れるような状況ってどうやったら作れるかなって思うと、
僕はこういうところに行きたいと思っているみたいな旗振りをちゃんとすることかなと思ったっていうところですかね。
こっちに行きましょうよとか、そっちに行きたいと思ってるんだよ、なぜならこうだからみたいなのをちゃんと言っとくと、
僕の好きな人たちはとか司会してる人たちは結構、そうしたいんだったらこういうやり方があるよみたいなんで、自分たちで勝手に動き出してくれるから、
自分はそういう旗振りをすることが大切かなって思ったかな。
いいですね。いい人がいるとか好きな人たちがっていうのが自然に出てくるのがいいなって思って。
やっぱりこういうテックリードみたいなところからVPOTだったり、もう一段上のレイヤーに行ったときに、
やっぱりテックリードの延長でやっちゃう人ってすごく多いと思うんですよね。
それって仕方ない、誰でもそういったこと起きて、その中で痛みを見て学んでいくみたいなことが多いなと思ってるんですけど、
例えばやっぱり全部の技術理解しようとしなきゃって思ったり、全部の技術に対してガイドライン示さなきゃとか、そういうふうになってすごく疲れてしまうだったりとか、
全部の細かいところにやっぱり結構ちゃんとしっかりデビューしたくなるとかしちゃうとか、口を出すみたいなことって結構起こりがちだと思うんですよね、と思ってて。
ただ、しーわさんちゃんとそこ早い段階からちゃんと周りを頼るっていうのを、当然のようにやられてるのはすごいなっていうのは思いました。
ありがとうございます。嬉しい。
あと、こっちに行こうよみたいなの言うのがちょっと怖いなって気持ちも同時にあるんですよね。
そっちが間違えてたときに、ごめんってちゃんと言わないといけないから、言ってなかったらみんなで言ってみて違ったねってなったら違ったねって言えるんですけど、
僕がこっち行こうって言ったんだよねっていうことになるから、そこは怖いなーって気持ちあるんですけど、でもそれも自分のスキルの一つかなっていう。
それがちゃんといい方向に向かってなかったら、自分の見てた方向がスキル足りなかったんだなっていう気持ちだったりしますかね。
そうですね。やっぱりちゃんと信じてもらうみたいなところと、それで結果的にうまくいかなかったとしても、しょうがないかっていうか、そういうふうに思ってもらえる関係性づくりとか、ちゃんと巻き返せるかどうかみたいなところがあったりはしますよね。
限界に挑戦することの意義
そうですね。なんか結構、自分が無能になるまでラダーを上がってしまうみたいな話とかあったりしますけど、それ登り切ったらいいかなと思ってるんですよね。
だから自分がこうだと思ったけど、全然なんかここ自分の限界だったなーっていうところまで行って、それでごめんみんなって言って、ちょっとそこが限界かーってなって知るのも自分の中では一つ目標かなと思ってます。そしたら違うことやろうかなっていう気持ちがあったりします。
いや、本当そうですよね。そうそう、もうピーターの法則上等みたいなところありますよね。っていうのは僕も思っていて。し、どうせそういう壁にぶつかって変化せざるを得なくなる時ってやってくるし、そういうのがあればあるほどいいし、実際そういう結果を出せない場所にいたときにそこに留まり続けるのがやっぱり問題なのであって。
なんかそれでなんか組織がサインを変えないとかそういったことがやっぱり問題なわけだから、ちゃんとそこで失敗したらちゃんと配置替えするとかそういうのができるようになってれば全然問題ないですもんね。なんかそうしないとずっと恐る恐る限界に当たらないようになんか頑張るみたいになっちゃうからよくないですよね。
そうなんですよね。その自分の限界が来ちゃうかもしれないと思いながらやってるとその前に進めないというか恐る恐るで進むしかないから、それだとちょっと人生は足りない短いなと思っちゃうんですよね。残りが。
それはかっこいいな。
本当に逆算するともうあんまり自分には時間ないのかなと思ってたりして、そう考えると限界来るかもなって思ってるよりはさっさと限界にぶち当たって次のことやりたいなっていう気持ちですかね。
いいですね。あとまあ確かにその今しかできないことってありますからね。今なんか限界にぶつかっておいたほうがいいことっていうのはありますしね。なんか例えば人生で一番早く走れそうな時にやっぱ全力で走っておくみたいなのってすごく大事だから、なんか。
なるほどね。
そうですね。今が一番若いですからね。
そうですね。いやでもやっぱ頼れる人強いなっていうのはすごく思います。なんかやっぱその超人っていないわけじゃないですか。いないわけじゃないと思うんですけどなかなかいないし、なんか超人に見えることがあっても絶対できないことはあるわけですよね。
技術幹部の役割
だから結構自分はここできないから、なんかちゃんとわかる人に頼りたいですっていうことを言うのってすごく大事だと思っていて、特にやっぱりそういうこうなんていうか技術幹部みたいになってくると当然わかんない領域なんていくらでもあるから、そうするとなんかそこで虚勢を張るよりもちょっとここ全然わかんないんでみたいにやっぱ行ったほうが絶対良いし、
そういったところでちゃんと周りが助けてくれるような関係性づくりをすることが本当大事なんで、そうやっぱそう、なんかここがわかんないです、ここが苦手ですってやっぱり言っていくこと大事だなって思うんですよね。
そうですね。頼る時も自分にはここに強みがあるからこの辺は頼るっていう気持ちではあるんですよね。それが全部頼っていると自分何のためにいるんだろうってなっちゃうから。それでいろいろ頼りたいなと思ってるし、また生成AIの話になっちゃいますけど、生成AIとかを使うのがめっちゃ上手な人たちが会社の中にいるんですけど、
その人たちに頼りたいと思ってるんですけど、その人たちが喋ってることぐらいはわかりたいなっていう気持ちがあって、家でもちょっと生成AI触ってみれたりするっていう感じですかね。
なるほどなるほど。確かにそういうのはありますよね。ちょっと話を聞くときにある程度ちょっと下調べはするみたいなのはありますからね。なんかそしたら結構専門家に教えてもらったときにすごく何ていうか理解度が高まりやすいし、やっぱりそうですよね、ちゃんとそういう専門家に教えてもらうみたいなのがやりやすい立場でもあると思うから。
そこをうまく使うことって大事なポイントですよね。
そうですね。で、自分はエンジニアの延長線上でやってるっていうのもあるので、エンジニアが喋ってる言葉が全然わからないっていう状態はダメだと思ってるんですよね。
エンジニアたちがマネージャーとかに言わなくても、一から説明しなくても自分には伝わるっていう状況がVPoTとしては大切にしたいなと思ってるので、みんなが言ってることを詳しい説明なくてもわかってそれをCTOとかと喋れるっていうのが自分の中では自分の場所かなと思ってます。
やるべきことかなと。
対話の楽しさ
なるほど。いいですね。じゃあ、なんか引き続きご活躍を楽しみにしています。
ありがとうございます。
なんかだいぶ話せて楽しかったな。
面白かったですね。
そんむさんの話もいろいろ聞けたんで。
なんかあんまりまとまってませんでしたけど、ありがとうございます。
ありがとうございます。
じゃあそんなところかな。そういったところで、趣味でOSSをやっているものだシーバさんを迎えていろいろお話をしました。ありがとうございました。
ありがとうございます。
