「儲からない」のは誰の責任？アジャイルにおける「責任問題」とその解決策【ryuzee｜吉羽龍太郎】

アジャイルコーチの吉羽さんは、過去のレバテックLABの取材では何度も「アジャイルなプロダクト開発を成功させたいなら、短期的な数字に惑わされず、価値を届けることにこだわり抜くべきだ」と一貫して伝えてきました。

とはいえ、プロダクトの価値と売上が完全なイコールとは言い切れません。「売れるもの」をつくらなくてはビジネスとしては成り立たない。となると「売れるものをつくる責任」は、誰にあるのでしょう？アジャイルなプロダクト開発における「責任」をどう切り分けるべきなのか、詳しくお話を聞きました。

• keyboard_arrow_down プロダクトオーナーは説明責任を、経営者や事業責任者は結果責任を負う
• keyboard_arrow_down スクラムマスターの責務は、アジャイルなプロダクト開発を阻む要因を「スコープ問わず」取り除く手助けをすること
• keyboard_arrow_down 利害関係のコンフリクトを生みたくないなら、人事評価に定量目標を置かない

——今回のテーマは、アジャイルなプロダクト開発における「責任」の切り分け方です。プロダクト開発に関わる人たちは、それぞれどのような役割、責任を果たすべきでしょうか。

吉羽：ステークホルダーそれぞれの責任については非常に定義が難しいのですが、確実に言えるのは、分け方のお手本となるような明確なガイドは存在しない、ということです。

たとえ同業種であったとしても、組織や事業のサイズ、組織としての成熟度、構成メンバーの顔ぶれ、プロダクトの成長フェーズなどによって、役割分担や誰がどの責任を担うべきかは動的に変わるものだからです。例えば、スタートアップなら創業者自ら描いたビジョンをもとにチームを率いるでしょうが、大企業の経営者は企業戦略や事業ポートフォリオのマネジメントに集中するのが一般的です。これほど違う以上、どの企業にも適応可能な「答え」はないんです。

とはいえ、アジャイルな開発チームのキーパーソンである「プロダクトオーナー」「スクラムマスター」の役割や責任は、ある程度決まっている部分もありますね。

——プロダクトオーナーの役割と責任とは何でしょう？

吉羽：前提として、アジャイル開発、とりわけスクラムの文脈において、「責任」という言葉は「説明責任」を指すことが多いです。

プロダクトオーナーは多くの場合、プロダクトの価値を最大化する役割を担い、その役割を全うするために、開発すべき機能やデリバリーの順番を決める権限を持ちます。そして、開発に関する主導権と引き換えに、説明責任を担います。

——では、「プロダクトの価値の最大化」と「売上の最大化」はイコールで結べるのでしょうか。もし同じ意味であるなら、開発したプロダクトが売上目標を達成できなかったら、プロダクトオーナーは説明責任に加え、結果責任を負うことになってしまいます。

吉羽：プロダクトオーナーが結果責任と無縁ではないにせよ、プロダクトの成否をプロダクトオーナーだけに背負わせるのは正しくないと思いますね。

プロダクトオーナーがきちんと説明責任を果たしているのであれば、下した意思決定には経営陣をはじめ関係部門から合意を得ているはず。結果責任はプロダクトオーナーに合意した人たちにも問われるべきです。

それに、よく知られているように、そもそも新規事業が成功する確率は高くありません。10個あればそのうち1つは成功するかもしれませんが、打率は高くても1割に過ぎない。つまり誰がプロダクトを率いたとしても、かなりの確率で失敗に終わる可能性があるということなんです。

ですから、失敗の責任をプロダクトオーナーだけに押し付けるのはいかがなものかなと思います。ここでいう「結果責任」を減給や降格に直接結びつけるようなものだと捉えているなら、それはちょっと違うのではないでしょうか。

——だとすると、誰がプロダクトの結果に対して責任を負うべきなのでしょうか？

吉羽：プロダクトの成否という最終的な結果責任は、そのプロダクトの開発に投資するべきかを決める経営者や事業責任者が担うべきでしょう。

そのうえで、プロダクトオーナーやスクラムマスター、開発チームがやるべきは、経営者や事業責任者が適時適切にジャッジを下せるよう、プロダクトの状況や進捗などの情報を開示して透明性を保つこと。現状や将来の展望を踏まえてこの先どうするかを決めるのは、経営戦略、事業戦略を決める経営陣や事業責任者の範疇であり、アジャイルチームの外側にあると考えるとよいでしょう。

