開発チームが会社のプロダクトビジョンと足並みをそろえる4つのルール【テッククランチ】

ソーシャルニュースサイトを運営する米Diggの共同創業者で、ベンチャーキャピタリストでもあるKevin Rose（ケビン・ローズ）氏はかつて、「A team aligned behind a vision will move mountains. （ビジョンに沿っているチームは山を動かす。）」と言った。これは真理だ。成功するプロダクトを生み出すにはあらゆる不確実性を乗り越えなければならない。そのためには明確なプロダクトビジョンが必要だ。

開発チームがプロダクトビジョンに沿っていれば、意思疎通が容易になり、チームメンバーに意思決定権を委ねられる。すると、主要関係者への依存度が低くなる。このようなチームは、機能採用の促進や顧客エンゲージメントの向上、プロダクト中心な成果の実現をより重要視している。これは反復や生産コストの削減、市場投入までの時間の短縮、そしてビジネスマイルストーンの達成につながる。

新型コロナウイルス感染症のパンデミックを考えてほしい。スタートアップは通信経費、高い離職率、従業員の士気低下に苦慮し、生産性の問題に直面した。

しかし、プロダクトチームとの連携が取れているスタートアップは生産性を維持し、これまでとおりにイノベーションを起こすことができた。それはチームがプロダクトをつくる「理由」を理解していたからだ。

プロダクトの成功はそれを手がけるチームのコミットメントにかかっている。

筆者は過去16年間で約30のスタートアップのプロダクトを手がけ、わずか3人の小さなチームから150人の大所帯までのプロダクトチームを指揮した。こうした経験をもとに、率いるプロダクトチームがプロダクトのビジョンに沿うようにするために常に守る4つのルールをつくった。

• keyboard_arrow_down ルール1：個人の希望とプロダクトのニーズを一致させる
• keyboard_arrow_down ルール2：プロダクトマインドセットの原則に従う
• keyboard_arrow_down ルール3：ビジネスの成果とチームの重要目標を一致させる
• keyboard_arrow_down ルール4：シームレスなコミュニケーションを確保する

プロダクトの成功は、それをつくるチームがいかにコミットするかにかかっている。マイルストーンを達成するためには、プロダクトビジョンに共感してくれる優秀な人材が必要だ。そうでなければ、スキルはあっても当事者意識のない人材が集まってしまう可能性がある。

そうならないようにするには、一人ひとりの志向とプロダクトのニーズを照らし合わせる必要がある。その微妙なバランスをうまくとりながらチームのグレードを上げ、コミットメントのレベルをわずかたりとも落とさないようにしなければならない。

開発者と接するときに筆者心がけているのは、開発者が何をしたいのか、どのような成長を望んでいるのかを常に理解しようと努めることだ。

よく以下のようなフィードバックをもらう。

このような希望を把握し、それに応えることで、士気とエンゲージメントが高く、プロダクトビジョンとの整合性が高いプロダクトチームを容易につくることができる。同時に、個人はプロダクトに対する当事者意識を育み始める。このようなチームは不確実な時代にも影響を受けず、離職率も低く抑えられる。

筆者のチームはこのルールを戒律のように守り、常にその恩恵を享受してきた。実際、私たちは世界最大級のモバイル広告プラットフォームで働いていたときにこのルールを実践し、4年連続で離職率ゼロを達成した。

スタートアップが進化していく中で、プロダクトのビジョンを修正することがある。その修正を理解するには開発者のスキル、経験、希望を定期的にマップ化することが必要だ。

「プロダクトマインドセットの原則」はスタートアップや成長段階の企業にとって不可欠なものだ。というのも、プロダクトのデリバリーで戦略的な成果を約束するからだ。機能をつくるだけのスタートアップは、マイルストーンの達成が難しいかもしれないが、「プロダクトマインドセット」を導入すれば良い結果が望める。これらの役割は「must-do」（しなければならないこと）と「should-do」（したほうが良いこと）の2つに分けられる。

must-doにはコミットメントとデリバリー、技術的な問題の解決、短期的かつ敏捷性のある設計、最初から正しい手法を採用などが含まれる。一方、should-doにはスコープクリープの管理、より良い機能の採用、イノベーション、アーキテクチャの長寿化などが含まれる。

これらの目標を達成するためには、ユーザーストーリーを適切にマッピングし、ユーザーがその機能をどのように利用するか、その機能がプロダクトのKPIにどのような付加価値を与えるかを理解した上で、機能を本番リリースすることが必要だ。

「プロダクトマインドセット」の採用は私たちにとってゲームチェンジャーとなった。今ではプロダクトの要件を深く理解するためにユーザーストーリーを求め、共同で機能を開発し、仕様書とおりに機能をリリースすることよりも機能の採用を優先している。プロダクトオーナーは機能の投資利益率（ROI）に責任を負っているが、適切な質問をすることで最終目標を理解し、それに基づいて技術の実行を計画することができる。

仕事のやり方を変えようと思わせた例を紹介する。

