ObjectSquare [2008 年 8 月号]

[技術講座]


アジャイルモデリングへの道

第4回:アジャイル開発におけるモデリング

( 株 ) オージス総研 技術部 アジャイル開発センター 藤井拓

ほぼ 3 年ぶりの連載再開です. 3 年前に今回の原稿を書き始めた際にちょっと気負い過ぎて筆が止まり, 忙しさにかまけているうちにあっという間に 3 年間が経ってしまいました. この 3 年間で, 日本ではアジャイル開発への関心がやや停滞していますが, 米国では驚くほど盛り上がっており, 今やウォーターフォール型開発を凌ごうという勢いです. 今年の 9 月に WCSQ (World Congress for Software Quality) という会議でアジャイル開発での設計の実践経験について発表するという機会を頂き, とにかくその発表内容に至るまでに考え, 実践したことを記事に書こうと気を取り直しました.

今回の記事では, ウォーターフォール型開発におけるモデリングの問題点を説明し, さらにアジャイル開発でモデリングを取り入れる 2 つのアプローチを紹介します.




1. ウォーターフォール型開発アプローチにおけるモデリング

中規模以上の商業的な開発プロジェクトでは, 以下のような作業を実行することで従来開発を進めてきました.

図 1 ウォーターフォール型開発アプローチ
図 1 ウォーターフォール型開発アプローチ

これらのプロジェクトの多くでは, 図 1 に示されるようにこれらの作業を順番に1回ずつ実行する「ウォーターフォール型開発アプローチ」を用いてきました.

このようなウォーターフォール型開発アプローチでは, 要求, 分析, 設計などの作業の作業結果を以下のような形で表現し, 次の作業に伝えます.

要求, 分析, 設計の内容を図で表現する記法の代表例としては, オブジェクトの広場の皆さんにお馴染みの UML (Unified Modeling Language) が挙げられます. UML は, 中規模以上の商業的なソフトウェア開発プロジェクトにおいて近年かなり普及してきました. しかし, すべてのソフトウェア開発プロジェクトで UML が使われているわけではなく, 要求,分析,設計の情報伝達の主な手段としてテキストが用いられているプロジェクトもまだまだ多いと思います. 本記事では, これら図やテキストで表現した要求,分析,設計の情報をソフトウェア開発のための「モデル」と呼びます.

ウォーターフォール型開発アプローチで分析や設計などのモデルを作る目的は, 要求内容の不明確な点や設計上の問題点をプログラミング以前に取り除くことです. 結果として, 多くの労力を必要とするプログラミングにおける試行錯誤や修正を減らせれば, 全体的な開発効率を向上させることができます. そのようなモデルを用いた問題発見を助けるために, モデルは必要な情報を網羅する精密なものが良いと考えられ, そのような精密なモデルをある程度の時間をかけて作ることが良いとされてきました.

一方, プログラミングに先駆けて要求や設計をモデリングするためには, 前の作業で集められた情報だけを頼りに概念やアイデアをモデリングする必要があります. しかし, そのような概念やアイデアのモデリングはプログラミングのように具体的な作業とは性格が異なり, 分析者やシステムエンジニアと呼ばれるような専門家が必要だと考えられてきました.

このようなウォーターフォール型開発におけるモデリングの考え方をまとめると, 以下のようになります.



2. ウォーターフォール型開発の問題点

前節の説明で, ウォーターフォール型開発においてモデルを作成することが開発生産性の向上につながると思われたかもしれません. しかし, 現実はそう単純ではありません. モデルの作成が開発生産性の向上につながるためには, 以下のようにいくつかの前提となる条件があります.

  1. 要求を確定した後に, 開発依頼者の要求が大きく変わらないこと
  2. プログラミングで必要なことを設計段階で見通せること

A は, 開発依頼者の要求は開発初期に確定し, 開発中変わらないという仮定です. しかし, 実際には開発依頼者が作成されたソフトウェアの動作を見ることで, ソフトウェアに求めるべきことが明らかになり, 作成されたソフトウェアに対する大幅な修正や作り直しが発生することも多いでしょう. また, 開発中のビジネス状況の変化や開発技術の変化によって要求する内容が変わることもあります. 大幅な修正や作り直しをおこなうと, 結果的には納品の遅れや開発費用の超過を招きます. それでも, 開発依頼者の要求が開発システムの有用性に大きく関わるものである場合, そのような要求の変化に対応しないと開発されたシステムの価値とともにそれを開発した開発者の評価も下がることになります. 結局, ウォーターフォール型開発は要求が開発初期に確定されることを前提としており, このような要求の変化への対応は困難です.

B は, プログラミングで作るべきクラスの定義などを設計段階ですべて決められるという条件です. 現実的には, 以下の 2 点の理由ですべて決めることが困難だったり, 決めても無駄になったりすることが多いでしょう.

