2011年9月アーカイブ

ひょんなことから、E-AGILITY協議会が開催するカンファレンスで講演させて頂く機会を頂きました。E-AGILITY協議会は、エンタープライズにおけるシステム開発のあり方をユーザ企業とベンダーの双方の立場から考えようという団体です。その第２回のカンファレンスが、10月4日（火）に開催されます。私は、その中で２番目に講演させて頂きます。

私の講演では以下のタイトルと概要で話す予定です。

「納品しない受託開発」にみるソフトウェア受託開発の未来

～IT投資に対するソフトウェアの価値を最大化できるビジネスモデルとは～

ソフトウェア開発のアウトソーシングにおける「一括での受託開発」というビジネスモデルは、多くの問題を産み出してきました。当初に決めた要件が、市場環境で変わってしまったとしても、その通りに作らざるを得ないのも問題ですし、いつまでも仕様が決まらずに開発に入ってしまい膨らみすぎた要件で赤字を産み出すのも問題です。 私たちは、そうした問題の原因は「一括での受託開発」というビジネスモデルにあると考え、新しいビジネスモデルの構築に挑戦してきました。そして、ソフトウェア開発の業界での悪しき常識「要件定義をしないと作れない」「少しずつ発注すると割高になる」などをぶち破り、アジャイル開発による圧倒的なパフォーマンスを圧倒的な低価格で提供する「納品しない受託開発」に辿り着きました。 本講演では「一括での受託開発」以外の選択肢としてのビジネスモデル「納品しない受託開発」について、実際の事例をもとに紹介します。

このブログでずっと語ってきた、ソフトウェア開発に潜む問題の追求と、それを解決できる「納品しない受託開発」という提案について、お話する予定です。無料のイベントになっていますので、ご興味のある方は是非お越し下さい。

申し込みはこちらです。　→　http://pw.tech-arts.co.jp/e-agility/index.html

定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。

ディフェンシブな開発

今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請け会社を使うことにならざるを得ず、技術力の向上を目指すプログラマにとって生き辛い業界になっています。ここに潜む問題は現場の改善で解決できるものではなく、ビジネスモデルを変えるという経営者の判断が必要になるという話を書きました。

「ディフェンシブな開発」の記事は多くの方に読んで頂き共感を得ました。あれから5年が経ち、世界は変わったのでしょうか。ソーシャルゲーム業界が台頭したことやクラウドビジネスの盛り上がりから、ITをコアコンピタンスとする企業が優秀なエンジニアを直接採用するケースが増えたことで転職ブームが起きています。また、スタートアップという言葉が流行りつつあり、優れたプログラマが自ら起業するケースも増えてきたように感じます。こうした流れは必然ですし、良い傾向だと私は思います。やはり、ビジネスモデルを変えるのは現場のエンジニアの仕事ではなく、経営者の為すべきことです。では、この5年でSI業界のビジネスモデルに変化はあったのでしょうか。残念ながら大きな変化があったようには思えませんが、それを取り巻く環境は変わりつつあります。

5年で変わったもの

2007年からの世界金融危機の影響で日本経済全体に打撃が与えられる中、SI業界を支える企業のIT投資額にも当然のように影響が出てきました。それまでは、最初に予算を積みさえすれば、大手のSIベンダーが黒字になろうが赤字になろうが、最後まで作りきってくれるというビジネスモデルでした。そのビジネスモデルでは、ユーザ企業は完成リスクを丸投げする代わりに高い費用を払っていました。リスクを丸受けするために、SIベンダーには企業体力が求められます。数件のプロジェクトを抱える企業と、数百件のプロジェクトを抱える企業があるとしたら、後者の方が丸投げをする方からすると安心です。SIベンダーはある意味、保険屋のようなものだったのです。不景気になると、そのビジネスモデルの延長上では、経営者の採るべき方針は合併をして体力を増やすことしかないのも頷けます。

しかし、不景気になったことでコストを抑えるためにも、ある程度のリスクは自分たちで持とうとするユーザ企業も出てきます。そうなれば、体力があって安心できるだけのSIベンダーは選ばれなくなります。そうしてユーザ企業からのキャッシュアウトが減ってきたことが、SI市場がシュリンクしている一因だと考えられます。それでは、このままSI業界は終わってしまうのでしょうか。否、すべての企業でソフトウェアの開発と運用のすべてを内製化することはありえません。ITそのものでビジネスをしているのでなければ、お金を稼いでいる本業があるはずで、本業以外をアウトソーシングするということは当然です。つまり、受託はなくならない。では、何が問題の本質なのかと言えば、やはり「一括で発注・請負」をする「ディフェンシブなビジネスモデル」です。

本当に「SI業界が駄目」なのか

