ObjectSquare [2011 年 10 月号]

[技術講座]


OGIS Scalable Agile Method の真髄

後編:スクラムとアジャイル UP との組み合わせの利点と測定の活用

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

今月号では、OGIS Scalable Agile Method (以降 OSAM と略す)においてスクラムとアジャイル UP とを組み合わせていることの利点と測定に基づく見積もりや契約について説明します。なお、本記事に挿入したいくつかの漫画は同僚の正木氏が作成したものです。




3.2 スクラムとアジャイル UP を組み合わせることの利点

OSAMの開発手法部分では、スクラムとアジャイル UP を以下のように組み合わせます。

後者は、アジャイル UP の各プラクティスの概要で説明したように開発を長期的に制御したり、ソフトウェアの品質を向上させることができるということです。さらに、アジャイルUPを組み合わせることには以下のような利点がもあります。

これらの利点と、スクラムによるアジャイル UP のプロジェクト管理作業分野の実装について以降説明します。

アジャイル UP にはプロジェクト管理作業分野が定義されていますが、そこで行う作業は以下のようなものです。

この「プロジェクトや反復を計画する」や「プロジェクトの状態を報告する」という作業について、詳細な作業の進め方について説明はありません。この部分にスクラムの開発の進め方を使うことができます。逆にスクラムを実行する際に、アジャイル UP の定義を以下のように活用することができます。

アジャイルではない開発手法に慣れたメンバーがアジャイル開発を段階的に取り入れる場合には、このような参考資料が非常に役立ちます。

スクラムで大規模なソフトウェアを開発する場合には、以下のようなアーキテクチャやチーム横断的な設計をどのように行うかを考える必要があります。

  1. アーキテクチャ構成要素の連携の設計
  2. アーキテクチャ構成要素のモジュール性の確保
  3. 情報の共有
  4. 全体的な設計の一貫性の確保

Aは、各反復の実装対象となるエンドユーザ機能(外部機能)を実現するためのアーキテクチャ構成要素の連携(インタフェース)の設計をどうするかという点です。

Bは、アーキテクチャを構成するコンポーネント(パッケージ)、サービスなどをどのように独立性良く、変更が波及しないように設計するかという点です。

Cは、アーキテクチャの全体像、ドメイン(データ)モデル、共通機能などをどのようにチーム全体で共有するかという点です。

Dは、パッケージの階層、クラスの命名、クラスの連携パターンなどに一貫性を持たせて設計やプログラム構造の理解容易性を高めるという点です。

これらの課題を解決する方法として、以下の 3 つの方法が考えられます。

「リファクタリングと暗黙知を使う方法」は、先行してあまりアーキテクチャを考えず、リファクタリングにより徐々に独立性をよくし、一貫性を高めるという方式です。また、開発者が担当する機能を固定化せずにローテーションすることで、開発者がアーキテクチャの全体像をモデルなし(暗黙知)で理解できるようになります。この方法が有効なのは、小規模なものからソフトウェアを徐々に発展させることができ、同じ開発者が比較的長く同じソフトウェアを開発し続ける場合です。このような場合によく当てはまるのは、ソフトウェアを内製する欧米の企業やネット企業、パッケージソフトウェア製品やクラウドのベンダーです。

「モデルを使う方法」は、先行してある程度アーキテクチャを考え、アーキテクチャの全体像、データモデル、共通機能などをモデルで表現するものです。それらのモデルにより、早い段階から独立性や一貫性を高めたり、チーム内で理解を共有します。この方式が有効なのは、比較的短期間に一時的に集まったプロジェクトメンバーでソフトウェアを開発する場合です。このような場合がよく当てはまるのは、日本の大規模な業務用アプリケーション開発のようにITベンダーが一時的に多くのプロジェクトメンバーを集めてユーザ企業向けに開発を行う場合です。

「ドキュメントを使う方法」は、先行してある程度アーキテクチャを考え、アーキテクチャの全体像、データモデル、共通機能などを詳細に文書で表現するものです。それらの文書により、早い段階から独立性や一貫性を高めたり、チーム内で理解を共有します。この方式の利点は「モデルを使う方法」とほぼ同じです。但し、文書はモデルに比べて変更コスト、特に整合性を維持するコストが高く、アジャイル開発が登場した背景となった「変化に対応する」という点では「モデル」ほど適していません。さらに、文書を増やせば増やすほど文書の変更や整合性維持のコストが高まるという点が短所になります。

