00:00
小田中育生
あらたま・いくおのマネジメントRadio
Makoto Arata
この番組は、事業とエンジニアリングのマネジメントを探求する2人のEMが、雑談多め定期でお届けするポッドキャストです。
はい、では第9回始めていきましょうか。
小田中育生
はい、始めていきましょう。
よろしくお願いします。
よろしくお願いします。
Makoto Arata
雑談多め不定期でって言ってるのに、雑談ないし不定期で。大体日曜か月曜日に公開してますよね、私たち。
小田中育生
なんかね、この原稿不一致なところは、しっかり返り見なければいけないなと思っているんですが、今日も真面目に話します。
チームの力の重要性
Makoto Arata
はい、今日はですね、チームの力で組織を動かすっていう本を読んだよっていう話をしたいなと思ってまして。
小田中育生
この本はいい本ですよね。
この間書評も書かれてましたよね。
はい、書評書いたのと、私、あらたまさんに内緒でフロシキFMっていうポッドキャストにゲスト出演したんですが。
聞いてないぞ。いや、知ってますけどね。
はい、そこでも藤井優次さんと同じくゲストの方で、あれも私と藤井さんゲストなのに、MCの2人置き去りで喋り続けるっていうひどいことをしたんですけど。
放送事故に。
放送事故なんですけど、そこでも盛り上がりましたね、非常に。
Makoto Arata
ああ、そうなんですね。いや、本当にいい本、いい本でした。
小田中育生
何がどういう本なんですか。
Makoto Arata
はい、チーム、個の力を生かすっていうことももちろん大事なんですけど、個の力を組み合わせたときに、個の力の足し算以上の力が得るよねっていうところをまず説いてるんですよね、この本は。
で、その上でチームの力を最大限生かすために、こういうベストプラクティスがありますっていうところと、それを対応させるような形で、こういうアンチパターンがありますよねっていうのをいくつか累計にして紹介しているっていう本で、
チームの力が大事だよね、だからこうやって伸ばしていきましょうねっていうところに留まらず、診断のツールとして機能するっていう構成がすごく素晴らしいなっていうふうに私は感じました。
小田中育生
ありがとうございます。本当に素晴らしい、今新玉さんおっしゃっていただいた通りで、やっぱりチームは大事だなっていうのは、皆さんも日々、特にこのラジオを聞いてくださるような方っておそらくマネジメントに興味あったりするので、日々実感されてるのかなと思いますし。
で、チームについての本ってこれまでもたくさん世の中にあるじゃないですか。
Makoto Arata
私も中にも書いてますしね。
小田中育生
そんな日々もありましたね。
そういった本でいかにチームを蘇生していくかっていうところに結構焦点が当たってて、それもすごく大事なこと。
組織と環境の関係
小田中育生
一方でこの本は新玉さんにもおっしゃっていただいた通り、とはいえいいチームを保つこととか、いいチームであり続けることって難しいよね。
そこの構造、チームの中にある課題だけじゃなくて、チームを取り巻く環境を含めて、なぜチームがいいチームであることが難しいのかっていうのを様々な角度から検証されてて。
そこは本当にパラパラめくってても、これ今うちのチームこうなってるなみたいなことに気付けるという点で非常に価値があるなと。
そういう素晴らしい本です。
Makoto Arata
ですね。あとユニックだなと思ったのは、組織やチームの設計について書かれた本ではあるんですけど、技術的なベストプラクティスとか捉え方みたいなところをうまく引き合いに出して、
その業種度が高い方がいいチーム分けになるよねみたいな話であるとか、そのコーナーの共同所有のパターンとかを引き合いに出して、
どのぐらいの依存関係でお互いのチームがあるべきなのかみたいなところが語られているのが面白いなと思って読んでましたね。
小田中育生
そうなんですよね。本当にまさにそこでチームについて語るときって、おそらく意図的にソフトウェア文脈をちょっと抽象化して文化化することが多いかなと思うんですけど、
もうこの著者の松本さんの隠しきれないソフトウェアエンジニアなんというか、
おそらくこの方なんで、自分のエンジニアとしての経験を生かしながら、もう本当にエンジニアリングとともにマネジメントを走らせてきた方なんだろうなっていうのが、
うかがい知れるっていうところで、そういう意味でなんで、おそらくエンジニアの方も読んでて、メタフォーとかすごいわかりやすいんじゃないかなと。
実践とモニタリング
小田中育生
もうスパゲッティコードみたいになっちゃった組織とか、みたいなのがわかりやすいかなと思うし、
この例を積み重ねていくと、よくコンベイの法則って言われたりするじゃないですか。組織の構造がアーキテクチャの一点です。
それが、そのコンベイの法則が実際に作用してるっていう例がもう散りばめられていて、
Makoto Arata
そうですね。
小田中育生
そういうことなのねっていうのを立体的に捉えることができる、いい本だなと。
Makoto Arata
個人的に印象に残っているのが、最後の方、例、スペースフレームワークについて結構幅を取って説明されていたじゃないですか。
小田中育生
ヒコさんもスペース大好きだと思うんですけど、
Makoto Arata
実際にこういう考え方でスペースフレームワークと向き合うといいですよっていうふうに書いてはあったんですけど、
それを自組織に落とし込んだときにどうなるのか。
例えば、指標、大事な指標っていうのを一つか二つ決めて、それをモニタリングするために仕組みを整えていきましょうみたいなことが本では書かれていたんですよね。
スペースの頭文字全部を押しなべてベタっと取っていくのではなくて、今自分たちの組織にとって大事な指標っていうのをその中からピックアップして、
こういう例を使いながらモニタリングして最前につなげていきましょうみたいなことを書いてあって。
ヒコさんは自分のチームとか組織とかで運用されてますか、この辺。
小田中育生
今ゴリゴリに運用はしてないんですけど、スペースフレームワークは実はフレームワーク自体がまさにこの本に書かれてるように全部を見るんじゃなくて、
大事なところを見ろっていうふうに言ってるんですね。
私たちのチームでいうと、当然開発生産性のところ、サイクルタイムみたいなところは見ていますし、
そこがただ頻繁にデプロイしてるようじゃなくて、成果につながるところですね。
チームが目指してOKあると結びついたところでしっかり出せているかだったりとか、
ロードマップのところと結びついているかっていう、いわゆるパフォーマンスのところだったり、
結構大きく変化をしていくときってチームのエンゲージメントだったり、
みんなが不安になっちゃってちょっとウェルビングがそこなったりっていうことが起こり得るので、
そこに関してはウェルビング指標のところをウォッチしながら、
ここはいい感じだけど、ここはちょっと危ういかもね、みたいなのを見たりっていうのはやったりしてます。
スペースとメールって見てないけど、結局的にWeboxっていうエンゲージメントのツールが、
たまたま前者で導入されてるのもあって、
チームメンバーで一人そこをメインで見てくれてる方がいて、
マネージャーからエンゲージメント上げようぜって言うとあまりに意図的なものになるので、
Makoto Arata
メンバー主導でちょっと進めてもらってるんですけど、そういったこともやったりしてます。
エンゲージメントカウントを置いてるってことですか?
小田中育生
そうです。
Makoto Arata
面白いですね。
それはその人はWeboxのスコアを見ることができる?
小田中育生
できる。
Makoto Arata
みんなのエンゲージメントを上げるためにどういうことをやろうかやらないでおこうかみたいなことを考えて実行してくれる人。
小田中育生
そうですね。私に相談してくれたり、周囲のメンバー巻き込んだりして進めてくれてて、
僕から見ると非常にいい動きをしてくださってるなっていうふうに捉えてます。
そういうふうにしてスペースのところに、結果的にチームの状態で見たいことを見ると、
このスペースで表現されてるところのどれかを見ていくことにはなるんじゃないかなと。
Makoto Arata
最終的にそこに実践するよねっていう感じか。
そうです。
ありがとうございます。
ちょうどチームの健康状態をモニタリングするであったり、
それこそこの本で書かれているような内部品質を高めていくためにどういうアクションが取れるのかって、
やった方がいいことを詰め込むと忙しくて死んじゃうじゃないですか。
なので、どういうふうに注射選択していこうかなって考えていたちょうどタイミングだったので、
この本に書かれてたことすごく身に詰まされることもあれば、
これちょっとやってみようかなって思うこともあればっていう感じで、
答えの意味を増していただきましたというのがあります。
小田中育生
いいですね。
Makoto Arata
さっきもキラッとお話ししたんですけど、
この本、アンチパターンっていうのが存在してですね。
責務が分かれきってない、他のチームが持っているべき責務を自分たちが何でか持っちゃってて、
それでうまく開発の前に進まないなあであったり、
どこかしらでバリューストリングが止まってしまうであったり、
っていう弊害を引き起こしているねというみたいなパターンとか、
いろいろ紹介がされてるんですけど、個人的に結構気になったのが、
バリューストリングの合流点っていうパターンがありまして、
どういうことかっていうと、
一つのチームが複数のバリューストリングに配備されているっていうふうに書いてあるんですね。
バリューストリームの理解
Makoto Arata
これはどういうことかっていうと、バリューストリングっていうのは、
例えば企画からデリバリーまでっていうといいんですかね。
実際にユーザーに価値が届くまでの一連の流れをフローに捉えて、
それをバリューストリングというふうに表しているんですけど、
最終的に流れが合流して、
例えばデプロイの前であるとか、コードレビューであるとかっていうところで踏ん詰まっちゃって、
うまくストリームが流れていかないみたいなことが起きてますっていうのが、
バリューストリングの合流点、アンチパターンっていう感じなんですね。
これは結構起きるよねって思ってね。
どういうことかっていうと、
例えば一つのアプリケーションを複数の関心ごとを持つチーム、
例えば一つのアプリケーションに三つ大きな関心ごとがあったとして、
それをそれぞれ開発して届けようとしたときに、
共同所有しているコードベースの場合って、
自分たちがやった変更が他のチームに影響が波及してしまうことって全然あると思うんですよ。
そうなったときに相互にレビューしましょうねってなると、
関心ごとの異なるチームの変更を別の関心ごとのチームがレビューしようってなると、
そもそもこれって何のために必要なんでしたっけみたいなところからキャッチアップが必要だったりして、
そのコストっていうんですかね。
もちろんチームに関心ごとが関心ごとごとのチームに閉じて、
それで影響が出なくて、ちゃんと開発が回る状態が作れてればいいことはないんですけど、
そうじゃないことも多い。
例えばその三つあるうちの一つはまだそのドメインに就職式ってなって、
ここを変更すると他が壊れるっていうことを知らないみたいなケースもあるかもしれないですし、
そういうふうに就職度がバラバラな状態で、
じゃあ誰が責任を持っていくのかっていうのと、
合流したときに踏んざまっちゃうって現象をどうやって解きほぐしていこうかなみたいな、
チームの責任とドメイン知識
Makoto Arata
結構いろんな人が困ってると思うんですよね。
これ、りこさんの組織で過去、経験ありますか。
小田中育生
過去、そうですね。私社会人たってまだ十数年しかたってないですけど、
死ぬほど見てきたなって。
一時的に起こってる瞬間課題なんだけど、
それで悪いことじゃないよなっていうふうに僕は思ってるんですよね。
バリューストリームが複数入り乱れてくるっていうのが、そこが価値を生み出しているから、
もっと価値出そうぜってバリューストリームが増えてきてるっていうこと。
責務が増えたり、そこに関わってくる人が増えてるっていうので、
ビジネス観点で言うと、そこは喜ばしいことだったりする。
一方でエンジニアリングの軸で言うと、放っておくと偉いことになります。
放っておくと大変だのがその通りで、
今、あらたまさんがおっしゃってる、やっぱりそこで人が増えてきたりとか、
あるそのプロダクトが持ってるユーザーに提供する価値の、
新しい価値を提供しようってところに新しい人たちが来たときに、
その人たちが既存のものを知らないから壊れちゃうみたいなのって、
まあまああるじゃないですか。
そこに対して、一時的に壊れたりとかレビューにすごい時間かかるっていうのは、
誰しも経験することなんだけど、
それってじゃあ、数年前だと一番ベストプラクティスになったのは、
マイクロサービスにしようと。切り出して即結合にしよう。
それが本当にお互いに干渉しないものなら、最適解だと思うんですよね。
問題が起きたときにまずは切り離すことができるかっていうのを考えるのも大事だし、
一方で、価値が連動してて切り離せないものもあったりするじゃないですか。
Makoto Arata
ありますな。
小田中育生
ソフトウェアエンジニアとしてはまずきれいに即結合にすることを考えるんだけど、
とはいえここって連動してるからこそユーザー体験につながってるんだよ。
ありますあります。
そういったものは無理に切り離すと、
今度切り離されてチーム分かれてるけど事実上同期取らなきゃいけないっていう意味で、
逆にオーバーヘッド増えたりするんですよね。
ってなると、レビューのタイミングだったりで問題が起きてるときに、
それが何が問題なのか。
さっき新玉さんおっしゃってたドメイン知識が足りないことが課題だとしたら、
じゃあドメイン知識が足りてる状態だとそこで独立してレビューできますなら、
じゃあその人たちが独立してレビューできるように
ドメインナレッジを貯めるっていうことに焦点を当てたレビューイングをしていくっていうと、
そこに対して、この例えば3ヶ月でこういった判断ができるようになったら、
渡せるよねみたいな、定制的にどうしようもないと思うんですけど、
そういった目標を持って、そういうふうにして少し分けていくだったり、
一方でやっぱりモジュールA、モジュールBあります。
そこのAでアウトプットされたものがBの入力元になってるなら、
AのアウトプットどうなってるかってBは常に関心ごとじゃないですか。
そういう影響を与え得るものは何かっていうのを特定して、
それの時はちゃんとレビューしましょうだったりとか、レビュー自体にも目標、
常にフルスペックでレビューかけちゃうと確かに大変だし、
それこそバリューストリームアルファとベータがあります。
バリューストリームアルファチームは開発チーム含め、
今生み出そうとしているバリューに対しての顧客インパクトを理解し、
やるべきだと思ってる時に、それを知らないベータの方に関わってる人たちが、
見てわからないからって、これってそもそもビジネス的にどんな意味あるんでしたっけの説明から始めると、
すごく時間かかっちゃう。時間かかっちゃうし、
そのバリューストリームベータの人たちのレビューで見てほしいところって、
ビジネス価値の検証何でしたっけっていうところは取るべきポイントで、
何で見てもらうのかなっていうところで、例えば何か予期しない不正語が起きてないかとか、
そういうレビューの意味を明確にして切り離していく。
そういう何でこれやってるんでしたっけって一個一個のアクションを問いながら、
バリューストリームマッピングのアップデートみたいなのを仕掛けていくと、
だんだん良い方向には倒れていくから。で、一時的にその状態になるのは、
だいぶ話戻りますけど、これまでの自分の経験から言うと、プロダクトやビジネスが伸びていく中で、
バリューストリームが混戦するのは全然起こり得ますと。
で、一時的にそうなったのはビジネス伸びてることだから、
まずはいいねって捉えてあげるといいんじゃないのっていうところと、
長い間混戦した状態を保つとすごい開発しづらい、企画しづらいになるので、
それはマイクロサービスにするなり、レビューのルールを決めるなり、
解きほぐす方法は模索しようっていうのが一ついいんじゃないか。
なんでこのアンチパターンへの向き合い方として、
ここの本で書かれてるアンチパターンになったらダメだよーではなくて、
組織の課題と解決策
小田中育生
こういうこと起こり得るよーって起こり得るので、
状況を見えてきたらどう脱出するかも、先にじて手を打てるといいんじゃないっていう使い方なのかなと思ってます、この本が。
Makoto Arata
本当にそうですね。アンチパターンって書かれてると、
それを脱し抜きゃみたいな気持ちにというか、そういう力学が働いてしまいがちですけど、
この本にも、そういう状態であるっていうこと自体は、自覚してやってるんだったらいいですよと。
で、そのせいでみんなが疲弊するんだったらそれはよくないから、手を打ったほうがいいと思うけど、
一時的に必要なものとして割り切ってやるんだったら、
それは必ずしも組織に対して悪影響があるわけではないですよみたいなのが書いてあったような気がしますね。
小田中育生
そうですね。アンチパターンって実装からはもうそこ自体が悪そうに見えるけど、
なんか僕の記憶だとアンチパターンってもともとは、
そういうデザインパターンがあったじゃないですか。
そのデザインパターン、あるところではハマるデザインパターンがあるところではハマらないみたいな。
Makoto Arata
アンチ。
小田中育生
そうそう。あるので、必ずしも悪いものというよりは、
このタイミングでそうなったらうまくいかないよっていう。
物のニュアンスも含まれているのかな。
Makoto Arata
そうですね。ある点においてはいいパターンだったものが、
時間の経過によってアンチパターンになっていくみたいなケースもありますね。
小田中育生
そうです、そうです。
本当にどうしようもない、絶対にすんじゃいけないよってアンチパターンもあったりしますけど。
せっかく新玉さんが語ってくれたので、僕もお気に入りのアンチパターンを言うと、
ねじれコンウェイっていうのが出てくるんですが、
あれも死ぬほど見てきたなっていうところで、
組織構造とコード所有の問題
小田中育生
このねじれコンウェイって、要はコンウェイって本当は組織構造がアーキテクチャに社蔵されてるよねってものなんだけど、
それ自体がずれちゃってるっていうところがある。
これ、自分見てきたのが、Aというモジュールがありましたと。
Bというモジュールがありましたと。
Fという機能は、それぞれのモジュールの責務を考えるとAであるべきなんですけど、
なぜかBの方に実装されていたんですね。
Makoto Arata
全然ありますよね、そういうことね。
小田中育生
全然ありますよね。
そのときいた人たちで真剣に考えたんですよ。
それがなぜBにあるのかを考える。きっと何か意図があるに違いない。
経験学が考えても答えが出ず、そのとき通りすがったベテランの方が、
みんなが人だかりになって話してたんで、どうしたのってなるわけですよ。
これがなんでこのモジュールにあるのかわからなくてって言ったら、
それね、このときAのモジュールの人たち忙しかったから、
俺がこっちに実装したんだよって。
本人?
そう、本人登場っていう感じでしたけど。
Makoto Arata
よかったですね、たまたま本人が取り上がって。
小田中育生
たまたまいてよかった。
でもひも解くと、そのとき人がいなかったから仕方なかったみたいなのって結構ある。
特に小規模のスタートアップから始まって走り抜けてるときって、
一旦ボール持てる人が持つみたいなのが起こりがちなんですよ。
右のコーナーへどうぞ。
それは正直先輩がそれ言ったときはお前ふざけんなよって思ったんだけど、
そのときはたぶんそのとき持ってる組織のケーヴァビリティとか、
みんなの知識では最短かつ最良だったと思うんですよね。
ノームクラスの最優先上校じゃないですけど、
そのときみんな最善は尽くしたっていうのは常に信じて、
そっからじゃあ、そのとき最適だった意思決定をこのまんま引きずるとどうでしょうね。
話を聞いて、それならしょうがないよねってみんながねじれ気持ち悪いけどほっとけるなら、
それもほっとくのも実は選択肢の一つなんだけど、
でもみんなが気持ち悪いって思ってるってことは、
将来回収するときに何かの意図しない変更を招きやすいので、
変えたほうがいい。
っていうことをみんなで議論しながら、
今の最善を尽くしたらどうするっていうふうに変えていくっていうのは大事なんだなっていうのを、
実体験もしてたし、実体験もしてたけど、
なかなか皆さんと会話してるときにそういうことあるよねっていうのはあるけど、
本で書かれたのはあんまり見たことなかったから、
これこれって思ってのエピソードですね。
チームのプラクティスと経験
Makoto Arata
コードをどういうふうに持ち合うかっていうところがパターン化されて説明されてましたね、本では。
強いコードの所有、弱いコードの所有。
小田中育生
さっきあらたまさんがおっしゃってたバリエストリームが一個になっちゃうみたいな、
合流しちゃうみたいなのもあるし、
強いコードの所有、弱いコードの所有みたいなの、
強弱がやりたいことと合ってないとねじりにつながっていくっていう意味で、
いろんな問題がつながってるなっていうのが本を読むとよくわかりますね。
Makoto Arata
ですね。
コードの所有の形もそうですし、
機能としては別なんだけど、
出面としてはAのモジュールに、
フロントエンドだけはAに異論するんだよねみたいなやつもあったりして、
そういうのだとより分け方が難しいなと思ったりしますけど、
私たちはもういくつかの共同所有の形を変えながら、
この時はこうかなみたいなので、
ずっと判断しながらやってますけど、
すると自分たちの持ち物のはずなのに、
オーナーシップの弱いコードみたいなのがだんだん生まれてきちゃったりして、
それは最終的に自分たちに所有権が帰属するんだったら、
そこはキャッチアップしておかないとねみたいなので、
キャッチアップの機会を設けたりみたいなのもあったりしてますね。
はい。そんなところでしょうか。
小田中育生
そうですね。今日はこんなところかな。
Makoto Arata
はい。今日はじゃあ、
チームの力で組織を動かすという本題材に、
いろいろ自分たちのチームで起きていることとか、
これまでやってきたプラクティスの話とか、いろいろできましたね。
小田中育生
そうですね。
僕はすごいこの本好きなんで、
ぜひ新たなマイクを出る方も、
この感想を新たなマイクに寄せるのが適切かなと。
Makoto Arata
そうですね。
小田中育生
お届けいただくのがいいかなと思います。
Makoto Arata
本の作詞はだいたい自分の本のタイトルで誤差してるんで、
SNSでつぶやいてもらえると、
みんな嬉しい。私たちの本もつぶやかれたい。
つぶやかれたい。
では今日は以上にしましょう。ありがとうございました。
