義務と機会

複数の若い企業でエンジニアチームのリーダーを務めてきたある友人が、最近コアバリューについて興味深いことを言っていました。

私は二度と「説明責任」をコアバリューに含めるつもりはありません。まったく異なる3つの企業で、3つの異なる方法で試してみましたが、いつも結果は同じでした。自分ではなく、誰もが他者に、より多くの説明責任を求めるようになってしまいます。説明責任は実践すべきコアバリューではなく、他者を攻撃するための材料でしかありません。

これは、2010年代に Indeed が急成長したときに私が気づいたことと同じです。企業が成長して複雑になるにつれ、1つのチームの範囲を超え、複数のチームに共通する能力を改善していくことが難しくなりました。そしてこの数年では、次のような発言を耳にするようになりました。

• （物事X）は誰の責任ですか？
• （側面Y）は別の人が担当すべきだと思います。
• なぜリーダーシップは、（タスクZ）をこのチームの担当にしないのですか？

しかし、責任とは与えられるものではなく、自ら負うものです。

画像： Tumisu, Pixabay

この10年間で、私は何百人もの同僚たちと仕事をする機会に恵まれました。彼らは皆、非常に優秀で、Indeed 社内のさまざまなチームや社外のさまざまな組織で活躍できる人材です。もしマネージャーが、そうした従業員が興味を持てない、影響力の度合いも明確ではないような仕事を割り振っていたら、転職の機会を探し始めるのにそう長くはかからないでしょう。

Indeed のエンジニアチームのリーダーは、マネージャーがまだ数名しかいなかった頃から、指揮統制型のマネジメントよりもコーチング型のリーダーシップを重視してきました。このモデルにおけるコーチの仕事は、タスクや義務を与えることではありません。コーチは部下と一緒に機会を特定し、最善の機会を選び、実現できるよう支援します。

義務よりも機会を重視することの大切さが分かる実践的な例として、障害発生時のレトロスペクティブにおけるオーナーシップを挙げたいと思います。Indeed では長い間、非難をしない振り返りの習慣を推進してきました。つまり、過失を探すのではなく、要因を理解して再発を防ぐことに注力するのです。

しかし、つい感情的になって次のような発言をしてしまう場面を数多く目にしてきました。「あのチームが障害発生の原因なのだから、彼らが責任を取るべきだ」と。私の考えでは、これは少し論点がずれています。振り返ることは機会であって、義務ではありません。原因となった問題に関係していたかどうかにかかわらず、再発を防止できる立場にいる人が責任を持って振り返りを行うべきです。

チームの責任も、個人の責任と同じ

もちろん、Indeed でもチームがそれぞれの領域に責任を持っていますが、皆さんが想像するほどには、担当を明文化していません。例えばチームが実際の環境でサービスを稼働させる場合、健全でレスポンシブな、会社のポリシーに準拠したサービスを開発するのはチームの責任です。しかし、期限までに機能要求に応えることや特定の機能をサポートすること、特定の技術を使用することをチームに義務付けてはいません。

その代わりに、Indeed では、機会を探すようお願いしています。新しいユーザーをサポートすることは、他のチームが構築しているソリューションをユーザーに取り入れてもらえる機会につながるのでしょうか？どの機能が彼らのミッション達成に役立つでしょうか？新しい基盤技術を採用することで、断続的な優位性を見出せる分野はあるでしょうか？

プラットフォームチームのエンジニアリングリーダーとして、私は義務と機会について考えることがかなり頻繁にあります。例えば、私のチームはモジュール化したブラウザベースのUIプラットフォームを提供しています。そのプラットフォームに書かれるコードの大部分は、私たちが書いているわけではありません。プロダクトチームがプロダクト固有のモジュールを作成しています。プラットフォームチームのメンバーにモジュールが発するブラウザ側のエラーを監視する義務はもちろんありませんし、責任を負わせるのもスケーラビリティを考えると無理があります。しかし、今のところは、プラットフォームチームが監視できる状態ですし、実際に監視を行っています。モジュールの導入や保守にあまり慣れていないプロダクトチームを支援する機会を逃すのはもったいないことです。スケーラビリティの観点から長期的なサポートは難しいですが、新しいチームが容易に導入できるようになるだけでなく、ユーザーがどこで問題に直面しているかをプラットフォームチームが把握するのに役立っています。