——アジャイルなプロダクト開発においては、プロダクトオーナーを各ステークホルダーとのハブとして、開発チームをある程度独立させるべきだとされています。その独立を保つのは、誰の役割なのでしょうか。

吉羽：開発チームの適切な独立状態を保つのは、スクラムマスターの役割です。

スクラムマスターは、アジャイルな開発チームがうまく機能するための環境を整える役割を担います。その役割を果たすために、あらゆるステークホルダーに対して、開発チームの動き方や、その根底にあるアジャイルの価値観や原理原則を説明し理解してもらう責任があります。

アジャイル開発が失敗に陥ってしまう原因はいくつかありますが、チームの外側にいる人が「僕の考えた最強のアイデア」を開発チームに押し付け、結果責任のみを問おうとする姿勢が、プロダクトの失敗につながってしまうことがよくあります。いくら元々のアイデアが素晴らしかったとしても、開発者が「なぜこの機能が必要なのか」を理解することもできず、ただ開発するだけの状況に追い込まれてしまえば、良いプロダクトが生まれる見込みは立ちません。

だから良いプロダクトを生み出すために、スクラムマスターの、関係者全員にアジャイルの価値観を理解してもらう努力と、プロダクトオーナーの、開発に関する意思決定の背景や戦略を説明する責任が問われるわけです。

——となると、スクラムマスターはアジャイルの原理原則を広げる努力をするのはもちろん、最終的には会社のカルチャーをも変えていくために働きかけるべきなのでしょうか。

吉羽：当然そうなります。円滑な開発を阻む障壁を取り除くために尽力するのがスクラムマスターの務めである以上、必要とあらば、組織構造や人事制度、報酬体系、権限のあり方などに踏み込んだ改善を経営陣に訴えることもあります。なにしろ、プロダクト開発がうまくいかない根本の原因が、組織構造にある場合も多いですから。

——会社の規模が小さいと、プロダクトオーナーとスクラムマスターを兼任するケースもありますが、兼任するには無理があるように思えてきました…。

吉羽：実際「兼任してもいいですか？」という質問を受けることが多いのですが、答えはもちろんノーです。どちらの仕事も片手間でできるものではありません。

それに、プロダクトオーナーはプロダクトの価値の最大化にコミットする立場でもあるので、「想定した時期に間に合わない」「思ったほどの成果が得られそうにない」などとわかった場合、スクラムマスターと対立的な立場となってしまうこともよくあります。価値だけを追求するあまり、スクラムマスターが大切に守ってきたアジャイルの原則に反する行動をせざるを得なくなったり、チームに無理をさせる意思決定をしてしまったりするのです。

同じ人がプロダクトオーナーとスクラムマスターを兼任していると、このような壁にぶち当たったとき、「円滑な開発を守る」というスクラムマスターの責務は大切だとわかっていながらも、「売り上げ」や「結果」といった強いプレッシャーに押されてプロダクトオーナーとしての責務を優先せざるを得なくなり、本人も周囲も疲弊します。だから「どんなに人が足りなくても、プロダクトオーナーとスクラムマスターは分けるべきだ」と、口を酸っぱくして言っています。

——取材の冒頭に「責任や役割は、チームの状況に応じて動的に変わる」とのお話がありました。そうして変わっていく責任や役割に適応していくのも、一筋縄ではいかないような気がします。

吉羽：責任や役割が限定され、固まっていた方が分かりやすいし楽ではあります。でも、プロダクト開発において、それが全体最適だとは限りません。それぞれの職種の守備範囲を固く決めてしまうと、その狭間に落ちたまま拾われないボールが出てきてしまいます。

それに、プロダクト開発って、注力すべきことがその時々で変わるじゃないですか。必要な仕組みも、取り組むべき専門領域も、プロダクトが成長するにつれてどんどん変わっていく。となると、プロダクトのフェーズによって、特定の専門領域には「待ち時間」が発生してしまいます。

例えば機能開発に注力するフェーズでは、機能開発に関わるエンジニアは忙しいけれども、QA領域のエンジニアは手が空いてしまう。一方で、品質が強く求められるフェーズでは、品質向上に注力するべくQAエンジニアは火の車ですが、機能開発を担うエンジニアは少しのんびりできる。こうした待ち時間は、「関係者全員でプロダクトをより良くしていく」という全体の視点から見たら「ロス」となります。

そのため、アジャイルの価値観をもってプロダクト開発をすることと、職種ごとに役割をバッサリ切って「あとはよろしく」という考え方は、相容れないんじゃないでしょうか。