新たな開発プロジェクトでは, これまで経験したことがないような技術があったり, 開発依頼者と開発者の認識の違い等に起因するような不確実性があることが多いでしょう. 例えば, 技術のはやり廃りが加速化している今日において, 設計者が過去経験したことがないようなプラットホーム, フレームワーク, 開発言語を使わねばならないという場合が昔より増えています. また, 特定の外部システムと連携しければならないことが設計段階以降で判明したり, その外部システムのインターフェイスが設計段階では確定しなかったりする場合もあります. そのような未経験や不確かなことがある状況で設計をするためには, 仮説を立てて設計するしかありません. そのような仮説には大きなものも小さいなものもあるでしょうが, 設計の基本的な部分がそのような仮説に基づいていた場合に, 仮説が外れるとその影響で広範囲に設計を変えなくてはならなくなります. そうなれば, 当初行った設計のその部分の作業は無駄になってしまいます. 結局, 精密な設計モデルを最初にいっぱい作るというのはかなり難しいことなのです.

また, 商業的な開発プロジェクトでは, 近年プロジェクトの小規模化や短期間化が進行しており, 10 名以下の小規模チームで 6 ヶ月未満の期間で開発を行わなければならない場合が大勢を占めてきています. そのような小規模開発プロジェクトでは, 要求,分析,設計の専門的スキルを持つ開発者を確保することは困難です. その一方で, 行き当たりばったりの開発方式では高品質で顧客満足度の高いソフトウェアを開発することはできないことも確かです. そのような状況の中で, ソフトウェア開発においてモデルを作ることの意義や作り方が改めて問われています.


3. アジャイル開発

前節で述べたように, ウォーターフォール型開発アプローチは要求の変化に対応するのが困難だという点が大きな短所です. この短所を克服する方法として期待されているのが図 2 に示す反復的な開発アプローチです. 反復的な開発アプローチは, 開発依頼者から要求を聞き, その要求内容を一定の期間で要求, 分析, 設計, プログラミング, テストを実行し, 結果として作成されたソフトウェアを開発依頼者に示すことを1つの「反復」とし, これを繰り返すことにより進行します. このような反復的な開発アプローチを用いることにより, 反復の切れ目で開発依頼者のフィードバックや要求の変化をソフトウェアに反映することができます.

図2 反復的開発アプローチ
図2 反復的開発アプローチ

しかしながら, 反復的な開発アプローチでウォーターフォール型開発アプローチと同じ様な専門家の分業を行おうとすると, 以下のような問題に直面します.

  1. 開発要員の稼働率の低下
  2. モデルを更新する手間の増加

A は, 要求, 分析, 設計などの専門的スキルが必要される作業が繰り返し現れ, プロジェクトの大半を占めるプログラミングの作業者が待ち状態になってしまうということです. B は, 要求の変化に対応して要求, 分析, 設計などのモデルを更新しなければならないためオーバヘッドが生じるということです.

A を克服するための方法としては, 以下の 2 つの方法を考えることができます.

これら 2 つの解決策を組み合わせることも可能です.

一方, B は維持するモデルをなるべく減らすことで克服できます.

アジャイル開発を実現する開発方式でもっとも有名な XP (eXtreme Programming)[1]とアジャイル開発におけるモデリングの作業指針を提案する AM (Agile Modeling)[2]の両者において, これらの問題点を克服するための具体的な方法を見ることができます. そこで, 以降の節では, XP と AM におけるモデリングの実践方法を紹介します.


4. XP におけるモデリング

XP は, 1999 年に Kent Beck 氏らが書籍 [1] にて発表したアジャイル開発方式です. XP では, 開発は大雑把には図 3 に示されるように 4 つの作業を通じて進行します. 各作業の内容は, 以下のとおりです.

図 3  XP の開発サイクル
図 3 XP の開発サイクル
  1. 要求:開発依頼者の要求をその優先度とともにストーリーカードというインデックスカードに順次記し, カード毎に見積もりを行い, 今回の反復の開発範囲を決める
  2. タスク分割:開発者が集まって各ストーリーカードを実現するために必要な開発作業をタスクカードというインデックスカードに書き出し, 各開発者ペアが担当する作業範囲を決める
  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 点です.

  1. すばやいフィードバックを重視する
  2. モデリングを理解したり, 話し合う手段として考える
  3. 多様なモデリングテクニックを広く, 浅く使う

