アジャイルについて
アジャイルの妄信的な信者が率いる開発現場は悲惨だ。彼らは宣言文の文章に感銘を受け、その理念に惚れ込み、手当たりしだいに書籍を購入し、教科書どおりに実践しようとする。「ウォーターフォールは過去の産物だ」とさもしたり顔で批判し始め、これからはスクラムだ、コミュニケーションだと言って開発員の性格や社風も気にせず職場環境の改革を訴え始める。
残念ながらこのようなプロジェクトでのアジャイル導入は失敗するだろう。アジャイルは宗教などではなく、あくまで開発手法の提案に過ぎないからだ。教科書に載っているプロセスにこだわっていては目的を見失う。理論ばかりが先行しても現実とのギャップを埋められるはずもない。
そもそもアジャイルを受け入れられるプロジェクトというのは限られている。SLAに最高の品質を求められるような基幹系のシステム開発や大規模なプロジェクトにアジャイルは向いていない。開発途中の仕様変更が即座にプロジェクトの死と莫大な違約金に直結しかねないからだ。このような性質のプロジェクトにアジャイルを導入しようとする輩は、きっとその会社に恨みでもあるのだろう。彼らの言うことを鵜呑みにしてはいけない。導入にあたっては生産するソフトウェアの性質やプロジェクトの規模、開発員の質などをきちんと見極めることが重要である。
実際にアジャイルがうまくいっているプロジェクトというのは、顧客の要望や管理職の要求、世の中の動向を吸収していくうちに自然とアジャイル的な開発工程が身についた現場のことだ。有能なリーダーであれば、機能を確認したいという顧客の要望や、仕様変更へのリスクを下げたいという開発員の希望によって、必然的に開発工程をウォーターフォール型からアジャイル型へシフトさせていくだろう。どこまで計画を重視するか、どこまで変更に対応するかをきちんと見極め、最適なバランスを模索するはずだ。目の前にあるニーズに応えていくうちに自然と生み出された業務こそがその現場にとってのベストプラクティスである。急激な改革を開発員に押し付けてはいけない。
○本体実装以外の業務の重要性
開発員はリファクタリングやテストコード開発にかかる工数を工程管理者にきちんと納得させ理解してもらわなければならない。彼らはしばしばこれらの開発業務を周辺作業とみなし、ソフトウェアの実装を優先するよう指示してくる。これらの工程が削られていくようであれば、開発員はすぐに「以前の方が良かった」と嘆くことになるだろう。結局のところ、頻繁な仕様変更に対応しなければならなくなっただけなのだから。
○初期設計の重要性
通常、プログラムの修正コストは開発が進むにつれて増大する。アジャイルにおいては、反復（イテレーション）やテストファーストなどの施策によって変更への適応性を高めている。しかし、これらの施策は修正コストの増大を抑えるものであってゼロにするというものではない。仕様変更にナーバスなウォーターフォールと比べると、アジャイルは変更が繰り返される分、明らかに開発量は増え、開発の難易度は高くなる。
時としてYAGNIは深刻な問題を引き起こす。仕様変更の影響がソフトウェア設計のアーキテクチャ、つまり根幹の部分に関われば修正範囲がソースコード全体、テストセット全体に及んでしまい、もはや修正コストの増大を防ぎきることは不可能となる。このためソフトウェアの設計者は、設計段階においてソフトウェア要件や機能仕様のかなりの部分をあらかじめ見通しておく必要があり、そういう意味ではアジャイルであろうがウォーターフォールであろうが初期設計というのは非常に重要な工程となる。特にソフトウェア要件が出揃っていない前提で開発が進んでいくアジャイルでは初期設計工程が軽視されがちであるが、ウォーターフォール並みのきちんとした初期設計がなければイテレーションを繰り返すたびに変更リスクが増大し、むしろデスマーチを招く結果となるかもしれない。
実際に開発の初期段階において反復する必要があるのは、ソフトウェア要件の整理とそれを元にした機能仕様設計だけである。したがって顧客とのプラクティスにおいては、まずは実装を行わず、ユーザーインタフェースのみのリリースと確認作業を反復することが望ましい。仕様の大筋が決定した後に実装の反復に入ることでさらに修正コストを下げることが可能となるだろう。
○顧客側プラクティスの重要性
アジャイルを論じる者の多くは開発者である。このため、アジャイルを話題にするときには開発側のプラクティスばかりが注目されがちであるが、実際にアジャイルにとって最も重要なのは顧客側のプラクティスである。そもそも顧客の協力なくしてアジャイルの成功はあり得ない。度重なるリリースに対する確認作業を顧客側が受け入れてくれないのであれば、安易にアジャイルの導入を決定すべきではない。修正リスクが下がらないまま、仕様変更に対応する約束だけが一人歩きしかねないからだ。
ここで注意が必要なのは、顧客はただただわがまま放題にあれこれ言えるわけではないということだ。仕様の大前提が崩れれば変更への適応性もクソもない。「アジャイル」という言葉を免罪符にしてなんでもかんでも仕様変更に対応しろというのは上流従事者の怠慢である。決定事項は何か、どこが変更可能でどのような変更が困難であるか、どれくらいの修正量になりリリース時期はいつになるかをきちんと把握すること、そして毎回のリリースでこれらの事柄についてしっかりとコンセンサスを得るという非常に難易度の高い業務が上流従事者には求められる。もしこの役割をきちんとこなすことができなければアジャイルの成功は絶対にないということを上流従事者は肝に銘じておくことだ。これは顧客側に押し付ける類いの話ではなく、SEが為すべき業務、果たすべき責任の話だ。ただただ顧客の要望を聞いてくるだけのSEは真の意味での上流従事者とは言えない。
○まとめ
アジャイルで提唱されている数々の手法を教科書通りに実践すれば、どんなプロジェクトでもうまくいくというわけではない。アジャイルの台頭とは、裏を返せば、顧客が品質や堅牢性よりも変化への対応を望んでいることを示しており、プロジェクトがその目的に対して最適な結果を模索していけば、自然とそのプロジェクトにはアジャイル的なプラクティスが身につくはずだ、というのが私の考えである。理論の押し付けやプロセスの強要といったいわばトップダウンな方法よりも、現場で発生したアジャイル的なプラクティスを改善・進化させていくボトムアップ方式がアジャイル導入に適しており、こちらの方が理念の浸透に無理がなく、プロジェクトの目的・実情に即したプラクティスだけが実践されることになるだろう。
ただ、ソフトウェア業界全体が顧客の要望に臨機応変に対応できないと淘汰されてしまうという非常に厳しい状況にあり、企業は望むと望まざるに拘わらずアジャイルの採用を余儀なくされているという現実もある。このようなプロジェクトではトップダウンによる導入方法しか選択肢がなく、急激な改革によって現場が混乱するという状態に陥ってしまうこともあるかもしれない。ここで注目されるのはプロジェクトを正しい方向へ導くリーダーの存在であるが、アジャイル成功への鍵となる最も重要な顧客側のプラクティス、特に上流従事者のなすべき業務について語られることが現状においては圧倒的に少なく、これがアジャイル失敗の主な原因となっているのではないかと私は思う。
最新の投稿
コメント
h
>アジャイルで提唱されている数々の手法を教科書通りに実践すれば、どんなプロジェクトでもうまくいくというわけではない。
これってアジャイルの教科書の一番最初に書いてあるんじゃないですかね？
（常識だから書く必要ないだろって事で書いてないのもあるのでしょうけど…）
アジャイルが失敗するのは教科書通りに進めるから良くないのではなく
逆に教科書通りに進めないからではないでしょうか。
また
>度重なるリリースに対する確認作業を顧客側が受け入れてくれないのであれば
とありますが、この確認作業とはどの程度を意図されているのでしょうか。
1．クリックくらいして欲しい
2．実際のデータを2つほど入力してみて欲しい
3．全テストケースを顧客側で作成して実施して欲しい
4．etc
1ではないと考えますが（実際に触った結果で「～に直して欲しい」と要望しているでしょうし）
2と3の溝がアジャイル失敗の要因ではないでしょうか。
玄米茶
hさんコメントありがとうございます。
>逆に教科書通りに進めないからではないでしょうか。
hさんのおっしゃるとおり、教科書通りに進めないから起きる失敗例も当然あると思います。
ただ冒頭でも触れていますが、このコラムが、アジャイルを絶対的に信じ込んでいるいわば信者のような人間に向けての注意喚起という主旨を持っていますので、「教科書通りに進めないから起きる失敗」よりも「教科書通りでも成功するとはかぎらない」という方に焦点を当てた形となっています。
>とありますが、この確認作業とはどの程度を意図されているのでしょうか。
程度の度合いは一律に決まるものではなく、そのプロジェクトごとの方針や実装箇所の事情などで違いがでてくると思います。
たとえば予算的にも工数的にも余裕があるのなら全体的にある程度ゆるくても構わないかもしれませんし、非常にクリティカルな部分のリリースにおいてはなるべく変更が起きないよう機能確認以上のことを要求する場合もあるかと思います。
あと、ここで言う確認作業とは、品質チェックの話ではなく、機能の網羅性やデータ構造の妥当性などの確認ですので、3は選択肢としてはおかしいかなと思いました。
確認というより検収という言葉の方が意味合いが近いのかもしれません。
まりも
内容を見ていると、
単にアジャイルを勉強せずに、
ウォーターフォールの信者をやっているように見えますが。
アジャイルが品質を重要視しないなんていったいどこの話だ？
ardbeg32
アジャイルだって「ある程度の仕様の範囲の品質」は当然考えているでしょうけど、
『SLAに最高の品質を求められるような基幹系のシステム開発や大規模なプロジェクト』
には対応できないでしょう？と筆者は仰っているだけでは？
実際上場企業の基幹系をアジャイルで開発している案件ってあるんですかね？
と現場から離れて久しいロートルは首をひねるわけで。
あるなら、筆者の前提がそもそも間違えており、
あったとしても、枝葉末節のプログラム開発でのことなら筆者の主張には一定の正当性があるのでは。
まりも
>ardbeg32さん
私への発言ですか？
そもそもアジャイルは品質が低くていいというような事実とは違ったことを言っていると指摘しているのですから、
>『SLAに最高の品質を求められるような基幹系のシステム開発や大規模なプロジェクト』
のように状況を絞っても絞らなくても、関係ないでしょう。
玄米茶
まりもさん、コメントありがとうございます。
ウォーターフォール信者のように見えましたか。
然るべきプロジェクトが最適な結果を模索していけばウォーターフォール的な工程はなくなっていくだろう、ということを述べたつもりだったんですが、私の表現力・文章力が足りなかったでしょうか。
ちなみにどの文脈から「アジャイルは品質が低くていい」と言っていると思いましたか？
ardbeg32さん、コメントありがとうございます。
>実際上場企業の基幹系をアジャイルで開発している案件ってあるんですかね？
コラム本文でも触れていますが、受託契約の内容に違反した・しないで裁判沙汰になったときにものすごく揉めそうなんですよね。
なもんで、管理職なんかは怖がっちゃって二の足を踏んでしまうと。
開発がスタートした時点ではお互いあるべき完成品の姿が見えていないわけで、納品・検収項目をどう契約書に盛り込むか非常に難しいところだと思います。
この辺りはある意味、アジャイルの一番の欠点と言えるかもしれませんね。
まりも
>然るべきプロジェクトが最適な結果を模索していけばウォーターフォール的な工程はなくなっていくだろう、ということを述べたつもりだったんですが、
字面を見ればそのようなことが書いてありますが、
語られている未来の内容は、大変ウォーターフォール的ですね。
>ちなみにどの文脈から「アジャイルは品質が低くていい」と言っていると思いましたか？
>顧客が品質や堅牢性よりも変化への対応
ここですね。
玄米茶
>顧客が品質や堅牢性よりも変化への対応
どちらを優先するかという比較の話であり、この文章をもって「重要視しない」「低くていい」と言い換えるのはなんとも悪意のある表現ですね。
ただただ相手を咎めるためだけの議論はできれば避けたいので、もう少し具体的な指摘やご自身の見解等を述べていただけるとありがたいです。
まりも
このコラム、その人が新しい記事が書いてないと古い記事を探すのが大変ですね。
見つかったので返事を。
>どちらを優先するかという比較の話であり、この文章をもって「重要視しない」「低くていい」と言い換えるのはなんとも悪意のある表現ですね。
いや、比較的重要視しない、比較的低くていい、という話を私はしていますよ。
そんな事実はないです。
常に変化が必要とされるときに、どれだけの品質が必要とされると思っていますか？
少なくとも、私が見たことのあるウォーターフォールよりは高い品質がないとやっていられませんでしたが。
考えてもみてください。毎週必ず改修が来るんですよ？
まともに動いているアジャイル開発なら、品質を非常に大事にしているはずです。
それはアジャイルを少し勉強すればすぐわかることです。
玄米茶
長文失礼。
>このコラム、その人が新しい記事が書いてないと古い記事を探すのが大変ですね。
たぶんここ見てるのもはや私たちだけだと思いますよ（笑）
>いや、比較的重要視しない、比較的低くていい、という話を私はしていますよ。
ここからは国語の話です。
「比較的」という言葉もどうかと思いますが、なぜはじめから「比較的」をつけなかったのでしょうか。
それがなくても通じると思いましたか？
あと、何と何を比較していますか？
この文章では「品質」と「変化への対応」について、顧客の希望の度合いを比較しています。
もちろん「顧客が」などというからには、この文章は一般論・抽象論を述べようとしており、推測を孕んでいます。
そんなデータは存在しない、という反論であればまだ納得できますが、いきなり「アジャイルは～」と主語を置き換えられると非常に違和感を覚えてしまいます。
この文章は述語が「望んでいる」なので、文脈は「比較的望んでいる」であり、「比較的低くていい」とでは大きく意味合いが異なると思いませんか？
文章中において品質の低さを許容しているわけではありませんし、重要視していないと主張しているわけでもありません。
そもそも開発手法といったソフトウェア工学的な話をするのに「品質は低くていい」などというような意見・理論はあり得ないと思いますがいかがでしょうか。
まりもさんの読解の仕方や表現の仕方には非常に違和感を覚えるのですが、故意でしょうか素でしょうか？
見下されているのはまぁ別に構いませんが、相手を咎めようという衝動だけでコメントをくださっているのであれば、あまりこの先続けてもしょうがないなというのが正直なところです。
>少なくとも、私が見たことのあるウォーターフォールよりは高い品質がないとやっていられませんでしたが。
工学的にアジャイルはウォーターフォールよりも品質が高いはずだと言っていますか？
それとも経験にもとづく単なる主観ですか？
ここからは工学論です。
ウォーターフォールだと検査工程を経て開発側で可能な限り故障率を減らした状態で顧客へのリリースが行われます。
一方、アジャイルでは開発の途中段階においても複数回のリリースが行われるため、毎回レベルダウンの危険性を孕んでいます。
もちろん、最終的にはどちらも完全に品質を確保した状態で納品がなされますが、アジャイルにおいては複数のリリースによって顧客側で発覚する故障件数はウォーターフォールよりも多くなることが予想されるでしょう。
また、開発途中では仕様が明確になっていないことで故障（仕様誤り）だとみなされてしまうものもあると思います。
もし、ウォーターフォール並みの品質を毎リリースで確保するのであれば、仕様誤りの不明瞭さを克服し、さらにリリースごとに厳格な検査工程を経なければならず、これは実際の現場において現実的とは言えません。
このようにアジャイルでは開発の途中段階において顧客側に品質確保のための負荷をかけることになりますが、顧客はこうした負担よりも変化への対応を望んでいる（のではないか）と言いたかったのです。
まりも
>ここからは国語の話です。
マネージャー層をやっている方が技術者と話すときには、
国語の話に持ち込んで話をそらして、
うやむやにすることが大変多いように思えますが。
マネージャーのマニュアルにでもそうが書いてあるのですか？
あまり関心はできない態度ですね。
>なぜはじめから「比較的」をつけなかったのでしょうか。、
あなたの元の文が
>顧客が品質や堅牢性よりも変化への対応
これですから、「よりも」と書いてあるので、最初から比較の話ですよ。
むしろこの話の流れで比較じゃないと解釈したあなたの国語力は、
どうなっているのですかね。
まあ国語力の話はどうでもいいですが。
>ここからは工学論です。
論にの何もなってない。
>ウォーターフォールだと検査工程を経て開発側で可能な限り故障率を減らした状態で顧客へのリリースが行われます。
アジャイルでもそうです。なので論になってないですね。
ペアプログラミングとかTDDとか聞いたことはないですか？
勉強すればわかりますが、その二つはウォーターフォールで行われていた品質確保の方法を発展させたものですよ。
ウォーターフォールで検査される品質のみが品質であると定義するのならば、
アジャイルの検査方法は品質を保証しないという結論になるでしょうが。
ウォーターフォールで行われる品質確保が正しいと定義するからウォーターフォールでしか品質確保はできないんだ、
というのではトートロジーにすぎず、何も言っていませんよ。
正しいから正しいんだ、じゃなにもなりません。
きちんと理由を言ってください。
工学論とか言うならそれからでしょう。
玄米茶
>アジャイルでもそうです。なので論になってないですね。
主観を排除して議論を進めようというただそれだけの主旨だったのですが、まぁ大げさな印象を与えてしまったかもしれませんね。
まりもさんのコメントは主観や相手への批判・皮肉にまみれていて、ご自身の論述展開がほとんどないんですよね。
人に説明を求める前に、まずはご自身が自分の言葉で論を述べられてみてはいかがでしょうか。
同規模のプログラムであれば、単純に数学的に一般論的に、コードの開発量（修正量）、検査工数、リリース回数の比較によって故障率の差を推測できるよね、というだけの話なんですけどもね。
念のため言いますが、アジャイルでは品質が保証されないと言っているのではありませんよ。
あえて比較すれば故障率が上がる可能性はあるよねと言っているだけです。
>ペアプログラミングとかTDDとか聞いたことはないですか？
TDDが保証できるのはせいぜい単体テストの範囲、コードベースのガバレッジくらいなのではないでしょうか。
機能の網羅性・正当性いわゆる仕様誤りの部分や自動化の難しいもの、例えばマルチスレッディングな箇所の検証などではどうしてもTDD以外のところに頼るしかないのではと思いますよ。
またTDDそのものにはテスト項目の妥当性・網羅性を保証する仕組みはなく、「可能な限り故障率を減らした状態」の証明には不十分なのではないかと思います。
本文中でも触れていますが、どちらかというとレベルダウン検証の自動化、つまり変更への適応性という役割の方が強い気がします。
あと、ペアプロが効果があるのはわかるんですが、それによってどれくらい品質を確保したかを数値化したり分析したりするのが難しくないですかね。
「可能な限り故障率を減らした状態」の証明にペアプロって使えます？
どちらかというと生産性向上の役割の方が強い気がします。
誤解があるように思うのは、私がアジャイルの批判者であるかのように思われているのかなというところです。
実際、私は現在いくつかのアジャイル的なプラクティスを導入した開発をしていますし、厳格なウォーターフォールに戻るのはこりごりだと思っていますよ。
ただアジャイルも万能というわけではないので、長短含めて受け入れることをしないとアジャイル信者だと言われかねませんよね。
まりもさんはアジャイルに精通なさっているようですので、もし良かったらご自身のプロジェクトにおいてどのような品質保証への取り組みをしておられるのかお伺いしたいところです。
まりも
>まずはご自身が自分の言葉で論を述べられてみてはいかがでしょうか。
いや私は、あなたがアジャイルについて基本的な事実誤認をしているため、
あなたの意見が論になっていない、と指摘しているのですが。
私が論を述べた時点で、それと矛盾してしまいますよ。
論ではない事実誤認に対して論で反論をすることはできませんから。
自己矛盾することは言えませんね。
>単純に数学的に一般論的に、コードの開発量（修正量）、検査工数、リリース回数の比較によって故障率の差を推測できるよね、
似たような開発手法ならそうですね。
開発手法が変われば、その三つ以外の条件が変わり過ぎますし、
そもそもその３つの測定方法も変えざるを得ないわけですが。
なぜ、その三つだけで推測できると思ったんですか？
>TDDが保証できるのはせいぜい単体テストの範囲、コードベースのガバレッジくらいなのではないでしょうか。
そうですが、それがどうかしましたか？
別に他のテスト方法と併用してはいけない、とは誰もいっていないのですが。
単体テストの範囲で、自然なプロセスで品質が大幅に向上すれば、全体の品質も向上するでしょう。
>例えばマルチスレッディングな箇所の検証などではどうしてもTDD以外のところに頼るしかないのではと思いますよ。
手動でマルチスレッディング周りの完全な検証ができるとは知りませんでしたが、そういう手順があるんですか？
あるのならその手順をスクリプトで書けば自動化もできますね。
>「可能な限り故障率を減らした状態」の証明にペアプロって使えます？
使えませんが、それはウォーターフォールでも同じでしょう。
「可能な限り」をウォーターフォールの手順で再定義しているから、
できるように見えているだけです。
再定義していいならペアプログラミングだってできますよ？
レビューしたコード率で測定すれば最高となりますね。300％くらいにはなるかな。
工学の話をするなら、「測定」が何を測っているのかを認識したほうがいいと思います。
数値化というのは事実の一面しか切り取れないものです。
一面でも切り取ることによって得られるものは確かにありますが、それがすべてではない。
アジャイルでは、だからあえて数値化はしないという選択をすることが多いようですね。
正確な測定が難しい局面で測定することは、意味のない数字に振り回されることになるか、莫大な測定工数を必要とするか、どちらかですから。
まりも
>誤解があるように思うのは、私がアジャイルの批判者であるかのように思われているのかなというところです。
そうだと自覚していないであろうことは、文章から読み取れますが、
実際やっていることはアジャイルの批判者と同じだと思いますよ。
玄米茶
返事が遅れてしまいました。
色々考えていたのですが、よくわからなくなってしまったもので。
おそらく「可能な限り故障率を減らした状態」という言葉がよくなかったんだと思います。
>顧客側で発覚する故障件数はウォーターフォールよりも多くなることが予想される
この意見に異を唱えるのであれば、純粋に両者の比較論をすればいいだけだと思います。
もしそうであれば、この件について次回のコラムで書こうと思います。
運が良ければ他の識者の方からのコメントをもらえるかもしれません。
コラムに対するまりもさんのご感想については、今後の執筆にあたって参考にしたいと思います。
まりも
論旨が散らかってわかりにくくなったかと思い、なるべく短く要点をいうと。
工学的に測定を考えるのならば。
測定方法は適切であるのか。
測定方法の前提条件は何なのか。
は常に考えておかねばならないはず。
ということです。
あなたが多少なりともそういうことを考えていると想定するならば、
ウォーターフォール開発どうしを比べるための測定方法を、
そのままウォーターフォール開発とアジャイル開発間に適用するというのは、
アジャイルによほど悪意があるとしか思えませんでした。
多少なりともすら考えていなかった、という可能性について、今は検討していますが。
ｄｄ
私の経験では基本的にアジャイルは開発者によって都合の良い開発手法です。
確かに正しくアジャイルを適応の出来れば開発速度は上がります
しっかりとスプリントを全てをフェーズを無視することなく開発すればとても素晴らしい開発プロセスです。ただしアジャイルを理由にして上流工程が終わらない内から開発が始まる現場等あるので上流工程を担当する人にとってはものすごくやりにくい開発手法です。開発者しか楽しくないです。
因みに開発者育成は数年で行えますが、上流工程を正しく行える人材を育てるのは時間が掛かります。
然し、現実問題、アジャイルを適応する開発現場では発生する問題は色々あります。
一番最悪だった現場では要件定義、基礎設計、詳細設計、単体テスト、統合テスト、スケジュール、スコープのフェーズは意味が無いとされてました。
アジャイル開発が正しく適応されないとメンテナンス出来ないコードが容易に作成できます。