「ソフトウェアの品質はいつ決まるのか？〜「Point of Sales」から「Point of Use」へ」という記事で書いた通り「一括での発注・請負」は製造業の発想です。ソフトウェアでこのビジネスモデルを採用したことは多くの弊害を産みました。最も大きな問題が人月という単位です。目に見えないソフトウェアを測るために「どれだけ工数がかかるか」で見積もりをするのですが、同時にその見積もりで契約では「完成責任」を負います。このねじれがある限り、エンジニアが技術力を高め生産性をあげれば上げるほど売上高が下がるという構造から抜け出せません。それ以外にも、要件定義したのに、出来たものが要件と違ってしまって揉めるなんてことはざらにあります。また、プロジェクトの途中で誰もが不要だとわかった機能であっても、要件が決まっているからと作らないといけない無駄もあります。

そもそも「SI業界が駄目」というのは何を指して言っているのか、はっきりさせておく必要があります。「一括で発注・請負」をするビジネスモデルのことを、システムインテグレーション（SI）と呼ぶのであれば、それは駄目だと私も強く思います。以前は私もそこを混同させていました。しかし「一括で発注・請負」をするというのは取引の仕方だけで、お客様が必要とするシステムやソフトウェアをプロフェッショナルとして提供するという市場は存在し続けます。目指したい姿は、リスクを理解したお客様と直接プログラマが対話をし、お客様のためにオーダーメイドで価値を産み続けるソフトウェアを作るスタイルです。それはお互いに守りに入るのではなく、ソフトウェアの生み出す価値を最大化するために、対等に切磋琢磨しあえる関係です。それは「一括で発注・請負」では出来ません。

「納品しない」という仮説

「ディフェンシブな開発」の記事を書いてから、ずっと「一括で発注・請負」ではない新しいビジネスモデルを模索してきました。その一つの答えとして「改善型開発 ～ システムを作るのではなく育てるという発想」という記事を書きました。そこで、プロジェクトの一番初めにリリースを行い、それから受発注契約を結び保守と改修を繰り返すことで、システムの改善を推進するという改善型開発という開発モデルについて提案しました。この記事を書いた時はまだ事例も作れてなく、私の仮説に過ぎず、なによりビジネスモデルまでは考えられていませんでした。その後、何度も失敗の経験と、クラウドのビジネスをする経験を積むことで、「一括で発注・請負」の問題はすべて「納品」してることに起因しており、そこで「納品しない」ことによって解決するのではないか、という仮説に辿り着きました。

「キャプション直すだけで数万円？システム開発の値段が高くなる３つの理由とは」という記事で書いたのは、IT投資のコストパフォーマンスの悪さについてです。原因は、１）ベンダの見積りにおける過重なバッファ、２）開発と運用で別の業者を利用していること、３）最大時を想定したハードウェアを購入していること、と分析をしました。実は、これらもすべて「納品」していることに起因します。納品するためには要件の確定と見積もりが必要になり過重なバッファが発生し、納品があるから開発と運用が分かれますし、納品するためにハードウェアを購入するのです。人月以外の単価ということで、ストーリーポイントやファンクションポイントなども試しましたが、結局は「金額のための見積もり」につながってしまえばうまくいきません。金額のための見積もりをしてはいけないのです。

「ソフトウェアパートナーシップモデル」

「オーダーメイドの受託」と「納品しないこと」の両立が新しいビジネスモデルの肝です。作業のための見積もりは良いですが、それを金額に換算してしまえば人月になってしまう。金額を見積もりから分離するには「定額モデル」を採用すれば良いのです。月額定額のキャップを決めて、その中で出来る範囲の開発と運用をしていくという、信頼をベースにおいたビジネスモデルです。月額定額の中で出来るだけのことをするというのは、顧問弁護士や顧問税理士のようなビジネスに近いです。私の考える「一括で発注・請負」ではない新しいビジネスモデルは、ソフトウェアのライフサイクルすべてを受け持つ顧問のようなスタイルです。顧問といっても開発と運用のために手を動かすため、内製部隊のように使うことができます。それを「ソフトウェアパートナーシップモデル」と名付けました。

この「ソフトウェアパートナーシップモデル」という仮説を立証するために、SonicGardenで試行錯誤を繰り返してきました。ここからは、今のSonicGardenで行っている「ソフトウェアパートナーシップモデル」の内容を紹介します。SonicGardenでは「カスタムクラウド」というサービス名で呼んでいました（今、サービス名の変更を検討してます）。私たちが考える「ソフトウェアパートナーシップモデル」のポイントは４つあります。「クラウドのアプリケーション」「開発と運用を分けない」「月額定額」「チーム固定」です。

「クラウドで動くアプリケーション」

まず提供するのは「クラウドで動くアプリケーション」だけに限定しています。オンプレミスで動かすということは、どこかで「納品」をしないといけなくなるからです。私たちは納品しないことを目指すので、作るものはクラウド上で動くウェブアプリケーションに限定しています。実際には、エンドユーザが利用する本番環境の他に、顧客側の仕様責任者（プロダクトオーナーと呼んでいます）が動作を確認するためのステージング環境も、クラウド上に用意します。プロダクトオーナーは、ドキュメントで仕様の確認をするのではなく、実際に動くアプリケーションで確認をしてもらいます。そして、確認が出来れば、あとはいつのタイミングでも本番環境へ反映させます。どちらもクラウドなので、リリースはあっというまに終わります。プロダクトオーナーにとっては、机上の空論で進捗や製品の確認をしなくても、実際に動くアプリケーションでいつでも確認ができるというメリットがあります。

