アジャイル開発の舞台裏：プロダクトオーナーの苦悩と克服

• はじめに
• アジャイル開発とスクラム
• スクラムの三種のロール
• プロダクトオーナーの課題、提言
• 課題1. 手法の難しさ
• 課題2：人間関係
• 課題3：プロダクトオーナーのポジション
• 提言：プロダクトオーナーはチームとして担う役割である
• 最後に

経済産業省の「DXレポート ～ITシステム『2025年の崖』克服とDXの本格的な展開～」をきっかけに、DXに係る取り組みが大企業を中心に進められてきた。IT人材が不足しているにもかかわらず、長年事業を支えてきたレガシーシステムの保守・運用にIT人材・IT予算の多くが割かれている現状から脱却するために、自社競争力を強化しようとDXに取り組んでいる。
 
DXを企画する際に必ず選択肢として上がるのが、アジャイル開発手法である。ウォーターフォール型と違い、変化への対応力が期待されているが、日本で取り入れている企業は全体の5割に満たないのが現状であり、7割から8割を超える米国とは大きな差がある。(注１)
 
本レポートでは、「アジャイル開発」の有用性とともに、推進にあたっての課題と解決策を考察する。

2001年にソフトウェア開発にあたり重視されるべきマインドセットを盛り込んだ「アジャイルソフトウェア開発宣言」が公開された。ここでは変化を前提とし、顧客満足を最優先とした、素早く、継続的な価値提供を目指している。この宣言は世界中のソフトウェア開発者達に支持され、今ではソフトウェア開発以外の分野においても広まっている。
 
アジャイル開発において最も利用されているのが「スクラム」である。スクラムチームという小規模のチームを編成し、一定期間ごとに優先順位の高い機能を盛り込んだソフトウェアを開発し評価することを繰り返す。
 
ユーザーやステークホルダーからの要望を迅速にフィードバックしながら計画と改善を繰り返すため、不確実な状況への対応力が高いという特徴がある。
 

■スクラムの3種のロール

スクラムチームにはプロダクトオーナー、スクラムマスター、開発チームの役割がある。
プロダクトオーナーはプロダクトの価値の最大化を目指すことに責任があり、プロダクトの要件となるプロダクトバックログの決定、予算の管理やステークホルダーとの調整を行う。
スクラムマスターは、プロダクトオーナーや開発チームを支援する役割であり、スクラムチームが円滑に作業を進めるために必要な支援を行う。
開発チームは実際にスクラムチームの中で開発作業を担う役割であり、プロダクト作成に必要なすべての作業を担当する。
 

図1：スクラムチーム

課題1：手法の難しさ

プロダクトオーナーが陥りがちな課題の1つは、様々な手法でプロダクトを表現・展開するが、人によって求める視点や粒度が異なるうえ、手法が正しく使えておらず、本質的ではない書き直しに工数をとられてしまうことだ。
 
アジャイル型の進捗管理手法・ツールは確立されつつある。プロジェクト管理ツールはAsena、Backlog、Wrikeなど、KANBAN/ガントチャートのアジャイル・ウォーターフォール両面対応が一般化し、JIRAなどアジャイル特化ツールの流通も大きい。
これらはプロジェクト開始当初にスクラムマスターが検討、提案することが多く、定型化している。
 
一方、プロダクトの価値を考えるアプローチは未だ決まった方法が確立されていない。
ユーザーの詳細を書き起こすペルソナや、どの程度の市場があるか、何を主眼にした製品であるかといった商品コンセプトにはビジネスモデルキャンバス、バックログを起こす際はユーザーストーリーマッピングという記載方法など、これらは一般的に広まっている。
 
しかしながら、1つの手法に対し何冊も書籍が出ており、それぞれ記載の粒度や優先順位の付け方などが異なり、有識者の主張・提言も統一されているわけではない。
またそれぞれの手法に対し時間をかけて経験を積まなければ、コツをつかむのも難しい。
 
 

課題2：人間関係

