アジャイルソフトウェア開発スクラム

読んだ！　読みづらかった！　疲れた！

アジャイル系といえば数年前にXP本を何冊か読んだ。色々試したがその時点で出した結論は「適用は難しい」だった。XPは名前の通りエクストリームすぎるし、スコープがプログラマ周辺に限定されていて（自分の理解では）、管理者を巻き込んだ適用は難しいと感じた。

一方スクラム…とXPと比較すべきではない。スコープが違っていて、スクラムの中にXPのプラクティスを取り込んでもいいと思う。

で、スクラムはどうなのかというと、イテレーティブな進行方法がより詳細に定義されているので参考になる。特に残工数ベースのバーンダウンチャートベースの進捗管理は現実的だ。

進捗管理といえばMS-Projectでおなじみのガントチャート。見栄えはするし、なんとなく進捗％がでて進捗管理出来ている気になるが、実際使うとなんか使いづらい。

何が使いづらいのかといえば、ソフトウェア開発ってアジャイル陣の主張する通り不測の要素が多くて、

• タスクの見積工数が十中八九ブレる（大概増える）
• 進めると「ああ、これやらなきゃ」とタスクが増える
• 最初に想定していた機能の価値が下がって優先度が下がる（もうやらんでええやんと）

こういうことがよく発生するのだけれど、MS-Pでこれらをちょくちょく反映するのってかなりしんどい。しかも反映したらしたで元の計画に対してどう変化したのかが分かりづらい。（僕がMS-Pの使い方を知らんだけというのもありますが）

見積精度が甘いヤツの言い訳だと言われればそうなんだけど、そんなに正確な見積を出来る人を僕は少なくとも見たことがない、というのが実情だ。

で、バーンダウンチャートを使った残工数ベースの進捗管理はそれにどう答えてくれるかというと単純だ。

• 進捗度合いを%ではなく、残作業時間で報告する
• その際に元の見積工数を超えても素直に報告時点の見積った残作業時間で

報告された残工数をグラフにするとこんな感じだ。

理想の消化は単純にイテレーション（スクラムではスプリントと呼ぶ）開始時に見積もった工数を均等に消化していく線だ。（こんな綺麗にことが運ぶことはまず無いが）

実際にはうまくことが進まなかったり、見積時に見落としがあって追加タスクが発生したりして理想線よりも上にぶれることが多い。そして最終的には残工数を０に収束させる。

さて、ここで「収束させる」というのがスクラム（というよりアジャイル）のポイントだ。

どうやって収束させるのか。これはウォーターフォールな考え方からしたら「反則だろ」というもの。

1. がんばる（残業、追加人員の投入）
2. あきらめる（機能を削る）

１はまぁいい、というよりよくある話。２って「ええー」って感じでしょ。

アジャイルへの抵抗感はここだったりする。

通常プロジェクトは次の4つの変動パラメーターの影響を受ける。

1. スコープ
2. 期間
3. コスト（要員）
4. 品質

ウォーターフォールでは、１・２を固定して３を増大させて調整する。４も犠牲になりやすい（テストを省略したりするのなんてそうでしょ？）・・・よね？

アジャイルでは２・３・４を固定して、１を調整する。その背景には「変化を包容せよ」という考え方がある。要するに「時間とともにビジネス的価値は変わる」「要件定義の時につけた重要度のままで本当にいいの？」ということだ。

た・し・か・に。

要件定義やら基本設計で決めては見たもののある程度実装して動くようになるとクライアントは色々な要求を出してくる。

作る側からすると「え？　設計の時に決めたじゃないですか」。

クライアントからすれば「あの時は完成図がよく分からなかったからそういったけどさぁ。」

結果として「あの時よくわからなかったけどとりあえず決めた」内容でずるずると開発は進められ、要件は満たしているけど本当に欲しいものではないものが納品されたりする。

アジャイルはこのような事態に対して「変化を包容せよ」と言っているのだ。

上記のような場合に「OK,じゃあこういう風に機能を加えましょうか」とか言ってしまうのだ。

し・か・し。

光あれば影ありじゃないけど、当然ながら追加要求をバンバン受け入れてたら期日までに終わるわけが無い。そこでアジャイルではクライアントにトレードオフを要求することでバランスを保つ。つまり、「その要求はやります。その代わりあまり重要でないものを捨ててください」と。

要するに「当初要求通りのモノでなくてもいい、最終的にクライアントにとって価値があるモノであれば」という考えだ。

ここでRFPに焦点をあててみる。

RFPには要求がずらっと書いてあるわけだが、このRFPを元に開発受託の契約を結ぶ。

RFPに書かれる要求全部ではないにしろ、契約締結時にはスコープを決める。

スコープはクライアントが支払う代金に対する対価。それは例えば5000円でフィレステーキを注文するようなもの。

と、いうことはアジャイルがスコープを変更すると言うのは「5000円払ったけどロースになっちゃった！」ということがあり得るのだ。（もちろん逆に5000円でフィレに加えてフォアグラがついてくることもあり得る。）

もちろん、勝手にフィレをロースにするわけではない。頻繁にコミュニケーションをとり合意形成のもと納得しもらってフィレをロースにするのがアジャイルだ。そのためにイテレーションごとに「動くモノ」をクライアントに提供してフィードバックを取り込む。

だ・が・し・か・し。

堅苦しい「契約」からすると「約束が果されていない」ということもできてしまうのだ。

この問題をどう解決するのかがわからない。

もちろんウォーターフォールにだってこのリスクは実は十分以上にあるのだが、問題は契約条件として表立って「スコープを満たすことは保証されません」と言える人がどれだけいるのだろう。

契約の無い社内開発においても経営陣に対して「スコープは確約されません」「信じてくださいベストを尽くします」では稟議を通しにくい。

アジャイルはウォーターフォールのような理想論ではなく、現実的論だというのはよく分かる。

アジャイル本を読むと一様にして「めんどくさい管理は最小限にして、俺たちを開発に集中させてくれ！　そうしたら最高のモノを作って見せるぜ」と言う。

しかし、アジャイルはある意味「提供するモノに対する責任」をうやむやにしているともいえる。（現実的にはそうではないのは理解できるのだが）

どうするとうまく運用できるのか、それを考えていかなければならないなぁ。。。