アジャイル開発手法(Agile Development)とは？

実は未だによく分かっていない。
まず、反復型開発手法(IID: Iterative and Incremental Development)との違いが分からない。
Wikipedia を見ると、リリースの期間単位がアジャイルは数週間なのに対して IID は数ヶ月単位とあるが、

• アジャイルソフトウェア開発 - Wikipedia

「イテレーションが一ヶ月を超えているので、この開発手法は IID です」と言えるのだろうか？


大きく異なるのは、まずはアジャイル開発手法が「4つの価値」と「12の原則」を謳っている点あたりか。

• 4つの価値：アジャイルソフトウェア開発宣言
• 12の原則：アジャイル宣言の背後にある原則

細かいツッコミだが、この「12の原則」の一つに「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」とあるので、イテレーション期間の長さでアジャイル開発手法か IID かを区別することはできないみたいだ。
ともかく、この良い意味で宗教的な所がアジャイル開発手法と IID の違いなんだろうと、ひとまず勝手に決めつけておく。


以下、気になった記事・論文を引用・マーク・コメントしておく。

• IT Japan Award 2009 - 要件未定でも納期は厳守 “アジャイル開発”で乗り切る：ITpro (2009/7/15)

（後で書く。）

• 「アジャイル開発」って何がいいの？--アジャイル開発を実案件に生かすための基礎知識 - ZDNet Japan (2011/5/25)

コストに関しては、アジャイル開発の場合、どの程度の変更までを許容するのかといった見積りが難しいという面もあります。
　：
「発注者（顧客）のほうが受注者（開発側）より立場が上」という感覚が必要以上に強く刷り込まれている企業の間では、
この図式が崩れることを嫌がる発注者と受注者が多いこともまた事実です。
コミュニケーションが苦手な技術者であればアジャイル開発を苦痛に感じることもあるでしょう。
　：
短い期間でひと通り動くソフトウェアを作り上げるには、1人でソフトウェア開発のすべての工程をこなせるスキルをもった技術者が必要です。
ある程度以上のスキルをもった技術者でプロジェクトチームを構成してこそ、アジャイル開発は成り立つのです。
　：
アジャイル開発という手法は、開発側に対しても顧客に対しても能動的な姿勢を求めていることがわかると思います。

• アジャイル開発はなぜ難しい？--アジャイル開発を実案件に生かすための基礎知識（2） - ZDNet Japan (2011/6/1)

大企業の場合、ウォーターフォール型を前提とするソフトウェア開発のプロセスが社内標準として規定されていることが多く、それとは整合しないアジャイル開発は社内規定に引っ掛かってしまうのです。
　：
「顧客からの仕様変更要求に際限なく応えるのがアジャイル開発」と誤解している人々も多いようです。
　：
問題の本質は、プロジェクト開始時に工数確定が難しいアジャイル開発に、現在ソフトウェア開発案件で契約の主流となっている一括請負契約がそぐわないという点で、これがアジャイル開発普及の大きな障壁となっています。
　：
ソフトウェア開発に限らず、日本では「お客様は神様」という言葉に代表されるように、顧客はサービスの提供者より立場が上という考え方が広く浸透しています。
これは「顧客と開発者は対等なパートナー」という意識が強い欧米の商習慣と大きく異なります。
アジャイル開発は、顧客と開発者の密で対等なコミュニケーションを基本としています。
　：
仮に双方が対等な立場で連携しながらシステムが出来上がったとしましょう。
このシステムに不具合が生じたとき、一体どちらが責任を取るべきなのでしょうか。
　：
開発における責任分岐点がはっきりしないということも、アジャイル開発におけるビジネス上の課題として指摘されやすい傾向にあります。
　：
可能であればチームのリーダー的存在（もしくは補佐役）には、過去にアジャイル開発の経験がある人材を配置することをお勧めします。

• ：日本経済新聞 (2011/6/1)

「できました、使ってください」では駄目なんだと分かった。
　：
「どう作るか」ではなく、「なぜ必要か、何を実現したいのか」を念頭に置き開発していくことが必要であると感じた。

個人的にアジャイル開発手法を試したことはないが、その手法に則って作業を進められる人は限られているという印象を受ける。
しかも、何度もイテレーションを繰り返して初めて手法が身に付くように思える。
そのため、開発経験が浅かったりコミュニケーションが苦手な人にとって、アジャイル開発手法は敷居が高い気がする。
しかしながら一方で、コミュニケーションが不得意な開発者というのは少なくないと思うので、今後、この手法が普及していくためには、
開発経験はあるけどコミュニケーション能力は高くない人をどのように取り込んで順応させていくのかが意外と重要なんじゃないだろうか？と思う。


2011/6/19 追記：
･･･などと思っていたら、以前このような記事を目にしていたのを思い出した。

• アジャイルはなぜ失敗するのか？～教科書には載っていない反復型開発の3つの掟: プログラマの思索 (2010/10/9)

2011/6/28 追記：

• Linear models vs Agile models : Making the right model decision
  • 長岡技術科学大学の Aline U. HAKIZABERA さんと Koichi YAMADA さんが発表された論文。
  • 下記の表や図で描かれている各手法の分類・選択の仕方が分かりやすい。
    • Table 1: Features of Linear approach models
    • Table 2: Features of Agile approach models
    • Figure 1: From Linear to Extreme model
    • Figure 2: Decision Process

2011/7/18 追記：

• アジャイル開発を、人はどのようにして学ぶのか。アジャイルの第一人者、平鍋さんに聞いた － Publickey (2010/09/24)

世の中には誰かが見つけた再現性のある正しいことがどこかに書いてあり、それが自分の状況でもうまく機能すること、すなわち「サイエンス」という、形式知で伝えられるものがあり、その応用として「エンジニアリング」があり、そうでないもの（本で伝えられないもの）は暗黙知のまま経験知、実践知として人づてに伝える必要があるんです。
　：
「自分の状況に合わせて自分で考える」「まずやってみてから考える」「実践による知」「コンテクスト優先、ソリューションはあと」という考え方を重視しています。

補足：「アジャイル開発手法」でググルと、だいぶ上位にランクしていて焦った。けれども消すのも勿体ないし折角なので、今後、少しずつ付け足していこうと思う。

---