00:01
こんにちは。言語化.fmは、あんな話やこんな話を、きにんとだての2人でゆるく話しながら、言語化を試みるポッドキャストです。
というわけでですね、今回第1級回目なんですけども、今日のテーマは、運用のことまで考えて、物は作られてないことはあるよね問題について言語化したいです。
そうですね。タイトルがやっぱり難しいんだけども、あれですよね。最近物を作るのって結構ハードル下がってきてると思っていて、
変にどうレベルなことをやらなければ、アプリケーション作るぐらいの話だったら、クライアントもバックエンドももう用意されたものを使って組み合わせていくという風な世界になっているので、
難易度自体はそんなに実は高くないんですけど、もちろんお金とか人が必要だったりはしますけども、新しいものが出てきたときに、
エンジニア、我々エンジニアってとりあえず使ってみようと言って、手を貸してみて、これすごい使えそうじゃん、使ってみようっていうのはよくやる話なんですけど、
じゃあそれでプロダクトが出来上がって運用するっていうことって、その時点では頭の中にはないわけですよね。
そうなったときのコストの話とか、長く運用し続けるっていうことに見合うだけの価値があるのかっていうのは、
検討されないというか、おざなぎになりがちだよねというお話です。
なるほどですね。ありがとうございます、解説を。
そうだね、いやーこれなんか話を聞きながら、いくつかの特定の技術の具体的な技術名が頭に浮かんでしまって、
言ったら炎上するか絶対に言わないぞっていう気持ちになったんだけど、
なんか、そうだね、なんかわかるって感じが気がしていて、
僕は割と、いやーどうだろうな、
なんか僕自身は多分あんまりそういうことをしないというか、なんかそのしないのは何でなのかなっていうのを今言語化しようとしちゃったんですけど、
話が揃えるのを置いといて、例えばその趣味でウェブアプリケーション作りたいなみたいな思ったときに、
今の時代だったら多分めっちゃ、一昔前に比べると楽で、サーバー自分で立てなくていいしとか、そもそもサーバーなくていいし、
ファイアベースとかで無料の枠の範囲内でポチポチポチっていろいろ設定していって、ちょっとSDK、NPMにインストールして、
03:01
ドキュメント見ながらちょちょっと書いたら、なんかいい感じに全部作れるし、
ビューとかもなんでしょうね、ウェブだったらコンポーネントのライブラリーが無限にあるんで、
好みのものを使って、あとはロジックを組むだけみたいな感じの、何だろうな、ことができる、いい時代になったなっていうことはありつつ、
まあ難しいな、なんかどっから整理していけばいいかわかんないですけど、
まあ一方で楽は楽なりのトレードオフがあることも、まあ往々にしてあって、
なんかそのトレードオフをどれだけきちんと認知した上で、まあプロダクションの環境で開発をしているのかなみたいな、
なんか同じことを2回別の言葉で言い直したときになっちゃった、そういう話なのかなっていう気がしてる。
まあそうなんだよね、技術選定をした後に運用のこと考えてないじゃないですかって言うのは簡単なんだけど、
じゃあどうすれば考えてることになるのかって定義するのって意外と難しいというか、
経験値でしかないんじゃないみたいな話もあってですね。
だからある技術はすごく優れていて、別のある技術もすごく優れているんだけど、
組み合わせたときに実はすごく使いづらくなってしまって、
外から見たら仕上がりはいいんだけど、中で歓迎運用し続けると実はつらいみたいなものってちょいちょい見る気がするんだよね。
うんうんうんうんうん、確かに。
いやー、なるほどね。
いやー確かに、なんかそれで言うと、
いやー、確かにどういうふうに作ったら運用しやすいようになってるんだっけのところは確かにめちゃくちゃ難しい気がしていて、
うーん、なんか僕とすごい過去の副業のことを思い出してたんですけど、
そのときはAPIサーバーとフロント側のアプリケーションを提供するっていう要件で、
何でしょうね、なんかそのときに僕が取った意思決定は運用のしやすさとか、
そこにコミットすることになるであろうエンジニアメンバーのスキルセットとかレベル感を考えて、
あと何でしょうね、例えばめちゃくちゃフロントエンド界隈だったらグラフQLでこのライブラリ使って、
表側もゴリゴリに新しめのやつを使って、
新しめの枯れてる中での一番新しめのやつを使うみたいな選択肢も取れたけど、
そっちよりかはもうちょっと何でしょうね、
HTTPSのAPIでRESTでそれなりに綺麗に設計されていて、
サーバー側のコードも言語に依存しない、
06:03
よく言えば分かりやすいし悪く言えば愚直でよくある実装みたいなものを取ったことがあって、
運用のことだけ、それが今言った運用のことを考えられてたかなって振り返ったときに、
僕は何か僕なりに考えられてた気もするが、
でも難しいですよね、一方で何だろうな、
そのやり方が良しとすると、
僕は自分が経験したものをもう一回作ることしか選択できないことになってしまって、
それはそれで良くない気がするから、
一定新しいチャレンジをするということも良しとしなきゃいけないよなっていうことをごちゃごちゃ考えてる。
久々にめちゃくちゃ言語化できてないから感じがする。
この話題はふわっとしてて、話しながら思ったのは、
新規開発で新しいものを使うって割と難易度低いじゃないっていうのも、
自分の今まで使ってきた技術と新しいものを掛け合わせて、
この例が適切かはよく知らないんだけど、
フロントエンドにリアクトを採用していて、
リアクトの周辺環境もすごく変わっていって、
Fuchsとかいろんなリコイルとかいろんなライブラリが出てきてると思うんだけど、
今回はじゃあこれを使ってみようって考えたときって、
そのライブラリに関しては初めてだけど、
フロントエンドの基本知識は備わった状態でやるわけじゃない。
だから多分、あとは少なくともライブラリが提供しているドキュメントとか、
コードが間違ってない限りは、ちゃんとピースとしてはまるはずなんだよね。
なんだけど、そこからそれでプロダクトが完成して、よしじゃあ運用するぞといって、
1年、2年経ったら、IOSもそうだけど、フロントエンドの流行りスタレってすごくドラスティックに変わるじゃない。
うん、変わりますね。
それで自分の入れたものがスタレール側になってしまった場合、
もしくはスタレっているわけじゃないんだけど、
明確に不採となってしまった場合で、
新しいベターな解決策がすでに提供されている場合、そっちに移したくなるじゃない。
そうしたときにどういう判断でやっていくかっていう。
いやー、そうっすね。
めちゃくちゃ、全エンジニアたぶん3回ぐらいは直面してるあの問題ですね。
09:01
いや、もうそんなのもう毎年やってるわっていう感じだけども。
そうだね。いやー、難しいよな。
そうだね、確かに新しく始めるのと動いてるものを切り替えていくみたいな話ありますね。
うん。
いやー、なんかでもめちゃくちゃシンプルな話も話しなきもしており、
その辺りでより良い意思決定を下せる人はグッドなソフトウェアエンジニアだよねっていう評価につまるとこになる気もしてきたな。
なんかさ、そこでよくある話でさ、例えばクリーンアーキテクチャーみたいなもので、
もう割とクリーンアーキテクチャーがベストなクリーンアーキテクチャーだって言いたいわけではなくて、
そのとき流行っていたのがクリーンアーキテクチャーだとしましょう。
で、その後にもっとリラックスライクでデータフローが単行本になっていて、
よりフロントエンドの流行りに乗ってますみたいなアーキテクチャーが出てきたときにさ、
今後のことを考えたら絶対そっちで作り直した方がいいみたいな状況になって、
そうすると、じゃあその新しいものを作りましょうっていう話になったとするじゃない。
そうすると古いものと新しいものが共存してしまって、
でも古い方ではずっと機能開発が進むから、
その新しいアーキテクチャーで作られたアプリケーションはそれに追従しながらアーキテクチャーしなきゃいけなくて、
結局いつまで経っても古い方にマージできないみたいな話はごく稀によくあるじゃない。
ごく稀によくあるね。
だからなんていうか、そういうアプリケーション全体の作り直しっていうのは本当の最終手段で置いておくべきで、
基本はその既存のものをメインに据えながら、ちょこちょこ新しいものを入れていく、
継ぎ足していくっていう手法しか取れないわけなんだけど、
そこをどういうタイミングでどれくらいのスパンでやろうかっていうのに、もう毎年頭悩ませるわけですよ。
そうだね。いやー、なんかすごいふんわりした話題だけどさ、だし、多分100点満点の回答は絶対ないんだけど、
なんかある程度知恵を出したら、なんかなんだろうな、シーケンスフローズをかけそうな気がしている。
12:08
なんか頭の中でいろいろぐるぐる回ってて、例えば、なんか大きく分けると、
新しく始めるときに、そうならない、そうなるというか、絶対いつかはそうなるんだけど、
新しく何か技術的な意思決定をして、新しいプロトコルを作るってなったときに、
そのプロダクトが方向転換をしなきゃいけなくなるまでの時間をいかに伸ばすかって話と、
あとは方向転換というか、その方向転換の大きさはめちゃくちゃグラデーションあると思うけど、
そのグラデーションある中で、そこに対してどういう場面ではどういうアプローチを打っていくのが、
よりベターなのかみたいな2つの話があって、なんかそれぞれ正解はないけど、
なんかこういうやり方がいいよねっていうのは、なんか整理できそうな気がしてるし、
ちょっとオフラインで集まって、マインドマップを一緒に書く回を、YouTube生配信とかしたい。
まあでも、そのダディッシュが言ったのは後者の話だと思ってて、後者の部分を、
なんかより良い選択とか、ある程度多分再現性のある意思決定っていうのは、なんか言語化したい気持ちはあるね。
でも今の、その2つあるっていう話の前者の寿命の話がさ、結局、
そもそもなんで直さなきゃいけないんだっけ、みたいな話に繋がるから、
多分寿命っていうのは何なのかをちゃんと定義するというような気がしたんだけども。
確かに。
アプリケーションにおける技術の寿命とは何でしょう。
いやーめちゃくちゃいい質問ですね。
ちょうど現職で、まさに意図せずタイムリーなことを実はしていて、
今弊社、まあ5年目か、会社5年目だけど、サービスは2年目で、
リリースから2年だから、リリース前を含めると多分3年もののコードベースを面倒見てることになるんだが、
それの寿命がとうとう近づいていることをみんな肌で感じているみたいな状況があって、
で、肌で感じてるけど、多分正しく見つめるのってすごい難しいじゃん。
多分やろうと思えば、多分10年同じものでいけるし、
ただ、それだとまずいということも、なんかエンジニア全員が肌で感じてるみたいなので、
じゃあなんかその何か手を打とうみたいな話をちょうど社内でしてるんだけど、
その判断をするときに、
事業をやってる以上は、その事業のスピードをある程度緩めてそこに投資をするみたいな判断が必要ってなると、
それこそその寿命を言語化する必要があるっていう局面に立っていて、
15:05
そうだね、で、なんか個人的にその、それを整理するために、なんか不採偏採のやり方みたいなすごいチープな検索ワードで、
で、検索するってとこから僕はちょっとリサーチをし始めて、なんかいろいろ読んでたんだけど、
まあそうだな、なんか寿命とはっていうのは、多分身も蓋もないこと言うと状況とかにもよるし、
あとは多分決めの問題な気がしていて、
例えば、その不採偏みたいなところで一番あるあるなのは、そのまま進めていくと多分開発者の生産性が下がるみたいな、
で、開発者の生産性が下がると、まあプロダクトのアウトカムが減って、まあ事業の売り上げも減りますみたいな話が基本なのかなと思ってて、
その事業、エンジニアリングでビジネスをするっていう前提に立つんであれば、それが基本かなと思ってて、
そうなった時に結構、じゃあなんかそのなんだろうな、
一つあるグラフとしては、そのシステムでそのまま続けていった時に、一人当たりの生産性がどんな傾きで下がっていくのかみたいな話があるはずで、
まあなんか何でしょうね、何て言うんだっけ、線グラフ、なんか横軸時間、縦軸を生産性にした時に、
なんかその線グラフがどんな経緯で下がっていくのかみたいな、なんか緩やかに落ちていっているのか、
もうなんか来年、例えばエンジニアを増やしたタイミングでガンって落ちますなのか、
なんかそういうグラフがあって、そのグラフは多分ソフトウェアとか組織によって全然バラバラで、
それを明らかにした上で、じゃあこのタイミングまでにやらないと生産性が落ちるよねとか、生産性がこのラインを割るのはもう事業的にリスクだから、
もうこのタイミングがデッドラインだよね、みたいな感じで締め切りを決めるしかない、締め切り?寿命か、寿命を決めるしかないのかなっていう気は、
考えたりしてた。
でもその生産性が落ちるっていうのはさ、もちろん僕は分かっているんだけど、
現実的に言いにその生産性のグラフみたいなのを書いた時って、傾きは最初ある程度傾きはあるんだけど、
だんだんだんだんだんそれが緩くなる、まあ下に向くことはあんまり想像できないけど、緩くなっていくのはそうだと思うんだけど、
どうしてエンジニアの一人当たりの生産性が落ちるんだろうっていう。
いい質問ですね。
まあでもめっちゃいろんな、だからそれもちょっとオフラインでマインドマップ書きたいんだけど、
18:05
なんかめちゃくちゃいろいろあるよね。
これはもうだから一概に言えないって言ったらまあそれまでなんだけど、
これを聞いてくださっているリスナーの皆さんと問題を共有するために、
書いてみてみるっていうのがいいかなと思っていて。
僕は二つ切り口ある、パッと思いつく範囲だとあると思ってて、一つは技術的な切り口と、
もう一つはなんかその開発するチーム体制の切り口があって、
技術的な切り口としては、例えば一番わかりやすいのは、
いやわかんねえな、ちょっと思いつくままにしゃべるわ、思いつくままにバッて散らかして、
タテシに整理してもらおうっていう。
突然の無茶ぶりをするんだけど、
例えば利用している技術アセットがソフトウェア界隈の中で相対的に古くなっていくことがまず一つ。
相対的に古くなると何が起きるかっていうと、利用者数がどんどん減っていくから、
知見がインターネット上からどんどん減っていくとか、
利用者が減っていくことでそもそもサポートがどんどん薄くなっていくみたいなところで、
自分たちがOSSを利用してるっていう前提に立つのであれば、
そのOSSの集合値みたいなのに依存してたところがあんまり依存できなくなっていって、
自分たちがやらなきゃいけないことが増えるみたいなところもあるだろうし、
あとは何だろうな、
あとは多分そのソフトウェアが届けたい価値みたいなところが変化する、もしくは拡大するみたいなのも一つある気がしていて、
例えば、そのソフトウェアを作り始めて1年間の間は機能がそんなに多くなくてシンプルでしたみたいな。
弊社で例えると、もしECサイトを作ってるんであれば、カート機能を検索購入だけあればいいみたいな状況で、
商品数も1万件程度ですみたいな感じだったら、この技術選定とこのデザインでいきたいよねっていうものが、
ある日じゃあ、例えばそれは野菜を扱ってたECサイトだけどお菓子も扱えるようにしてくださいみたいになって、
仕様がちょっと複雑になるとか、あとはその事業を水平展開しようみたいなんで、ECサイトに誰でも出品できるようにしましょうみたいな、
某フリマサイトみたいになってきちゃったけど、そういうふうに別の機能を大きく付け出しましょうみたいなところに対して、
一番最初に採用した技術的意思決定を当て込もうとすると、多分想定と違うものがどんどん入ってきて無理が出てくるみたいな。
21:05
これ技術的側面ではないか?事業的側面かな?まあまあまあまあ、みたいなのがパッと思いつくところではありそう。
一方で組織的な側面のところで言うと、分かりやすいのは、事業とか何かしを拡大するためにエンジニアをいっぱい増やそうとか、
あとは例えば今までは12エンジニア1チームで1つのソースコードを面倒見てたのを、
15人エンジニアになって555で3チームに分けようみたいになった時に、
アーキテクチャとかにと、開発チーム側がマッチしなくてセンサー性が落ちるみたいなのも全然あるかなという気がする。
分かりやすいのだと、よくモノリスで1ソースコードを12人で見る分にはいいけど、
3チームで見ると、その3チーム間でコンフリクトが発生して、その調整で結局日が暮れるみたいなこととかは、
アーキテクチャで解決した方がいいよねみたいなところかな、思いつくところだと。
どうでしたろう。
まあそうですね、純粋に技術が伝わっていくっていう話と、
デリバースするソフトウェアの価値、中身が変わるっていう話と、
あとはその事業拡大のための組織の話っていう3つの側面の話があるんだけど、
技術的に使っているライブラリが古くなるとかっていうのはちょっと特殊例だけども、
それ以外は実は根本に共通するものはあると思っていて、
例えば提供しているプロダクトの価値が変化するとか、
事業拡大するっていうのは、
割とソフトウェアの成長を、それは自然的な成長に身を任せるんじゃなくて、
外側から組織に人間が手を加えることによってドライブさせようという、
そういう力学だから、既存の使っている技術とかアーキテクチャの自然に働く重力みたいなものに逆らって、
何か別な方向に動かそうという動かし方なので、それは壊れるよねっていう話も想像ができて。
なるほどね、確かに。
でも個人的に、まだいろんな会社の動きを見て踏み落ちてないのは、
何で事業拡大をするためにエンジニアを増やさなきゃいけないんだっけというところにあって、
ソフトウェアエンジニアなど誰しもが知っている隣月の神話というのがあって、
エンジニアを大量に突っ込んだところで、生産性は先期増加しないっていうのはもう目に見えてわかってるじゃないですか。
24:07
さっきのグラフの話で、人入れれば入れるほど生産性は落ちるという話になってしまうんだけど、
何で生産性が落ちるほどエンジニアをいっぱい取ってしまうのかという組織的な課題も多分あるし、
チーム構造、もちろん1マネージャーに対してマネジメントできる人数っていうのは限界があるというのはもうわかっている話なので、
チームもいっぱいできてしまうんだけど、チームがいっぱいできるということはチーム間のコミュニケーションの問題を考えなきゃいけないし、
もちろんモノイスの話で言うと、モノイスの話はマイクロサービスアーキテクチャに対抗するようなものの話だからちょっと難しいところはあるけど、
端的に言うとコードベースが大きくなって全体像を把握している人の数がはるかに少なくなるというところで、
何が言いたいかというと、そんなに何でやたらめったらエンジニアをいっぱい取らなきゃいけないのかという話なんですよね。
なるほどね。いやー、その話します。弊社絶賛採用中なんで。
数多くのみなさんソフトウェアエンジニアを欲しいと言っているところで、僕自身はそんなに、もちろん大きい組織にいたこともあって、
そういう組織企画が働くような場所に今もいますけどもちろんね。なんだけどエンジニアがいっぱいいて良かったねと思ったことってあんまりなくて、
しかって言うと関義で目の届く領域がどんどんどんどん狭まっちゃって、それは専門性が発揮できるっていう意味では良いことなんだけど、
フラッグと成長させるために潜む問題を検知しにくくなるなというので、どうなんですかっていう。
そうね、これに関しては僕1月から、今年1月からエンジニアマネージャーかな、マネージャーとして働いてて、
で、ある程度その実際のチームの動きと事業をアラインさせるみたいなところに一定の責任を持っているので、
チームの動きを考えたりとか、採用のことを考えたりとか、あとはチームと採用と、
あとはあれか、目指すべきチーム像みたいなところを考える機会が増えて、結構なんか話せる、
自分の中で結構きれいに整理されてるなっていう領域なんで、その中身を開示するとですね、
いやー、でもロジックとしてはシンプルで、なんか事業、多分、
27:01
いやー、なんか世知辛いというか、なんかめちゃくちゃ難しいなとか、難しいし、戦国の世の中だなと思ってるのは、
その事業のチャンスみたいなのがあったときに、そこに対して切り込んでいって、今各種スタートアップとか、
スタートアップでなくてもいろんな企業は戦ってると思うんですけど、その企業たちは常に厳しい競争環境に晒されているっていうのもそうだし、
あとはその事業チャンス自体がいつまで続くかわかんないみたいな前提があって、それがめっちゃ難しいなと思ってて、
なんで、うちの会社とかも、何だろうな、今は多分、スタートアップ的には上手くいってるけど、
じゃあ、なんかその同じスピードで5年間やったときに勝てるかで言うと、まあ明確にノーだよねって話をしてて、
それはなぜかっていうと、めちゃくちゃ資本を持ってる別の大きい会社が同じスキームで参入してきたときに本当に勝てるんだっけっていうところとか、
あとは別にその競合が動かなかったとしても、その事業、僕たちが相手してるお客さんたちがいつまで僕たちの事業に興味を持ち続けてくれてるかみたいなところとか、
別の選択肢を取らないかみたいな変数もあって、なんでそういうところを加味して、多分各会社を意識しているのかなと思っていますと、少なくともうちの会社はそう。
で、そうなったときにそっから逆算すると、じゃあなんか1年後はプロダクターこうあってほしい、3年後はこうあってほしい、5年後はこうあってほしいみたいなのがうっすら出てきていて、
で、もちろんレバレッジはあるというか、代わり売るんだけど、まあそういうのが出てきて、じゃあそれを作る組織体制みたいなのを逆算したときに現状とのギャップがめちゃくちゃ大きいっていうのが多分どの会社でも起きていることかなという整理。
で、じゃあそのギャップを埋めるときにいくつかアプローチがあって、1つは一番最初に多分どの会社も絶対取るべきなのは1人当たりの生産性を最大化できないんだっけっていうのがまず初手だと思っていて、
それはなんか、それこそ人を増やすっていうのは基本的には増やすこと自体はソリューションにはなり得ないから、
増やした人の生産性が0.3になったら、3人雇ったらやっと1みたいな状況なんで、今いる人たちの生産性って今どうなんだっけっていう、
分析とか整理とか、分析した上でそれが1になっていないんだればどうしたら1に近づけられるのかみたいな話と、
それじゃあ仮に今いるメンバーが全員1になったときに、さっき描いたその事業ロードマップみたいなのを達成できますかっていうときに、
そのギャップが埋まらないんであれば、初めて拡大を考えなきゃいけないのかなっていう整理を僕の頭ではしております。
で、難しいのは、ギタティ氏が言った、じゃあ人増やしたらそのまま生産性上がるかというと絶対にそうではなくて、
増やす前提の組織に進化させていかないと下がるし、あとはチーム分ければいいじゃんみたいな話とかでも、じゃあチーム間のコミュニケーションで結局コスト増えますよねみたいなとこもあるから、
30:15
じゃあそのあたりも解決した最強のチーム体制、最強のチーム体制とそのチーム体制で取り組めるアーキテクチャーをまずはきちんとデザインして、
それと現状とのギャップを換算して採用を頑張りましょうって各社頑張ってるのかなって思ってます。各社、弊社。
そもそもさ、さっき大手が資本を持って参入してきたらスタートアップは果てないという話があったんだけど、
でもそれでもスタートアップ側が描く理想って結局人数をある程度集めてプロシティを出すみたいなことが前提にロードマップが組まれるじゃない。
どう、それで言うとなんかそうじゃない気はしていて、多分人数を増やした上でここにたどり着きたいじゃなくて、
事業的にこのタイミングでここにたどり着いていかなきゃいけないっていうのが基本的には先にあると思う。
で、それを達成するために組織を拡大するかしないかの選択を迫られて、拡大を迫られるっていうのが実態かなっていう気はしてる。
そう、大体なんかそのさ、過去のいろんなスタートアップで見てきたのって、数年後は利益こんくらい、ユーザー数こんくらいみたいなものは目標として一応定義されるんだけど、
そこからブレイクダウンされる形で採用計画なるものが設定されてですね。
例えば、iOSエンジニアが今3,4人しかいないけども、1年、3年後くらいには20人くらいにしたいですみたいな計画を普通に出してくるんだけど、
そんな現実的にiOSエンジニア20人いたところで、プロダクト何作るんですかっていう話にしかならなくて、
そういう、あんまり現実的じゃない計画っていうのがどうしても落ちてきちゃって、
そこの裏側にあるのって、やっぱり人数がある程度いないと、ペロシーが出ない、攻撃が安定しないみたいなところが多分、
ある種の恐怖としてあるんだろうなというのが経験なんだけど。
なんか、いやー、そうだね。いや、それで言うと、いやー、決して特定の企業の話をしてるわけでは本当にないんだけど、本当にない。
たまたま刺さったらごめんなんだけど、それで言うと、エンジニアがそう感じ、現場のエンジニアがそんないらんやろとか、
そんだけ取っても無駄でしょって思っている採用計画が進んでる企業は、なんか何かをミスってる企業はなんとなくする。
33:08
それは、例えば採用計画を、例えば経営からのトップ、経営からのトップダウンで決めているかつ経営メンバーに、
例えば技術的なアーキテクチャを考えられる人がいないとか、もしくは十分な議論がされてないみたいなときに、
そのギャップが起きるのかなって気がしていて、
最近、少しだけ話題を変えると、弊社内でチームトポロジーっていう本が有名な本があるんですけど、それの輪読会をしたんですよ。
僕も読みました。
読みましたか、じゃあもう話が早いですね。
何らかに、僕も恥ずかしがりながら、そのときまで読んだことはなかったんですけど、
頭で、感覚では分かってたけど、いい言語家だなと思った一文としてあったのは、
チームとか組織を設計するメンバーは、システムを理解してる人間でなければいけないみたいな話があって、
それはなぜかっていうと、システムに取り組むのは組織であって、その組織の形がどういう形であるべきかっていうのは、システムがどういう形であるべきなのかっていうのとほぼ同義。
だからシステムを理解してない奴が組織を設計しても、ギャップが生まれるだけみたいな話があって、
それが普通に起きると、よく分かんない採用計画になったり、採用計画があっても、それが何かどこを目指して、
例えばこういう組織図を目指してて、こういうふうに計算していくと何人足りないから何人取りますみたいな、説明責任をボードメンバーがきちんと果たしてないみたいな。
ところが、あるよねっていう、知らんけど、世の会社にありそうだったりな、なさそうだったり。
いや、なんかね、今のセリフはね、今日のテーマを総括するのにとてもいいステップメントだと思っていて、
結局その運用のことまで思いを馳せて技術選定ができないっていうのは、結局運用の経験に乏しいっていうことに尽きるんだよ、だと思っていて、
今の組織を設計運用できる人は、そのシステムを理解してる人っていうのと全く同じ形ですね。
技術選定って今の、今日の話からするとすごくミクロな内容になっちゃったけど、
結局先のことが見える人って先を経験した人だけなんだよなっていうところでかなり踏み落ちる話なんじゃないかなっていうね。
確かに。いや、めっちゃ綺麗に詰まった。
順調にスコープを拡大していって、最後キュッて詰まった。
なるほどね。いやでも確かに、そうだね。運用も一緒だね、確かに。運用したことない奴に運用できるアプリケーション作れるわけないよな。
36:05
そう。
リサーチはできるだろうけど。
なるほどね。
で、まあ組織も技術もそうだけど、そこまで達してる人ってものすごく少ないんだよね。
うんうんうん、そうだね。
最初の一歩を踏み出すのはとても簡単な話ではあるんだけど、その一歩を進められ続ける人っていうのは、僕もそんなにそこは自信がないというか、
一つのアプリケーションを5年10年運用していたわけではないので、じゃあ今やってるものが5年10年経った時に何が起こるのかっていうのは、
やっぱり予測不能なところがたくさんあるところなんだけど、それをどうやって精度高く推測していくかっていうのは、
いろんなやり方がきっとあるんだろうなとは思っていて、
今日の話を振り返っていくと、やっぱり技術をどうやって選んでいくのかというのと、
まあ、ハイアリスタでも含めて見極めていくっていうのと、そのプロダクトの提供する価値を定期的に見直していくっていうのと、
その組織構造をどう柔軟に変えられるものにしておくかっていうふうな話なんだろうなと、
まとめてみたけど別に何も特殊なことは言ってないんだけども。
いや、でも大事ですよ。いや、現実はね、そんな別に銀の段階ないんでね、こんなもんっていうか、いやでもめちゃくちゃいい整理だと思うな。
確かに。テーマとして取り扱うかわかんないけど、その技術選定みたいなところだと、かつてティーワダさんが、スライダーの名前忘れたけど、
技術の選定眼を磨く、ん?技術選定の神秘眼を磨くみたいな発表昔されていて、そのあたりの話とか機会あればしてみてもいいかもしれない。
そうね、ティーワダさんの質とスピードという、毎年いろんなところでやってるテストの話もあるんだけどもね、あれもすごくいいよね。
品質とスピードはトレードオフではないという、しっかりとやってくれるいいスライドもあるので。
もう全エンジニアが愚直にこれをね、いろんな会社に布教していくことで、みんなでいい世界を作っていきたいなぁ。
そうね、今日の話はどうしてもそのスピード、あの事業の成長っていうところでスピードにフォーカスが当たっていたけど、まあ本質的に我々が担保すべきっていうのは品質の話なので、それをどうやってその事業の成長に合わせて品質を維持し続けられるか、あの向上させていけるかというのもまあいいテーマな気がするので、どこかで扱えるといいですね。
39:07
よいしょ。いやー、めっちゃ綺麗にまとまったなぁ、なんか。
まとまった。
うん、途中何のテーマか。
チームトボロジーの例が良かったよ。
あのセリフ、この一言はね、禁言だなと思ったんですよね。みなさん、読んでない人はみんな読んでほしいな。
あの本はね、あれを申し入れするのはちょっと難しいというか、そういう組織規模に立っていない会社がいっぱいあるので難しいとは思うんだけども、書いてあることは割と納得感があるので、読んだ上で批判をすると良さそう。
良さそう。はい、じゃあ今日はDMはいらないけど、チームトボロジーをみなさん読んできてくださいって感じですね。
今日はいらないんだね。
いや、全然待ってますよ。もうね、一件も来てないですけどね。
まあでも感想はちょいちょいいただいてて、ツイートとかも実はめっちゃエゴサしてるんで、まあ感想はよろしくどうぞって感じです。
毎日エゴサしてます。
毎日エゴサしてます。気にしーなんでね。
今日はそんなところですかね。
運用、運用、まあタイトルは後で考えよう。まあ運用についてとか組織についてとか、まあいろいろ思いを馳せた回でした。
それではさようなら。
さようなら。
