なぜアジャイル開発の検証するかその狙いを理解しようとしないの
「あ、お久しぶりです」
「ああ、こんにちは。久しぶりだね。今はどのプロジェクトをやっているの」
「顧客の役員がアジャイルをやってみて課題は何かを検証するプロジェクトなんですよ」
「アンチパターンそのものだね。上から手法を指定されたプロジェクトで成功した試しないよ」
「やることは決まっていて、アジャイルで開発することになってて」
「それであなたは何をするの」
「リーダです」
「へー、じゃあスクラムマスターなの（POではないのか。PMならPOな気もするけど。でも要件持っているのは顧客だよね）」
「ああ、スクラムマスターっていうんですね」
「ん、アジャイルって一括りに言っているけどどの開発手法でやるの。アジャイル開発は幾つかメジャーな手法があるから」
「スクラムでやろうと言われています」
「言われてって…大丈夫なんかな。心配になってきたよ」
「これから勉強したいので何か情報教えてもらえませんか」
「まあ、知っていることは教えられるけどさ」
「お願いします」
「じゃあamazonのサイト開いて。このキーワードで検索して。アジャイルサムライ
、SCRUM BOOT CAMP THE BOOK くらいは読んでおいたらどうかな。あとこのキーワードでサイトを検索して。そのサイトにスライドがあるから読んでみたら」
「へー、こんなスライドがあるんですね。ありがとうございます」
「でさあ、要件決まっているならウォーターフォールでいいんだよ。どうしてわざわざスクラムだって言っているのか知っている」
「顧客の偉い人がアジャイルでって」
「うーん（失敗はして欲しくないけどなぁ、さて）。そうだこれで検索して。
フロー効率性とリソース効率性について #xpjug をめくって。それ、6ページの上がウォーターフォールなんだ。乱暴だけどさ、イメージはそう。ABCの機能は納期にならないと出来上がらないじゃん。そこで初めてビジネス的に価値があるかどうかをソフトウェアとして確かめられるんだよね、顧客は。わかるかな」
「…ええ…」
「下がアジャイル開発でやったらになるイメージね。小さなスプリントに収まる必要な機能だけを繰り返し作っていくんだ。ほらA機能はさ、5つ目で終わるでしょ。そこで顧客はソフトウェアがビジネス的にリターンを得られるか確認できるんだよ。それもマーケットで。ウォーターフォールとは違うでしょ」
「はあ…なんとなく…わかります」
「そうだ、アジャイルソフトウェア開発宣言 のサイトって知ってるかな。そう、じゃあアジャイル宣言で検索して。ここのね、
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を
ってあるじゃない。顧客の欲しいものを作るのが強調のところ。動くソフトウェアはA機能をいち早く使える状態にすること、それが期待と違っていたら顧客の欲しいものが変わるから続けて作るソフトウェア自体を変化させることが対応、短期間で作る必要があるから関係者で会話しないと進まないから対話、とね、さっきのスライドがこうしたことを背景に繋がっている、とね、そう思っている。ワタシだけかもしれないけど」
「…」
「たぶん、失敗するよ。今のままだと」
「それは困ります」
「いいじゃないの、検証なんだから間違った課題設定で間違った結果となっても」
「それじゃ」
「じゃあ、その検証はなんの目的でやるんだろうね。それを突き止めないとなんかやりましたとか、そのエライ人の期待する結果に合わせた報告をするだけになってしまいそうなんだよ」
「どうしたらいいですか」
「アジャイルコーチを雇ったら」
「コストが」
「じゃあワタシが傍観してあげようか。コスト必要だけど」
「そこは無料で」
「コーチを入れた方がなんの目的でやるのかから根掘り葉掘り詳らかにしてくれてていいと思うけどなぁ。ワタシでもやるけど」
「…」
「まあ、困りそうな前に何かあったら雑談にでも誘って」
