先の投稿で、チームを独立させることの大切さについてお伝えしました。このアプローチにはデメリットはあるのでしょうか？

独立したチームを育てることの難点の一つに、エンド・ユーザーから見た際に、プロダクトが一貫してないように見えたり、ひょっとするとぐちゃぐちゃに見えたりしかねないという点があります。必ずしも、プロダクトや機能の質が悪いわけでもありませんが、完璧でもないかもしれません。例えば、フォントが Web ページ間で統一されていない、サイト内のあるセクションで保存したクレジットカード情報が他のセクションでは使えないなどです。チームを独立させたままにして、もっとイノベーションを起こせるようにすると、統合負債 (consolidation debt) が生まれるのです。

一貫性は、エンジニアリングとユーザー体験の品質にとって重要な要素です。けれど、早期の段階で一貫性を求めることは、良いアイデアを潰すことになるかもしれません。一定の統合負債を許すことは、必要悪でもあるのです。

統合負債を管理する

統合負債は技術的負債の一種です。統合負債はそれ自体がプロダクト間の冗長性や非一貫性を表しています。あなたが三つもログ・ライブラリを持っていたり、二種類の決済システムを持っていたりするのはこのせいです。上層部の考える自社ができることと、自社に本当に備わった力とそれを活用できる分野に対する認識のずれの原因でもあります。

技術的負債と同様に、事業が統合負債をもたないまま発展するというのは滅多にありません。だから心配することは何もないのです。ですが、そのまま統合負債を大きくなるままにしてしまうと、ちょうど蔦が木の幹を覆ってしまうみたいに、統合負債はプロダクトと事業にくっついて、それらを隠してしまいます。

「 うちの会社Xが多すぎる。一つにしたスーパー X をビルドして、全部のサービスで使えるようにしよう！ 」

こういう状況を何度も見たことありませんか。時には、素晴らしくうまく行くこともあれば、惨めに失敗することもあるでしょう。また、最終的な結果は普通で、元の状況より対して良くならなかったこともあるでしょう。でも間違いなく、あなたのチームは、団結することで少しは得たものがあったとしても、かなりの自主性を失ったはずです。なぜなら、このような状況では、本番に送りたいあらゆる新機能が、他チームとの連携を必要としてしまうからです。その後、ある程度時間が経つと、チームはイノベーションを起こす力を放棄してしまい、事業を前進させるというか、維持するしか望めなくなっていきます。

プロジェクトの統合は素晴らしい成功でなくてはならず、それ以下であってはならないのです。統合のメリットは、自主性の犠牲を大いに上回るものでなければいけません。

統合負債のプロジェクトを成功させるには

もし、複数の目的に埋め込まれ過ぎたり、問題解決のために作られたチームが初日からコミットメントにがちがちに縛られたりしている場合、統合は失敗したり、不十分になりうるでしょう。会社は問題を解決したいので、意味があろうとなかろうと、他のチームにインフラチームのプロダクトを取り入れるよう強要するからです。

インフラチームというのは、プロダクトチームと同じ、自由な精神の元に作る必要があります。独自の成功指標を持たないといけませんし、自身の取引する相手を攻略し、本音での批判に向き合い、置き換えようとしているその場しのぎのソリューションと競わなければいけないからです。

Indeedのエンジニアリングケーパビリティの担当グループは、冗長性を減らし、開発スピードをあげて、品質を維持する内部ツールやサービスのビルドに注力しています。私たちはこうした問題に対処する際も、外部に向けたサービスを開発するときに適用される、データや指標に基づくアプローチを使用して、問題に対処しています。

次は ?

次回の投稿では、「もしエンジニアに、彼らが作業するタスクを自分で決めさせたらどうなるか？」と言う事について、問いたいと思います。

前回の投稿では、チームを独立させることの大切さについてお伝えしました。今回の投稿では、間違いを学びに変えていくことを、Indeed ではどのように奨励しているかについて触れていきたいと思います。

多くの組織では、間違いと言うのは、計画には絶対に含みません。計画は常に成功するものとして、設定されます。計画というのは、「これやあれがさっぱり間違っていた場合」なんていう段階を含まないのが普通です。ほとんどの場合、これは単なる癖によるものであったり、時には誰かのエゴがそうさせていたりします。

…このアイデアすごい冴えてるし、失敗なんてありえないよ。皆を集めて、素晴らしさを祝おうぜ。失敗しても、プロジェクトオーナーのせいにすればいいよね、絶対あいつらのせいだから。それとも、要件を理解できなくて、技術的問題を解決できるほど賢くなかったエンジニアのせいにしようか。いやいや、マーケティングチームとかセールスだよ。あいつら、競合も欲しがってたプロダクトを手に入れたくせに、こけたんだからさ…

NASAは、月に人を送る前に、何度失敗を重ねてきたのでしょうか。スペースXは、初めて帰還に成功するまで、いくつロケットを失ったでしょうか。これらの組織が成功したのは、間違いをおかさなかったからではありません。むしろ、どう間違えて、そこから学んでいくかというプロセスの定義をしていたからです。

Indeed では、間違いが学びに変わるように、間違いをプロセスに組み込んでいます。

