永和システムマネジメントの例のスキームは、どうやって赤字リスクを回避しようとしているのかについてちょっと考えてみたござ先輩のエントリーを読んで、久しぶりに法務ブログっぽいエントリーを書こうと思い立ちました。題材は、永和システムマネジメントの例のスキームです。このスキームを目にした方が最も印象的に感じるのは「初期費用を無料にして、運用費だけで回収する」「しかも、途中解約に制限・ペナルティはない」という回収モデルの部分だと思います。永和システムマネジメントは、どのようにしてプロジェクトが赤字に終わってしまうリスクを回避しているのでしょうか。1.対価の発生時期を早める永和システムマネジメントの例のスキーム(永和スキーム)は、ウォーターフォール(最初から完成品を作る)モデルでも、対価の回収方法を変えれば実現自体は可能です。実のところ、永和システムマネジメントがアピールしているアジャイル(ちっちゃく作った後完成品目指して追加開発していく)は、永和スキームの必要的要素ではないのです。アジャイルはウォーターフォールに比べると最初のリリースまでの時間が圧倒的に早いため、結果として、リリース後に発生することになっている対価の発生時期を早めることが可能になります。永和システムマネジメントは、アジャイルの特性の「ちっちゃく作って...」を、こんな面からも活用しているんですね。2.リリース前のコストを圧縮するアジャイルで開発する以上、最初のリリースまでに必要な工数はウォーターフォールよりもずっと低くなります。純粋な開発工数以外にも、成果物の仕様が限定されているため、仕様変更に振り回される危険も低くなります。(仕様追加に至っては、「リリース後にやりましょう」と切り捨てることが可能)さらに、著作権を譲渡しないこと、着手時点でリスクを取っているのは主に永和システムマネジメント側であることから、通常の受託開発よりもユーザーの無茶な要求に振り回されにくいという面もあるかもしれず、そうであればコスト圧縮に大きく寄与すると考えられます。対価発生前のコストが圧縮できれば、当然立ち上げ時の赤字幅も小さくなりますよね。3.リリース後もコストをかけない永和スキームの紹介ページを見ると、トライアル開始されるプランSSにおいて、月次で委託できる工数は1チケット。”1チケットで1日程度の保守・サポート対応が可能です。”とのことですので、これが1人日という意味なのであれば、アジャイルの継続開発というより、どちらかと言うと保守・サポートに近い印象を受けます。最初のリリースから次のバージョンのリリースに1人月必要だとすると、ユーザーがチケットを買い増さない限り、1年近くかけて開発することになります。(本当の意味での保守が発生する可能性を考慮すると、1年を超過する可能性も多いにあります)このように、リリース後にかかる工数を限定することで、黒字化までの期間を短縮できるってわけです。永和スキームの紹介ページを見ると、プランSSの料金は15万円なので、1人日15万円という前提で単純に人月単価に換算すると300万円(4年目以降は半額になるそうなので、150万円)ということになりますね...ただ、買い増しチケットの単価は15万円よりも安いかもしれません。4.成果物を転用する永和スキームでは、著作権は永和システムマネジメントに留保されますので、特段の事情が無い限りコードの転用は永和システムマネジメント側で自由に行えます。ワークフローの様な汎用性の高い案件を受注できた場合には、これを転用することで次の案件のコストをぐぐっと圧縮できる可能性があります。ものによっては、パッケージ化してライセンスで収益を上げることだって可能になるかもしれません。5.成長を見せることで期待感を持たせるシステム変更時には、ユーザーとしても教育や運用の変更などの対応をせざるを得ないため、たとえ開発費/構築費が0であってもそう簡単に新しいシステムの利用をやめる訳には行きません。これに加え、アジャイル開発の下では、リリースされたシステムに要望していた機能が追加され、(運が良ければ)使い勝手も向上していくのを目の当たりにしたユーザーが「来月・来年はもっと良くなっているかもしれない」と期待することにより、さらにその効果が高まるんじゃないかと思います。当然ながら、リリース後は単月では黒字になるように値決めしているはずなので、継続期間が長期化はそのまま黒字幅になるわけですね。このように見て行くと、目先のキャッシュだけ工面できれば、通常の受託開発と比較しても、それほど危ない橋を渡っていないように思えてきませんか?ぜひ技術力に自信のある他社さんも、丸パクリではなく、「ご紹介キャンペーン(顧客を紹介してくれたら1年間収益分配する、とか)」「余ったチケットをコンサルティングetcに流用できる仕組み」「ボーナスチケット(汎用性のあるシステムについてはチケットを上積みしてあげる)」のような工夫を追加して新しい契約スキームを盛り上げて頂ければと思います。09:53リリース後の開発工数のしょぼさが、リスクヘッジのためなのだとしたら、すごく残念ですねぇ。