先の投稿で、チームを独立させることの大切さについてお伝えしました。このアプローチにはデメリットはあるのでしょうか？
独立したチームを育てることの難点の一つに、エンド・ユーザーから見た際に、プロダクトが一貫してないように見えたり、ひょっとするとぐちゃぐちゃに見えたりしかねないという点があります。必ずしも、プロダクトや機能の質が悪いわけでもありませんが、完璧でもないかもしれません。例えば、フォントが Web ページ間で統一されていない、サイト内のあるセクションで保存したクレジットカード情報が他のセクションでは使えないなどです。チームを独立させたままにして、もっとイノベーションを起こせるようにすると、統合負債 (consolidation debt) が生まれるのです。
一貫性は、エンジニアリングとユーザー体験の品質にとって重要な要素です。けれど、早期の段階で一貫性を求めることは、良いアイデアを潰すことになるかもしれません。一定の統合負債を許すことは、必要悪でもあるのです。
統合負債を管理する
統合負債は技術的負債の一種です。統合負債はそれ自体がプロダクト間の冗長性や非一貫性を表しています。あなたが三つもログ・ライブラリを持っていたり、二種類の決済システムを持っていたりするのはこのせいです。上層部の考える自社ができることと、自社に本当に備わった力とそれを活用できる分野に対する認識のずれの原因でもあります。
技術的負債と同様に、事業が統合負債をもたないまま発展するというのは滅多にありません。だから心配することは何もないのです。ですが、そのまま統合負債を大きくなるままにしてしまうと、ちょうど蔦が木の幹を覆ってしまうみたいに、統合負債はプロダクトと事業にくっついて、それらを隠してしまいます。
「 うちの会社Xが多すぎる。一つにしたスーパー X をビルドして、全部のサービスで使えるようにしよう！ 」
こういう状況を何度も見たことありませんか。時には、素晴らしくうまく行くこともあれば、惨めに失敗することもあるでしょう。また、最終的な結果は普通で、元の状況より対して良くならなかったこともあるでしょう。でも間違いなく、あなたのチームは、団結することで少しは得たものがあったとしても、かなりの自主性を失ったはずです。なぜなら、このような状況では、本番に送りたいあらゆる新機能が、他チームとの連携を必要としてしまうからです。その後、ある程度時間が経つと、チームはイノベーションを起こす力を放棄してしまい、事業を前進させるというか、維持するしか望めなくなっていきます。
プロジェクトの統合は素晴らしい成功でなくてはならず、それ以下であってはならないのです。統合のメリットは、自主性の犠牲を大いに上回るものでなければいけません。
統合負債のプロジェクトを成功させるには
もし、複数の目的に埋め込まれ過ぎたり、問題解決のために作られたチームが初日からコミットメントにがちがちに縛られたりしている場合、統合は失敗したり、不十分になりうるでしょう。会社は問題を解決したいので、意味があろうとなかろうと、他のチームにインフラチームのプロダクトを取り入れるよう強要するからです。
インフラチームというのは、プロダクトチームと同じ、自由な精神の元に作る必要があります。独自の成功指標を持たないといけませんし、自身の取引する相手を攻略し、本音での批判に向き合い、置き換えようとしているその場しのぎのソリューションと競わなければいけないからです。
Indeedのエンジニアリングケーパビリティの担当グループは、冗長性を減らし、開発スピードをあげて、品質を維持する内部ツールやサービスのビルドに注力しています。私たちはこうした問題に対処する際も、外部に向けたサービスを開発するときに適用される、データや指標に基づくアプローチを使用して、問題に対処しています。
次は ?
次回の投稿では、「もしエンジニアに、彼らが作業するタスクを自分で決めさせたらどうなるか？」と言う事について、問いたいと思います。