受託開発はITエンジニアの間ではネガティブに語られることの多いビジネスモデルです。その一方で、国内IT業界で一番多いモデルでもあります。受託開発の課題解決に目を背けていては、ITエンジニアの明るい未来はなさそうです。本章では、受託開発の課題を改善すべく、「価値創造契約」という新しいビジネスモデルに取り組んだ(株)永和システムマネジメントの事例を紹介します。
はじめに
「ソフトウェア受託開発」という言葉を聞いて、読者のみなさんはどんな印象を持たれるでしょうか? 3K、デスマーチ、オワコンといったネガティブな印象を持たれる方も多いのではないかと思います。どうしてこのような印象を持たれるようになったのでしょうか?
受託開発と自社開発
ソフトウェア受託開発(以下、受託開発)はユーザのシステムを開発会社が依頼を受けて開発します。これに対して、自社開発という形態があります。自社開発とは、自社が販売するパッケージや提供するサービスを自社内で開発する形態です。
自社開発では会社間の契約の壁がないため、プロジェクト開始後も作るものの仕様やスケジュールを柔軟に調整できます。
それに対して、受託開発では契約行為をするために、あらかじめ仕様を合意する必要が出てきます。そのため、プロジェクト開始後に仕様やスケジュールの調整が難しく、何が何でも契約時に決めた仕様どおり、スケジュールどおりに完成させなければならないという状況に陥りがちです。それがネガティブな印象の元になっているように思えます。
また、受託開発はビジネスモデルが労働集約的であり、エンジニアの稼働率を上げることが売上向上につながります。逆に言うと、作業環境の効率化やエンジニアのスキルアップのために時間を使うことは短期的には売上減になり、開発会社はそういったところに投資がしづらいというのが実状ではないでしょうか。こういったところも、受託開発に魅力がない一因になっていると考えます。
ネガティブな側面ばかり述べましたが、受託開発には次のような魅力もあります。
- 受託開発では基本的に数ヵ月~数年でプロジェクトが変わっていくため、多くの顧客(ユーザ)と出会い、人脈を広げることができる
- 1つのシステムの運用や特定の技術に縛られることなく、プロジェクトが変わるごとに新しい技術にチャレンジできる
アジャイル開発から新しいビジネスモデルへのチャレンジ
筆者は 1998 年にソフトウェア業界に入り、さまざまな現場を経験してきました。仕様が契約の範囲内かどうか、言った言わないということを繰り返しているうちに、これを続けても「誰も幸せにならない」と思うようになりました。このような誰も幸せにならない開発から脱却したいという思いを強くし、アジャイル開発への興味を持ちました。そして、2005 年頃から実際にアジャイル開発に取り組むようになりました。
しかし、アジャイル開発だけですべてがうまくいくようになったかというと、そうではありませんでした。アジャイル開発で解決できた問題も多くありますが、受託開発の契約やビジネスモデルに潜んでいる問題もありました。
筆者は 2010 年から管理職として永和システムマネジメントのアジャイル開発を行うグループのグループ長になりましたが、労働集約的でエンジニアの稼働率に依存するビジネスモデルの限界はますます身近な課題となりました。
このような背景をふまえ、既存のビジネスモデルの延長ではなく、1つ上の段階にジャンプするために考えたのが、「価値創造契約」です。
「価値創造契約」の概要
当社では、2010 年 11 月に「価値創造契約」をリリースしました。まずはじめに、従来型の受託開発の契約の問題点と「価値創造契約」の概要を紹介します。
従来型の受託開発契約の問題点
ソフトウェア開発の契約形態には大きく分けて次の2つがあります。
請負契約
あらかじめ定めた成果物を完成することが目的であり、成果物に対して対価が発生する
準委任契約
知識や労働力といったサービスを提供することが目的であり、提供したサービスの割合(作業した時間など)に応じて対価が発生する
従来型の受託開発契約の創意工夫
そういった状況の中でも、当社ではさまざまな契約形態を創意工夫してやってきました。
これまでのソフトウェア業界での受託開発における一括請負契約では、納品時にユーザから開発会社に、システム開発費用を全額支払うというビジネスモデルをとってきました。しかし、受託開発における一括請負契約は要件定義が完了してから開発見積もり/契約するというやり方が当たり前となっており、仕様やスケジュールを固定せざるを得ず、ユーザにアジャイル開発のメリットを実感いただくのが難しいという課題がありました。
一方、準委任契約では発注者側に一方的にリスクを押し付ける形となり、発注経験の浅いユーザには採用しづらいという課題がありました。
パターン A 最小限のスコープを約束する請負契約
契約段階では大まかな全体像と最小限(絶対必須)のスコープを約束します(図 1)。最小限のスコープを超える部分は開発開始後に調整可能なこととします。全体像ははっきりしていないが、最低限作りたいものははっきりしている場合に有効です。
発注者側からは最低限何ができるかがクリアになるため、発注の決裁を通しやすいというメリットがあります。
図 1 最小限のスコープを約束する請負契約
パターン B 機能ごとの請負契約
システム全体を 0.5 〜 3 人月くらいの機能に分割し、優先度の高いものから契約していきます(図 2)。五月雨式に着手していくため、複数の契約が同時に走ります。
この契約をするうえでのポイントは、開発チームの人数をできる限り増減させず、固定の人数で対応できるように同時並行させる契約のボリュームをコントロールしていくことです。
図 2 機能ごとの請負契約
パターン C 短期の請負契約
1~3ヵ月単位で成果物を規定して契約します (図 3)。全体像ははっきりしていないが、短期的に作りたいものははっきりしている場合に有効です。
この契約をするうえでのポイントは、要件を先に固定するのではなく、先にタイムボックス(たとえば 3ヵ月)を決めて、その期間に入る要件を決めていきます。
単発で終わるケースはほとんどなく、継続が基本です。
図 3 短期の請負契約
パターン D 短期の準委任契約
1~3ヵ月単位で準委任契約を締結します(図 4)。たとえ 1ヵ月でも成果物を明確に規定することが難しいプロジェクトに有効です。契約期間を短くすることでユーザのリスクを最小化しています。
B2C や B2B のサービス開発や初期開発が一通り落ち着き、メンテナンスフェーズに入ったプロジェクトで多く採用されています。随時上がってくるユーザからの要望に応えていくことが可能です。
このパターンも、単発で終わるケースはほとんどなく、継続が基本です。
図 4 短期の準委任契約
いずれの契約形態も実際のプロジェクトに適用し、うまくいっています。
永和システムマネジメントのビジネスの現状
図 5 は契約形態別に見た当社のアジャイル事業部 (注 1) の売上高の比率です。この中で「コンサル/教育」を除いた部分が受託開発の売上です。全体の 3 分の 2 が準委任契約(前述の「パターン D 短期の準委任契約」)になっています。準委任契約でも、作業場所はお客さま先に常駐ではなく、お客さまのところに行ったり、自社に持ち帰ったり、プロジェクトチームの裁量で作業場所を選択できるようにしています。
請負契約も 15%ありますが、ほとんどが前述のようなさまざまな契約上の工夫を行い、アジャイル開発を適用しています。
図 5 契約形態別売上比率
図 6 は当社のアジャイル事業部が受託開発を担当しているシステムの種類です。
8 割が B2C ないしは B2B のサービスです。このようなサービス開発はリリースしてみてユーザからのフィードバックを得て、継続的にサービスを改良していくスタイルになるため、アジャイル開発との相性が良いです。そのため、お客さまからの相談も多く、ビジネスのボリュームが大きくなっています。
図 6 対象システム種類別売上比率
図 7 は営業ルートの比率です。
現在、アジャイル事業部で開発を担当しているプロジェクトの 8 割がエンジニアのコミュニティの人と人とのつながりでいただいている仕事です。ほかの 2 割もコーポレートサイトからのお問い合わせであったり、プライベートセミナーに参加いただいたのがご縁でお声がけいただいたり、他事業部から紹介を受けたりという形で、100%がプル型の営業で案件を取得しています。
これらのグラフを見ると、ビジネスは非常に順調なように見えますし、実際に順調です。しかし、前述の契約形態(4 つの工夫)はあくまでも既存の労働集約的なビジネスモデルの延長であり、稼働率に依存するビジネスモデルの限界から抜け出すことはできないと考えています。従来型の受託開発のビジネスモデルから脱却するための新しいチャレンジが必要だったのです。
このように筆者が考えていた折、当社は 2010 年に創業 30 周年を迎えました。創業 30 周年の社内イベントとして、「新規ビジネス創生事業」と名付けられた社内のインキュベーション企画が実施されることになりました。企画の応募条件は「『売上』と『コスト』が比例しないビジネスモデルであること」。B2C 向けのスマートフォンアプリや B2C 向けのパッケージ製品の企画などが出される中に、筆者は「価値創造契約」を提案し、採択されました。
図 7 営業ルート別売上比率
注 1) 当社の中で Ruby とアジャイル開発手法を用いた受託ソフトウェア開発とコンサルティングを専門に担当する組織です。
「価値創造契約」とは
「価値創造契約」とは従来型の受託開発のビジネスモデルから脱却し、開発したシステムを初期費用 0 円で提供するサービスです。お客さまにはサービス利用料という形で月々の費用をお支払いいただきます。
サービスの価値は納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的に提供されます。このことから、サービスを利用している期間に対してサービス利用料をお支払いいただく形をとっています。
表 1 「価値創造契約」と従来型契約の比較
「価値創造契約」と従来型の契約を比較したものが表 1 です。
お客さまにとっては、次のようなメリットがあります。
- 初期投資が不要なため、まとまった資金を調達する必要がない
- 一定量の追加開発についてはサービス利用料の範囲で対応できるため、追加開発のたびに社内決裁を通して、契約するという面倒な手続きを踏む必要がない (注 2)
- 継続してメンテナンスをし続けるため、短期的にリプレイスを繰り返すことなく、システムを長く使える
- いつでも解約手数料なしで解約できる(「システムができてみたら思っていたものと違った」というリスクをユーザ企業が取る必要がない)
- レンタルという形態になるため、ユーザの会社で資産化する必要がない(バランスシートの健全化に寄与する)
「価値創造契約」のより詳細な情報は、Web サイト (注 3) を参照ください。
「価値創造契約」のターゲット
B2C、B2B のサービス開発は前述の準委任契約でうまくいく(お客さまにも満足いただける) ことはわかっていましたので、これまでアジャイル開発のメリットを実感していただくことが難しかった社内システム(とくに前述の工夫が適用できないような請負契約を採用していたような受託開発)をターゲットにすることにしました。
B2C、B2B のサービス開発ではレベニューシェア (注 4) という形態がありますが、社内システムはその性格上、そのシステムによって得られたインカムを数値化することが難しいため、シンプルに毎月定額を支払っていただくという契約形態にしました。
「価値創造契約」の自信と覚悟
「価値創造契約」の最大の特徴は解約手数料なしでいつでも解約できる点にあります。このような契約になっているのには背景があります。
永和システムマネジメント(以下、文脈によって「私たち」と表記)では Ruby とアジャイル開発の組み合わせで直近 8 年間に 150 近くのプロジェクトを実施し、そのうち「使えない」「思っていたものと違う」という理由でリプレイスされたものは、ほとんどないという自信があります。
しかし、私たちにお声がけいただいた初めてのお客さまの提案/コンペに参加する際に、アジャイル開発の実績を示して、「これまでちゃんとやってきました」「今回もちゃんとやります」ということをアピールし、お客さまに信じていただこうとしても、どうしても限界がありました。失注したときに、少しでも一緒に開発をやらせてもらえれば私たちの良さがわかってもらえるのに、と歯がゆい思いをしたことは一度や二度ではありません。筆者はこの「ちゃんとやります」ということを契約の形で表現したかったのです。
「価値創造契約」のポイント
受託開発において開発を成功させるためには、発注者と受注者という関係を超えて、お互いが同じゴールを目指して協力してソフトウェア開発にあたることが不可欠です。
図 8 Iron Triangle
図8はIron Triangleと呼ばれるものです。ソフトウェア開発ではスコープ、スケジュール、コストの綱引きになります。発注者が作りたいもの(スコープ)が増えるとスケジュールやコストも増加していきます。逆にコストのキャップや決まった納期があると、スコープを一定量以下に制限しなければなりません。
アジャイル開発の Iron Triangl(Agile Iron Triangle、図9)では、従来のIron Triangleよりも、もう少し広い視野でソフトウェア開発をとらえています。スコープ、スケジュール、コストを 1 つの変数(制約)とみなし、価値、品質、制約の綱引きであると考えます。つまり、スコープ、スケジュール、コストの制約の中で、いかに価値や品質を高めるかを考えるのです。
図 9 Agile Iron Triangle
価値と言っても人によってとらえ方はさまざまです。B2C や B2B のサービスであれば、アクセス数やコンバージョン率のような KPI と呼ばれるわかりやすい指標を使って効果測定をすることができます。
しかし、「価値創造契約」がターゲットとしてる社内システムとなるとそうもいきません。社内システムはその性格的に、使ってみて効果を測定するのではなく、使う前にこのシステムを使えば業務がどれだけ効率化できるかとか、人件費がこれだけ削減できるという予測をしたうえで開発されるものです。よって、社内システムは使いながら効果を高めていくというよりも、社内業務の変更にも柔軟に対応でき、リプレイスの手間がかからず、長く使えるシステムであ ることが価値のあるシステムなのではないかと考えました。
開発期間中に、ユーザから要望された機能を入れるかどうかという場面で、従来の受託開発では追加で予算を取っていただくか、ほかの機能を削るかしか選択肢がありませんでした。「価値創造契約」では、要望された機能を入れることによって、ユーザ価値が高くなって、その機能を入れない場合よりもシステムを長く使ってもらえるのであれば、追加予算を取ることもほかの機能を削ることもなしに、要望された機能を作るという選択肢が出てきます。
「価値創造契約」は私たちにとっても納品して終わりではなく、ユーザに長く使っていただかないと、開発にかかったコストを回収できませんので、発注者と受注者が「長く使えるシステム」を作るという共通ゴールを持てる点が最大のポイントであると言えます。
注 2) サービスチケットというしくみがあり、契約期間中、毎月一定数のチケットをお客さまに発行します。お客さまは追加開発の際にチケットを使うことができます。
注 3) http://www.esm.co.jp/new-agile-contracts-service.html
注 4) 複数企業による共同事業において、得られた利益をあらかじめ決めておいた配分率で分け合う方式。
「価値創造契約」の現状
2010 年 11 月の「価値創造契約」のニュースリリース後に続けて問い合わせをいただき、合計 3 件の案件を受注しました(うち 1 件はすでに解約)。
お客さまからは次の点を褒めていただきました。
- 初期費用 0 円、月払いのサービス利用料、また使用開始後も利用年数によらず解約自由という、クライアント側としてはリスクの少ないサービス形態
- 「納得のいくシステムをできるだけ長く使ってほしい」という姿勢に共感した
- 開発開始までの着手期間が短く、開発の進捗状況を動くシステムで確認でき、要望の追加や修正を途中でも受け入れてくれる開発手法にメリットがある
- サービス利用料に見合う形で開発することが初めにはっきりしていたため、要望がその枠内に収まることを確認した時点で、ある程度安心できた
- できあがったシステムは自社内で使用する以外に使い道はなく、よく考えると所有していることにあまり意味がない。解約時にデータしか残らないが、逆にデータさえあれば次のシステムに移行する場合でも何とかなるだろうという思いで割り切ることができた
このようにお客さまから評価いただけたところがある (注 5) 反面、実際に「価値創造契約」を提案したり、サービスを提供したりしていく中で、さまざまな失敗を経験し、お客さまから厳しい評価をいただくこともありました。
また、2010 年の「価値創造契約」リリース後は多くの引き合いをいただきましたが、数ヵ月でお問い合わせが落ち着いたため、プル型の営業スタイルをプッシュ型に変更しました。前述したように、私たちは基本的にプル型の営業で仕事をいただいてきたため、プッシュ型の営業というのは慣れない試みでした。2013 年から 2014 年にかけて産業交流展への出展と約 800 社へのテレアポを行い、12 社とコンタクトを取りました。そのうち、2 社から具体的な案件の相談を受けました。しかし、目立った成果はなく、受注に至ることができませんでした。このような状況からさまざまな課題が見えてきました。
注5) http://www.esm.co.jp/new-agile-contracts-service/576/573.html
価値創造契約」の問題
(注 6)
サービス利用検討段階
①「いつでも解約できます」はメリットにならない
図 10 システム開発プロジェクトの成功/失敗の割合 (注 7)
システム開発プロジェクトの 6 割は失敗しているか何らかの課題を抱えているというレポート(図 10)があり、失敗したときに解約できることはお客さまにとってメリットになると考えました。しかし、実際にお客さま(ユーザ企業)と会って話をすると「失敗する前提でシステム開発をしない」ため解約はメリットとして社内で説明できないという声が多く聞かれました。
解約すれば金銭的な損害は受けないかもしれませんが、再び、別の会社に発注してシステムを作り直さなければならない事態になることを軽視していたことが反省点です。
ユーザ企業の情報システム部や担当者は、たとえ失敗したとしても失敗を認めることが許されないといった声も聞かれました。
②サービス利用料の設定が高い
「価値創造契約」は初期費用がかからないことがウリの 1 つです。よって、初期費用を準備できないような中小企業がターゲットになってきます。しかし、もっとも低価格のプランでもサービス利用料として月々15 万円の費用がかかります。これはターゲットユーザ(初期費用の準備できないような中小企業)の手に届かないような価格設定であることがわかりました。
「初期費用が準備できないような会社はそもそもシステム開発なんて考えない。業務システムの開発は儲かっている会社がすることだ」という声すらいただいたことがあります。
③怪しいと言われる
客さまのメリットとして「初期投資不要」「解約手数料なし」を強調してきましたが、私たちの自信と覚悟、それからリスクとそのリスクをどのように担保しているかを説明してきませんでした。そのため怪しいサービスという印象を持たれてしまうことがありました。
本記事の「『価値創造契約』の自信と覚悟」に書いたようなことをもっとお客さまに知っていただく必要があったのです。
初期開発コストを当社が回収する前に、途中解約された場合のリスクヘッジはどのようにしているのかと思われるかもしれません。前述のとおり「価値創造契約」は「新規ビジネス創生事業」という当社内のインキュベーション企画から始まったものです。この公募で「価値創造契約」が採択され、途中解約のリスクヘッジ(担保)として、1 千万円を獲得しました(会社が 1 千万円を用意しました)。
注 6) これ以降は「XP祭り2014」で発表した失敗事例を再構成し、紹介します。
XP祭り2014 http://xpjug.com/xp2014/
発表資料「俺の価値創造契約」http://www.slideshare.net/fkino/ore-no-new-agile-contracts-in-action
注 7) 調査資料の出典:The Standish Group International, Incorporated.“ CHAOS MANIFESTO 2013”, p1 http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf
サービス提供開始後
④社内のシステム化方針の変更による解約
「価値創造契約」で開発したシステムをリリースした直後、経営者(CIO)が交代し、「価値創造契約」で運用しているシステムを ERP に入れ替える方針となったことにより解約に至ったケースがあります。
お客さまの担当者とは少なくとも 3 年程度は運用する前提でスタートし、ユーザ(システムの実際の利用者)にも高い評価をいただいたのですが、経営者の交代は想定していませんでした。解約には「価値創造契約」の規定どおり、手数料なしで応じました。
ユーザが満足するものを作れば長く使ってもらえるという考えは、作る側の勝手な思い込みであることを知らされました。
⑤チケット使用に承認が必要なため、あまり使われない
「価値創造契約」では一定量の追加開発についてはチケットの範囲で対応できるため、追加開発のたびに社内決裁を通していただくという面倒な手続きが必要ないというメリットを挙げています。しかし、実際にやってみると、チケットの使用にお客さまの社内決裁が必要となり、追加開発のために予算を確保する場合と同じフローになるという状況が発生しました。
⑥「最終的な仕様は開発会社が決める」は受け入れられにくい
「価値創造契約」では開発スコープをお客さまと合意したサービス利用料のプランの範囲内に収めるために、最終的な仕様は開発会社が決めるとしています。しかし、対象としているシステム(お客さまの社内システム)の性質上、お客さまに判断を仰ぐ場面が多くなっているのが実状です。仮に開発会社で仕様を判断したとしても、使いものにならないシステムができあがってしまいます。
また、仕様は開発会社で決めると言っておきながら、知っていて当たり前の業務知識についてまったく不勉強でした。知識/勉強不足により、お客さまに確認すべきことが確認できていないことがありました。
⑦お客さまに理解いただけるドキュメントの不足
「価値創造契約」で開発したシステムは納品せず、当社の資産になるため、当社の開発者がわかるレベルの仕様書しか残してきませんでした。開発中は良かったのですが、運用が始まり、チケットを使ってシステムをより良いものにしていこうという段階になって、お客さまと共通認識を持つために必要な情報が不足しました。
上記と同様の理由で、お客さまが自分たちのシステムとして運用していくために、必要な情報が不足しました。お客さまは、自分たちの資産ではない(レンタルのような形態)とはいえ、システムを運用していく中で発生する課題を、「自分たちのシステム」として可能な限り自ら解決して使いこなしていきたいと考えていることがわかりました。しかし、お客さまに提供できるような資料を作っていませんでした。
⑧担当者変更に伴う進め方、考え方の擦り合わせの難しさ
「価値創造契約」はこれまでにない新しい契約であるため、途中でお客さまのシステム担当者が交代した場合、新しい担当者から理解を得るのが難しいです。
開発時は新しいものが段階的にできていく姿を見せながらお客さまの要望を取り入れていくため、加点法で評価していただけます。しかし、運用に入ったシステムは障害発生や過去のシステムと比較して使いづらくなったなど、減点法で評価されることが多いです。システムが運用に入ってからお客さまのシステム担当者が交代した場合、信頼を得るのが難しいことを実感しました。
⑨システム利用料に対する成果を求められる
「価値創造契約」ではシステムを初期費用 0 円で提供し、月々のサービス利用料という形で対価をいただいています。しかし、エンジニアの稼働に対する対価を支払うという考え方が抜けきらず、システムの運用に入ってから、対価に対してエンジニアの稼働が少ないという不満を抱かれるケースがありました。
⑩仕様確定や決裁に時間がかかるとチケットが失効する
チケットを使った対応を行う際に、仕様確定や決裁に時間がかかって開発開始が遅れたことによって、チケットが失効したことがありました(チケットの有効期限は 1 年)。
大きめの要望が発生したときには、仕様確定や決裁に時間がかかりチケットが失効する可能性が出てくるため、お客さまには要望を細かく区切って段階的な対応をお願いしました。しかし、段階的な対応を取った場合、受入テストや移行作業、システムの利用者への説明が何度も必要になり、お客さまに負担をかけるため、敬遠されることがありました。
「価値創造契約」の教訓
このような失敗を通して「価値創造契約」から多くのことを学びました。課題は大きく次の 3 つに分類されます。
- ニーズとサービスのミスマッチ
- ユーザから新しいサービスへの理解を得ることの難しさ
- 私たちのレベルアップの必要性
このうち、(1)の「ニーズとサービスのミスマッチ」が一番の失敗だったととらえています。当社のビジネス上の制約(解約されない長く使われるシステムをターゲットとすること)と「価値創造契約」に魅力を感じるターゲット(スタートアップのような事業)がミスマッチであり、受注につながっていない、つまりスケールしていないということです。前述のように「価値創造契約」の売上比率は全体のわずか 2%です。
(2)、(3)については「価値創造契約」に限定した話ではないと考えています。これらについては、これまでの経験を糧にすでに改善を実施しています。
なお、収益面では受託した 3 案件のトータルで黒字になっています(途中解約された案件は赤字ですが、3 案件トータルすると黒字です)。従来の受託開発の案件と比較しても、遜色のない利益を上げられるビジネスモデルであることは実証できたのですが、スケールしないことが課題であると言えます。
「価値創造契約」のこれから
サービス自体の見直しとコンセプトを守ること
「『価値創造契約』の教訓」に記載したとおり、「価値創造契約」にはニーズとサービスのミスマッチが発生しています。ニーズを見極め、サービス自体を改良していく必要があります。
サービスの改良を考えるうえで、「価値創造契約」は受託開発に対する私たちの姿勢や覚悟を示しており、「長く使い続けられるシステムを育てていくことが、お客さまとサービス提供者である私たち双方にとっての価値であり、そういった価値をお客さまと私たちが共同で創り出していく」というコンセプトをぶらさないことが重要であると考えています。広く売れるよりも、私たちのやり方に共感していただき、本当にサービスを必要としている人(これまで請負契約を採用するしかなく、アジャイル開発のメリットを実感いただけなかったお客さま)に利用いただけるサービスにします。
そして、受託開発でストックビジネス (注 8) を作っていきたいと思います。稼働率を上げることでしか売上の向上がない労働集約的なビジネスモデルから脱却し、エンジニアがクリエイティブな活動により多くの時間を使えるようにしたいと考えています。
注 8) 電気料金、電話の通話料金、Web サービスの月額利用料などのように、一度作ったしくみを利用して継続的に利益を得るビジネスモデル。
サービスづくりよりもファンづくり
ふりかえってみると、「お客さまに価値を提供したい」という思いの発端には、「アジャイル開発で」という手段へのこだわりがありました。開発をアジャイルにしたい、Ruby を使いたい、ストックビジネスを作りたいという自分たちのやりたいこと、思いからスタートしていました。「価値創造契約」をマーケットイン (注 9) で確実に売れるサービスにするというやり方もありますが、それによって自分たちのやりたいことができなくなったのでは意味がありません。
そして、「価値創造契約」のような新しいチャレンジをする際には、どんなチーム(開発者だけではなく、お客さまも含めたチーム)で対応するのかが重要になってきます。したがって、一番大事なことは自分たちのやり方やコンセプトに共感してもらえるお客さまと出会うことだと思います。
失敗事例を「XP祭り2014」で初めて発表したとき、「ここまで公表してしまっていいのか」という反応をいただきました。アジャイル事業部のビジネスは私たちにお声がけいただくお客さまの存在に支えられています。「永和システムマネジメントのビジネスの現状」にも記載したように、そのお客さまの 8 割がエンジニアのコミュニティからのつながりです。「価値創造契約」の事例や「価値創造契約」を通して得た経験/ノウハウをコミュニティの場で発表することで、支えていただいているコミュニティの人たちに現状を報告し、受託開発のこれからを考えるうえで議論の種になればという思いで、発表をしました。
今後もこのような事例や経験/ノウハウを発表していくことで、口コミや人のつながりを広げ、「価値創造契約」を必要としているお客さまに出会うことを目指していきます。
注 9) なによりも顧客ニーズを優先し、そのニーズに応えるための製品開発を行うこと。
お問い合わせ
こちらからお問い合わせください。 担当者より、追ってお電話もしくはメールにてご返信いたします。
おおまかな業務要件をお聞きし、本サービスを適用てきるかどうかを判断させていただきます。
審査の結果、ご意向に添えない場合がございますので、あらかじめご了承ください。
