1. readline.fm
  2. EP042『組織パターン』PART3
2024-10-08 37:26

EP042『組織パターン』PART3

spotify apple_podcasts

『組織パターン』の中から、『第4章 組織デザインパターン」の感想を話しました。

## 取り上げた本

⁠『組織パターン チームの成長によりアジャイルソフトウェア開発の変革を促す』⁠ James O. Coplien, Neil B. Harriosn 翔泳社 2013年

## 取り上げた主なパターン

  • 4.1.12 コミットメントのやり直し
  • 4.1.22 誰か1人を犠牲にする
  • 4.1.23 託児所
  • 4.2.2 組織を細かくする
  • 4.2.3 段階的に人を増やす

## 言及した本・スライド・サイト

https://gennei.notion.site/EP042-PART3-118c645d4911805c9ff9d1db7e705f95


サマリー

このエピソードでは、組織内のコミュニケーションやプロジェクト管理におけるパターンを探ります。特に、開発者とマネージャーとの関係や「生贄の子羊」の概念を通じて、チームの効率性や認識の重要性について考察しています。また、職人チームと訓練チームの役割、および新人教育のパターンについて議論します。タクジショーのパターンが新人の成長にどのように寄与するか、進捗チームとの関係性にも焦点を当てています。さらに、組織の成長を促進するためのパターン言語について深く掘り下げており、特にプロジェクトの運営とチームサイズの重要性に触れています。ジェフ・ベゾスが提唱するワンピッツァルールに基づくチーム構成や、効率的なソフトウェア開発の戦略も議論されています。最後に、チームのメンバーを増やし、組織のアイデンティティやチームビルディングに焦点を当てた方法論について考察しています。

