AIの影響とコミュニケーションの変化
きんじょうひでき
チームの力で組織を動かすの話を引き続きやっていきますが、
本の内容をがっつり触って、発売して10日も経ってない本のネタバレばっか食らわすっていうスタイルだと、
あんまり気持ちも良くないし、ちょっとなんかこの本の中で直接書かれてたっていうよりかは、
本の内容を踏まえてこういうことを考えたよとか、何ですかね、本に載ってないところで話したいことをちょっと話していきましょうか、後半は。
げんえい
そうですね。
きんじょうひでき
本に何が載ってなかったですか?
げんえい
やっぱ一番最初はAIじゃないですか。
AIなあ。
この時点においてAIの話をしないわけにはいかないみたいなぐらいみんな本当にAIの話をしてますけど、
AIが出てくることによってチームとか組織みたいな前提がどれぐらい変わっていくんですかねっていうのは、
多分今から予想しても外れるのは外れると思うので、
この本踏まえてどうなっていくのかなみたいなのはちょっとやっぱこの先気になるなあっていうのはちょっと思いましたね。
きんじょうひでき
コミュニケーションの形は変わりますもんね。間違いなく。
げんえい
チームのまずサイズが小さくなるのかなあみたいなことは思ってて、
一人ができることが増えていった時に今まで10人でチームを組んでました。
多いなあコミュニケーション大変だなあと思ってたけど、
いやそれ半分の人人数でできるようになります。
だからチームを分割しましょうみたいなことが起きたりとかして、
そうするとコミュニケーションの取り方コミュニケーションパスは減るだろうし、
そういうところでこうもっともっといいチームを作るっていうことの価値が上がっていったりするのかなあみたいなことを思ったりしてましたね。
チームの分割と採用の見直し
きんじょうひでき
チームを小さくするってことは分割していくからチームの数増えるってことですもんね。
げんえい
そうですねそうですね。
きんじょうひでき
そうするとチームの数増やしたいんだっけってなりますね。
げんえい
ということは採用止め。
きんじょうひでき
採用は止めるんでしょうね。
げんえい
そうですね。
きんじょうひでき
この本読んでる感じだとバリューストリームがそんなに何本もないのにチームの方が数が多いみたいな感じだと変だぜってところですもんね。
げんえい
そうですね。
きんじょうひでき
手が回りきらなかったバリューストリームっていうのを独立させられるかもねえは、
今言った人数あたりのアウトプットが増やせる、もしくはスループットが改善できると生まれるかもしれないのか。
げんえい
そうですね。とか実験的にいろいろ新しいことをやりたいと思ってたけど余裕がなかったところにチームを当てられるようになるとか、
いろいろ試行錯誤したかったことがもっとできるようになっていく。
別にそんなにいろんなやりたいことがないのであればやっぱ採用止めたりとか、
ちっちゃいチームで人数でやっていくぞってなった時に、
どうなんですかね。日本だと人を切ることは難しそうですけどなかなか。
結局海外だとチームごとレイオフしましょうみたいな話とかに多分なっていくんだろうなあみたいな。
ちゃんとチーム単位でやっていく。
この部署廃止みたいな感じになるんじゃないですかねって。
外から見てる海外情報だけを見てるとそういうイメージだなあ。
きんじょうひでき
本の中に書かれてた内容とかなりダイレクトに繋がりそうだなあって思ったのが、
コードレビューとAIの役割
きんじょうひでき
コードのオーナーシップの話あったじゃないですか。
でそのアンチパターンとして誰でも自由に触れるコードっていうのが増えすぎると、
それはそれでちょっと別の問題が起きるかもしれない。
要するにみんなが雑なコードを書いて荒らして一貫性も何もないみたいなコードが
なんか爆誕して悲しくなっちゃう的なアンチパターンが触れられてたと思うんですけど、
誰でも自由に触れるっていう自由の代償としてカオスっていう話でしたよなあ、あの文脈は。
げんえい
そうですねそうですね。
きんじょうひでき
でそのカオスっていうすごい悲しい状態避けるにはオーナーシップを誰かに明確に定義する。
要するに誰かがちゃんと責任を持ってコードレビューして品質を担保するっていうような解法があるよねっていう話も出てたんですけど、
コードレビューをAIが自動化してくれたら内部品質は常に完璧になるので、
オーナーシップのあり方は変わりそうだなあとか今話聞いてて思いましたね。
当然少なくとも今の段階だとAIのコードレビューがそんなめちゃくちゃ完璧ってことはないなっていうのは非常に憧れを持ちつつ絶望もしてるところではあるので、
そんなにうまくいかないんですけど、ただとはいえコードレビューの効率化は絶対進んだなと思うんですよね、実際使ってみて。
今の会社で実際に自分が使ってるやり方理由と、自分とは違うチーム、チームっていうほどじゃないんですけどワンプロダクトの会社なんで、
自分が触ってないではいけない、マシンラーニングだとか組み込みだとかネイティブモバイルアプリだとか、
あそこら辺のコードを読んで、なんか理解して、こういうコードロールを持ってるのみたいなところは探ってくれるようになったので、
なんて言うんですかね、古びく投げやすくなったりはする気がするんですよね。
っていう意味でその、エクロ的なチームっていうバウンダリーを超えたコードのあり方っていうのは加速するかもなあとかっていう気はしました。
げんえい
そうですね、だいぶコード、何やってるかとかはAIに要約させてとか、
なるほど、こういう風に変更していけばいいのねみたいな勘どころが分かったりするまでが早くなったりすると、一気にハードルが下がり、
こういうことを実現したいんだけどって言って、AIが書いてくれて、プルリクも全部AIが予定書いてくれてやってると、
多分影響はすごいしやすくいいですよね。
さっきのコードレビューの話のところも、ある種チームの中で保ちたい品質みたいなのが、
これはすごいデジタル理想って感じですけど、このラインを守ってほしいみたいなのが、言語化うまくできると、
AIがじゃあほとんどそこ見てくれますってなった時に、結構それなりの精度でコードレビューできんじゃねみたいなことは思ったりとかして、
きんじょうひでき
そうですね、このぐらいの水準を言語化できるかっていう。
言語化っていうのは、我々の頭の中にあるもっかりダンプできるかっていう話もあるし、
それと別にAIというか機械が理解できる形に変換できるかっていうのもあるんで、どうすればいいんだろう。
フィットネスファンクションみたいなものをちゃんと用意して、
っていうと大げさだけど、テストカバリッジこのぐらいは維持しつつ、テストはちゃんと通るようにしてねとか、
っていう話はすごいめちゃくちゃ単純化するとありますけど。
げんえい
そうですね、こういう構造になっているんでそれに従って書いてくださいみたいな、もしかしたらそのAIに合わせるような構造みたいなものができ上がるかもしれないですね。
きんじょうひでき
そうですね、道具に合わせて設計変えるのは我々は昔から得意ですからね。
そうですね。
ミニタフルインフラストラクチャーってなったら、多少ローカルに入れるのやめろってすぐできますよね。
げんえい
そういうAIフレンドリーな設計みたいなことは考えられると、こういうことしたいんだけどみたいなことがよりやりやすくなっていくとかは全然ありそうだし、
そうなってくるとどうかっていうかチームを影響しやすくなるっていったときに、さっきの話でいくと機械学習チームとネイティブアップチームと組み込みチームとみたいなのがあったときに、
きんじょうひでき
そういう分け方じゃないとかもっと考えられるようになるんですかね。
エンドツーエンドのチームにしようぜのハードルは多分下がりますよね。
げんえい
なんかでも言ってることはあれなんだよな、なんか専門的な技術の価値が相対的に低くなるみたいな話だから、あれ?失職するのでは?ってなってるんですけど。
きんじょうひでき
だって今までフロントエンド書いてたけどAI使ってたらバックエンドも書けるようになるぞって世界が来るようにって話をしてるので、あれバックエンドエンジニアいらなくない?
げんえい
いやお前もフロントも書けよっていう話でするんですけど。
悲しくなってきたね。
フルサイクルに頑張りましょうみたいな感じなんですよね。
でも本当に出したい価値ってフルサイクルっていうかエンドツーエンドなんだよなって今多分それが一番早く適切に扱えるのが、
じゃあ例えばバックエンドとフロントエンドっていうので切ってみましょうとか、
アプリのチームはアプリのチームにして、そうじゃないチームとアプリのチームを分けましょうとかっていうのが多分今の構造上では最適だからそうなってるっていう感じですね。
っていうようなパラダイムシフトはどこかで起きる可能性はありそうですね。
きんじょうひでき
そうですね。どうなっていくんだろうな。
げんえい
いやでもさっきの。
きんじょうひでき
空得言うと、ストリームラインのざっくり言うとプロダクト側のチームの技術力というか内部品質をそんなに問題にしなくなるのかな。
内部品質大事なんですけど、バグがなくて信頼性が高くて高速、ちゃんと冷停止が低いみたいなシステムを作るのとかあとセキュリティか大事なんですけど、
それって別にプラットフォームチームが担保できれば済むじゃないですか。めちゃくちゃボロいってますけど。
って考えるとプラットフォームが技術力つよつよになってくれたら、あとはAIとそこらへんのミドルぐらいのミドルとジュニアをかけ集めた人たちとAIのチームで少人数フルサイクルなストリームアラインドなチームを作っていけば勝てるのか。
げんえい
アウトプットを増やすという意味では全然いけそうですよね。それが多分求められるフェーズもあると思う。いろんな弾を打ってみてどれが当たるかわからないからアウトプットいっぱい出してみて当たったものを大きくしていきましょうみたいなフェーズにおいては。
それってすごく大事なことだと思うし。って考えるとそういうのは全然ありえそうな感じはしたなーって思いましたね。うまくいくかどうかというのは現実にやってみないとわからないですけど。
きんじょうひでき
現実にやってみないとわからないしAIがどんだけ早く未来になってくれるか次第なところもあるそうですよね。
げんえい
でも5年後ぐらいにはそれなりに今言ったような話のことがだんだんでき始めてるとかできててもおかしくないかもなっていう気はなんとなくしてますね。
きんじょうひでき
絵は描けるようになりましたもんね。プロのイラストレーターから見たら怒られると思うんですけど、同じようなレベルでオタクのパソコン方々君たちは文句言ってるけど十分動くじゃんっていうのがプロンプト2,3乗描くだけで実現されるようになってくると当然ゲームのルールが変わるはず。
げんえい
例えばスタートアップにおいては内部品質とかってよりも実際これがPMFスクアとかが大事だったりするわけで、そういうシチュエーションにおいて内部品質が大事って言ってもそれは大事なんだけどさみたいな状態があるわけだし。
きんじょうひでき
内部品質とか品質特性は別に言うか、内部品質で充実される項目は変わる気しますもんね。
だってレディーズが流行ってきた時にたぶんボロボロじゃないですか、ドキュメントもちゃんと描かないリアルなんてみたいな話と同じことは起きる気しますよね。
げんえい
あとAIを使うってことは人間より安いはずなんで、でなった時にスタートアップとかだとラウエーの期間が長くなるってことは出席に立つ回数を増やせそうとかあったりするし、都合が良いことが多そうだなっていうのは今の話を聞きながらアウトプットを増やすっていうところと関連して思ったりもしましたね。
きんじょうひでき
そうですね、アウトプットを増やさないとアート感が上げづらいですもんね。アートプットっていうかイテレーションを早く回すって感じか。
実験して学習してを細かく素早く回す。だからAIが来るとより強くてイテレーティブなチーム活動が、プロダクト開発の活動ができるようになるっていうことですか?
げんえい
そんな気はしますね。しかもそうなってくるとプロダクトがどんどんサイズがちっちゃい方がやりやすいと思うんですよね、それって。
きんじょうひでき
すごい、なるほど。
組織設計の重要性
げんえい
考えた時にスタートアップの方が有利だよね、後発の方が有利だよねってなっていく中で既存にあるような会社のプロダクトとかって組織設計を考えないといけないし、ストリームアラインドをちゃんと作ってAIがうまく動くように、プロダクト自体がでかいってなった時に結構大変そうだなっていうのを感じましたね、今の話を聞いて。
きんじょうひでき
人をたくさん雇うことを得られてた馬力みたいなものが機械で担保されちゃうってなるとオーバーヘッドだけが目に付くようになるみたいな。
げんえい
マイクロサービスみたいなものが一時期流行った中で依存関係を減らしてそれ単体でデプロイできるんだみたいな話があったけども、それはなかなかやっぱり難しかったんだっていう揺り戻しもあったものの、やっぱりサイズを小さく保ってスピードイテレーションの回数を増やしてってことを考えた時には、
やっぱりマイクロサービスだったりとか、プロダクトとしての結合はあるかもしれないけど、プロダクト単体が一個一個が小さいっていうことが、ユーザーにとって作り勝手がいいかとかちょっとまたあるかもしれないけども、結構それは大事になってくるかもしれないなっていうのをちょっと思ったりしましたね。
結局それが競合とかプロダクトの開発サイクルの早く機能がいろいろ出てくるっていうところが良しとするならば、大事なところになりそうな気がしましたね。
組織サイズを小さく保ってても十分価値を生み出せるようになると、割とこの本に書いてあったことは要らなくなるんだよな。
きんじょうひでき
人が多いと大変だよねっていう前提はある気はしていて、人が多いって言ってる敷地がね、いろいろあると思うんですけど。
例えば10人だと、全体で10人とかしかいなかったら、1チームの数として10人は多いけど、全社で10人だったらチーム分割要請ってならないというか、チームっていう概念を導入しないと思うので。
だからそうすると複数チームある前提の本ではあるじゃないですか、多分。
どうなんだろう。1チームだけでも使えるのか。使えるSSはあるんですけど。
げんえい
この本じゃないと思う。その時に読むべき本は。みたいな感じはありそう。
きんじょうひでき
何チームぐらいの会社、組織からこの本を読んだ方がいいんですかね。
げんえい
どれぐらいなんだろうな。
難しいんだよな。でも頭数でいうと20人とか15人しかいませんっていうのと、スタートアップの意見を保ったまま15人体制ですっていうのは、中身が違う気がするんだよな。
そうですね。たぶん2チーム、3チーム目とかが出てきてコミュニケーションが上手く取れなくなったなって感じるとか、それぐらいからなのかなっていうのは、ぱっと今思い浮かんだのはそれぐらいかなって。
その話めっちゃ面白いな。どういう3チームですかそれは。
それは1チームで機能作ってて、お金が投資があって、もう1チーム、人を増やしてた結果、1チームだとちょっと難しいよなって言って2チームに分けました。
それやった結果、またさらに誤差位を進めていって、もう1チームできました。
きんじょうひでき
やったら1チームの時の感覚でずっと仕事しながらやってたら3チームになったら、あれなんかパスも増えてるし、人も増えてって、結構困りそうみたいななんとなくなイメージですごい喋ってますね。
げんえい
でもどれくらいですかね。3チームぐらいだと会社全体として。
きんじょうひでき
エンジニアで3チームですか。
げんえい
そうですね。開発チームで。
きんじょうひでき
それはでかいな。
げんえい
ってなると50人以上ぐらいですかね、会社として。
きんじょうひでき
そうですね。エンジニアだけで20人前後いますってなると、部署とかっていう概念も会社の中に発生してきたりとか。
げんえい
日から組織設計みたいなことを考えとかないとヤバそうっていうのが、いろんな話を聞いたり見たりしてる感覚。
多分そこがうまくいかなくてゴテゴテになっていくと、人は増えたんだけどミーティング多いなとか、知ってるのはこの1人しかいないからあのチームとあのチームを権利してみたいな。
そういう風にいきそうな気がするなーっていうなんとなくの想像がありますね。
評価制度とチームの成長
げんえい
そうですね。全社50人だとそうか。50人ぐらいの規模でPMFしてればいいんですけど、なんか組織組織みたいなこと言ってる前にやることあんだろうがって感じがしちゃいますよね。
そうなんですよね。
きんじょうひでき
いや、当初元からHR系の人連れてきて、なんかいい感じにやらせといてもらってほしいなそれ。
げんえい
スタートアップが多分今経験した人が新しいスタートアップに入ってとかVPOEとかテクノトップみたいなところに入ってみたいなの人の記事を何個か読んでたりすると、やっぱ評価制度とか早めにちゃんとやっとかないといけないよねとかいう話とかを読んでると、
やっぱりだいたい1週目でみんな組織の成長に言うと評価制度が合わなくなってたりとか、だんだん人が見えなくなっていって、人が増えて見れる範囲が広くなりすぎて、見る範囲が広くなりすぎて一人一人見えなくなっていくみたいなとかあった時とかにやっぱり評価制度だったりとか大事だなって感じた人たちが、
たぶん2週目3週目の中で組織に入ってた中でプロダクトを出していく、機能を出していくってことは大事な一方で、でもこのままスケールするためにはやっぱりそういうところに手を入れないといけないんだよなみたいな感じなのかな、少ないサンプルですけど、ブログとか読んでて思ったりするんですよね
なのでこの本の、それぐらいから読む必要が出てくるのかなみたいな、この本読むっていうかここに書かれてるようなことを意識していくような必要があるのかなっていうような気はしましたね
きんじょうひでき
確かにこの手のお話、この本で触れられているような話って気づいたらうまくいってないなってなりがちですもんね そうそうそう
げんえい
なんか全く無自覚で認知する前にハマってたみたいな なんでだっけって紐といていくと組織構造が歪になってたりとか問題はあるってことは分かってたけど今の優先順位だとできないから後回しってやってた結果、やっぱそこは問題だよねってなっていくみたいな
早めに変更可能性を保持しながら組織設計をやっていくみたいなことがすごく求められるなあっていう気がします なるとやっぱ人とかチームを増やすよりAIさんに頑張ってもらいたいねみたいな気持ちもありますね
そうですねいつでも解約解雇できますからね そうですねなんかちょっとそのAIの話と関連してなんかもう一個喋りたいなと思ってたのが今までってそのこの本の中でもその開発プロダクト開発チームみたいなところの話がいろいろ載ってたんですけど
じゃあここにSalesだったりとかCSだったりとかチームに入れることができるのとか 究極そのエンドツーエンドを考えた時にそのプロダクトを作って出すっていうところだけじゃなくてどうやって打っていくかとかその使ってもらった後のフォローアップだったりとか体験のとこまで含めて考えていったら
きんじょうひでき
Salesの人とCSの人もいた方がいいんじゃないとかっていうのを思ったりしたんですけど その辺どうなんですかっていうのをちょっと思ったりもしました
県民が結構いろいろなアクダネっていうのはこの本でも触れられてるし本当にいろんなところで触れられてるがプロダクト開発の中に利用するプロダクトバックログアイテムをインプリメントしていくっていうチームの中においてSalesとかカスタマーサポートの人がエンジニアとかデザイナーほどフルタイムでチームにコミットするんだっけっていうのは僕はあんまりわかってないんですよね
げんえい
そういう状況になったことがないからな
といえばなんですけど今開発の中のそのチームの中に断の定義の中に例えばサポートサイトの更新とかが入ってないってなったときとかにじゃあそれを入れましょうってなったときにサポートサイトを仮にCSが持ってますとかだったらCSの人が入ってもらってサポートサイトを更新していくとか
そこに関連して影響がある部分がどこなのかを知るという意味でチームの中にいたほうがいいのかなみたいなことをちょっと思ったりとかあとある機能が出来上がったときにこの機能欲しいって言ってたお客さんにプッシュするできましたよって言って案内を出すとかそういうような部分とかもいるとチームにいるとフルタイム必要かどうかちょっとわかんないですけどもできることがもっと増えるかなとかその価値を届けるという意味で
ダイレクトに届ける可能性が高くなるなとか思ったりとかそんなことをちょっと考えたりとかしててなんかそれが開発チーム今のバックログをインプリメントしていくチームだけでやろうとするともう結構大変なんだと思ってて
そういうようなチーム体制で考えられるのかなとかAIとか人を減らしてうまくいくとかってなったときにそういうようなことがもっともっとできるんじゃないかっていうのは思ったりしましたね
きんじょうひでき
そこでAIが絡むのかどんなAIですか
げんえい
要はどんなっていうか人を減らせる減らすことができるっていう意味でAIっていう感じですね
多分今のサイズにこうじゃあ営業もカスタマーもとかって入れていくとチームサイズがどんどんでかくなっててコミュニケーションが大変だねみたいな感じになってしまうからみたいのは一個あったりするんで
きんじょうひでき
そうですねこれスクラムとかだとどうしてるんだろうななんかねステークホルダーという扱いにしてスプリントレビューでセールスとかCSとか混ぜてフィールドバックもらってとかあげると思うんですけど
ステークホルダーとしてマネックだったらチームの外になると思うんですよね配置としては
そうですねそのサポートサイトの更新とかはシステムの操作ってopsだからデブとops分にしてるのおかしくないっていう気もするかもしれないですね
まあそこは別にわかりやすくなんかシステムっぽい話になってるからあれですけど紙のカタログを送付しますとかなるとあんまり自分たちで確かにやらなそうっていう気しちゃうしな
どうなんですかね取り決めだけしておいてプロトコルだけ決めておいてやるのかな
げんえい
多分それが現実界そうなんだろうなって気はしますね
きんじょうひでき
なんか現実的に考えたらそうやるんだろうなぁとは思いつつあれなんかすごい保守的な価値観で今施行しちゃってるかなっていうのが自問自答してます
げんえい
じゃあ例えばですけどお知らせとかを出すとかサポートサイトの更新みたいとかリリースブロッカーみたいになった時に自分たちのチームで完結できないってなったら
なんかそれはそれで気持ち悪くない?みたいなのがあったりとかしてそういうのを取り払おうと思ったら自分たちでできるようにするとか
並行稼働するのかなこの辺にリリースだからサポートサイトいついつまでにお願いしますみたいなのとかお知らせをお願いしますとかリリースノートみたいな
でももう手元ではできてんだよなみたいなときとかにあとトゲロオンにするだけですみたいな
じゃあちょっと1週間待ってくださいみたいなやつみたいな
きんじょうひでき
リードタイムだ
げんえい
リードタイムだそう
ってなった時にじゃあこのストリームアラインを綺麗に流すためにチームの中に取り込んでいくのがいいのかなどうなのかなとかちょっと思ったりとか
きんじょうひでき
段の定義の中に自分たちでコントローラブルじゃないものを含めても仕方ないよねって話と
自分たちで本当にコントロールできないんだっけ工夫すればいいんじゃないっけっていう両方ありますよね
げんえい
難しいなあとセールスやCSって別に自分たちの作ってる機能以外のことも多分把握してたりとか
ウールスクリプトとしては別にそれ以外の機能と掛け合わせてだったりそれ以外の機能を中心にとか聞かれたら答えるぐらいだったりとか多分いっぱいあると思うんで
チームの中にいるのがいいかどうかってのはまた難しいなと思いながら
逆に言うとそこから設計してチームを作っていくとかももしかしたらあるのかなとかね
ようなことをちょっと思ったりとかしてこの本の中でじゃあもちろんステークホルダーというふうに捉えて考えるっていうのは一個全然現実的な話も多いながら
このチームの力で組織を動かす中ではどういうふうにアップデートしたら書くんだろうなとかっていうのは載ってないところでちょっと考えると面白いのかなっていうのはありました
きんじょうひでき
それ聞いてみたいですね松本さんどうしてますか
チームの理想と現実
げんえい
松本 多分こうしたいっていう理想系と現実的にはこうなってますみたいなその2つがあってそこをどうやってその理想に近づけていくかみたいな
自分はさっきの間では例えばAIによってじゃあチームサイドが小さくできたら他の人を入れることができるかもしれないか
ちょっといろいろなことを考えてみたけどもそういうようなところは何かしらアイデアを持ってるのかなみたいな思ったりした
きんじょうひでき
そうだよな企画メンバー企画チームとか2Aメンバーみたいなところまでは話広がってるんですけどねこの本
セールスへの厳重って本当になかったっけなあったっけな
げんえい
松本 作品にたどりづらい
きんじょうひでき
作品にはないですねあんまりだから強調的に強めに触れてはいない気がする
げんえい
多分世の中的にそこまで含めて考えるが当たり前では別にないと思うので
なかなかまずプロダクトを頑張って作るでアイデアを考える人と作る人を分離せずにちゃんと巻き込んで一緒にやりましょうねっていうのは
割とそこ分離しがちだから一緒にやりましょうねってしましょうねみたいなところっていうのは言われてきてるから
そこはやっぱ前提としたいよねっていう感じで本の中に書かれてたし
そっから先ってまだ多分世の中の事例としてもそんないっぱいあるわけではないと思って
なんかちょっと本にしづらいですよね
そうケースバイケースすぎるからな
きんじょうひでき
いや多分エンジニアリングとかソフトウェアプロダクトチームっていうだけでいっても本当はケースバイケースだよねっていう世界だったの
こういう本とかでちゃんと一般化してまとめてくれてるからちゃんとプラクティスベストプラクティスのことっていこうぜってなってると思うんですけど
そこら辺がいかにビジネス職って言われるところまで踏み込んでいけるのかなは今後に期待って感じですね
質問の仕方とAIの利用
げんえい
そうですね
きんじょうひでき
超面白かったのが会社でCSの人から質問来てここってどういうロジックなってますかみたいなよくある質問で
これそのままAIに食わせたら答えられるのかなと思ってクロードコードに
僕がスラックで見かけた質問をコピペして自分のターミナルでクロードコードに聞いてたんであれこれ僕の価値はって思いながら
全然回答が全くの嘘だったんでここから俺の仕事かって思ったんですけどちょっと面白かったですね
げんえい
でもそれ質問の仕方とかがなんかコツをつかんだらもしかしたらいけるとかあったりするんですかね
きんじょうひでき
あるんじゃないですかねただ質問の仕方っていうよりコード次第なんだろうな
なんかそれこそDDDとかやってて指キタス言語がめちゃくちゃしっかり定義されててで管理されてます
それはAIのアクラウンでもCSVでもいいんですけど読み込める形になってますってなったら
多分質問と回答のピントが合いやすくなるとかあると思うんで
そういう意味でのそもそもの内部コードの問題とか運用の問題はあるなって気はしつつ
ある程度は本当に大部分はいけるようになるんだろうなって気はするんですけど
社内でCSがエスカレーションしてくる質問ってだいたいニッチな話とか曖昧な部分なんで
活用できるだろうかは嘘つかれる率がめちゃくちゃ高い気もしてます
げんえい
確かにな
生産性の向上とチームの重要性
きんじょうひでき
一般的な質問だったら多分バッと結構いけると思うんですけど
げんえい
本当にわかんねえってやつはAIさんにもまだわかんない可能性が高そうですね
きんじょうひでき
簡単な問題はもうすでに解いてありますっていうまさにあれですね
げんえい
まさにどうであるかも
きんじょうひでき
あそうそうデマルコの話出てましたね
げんえい
そうですねこの本デマルコの話出てましたね
きんじょうひでき
そうなんかこの本でデマルコとかが言ってる生産性がエンジニア間で10倍とかにもなるよみたいな話が出てたのがちょっと気になってました
あれピープルウェアですよね多分
げんえい
あれピープルウェアですね
きんじょうひでき
ピープルウェアの何ページか覚えてますか
げんえい
第8章ってこの本の中に書いてありますね
きんじょうひでき
今ちょうどびっくりした目の前にありました
便利
第3番ピープルウェア54ページとかにある
ほんとだ
リサーチしたよプログラムの個人差っていう説が50ページですね
プログラミングコンテストのデータを分析して最初にわかったことっていう風に書かれてて
3つの文献の調査結果から弾き出したよみたいな図とかが載っててこの図表を見るとわかること
最優秀者の測定値は最低者の約10倍である平均的プログラマーの約2.5倍であるっていう風に書かれてるのか
これ絶対アップデートした方がいいと思うんですよね
なんかみんな40年前のデータ信じすぎではって思っちゃうんだよな
げんえい
確かに
きんじょうひでき
いやーまゆつばよって思って
げんえい
あとどうやって分かるみたいな話もありますよ
きんじょうひでき
コンテストですからねここで言ってるのは
今AIありきで考えたらマジでどうなるの開くのかめっちゃ縮まるのか
げんえい
いやーなんかどっちもありそうだなどっちもありそうって気持ちになる
きんじょうひでき
どっちもありそうですよね
でもデマルコたち自身が自分たちでやったのか我々ってなってるからデマルコとリスターさんかな
我々リスターだけさんづけしがちっていうすいませんちょっと脱線したんですけど
結構そのピープルウェアとかトムデマルコ曰くみたいな形で
この優秀なプログラマーと平均的なプログラマーの生産性の開きについて
引用的に厳禁されることがこの本に限らずよくありますね
でそっかこの本この本って言ってるピープルウェアじゃなくて
チームの力で組織を動かす本の感想で言うと
こっちの本の中だと個人の生産性はこのぐらい開けるよね
チーム間の生産性の差ってもっとでかいぜ的なニュアンスで書かれていて
げんえい
そうですね
きんじょうひでき
なんかそう今ってだいたいチームっていう単位で仕事してるから
あんまり個人の生産性の差っていうの無視できるとは言わないんですけど
チームで考えた時にどうなるんだっけっていうのを
なんていうか最初に一番のプライマリーはそこだよねっていう気はしてて
なんかそれはこのピープルウェアとか書かれた時代と
令和の今になって変わったことかな
ちょっとそこはアップデートがあって面白いなっていうような気が
げんえい
個人的な感想としてありましたね
そうですね
トムデマルコのさっきのピープルウェアの中でも
誰も書かなかった生産性要因で53ページのところでも
意外だったのはそれは誰とチームを組んでいるかであるみたいな話は
一応言及はされているものの
きんじょうひでき
この時よりも重要さみたいなのが変わってきてるよねっていう感じはありますよね
あとブラックチームの伝説とかっていうのも後ろの方に
げんえい
懐かしいブラックチームの伝説ありましたね
もう最初に読んだ本だ
まあでもそうですね
そうチームここだと2000倍みたいな差があるってなってるけど
2000倍ってどれくらいなんですかね
きんじょうひでき
2000倍そうですよね
1週間と2000週ってことか
げんえい
本当にって気持ちに若干なりますけど
ある種できないチームに難しい問題を与えて
一生何もできずにずっと過ごすっていうのはあり得るのかな
きんじょうひでき
プロジェクトが失敗するか成功するかみたいな話はありますよね
資金が尽きちゃったとか
げんえい
そんな感じなんだろうな
2000倍って言ってるところはほぼ失敗したっていうことで
うまくやるチームっていうのはあっという間に
だったらこの問題ってこうやって解けるじゃん
こうやってやっていこうねっていうのが協力的にうまく回っていくみたいな感じですかね
きんじょうひでき
あと時間軸的にリリースまでなのかその後の諸々も含めてなのかで
だいぶ違いますもんね
内部演出が問題になるのってリリースした後のはずなんで基本的には
げんえい
そうですねそうですね
チームを中心という話は多分すごく同意するしそうだよねって思いながら
でも我々はじゃあいいチームってどこにあってどうやってそれを維持したり
これいいチームだよってどうやってそれ観測してるんですかね
何思っていいチームって言ってるんですかねみたいなのはちょっと思ったりもしますね
成果が出てる
きんじょうひでき
成果が出てるあとニコニコしてるとかじゃないですか
げんえい
いつ話しかけても明るいみたいな
余裕がありそうみたいな
この本で一応スペースの話でチームが機能してるかどうか測りましょうみたいな話は
一応載ってはいるもののスペースのフレームワーク自体が新しいんで
あんまり世の中にそういうのがあるっていう紹介はいっぱいされるものの
うちの会社でこう使いましたとかいう話はないんで
多分ここでもそんなにたくさん触れるってことはしてないと思うんですけど
この辺がうちの会社でこうですみたいな話がいっぱい出てくるといいんだろうなと思いながら
きんじょうひでき
そうですねスペースの話どこだっけ
RSGTかなこのフレームワークで考えていました的な発表とかしてる会社さんとかって
ああいうのは面白いなって思いましたけどね
げんえい
どんどん事例が増えていくと多分そうやって考えるのかみたいなのが
もっと言いやすくなっていって分かりやすくなっていくんだろうけど
きんじょうひでき
ただやっぱり複雑なものだとやっぱり使いこなすまでがめんどくさいので
ゲットスターテッドが分厚いとめんどくさいみたいになると
やっぱりフォーキーズぐらい単純化されたものを取り入れたくなるっていう
そうですね
気はしますね悲しいけど
げんえい
フォーキーズのスイッチが出ましたって言って
リントでボスを描くとかドーラではエリートって言われてどこに近づきましょうねみたいなことだけ言って終わっていくと
そもそもうちでそれでいいんだっけみたいな話が抜きにされたりすると
うーんって若干なっちゃったりとかしちゃうし
そもそもそれをなんで追いかけるんだっけみたいな話を抜きにして
いやなんかこれは毎日デプロイしないといけないんでデプロイしますねみたいなことになってしまうと
なんで我々が毎日デプロイしてんだっけみたいなことになっちゃうんですよね
きんじょうひでき
確かになそこにデプロイボタンがあるからみたいな
とりあえず今日も押しましたみたいな
げんえい
だから多分いいチームを作っていきましょうはみんな多分ある程度同意だねってなっていくけど
じゃあいいチームを維持していきましょうとか
どんな風にいいチームがいいチームの状態のままいるのかみたいな話っていうのは今後に期待みたいな感じなんだろうなっていう風にもこの本も含め読みましたね
きんじょうひでき
そうですね会社組織みたいなところで言うとちょっと青臭い感じですけど
会社のバリューとかミッションっていうのをよく体現しているチームがいいチームだし生き残ってほしいチームになるんだろうなっていう気がしますけどね
ただそうじゃなくてなんか生産なんだデプロイ数リリース数が多いとか
げんえい
本番リリース後のバグ欠陥が少ないとかってなるとなんかうーんって感じじゃないですか
きんじょうひでき
それを図ってコミットしてお前はどうするんやみたいな
今の組織状態アズイズを次のステップに持っていくために今はここにコミットしますアタックしますだったらいいと思うんですけど
なんか50年後も100年後もうちの会社はバグが少ないチームを優秀なチームとしますってなるとじゃあログ吐かないでバグ
このログを一度消しただけでボーナスが50万出ましたって
なっちゃうのでならないと思うけどなっちゃうので
げんえい
半年に1回デプロイだったって人たちをじゃあ月に1回デプロイしたいですが週に1回デプロイしたいですって意味で
デプロイ数を測ってチームが変わったねみたいなことを評価するって意味でデプロイ数を測ってみましょうは多分全然いいと思うんですけど
きんじょうひでき
そうですね計測すると改善しますからね
デプロイ頻度の考察
げんえい
そうそうそれが究極いくとじゃあ毎日デプロイ1時間に1回デプロイ毎秒デプロイしてますっていう方向に行き始めるとなんかそれは違うねってやっぱんなっちゃいます
きんじょうひでき
毎秒デプロイやばいなCPUタイミングやばいからお金過ごそう
げんえい
だんだんクッキークリッカーみたいになってて何のために我々はクッキー増やしてるんだろうみたいな
きんじょうひでき
そうですよね人口よりクッキーの方が多いってなっちゃいますもんね
げんえい
そうそうこんなに食べきれないクッキー生まれてるけどなんでギガみたいな話になっちゃうから
その辺とかはやっぱりケースバイケースとかどういう風にチームをしていきたいかとか会社の状態をしていきたいかによって変わっていくんで難しいねっていう
けどなんかどうにかこうもうちょっとリンとデブオフスの科学とかではやっぱそのフォーキーズみたいなものである程度一般化できるんじゃないかっていうチャレンジもあったわけで
なんかそこの辺とかのアップデートだったりとか新しい軸みたいなことの考え方だったりとかなんかできてくるといいんだろうなと思いながら
じゃああなたがやったらどうですかみたいなこと言われたらそれができたら苦労しっちになりますね
きんじょうひでき
でもそうなんかそこら辺の本当に良いチームとはみたいなすごく本当に究極的なところになってくるとなんて言うんですかねうちはうちよそはよそでしかないなっていう気がするんで
自分たちで定義していくしかないと思うんですよねそれをどう図るかっていうのを問題より前になんかどうありたいか自分たちのバリューズをちゃんとMVPを定義するみたいな話
でそれって別に世の中のアップルのビジョンが生きてるからうちも同じビジョンにしようって変じゃないですかなんかそういう話な気はするんですよね
げんえい
組織のフェーズとか作ってるプロダクトによっても何が大事かって変わるし
いや他社が10回デプロイしてるからじゃあうちも10回ってなんかおかしいよねって言っちゃうし
きんじょうひでき
うちも10回できるはずじゃないって疑ってみると立てることに価値があると思うんですけど
組織文化と心理的安全性
げんえい
なんかあっちの会社をデプロイするれたから俺たちの勝ちだじゃないじゃんっていう気がする
企業チームの数値を他のチームと比較したって目標値にする意味ではいいかもしれない
きんじょうひでき
他のと比べてどうしたいのみたいな話とかを抜きにじゃあマネージャーが突然やってきてじゃあ10回デプロイしてってやったらまあだいぶおかしいことになります
そうですねまあやったことあるけどなそれマネージャーとしてデプロイ数増やしなよって
そうですね意外と話してるんだな時間な
げんえい
意外といっぱい話してるなと思いながら
きんじょうひでき
あとはなんかこの本を読んだ上で合わせて読みたい本とか自分だったらこの本一緒に読むなみたいなのとかってなんかありましたか
げんえい
組織パターンはなんか合わせて読むといろんな武器が増えるなと思ってて
いやこの本に組織パターン参考文献載ってなかったと思うんですよ確か
きんじょうひでき
そうこの本なんか参考文献をあれなんですよ我々最近ワインバーグの本をずっと読んでたじゃないですか
ワインバーグの昔の本ってすごい読書ガイドみたいなのが付いてるんですよね後ろの方に超手厚めに
げんえい
なんだったらソフトウェア文化を作るシリーズ第4巻なんてねこの本を読んだら参考文献にある44冊を読んで終わったりな書いちゃったし
きんじょうひでき
その前半では出てたこの本自体がすごい網羅的にいろいろな話を構築して組み合わせてくれたなって思う反面で
これだけで十分役に立つんですけどもっと深く知る必要は多分あるだろうなっていう気はしていて
でもそれはこの一冊だけで学びを止めてしまった場合にはすごいなんていうか知識に踊らされるというか
カーゴカルトってほどまではいかないですけど本質を見失っちゃいそうだなっていう気もしてて
その意味ではこの本が結構入り口として機能してほしいんですよね個人的に
なのでだからこの裏にある100冊200冊の本を多分読んべきだと思ってて
考えた時に参考文献あと3倍のボリューム欲しかったなっていう気がちょっとしてますね
げんえい
書記の下にいっぱいこの本を読んだ後に読むべき本を紹介してもらう
きんじょうひでき
そうすると松本さんのブログ全部読んでくださいでいける気はしてるんだよな
まあ確かにな
ダイナミックリチーミングとかが参考文献に載ってない気がする
いやそんなことない途中にはだから
げんえい
途中にはダイナミックリチーミングの本自体ではなくてなんかサイトだったりとかブログが紹介されてたりとかしましたね
きんじょうひでき
絶対に読んだ方がいい1冊ですねこの本の後にダイナミックリチーミング
目標設定の重要性
げんえい
そうですね
きんじょうひでき
あと組織パターン英語で良ければスクラムパターンも結構読んでみると面白いんじゃないかなっていう気はするけど
アップデートされないのかなあの本というか植木があると思うんですけど書いた人同じじゃねーかって言ってコプリンじゃねーかっつって
げんえい
そうそう今それをコプリンだよなと思いながら
きんじょうひでき
あと何ですかねこの本をすごい役に立ちそうだぞっていう立場にあるような人に読むといいの
リーン周りはちゃんと原点当たった方がいい気はしますよね
げんえい
あー確かに確かに
きんじょうひでき
第1部第1章か第1章でそのリーン志向ではないなリンスタートアップとリンソフトウェア開発は触れてあるんですけどどっちだろうないやどっちもどっちも読めばいいんじゃないですかね
げんえい
まあここに載ってるある種この本で取り上げてるような本はもう全部読むぞぐらいの勢いで
きんじょうひでき
僕割と参考文献に載ってるレベルだとだいぶ書籍については全部持ってるかなもしかして
すごいすごいですね気持ち悪い
げんえい
自分はデブオプスハンドブックとかザデブオプスギャクテンダーとかデブオプス系は全然読んでこなかったんだよな
きんじょうひでき
ゲインさんって小説仕立ての技術者大丈夫な人ですかデッドラインみたいなやつ
げんえい
大丈夫ですよ
きんじょうひでき
大丈夫なんであればザーデブオプスギャクテンダーはちょっと放題が覚えづらいんですけど
これ面白いと思うんですよね
げんえい
あちこちで紹介されてて見てはいるんで緊急されてるなっていつも思いながら見てますけどね
きんじょうひでき
この本ザーデブオプスギャクテンダーを読んだんだったらその勢いで勝利をつかめっていうのもあるので
一気に読んじゃった方がいいかな
ユニコーンプロジェクトとフェニックスプロジェクトですね
げんえい
なんかそれは聞いたことあるぞみたいな
きんじょうひでき
アメリカのソフトウェア系の人が書いたソフトウェア系に限らないのかなビジネスフィクションみたいなやつにありがちな
たまたま出会った人が実はすごい人で立ち話ししてたらめっちゃ教えてくれるみたいな
仕事は楽しいかねとかの方式と同じやつです
げんえい
いいですね
今その話を聞きながらちょっとこの参考文記なさそうなここにあるものは読むとしてって思った時に
チームの話ししてるんだったら
きんじょうひでき
アドレナリンジャンキーですか
げんえい
アドレナリンジャンキーではなくて
本棚のどこにあるかチームが機能するとはどういうことか
読んで面白かったし割と会社でも勧めたりするんであれとか良さそうな気はしますね
きんじょうひでき
心理的安全性って言葉出てましたもんね
ありましたね
予想限でやってたやつかコフォートゾーンとかダーニングゾーンとかと合わせてやってましたね
げんえい
多分そういう話とかフィードバックサイクルの話だったから学習する組織だったりとか
で多分この本読んでも組織って働きかけても変わんねえなって思うから
なぜ人と組織は変われないのかとかあの辺ですかね
きんじょうひでき
そうですねあとまあそっかあなたのチームは機能してますかと
なぜ人と組織は変われないかとかそこら辺か
あとあれですね心理的安全性とアジャイルっていうのピサのタイトルの方がありますね
げんえい
確かに確かに
きんじょうひでき
僕は読んだフェアレスチェンジとかもあるし
今でも参考文献読んでて思ったんですけど思ったというか見つけたんですけど
一冊持ってない本ありましたね
げんえい
原著一冊しかないんかいっていう気持ちもありますけど
あと自分がこれもうちょっとあるといいなと思ったのは
多分なんかチームの話の中でチーム作るのはやっていくと思うんですけど
やっぱりそのチームを駆動させるためには目標とかビジョンみたいな話は
ちょっとは出てたんですけど多分必要になってくると思うんで
イクオさんの目標設定の本とかがいいのかなっていう気はしましたね
きんじょうひでき
あのめっちゃいいですよね目標設定系の本だったら
いやなんか分厚い本を勧めてくれば他にも候補あるんですけど
なんかコンパクトにまとまっててすごい読んでて前向きな感じで
目標設定って楽しいかもってなれる気がするんであの本とてもいいですね
げんえい
しかもちゃんと目標設定をする前にやるべきことがあるんだよってことを教えてくれたりするんで
いきなり目標設定したらもういきなり終われるわけじゃないんだろうっていうことがよくわかる
きんじょうひでき
そうだよなそうですね目標設定しても何も始まってもないかな
あとは学習する組織さっき名前挙がってましたけど
あの本気軽に勧めて読む人あんまいないじゃないですか
げんえい
そうですね
きんじょうひでき
重いからな
げんえい
大変だと思うので学習する組織入門ってやつもあるんですけどそっちもそっちで大変なんで
きんじょうひでき
あとはなぜあの人の解決策はうまくいくのかとか
あれはシステム志向入門的な感じで
げんえい
そうですねいいですね
でもそんな感じですか
もうちょっと準備しておけば上げられたかもしれないけど
もうなんかいっぱい上がったのではっていう気がするので
きんじょうひでき
いい本なんだしめっちゃ関係するけど
勧めやすいかどうかが微妙なものとしてあれですねワインバーグのソフトウェア文化をつくるシリーズが
げんえい
そうですねちょっと4冊全部読みますかって言われたらうんみたいな感じにはなると思うんでね
きんじょうひでき
せめて3冊目まででもっていう気はするけど3冊目までで十分重いか
げんえい
そうなんですよねワインバーグの本とかをなんか読んでこの本に来て
まあ一気に飛んでここまで来て読んでやっぱり何ですかねなんか大枠は変わってないっていう気持ちというか
組織みたいなものがねじれたりうまくいかないっていうことに対して
ワインバーグはどういうふうにやったのかで現代においてはどうやったのかみたいな
その多分アプローチは違えどそこそういうものの課題感みたいなところっていうのは
多分まあ一生解消される問題ではないと思って
まあいろんな人はいろんなアプローチだったりいろんな考え方をしているっていうところで
30年前40年前と比べてどうだったのみたいな話はそれはそれでやっぱり面白い話でもあるんで
大変ですけど読む価値が全くないわけではないっていう感じですかね
きんじょうひでき
読む価値はめちゃくちゃあると思いますけどねただコストは読むコストは高い
げんえい
じゃあこのワインバーグの本を読む前にもっと読んだ方がいい本ありますかって言われたら多分いっぱい出てくるんだろうなって気がする
きんじょうひでき
そうなんですよでもそう確かにね根っこの部分とか本当に根っことか言ったり幹の部分っていうのはだいぶ共通するものがあるなとも一方で
なんだろうDevOpsとかクラウドネイティブとかっていうのは本当に実践レベルで現実化してきてるし
当たり前の水準がめちゃくちゃ高くなった上で今の時代どう戦っていくのかっていう話になっていってると思うので
そこらへんは本質は変わってないけど要求されるレベルとかめちゃくちゃ変わってきてるし
世の中一般的に要求されてるレベルが変わったのに耐えよるというか
押し上げてるぐらいにそのプラクティスがすごい一般的に溢れてきてるとか
本が出てますとかいろんなコミュニティで盛り上がってますとかっていうのはあると思うので
そっち側も抑えつつっていう感じになりますよね
げんえい
忙しいですね
きんじょうひでき
忙しいでしょうけどまあなんか組織作りとかマネジメントとか言い始めた人はそれ忙しいですよ
げんえい
そうなんだよな
きんじょうひでき
まあでもそんなところですかね
げんえい
そうですね
きんじょうひでき
なんかでも本当に一章一章というか下手すら1ページ1ページここらへんをもっと深掘りたいならこういう本読んだ方がいいかもっていうのが
溢れてきそうなぐらい密度の高い一冊だなっていう気はしますね
げんえい
ぜひ買ってみなさん読んでほしい
きんじょうひでき
いい本だったなすごい定番になりそうな本だなっていう感想です
じゃあ最後に何かありますか言っておきたいこととか
げんえい
これ読みましたっていう人とやっぱり喋りたいなっていう気がするので
人と感想戦したいなとかあと多分エンジニア本大賞とかに選ばれたりもすると思うんで
きんじょうひでき
確かに
げんえい
多分少なくとも候補には入るんじゃないかなって勝手に読んだ感触で思ってるんですけど
だいたい自分が思った本入らないこと多いんですけどこれは入るんじゃないかなと思って
今のうちから抑えてライバルに差をつけろみたいな感じでぜひ読みましょうっていうことですね
きんじょうひでき
大一冊持ってますって言って
そうですねぐらいですかね自分は
エンジニアリングマネージャーの成長
きんじょうひでき
あとあれですねリーダー向けの本とかエンジニアリングマネージャー的な本とか増えてきていいですね
5年前初めてEMやりますっていう人と今だとだいぶ日本語でアクセスできる文献の厚みというか
げんえい
懐の深さが違うなっていう気がしてますねさっきの伊藤さんの目標の作りの本とかもそうですし
しかもコミュニティもどんどん大きくなってるし実際に現場でやってる人の数自体も増えてると思うんで
多分いろんな質問だったりとか自分が今抱えてる問題に対しての相談先も増えてるだろうし
登壇試練も増えてるだろうしまさに今日EMコンフ2026やりますみたいなのも出てたりするんで
全然状況が変わったなっていう感じはありますね
きんじょうひでき
っていうねEMでもなんでもない2人が言ってます
げんえい
そうですねそうなんだよなここまで言ってEMじゃないって
きんじょうひでき
まあ5年前10年前の方が良かった点といえばエラスティックリーダーシップが手に入るっていうぐらいだと思うんで
げんえい
そうですね
きんじょうひでき
あの本が復活してくれればマジで
まあそんな感じですか
はい
じゃあ閉めていこうと思います
げんえい
はい
きんじょうひでき
はいえーと今週も放送を聞きいただきありがとうございますではまた次回さよなら
げんえい
さよなら