——プロダクトのフェーズに合わせて、最適な「責任」「役割」の切り分けであり続けるには、どうすればいいでしょうか。

吉羽：ステークホルダーそれぞれが、どこからどこまでを自分たちの守備範囲とするべきかを考え、話し合い、決め続けるしかないと思います。

今のプロダクトのフェーズで最も大切にすべきことは何なのか。それをやりきるために、それぞれの職種は何をするべきなのか。比較的手が空いてしまう職種があるとすれば、その人たちは何に協力できそうか。これらを話し合い、その時々で変わる「最適」を掴み続けるという地道な努力によってこそ、プロダクトの成功に対して関係者全員の力を生かすことができるのです。

となると、同じゴールに向かってそれぞれがどうあるべきかをフラットに話し合える組織をつくることが、一番重要と言えるかもしれませんね。

——たしかにそうですね。ただ、責任や役割が動的に変わる一方、利害関係やモチベーションを左右する強い要素となりうる「人事評価」はそれほどフレキシブルに動かせるわけではありません。この場合、個人のモチベーションをどのようにしてプロダクトの成功に結びつけるべきでしょうか。

吉羽：同じプロダクトに関わっている人は、職種問わず同じ目標を背負うのがよいと考えています。「プロダクトそのものが成功に向かっているか」などといった観点から、チーム全員が協力して目指せるものを共通の目標にするといいでしょう。

——「プロダクトそのものが成功に向かっているか」というチーム全体の目標をブレイクダウンして、定量的な個人目標を設ける、といったイメージですか？

吉羽：いや、それは典型的なアンチパターンですね。プロダクトを犠牲にしたくないのであれば、チームの目標からブレイクダウンしているとしても、個人の定量的な成果を目標に設定し、それに応じて報酬が変わるような人事評価をしてはいけません。個人目標を達成した方が金銭的なインセンティブにつながるのであれば、チーム全体の目標よりも個人目標を優先する構図になってしまいます。

それに、そもそも人間は、細分化や定量化をすればするほど、目標をハックしようとするようになります。個人目標の達成に動きが最適化されると、利害関係のコンフリクトが起きます。

——定量的な個人目標は置くべきではない、ということでしょうか。とすると、定量的な目標がモチベーションにつながりやすい人にとっては、動機付けが難しくなりそうです。

吉羽：定量指標で「人事評価」をするのは確かに良くないことです。ただ、人事評価とは紐づかない形で、チームとして成果につながる定量指標を設けて追いかけるのであれば話は別です。関係者全員で同じゴールに向かっていくための定量指標を設けられれば、チームのモチベーションアップや方向性の統一には効果的に機能するでしょう。

——定量的な目標は「人事評価と紐づけるかどうか」で大きく作用が変わってくるのですね。では、アジャイルなプロダクト開発をうまく進めていくためには、メンバーそれぞれの人事評価はどのように行えばよいでしょうか。

吉羽：基本的に僕は、360度評価が最も健全だろうと思っています。

定量指標で他人との競争やハックを促すのではなく、一緒に働いているチームの人からの客観的な意見と、本人の意見をもとに、定性情報で評価する。チームに対してコントリビューションすれば、360度評価で「あの人が助けてくれた」と評価される、というモデルであれば、チームやプロダクトへの貢献が人事評価と一致することになります。

人事評価と紐づく個人の定量目標を置きたいのであれば、チームへの貢献につながる目標であれば多少あってもいいと思います。ただ、たとえば資格を取るとか、外部のイベントに何回登壇するとか、メインの仕事に比べてサブ的な目標としておいたほうがいいでしょうね。

——最後に、プロダクト開発に関わる関係者同士の責任のコンフリクトに悩む人は、何から始めたらよいか、アドバイスをください。

吉羽：アジャイルなプロダクト開発を成功させたいのであれば、結局一番最初に押さえるべきは「アジャイルの原理原則や価値観を、プロダクトに関わる全員が理解し実践すること」に尽きると思います。

これを推進するのはスクラムマスターの役割ですが、ひとりで背負いきれるものではありません。プロダクト開発に関わるメンバーは誰しも、プロダクトの成功を目指すために重要な役割を負う以上、アジャイルへの理解やそれに基づいたプロダクト開発に対して、それぞれの立場で最大限の努力を払うべきです。

まずは、アジャイルやスクラムに対する認識に誤解や齟齬がないか振り返り、足りない部分があれば補ってみてください。それが改善の一歩になるはずです。

取材・執筆：武田 敏則
編集：光松 瞳・王 雨舟