GoTheDistance

ユーザ系SIerから全く別業種の会社で「ひとり情シス」として内製してる変わったエンジニアのブログです

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

この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。

永和さんの価値創造契約とは

新しい契約形態での受託開発サービス「価値創造契約」 | 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。

2013年営業実績、0件

資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。

受託開発の弊害と指摘される「価値あるシステムを作りたいユーザーと、作ることが目的になるベンダーとの間に生まれる、ゴールの不一致」を解決できるビジネスモデルなのに、どうして苦戦を強いられてしまったのか。僕が思うに大きな理由が3つあったと見ています。

謳ってるメリットが伝わらなかった

価値創造契約では、「いつでも解約」「初期費用無料」でソフトウエアの利用するまでの負担をかけないという点がメリットとして謳われています。しかし、資料でも言及されていますが、ユーザーにとっては全くメリットでは無かったと書かれております。解約する前提でシステムの開発依頼をする会社は無い、と。嫌な言い方をすると、いつでも逃げられるように予防線張ってるんちゃうかと勘ぐられることもあるなと感じました。

負担がかからないから良いでしょってのは、「この商品は他のメーカーより安いからお得ですよ」という話と大差がない。極端に言えば価格勝負をしている。割安という点をクローズアップしてしまうと、自分の欲しい価値がゲットできる保証になってない。その商品である理由が説明できていないし、買った後のメリットが理解できない商品を買う顧客はいない。その辺のズレがあったのでは、と。

チケット制がうざい

月額定額なのに従量課金でチケットを売ったのも非常に不自由で、個人的には気に入らない。回数制限があったら、そう簡単に変更依頼は頼めません。もし頼んだ変更を適用した結果、昔のほうが良かったから戻したいという時に新たにチケットが発行されてしまうとなると、デメリットが際立ちます。「ちょっとした機能追加にチケット追加ならやめよう」→「チケットで予防線張っといて何もしてないのにカネを取るのか」にすり替わってしまうんじゃないでしょうか。運用しているから何もしてないわけじゃないけど、心証の問題で。

後から見えない費用がかかる可能性が高いのなら、始めに一括で払ってスッキリしたいというのが一般的な感覚でしょう。

要件定義〜リリースまでの費用をとらなかった

取るべきです。絶対。

WF型でもアジャイル型でも、要件が決定しなければ次の工程に進むことはできません。特に柔軟に変化に対応することを前提とするアジャイル型の場合は、WF型よりも顧客にかかる負担が大きくなるはずです。だからこそ、期間を決めて金銭を発生させることで真摯な議論を積み重ねるようなビジネスモデルにすべきでした。要件定義が遅延すると追加料金出ますよぐらいでもいいでしょう。その後が月額定額なんだから。どの案件でも要件定義は不可避ですし、そこできっちり詰めていればフェーズ分けの議論もしやすいでしょう。

この部分が無料になってしまうと、発注側は「無料だからいつでもいいや、後から考えよう」になりかねないし、開発側は「明確な縛りがないから、詰めたくても押し切れない。非常にやりにくい。」という中途半端な状態になるんじゃないでしょうか。また、このまま進めてリリースして大丈夫かという不安にもつながります。要件定義等のコストをサービスしてしまえば開発者のモチベーションを下げる結果になるでしょう。

上記3点のビジネスモデル上の欠点が大苦戦の背景にあるのかなと思いました。

その他資料に記載されているエピソード(失敗談)は、このモデルに限ったものではないと思ったので取り上げておりません。詳しくは資料をあたってください。

今後の展開は?

どうしましょうかねぇ・・・ まぁ、頂くべき対価の設定を間違えてしまったのなら、価格体系を大幅に見直すべきでしょう。そうなると今までと何も変わらないよって話になりそうだから何とも難しいのだけれども。

長く使い続けられるシステムを育てていくことがWin-Winなのは間違いありません。でも、価値を提供するためには然るべき所で対価を頂く必要があります。今後どのような巻き返しをなさるのか、期待しております。

はてブを頂くことで生まれる悲喜こもごも

突然はてブTwitterで著名人に拾われて自分のブログに大量アクセスがやってきた・・・そんな時はどうしたら良いのか問題。

