Roman Pichler 氏とアジャイルスクラム
アジャイルの初期には、スクラムコミュニティは献身的で情熱的な少数のメンバーに支えられていました。Pichler 氏と出会ったのもそこでのことです。同じプロフェッショナルコミュニティに属しており、業界のイベントでスピーカーやファシリテーターとして顔を合わせることがありました。彼の製品管理に関する視点と詳しい説明にスクラムコミュニティは沸きました。
Pichler 氏は Siemens で最初のスクラム実践者としての経験をコミュニティにもたらし、当時あまり注目されていなかったスクラムの製品オーナーという役割に新たな視点を運んでくれました。製品オーナーは、製品開発におけるビジネス側 (要求側) とデリバリー側のギャップを埋める重要な役割を果たします。
コミュニティが製品オーナーというステークホルダーのプロセス、問題点や日常業務への理解を深める上で、Pichler 氏はソートリーダー的な役割を果たしました。こうした深い理解を得て、スクラムにおけるこの要職のためのプログラムと資料を作成しました。
間もなく彼はアジャイル分野の専門家、オピニオンリーダーとしての評価を確立し、製品ビジョンボードや GO 製品ロードマップなどのツールを完成させ、その見識をアジャイルや製品管理のコミュニティで共有し始め、2010年の『Agile Product Management with Scrum: Creating Products that Customers Love』の出版でアジャイルコミュニティ全体にその名を知られるようになりました。
スクラムと製品管理のギャップを埋める
こうしたアジャイルコミュニティへの貢献を評価するためには、一歩引いて、同氏のようなアジャイル実践者が常に提唱してきた職場の変化を取り巻く状況を探ることが重要です。
アジャイルの核心は、組織内のビジネス側とデリバリー側の間の分断を修復することにありました。アジャイルの登場以前、ビジネスの世界では、成果よりもアウトプットを重視し、効率のみを重視した経営が行われていたのです。
技術者の業務の管理はかつて、駅伝のような形で行われていました。管理者は走者に注目し、走者全員が予定通りに走っているかといった問題を検討します。先行している走者、ペースを保っている走者、遅れている走者を見極め、走者のパフォーマンスを最適化し、アウトプットを増やす余地を考えます。
こうした管理手法では、バトンをゴールラインまで運ぶという最終目標が抜け落ちてしまいます。アウトプットありきで成果が犠牲となるのです。
こうしたかつての製品開発プロセスでは、引き継ぎ、ドキュメント作成、ゲートレビューや承認などの負担が大きくなり、極めて精度の高い情報を伝えようとするあまり、開発を導く主要要素間の整合性を保つことが難しくなっていました。
こうした大量のドキュメントやレビュー対応に迫られる結果、構築担当者とまったく関係のないところで設計や仕様が決められ、実際の開発開始までには何か月もかかるような製品が生まれることになります。
こうした煩雑な製品管理プロセスに待望の一石を投じたのがアジャイルソフトウェア開発宣言とそれを支える原則で、以下の重要性を強調する内容でした。
- 顧客と協働し、顧客を満足させること
- スタート前に不要な包括的なドキュメントを用意するのではなく、進化している、動く製品に反復して取り組むこと
- 開発者とビジネス側が日常的に連携していること
- 当初の計画に固執して前進するのではなく、必然的な変化に対応すること
責任感ある製品オーナーが率いるアジャイルチームは、事前に完全な設計を行ったり、想定されるプロジェクト計画を文書化するのではなく、計画と実行を一連の短いイテレーション (スプリント) として行う反復的かつ漸進的なフレームワークで作業を進めます。
このモデルでは、計画の検討を実際の作業開始の前日など直前に行います。また、チームが定期的な口頭での確認で理解度を測り、作業の実施方法に関するフィードバックを求める際にも製品オーナーが立ち会うことで、整合性が保たれるようになります。Roman を始めとする多数が参加し、スクラム製品オーナーのための最初のトレーニングプログラムの学習目標を作成しました。こうしたプログラムにより、製品オーナーという新しい役割を確立させる上での認識が高まりました。
最初の時点では、製品オーナーという役職を果たす人材の確保をビジネス側に要請するのは容易ではありませんでした。ビジネス側のチームは、引き渡しされる側となることに慣れており、実際の作業に関与した経験がなかったからです。しかし、Pichler 氏などの影響を受け、専属の製品オーナーを置くことの価値は間もなく明らかとなりました。
アジャイルの反復的な性質を受け入れる
製品ビジョンボードや GO 製品ロードマップなどの製品管理ツールは、アジャイルの核心であるコラボレーションやアイデア出しを促進します。
アジャイルでは、チームは実用最小限の製品の構築から作業を始め、それを市場にリリースします。このプロセスを個人の移動手段の進化に例えて、スクラムコミュニティの初期のメンバーであった Henrik Kniberg 氏は、個人の移動手段における実用最小限の製品をスケートボードであるとしました。アジャイルチームは、時間をかけてユーザーのフィードバックを集め、そのスケートボードを改良していきます。初期の段階での制作物から学び、このスケートボードがスクーター、バイク、そして最終的には完全な機能を備えた自動車へと進化していきます。
アジャイルの登場で、全体を構築してから完成品としてリリースするのではなく、テスト可能な段階で製品が世に出てからアイデアを追加していくことが一般的となりました。こうした反復的なアプローチにより、ユーザーとの間の対応とフィードバックのサイクルが向上し、実際のユーザー体験という強固な基盤に基づいた製品が生まれることになります。
最終的にはこんな製品にしたいという完成形を骨組み段階で公開することには抵抗を感じるかもしれませんが、高度にレスポンシブな開発プロセスを実践することで、最終的により優れた製品が生まれるようになります。
Roman Pichler 氏のような革新的な人物のおかげで、製品やプロジェクト管理、特に製品オーナーという役割は、今やアジャイル、とりわけスクラムの中心的存在となっており、結果として、チームや組織の改善にもつながっています。
