アジャイル開発の主導者が、プロジェクト発足時にやるべきこと
ウォーターフォールの歴史
プロダクト開発におけるウォーターフォールの歴史。それを遡ると、1970年にウィンストン・W・ロイスが発表した論文「Managing the Development of Large Software Systems」から始まる。
この論文で、彼は、開発の流れを段階的に進める取り組みについて論じ、それが「ウォーターフォール」として広く知られるようになった。僕が興味深いのは、彼自身がこのウォーターフォールを推奨していたわけではないということ。このモデルの限界やリスク、それが含まれていることを強調している点だ。
ウォーターフォールは、プロダクト開発を指揮するディレクターなら、誰しも聞いたことがあり、馴染み深いものだろう。
顧客からの要求を整理し、要件を定め、設計、実装、テスト、受け入れと進む。さらりと書くとこのようなものだが、「要求整理」と「要件定義」という初期段階の計画がとても重要になってくる。
例えば、初手で致命的なミスや取りこぼしがあった場合、細かな変更やフィードバックに対して柔軟に対応できない。それは、現代の複雑かつ変化に富むプロジェクトには適さないことが多くなり、より適応力のあるアジャイルが注目されるようになってきた。
ウォーターフォールからアジャイルへ
最近、弊社で対応する案件の様相も変わりつつあり、特にアジャイルを取り入れたプロダクト開発の相談が多い。プロダクトオーナーといっしょに、サービスの構想段階から一緒に考えてほしいというものもあれば、設計者としてプロダクト全体の構造化と画面設計を担当する場合もある。
そこで、いつかnoteにまとめようと思っていたのだが、アジャイル開発における初期段階の進行方法、特にプロダクトバックログとインセプションデッキの作成について、これらのドキュメントを効果的かつ効率的にまとめる方法を探りたい。
僕は、さまざまな立場でアジャイル開発プロジェクトに関わってきた。そのため、これがウォーターフォールにおけるプロジェクト計画や要件定義と類似した部分を持ちながらも、アジャイルならではの変化に適応するノウハウが詰まっている工程だと感じている。そのあたりを経験の浅い若手ディレクターでもわかるようにまとめたのが本記事になる。
アジャイル開発におけるプロジェクト発足時の進行
アジャイル開発の初期段階では、そのプロジェクトの全体像を構築するための重要なステップがある。その中で、特に僕が重要だと感じるものは、
・プロダクトビジョンの策定
・初期プロダクトバックログの作成
・インセプションデッキの作成
この３つだと考える。これらをアウトプットする工程を「Discovery Phase（発見）」、「Inception Phase（方向付け）」と置いて考えた時、どのような進行で進み、その時に何が大切かを順番に見ていく。
1. Discovery Phase（発見）
アジャイル開発において最初に行われるのが、Discovery Phaseと呼ばれる工程。デザイン思考の価値探索や問いの設計に重なるところが多くあり、それはプロジェクトの全体的な目標とビジョンを明確化するために、プロダクトビジョンを策定していくことにつながる。
プロダクトビジョンの策定
プロダクトビジョンは、プロジェクトが解決すべき問題、提供すべき価値を簡潔に表現したもの。プロジェクトに関わるチーム全員が共通認識を持って取り組むための「旗印」とも言える。このようなドキュメントを成果物として作成支援する場合、弊社では以下のような要素を含めて、後半に記載する各種ツールを使ってドキュメント化している。
・会社のビジョン：大前提となるその組織のビジョンが何か
・プロダクトの目的：なぜ、何のために作るのか？
・Valueポジション：それが提供する価値とは何か？
・成功のための指標：成功とみなされるための定量、定性的指標（KGI）
・中長期的な方向性：それの将来的な構想、成長戦略、投資計画
これらの項目。僕のこれまでの経験からすると、ウォーターフォールにおけるプロジェクト計画にも記載されることが多いと感じる。いずれの場合でも、最初の段階でプロジェクトの目指すべき方向性を定める役割を果たしていることに違いはない。
ただ、アジャイルにおけるこれらのビジョンは「決して変わらないもの」として存在するのではない。僕の理解だと、状況に応じて調整可能なビジョンとして捉えられるもの。プロジェクトが進行する中で、新たな発見や変化に応じ、このビジョンを微調整、より良い方向へ進められるという点に置いて、若干の相違がある。
初期のプロダクトバックログ
プロダクトビジョンが明確になると、次に行うのが初期のプロダクトバックログの作成だろう。スクラムに代表されるフレームワークを使うと、だいたい耳にする言葉になる。念のため補足しておくと、これはプロダクトに求められる機能や要件のまとまりであり、リストごとに優先順位がつけられた形で管理される。管理者はプロダクトオーナーだ。
・誰が、何を、なぜ？の形式で具体化していく
・利用者のストーリーに合わせて言語化する
・ユーザーの思惑、プライオリティ、見積もり、受入れ基準をリスト形式で
例えば、ウォーターフォール開発の要件定義を考えたい。顧客から提供されるRFPをもとに、案件担当のディレクターが、それらに対応する形で細かな要件を文書化、機能要件として管理していく。一方、アジャイル開発におけるプロダクトバックログも、プロダクトに必要な機能をリスト化する点で類似しているが、アジャイルでは常に優先順位を見直し、状況に応じて柔軟な変更を許容する。
2. Inception Phase（方向付け）
前段のDiscoveryフェーズを受け、次のInceptionフェーズでは、今回の取り組みが何を達成し、どのように進行するかの大枠を定めていく。そして、みんなで作るべきものの共通理解を促していくことが大切だ。特に、アジャイル開発においては、初期計画が変更されることが前提とされるため、個々の詳細な計画よりも柔軟に変更に対応できる基盤作りが重視される。
インセプションデッキの作成
インセプションデッキは、プロジェクトの初期段階でチームが共通認識を持つための資料となる。これにより、プロジェクトのビジョン、目標、成功基準、リスクなどが明確になり、チームが一貫した方向で開発を進めるための道筋を示すことができる。
・なぜここになるのか？
・成功の要件とゴール
・解決する課題と提供する価値
・主な利用者像
・いかにして目標へ到達するか
・やること、やらないこと
・考えうるリスクと対処法
・チーム構成と役割
・リリース計画とマイルストーン
これらの項目を眺めると、まとめるのが億劫だなと感じてしまうかもしれない。でも、アジャイルの場合は、後工程での柔軟な変更も許容していくことが前提であり、ウォーターフォールの詳細なプロジェクト計画書とは質が異なる。インセプションデッキは、とても軽量なドキュメントであることを忘れてはいけない。
インセプションデッキを資料にする目的は、プロジェクトの初期段階でチームが共通認識を持つことにある。そこで、この目的を達成するために軽微にまとめるための雛形を作成したので参考にしてほしい。
これらの成果物をどのように管理するか
以上、見てきたように、アジャイルのプロジェクトでは、プロダクトビジョン、プロダクトバックログ、インセプションデッキなど、あとで柔軟に変更が加えられるドキュメント管理が非常に大切になってくる。
会議の中で、リアルタイムにフィードバックを反映したり、チーム全員が最新の情報にアクセスできる環境が求められるため、それに適したツールを使って管理することが望ましい。（以下は、弊社でも使っているツールとその特徴）
1. Notion
Notionは、アジャイル開発のドキュメント管理に非常に適したツールであり、弊社でもよく使っている。
編集: リアルタイムでドキュメントを編集でき、プロダクトバックログやインセプションデッキのような資料も簡単に更新できる。アジャイル開発の頻繁な変更や追加に対応可能。
一元管理: さまざまな形式のコンテンツをまとめて管理でき、バックログやプロジェクト計画書、スプリントゴールなどを一つのプラットフォームで整理可能。
コラボレーション: チーム全員が同時にドキュメントを編集し、コメントを付けたり、タスクを管理できるため、コミュニケーションがスムーズ。
テンプレート: アジャイル開発に最適なテンプレート（プロジェクト管理、プロダクトバックログ、会議議事録など）を使うことで、スピーディーに作業開始可能。
2. Jira
次にJira。プロジェクトによってはJiraを指定されることも多い。
管理: ユーザーストーリーやタスクを管理するためのバックログ機能。プロダクトオーナーやチームが簡単にアイテムの優先順位を変更し、進行中のスプリントに対応させることができる。
アジャイルボード: 例えば、スクラムボードを使って進行状況を可視化したり、チーム全員がリアルタイムで進捗を確認でき、スプリントの進行状況も容易に管理で可能。
インテグレーション: 他のツール（Confluence、Slackなど）との連携が強力で、ドキュメントとタスク管理の両方をシームレスに実行できる。
3. Confluence
Confluenceは、Jiraと同じくAtlassianが提供しているコラボレーションツールで、特にドキュメント管理特化型のもの。
管理: プロジェクトのビジョンや目的をまとめたインセプションデッキを作成し、他のチームメンバーとリアルタイムで共有可能。
Jiraとの連携: 両者の連携を行うことで、バックログや進行中のタスクをすぐに確認し、関連するドキュメントにリンク可能。
テンプレート: Confluenceにもプロジェクト計画や要件定義書を作成するためのテンプレートが用意されており、効率的に文書作成が可能。
弊社が関わる案件だと、ドキュメント管理として上記３つのツールを使うことが多い。こちらも参考までに。
まとめ
以上、説明してきた通り、アジャイル開発の初期段階では、これらの工程がプロジェクトの成功を左右する重要なプロセスとなっている。そして、ウォーターフォールの計画段階や要件定義に似た側面を持ちながらも、アジャイル特有の柔軟性と反復的な改善が大前提となる。
プロダクトオーナーやディレクターにとってみれば、これらをどのように組み立てるのか？初手としてどのように着手するか？
このあたりが非常に悩ましいところだろう。かくいう僕の本業は、プロダクトオーナーでもディレクターでもない。そのため、近年のプロダクト開発の大きな変更を目の当たりにして感じることがある。
それは、このようなプロジェクトの主導者に抜擢された人は、自身に求められる守備範囲が膨大になっていて、果たして勉強量もこれまでの経験も、両方を兼ね備えた者が世の中にどれだけいるのだろう？という素朴な疑問。
そんなスーパーマンはいないはず。でも世の中的には求められているわけで、そこに風穴を開けるだけの、わかりやすく柔軟な教育プログラムの作成が必要不可欠なのかもしれない。
この記事が気に入ったらサポートをしてみませんか？