最近のはてなオフ会クラスタの方からみればお前誰だよだと思いますが、不詳ござ先輩、今まで38,000弱のはてブを頂いております。乱気流に頭から突っ込んでどーゆー感じで心のバランスを取ったのかみたいな、そんな話を連々と書きます。

はじめてホッテントリに入った時のこと

「もういいじゃん・・・」っていうのが正直な感想でした。アメリカにはSIerなんて存在しない - GoTheDistanceという記事が2007年に突然ブクマ頂きまして、色んなコメントを頂きました。コメント内容云々よりも、早くこの乱気流は終わらないかな、と。色んな人に見て頂ける事自体は嬉しくても、僕には何のメリットもなかった。ブログで商売してるわけじゃないから。

「どこまで伸びるのだろうな〜、うひょひょー」という期待感は全くなく、どこまで伸びちゃうのこれっていう焦燥感しか無かったです。

アテンションの濁流でバランスを崩す

読み手に自分の意図した通りに読み取って頂けない場合は、原則として書き手の問題です。誤解を生むような書き方が悪いと考えるべき。でも、それが不特定多数だと・・・どう対処していいかわからないんですね。

頂いた大量のコメントに目を通すと、「すいません、それ違います。こういう意味です」っていうポイントが複数生まれます。色んな人が見に来てくれるので、余計気になります。訂正・追記したりはするんですけどね。またそこでDISられるのは・・という気持ちにもなります。書いた記事によっては「ここだけは曲解してほしくない」という所もあり、そこを守るように予防線を張るとその行いがバカらしくて自分で凹んだりしました。

ホッテントリに入って1番堪えたのは、不特定多数のコメントを頂き続けると自分が否定されているような感覚になったこと。あくまで記事についてのコメントなんですけれども、「この記事なんなの」と「コイツ何なの」って非常に距離が近いのです。そこから自己罪悪感というか、そういうのも生まれた。この肌感覚はホッテントリに入らないとわからないかもしれません。

情報の取捨選択は受け手の自由

その自由を阻害したり、解釈を強要することは絶対に出来ません。

はてブで頂いたコメントを見ては「なんで言わんとしていることがわかんねーかな、随分と勝手な解釈しやがって」という苛立ちを感じていた頃もございましたが、この行いが天に唾を吐くのと同意だと気づいたら気が楽になりました。

そういう気持ちになると「この記事で伝えたいことはコレなんで、そこだけ伝われば後は何でもいいや。」という絶妙なバランスを取ることが出来るようになりました。ホッテントリに入ってから、2年ぐらいかかりましたけど。

段々と守りたい主張とツッコミ所を記事内で両立させることが出来るようになり、頂いたコメントも「あ、やっぱそこですよねー(・ω<)テヘペロ」的な感じで受け流せるようになりました。何かを主張するってことは何かしらの立脚点を持っていますので、その立脚点の違いに拠る見解のズレは当たり前のことですから。良い悪いではなくて。

その辺のやわい気持ちをまとめた記事が他人からの評価は受け止めちゃいけない - GoTheDistanceになります。よろしければ。

承認欲求

今は全く無いですけど、はてブに慣れてくるとブクマを集めることが面白くなった時期も確かにありました。このテーマの記事じゃ伸びないからやめようとか、これを記事にすれば絶対伸びるなとか、そんな打算というか。初めて1000ブクマ超えた記事を書いた時は、正直テンション上がった。

コメントに対する耐性がついたので、書く以上はいっちょやったろか的な気持ちがで出来ちゃった。書いた記事が全くブクマつかないのはつまんなくなってしまい、ちょっとかっこ悪いぐらいに思ってた時もあった。こういう気持ちのことが承認欲求なのでしょう。

しかしですね、それらの感情はブログというかネットから距離を置くとス~ッと消えていきました・・・。

もう3万8千もはてブを頂きましたので、はてブを頂くことで何かを得たいという欲求はさすがにもう無いです。ブクマページのコメントを非表示する予定はありませんのでご安心下さいませ。百花繚乱、大歓迎です。

はてブのおかげで今がある

ブログをやり続けてきた1番の理由は、やっぱこれ。近しい人・友人が見守ってくれたから。その延長線上で、ブログを見てくれて参考にしてくれた人が増えたという好循環があって、色んな出会いや機会を僕にくれました。そうなると、辞める理由も無かった。もったいなくて。

