part.1 で書いた以外の学びになったこと、重要そうなエッセンス
認知負荷
ワーキングメモリ(作業や動作に必要な情報を一時的に記憶・処理する能力)にかかる負荷のこと。
この容量は多くないので、抱える作業が多くなってくると情報を処理しきれなくなってしまう。
例えば、チームが複数の複雑なドメインを抱えると、認知負荷は高くなり意図せず不具合を生じさせ、その対応に追われることが多くなってしまうかもしれない。適切に切られていないマイクロサービスも認知負荷になりうるだろう(ドメインを適切に切れていなかったりすると結局依存関係で苦しむ)
認知不可は 3 つに分けれられる
-
課題内在性負荷
- 問題領域の本質的なタスクに関連するもの(コーディングなど、どう作ればいいか)
-
課題外在性負荷
- タスクが実施される環境に関連するもの(サービスをどうやってどこにデプロイするか)
-
学習関連負荷
- 学習を進めたり、高性能を実現する上で特別な注意が必要なタスクに関連するもの
- サービスとの関係
認知負荷とうまく付き合うためにチームでドメインを
- シンプル
- 煩雑(変更の分析が必要で、適切なソリューションの提供には数回の繰り返しが必要)
- 複雑(ソリューションの提供には、多くの実験、探索が必要)
にわけて、チームに割り当てていく。煩雑なものはチームで2つ以上抱えないようにするとよいとされていた。
チームをAPIで運用していくために
- サービスレベル
- クォータ
- スロットリング
などを定義して公開する。AWS はこのやり方。
サイロ化
言葉の定義の再確認。
各部門、チームが独自に業務を遂行し、それぞれ孤立している状態。
何が問題かと言うと、ビジネスにおいて1つのチームで完結するということは中々ないのでチーム感での認識齟齬やフィードバックが伝わらないのはリスク。伝達ミスも起こりうる。
複数チームでもうまくやるためには、リーダーが全体像を伝えて同じ方向にチームが進むようにする。OKR とかの文脈に近そう。これもトップダウンでやること落としてみんなで頑張ろうというものだから。
ダンバー数
グループ内の認知や信頼に関する上限値
1人の人間が信頼できるのは 150 人。更に親密になれるのは 5
グループの単位としては
5, 15, 50(ファミリー), 150(高信頼), 500(部門) があげられている
これを目安にグループとして分割を行っていくのがよい。
ソフトウェア開発のチームとしては 5 ~ 8 人
信頼がなぜ必要かと言うと、ないときには不信によって不適切な決断が行われる可能性がある。実験もできない。
なので信頼が最大化できる状態を保てるようにしておくのがいい。
組織の設計
与えられたシステムのアーキテクチャに対するソリューションの数
デリバリ速度 → 組織設計がどれほど多くのチーム間の依存関係を組み込んでいるか
すなわち、依存やコミュニケーションパスを限定するのが速度を上げる近道
ただ、不確定要素を探るにはチームのコラボレーションは効果的
分散モノリス
サービスとして分割はされているものの、依存関係によって本来のマイクロサービスのメリットが受けられなくなっている状態。
分散モノリスになっていそうな例
- すべてを同時にデプロイしないといけない
-
社内にフルタイムのリソース調整マネージャがいる
- リリースタイミングを調整する人が必要になっている
- リリース前にサービスの組み合わせで E2E テストが必要
ソフトウェア境界の節理面
節理面 → ソフトウェアをかんたんに複数分割できる自然な継ぎ目
- ビジネスドメインのコンテキスト境界
-
規制遵守
- PCIDSS は厳密すぎるので必要な一部にのみ適用したい
- パフォーマンス分離
-
リスク分離
- 重要な機能は切り離しておく
- ユーザペルソナ
-
技術
- 基本的にはやらない
- ios, android など複数デバイス対応必要な場合には考慮が必要