(編集者より: 五年前、 Indeed が日々取り組む技術についてお伝えするため、このブログを開設しました。あれから、会社の規模は10倍以上に拡大し、私たちは、 Indeed を世界 No.1 の求人サイトにするソフトウェアを開発し続けています。これを記念して、Indeed エンジニアリング・マネージャーのJames Dingleの一週間にわたる連載を掲載します。このシリーズでは、Indeedエンジニアリングが働きがいのある職場である理由の核心となる部分に、スポットライトを当てていきます。)
過去5年間の Indeed エンジニアリングのブログ内容を元に作られたワードクラウド
Indeedに在職するこの一年半の間、私はソフトウェアを利用して事業目標を達成する、新しい方法を知りました。 Indeed の文化の元になるものや、その要素は、とても驚くべきものです。なので、もし実際に行われる現場を見なければ、こんなことをしている企業は失敗の運命を辿っているのでは…とあなたは思うかもしれません。でも、実際はその逆です。こうした Indeed の文化の根源にあるものには、熟考の末生まれたものもありますが、自然と生まれたものもあります。このシリーズでは、Indeedのそうしたエンジニアリング文化の原理について、私の考えを述べていきたいと思います。
ステップ 1: チームを独立させる
一般的に大きな組織では、企業は総括的なビジョンを定義し、それをプロダクト、ストーリー、機能、そしてタスクなどに細分化していきます。これらのタスクはチーム間を移動し、チームから別のチームへと期日に渡されます。
依存しあうチームが多すぎると、期日を守ることが、タスクの提供する価値より大事になってしまいます。そうなると、チームは予定していた作業の一部をはぶくようになり,プロダクトの魅力が中途半端になり、機能のバランスも崩れ、満足のいかないユーザー体験に繋がります。
これは企業文化にも痛手です。チームが期日をのばすと、組織も、責任追及や守りのマネジメントに流れてしまいます。ほとんどのソフトウェアプロダクトでは、こうした期日は外部の予定と結び付くものではありませんが、一部のマネージャーは、プロジェクトには絶対に守らなければいけない期日があるかのように、タスクを進めていきす。
新しいプロダクトの設計というのは、プロジェクトを進めていく上で直面する問題
やその解決にかかる時間など、、予測できないことがつきものです。プロダクトが一定のサイズを超えると、予想される期間にバッファを取っても、うまくいくとは限りません。だからこそ、より小さく独立したチームがとても重要になるのです。
独立したチーム（と不確定な期日）は、予定表の大きなマイルストーンがあると喜ぶような重役を、躊躇させてしまうのかもしれません。彼らは、マイルストーンが組織内外に、明確さ、モチベーション、そして説明責任をもたらすと信じているのかもしれません。もしプロダクトが、砂のように細かい機能の流れになってしまったら、管理できなくなると思っているのかもしれません。期日がなければ、皆が怠けて永遠にさぼり続け、何も完成させなくなると思っているのかもしれません。でも実際には、従業員は現実的でいる理屈をいくつも持っています。
独立したチームは、チームとマネージャー両方に有益です。
チームが独立していると、次のようなメリットがあります。
- 摩擦が減らせる
- 実際に貢献した人がプロダクトに対し、さらに当事者意識を持てるので、さらにモチベーションや自発性を高める
- チームが大体の決定を下せるので、きちんとチームの文脈が理解される
上層部のマネジメント陣にとって、チームの独立は次のメリットがあります。
- その仕事の及ぼす、実際の事業への影響に対してチームが説明責任をもてる
- チームが失敗したり作業が遅れたりした場合の、企業の戦略全体に影響するリスクを削減できる
- チームがもっとリスクを取れるようになる
そして、チームを独立させるには、次の事が必要になります。
- チームがプッシュやロールバックを好きなだけできる、効率的なデプロイのパイプライン
- チームだけが動かせるゴールや指標
- 新しい機能や実験の影響を評価できるテストフレームワーク
- 効率的なデータ収集と分析のパイプライン
Indeedでは、急成長をする中で、上記の四つの性能を開発することに力を注いできました。ゴールはトップダウンで与えられるものですが、イノベーションはボトムアップで起きるのです。
その次は ?
次回の投稿では、失敗から学ぶことの重要性について掘り下げていきたいとお見ます。