ほぼ 3 年ぶりの連載再開です. 3 年前に今回の原稿を書き始めた際にちょっと気負い過ぎて筆が止まり, 忙しさにかまけているうちにあっという間に 3 年間が経ってしまいました. この 3 年間で, 日本ではアジャイル開発への関心がやや停滞していますが, 米国では驚くほど盛り上がっており, 今やウォーターフォール型開発を凌ごうという勢いです. 今年の 9 月に WCSQ (World Congress for Software Quality) という会議でアジャイル開発での設計の実践経験について発表するという機会を頂き, とにかくその発表内容に至るまでに考え, 実践したことを記事に書こうと気を取り直しました.
今回の記事では, ウォーターフォール型開発におけるモデリングの問題点を説明し, さらにアジャイル開発でモデリングを取り入れる 2 つのアプローチを紹介します.
1. ウォーターフォール型開発アプローチにおけるモデリング
中規模以上の商業的な開発プロジェクトでは, 以下のような作業を実行することで従来開発を進めてきました.
- 要求：開発依頼者がソフトウェアに行って欲しいことを定義する
- 分析：要求を開発者が整理する
- 設計：要求の実現方法を定義する
- プログラミング：設計内容をプログラミングする
- テスト：作成されたソフトウェアが要求を満足するかを確認する
これらのプロジェクトの多くでは, 図 1 に示されるようにこれらの作業を順番に1回ずつ実行する「ウォーターフォール型開発アプローチ」を用いてきました.
このようなウォーターフォール型開発アプローチでは, 要求, 分析, 設計などの作業の作業結果を以下のような形で表現し, 次の作業に伝えます.
- テキスト
- 図
要求, 分析, 設計の内容を図で表現する記法の代表例としては, オブジェクトの広場の皆さんにお馴染みの UML (Unified Modeling Language) が挙げられます. UML は, 中規模以上の商業的なソフトウェア開発プロジェクトにおいて近年かなり普及してきました. しかし, すべてのソフトウェア開発プロジェクトで UML が使われているわけではなく, 要求,分析,設計の情報伝達の主な手段としてテキストが用いられているプロジェクトもまだまだ多いと思います. 本記事では, これら図やテキストで表現した要求,分析,設計の情報をソフトウェア開発のための「モデル」と呼びます.
ウォーターフォール型開発アプローチで分析や設計などのモデルを作る目的は, 要求内容の不明確な点や設計上の問題点をプログラミング以前に取り除くことです. 結果として, 多くの労力を必要とするプログラミングにおける試行錯誤や修正を減らせれば, 全体的な開発効率を向上させることができます. そのようなモデルを用いた問題発見を助けるために, モデルは必要な情報を網羅する精密なものが良いと考えられ, そのような精密なモデルをある程度の時間をかけて作ることが良いとされてきました.
一方, プログラミングに先駆けて要求や設計をモデリングするためには, 前の作業で集められた情報だけを頼りに概念やアイデアをモデリングする必要があります. しかし, そのような概念やアイデアのモデリングはプログラミングのように具体的な作業とは性格が異なり, 分析者やシステムエンジニアと呼ばれるような専門家が必要だと考えられてきました.
このようなウォーターフォール型開発におけるモデリングの考え方をまとめると, 以下のようになります.
- テキストや図に基づくモデルを使う（テキストが多い）
- 開発作業はモデルを受け渡して進行する
- モデルを作るのは専門家である
2. ウォーターフォール型開発の問題点
前節の説明で, ウォーターフォール型開発においてモデルを作成することが開発生産性の向上につながると思われたかもしれません. しかし, 現実はそう単純ではありません. モデルの作成が開発生産性の向上につながるためには, 以下のようにいくつかの前提となる条件があります.
- 要求を確定した後に, 開発依頼者の要求が大きく変わらないこと
- プログラミングで必要なことを設計段階で見通せること
A は, 開発依頼者の要求は開発初期に確定し, 開発中変わらないという仮定です. しかし, 実際には開発依頼者が作成されたソフトウェアの動作を見ることで, ソフトウェアに求めるべきことが明らかになり, 作成されたソフトウェアに対する大幅な修正や作り直しが発生することも多いでしょう. また, 開発中のビジネス状況の変化や開発技術の変化によって要求する内容が変わることもあります. 大幅な修正や作り直しをおこなうと, 結果的には納品の遅れや開発費用の超過を招きます. それでも, 開発依頼者の要求が開発システムの有用性に大きく関わるものである場合, そのような要求の変化に対応しないと開発されたシステムの価値とともにそれを開発した開発者の評価も下がることになります. 結局, ウォーターフォール型開発は要求が開発初期に確定されることを前提としており, このような要求の変化への対応は困難です.
B は, プログラミングで作るべきクラスの定義などを設計段階ですべて決められるという条件です. 現実的には, 以下の 2 点の理由ですべて決めることが困難だったり, 決めても無駄になったりすることが多いでしょう.
- なんらか未経験や不確かなことがある
- ささいな違いで大きく結果が変わる
新たな開発プロジェクトでは, これまで経験したことがないような技術があったり, 開発依頼者と開発者の認識の違い等に起因するような不確実性があることが多いでしょう. 例えば, 技術のはやり廃りが加速化している今日において, 設計者が過去経験したことがないようなプラットホーム, フレームワーク, 開発言語を使わねばならないという場合が昔より増えています. また, 特定の外部システムと連携しければならないことが設計段階以降で判明したり, その外部システムのインターフェイスが設計段階では確定しなかったりする場合もあります. そのような未経験や不確かなことがある状況で設計をするためには, 仮説を立てて設計するしかありません. そのような仮説には大きなものも小さいなものもあるでしょうが, 設計の基本的な部分がそのような仮説に基づいていた場合に, 仮説が外れるとその影響で広範囲に設計を変えなくてはならなくなります. そうなれば, 当初行った設計のその部分の作業は無駄になってしまいます. 結局, 精密な設計モデルを最初にいっぱい作るというのはかなり難しいことなのです.
また, 商業的な開発プロジェクトでは, 近年プロジェクトの小規模化や短期間化が進行しており, 10 名以下の小規模チームで 6 ヶ月未満の期間で開発を行わなければならない場合が大勢を占めてきています. そのような小規模開発プロジェクトでは, 要求,分析,設計の専門的スキルを持つ開発者を確保することは困難です. その一方で, 行き当たりばったりの開発方式では高品質で顧客満足度の高いソフトウェアを開発することはできないことも確かです. そのような状況の中で, ソフトウェア開発においてモデルを作ることの意義や作り方が改めて問われています.
3. アジャイル開発
前節で述べたように, ウォーターフォール型開発アプローチは要求の変化に対応するのが困難だという点が大きな短所です. この短所を克服する方法として期待されているのが図 2 に示す反復的な開発アプローチです. 反復的な開発アプローチは, 開発依頼者から要求を聞き, その要求内容を一定の期間で要求, 分析, 設計, プログラミング, テストを実行し, 結果として作成されたソフトウェアを開発依頼者に示すことを１つの「反復」とし, これを繰り返すことにより進行します. このような反復的な開発アプローチを用いることにより, 反復の切れ目で開発依頼者のフィードバックや要求の変化をソフトウェアに反映することができます.
しかしながら, 反復的な開発アプローチでウォーターフォール型開発アプローチと同じ様な専門家の分業を行おうとすると, 以下のような問題に直面します.
- 開発要員の稼働率の低下
- モデルを更新する手間の増加
A は, 要求, 分析, 設計などの専門的スキルが必要される作業が繰り返し現れ, プロジェクトの大半を占めるプログラミングの作業者が待ち状態になってしまうということです. B は, 要求の変化に対応して要求, 分析, 設計などのモデルを更新しなければならないためオーバヘッドが生じるということです.
A を克服するための方法としては, 以下の 2 つの方法を考えることができます.
- 1 人で異なる種類の作業をカバーする
- 要求, 分析, 設計などの専門的スキルを持つ人（専門家）の分業に基づく開発方式ではなく, 設計とプログラミングなど異なる種類の作業をカバーできる開発者によって開発を行う
- モデルを簡単にする
- 要求, 分析, 設計などで作成するモデルを専門家以外の人が作れるようなより簡単なものにする
これら 2 つの解決策を組み合わせることも可能です.
一方, B は維持するモデルをなるべく減らすことで克服できます.
アジャイル開発を実現する開発方式でもっとも有名な XP (eXtreme Programming)[1]とアジャイル開発におけるモデリングの作業指針を提案する AM (Agile Modeling)[2]の両者において, これらの問題点を克服するための具体的な方法を見ることができます. そこで, 以降の節では, XP と AM におけるモデリングの実践方法を紹介します.
4. XP におけるモデリング
XP は, 1999 年に Kent Beck 氏らが書籍 [1] にて発表したアジャイル開発方式です. XP では, 開発は大雑把には図 3 に示されるように 4 つの作業を通じて進行します. 各作業の内容は, 以下のとおりです.
- 要求：開発依頼者の要求をその優先度とともにストーリーカードというインデックスカードに順次記し, カード毎に見積もりを行い, 今回の反復の開発範囲を決める
- タスク分割：開発者が集まって各ストーリーカードを実現するために必要な開発作業をタスクカードというインデックスカードに書き出し, 各開発者ペアが担当する作業範囲を決める
- プログラミングと単体テスト：各開発者ペアがタスクカードに対応するプログラミングを行い, 作業範囲が完了したことを単体テストで確認する
- 受け入れテスト：作成されたプログラムにおいてストーリーカードで合意した開発範囲が実現しているか確認する
ここで, インデックスカードとは図書目録などを作るために使われる紙のカードのことです. これら 1 から 4 のサイクルを 1 回実行することを XP ではイテレーション（反復）と呼びます. XP では, 1 回のイテレーションを 2－3 週間の短期間で実行します. このような短期間でイテレーションを行うことにより, 要求の変化にきめ細かく対応し, 開発依頼者の要求に即したソフトウェアの開発が行えるとされています.
XPでは, モデリングを以下のように行っていると考えることができます.
- 要求, プログラミング, テストを中心として反復的に開発を進める
- 開発途上でモデルをできるだけ作らない
- 要求の記述やタスクの分割においてインデックスカードを積極的に利用している
XP では, 分析, 設計の作業を行わないことでプログラミング作業者が待ち状態になることを防いでいます. また, 開発途上で極力説明やモデルを作らないことで, それらを維持するオーバヘッドを無くしています. 結果として, プログラミングを行う途上で要求内容の矛盾, 不整合, 不明点が発見されます. それらの矛盾等々は開発チームと同じ場所に常駐している開発依頼者（オンサイトカスタマー）に適宜質問して解決するとされています.
また, XP の作業の 1 , 2 では開発依頼者と開発者の間, あるいは開発者間で協調的に要求や作業範囲を決めるのにインデックスカードが用いられます. これらのカードは, 要求やプロジェクト管理のための一種のモデルと考えることができます. このようなカードを用いたモデリングは以下のような長所があります.
- 短い文書とインデックスカードだけしか使わないので, 誰でも容易に実践できる
- 複数人で一緒に作業が行える
- プログラミングとモデリング間の作業の重複が少ない
一般的に UML のような記法は教育してから, 自らモデルを書けるようになるまでに数週間から数ヶ月間の期間を要します. しかしながら, 数週間から数ヶ月間の期間を教育に投資できる商業的な開発プロジェクトは限られているでしょう. それに対して, このようなカードを用いたモデリングは 5 分間程度の説明で実践できるようになれるという大きな利点があります. さらに, カードを用いたモデリングでは, カードを参加者に分担させて, 参加者全員を巻き込んで協調的にモデリングを行うことが可能になります. 従来のモデリング方法では, まず一人でじっくりとモデルを考えてから, 議論することが一般的でしたが, カードを用いたモデリングであれば準備なしにみんなで即興的にモデリングを行うことが可能になります. また, モデリングをプログラミングを補完する作業と位置付け, 両者の重複を防ぐことにより, 無駄な作業が発生するのを防止しています.
このようなカードを用いたモデリングは, アジャイル開発でのモデリングの一つの形を示すものだと考えられます. その一方で, カードを用いたモデリングは UML のような形式がきっちりとした図を使うようなモデリング方法と比べると以下のような限界があります.
- 矛盾や不整合を除くのが困難
- 維持や更新するのが困難
- 全体像の把握には難しい
XP では, カード形式のモデルはあくまで過渡的なものだと割り切ることで A ,Bの限界を避けています. 最終的に矛盾や不整合を除いたり, 維持する対象はプログラムコードであり, プログラミングに入ればカードは捨てます. また, XP では開発チーム内でソフトウェアのアーキテクチャに対するメタファ（喩え）を用いることを推奨しています. 例えば, 電子商取引で用いられている買い物かごはこのようなメタファの一例だと言えます. このようなメタファは, 開発チームのメンバーが開発すべきものに対する共通の理解を持つために役立つと考えられます.
まとめると, XP が提案するアジャイルなモデリングとは以下のようなものだと考えられます.
- インデックスカードやメタファに基づくモデルを使う
- モデルはプログラミング段階で捨てる
- モデル作りにおいて専門的なスキルを求めない
5. アジャイルモデリング
アジャイルモデリング (AM) [2], [3] は, アジャイル開発においてモデリング作業を効果的に行うために Scott Ambler 氏が提案した価値, 原則, プラクティスです. AM の原則やプラクティスにおいて, 特徴的なのは以下の 3 点です.
- すばやいフィードバックを重視する
- モデリングを理解したり, 話し合う手段として考える
- 多様なモデリングテクニックを広く, 浅く使う
A には, 2 種類の意味があります. 第 1 の意味は, 要求を理解する段階でモデリングを活用することにより, 開発依頼者にすばやいフィードバックを提供するということです. この点では, 従来の開発の要求段階の進め方に近く, 開発依頼者が要求を具体化するためにモデルを積極的に用いるということです. そのために, AM では要求を表現するために後述するように多様なモデリングテクニックを推奨しています. 第 2 の意味は, モデルに対するフィードバックをなるべく早く得ることを促すということです. 従来の開発では, 分析, 設計などのモデリング作業では一定の期間にひたすらモデリングを行いますが, AM ではモデルをある程度作成したら, そのモデルの妥当性をプログラムによって確かめることを推奨します. つまり, 仮説の裏づけを取りながらちょっとずつモデリングをした方がよいというのです.このようなフィードバックをすばやく得るために, AM でも XP のように短期のイテレーションを推奨する立場です.
B は, モデリングを, 作業間での情報伝達の手段ではなく, 理解したり, 話し合うための手段だと位置付けるということです. つまり, 一人でモデリングするのではなく, 複数人でモデリングすることをよしとします. そのような複数人でのモデリングは, XP で使っているようなカード型のモデルを作成したり, 白板に UML のモデルを書いたり, 付箋紙を貼り付けるという手軽な方法で実現できると考えるのです.
C は, UML を含む多様なモデリングテクニックを広く, 浅く用いるということです. AMで推奨されているモデリングテクニックは, 全部 で 32 ものテクニックに及びます [4], [5]. AMで推奨されているモデリングテクニックの中で代表的なものを抜粋したものが表 1 です. この表では, 各種のモデリングテクニックを作業種別, モデリングをする際に使う道具および以下のような 3 つの観点で分類しています.
- 即興性：議論しながら, モデリングを行うのに適したテクニックであるか
- 大局的表現：ソフトウェアの全体像の表現に適したテクニックであるか
- UMLで規定：UML で規定された記法であるか否か
| 作業種別 | モデル | 道具 | 即興性 | 大局的表現 | UML で規定 |
|---|---|---|---|---|---|
| 要求 | ストーリカード | カード | Ο | ||
| ユースケース図 | 白板 | Ο | Ο | Ο | |
| 本質 UI プロトタイプ | 付箋紙 | Ο | |||
| ビジネスルール | カード | Ο | |||
| 分析 | ロバストネス図 | 白板 | Ο | Ο | Δ* |
| CRC カード | カード | Ο | |||
| クラス図 | 白板 | Ο | |||
| 設計 | 論理データモデル | 白板 | Ο | Δ** | |
| CRC カード | カード | Ο | |||
| クラス図 | 白板 | Ο | |||
| 相互作用図 | 白板 | Ο | |||
| ステートマシン図 | 白板 | Ο | |||
| コンポーネント図 | 白板 | Ο | Ο | Ο | |
| 配置図 | 白板 | Ο | Ο | Ο |
表 1 で挙げられている本質 UI (User Interface)プロトタイプとは, Usage Centered Design [6] で用いられているモデリングテクニックであり, 付箋紙を用いて画面や帳票のプロトタイプを作る方法です.また, CRCカード [7] とは, Kent Beck らがオブジェクト思考の教育のために考案したインデックスカードを用いるモデリングテクニックです. さらに, ロバストネス図 [8] はオブジェクトの広場の記事でも紹介されたことがありますが, Objectoryという方法論で元々提案されたInterface, Control, Entityという 3 種類のステレオタイプを用いるモデリングテクニックです. Interfaceという言葉は他の意味でもいろいろ使われるために, その後InterfaceはBoundaryという呼び方に変わっています. また, 論理データモデルは ER (Entity Relationship) 手法のようなリレーショナルデータベースを対象としたモデリングテクニックを指しています.
表 1 に示されるように, AM では XP で使われているカードを用いたモデリングのような即興的なテクニックを取り入れ, さらに図形式のモデルである UML のモデルやデータモデルなども併用するのが特色になっています. これらのモデリングテクニックはそれぞれ細かい記法まで含めると習得に相当な時間を要しますが, AM ではこれらのモデリングテクニックのごく基本的な記法だけを広く,浅く使うことを推奨しています. そのために, 5分間程度の説明で誰もが使えるようになるための記法の簡単な見本を準備することを提案しています.
AM はモデリングに特化しているため, XP のような開発方式と併用することにより, それらの開発方式のモデリングに関する部分を強化することができます. 例えば, AMをXPに併用した場合には, XP の弱点であった以下のような点を補うことができます.
- 要求に対するフィードバックがイテレーション単位と遅いこと
- 開発内容の全体像に対する共通の理解を形成しにくいこと
AM を XP と併用して, J2EE (Java 2 Platform, Enterprise Edition) で実装されるようなWebベースのデータベースシステムの開発に適用する場合, 図 4 のような開発サイクルを考えることができます.
- 要求：ストーリカードに本質 UI プロトタイプやユースケース図を併用することにより, 要求内容に対する素早いフィードバックを行う
- 分析：要求内容に基づいて, グループワークでロバストネス図を作成したり, CRC カードでモデリングを行う
- 設計：分析結果に基づいて, グループワークで CRC カード, UML のコンポーネント図, 配置図, データモデルなどを用いて全体的な設計を行い, 各自の詳細設計とプログラミング作業に入る. また, 詳細設計とプログラミングの作業が進行している期間にも, 日次あるいは随時設計上の問題点や変更点をモデルにより協議する.
この開発サイクルの例は, 開発メンバーの大半がプログラミングに先行してクラス図等のUMLのモデルが書けないことを前提に考えたものです. そのため, UML の図は記法が比較的容易に習得できるコンポーネント図や配置図に留めています. 開発メンバーの UML を使い慣れていれば, クラス図や相互作用図などの UML の図を使用することも可能です.
AM では, XP と同様に, 最低限維持するのはプログラムコードだと位置付けていますが, 維持する労力を上回る価値があるモデルは, 維持することを推奨しています. 例えば, 分析ステップで作成した CRC カードのモデルは捨てます. その一方で, コンポーネント図や配置図のように大局的な設計の理解を共有するために有効なモデルは維持することになります.
今まで説明した AM のモデリングに対する考え方をまとめると, 以下のようになります.
- インデックスカード, 付箋紙, 図を使って複数人でモデリングをすることを推奨する
- 維持する労力を上回る価値があるモデルは維持し, そうでないものは破棄する
- モデル作りには少しだけ専門的なスキルが必要
5. まとめ
本稿では, 開発依頼者の要求の変化に対応する開発方式として注目を浴びているアジャイル開発におけるモデリングに対する 2 つの考え方について紹介しました. これら 2 つの考え方で共通するのは, 以下の点です.
- 習得しやすいモデリングテクニックを用いている
- モデリングは一人ではなく, 複数人で行う
- モデルは, プログラムコードを補完する過渡的なものである
モデリングをあまり行ったことがない人は, XP より多様なモデルを作ることを推奨するという点で「 AM は難しいのではないか」と印象を受けるかもしれません.また, モデリングが得意な人は逆に「他の人たちとモデリングするなんてまどろこっしい」と感じるかもしれません. 筆者も, モデリングを全然したことがない人だけで AM をいきなり実践するのは難しいと思います. それでも, モデリングの心得がある人が一人でもいれば, その人が中心になって AM を実践し, より効率的に品質のよいソフトウェアを作ることができるのではないかと考えています.
また, アジャイルモデリングはアジャイル開発だけではなく, 統一プロセスなどの作業や役割がきちんと定義された開発プロセスの中でより効果的にモデリングを行うためのヒントになるのではないかと筆者は考えています.
次回は, アジャイル開発に設計を取り入れるために筆者らが考えた方法論 AMRM (Agile Method Reinforced with Modeling)とその実践結果を紹介する予定です.
参考文献
- [1] ケント・ベック: XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法, ピアソンエデュケーション, 2000
- [2] スコット・アンブラー: アジャイルモデリング - XPと統一プロセスを補完するプラクティス, 翔泳社, 2003
- [3] AM 日本語リソースサイト: https://www.ogis-ri.co.jp/swec/pukiwiki/index.php?am-res
- [4] Scott W. Ambler: オブジェクト開発の神髄 - UML 2.0を使ったアジャイルモデル駆動開発のすべて, 日経 BP 出版センター, 2005
- [5] アジャイルモデルのエッセンス: https://www.ogis-ri.co.jp/swec/process/am-res/am/artifacts/index.html
- [6] Larry L. Constatine他: 使いやすいソフトウェア―より良いユーザインタフェースの設計を目指して, 構造計画研究所, 2005
- [7] レベッカ・ワーフスブラック他：オブジェクトデザイン, 翔泳社, 2007
- [8] ダグ・ローゼンバーグ他：ユースケース入門 - ユーザマニュアルからプログラムを作る, ピアソンエデュケーション, 2001