Asana のエンジニア部門長、Prashant Pandey が薦める エンジニアチームの目標を設定する 10 のヒント

Asana Engineering TeamEngineering Team
2020年7月9日
facebookx-twitterlinkedin
Engineering goals article banner image

エンジニアリングチームのリーダーにとって、目的、計画、責任の明確性を提供することがチームへの最大の貢献です。先日、Asana のエンジニアリング部門長、Prashant Pandey が、明確性がそれほど重要である理由と、明確性が目標に及ぼす影響について、Plato とじっくり語り合いました。チームが世界のどこで働いていたとしても、チームにとって明確で、モチベーションにつながるエンジニア部門の目標を設定するための、彼のインサイトとアドバイスをご紹介します。

Q: Asana のエンジニアリングチームは目標設定にどのようなアプローチをとっていますか?また、リモートワークへの移行後にこのアプローチはどのように変化しましたか?

A: Asana では、明確性こそチームの足並みを揃えると考えています。それが製品づくりと、会社としての目標設定に対する私たちの姿勢です。具体的には、私たちは明確性を「目的の明確性」「計画の明確性」「責任の明確性」という 3 つの枠組みで捉えています。

  • 「目的」とは理由。つまり、なぜ、 この仕事に取り組み、この目標を設定するのかということです。

     

  • 「計画」とは手段。 それをどんな手段で実行するのかに当たります。

     

  • 「責任」とは誰が何をするのか。 目標を達成するために、各メンバーがどんな貢献をするのかを意味します。

私たちは OKR のメソッドに従い、ボトムアップとトップダウンの両方のプロジェクトを組み合わせ、会社レベルの目標を設定しています。目標を設定すると、各チームはその目標に貢献する個別目標と、その達成を支援する、主要な成果指標を設定します。

変化という点についていえば、分散型のエンジニアリングチームの環境を作ることは、外出自粛期間中の働き方とはかなり違うと思います。オフィスで一緒に働くメンバーを雇うのではなく、離れて働きながら現実的に達成できるものは何かを考え直すようになりました。影響が出ることは初めからわかっていましたが、まず、エンジニアリングチームに、数週間かけて状況を把握し、個人の生産性やチーム全体としてのスピードへの予想される影響を知らせるように指示しました。それをもとに、本来計画していた目標のスケジュールを変更したり、完全に見直したりして、目標を設定し直したんです。外出自粛前も、明確性を重視していましたが、そのおかげでこの変化を効率的に乗り切れましたし、今も、新しい目標に向かって邁進できています。

Q: OKR などの目標設定の枠組みを実践する際に、チームが直面する問題には何があるでしょうか?

A: カスタマーチームで見られた最大の問題は、目標の計画プロセスと実行の乖離です。多くの企業では、計画プロセスがあり、時間をかけて大きな目標を考案して正式な文書にまとめます。ところが、その文書が承認されてしまうと、実際の仕事とのつながりが切れてしまいます。そして、実行プロセスに入ると、まったく違う方向に動いていくことにすぐに気づきます。チームリーダーやチームメンバーは四半期ごとや半年ごとに目標の見直しを行うかもしれませんが、それは日々の仕事に結びついていないのです。同時に、チーム間でお互いに会社の目標にどう取り組んでいるかを見ることも難しく、これも意思共有の問題を作り出します。

たとえば営業チームのリーダーが目標に対するエンジニアリングチームの進捗を見たい場合、膨大なメールをチェックして状況を把握したり、そのためにプロジェクトマネージャーを雇ってステータスレポートを作らせたりといったことをしなければならないでしょう。ところが、レポートができたときには、仕事は先に進んでいるのでデータはすでに古くなっているのです。

部門間で情報を明確かつリアルタイムに把握できれば、ビジネスの機動性が高まり、即時性をもって人材の配置や優先事項の変更などの決定を下せます。OKR は仕事と直結していることが重要です。業務遂行の核となり、容易に変更可能でなくてはなりません。私自身は、経営陣がチームの成果を測定するためではなく、チームが自身の進捗を測る方法として機能するのが、理想的な OKR だと考えています。

Q: 曖昧な方向性や、あまりにも野心的な抱負しか知らされていないときに、チームの目標を設定する場合のアドバイスはありますか?

A: 一般的に、エンジニアリングチームのリーダーの大きな責任の一つは、曖昧さを明確性に変えることだと考えています。こうした立場にいるなら、難しいとだけ捉えるのではなく、チャンスだと考えましょう。曖昧な内容にどう取り組むか、チームに明確性を提供してください。関係するトップやチームにとって明確なプランを立てられれば、大きな信頼を勝ち取れます。

Q: 上級のリーダーが従業員教育やプロセス、品質などの、製品以外の分野で目標を立てようとする場合、どんなアドバイスがありますか?

A: まず、目標を立てる際に、経営陣からどれだけの了承を得る必要があるか確認します。次に、目標の中で最も重要なものを、チームと相談しながら決定します。品質を例にとると、チームがすでに高品質の製品機能を納品できているなら、さらに積極的な目標を立てるタイミングではないでしょう。ベースラインを設定して、経時的に業務の測定を始めたり、何かが滞った場合に気づけるようにするのがよいと思います。目標を追求するために必要な時間や余裕を判断することも重要です。十分に時間がなければ、完全に失敗に終わることも考えられます。次に目標を設定する際は、そうした情報を考慮してください。

