日経ITProの記事にケチつけておく

日経ITPro: アジャイルはウォーターフォールよりも難しい

何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。

そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。

そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。
ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。
ただ、最近は大規模でのAgile事例は増えてきている。日本ではまだ少ない、というところでしょ。

「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。
当初の一欄に入っていない要求が増えたら、納期延ばす・金を積んでもらう・代替として何かの要求を削るという選択しかない。
それができないというのはAgileが悪いのではなく、お客さんとの関係に問題があるわけで。
そしてそういう関係の場合、ほぼ確実にウォーターフォールでもうまくはいかんでしょ。「当初見積り範囲外なので対応できません」と言い続ければ納期予算には収まるかもしれんが、果たしてそれは「成功」と言えるのかね？

さらに業務システムへの適用となると、コストや納期の制約があり、品質優先で開発を繰り返しながらシステムを成長させていくアジャイルと考え方が相反する面がある。

この記者は真面目にTDDやったことがないか、TDDに関する理解が欠如していると思われる。
コストや納期の制約があるから、常に品質を確認しながらビルド＆テストを回していく必要があるのだ。

一つ目は、イテレーション（反復）に関する難しさだ。2週間や1カ月という短い周期で設計・実装・テストを繰り返すアジャイルでは、慣れないと期間内になかなか機能が出来上がらない事態に直面することがよくある。

ではこれはウォーターフォールなら解決するのだろうか？
なかなか出来上がらないものが最初の二週間で判明するのはとても素晴らしいことでは？
それとも「順調」という報告だけ信じて、結合テストとか総合テストとかで地雷踏むのがいいの？

根底には三つの原因があると考える。（a）何を作るかという要求がほとんど決まらないままイテレーションを始める、（b）作業の負荷を考えずに各イテレーションの機能配分を行う、（c）イテレーションの反省を次のイテレーションに生かせない――である。

これはAgileかウォーターフォールかを議論する前の問題でしょ。
何作るか決まってないのならなにしても無駄。
作業の負荷がどれくらいなのかを作りながら把握できるのはAgileの利点。

とりわけアジャイルでは、詳細設計書を作らない場合が多い。しかし、大勢のメンバーが参加する業務システム開発の場合、プログラムを実装する際にスキルの個人差が出る恐れがある。これは保守性の面で大きな問題だ。

では詳細設計書があれば保守性があがるのだろうか？
詳細設計書がなければソースが理解出来ない、というようなスキルの持ち主は、果たしてそのソースが詳細設計書通りであることをどうやって担保するのだろうか？
ソースから起こしたUMLと、テストコードのほうがよっぽど保守性を上げる武器になるのでは？
あとはソース読めるようにしろ、と。

アジャイルでは設計の見直しが頻繁に入るので、メンテナンス性を考えたドキュメントの作成方法にも頭を悩ます。表計算ソフトやプレゼンテーションソフトでは、作成やメンテナンスに時間がかかり、限られた時間を圧迫してしまう。

だからそんなドキュメントはいらねーんだよ。

メンバーやユーザーがうまく連携できない。これが三つ目の難しさである。アジャイルでは、コミュニケーションを重視するが、慣れないとギクシャクしたり、報告・連絡・相談が滞ったりすることがある。

これはまさにそのとおりなんだけど意思疎通に問題を抱えるチームがウォーターフォールで開発したらもっとひどいことになるわけで。

専門分化が進む職種構造によって、設計者とプログラマが設計書ではなく口頭でコミュニケーションを取るのに苦労する現場も多いようだ。

設計書でコミュニケーション取れていた、と思い込んでいた「自称設計専門家」にはつらい日々が来るだろうね。
そういうやつはいらねーんだよ。

エンドユーザーとの対話が少なかった現場は、さらにアジャイルの適用を難しくする。日常業務と並行して頻繁にレビューを依頼する必要があるためだ。レビューのフィードバックの遅れはそのまま進捗遅れにつながる。リリース日はあっという間に来てしまうので、「アジャイルは精神衛生的に悪い」と訴えるITエンジニアの声は目立つ。

確かにAgileの場合恒常的に忙しさを感じることはある。
だけど、忙しさを感じたら手遅れであとは炎上しまくりのウォーターフォールよりはよっぽど精神にはやさしいよ。

最後はマネジメントに関する難しさだ。アジャイルでは各メンバーが水平型のチームを構成し、ボトムアップ的に行動する。指示や管理といったプロジェクトマネジメントが利きにくい面は否定できない。

階層構造型の組織だと指示や管理といったプロジェクトマネジメントが効きやすくなるんですかね？

プロジェクトマネジャーが作業の負荷や進捗をきちんと把握できない例は少なくないようだ。プロジェクトマネジャーにとってアジャイルは、プロジェクトを進めにくい手法といえる。

そのプロジェクトマネージャさんはウォーターフォールでの基本設計進捗率とかをどうやって把握するんですかね。設計に漏れや間違いがないって、どうやって確証を持つんだろうね。

Agileは日々のタスクレベルでの完了/未完が客観的かつ明瞭にわかってしまう。「進捗率50%くらい」などという恣意的な判断が入る余地はない。そういう中、どのタスクを優先させ、どのタスクを後回しにし、やばそうなタスクを見つけて早めに手を打つ、といった判断を日々繰り返さなければならない。そういう視点では確かにAgileは「しんどい」かもしれない。だけどガントチャートを塗りつぶして「できたつもり」「50％終わったつもり」などという「思い込みプロジェクト管理」を排除できるから、Agileは後半に「どっひゃ〜」となる危険性を回避しやすいのである。