Roman Pichler 氏考案のアジャイル管理ツール

Lucidspark では近頃、Roman Pichler 氏とのコラボレーションの機会を得て同氏の最も人気の製品ビジョンボードと GO 製品ロードマップを Lucidspark のアジャイル管理ツールテンプレートとして再現しました。

これらのテンプレートを紹介する前に、同氏について、また同氏がアジャイルコミュニティに与えた多大な影響について少し説明したいと思います。

Roman Pichler 氏とアジャイルスクラム

アジャイルの初期には、スクラムコミュニティは献身的で情熱的な少数のメンバーに支えられていました。Pichler 氏と出会ったのもそこでのことです。同じプロフェッショナルコミュニティに属しており、業界のイベントでスピーカーやファシリテーターとして顔を合わせることがありました。彼の製品管理に関する視点と詳しい説明にスクラムコミュニティは沸きました。

Pichler 氏は Siemens で最初のスクラム実践者としての経験をコミュニティにもたらし、当時あまり注目されていなかったスクラムの製品オーナーという役割に新たな視点を運んでくれました。製品オーナーは、製品開発におけるビジネス側 (要求側) とデリバリー側のギャップを埋める重要な役割を果たします。

コミュニティが製品オーナーというステークホルダーのプロセス、問題点や日常業務への理解を深める上で、Pichler 氏はソートリーダー的な役割を果たしました。こうした深い理解を得て、スクラムにおけるこの要職のためのプログラムと資料を作成しました。

間もなく彼はアジャイル分野の専門家、オピニオンリーダーとしての評価を確立し、製品ビジョンボードや GO 製品ロードマップなどのツールを完成させ、その見識をアジャイルや製品管理のコミュニティで共有し始め、2010年の『Agile Product Management with Scrum: Creating Products that Customers Love』の出版でアジャイルコミュニティ全体にその名を知られるようになりました。

スクラムと製品管理のギャップを埋める

こうしたアジャイルコミュニティへの貢献を評価するためには、一歩引いて、同氏のようなアジャイル実践者が常に提唱してきた職場の変化を取り巻く状況を探ることが重要です。

アジャイルの核心は、組織内のビジネス側とデリバリー側の間の分断を修復することにありました。アジャイルの登場以前、ビジネスの世界では、成果よりもアウトプットを重視し、効率のみを重視した経営が行われていたのです。

技術者の業務の管理はかつて、駅伝のような形で行われていました。管理者は走者に注目し、走者全員が予定通りに走っているかといった問題を検討します。先行している走者、ペースを保っている走者、遅れている走者を見極め、走者のパフォーマンスを最適化し、アウトプットを増やす余地を考えます。

こうした管理手法では、バトンをゴールラインまで運ぶという最終目標が抜け落ちてしまいます。アウトプットありきで成果が犠牲となるのです。

こうしたかつての製品開発プロセスでは、引き継ぎ、ドキュメント作成、ゲートレビューや承認などの負担が大きくなり、極めて精度の高い情報を伝えようとするあまり、開発を導く主要要素間の整合性を保つことが難しくなっていました。

こうした大量のドキュメントやレビュー対応に迫られる結果、構築担当者とまったく関係のないところで設計や仕様が決められ、実際の開発開始までには何か月もかかるような製品が生まれることになります。

こうした煩雑な製品管理プロセスに待望の一石を投じたのがアジャイルソフトウェア開発宣言とそれを支える原則で、以下の重要性を強調する内容でした。

• 顧客と協働し、顧客を満足させること
• スタート前に不要な包括的なドキュメントを用意するのではなく、進化している、動く製品に反復して取り組むこと
• 開発者とビジネス側が日常的に連携していること
• 当初の計画に固執して前進するのではなく、必然的な変化に対応すること

責任感ある製品オーナーが率いるアジャイルチームは、事前に完全な設計を行ったり、想定されるプロジェクト計画を文書化するのではなく、計画と実行を一連の短いイテレーション (スプリント) として行う反復的かつ漸進的なフレームワークで作業を進めます。

このモデルでは、計画の検討を実際の作業開始の前日など直前に行います。また、チームが定期的な口頭での確認で理解度を測り、作業の実施方法に関するフィードバックを求める際にも製品オーナーが立ち会うことで、整合性が保たれるようになります。Roman を始めとする多数が参加し、スクラム製品オーナーのための最初のトレーニングプログラムの学習目標を作成しました。こうしたプログラムにより、製品オーナーという新しい役割を確立させる上での認識が高まりました。

