アジャイル開発におけるプロジェクトの進め方
アジャイル開発において、色々悪い意味で誤解をしている方々が沢山いるので、
アジャイル開発をした事が無い方々の指針になればと思い書いております。
はじめに
ここに記載している内容を読む前に、必ず以下の点を考慮してください。
- 全てのチームに同じように適用できるとは限らない。
- そもそもプロジェクトの段階で、アジャイル開発の適用が出来るものとできないものがある。
- やり方は一つじゃない。
スケジュールの立て方
アジャイルにせよウォーターフォールにせよ、まずはスケジュールがあります。
アジャイルにスケジュールなんて( ´,_ゝ｀)ﾌﾟｯ
っと思うかもしれませんが、そもそも1年後か10年後か100年後か成果を何時出せばいいか
わからないようなプロジェクトは極僅かしかありません。
アジャイルとウォーターフォールの上のスケジュールの違いは、
スケジュールの粒度とスケジュールの重要度（柔軟性）が違います。
ウォーターフォールにおけるスケジュールは、聖典であり、絶対的に守るべきもので、融通の聞かないものです。
アジャイルにおけるスケジュールは、変化するものであり、柔軟に変更を行うものです。
これだけを聞くと、アジャイルにおいてシステムリリースが何時になるのかや、何時終わるかわからない等と思うかもしれません。
これがアジャイルをやり始めたばかりの人たちが陥る罠です。
わかりやすい例えを以下に書きます。
旅行の場合を考えて下さい。
ウォーターフォールでは、旅行に行く場合に、京都の何処に旅行に行こう。
その際に、車でどの道を通って、寄りたい場所を全部だして、どうしたら旅行日程中に全部を回れるか、綿密な計画を立てて、寄りたい場所に時間通りに到着する前提で動いていきます。
アジャイルでは、旅行にいく場合、京都の何処に旅行に行こう。
その際に、寄りたい場所に優先度をつけて、道については、当日の渋滞情報を見て、回れるようなら、寄りたい場所に優先度をつけて回っていこう。
っというふうに、京都に行く目的を果たす為に、その他の寄り道に対して取捨選択を行います。
実際2つの旅行日程では、京都にはつくとは思いますが、
ウォーターフォール型の旅行日程では、当日の渋滞状況によっては、時間通りに物事が進みません。これがプロジェクトの遅れです。
アジャイル型の旅行日程では、京都には目的の時間どおりにつくと思いますが、当日の渋滞状況によっては、寄りたいところに全てよれません。
これがシステムリリースは出来るが、機能実装が全て終わっているわけではないという状況です。
プロジェクトの段階で、アジャイルでの実装が可能かは、上記のように、機能全てをリリースする必要があるのか？優先度をつけて、未実装機能がある事が許されるのか？
この考えが重要です。
スケジュール（旅行日程） ＝ 期間 （旅行期間）＋ 実装機能（寄り道先）
上記である事を理解しなければなりません。
ウォーターフォールでは、機能の取捨選択は基本的に起こりません。
全ての機能を洗い出しWBSを作成し、あらゆるものに工数を設定し、そのスケジュールどおりに
物事が動く前提でプロジェクトを動かします。
予定外の事があった場合は、前工程に戻って、ひたすら同じようにWBSを書き直し
スケジュールどおりになんとか進めようとします。
アジャイルでは、期間を重視する為に、機能の洗い出しを行い、それらの実装優先度と
実際に予定外の事が起こった場合に、どの機能を取捨選択するかを決定し、
期間内に最低限の機能を実装した物をリリースしようとします。
ウォーターフォールでは機能実装を優先、アジャイルでは期間を優先とも言えます。
ですので、バッファの積み方も違います。
ウォーターフォールでは、コンティンジェンシー予備費等で、スケジュールどおりに動かすために
お金に関してバッファを積んだり、各機能実装において実装する為の時間に、バッファを積んだりします。
アジャイルでは、フィーチャバッファとして、機能にバッファを積み、優先度をつけて、時間が無ければ実装しない機能をつけます。
（※実際は、アジャイルでも日数のバッファ等は適切に積みます。お金もね。ただ、重要視されるバッファが違うというだけです。それと同じように、ウォーターフォールでも機能にバッファを積んだりもします。）
これらを前提にスケジュールを組み上げていきます。
では、全部の詳細な機能実装のスケジュールを作るかと言われると、
ウォーターフォールでは、WBSとして全ての実装機能までワークパッケージとして作成しますが、
アジャイルでは、直前に起こる出来事に対してのみタイムボックス内のスケジュールを作成します。
ここがスケジュールの粒度の違いです。
ウォーターフォールは、予め先を見通す為に、全ての詳細な項目の洗い出しを行い、巨大なWBSができますが、アジャイルでは、直前に発生する物事に対してのみ、詳細化を行っていきます。
しかしながら、全体としてアジャイルは直前に物事が起こるまで、何があるのかわからないのか？
っと言われると、それはそもそもプロダクトオーナーが仕事をしていないか勘違いです。
アジャイルには、プロダクトバックログとスプリントバックログ（イテレーションバックログ）があり、
プロダクトバックログに、今後実装していく内容が記載され、優先度が付いている状態です。
（※この優先度は、適宜変更され、また同様にプロダクトバックログの内容についても適宜変更・追加が発生する。）
わかりやすい例えを以下に書きます。
車の改造を想像して下さい。
（※この例えは迷ったのですが、私DQNじゃないですよ・・・）
車の以下の部分を改造するとします。
- ハンドル
- シート
- アクセル・ブレーキペダル
- 外装
- オーディオ機器
ウォーターフォールでは、はじめから、改造する箇所を一覧化し、何を使うかを明確化します。
例えばシートで言えば、革張りにするのか等。
それらの打合せが完了した際に、金額の見積もりを行い一括して全てを改造しようとします。
そこで出てくるのが改造箇所の一覧と改造する物（革張りにするのかなど）が詳細化されています。
対して、アジャイルでは、改造する箇所の要望は書き出します。（プロダクトバックログ）
しかし、改造の詳細については、都度改造するたびに車のオーナーに確認を行い、その要望の順序で順番に詳細な内容を確認し都度確認を行います。
ハンドルの握り心地はどうですか？等です。
当然車のオーナーは、1点ずつ交換していくので、車の雰囲気に合わせて、当初の予定と違う事を言うかもしれません（スケジュールの変更）。
ハンドルを白に取り替えたから、当初シートは黒の革張りにする予定が、白い革張りにしたいとか。
それらの詳細な内容については、都度フィードバックを行い、改造箇所の一覧に優先度がつけられ、作業する際に詳細化（スプリントバックログ）されていきます。
これがスケジュールの粒度です。
最初から詳細な粒度で物事のスケジュールを捉えるか、
概要のみで、着手するタイミングでスケジュールの詳細化を行うか。
初めてアジャイルを行う際に、誤解しがちなのが、この部分で、
アジャイルであってもプロダクトバックログという形で、全体としての概要スケジュールは
管理を行っている点です。
ただ、この概要スケジュール自体が、流動的で、優先度が変わったり、そもそも実行しないという決定がされるかもしれないという点が違うだけです。
実行するか、詳細に落とすかが違うだけで、全体としては、ウォーターフォールもアジャイルも全体像は詳細として捉えるか（WBS）、漠然として捉えるか（プロダクトバックログ）の違いはありますが、見通してはいるのです。
ここを勘違いすると大きな落とし穴にハマります。
よくあるスケジュールの失敗例
チーム全体が、スケジュールがわからないと言っている場合。
これは、プロダクトオーナーが明確なプロジェクトの終了時期とプロダクトバックログの確認が
できていない事に起因するのです。
プロダクトオーナーは、プロジェクト終了時点の概要とスケジュールはチーム全体が確認出来る状態にしておくべきです。
逆にこれがはっきりしないのは、プロダクトオーナーがプロダクトバックログを作ったはいいが、チームメンバーにその概要すら伝わっていない（要件の定義ができていない）だけです。
極稀に、終了時期があやふやなプロジェクトがありますが、その場合は、そのあやふやな概算を伝える事が大切です。
なぜなら、期間によって、実行できるスプリント数が決まってくるからです。
プロダクトバックログの優先度が全て最上位になっている。
プロダクトオーナーが、物事の優先順位付けを失敗しているパターンです。
ユーザーが望む機能というのは、当然のごとく流動的に変化するものです。
その変化を前提にアジャイル開発は行われるわけですが、全部実装するよ！！
などとプロダクトオーナーが言い始めると、もはやそれはアジャイルの名を借りた
ウォーターフォールプロジェクトになります。
もし開発において、このパターンが出たのであれば、
作成する物として、全ての業務機能と便利機能を兼ね備えた完璧なアプリケーションを作ろうとしているという事です。
この場合は、その完璧なアプリケーションの形がすでにプロダクトバックログとしてあるので、
それに合わせて全体の詳細なWBSを作成し、作成したWBSを基にスケジュールを永遠と後ろに伸ばすべきです。
万が一、プロダクトバックログの優先度が全て最上位にあるにも関わらず、プロダクトオーナーが各バックログの詳細な内容を話せないのであれば、もはやプロダクトオーナーが要件定義と仕様確認を怠っているだけなので、プロダクトオーナーをやめるべきでしょう・・・
プロダクトバックログの作り方
さて、プロダクトバックログですが、ユーザーストーリー作って、ユーザーが望むものに
優先順位をつければ良いんでしょ？という話がよくあります。
しかしながら、これはある意味あっていますが、ある意味間違っています。
プロダクトバックログは、以下の観点から作成を行う必要があります。
- ユーザーに対しての価値（よく言われるユーザーストーリー）
- 不確定要素（リスク）
- 後続作業の多さ（開発的制限事項）
例えばですが、アプリケーション開発において、ユーザーが業務上利用するアプリケーションと、
ユーザーが業務上常に利用はしないが、先行してデータを入力して貰う必要があるマスタシステム。
上記の2つのアプリケーションはどちらが優先度が高くなるでしょうか？
これは、先行してデータを入力してもらう量にも比例します。
ユーザー側で、データを用意する必要があるもの（顧客データの一覧等）で、
ユーザーが時間を取って作業をする必要があるのであれば、そちらを開発上先に行って置かなければ、アプリケーションがリリースしたとしても、データがなくて使い物にならない可能性があります。
（※DBからデータコンバートすればいいんじゃね？っという話がありますが、そもそもDBすら無い新規案件等もあります。）
ようは、後続作業として、どの程度のボリュームが見込まれるかを、また、それらに対するリスクと、
アプリケーションとしての利用価値を天秤にかけてユーザーストーリーとして組み込む必要があります。
単純にユーザーに対しての直接的な価値のみをユーザーストーリーに定義していても意味がないのです。
そのユーザーに対して価値あるものを提供する為に、直接的な価値として認識ができないものであっても、ユーザーストーリー上、優先度が一番高いものがある可能性もあります。
よって、アプリケーションとして、ユーザーに対して直接的な価値を提供できるものをユーザーストーリーとして定義するのは問題ありませんが、それのみではなく、一見価値を提供しないが、これがないと、ユーザーに対して価値あるアプリケーションとして提供が行えないものもユーザーストーリー上に定義する必要があります。
よくある例としては、開発現場で毎回頭を悩ませる、フレームワークの選定や各種ツールの選定、
また、サーバ構築やネットワーク構築作業等も含まれるでしょうし、テスト環境構築等もこれらに含まれます。
ここをすっ飛ばして考えて、スプリントを回し始めてしまうと、いざリリースとなった場合、
ユーザー側から、今更マスターデータ作れと言われてもリリースに間に合うはずがね～だろう。
どうしてくれるんだ？
等と言われてしまいます。
ですので、プロダクトバックログには、ユーザーに対して価値を提供する為のアプリケーション本体以外のあらゆる項目をあげる必要があります。
そして、時として、それらはアプリケーション本体以上の優先度となる事を理解する必要があります。
（※ユーザーストーリーとは別に、タスク（スパイク）としてプロダクトバックログとは別に管理を行っても問題はありません。必要なのは、見える形にしておき、ユーザーストーリーと同様にどう消化するかチームで話し合える状況下にしておく事が大切です。）
プロダクトバックログの補足（調査項目など）
技術的検証や調査項目を含めた項目をスパイクとして別途スプリント0等で検証を含めて確認する事もあります。
この場合、ユーザーストーリーとは別に、調査課題等をスパイクとして管理を行う必要があります。
たいていここに記載されるのは、これがないとプロジェクトが破綻する、または、この調査をしないと実装検討やDB設計すらままならないというような、どれもリスクが高く優先度は通常のユーザーストーリーより圧倒的に高いものです。
実装前にユーザーストーリーを実装する為の検討課題があるのであれば、全てスパイクとして管理をしてしまうのもありです。
ちなみにこの調査についても期間を区切って検証しますが、ここで無理となった場合、ユーザーストーリーの変更や、実装機能の変更が入ったり、場合によっては開発者が逃げたりします・・・
スプリントバックログの作り方（イテレーションでもいいよ）
プロダクトバックログができたなら、次はスプリントバックログの作り方です。
（※ストーリーポイントの見積もりについては、後ろに回します。だって、スプリントバックログの話をしたほうがすんなり進むと思うから。）
基本的な考え方は、ユーザーストーリーを基に、作業単位まで分割し、実際にTODOとしておこしていく作業となります。
この際、注意しなければならないのが、何を持って終了とするかです。
基本的に、一つのユーザーストーリーが完了したとする場合、テストまで完了し、すぐに本番環境にのせられる状態である事が望ましいです。
よって、この際タスクとして現れるのは、当然単体テストや、必要であれば他システムとの結合を含むテストを行う必要があります。
例えば、ログイン画面を作成する場合、以下の作業項目が見込まれます。
- ログイン画面のデザイン作成
- ユーザー情報を格納するDB設計
- 必須入力チェック
- パスワードの暗号化等を含めた各種ロジック実装
- 各種テスト
また、ユーザーログイン画面として2段階認証等を取り入れるのであれば、
ワンタイムパスワードとの連携等もテストに含まれるでしょう。
これらの作業に分解したものがTODOとなり、スプリントバックログとして、スプリント内に消化するべき作業となります。
ここでよく陥る問題点として、一つのストーリー内にも先行して終わらせなければならないタスクが存在します。
例えばDB設計が終わらなければ、そもそもプログラム開発にも着手ができません。
開発者が二人いて、DB設計者が一人で、DB設計が終わるまで開発者二人が進められない等という事がフタを開けるとあったりします。
こういった事が出来る限り無いように、開発順序の制限が発生する場合は、調査項目としてこれらを解消しておく必要があるのに注意して下さい。
場合によっては、プロダクトバックログの細分化が必要になるでしょう。
これはこの次に話すストーリーポイントの話と絡みます。
プロダクトバックログの見積もり方法（ユーザーストーリー）
最初に、あくまでも目安です。
正確な見積もりは誰にも不可能です。
さて、プロダクトバックログからスプリントバックログの分解方法が分かったのであれば、
プロダクトバックログの見積もり方法です。
たいていアジャイルだとストーリーポイントと言いますが、基本的には工数で作業を行ってきたのであれば、工数の見積もりで構いません。
これは、どちらかというと経験に基づくもので、明確な基準はありません。
いずれ、ストーリーポイントという数値に変換していけるようになれば大丈夫です。
見積もりの方法ですが、そのユーザーストーリーを完結させる為に必要な全ての人間が、
見積もりに関わる必要が絶対にあります。
ユーザーストーリーを分解し、各作業におけるタスクから逆算して、ストーリーポイントを見積もります。
どの程度出来るかは、はじめのうちはやってみないとわかりません。
ですので気楽に、間違っても仕方がないくらいの感覚で行いましょう。
フィボナッチ数等を当てはめます等わけの分からない事が書かれている事が多いですが、
チーム内の基準値として扱えるのであれば、16進数でも、なんなら「あ〜ん」までのあいうえおでも良いです。
このストーリーポイントの大切なことは、繰り返し反復（スプリント・イテレーション）処理を行っていく際に、
どの程度のストーリーポイントであれば、1回のスプリント内で作業を終えることが出来るかというのをチーム内で共有する事が大切であり、
残りのプロダクトバックログの消化に対してどの程度までなら消化出来るかという目安となり得るかが重要です。
ストーリーポイントをいくら当てはめても、精度があがってこないのであれば、それこそが問題であり、ストーリーポイントを当てはめる事が目的ではないのです。
最終的な目的は、チームが1回のスプリント内で提供できる作業量の見える化こそが目的です。
ですので、集まったばかりのチームでは、ストーリーポイントの見積もりは、相当バラけるでしょう。
スプリントが開始されたばかりの頃は、プロダクトオーナーは、消化されるストーリーポイントの量に一喜一憂する必要もありません。
いずれこなれてくれば、収束していきます。
そして、もう一つ重要なことが、作業単位に分解した際に、開発者の手がとまるような先行タスクが複数存在して、うまくスプリント内に消化できないようであれば、ユーザーストーリーの細分化を行い、再度プロダクトバックログとして定義し直すことが重要です。
見積もり方法については、上記のように作業単位に分割する事も大切ですが、
同時に、各作業に適切な見積もりをする為に、他のプロダクトバックログ（ユーザーストーリー）と比較が重要です。
最低限でも、大きいものと小さいものの2つと比較をしてみましょう。
全体として出たストーリーポイントが、大きいものと小さいものを比較して、あまりにも感覚が合わない場合、何か見落としているか、作業の見積もりが大きすぎるか、想像以上に複雑（リスクを内包している（連携システムが多くテストが多い等））可能性があります。
こういった場合は、対象のプロダクトバックログの消化は注意深く行う必要があります。
ついでに、他チームとの比較が出来るかと言われると、首をひねるので、あまりそういった意味があるとは思わない方が良いと思います。