1. 推測を特定する　自問自答をし続ける代わりに、あなたのアイデアが失敗するものだと思っている人に相談してみましょう。このときお互いを説得しようとしないこと。（たいてい無理なので。）代わりに、科学的に、どこに真実があるのか実証するような、可能な限り最小の実験ができるよう摺り合わせてみましょう。
2. テスト・フレームワークを使用する　ビフォア・アフターの比較は、通常、多くの人が取る手段ですが、弱点もあります。外的要素はどうなるのか？複数の実験を、どうやって同時に行うのか？ Indeedでは本番に送るもの全てに対して A/B テストを使用します（優先度の高いバグを除く）。
3. 出来るだけ細かいステップを踏む　 一度に一つの事を変更しましょう。複数の推測や変数を同一の実験の中にいれるのは避けること。
4. 責めない 本当の間違いは、何も学ばないことです。何かが上手くいかないとき、結論を出して、次の実験に移りましょう。素早く失敗すれば、間違いは、キャリアにとっても個人的な妨げには、なりません。

次は ?

次回の投稿では、冗長性や非一貫性として表される技術負債の一種である、統合負債 (consolidation debt) の管理についてお伝えします。

(編集者より: 五年前、 Indeed が日々取り組む技術についてお伝えするため、このブログを開設しました。あれから、会社の規模は10倍以上に拡大し、私たちは、 Indeed を世界 No.1 の求人サイトにするソフトウェアを開発し続けています。これを記念して、Indeed エンジニアリング・マネージャーのJames Dingleの一週間にわたる連載を掲載します。このシリーズでは、Indeedエンジニアリングが働きがいのある職場である理由の核心となる部分に、スポットライトを当てていきます。)

過去5年間の Indeed エンジニアリングのブログ内容を元に作られたワードクラウド

---

Indeedに在職するこの一年半の間、私はソフトウェアを利用して事業目標を達成する、新しい方法を知りました。 Indeed の文化の元になるものや、その要素は、とても驚くべきものです。なので、もし実際に行われる現場を見なければ、こんなことをしている企業は失敗の運命を辿っているのでは…とあなたは思うかもしれません。でも、実際はその逆です。こうした Indeed の文化の根源にあるものには、熟考の末生まれたものもありますが、自然と生まれたものもあります。このシリーズでは、Indeedのそうしたエンジニアリング文化の原理について、私の考えを述べていきたいと思います。

ステップ 1: チームを独立させる

一般的に大きな組織では、企業は総括的なビジョンを定義し、それをプロダクト、ストーリー、機能、そしてタスクなどに細分化していきます。これらのタスクはチーム間を移動し、チームから別のチームへと期日に渡されます。

依存しあうチームが多すぎると、期日を守ることが、タスクの提供する価値より大事になってしまいます。そうなると、チームは予定していた作業の一部をはぶくようになり,プロダクトの魅力が中途半端になり、機能のバランスも崩れ、満足のいかないユーザー体験に繋がります。

これは企業文化にも痛手です。チームが期日をのばすと、組織も、責任追及や守りのマネジメントに流れてしまいます。ほとんどのソフトウェアプロダクトでは、こうした期日は外部の予定と結び付くものではありませんが、一部のマネージャーは、プロジェクトには絶対に守らなければいけない期日があるかのように、タスクを進めていきす。

新しいプロダクトの設計というのは、プロジェクトを進めていく上で直面する問題
やその解決にかかる時間など、、予測できないことがつきものです。プロダクトが一定のサイズを超えると、予想される期間にバッファを取っても、うまくいくとは限りません。だからこそ、より小さく独立したチームがとても重要になるのです。

独立したチーム（と不確定な期日）は、予定表の大きなマイルストーンがあると喜ぶような重役を、躊躇させてしまうのかもしれません。彼らは、マイルストーンが組織内外に、明確さ、モチベーション、そして説明責任をもたらすと信じているのかもしれません。もしプロダクトが、砂のように細かい機能の流れになってしまったら、管理できなくなると思っているのかもしれません。期日がなければ、皆が怠けて永遠にさぼり続け、何も完成させなくなると思っているのかもしれません。でも実際には、従業員は現実的でいる理屈をいくつも持っています。

独立したチームは、チームとマネージャー両方に有益です。　

チームが独立していると、次のようなメリットがあります。

• 摩擦が減らせる
• 実際に貢献した人がプロダクトに対し、さらに当事者意識を持てるので、さらにモチベーションや自発性を高める
• チームが大体の決定を下せるので、きちんとチームの文脈が理解される

上層部のマネジメント陣にとって、チームの独立は次のメリットがあります。

• その仕事の及ぼす、実際の事業への影響に対してチームが説明責任をもてる
• チームが失敗したり作業が遅れたりした場合の、企業の戦略全体に影響するリスクを削減できる
• チームがもっとリスクを取れるようになる

そして、チームを独立させるには、次の事が必要になります。

1. チームがプッシュやロールバックを好きなだけできる、効率的なデプロイのパイプライン
2. チームだけが動かせるゴールや指標
3. 新しい機能や実験の影響を評価できるテストフレームワーク
4. 効率的なデータ収集と分析のパイプライン

Indeedでは、急成長をする中で、上記の四つの性能を開発することに力を注いできました。ゴールはトップダウンで与えられるものですが、イノベーションはボトムアップで起きるのです。

その次は ?

次回の投稿では、失敗から学ぶことの重要性について掘り下げていきたいとお見ます。