組織の
アーキテクチャ
工藤 由美
目的
メインの想定対象者は、
部門設計やチームの切り分けの設計を行うPM、PdMの方など向け。
【ToBeの姿】
意味のない生産性が低くなり、自分たちの視野も狭くなりがちな組織構
造を脱却し、
仕組み的に組織全体で視野が広く、全体最適な振る舞いをするようにな
るための
思考のベースが身についている。 2024/1/27
必要な知見(詳細は端折ります)
・境界付けられたコンテキスト
・コンポーネントの6大原則、SOLID原則&GRASP設計パターン
・契約による設計 DbC
・コンウェイの法則 ・モノリスとマイクロサービスアーキテクチャ
・TOC 制約理論
・KPIマネジメント
・仮説推論スキル
2024/1/27
コンウェイの法則
【組織構造の力学を強く受ける】というメカニズム。
大規模なサイロ化した組織では、特にちょっとでも放置すると
す~~ぐ目も当てられないほどのアーキテクチャになる。
最悪なのは
システムアーキテクチャと
組織アーキテクチャの乖離を
そのまま放置しておくこと。
2024/1/27
職能別(縦割り)
-視野の広さより専門性の高さが優勢したい時
よく見かける組織構造パターン。
【メリット】
専門性を高めやすく、他より学習コスト低い。
【デメリット】
視野が狭くなり、目的から考えにくくなり、
個別最適な振る舞い取りがちゆえ、
ボトルネック発生しやすい。
観点も偏る。変更、拡張性に乏しい。
2024/1/27
ドメイン別(情報は一か所)
-規模に関わらず維持したい形
プロセス面で、コンテキスト境界はったモジュラーモノリス。よほど大規模組織でないなら、これがベターな
傾向。
【メリット】
プロセス面では、他の観点の人と触れ合うことで
視野が広がりやすい。MSAより学習しやすい。
データのACID特性の担保のしやすさ。
【デメリット】
職能別よりスコープが広くなるので、
学習に時間がかかるのと、
抽象化スキルがないと粒度がバラバラに。
データは一か所に集中。
2024/1/27
ドメイン別(情報も別々)
-規模の拡大に伴い考えるべき選択肢
モジュラーモノリス+データ面でも境界はったマイクロサービス型。
【メリット】
意味のある単位で情報まで込みで
チームが切り分けられている。
拡張性や独立性に優れている。
【デメリット】
他のコンテキストとの結合や運用の一貫性、
学習コスト、移行コスト、分解コスト、
組織の文化が対応できないとダメ。
データのACID特性は保証できないのが前提。
2024/1/27
組織的に逆コンウェイ
職能別モノリスはたしかに規模が小さいとかならいいけど、事業が拡張してきた際には?
モジュラーモノリスを組織構造的に目指すにしても、責務の割当が適切にされてないと、
分散されたモノリスっぽくなりかねない。
ソフトウェア側の設計と一緒で、そのチーム名と責務が一致し、【チーム名前設計大事】
極力1つのチームに対して、1つの責務で高凝集になるように!!
関係ないもの混ざってると、コンテキストスイッチ発生して気が散り、生産性落ちる。
チームも大きさの粒度を揃えること!!
2024/1/27
事業間にも互いに相互作用働いてる
事業Aを伸ばそうとすると、
事業Bは相乗効果で利益向上するが、
事業Cは下がってしまうみたいな現象もざらに起こり得る。
それは市場っていう外部環境を通して、
事業同士が力を及ぼしあっている(大小ある)から。
プロダクトがそれぞれ違う市場を狙っていても、
市場と別の市場が相互作用を及ぼしあっている。
マーケターなどやデータ分析者とデータを元に相互作用メカニズムを類推し、事業同士のトレードオフ関係を
把握!
2024/1/27
評価制度の継続的メンテ
組織構造に合わせて、動的に評価制度の見直しをすべき。
ずっと評価制度がメンテされていない組織は、沈む船。
理想とする構造に合わせた評価制度(経営方針に従うよう
リスコフ置換原則満たしてるかチェック)を先に定義し、
トップダウン的に全体最適な振る舞いするよう調整。
必ず事業のKGIに対しても、各チームのKPIに対しても
Min~Maxを最初はおおよそでいいので定義。
これ以上伸ばしても他の事業への悪影響っていう所があるから。
2024/1/27
参考文献
2024/1/27
組織のアーキテクチャは、
設計分かってない経営層でなく
エンジニアやアーキテクト自身が
行っていくもの。
ビジネス構造にソフトウェアの設計思想
とかをアナロジー展開!
-エンタープライズアーキテクト目指してる工藤より

組織のアーキテクチャ(逆コンウェイ法則を用いて組織アーキテクチャを考える).pptx