A には, 2 種類の意味があります. 第 1 の意味は, 要求を理解する段階でモデリングを活用することにより, 開発依頼者にすばやいフィードバックを提供するということです. この点では, 従来の開発の要求段階の進め方に近く, 開発依頼者が要求を具体化するためにモデルを積極的に用いるということです. そのために, AM では要求を表現するために後述するように多様なモデリングテクニックを推奨しています. 第 2 の意味は, モデルに対するフィードバックをなるべく早く得ることを促すということです. 従来の開発では, 分析, 設計などのモデリング作業では一定の期間にひたすらモデリングを行いますが, AM ではモデルをある程度作成したら, そのモデルの妥当性をプログラムによって確かめることを推奨します. つまり, 仮説の裏づけを取りながらちょっとずつモデリングをした方がよいというのです.このようなフィードバックをすばやく得るために, AM でも XP のように短期のイテレーションを推奨する立場です.

B は, モデリングを, 作業間での情報伝達の手段ではなく, 理解したり, 話し合うための手段だと位置付けるということです. つまり, 一人でモデリングするのではなく, 複数人でモデリングすることをよしとします. そのような複数人でのモデリングは, XP で使っているようなカード型のモデルを作成したり, 白板に UML のモデルを書いたり, 付箋紙を貼り付けるという手軽な方法で実現できると考えるのです.

C は, UML を含む多様なモデリングテクニックを広く, 浅く用いるということです. AMで推奨されているモデリングテクニックは, 全部 で 32 ものテクニックに及びます [4], [5]. AMで推奨されているモデリングテクニックの中で代表的なものを抜粋したものが表 1 です. この表では, 各種のモデリングテクニックを作業種別, モデリングをする際に使う道具および以下のような 3 つの観点で分類しています.

  1. 即興性:議論しながら, モデリングを行うのに適したテクニックであるか
  2. 大局的表現:ソフトウェアの全体像の表現に適したテクニックであるか
  3. UMLで規定:UML で規定された記法であるか否か
表 1 AM で推奨される主なモデリングテクニック
作業種別モデル道具即興性大局的表現UML で規定
要求ストーリカードカードΟ
ユースケース図白板ΟΟΟ
本質 UI プロトタイプ付箋紙Ο
ビジネスルールカードΟ
分析ロバストネス図白板ΟΟΔ*
CRC カードカードΟ
クラス図白板 Ο
設計論理データモデル白板ΟΔ**
CRC カードカードΟ
クラス図白板 Ο
相互作用図白板 Ο
ステートマシン図白板 Ο
コンポーネント図白板ΟΟΟ
配置図白板ΟΟΟ
*:UML のプロファイルとしてサポートされている **:UML のプロファイルでも表現できる

表 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 の弱点であった以下のような点を補うことができます.

図 4  AM を併用した XP の開発サイクルの例
図 4 AM を併用した XP の開発サイクルの例

AM を XP と併用して, J2EE (Java 2 Platform, Enterprise Edition) で実装されるようなWebベースのデータベースシステムの開発に適用する場合, 図 4 のような開発サイクルを考えることができます.

この開発サイクルの例は, 開発メンバーの大半がプログラミングに先行してクラス図等のUMLのモデルが書けないことを前提に考えたものです. そのため, UML の図は記法が比較的容易に習得できるコンポーネント図や配置図に留めています. 開発メンバーの UML を使い慣れていれば, クラス図や相互作用図などの UML の図を使用することも可能です.

AM では, XP と同様に, 最低限維持するのはプログラムコードだと位置付けていますが, 維持する労力を上回る価値があるモデルは, 維持することを推奨しています. 例えば, 分析ステップで作成した CRC カードのモデルは捨てます. その一方で, コンポーネント図や配置図のように大局的な設計の理解を共有するために有効なモデルは維持することになります.

今まで説明した AM のモデリングに対する考え方をまとめると, 以下のようになります.


5. まとめ

本稿では, 開発依頼者の要求の変化に対応する開発方式として注目を浴びているアジャイル開発におけるモデリングに対する 2 つの考え方について紹介しました. これら 2 つの考え方で共通するのは, 以下の点です.

モデリングをあまり行ったことがない人は, XP より多様なモデルを作ることを推奨するという点で「 AM は難しいのではないか」と印象を受けるかもしれません.また, モデリングが得意な人は逆に「他の人たちとモデリングするなんてまどろこっしい」と感じるかもしれません. 筆者も, モデリングを全然したことがない人だけで AM をいきなり実践するのは難しいと思います. それでも, モデリングの心得がある人が一人でもいれば, その人が中心になって AM を実践し, より効率的に品質のよいソフトウェアを作ることができるのではないかと考えています.

また, アジャイルモデリングはアジャイル開発だけではなく, 統一プロセスなどの作業や役割がきちんと定義された開発プロセスの中でより効果的にモデリングを行うためのヒントになるのではないかと筆者は考えています.

次回は, アジャイル開発に設計を取り入れるために筆者らが考えた方法論 AMRM (Agile Method Reinforced with Modeling)とその実践結果を紹介する予定です.


参考文献


記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。
  

© 2008 OGIS-RI Co., Ltd.
Prev. Index Next
Prev. Index Next