「開発と運用を分けない」

次に「開発と運用」は分けない体制を採用しています。もし開発と運用を分ける、ということになれば、それもどこかで「納品する」ということになるからです。開発と運用を分けずに、クラウド上のアプリケーションの裏側の全てを任せて頂くというアウトソーシングになります。SonicGardenが開発と運用の両方を受け持つということは、プロジェクトに終わりがないということでしょうか。いいえ、そうではなく、そのソフトウェアが稼働し続ける限り、ずっと面倒を見続けるということです。終わりがあるとすれば、そのソフトウェアを稼働させなくなった時です。開発と運用を分けないことで、引継のためだけの無駄なドキュメントは不要になり、圧倒的なコストダウンを実現することが出来ました。

「月額定額」

そして、このビジネスモデルの最大の特徴が「月額定額」です。「納品」するということは見積りが必要ということで、逆に、納品しないことに対しては「見積りしない」ビジネスモデルにする必要があります。そこで、私たちは月額に支払われる金額の上限額を決めて、その範囲内で出来るだけの作業を実施するということにしました。月額定額にすることで、最初の大きな要件定義は要らなくなります。最初の１ヶ月分くらいの機能を決めて、順に開発を進めていき、すぐに運用に入っていきます。プログラマが作業に入っている間に、プロダクトオーナーは次の機能を決めていけば良いのです。しかも、本番で運用が始まれば、ユーザのニーズを汲み取りながら変えていけます。月額定額なので、要件はいつでも、どれだけ変えても良いのです。要件はいつでも変えても良いし、どれだけ変えてもかまいません。優先順位も変えることができます。これも大きなメリットです。

しかも、月額定額という金額を決めてしまうことで、新しい機能や要件が出た際に、ベンダの営業担当が持ち帰って見積りを・・・というようなことをしなくて済みます。プログラマに直接依頼すれば良いだけです。こうすることで、見積りをするだけの営業は要らなくなりますし、バッファを積むだけのマネージャも不要になります。プロダクトオーナーとプログラマの間には誰も入らないので、話がスピーディになります。そして、またしても大幅にコストを削減できました。プロダクトオーナーは、実際に手を動かすプログラマと直接に対話ができることで、余計な伝言ゲームがなくなることもメリットです。

月額定額にするという選択は、私たちにとって一時的な売上を捨てることを意味します。しかし、私たちはお客様と長くおつきあい出来ることを選びました。また月額定額なので、プログラマは時には、プロダクトオーナーの思いつきの機能を否定することもあります。限られたリソースを有効に使うため、本当に価値のあるものだけを作ろうと考えるのです。プログラマがお客様の立場に立って話ができることも特徴です。私たちは、お客様のパートナーとして長くおつきあいさせて頂くビジネスモデルにしたことで、お客様とともにそのソフトウェアの価値を追求します。

「チーム固定」

そして最後の特徴が「チーム固定」という点です。これまでのシステム開発では属人性を排除しようとするので、最初の提案時にエース級のプログラマが出てきたけど、実際に作業するのは別の担当者がアサインされることがあるかもしれません。しかし、SonicGardenでは「属人性」を重視するビジネスモデルにしました。契約して頂くプロダクトオーナーごとに、メインプログラマとサポートプログラマの２名をアサインします。そして、彼らはそのプロダクトオーナーの担当として、ずっと開発と運用の両方を行っていきますし、窓口自身もそのプログラマが行います。当社のプログラマは、プロダクトオーナーと対話をし要件の引き出しから、画面設計データ設計から、ソースコードでの表現まですべて行える担当者を用意しています。

「お客様にとっての内製部隊として使って頂く」

「月額定額」で「人を固定」して提供するビジネスモデルと言えば、派遣を想像するかもしれませんが、SonicGardenでは派遣は一切行いません。プログラマがお客様のところへ伺うことはしないというのが、私たちのスタイルです。ではどうするのか。ここで出てくるのが第３のクラウドです。youRoomやSkype、Pivotal Trackerといったクラウド上のツールを使ってコミュニケーションしていきます。実際のところ、移動するコストは馬鹿になりません。生産性を阻害し、移動にかかる時間もコストになり、そうしてまで移動する価値は、クラウドを活用すればなくなります。移動にかかるコストは、結果的に顧客が支払う金額の中に入っていることを気付くべきです。私たちは、そうした無駄を省くことで、圧倒的な低価格を実現しています。オプションで移動することも可能ですが、高価格になるのでオススメできません。