それもやっぱり自分の軸足は普段生活しているこの世界で、自分が信頼してるパートナーや理解してくれる人たちが分かってくれればそれでいいや、と気付けたからだと思います。

インターネットでは軸足をブラすと死ぬ - インターネットの備忘録

はてブのおかげで今があるし、はてなでブログをやっていて良かったです。

また、7年前からずっと記事を取り上げてくれたカリスマ個人ニュースサイト管理人である「まなめ」氏には大変感謝しております。「はてな生まれ まなめはうす育ち」と申しますか。

最近はめっきり更新ペースが落ちてしまいました。すいません。これからも頑張りますので、よろしくお願い致します。

【書評】「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

日本実業出版社の今野様より献本御礼。

「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則

なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術に続く、細川氏の第2作。前作ではITシステム開発の難しさを題材に網羅的にユーザーやベンダーがプロジェクト運営で失敗してしまうポイントを挙げられておりました。いわば、入門編という位置づけですね。本作では実際にプロジェクト運営でモメてしまう所も判例を通じて論じており、いわば「実践編」という立ち位置になっています。モメてしまうポイントを先回りして、フェーズ毎にヘルスチェックをして頂いております。

本書は女性弁護士キャラは出てきません。悪しからず。

システム開発複雑系の極み

本書ではITプロジェクト運営を成功裏に導くために、77個の鉄則(チェックポイント)を掲げてこのチェックポイントをうまく抑えておかないと水が漏れるように浸水する可能性があるぞ、という警鐘を鳴らしています。

・・・77個もあるのか、というのが僕の正直な気持ちです。請負でこのリスクを背負うベンダーはよく商売ができるなと。ディフェンシブになるのが当然。転ばぬ先の杖を提供するのがプロの仕事だから当然のことだよ。転べば転ぶほど金も時間も喰っちゃう。

MosCow分析を徹底する

僕が自社の業務システムを運営している中で感じるのが、どの課題も等しく同じ重要だと考えがちな人がとても多いこと。これでは課題管理にならない。課題管理表を回覧板にしないために、WBSの粒度(更にはタスクを定義)を決めるために最も重要なのが、本書の132pで触れられているMosCow分析だと感じました。

Must その要件が実現されなければ、システムやサービスの導入目的が果たせないもの
Should その要件が実現されなうても、システムやサービスの導入目的が果たせるが、メリットが大きく損なわれるもの
Could その要件が実現されなくても、システムやサービスの導入目的が果たせるしメリットもあるけれども、実現すれば更に大きなメリットを享受できるもの
Would 現時点で議論する必要がないもの。実現の要否判断をしたところで、導入目的にもメリットにも寄与しないもの

この区分けができていれば、課題を構造的に管理できるし、どの課題を潰せば他に影響が出るのかも議論しやすいと思う。

他人に仕事を任せることに不安な方にもおすすめ

本書は最も複雑なIT系のシステム開発プロジェクトを題材にしてモメないようにヘルスチェックが出来ますので、細かく厳密に状況を俯瞰できます。本書に挙げられた基準を元に他社様に依頼した作業の管理手法を見なおせば、ご自身のお仕事の管理効率UPにも繋がります。部下を持った、パートナーと共に働く。そういったことに、ちょっとでも不安を感じた方は一読をおすすめします。

ここから本書と関係ない話

モメないプロジェクト運営をする最適な方法を教えます

非常に簡単な事です。開発をベンダーに依頼しないで自社で開発することです。これで全てのリスクは自社内だけ。僕は本気でそう思っている。日本の会社の99%は中小企業だし、中小企業が日常的に使うシステムを作るインフラは有り余っている。弊社内製システムはVPSで動かしているので、モメるのは物理的障害(プリンタ接続)ぐらいしかない・・・。中小企業のトランザクションなど年間で1万レコードあるかどうかだし。パフォーマンスの問題などまず出ない。

オーダーしたことでコントロール出来ないなら、オーダーしてはいけない。自分でExcel/Access/各種PaaSで自作すればいい。もしくはASP/SaaSを借りたっていい。いわば、自習。Access使って簡易的システムを構築する本など巷にあふれている。これがWebベースでかつインターネット上に構築して売上を取るようなサービスになると話は別だけど、事務作業の代替手段なら自習しよう。お兄さんとの約束だ。

