|
[2011 年 10 月号] |
［技術講座］
今月号では、OGIS Scalable Agile Method (以降 OSAM と略す）においてスクラムとアジャイル UP とを組み合わせていることの利点と測定に基づく見積もりや契約について説明します。なお、本記事に挿入したいくつかの漫画は同僚の正木氏が作成したものです。
OSAMの開発手法部分では、スクラムとアジャイル UP を以下のように組み合わせます。
後者は、アジャイル UP の各プラクティスの概要で説明したように開発を長期的に制御したり、ソフトウェアの品質を向上させることができるということです。さらに、アジャイルUPを組み合わせることには以下のような利点がもあります。
これらの利点と、スクラムによるアジャイル UP のプロジェクト管理作業分野の実装について以降説明します。
アジャイル UP にはプロジェクト管理作業分野が定義されていますが、そこで行う作業は以下のようなものです。
この「プロジェクトや反復を計画する」や「プロジェクトの状態を報告する」という作業について、詳細な作業の進め方について説明はありません。この部分にスクラムの開発の進め方を使うことができます。逆にスクラムを実行する際に、アジャイル UP の定義を以下のように活用することができます。
アジャイルではない開発手法に慣れたメンバーがアジャイル開発を段階的に取り入れる場合には、このような参考資料が非常に役立ちます。
スクラムで大規模なソフトウェアを開発する場合には、以下のようなアーキテクチャやチーム横断的な設計をどのように行うかを考える必要があります。
Aは、各反復の実装対象となるエンドユーザ機能（外部機能）を実現するためのアーキテクチャ構成要素の連携（インタフェース）の設計をどうするかという点です。
Bは、アーキテクチャを構成するコンポーネント（パッケージ）、サービスなどをどのように独立性良く、変更が波及しないように設計するかという点です。
Cは、アーキテクチャの全体像、ドメイン（データ）モデル、共通機能などをどのようにチーム全体で共有するかという点です。
Dは、パッケージの階層、クラスの命名、クラスの連携パターンなどに一貫性を持たせて設計やプログラム構造の理解容易性を高めるという点です。
これらの課題を解決する方法として、以下の 3 つの方法が考えられます。
「リファクタリングと暗黙知を使う方法」は、先行してあまりアーキテクチャを考えず、リファクタリングにより徐々に独立性をよくし、一貫性を高めるという方式です。また、開発者が担当する機能を固定化せずにローテーションすることで、開発者がアーキテクチャの全体像をモデルなし（暗黙知）で理解できるようになります。この方法が有効なのは、小規模なものからソフトウェアを徐々に発展させることができ、同じ開発者が比較的長く同じソフトウェアを開発し続ける場合です。このような場合によく当てはまるのは、ソフトウェアを内製する欧米の企業やネット企業、パッケージソフトウェア製品やクラウドのベンダーです。
「モデルを使う方法」は、先行してある程度アーキテクチャを考え、アーキテクチャの全体像、データモデル、共通機能などをモデルで表現するものです。それらのモデルにより、早い段階から独立性や一貫性を高めたり、チーム内で理解を共有します。この方式が有効なのは、比較的短期間に一時的に集まったプロジェクトメンバーでソフトウェアを開発する場合です。このような場合がよく当てはまるのは、日本の大規模な業務用アプリケーション開発のようにITベンダーが一時的に多くのプロジェクトメンバーを集めてユーザ企業向けに開発を行う場合です。
「ドキュメントを使う方法」は、先行してある程度アーキテクチャを考え、アーキテクチャの全体像、データモデル、共通機能などを詳細に文書で表現するものです。それらの文書により、早い段階から独立性や一貫性を高めたり、チーム内で理解を共有します。この方式の利点は「モデルを使う方法」とほぼ同じです。但し、文書はモデルに比べて変更コスト、特に整合性を維持するコストが高く、アジャイル開発が登場した背景となった「変化に対応する」という点では「モデル」ほど適していません。さらに、文書を増やせば増やすほど文書の変更や整合性維持のコストが高まるという点が短所になります。
| 設計の考案と共有手段 | 開発の継続性の前提 | 開発者の継続性の前提 | 変化への対応 | ソフトウェアの種類 |
|---|---|---|---|---|
| リファクタリングと暗黙知 | あり | あり | 強い | パッケージ クラウド |
| モデル | なし | なし | 強い | 業務アプリ |
| 文書 | なし | なし | 弱い | 業務アプリ |
以上の議論をまとめると、どの設計手段が適しているかは以下の 3 つの条件によって決まるといえます。
ここで、「開発の継続性」とは対象となるソフトウェアの開発作業が１つリリースに留まらず、複数のリリースの間で継続するかどうかを意味します。また、「開発者の継続性」とは複数のリリースの開発を通じて開発者の大半が継続して開発に従事するかどうかを意味します。
日本での大規模な業務アプリ開発を考えると、短期に一時的な開発要員が集まるという点で「開発の継続性」も「開発者の継続性」も「ない」ということになります。そのような状況において開発途上で変化に対応することが求められた場合には、前述した A-D の課題を解決する手段としては「モデル」が有効だと考えられます。
A-D の課題の解決が問われるのは、2つ以上のチームでアジャイル開発を行う場合です。1チームを10名以下と考えると、10名を超えるチームでは「モデル」を使うことの有効性が高まると考えられます。
「モデルを有効」とする考え方に対する反論としては、「モデリングできる人（モデラー）が少ない」というものや「モデラーのコストが高い」というものが考えられます。しかし、前述した A-D の課題を解決する人をプロジェクトの一部のメンバーに限定したり、アジャイルモデリングで推奨されるような敷居の低いモデリングテクニックを使うことで、これらの問題は致命的なものではなくなると考えられます。
この節では、以下の点について論じ、機能規模測定手法COSMIC法に基づく測定が見積もりや契約にどのように役立つかについて説明します。
開発途上での仕様変更に対応し、顧客のビジネスに役立つソフトウェアを開発するのがアジャイル開発の意義ですが、それは同時に本白書の 2 章で述べたような以下の不安を生みだす原因になっています。
これらの不安にどの程度対処できるかは、開発当初における要求の不確定性の大きさと、その不確定性が開発途上でどのように変化するかによって決まります。
まず、要求の不確定性の大きさを以下の 3 段階に分類します。
ここで「要求の詳細」とはユースケース記述のイベントフローや画面定義などを意味します。また、「要求の X% が決まっている」とは、開発途上での要求の詳細の変化は (100-X)% 以内に収まるということを意味するとします。
開発初期段階で不確定性が大きい場合と中ぐらいの場合に、3.で説明したアジャイル UP の推敲フェーズのようなフェーズを 1-3ケ月 程度設けて要求をある程度定義することで要求の不確定性がどの程度変わりうるかを考えます。
不確定性が開発当初に小さい場合と不確定性が開発とともに大きくなる場合を除くと、起こりえる場合は表 3 の 5 つの場合になります。これらの 5 つの場合について、以下の観点で考えてみましょう。
| 開発当初の要求の不確定性 | 推敲フェーズ終了時点での要求の不確定性 |
|---|---|
| 大 | 大 |
| 大 | 中 |
| 大 | 小 |
| 中 | 大 |
| 中 | 中 |
以降、推敲フェーズ終了時点での要求の不確定性の大きさで場合分けして議論します。
まず、不確定性が小さくなる場合（大→小、中→小）では、不確定性が小さくなる作成フェーズ以降は従来の見積もり方法で費用を見積もり、開発スコープと費用を定めた一括（請負）契約が可能になり、開発依頼者の負荷も減ります。
不確定性が中ぐらいの場合（大→中、中→中）では、不確定性が中ぐらいで残るため従来の見積もり方法で精度よく費用を見積もることが困難であり、契約上の選択肢は準委任契約になります。また、不確定性を解決するために開発依頼者の継続的な関与が必要になります。
不確定性が大きいままの場合（大→大）については、開発スコープが定まらないために、開発スコープと費用を定めた一括（請負）契約を結べないことになります。その結果、選択しうる契約形態は準委任契約になります。ただ、準委任契約を選んだ場合、ITベンダーが妥当なパフォーマンスで開発を行っているかどうかという点について不安を持つことになります。また、不確定性を解決するために開発依頼者の継続的な関与が必要になります。
これまでの議論では、「従来の見積もり方法」の適用を前提としましたが、「見積もる」のではなく、「発生する変更の規模を測定する」という考え方に基づく別の解決策も考えられます。その別の解決策とは、以下のようなものです。
これらの実現には、ソフトウェアの規模や要求変化の規模を定量化する機能規模測定手法の適用やプロジェクトの測定データの蓄積が必要になります。
機能規模測定手法を用いて、スコープの変化を許容するソフトウェアの調達方法としては southernSCOPE [12] というものが提案されています。この方法は、オーストラリアのヴィクトリア州における情報システムの調達において開発されたものです。
southernSCOPE の実行手順は以下のとおりです。
southernSCOPE を導入してから、予算超過したプロジェクトが 84% から 10% 以下に減ったと報告されています。フィンランドの Finnish Software Measurement Association (FiSMA) は、この southernSCOPE に「プロジェクトのデータを蓄積する」などのステップを追加するなどの改良を加えた northernSCOPE [13] という手法を提案しています。
さらに、日本固有のユーザ企業とITベンダーに分かれた産業構造がここ数年間で大きく変わるという可能性が低いことを前提とする場合には、ユーザ企業とITベンダーの間でどのような契約を結べばよいかということも問題になります。このような問題を解決するというのは、スクラムに限らず、どのような開発手法であれ、開発手法の守備範囲を超えています。しかし、ユーザ企業とITベンダーに分かれた産業構造でアジャイル開発を活用するためには開発手法で解決できない、このような問題を解決する必要があります。
southernSCOPE や northernSCOPE は、開発依頼者と開発会社が以下のことに合意していることを前提にしています。
これをスコープの変化を許容する契約と呼びます。
OSAM では、このスコープの変化を許容する契約を以下のように実装することを提案します。
COSMIC 法は、白書第 1 部で説明したように以下のような特徴を持つ機能規模測定手法です。
このような特徴を持つため、機能規模の測定の際に作成したデータ移動モデルをITベンダーが提供すれば、機能規模の根拠を開発依頼者が確認することが可能です。
OSAM の契約スキームを使うことで、開発途上で受け入れる仕様変更の規模（上限）を契約時点に設定して開発契約を締結することが可能になります。これを仕様変更上限設定型契約と呼びます。
また、委任契約のように開発者の工数を契約する場合にも、各時点で開発した機能規模と実績工数（費用）から機能規模あたりの単価を求めて開発のパフォーマンスを評価することができます。
不確定性が中ぐらいの場合（大→中、中→中）と不確定性が大きいままの場合（大→大）には、このような仕様変更上限設定型契約やパフォーマンス評価を用いることで、ユーザ企業と IT ベンダーとが公平なパートナーとして前向きにアジャイル開発を推進できるようになると期待できます。
また、アジャイル開発において開発方法を改善したり、プロジェクトが大規模した際の全体の状況を把握（共有）するためにも、機能規模を用いたプロジェクトの測定が役立ちます。
これまで説明したスクラム、アジャイルUP、COSMIC を融合した OSAM の全体像は、以下のような原則で表現されます。
5 で述べられている「技術的な方策」とは、テスト駆動開発 (TDD)、アジャイルモデル駆動開発 (AMDD)、リファクタリングを意味したものです。
OSAM の大きな利点の1つは、3.2 節で述べたようにプロジェクトの規模の拡大に対応することができる点です。この特徴が、“Scalable”と命名した所以です。それに加えて、OSAM は以下のような不安に対応し、アジャイル開発を活用して業務に役立つソフトウェアを早く作ることを支援します。
A, B, C は、アジャイルUPの長期的なマイルストーン、COSMIC 法、仕様変更上限設定型契約で解決します。 F, D は、AM, TDD, リファクタリングにより高い品質を実現し、変更コストを低減することで解決します。E は、推敲フェーズを通じて可能な限り要求の不確定性を減らすことで、開発依頼者の負荷を減らします。G は、スクラムのような敷居の低い開発手法から出発し、アジャイル UP のプラクティスを徐々に取り入れることで解決できます。H は、ドキュメント作成をアジャイル UP の移行フェーズの作業として位置付けることで解決できます。
OSAM の今後の課題としては、以下の点が挙げられます。
要求の確定を促進するための技術とは、開発者も含む複数の利害関係者の要望や制約をうまく調整し、迅速に要求としてまとめるための技術です。このようなことを実現するために有望な技術としては、Joint Application Development (JAD) の流れを組んだ要求ワークショップ[14]というものが提案されています。今後、要求ワークショップの方法論を研究するとともに日本での要求ワークショップを効果的に開催するためのノウハウを蓄積していく必要があります。
開発メンバーの知識や習熟度のバラツキを克服する方法とは、複数の会社のメンバーから構成されるような大規模プロジェクトの場合に、以下のような点において知識や習熟度のバラツキが大きくなることへの対処方法という意味です。
大規模プロジェクトでは、プロジェクトメンバーの大半がこれらの知識や習熟度が少ないメンバーで構成される場合もあります。そのように知識や習熟度が少ないメンバーが多い場合にスクラムのようなアジャイル開発を単純に適用しただけでは、高い開発生産性を達成するのは困難です。このような状況で高い開発生産性を確実に達成する方法の１つは、以下のように従来の開発手法のやり方を取り入れることです。
しかし、このような方法を使うと自己組織化されたチームが自律的に開発するというアジャイル開発の理想像からは外れてしまい、変化への対応力が損なわれる恐れがあります。
自己組織化されたチームが自律的に開発するという理想像の実現を大規模開発で目指す場合、以下の 2 点を整備することが必要になります。
これらの実現のためには、トレーニング教材や方法を整備するとともに、ペアプログラミングのようなメンバー間での技術移転の仕組みをうまく活用していく必要があります。
先月号の前編と今月号の後編の 2 回で、OSAM の概説を行いました。この OSAM の概説に統一プロセスの簡単な説明を加えたものが「アジャイル開発白書の第 2 部」になります。今後、「アジャイル開発白書の第 2 部」を執筆する予定ですが、そこでは OSAM 誕生のもととなったいくつかのアジャイル開発や反復開発の事例を紹介するとともに、アジャイル開発が企業にもたらすものについて考察する予定です。
| © 2011 OGIS-RI Co., Ltd. |
|