また「月額定額」で「人を固定」するというのは、顧客自身でプログラマを雇用して内製することに近いです。私たちは、顧客自身で内製をすることが本当は最も効率よくソフトウェアを作っていけると考えています。しかし、プログラマを雇用するのはリスクが大きいのも事実です。簡単に解雇できない雇用リスクもありますし、良いプログラマかどうか判別することは一般の人にとっては相当難しいことでもあります。私たちは「お客様にとっての内製部隊として使って頂く」ことをコンセプトに提供しています。つまり、ひとりのプログラマを雇用するよりも安い価格で、かつ、既に実績のある私たちのプログラマがチームで対応させて頂くという形です。私たちはお客様にとっての顧問プログラマになりたいのです。企業法務を担当する弁護士は、１社専属ということは殆どの会社ではありえなくて、弁護士を複数の企業でシェアする形をとると思います。私たちのプログラマも、複数の企業でシェアして頂くことで、最大のコストパフォーマンスを発揮することができます。

プログラマの努力がビジネスに反映される仕組み

このビジネスモデルでは、プログラマは技術力を高めて生産性を上げることによって、効率を高めることができ、シェアできる企業を増やしたり、自社作品のサービスを作る時間を増やすことができるようになります。そうして、自身のギャランティーを増やしたり、新しい挑戦のための時間を作ることができます。また、プログラマは移動しなくて良いので、どこからでも仕事をすることが出来ます。「『国境なきプログラマ』を目指す～ノマドワークの究極のかたち」という記事で紹介した通り、アイルランドにいながらにしてプログラマとして仕事をすることが出来るのです。

「ソフトウェアビジネスの新分類」という記事で書いた通り「ソフトウェアパートナーシップモデル」は、あの図の左上の領域（ソリューション型＆サービス型）です。この領域はまだこれからの市場です。そして私の考えでは、左下に比べて売上高では低く、その代わりに利益率の高い市場になるはずです。丸投げするのではなく、自らリスクをコントロールして価値を産むソフトウェアを作りたい顧客にとって、左下の領域で提供される品質は過剰です。左下の領域の企業にとってイノベーションのジレンマに陥っており、容易に左上の領域には移ることは難しいでしょう。

運用中心プロセスとARC（Agile/Ruby/Cloud）

このビジネスモデルを実現するのに必要なポイントをあげるとするならば、１）スモールスタート出来るように小さい状態でも動くものを素早く作り上げること、２）徐々に肉付けを行い改修していくために保守性を高めること、３）利用者が増えた場合でも容易にスケールアウトすることができること、になります。それらについて、SonicGardenでは、アジャイル開発、Ruby、クラウドによって実現しています。それを実現したプロセスが「「運用中心プロセス」という考えかた～モノ作り中心から動くサービスを中心に据えることへのパラダイムシフト」という記事に書いた「運用中心プロセス」です。

ソフトウェアパートナーシップモデルで目指すビジョン

私は、このソフトウェアパートナーシップモデルのビジネスモデルが広まることで、受託開発の業界は新しい市場が開けるのではないか、と考えています。そのビジョンでは、ソフトウェアを提供するベンダーはただ仕様通りに作るのではなく、顧客企業にずっと寄り添う形でサービスを提供し続ける関係になり、プログラマという仕事を希少価値の高い職業にすることで、プログラマで高みを目指し続けることで高い報酬を得られ、プログラマを一生の仕事にできるような業界が作られるのではないか、と考えています。そして、このビジネスモデルは、もはや只の理想ではなく、現実に契約は始まっています。

Facebookで友人が読んだ本ということで知った本。読んでみたところ、とても面白い本でした。こういう自分では見つけられない本に出会うことができるのがソーシャルメディアの良いところですね。

とても面白いと書いたけれど、この本を読んで面白いと感じるのは、時代の変化に気付いている人に違いない。そして、そういう人たちは既に本書で書かれている「アーティスト」として活動をしている人たちなのだろうと思う。こういう本の難しいところは、すでに理解しつつある人にとっては当たり前のことを明文化してくれただけとも言えるし、まだ気付いてない人にとっては新しすぎて理解しきれない、というジレンマがありますが、本書はどちらの人にとっても役に立つ本になっているように思います。

本書では、世界の市場やビジネスに変化が起きつつあり、それに伴って人々は働きかたを変えていかねばならず、そこで成功するにはこれまでとは異なる「アーティストのように、才能を全開にして働くこと」が出来る人にならなければならない、ということを語っています。

農業社会から工業社会に変わった際に、市場からは大量生産が求められ、人は独創性や自主性よりも従順な労働力を提供することが求められてきました。しかし、一部の国や市場では、工業社会から次の知識社会に産業革命が起きつつあります。人は大量に作られたものではなく、自分の感性に響くものを買うようになり、個人と個人がTwitterやFacebookを通じて知り合うことで「人を中心としたビジネス」の可能性が大きく広がりつつあります。そこで働くには、従順なだけでは生き残れません。そんな新しい時代をどうサバイブしていくかを本書で知ることができます。

目次からいくつか抜粋。