最初の時点では、製品オーナーという役職を果たす人材の確保をビジネス側に要請するのは容易ではありませんでした。ビジネス側のチームは、引き渡しされる側となることに慣れており、実際の作業に関与した経験がなかったからです。しかし、Pichler 氏などの影響を受け、専属の製品オーナーを置くことの価値は間もなく明らかとなりました。

製品オーナーのためのビジュアル管理ツール

製品オーナーと製品マネージャーのためのツールキットの一部として、Pichler 氏は「製品ビジョンボード」と「GO 製品ロードマップ」を作成しました。重要な成果物に対応するコラボレーションプロセスを実現するためのシンプルなビジュアルフレームワークです。

製品ビジョンボード

製品ビジョンボードは、ビジョン、対象グループ、ニーズ、製品、ビジネス面での目標の5つのカテゴリーにわたる重要な質問をチームメンバーに提起することで初期の製品開発を導きます。

ビジョン

• 製品を作る目的は？
• 製品がもたらすべきポジティブな変化とは？

対象となるグループ

• 製品が対応する市場や市場セグメントは？
• 対象となる顧客やユーザーは？

ニーズ

• 製品が解決すべき問題は？
• 製品がもたらすメリットは？

製品

• どのような製品か？
• 製品の優れている点は？
• その製品の開発は可能か？

ビジネス面での目標

• その製品は会社にどのような利益をもたらすか？
• ビジネス面での目標は何か？

ボードにメモやインサイトを追加するたびに、製品に対するチームのビジョンが充実していきます。Lucidspark のこのテンプレートは、調査と反復を促進し、直感的な衝動に依ることなく、構築すべきものを明確に理解することの重要性を強調したものです。

さらに、このボードでは各製品のエンドユーザーを中心とし、指針となる質問を使ってユーザーの質問、ニーズや期待する点への共感を深めていきます。製品ビジョンボードを作成するプロセスを経ることで、製品開発の意思決定の背景や目標を十分に理解できるようになるのです。

GO 製品ロードマップ

製品ビジョンボードが完成したら、今度は同氏の GO (ゴール指向) 製品ロードマップの作成に移ります。このロードマップは、チームが一定の時間枠内で特定の目的を達成するための計画立案方法を明確にし、チームのプロジェクト計画の具体的な枠組みとなるものです。GO 製品ロードマップに沿って作業を進めていくことで、最終的に説明責任を果たし、評価基準を定め、スケジュールやタスク管理を確立できるようになります。

この GO 製品ロードマップは、コラボレーションを前提に設計されたものです。もともとは、ロードマップをポスターサイズで印刷して会議室の壁に貼り、チームで付箋やアイデアをマップに追加していき、その後完成したマップの写真を撮り、デジタル化して社内で共有していました。

Lucidspark などのバーチャルホワイトボードなら、共有のロードマップ上で効果的な共同での計画に欠かせないデジタル付箋やフィードバックツールを使ってリアルタイムでメンバーが集まって作業を進められます。

GO 製品ロードマップでは、個々の製品機能の詳細やメリットに注目するのではなく、主要な目標や目的に沿って計画を立てることが求められます。こうすることで、戦略的目標に沿った計画を立案でき、経営陣の賛同を得られる可能性が高まります。

アジャイルの反復的な性質を受け入れる

製品ビジョンボードや GO 製品ロードマップなどの製品管理ツールは、アジャイルの核心であるコラボレーションやアイデア出しを促進します。

アジャイルでは、チームは実用最小限の製品の構築から作業を始め、それを市場にリリースします。このプロセスを個人の移動手段の進化に例えて、スクラムコミュニティの初期のメンバーであった Henrik Kniberg 氏は、個人の移動手段における実用最小限の製品をスケートボードであるとしました。アジャイルチームは、時間をかけてユーザーのフィードバックを集め、そのスケートボードを改良していきます。初期の段階での制作物から学び、このスケートボードがスクーター、バイク、そして最終的には完全な機能を備えた自動車へと進化していきます。

アジャイルの登場で、全体を構築してから完成品としてリリースするのではなく、テスト可能な段階で製品が世に出てからアイデアを追加していくことが一般的となりました。こうした反復的なアプローチにより、ユーザーとの間の対応とフィードバックのサイクルが向上し、実際のユーザー体験という強固な基盤に基づいた製品が生まれることになります。

最終的にはこんな製品にしたいという完成形を骨組み段階で公開することには抵抗を感じるかもしれませんが、高度にレスポンシブな開発プロセスを実践することで、最終的により優れた製品が生まれるようになります。

Roman Pichler 氏のような革新的な人物のおかげで、製品やプロジェクト管理、特に製品オーナーという役割は、今やアジャイル、とりわけスクラムの中心的存在となっており、結果として、チームや組織の改善にもつながっています。