表 2 開発形態と設計手段
設計の考案と共有手段開発の継続性の前提開発者の継続性の前提変化への対応ソフトウェアの種類
リファクタリングと暗黙知ありあり強いパッケージ
クラウド
モデルなしなし強い業務アプリ
文書なしなし弱い業務アプリ

以上の議論をまとめると、どの設計手段が適しているかは以下の 3 つの条件によって決まるといえます。

ここで、「開発の継続性」とは対象となるソフトウェアの開発作業が1つリリースに留まらず、複数のリリースの間で継続するかどうかを意味します。また、「開発者の継続性」とは複数のリリースの開発を通じて開発者の大半が継続して開発に従事するかどうかを意味します。

日本での大規模な業務アプリ開発を考えると、短期に一時的な開発要員が集まるという点で「開発の継続性」も「開発者の継続性」も「ない」ということになります。そのような状況において開発途上で変化に対応することが求められた場合には、前述した A-D の課題を解決する手段としては「モデル」が有効だと考えられます。

A-D の課題の解決が問われるのは、2つ以上のチームでアジャイル開発を行う場合です。1チームを10名以下と考えると、10名を超えるチームでは「モデル」を使うことの有効性が高まると考えられます。

「モデルを有効」とする考え方に対する反論としては、「モデリングできる人(モデラー)が少ない」というものや「モデラーのコストが高い」というものが考えられます。しかし、前述した A-D の課題を解決する人をプロジェクトの一部のメンバーに限定したり、アジャイルモデリングで推奨されるような敷居の低いモデリングテクニックを使うことで、これらの問題は致命的なものではなくなると考えられます。

3.3 測定に基づく契約と見積もり

この節では、以下の点について論じ、機能規模測定手法COSMIC法に基づく測定が見積もりや契約にどのように役立つかについて説明します。

開発途上での仕様変更に対応し、顧客のビジネスに役立つソフトウェアを開発するのがアジャイル開発の意義ですが、それは同時に本白書の 2 章で述べたような以下の不安を生みだす原因になっています。

  1. 最終的に何ができるか分からない
  2. いつ開発が終わるか分からない
  3. 開発費用をどのように見積もればよいか分からない

これらの不安にどの程度対処できるかは、開発当初における要求の不確定性の大きさと、その不確定性が開発途上でどのように変化するかによって決まります。

まず、要求の不確定性の大きさを以下の 3 段階に分類します。

ここで「要求の詳細」とはユースケース記述のイベントフローや画面定義などを意味します。また、「要求の X% が決まっている」とは、開発途上での要求の詳細の変化は (100-X)% 以内に収まるということを意味するとします。

開発初期段階で不確定性が大きい場合と中ぐらいの場合に、3.で説明したアジャイル UP の推敲フェーズのようなフェーズを 1-3ケ月 程度設けて要求をある程度定義することで要求の不確定性がどの程度変わりうるかを考えます。

不確定性が開発当初に小さい場合と不確定性が開発とともに大きくなる場合を除くと、起こりえる場合は表 3 の 5 つの場合になります。これらの 5 つの場合について、以下の観点で考えてみましょう。

表 3 不確定性の変化の起こりえる場合
開発当初の要求の不確定性推敲フェーズ終了時点での要求の不確定性

以降、推敲フェーズ終了時点での要求の不確定性の大きさで場合分けして議論します。

まず、不確定性が小さくなる場合(大→小、中→小)では、不確定性が小さくなる作成フェーズ以降は従来の見積もり方法で費用を見積もり、開発スコープと費用を定めた一括(請負)契約が可能になり、開発依頼者の負荷も減ります。

不確定性が中ぐらいの場合(大→中、中→中)では、不確定性が中ぐらいで残るため従来の見積もり方法で精度よく費用を見積もることが困難であり、契約上の選択肢は準委任契約になります。また、不確定性を解決するために開発依頼者の継続的な関与が必要になります。

不確定性が大きいままの場合(大→大)については、開発スコープが定まらないために、開発スコープと費用を定めた一括(請負)契約を結べないことになります。その結果、選択しうる契約形態は準委任契約になります。ただ、準委任契約を選んだ場合、ITベンダーが妥当なパフォーマンスで開発を行っているかどうかという点について不安を持つことになります。また、不確定性を解決するために開発依頼者の継続的な関与が必要になります。

