はじめに
このエントリーは、アジャイル開発を実施するにあたって、自分が今まで読んだ本や携わったプロジェクトの経験から「どのような方法でプロジェクトを運営 すれば効率よく開発ができるのか」という自分の考えをまとめたものになります。実際にプロジェクトを運営する際は他にも考慮すべきことが多くありますが、プロジェクトの運営に絞って考えをまとめてみました。
参考にした書籍
プロジェクトの運営や見積もり、不確実性を減少させるためにはどうすればいいのかというような内容に関する本に絞りますが、だいたい以下のような書籍を読みました。エッセンシャルスクラムは積んでいるのでそのうち読みたい。
- アジャイルな見積もりと計画づくり
- アジャイルサムライ
- ユーザーストーリーマッピング
- エンジニアリング組織論への招待
- カイゼンジャーニー
- カンバン ソフトウェア開発の変革
- アートオブプロジェクトマネジメント
まず何をすべきなのか
まずはユーザーが何をしたいのか、ユーザーの考えていることが実現した場合、世界がどのように変わるのかということの全体像を把握する必要があるかと思っています。プロジェクトでいうところの企画段階で、このアプリやシステムが完成するとこうなりますよ〜みたいな感じです。
現在私が携わっているシェアフルでは、シェアフルが完成すると短期・単発でもっと働きやすくなり、今まで副業やダブルワークをやったことがなかったサラリーマンなどの方達に対してもリーチする可能性があり、結果的に日本社会全体における副業のイメージ変革や新しい働き方の提案ができるのではないか？というミッションからスタートしています。では、シェアフルを実現するためにはどういったフィーチャーが必要で、どのようなバリューストリームになり、そのために必要な機能はなんなのかを把握する必要がある といった感じです。
ユーザーストーリーの全体像を把握するためには
アジャイルプロジェクトではプロダクトバックログなどの形式でユーザーストーリーを管理し、ユーザーストーリーを実現するための具体的な手段を Issue にして開発を行なっていくかと思いますが、ユーザーストーリーのみに着目した場合、ユーザーストーリー全体の流れを見失ってしまいがちになります。森を見ずに木だけを見ているような状態です。自分の作っている機能がシステム全体で見るとどの部分に該当して、どのような役割を持っているのかきちんと説明できないのは非常にまずいんじゃないかと思いますし、理解の浅い状態で機能を作っていくとバグが潜在しやすくなります。
そのために、まずはユーザーストーリマッピングを作成することでユーザーストーリー一連の流れを把握し、フィーチャー全体の流れが一目でわかる状態にしておくことが大事だと思っています。大まかな粒度で何をどこまでやればいいのか把握できるのと、全部やろうとしたら絶対に時間が足りないので、まずは MVPe として何を優先的に作成すべきなのかが明確になります。また、ユーザーストーリーマッピングをステークホルダーやプロダクトオーナーと協力して作成することで、お互いの期待の一致や理解の共有、不確実性の削減を行うことが可能となります。ユーザーストーリーマッピングを起点としたコミュニケーションが活発となり、会話を継続することで、システムに対してのより深い理解や洞察が得られるようになる効果があります。このようなコミュニケーションが開発には必要不可欠です。
全体的なスケジュールを作成し更新し続ける
スケジュールは一度立てたら終わりではなく、常に改善し続ける必要があります。大まかなスケジュールを立てて、ユーザーストーリーの実現に必要なファーストリリースの MVPe を実現するためにはおおよそどれくらいの期間が必要なのかをざっくりとした感じでスケジューリングしましょう。プロジェクトの初期段階では不確定要素が多く、必要な情報はプロジェクトが進んでいくにつれて判明してくるので、「おおよそこれくらいかかるので10〜12月くらいにはリリースできるんじゃないか」というような大まかなスケジュール感から始まり、プロジェクトを進めていくにつれてベロシティが判明するので、残りのフィーチャーとベロシティからいつまでにはリリースできるようになるかの目処が立つようになります。プロジェクトを進めていく間にビジネスが取り巻く環境が変わったり、フィーチャーに対する理解が深まったことにより必要な機能が増えたり、逆に減ったり、進捗が思わしくないのでフィーチャーを削ったりとプロジェクトを進めていかないとわからないことが非常に多く、その都度計画は更新する必要があります。
ユーザーストーリーマッピングからプロダクトバックログを作成する
ユーザーストーリーマッピングがおおよそ出来上がり、第一段階リリース候補のフィーチャーが見えてきた段階で、次はプロダクトバックログを作成していきます。プロダクトバックログを作成するにあたって、どのツールを使用するかは特に言及しないですが、複数のスクラムチームからなるプロジェクトの場合、以下の4点を抑えているツールが望ましいと考えています。
- 各チームの進捗が把握できる
- チーム全体の進捗が把握できる
- バーンダウンチャートを自動で作成できる
- ベロシティがわかる
バーンダウンチャートに関しては、予定と実績の両方がわかるようなチャートになっていると予定からどのぐらい進んでいるまたは遅れている のが一目でわかるようになり、スプリントの進捗が可視化されるのでわかりやすいです。
見積もりを行う
プランニングポーカーなどの方法を用いて見積もりを行なっていきます。見積もりにおける前提としてプロジェクト全体に周知すべきこととしては、見積もりはあくまで見積もりであり、決してコミットメントではないことを理解してもらうところから始めます。また、見積もりの精度はプロジェクトの進捗によって改善されていくので、振れ幅があり完全に正確ではないことも認識する必要があります。特にプロジェクトの初期は振れ幅が大きく、プロジェクトを進めていくと見積もりが徐々に正確になっていくので、「まあだいたいこれくらいかかるだろう」という大まかな見積もりを軽い気持ちでやっていくのがいいんじゃないかと思います。
また、見積もりにバッファを含めるのではなく、バッファはプロジェクト全体にバッファを設けるようにします。パーキンソンの法則により、人間は与えられた時間を全て使って作業をしてしまうので、見積もりよりも早く作業が終わることが基本的に起こり得ません。例えばある作業が5日かかるという見積もりをした場合、3日目には作業が終わっていたとしても不要なブラッシュアップや最適化などを行なってしまい、結局見積もり通りの時間がかかってしまうからです。
ですが、見積もりにバッファを乗せて働いてきた経験が長い方からはバッファなしに見積もりをすることは反対されやすいので、まずは心理的安全性を確保してもらうために、見積もりはあくまで見積もりでしかなく、バッファはプロジェクト全体のバッファを用いるので、見積もり通りにタスクの消化ができなくてもプロジェクト全体のバッファから消化するという合意をエンジニア、顧客、ステークホルダーに対して形成する必要があります。どうしても期限を優先するのであればリリース対象のスコープからいくつかのフィーチャーを削るか、リリース日をずらす、品質を下げてとりあえずリリースするなどの対応が必要になってくるでしょう。どのような対応をするかはプロジェクトの状況やプロジェクトを取り巻くビジネス環境に依存するので、何で合意するかはまちまちです。
進捗を可視化する
どこまで何が終わっていていつリリースできるのかが明確になっていないとステークホルダや顧客は不安になり、進捗状況の詳細な説明を求められるようになります。エンジニアとしてもプロジェクト全体のフィーチャーが可視化されておらず残作業が見えていないと不安を覚えるので、プロジェクトの初期段階から進捗を可視化するのがいいでしょう。可視化された進捗は顧客とステークホルダーに対しての説明資料になり、エンジニアは自分たちの残作業量を把握できるようになります。
また、バックログから Issue 化された Issue Tracker などのツールから予定と実績のバーンダウンチャートを作成し、スプリントの予定ベロシティと実績のベロシティで進捗を可視化するのと、可能であればプロジェクト全体のフィーチャーからバーンダウンチャートを作成できてるといいかなと思います。
さらに、プロジェクトの執務室にユーザーストーリーマッピングを掲示しているのであれば、完了したフィーチャーがわかるようなシールを貼っておくと、完了したフィーチャーとストーリー全体が連動するので、大まかな進捗状況が一目でわかるようになります。
振り返りを行う
KPT を用いた振り返りをスプリントごとに実施します。1週間単位でスプリントを実施していれば毎週振り返りを行います。振り返りを行う際に大事な点は、Problem で上がった問題の深掘りを実施することと、Try を1つか2つに絞ることです。多くの Problem が上がった場合、Problem をすべて解決する Try を実施することは不可能なので、本当に解決したい Problem だけに絞って徐々に問題をなくしていくようにするのがいいと思います。また、Problemn に上がった問題は表面的なものであることが多いので、問題の深掘りを行なって問題の本質を解明するようにファシリテートして問題の早期発見と解決ができるようになると、自律的に問題を発見して解決するチームが出来上がっていきます。
1on1を実施する
これは今のプロジェクトで継続的に行なっている取り組みで、僕自身も初めて 1on1 を受けているのですが、1週間の出来事を振り返ってよかったことや悪かったこと、気になる事を整理することができるので、非常にいい機会をいただけていると思っています。よかったことや問題だと思ったことが PM に連携されるので、PM としては早めに是正する対策を取ることができるのと、メンバーが意欲的に取り組んでいる技術などを知ることができます。1on1 を実施するのはメンバーが多いとかなり時間がかかって大変だと思いますが、毎週実施してもらってありがたいです。
まとめ
アジャイルなプロジェクト運営をやっていくのは、ウォーターフォールと比べると進捗のごまかしがきかない部分が多いので、合わない人は全く合わないと思います。ですが、ウォーターフォールと違って変化を受け入れてプロジェクトを進めていくことができる手法なので、考える必要のあることは多いですが、変化に合わせて柔軟に開発を進めていくには、プロジェクトをアジャイルに適応してやっていくという気持ちで頑張ろうと思いました。
