本の紹介と背景
きんじょうひでき
こんにちは、readline.fmです。readline.fmは、つんどくが趣味の2人が、何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、ハッシュリードラインFMです。Mixi2にもコミュニティがありますので、ワイワイや感想などお待ちしております。
ホスト役は、ゲイエさんと金城です。それではゲイエさん、よろしくお願いします。
げんえい
よろしくお願いします。
きんじょうひでき
はい、というわけで、今回はちょっと特殊回ですね。
げんえい
そうですね。
きんじょうひでき
緊急で動画を回しておりますみたいなことをすると。
げんえい
そうですね。
きんじょうひでき
何の本を読んでいきますか?
げんえい
今回は、チームの力で組織を動かす、ソフトウェア開発を加速するチーム志向の組織設計です。
きんじょうひでき
収録してるのが9月なので、ギリギリ。
げんえい
発売して1週間くらいですかね。
きんじょうひでき
そう、発売して1週間の本なので、今回は積読じゃないんじゃないですか。
げんえい
届いた日にはもうパラパラ読み始めてましたね。
きんじょうひでき
そうですよね。あんまり熟成を効かせてない本を取り上げることもできるんだぞという感じですね。
げんえい
そうですね。
きんじょうひでき
この本を取り上げたきっかけが、ワインバーグの本を連続で読んでてやや疲れたね。
げんえい
そうですね。古い本で読むのが大変だし、一発最近のもので気になってるものでも読んでみるかみたいな話を収録終わった後にしてて、
そういえば最近出る本で面白そうなんだけどっていうところで取り上げたっていう感じですかね。
きんじょうひでき
これは界隈で話題になるやろみたいな本がちょうど来週出るじゃん。じゃあこれやるかって。
げんえい
ページ数とか中身も確認せず、とりあえず一旦届いたらこれを読みましょうっていう話をしてましたね。
と言っても本当に中身全く知らないとかっていうわけではなくて、
著者の松本さんのブログとかはハテブだったりとかツイッターのタイムラインとかで話題に上がっていたので、
この人の書く本だったらきっと面白いだろうっていう見立てというかきっと面白いはずっていうのは前提としてありましたね。
きんじょうひでき
あと先に読んでた人は見本を受けて読んでた人の感想とかもちらちらと視界に入ってきて、
とても面白いんじゃなかろうかみたいな感じはしたので、
ということで二人してこの本なら読んでみていいんじゃないっていう感じがあったというところですかね。
げんえい
そうですね。
きんじょうひでき
なので発売したばっかりなのでいつもみたいに1章からなんだかんだ最終章までダラダラダラダラ触れていくっていうのはあんまり良くないんじゃないかという縛りがありますね今回は。
著者の視点と内容
げんえい
そうですね。最初に言っとくとこの本はやっぱいい本だなって思ったので売れてほしいと思ってるので、
詳しくはこの本を読んでくれっていう風な感じに今回のエピソードは思ってますね。
きんじょうひでき
いつもなら大体30年とか50年とか経ってる本なんで、ネタバレも何もないやろみたいな感じはしてるし、
げんえい
そうそうそう。
きんじょうひでき
著者の松本さんご自身が過去の発表、登壇資料だったりブログだったり内容にたくさん盛り込んでる印象もありますし、
あと発売後に発売記念イベントみたいなのを立て続けにやってらっしゃってそこの話の内容ももちろんですけど資料も非常にわかりやすくて面白かったですもんね。
げんえい
そうですねそうですね。
きんじょうひでき
面白かったですしあそこで話されてる内容は割と素直に本の内容を辿ってるなっていう印象があったので、
どうしようかなこの本買おうかな気になるなっていう人はちょっと見てみてもいいかもなっていう気がしますね。
げんえい
迷ってるんだったら読んで買ってもらうでいいと思ってるけど、買っていいんじゃないっていう。
きんじょうひでき
買っていいと思う。
げんえい
もう悩まずにとりあえず買っていいんじゃないって思うぐらいには自分は手元に置いておきたい本だなっていうふうに思っていましたね。
きんじょうひでき
じゃあ全体の感想というか入ってきますか。
げんえい
そうですね。
きんじょうひでき
どこら辺からシェアしたいですか。
げんえい
いったんあれですかねこの本がどういうことが書かれているか。
タイトルは今紹介したけどもその全体感みたいなところですかね。
こういう時に便利なのが出版社のサイトにこの本の紹介文っていうのがあるので全部読むとちょっと大変なんでちょっとかいつまんで説明をしますと。
チームという単位をないがしろにする組織はうまく機能しませんよと。
日々の業務フローが複雑で入り組み非効率になりがち。
例えばプロジェクトが成功したとしても再現性がなかったりとか現場はいつも手一杯で余裕がない状態が続きますと。
そういうような組織の問題っていうものを組織設計の視点から解決に導きます。
チームを最小単位とするチーム思考に基づく組織設計によって組織問題を解消することを目指しますよっていうような本ですね。
対象読者は組織設計を担うエンジニアリングマネージャーとか現場で働くメンバー。
多分ここで言うメンバーって言ってもリーダーぐらいでちょっと周りが見えてるような人たちの問題把握に役立ちますよみたいなことを書いてありますね。
きんじょうひでき
あとはイベントで話されてたのあの表紙を見てみてくださいと。
表紙の左側に3つの円があって、行動品質の悪さ、ミーティングの多さ、開発の多さっていうふうに書かれてて、これらが組織設計に原因があるんだっていうようなことを言ったりしているんですよね。
ソフトウェアなしプロダクト開発に関わる開発生産性がとか品質がみたいな話言って、実は組織設計によってもたらされてるとか、あるいはそこを何か問題をちゃんと見極めて工夫するとすごい軽減したりとか解消したりとかできるんじゃないかっていうようなことを提示してくれる一冊でしたね。
げんえい
目先の問題を解消するってよりはもうちょっと大きく広い視野を持って、どこが入り組んでるんだっけ、なんでこの問題が起きてるんだっけ。
きんじょうひでき
ある種システム思考というかっぽい感じで、全体を見た時にどこを直すとこれがうまくいくんだろうみたいな、そういう視点を手に入れるような、そんな本だなって思ったりもしましたね。
システム思考の話も出てきてましたもんね。
げんえい
確かあったような気がしますね。
きんじょうひでき
あれ、でも作品にないかも。いや、でも触れてないわけがないという自信があるな。
げんえい
イベントの中でシステム思考という言葉を使ってたような気が。
そういうような前提があるような感じですかね。
きんじょうひでき
そうですね、なんかノートブックLMみたいな会話は。
そうすると対象読者みたいな話はありましたけど、改めて読んでみてどういう人に勧めたいなーとか、タリアとかロールとかって話もあるかもしれないし、
こういうところにこういうシチュエーション、こういうコンテキストで困ってる人はこの本手に取ってほしいなー的な、お勧めしうるターゲットみたいな原因さん的にありますか?
げんえい
自分の中では読みながら思ってたのは、この20年ぐらいのソフトウェア開発のプロダクト開発の文脈の中でどういうような変化があったかみたいな、
そういう歴史的なことを知りたい人っていうのはすごくいろんなキーワードだったりとか、出版されてターニングポイントになるような本だったり論文だったりっていうのは紹介されてるんで、
そういうところをざっとまず抑えたいなとか、そういうところに知見がまだ明るくないなっていう人に向けてはこの1冊まず読んでほしいなっていうふうに思いました。
もう一方で現場とか組織を設計するぞっていうふうに思っている人がソフトウェア開発をやってる現場に入った時に、この本の言葉を言えば例えばリソース効率を重視したりとか、
なんか暇そうにしてるやついるからちょっとこれやってくれないみたいなことをやって、その後プルリクエストがバンバン飛んできてコードレビュー時間を取られてとか、
あと知らないコードを触っていろんなものが起きるとか多分いろんな経験をすると思うんですけど、そういうようなことが何で起きてしまうのかみたいなことに関して疑問を持っている。
今までの自分の一般常識としては、暇してる奴がいたら仕事させた方がいいし、プロジェクトを作ってそれを達成するんだみたいなことが今までやってきたんだけど、
そうじゃないような考え方っていうものが世の中にあるんだっていうことを気づいてもらうために、そういう人と一緒に読みたいなって思うような、そんな本でしたね。
実用性と読者へのメッセージ
きんじょうひでき
そうですね、僕の感想で言うと、ゲイさんが言ってくれたところはゲイさんが言ってくれたからいいかっていう感じであるんですけど、
一言にEMって言っても何かいくつかレイヤーというかになってる役割みたいなのがある気はしてて、初めてエンジニアリングマネージャーになった時ってそこまで組織設計みたいなことやらない気もするんですよね。
まずはあなたの目の届く範囲のチーム数人を面倒見てみてくださいみたいなところから始まると思うんですけど、そこから少しずつ経験積んでいったりとか立場が変わっていくにつれて、
より大きい、どういうチームを何個作るかとか、どういうプロジェクトをどういうロードマップで立ち上げるかとか、そういう規模の話により主体的な立場で関わるようになってくると思うんですけど、
僕はどっちかっていうとその校舎の役割を担い始める、もしくは担うようになりそうだな、次のクォーターからぐらいの人とかが読むと、
多分本当にジャストインタイムにというか、その場で役に立ちそうだなっていう気がしてますね。
そういう人たちにお勧めしやすい本って結構少ない気はするんですよ今まで。
いきなり経営論の話に踏み込めばいいのかとか、戦略の立て方みたいな話に突っ込んでいくしかないのかっていう感じはするし、
本当はスクラムとかXPとかを勉強して良いチームとはっていうのを突き詰めればいける気もするし、
リンスタートップについて勉強すればいかにしてフロー効率を高めるかみたいな話はできるかもしれないんですけど、
組織設計どうやって実装していくのっていう観点でちゃんと包括的に話してくれてる本ってあんまりこれはなかった気がするので、
そこの空白を埋めてくれる本だなっていう気がしてて、
実際僕がマネージャーやってて、他のマネージャーたちとここから半年プロジェクトどのタイミングで立ち上げて、
誰をどういうふうに何人ぐらいアサインするみたいな話してた時に、
兼務はやめさせず、プロジェクト1個ぐらいそのために送らせるなんて全然ありだろうみたいな話をしてたわけですけど、
やっぱり投入できる基盤、土台になる本が少なかったんですよね。
組織パターンを読めって言っても誰も読んでくれなかったからっていうのが、
すげー損失だなと思ってるんですけど。
かといってさっき言ってたDOCの制約理論の話とか、
リーンなんちゃらの本とかの話を読んでると延長的というか、本質はそっちなんですけど若干後一歩に行くといいんですよね。
EM同士の会話なんで頭使いましょうっていうのは当たり前なんですけど、
じゃあプロジェクト何を立ち上げて誰をアサインしますかっていう話には、
そこのショートカットしたいなっていう意味ではこの本が欲しかった。
もうちょい早くあれば嬉しかったなーっていう気がする。
げんえい
うん、確かに。
事業戦略とかプロダクト戦略みたいなものと現場を上手に結んでくれそうみたいな、
そんな期待ができそうな感じの話だなって今聞きながら思いましたね。
きんじょうひでき
最初に言ったEMって言ってもいくつかグラデーションはあると思うんですけど、
例えばCTOとか部長みたいな人、上の人と組織設計どうするのっていう話をしたり意見求められたり、
するぐらいの感じのEMの人はもう読めっていう感じがしてます。
げんえい
そうね、そうです。役立つ話がたくさん載ってます。
きんじょうひでき
そう、この本を読んでめちゃくちゃ新しい知識が手に入ったぜ、
これ知らなかった、やった感動したっていうよりかは、
これを武器として装備することによって、
いろんな障害っていうか話が通じない相手を叩けるって言い方よくないな。
ショートカットができるようになるなっていう気がしてて、
という感じですね、私としましては。
げんえい
今の金城さんの話を聞いたりとか、メモを見ながらですけど、
今いろんなキーワードみたいなものが出てきたと思うんですけど、
制約理論だったりとか、フロー効率だったりとか、
キーワードはこの本にも散りばめられてるし、いろいろあるんだけども、
結局それを全部勉強して現場につなごうと思うと、
30冊か50冊ぐらい読んで、
自分の頭で考えて、これをやるとこういう問題が出てくるから、
それはやらないようにしてとかって、いろいろ考えないといけないけど、
この本があることによって、ギュッとそれをくっつけた状態で装備させてくれるから、
全部自分で説明書を読まなくても、
装備が一通り使える状態に一気になれるから、
そういう意味では本当に役に立つというか、
いい本だなという気もしましたね。
きんじょうひでき
そうなんですよね。
30冊、50冊って別にEMになった時点で読みよっていう感じはするんですけど、
人に統制できないじゃないですか。
げんえい
はい、そうですね。
きんじょうひでき
そういう辛さがあるので、その点でいうと、
まずこの本は本当に全体マップというか、
薄くってほど薄くもないし、
ちゃんと手広く、網羅的に、
漏れなく、一応そういう話をしてくれてるんで、すごいありがたいし、
あとどうやって現場に接続するのっていう目線で、
すごい書かれてるなっていう気はしてるので、
それがありがたいですね。
げんえい
すごいイメージが湧きますよね、この本読んでて。
問題の可視化と対応
げんえい
事例としてアンチパターン紹介とかもあったりするし、
じゃあそれに対してどういうふうに、
どういうプラクティスを適用して解決していくかみたいな話、
みたいな事例がたくさん載ってるので、
そうなると、この問題うちでも起きてるなみたいなことが、
多分読んでる人の頭の中に浮かんで、
そういうものに対してこういうふうな対処の仕方があるのかとか、
こういう考え方があるのかみたいなところとかっていうのが、
直接書かれているので、あるあるって思いながら、
いやでもそれどうにかしないといけないんだよなみたいなところで、
じゃあ次アクションどうしてみようかって、
そのまま考えていけるような、スッと使えるって感じになってますね。
きんじょうひでき
うーん、そうなんか問題が見えやすくなりそうですよね。
げんえい
うんうん。
例えばリファクタリングしたいですとか、
じゃあ例えば品質が悪いですっていう、
みんなの感想は聞こえてくるけど、
なんでそれが生み出されてしまうのかとか、
直せばその問題が解消されるのか、
結局もう一回また起きるんじゃないかとか、
そういうところって、その会話をしている時には、
なかなかやっぱ考えられないんだけど、
この本を読むことによって、
それを生み出すメカニズムみたいなものが、
組織の中にあるはずだっていうふうな考え方になっていくと、
どんどんどんどん物の見方が変わっていって、
それによって組織っていうものの設計の大事さだったりとか、
チームっていうものを維持することの大事さ、
みたいなものがわかってくる。
そこが見えるようになると、
全然問題の向き合い方が変わるよねっていう気になりますね。
コミュニケーションの設計
きんじょうひでき
うーん、それこそチームの分け方の機能を別にするか、
機能っていうのはフィーチャーの方の機能、
プロダクトごととかに対して、
水平っていう言い方してましたけど、
バックエンドとかフロントエンドとか、
企画とかっていう分け方すると、
それって結局こういう症状が発生して、
結果としてこういう問題になるよねっていうような話が、
この本を読むとちゃんと、
それとかめちゃくちゃわかりやすい例だし、
いろんな本で売れられている話だと思いますけど、
そういう例だけじゃなくて、
組織設計上のアンチパターンがあるとか、
問題の形としてこういうふうに症状が現れるとか、
だからこういうアプローチしてはいかがっていうところまで、
ちゃんと触れてくれているので、
なるほどって感じ。
こういうメガネみたいなものをかけて、
自分のいる環境というか周りを見渡してみると、
なるほど、うちの組織ってこういう構造になってて、
ここがいびつなのかっていうふうに、
ちょっと気づきやすくなるんじゃないかなっていうのがいいですよね。
シチュエルアンチパターンみたいな。
名前がついたりとか、
知識として形式化されると世界が変わる、
げんえい
見え方が変わるみたいな。
こういう体験をするのが自分は結構好きなので、
読書してて、別に技術書だけじゃなくても、
他のもの、秘境とかを読んでもそうですけど、
こうやってものを捉えると見ると面白くなるんだとか、
その発想は自分になかったなとか、
こことここって意外と共通してるんだな、
同じような相似形なんだなとか見つけるって、
すごい自分にとっては楽しいことなんで、
この本はものすごい楽しいんですよね。
きんじょうひでき
ふわふわっとした話ばかりしてるんで、
具体的にここ面白かったなとか、
ここをぶっ刺さったわとかってありました?
げんえい
そうですね。
この本の中でコミュニケーションコストと
フロー効率みたいな話をしているところが4章であったんですけど、
コミュニケーション不足ですっていう話と、
ミーティングが多いっていう話って同時によく聞くなって思って、
なんかそれ不思議だなってずっと思ってたんですよね。
どっちやねんみたいな気持ちにもなるし、
コミュニケーション取らなかったらうまくいくんだっけとか、
いうことを思ったりとかしていて、
そういうことに関してこの本では、
コミュニケーションパスの設計だったりとか、
チームの分け方だったりとかによって、
コミュニケーションってどうやってなされているの?
っていうふうな話があったり、
一番最初に出てきたのがスパゲティ組織ってやつで、
プロジェクト体制が組織内で複雑に絡まっていて、
あっちとこっちともコミュニケーション取らないといけないみたいになって、
きんじょうひでき
そうね、GO TO GO TOみたいなやつね。
げんえい
そうそうそうそう。
でも確かにこうやって図にされたら、
あれなんか喋んないといけない相手多いなみたいなことって、
たぶん誰が見ても気づくんだけど、
でも普段たぶん現場にいるとだんだん慣れてきて、
頭の中に収まり始めると、
なんか大変なんだけど何とか回るしなみたいになっちゃうんだけど、
でもこういうことってちゃんと見直すタイミングがないと、
なかなか難しかったりするから、
じゃあその中でいろんな話が出てくるんだけど、
どうやってそれに対応しますかっていう話もあるし、
この辺は結構好きだなって思いましたね。
きんじょうひでき
やっぱりあれですか、組織パターンのインタラクショングリッドを書いてこう、
縦軸と横軸にロールを並べて、
インタラクションが発生している、クロスするところを色を濃くしていって、
本当は離れてるはずの、
ここの部署とここのチームがなんか会話してるっぽいぞみたいな話を、
コプレーは何十年前にしてるんだってことなんですよね。
げんえい
そうなんですよね。
でもまさに読みながら、組織パターンで読んだなっていう話でもあるなって思ってて、
なかなかあそことこの本を接続するっていうのも大事だなってことをちょっと思ったりもしました。
きんじょうひでき
マジでいい本だからな。
コミュニケーションの話で言うと、
チーム内のコミュニケーションの待機幅はめちゃくちゃ広くして、
チーム外の無駄なコミュニケーションを減らしましょうっていうような見方をしてましたね。
あれは結構好きだなっていう気がするな。
げんえい
あれは元ネタがチームトポロジーから来てるんですかね。
きんじょうひでき
この本がめちゃくちゃチームトポロジーベースですよね。
バリューストリームの重要性
げんえい
そうですね。ストリームアラインドなチームを作りましょうっていう話が出てきたりとかするのも、
元は多分チームトポロジーが元ネタになっているはずなので。
きんじょうひでき
リーン思考とチームトポロジーと、あとちょっとダイナミックリチーミングみたいな。
げんえい
はい、ありましたね。
あとデブオプスがあるから、リーンとデブオプスの価格もか。
基本的にその辺りがこの20年ぐらいのキーワードみたいなところを拾っていくと多分そうなって、
スクラムだったり、XPみたいなアジャイルみたいな価値観も合わせると、
大体この本が出来上がってくるみたいな、そんな感じですよね。
この本がチームを中心にっていう話になってるのも、
もちろん現代においてチームが大事だよっていうところはもちろんあると思うんですけど、
大事だよって言われてる背景の中には、
Googleのプロジェクタリストってやつだったりとか、
チームトポロジーだったり、ダイナミックリチーミングだったり、
アジャイルなチームみたいなところの話だったり、
そういう前提がある上でこの本が出来上がってそうっていうのはちょっと思ったりもしましたね。
きんじょうひでき
今までだと組織か個人かみたいな二択でしたもんね割と。
当然チームっていう概念はあるし、意識はしてるんだけど、
個人の力を1たす1を2じゃなくて2.5とか3にするためにチームっていうのを使いましょうぐらいの、
個人が主、チームがサブぐらいの感じが、
もしかしたらこういう系統の本を読むとあったのかなっていう気もするんですけど、
この本は徹底的にチームっていうのを一流市民にして、
チームから組織を動かすし、
チームの中にいる個人っていうのはもちろん大事だけどっていうぐらいの雰囲気があるな。
げんえい
なのでね、読んでてすごい耳障りがいいんですよね。
普段からすごい意識しているし、摂取しているような情報だなっていう気持ちもあり。
きんじょうひでき
それはあれですよ、我々がずっと1970年代の本を読んでいるから、最近の話聞いたらそれは嬉しくなります。
げんえい
まあそうですね。
きんじょうひでき
インターネットがもうあるぞぐらいの感動してたんで、我々。
げんえい
そうですね、なんか自動テストとかテストの足が自動になっているとかね、
プログラムがフォートランとかコーポレが出てくるとうってなってたのがね。
そんな話をしましたからね。
きんじょうひでき
配信というか公開の順番は前後する気しますけど、前回とかプログラマーのリードタイムが印刷の待ち時間でしたからね、パンチカードとか。
そうそうそう。
確かにあの時代はチームっていう単位は出てこなかったですもんね。
コードレビューもギリギリ出てきてないんで、本当にちょうど前回読んだのがタイミング悪すぎるんですけど、
それにしたってチーム活動とかいう感じじゃなかったからな。
あとそのチームっぽい話で言うとこの本の中で一番好きだったのが、
チーム設計の原則のところでアトミックに扱うっていうようなことが書かれてて、
本の中の言葉を借りると組織内でチームを子として扱う。
子っていうのは個人の子ですね、インディビジュアルの子ですね、として扱うっていうふうに書かれてて、
〇〇タスクっていうのが湧いた時に〇〇さんに頼もうじゃなくて〇〇チームに預けようとか、
プロジェクト立ち上げる時もプロジェクトがあって人を集めてくるっていうよりかはチームに対して何かアサインするとか、
これも言われてみればすげえまあそうだよねなんですけど、
ラベルをつけてくれてありがとうございますな気がするんだよな。
げんえい
こういうふうに考えるといいぞって言われたらすげえうん確かにって思うし、
チームとして自立していくっていうふうになってほしいよねっていうのはすごく思うので、
結局チームを作ったけどチームに対してあれやってこれやってって指示を出していたとしたら、
あんまりスケールしなさそうだしすごく難しそうだなみたいなふうに思っちゃうけど、
こういうふうな方向づけ方針チームとして自立してるってことを期待するよっていうふうなことが言えるようになると、
じゃあ自分たちでチームってものを自己管理していかないといけないんだよねっていうふうなことにつながっていって、
すごくマシが早くなりそうだなっていうふうに思いますね。
きんじょうひでき
これを基礎としてここから導かれるベタプラクティスとかパターンみたいなものは、
すごいたくさんありそうだなっていう気はしてて、
そういう意味でもこの概念をしっかりインストールしてほしいなっていう感じがしてます。
げんえい
自分は個として見れてるのかなチーム、他のチームを見たいことはちょっと考えたりしましたね、ちょっと読みながら。
きんじょうひでき
難しいですけどね、体感として得られるところまでいくのは、
より難しそうだなっていう気はするけど間違いなくメリットは大きいだろうなっていう気はするんだよな。
げんえい
仕事とかも依頼するとき、果てまえじょはこのチームにちょっとやってもらうって言いながら、
あの人暇そうだしなーって言って、そこのチームのバイネームを指してたりするなーみたいな気持ちとか。
きんじょうひでき
嫌じゃないですか、プライベートメンバーをリフレクションでこじ上げて無理やりライブにするみたいな、やりたくないじゃないですか。
げんえい
そう、やりたくないけど個人に対する期待値みたいなものとかを持ち始めると、
あの人にこれをやってもらって成長してほしいなーみたいな気持ちが出てくると、
こじ上げたくなっちゃう。
きんじょうひでき
そうですね、面白かったというか、この本の多分一番、自分から見てて一番太い特徴の一つだなーって思ったのは、
あるべき組織設計っていうのをバリューストリームで説明しようとしてるなーっていう印象がすごいありましたね。
げんえい
多分松本さんのその発表みたいなところ見てても、やっぱバリューストリームの話は必ず触れられていて、バリューストリームってものが大事なんだってことは、
この本の中ですごく大事にしているところなんだろうなっていう気がしますね。
きんじょうひでき
バリューストリームと組織図なしワークフローみたいな実装の方をいかにねじれなく投下的に実装するかっていうところにこだわっていけるといいんでしょうなーっていう気がしますよね。
げんえい
そうですね。多分これが何も考えてないとどんどんどんどんねじれていって、バリューストリームが分岐して最後もう一回合流してじゃないとものが出ないとか、市場に出ないとかみたいなことが起きたりするんだろうなーっていう気はしてますね。
組織構造とソフトウェアの関係
げんえい
この本の中でコンウェイの法則っていうのは結構大事なキーワードとして出てきたりしますけど、組織構造ってじゃあ結構早くから考えとかないと、あの人の手が早いからの人にお願いしようみたいな、人に任せるみたいなことをしたときに、
その人がやりやすいように作った結果、いろんなものが密結合したものが出来上がって、気づいたらプロタクトが密結合、いろんな機能同士が密結合した結果変更が加えにくくなったりとか、バリューストリームをうまく流すためのことができなくなったりとかするのかなーみたいな。
別に誰かがそうしてやろうって思ってるってよりは、良かれと思ってやった結果そうなってしまうみたいな、そういうことが発生するのかなーって思ったりもしましたね。
俺がやったほうが早くリリースできるんだもんって言われて、その時はそうだったみたいな。
そうですね、泥団子職人みたいなふたを開けてみた。
そういう意味ではやっぱりソフトウェアの構造と組織の構造が見えるっていうのは公明の法則だからっていう話でもあるんだけども、ソフトウェアを作るように組織を作るというか、どこが依存してどこが依存しない方がいいのかって、
意図的にちゃんと設計しようがないと、後々難しくなっていくんだろうなっていうのを全体を見ながら思ったりもしましたね。
じゃあそれが最初から分かってるかって言われたら、分かってなくてリリースしてユーザーが使って、そんな風に使うんだって。
分かってた結果、こうとここって実は関係なかったんだなとか、こうとここは教習度が高くないと困るんだなとか、インターフェースを一個かましておくといいんだなとかって、後々分かったりすることなんで、大変そうって。
きんじょうひでき
リファクターしやすいように作っておかないとやっぱりリファクターしづらいし、リファクターって結局技術力いるじゃないですか。
そういう意味でもこういう組織論、いろんなパターンを知っておくとか、引き出しを増やしておくとか、知識と武器としてっていうのは必要な気がするし、
あとは、なるほどこのシグナルが買いも見えたからそろそろリファクターのタイミングかっていうかハグ勲力とかって考えるとソフトウェアシステムと同じだなっていう感じがしますよね。
まあ人間の方が感情があるからめんどくさいんですけど、ソフトウェアは別にクラスを別のフォルダに動かしても文句言わないですからね。
げんえい
そうですね。離れ離れにするなんて酷いみたいなことは言われないですからね。
あと難しさで言うと、フィードバックのサイクルがソフトウェアとかコードを書いているときは短いんで、組織変えて1週間後に成果が出るってことはたぶんあんまないと思うので、
半年、1年みたいなそれなりのスパンで評価するってことになると思うんで、もちろん先行修行みたいなものはあるかもしれないけど、ライフサイクルが違うから大変だなって思うことはありますね。
きんじょうひでき
そうですね。ライフサイクル広めでインプットアウトプットが安定せず、しかもめちゃくちゃステートフルみたいな、そういうやつですね。触りたくないな。
げんえい
そういうシステムって言われたらちょっとうーんと思っちゃいますね。
けど、やっぱり現在で1人で作れるものの希望感みたいなものは、AIが出てきた前提が変わった部分もあるかもしれないけど、
ちょっと前までのことを考えると、1人で作れるもののサイズ感だったり立ち打ちできるビジネス希望みたいなものは、チームだったり組織だったりに比べたら小さいと思うんで。
ってなるとやっぱり大きいインパクトみたいなもの、成果みたいなものを出そうと思ったら、チームだったりチームが複数いるような組織だったりとかっていうことを上手に作っていくっていうのは、
もう必要とされる時代なので、その辺とかやっぱり触りたくないよねって思うけど、考えないといけないよねっていうところはありますよね。
きんじょうひでき
そうですね。うまくいけば間違いなくアウトカム増やすのに寄与するので、そうじゃないとしたら本当にやる価値ないどころかやらないほうがマシでしかないので。
げんえい
そうですね。個人商店やってた方が良いっていうのがあったら。
きんじょうひでき
全体的なというか面白かったところ、つまみ食いはそんなもんですか?他なんかあります?ここは行っておきたいぜって。
げんえい
そうですね。まあでもそんな感じですかね、全体として。ぜひ皆さんこれを読んで、ソフトウェア開発の現場ではこういうようないろんな知見があって、
これがだんだんもしかしたら5年10年経っていくともう本当に前提になって、こういう経験をした人たちが増えていくみたいな世界になっていく可能性はなんかあるかなって、
ぜひ買って読みましょうっていうふうに思ったりしました。
きんじょうひでき
あとはあれですね、この本に興味を持つ人はこの本の中で触れられているいくつかのことは必ず知ってるであろうなっていう気はするので、
まず目次見て気になったところから読んでみるっていう感じでいい気はします。多分順番関係なく読めますよね。
げんえい
そうですね。全部で7章あるんですけど、この本1章がチーム思考ってなんで大事なのっていうような、とか現代においてチームみたいなところの話の前提みたいな、
要はこの本で一番言いたい主張の部分があって、2章3章4章が組織だったりとかチームとかによくある問題みたいな、
組織内部品質とか素早く作るための作るんだけどそれを妨害するものは何なんだろうかとか、そういうような問題みたいなところは2,3,4章やってて、
5,6,7ってじゃあそれに対抗するようなチームっていうものはどうやって作っていきますかっていうような話をしているのが5,6,7なんで、
チーム思考の重要性
げんえい
なんか大体そういう分け方で気になるところから読んでいくっていうので全然いいかなって気がしましたね。
きんじょうひでき
で、もちろん気になったらページ戻って読めばいいし、なんかその参照先というか相互じゃないか、リンクも貼ってますもんね。
げんえい
そうですね、この問題と関連した問題はどれでしょうとか。
きんじょうひでき
その意味だとパターンランゲージ的な作り意識してるなーっていう気もするし、ちゃんと名前があって絵があってっていう、なんかアレグザントリアンなパターンランゲージみたいな。
げんえい
うん、よくわかんない絵じゃなくてちゃんと。
きんじょうひでき
よくわかんない絵はね、スクラムの人とか組織パターンの人がやりがち。
じゃあ一旦前半という形でここまでにして、ちょっとじゃあこの後は少し分け道にそれるような話をしていきますか。
げんえい
そうですね。
きんじょうひでき
じゃあ一旦終了しましょう。