多くのソフトウェア企業と同様、当社の開発者はユーザーの使用パターンにあまり目を向けず、記載された仕様に基づいて機能を迅速に展開することに注力していた。しかし社内で議論を重ねた結果、そうした機能がユーザーにどのような影響を与えるかを確認することにした。その結果、ユーザーの大半が機能の6割を使ったことがないことが判明。そうした事実を認識していなかったため、愕然とした。

あるときは、ターゲットユーザーの10％しか利用しない機能をつくるために、開発者が余計な労力を使ったこともありました。

より良いユーザーストーリーの作成で考慮すべき点は次の通りだ。

次に、機能のインパクトをより全体的に把握するために、機能の使用について考えをめぐらすべきだろう。

「プロダクトマインドセット」を持つことは不可欠だ。そうすることでエンジニアリング関連の効率的な活用、インパクトのある成果、真の当事者意識が得られ、プロダクトチームのモチベーションと連携を維持することができる。このマインドセットがうまく機能すれば、イノベーションを単なる一過性の活動ではなく仕事のやり方として定着させることができる。

目標達成に必要な鍵を握る項目（KRA）の設定はトップダウンで行うべきであり、単にデリバリーに限定したものとすべきではない。むしろ、ビジネス上の成果はプロダクトチームのKRAを推進すべきである。

筆者はこのことを苦労して学んだ。従業員は顧客と一緒に仕事をしながら個人のKRAを達成したが、そのようなKRAはチームにとって期待される効果を確保するのにあまり役立っていないことに気づいた。このようなことがあると、最初は偽りの達成感のようなものを得られるかもしれないが、後にチームの不満や混乱、士気の低下を招くことになりかねない。

その後、私たちは仕事のやり方を変えた。プロダクトのKPIに従ってチームの能力評価をマッピングし、個人活動レベルのKRAをなくした。これは、個人のKRAがビジネス上の成果と一致することを確認するのに役立った。その結果、チームメンバーのエンゲージメントレベルが大幅に向上した。チームメンバーはいま、自分の仕事を通じてインパクトを与えようと高い当事者意識とコミットメントを持っている。

例を挙げると、あるオンライン広告の顧客が収益を向上させようとしていた。私たちはプロセスの自動化、プロダクトのリエンジニアリング、ターゲティング広告の改善などアイデアを出し合ってKRAを設定した。そして最終的に各広告取引のテクノロジーインフラコストを15%削減することに成功した。

チームのKRAを定義するために、筆者は毎回4つのステップを使っている。

これらのルールは、個人のKRAとビジネスのKRAを一致させるために不可欠だ。一致していればチームの士気は高まり、個人の貢献は価値を増し、成果はよりインパクトのあるものになる。

プロダクトビジョンの管理に関する窓口を一本化することはお勧めしない。プロダクトビジョンが近視眼的になり、チームの優先順位とビジネスの期待値がずれてしまう可能性があるからだ。テクノロジーを活用すればそのような問題はかなり取り除けるだろうが、プロセスを大幅に改善したいのであれば、多対多のコミュニケーションに加えて、階層を超えた定期的な接触機会を設ける必要がある。

スタートアップは特にビジネスシナリオの変化が速く、敏捷性とスピードに傾倒しているため照準ミスの問題が発生しやすい。短期的、長期的なビジネス目標の変更をプロダクトチームに効率的に伝えるためには、定期的な接触機会と多対多のコミュニケーションが重要だ。

ほとんどのテレワーク企業では接点は1つしかない。筆者は3段階の接触モデルを採用している。これによりチームメンバー間の絆が深まり、意見や提案を気軽に伝え、疑問を解決することができる協力的な職場カルチャーが生み出される。

日次

通常、デリバリー部分を担当するチームリーダーは同僚や上司と連携してユーザーストーリーを作成し、機能のタイムリーなデリバリーと品質を確保する。スクラム会議、発表、全体会議、ロードマップの議論などを通じてこれらを確実に実行する。

月次

プロダクトロードマップに注力するエンジニアリングマネージャーは月に一度、チームの取り組みが短期目標に合致しているかどうかをチェックし、次の1～3カ月のプロダクトロードマップを決める。また、機能のデリバリーと採用、プロダクトの評価基準を追跡し、リスクを特定する。そして改善策を提案する。

四半期ごと

CTOまたはテクノロジー幹部チームの誰かが四半期に一度、プロダクトチームとやり取りする。この担当者はチームがプロダクトビジョンを理解していることを確かめ、今後3～6カ月間の優先順位を決め、主要リリースのタイムラインを確認する。そして新しいアイデアを共有し、ビジネスKPIをアップデートする。

この3段階の接触モデルは、変化するビジネス予想を管理し、関連する成果に対してチームの足並みをそろえるのに極めて効果的だ。

多対多のコミュニケーションを確保することでオープンな議論と有効活用の環境が生まれる。何か問題に直面したとき、説明が必要なとき、提案があるとき、誰もが気軽に誰かに連絡をとれるのが望ましい。このようなオープンな環境は、イノベーションとモチベーションを生み出す触媒となる。

From TechCrunch. © 2022 Verizon Media.  All rights reserved.  Used under license.

元記事：How to keep your development team aligned with the company’s product vision
By：Sanjoy Singh
翻訳：Nariko