Pages

2014年2月2日日曜日

アジャイル・メソッドとロック・ミュージック

こんにちは、@wd0214です。

今回はアジャイルソフトウェア開発手法について書くことを試みます。

アジャイルの誕生


アジャイルは2000年ごろに生まれたと言われています。

90年代までのソフトウェア・デベロップメントは、予め決められた計画を遵守することで正しいソフトウェアが得られると考えられていました。しかし次第にソフトウェアのオープン化が進み、ビジネス要求の複雑化と要求スピードに対して、従来の開発手法では満足できるソフトウェアを得ることが困難になりました。

まずは作ってみないことには、目的とする事柄に合っているのか、またステークホルダーの要求を満たすソフトウェアなのかどうかさえわからないのです。

筆者は1999年の大晦日、KDD新宿本社ビルで2000年対応のため年越しで仕事をしていました。
「だいたい2000.1.1に問題が起こるなら、1999.9.9にすでに起こってるはずだよね。」
C言語のプログラマーならそんな愚痴でもこぼしつつ、万が一に備えて新年を迎えられた方も少なくなかったことでしょう。(結局何も起こらなかったけど

あれから14年程経ちますが、アジャイルはロック・ミュージックと同じくたいていは誤解されています。

考え方は至ってシンプルですが、習得するには非常に困難で、正しい理解と継続的な開発現場での実践が必要です。アスリートが日々自身の身体をチェックし、鍛錬するごとく真摯にエンジニアリングに向かわなければ、本質的に習得することは難しいと思われます。

ニワトリとブタ


アジャイルでは次のような「ニワトリとブタ」の寓話が有名です。


ニワトリとブタがいた。ニワトリは「さあ、レストランでもやろうよ」と言った。ブタはよく考えてから「レストランのメニューは何にしようか」と言った。ニワトリは答えた。「ハム・エッグさ」。ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」

これは、デイリースクラムミーティング(朝会)での参加や発言権について「傍観者としてのニワトリは必要ない」ということへの理解のための喩え話で、シュエイバー・ビードル共著の「アジャイルソフトウェア開発スクラム」(ピアソン・エデュケーション)で紹介されています。

アジャイルの本質


アジャイルはシンプル、ほとんどすべてがこれまでと異なっている

アジャイルの捉え方については、世界中で語り尽くせない様々な意見がありますが、一つ確かなことは

開発現場をよりよくするためには、必ず自分自身がソフトウェア開発をしなければならない

というところです。一番プロダクトを理解している人自身が開発(コーディング等)を行うことこそアジャイル(俊敏)という意味です。

あなたがエンジニアならなおさらですが、ご興味があれば、上記を踏まえた上で原則を読んでみましょう。

アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/

アジャイルソフトウェアの12の原則
http://agilemanifesto.org/iso/ja/principles.html

アジャイル・メソッド


アジャイルと呼ばれるメソッドは下記が有名です。すべてのメソッドは各々異なるチャレンジを持っています。

• エクストリーム・プログラミング(XP)
• スクラム(Scrum)
• ラショラム統一プロセス(RUP)
• リーン・ソフトウェア開発(LSD)
• ダイナミックシステム開発メソッド (DSDM)
• フィーチャ駆動型開発(FDD)
• etc...

あなたならどちらのチームに仕事を依頼しますか?


あなたがプロダクトをビジネスにしたいと考えた時、
「あなたならどちらのチームに仕事を依頼しますか?」

*ウォーターフォール(従来のやりかた)
 大量のドキュメントを納品し、依頼したソフトウェアは最後まで秘密とされるチーム

 *アジャイル
 お客様が一番大事だと考えている順に機能を実装してテスト済みで毎週必ず届けてくれるチーム


  北アメリカとヨーロッパでは企業の14%がアジャイルを採用しており、19%は興味を持っているかすでに計画を立てているようです。

  ▼アジャイルを採用している企業調査(なぜアジャイルを採用したか?)

  1.生産性とタイムツーマーケット(66%)
  2.コスト削減(48%)
  3.品質向上(43%)
 [ForresterResearch,2005] ←古くてスミマセン

  アジャイルへの動機は、これまで同様、ソフトウェアをより早く、より良く、より安く開発することに加え、さらに、高い生産性、高い士気を生み出すことができます。


管理者層に対する最も重要な哲学


例えば、スクラムには「プロジェクトマネジャー」の役割はありません。

アジャイルではリーダーシップとマネジメントは全く異なったものと捉えており、これまでソフトウェアエンジニアに指示をして開発をすすめていた管理職の方は、アジャイルを導入する際にまずこの部分でつまづくと思われます。前述したように自身でソフトウェア開発をしないスタッフはスクラムチームのメンバーに入ることは(原則では)できません。

その意味で、アジャイル、スクラムの価値、原則、プラクティス (管理者層に対する最も重要な哲学)は、

• ビジョンとチャレンジをチームに与えるが、チームが目的を達成するための具体的なステップを与える訳ではない

• 「ここに私たちの欲しいものがある、どうやってそれを成し遂げるかは自分でみつけてくれ」というアプローチ

• 自己組織的なプロジェクトチーム

• 信頼こそがコラボレーションの基礎であり、個々の約束を果たすことが信頼関係を構築する基本である

深く、いいですね。今回はここまでにします。

アジャイルとロック・ミュージック


ロックってほんと最高ですよね。
アジャイルが生まれた頃のロック・ミュージックを一曲紹介します。



やっぱかっこいいですね。

筆者は世の中で一番かっこいいのはバンドマンだと思います。
Bobbyみたいにガリガリにダイエットして、熱唱していきたいところです。

本当に好きなことをやるのが一番、それが一番アジャイルな人生だと思います。

次回からは一つ一つ、アジャイル・メソッドを紹介していきたいと思います。