00:00
こんにちは。言語化.fmは、あんな話やこんな話を、きりんとだての2人でゆるく話しながら言語化を試みるポッドキャストです。
というわけで、今回のテーマは、組織もプロダクトも歳を取るのではという仮説について言語化をしたいです。
お願いします。お願いします。お願いします。
はい。これはどういうことだってばよ。最初からぶん投げるか。
はい。私が書いたやつなんですけど。あのですね。何から話せばいいんだろうね。
いいよ。思いついたままに話そう。
思いついたままに。そういうfmでしたね。これはね。
そういうfmなんで。
なんというか、あれですよね。プロダクトって結局、我々人間が作ってるものなんですけど、
長くやってるプロダクトって、技術面っていうところから見ると、やっぱり最近の、
枯れていてよりベターな技術を使っているかっていうと、多分そうはなってないことが多いと思っていて、
それはリプレイスするのにすごくコストがかかったりとか、やっぱり乗り換えるほどのメリットが見出せてないとか、
あとは単純に中にいる人たちの感度が鈍くって、そこに至ってないみたいな話とか、いろいろあると思うんですけど、
プロダクトを作ってるのも人間なので、やっぱりそういう進化が鈍くなってくるっていう風に考えてくると、
それはやっぱり中にいる人間の成長というか、そういうことをやっていこうっていう欲が弱まってるということで、やっぱり組織も年をとっているのではないのかなっていう風に考えることがやっぱりふとあるんですけど、
なんかその辺ってどうなんだろうねっていうのを深掘っていけると、何か見えてくるのではないかなかろうかという提案というか、仮説というかです。
たしかに、でも直感的にはそのロジックになってそうな気がするよね。
そうだね。
なんかそういう風に感じた経験ってあります?
なんかパッとは思いつかないけど、私ごとですけど、僕が今年30になったんですけど、
ありがとうございます。
あ、ありがとうございます。
4月にミソジュへ向かいました。
で、なんかその、自分個人に焦点を当てたときに、なんか感覚的に強い意思を持ってないとそうなる、今回立った仮説みたいになるなという気持ちは正直あって、
まぁどうだろうな、わかんない。なんか若いからだったのか、その経験レベルが浅いからなのかの切り分けできてないけど、
03:02
その社会人1年目とか2年目とか3年目とかのときは、なんだろうな、見てるシステムが別にレガシーだろうと古かろうと、結構意欲があって、
まぁなんだろうね、わかんない、僕の新卒の当時だったら、JQuery古いバージョンで回ってるとこにリアクト使いましょうよみたいな感じでプロダクション投入頑張ってやるみたいな、
気持ちがすごい前のめりにあったんだけど、なんか今は、今も、今はないわけじゃないけど、ないわけじゃないし、考えとしては持ってるし、
そのあるべき姿を目指すっていうハウとしては手札として常に持ってるけど、でも結構強い気持ちで持たないと、流されそうな自分も正直いるなっていう感覚はある、なんか。
それなんでなんだろうな、なんでかわかんないけど、うん、だからなんかこの気持ちに流されて、組織のメンバーがみんなこの気持ちに流されたら、まぁなんか動いてるしいいよねみたいな、なんのかな。
そう、だから人間は年を取るって言い方をしてしまったけど、最初に組織って言い方をしたのは多分そういう話で、多分中にはそういうことをやりたいウイルを持った人はいるんだけど、組織の文化というか、状態的にやっぱそういうことに対してちょっと何というか躊躇してしまうというか、
それがこう続いてしまって結局そういった技術の刷新が進まないみたいな。
で、その例えばそのNode.jsのサポートバージョンが、加減がここになるから上げましょうよって言って、ちょっと消極的なバージョンアップを繰り返すみたいなことになりがちみたいなのはあると思うんだよね。
で、話しながら年を取るって言ってしまったけど、これも別に、じゃあ年を取った人がそういうことをやらないかっていうと別にそういう意味ではなくて、他の周りにもいっぱい年上でそういうことをバリバリやってる人というのは実際にいるので、
年を取ったからそういうことに疎くなるという話ではないというのはちょっと入れておかないとネットが荒れるんで一応言っておきますけど。
大丈夫ですよ。
何だろうね、そういう力学があるよね。
僕の場合だと割と、例えばOSSをメンテナンスとかしてるとよく分かる話だけど、
本的にそういうバージョンアップみたいなものっていうのは新機能が追加されることもあるけど、もちろん破壊的な変更もあるんだけど、それよりは上がってる不具合を直してパッチを当てた方がいいよっていうバージョンの方が多いわけだから、
06:09
本的には積極的に取り入れるで問題ないと思ってるんですよ。もちろん何も考えずに入れるんじゃなくてリリースノート見たりとかコード読んだりとかしてるんですけど、そういうことはやって当たり前だと思ってるから、
そういうのがなされてないプロダクトを見ると、なんでこれで停滞しちゃってるんだろうっていうふうに考えることが多いんですよね。
なるほどね、なるほど。
なんか話聞いたりしながら思ったのは、そうだな、歳をとるというか、時間軸が相関はしてるものの、プロダクトの規模とかが大きくなった時に、
新しいものをガンガン入れるとか、細かく細かくアップデートしていくみたいなものをしづらくなる引力が必然的に働くっていう話はありそうかなという気がした。
その引力に多分意識的に逆らわないと、どんどん停滞してしまうみたいなのはある気はする。
それはあるよね、組織規模が大きくなって、プロダクトを作るチームが2つとかのやつになったりとか、そもそも作るプロダクトが増えたりすると、
自分の目の届かない容器っていうのが絶対に出てきて、そこで何がなされているかっていう意思決定とか議論のプロセスっていうのは絶対に終えなくなるので、
そうすると口が出せなくなって、いよいよ組織が大きくなってきた時に、ようやく組織横断で見るチームが必要だとなって、
そういった基盤って言われたりしますけど、プロダクトに共通するところの何がしをお世話する人が出てきて、
こんなに使ってる技術スタックもバージョン管理もバラバラだったらやってらんねーよなって言って、
外の枝先にも何となくいろんなところで見てる気がするんですけど。
あるあるやな。
なんか、そうだね、いやでもその通りだと思う。
だからなんか、たぶんその、プロダクトの巨大化に伴って発生する引力に逆らえてる組織と逆らえてない組織の差分は、
なんか個人的には、ある程度予見、予見プラス細かく細かく発生した一周に対して、きちんと手を打ててるかみたいなのが一つあって、
で、その手をきちんと打てる組織がどうかの差分は、まあでもいろいろあるね。いろいろあるんで、これですって一通り横断してしまうのはリスクなんだけど、
大きく一つありそうだなって個人的に思うのは、会社とか組織とかチームの上位レイヤーがそれに対してどんだけ理解をしてるかみたいなのは結構ある気はする。
09:07
どこの会社の話でもないし、例え話としてめちゃくちゃ極端なシナリオを出すと、
経営メンバーにエンジニアがいなくて、初期メンバーエンジニアがいて、
プロダクトちっちゃい頃にゴリゴリゴリ言って、動くものを作り上げて、爆速で開発してリリースしましたみたいな。
で、いいじゃんみたいな、うちのチーム優秀で爆速で作って、じゃあどんどん人増やして、10人が100人、100人が200人ってなっていって、
プロダクトも成長させていくんだけど、そこで、例えば人数が増え、人月の神話を知らないとか、
同じプロダクトに同じメンバーで取り組んでいる場合でも、そうすることが大きくなったら認知負荷が上がって、生産性が下がるみたいな。
それは人間の努力とかじゃどうしようもなくて、きちんと明確に一定のリソースを支えて投資をしなきゃいけないみたいなことを、
分かる人が経営層にいない、もしくは分かる人が会社の課題としてきちんとレイズしなかったら、スピードは鈍化していくし、
そこに対してなんで鈍化すんねん、バーサーズ、いやいやみたいな争いがあったりなかったりする会社もあるよね、みたいな感じで。
知らないけど。
知らない世界の会社の話だとしましょうよ。
でも今の話はあれだよね、最初からそれができるかっていうとそれは絶対的に優先順位が間違っていて、
そのプロダクトを成長させるってことはまず市場命題としてあるので、それはプロダクトがヒットしないとどんなに優秀な技術スタックが揃っていても意味がないので、
まずそっちに力を入れましょうっていうのは正しい、1-0-0-1の話じゃなくて、バランス的にはそっちに偏りがちっていうのはそれはいい話だし、
プロダクトプロダクトの成長が急に始まるとどんどん追いつかなくなってっていうのもあるんだろうから、それは多分正しくて、
だからタイミングの話なんだよね、どのタイミングでそういったところにメスを入れるかっていうのを言えるか、それは多分いろんな経営リソースを見ながらの話だし、話だと思うけど、
儲かってるかっていうのが一番大きなファクターにはあると思っていて、儲かるから人が採用できて、
人が潤沢にいるので、そういったところに人を抑えてもプロダクトの成長には影響はないみたいな、影響はないことはないんだけど、ある程度無視できるというか、
むしろそういう投資をした方が命の判断が大きいよねって判断できて、こうできるんだったらそれは多分素晴らしい判断なんだと思うっていうか、
12:01
多分そのタイミングでそれを言い出すと、まだ別にやらなくていいんじゃないみたいな反対勢力がエンジンや非エンジンが問わず現れ出すと思うんだけど、
そういったところを打ち勝って、今投資しないと後で取り返しのつかないことになるからといって、それを判断できる組織があるとしたらそれは相当に素晴らしいことだと言えるんだけど、
大体の組織はそうは言ってなくて、気づいた頃にはもうすごいことになっていて、何とかもうだから借金を抱えている状態になってしまっていて、最初から作っても借金はあるんだけど、結構それが利息が溜まってしまって、
返すのに一定のコストを払わなければいけないという状態になっていて、そのタイミングで強い人たちが、その頃にはお金がいっぱいあるので強い人たちは雇えるんだけど、強い人たちはまず利息分含めた借金を返すというところから考え始めなきゃいけないっていうのが、いろんな現場で起きている話だと思いますよね。
なるほどね。その意思決定するのすげえ、なんかベストアンサーあんのかな?ない気がするな。
そういう意思決定は、もちろん合理的な判断はするんだろうけど、うまくいくかどうかはわかんないという状態で走るんだろうね。それをやったからといって、定量的に測れる数字で出てくるかはちょっとわからないみたいな。
そうだね、いやー難しいな。なんかちょっと全く宣伝とか自慢とかじゃないんですけど、僕の会社が今とっているアプローチは一つの答えになる気がしているんで、ちょっと話すと、そうだね、ちゃんと考えながらしゃべるんでまとまってないんですが、
単的に今の状況を言うと、3ヶ月前から既存の膨らみすぎた、膨らんだシステムでこのままだと同じスピードで走れないっていうのが、誰かが言い出さなくてもなんとなくわかるじゃん、コート触ってる人とかが。
で、みんななんとなくわかってて、でも走れんくもないみたいな状況だったんだけど、そこに対して3ヶ月前に会社としてリソースを一定割いて、次のアルビック形ってなんだっけっていうのをきちんと考えるプロジェクトみたいなのをテンポラリーで立てて、
来月から新体制になるんだけど、そのテンポラリーなプロジェクトを一つの正式なチームとしてリソースを当てるっていう意思決定をしたんですよ。
で、これはなんかそのこのタイミングがベストだったかどうかは、中に人しかわかんないし、たぶん5年後とかしか、1年後、2年後にわかる、なんかもっと早ければよかったとかベストだったというのはわかんないんだけど、個人的にはなんか全然手遅れの3歩4歩手前ぐらいで意思決定できてるじゃないかなって裸笑って、じゃあなんでその意思決定できたんだろうなっていうことを考えると、
15:17
なんかその技術的な話は基本的には、その状況分析とか意思決定のトップに来ることっていうのは基本的にはなくて、一番最初に事業があるんですよ。事業があって、5年後にこうなりたいみたいなのがあって、じゃあ3年後こうなりたい、1年後こうならなきゃいけない、じゃあ半年後これをできなきゃいけないみたいな、
ブレイクダウンをして、それとビーズデブチームとエンジニアリングチームとPDMとかデザイナーとかプロダクトチームとCSの対戦みたいなののギャップを洗い出していったら、他のチームも多分いろいろギャップがあるけど、エンジニアリングチームはそもそもなんか、じゃあ半年後これできますかって聞かれて、できませんって今は答えなきゃいけない、じゃあなんでかって分析していくと、
ソースコードが古いだけが原因じゃないけど、それも大きな一因となって、達成できないみたいな、達成できないってなった時に多分いろいろあって、人を増やせば、
まあ、いや、えっとね、うわ、言語化頑張りたい、うちの会社よくレバーを引くって表現するんですけど、引けるレバーめちゃくちゃ無限にあると思うんだよ、どの会社もそうだと思うんだけど、例えばシンプルに人員を増やすとか、極端な例だと開発委託会社にめちゃくちゃ金を払ってリソースを増やしてどうにかするとか、
ソースコードにきちんと投資して根本的に直すとか、もしくは今言ったような手を組み合わせるみたいな、3割これやって、2割これやってみたいな、本当にいろんな意思決定があると思うんだけど、その中でソースコードがやばいっていう、じゃあなんでやばいのかみたいなのを、
まあその経営のレイヤーまでCTOがきちんと説明して、まあ理解を得た上で、じゃあそのレバーを引くのが一番インパクトがでかいし、長期的に見たらいいよねっていう議論ができてたからっていう一つのユースケースというか、まあこの意思決定が本当にベストなのかどうかは、まあ神のみぞ知るだけど、
そういう、それはなんか個人的には一ついい例というか、まあわかんない、将来別の会社の同じようなシチュエーションがあったら、そういう意思決定を促せる偉い人になりたくはないけど、まあ一ついい例だなと。
そうやって多分、どのレバーを引くかっていうのを決める側には少なくとも、そういう技術的な経験もいるから。
なんか聞いてて、そのレバーを引くっていうのは、まあそういうことなんだろうと思いつつも、多分御社にはそういう、そもそもどういうレバーがあって、このレバーを引くとこういうことが起こりますけど、こういった良くないことも起こるかもしれませんっていう、
18:21
メリットデメリットをちゃんと説明して判断させられるような人たちが多分集まってるだろうから、まあ多分そういうのは成り立つなと思うんだけど、
ちまたというか、まあちまたというのは良くないな。他の組織であるのは、やっぱり質の良いレバーを提供できないっていうのはよくあるんだよね。
確かに、あり得るね。
もちろん経営的な判断においてもそういうことはあるだろうし、技術的な判断の方が僕の方はよく目にするけど、複数のレバーを提示して、このレバーを引けばいいですよっていう押し方が多分一番は説得力があると思うんだけど、
もう最初からこのレバーしかないんですっていう、まあそうやって戦略的にやることもあるとは思うんだけど、
1個しか出せないみたいな。で、その1個の質が周りから見たときに、え、それしか本当にないって思わせちゃうみたいな。
あるね。
で、それはちょっとどうなんっていうので、それに対してはもう、経験値も正直影響するから、一概にじゃあたくさん出せばいいんですかって言われるとそういう話じゃなくて、
その質を高めるための何がしをしましょうよって話なんだけど。
いや、確かに。なんかその、いやー、その、この例え話めっちゃなんか話しやすいなと思ってて、その1つしか出せないみたいなパターンもそうだし、
なんか複数出してんのに、まあ質が低いみたいなパターンもそうだし、なんかそういうことすると、なんか起きること、デメリットってめっちゃある気がしていて、
経営が採用されたとしても、いい質の良くないっていうか、質の良くないっていうか、言い方難しいけど、もっとベタな方法あるのにっていう意思決定を取るから、
まあ会社へのインパクトは微妙になったりとか、あとはなんかこういうパターンもあるだろうなと思ったのは、そのレバーを提示したそのエンジニアリングチームとか、
プロアクトチームを経営メンバーが見たときに、いや、うちのプロアクトチームは信頼できないわって言って、なんか信頼を失ってしまうみたいなパターンも全然あると思ってて、
まあそれってすごい悪循環のスタートというか、信頼できないから意思決定させてもらえず、ダメな方向に行っていいメンバーが取れずみたいなパターンに転がっていくパターンも全然あるだろうし、
21:06
その辺はすごい、そういうのを考えるとやっぱいいレバーを作り続けられるチーム作りは大事だし、まあ当たり前のことを言うようだが優秀なメンバーを集め続けるみたいなところもあるし、
またその時の軸としては、同質性が高すぎないメンバーを集めるみたいなのがすごい大事だろうなって気はしてて、同じぐらい優秀な人でも、違う形のビジネスで開発をしたメンバーを集めるとか、違う規模で活躍してきたメンバーを集めるみたいなのがすごい大事なんだろうなっていうのは話しながら思ったわ。
何というか、これをやれば絶対にうまくいくという必勝法ではないんだけど、ダメになっているチームというか、これはちょっとやばいねって感じるチームの多くはやっぱりPMとか経営レイヤーとのコミュニケーションがうまくいってないっていうのはよく見る。
要はエンジニアのチームで、チームを回すことにはやっぱりみんな一生懸命というか、そこはうまくやろうとしてるし、スクラムみたいなノウハウもあるので、そこはできるんだけど、でもそれってそもそも何というか、こういう機能を入れてほしいとか、数字的にこうしたりとかキャンペーンしたりとか、いろんな施策を打ってくるような人たちと、
円滑なコミュニケーションが取れているということが前提だと思うんだよね。
そこがね、実はスクラムぐらい定式化されたノウハウがあんまりない気がしていて、もちろんそっちのレイヤーもうまくそこの仕組みに乗せられるっていうのは、経営レイヤーがそういうことを知っているとか、経験があるとか、そういったのがあるからうまく回るって話なんだけど、
同じ仕組みで回ってるわけじゃないから、なんというかいきなりエンジニアからこういうやり方でいきましょうよって言っても、多分ちょっとアレルギー反応が出ると思うんだよね。
それが出てなくて、いや、これでやった方がプロジェクトが円滑に回ると判断できて、入ってきてくれるそっち側のレイヤーの人がいるんだったら、それは結構うまくいきやすいかなっていうのは思ってるというか、うまくいってるところはそうやってやってたなっていう風な。
たしかに。いやー、そのレイヤーの再現性のあるプロセスとか作れたら妄想できそう。
24:01
いやー、再現性がないんだよね。再現性があったら会社は倒産しないんですよ、多分。
それだけで倒産するとは言わないけど、やっぱりお金はやっぱり一番大きなファクターなんで、それが直接的に絡んでくるか分からないけど、そのさっき言ってた採用とか優秀なメンバーが残り続けてくれるみたいなところは多分そういったコミュニケーションにあるよなっていうのは思ったりしますね。
いやー、その辺の難しさを言語化する回やりたいな。
なんかそのレイヤーに一定近い立場でこの半年間ぐらい働いてて、EM兼リーダーという立場なんでやったんですけど、正直ベース自分がうまくできたかどうかあんま辞任できてないというか、自己評価できてなくて、その原因はいろいろあるんだけど、
なんかこういう形で立ち回るのがベストだよねみたいなベンチマークが自分の中で結構まだなくて、私、難しいんすよ。別の回で話したいわ。
なんか報告するだけならさ、もうマジ別にいらんやんみたいな、中間間食じゃんみたいなただ、いかに自分のチームの具体的なイシューをきちんと抽象化して、その会社の課題なんですよっていうことをいかにきちんと説明するかみたいなのは多分大事だし、
どんどん組織が大きくなったらそれをリレーでやるのか、いろんな方法があると思うけど、これを優秀な人がいればいいようで片付けると会社が倒れそうだから、頑張らなきゃいけない気がするけど。
いやでもさ、我々ぐらいの経験積んでくると、仕事の大半ってそういった抽象化ばっかりじゃないって思うんだけど、そういうエンジニアじゃない人に対して、今やろうとしていることはこういうことなんですって題例を用いながらわかりやすく説明したりとか、
そういった抽象化もあるし、ソースコードレベルでも我々は抽象化ばっかりやってるような気がするんで。
そうだね、汎用的なツール作るぞって言ったら、あっアブストラクトだって。
技術的にはみんな抽象化と共通化を吐き違えてるみたいなところから本当は説明すると面白いんだけど、それはそのFMの範囲を超えるのでちょっとやめておきましょう。
27:01
ツイッターでデュエルしよう。
いやでも確かに、個人的に思うのは抽象化もそうだし、きちんと言語化したい、きちんと言語化したいけどパッと思いついたのは、俯瞰するみたいなのもすごいより求められるなって気はした。
抽象化したイシューが、エンジニアチームの中ではそのイシューってどこに作用するのかとか、結果としてプロダクト全体でどこに作用するのかみたいな。
結論、じゃあ会社から見たときにどこから、どのイシューと紐づいてて、それを解決しなかったらどこに影響してしまうのかみたいな、結構俯瞰をしなきゃいけないみたいなのは一定求められるなという気はしたわ。
そういうのはあるよね。ちょっとワンランク上というか、もう一個ぐらい階級的なものが上がってくると、
多分そのプロダクト全体のイシューの相互関係とか、あとはその会社全体でどういう位置づけなのかっていうのを多分俯瞰してみれないといけないっていうのは今まさに言ってもらった通りかなと思っていて、
その辺の経験ができる人っていうのは結構実は剥げられているので、
そういうチャンスがある場合は、いろいろ経験できて面白いような気がしますね。
確かに。そういう意味で言うと、ありがたい半年間だったな。
そうだよな。なんかその辺も結構むずいね。なんかその、ちょっと話どんどん逸れてった気がするけど、
なんだろうな、ソフトエンジニアとしてリードを張るとか、その実写、プロダクトの運用保証をやるみたいな経験を積ませられる絶対数と、
その一つ上のレイヤーで、テックリーダーなのかエンジニアマネージャーなのかリーダーなのかなんでもいいけど、
そのレイヤーでそのひと回しするみたいな経験をさせてあげられる絶対数って全然違うじゃないですか。
それ結構不合理だわ。不合理中か。理想はその、多分打席に立てる人数どんどん増やした方が、この人実はめちゃくちゃ向いてるみたいな発見確率も上がるし、
組織としても前回の話に通じますけど、俗人化みたいなところとかでもまあまあ傍聴地寄与するんじゃないかと思うけど、
現実はそうじゃないの、絶対数少ないし、あとはなんかありがちなのは元EMが次の会社でもEMになって、
別になんか席を空けないわけじゃないんだけど、プレイヤーがそのレイヤーに行く強制的な理由がなんか多分大きい組織になればなるほど、
生まれづらいとかはある気はしたなぁ。
会社からしたら、プロダクト組織の成長が優先課題になるから、経験者はね、まさにプロ野球の世界と一緒だと思うけど、優秀な選手はどんどんお金積まれてスカウトされて、
30:17
活躍してっていう風になるのはまあそれはそうだと思っていて、
まあ多分その辺と違うのは、ちゃんとそうした人が下の方の育成にも本当はタッチしないと、
自分が抜けた後そのポジションになれる人っていうのをちゃんと入れておかないと、会社のためにはならない。
自分のためになるかはちょっと別問題だけど、育成は基本的にやっぱコストはかかるので。
いやー、なんかこのFM話してるとどんどん目線が天に昇ってく気持ちだわ。
そうなんだよね。
考えるほど。
このFM自体が、話してるとね、どんどんこのFMが抽象化されていくっていう。
なんか実は会社を作るのって、すごいイケてる会社作るのって難しいよねを言語化するをもう十何回重ねて話してるみたいな気持ちになってきて。
いやまあそうだよね。
詰まるところ。
いやー、でも難しいな。
まあでもなんていうか、ちょっと考えても思いつくようなことはやっぱみんなやろうとしてるわけだし、聞いてる人は分かるそうなんだよなっていう人たちがきっと多いことを信じているので。
いきなり強引に元の話題に立ち戻ると、年を取るって言い方はあれだけど、やっぱり組織もプロダクトも健全な状態を位置し続けるためには、
だからそういう、俯瞰して組織のことを見たりとか、プロダクトの位置づけがどこにあるかとか、そういったことを考えられるように癖をつけておくというのがきっと必要だろうね。
うん、そうだよね。
あとは、より良い意思決定を複数提供し続ける。
それなんか実はアーキテクチャーでも一緒な気はするけど。
一緒だと思うね。
いかに、そうだね、その話は別でしたいんだよな。
アーキテクチャーの場合はね、ちょっとなんていうか、考えることはまた違うんだけど、違うし、
何だろうね、アーキテクチャーは今度一緒、なんか下手なことを言いたくないっていう。
そうだよ。
33:01
例がわかっているんだけど。
次回、いつかのお楽しみにしよう。
いつかの、はい。
あとアーキテクチャーの、終わらせないんかって感じなんだけど、アーキテクチャーのレバーを用意する話と、
組織的なレバーを用意する話、サブみたいなのもなんか、
頭の中でバーッと考えたらある気がしたから、その辺もその時にできたら嬉しい。
なんかそれで言うと、この場で言っておけばいいのは、
相手によって提示するレバーが変わるっていうのは絶対なくて、
チームメンバーに提示するものと、
それを抽象化するのがまさにマネージャーレイヤーの仕事だと思ってるんだけど、
そこでの判断を持って、
別の会議体に対して、会議体というか、別のもっと上のレイヤーの人たちに対してレバーを提供して、
下ではこういうふうに言ってますけど、どう思いますっていうことをやるっていうのが、
どうしても中間管理職の仕事みたいになっちゃうよね。
確かに。
あとなんかちょっとアーキテクチャーと違うなって思ったのは、
この半年間思い返してみてってのもあるけど、
アーキテクチャーと違う方は話しすぎないようにしますけど、
正直場合あったときに、
ざっくりいい意思決定だよねっていうのは、産業を書き換えて、
少し進化させて、他のとこいじる余地を残すパターンの方が、
フレーマーク全部こっそり入れ替えて、いいアーキテクチャーにしましょうっていうのよりは、
いやーちょっと踏み込みたくない。
まあいい。
でも何にせよ、
デバーの質を高めるためのコツというか、
やったらいいことは、
頭で考えたことを出すだけじゃなくて、
手を動かしたものを出してみるっていうところだよね。
そうだね、そういうのはあるかも。
それは両方共通してる。
ごめんごめん。
ただなんか難しいなと思ったのは、JoyLayerのときは、
ソフトウェアの向き変え方で何回か取ったアプローチとしては、
まずは小さく始めるみたいな。
ちっちゃく始めて、うまくいったら大きく回すみたいなパターンを何回か試みたんだけど、
場合によっては、ちっちゃく回してもうまくいかないんだけど、
大きく回さないとインパクトが出ないみたいなパターンがあって、
それはすごい難しいなって思った。
それの差分何なんですかっていう話は、
楽しくないが振り続けるけど。
アーキテクチャーの場合は話すんかいって感じなんですけど、
あれなんだよね、
POCの段階では、
どうしても小さく作って、
比較するより他なくて、
大きくなっちゃうともう分かんなくなるから、
それ作るのに結構コストがかかるから、
36:02
原始的にできなくて、
他の組織でこうやってるからっていうような、
振り返りしかできないんだよね。
他の組織でやってみて、
運用してみて、
うまくいったかどうかって判断するしかなくて、
それがうまくいかなかった場合は結構悲惨なんだけど、
うまくいかなかった場合は、
出戻りができないっていう風になっちゃって、
新しいバージョン作ったのに永久にリリースされない、
みたいな話になっちゃうので、
アーキテクチャの場合はちょっと難しいよね。
そもそものコンセプトも、
要はそのアーキテクチャを提唱した人もそうだし、
これいいですよって持ち込んだ人も、
これがいいよっていう風に言うための、
サンプルプロジェクトを書いても、
例えば極端な話、
アプリだとトゥールアプリみたいなちっちゃいものを作って、
それをMVVMで作りましたみたいなことを言われても、
じゃあそれもっと画面数増えたり、
ビューモデルが増えたらどうなっていくのみたいな話とか、
本当はしなきゃいけないんだけど、できないんだよね。
希望が違いすぎて。
そうか、じゃあアーキテクチャの方も。
いやー、なるほどね。
いろんなパターンあるな。
いや、ちょっとグッドコラよ。
めっちゃしゃべり倒したいね。
僕ら二人ともね、モバイルアーキテクチャの本書いてますので。
いやー、書いてるわー。
モバイルじゃないけど、すいません。
モバイルじゃなかったっけ?
MVVBかな?書いてなかったっけ?
書いた。書いたのはモバイルだけど、
モバイルの人じゃなくてすいませんっていう。
そういうことね。
まあ、書いたトピックはね、
バックエンドもフロントエンドにも通ずる話なんで別にいいですけど。
そうですよね。
いや、懐かしいな。そんなことありましたね。
ありましたね。
まあ、そんな感じで。
さっきせっかくまとめてくれたのに、広げてしまったから。
まあまあ、そういうふうに意思決定をするというか、
意思決定するための材料を出していくっていう、
そういう小さな取り組みが、
組織やプロダクトの改善につながりますよっていう話をしてみました。
イエーイ。これでみんなもう、
いい組織しか、この前分を聞いた人が作る組織はみんな、
全部いい組織になるはず。
いやー、でも一生はないんだよなー。
難しいんだよ、これは。
ダメでしたって人はDMください。
話を聞くだけならできます。
いやー、いい会社作るために引き続き色々話していくか。
いい会社作るためじゃないけど。
39:05
はい、というわけで今回は、
組織もプロダクトも年を取るという仮説について言語化しました。
いい話できたな。
よかったよかった。
次につながるトピックもあったので、
次回話すかは知らんけど、
いつか話すのでお楽しみに。
どうぞよろしくお願いします。
はい、というわけでみなさんさよなら。
さよなら。