これまでの議論では、「従来の見積もり方法」の適用を前提としましたが、「見積もる」のではなく、「発生する変更の規模を測定する」という考え方に基づく別の解決策も考えられます。その別の解決策とは、以下のようなものです。

これらの実現には、ソフトウェアの規模や要求変化の規模を定量化する機能規模測定手法の適用やプロジェクトの測定データの蓄積が必要になります。

機能規模測定手法を用いて、スコープの変化を許容するソフトウェアの調達方法としては southernSCOPE [12] というものが提案されています。この方法は、オーストラリアのヴィクトリア州における情報システムの調達において開発されたものです。

southernSCOPE の実行手順は以下のとおりです。

  1. ソフトウェアを調達する際に、顧客はスコープマネジャーを雇う
  2. スコープマネジャーは、FP (Function Point) 法により初期の費用とスケジュールを見積もる
  3. 顧客は、機能概要や制約を記述したRFPを作成し、入札にかける
  4. 顧客は、調達先と機能規模あたりの単価に合意する
  5. 分析フェーズを実行することで、要求仕様書を作成する
  6. 要求仕様書に基づいてスコープマネジャーが機能規模を算出し、顧客は予算とスケジュールを考慮してどの機能が必要かを決める
  7. 開発途上での変更について、 スコープマネジャーが費用に対する影響を算出し、顧客と開発者が合意する
  8. 開発が完了した時点で、顧客は納品されたソフトウェアと変更に対する費用を支払う

southernSCOPE を導入してから、予算超過したプロジェクトが 84% から 10% 以下に減ったと報告されています。フィンランドの Finnish Software Measurement Association (FiSMA) は、この southernSCOPE に「プロジェクトのデータを蓄積する」などのステップを追加するなどの改良を加えた northernSCOPE [13] という手法を提案しています。

さらに、日本固有のユーザ企業とITベンダーに分かれた産業構造がここ数年間で大きく変わるという可能性が低いことを前提とする場合には、ユーザ企業とITベンダーの間でどのような契約を結べばよいかということも問題になります。このような問題を解決するというのは、スクラムに限らず、どのような開発手法であれ、開発手法の守備範囲を超えています。しかし、ユーザ企業とITベンダーに分かれた産業構造でアジャイル開発を活用するためには開発手法で解決できない、このような問題を解決する必要があります。

southernSCOPE や northernSCOPE は、開発依頼者と開発会社が以下のことに合意していることを前提にしています。

これをスコープの変化を許容する契約と呼びます。

OSAM では、このスコープの変化を許容する契約を以下のように実装することを提案します。

COSMIC 法は、白書第 1 部で説明したように以下のような特徴を持つ機能規模測定手法です。

このような特徴を持つため、機能規模の測定の際に作成したデータ移動モデルをITベンダーが提供すれば、機能規模の根拠を開発依頼者が確認することが可能です。

OSAM の契約スキームを使うことで、開発途上で受け入れる仕様変更の規模(上限)を契約時点に設定して開発契約を締結することが可能になります。これを仕様変更上限設定型契約と呼びます。

また、委任契約のように開発者の工数を契約する場合にも、各時点で開発した機能規模と実績工数(費用)から機能規模あたりの単価を求めて開発のパフォーマンスを評価することができます。

不確定性が中ぐらいの場合(大→中、中→中)と不確定性が大きいままの場合(大→大)には、このような仕様変更上限設定型契約やパフォーマンス評価を用いることで、ユーザ企業と IT ベンダーとが公平なパートナーとして前向きにアジャイル開発を推進できるようになると期待できます。

また、アジャイル開発において開発方法を改善したり、プロジェクトが大規模した際の全体の状況を把握(共有)するためにも、機能規模を用いたプロジェクトの測定が役立ちます。

3.4 OGIS Scalable Agile Methodの原則と不安の解消

