「永和さんの「価値創造契約」が大苦戦を強いられている件」の記事がすごく参考になる

XP祭り2014で発表された「俺の価値創造契約」の発表資料がすごく参考になるのでメモ。
「この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。」という指摘はまさにその通り。

俺の価値創造契約 from Fumihiko Kinoshita

【参考】
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance

新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメント

価値創造契約の件の感想

これだけはマスター！情報戦略キーワード - レベニューシェア型契約：ITpro

理想と現実 | 検索結果: | cloud42

エンタープライズの開発における、プロダクトオーナーとしての組織（前編）。Developers Summit 2014 Summer － Publickey

エンタープライズの開発における、プロダクトオーナーとしての組織（後編）。Developers Summit 2014 Summer － Publickey

【1】僕の立場としては、アジャイル開発のビジネスモデルが確立して欲しいと思っているので、永和さんの「価値創造契約」やソニックガーデンさんの「納品のない受託開発」モデルも応援したい。
しかし、「価値創造契約」の資料を読むと、色々考えさせられる。

初期投資不要、チケット制の追加開発、受託開発したシステムはレンタル、などというビジネスモデル。

3年やり始めて、受注実績は2社、3システム。
テレアポ800社やっても、テレアポからの受注実績はゼロ。

アジャイル開発をやりたい、という気持ちがあっても、ビジネスは別。
売上を上げて、利益を確保するのは、また別のテクニックが必要なのだろう。

でも、この辺りは、最初に誰かが始めなければ、その仮説が正しいかどうかも分からない。
やってみて初めて、何が必要なのか、が分かる。

【2】日本企業の情報システム部門が業務システムの開発を委託する場合、彼らの開発計画に失敗や損はない。
そんな予算や計画を立てたら、首になる。

だから、情報システム部門は、システムの開発を委託する場合、その投資に対する費用回収計画を作る。
1年目は5千万とか1億とか投資して、その後、1年目の投資を5年で償却しながら、保守料を毎年支払っていく。
その時、投資したシステムがいつ元が取れるのか、がすごく重要になってくる。

受託開発がメインになりがちな、企業の社内業務システムでは、社員がどれだけ使ってくれるか、が重要だ。
だから、社員の操作頻度ないしシステム利用料から、投資したシステムの売上を計測する。
その売上の累積が、費用回収計画での損益分岐点にぶち当たり、損益分岐点が前倒しになるほど、システムは成功したことになる。

しかしながら、業務システムはさほど使ってくれないものだ。
経営者が業務の効率化で導入するのであり、社員が楽しく使ってくれるために入れるのではない。
普通の業務システムは、機能は豊富でも、使い勝手が悪いのが普通。
すると、利用者が増えず、CIOは経営者から、あんなに高い金額で投資したのに何故システムは使われないのか、元が取れないぞ、と文句を言われがち。

そんな立場にいる情報システム部門から見れば、価値創造契約は不向きなのかもしれない。

システムはレンタルなので資産計上できない。
つまり、お金を支払ったのに、システムは使い捨てに等しい。
投資したお金は、資産にならず、その時限りの使い捨ての費用にしてしまっていいのか？
そもそも、システムは重要な資産ではないのか？

システムの機能改善を依頼しようとしても、チケット制の場合、社内の稟議に引っかかってしまい、なかなか発注できない、という話もありがちだ。
日本の大企業では、例えば、20万円以上の仕入れは部長決裁が必要だったりするので、部長に逐一説明しなければ稟議は通らない。
部長も忙しいし、詳細まで知っているわけではないから、理解できないモノは決裁してくれない。

また、社内のシステム化方針が変わったことにより、せっかくの受託開発が中止となり、簡単に契約が破棄された、という話も、よくあるなあ、と思う。
特に、社内の基幹系業務システムは、スクラッチの受託開発よりも、ERPパッケージ製品を導入する場合が多い。
スクラッチで一から作るには、情報システム部門が社内のたくさんの利用部門から要求を集めて、要件定義を確定する必要があるが、政治力がなければ、開発スコープが収束しない。
また、普通の情報システム部門はシステム開発のマネジメント力がないから、スクラッチの受託開発は赤字になりやすい。
そんなリスクを考えると、ERPをノンカスタマイズで導入し、ベンダーの保守サポートを受ける方がはるかに楽だ。

【3】他にも下記の反省点が書かれていた。
実際に試したからこそ、得られたノウハウ。

(引用開始)
失敗する前提でシステム開発をしないため、解約をメリットとして社内に説明できない。
解約すれば金銭的な損害は受けないかもしれないが、再び、別の会社に発注してシステムを作り直さなければならない。
ユーザー企業の情シスは絶対に失敗を認めない。

『価値創造契約』で開発したシステムをリリースした直後、経営者（CIO）が交代し、『価値創造契約』で運用しているシステムをERPに入れ替える方針となった。方針転換は想定外。
解約手数料なし。