特にプロジェクトの初期段階におけるプロダクトの方向性は未知数である。
何ができるか、何の効果があるかわからない中で、プロダクト案を書き起こし提示したとしても、仮説やアイデアレベルであるにも関わらず、根拠や分析を求められるなど、開発チームからの疑問やステークホルダーからの指摘が多発する。
 
そしてプロダクトバックログの書き直しを繰り返し、開発開始までに時間を要してしまう。遂には開発チームからプロダクトオーナーの推進力の不足を嘆かれ、ステークホルダーからは「アジャイルになるとスピードが上がると思っていたが、何もできてこない」というコメントが出る状態にまで至ってしまう。ここまでくると、プロダクトオーナーが孤立感を抱いたり、当初の勢いを失ってしまうことは多い。
 
プロダクトオーナーは常に誰もが納得し、必ず効果が出るプロダクト案を持っているわけではない。
ましてや、日本企業においては、自身が立案していないプロダクトのオーナーに任命されることも多々ある。
プロダクトオーナーの責任はプロダクトの価値を最大化するよう、チームやステークホルダーと共に、検討を進めることである。
 
アジャイルやスクラムの知識が浅い関係者も含めて説明し協力を求め、関係をつくる必要がある。
プロダクトオーナーはプロダクトの中身だけでなくプロダクトに関係するメンバーが成長する環境づくりまで担わなければならない。
 
 

課題3：プロダクトオーナーのポジション

アジャイルやスクラムを介して、会社をまたがったイベントやコミュニティが盛んに作られているが、そこにプロダクトオーナー参加することはわずかである。
 
参加するスクラムマスターや開発チームを見ると、システム部門やITベンダーに所属しているケースが多く、システム開発の共通言語で事例やベストプラクティスの共有がなされていたり、現場における悩みの吐露や、新たなやり方・工夫を共有し合える横のつながりを得ている。
 
一方、プロダクトオーナーは通常、ビジネス部門からアサインされている事例が多く、事業内容や業界が異なるためプロダクトオーナー同士がつながることは稀である。
書籍から手法を学んだり、スクラムマスターや開発チームから教えてもらわざるをえない。
 
後者は多かれ少なかれ、教える側が動きやすいようなやり方を提案するため、プロダクトオーナーとマッチするかどうかは未知数だ。
プロジェクトと違い、プロダクトのライフサイクルは長いため、何度もプロダクトオーナーを経験するということは少ない。
したがって、主に書面上で知見を学び、実践していかざるを得ない。
 
 

提言：プロダクトオーナーはチームとして担う役割である

スクラムガイドによると、意思決定の速さや明確さが製品開発の鍵となるため、プロダクトオーナーは合議制ではなく、1名となっている。
しかし、未経験ながら発展途上の手法を学び、プロダクト構想、市場価値の分析を行ったうえで、チームやステークホルダーを導くという一連の作業をたった1人で行うというのは現実的ではない。
1人の最終決定者を据えつつも、チームとして対応していくことが望まれる。
 

図2：スクラムガイド

プロダクトチームに必要な知識はプロダクト企画に向けた、デザインやマーケティングの知見となる。
ライズでは新規事業の経験者、デザイン思考、マーケティングの有識者が所属し、IT開発経験者とワンチームでの支援を行っている。
今後もIT、プロダクトにまつわる包括的な取り組みを通じて業界に貢献していきたい。

本川 友理（ほんがわ・ゆり）
SENIOR MANAGER
SIer、PwCコンサルティング、事業会社を経て、ライズ・コンサルティング・グループに参画。
小売、サービス業、金融、官公庁など、様々な業界にて、ITインフラ・セキュリティ、PMO、組織開発の経験を有す。
当社では、IT、組織開発のクライアントに従事するとともに、Inclusion＆Diversity推進及び社内情報システム支援を担当。
 
鈴木 秀孝（すずき・ひでたか）
SENIOR MANAGER
System　Transformation（SX）
野村総合研究所を経て、ライズ・コンサルティング・グループへ参画。
通信業界、IT領域における経験を豊富に持ち、上流～下流まで幅広いサポート経験を有する。
当社ではBPRおよびBPRを伴うシステム導入プロジェクトを中心に携わり、構想策定から実行支援まで一気通貫で支援できるところに強みをもつ。