チームコラボレーションツールについて
Qiita:teamやesa, Confluenceなど情報共有のためのツールで最近はどれがいいのかなと久しぶりに探してみたけど、どれを使うのがいいか、という議論自体はあまり本質的ではない気がしてきた コラボレーションの方法はチームカルチャーそのものでありどういったチームにしたいかが自分達で分かっていれば自ずと一番正しいコラボレーションの方法が決まるのではないか コンウェイの法則のようにそのチームが使うソフトウェアの使い方はそのチームの組織構造を意識せずとも反映してしまう そのチームの組織構造に合わない構造のソフトウェアを使うとインピーダンスミスマッチを起こして導入してもうまくいかないという現象が発生する コラボレーションツールを導入しても最初だけ使ってなかなか更新されなかったり
自律型のmicroservices的組織構造であればそれぞれが自分たちの権限の元それぞれの最小チーム単位に最適なツールを採用決定するというのが正しい 官僚型のトップダウン組織であればトップダウン型のツールを使うのが正しいということになる
逆コンウェイ戦略のように理想とする価値を実現するソフトウェアの構造に合わせて組織の構造を変えるというのが戦略的には正しいかもしれない
意識的に理想とする価値をまず設定し、その価値を実現するソフトウェアを選択し、それに合わせて組織構造を変化させるということ
まず組織や業務ありきでそれに合わせてシステムを作成すると常に移り変わる組織の構造や人間とシステムのミスマッチが必ず起こる
ソフトウェアを変更するコストは多大なためそれよりは柔軟で移り変わりやすい人間を変える方が時代の変化に対応しやすい
コンウェイの法則が今なお有効だとすると最終的には自分たちでコラボレーションツールを作るというのがその組織構造を最も正確に反映するものだと言えるのでコストが許せば自分たちで作ってドッグフーディングするのがいいかもしれない コラボレーションツールを今SaaSとして売っている企業は最初は社内のコラボレーションツールとして作られたものも多い もちろんそういった企業は社内のコミュニケーションのために自社のツールを使っているがそういうのがある意味理想的な気もする
AWSがAmazon.comのために作られたようにソフトウェアのドッグフーディングというのはソフトウェアとそれを使う組織のインピーダンスミスマッチを防ぐための最も簡単な方法かもしれない
ある組織がかかえる問題は必ずしも他の組織がかかえる問題ではないのである組織で本当に必用なソフトウェアというのも自分達で作らない限りはほとんどミスマッチを起こす
大きすぎたり、小さすぎたり
全てを自分たちで作ることは出来ないがアプリケーションレベルで必用なことであれば自分達で作るというのが一番早い気もする
Unrealエンジンが元はUnrealというゲームのために作られたゲームエンジンだったように 現実的には複数のツールを組み合わせて自分の組織に合わせて取捨選択するというのがいいと思う
One size fits for allなソリューションは何にでも対応出来る分無駄な余白も生む
Unix哲学的に他のソリューションとうまく連携出来るシンプルなツール同士を組み合わせて自分の目的を実現出来るのが理想