BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 変化と永続性

変化と永続性

原文(投稿日:2012/11/27)へのリンク

 
アジリティ(Agility)には変化を容認するフレキシビリティがある。それに対して,法律的な契約は永続性の成文化であり,企業間取引関係者の損失や被害リスクを回避する手段である。法律専門家とアジャイルソフトウェア開発者という2つの分野がもたらす価値を損なうことなく,この両極のギャップを埋めるにはどうすればよいのだろうか。Callum Sinclair氏が2012年10月,Computer Weeklyに発表した記事 "IT 契約をアジャイルにする方法 (How To Make IT Contracts Agile)" で提案したのは,まさにそのための方法だ。
 
Sinclair氏によれば,
 
法律関係者のアジャイル方法論に対する理解の欠如,その結果として契約の前例と"法的"ケーススタディの欠如。これらがビッグビジネスがアジャイルに取り組む上で障害となっています。
 
同じような指摘は他にもある。中にはアジャイル採用の主要な障害のひとつとして,アジャイルプロジェクトを扱うための契約モデルが存在しないことを挙げているものもある。
 
ソフトウェア製品開発を対象とする契約文書は,作業範囲やその(応札された)コスト,開発作業のスケジュールなどを詳細に記述することによって,すべての成果物の仕様を詳細に定義しようとするものが大部分だ。いわゆる固定入札契約(fixed bid contract)であり,英国内閣府で先日実施された例に見るように,政府が調達する IT サービスについてはごく一般的な形式である。
 
世界中の政府機関がアジャイルのメリット活用に対する関心を高めている現在,ビジネスとして契約を扱う弁護士たちは,アジャイルのどの部分を問題としているのだろうか。アジャイルソフトウェア開発プラクティスに関する理解ないし一般知識の単なる欠如という問題以上に,具体的な懸念をもたらしているものは何なのだろう。Sinclair 氏の言葉を借りるならば,
 
  • 仕様の欠如。ほとんどのアジャイル方法論はプロダクトを事前に定義しない。代わりにプロダクトは進化し,その過程で発生する変化を有機的に包含する。そのために何が提供されるのか,あるいはされないのかを,契約書で正確に定義することは困難である。
  • 同意することの同意。アジャイルでは,イタレーション終了時や完成時に提供する内容の決定が頻繁に延期される。このような事前の意思決定の欠如は,契約法の理念や原則と真っ向から対立するものであり,争議が起きた場合の訴訟,仲裁,あるいは調停を通じた契約の強制を難しいものにする。
 
これらの懸念に対処するためにSinclair氏は,アジャイルの有用性を信じる経営者やベンダに対して次のような方法を提案する。ただし上級管理職や弁護士との調整が必要になる。
 
  • プロセスの初期段階において,アジャイル開発とは何か,そこから得られる利益は何か,といった点に関する基本的理解を確認せよ。簡単なメモやケーススタディがあれば,同意内容の説明や確定の役に立つ。リスクには先行して対処すると同時に,リスク軽減に有効性を期待できるアジャイルの特性にも注目すべきである。例えばイタレーション毎に成果を提供するというアジャイルの特徴は,早期終了と責任規定に関する弁護士の懸念を緩和するのに役立つはずだ。
  • プロジェクトの規模やユーザ組織の文化,ユーザの所有するリソースなどを考慮した上で,当該プロジェクトに対してアジャイルとウォーターフォールを適用した場合の相対的利点とリスクを十分に比較検討せよ。プロジェクトにとって検討結果がいずれかのアプローチを除外するものなのかどうか,早い段階で決定することが必要だ。
  • ユーザ視点に立って,ビジネスケース資料と提案依頼書 (RFP / Requests for Proposals) がアジャイル方法論の適用 – 前述の2番目のポイントによって除外されていなければ – に対して十分な柔軟性を備えているか確認せよ。一般的に調達を好条件で行うには,提案された契約条件を弁護士が RFC 文書に折り込むことによって,取引先との実施計画合意(AIP)を確実なものにしておく必要がある。しかしその契約条件がウオーターフォール的な成果達成方法を前提とする場合,このことが問題になる可能性がある。複数の実施契約,すなわちアプローチの違いを考慮した2形式の契約を採用することによって,同レベルの確実性を担保する配慮が必要だ。
  • 確実性をさらに取り戻す手段として,制限的契約管理を弁護士とともに検討せよ。"最低限の成果" の定義,プロジェクト費用限度,最終納期などはその例だ。このような確実性がアジャイルの柔軟性を損なうものであることは間違いない。しかしこのようなハイブリッドモデルも,トレードオフを正しく理解する限りにおいては有効なのだ。
 
氏の2番目の提案が「すべてのケースにアジャイルが適合するとは限らない」という,ソフトウェア開発コミュニティで長く議論の的になってきた点の指摘になっているのは興味深い。
 
法律と契約は,争議において私たちの権利と財産を守るためのものだ。しかしソフトウェア開発のような複雑な行為においては,成功のために柔軟なアプローチを必要とする場合も多々ある。契約法は時代とともに進化する必要があるのだろうか,あるいはアジャイル主義者たちの方がアプローチにおいてより実用主義になるべきなのか。アジャイルソフトウェア開発と契約法との間により多くの共通点を生み出すためには,他にどのようなアプローチがあるのだろう。

 

この記事に星をつける

おすすめ度
スタイル

BT