アジャイル・DevOps＃１　「プロダクトオーナーの難しさ(1/2)」

アジャイル開発の普及

スタートアップ企業やIT系サービス企業だけではなく、いわゆる従来型の「堅い」企業にも、アジャイル開発が確実に浸透しつつあります。それに伴い、開発側だけではなく、ビジネス側の難しさを実感されている会社様が増えてきました。

アジャイルの本来の目的はビジネス価値の素早いリリースです。とはいえ、アジャイルの元々の動きがソフトウェア開発から始まっていることは事実であり、これまでは、まずは、開発側の難しさや手法に注目が集まっていました。つまり、

• どんな体制で開発するのか
• そこで使うツールや手法は

という 「自分たちがどうすればよいか」 を、まず開発側は気にしていました。
スクラムのロール（役割）についても、スクラムマスターの位置付けについての質問が多かったように思います。

ところがここに来て、プロダクトオーナーという役割の難しさに、みなさんが徐々に気づき始めています。
事業会社において、誰がプロダクトオーナーになるのか、そのアサインが現実的に可能なのか、開発側からどんなサポートが必要なのか、等々。

ITを主要な道具としてビジネスを一から立ち上げるIT系／スタートアップ系企業では、あまり問題なくプロダクトオーナーという位置付けが受け入れられている気がします。この位置づけをより発展させて 「プロダクトマネージャー」 という役割を作っている企業もあります。問題はIT以外の"本業"がある従来の企業です。アジャイル開発の主な手法としてスクラムを採用しようとする際、たいてい出てくる疑問は、

「スクラムマスターって、従来のプロジェクトマネージャーじゃないの？」
「プロダクトオーナーって、要は要望を出す人でしょ？」

というお話。

このうち、スクラムマスターの話はまだ理解していただきやすいのです。スクラムマスターが、従来のコマンド＆コントロール型のマネージャーではなく、ファシリテーターにならないといけない、という話は、割合よく聞きます。スクラムマスターがチーム専任でなければならないという話も、従来のプロジェクトマネージャーのことを考えれば、専任の必要性は、ご理解いただきやすいです（とはいえ、複数チームを見てもいいのか、開発メンバーと兼任でもいいのか、という質問はよくありますが）。

プロダクトオーナーの位置付け

翻って、プロダクトオーナーについては、「事業部門側／ユーザー側の人」 という想定があり、開発側がまだそこまで思いが至っていないことが多い。しかしながら、プロダクトオーナーはスクラムの中でもプロジェクトの成否を決定する非常に重要な役割です。

私は、プロダクトオーナーの役割を説明する際に、以下の2点を強調します。

• スクラムチームの旗振り役です
• この人によってチームがいかに効率的に働けるかが決まります

「旗振り役」とは、スクラムチームという船の舳先に立って、「こっちに行って」 「次はこっちの方向へ」 と旗を振っているのがプロダクトオーナー、とイメージしていただければよいでしょう。
目的地が厳密に決まっていないアジャイル開発チームという船で、穏やかなこともあれば荒波もある大洋の中を進んでいく。荒波を何とかして超えていくのは、開発チームやスクラムマスターの腕かもしれませんが、目的地を指し示すのはプロダクトオーナーです。さらには、目的地は途中で変わりうる（目的地が最初に決まって、プロジェクト期間中変わらないのであれば、アジャイル開発にする必要はありません）。プロダクトオーナーは、途中で変わるビジネス状況をしっかりと踏まえて、チームを導く必要があります。

ふたつめの「効率」について。特にご注意いただきたいのは、ここでいう効率が、決して 「開発者の稼働率が高いこと」 ではなく、いかにビジネスに役立つシステムになっているかという度合いだということです。有名な統計として、典型的なシステムの実に45%の機能は全く使われていない、さらに19%もめったに使わない、というものがあります（Standish Group Study Reported in 2000 Chaos Report）。開発者がどんなに稼働率高く働こうが、作るコード量が多かろうが、それが使われていないのであれば、単なる「ゴミ」。プロダクトオーナーはこの無駄な機能をいかに作らせないかということに、責任があります。

※転載元の情報は上記執筆時点の情報です。
　上記執筆後に転載元の情報が修正されることがあります。