• 「モノが中心の時代」の終焉、そして「第三の世代」へ・・・（第１章）


• あなたの価値は「どれだけ個性ある能力を発揮したか」で決まる（p.35）


• 「替えの利かない人間」になれる人・なれない人の分かれ道（p.40）


• 「知識に頼る人」が危機的な状況に（p.76）


• 人の心に「感動を呼ぶ」仕事が最大の評価を得る（3章）


• 「何かを与えられる人」だけが生き残る時代（5章）


• トップダウンではもはや変化は起こせない（p.204）

ここからは私の意見ですが、工業社会が誕生したからといって農業がなくなった訳ではなく、従事する人たちの数が変わっただけで共存しています。同様に、知識社会が到来したからといって、工業がなくなることはないでしょう。工場は必要だし、そこで働く人たちも必要です。工業社会での働きかたは変わらないでしょう。しかし、知識産業が広まってきた際に、それまでと同じように働くというのは、ナレッジワーカーにとって窮屈になってくるのは間違いありません。

ナレッジワーカーにとって働くとは一体何か、本当に価値を産む仕事は何かを、企業は考えなければ生き残ってはいけないでしょう。ナレッジワーカーにとって会社にいる時間だけが仕事なのでしょうか。そうではないはずです。アイデアは考えるものではなく閃くものです。いつでも仕事だし、いつでも仕事ではないのです。そして、働く場所も同様です。ノマドと呼ばれる働きかたが広まりつつあるのは、ナレッジワーカーにとって場所は制約以上の何者でもないからでしょう。

私はナレッジワーカーが働く企業に、大企業は不要だと思っています。本書の中でも語られていますが、ダンバー数と呼ばれる組織として人間の認識できる人数の限界である150名を超えるような大規模な企業は必要ないのです。大企業は、たくさんの労働者を雇います。労働者の仕事を取り替えの利く仕事だと考えているならば、たくさんの人数を抱えていることは意味があるでしょう。しかし、ナレッジワーカーに換えは利かないのです。属人性は排除するものでなく、属人性こそが大事なのです。そうであれば、たくさんの人数は不要です。

ブルーカラー、ホワイトカラーと働きかたを分ける表現があります。ナレッジワーカーは、ただの事務仕事ではありません。デスクワークをしていればナレッジワーカーという訳ではありません。ナレッジワーカーは、新しい価値を生み出し、その人でしか出来ないことを、自分の才能と人とのつながりで実現していく人のことです。マニュアル化することができないのがナレッジワーカーの仕事です。私に言わせれば、プログラマは立派なナレッジワーカーです。プログラマのことを、ナレッジワーカーとして扱えない企業はなくなってもらいたい。

本書には、ナレッジワーカーとして働くにはどうすれば良いか、そして、ナレッジワーカーを企業側はどう扱えば良いのか、が書かれています。自分がどちらの立場であるかによって、読んだときの印象は変わるでしょう。今、企業の中で働いているけれども、時間や場所に縛られることに窮屈に感じている人、ソーシャルメディアでのつながりがビジネスになりそうなのに踏み出せない人などは、本書を読むことで、自分たちが間違っていないという実感を持つことが出来るはずです。

あわせて読みたい：『国境なきプログラマ』を目指す～ノマドワークの究極のかたち

最近のアジャイルのトレンドをキーワードで見ると「Continuous Delivery」や「DevOps」といったものが並びます。どちらも、ソフトウェアの開発だけにフォーカスをあてるのではなく、開発した後の運用にフォーカスをあてようとしています。そう、開発から運用にフォーカスが移ってきているように感じます。確かに、繰り返し作っていくということは、順に出来上がって運用に入っていくということなので納得できます。しかし、それでもまだ開発から運用に橋渡しする感じが否めません。そこで、発想を逆転してみて、運用のために開発があるのだと考えたらどうか、という話です。

「アジャイル開発」は、その名の通り「開発」という行為にフォーカスを当てています。タイムボックスをきって、イテレーションを繰り返しながら、動くソフトウェアを少しずつリリースしていく。ソフトウェアを作って、繰り返すにしてもリリースすることがひとつの到達点として考えられているので、「開発」に力点が置かれるのは当たり前のように思います。しかし、本当に価値を産んでいるのは、作っている最中ではなく、実際にユーザが利用している間の筈です。

動いていないソフトウェアに価値はありません。そうであれば、プロセスの考えかたも動いている状態を保つ「運用」の方を中心に考えた方が良いのではないか、と考えました。ここで言う「運用」は、すでに完成されたものを、何事もなく動かすことだけを表すものではなく、ユーザからのフィードバックを受けて、パフォーマンスをチューニングするのは当然のこと、機能や使い勝手なども最高の状態にするべく改善していくことも含めています。

