同僚の協力もあり 2002 年にアジャイルモデリング ( AM ) 日本語リソースサイト [1] を開設し, 2003 年に AM 本 [2] を刊行して以降, 筆者にとって「 AM の適用事例を作る 」ことが大きな課題として残されていました. 幸いにも, 2003 年から社内開発でアジャイルなソフトウェア開発を適用する機会を得るとともに, 2004 年にはお客様からアジャイルなソフトウェア開発のプロジェクトのお手伝いを依頼されたり, 社内開発で AM を実践する機会を得ることができました.
読者の皆さんが AM を学ぶ際の参考となることを目指して, 今回から数回の連載で AM を実践するために筆者が勉強したり, 考えたり, 実践したことを紹介させて頂こうと考えています. とりあえず, 今回は AM の土台となるアジャイルなソフトウェア開発について説明します.
1. アジャイルなソフトウェア開発とは
アジャイル (agile) とは, 英語で「機敏な」という意味の言葉であり, アジャイルなソフトウェア開発とは, 機敏にソフトウェア開発を行うことを意味します. それに対して, アジャイル開発手法とはアジャイルなソフトウェア開発を実践するための価値, 原則, プラクティスなどの指針を提供するものです. 近年日本で話題になっているXP ( eXtreme Programming ) [3] は, このようなアジャイル開発手法の最も有名な具体例です. アジャイル開発手法は, XP だけに留まらずスクラム [4], DSDM (Dynamic Systems Development Method) [5] , 適応型ソフトウェア開発 [6], Crystal Clear [7] などの複数の方法論から構成されています. 2001 年初頭からこれらの複数の方法論者がアジャイル・アライアンス ( Agile Alliance ) [8] の名の元に集まり, ソフトウェア開発の新しいスタイルを提案する一つの大きな流れを形成してきています.
これらのアジャイル開発手法は, 開発プロセスの観点では 80 年代に提案された発展的プロトタイピングやスパイラルなソフトウェア・ライフサイクルの流れを汲んだ反復型開発手法の 1 種と見なすことができます.
すなわち, 図 1 に示されるように反復 ( iteration ) と呼ばれる一定の期間内に要求, 設計, 実装, テストなどを行い, 動くソフトウェアを作り上げ, そのソフトウェアを評価することによりフィードバックを得ながら開発を進めるやり方です.
このような開発の進め方を行うことにより, 動くソフトウェアを用いて顧客のフィードバックを得たり, 性能などの点でリスクが高そうなソフトウェア部分を実際に動作させて本当に深刻な問題を発生しうるか現物（部分実装の場合多い）で評価することができます. すなわち, 顧客ニーズにより即したソフトウェアをより安全に開発することを可能にすることを目指した開発手法だと言えます.
このように一定の期間で短期目標を立案, 実行し, その目標の達成度や達成できなった理由を分析し, 次のサイクルにフィードバックする作業の進め方はソフトウェア開発以外の分野において日本で一般的な PDCA ( Plan Do Check Action ) サイクルと呼ばれる管理アプローチと類似しています. PDCAサイクルは, 業務目標を上司の指示ではなく, 自らの意思で決め, フィードバックをかける自己管理 ( 部下への信頼 ) に基づく管理アプローチです. アジャイルなソフトウェア開発では, 反復毎の目標は開発者と開発依頼者の話し合いにより決められますが, 基本的には開発依頼者の開発者への信頼があることが大きな前提になります.
2. アジャイル宣言
2001 年 2 月に XP , スクラム, DSDM などの 17 名の開発方法論者が集って, 自分達が目指すアジャイルなソフトウェア開発の価値を以下のようなアジャイル宣言 ( Agile Manifesto ) [9] としてまとめました.
- プロセスやツールよりも個人や相互作用
- 分かりやすいドキュメントよりも動くソフトウェア
- 契約上の駆け引きよりも顧客とのコラボレーション
- 計画を硬直的に守るよりも変化に対応する
アジャイルなソフトウェア開発では, これら価値において下線を引いてある右側の部分を左側の部分より重視するということが価値とされています.
同時に, この宣言を行った方法論者によりアジャイルなソフトウェア開発の概念を普及, 発展させるための NPO であるアジャイル・アライアンスが組織されたのです. アジャイル・アライアンスについて重要なのは, そのメンバーである複数の方法論者が価値観や原則について合意した結果として創立されたのであり, 各方法論を統一することを目指しているのではない点です. そのため, 各アジャイル開発手法では個別の価値, 原則, プラクティスが定義されています.
アジャイル宣言には, さらに以下のような原則が付随しており, この宣言が目指している方向性をより明確に示しています.
- ソフトウェアの早期,継続的な納品により, 顧客の満足を達成することが第１優先である.
- 開発の終盤であろうとも、要求内容の変更を歓迎する. アジャイルなプロセスは, 顧客の競争上の優位性のため, 変化を制する.
- 数週間から数ヶ月間のサイクルで動作するソフトウェアを納品する. サイクルは短い方が良い.
- ビジネス側の人間と開発者がプロジェクトを通じて日々協力をしなければならない.
- 志の高い開発者を中心にプロジェクトを編成する.必要な環境や支援を与え, 任務をやり遂げることを信じなさい.
- 開発チームの内外でもっとも効率的で、効果的な情報伝達を行う手段は, 顔をつき合わせて話し合うことである.
- 動作するソフトウェアが, 主たる進捗の確認手段である.
- アジャイルなソフトウェア開発は、持続的な開発を促す. 開発資金の提供者、開発者、ユーザは、必ず一定のペースを守れるべきである.
- 技術力と良い設計に絶えず気を配ることで、機敏さは向上する.
- 不必要なことを行わない技能である簡潔さは、本質的である.
- 自己組織化されたチームから最善のアーキテクチャ, 要求, 設計が生まれる.
- 定期的に、チームはもっと効果的になる道を考え、開発の進め方を調和させ, 調整する.
11.の自己組織化されたチームとは, 命令や指示に基づく縦割りの組織ではなく, チーム内での話し合いや自律的な判断に基づいて各人がなすべきこと行う組織を意味しています. このような自律的に行動する個人がチームで協調作業を行うことで, 変化への適応性が強くなるとされています. [6] には, 複雑系の科学の観点でこのような組織論が説明されています. このような組織論は, 次回の記事で説明する野中らの知識創造プロセス [10] にも通じます.
このような原則の内容を大別すると, 以下の 5 点に分類できます.
- チームのあり方: 5, 6, 8, 11, 12
- 個人の心構え: 9, 10
- 動くソフトウェア: 1, 3, 7
- 顧客とのコラボレーション: 4
- 変化への対応: 2
A と B は, アジャイルなソフトウェア開発の 4 つの価値である"個人や相互作用"を個人に関する原則とチームに関する原則に分解したものです. また, 1, 3, 7 の原則は反復型開発手法に関するものであり, "動くソフトウェア"の価値と対応すると考え, C に分類しました. さらに, D と E は顧客のニーズの変化に即応した開発を行うことであり, 顧客本位のソフトウェア開発を行うという方向性を示すものです.
これらの原則から, アジャイルなソフトウェア開発にとって"顧客のニーズの変化に即応した開発"が大きなテーマであり, A, B, C はその実現手段だということができます. すなわち, 顧客のニーズの変化に即応するためには, 一定の作業内容や作業手順に従うだけでは不十分であり, 機動性に富んだチームと個人の自律性が必要になるということです. また, アジャイルなソフトウェア開発はソフトウェア開発全般をターゲットにしたものではなく, "顧客のニーズの変化に即応した開発"に焦点を合わせたものであることを理解した方が良いと思います.
3. アジャイル開発手法の分類
アジャイル開発手法を個別に見た場合, 以下の 3 種類に分類できます.
- プロジェクト管理中心
- スクラム
- 適応型ソフトウェア開発
- より包括的な開発手法
- XP
- Crystal Clear
- モデリング中心
- アジャイルモデリング
本記事の冒頭で述べたようにアジャイル開発手法の範疇の中でもっとも有名な開発手法は XP です. XP は, 計画ゲームのように反復計画を立案する等プロジェクト管理に関わるプラクティス以外にテスト駆動型開発やペアプログラムなどテストやプログラミングなどにプロジェクト管理以外の開発作業をも含んだ包括的な開発手法です. それに対して, A の２つの方法論はプロジェクト管理的な作業やチーム運営などに特化したものです.
2 節で説明したようにアジャイルなソフトウェア開発の原則の多くはプロジェクト管理に関するものであり, スクラムや適応型ソフトウェア開発はそれらの原則のより具体的な適用イメージを理解するために参考になります. 本連載の次回の記事では, スクラムの概要と事例を紹介する予定ですので, その記事でより具体的なイメージを掴んで頂きたいと思います.
また, A の手法を適用する場合には, プロジェクト管理以外の開発作業についてB)の方法論を取り入れたり, 独自に定義することが必要になります. 本連載の第 3 回の記事では, スクラムのプロジェクト管理手法に XP のプラクティスをいくつか取り入れたアジャイル開発手法を構築し, 適用した事例を紹介する予定です.
B に挙がっている Crystal Clear は, Cockburn により提案された Crystal という開発手法ファミリーの一員です. Cockburn はプロジェクトの規模などに応じて成果物や作業などの構成を変えるべきだということを提案しており, Crystal は規模に応じた複数の手法から構成されています. Crystal Clear は, そのCrystal ファミリーの中で最軽量の開発手法です. Crystal Clear に関する書籍 [7] は 2004 年 に刊行されたばかりで普及はこれからですが, XP 以外の包括的な開発手法の選択肢として注目されます.
C に挙がっているアジャイルモデリング ( AM ) は, 機敏にモデリングを行うための価値, 原則, プラクティスを提案するものです. AM は, モデリングに特化しているため, A や B のアジャイル開発手法や統一プロセスと組み合わせる形で開発に適用されます. 他のアジャイル開発手法に AM を併用することにより, 開発者間や開発者と開発依頼者の間のコミュニケーションを強化したり, 開発上の問題点をより早く見つけたりすることが期待できます. そのため, 筆者は AM をアジャイルなソフトウェア開発をさらに効率化したり, 質を向上させるものだと考えています. 本連載の第 4 回目以降では, AM の価値, 原則, プラクティス及びアジャイルなモデルを紹介するとともに, 筆者らの実践結果を紹介しようと考えています.
4. アジャイル開発手法のプラクティス
2 節で説明したアジャイル宣言の価値や原則を尊重してソフトウェア開発を行うことがアジャイルなソフトウェア開発だということになります. しかながら, これらの価値や原則でアジャイルなソフトウェア開発のなんたるかをイメージするのは厳しいかもしれません. そのようなイメージを明確にするため, 筆者は原則を以下のように自分なりに要約しています.
- 1 週間から 1 ヶ月程度のサイクルの反復型開発
- 顧客と協調し, 変化に対応することによるサービスの質の向上
- 開発者の自律性, コミュニケーション, 改善を重視する開発組織
- 無駄なことを省く簡潔さや技術力を尊重する合理的な精神
このように要約し, 反復型開発手法を PDCA サイクルに置きかえてみると, このような事柄はソフトウェア業界以外の業界でも, 競争力のあるビジネス組織が目指しているものと共通するような気がしないでしょうか. 筆者は, かなり共通するものがあると感じています. しかしその一方で, 現実にはこのようなことを実践し, 成果を出せている組織は比較的少数であるような気がします. それは, 1 つにはこれらのイメージが目指している姿を示しているだけにすぎず, 各人の異なった現状から目指している姿にどのように至るかを示すものではないからです. すなわち, 日々の業務において何をどのように実践すれば良いか分からないのです. ソフトウェア開発で言えば, 日々の開発活動で何をどのように行ったらアジャイルなソフトウェア開発に至るかということが問われるのです. その答えは, 価値や原則を眺めていても得られません. 得られたら, あなたは開発方法論者として旗揚げできるでしょう.
でも, 安心してください. 日々の開発活動をどのように進めたら良いかという問いに対する答えを方法論者が考えた結果が各開発手法のプラクティスだからです. 基本的には, プラクティスを忠実に実践することで, アジャイルなソフトウェア開発のイメージに到達できるはずです. でも, "忠実に"というのがまず曲者です. "忠実に"ということは, 基本的にはプラクティスをすべて実践するということを意味します. 言い換えれば, 方法論者がそれらをすべて実践することでのみ, 従来の開発と異なるアジャイルなソフトウェア開発のイメージに到達できたということです. 部分的に実践しても, 効果のほどは保証されていないのです.
「 XP のプラクティスをすべていきなり実践できないよな 」というあなたにお勧めなのが, 3 節で言及したスクラムなどのプロジェクト管理中心のアジャイル開発手法です. これらの開発手法は XP と比べて実践が容易であり, しかも反復型開発, 自律性やコミュニケーションの重視などアジャイルなソフトウェア開発の基本を習得できる点が売りです.
5. 最後に
本記事では, アジャイル宣言の価値や原則を中心に, アジャイル開発手法の基本的な概念やプラクティスに関する筆者の考えを説明しました. 今回の記事ではアジャイル宣言の原則までしか説明しなかったので, アジャイル開発手法の具体的な実践イメージが湧きにくかったかもしれません. 次回は, 本記事で名前を紹介したスクラムというアジャイル開発手法の概要とその事例を紹介する予定です. 個別のアジャイル開発手法を知ることにより, アジャイル開発手法のより具体的イメージが掴めると思いますので, 乞うご期待ください.
参考文献
- [1] AM 日本語リソースサイト: https://www.ogis-ri.co.jp/otc/swec/process/am-res/am/
- [2] スコット・アンブラー: アジャイルモデリング - XPと統一プロセスを補完するプラクティス, 翔泳社, 2003
- [3] ケント・ベック: XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法, ピアソンエデュケーション, 2000
- [4] ケン・シュエイバー他: アジャイルソフトウェア開発スクラム, ピアソンエデュケーション, 2003
- [5] Stapleton, J.: Dynamic Systems Development Method, Addison Wesley, 1997
- [6] ジム・ハイスミス: 適応型ソフトウエア開発-変化とスピードに挑むプロジェクトマネージメント, 翔泳社, 2003
- [7] Alistair Cockburn: Crystal Clear: A Human-powered Methodology For Small Teams, Addison-Wesley, 2004
- [8] アジャイル・アライアンスのサイト: https://www.agilealliance.org/home/
- [9] アジャイル宣言: https://www.agilemanifesto.org/
- [10] 野中郁次郎, 竹内弘高: 知識創造企業, 東洋経済新聞社, 1996