BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース "プロダクトオーナ”は最悪の発想だ

"プロダクトオーナ”は最悪の発想だ

ブックマーク

原文(投稿日:2020/09/07)へのリンク

プロダクトオーナは、スクラムがソフトウェアの世界に負わせた最悪のものだと思います。

本当に最悪の発想です! — Mary Poppendieck

プロダクトオーナという役割は、仕事をしている人たちと仕事を終わらせる必要のある人たちの中間に立つ仲介者で、これが我々のソフトウェアエンジニアリングプロセスに遅延、誤解、膨張を生み出している、とMary Poppendieck氏は断じている。ソフトウェアにおけるリーンに関する多数の著書を持つPoppendieck氏がこのように主張したのは、7月15日、変化に対して迅速な反応を得る上で、リーンの思想がいかに効果的なパターンであるかを氏が論じた、"Developing a Lean Mindset"と題した講演の中でのことだ。

"User Stories"の著者でアジャイル憲章の署名者でもあるMike Cohn氏は、6月11日に同じ話題を取り上げた記事をリツイートしている。氏は"Is It Time to Do Away with Scrum's Product Owner Role"という記事を書き、"技術的な判断は、チームが協同的に下すように求められています。プロダクトの判断も同じでよいのではないでしょうか?"と問いかけている。

我々がすでにテストで行っているように、プロダクト判断の責任は協同責任としてソフトウェアエンジニアリングチーム内で分散するべきであるという点と、ソフトウェアを構築し、変化に迅速に対応する能力を向上するためには、アーキテクチャが望ましい方法であるという点で、Cohn氏とPoppendieck氏の意見は一致しているようだ。

これには開発者が、"コードモンキー( code monkey)という自らの思考から抜け出す"必要がある、とCohn氏は言う。Poppendieck氏はこれを、1990年代にソフトウェアが失ったと氏のいう、エンジニア元来の考え方に立ち返ることだ、と論じている。プロダクトオーナの役割に同じような懸念を挙げるものは他にもたくさんいるが、根本原因の解析や可能性のあるソリューションは実にさまざまだ。

Nigel Thurlow氏は "The Great Product Owner Challenge" と題した記事で、プロダクトのオーナシップは間違いではない、組織の中でその役割をどのように運用するか、組織の持つ惰性が必要な変化をどの程度阻んでいるのかが問題なのだ、と主張している。

以下に挙げたのは、この問題を取り上げたコメンテータによるタイトルを抜粋したものだ。

ほとんどの記事が優れたプロダクトオーナを作る方法について述べる一方で、プロダクト提供にその役割を活用しようとした多くが困難を抱えている、という事実も明らかになっている。

スクラムの創始者であるJeff Sutherland氏がツイートした記事のひとつには、従来型の組織構造にアジャイルを当てはめようとしてアジャイルを破壊している組織によって、役割が歪められている傾向が強調されている。なぜスケールアップができないのか:

簡単に言えば、文字どおり、新たなテーマが存在するからです。それはすなわち、スクラムjマスタ、プロダクトオーナ、チームという役割に与えられていた元来のバランスが、ウォーターフォールから移行しようとする組織のニーズに合わせるために、適合され、汚染され、場合によっては毀損されている、ということです ...

さまざまな見解を要約すると、アジャイルの規模が拡大し、その利用がごく普通のことになっている一方で、プロダクトオーナという役割には明確なニーズがない場合や、明らかに状況に適合しない場合がある、ということだ。InfoQでは過去10年以上にわたって、Henrik Kniberg氏が考えを述べたチームコラボレーション、"プロダクトオーナーパターン"、"<プロダクトオーナーの役割を拡大するには"などの記事で、この複雑な役割をさまざまな側面から取り上げてきた。組織設計には常に、状況の複雑性と複雑な人の相互作用が関与する。プロダクトオーナという役割の是非に、チームの成熟度、組織の成熟度、組織のタイプ、組織の複雑度、さらにはプロダクトオーナ自身など、多くの要素が関係していることは疑う余地がない。

 

この記事に星をつける

おすすめ度
スタイル

BT