「CodeZine」の記事が酷いのでコメントしておく

しばらくブログをさぼっていましたが、酷い記事を読んで反論コメントしたくなったので、久々に書きます。

読んだのは、
「グラス片手にアジャイル開発 第4回 − ハイブリッドアジャイルの実践法」
http://codezine.jp/article/detail/5498

この記事の題名には「アジャイル」という単語が2つも入っているのに、全然「アジャイル」じゃないような気がするので、私個人の意見を述べさせていただきます。

業務システムにもアジャイルを適用」という目標を掲げた場合、3つの課題が浮かび上がります。1つは契約の問題です。連載第1回目に述べたようにアジャイルは「変更があって当たり前」というスタンスなので、いつまでもお客様が変更を要求してきたらコストが膨れ上がるのではという恐怖があります。

恐怖って・・・w

「変更があって当たり前」っていうのは、アジャイルだけではなく、現実的にウォータフォールでも同じだと思いますよ。工程の区切りでいくら「FIX」って宣言したところで、後から追加・変更ってのはざらにあるでしょ。社会だって市場だって動いているものなんだから、お客様の要求は常に変わるのは当然のこと。最初から全てわかっているって考える方がどうかしてる。

結局は対応の仕方が違うだけだと思います。

従来だと、お客様が変更を要求したきた時「最初の要件にないので、追加契約ですね」とか「今回は予算オーバーなので次期システムで対応しましょう」とか、最悪「そんなの聞いてないので出来ません!」といったところでしょうか。

アジャイルでは、「開発予算と開発期間は固定ですので、要件の中から相殺できるものを探しましょう。なるべくお客様にとって価値あるものを残した方が良いですからね」といった対応をします。お客様と開発者で話し合って、要件の優先順位を踏まえて作る対象を決めていきます。
この話し合いが出来ないなら「アジャイル」とは普通は言いません。
尚、この話し合いのタイミングを明確にしているのがスクラムです。

2つ目は工程による適用性の問題です。アジャイルは詳細設計やプログラミング、単体テストあたりの工程で有効ですが、システム全体の構想・企画を決定する要件定義や基本設計などの工程はあまりアジャイル向きとは言えません。

ここで言っている「アジャイル」とは「XP」の事なんでしょうね。
システム全体の構想・企画は、会社の特別なある部門が(必要であればコンサルタントと一緒に)作り上げるのが普通ですので、開発以前のお話しです。
1つ目の課題のところで既に述べたように、要求をベースに分析や要件定義・基本設計まで含めて、調整しながら一通りの工程をグルグル回すのがアジャイルの特徴です。

3つ目はドキュメントの問題です。エンタープライズ系の請負開発では、きちんとしたドキュメントの提出を求められます。アジャイル開発の基本は「不要な」ドキュメントを作らないことですが、業務システムでは「設計書」や「マニュアル」などは「必要な」ドキュメントとしてきちんとしたものの提出を求められます。

結局は、「不要なドキュメント」は不要だから作らないのであって、「設計書」や「マニュアル」は必要なことが多いのでアジャイルでも作りますよね。設計が不要なシステムなんて普通はあり得ないし、マニュアルはエンドユーザが操作するのに必要ですから。
ただし、ドキュメントを「紙で印刷する必要があるかどうか」は別です。これはプロジェクト毎に契約で決められることです。「××設計書一式○○部」と。
これは、アジャイルであろうがウォータフォールであろうが同じですよね。


記事にはこの後にも、かなりツッコミどころ満載な感じです。
イテレーションの考え方とか「それはウォータフォールそのものだろー」とか思わせる箇所があります。

が、昼休みも終わり(1h以上過ぎてる・・・)、そろそろ仕事しないといけないので、残りは別途時間のあるときにでも。

この記事を書いたのは、「(株)システムインテグレータ」の設立者の方のようですが、「アジャイル」の事をほとんどわかっていないのに「アジャイル」を語らないで欲しいです。また、この様な「一般的な読者(開発者)が誤解を生んでしまう」ような記事は、CodeZineの編集の方でちゃんとチェックして欲しいです。こんな記事が掲載され続けるなら、CodeZineサイト全体の信頼性も疑われます。