読者です 読者をやめる 読者になる 読者になる

Dividing By Zero

ソフトウェアをはじめとする技術に関する備忘録と日々のメモ書き。

なぜアジャイルソフトウェア開発?

プログラミング

はじめに

 前回のNetOpsCoding#3 勉強会参加の記事の中でアジャイルソフトウェア開発、エクストリームプログラミングなどの単語が出たので、ここで説明しようと思う。

 アジャイルソフトウェア開発をただ、説明するのもアレなのでいつも通り「なぜ」それが必要になり、「どう」利用されるかを重点に書きたいと思う。ただ、今回の記事は「なぜ」の部分を中心とする。

ウォーターフォール型開発への批判

  もともとアジャイルソフトウェア開発は、ウォーターフォール型開発に対する批判から始まった。ウォーターフォール型に関して書かれたWikipediaの記事を見てみよう。

ウォーターフォールモデルは間違っており有害である。私たちはこのモデルから脱却しなければならない」 -Frederick P. Brooks Jr.-

ウォーターフォール・アプローチは,危険かつ問題をはらんだ,企業における風土病」 -McBreen,P.-

「秩序正しく、予測が可能で、説明が付きやすく、測定可能なプロセスであり、文書を中心とした単純なマイルストーンが存在するという幻想をウォーターフォールがあたえた」 -Larman,C.-

ウォーターフォール・モデル - Wikipedia

 酷い言われようである。なぜウォーターフォール型がこんなにも嫌われているかを見て行こう。

開発した45%の機能は一切使われない

 ウォータフォール型の開発では、初めにシステム全体の要件定義(顧客が解決してほしい問題を聞き、どんな機能を作るか)を決める。この要件で定義された機能のうち、いったいどれほどの機能が使われているのだろうか?

 以下の図はBig Requirements Up Front (最初にまとめて要件定義)で実装された機能がどれほど使用されているかという調査報告である。

f:id:na-777:20160711224402p:plain

Examining the "Big Requirements Up Front (BRUF) Approach"

  報告によると45%の機能が一切使われず、19%の機能が稀に使われるといった結果だ。つまりウォーターフォール型の開発では約半分の仕事は全く意味のない作業という事になる。

 顧客自身が自分の問題を把握していない、問題から必要な機能を絞れていない事もあるが、実際に物が出来て使ってみるまで分からないという事も影響してるだろう。

大規模伝言ゲーム

blog.imalive7799.com

 ウォータフォール型の開発では工程ごとに作業する人が異なる事が多い。[要件定義]を行う技術者、[設計]を行う技術者、[プログラミング]を行う技術者など様々だ。各技術者は単一の仕事の能力だけで済むというメリットも存在するが、デメリットも存在する。それはコミュニケーションの問題だ。例えば要件定義の工程を考えてみよう。

要件定義のある打ち合わせ例

  • 顧客:「○○の機能ですが前の打ち合わせでは5秒くらいの処理時間と言いましたがそれはあくまで理想で、10~15秒くらいでもそんなに問題ないです。」
  • 担当者A:(5秒の処理時間で終わるように実装しよう)
  • 担当者B:(5秒が理想だけど、10~15秒でもいいんだ)
  • 担当者C:(前に優先順位高くないって言ってたし10~15秒で)

 簡単な打ち合わせだけでも担当者ごとに理解が異なる場合もある。相互にチェックし、調整ができれば問題ないかもしれないが、抜け漏れというのは発生する。これが設計担当、プログラミング担当、テスト担当へと話が伝わる時にはどうなっているのだろうか?

f:id:na-777:20160712235121p:plain

顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科

 伝言ゲームを防ぐために行われるのは大量の資料作成だ。顧客が述べた要件を事細かく記述し、誰がどう読んでも理解に差が出ないようにするのだ。え?顧客が言った要件が間違っていたので資料に手直しが必要? もう設計担当に渡した後なんだけど。

書類の文字をコードに落とし込むとき

 なんだかんだで要件定義に関する書類が完成し、設計担当の手に渡った。設計担当はその情報をもとにプログラムの詳細を作っていく、操作画面はどんなデザインか、どういった画面の遷移をするのか、どういった情報が必要で、その情報はどういったやり方で入力、保存、処理、出力がされるのかといった様々なことを書く。ああそうだ、障害が起こった場合の対処、処理性能やセキュリティも・・・といったことを考慮しつつ(本当はもっと考慮すべき点があるが)、様々な資料を作る。よし時間がかかったが完成した。

f:id:na-777:20160816002234j:plain

アポロ誘導コンピュータ(AGC)のソースコードの隣に立つマーガレット・ハミルトン

 よし、プログラミング担当が設計書を元に作り始めた。これでひと段落だ。そう思っていた矢先にプログラミング担当から電話が入る。

 PG担当A:「ここの機能は、○○というやり方にしたほうが効率良くないですか?」

 PG担当B:「××って今回使用するプログラム言語の機能にありましたっけ?」

 なるほど、確かに○○はいい方法だ。そして××は言語の仕様を失念していた。書き直したほうがいいのだが、書き直してしまうと他のプログラミング担当に頼んだ部分も修正しなければ・・・だがもう他の担当は書き始めてしまっている。どうしよう・・・このまま進めるか。そして今度は要件定義担当からメールが来た。

 要件定義担当:「お客様の部長さんから、要件を追加しろとの話が・・・」

顧客の満足度

  現場は大混乱だ。仕様の変更、実装時に判明する考慮不足で資料の大量修正がかかる。下手をすれば、もう資料を残す余裕もないかもしれない。修正によって発生した遅延のツケはプログラム担当が支払う。それならばプログラム担当を増やせば大丈夫では・・・いや、後から入った担当者に関連資料や今作ってるプログラムの説明をしなければならない。どちらにせよ作業が遅れる。

  こういった状況で作り出されたプログラムは果たして顧客の問題を解決できるものなのだろうか。顧客はIT投資といった名目で予算を取る。投資と銘打ったからにはそのソフトウェアは初めに掲げた目標を達成し、投入した金額以上の効果を上げてくれるはずだと。これでは全員が不幸になる道以外残されていない。

エクストリームプログラミングの登場

  このままウォーターフォール型の開発を続けていても誰も幸せにならない。そういった中で登場したのがエクストリームプログラミングだ。

- eXtreme Programmingの魅力を探る エクストリーム・プログラミング - Wikipedia

 顧客の要件は常に変化する、重要なのは[コミュニケーション]、[シンプルさ]、[フィードバック]でありそれらを実践するための[尊重]や[勇気]である。そういった事柄から開発中にすべき良い経験則、習慣(ベストプラクティス)を示している。これにはアジャイルソフトウェア開発の骨子となるものが数多く含まれている。

 これらを実践すればより良い結果が*1・・・ん? でも待てよ。内容自体は確かにいいのだが、かなり面倒な作業もある。ルールにのっとって運用しないといけない部分もあるし、頻繁に同じような作業をしないといけない時もある。

そうだ、ソフトウェアをつかって自動化しよう。

 NetOpsCoding#3勉強会参加の記事の中で出てきた技術の元となる思想が幾つか存在する。こういった成り立ちを知ることで、自動化関連技術をより深く理解できるはずだ。

まとめ 

次の記事ではベストプラクティスの継続的インテグレーションについて解説しようと思う。

*1:今回ウォーターフォール型を批判し、アジャイル型のメリットなどを述べたが、もちろん一長一短の部分もある。アジャイルがすべての問題を解決してくれるものではない。