言い方悪いけど、素人だから生兵法は怪我の元でプロに依頼して、プロに対する仕事の依頼方法がわからずに爆死すること程、愚かしいことはない。

ソフトウェアは完全にコモディティ化しており、制作するだけならいくらでも手段がある。何百万もかける予算があるなら自習期間にお金をかけたほうが、後々IT戦略を立てる時に地に足の着いたものになります。

【書評】「納品」をなくせばうまくいく 〜ソフトウェア業界の“常識"を変えるビジネスモデル〜

著者の倉貫さんより献本御礼。

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

納品のない受託開発とは

簡単に言うと「一括請負契約をしないで、お客さんの欲しいシステムを受託開発すること」になります。何故一括請負契約をしないのかということが理解できないと、このモデルで契約する意味を感じられないでしょう。本書の主題の1つに「完成(納品)を前提とした一括請負契約がシステム開発をダメにしている」という問題意識がありますので、そこを重点的に補足したいと思います。

一括請負契約の問題点

作ることが目的になる

一括請負契約では完成責任を果たすことが求められます。その為に要件定義を行い完成となる条件を決めます。そして要件を満たすソフトウエアを作るために仕様を策定することになります。

その要件を満たす為のソフトウエアを作ることになるので、本当に顧客が必要な機能を改めて開発したり、コード上にある技術的負債を直すことにはつながりません。コストが増えるだけだからです。完成基準がどんどんブレてしまっては、何のためにその仕事を請けたのかわからなくなります。

「ソフトウエアを作ってから達成したい目的」と「ソフトを作ること自体が目的」との乖離は、必ずつきまとう問題です。

費用対効果が悪い

一括請負をするためには、不完全なリスクに対応するためにバッファを積みます。ベンダー側も必ず予定通り進むとは思っていないので予定とずれた時の為の隠し貯金を積んでいます。完成を引き受ける以上、完成リスクを負うのはベンダーですから、そのリスクを軽減するために当然のことと言えます。そのリスクを負ってしまう以上、高品質なソフトウエアを作るために必要なお金以外のコストが多くかかります。完成すればそれで終わりじゃ無いのに不必要なコストがかかってしまうことを問題視されています。

継続的な手直しが出来ない

ソフトウエアは使い込めば使い込むほど、様々な変更点が出てきます。僕は内製で業務システムを組んだのですが、その変更点は細かい使い勝手から大きなビジネスの流れをサポートする機能まで幅広かったです。改善と前提した運用が出来ることの意味を肌で感じています。進化のないシステム運用を強いられると、自社の業務やビジネスをより良くするチャンスを失うことになりソフトウエアがビジネスの足を引っ張りかねません。これでは、折角オーダーメイドで作ったソフトウエアを使い続ける意味が何なのか、わからなくなってしまいます。

ビジネスをITで成長させたい顧客に最適のモデル

上記の3つの負の側面を無くすために「ビジネスの成長に寄与しながら、エンジニアのプレゼンスを最大限高めるビジネスモデル」を倉貫さんが考案され、月額定額制の顧問プログラマを活用してソフトウエアとビジネスが共に成長することを目的とした受託開発モデルが「納品のない受託開発」であるいう理解を、本書を読んで新たにしました。必要な企業に必要なITを提供できるモデルだからこそ、優秀なエンジニアの地位も高まっていくという相乗効果についても書かれています。

ソフトウエアって経営に何の役に立つのだろうと漠然と考えられている経営者の方にも、このモデルはありがたいのではないでしょうか。発注側のリスクが殆どありません。変更OKの前提で作ってもらえて本当にそれが必要なのかどうか確認しながら月額料金だけ払えばいいというモデルは、一括請負に比べて実に頼みやすいのではと感じます。自社の競争優位をITで築くことの意味を共に考えていけるわけですし。

個人的にはビジネスに寄与できるプログラマが特に非IT企業で当たり前の存在になって欲しいので、経営の外部ブレーン(顧問)としてプログラマとしての働き方がこのモデルで更に加速することを、期待してやみません。

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

