昔Wantedlyに書いた記事の2025リライト版の記事です。

アジャイルってこういうメリデメあるよね。
世の中にはこういう需要ありそうだよね。
そこに対してこうビジネスしたいね。

みたいなやつをまとめておこうと思って書いたやつ。BAMVに発注を考える人、BAMVに応募を考える人。社員。その辺の方向け。
ぜんぶやると長くなるので、ここでは従来の契約方式の問題点や、こういうの良くない？って話に絞ろうかな。

↓アジャイルサムライになんか書いてあった

3つの真実

1. プロジェクト開始時点ですべての要求は集まらない
2. 集めたところで必ずと言っていいほど変わる
3. やるべきことはいつも、時間・資金より多い。

圧倒的プロジェクトマネジメント能力で何とかするか、素直にこの３つの真実を前提にした手法・思想・契約を選ぶか。そんな話です。

アジャイルて、請負契約には不適合。

ベンダーに発注しようとする場合、最初期で『つくるもの』を厳密に決めてしまえるとベストです。『つくるもの』が厳密に決まっているならば、それを目指してウォーターフォールモデルで、請負契約で。それがおそらくは品質・開発速度の面でも高い効率となるのではないでしょうか。まあ、最初に『つくるもの』を厳密に決めるって、めちゃんこ難しい訳ですけどね。（と言うか、決め切るというのは理想論であって、まず無理。）決めなくても受けてくれるベンダーさんはいますが、ベンダー側の危険度は上がっていきますから、人気のあるベンダーほど受けてくれない。『困ってるベンダー率』みたいなのが高くなっていきそうです。

さて。そんなこんなでスクラムで開発しようという話になったとします。
いきなりですがまず、請負契約が使えません。『つくるもの』を決め切っていないわけですので、請負契約で目的とする成果物が定義できません。ですので、まず見積ができません。損を承知でめちゃめちゃバッファ積んだ見積もりで作るにしても、途中で仕様変更などができません。（ベンダー側の売上は変わらず。コストだけが増えてしまう）　機能の追加・変更や優先順位の変更、先行リリース部分の改善など、『変化に対応する』要素がベンダー側には不利益に。請負を選択した時点で、発注者・受注者間の利害の不一致が発生してしまう構造です。

そもそもが、スクラムを選択したのであれば、必要な部分から順に作る。全部は作らない。が利点です。　完成したソフトウェアの機能の2/3は『使わない・あんまり使わない』と言う話が(真偽はともかく)有名ですが、請負契約では作る範囲を最初に決める必要があり、この時点で『全部作らない』の利点が消えます。スクラムを選択する意味がなくなるのです。

SES・派遣で調達する場合

こちらは労働者派遣に近い状態を作れますので、最初に成果物の範囲を決め切る必要はありません。コアとなるSEやスクラムマスター等を用意できれば、請負に比べて現実味も帯びてきます。こちらの問題は契約よりもむしろビジネス構造になります。
派遣・SESビジネスは成果よりも頭数の確保が売上に直結するビジネスです。労働者の調達がビジネス上の最重要項目となりますので、雇用者との関係も労働者個人の自由度・利害を重視したものとなりますので、雇用者(受注者)のクライアント(発注者)と、派遣労働者たちの利害関係が一致することはほとんどありません。さらには、時間貸しのような契約形態となるのが一般的ですので、遅延することにより受注者側にメリットまで発生してしまいます。となれば、受注者には労働者の質を担保する動機が発生しません。その為、派遣される労働者の専門性・倫理観・ミッションコミットなどが担保されず、かけた費用に対して成果が比例しないと言う問題が起きがちです。ここでも請負と同じように、発注者・受注者間の利害の不一致が発生します。
SESに関してはこのほか多重の再委託などの問題もあり、悪質な受注者に対してペナルティを支払わせようにも、労働者を直接雇用している会社にダメージが及びづらい。善管注意義務違反を軽視した派遣が多くなる点も問題です。（これはアジャイル関係なく）

CAOG契約。ベロシティ基準の契約を提案する。

これらの問題への対策として、BAMVでは、『一定のベロシティを買う』CAOG契約を提案します。
ベロシティとは、開発チームが一回のスプリントで処理したストーリーポイント（タスクの重さにポイントを付けたもの）の合計値です。『一回のスプリントでどのくらい作業できる？』と言う数値ですね。

これのメリットとしては、請負契約同様に低質な技術者のアサインによるコストを負担するのはベンダー側になるという事がまず挙げられます。ベロシティが向上しない限りは、ベンダー側が何人投入したとしても売上は増えません。ベンダーが利益を得るにはベロシティを向上させるほかない。つまりこの契約はベンダー側のチームの生産性向上を促進することになります。また、チームの生産能力の振り分け先はスプリントごとに変更可能ですので、『変化に対応する』『全部作らない』の利点も維持。
ベンダー側としても、ベロシティを維持する（または契約時に調整する）などでメンバーの変更や育成が可能となります。開発体制を増強するための人員増や新人の投入が発注者側の負担になりづらい構造となっているためです。