プロセスを考えるとき、「Point of Sales」と「Point of Use」で説明した通り、ビジネスとしてどこに力点を置くかということが前提になってきます。「Point of Sales」であれば、売って検収される時がお金の発生タイミングなので、開発（モノ作り）が全ての中心にきます。つまり、一括発注/請負の世界では開発中心プロセス（Development-centered Process）の方が正しくなってしまいます。一方で「Point of Use」のビジネスでは、ユーザに利用される時が価値が発生するタイミングなので、運用（動く状態）を全ての中心に置くべきです。よってウェブのサービスをするようなサービス企業においては、運用を中心に置いたプロセスが向いているように思います。

運用を中心に考えるというのは、ソフトウェアが動いている状態を正常の状態として、その動き続ける中でどのようにユーザからのニーズや要件を反映して改修をしていくか、となります。Continuous Deliveryに限らず、小規模リリース、テスト駆動開発、継続的インテグレーション、ソースコードの共同所有などの多くのプラクティスが、「運用しやすさ」を軸にするとしっくりきます。持続可能性（sustainability）を重視するのも運用中心ならば当たり前です。開発と運用の協業というDevOpsも当然のことで、むしろ分業せずに運用担当者が開発をする位が効率的です。

このように「Point of Use」を重視するウェブのサービス企業において有効な、運用を中心として考えたソフトウェア開発プロセスを「運用中心プロセス（Operation-centered Process）」と呼ぶことはどうでしょうか。

アジャイル開発と違い、運用中心プロセスが使えるケースはあえて限られていると考えます。ターゲットはウェブを使ったビジネスで使うソフトウェアが対象になるでしょう。例えば、リーンスタートアップの中でも特にウェブのビジネスをしようとする場合には、運用中心プロセスでソフトウェアを作っていく方が良いはずです。リーンスタートアップの両輪は「顧客開発モデル」と「運用中心プロセス」です。

テスト駆動開発に初めて出会ったとき、テストから先にコーディングするというパラダイムシフトに戸惑いました。ソースコードは普通、部品を積み上げるように作っていくものだと思い込んでいたのが、機能に必要な部分から作っていくためにテストから作ることが出来るとわかったとき、自然と受け入れることができるようになりました。テスト駆動開発はゴールを先に置く考えかただったのです。運用中心プロセスも同じです。従来の開発があって運用をするという考えかたから、180度変えなければいけません。まずは動くソフトウェアの運用がありきです。

最近「アジャイル」という言葉の適用範囲が広がっているように感じています。それ自体は言葉が広がるので良いのかもしれないですが、結局「何をやったらアジャイルなのか」わからなくなる時もあります。なんでもかんでもアジャイルという風潮は好きではないのですが、それは止めることも出来ませんので、ウェブのビジネスをしている企業に特化した名前があると、背景が共有されて良いかと思いました。「ビジネス中心」が良いか「顧客中心」が良いか、など考えましたが、それらにしてしまうと、どんなビジネスでも使えてしまうので、かえってわかりにくいと考えたんですよね。

ずっと、ソフトウェアはビジネス（お金の入るところ）と、もっと密接に寄り添うようになっていくと良いのに、と考えていました。一括発注/請負の中でアジャイルをしようとするとビジネスに直結することはならないので、経営に対する現場からの改善や抵抗といった風に映ってしまい対立を産みやすいと感じています。ビジネスにもっと近づく、つまりソフトウェアへの貢献が経営にシンプルに結びつくには、ビジネスモデルを前提とした開発プロセスがあると良いはずです。まだ思いつきの域を出てないですが「運用中心プロセス（Operation-centered Process）」で考えてみるのは良いかもしれないと感じています。

「運用中心プロセス」の具体的なところはこれから考えますが、一緒に考えてくれる方がいたら是非ご意見ください。

ユーザ企業がITを活用したサービスビジネスをする場合、ソフトウェア開発を一括発注してもうまくいかないケースが多いです。また、それまで受託開発をしてきたようなベンダー企業がクラウドビジネスに取り組む場合も、苦労が多いようです。それらは「ソフトウェアの品質がいつ決まるのか」という観点から考えると説明できそうです。ITサービスを一括発注で作るのが難しいのには理由があるのです。

これまで、ソフトウェア開発は製造業だと考えられてきました。顧客から発注を受けた機能を、指定された期日に向けて製造を行い、最終的には納品をして検収を受けるという流れです。完成されたソフトウェアを受け取った顧客は、それを使い続けて、いつかは新しいものに置き換えるというサイクルになっています。ユーザ企業は作られたソフトウェアを自分たちの資産として所有するため、完成し受け取る瞬間の品質を重視します。ベンダ企業にとって見れば、それは製造業そのものです。その製造業における品質の考え方は「Point of Sales」つまり「納品時点を最高にもってくる」という考え方です。（図左側）

しかし、ソフトウェアは実際には使われ始めてから、利用者のニーズに応じて対応していかなければいけません。もしそのソフトウェアを使ったビジネスがサービス業であれば、なおさらです。サービス業というのは、無形の経験を提供する業態のことです。消費者はモノを買って自分のモノにする、というのではなく、提供された環境などを利用して便益を享受します。例えば、タクシーは購入するのではなく利用しますし、新幹線や飛行機なども同じでしょう。他に、レストランや映画館などもサービスと言えます。サービス業に共通する品質の考え方は「Point of Use」つまり「使われる瞬間を最高にする」というものです。（図右側）

