コンピュータ技術者のための無料情報倉庫です

ソフトウェア設計者向け情報

2.アジャイル宣言
・・・「アジャイルソフトウェア開発宣言」(Manifesto for Agile Software Development)・・・

　2001年、17人の高名なソフトウェア開発技術者達によって「アジャイル宣言」が出されました。 DoDによるソフトウェア開発の効率調査に対し、当時の高名な技術者がその不効率の原因と解消策を公言したものと考えております。
　アジャイル開発は、多くの「反復型：IID（iterative and incremental development）」開発手法、「OOD」開発手法と並んで、世界中で認知されています。 日本では、ソフトウェア工学の分野で、迅速かつ適応的にソフトウェア開発を行う「軽量な開発手法」群の総称として定義されることが多いようです。 （ヤコブソンが最近の日本講演で、オブジェクト指向は「手間と時間がかかります」と解説されたのは、日本での考え方を暗に批判されたものかもしれません。）

【著者所見】
　アジャイルSD・IID・OODの3通りの呼び方は、現在でも混乱している（確定していない）と思われます。 （関連項目を記述する都度、参考として、考察を述べます。） 本稿においては、三通りの呼称には細かな相違はありますが、ほぼ同じ要旨であるとご了解ください。
　著者がリーダを務めた開発事例として、 「アジャイルなOOD技法（スクラム、エクストリームプログラミング）」で、かなりの回数、開発いたしました。 ほとんど全ての事例で、発注者から時間と工数を削減することを義務として要求されたのです。 アジャイルに開発する「目的」はシステム開発の成功であって、コスト削減はあくまで望ましい「結果」であり、保障の範囲外なのです。

　この、アジャイル宣言に間に合うように、前述のスリーアミーゴたちは、システム開発（設計）用の世界共通言語の開発に挑みます。 結果として、UMLパートナーズという国際コンソーシアムが1996年に結成されました。 統一モデリング言語（Unified Modeling Language、UML）仕様が作成・提案されたのです。 UML 1.0 仕様ドラフト版が1997年1月に、UML 1.1 として1997年8月に、OMG（Object Management Group：コンピュータ業界の非営利の標準化コンソーシアム）へ提出されています。 （UMLは、現在、OMGが管理しています。ISO/IEC 19501:2005 としてUML1.4.2 、ISO/IEC 19505-1:2012として UML 2.4.1 が標準化登録されています。）
UMLの内容については、後稿で解説いたします。

2-1.「アジャイルソフトウェア開発宣言」

　2001年に発表されました。（日本においては、2010年に正式に訳文が公表されています。）

【アジャイルアライアンス宣言の日本語訳全文】
「宣言文」
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck、Mike Beedle、Arie van Bennekum、Alistair Cockburn、Ward Cunningham、 Martin Fowler、James Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、 Jon Kern、Brian Marick、Robert C. Martin、Steve Mellor、Ken Schwaber、 Jeff Sutherland、Dave Thomas Copyright 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
「宣言文の終わり」

DoDでは、オブジェクト指向開発の総称として、IID（iterative and incremental development、反復型開発と訳します。）が推奨され、やがて、標準開発方式へとなっていきました。 民間においても、2001年にはアジャイル宣言が出され、オブジェクト指向開発が一般的な開発技法として認知され始めたのです。

【著者所見】
アジャイルとオブジェクト指向はほとんど同じ意味で使われることが多いようです。 正確には、オブジェクト指向開発とアジャイル開発とは異なる部分があると考えられます。
著者は、1999年に初めてオブジェクト指向設計を手がけて以来、ほとんどの開発業務はオブジェクト指向開発でした。 しかしながら、日本でアジャイル宣言が受け入れられた（日本語版が公表された）のは2010年になってからです。
日本のアジャイル開発とオブジェクト指向開発の理解や普及は、諸外国に比べて、10年遅れているのかもしれません。

　以下の資料は、著者が、2003年までに発表されている研究成果をまとめてみたものです。 （注：過去、何度か資料を小規模に公開しています。以下は2014年版としてお読みください。 所見は、多くの論文の中から、あるいは、ピンボックの記載事項から、また、小職がPM/PLやPMOを務めたさいの感想を加味しています。）
アジャイルソフトウェア開発宣言は、「ソフトウェア開発技術者は、ソフトウェア開発の実践、もしくは、実践を手助けする活動を通じて、よりよい開発方法を見つけだそうとしている。」と主張するものです。 具体的には4つのテーマをかかげており、これに対して多くの研究結果が2003年時点で発表されていました。
以下、著者が開発活動で恩恵を受けた研究結果を4つのテーマ別に述べてまいります。