これまで説明したスクラム、アジャイルUP、COSMIC を融合した OSAM の全体像は、以下のような原則で表現されます。

  1. 開発の大きな方向性を顧客と合意するために長期的なマイルストーンを持つべし
  2. 動くコードで客観的に進捗を判断し、顧客からのフィードバックを得るべし
  3. メンバーの自律性と個性を尊重し、チームとしてのパフォーマンスを高めることに力を注ぐべし
  4. 要求の変化の影響を最小限に留め、品質のよいソフトウェアを実現するための技術的な方策を適用すべし
  5. 要求を理解し、解決策を考案し、コミュニケーションの精度を高めるためにモデリングを行うべし
  6. 要求の規模とその変化を測定し、その測定結果に基づいて顧客と開発スコープの設定や変更について合意すべし

5 で述べられている「技術的な方策」とは、テスト駆動開発 (TDD)、アジャイルモデル駆動開発 (AMDD)、リファクタリングを意味したものです。

OSAM の大きな利点の1つは、3.2 節で述べたようにプロジェクトの規模の拡大に対応することができる点です。この特徴が、“Scalable”と命名した所以です。それに加えて、OSAM は以下のような不安に対応し、アジャイル開発を活用して業務に役立つソフトウェアを早く作ることを支援します。

  1. 最終的に何ができるか分からない
  2. いつ開発が終わるか分からない
  3. 開発費用をどのように見積もればよいか分からない
  4. 従来の開発と比べてコストアップになるのではないか
  5. 開発依頼者側の負荷が高いのではないか
  6. 開発されるものの品質が悪いのではないか
  7. 高いスキルのメンバーしか実践できないのではないか
  8. 保守のためのドキュメントは作成されるのか

A, B, C は、アジャイルUPの長期的なマイルストーン、COSMIC 法、仕様変更上限設定型契約で解決します。 F, D は、AM, TDD, リファクタリングにより高い品質を実現し、変更コストを低減することで解決します。E は、推敲フェーズを通じて可能な限り要求の不確定性を減らすことで、開発依頼者の負荷を減らします。G は、スクラムのような敷居の低い開発手法から出発し、アジャイル UP のプラクティスを徐々に取り入れることで解決できます。H は、ドキュメント作成をアジャイル UP の移行フェーズの作業として位置付けることで解決できます。

4. 今後の課題

OSAM の今後の課題としては、以下の点が挙げられます。

要求の確定を促進するための技術とは、開発者も含む複数の利害関係者の要望や制約をうまく調整し、迅速に要求としてまとめるための技術です。このようなことを実現するために有望な技術としては、Joint Application Development (JAD) の流れを組んだ要求ワークショップ[14]というものが提案されています。今後、要求ワークショップの方法論を研究するとともに日本での要求ワークショップを効果的に開催するためのノウハウを蓄積していく必要があります。

開発メンバーの知識や習熟度のバラツキを克服する方法とは、複数の会社のメンバーから構成されるような大規模プロジェクトの場合に、以下のような点において知識や習熟度のバラツキが大きくなることへの対処方法という意味です。

大規模プロジェクトでは、プロジェクトメンバーの大半がこれらの知識や習熟度が少ないメンバーで構成される場合もあります。そのように知識や習熟度が少ないメンバーが多い場合にスクラムのようなアジャイル開発を単純に適用しただけでは、高い開発生産性を達成するのは困難です。このような状況で高い開発生産性を確実に達成する方法の1つは、以下のように従来の開発手法のやり方を取り入れることです。

しかし、このような方法を使うと自己組織化されたチームが自律的に開発するというアジャイル開発の理想像からは外れてしまい、変化への対応力が損なわれる恐れがあります。

自己組織化されたチームが自律的に開発するという理想像の実現を大規模開発で目指す場合、以下の 2 点を整備することが必要になります。

これらの実現のためには、トレーニング教材や方法を整備するとともに、ペアプログラミングのようなメンバー間での技術移転の仕組みをうまく活用していく必要があります。


後編の終わりに

先月号の前編と今月号の後編の 2 回で、OSAM の概説を行いました。この OSAM の概説に統一プロセスの簡単な説明を加えたものが「アジャイル開発白書の第 2 部」になります。今後、「アジャイル開発白書の第 2 部」を執筆する予定ですが、そこでは OSAM 誕生のもととなったいくつかのアジャイル開発や反復開発の事例を紹介するとともに、アジャイル開発が企業にもたらすものについて考察する予定です。


参考文献


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

© 2011 OGIS-RI Co., Ltd.
Prev Index
Prev Index