デメリットとしてはまず、契約したベロシティが担保されているかどうかの確認作業が必要になることです。信頼できる報告内容をスプリントのたびに用意する。精査するというのはかなり負担となりますので、現実的には共通のツールを用意しツール上で確認する。報告やベロシティの調整は契約単位（1～数か月）ごと。になるのではないかと思います。
加えて、ストーリーポイントの見積が妥当である必要があります。見積をクライアントが行う、ベンダーが行う、いずれにしても悪意があれば相手を不利にすることが可能であるため、信頼関係の無い状態。WinWinの状態ではないタイミングでいきなりこの契約を導入と言うのは難しいのではないかと考えます。ストーリーポイントの見積の妥当性やベロシティにつけられる価格など、双方が納得できる状態を作るまで、助走期間は必要です。

なお、契約物となるベロシティは、『ストーリーポイントで算出する。』のほか、『人日計算で算出する。』など、ユーザーの慣習やシチュエーションに合った手段を選択することができます。環境や目的に合わせて最善となるものを選択するのが良いかと思われます。

実際の契約のイメージ①（考え方）

とりあえず、前提として３つの真実（と言うか現実？）があるとして。

1. プロジェクト開始時点ですべての要求は集まらない
2. 集めたところで必ずと言っていいほど変わる
3. やるべきことはいつも、時間・資金より多い。

まずは予算と納期ですね。これは必要です。じゃないと費用が無限に膨らんでしまう。
クライアント側ならば、目的と想定リターンから投資額を決める感じになるでしょう。期限があるならば、それを明確にします。ベンダー側ならば、【いい感じの概算見積】を作成し、クライアントが予算感を把握するための目安としてもらいます。この見積はあくまで『概算』であり、正確ではありません。

製造業にはQCD（「品質（Quality）」「コスト（Cost）」「納期（Delivery）」）と言う3要素の概念があり、これらは互いにトレードオフ関係のものとされています。通常のシステム開発でも同様で、品質を向上させるならコストや時間をかける必要がある。納期を短くするなら品質かコストを犠牲にする必要があると言った具合。よくある感じ

アジャイルの場合は、『つくるものの優先順位を変更』・『全部は作らない』前提で進めるわけですので、QCDに加え、「スコープ」（Scope）※作るものの範囲」の要素が加わってきます。　つまり作らないものを決めていくことによって、品質を犠牲にせず、予算・納期内で開発を進めることができるという事になります。これがよく言うアジャイルはQCDは固定、Sが変動。です。このような考え方でプロジェクトマネジメントを行っていくことになります。

実際の契約のイメージ②（契約の進め方）

まずは、ふつうに準委任契約によるチーム参画からスタート。ストーリーポイントの見積やベロシティの管理の方法などをクライアント・ベンダー双方が参加して仕組み化。安定してきたベロシティがどのくらいなのかお互いに把握しておく。成果を明らかにしていく取り組みですので、本来行われるべきものですし、他のベンダーや外注さんとの比較も容易になっていきます。この時は精度も重要ですが、それよりも互いの信頼関係と納得度の醸成が重要です。実際の開発では未知の要素や予想外の変化などが次々に発生しますので、どのような仕組みであっても完璧な運用は不可能。時にはクライアントが有利、時にはベンダーが有利。など、やや不公平な状態なども発生します。　お互いに利害を調整し合いながら進めることになるでしょう。より価値を置くのは【契約交渉よりも、顧客との協調】です。

互いにストーリーポイントの見積やベロシティ周りでの共通認識が醸成されてきましたら、CAOGへ移行です。

開発目的による話とは思いますが、契約規模を3～6か月くらいに抑えて概算見積。目的をスリムにしたうえで、品質・費用・納期を固定し、見積をしやすくする。

スタートする前に、【開発範囲を調整して納期内に抑える】【期限を超えるものは作らない or 次フェーズに回す】で合意する

ラボ型受託的な準委任契約になるかと思います。

その他のスタートの仕方。

互いに自信・経験が薄い場合など、IPAが作成した、アジャイル開発を外部委託する際のモデル契約に乗っかってしまう。契約前チェックリストから始めるなどでもよいかもしれません。少なくとも、【アジャイル開発ってこんなだよね】みたいな認識が食い違っている状態からのスタートよりはよっぽど良いはずです。

独立行政法人情報処理推進機構（IPA）情報システム・モデル取引・契約書

まとめ

アジャイル関連の記事は結構多いですが、契約周りの話はわりと珍しいんじゃないかな。

しかし、実際にシステム開発を発注する・受注するとなれば避けては通れない話になるかと思います。既存ベンダー様に『動きが悪い』『クライアントの利害を考えてくれない』などの不満を持つクライアント企業様はけっこう多い印象ではありますが、契約内容の点ですでに利害が一致しなくなる原因があるなど、意外に知られていません。我々ベンダー側としても、もうすこし研究していきたい部分ですね。

CAOGもAIエージェントを利用した開発が登場する以前のネタなので、今の世にどのくらい適合するかは検証が必要です。人月ビジネスからの脱却に使える可能性もありますね。

BAMV合同会社 コーポレートサイト お問い合わせフォーム

TEL：03-6424-7968　　担当者：寺野・園生