生産者の役割とオーバーヘッド
げんえい
じゃあ、次行きますか。生産者の話 ちょっと触れていいですか
いいですよ
きんじょうひでき
生産者っていうパターンがあって 原文まま読みますけど、組織内で
オーバーヘッドと役所仕事が過剰 になっている。このことは、ロール
の数が多すぎるのを見ても明らか だ。ただし、ロールはどれも重要
に見える。役所仕事を減らそう方法 などなさそうだっていう掛け出し
というかコンテキストの設定が されていて、ロールを減らしたい
よね。それによって無駄な承認とか ミーティングとかそういうの含めて
無駄なオーバーヘッドを減らしたい よね。コミュニケーションを最適化
したいよね。同期があって、じゃあ どうするかっていう、それ故のところ
に書いてあるのが、各ロールが生産者 支援者怠け者のどれに当たるか
を見極めよう。怠け者とはプロジェクト に何の価値も与えないロールの
故障の一例だ。怠け者を消し、場合 によっては支援者をいくつか消したり
統合したりしよう。生産者に該当 するロールを育てよう。そのロール
こそがお金を稼いでいるからだ っていうようなパターン。でパターン
目が生産者ですね。怠け者を追い払い とかにしなかったんですねパターン
げんえい
目
そうですね。フォーカスするのは 生産者が一番フォーカスしてほしい
っていうことなんですかね。支援者 っていうのもあるけども
きんじょうひでき
そうですね。生産者っていうのが 本当にプロダクトとか売り上げに
怠け者の排除
きんじょうひでき
つながるような活動をしている 人たち。いわゆるマーケットとか
固着に対して付加価値。アートカモ を出している人たち。で怠け者
はなんていうかなんすかね
げんえい
仕事を増やす人
きんじょうひでき
仕事を増やす人。社内遺伝商売 とみたいな人とかそうかなっていう
気がしますね。結局あなたがい なければその仕事ないですよね
みたいな話で。だから支援者と 怠け者は表裏一体というかグラデーション
っぽいものなのかなっていう気 もして。スクラムマスターとか
は支援者ですよねまさに。プロジェクト マネージャーもかな
げんえい
そうですね
きんじょうひでき
生産者をエンパワーメントする ために防火壁とか犠牲になったり
しつついろいろ全体の付加価値 生産価値を高めていく人たちですね
げんえい
そうですね
きんじょうひでき
社内のいろんな人たちの果たしている 仕事っていうのに仮想的にかもしれない
んですけどロールっていうのと 設定してひも付けてこのロール
この仕事怠け者でしかなくない みたいなやつを消していくっていう
話ですかね
げんえい
そうですね。怠け者を排除するのも あるかもしれないけどやっぱり
生産者が集中して仕事ができる ことにフォーカスをしましょう
っていうことでもあるのかなっていう そっちのほうが強いのかなみたい
なちょっと読んでて思いました ね
きんじょうひでき
なるほど組織内における生産者 に該当する人の比率を上げましょう
げんえい
みたいなニュアンスで僕は読んで ました
最初が役所仕事が過剰になっている みたいな話があったんで要は生産者
がなかなか生産できない状況が あるのかなみたいな思って自慢
そういうような読み方をしました ねある種怠け者がブロッカーになって
たりとか仕事を増やしているみたいな そういうようなこともあるのかな
って思ったりとかしましたね
きんじょうひでき
そうですねそれもあるんだろうな 怠け者が減ってくとおのずと生産
的な時間の使い方得ていくよね みたいなニュアンスもあるかもしれない
げんえい
ですね
面白いですね何か当たり前じゃん みたいな感じはするんだけどやっぱり
当たり前が一番難しいということ でもあるのかなっていうような
ショーですね
きんじょうひでき
これでも例えばマネージャーの ミーティングの棚下ろしとかっていう
のをメンバーにやらせてみたら 結構怠け者じゃないお前みたいな
生産者中心な組織
きんじょうひでき
話が出てきたり呼ばれちゃう じゃないですかマネージャーとか
一旦このCCぐらいの気持ちでいい から同席してもらえるとうむず
そうみたいなただ蓋開けてみる と自己報告でおければそこの決定
こっちでやっておきますよとか プログラマーとデザイナーが直
で話して決めちゃいますよみたいな とかあったりすると思うんですよ
げんえい
ね
めっちゃあると思いますね最後の 一押しだけ欲しかったみたいな
そういう場合とか別にそれって 後で自己承認でオッケーじゃん
みたいな場合とかもあるだろう し
デリゲーションポーカーとかやる と多分面白いんでしょうね
そうそうそうやっぱりこの本の 前提としてはみんなが生き生き
として働けるようなことみたいな ものも含まれてるような気がする
つまり管理を頑張りましょうっていう よりはそこにいる組織の人がどう
やったら生き生きと働けるかっていう ようなことも含まれてると思う
生産者はコントロールされていて 生産性を上げるためにはトップ
が何をしたらいいのかみたいな っていうよりは現場の人も含め
どうやったら効率よくものが作 れるかとか効果があるようなもの
を作れるのかみたいなそういう ようなことが裏にありそうだな
みたいなのは思ったりしますね
きんじょうひでき
生産者中心な組織を作ろうとしている 意思はすごい感じますよね
げんえい
そうですね
きんじょうひでき
飛ばしたかもしれないですけど 仕事が中心作業か作業が中心に
繋がれるとか働いててすごい手応え を感じられるようにしようぜみたいな
意味でみんなが生き生きとする ようなっていう世界観はあるの
かなとか今話聞きながら思った りしましたね意思決定をどんどん
エッジに寄せていく現場主導で 動けるようにするとかっていう
のもそこにすごい密接に関わる はずだし
げんえい
そうですよねそれができるよう になったらいい組織というかいい
チームというかが出来上がって いくんだろうなっていうのがもし
それができたらいいなあみたいな ワクワクするなあみたいな感じ
はどこ読んでてもあるなあっていう 気がしますね
きんじょうひでき
自分たちで考えて自分たちで決め られるんだなっていったこと
だったらもうそれはどんどん学習 してきますもんねいろんなこと
やってみていろんなことを考える ようになっていろんなことに敏感
になってみたいな
そうそう
げんえい
言われたことをやるだとなかなか そうなりづらいんで
自分たちで実験して学習した結果 が決めていいよって言われたら
ちゃんと説明責任さえ果たせば 説明責任自己責任さえ果たせば
仮にそれでうまくいかなかった としてもいやこれがやった結果
なんでじゃあ次はこういうふう にやりますねっていうふうになって
いけばそれはもう任せられるような いろんなものとかそうなって
いきたいよなあって思いますね
きんじょうひでき
そうですね自己管理的な組織チーム を育るためのスクラムっていう
フレームワークがあるんでそういう のがお勧めかもしれないですね
げんえい
そうですねいろんなものを経験 したりとかして
きんじょうひでき
当てつっぽでやるよりはいろんな フィードバックをもらいながら
げんえい
みたいな
そうそう
きんじょうひでき
だから生産者も結構個人的に印象 深いというか大事に考えたいパターン
だよなっていうような感想ですね
げんえい
じゃあ次どれいきます
きんじょうひでき
さっきチラッと言及したんで形状 は機能に従ういきますか
げんえい
形状は機能に従うは単純に写真 がおもろいなっていうのが一番
ありますよねまずポットみたいな 形をしたコーヒーポットビアワインズ
リキュールズって書いてあるっていう 建物があるっていう
きんじょうひでき
そうなんすよねコーヒーポット の形してるんですよね
げんえい
でタイトルが形状は機能に従う って書いてあるんですよね
きんじょうひでき
形状は機能に従ういや絶対従 ってない写真なんだよな
げんえい
そうそう
きんじょうひでき
これレストランの写真みたいで
げんえい
そうなんだ
きんじょうひでき
多分クレジット見てここのリファレンス というかデータベースから撮った
写真なんだっていうのとかただ 写真の作品名タイトルはこの本
に書いてる写真のクレジットに タイトルついてないんだよなとか
いろいろ思いながら探したんです けどレストランらしいですね
げんえい
下がっとらへんやんけ
きんじょうひでき
コーヒーポットって書いててビール ワインズリキュールって書いて
あってお前コーヒーじゃねえん じゃねえかって思ったんですよ
最初
げんえい
そうですね
きんじょうひでき
何だろうこれはって思って調べ たらレストランらしい確かにこの
形状を見たら飲食店かコーヒー 屋さんか酒屋か何かしらなんとなく
飲食に関わる建物なんだろうな っていうのはたぶんパッと見で
想起できるのでその意味で形状 は機能に従ういやでも機能があり
きで徐々にこの建物がこういう 形状になっていったとは思わないん
ですけどでもあれですよね機能 と形状っていうのが乖離しすぎ
てる状態っていうのは歪なんでしょう ねそれが組織図だったりロール
だったりみたいな結局公務員の 法則みたいな話っぽい
げんえい
それぐらいにしときますかただ 写真が面白かったという情報でした
きんじょうひでき
っていう
そう触れるパターンの中だとこれの 写真が一番好きですね個人的に
げんえい
あとは組織伝えるためのパターン 言語で触れておきたいのとかあります
なかったら次に行っちゃって人と コードのほうに行っちゃっても
いいのかなって
きんじょうひでき
次いきますかコミュニケーションパス っていうのをどうにか減らさな
きゃいけないそれのためにはロール の数っていうのも減らさなきゃ
いけなくてそのためにいろんな ロール機能をマージしたりとか
責務このロールがどこにあるべき かこの仕事この責務がどこにある
べきかっていうのをいい感じに 調整していきましょうよみたいな
話ですよね残りは残りというか 全般的に
げんえい
そうですね
きんじょうひでき
あとは組織仕事の必然的に生まれる コミュニケーション以外が死んで
しまうと結構つらいので偶発的な コミュニケーションが生まれる
ように立ち話しっていうパターン があったりだとかレース行きっていう
なんか何ですかね水飲み場がある とそこでたまたまいた人とロール
関係なくお話しするでしょみたいな パターンがあったりとかっていう
ようなところですかね
げんえい
そうですね
きんじょうひでき
はいじゃあ人とコードのための パターン言語いきますか
げんえい
いきますかでこれも最初は信頼 で結ばれた共同体また会いました
ねみたいな感じですね順当にいく とアーキテクトがプロダクトを
コントロールするですかねこの パターンはプロダクトの設計には
多くの人が携わるがプロジェクト ではプロダクトを上品にして一貫
アーキテクトの役割と権限
げんえい
性を保つように努力しなければ ならないっていうのが最初の文脈
としてあってそれゆえアーキテクト ロールをつくってプロジェクト
のアーキテクチャースタイルを 定義する原則やそのスタイルを
正確化するような幅広いドメイン 知識を体現させようっていうふう
な話をしていてやっぱ人とコード の中でまずはアーキテクトみたいな
全体をリードするような人がいない と一貫性が保たれなくてどんどん
複雑だがっていったりとかその スタイルを正確化するような幅広い
ドメイン知識みたいなものを体現 しておかないとぐちゃぐちゃになって
しまうよっていうところが最初 のほうに話されていてこの辺とか
はいきなりプロジェクトの序盤 にアーキテクト100位に突っ込ん
でもしょうがないみたいな話でも トムデマルコとかでもあったような
設計者をたくさん入れてみたいな あったような気もしますけど
そういうとこだったりするから まあそうだよねみたいな感じですか
きんじょうひでき
ね
そうですねコントロールするって いう言葉が強く取られすぎる
かもなみたいな懸念が振れられて いてアーキテクトがプロダクト
をリードするとかプロダクトを ガイドするっていうふうに呼ん
でもいいかもね的なことが書いて ありますこれやるとアーキテクト
も実装するのパターンちょっと 触れてみますか
げんえい
はい
きんじょうひでき
5-2-10ですねアーキテクトっていう ロールを定義してその人がアーキテクチャ
というかプロジェクト開発における ガイドラインコードのガイドライン
みたいなものを示してそれで終わり っていうふうにするんじゃなくて
実際に開発者と一緒にとかもしくは 自分一人で実際にそのアーキテクチャ
の上でコードを書いてみるっていう のも大事だよ的なパターンですね
自分で決めたガイドラインで自分で ロックフードリングもしましょう
みたいなニュアンスがあるのと そもそもアーキテクチャとかアーキテクト
と同じレベルの開発者がすごい 十分な数揃ってるんだったらそもそも
アーキテクトっていうロールって ほとんどいらなくなるはずなのに
アーキテクトっていうロールを わざわざ上に置いてるってことは
多少なり実力の乖離があるかも ねっていう前提で言うとガイドライン
示しましたあとはこれに従って やってくださいって言ってもうまく
使いこなされない可能性がある のでアーキテクト自身が例えば
こういう実装になりますよみたいな サンプルを示していく的な話も
多分含まれてるんだろうなとか 思いながら
げんえい
そうですね自分はアーキテクト も実装するって読んだときにさっき
スモールチームみたいな話があった りしましたけどだんだんチーム
に権限移動していくとアーキテクト みたいな設計だけやってあとは
おまかせみたいなのって今って あんまりどんどん減ってるんじゃない
かなみたいなチームの中でアーキテクト がいてアーキテクトって呼ばれてる
人はただ単にチームの開発をリード する人ぐらいな意味になって一緒に
開発していくっていうほうが結構 多いのかなみたいなことをちょっと
思いながら読んだりもしててこの 辺はもしかしたら時代的にちょっと
変わってきたのかいや全然今でも アーキテクトで設計だけやって
ますみたいな人はもちろん世の中 探せばゼロではないと思います
きんじょうひでき
けど
そうですねあるとしたら技術選定 的なレベルの本当のチームとか
プロジェクトっていうのを横断 したというか超越したところでの
指針を示すような人たちっていう のはなんだろうなシニアリード
エンジニアとかそれ以上のIC系 の人たちでいたりするのかもな
とかっていう気はするんですけど チーム1アーキテクト1000人っていう
世界観はあんまりない感じが僕も しますね
技術選定とチームの動き
げんえい
ここは適切に読み替えていく必要 がありそうな感じはありますね
きんじょうひでき
これでも源永さんの会社でいう と常通技術職常通技術ロール
を設けていて多分全体的な導入 するプラクティスっていうのを
示したりとかこういうふうにやり ましょうよみたいな話とかコード
全体の品質を最終的に責任持つ そこ上げするみたいな話とかさ
れてるのかなと思うんですけど チームの中アーキテクトも実装
するみたいなところまでやってる ものなんですか
げんえい
今の話でいくとCTオフィスとか 技術基盤部みたいな横断的にやって
いくぞみたいなそこを専任とする みたいな人がいてそこが割と仕組み
を作ったりとかしてこういうふう にコードを書いてねとかこういう
ふうな依存関係をちょっと依存 がぐちゃぐちゃになると難しく
なるから依存を整理しましょう ねとかいうことをやったりとか
必要な仕組みみたいなところ例えば フィーチャートグループを実装
して安全に本番に出していくん やみたいなのとかの下準備とか
をするみたいなの実装を実際やって いくプロダクトコードの中に混ぜ
ていくみたいなこととかそういう ような部分においては全然やって
たりとかしますね
行動の所有権の重要性
きんじょうひでき
なるほど
げんえい
なのでその機能に特化した部分 は開発はしないかもしれないけど
もういろんな機能またがったり とか機能レベルでいくともしか
したらすごく複雑な何ですかね 技術力が要するようなものを作って
いくみたいなところは任せたり みたいな部分はあったりします
きんじょうひでき
ね
あれですかねなんか大量のデータ を処理するバッジが悲鳴上げて
たんで引き死にいくぞみたいな 話とか
げんえい
とかあとは認証認可回りとかあって 難しかったりするじゃないですか
それに特化した知識がないとう っかり作っちゃうと危ない部分
だったりとかいうところとかそういう のとかあったりしますね
きんじょうひでき
でもその話聞いてもやっぱりこの 本と時代の違いみたいなところ
って説ますとちょっと乱暴かもしれないん ですけどやっぱりそういうのを感じ
てこの本の中で書かれてるアーキテクト の責任範囲としてはプロジェクト
チームが作るプロダクトコード に関する中小レベル概念レベル
の設計とかまで多分アーキテクト 組織内のアーキテクトロール
の人の仕事として含まれてるんです けどそういう感じのアーキテクト
っていうのはやっぱり今あんまり いなくて逆にイネーブリング
とかプラットフォーム的なエンジニアリング やってて共通基盤だったりだとか
よりメタなところの全体指針とか やってたりするってそれがかつて
はアーキテクトになってた仕事 の一部だよねっていうような感じ
なんですかね
げんえい
そうですね あとはやっぱりチーム に分解してった分割統治で結果
そこに移情しましょうみたいな とか世の中の仕組みで言えばマイクロ
サービスだったりとかモジュラ モノレスみたいな部分的に取り
替え可能にしていくみたいなところ を結構みんなこの20年ぐらい考えて
たりとかすると思うんでじゃあ そこは別に依存関係が少ないので
あれば全体指針をまで作らなく たってその部分的に差し替えが
できるんだったらその中で閉じて リードするような人がやってしま
えばいいよねっていうことになって たんだろうなっていう気はします
きんじょうひでき
ね
そうですね ちゃんとちっちゃく分け ておけば大爆発しても全体的に
崩壊しますっていうふうにならない からある程度自由にやらせながら
経験積ませて 市長させてみたいな そういう話かなっていう感じが
しますねっていうようなところ でじゃあまた別のパターンいきます
げんえい
か
次しゃべりたいなと思うのは結構 二人がこの本とえそうなのみたいな
感じになってる行動の所有権の話 したいなと思っていてこれは行動
の所有権の話はどういうことか っていうと全員で責任を持つ
っていうふうにすると実は誰も 責任を持たないっていうことになって
しまう 全員がチェックしてるから いいよねってよしってやった
結果誰もちゃんと見てなかった みたいな文字があるんでそれゆえ
システム内の行動モジュールは それぞれ一人の開発者が所有する
ようにして例外的で明らかな状況 を除き行動を修正するのはその
所有者だけにするっていうふう なことをやりましょうっていう
話を行動の所有権っていうパターン では言ってますね
きんじょうひでき
だからPHPじゃなくてJavaDocとか でもいいんですけどあとオーサー
をつけるみたいな話ですよね
げんえい
そうですねなんとかモジュール は○○さん担当だから○○さん
だけが修正するこれは現代的じゃない のか当時はこれがすごくそうだ
よねってなってたのかあんまり イメージがつかないですけど
きんじょうひでき
どのくらいの時代の話なのかな っていうのがやっぱりあります
よね人と行動のためのパターン 言語を今読んでいるんですけど
組織とか政治社会的な要因が開発 されてくる成果物例えばソース
コードにというふうに影響を及 ぼすかみたいな観点で書かれて
るんですけどGitを使ってプルリック 駆動でやって自動化テスト回して
みたいなところで解決されてる 問題コンテキスト多そうだなっていう
気も割とこのパターン言語全体 見たときにその中に含まれてる
いくつかのパターンからはそういう ちょっと今の時代だったら自然
と解消されてるかも的な雰囲気 を感じたりとかその一つの例として
行動の所有権のパターンはどういう 感じのことなんだろうなってなります
よね
げんえい
そうですね一方でじゃあこの本 が一番危惧してるのって全員で
責任を持ちましょうXPでいうと このコードの共同所有みたいな
プラクティスを考えたときに誰も 責任持たないじゃんみたいなこれ
対応してよって思っても誰も対応 してくれないみたいなっていうこと
って現代においてはどうやって 避けてるのかみたいな話がある
とこの話はもう完全に古くなって 今はこうやってんだよねみたいな
ことが言えるのかなみたいなのは ちょっと思ってどうやってるんですか
ね
きんじょうひでき
ペアプロとかコードレビューとか での知識の投入っていうのはあります
よねっていうのがすごい表面的 というかすごい安直にはそう思います
げんえい
ね
あとは機能とチームを紐づける ことによってチームの共同所有
みたいな全員ってよりはチーム の所有みたいな感じにするとか
コードの所有権パターンの議論
げんえい
はあったりするよなとか思って たりとかあとあれですかねもしか
したら自分が見慣れすぎている からかもしれないですけどクロース
ファンクショナルのチームを作って 開発をやっていくので何ですか
ねそこのチームの持ち物みたいな 感じになるのかなこれがもう一
昔前だとどうなってたんだろう なみたいな
きんじょうひでき
あとこのパターンが出てきた背景 というかコンテキストのところ
で書かれてるのはなじみのない コードを修正するのは危険である
とかなじみのないコードを5字が ありますねなじみのないコード
をの中からなってるなじみのない コードの中から設計課題を探し
当てるには時間がかかるって書いて あるので修正の失敗っていうリスク
が高くつくっていう話かなと思 うんですよねそれだったらめちゃ
くちゃそこの生地引きとかライブラリア みたいな人がいてその人に聞いて
直してもらったりとか正しいやり方 っていうのをその人に依存して
どうにかしてもらおうみたいな ほうが変更が安全であるっていう
話だと思うのでそれでいうと結構 単体テストが充実してるっていう
のはダメージコントロールじゃない ですけど対抗策になっているの
かなっていう気はしますね
げんえい
確かに
きんじょうひでき
逆に言うとCI回してませんコード レビューが機能してませんっていう
状態だったらコードの所有権パターン を僕も使うかもなと今ちょっと
思いました
げんえい
確かになちょっと言えないけど いろんなものを今頭にあれはそうだ
なみたいなこと思い浮かべながら
きんじょうひでき
我々はちゃんと秘密保持契約を 結んだ上で社会的な生物として
生きてるんで
げんえい
確かにあの部分はあの人が一番 わかっていてあの人じゃないと
変えられないみたいな話とか架空 の話かもしれないですけど見て
きたことあるなって思ったりしました ね
きんじょうひでき
たまにめちゃくちゃパワフルな 中途採用の人が来てイライラしたん
で俺がやりますって言ってちょう だおしてくれるみたいなそういう
エフェクションもあったりします よね
そうですねプルトーザのように こう直していくみたいな
あれもあるかロールバックが容易 なので
げんえい
確かに
きんじょうひでき
やっぱり失敗したときの停滞具合 停滞っていうのは止まってしまう
止まってしまうじゃなくて痛い 思いをするみたいな嫌な気持ち
になる率で言うと
げんえい
そうですねまあその修復時間が 短いですからね今は
きんじょうひでき
そうですねだからdわださんがめちゃ くちゃ言ってるやっぱり不可学性
っていうのを軽減していくっていう のができてくるともうストラテジー
とかドクトリーのレベルでやり方 変わってくんじゃないかなっていう
感じがしますね
げんえい
我々はかなり今いい何ていうか ラッキーな時代というか
きんじょうひでき
甘やかされてますだって我々は 小っちゃい頃から集中2日だったん
げんえい
で甘やかされてますよ
そうですねやっぱりこのコード の所有権っていうのはそうですね
やっぱりピンとこないなっていう のは正しいんだな
きんじょうひでき
ですかねこういうところを見て みると何というかやっぱりXPとか
スクラムとかっていうのがしっかり 変えられるよりかはちょっと前
にまとめられたパターンたちなの かなっていう気もしますね
げんえい
そうですね
きんじょうひでき
面白いな50年後どうなってるかですね コードの所有権が
げんえい
我々が今甘やかされていってた けど50年後はもっと楽になってる
はずというかもっと良くなってる はずだから
きんじょうひでき
そうですね通勤なんてどこでも 10秒でいいじゃないですかみたいな
げんえい
そうオフィスに集まるの普通っしょ みたいなリモートワークとかないっしょ
とかやっていいんだからだって どこでもドアあるしみたいな
いいな
きんじょうひでき
いいっすね
データセンター駆けつけるのも 3秒ですよみたいなあそこは変わって
ないんだみたいな
セキュリティどうなってんだろう みたいな感じがありますけど
でもあれですねコードの所有権 っていうのがこの時代に記述された
パターンだと1人に持たせましょう なんですけどさっきねゲインさん
が言ってたチームで責任を持ち ましょうそれはスモールチーム
ですよねみたいな話とかっていう ふうにやっぱり自分の手足のように
生み出したコードっていうのが 動かせる必要があるみたいな話
でいうとじゃあそれをうまくやる ためにはもっとどういう工夫が
できるだろうかとかそれができる ようになったらじゃあ次どういう
とこ踏み込んでいくかみたいな 話でいうとなんかこれもまた発展
がありそうなパターンだなっていう 気はしますよね
げんえい
そうですねアップデート版組織 パターンが欲しくなってきます
インターフェースの背後のバリエーション
げんえい
ね
きんじょうひでき
どのくらいアップデートされる のかなドメインがぐちゃぐちゃ
になってチームが作られていたら チーム全体で共同所有しましょう
で責任は全部持ってくださいとか やっぱり無理じゃねってなるんで
げんえい
そうですねそれは結構しんどい ですね
きんじょうひでき
じゃあちょっと次のとこ行きます か
げんえい
はいそれでいいかな
きんじょうひでき
インターフェースの背後のバリエーション にいっていいですか
げんえい
はい
きんじょうひでき
いや今名前見てよしこれだって 思ったんですけどNotionのメモ見
たらこれはとても便利だしよく わかるとしか書いてないですね
これはプロジェクト何だろうな 複数人とか複数チームでもいい
のかなで開発していくときに一旦 インターフェース決めちゃって
細かいところはそっちのチーム で書いてくださいねとか要する
に抽象レベルインターフェース レベルの形状だけ決まっちゃえば
割と作業を分散させたりとか同時 並列で走らせたりとかっていう
のがしやすいでしょみたいな話 ですね
げんえい
そうですね
きんじょうひでき
っていうのを見てこれはとても 便利だしよくわかるなって書き
ました逆に言うとパターン名の 通りでインターフェースの背後
のバリエーションっていうのを うまく意識できる思考に組み込
めると非常に開発っていうのが スムーズにいきやすいのでバリエーション
が発生しそうなところ変動性っていう のを鍵付けてそこに対してインターフェース
切っていきましょうみたいな感じ がしますね
げんえい
そうですねこれとさっきの後藤 さんのところとかが繋がるんだろう
なみたいなことを
きんじょうひでき
そうですね
げんえい
このバリエーションっていうのは どっから来るのって言ったらそれは
マーケットから来るんだよって ことはマーケットに従ってインターフェース
のどの決まっていくかもねみたい なとかいうとこにも繋がっていき
そうだよねって気がしますねこの 中だと入ってないですねこの本
の中ではそこに矢線は伸びてない けどやっぱバリエーションをどう
見極めるかこの多分インターフェース の背後のバリエーションっていう
のはやっぱみんなバリエーション と言われたらそうだよなってなる
けどどういうふうにバリエーション を捉えるかみたいないうのっていう
のはまたそこはそこでテクニック がいるよなみたいな話が思ったり
しますね
きんじょうひでき
そうですね
げんえい
ここで間違えると結局インターフェース を作ったがいやちょっと全部やり
直しですねみたいなオチが待って たりするんで
それ言われるとちょっと涙が止 まらなくなるんですけど
そう思ってたがしかしみたいな ことっていうのはでもそれは経験
とか失敗したことによって本当に 必要だったものが分かるみたいな
とこがあるんで結局これがさっき の話にどんどん近づいていって
早く失敗できるとか早く経験を してフィードバックもらってっていう
ところにつながっていったりするん だよなっていうのをすごく最近
もそういうことを実感するような ものがあったりとかして思った
きんじょうひでき
りしました
当然これはいるでしょって思って 定義しておいたメソッドがめちゃ
くちゃ実は使いづらいみたいな 話とか抽象化を間違えました
みたいな話なんですけどあります からね
げんえい
ありますね
きんじょうひでき
っていうかあれなんですよね通通 性変動性っていうのを見極められ
ればもうソフトウェア開発うまく いくはずなんで
げんえい
そう結局それが難しいからイフ 分で逃げてしまったりとかして
複雑度が上がり爆発していくみたいな のが一番あるパターンですから
ね
きんじょうひでき
それをどうにかできる最強の方法 ないんですかって言われてそんな
げんえい
ものないって言ったのがいわゆる 銀の弾などないって話なんでそれは
きんじょうひでき
多分本質的な複雑性混乱性難しさ に対してパーンと吹き飛ばすような
弾なんてないでって話だったから 難しいよね
げんえい
そうですねそれにちょっとつなが ってこの緩やかなインターフェース
っていうのが次にあるんですけど ちょっとインターフェースつながり
でしゃべってみたいなと思って いてこれは何かっていうと開発
時にボトルネックになってしまわない ようにあるチームの作業が別の
チームに与える影響を制限しなければ ならないとそういうことをする
ためにどうやって解決していく かっていうと明示的で安定したインターフェース
の数を制限しましょうとあらゆる 誘導のインターフェースを定義
して初期に定義されたインターフェース に対して開発者が行動をかける
ようにしつつ機能を制限しすぎない ようにしようでこの目的のため
緩やかなインターフェースをおん ちゃかおんちゃかっていうふう
な話が書いてあって緩やかなっていう のは分からんでもないんだけど
なんか緩いとつらくねみたいな ことをちょっと自分は思ったんですけど
つまり後から型をきつくしていく ってやりづらいから最初にきつく
してだんだん緩くしてたほうが 良くないってちょっと思ったり
したんですが
きんじょうひでき
なるほどそうですね源井さんが ノーションに書いてるメモを見て
ちょっと笑っちゃったんですけど ミックス度でデータのやりとり
げんえい
すると確かに緩い束縛というか 結合になるけどきついもんな
でなんかだんだんやってくとあれも 必要これも必要みたいなたぶん
分かっていくってそうなんだけど いきなりじゃあ最初からanyとか
ミックス度で受け取るとちょっと つらいっすみたいなと思うので
緩やかなインターフェースの考察
げんえい
なんかたぶん緩いっていうか柔軟 なみたいな感じで捉えるといい
のかなっていうのはちょっとこの 話を受け取ったりとかもしたん
ですけど
きんじょうひでき
そうですねこれでもインターフェース 分離の原則とか抽象を使って
プログラミングせよみたいなそういう 話かなって思って読んでたんですよ
げんえい
ね
きんじょうひでき
うんうん
で具象クラス返しますじゃなくて ここはインターフェースを返します
みたいな話にすると曖昧にはせ ずに抽象度を上げて緩くするみたい
なのが成り立つと思うんですよね なんかそういう話なのかなって
思ってて
げんえい
普通に作るとそうしますよねっていう のはありながらなんだろうなでも
たぶん実際言いたいのはそういうこと なんだろうなっていうふうに読み
ながらただ単にタイトルが緩や かなって書いてあるからちょっと
危なそうだなっていう危険な香り を感じたりみたいな
きんじょうひでき
そうですね緩いの確かに罠になり がちとか緩いほうがズブズブになる
じゃんみたいな感じしますもん ね
げんえい
そうそうそうですぐに引きつを 増やして影響範囲が広いんでじゃあ
ここはデフォルトでフォルスを 渡してみたいな既存に影響を与え
ないようにみたいなことをやり 始めると吉波っぽい感じはする
けどだいたいそれって後でこう 辛い思いをするんだよなみたいな
きんじょうひでき
これはまた例によって写真もあんまり 理解のヒントになりづらいし
げんえい
そうですね緩やかなインターフェース を取って牛が外に出ているって
書いてあってこれは出ていい話 で出ているのか出ちゃいけない
はずなのに出てしまっているのか ちょっとどう捉えるか難しいな
って気持ち悪い
きんじょうひでき
出ていいんじゃないですか大げさ な柵とか檻とか用意しないでちょっと
柵の中に一部分だけドアみたいに 簡単に開け閉めできるようになって
てでドアが開いてるから牛が出入り してるよねみたいな話なんですけど
げんえい
これはだから出入り口のコントロール には成功しているって話なのか
なるほどなるほど
きんじょうひでき
かつその檻なんだ本当に全体を がってあげるような檻ではない
のでちょっと緩やかというか大げさ すぎない使い勝手がいいっていう
話なのかなあんまり写真を深掘り すると負けない気がするんだよ
なこの方
げんえい
そうかもしれない無理やり当てはめ たとかこの写真の群から選んで
きただけだったりするかもしれない から
きんじょうひでき
そうですねだからうまくデザインパターン 使っていくとええよみたいなやっぱり
あれじゃないですかアジャイル ソフトウェア開発の奥義なので
あれらは
げんえい
そうですね
きんじょうひでき
はいこんな感じがするなあちょっと もうあれですねもうちょい具体的に
どういう意図でどういう想定で この話してるんですかっていう話
はなんか聞いてみたいですね
げんえい
そうですね
きんじょうひでき
そんなところで次いきますか
パターンランゲージの考察
げんえい
次いきますか5.2でいくとどうですか ね
きんじょうひでき
まあでも割とそうですねそんなに なんかこのパターンランゲージ
自体はそんなにメムが少ないという かなんか変更用意性をどう保って
いくかみたいな結構慣れ親しんだ 話に近接してますもんねこのパターン
ランゲージ自体が
げんえい
この辺は別でも読んだしとか
そうそうそう
まあもしかしたら2人の関心がコード の底の部分よりももうちょっと
組織の話の方が興味が高いっていう 感じでもあるのかなっていう感じ
きんじょうひでき
はしますね
うんこっちはしょっちゅうカンファレンス 行ってるんだぞみたいなね気持ち
げんえい
にもなる
そうですね
うんじゃあ第5章全体そんなところ ですかね
げんえい
そうですね
きんじょうひでき
でそうすると具体的なパターン ランゲージというかパターンの
カタログみたいな話が終わって 第3文に入っていくと少しもっと
げんえい
小さくなりますね
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
小さくなる