コミュニケーションプラットフォームチームは、プロダクトチームが求職者や採用企業にさまざまなチャネルでメッセージを送るのを支援しています。長年にわたり、このチームはコアインフラストラクチャーチームと協力して、さまざまな仕事を担当してきました。

• 数年前、Postfixのパフォーマンスが大きなボトルネックになっていたとき、コアインフラストラクチャーチームはフィードバックを受けてパフォーマンスの問題を修正し、その後のメンテナンスを担当してきました。これは責任を果たした例です。
• さまざまなイシューがメッセージキューの耐久性保証に影響を与えた際、コアインフラチームには求められるレベルの改善を提供するための明確な道筋がありませんでした。私たちは、エンドツーエンドの送信に失敗したメッセージを検出して再送信することで問題を回避しました。これは責任を負うことを拒否した例です。
• 廃止された独自のKVSから移行する必要があった際、OpenStackを使用しているインフラチームがCephベースのソリューションの構築に強い関心を示しました。私たちはインフラチームと協力してソリューションのプロトタイプを作成しましたが、スケジュール的に十分なパフォーマンスを保証できないことが明らかになりました。後でCephのコストを最適化するという選択肢を残しながら、S3を使うことにしました。これは、責任を担うことが望まれたけれども、実現できなかった例です。

これらの例は、非常に重要なテーマにスポットライトを当てています。責任の所在は、チーム名だけでは決められません。責任は、チームが責任を担うことを望み、その能力がある場合のみに負うことができるものです。チーム名がStorage Systemsだからという理由だけで、OracleDBをサポートする義務はありません。ただ、彼らのロードマップの方向性が変わり、Storage SystemsチームがOracleDBをサポートすることで、顧客や関係者のニーズを満たすことができるなら、彼らがそのように判断して責任を負うべきでしょう。

同様に、やる気だけでも不十分です。Indeed の規模がまだ小さかった頃に初めてCassandraを使ってみたとき、その試みが失敗したのはテクノロジーに本質的な欠陥があったからではありません。大規模なクラスターを運用するための専門知識や能力が社内になかったために失敗してしまったのです。誰もがうまくいくことを望んでいましたし、チームは何とか成功させようとしていましたが、結果的には実現不可能でした。

機会に気付いてもらう方法

では、「物事X」「側面Y」「タスクZ」など、日常の仕事で出てくる機会について考えてみましょう。マネージャーが、それらをただ誰かに割り振るというわけにはいかない場合、まだ誰の手にも渡っていないその機会をどう進めていけばいいのでしょうか？

機会主導のモデルを効果的に実践するには、2つの基本的な条件があります。1つは機械的なもの、もう1つは文化的なものです。意外なことに、機械的な側面のほうが簡単です。

先ほど、コーチであるリーダーの責任は、機会の特定、機会の選択、そして機会の実現を支援することだとお伝えしました。

プロダクト主導型でサービスを提供する Indeed のような組織は、本番環境にソフトウェアを提供する能力を継続的に改善するために、すでに多くの取り組みを行っています。その機会について、ここで深く説明はしません。

機会の特定は、プロダクトデリバリーチームのコアスキルでもあります。しかし私たちが特に力を入れなければならなかったのは、機会を効果的に特定することでした。これは主に、良いアイデアが、それに取り組み実現できる人々の目に留まるようにすることを意味します。

利用者に配慮した受け入れプロセスは、社内のユーザーにサービスを提供するチームには欠かせません。このプロセスには、以下のようないくつかの重要な側面があります。

• 軽量であること：不完全なアイデアは後からいくらでも肉付けできますが、失われたアイデアは永久に消えてしまいます。
• 反応が早いこと：せっかくの提案がどこかへ消えてしまうことほど、同僚のやる気を削ぐものはありません。
• 組織のある程度大きな範囲で運営されていること：各デリバリーチームは通常、慎重に定義された狭い範囲に注力しています。これはデリバリーの効率化には有効ですが、チーム外の人にとっては、細かく調整された業務分担を理解するのは難しいことです。