チケットの使用に承認が必要なため、あまり使われていない。
チケットの使用にお客さまの社内決裁が必要となり、追加開発のために予算を確保する場合と同じフローになるという状況が発生した。

最終的な仕様は弊社で決めるという『価値創造契約』のルールは受け入れられにくい。
仕様は弊社で決めると言っておきながら、知っていて当たり前の業務知識についてまったく不勉強であった。知識・勉強不足により、お客さまに確認すべきことが確認できていないことがあった。

『価値創造契約』で開発したシステムはお客さまに納品せず、弊社の資産になるため、弊社の開発者が分かるレベルの仕様書しか残してこなかった。お客さまが自分たちのシステムとして運用していくために、必要な情報が不足した。

開発時は新しいものが段階的にできていく姿を見せながらお客さまの要望を取り入れていくため、お客さまに加点法で評価していただける。しかし、運用に入ったシステムは障害発生や過去のシステムと比較して使いづらくなったなど、お客さまは減点法で評価されることが多い。

システム利用料に対する成果を求められる。
エンジニアの稼働に対する対価を支払うという考え方が抜けきらず、ステムの運用に入ってから、対価に対してエンジニアの稼働が少ないという不満を抱かれるケースがあった。
(引用終了)

【4】「価値創造契約」の記事を読むと、なぜ、ソニックガーデンの「納品のない受託開発」は成功したように見えるのか、不思議になる。

どちらのビジネスモデルも、クラウドとRubyとアジャイル開発を前提としており、開発技術そのものは変わらない。
どちらの収益の獲得方法も、受託開発からの保守利用料だ。

あえて違いが見える部分を探してみれば、開発体制とマーケットだろう。

「納品のない受託開発」の開発体制は、ビジネスオーナー、プロダクトオーナー、開発チームというスクラムチームに似たような体制を作る。
この体制の利点は、仕様を決める人の責任が明確であることと、システムの方向性を経営者(ビジネスオーナー)が決める事実が可視化されていることだろう。
だから、システム開発の要件定義で右往左往しづらいように思える。

また、「納品のない受託開発」のマーケットは、ベンチャー企業のWebサービスや中小企業のWebシステムだ。
つまり、社内の業務システムというエンタープライズ系のシステムが対象ではない。

「納品をなくせばうまくいく」の感想part3～「納品のない受託開発」のビジネスモデルの不明点とあるべき姿: プログラマの思索

「納品をなくせばうまくいく」の感想part2～「納品のない受託開発」のビジネスモデル分析: プログラマの思索

「納品をなくせばうまくいく」の感想part1～ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索

【5】僕の直観では、企業の基幹系業務システム開発、つまりエンタープライズ・システムの開発は、アジャイル開発に向かない気がする。
「納品のない受託開発」のビジネスモデルの成功要因の一つは、エンタープライズ系のシステム開発を避けているからではないか、とも思う。

エンタープライズアジャイルは袋小路に陥っているのではないか: プログラマの思索

鈴木雄介さんの記事を読んで思うのは、やはり、エンタープライズ系のシステム開発では、上流工程はウォーターフォール型開発で要件をある程度仕様凍結し、方式設計や分析である程度、アーキテクチャを固めることが重要なのだろう。

また、下記の記事を読むと、開発体制の面でも、プロダクトオーナーを人ではなく組織に担当させて、組織が定期的に意思決定できる仕組みを整えている。
つまり、スクラムチームに似たような開発体制を作る事が重要なのだろう。

エンタープライズの開発における、プロダクトオーナーとしての組織（前編）。Developers Summit 2014 Summer － Publickey

エンタープライズの開発における、プロダクトオーナーとしての組織（後編）。Developers Summit 2014 Summer － Publickey

エンタープライズ系のシステム開発では、技術一辺倒では成功しづらい。
社内の利用者を巻き込む政治力やファシリテーション力、業務ノウハウをまとめたドキュメントや利用者への手厚いマニュアルなど、技術とは別の要素の比重が高い。
アジャイル開発は動くシステムと言う現物主義だが、「プロフェッショナルCIOの教科書」を読むと、エンタープライズ系のシステム開発では、それだけでは通用しづらい面があるのだ。

「プロフェッショナルCIOの教科書」の感想～調整型CIOは必ず失敗する: プログラマの思索

でも、こんな赤裸々な資料を公開されている永和マネジメント様はすごく太っ腹で、すごいな、と思う。
事例が少ないだけに、すごく貴重だ。

【追記】
9/27土に関西に倉貫さんをお呼びして、アジャイル開発のビジネスモデルについて議論します。
まだまだ座席はありますので、是非ご参加下さい。

9月27日 第60回 SEA関西プロセス分科会(大阪府)「納品をなくせばうまくいく?アジャイル開発のビジネスモデル！」