【参考情報】
アジャイルモデリング(AM)公式サイト
「http://www.ogis-ri.co.jp/otc/swec/process/am-res/am/」
モデリング成果物：アジャイルモデルのエッセンス: アジャイルに作れる成果物
by Scott W. Ambler, Copyright 2003

2-2.テーマ１．プロセスやツールよりも個人と対話に、より価値をおく

　ここでいうプロセスとは、主に統一プロセス（Unified Process、UPと略します）をフレームワークとした開発を示しているようです。 具体的には、レイショナル（現在は、IBM社のホームページを参照してください：以下同様）、ルキナ（現日本ユニシス）、テラソルナ（現NTTデータ）などがあげられます。 ツールは、これらのUP用の管理/開発ツールやUML用の記述ツールであると推定します。 これらのプロセスやツールは非常に便利なものです。 たとえば、同じ設計書を小職が記述した場合、ツール無しでエクセルなどへ書き込むと、数倍から十数倍の時間がかかります。
しかし、アジャイル宣言では、「個人と対話」がさらに重要であると主張しています。 プロジェクトを成功に導くために必要なものと研究された結果は以下のとおりです。
(1) 必要とする知識や経験を有する「技術者」を集めること。
　（費用はかかりますが一番の重要事項です。）
(2) やる気のある技術者をグループリーダにすること。
　（経験や知識、肩書や年齢では仕事はスムーズに進まないものです。）
(3) ユーザと技術者、および、技術者同士で対話をすること。
　（コミュニケーションは完成へ向けて必須です。）

→参考1
　コミュニケーションの方法として有名なのがスクラムミィーティングです。 今日、オブジェクト指向開発の多くのプロジェクトでは、毎日、開発メンバー（と顧客）が「立ったまま」予定や進捗を相互に連絡するのが一般的です。 （10年まえ頃は会議室を多用していましたが、近年、オフィス内にホワイトボードを置いてミーティングする光景が増えてきました。）
＊スクラムミーティングの基本ルール、
(1) 資料は、事前配布する。（会議中の配布はしない。）
(2) 議事はホワイトボードへ記録し、写しを全員に配布する。（議事録・メモは全員で共有する。）
(3) 全員が発言する。（前回からの「経過報告」と会議後の「予定」を発表する。）
(4) 原則、全員が立って行う。（居眠りと個人演説の予防・・？）

2-3.テーマ２．包括的なドキュメントよりも動くソフトウェアに、より価値をおく

　 システム開発におけるドキュメントは重要です。 一般に、ソフトウェア開発に係わるドキュメントは２つの種類に分類することが可能です。
ひとつは、システムの内容を記述する「仕様書」であり、もう一つはシステムを作成するための「設計書」です。 このドキュメントが「現状」を正しく反映していなければ、システムは正しく作成・維持管理することが「困難」になります。 しかし、アジャイル宣言では「動くソフトウェア」がさらに重要であると主張しています。
ドキュメントを構成するのは情報（ビット）の集まりです。 ビットとは、「系のエントロピーの尺度」であり、エントロピーは常に増大するのです。 つまり、法律・会計原則に修正があったり、システムの要件が変化したりすることを示しています。 したがって、設計書に忠実であることよりも、「変化に対応した：実際に使える」システムであることを重視するべきと主張します。
（エントロピーとは、古くは熱力学の第二法則、1974年ごろにホーキング博士らによって再確認されました。 なんと、ブラックホールでも成り立つそうです。 ドキュメントを構成する情報も古くなるのは避けては通れないですね。）
ドキュメント作りにばかりに「注力」していると、出来上がるころには過去の遺物となっており、有効に働かないシステムを作成してしまう可能性が存在します。

→参考2
　2000年当時、DoDが統計をとったシステム開発の成功率は75％程度であったと記憶しています。 （文献：資料を紛失してしまいました、ご存じの方はご教授ください。）
ドキュメントがしっかり作成してあれば、ユーザの承認済ドキュメントに対して忠実であることが重要で、 実際には有効に動かないシステムでも納品してしまう習慣（もしくは契約）が横行していました。
残念ながら、日本では、現在でも、しばしば見かける光景かもしれません。 動かないシステム構築というのは、存在自体に疑問があると考えておりますが、最終的には「法律」分野の問題なのでしょうか。