コミットメントのやり直し
げんえい
おだしょー じゃあ、次いきますか。開発をうまくいくようにさせるためには、失敗の話をすると、だんだんツラいエピソードがいっぱい出てきそうだなってちょっと思ったりとか。
きんじょうひでき
そうですね。コミットメントのやり直しが関連パターンとしてあるねって話をしたんで、ちょっと軽く触れますか。
げんえい
これは写真は何ですかね。これは人がみんな椅子に座って、円になって座っていて、帽子でお金を集めている絵ですかね。賭けにみんな乗るようにお金を集めているような写真に見えますね。
きんじょうひでき
おだしょー そう、チャプションも何もないからわかんないですね。
そうですね。
おだしょー これコミットメントのやり直しだ。投票してるのかな?お金ですかこれ?紙?
投票か。何もわかんないです。あんまり楽しそうにはしてない。
げんえい
おだしょー もう一回爆笑を打ちましょうっていう話なのかなって勝手にタイトルが推測しちゃいましたけど。
きんじょうひでき
これはプロダクトの主導権が危険にさらされているスケジュールとか調整がうまくいかない。開発者主導の活動ではもうどうしようもなさそうだっていうコンテキストですね。
そういう場合は関心を持つマネージャーと主な開発者を集めて打ち合わせをしよう。
ああだこうだ言って、質問に対しては根拠のある答えを示せるようにしながら議論をして、新しい計画を立てて、そこにいる人たち参加者全員で合意しましょうみたいな。
なんていうか普通ですね。
げんえい
もう一回プランニングをしましょうみたいな。
きんじょうひでき
ここだけ読むとすごい、行き詰まったら関係者集めてもう一回計画立て直しましょうっていうだけなので、なんかすごい普通だなーって感じなんですけど。
これ多分見方としては、開発者がソフトウェアを実際に作っている人たちが自分たちの努力とか能力っていうのを超えた時に、そこを監督しているマネージャーがしっかり介入していって、
関係者を交渉の場を設けて、かつそこの当事者である開発者っていうのをちゃんと入れて、全員でコンセンサスとってやりましょうよみたいなところがポイントなのかなと思ってて。
勝手に話をしないとか、開発者に任せるっていうのが自律的に開発させるっていうのがベースではあるんですけど、こういうライン、こういう状態になったらマネージャーもちゃんと出張っていきましょうよって話。
げんえい
もしかしたら期日は決まっていて動かせないものだと開発者が例えば信じ込んでしまっていたりしたら、そこにありますよねそういうのって。
とりあえず2週間みたいな感じでざっくり言われたものだったんだけど、実は2週間終わらないどうしようみたいな。
怒られると思って開発者が抱え込んじゃったりとかすることもあると思うので、ちゃんとそれが交渉可能なもの、調整可能なものなんだよっていうためにもこういうパターンっていうのは結構大事。
なのかなっていう気がしましたね。当たり前だけど当たり前にやるって結構実は難しいことなのかもしれないですね。
特にこの自分一人でどうにかできる問題じゃないものとかに関して。
きんじょうひでき
パターンランゲージの中の一つとしてこのパターンが組み込まれているのすごい見方を変えさせるというか、特別な意味合いを持たせて面白いなっていう気がしますよね。
あと全然関係ないですけど、実は現場が思っているほどスケジュール厳しいものでもなかったみたいな話聞いてて思ったのが、下から上に情報が上っていくとニュースの改良が起こるじゃないですか。
大丈夫らしいですよ。3日で余裕でいけるらしいですよみたいな。言ってもないことを現地取ったかのように扱われるみたいな。
で、なんか上から下に落ちてくるときは逆に解約されるなーって今思って。難しいですね組織っていう気持ちになりました。
げんえい
これは社長案件だからって話が言ってて後々聞いたら、社長が言ってたけど別にそんなに優先度は高くないですみたいなこととかが実際あったって話を聞いたりとかして、
組織ってそういうもんだよねみたいな間に人が挟まってて、やっぱり熱量みたいなものが伝えるのってやっぱり人がいっぱい間に入ると難しくなっていくと思うんで。
テキスト自体は送ることはできるけど、そこに対する感情だったりとか熱量だったりネガティブな、今ポジティブネガティブな感情みたいなところまでは乗っからないんで、そういうところで結構難しさが出てくるんだろうなって気がしますね。
きんじょうひでき
でね、たまたま休憩時間にどうかで社長とすれ違った時に今何やってるのみたいな話だって、社長案件のあれすげー頑張ってきついけどどうにかなりそうなんですよって言ったら、いやそれよりも他のことやった方がいいんじゃないって言われて、現場のプレイヤーがなんか非常に辛くなって辞めてしまったみたいな話もあったりなかったりしますからね。
げんえい
そうなるとこううっかりしたこと言えねえなっていう気持ちになって情報がまたひとくされて、なんかそれよりそれであんまり良くない方向に行ったりとかして、組織に対するメッセージングの難しさってそういうとこあるよなみたいな、メッセージ大事だけど公開しまくってると言ってることがコロコロ変わってるとかね言われたりとか、そういうことが起きたり起きなかったりするんで、難しいなメッセージングって思いました。
生贄の子羊の概念
きんじょうひでき
そうですね、やっぱりPR担当を立てないといけないですね社内向けでも。
なんかじゃあまた次のところ行きますか。コミットメントのやり直しはこれはこれで終端というか行き止まりなので、別のところ起きそうなのありますか?
げんえい
起きそうなのは、ちょっとお飛ばしで4.1.22で誰か一人を犠牲にするっていう。これね写真がいいので是非本を買ってですね写真見てもらいたいんですけど、羊ですね写真が。で誰かを一人を犠牲にする。
きんじょうひでき
これパターンに別名がついててね生贄の子羊って書いてありますからね。
げんえい
スケープゴートですね完全にこれは。
きんじょうひでき
これはですねでもめちゃくちゃ有用だと思いますよ。
げんえい
そうなのでもう話もしたいみたいな思ってた。
きんじょうひでき
どんなパターンですか?
げんえい
これはどういうシチュエーションかというと、余計な作業が細かく積み重なるとチームの力を蝕んでしまうと。
余計な作業本来集中すべき作業があるんだけどもいっぱいいろんな細々したものがあるとスイッチングコストが大きいとかって言ったりしますよね。
そういうのがあったりするんで本来集中してコードを書きたいなと思ってるかもしれないけど割り込みちょっと多くて辛いんですよねみたいな。
そういうような状態の時に誰か一人余計な作業に割り当てて作業を終わらせてもらおうってやって。
つまり誰か一人犠牲になってもらってじゃあ君は今日は外から来た何ですかね依頼を担当する人ねみたいにして誰かが集中して進めるために誰か一人を生贄にしましょうっていう。
そういうようなパターンですね。
きんじょうひでき
ありますもんねセキュリティチェックシート回答してくださいとか。
げんえい
そうCSからのお問い合わせが1日3件起きた日にはもう進まねえよみたいなことになったりするとか実際やってたこともありますねこれは。
きんじょうひでき
ありますねありますね。
げんえい
水曜日はじゃああなたが当番で一周とかこれやってほしいんだけどみたいな来たらその人がお前に担当するとかなんかそういうのやってました。
きんじょうひでき
これまあそうですよねパターンの名前が非常に悲観的すぎるというかちょっと強いなぁ怖いなぁって思ってたんですけど改めて考えるチーム全体で認識を持って本当に犠牲にするいや難しいですけどね。
社内の一緒に頑張っている仲間のCSの人たちからのエスカレーに対応するのに犠牲にするっていう言葉を使うと非常に何かしらの火種を撒くことになるんで難しいんですけど。
ただ意識としては犠牲にしているなんですかねめちゃくちゃ表現が難しいし表現が難しいなって思ってるんで口が滑るかもしれないんですけど。
ローは○○さんが犠牲になりますって言うとみんなこう慈愛の眼差しを持ちながらその○○さんを見ることになるじゃないですか。
で早く救い出してあげなきゃいけないみたいな尊い犠牲になってくれてありがとうみたいな感謝の気持ちとかも生まれるのかなって思うとこれの逆のパターンで説得的にできちゃう人がボール拾いに行っちゃうみたいな。
自然とやってくれすぎちゃって結構透明化するというか周りの人からいつもやってくれて言われてみればありがたいねぐらいの軽い感じになっちゃうみたいな話も結構あったりとかそれってみんなのストレスになるはずなんですよね。
っていうぐらいだったら強めの言葉使って状態を正しく認識するある種のイレギュラーというか危機的な状況になったからこそそれこそ犠牲を出さなきゃいけないぐらいの感じだからそういう対処してるんだねっていう現状を正しく認識させるための強い何て言うんですかねパワーを持った言葉っていう意味だとなるほどいいのかもなぁとかちょっと思ったりとか。
実際ね本の中でもこれ犠牲になった人は辛いとか成功報酬っていうパターン使う時には生贄の子羊になってしまった人のことを忘れないようにしましょうって書いてあったりとか結構気を使った書き方をしていて。
ズルズルといかないでメリハリをつけるっていうのは結構この組織パターンのいろんなところで意識されているなと思うんですけどさっきの細かいリスクをしないとかもメリハリを持ってやりましょうみたいな話だと思うしこれもそういう意識づけのためのいいワーディングっていう風に100%こうやってどうしてもしづらいにしたくないんですけどそういう効果はありそうだなとか思ったりしました。
げんえい
あとはなんか自分はこの誰か一人犠牲にするっていうのは自分のチームを想像してっていうよりはそこに架空のチームがあってそこの一人が犠牲になってるみたいなイメージをなんとなく自分は最初知ってたんですけど逆にこう自分のチームみたいなところを考えたときにやっぱり犠牲になるっていう言葉あれかもしれないですけど犠牲になってでもそういうことをやった方がチームがうまくいくんだったらあるタイミングではそういうこと勇気を持って自分が犠牲になるみたいなことを
取らないとじゃあそこで何かじゃあみんなでこう等しくいろいろあれこれちょっとずつツイッチングコストをかけながらやっていっても最終的にプロジェクトが失敗してしまったら意味がないよねっていうようなところでも思ったりもするんで
犠牲にするって言うと自分は犠牲にならないかみたいなイメージを自分は勝手にしちゃったんですけど勇気を持って自分が犠牲になるみたいなのも必要なんだぞっていうことを言ってくれてるようなパターンでもあるかなってちょっと深読みをしてしまいました
きんじょうひでき
そしてあれですねこれはよりコンテキストに特化した派生パターンがいくつかあるわけですね
新人育成の重要性
きんじょうひでき
そうですね
じゃあ託辞書いきますか
げんえい
はい
きんじょうひでき
託辞書これ幻影さんが一番議論したいかもって書いてありますけど
はい
好きとは言ってないか議論が
げんえい
そうですね これは何かっていうとプロジェクトに新人がやってきましたと
そうすると新人っていきなり何でもできるわけじゃないんで鍛える必要がありますよねと
でよくやるのって新卒入ってきていろんなチームに割り振って配属をしてそこで成長してもらうみたいなことでやると思うんですけど
このパターンは職人を一人新人全員の教育に割り当てその他の人たちでシステムを開発しようっていうようなことを言っていて
つまり新人を一つのまとまりのチームとしてそこに人を一人だけ当ててとかチームを作ってそこで開発するのと
ある種さっきの犠牲に近いような感じもありますけど
他の全員が平等にちょっとずつ作業できなくするよりも新人は新人でまとめてしまってそこで成果を出せるようにトレーニングをするんだっていうような考え方ですね
なんで一番議論したいと思ったかっていうと
じゃあこの新人の教育をする時に誰か一人を割り当て一人とか二人でもいいんですけど割り当ててチームで仕事をしてもらった時に
じゃあ一体いつになったらその人は卒業できるのかとか
新人同士で働いても分かんないことがそこからは見えないことって多分いっぱいあって
全然年が離れてるとか
なんかもっと一つのチームの多様さみたいなところ
同室じゃないっていうところの方の中に放り込まれた方が学べることってたくさんあるんじゃねみたいなことは結構思っていて
このパターンってどれぐらい有用そうなのかっていうのをちょっと話してみたいなって思いました
タクジショーパターンの分析
きんじょうひでき
これね宅次装パターン別名が進捗チームと訓練チームっていう風に分かれてて
このパターンの反対側がケインさんが言ってたようなペアOJTみたいな感じとか
各チームに新人均等で割り当てるみたいな話ですけど
これあんまり僕一生懸命読んでなかったんですけど今見返してて気づいたのグラフがありますね
げんえい
そうですね
きんじょうひでき
宅次装パターンを使った場合と均等に新人を職人チーム進捗チームに割り当てた場合の生産性が
全体の生産性ですね個別のチームじゃなくて組織全体の生産性がどのように変化するかみたいなグラフが書いてあって
これを見るとあれじゃないですかバランスが取れるところが分かる
リサーチしたんですかね
げんえい
どうやってリサーチしたんだろうっていう気がしますけど
数理モデル作ってそれに当てはめたという感じな気もしますけどね
きんじょうひでき
投影効果法律みたいな話で言うと原作が伸びるような新人同士だとなかなか到達できないところがあるよねとか
実際に配属される現場で生の実践地を身につけるそれはそれで価値があることだよねみたいな話もね
この本の中でも実際に触れられてたりしますけど
これ新人研修みたいなのは多分開発職全体新人研修みたいな機関がある会社は
多分ある程度研修チームみたいなのを組んでやったりしますよね
げんえい
そうですね
きんじょうひでき
上等によるけどになっちゃう気がするんだよな
げんえい
そうなんですよね
あと最近の新人新卒って言ってもバリバリ開発アルバイトでやってましたみたいな人とかもいたりするんでね
近所さんみたいに入社しかなくていいかなみたいな世界はそういうパターンもあったりするんでね
きんじょうひでき
4月1日は8時間ぐらいコールを書いてましたからね
げんえい
それもう普通の社員やんけみたいな
同い年が入ってきたねぐらいな横目で見てる人みたいな状態
きんじょうひでき
マジで同期にずっといる人だと思ってましたとか
げんえい
まあそうなりますよね
きんじょうひでき
これはでもタクジショー
誰か一人を犠牲にするパターンの展開というか派生応用バリエーションで
新職を出すみたいなところで言うと確かに納得感はありますよね
逆に言うとその新職チーム的ないわゆる職人が普通に手を動かしているチームっていうのが余裕があるんだったら
中長期的な目線で考えるのを優先してある程度行動かけるぐらいの水準に達している新人だったら一緒にやりましょうよとかやる気がするかな
げんえい
いつのタイミングでこのタクジショー出てってもらうかみたいなとか
そこの基準って明確にするって結構難しいじゃないですか
きんじょうひでき
そうですねただそうかあくまでこれもさっきの犠牲にされている人だと思ってて
マジでリアな言葉だななんか
かわいそうな子羊として選ばれた人って考えに立つとテンポラリーなロールじゃないですか
だから新人がちゃんと出荷できる状態まで持っていくことっていうのに対して責任を負うっていうよりかは
ある程度の3ヶ月ぐらいだったらこのプロジェクトの進捗を削ってでもどうにか潰れないですよねっていう
期限付きの出向って元々の進捗チームの都合に合わせてレンタルしていくってイメージの方が強いかったですね僕は
げんえい
そうですね
きんじょうひでき
逆にこの水準まで持っていくか持っていくまで出られない部屋みたいなチームなんだとしたらどうなんですかね
人事部とか組織開発寄りのミッションの人になるんじゃないかなっていう気がしますよね
すごい感覚的な話ですけど
げんえい
確かにそうですね
きんじょうひでき
それこそCT用室みたいなところ
げんえい
確かに新卒の頃いろいろ思い出したなと思いながら
きんじょうひでき
新卒の頃思い出しても何も出てこない
げんえい
自分が新卒だった時はコードかけそうなやつから自分にこう出荷されて客先に出荷されてたなと思いながら
そういうのはありますね
でそれまでははいSTRATZでECサイトを作ってみたり
突然Androidアプリを作らされたりみたいなことをやってる人を見たなみたいな気持ちが
いやこれは架空の話かもしれないがそういうことがあったかもしれないですねって思いながら
きんじょうひでき
その場合はある程度の技術試験みたいな
試験じゃないかもしれないですけど一定の基準があってそれを満たせばOKみたいな話なんですか
げんえい
基準ってよりは自分で調べて解決できてそうなやつから順にみたいな感じでしたね
つまり現場に入れても何とか自分で何とかできるやろうみたいな人
でできなさそうな人は期限が決まっていて
それが終わったらどっか現場に先輩社員についていくみたいなそんな感じでしたね
きんじょうひでき
あとあれか一応これ本の内容に立ち替えると
さっき新人研修みたいな話を例に新人っていうか新卒研修みたいなところを例にしたんで
ちょっとこの本で書かれてるイメージと少しずれるかもなみたいなところで言うと
原文まま読み上げると進捗チームにシステムの85から95%を設計してもらおう
そして訓練チームはシステムの5から10%をデリバリーすれば良いことにして
訓練の質を高めることに集中してもらおうって書いてあって
これだから新人の託児所に預けられた人たちも実際の開発実務デリバリーの責任を負うっていうことか
訓練チームって言ってるのはこれはどっちですか犠牲になった人たちを指しているのか新人たちを含んでいるのか
げんえい
これは要は会社内にこのチームは進捗を出してもらって
その新人を集めた訓練チームはお膳立てが終わっていて後はゴール前に行ってシュートを打ってくださいみたいなチームで
実際にプロダクトコードを書いて出荷はするっていうことかなって思いますね
きんじょうひでき
難しい仕事の部分はあれ程度やってもらって後はこの託児所に従ってまずはコードを書いてみようみたいなそんな感じのイメージですかね
続きに書いてありますね訓練チームが単純に訓練だけをやることがないようにしようとか
さっきげんえいさんが疑念を抱いてた関連に言うと
訓練チームの人が十分プロジェクトに貢献できるようになったら進捗チームに移動させようって書いてあるんで
僕が言ってた技術できるみたいな世界観とはやっぱり別の想定をしてますね
進捗チームの役割
きんじょうひでき
いやー難しくねどのくらいなんだろうな
げんえい
そうなんですよ
きんじょうひでき
どのくらいのレベルの人たちかけるどのくらいの人数を想定しているのか
げんえい
しかもそれをずっと抱え込んでおけるほど体力があるというかなんていうかその訓練チームの
ある期待値よりも会社の視点でいうとかかってるお金よりも
かけてるお金よりも低いアウトプットとかアウトカムが出てきている人たちを
どれくらい面倒見れるかみたいな部分もあるわけじゃないですか
きんじょうひでき
全員友達折れするよりかは卓持書パターンやりましょうっていうニュアンスもすごい込められてると思ってて
だから誰か一人を犠牲にするっていうパターンからつながってるし
あともう一個常に誰かが進捗させるパターンからの連結でもあるんですよね
げんえい
そうですねそうですね
きんじょうひでき
進捗チームっていうのが新人の子守育成に夜勤になってゴリゴリ生産性削られて
誰も幸せになれませんでしたっていう最悪の事態をどう避けるかであって
だから教育の質を上げるみたいなところは多分別の話なんだろうな
もしかしたらこのパターンからさらに派生してどうするっていうのがこの後出てくるかもしれないですけど
げんえい
マイナスロスを減らしましょうみたいな多分思考だと思うんですけど
じゃあそれっていつまでやってられるのっていうのはありますよねとか
一番最初に疑念に思ってたのは結局どういうチーム構成にしたりとか
どういう場所にいたらその人が成長するとかいろんなものを身につけられるかっていった時に
新人同士で本当に一つのチームでメンターみたいな人がいて
ちゃんとチケット内緒のお膳立てがあるような
簡単なコードを書いてリリースしていくことから始めてだんだん難しくしていくって言って
チームにその人がパッと別の卒業して他のチームに入った時に
うまくいくように育っているというかやっていくって難しいだろうし
実際パッて入ったらあれなんかやっぱり周りのレベル高いなとか
周りの人って新人のチームにいる多様性とは全然違う多様さがあるはずだから
年齢が違ってコミュニケーションの取り方も違ってとか
自分のバックグラウンドが全然違うってことがいかに言葉が伝わらないかってこととか
そういうものをきっと体感することってあるだろうと思っていて
そういうことはなかなかそのチームでは学べないよなっていうのは思っていて
全部をそんな手に入れるなんて贅沢だから無理だよみたいな気持ちもあるんだけども
なかなか難しいなってちょっと思ったりしました
きんじょうひでき
そうですね ただ卓上章パターン使うような実態っていうのは
さっき言ったコンテキストとして進捗っていうのを誰かが
常に出せる状態っていうのを支出しましょうとか
どうしても無理な時は誰かを犠牲にしてやりましょうみたいな
コンテキストから来てるよねって考えると
もう本当に最低限ある程度使えるようになったら
進捗チームに送り込むのかなみたいな気がしますよね
ドメイン知識とかしっかり身についてて
ある程度の仕様をディレクターの言葉でもらえば
スラスラと実装入れますみたいなレベルまで成長することはもちろん望まないけど
ただ最低限フレームワーク上で自然なコードを書けるようになってくれとか
テスト書いたらバグトラッキングというか
トラブルシュートを自分である程度できるぐらいには
バグの調査とかできるぐらいにはなっててくれっていうところまで行ったら
プロジェクトの機能向上
きんじょうひでき
よしお前死んでこいみたいな感じで送り出す的な具合じゃないですかね
げんえい
たぶん現実的な落としどころはそこぐらいですよね
いかに自立して一人で作業できるぐらいまで
指示をもらったら作業できるところまで行けるか
きんじょうひでき
じゃないかな
げんえい
このパターンいいかもしれないなっていうのは思ったりとかしつつも
どこまで面倒見るとかそういうところいろいろ気を配る必要があるかな
みたいなのはちょっと気になったんで
一番機能してみたいなって思ったパターンでした
きんじょうひでき
でもそうですよねまさに人月の神話的に人増やしても早くならない的な話でもあるよっていうのは
触れられてますねちゃんと95ページで
げんえい
そうですね
きんじょうひでき
じゃあ次行きましょう
げんえい
次行きましょう
きんじょうひでき
じゃあ4-2行きますか
組織の前進的成長のためのパターン言語
さっきのがプロジェクトをどうやって機能させるかみたいな話だったのに比べて
プロジェクトを生み出したり運営したりする土台より機関の部分で組織っていうのがあるけど
4-2のこれから話すのは少しプロジェクトっていうところよりも
もう少し広い部分土台の部分の組織っていうのを
どうやって育んでいくかっていうところに少し目を向けた話ですね
こっちも信頼で結ばれた共同体から始まっていって
順番でいくと組織を細かくするからですか
げんえい
そうですね
きんじょうひでき
組織を細かくするはでかいとこもあるから細かくしましょう
ジェフ・ベゾスが言うようなワンピッツァルール的な話
トゥーピッツァー
トゥーピッツァーだワンピッツァー少ないか
ですけどこれ書かれてること面白いんですよね
こんな丁寧に話すんだみたいな
げんえい
そうですね
きんじょうひでき
この本でも基本は10人集めようみたいなチームのサイズとしては
げんえい
そうですね
きんじょうひでき
でプロジェクトの終盤になって人を追加したり技術から逆算して
作業をしたりしようとしたりするのはやめようって書いてますね
げんえい
まあそうですよね
終盤に人を集めるともう嫌な記憶しかない
ちょっと面白いなと思ったのは大規模なソフトウェアっていった時に
ソースコードでステップで上がるんだっていうのが
当時って感じがするなってちょっと思いました
きんじょうひでき
確かにでも他にないですよね指標
モジュール数とかだと言語のあれが出てきちゃうし
げんえい
でも我々は今大規模なソフトウェアっていった時に
全然行数で話してないよなって思いながら
きんじょうひでき
話してないですね
げんえい
現代っぽく言うとマイクロサービスが何個立ち上がってますとか
たまに出てくるのはファイル数が何個あってみたいな
とかいう言い方はするかなぐらいな感じ
きんじょうひでき
ただそんじゃそこらのマイクロサービスに負けないような
大きな泥団子があったりしますもんね
げんえい
そうなんですよねマイクロサービスを
きんじょうひでき
足し合わせでもちっちいじゃないかっていう
マイクロサービスあったりしますもんね
げんえい
そうなんですよねそこで区切りますみたいな場合もあるし
意図的にマイクロサービスを選んでない場合とかも
全然あるんでねなかなか
あと世の中のソフトウェアがどんどんでかくなってるせいで
相対的にちっちゃく見えるっていう問題ありますよね
きんじょうひでき
ありますねで逆に言うと
言語とかライブラリとかフレームワークが進化して
短い量でよりパワフルになってるんで
短い量数とかモジュール数で
どんどんどんどん好きなことができるみたいな
げんえい
GoogleとかAmazonのソフトウェア規模に比べたら
全てが小さいのではって気持ちになるし
きんじょうひでき
それはそうなんですよ
大谷翔平の家に比べたら3LDKってちっちゃいよねみたいな
げんえい
そうそう
広いよみたいな
3LDK広いよって感覚だけど
大規模っていう感覚っていうのが
当時と今ではちょっと違うなって思いながら
でも客観的に測ると
プロジェクトの段階的実行
げんえい
そういうことしかできないんだな
みたいな気持ちもちょっと思ったりしましたね
本日とあれですけど
きんじょうひでき
ただそう大規模プロジェクトを始めるのに
住人が多すぎるっていう表現をしてるんで
面白いですよね
サイズソフトウェアのシステムとか
プロジェクトの規模っていうとあれか
ソフトウェアシステムの規模に応じて
人数も比例的に増えていくよねって
考え方って間違ってるんじゃないか
いいようなこと言ってるようにも見えるなと思って
げんえい
そうですね
多分これの前提ってやっぱり
人を集めて労働集約的に
工場みたいなものが前提にあったりとか
もしかしたらビルの建設だったりとか
そういうものなのかもしれないですけど
それの感覚で来て
大規模のソフトウェア作るのに
何人いりますか?100人いりますか?
200人ですか?みたいな感覚で
10人だと多いですよねみたいな
そういうことから来てるんだろうな
みたいな気持ちにはやっぱりなりますね
きんじょうひでき
そしてよく見ると
ここにもデマルコが出てきてるっていう
そう
プロセスから恩恵を受けることになる人は
誰もがプロセスの作業と
プロセスの意思決定に関わらなければならない
考えるとあれですよね
会議室に入れるぐらいの人数にしましょうね
みたいな感じですよね
そうですね
ミーティングに呼ばれなくてもいいか
っていうぐらいの人は
そもそも入れない方がいいよみたいな
感じも印象論ですけどありますね
げんえい
そうですね
だからソフトウェアってそう考えるとやっぱり
すごいですね
少ない人数で大きい成果を出すっていう
きんじょうひでき
DHH
げんえい
大変してるからな
そしてそれを本当に
きんじょうひでき
とはいえでかくなっている
でかいもの
人間一人ができることって
げんえい
上限があるでしょみたいな話に対しては
きんじょうひでき
分割統治とかっていうパターンが出てくるんで
そことも肝心してくるかな
とは思うんですけど
直接的に言及はしてないですね
げんえい
そうですね
直接的にはないですね
きんじょうひでき
あとよく読んでみると
暇なやつは自分勝手に仕事作って
よく分かんないことを作るから
暇な人が浮いてる人ができるぐらいの
規模にするんじゃねみたいなことが書いてあったり
げんえい
そうですね
でもそういう暇な人が
いろんな改善的なことをやってくれると
助かるんだけど
そういう意味では
暇な人が出てくるぐらい
チームにゆとりがあったほうが
きんじょうひでき
そうですね
げんえい
ボール拾いしてくれて助かるかもしれない
きんじょうひでき
冒頭で触れとくべきだったんですけど
パターンランゲージっていう体系にしてるのが
ちゃんと自分たちの今置かれてる状況
コンテキストっていうのを判断して
それに応じて好きなものを選びながら使いましょう
そういうことができるのが
このパターンランゲージ意識の記述の良さだよね
っていうふうに書いてあって
次のレベルのチームになるためには
これとこれとこれが達成されてないといけません
げんえい
みたいな話じゃないよみたいなことが書かれているので
きんじょうひでき
だから今言ったゆとり持って
読み渡せる人がいた方がいいんじゃないかっていう話と
チーム暇な人が出るぐらいチームを
ラブ付かせるんじゃないっていう話は
多分そこだけ切り出すと
すごい矛盾してるんですけど
どっちもちゃんと一冊の本の中に
共存できるっていうのが
良いところ強みですね
げんえい
そうですね
絶対にこれに従ってこうしなさいっていうわけではないので
きんじょうひでき
っていうところで次どっか行きますか
げんえい
その前に行くと段階的に人を増やすかなっていう気もして
きんじょうひでき
段階的に人を増やすはありますね
いきなりチーム立ち上げたときに
いきなり10人ドーンって
10人だといいのかな
15人とかドーンって呼んでも
まだやること決まってないですとか
やれることないですとかになっちゃうので
フェーズに分けて入れましょうみたいな
例えば1回CICDとかの基盤できたら
開発のスピード上がりやすいから
あとはたまに聞くのが
本当の基本設計というか
例えば技術選定が終わって
こういうアーキテクチャー
こういうレイヤードを入れていきましょうみたいな
ところが整った段階で人を入れましょうとか
っていうのがあったりしますよね
あとやることが明確に決まったから
ここはもう後はタスク潰すだけってなったら
ある程度人をバッて入れてみたりとか
げんえい
自分の中ではそういうのを言うときに
効果があるってことが分かったら
あとは効率を目指すために人を増やす
みたいなことを考えたりは結構してますね
なんでそのアーキテクチャーだったりとか
作るものだったりとかに
作る価値があるんだねって分かったら
あとは守備範囲を広げていくというか
やることをやる範囲を広げていって
効率的に多くのものを作り出して
いわゆるアウトプットがアウトカメに
どんどん近づいていく状態みたいな
できると人増やしていっても
意味が結構あるかなみたいな
と思ったりとかしてますね
きんじょうひでき
あとあれですよね
プロトタイプ作るところまでは
パイロットチーム的にまず3人でやってみて
これ正式なプロダクトとしてリリースしようぜ
ってなったら
プロジェクトのフェーズを区切るでもいいんですけど
そもそも別のチームとして
同じプロダクトを作るものとして
再組織化するみたいなやつとか
あったりしてますよね
げんえい
まさにそれをやってますみたいな感じですね
別に狙ってやったわけじゃなくて
何作るかわからんけど
とりあえず人は集めたから
って最初3人ぐらい集められて
よしじゃあ俺たち何やるか決めようぜ
ってまずチームとしてどこに行くんだっけ
みたいなことを決めながら
じゃあとりあえずパイロット版作ってみて
こういうことだったら技術的にはできそうだね
みたいな検証して
じゃあ本当に作っていこうねってなって
1回そのコード捨てて
もう1回ちゃんと作っていくみたいなことを
まさにちょうど今やってますね
きんじょうひでき
いいですね 良さそうですね
チームの成長とビルディング
げんえい
そう だから段階的に人を増やすの
ちょうど明日からまた人が2人増えるんですけど
きんじょうひでき
宅自称作んなくて大丈夫ですか?
げんえい
宅自称は作んなくて大丈夫です
大人がもうチームに入ってくるんで
それもやっぱり人が増えるから
ってことは大きいこの機能の中の
これとこれとこれをもう何か依存関係なく
バッドをどんどん作っていける状態に
人が増えたことによって
ちゃんとポイントが
ポイントを消化することが
良いことではないかもしれないんだけども
もっとアウトプットとか
アウトカムに繋がるような
アウトプットが出せるような状態を
チームとして作っておいて
じゃあ人が来たら
もうあとはこれを
まさっき近所さんがタスクを潰すだけ
みたいな言い方をしてくれたけど
そういうような状態を作っておいて
上手くやっていくぞみたいなことを
結構意図的に設計して
最近は仕事してますね
きんじょうひでき
その場合って
チームのアイデンティティみたいな
例えばインセプションデッキとか
我々はなぜここにいるのかみたいなのって
あれって関わる人が全員参加で
同じ目線同じ立場で話せることで
より効果を生みやすいと思ってるんですけど
途中から人が増えたねとか
このチームとしてのフェーズ変わったよね
っていう時って
どういうふうに扱うんですか
げんえい
一応今のところは
インセプションデッキみたいな
今こういうものは過去やって
今チームとしてはこういうものです
みたいなことは伝えるものの
でもそろそろもう1回作り直したりとか
こういう前提あったけど
今人も増えてきてとか
そもそも何を作るんだっけ
このチームはみたいなところから来たんで
だんだん作るものが決まってきたから
もうちょっとゴール明確にできそうだね
とかがあるから
もう1回じゃあ今チームの状態を振り返りつつ
自分たちは今どういう立ち位置にあるんだっけ
みたいな振り返りをしてもいいかなと思って
直近でリリースがあったりとかするんで
ちょっとそれバタバタしそうだから
それが終わったら人も2人増えるし
もう1回チームビルディングやってもいいかな
みたいなことは考えてますね
きんじょうひでき
なるほど
ここに決まったステートメントがあります
っていうふうになって
そこに評価等いくというか
すり込んで洗脳するんじゃなくて
ちゃんと改めて向き直りしてみましょう
みたいなそういう繰り方になるんですね
げんえい
そうですね
だしある程度今自分たちはこういうチームだから
ステートメントがあるから
それに合いそうな人をちゃんと探してくるというか
いうようなことは
要はこのチームに入ってなじめるよねとか
うちらはこういうやり方なんだけど
それに対して嫌だなって思うような場合は別に
ちょっと合わないから
うちのチームじゃないかもねっていう風な
事前のなんていうか
きんじょうひでき
カルチャーバッジを見て
げんえい
みたいな社内だけでもやったりみたいなことはしてますね
まあそうだよな
きんじょうひでき
なるほどなるほど
げんえい
だからある種これがこう4.2.11の
自分たちで選んだチームみたいな
そこにつながってくるのかなみたいな話でもありますね
37:26

コメント

スクロール