WAフレームワークにおける組織の話
社内のメンバーがAWS Well-Architected フレームワークについてドキュメントを読んで、感想語り合おうの会を開いてくれた。
普段業務でAWSは利用しているが、真剣にWAに関する記述を読んでこなかったので良い機会だと思い、参加している。
WAの柱についてはなんとなく知ってたので比較的読めたけど、アーキテクチャの項目が読みづらい。アーキテクチャ - AWS Well-Architected フレームワーク
特に2段落目
AWS では 1 つの中心チームに職能を持たせるのではなく、その職能を複数のチームに分散することが望まれています。意思決定権を分散することを選択した場合は、チームが内部の標準を満たしていることを確認する必要があるなどのリスクが発生します。当社はそのようなリスクを 2 つの方法で軽減します。第 1 の方法は、各チームがその職能を持てるようにするための プラクティス です。各チームで準拠する必要がある標準の水準を高めることができるように、専門知識を持った人を導入します。次に、実装する メカニズム を導入して、標準への準拠を徹底させることです。分散というこの方法はAmazon のリーダーシッププリンシパルに基づいており、お客様を起点とする 逆行 文化をすべての職務で確立します。お客様のことを真剣に考えているチームが、お客様の要件に応じて商品を開発します。
Amazonはマイクロサービス化を推進していくために、自律した複数のチームを作って開発を行っているんだと。これはマイクロサービスの文脈でよく出てくるコンウェイの法則の話かな。
この時にチームそれぞれが同じ水準で開発するために第一の方法として専門知識を持った人を導入?どういう人をどうやって決めるのだろう。
そして標準を守るための仕組みを構築するのだと。意識しなくてもできるように、専門知識を持った人がいなくてもいいようにってことかな?具体例ほしい。
逆行文化ってのはworking Backwardsでお客様を起点に考えるということでAmazonで大切にされている考え方のようだ。Working Backwards (the Amazon Method) | Definition and Overview
この考え方も書かれたAmazonのリーダーシッププリンシパルはAmazonの社員が日々意識することのよう。弊社にもフィロソフィというものがあるな。
あとはそれぞれのチームが参考にするベストプラクティスをプリンシパルエンジニアの仮想コミュニティが作っていくべきだとも書いてある。
機能単位で定期的に集まるコミュニティだろう。フロントエンド定例だとか運用定例だとかそんなところだろうか。
そしてここで決まった内容をランチタイムミーティングで共有して録音しておくと。
今のPJでも録音はしてないけど、ランチタイムに知見共有する文化ある。
確かにこれを新規参入者のオンボーディングに活用できそうだ。
正直、組織の構造って意識してこなかったから今のPJに当てはめると・・みたいなのがあまり出てこなかった。
もう少し視座を少し上げて業務していきたいなー。