「きっちりとしたプロジェクトマネジメントが求められる案件はウォータフォール」、「とにかく動くものを早く作るならアジャイル開発」そんなイメージが浸透している気がします。
この記事はそんなイメージに真っ向から立ち向かう内容です。つまり「きっちりとしたプロジェクトマネジメントが求められる案件こそアジャイル 開発」という意見を経験を踏まえて述べていこうと思います。
上の画像はアウディのロゴみたいですがイテレーション開発のイメージです。
プロジェクトマネージャから見たアジャイル開発のメリット
昨今、PMというと「プロダクトマネージャ」と訳す方がメジャーになりつつあると思いますが、まだエンプラの世界ではPMと言えば「プロジェクトマネージャ」ですね。
ここで挙げるプロジェクトマネージャとは、物を顧客と握った仕様通りにちゃんと開発する事に責任を持つ人を示します。その先、つまり物が売れたり役に立つかには直接の責任は無いとします。
なお、Scrumを知っている方なら「そもそもPMなんて役割は無いだろう」とツッコミを入れたくなりますが、エンプラの世界では体制にPMがいるんですよね。そういう業界の話しと割り切って頂けると幸いです。
PMから見たメリット
- 正確な進捗管理が出来る
- 品質を維持、向上させやすい
- 問題/課題に対する対策が早く出来る
その結果、
「開発がコケる可能性を減らせる」
ここからは各メリットについて詳しく書いていきます。
正確な進捗管理が出来る
「アジャイル開発は厳密な管理をしない」というイメージを持たれている方が多数派ではないでしょうか。私がアジャイル開発の導入に関わり始めた頃も、今も、アジャイル開発のプロジェクト管理に関するご相談を沢山頂きます。
実際はウォータフォールよりもアジャイル開発の例えばスクラムのフレームワークに従った方がきめ細かく正確な進捗管理が出来ます。と言うのも、1 週間（5営業日）程度でリリース出来るものを開発するアジャイル開発にとって、たった1日の遅れが致命的な遅れになるためです。
アジャイル開発の進捗管理がどのようにきめ細かいのか、いくつかの要点を述べていきます。
まず計画です。そもそも無理な計画を立てては進捗なんて守れるはずがありません。アジャイル開発はスプリントというイテレーションの始めに計画会議を行い、スプリント（1～2週間が一般的）のスコープとスコープを実現するために必要なタスクの計画をします。1、2週間の計画を立てる訳ですから、数ヶ月〜数年レベルの計画を立てるウォータフォール開発に比べて、より確度の高い計画を立て易いことは間違えないです。
タスクは開発者が洗い出し、作業時間を1時間単位で見積ります。この時、作業時間が8時間を超えるようなタスクは進捗管理がやりずらいので分割をします。
そして最後に全タスクの作業時間の合計が開発者の開発に充てられる時間を超えていないか確認するのです。超えている場合も、反対に余裕がありすぎる場合も、スコープを再調整します。
これをしっかりと実施すれば、かなり現実的な計画が立てられます。
次は開発時の進捗の見える化です。見える化はウォータフォール開発でもWBSの稲妻線などを使って行いますが、アジャイル開発はより細かい粒度で見える化をします。
アジャイル開発の進捗の見える化では、主にバーンダウンチャートを使います。計画したタスクの見積り時間を積み上げておいて、タスクが完了する毎に積み上げた時間を減らしていくのです。完了予定日に対して真っ直ぐ引いた理想線に対し、実績線が上にいれば遅れている事になります。
タスクは時間単位で見積もられているので、バーンダウンチャートは時間単位で進捗管理が出来ます。
より厳密に進捗を見える化するのであれば、学校の時間割のような表を作り、あらかじめタスクを貼っておくという方法が有効です。現在時刻と時間割上のタスクの消化状況を比較すれば、遅れているタスクやボトルネックになっているタスクが一目で分かります。
品質を向上させやすい
アジャイル開発の品質管理に関しては、進捗以上に「いいかげん」と思っている方が多数派ではないでしょうか。確かにウォータフォールのように工程毎の進捗管理はしません。
しかしこれも品質目標を明確にして取り組めばアジャイル開発のフレームワークの方が品質に起因するプロジェクトの失敗リスクが低く、障害発生時のリカバリーもしやすいです。
まずスプリント毎に一定の試験をパスした成果物を積み上げていくため品質の積み上げ管理が容易です。これを効率化するためにGitによるブランチ管理とCI（Continuous Integration)を組み合わせます。
例えば、「開発中のプログラム」「スプリントレビューが完了したプログラム」「リリースしたプログラム」を管理するためのブランチを用意し、各ブランチにマージする際の品質要件（例えば、処理結合試験の完了など）を設定しておきます。更にマージする前に自動でリグレッションテストが実施されるようにします。そうする事でソースコードの品質が段階的に担保でき、管理がしやすくなります。
更にスプリント毎に一定の品質を担保していくので、バグが発生した際の原因分析と修正が容易になります。新しくマージした（しようとした）新しい小規模のコードに問題がある可能性が高いですし、リグレッションテストも行うので、バグの影響範囲も特定出来ます。
こういった点からフレームワークが破綻しているプロジェクトを除きプロジェクト後半でバグが頻出して炎上するプロジェクトは少ないように感じます。
次に障害発生時のリカバリーについて、前述のGitのブランチを活用した品質管理をしていれば容易だと分かって頂けると思います。障害の原因は十中八九、新しく「リリースしたソースコード」のブランチにマージしたソースコードにあると言えます。そのため、マージ前のバージョンをもう一度デプロイすればとりあえず障害は回復します。前バージョンへの切り戻しの影響はリリースの頻度が高いほど、即ち前回のリリースからの差分が小さいほど小さくなります。
リリースは勇気と責任の伴う行為かもしれませんが、障害発生時の迅速な対応を約束して高頻度でリリースするのは品質管理の１つの方法として有効かもしれません。
問題に対する対策が早く出来る
問題に対する対策が早く出来るのは問題に早く気付けるからです。そして、たいていの問題は早く気付くほど対策がより容易になります。
ここまで読んで頂ければ、進捗と品質については早い段階で問題に気付いて対策が出来ると理解して頂けると思います。
アジャイル開発が問題発見を容易にする理由は1週間や2週間の単位で設計、製造、試験、受け入れ を繰り返すプロセスと、デイリースクラムや振り返りといったプラクティスにあります。
まずプロセスですが、早い段階で動くシステムを開発して本番に近い環境にデプロイするため、技術的な課題が見つけやすいです。デプロイしたシステムを顧客に試行してもらう事で顧客のイメージとのギャップにも早い段階で気付く事が出来ます。
プロセスの利点をより活かすのが、デイリースクラムと振り返りのプラクティスです。これらはプロジェクトを点検するプラクティスです。例えば、デイリースクラムでは開発メンバー個人の進捗に加え、直面している問題や、これから問題になりそうな事を共有し、状況によっては別途時間を取って対策を検討します。
問題を早期に発見してプロジェクトの問題化を防ぐためのポイントを挙げます。
ポイント
- ユーザが使える機能の単位でイテレーションを回す
- 早い段階で一本通しをして、技術課題を出し尽くしてリスクを下げる
- ユーザにサービス提供しなくても公開前の本番環境で動かし続ける。出来ればお試しで使ってもらう。
まとめ
頻繁なリリースをせずに単にイテレーションで開発をしているだけのプロジェクトを「ミニウォータフォール」という事がありますが、例えミニウォータフォールだったとしても、上記で述べたような進捗管理や品質管理、問題発見を促すプロセスやプラクティスを守っていれば、ここで述べたようなメリットを得る事が出来ます。あえてプロジェクトマネジメントの観点でアジャイル開発を導入してみてはいかがでようか。