2-4.テーマ３．契約交渉よりも顧客との協調に、より価値をおく

　システム開発は、契約とともに開始されます。 したがって、契約をかわす行為は、非常に重要なイベントになるのです。 しかし、ここでは、契約締結後も継続して「実際にシステムを使用するユーザ」とコミュニケーションをとり続ける重要性を強調しています。 システム開発おける最大のトラブルは「顧客の意図したシステム」ではないものが完成してしまうことです。 これは、エンドユーザと開発者の意識のズレに起因するもので、このことがスケジュールの遅延や開発コスト収支の低下を誘発します。 最悪の場合には「動かないシステム」ができあがってしまいますが、この事態を回避するには、エンドユーザに開発作業へ参加していただくのが重要です。 会議だけではなく、エンドユーザが実際の成果物を見ることによって、双方が内容（成果物）を確認していくプロセスが重要であることを示しています。

→参考3
アジャイル・IID・OODと分類される手法の多くで、ユーザに、開発作業へ参加していただき、開発内容を確認・評価をお願いします。
有名な例として、エクストリームプログラミング技法の定義では毎日、スクラム技法では毎週ユーザ確認を実施します。 （ただし、小規模かつ全面的なユーザ確認はしないOODやIIDがあると考えている技術者もいます。）
今後の研究が待たれるテーマとして、かなり重要と考えるべきでしょう。 本稿では、設計時の定義に向けて考察を展開しますので、ユーザ参加の議論からは外れていく予定です。（あしからず）

→参考4
エンドユーザは開発の成果物を見ると、しばしば、「そうではなくて・・」と否定します。 （もちろん、コミュニケーションが良くとれている場合を除きます。） この後に続く、設計文章にできなかった「本音」が重要なのです。 小職も、PL・GLとして何度も「本音の収集」を実践し、重要性を実感しました。

2-5.テーマ４．計画に従うことよりも変化への対応に、より価値をおく

　オブジェクト指向開発が旧来の線表型開発手法と最も異なる点です。
「動くソフトウェア」の項で触れましたが、情報はエントロピーなので、常に増大し変化します。 ここでは、仕様（要求事項、設計）は常に変化していくものと認識し、変化した仕様に対して素早く対応していくことが重要であるとしています。
プロジェクトによっては、PLの最重要業務は、毎週、開発スケジュールを修正していくことになります。 （余談ですが、数年前月曜日の朝9時にスケジュール会議のあるプロジェクトでPLをいたしました。 当然、土曜日と日曜日は多忙で・・・運動不足でしっかり太ってしまいました。） しかしながら、オブジェクト指向開発を謳いながらも「確定仕様の変更はしない」といった奇妙なプロジェクトが、実際に、存在していることも事実なのです。 確定した仕様も時間の経過とともに古くなった場合は、計画から乖離する変化に対応していくことがより重要であると主張しています。

→参考5
　小職は、金融機関の業務システムが開発の初仕事でした。 30年以上前ですが、次々と新商品が登場するため「スパイラル開発」の手法がとられていました。 開発は人が変わっても、継続され続けて、常に「追加・変更仕様」が存在していました。 当時最先端であった金融機関のSEにとっては、仕様が確定するという表現が理解できなかったのです。
したがって、アジャイル宣言の内容は「当たり前の事項」として考えていました。 15年前にソフトウェアハウスへ移籍して、悪しき「仕様確定」の意味を理解し驚愕いたしました。

【著者所見】
アジャイル宣言の内容は、当時DoDにおいても標準開発方式であった「ウォーターフォール型」への反発であったとも考えられます。
もともと小規模開発用の考え方であった「ウォーターフォール型」を大規模システム開発にまで使用したことが発端と想像されます。

→参考6
ウォーターフォール型の開発手順
1.最初に、開発仕様を確定します。
2.開発仕様に基づき、システムを作成します。
3.出来上がったシステムを試験し、リリースします。
手順をイテレーションとして、2回繰り返すのが最大です。 ここでは、短期間で終了する小規模開発を前提としているため、仕様の変更に関する概念は入っていません。 非常に効率的で「優れた」開発手法なのですが、開発期間が数か月以上に亘る大規模開発では、時間の経過に伴う問題が発生してしまいます。
誠に残念なことですが、日本の大規模開発はこの小規模用手法を、依然として、使用している場合が散見されるようです。

アジャイル宣言-以上

お問い合わせについて

▲ページトップに戻る