サービスビジネスでは、利用者はいつでも使い始めることが出来ることが重要です。長距離の移動したいと思ったときに、それから新幹線や飛行機を作るということはありえません。また、利用するという考え方の裏側には、複数の利用者でシェアをするということが含まれています。利用者は自分にとって必要な分だけを利用することで、所有することに比べて安いコストで利用することが出来るのです。そう考えると、ソフトウェアの世界でクラウドと呼ばれている提供形態も、サービス業と言えます。ハードウェアやソフトウェアを購入するのではなく、利用することをクラウドと呼んでいるからです。

「Point of Sales」と「Point of Use」の違いは、ビジネスにおける重要視するポイントに大きく影響を与えます。製造業の場合は、一度の販売のタイミングのために品質は作りこむものですが、タイミングは一度だけなので、そこまでの工程は分業して進めていく方が効率的です。一方、サービス業の場合、常に高い品質を維持するために、工程による分業は非効率になってしまいます。これからサービスビジネスをしようと考えているのであれば、ソフトウェアを一括発注してしまうと、製造業で作られたモノを手に入れることになります。それは仕様変更に弱く、日々の改善を反映していくことは難しくなります。

ユーザ企業がITを活用したサービスビジネスをする場合、そのビジネスで重視する品質は「Point of Use」です。その基幹システムを「Point of Sales」の一括発注で作るといえば、うまくいかないのも納得がいきます。また、受託開発をしてきたベンダー企業はこれまで「Point of Sales」で培ってきたノウハウを活かそうとするので、クラウドで求められる「Point of Use」のサービスが出来なくても理解できます。

アジャイル開発の根底にある考えかたは、動くソフトウェアを作り小さくリリースを繰り返していくことです。その考えかたと「Point of Sales」の相性がよくないのはわかります。ビジネスにおいてソフトウェア開発を製造業と捉えているのであれば、製造業のエンジニアリングを追求することが正しいはずで、ウォーターフォールと分業というのは最も効率的でした。しかし、それで作られたソフトウェアは「Point of Use」のビジネスでは使いものになりません。

資金力のあるIT企業（ITを活用するユーザ企業）の多くが、優秀なプログラマを雇用して、アジャイル開発による内製化をしていこうとしているのは、こうした品質の考えかたの違いに気づき始めたからでしょう。ソフトウェアを外部から購入するのではなく、自社の中で開発することで、エンドユーザへの「Point of Use」を実現しようとしているのです。

では、そのように内製化することができないユーザ企業はどうすれば良いのでしょうか。ITを本業としない企業にとって、プログラマを雇用することは、容易に解雇できない雇用リスクもあるし、優秀なプログラマかどうか判定することも難しい。その課題は「Point of Use」を実現する納品しない受託開発で解決できると考えています。

私は、ソフトウェアの品質は本質的に「Point of Use」なのではないか、と考えています。ソフトウェアなのにハードウェアのように後から直すことが出来ないのはナンセンスだと思っています。クラウドという納品しない提供形態を採用すれば、ソフトウェアはソフトであり続けることができます。SonicGardenでは、クラウドの強みを活かすことで、一括発注/請負をしない「Point of Use」を実現する納品しない受託開発に取り組んでいます。

"Lean Startup Japan"の開催するMeetupに参加して発表してきました。（リーンスタートアップとは？） 100人以上の参加者が集まる非常に大型のイベントになっていましたが、QLiveという新しいイベント用のQ&Aサービスを使うことで、インタラクティブなイベントになっていたように思います。

私は、2009年からSonicGardenの経営をしてきましたが、リーンスタートアップを実践するために事業してるつもりはなく、自分たちなりに試行錯誤を繰り返しながら、新しいビジネスに挑戦してきました。そのプロセスは学びと改善の繰り返しで、それをリーンスタートアップと呼べるかはわかりませんが、私の経験はこれから起業しようと考えている人にとって参考になるかもしれないと思い、話すことにしました。

発表資料はこちらです。（プレゼンテーションZenスタイルなので、使った資料にキャプションを入れました。最大化すると文字も読みやすくなると思います）

今回は以下の３つの構成でお話しました。

1. 私の考えるリーンスタートアップとは


2. 私たちが経験してきたピボットの事例


3. 私の目指すスタートアップのビジョン

１つ目のテーマは、以前の記事「リーンスタートアップで小さく始めよう」で書いたことを話しました。

２つ目のテーマは、私たちが実際にピボットと呼ばれる方向転換をしながらも、徐々に前に進んできた経験を事例としてお話しました。