【書評】システムインテグレーション崩壊 これからSIerはどう生き残ればいいか?

技術評論社の傳様より献本御礼。

工数積算のビジネスは終わる

SIという言葉が指し示す範囲もSESから受託開発まで幅広い中で、著者の斎藤氏は「工数積算を前提としたビジネス全般、請負や準委任などの受託開発やSESや技術者派遣ビジネスも同様に崩壊に向かう」という内容の趣旨が、表紙をめくって1ページ目に書いてありました。アクセル全開です。エンジニア人月0円セールと、ござ先輩に見た未来 - 山本大@クロノスの日記っていう話もあるぐらいですからね。

崩壊に向かう理由は大きく3つあると書かれてあり、最初に挙げられている理由が「工数積算で成果保証を担保されるSIビジネスは、構造的に不幸にしかならない。」というものです。システムを欲しい顧客は「ビジネス上の価値向上」を目的としています。しかし、上限が決まっており瑕疵担保責任を負う立場のSI業者は「決められた仕様を満たすシステムを納めること」が目的となります。このゴールの不一致が構造的に不幸にしかならない理由だと説明されており、古くは2006年に現在ソニックガーデン社の代表である倉貫さんのディフェンシブな開発 〜 SIビジネスの致命的欠陥で指摘されております。色んな人がいろんな視点から同じことを言っていることに意味がありますね。

ビジネス上の価値を目的とするシステム構築が何故出来なかったのかについては、SIer/ユーザー企業双方に非があるということで、その理由については第2章で触れてあります。成果保証を求めるのにエンジニアの工数積算で根拠を出すこと自体がナンセンスではという疑問に触れながら、それにはそうなってしまった理由もあるのだということで。

3章以降は新しいポストSIへの取り組みを紹介しています。既存のビジネスがダメなら、ビジネスモデルを変えるか新しいことを始めるかのどっちかしか道がない中で、両方の道をどうやって歩むのか、実際にどういうビジネスモデルに変えた会社があるのか等、色んなヒントが書かれています。「問題認識→その背景を分析→次はこっち」って感じですごくまとまってるので、通覧するには最適の一冊ではと感じました。

が、これはちょっと待ってくれという提言がありました。「アジャイル型請負開発モデル」の提言です。

アジャイルで請負ってちょっおま

何故この提案が引き合いに出されているのかと言いますと、ウォーターフォール型のように後工程とのつじつまを合わせることが出来ないやり方は必ず歪みがでてしまう。先ほどの構造的な不幸を引き起こす一因である、と。ビジネス価値達成という共通の目標に向かって、重要な機能から先に作ってリスクを低減しながらシステムを育てることを目標に、フェーズを切ってその都度請負契約を結んでゴールの不一致から脱していこうという話でした。聞こえはすごくいいけど、積極的に請負でやろうという会社がどれだけあるのか疑問です。違う形でつじつまが合わない未来がすごく見えたし、仕様が不透明だとしたら工数積算しか出来ないと思います。2人あなたの案件に貼り付けますのでみたいな。

そういう風に考えるとはじめの1ページ目で指摘されていた工数積算前提のビジネスは崩壊するってあれ・・・という矛盾を感じました。このモデルを進めていくことで未来が明るくなるとは言い難いのではないでしょうか。

僕の考えるポストSI時代

本書でも記載がある通り、既存のビジネスがダメなら新しいことを始めるか、ビジネスモデルを改良するかのどちらかの道を取るしか無い。新しいことを始めるのはベンダーでは無くユーザー側になると見ています。新しいIT事業SIerが始めてシェアを取って新しい業界地図が出来るという未来にはなりそうもない。成長ドライバがユーザー側にあるとすれば、以下の様な未来がやってくるのではと思っています。4年前にツイートしていた自分、グッジョブ。

奇しくも昨日、ITProの名物コラム「極限暴論!」を連載されている木村記者が同じ内容の極論(木村岳史の極言暴論! - ユーザー企業がITベンダーを駆逐する:ITpro)を掲載されていました。我が意を得たり、でございました。

僕は主役が変わる未来が一番いいと思ってますが、皆さんはいかがでしょう? 本書をあたりながら次のIT業界の主役は誰になるのかを考えていくのが、一番面白い読み方だと思います。