00:06
きんじょうひでき
こんにちは、readline.fmです。readline.fmは、全読画趣味の2人が、何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、ハッシュ・リードライン・FMです。ホスト役は、源永さんと金城です。
それでは、源永さん、よろしくお願いします。
げんえい
よろしくお願いします。
きんじょうひでき
というわけで、組織パターンの後半戦ですね。
後半戦と言っているのは、この本が、前回の配信でも触れたんですけど、パターンランゲージとして4つの大型まとまりがあって、
今回は4つのうちの残り2つのパターンランゲージというのに触れて、パターン以外の話というか、その後の部ですね。
というところも、少し触れていこうという回でございます。
げんえい
今回のパターンは、大きく2つに分かれていて、組織のスタイルのためのパターン言語というのと、
人とコードのためのパターン言語というのが、大きな括りとなってますね。
きんじょうひでき
具体的な中身入っていっちゃった方が、どういう話なのかというのが分かりやすいと思うので、
そうですね。
第5章の1ですね。組織のスタイルのためのパターン言語というのが、これも前回までと同様にマップというか、
有効グラフが書かれている全体像みたいなのがあるんですが、出だしはまたしても信頼で結ばれた共同体からですね。
げんえい
そうですね。
きんじょうひでき
これは僕らは見かけるのが3回目なんですけど、
この本で扱っているいかなるパターンでも、やっぱりここからスタートするんだねっていうような印象がありますかね。
げんえい
これがないと本当に話にならんっていうことだと思うので、じゃあここから先にやっていきましょうって。
わざわざグラフに書かなくてもいいようなことかもしれないんだけども、
理事義にちゃんと毎回乗っけるんだなっていうのはちょっと思ったりしましたね。
きんじょうひでき
そういう意味で言うと、4つあるパターンランゲージそれぞれ独立して読んでいくことができる感じがしますよね。
そこから派生しているというかつながっているのが、ロールワークなくですね。
これ写真を触れようかと思ったけど、まあいいや。
これがどういうパターンですかっていうと、コンテキストの設定としては、
プロジェクトを成し遂げるためには、いくつかのロール、いくつかの人たちっていうのが関わっていて、
当然複数の人間が関わっているので、そこにコミュニケーションを達成しますよねっていう風になって、
ただやっぱり人とかロールっていうのが増えていくと、コミュニケーションによってオーバーヘッドが生じて、進捗を妨げると。
03:06
きんじょうひでき
これって本末転倒だよねっていうことで、組織内に出てくるロールの数っていうのを一定以下にしよう。
必要に応じてロールの見直しとか、このロールは本当に価値を発揮してるんだっけっていうところの点検っていうのをやっていきましょうっていうようなパターンですね。
げんえい
今回そこでいくと、じゃあロールが多いほうがいいのか少ないほうがいいというと、少ないほうがいいですよと。
多すぎるとコミュニケーションパスが膨らんでいくので大変なので、なのでロールを少なく抑えるようにしていきましょうねっていうのがこのパターンですね。
きんじょうひでき
この本で言ってるロールってどんなものがあるかというと、どういう切り取り方をするかにもよるんですけども、もちろん経営者とか役員とかそのレイヤーのものも含んだりとか、
プロジェクトマネージャーとか監査役とかテストの担当とかいろいろいますねっていう感じですけど、これ実際今我々が働いているような会社だとどのくらいのロールがありそうなもんですかね。
げんえい
そうですね。すごくざっくりした見方をしたら、経営者、監査とかさっきのあって、さらに言うと開発者、セールス、CS、あとはマーケティング、上司数とか人事とかロームとかか、バックオフィス。
上げていくとすげー大量に出てきそうだなっていう感じが今ものすごいしてます。
きんじょうひでき
この本で言うと、そうか、コンサルタントとか設計モデレーターとか秘書サポートとかなんかいろんなロールが出てきて、エンドユーザーっていうのを明示してたりしますね。
なるほど。で、ドメインエキスパートとかアーキテクトとかリードアセンブラーとかいますよ。
げんえい
リードアセンブラーはマジで何するんだろう。
16以下に抑えましょう。抑えるようにするといいよみたいな話が書かれてますけど、16っていうのがピンとこないな。多いのか少ないのかわかんねえなって思ったりはちょっとしましたね。
きんじょうひでき
どう切り取るかにもよりますもんね。
げんえい
そうなんですよね。例えば開発者の視点からしたら、別に直接のコミュニケーションパスがないものに関しては、増えてったとて影響はあんまりないわけじゃないですか。
きんじょうひでき
はい。
げんえい
なので増えても別に困らないのではみたいな気持ちになりながら、じゃあ16っていうのはコミュニケーションがうまく取れるようにロールを少なくしていくって意味だから、
コミュニケーションパスが結構色々複雑に絡まるところがやっぱりメインのところになっていくのかなとかちょっと思ったりとかして、
06:02
げんえい
あんまりそこが関係ないところは別に増えても減ってもあんまり影響しないんだったら、ロール増えてもいいんじゃねとかちょっと思ったりとかしちゃいましたね。
きんじょうひでき
ロール開発とかサービスの運営、運用に関して手を動かしたりとか、意思決定に関する人たちっていう登場人物を整理していけばいいのかなっていう気がしているんですよね。
例えばさっき言ってたバックオフィスみたいな話とかはあんまり多分出てきてないんじゃないかなっていう気はしていて、
ちょっとあの弊社サポートっていうロールがマジで何なのかわかんないんで何かも言えないんですけど、それでいうと、
当然カスタマーサポートとかセールスとかっていうのは何かものを作ってくれる非常に重要な意思決定に関わってきますし、
ロールの数にこだわるっていうよりかはコミュニケーションがこんがらがってないですか、コミュニケーションパスが複雑になりすぎてないですかみたいなことなんじゃないかなっていう気がするんですよね。
げんえい
そうですね。よくあるのは何か意思決定するためにあの人とあの人とあの人とみたいな関係者をたくさん呼ばないといけなくなっていくから。
きんじょうひでき
そうそう、会議室入ってない問題みたいな。
げんえい
いやちょっと大会議室空いてないですねとかってあるとこう難しくなるみたいなのがあると思うので、
まあ本当のこのロールが少なくっていうかまあ意思決定に関わる人数が膨れ上がるのを狭めましょうみたいな。
まあそういうところが本当は本質だとは思うんですけど。
きんじょうひでき
そうですね。ただそう聞くと16ってなかなか多い気がするんですけどね。
げんえい
そうですね。
きんじょうひでき
感覚があんまりわかんないですよね。組織の規模とか時代みたいなものもあるだろうし。
げんえい
あれか、もともと研究大使となってたのはAT&Tの研究所というかだったりしたんで、そこをもしかしたらちゃんとどういうプロジェクトやってたかを見たらわかるのかもしれないですけど。
あんまり現代において16は多いんだろうか。まあ多いよな。
きんじょうひでき
デモールチーム思考みたいなのが高まってる気は勝手にしてるんですよね。
げんえい
めちゃくちゃわかります。それだし、この本の後ろにも出てきますけど、分割統治せよっていうことをすごく何度も何度もこの本読んでると目にしていて。
きんじょうひでき
そう、ロールは少なくから派生してるというか繋がってるパターンの2つのうちの1つがまさに分割統治なんですよね。
げんえい
そうなんですよね。なので、いかに複雑度を上げない方向に組織というものを分割できるか。
人数が膨れ上がるのことは別にもしかしたら問題ではないんだけども、1個1個の統治するセクションなのかチームなのか、部署なのかわからないですけど、そういうものは分割して統治できるように保ちましょうみたいなところもあって。
現代においては多分それがすごく強まってて、小さなチームで大きな成果を得るっていうことの方が指向されてる。
09:04
げんえい
特にITの業界を見ていると。周りを見てるとそういう感じはあるなって思うので、そこから考えるとロール16って結構多いよなってちょっと思ったりしますね。
きんじょうひでき
そうっすね。代表者会議にミニマム16人ですもんね。
げんえい
そうですね。
きんじょうひでき
でもそう、やっぱり意思決定を速やかに行うみたいなところの法律性というか効果を高めるみたいな話っぽい気はしますよね。
げんえい
逆に言うとだからこれが出てくるまで、これが出てくるまでっていうか、過去研究というかリサーチの中ではここがどんどん膨れ上がっていてなかなか意思決定ができなくてうまくいかないみたいなものが見られたりとかもしたのかな。
きんじょうひでき
失敗の本質っていうめちゃくちゃ有名な、みんな大好きな本があるじゃないですか。あれとかスクラムとかやってるとよく参考に上がる米軍とか海兵隊とかの例とかだと、意思決定を中央でやってたら判断がどんどん遅くなるよりエッチですね。現場の判断で機動性を高めようみたいな話があって。
失敗の本質とかに書かれてたのは、空母かな空母かわかんないんですけど、実際に船に乗っている人たちから未確認の、もしかしたら敵かもしれない、何か近づいてきます。どうしてますかみたいなことを。
要するに機器が明らかに近づいている状態なのに、中央司令軍からその時間に敵がその海域にいるなんて情報はないから予定をそのまま計画通りに進めなさいみたいな言われて、めちゃくちゃ大破されたのかな。忘れちゃったんですけど。
要するに最新の情報とか確実な情報っていうのを現場持っているのに、トップダウンで中央から降りてくる情報、意思決定しか使えなかったから、本来だったらこう思う必要がなかった損害とか失敗とかっていうのをおっしゃってるよねみたいな話が失敗の本質には書かれていて。
落語かよっていうぐらいその結果論だけ聞くとそうなんですけど、そういうことになるからロール少なくして分割統治して、そこに実際に携わっている身をもって携わっている人たちがどうにか自立していけるようにみたいな話は出てくるんじゃないかなっていう気がしますね。
げんえい
そうですよね。そしてまあやっぱ現場で判断できた方が強いし、やっぱそっちの方に現代においてはどんどんいってるような気がするので、やっぱ16話多そうだなとか。
きんじょうひでき
16話多そうな気がしますよね。
じゃあ今名前が出たんで分割統治いってみますか。
げんえい
いきますか。
きんじょうひでき
5-1-6ですね。
げんえい
この本で分割統治って言ってるのは、
12:01
げんえい
うまくいってるプロジェクトは成功に伴う成長やチームのダイナミックスを上回る成長とうまく付け合う方法を学ばなければならない。
組織が大きすぎると管理することができない。結束してない組織は混乱の元になるし焦点もぼやけてしまう。
みたいなことを文脈としてあって。
それゆえ強力な相互関係がありながら組織の他の部分との結合度が低いロールのクラスターを見つけよう。
そしてそのロール群を中心にして今あるものとは別の組織とプロセスを形成しよう。
っていう風に言われてますね。
きんじょうひでき
まあ分割統治せよって感じですよね。
げんえい
そうですね。これすごく直感に合うというか。
最初はスタートアップで一つのチームでできてたけどだんだん人が増えてきて。
じゃあチームを分けるかって言って。
機能がどんどん作っていってでかくなっていったらドメイン単位にして。
こっちはECサイトであれば決済チームだったりとか。
こっちは買い物加工チームだったりとか。
こう分けていくみたいになって。
すごく最近でも今でもやられてるし。
本当によく見るよねっていう感じがしますね。
きんじょうひでき
この本の特徴みたいなところで言うと、
一冊通してずっとロール同士の結びつき、コミュニケーションパスみたいなものを
ソーシャルグラフっぽい感じで、このロールとこのロールが繋がってるよねみたいな図をずっと使ってるんですけど。
それでロールの配置の粗密だったり、ここのグラフめっちゃ出てるねみたいなところを分析して、
こことここの間に長回線引きそうじゃないみたいなことをやっていくのが、
この分割統治の中で他の部分との結合度が低いロールのクラストを見つけようって言ってる話かなっていう気がしますよね。
げんえい
そうですね。ここが今の我々が普段なじみのある言葉とかに行くと、
多分フィーチャーチームを形成しましょうとか、ストリームアラインドを作りって、
それが機能に対して対になるようなチームを作って、
要はその機能と機能の結びつきが低ければ多分そこには境界線が引けてチームを分割していくみたいな。
そういうようなことっていうのは多分同じような、
その裏にある分割統治とストリームアラインドの裏にある考え方の同じ方向性としてそういうところがあるんだろうなって思ったりしますね。
きんじょうひでき
そうですね。この分割統治を使えば、本の原文も読むんですけど、
分割統治を使えばどんなやりとりが行われている場合もロールは少なくできる。
ロールは少なくって言ってるのはさっきのパターンですし、
当たり前っちゃ当たり前なんですけど、すごいうまく繋がっているなって感じがしますよね。
だからこそこの分割統治っていうのをやる意味があるんだなみたいな。
あとあれか、このパターンを適用するのはリリースの合間にして進行中の作業が混乱するのを最低限に抑えようとか、
15:09
きんじょうひでき
作業の分割をさっさと行う必要があり、チーム構造をまたがる必要がないならグズグズするなを参照してほしいとか書いてありますね。
げんえい
あちこちに行きますね。
きんじょうひでき
あちこちに行きますね。
そんな分割統治がありつつですけど、何か次行きたいやつありますか。
げんえい
コンウェイの法則に一番繋がるなって、この分割統治を読みながら読んでたんで、コンウェイの法則も一応触れておきますか。
きんじょうひでき
コンウェイの法則すごいな。ここから6個のパターンに合成していってますね。
げんえい
全てコンウェイの法則で説明するんじゃないかっていうぐらいな感じがありますけど、
一応コンウェイの法則の説明をもう一応しておくと、組織の構成要素がプロダクトの本質的な構成要素を反映していない場合、
あるいは組織間の関係がプロダクトの構成要素間の関係を反映していない場合にはそのプロジェクトは困ったことになるだろう。
っていうのがコンテキストで、要は会社の組織などがプロダクトの方にすごく反映される。
つまりなんでこことここは絡み合って、本来関係なさそうな気がするのに絡み合ってるんだろうとか思ったら、
それはそもそも作ってる側がそういうような組織構造だったみたいな、いうオチですね。
それゆえ、ちゃんと組織とプロダクトのアーキテクチャを対比できるようにしておきましょうということですね。
これはものすごく最近も言われるので、耳たこというか、いう感じがしますね。
きんじょうひでき
そうですね。情報とかコミュニケーションの流れっていうのをちゃんと見て、それに合わせた形に組織も、
そこからできる成果物、構造物もちゃんと作っていきましょうよみたいな話ですよね。
げんえい
そうですね。ちなみにコンウェイの法則は出典は1968年なんですね。
なのでもう何年前?60年ぐらい前の話なんですね、実は。
きんじょうひでき
そうか。コンウェイの法則は誰が書いたんですかって聞こうとしたんですけど。
多分名前ですもんね。コンウェイさんですよね。
げんえい
コンウェイさんが見つけたコンウェイの法則ということみたいですね。
きんじょうひでき
何の時代なんですかね、1968年。
げんえい
60年代、日本で言えばオリンピックがあったりとか万博のちょっと前とかそれぐらいですよね。
きんじょうひでき
そうですね。
げんえい
アメリカで言うとどういう時代なんだろう、1960年代。
アポロ計画とか、月に行ったのが69年だそうです。それぐらいの時代。
きんじょうひでき
X理論、Y理論とか出てきたのも60年代らしいですね。
18:02
きんじょうひでき
だからあれじゃないかな、組織開発の第一次ブームがここら辺だったとかそういう話かな。
げんえい
ありそうですね。戦争もあったし、フォードの車の生産みたいな話はもうそれよりもっと前の時代からあって、
たぶん工場化みたいなものはずっと、要はファクトリーはもうあって、
戦争もあって、だから組織みたいなところにフォーカスが当たっていくみたいなのは全然ありそうですよね、その後に。
もっと効率よくとか、もっと生産性を上げるにはとか、もっとモチベーションを持たせるためにはとか、そういう話は全然ありそうですね。
きんじょうひでき
なんかあれじゃないですか、HRティックとかやってる会社の人だと詳しい人いるんじゃないですか。
げんえい
そうですね、HRの歴史みたいなとこに詳しい人はいるのかなじゃない。聞くともしかしたら歴史を教えてくれるかもしれない。
でもやっぱりここ最近の話の方が多いですね、やっぱり話題になるのは。
きんじょうひでき
まあまあまあ、じゃないと売れないですからね。
げんえい
60年代にはこういうのがあってとか言っても、まあ顧客ははーっとしか、そうなんですねーで終わっちゃったりするから。
最近のHRはこれですっていうのがまあやっぱ最初のつかみとしては必要だから、やっぱそっちの方が学習みんな知っててねみたいな感じにはなる気がしますね。
きんじょうひでき
そうですね、さっきコムウェイの法則から派生しているパターンが6つあるって書いてあったと述べたんですけど、このパターンランゲージの中でメインで扱っているところで言うと、組織は都天配置に従うとかぐらいか。
げんえい
そうですね、他は割と多分その後ろですかね、人と行動の話に行っちゃう分だったりとか。
きんじょうひでき
なんかこのパターンランゲージの中で出てこないとかサブ的な位置づけになってるっていうものではないんですけど、あっち側の体系の中に組み込まれてて説明があっち側でメインになってますね。
こっちのパターンランゲージの中での重要性よりもあちらでの重要性の方が高いみたいなそういう解釈でいいと思うんですけど、この後出てくるだろうみたいな感じはありつつ。
げんえい
そうですね、また後で触れるでしょうと。
きんじょうひでき
なんか今のうちに触れておきたいやつありますか、コムウェイの法則つながりで。
げんえい
そうですね、なんかまあ順当に組織は拠点配置に従うみたいな話をちょっとしてもいいかなと自分は今思ってます。
きんじょうひでき
5-1-8ですね。
げんえい
これはどういう文脈かっていうと地理的に分散した要因にタスクとロールの割り当てをするときは注意しましょうねっていう話で。
21:07
げんえい
要はコミュニケーションが分断されるような地理的にするときは注意しましょうと。
それ故アーキテクチャ上の仕切りは地理的な仕切りを反映させなければならないし、逆もまたしかりっていう風にありますね。
なんでちょっとこれ喋りたいなって思ったかっていうと、現在においてはフルリモートだよなって思ったときに、この組織は拠点配置に従うっていうのはどれぐらい現代において適用できるのかみたいなことをちょっと思ったりとかしました。
きんじょうひでき
これそうですよね、なんか遠く離れてしまっていると文化的な違いみたいな国をまたぐとか大陸をまたぐみたいなところとか顕著だと思うんですけど、
そういう文化とかスタイルの差っていうのが生まれてしまうで、それ乗り越えるのって結構難しいよねみたいなところが一つあるかなって感じがするのと、
この本の言葉で言うと、それぞれの拠点に意思決定を行えるようにしなきゃねみたいなことが書いてあって、そういうコミュニケーションのオーバーヘッドとか殺、パケットロスみたいなものとかもあるのかなっていう気がするんですけど、
フルリモートか、全員がフルリモートだったら多分大丈夫なんですよね、この話だけで言うと。
げんえい
そうですね、フルリモートで場所がその拠点っていうのが実はオンラインだったらOKみたいなそんな感じはあるのかなっていうのをちょっと思いつつも、でもフルリモートでうまくいってなくて出社に戻すぞみたいな話もあり、世の中的には。
きんじょうひでき
そうですよね、あれよくわかんないなって思うんですよね。何を思ってうまくいってないって判断したのかなみたいな。
げんえい
それはオフィスに行ってもうまくいかないのではみたいな説もあるじゃないですか。それは別にオフラインだからオフラインの頃にうまくいってたのか、じゃあ実はみたいな、本当はそんなことないのではみたいな説もあるだろうし。
きんじょうひでき
漏石とか離植率みたいな話で言うと、どっちかっていうとコロナかっていうパラメータがでかかったりは多分するじゃないですか。他の条件を揃えてリモートってやってないよなっていう気はして。
いろいろな難しさがあって、おやけな場で喋る難しさも今感じてるんですけど。
げんえい
その比較対象実験みたいなのは難しいですよね。オンラインでやったこととオフラインでやったことを同じチームで同じように働いて比較するって単純に実験として難しいですよね。
24:00
きんじょうひでき
そうですね、レッドラインでやってほしいなって感じが。
げんえい
そうですね。
きんじょうひでき
やっぱり国を味方にして数億円を持ってきて。
げんえい
大量のメンバーと少ないメンバーでどっちが開発が早いか勝負だみたいな感じにしてみたりとかしたように。
一方でちょっと思ってるのは、でも直感的には、拠点に人を集めるみたいなのって理にかなってるっていうか、正しいような気がするなと思っていて。
各社を見てると福岡オフィスはなんとかチームみたいな、東京オフィスはこういうチームでとか、京都はこうでとか。
別にどこに所属になっててもいいんだけど、あのプロダクトはこっちのオフィスでとかいうことってありそうだなっていうのを見ていて。
もしかしたら福岡とか東京とか何でもいいんですけど、その地域に住んでるっていうこと自体がさっきの文化の差異みたいな、共通のバックグラウンドを持っていてみたいなところがあって、仕事のしやすさにつながってるとか。
そういうのとか実はあるのかなってちょっと思ったりとかしましたね。
きんじょうひでき
なんかね、もっとちっちゃい単位で言うと、同じチームは同じ島に座らせ、島ってなんかあれか、国とかグローバルレベルの話してるときに島って言うと、なんかアイランドになっちゃうんですけど、普通のあれでデスクですね。
同じデスクでまとめて座りましょうとか、そういうところもまあ、なんか現れとしてあるんだろうなっていう気はしますよね。
げんえい
あとはまあ、昔のイメージとかだとあれですよね。土地と基本のその給料が安いっていうところで地方に工場を作って、なんか頭脳ロードは東京でみたいな、なんかそういうのって昔あったけど、これを多分何も考えずにそんなことすることはないと思うけど、
例えば考える人をあっちこっちに分散して、工場もなんか九州と北海道に作ってとか、みたいなことって多分まあしないから、結局同じような役割の人を同じような場所にまとめていってっていうふうにやると、結局組織っていうのは拠点配置に従って出来上がっていくよねっていうようなのは、確かにその通りだなみたいな気持ちにもなったりするので、
なんかここで言ってることは別にそのリモートワークが出てきたから古くなったっていうことも全然ないと思うし、まあ昔ってまあそうだったよな、で今もそういったワーク全然続いてる部分もあるよな、みたいなところをちょっと読みながら思ったりしましたね。
きんじょうひでき
そうですね。あとなんかね、みんな会社の近くに住むと組織力が強くなるみたいなね。
げんえい
二駅以内だったら家賃補助が出るとかね、いっぱいありましたね、なんかそういうのは。
きんじょうひでき
僕は目黒の会社で二駅ルールでなんか家賃どこも若たけえって思って、すごいワクワクしてた思い出がありますね。
げんえい
あと渋谷のオフィスから二駅になるとみんな池尻大橋とか三茶に住んでしまう問題があって、こうだいたいみんなすれ違うっていう話を聞いて大変だなって思ったりとかね、ありましたね。
27:05
きんじょうひでき
あとあれか、本の話に戻ると、このパターンの最後の方に必ずしも分散してるとうまくいくわけがないっていうことではないよ、こういう例外というかこういう条件を目指せばうまくいくこともあるよみたいな話が書かれていて、
それこそリモートワークやるにしても、なんかここに挙げられている必要な条件みたいなことはちょっと当てはまりそうだなっていう気がしていて、
全ての都店を合計してもプロジェクトの開発者の数が少ないとか、ほとんどのコミュニケーションがEメールとか広記分散コミュニケーションで行われているとか、
一回も会ったことがないとかではなくて、ある程度顔を知っている仲間になっているとかとかっていうのが書いてありますね。
げんえい
そうですね、現代っぽい感じでいくと、インセプションデッキを作ったりとか、お互いを知るためにチームビルディング頑張ってやってますとかいう話だったりとか、
スラックがちょっと同期コミュニケーションっぽい感じにはなってますけど、チャットツールを使って非同期でもテキストによるメッセージの方を重要視して、
ちゃんとログに残しましょうねみたいな話っていうのは、周りで働いている人たちとかと話をしていてもすごく多くなってきたなって思うので、
そういう意味ではやっぱりリモートワークみたいなところがだんだん成功する、同じ拠点にいる必要性が下げれるような環境がどんどん整っているんだなみたいな感じはありますね。
きんじょうひでき
あとあれですね、ちょっと抽象化というかメタっぽい読み方すると、今読み上げたのも含めてここに挙げられている必要な条件って、
要するに信頼された、信頼で結びついた共同体を構築しましょうっていうのと、コミュニケーションのコストというかコミュニケーションパスが短慢としてしまうことによるコストっていうのをある程度ちっちゃく保たないとうまくいかないよっていうところに全部集約されそうだなっていう気もしますよね。
げんえい
そうですね。いいですね。いいですね。やっぱりこの本の前提となっているものがだんだん見えてくるというか、やっぱりそれがないと組織が大きくなったりすると、どんどんどんどん難しくなっていくっていう感じがしますね。
きんじょうひでき
うん。てか本当にコミュニケーションパスをマジでめちゃくちゃ減らしましょうっていうのと、その生き残った数少ないコミュニケーションパスでは超緊密にやりとりしましょうみたいな話で言っても過言じゃない気がするんですよね、この本。
げんえい
確かに。確かにそうですね。
きんじょうひでき
コミュニケーションを減らすために意思決定のやり方とかって話が出てきたりもしますし。
げんえい
確かに。そういうことをみんなが意識しながら働けたらめっちゃ強くなりそう、その組織とか。
30:02
きんじょうひでき
でも別に殺伐とやりましょうっていう話では全くないので。
げんえい
そうそう。
きんじょうひでき
給水所とかのパターンもあるんで。
給水所これからか。
げんえい
はい。
給水所行きます?いきなりなんで。
きんじょうひでき
まだ順番に行きます。
げんえい
はい。