３つ目のテーマは、これからSonicGardenで目指したいビジョンの一つについてお話しました。私のビジョンでは、プログラマが一生プログラミングを仕事に出来る業界にすることと同時に、年齢や家族などを理由にスタートアップを諦めないで挑戦し続けられる会社にしたいと思っています。これは同じことを目指しているとも言えるし、それを実現するためのビジネスモデルと戦略は、私の中では同じ方法です。この３つ目のテーマについては、また改めて詳しく記事にしたいと思います。

ちょっと内容が泥臭すぎたのか、来ていた学生の方には受けがよくなかったみたいでちょっと残念ですが、一方で、既に起業されてる方など同じ悩みをもっている方からは共感したと言ってもらえてよかったです。

あわせて読みたい：リーンスタートアップで小さく始めよう， スタートアップにおけるネットワーキングの大切さ

これまでコンサルタントの方と一緒に仕事をする機会もあり、横で話を聞いていて、相手に伝えるのがとても上手だなぁと感心をすることがあったんですが、何度か経験をするうちに優秀な方のプレゼンテーションには共通のフレームワークがありそうだと気付きました。ここでのプレゼンテーションは、勉強会などのLTや発表というよりも、顧客にプロダクトを説明するケースです。

技術者のプレゼンテーションは、中身に詳しいが故に、どうしても「正確に伝えよう」「全て伝えよう」としてしまいがちです。もし技術者を相手にした「セミナー」であれば、それでも良いかもしれません。それも、聴く人たちが詳しく知りたいという動機をもって参加している場合です。

しかし、プレゼンテーションをする相手が、その技術やプロダクトについて詳しくなく、そのプレゼンテーションを聴いたあとに、興味をもってもらって、問い合わせなどのコンバージョンに繋げたいということであれば、正確性や網羅性の優先度は低いと考えた方が良いです。上手な人のプレゼンテーションだと「よくわからないけど凄かった」という感想が出ます。問い合わせに繋げたければ、それで十分なんです。

よくある技術者がするプレゼンテーションだと、○○とは？といった定義から始まり、全体の構造と特徴を示して、あとは一つ一つの部品と特徴について詳しく説明する資料が何枚か続き、最後にまとめ、というスタイル。これでは、興味を持ってもらえなかった場合、中だるみしてしまいます。ではどうすれば良いのか。出来る人のフレームワークに従えば良いのです。

上手なコンサルタントの方々のプレゼンテーションには共通の流れがあり、それに従って作れば、誰でもそれなりのプレゼンテーションを作ることが出来るのではないか、と考えました。その流れは以下のようなものです。

1. 問題に至る背景の共有と共感
2. 対象とする問題の提示
3. 解決につながる仮説(プロダクト)
4. それが正しい解決であるというプルーフ

まず最初に、プレゼンテーションをする相手の人々に共通する背景を説明します。これは、共感を得てもらうことが目的です。まず、相手と同じ視点を持っているということや、プレゼンテーションをする自分はどういった文脈で話すのか、ということを伝えた上で「同じ問題意識を持っているのかも」という共感を得てもらいます。これによって、聴く側は話を聞く心の準備ができますし、なによりも同じ問題意識を持っていると思ってもらうことで、対立ではなく同じ方向を向いていると思ってもらえます。

上級テクニックになると、この背景の話の中で、さりげなく数字を含んだグラフや表を入れ込みます。そうすることで、より一層、リアリティが増すので、そこで話されている背景が本当のことだと理解してもらえます。

背景を共有し、それに共感してもらえたら、次はその背景の中で起きている問題を示します。実際には、その背景からは様々な問題が出てくるとしても、それを網羅する必要はなく、ここで提示する問題は、次の自分たちで解決出来ることにフォーカスした問題だけを提示するだけで構いません。むしろ網羅するよりも、フォーカスをあてた方が良いです。聞いている人たちも考えながら聞いてくれるので、その背景から沢山の問題があることは承知の上なので、あえて自分の主張に繋がる問題だけを伝えます。

そして、その問題が的外れではなく、プレゼンテーションの相手も問題だと感じてもらえたら、それに対する、自分たちのソリューションを提示します。それは、特定の技術かもしれないですし、プロダクトかもしれません。このプレゼンテーションで興味を持ってもらいたい対象です。問題を解決するものだと提示をしますが、そうすると聞いている方にしてみると、本当かな？と思ってもらえる筈です。実はそのように疑問を持ってもらうことが大事です。疑問を持つということは興味があるということです。

そうして、ようやく準備が整いました。ここまでくれば相手は疑問をもっているので、詳しく聞こうという姿勢になってくれています。そうしたら、あとは好きなように技術やプロダクトの説明をしましょう。ここでは多少、難しい用語を使ったりしても大丈夫です。そのソリューションであるという仮説が正しいものであるという証明をするのです。機能や特徴の説明も、なぜこの問題の解決に繋がるのか？という視点から説明すると良いでしょう。

実際は、相手との関係性や、お互いの背景、プレゼンテーションの目的などによって、変えていくしかないと思いますが、こういったフレームワークも知っておいて損はないと思います。