XP祭り2014での発表資料

2010年11月に「価値創造契約」を発表してから4年。数案件を実施し、さまざまな経験をしてきました。

XP祭り2014のセッションでは、その貴重なエピソードを発表しました。

俺の価値創造契約 from Fumihiko Kinoshita

言及されたブログ

XP祭り2014での講演や講演資料について、いくつかのブログで言及いただきました。

講演を聴いた方、資料を見た方からのコメント

Twitter や はてなブックマークのコメントで多くの貴重なご意見をいただきました。ありがとうございました。

※ ( )内はコメント数

うまくいっていないことに対する分析・批評 (29)

  • 敢えて良くなかった数値を、分析含め提示している点は凄い。一方で長く使っていただくことが成功だという仮説は、もしかしたら外れかも。売上がたたないジレンマから抜け出せなさそう。
  • お客さんにリスクを負わせないのは、それはそれで本気じゃないと思う…
  • 「どれだけ価値があっても、安くても、幾らかかるかわからないものは予算化できない」という財務とか契約の側面の問題で、そこをhackしないとだめよって話じゃないの?エンジニアがいいもの作る意欲だけじゃ駄目
  • 開発する側は納品しないメリットあるけど、依頼側は納品されないデメリット ( 数年後に開発元の倒産など ) が大きい
  • コンタクト12件って少なすぎる。名前がよくないのでは。あやしげなコンサル会社とかの話に間違われやすそう
  • ヘンな契約形態を導入して責任問題になったら困る大きな企業は発注しないし、小さな企業は内製するのが当たり前だからねぇ、という営業レイヤーの話では
  • 個人的にコンタクト12件ってのは少なすぎなんじゃないかな。需要とターゲット層がずれてる感がある。べき論が先行してしまったのと、お客さんへの教育コストの見積もりが甘かったという分類になるだろうか。
  • この仮説は正しいの? → 「システムの価値はそのシステムがどれだけ長く使われたかではかれる」
  • 役務でダメな理由がわからんな。役務でいいじゃない。ゲスい想像をすると1人でいくつも掛け持ちすることで「生産性を上げる」何てことが役務だとしにくいから、こうしたかったのかもね!
  • どう考えても著作権のところがアウトだと思うがどうなんだろ。お互いに信頼がある既存顧客から始めることはできなかったのだろうか。もし営業がカニバることを気にしてたら成功はしないでしょうね。SG社とはそこが違
  • 将来コストが読めないってのは、個人に対しては目くらましとして効果的だけど、組織だと決裁がおりないから難しいよな。
  • BtoBの相手になる大企業は月定額制を喜ばないことを認識すべき。初期投資なら減価償却できるし部署毎の予算もあらかじめ貰える。ランニングコスト増加は顧客企業内での調整リスクを大きくするだけで担当者は嫌がる。
  • 期待してただけに非常に残念。新しいこと、未体験のことってリスクを大きく見がちなので、マニュアルや提案書、コミュニケーションを厚くして心理的ハードルを下げないと続かないよな。
  • これ、システムを資産に計上して減価償却する会計処理に組み入れにくいと思う。月額料金が高すぎる上に不定だから、サービス使用料として割りきるのも難しいかと。
  • 仮説が間違ってないだろうか
  • 確かに要件定義に価格設定しておけば、最悪その段階で契約打ち切りでも要件自体は他社開発へ流用可能だしね…
  • 単純に「相手側窓口社員が、上司を説得する資料」を作れなかったから、じゃないかな。180~1620万の年間保守契約が発生する代わりに受注1円です、に見える。5年刷新なら一括受託よりオトクですよ、的なのが必要だよね。
  • 提供するのは「実装してくれるコンサル」なのか「優秀な開発部隊」なのか、前者なら業務知識は必須だ- し後者なら発注側にシステム知識が必要。 / にしてもこれが成功したら嬉しいなあと思ってたので残念
  • このモデルは業務システム開発じゃなくて、たとえばパソコン安心サポートとかホームページ制作代行とか便利屋とかならよかったのではないかなー。高いからこそ売れるもの、安いと逆に売れないものがある。
  • どっちにしろ「今から作りますから!」モデルが辛いので、なんとも。
  • 「業務知識」と言うよりは現場レベルの事務知識だよね。あの書類はそのクリアファイルに入れて3時までにあそこの机の上に置く、みたいな。これがわかってないと事務システムは作れない
  • 基本的には後払いモデルなんだから、通常の受託見積と同時に見積出したら顧客に検討してもらえるような気もするんだけどそういう話じゃないのかな
  • 価格は競争力があったような気がするし、成果物の価値が見えづらかったのが問題なのかな?受託でアジャイルはやっぱり無理筋なのかね
  • 担当レベルは依頼したくても決裁者が嫌がりそうな
  • どんな業種のどんな企業でも自分たちの仕事が価値を生み出してないなんて考えてることはまずないわけで,そんな相手に「価値創造契約」って提案はネーミングで損をしていると思う。
  • 今回の永和さんの取り組みは上記取り組みに逆行した「一時払いを減らし、固定費不明瞭化(保守と一次費用である開発の混在)」となるわけで、お客さんからしたら受け入れられづらいのは当然じゃあないかな、と思います。
  • 価値を前面に出して契約を取るには、人材が揃ってないと厳しい。まあ、こうすると失敗する、という良い事例である。
  • 「俺様んところの重要システムは御託を並べて腹をくくっていなさそうな奴になんか任せられない」っていう印象を与えてしまっていそう (「価値創造契約」が)

