Open@ReeL の契約の考え方(続き)
先日ReeL の契約の考え方をご紹介しました。
関連するもう一つのトピックとしてバッファ管理の話があります。
ReeL では、ご紹介したように、「固定スコープの請負(基本) + 変動スコープ(上乗せ分)」 という考え方を前提としています。
この変動スコープの部分の実態は、現場によりまちまちでしょう。
目標コスト契約であったり、準委任との組み合わせであるかもしれません。
いずれにせよ、変動スコープの部分にも金額的に上限を見て、その枠内で実際に何をやるかを顧客と協議することになります。
すると必要になるのが、変動分予算(=バッファ)の管理です。
ある機能を追加で加えたならば、いくら予算を食いつぶすのか? といった話です。
○ アジャイル開発での対応
一般的には、実績ベースです。
人月幾らで契約しておいて、実際にかかった工数を請求します。
これは分かりやすさという意味でメリットは大きいのですが、
顧客側が全てのリスクを背負う形態なので、それを納得してもらう必要があります。
顧客側がリスクをとる前提として、開発側は開発の実態の全てを開示する透明性が必要となるでしょう。
○ ReeL での対応
開発の透明性を高め、顧客に全てのリスクを背負ってもらう方式は、日本のSIの現場ではなじみません。
SIer がリスクを吸収してきた一括請負の考え方とはあまりにも異なるからです。
日本のSIの現場では、顧客はそこまでのリスクを背負うことを嫌がるでしょうし、
SIer は開発のコスト構造の全てを開示することを嫌がるでしょう。
また、実績ベースでソフトウェアの価格を決定するという考え方そのものにも違和感はあります。
あるソフトウェアの値段は、その機能の大きさで決まるべきで、安く作るか、高く作るかは
開発側の努力次第であるべきという考え方もあります。
「COMMONDATION-ReeL」では、このような考え方を踏まえ、
バッファの取り崩しにファンクションポイント(FP)を採用しようとしています。
仕様変更や仕様追加に関するFPの変動分から、バッファの取り崩し金額を算出する方法です。
FP と実態との乖離については、開発側で吸収することになります。
実際には、差分FPの算出などでもう少しややこしい話が入るのですが、基本的な考え方としてはこのような話になっています。
ファンクションポイントを使うもう一つのメリットは、客観性です。
ある仕様変更がソフトウェアにもたらすインパクトを、検証可能な形で提示することができます。
バッファの取り崩し量で、顧客側と不毛なやりとりを避けることができます。
Open@ReeL では、さすがにファンクションポイントを自在に駆使することを前提にはできない
と思っていますので、この辺りは考え方のスキームを提示するに留めようと思っています。
整理しますと、
変動スコープのバッファについては、
・取り崩しの単位を顧客と事前に合意しておくことが必須となる。
・取り崩しの単位は、機能単位ベースの見積額の方が導入しやすい
・取り崩しの単位は、客観的に測定可能であった方が好ましい
となります。
実際には、個別のコンテキストに左右されることが大きいので、
「顧客と合意できていれば何でも良い」という話にはなるでしょう。
※ COMMONDATION は、株式会社日立システムアンドサービスの日本における商品名称（商標又は登録商標）です。
