はじめに
はじめまして。ソラミチシステム企画開発部の竹田と申します。
新卒で入社し、今年で2年目になります。初めてのブログ投稿で拙いところもあるかとは思いますが、お付き合いいただけますと幸いです。
この記事では、社内アジャイルコーチよりご教示いただいた半年間のアジャイルトレーニングでの学びとアジャイル開発の経験を通した教訓を交えてお伝えできればと思います。
私はこれまでPOとして、2つのアジャイル開発のプロジェクトを経験しました。机上での学びと実際の現場での経験の双方を織り交ぜて、実践的な学びに繋がれば幸いです。
今回、この記事では、アジャイル開発の中でも、プロジェクトの序盤にあたる『立ち上げ』期のゴールにフォーカスしてお話します。
『立ち上げ』とは？
下図をご覧ください。
これは、当社で特にBtoB、BtoG向けシステム開発で推奨している上流工程プロセスです。
『立ち上げ』期間はその名の通り、プロジェクトの一番初めの期間に位置します。業務分析や要求整理、インセプションデッキ等を用いたチームの方向付けなど、今後のプロジェクト進行に大きく影響する重要な期間です。
実はないがしろにされがちな『立ち上げ』期
こうしてみてみると重要なことはわかるものの、実際の現場ではリリースを急ぐあまり「早く開発にうつりたい」という気持ちが先行してしまい、十分なコミュニケーションが行われないままこの期間を経過してしまうというケースも往々にして起こり得ます。（私もそうでした。）
どうしてもアジャイル開発の花形はSprint1以降だと思えてしまうからかもしれません。
しかし、この『立ち上げ』期のゴールをしっかりと達成しておかないと、苦しむのは開発チームだけでなくPO等ビジネスサイドの人間でもあります。
『立ち上げ』のゴールは？
『立ち上げ』のゴールを一言で言うと…プロジェクトに対して全員が共通理解を持っていること、だと思っています。
もっといえば、『要求』に対して全員が共通理解を持っていること、だと私は思っています。
『立ち上げ』の次の『Sprint0』は、主に開発チームが要求を実現するための分析や設計、検証などを行い、開発着手にもっていくための期間です。
つまり、『Sprint0』に入る時点では、開発チームに要求が正しく伝わっている必要があります。（これが意外と難しい…。）
スクラムを適用する場合は、各Sprintのリファインメントで要求分析を行い、機能・非機能要件を詰めるため、『立ち上げ』期間に詳細まで検討するのは難しいですが、少なくともビジネス視点で実現したいユーザー価値については、正しく合意をとっておくべきです。そういった意味で、ここでは『立ち上げ』のゴールは、『要求』に対して全員が共通理解を持っていること、だと記載しました。
POは何をすればいいの？
では、このゴールを達成するためにPOは何をすべきでしょうか。
私は、開発チームと共通認識を持てていることを『確認』することに大きな責任があると思います。
例えば、丁寧に時間をかけて、マーケティング分析で価値を明確にしたり、サービスブループリントで業務を可視化し、ユーザーストーリーマッピングで要求を洗い出したとします。そうして出来上がった立派な資料。あとは、開発チームに伝えるだけ！そうなったときに、読者の皆さんならどのようにして、それらを開発チームに伝えるでしょうか。
多くの場合、ひとまず1時間ほどのミーティングを設定して、POから説明を行い、質問があればどうぞ、としてしまいませんか。（少なくとも私はそう思っていました。）
しかし、資料を共有する、一方的に伝える、だけではPOの果たすべき役割としては無責任になり得ることもあるように思います。
多くの場合、『立ち上げ』期間の初期に実施するワークショップに開発チーム全員が参加することはありません。
つまり、最終的に出来上がったアウトプットにたどり着くまでの議論を開発チームは見ていないのです。しかし、ビジネス側も開発側も『立ち上げ』期間に実施するワークショップに参加している上流メンバーは、既にそうした議論を経て、『要求』に習熟しているが故に、ワークショップに参加していなかった開発メンバーとの認識ギャップに気づけなくなっていきます。
それにより、一方的に「伝えた」だけで、当たり前に「伝わっている」と思い込んでしまいます。
PO視点で言えば、説明を受けて理解してほしいと思うかもしれませんし、わからないなら聞いてほしいと思うかもしれません。しかし、「認識がずれていること」に気づけなければ、そもそも質問もできませんし、わかっているつもりになってしまうのも仕方ないですよね。
そういう意味で、POの役割は、開発チームと共通認識を持てていることを『確認』すること、までにあると思っています。
共通認識が甘いと起こり得る問題
一番怖いケースは、そもそも実現しようと思っているものが違うケースです。
例えば、「アンケートを送信する」、という要求一つとっても、自動で送信するのか、手動で送信するのか、それだけでも『要求』としては大きく変わりますよね。
業務の流れに対する認識が違う、実現したい価値が違うといった大幅な認識のズレは、概算見積の数字にも大きく影響します。概算見積と各Sprintのリファインメントでの見積にあまりにも大きな乖離が生まれてしまうケースです。たしかに『立ち上げ』で行う見積は概算ですが、それでも作ろうとしているものがそもそも違う状態で見積を行うことは避けるべきだと思います。
多少の差分が生まれるのは仕方ないのですが、例えばあるストーリーを3ptと見込んでいたのが実際には13ptになるといったことが多くのストーリーで判明すれば、当初の計画が大きく崩れ、各所の期待を裏切る結果になってしまいます。
おすすめのコミュニケーション
こうした認識齟齬によるプロジェクトの失敗を招かないために、この『立ち上げ』期間の開発とのコミュニケーションでできることを私なりに考えてみました。
① 各機能の「価値」を明確にする
『要求』の最適な実現方法を検討するのは、実はPOではなく開発チームです。
POが明示すべきは、機能や要件への細かな説明よりもこの ユーザーストーリーが実現すべきユーザーの「価値」 にあります。
例えば、送信機能を作るときに顧客に提供したい価値が「業務を効率化する」なのか「コミュニケーション手段をつくる」なのかによって、実現方法は変わってきます。
顧客にどんな価値を提供するためにその機能が必要なのかという視点を共有できていれば、その後の仕様変更等でも大きく目的がずれることはなくなります。これがPOとして、この段階で「価値」を明確に伝えることに責任を持つべき理由です。
② できるだけ早い段階から開発チームにも入ってもらう
そもそも、開発チームが早い段階でプロジェクトに参画し、できる限り同じ議論の場を共有すれば、自然と認識齟齬がなくなっていくとも思っています。
もちろん『立ち上げ』期間の業務に開発チームはメインの責任を負っていないので、あまりにも多くの時間を割くのは難しいのかもしれませんが、『要求』が生まれるバックグラウンドを可能な限り理解してもらうことで、その後のコミュニケーションがスムーズになるように思います。例えば、途中経過段階で内容共有を行ったり、メイン機能や複雑な要求に関しては、開発チームの意見も反映できるよう議論に入ってもらうなどのやり方はとれるのではないかと思います。
③ 開発チームに要求内容を説明してもらう
個人的には、これが一番重要だと思っています。
『要求』を伝えて、開発チームの「わかった」が聞けた段階で、一度開発チームから『要求』内容を説明してもらうことです。もっと言えば、開発チームに実現する機能について簡単な絵を描いてもらい、視覚情報も加えて説明してもらうのがより確実かと思います。口頭での説明のみですと、用語自体への認識齟齬がある場合にカバーしきれないからです。
こうした過程を経て、開発チームからの説明を受けた結果、POとしてその説明に違和感がないのであれば、そもそも「作ろうと思っているものがちがう」といった大きな問題は発生しないように思います。自分の言葉で、実現すべきものを描いて説明するには、『要求』に対してある程度習熟している必要があるので、開発チームの理解度をある程度正確に把握できると考えています。
これらはあくまでも私が座学と実務での学びの中で得た答えですが、おそらく正解はないと思います。ですので、こんなコミュニケーションが効果的だった！等があれば、私もぜひ教えていただきたいです。
まとめ
いかがでしたでしょうか。私の経験は決して多いとは言えないので、実際はもっと良いやり方や改善方法があるかもしれません。
ただ、プランニングやレビューといったスクラムイベント等、開発着手後にフォーカスされがちなアジャイル開発において、実は開発着手前の期間に、その後のプロセスを成功させる要因が詰まっていることが少しでも伝わればと思います。
当時未熟だった私は、早くリリースしたい一心でこの期間を甘く見ていました。加えてオフショア開発であったため、言語や文化の壁を考えれば、通常よりも丁寧にすり合わせを行うべきだったと思っています。振り返れば、改善の余地は多々ありますし、その後、しっかりとそのしわ寄せに苦しみました。
アジャイルプロセスに乗っ取り、Sprint1以降を円滑に進めるためには、その前の期間に力を注ぐことの意味をひしひしと感じているので、ぜひまだPO経験の少ない方には心の片隅に止めていただけると嬉しいです。
さいごに
私は運良く、社内コーチによるアジャイルトレーニングと実務のタイミングが重なっていたので、温度感の高い学びをスピーディーに実践することも経験できました。そして、その中でしっかりとアジャイルのマインドやプロセスを学んでから実践に移すことの重要性を感じました。
アジャイルは、知識をインプットすることはできても、すべてを身に着けることには相当な時間を要します。その長い過程を経て、アジャイルを会得されているコーチからは、実務に役立つ有意義な学びを多く得ることができました。
最後になりましたが、貴重なお時間をいただき非常に濃い学びの時間をくださったアジャイルコーチの雨宮さんに心より感謝しております。
この御礼は、実務での成功を通してお返しできればと思っています！そして、繰り返しアジャイルへの知識を深めていければと思います。ありがとうございました。