効果的な受け入れプロセスには、依頼する側の協力も必要です。たとえ自分にとっては当たり前のことであっても、依頼の背景にある根拠や前提条件を明確にすることで、エンジニアがあなたの提示している機会に気付き、ワクワクして取り組めるようになります。価値提案を理解して伝えることは、前途有望なエンジニアが身につけるべき習慣であり、誰かがあなたの機会を選んでくれる可能性も高まります。

オーナーシップ（当事者意識）の文化

もちろん、機会に気付いて実行してもらうことを相手に委ねるには、同僚への心からの信頼が必要です。お互いの優先順位がおおむね一致していると信じているからこそ、論理的根拠にも説得力が出てきます。また、ほとんどの人が良い機会を待ち望み、それを実現する方法を探しているものであるということを信じなくてはなりません。

別の言い方をすれば、機会主導のモデルは、当事者意識が広く根付いている組織でしか機能しないということです。個人やチームが自ら責任を負う文化を育むために努力してきた Indeed では、義務や責任という言葉を使うことはあまりありません。チームや個人が責任を負うことを自ら選択したならば、彼らは最後までやり遂げるでしょう。

私の長年の同僚であるPatrick Schneiderが、オーナーシップの考え方をうまく説明しています。彼は、「自分の時間をどう使うべきか」という日常的な問題について、さまざまな立場でのオーナーシップを明確に示した「RACI」というツールを使って考えました。RACIとは、Responsible（実行責任者）、Accountable（説明責任者）、Consulted（協業先）、Informed（報告先）の頭文字をとったものです。

自分の時間をどう使うべきか

Patrick Schneider | 2019年5月16日

オーナーシッ	実行責任者	説明責任者	協業先	報告先
高	自分 自分の時間の使い方は自分で決めている。	自分 自分の行動と完了したタスク、そしてそれぞれの正当性を説明できる。	OKR、自分のプロダクトマネージャーやチーム、他のチームなど 自分の時間を有効に使えていると確信できるまで、必要な人に相談している。	自分のチームやプロダクトマネージャー、Jira、Slackなど 自分が何に時間を使っているか、定期的かつ積極的に伝えている。
中〜高	自分 選択肢の中から自分の時間の使い方を選んでいる。	自分 自分の行動と完了したタスクを説明できる。	自分 自分のマネージャーやプロダクトマネージャーが適切だと考える人に相談し、その上で選択肢や提案をもらっている。	自分のチームやプロダクトマネージャー、Jira、Slackなど 自分が何に取り組んでいるか、たいていの人が知っている。
低〜中	マネージャー 自分の時間の使い方はマネージャーが決めている。 プロダクトマネージャー 自分の時間の使い方はプロダクトマネージャーが決めている。	自分のマネージャーやプロダクトマネージャー、または自動化 自分のマネージャーやプロダクトマネージャーと、自動化されたシステムのいずれか、または両方が、自分の行動と完了したタスクを説明している。	自分 自分のマネージャーやプロダクトマネージャーが適切だと考える人に相談し、その上で選択肢や提案をもらっている。	自分のマネージャーやプロダクトマネージャー 自分が何に取り組んでいるかマネージャーとプロダクトマネージャーに伝え、彼らが適切だと考える他の人に伝えている。Jiraは通常、最新状態に保たれている。
低	マネージャー 自分の時間の使い方はマネージャーが決めている。 プロダクトマネージャー 自分の時間の使い方はプロダクトマネージャーが決めている。 人間以外例：受信箱に入ってきたメールの順番 人間以外の要素が時間の使い方を決めている。	不明または曖昧 多くの物事が進行中や作業中である。作業は進行形で表現されることが多く、完了したり説明することはほとんどない。	不明または曖昧 自分のマネージャーやプロダクトマネージャーが適切だと考える人に不定期に相談する。ランダム性またはアルゴリズム。	不明または曖昧 マネージャーやプロダクトマネージャーが、適切だと考える人に報告する。他の人が自分の仕事について知っていることもあれば、知らないこともある。

 

まとめ

説明責任は生産性の高いチームに欠かせない要素ですが、説明責任をコアバリューに単に据えるだけでは十分な効果を得ることはできません。それよりも、個人のオーナーシップを高める文化を浸透させ、機会にスポットライトを当てるプロセスを確立し、チームが自分たちのミッションにとって最も意味のある機会を追いかけられるよう、チームを強化することが重要だと感じています。