また、わたしはこうした目標をビジネス目標として捉え直すようにしています。ここでも品質の例を挙げますが、エンジニアが低品質の機能を出荷すれば、後でバグのトリアージや修正に時間がかかることになります。これは時間とコストの無駄につながり、明らかにビジネスに影響を与えます。では、それを織り込んで、品質目標をどう捉え直すべきか。簡単ではありませんし、少しばかりマーケティングも必要ですが、このスキルは持っておくに越したことはありません。

Q: 目標は常に定量化可能であるべきですか?

A: 一言でお答えすればイエスです。チームには目標を達成できたかどうか測定する基準が必要です。私は普段、プロジェクトの最後になって議論するのではなく、前もって時間をかけて基準を設定すべきだとチームにアドバイスしています。ですが、すべてを定量化するのは簡単ではありません。「来年は今年よりもセキュリティを高めよう」といった、ぼんやりした目標もあり得ます。それはそれでいいとして、これが意味することは何かを考えなくてはいけません。明確な一つの答えはなくても、この目標をいくつかの小さなパーツに分解することはできます。たとえば 2 つの新しいセキュリティ認証を受けるだとか、データ漏洩を X% 削減するとか、特定の SLA を達成するといった具合です。3 ~ 6 か月後にプロジェクトが成功しているとみなすには何が必要かを考え、そこから手を付けましょう。

Q: 優秀なチームメンバーの目標はどのように設定しますか?

A: 自分で決めてもらいましょう。マネージャーの仕事は、一日中目標を設定することではありません。目標設定は、みんなで助け合い、互いに目標を設定し合うコラボレーションのプロセスです。そのスキルをチームで活用しましょう。そうしたスキルがまだないチームなら、メンバーにそうしたスキルを身につけるよう促します。

Q: 目標設定に開発チームはどの程度、関与するべきですか?

A: 私は、少なくともある程度は、開発チームは常に目標設定に関与すべきだと考えています。なぜなら、誰でも、自分が設定に参加した目標には、よりコミットするものだからです。たとえば医療業界のように、適切な背景情報がすべて得られないような状況もありますし、ドメインに関する知識の豊富なプロジェクトマネージャーと比べて、背景知識の少ない開発チームが目標を設定するのは難しい場合もあります。しかし、私はそういう場合には、全員が状況を把握できるように、トレーニングを行うようにしています。開発チームが解決すべき問題のコンテキストを得られれば、その分、よい製品ができますから。

Q: チームと会社の目標の優先順位付けに関して、Asana にはどんな枠組みがありますか?

A: 会社レベルでは、カスタマーフィードバック、製品ビジョン、リソースのキャパシティという 3 つのインプットがあります。まず、お客様と直接やりとりのあるチームからインサイトを収集し、それらを私たちの製品ビジョンに照らして測定します。Asana は「コラボレーションをいっそう容易にする」という、非常に明確なビジョンをもとに設立された企業です。会社全体の目標にロックオンしたら、各チームの裁量で、そうした目標に向かって仕事の照準をどう合わせていくかを決定します。

Q: 面白そうなエンジニアリングの目標と、ビジネス上必要なエンジニアリングの目標のバランスの取り方を教えてください。

A: エンジニアたちに、自分たちが面白いと思うプロジェクトを、どうすればビジネスを前に進めるプロジェクトに転換できるか考えてもらうことから始めるでしょうね。「なぜこのプロジェクトが重要なのか」「これによってどんなビジネス上の価値が生まれるか」といった問いに答えてもらうのです。私が見てきたたいていのチームには、メンバーがやってみたいと思う仕事をする余裕があります。必要なのは、あと一歩掘り下げて考えることですね。他にできることは、将来の計画を立てることです。チームがやりたがっていることの優先順位が低い場合は、まずチームがそのことをしたがっていると認識し、ロードマップのどこにそれが当てはまるかをチームに示し、今すぐ達成する必要がある目標に向かって認識を統一するといいでしょう。

Q: エンジニアリングチームのダイバーシティやインクルージョンに関する目標設定のヒントがあれば教えてください。

A: ダイバーシティとインクルージョンに関する目標をビジネスの優先事項にしましょう。ビジネスの観点でこうした考え方を支持しない限り、優先事項から外れてしまいます。また、私はインクルージョンの問題をまず解決するようにチームを促しています。チームに所属する社会的少数者のメンバーたちが、居心地よく、歓迎されていると感じられる環境を必ず作る必要があります。あらゆる面において、彼らにとって完全にインクルーシブな環境ができていないという前提に立ち、その問題を解決するところから始めましょう。

今すぐ目標設定プロセスをレベルアップしましょう

これらのヒントは参考になりましたか?下のコメント欄で、あなたのエンジニアリングチームが目標設定にどのように取り組んでいるか、ぜひ紹介してください。