価値創造契約の改善提案 (6)

  • サービスは悪くないと思うんだけどな。スモールスタートにして、その初期費用は工数ベースでとったほうがいいと思う。ただマージン率は高めで。その上で、商品構成をどうするかだな。
  • このモデルに向いた業務領域とかがあるんじゃないかなぁ。直観的に情シス部門の案件より、事業部門直轄案件の方が向いていそうな気が。
  • 開発現場至上主義で強引にやるのが向いてる、ソースコードを納品しないってそういう事だよね。クライアントにお伺いしてコミュニケーションする前提だと何も進まなそう。
  • 要件定義~リリースまでの費用をとらなかった。取るべきです。絶対。価値を提供するためには然るべき所で対価を頂く必要があります。今後どのような巻き返しをなさるのか、期待しております。
  • 一括請負契約の枠組みで、擬似アジャイルを回す。これはひとつの解にならないかなあ。リスキーだけどね。
  • このまま進むならお客さんを選ぶのがいいと思います

失敗事例を公開したことに対する賞賛 (10)

  • せきららだな…
  • ここまで赤裸々に公表するのは、とても勇気が要ることだとおもいます。脱帽。
  • 大コケしてるって事だけど、それを正直に公開したことは立派だわ。日本のSIビジネスの限界じゃないかなぁ。
  • 難しいが、この資料出したってスゴイ。
  • 同じような意味で注目されたけど上手くいかなかったスタロジのギョイゾーは顛末が語られなかったけれど、ここまでオープンにする永和さんは凄いし内容に学ぶべきところは多い。
  • ここまで書いちゃうのすげーな。でもとても大事なこと。
  • この資料、非常に衝撃的だった。中の人が..
  • うほ、めっちゃ興味ある分野。しかも、なかなか表に出ない失敗事例とくれば、時間かけてじっくり読むべし
  • すごいなこれ。ここまで出していいもんなんだ。
  • 1カ月は考えさせられるネタを頂戴した。だから失敗事例は面白いんだよ。少なくとも「永和システムマネジメント」という会社が、社歴が長い割に、非常に漸進的かつ革新的で真面目に顧客満足を考えている会社だというの伝わってきたね。

応援 (2)

  • 素晴らしいチャレンジと失敗だと思う
  • そうだったのか、今までの流れから変わる一手として興味があるだけに、このまま終わって欲しくはないな~。

期待していたのにうまくいっていないという落胆 (7)

  • 辛い感じがする
  • 永和システムのアジャイル受託開発的なビジネスが全然うまく行ってないとのこと
  • 難しい。永和さんがダメだとなんかもう辛い。
  • プログラマにとっての楽園が顧客にとってはどーでもいいという当たり前っちゃ当たり前だが悲しい現実がわかってしまった
  • つらい感じ…。お客さんを変えることができないとアジャイルって空回るし、かといって開発会社ではお客さんを変えられない。
  • 期待していただけにつらい。
  • コケそうと思いつつも期待してただけに惨敗は残念すぎる。って敗因の一つ「提案する側なのに業務知識が不足」がひどい。従来型でもコケるだろそれ。糧にならない失敗、越える価値のない屍てやつか

やっぱり失敗したかという反応 (6)

  • 「あちらを立てればこちらが立たず」を地で行った事案。そもそも先行事例が無ければ受注は難しいだろうね。
  • これ何年か前の@ITのイベントで聞いて、このやり方に付き合ってくれる企業ははてなとかドワンゴとかクックパッドとか自分のところでどうにかできるところじゃないかなと思ってたら、なんかやっぱりというか
  • 「価値創造契約」の市場価値が0だった。
  • そもそもシステム案件が減っているうえ、ダメな会社が散々安かろう悪かろうを実践してきた歴史があるのに、初期費用なしなんて信用されるわけないでしょう。
  • 「システムの価値はそのシステムがどれだけ長く使われたかではかれる」ん?そんな訳ないやろ!
  • まあ、顧客が求めているものきちんと提供できなきゃ価値にならんよね、という当たり前の話と思う。はた目で見ても無理筋だったしね

他社サービスとの対比をしてほしいという意見 (3)

  • ソニックガーデンとの比較対照が必要かな
  • ソニックガーデン社の「納品のない受託開発」と考え方は似ている気がするけどどうなんだろう。
  • 倉貫さんにコメントしてほしいなぁ。

感想 (5)

  • お客さんが何を求めているか、よりも、自分達が正しいと思うやり方、にフォーカスしてるってことよね。ふむー。
  • 要するに、社内政治的に、責任を誰かになすりつけられる事が重要だったりするという悲しい現実だね。
  • 「納品」をなくしてもうまくいってない事例だ…
  • 非常に興味深い。 agile は経営戦略なんて言われるけど、開発側の都合を押し付けるだけのものであってはいけないんですよね…。
  • これすごいなぁ

質問 (1)

  • ランニングで数十万払う仕組みなら、要件の整理やら設計、コーディング、テストまで含めると半年~1年、いやそれ以上かかるはず。その間、金貰わないで体力持つのか?途中で要件膨らみすぎて中止とかもあり得るし。

価値創造契約いいかも (1)

  • 永和さんの自己分析+プロマネのオッサンの分析の後での永和さんの取り組み次第では、ウチにすごく合いそうな気がしてきた。

お問い合わせ

こちらからお問い合わせください。 担当者より、追ってお電話もしくはメールにてご返信いたします。

おおまかな業務要件をお聞きし、本サービスを適用てきるかどうかを判断させていただきます。
審査の結果、ご意向に添えない場合がございますので、あらかじめご了承ください。