(c) 2K｜写真素材 PIXTA

ソフトウェアをつくる上で「やるべきこと」は何か

ソフトウェアをつくる上で「やるべきこと」は何かをざっくりと分けてみます。

最初に、どんな困った問題を解決したいか、どんなことを便利にしたいか、といった根源的なことが思いつきます。次に、どうやって解決するか、何をつくれば良いか、というアプローチを考えます。そして、それを実際に動くようにプログラミングしていく訳です。

一人でつくる場合も、大勢でつくる場合も、実際はもっと色々あるかもしれませんが、ざっくり考えるとこんな感じで３つに分けることができます。

実際に作っていくとわかりますが、アプローチを考えることとプログラミングしていくことは一方通行ではなく、行ったり来たりで実現していくのが最も効率が良いやり方で、それはアジャイルと呼ばれています。

アジャイル開発に「外部設計」はあるのか

アジャイル開発で「外部設計」がないと思ってるなら間違いだ。「外部設計」はフェーズの名前ではなく「何を作るか」を決める役割のことだと思えば、モノ作りには必要なものだとわかる。 https://twitter.com/#!/kuranuki/status/162184317823496192

アジャイル開発では、少人数のチームで「多能工」という考えかたのもとで、一人のプログラマが多くの役割をもちます。そして、工程を分けること無く、実際に動くソフトウェアを中心に開発を進めていきます。

ではアジャイル開発で、ウォーターフォールでいう「外部設計」は無いのかというと、そんなことはありません。「外部設計」という「期間」は無いですが、「外部設計」に相当する「役割」は存在します。

「外部設計」とは「何を作るか」を決めることです。例えば、ある機能を追加しようとしたときに、どんな画面遷移をするとか、画面の中の配置はどうするとか、つまり、「プログラムをどう作れば良いか」を決めることです。それがないとモノ作りはできません。

プログラムがどのように動作すれば正しいか、を示したそれを「仕様」と呼びます。「仕様」は必ず必要ですが、それが「ドキュメント」でなければいけないかというと、また別の話です。SonicGardenの開発スタイルでは、ドキュメント化までしないで以下のようなホワイトボードで「仕様」を共有しています。この後、Pivotal Trackerにチケット化し、すぐにプログラミングに入ります。

スクラムでいうプロダクトオーナーの大きな役割の一つが、この仕様を決めることで、すなわち正解を決めることで、それはとてつもなく大変なことです。なぜなら正解と言ってもビジネス的な観点から本当の正解かどうかはわかりません。そんな中で決断をしなければいけないのは大変な訳ですが、アジャイルであれば、もし正解でなかったら直せば良いのです。

アジャイル開発が変化するビジネスに対応できるというのは、こういうことなのです。

「要件定義」とは何だったのか？

どんな問題を解決するのか、ビジョンやゴールを決める役割ですよね。「目的設定」って感じですか。 RT @toshi_yoshimoto: ちなみにウォーターフォールにおける「要件定義」は、どんな言葉がいいでしょう？ RT @kuranuki: 「外部設計」って言葉がよくないよな。 https://twitter.com/#!/kuranuki/status/162303438758219776

ウォーターフォールには「要件定義」という工程があります。それに対応する言葉があるか、というご質問に上記のように答えましたが、その後少し考えて、違うのかもしれないと思ってきました。

「要件定義」という工程は、誰のためのものだったのか、本当にソフトウェアを作る上で必要な工程なのか、常識を捨てて論理的に考えてみました。

そのソフトウェアで、どんな問題を解決するのか、どんなことを便利にする機能を作るべきか、というのは、「外部設計」で仕様を決める前に必要です。目指すゴールや、つくったソフトウェアによってなしえるビジョンを決めることと、どんな機能を作るのかを決めることが必要な「役割」です。

それを「要件定義」と呼ぶかというと違和感があります。実は「要件定義」なんてのは、一括発注で請け負いたいシステムインテグレーター（SIer）側だけの理屈ではないか、と考えています。そもそも、全ての要件を「定義」しようとするものではないのではないでしょうか。

どんな機能が必要かなんてことは、ソフトウェアを使うユーザがいる限り変わってくるし、立ち上げのタイミングか拡大のタイミングかなどのビジネスの状況によって変わってくるはずです。一度で決まるものではなく、少しずつ決めていくものです。

リーンスタートアップで言う「顧客開発」をするのは、この役割の一環です。顧客からのフィードバックを受けながら、必要な機能は何かを変えていきます。よくいうピボットするというのはこの役割の中でのことです。それ以外の変更はただの試行錯誤です。

ソフトウェアを作るためには、「仕様を決めること」「プログラミング」の他に、顧客（ターゲット）は誰かを考えて、ビジネスプランを検討し、そして出来たソフトウェアをプロモーションするという役割が必要です。それは「マーケティング」そのものです。

よって「要件定義」なんてものはなく、マーケティングがあって、それを推進するのはビジネスオーナーと呼ばれる役割だと考えています。

スタートアップするには、ハスラーとハッカーとデザイナーの３人いると良いといいます。つまり、それはこの３つの役割に相当するのです。

アジャイルの文脈であれば、下の２つの役割の中での話で、リーンスタートアップの文脈であれば、それにビジネスオーナーの役割を加えた話であることがわかります。これらを工程の期間で分けるのではなく、役割分担の中で渾然一体となって進めていくことで、ビジネスを成功させる確率を高めるように思います。

SonicGardenの「納品のない受託」ソフトウェアパートナーシップモデルでは、ビジネスオーナー向けプランとプロダクトオーナー向けプランの２種類を用意しています。くわしくはお問い合わせください。

あわせて読むと良いかも：プログラマと漫画家〜「何を作る」のか考えたいプログラマと「どう作る」を追求するプログラマ

Twitterでの質疑応答を追記しました

(c) 伊藤サトシ｜ストック写真 PIXTA

一般的には、掛け持ちや兼務は効率を落とすため悪いことだと思われていますが、私は組織にとって逆に良いことではないか、と思うようになりました。確かに、効率だけを考えたら一つの仕事だけに専任することの方が良さそうに思えます。実際に、それなりの組織になると総務や経理といった部門に分けますし、もっと大きな会社になれば人事部門、企画部門などより専門性をもった細かな部署に分かれるようになります。

しかし、そうした専門部署が会社を悪くする原因の一つではないか、と思うのです。

専門部署が無駄を生む

役割分担のしっかりした組織では、忙しそうに見えて実は暇な社員が沢山いるんです。細分化された役割と目標の中で、もし早く仕事が終わってしまったとしたらどうするか？その役割を超えて別の何かをする訳ではなく、その役割の中で品質を高めようと努力してしまうんです。世の中の仕事の大半は、80%程度の品質で済んでしまうはずですが、それ以上の品質向上を目指すのはかけるコストに対して見合う成果としては非常に小さいです。

もしExcelの見栄えを直したり、印刷物をキレイに出そうとしてる人がいたら、それは暇な人です。

実は、ソフトウェア開発でよくある「人月」の契約でも、それが起きがちなんじゃないかと思っています。発注側の意識というよりも、受注側は人数分のコストを受け取ってしまったら、他にすることもないので、それだけに専念しすぎてしまって、無駄に綺麗な仕様書とかに拘ってしまうのです。

かけもちせずに一つの役割だけでお金をもらってしまうと、それに依存せざるを得ないため、本末転倒することがおきてしまうことがあります。政治家が掛け持ちできずに選挙に当選することが仕事だと思ってしまう政治屋になるという話もよく聞きます。大企業だと、品質管理部やセキュリティ監査部といった部署がありますが、その部署の人たちにとって「取り締まること」が仕事になると、会社のパフォーマンスを落としかねなくなります。

この問題は、専門部署の人たちが真面目であればあるほど、その役割を全うしようとし過ぎて起きてしまうのです。

掛け持ちが助け合いをうむ

人がいないために、やむなく仕事のかけもちをやったりしますが、そうすると自分の役割を超えた視点を持つようになります。もちろん本業があってのことですが、組織全体のゴールは何かを常に考えていなければいけないので、お互いに助け合うようになります。それぞれの人にとって好き嫌いや得意不得意があるので、適材適所に人を配置することは大事ですが、一つだけの役割で業務分掌を決めずに、なんでもするというスタンスが助け合いの文化をつくります。

掛け持ちすると、とても忙しくなります。そこで100%の品質や成果を求めるのではなく、組織のゴールが明確に共有されてさえいれば、しなくて良いことも沢山みえてくるんです。掛け持ちしてると無駄なことをしてる余裕がなくなるんです。キレイなExcelとか用意してる暇なんて無い。大事なポイントは、すべてを100%にしないという割り切りを全員に浸透させることです。

100%を超えた掛け持ちは、ただのブラック企業の過労働になってしまいます。

また、一人に一つの役割だけしか持たないとなると、個人の目標も一つになってしまって、それに賭けるしか無いということが起きます。それが本人の頑張りだけで何とかなるのであれば良いのですが、世の中そうはいきません。掛け持ちしてれば、一つ駄目だったとしても、もう一つの方で頑張れば良いんだという気持ちも起きたりするので、精神的にも良いんじゃないかと思います。

トータルフットボールが出来るチームへ

私は、サッカーでいう「トータルフットボール」という戦術が好きで、チームとして理想的だと考えています。「全員攻撃・全員守備」の意識で、ポジションはあるにしても、ゴールのためにはお互いに遠慮しあわない。トータルフットボールは「選手一人一人が同じくらい高い技術と戦術眼を併せ持ち、なおかつかなりのスタミナが必要」ということですが、むしろ、社員にはそんな風に育ってほしいと思うし、そういうチームを目指したいと思うのです。

TwitterやFacebookで話題になっていたので興味は持っていたのですが、またイロモノなのかなぁと敬遠してましたが、違ってました。割と硬派な内容で、無理矢理こじつけた訳でなく、ちゃんとしたマーケティングの本でした。

しかも、フリーミアムやバイラルなどといった最近のウェブ界隈で行われている最先端のマーケティングをインターネットの無い時代にやっていたという話で、グレイトフル・デッドの活動を紹介すると共に、事例としてDropboxや、Yコンビネーター、Google、MySQL、Mashable、Amazonなどの話が出てきます。ここに並んでいる名前を見ているだけで読みたくなりますよね。

本書で紹介されているマーケティングは、実際はこうだったら良いのになぁと思ってしまうようなマーケティングを実際にやってみた様子が紹介されています。これまでのマーケティングの常識に従っていたら出来ないことをやってのける彼らにしびれます。

本書には共感出来るところが沢山ありましたが、中でも私がぐっときたところから、学んだことを幾つか残しておきます。

１章　ユニークなビジネスモデルをつくろう

p.62「グレイトフル・デッドは、ビジネスモデルの革新が、製品の革新と同じかそれ以上に重要であることを教えてくれる。」

彼らは、業界の常識だったアルバム販売による売上を目指すのではなく、ライブから収入を得ることに全力を注ぐというビジネスモデルの転換をしたそうです。それによって、新たな「ファン体験」を生み出すことができ、ライバルとの差別化だけでなく、バンドとファンの両方が連鎖的に恩恵をうけることが出来るようになった、と。

ここから学べることは、業界の常識に闇雲に従うのではなく、自社と顧客にとって本当の利益は何かを考え、それを実行に移すということだと思います。

４章　ありのままの自分でいよう

p.92「ファンは、グレイトフル・デッドの"偽りのない本物らしさ"に親しみを覚えた」

勘違いしがちだけど、企業としての活動は「ちゃんと」してないといけないと思い込んでるところがある。プレスリリースや広報などは特に。しかし、ちゃんとすればするほど個性がなくなってしまうのも確かで、そうでなくて自分たち自身の個性を出して良いんだということを教えてくれました。

５章　「実験」を繰り返す

p.104「グレイトフル・デッドは、リスクを取り、新しいことに挑み、失敗と成功から学び、全身し続けることを教えてくれる。」

失敗は悪いことではなく、そこから学びとって次に活かせば、それは実験なんだと言うことができる。挑戦を繰り返して、失敗から学んでいかなければ、成功は産まれないという主張は、とても共感できます。見直しのサイクルを短くして、何度も実験をしてみることが大事です。

８章　変わり者でいいじゃないか

p.133「私たちは、ある意味ではみんな変わり者なのだ。賢い会社は、変わり者を理解し、そこから市場を作り出す。」

当たり前だけど、すべての人が同じ嗜好を持つ訳ではなく好き嫌いがあって、全員に好かれるものは作り出せない。変わり者の集まりが市場になることを改めて再確認させてくれます。しかも、このインターネットの時代に本当に変わり者だけを集めたとしても、それなりの市場になるはずです。

12章　中間業者を排除しよう

p.182「グレイトフル・デッドは、自分と顧客との間にある何層もの中間業者を取り去り、顧客を直接取り込むことを教えてくれる。」

直販の方式は、本当に顧客を大事にするのならば、とても重要で、中間業者による付加価値のないマージンを搾取することを防ぐことができます。本当にその中間業者が必要かどうか考え直すべきで、今やインターネットによって様々な中間業者をなくすことが出来る時代になっています。

19章　自分が本当に好きなことをやろう

p.253「グレイトフル・デッドは、自分たちがやっていたことが本当に好きだったのでそれをやり通した。そしてもちろん、結果的に成功した。」

好きなこと、情熱を持てることを仕事にすることが、人生にとって非常に意味のあることだと思わせてくれます。そして、情熱を持って仕事をすることの方が成功する可能性が高くなることを示してくれています。

グレイトフル・デッドほどの成功までいかなくとも、好きなことを仕事にしている方が、きっとうまくいく確率は高くなるだろうし、何よりも、そうして過ごした人生の方がなんと楽しいことだろうか。

目次 こちらから引用

• 序章　「グレイトフル・デッドのライブほど素晴らしいものはない」


• PART ONE　THE BAND　バンド


• １章　ユニークなビジネスモデルをつくろう


• ２章　忘れられない名前をつけよう


• ３章　バラエティに富んだチームを作ろう


• ４章　ありのままの自分でいよう


• ５章　「実験」を繰り返す


• ６章　新しい技術を取り入れよう


• ７章　新しいカテゴリーを作ってしまおう


• PART TWO　THE FANS　　ファン


• ８章　変わり者でいいじゃないか


• ９章　ファンを「冒険の旅」に連れ出そう


• 10章　最前列の席はファンにあげよう


• 11章　ファンを増やそう


• PART THREE　THE BUSINESS　　ビジネス


• 12章　中間業者を排除しよう


• 13章　コンテンツを無料で提供しよう


• 14章　広まりやすくしよう


• 15章　フリーから有料のプレミアムへアップグレードしてもらおう


• 16章　ブランドの管理をゆるくしよう


• 17章　個人事業者と手を組もう


• 18章　社会に恩返しをしよう


• 19章　自分が本当に好きなことをやろう

• 人の縁こそビジネスの基本
• 仕組みや規則はシンプルが一番
• 変化しないことは現状維持ではない

これらの学びと、その学びから得られた2012年の行動指針について考えました。

(c) あらさん｜ストック写真 PIXTA

人の縁こそビジネスの基本

「人との出会いを大事にしましょう」なんて、みんなわかってそうなことですが、会社員をしている頃と起業してからでは、その重みが本当に違うんだと実感しています。会社員の頃は、やはり組織に属していますから、新たな出会いや社外の繋がりがなくとも「ワークする」仕事は沢山ありました。しかし起業してからというと、お客様にしても、パートナーにしても、新たに採用する社員にしても、どれも縁がきっかけで産まれています。

紹介してもらってお仕事を頂いたり、勉強会で出会った人にお仕事をお願いすることになったり。新たな出会いがあることで、思っていた未来から外れることがあるけれど、それが成長の機会だったりします。そのためには、いつもと同じ場所にいたり、同じコミュニティにばかり行っていては駄目だと気付きました。私の2011年は「リーンスタートアップ」というキーワードに惹かれて勉強会やコミュニティに参加したことで、これまでにない人たちとの多くの出会いがありました。

「新しい違うフィールドに出て行く勇気をもつこと」が1つ目の行動指針です。

そして「キープインタッチ（Keep in touch）」も大事です。一度きりの出会いはただのすれ違いに過ぎず、何度か会う機会があってこその「縁」です。これまでだったら勉強会に足繁く通うことで知り合いが出来て縁になっていくこともありましたが、最近はFacebookのおかげで縁が出来やすくなったように思います。自分のことを知ってもらっているというのは、ビジネスをしようとする際にすごいアドバンテージになります。エンタープライズ分野のビジネスでは特に、人と人の繋がりや縁が大事にされますし、これからはより一層そうなっていくのだろうと思っています。

こんな当たり前のことを今更ながら実感していますが、会社の傘から出てみないと気付けなかったことでもあります。改めて多くの出会いと縁に感謝です。

仕組みや規則はシンプルが一番

大きな会社に属していると、そこにある規則や常識が世間一般のものと同じだと思ってしまうことがあります。特によくわからないことや苦手な分野については、既に用意されたルールに従うことは簡単なことなので、つい従ってしまいがちです。起業して自分たちの会社の規則などを決める際も、元々いた会社の規則を参考にすることも考えたのですが、重厚長大すぎると気付いたのでやめました。自分たちの考える会社像やビジネスモデルにあわせて、必要最低限なシンプルなものを作ることにしました。

私たちが会社についての一般常識が少なかったことも幸いしたのかもしれませんが、会社の仕組みを決めていくにあたり、一つ一つどういう意味かを勉強しながら決めていったので、いらないものをなくしてシンプルに出来たのだと思います。そのプロセスを経たことで、これまで常識や制約だと思っていたことは、ただの会社内に限ったルールだったことを思い知りました。勿論、日本の法律から外れることは駄目ですが、それ以外はビジネスの創意工夫として色々するべきです。

起業する前に「社長は会計や資金繰りが大変でやりたかったことが出来なくなるよ」と言われたこともありました。しかし、それは真実ではありませんでした。その人たちが考えるビジネスの常識に過ぎなかったのです。何か新しいことに挑戦しようとするならば、それまでの常識だと思われていたことよりも、自分たちのビジネスについては、自分たちが一番良く知っているので、だいたいにおいて自分たちの頭で考えたことは正しかったことが多いです。

「常識を疑って自分たち自身で考えて行動すること」が2つ目の行動指針です。

慣習や常識に無闇に従うのではなく、自分たちで考えて、自分たちなりの「答え」を持っていることが大事です。会社における決めごとの全てに「何故そうしたのか？」の理由があるべきだと思うようになりました。それが会社内の哲学やポリシーになって社員のみんなに浸透すれば権限委譲も出来るようになります。しかし、その結果として、いつか今の自分たちの中ですら「会社の常識」が出来てしまう時がくる筈で、そうなったときに自分たちで自分たちが作った常識を壊していくという意思を持っていたいと思っています。

変化しないことは現状維持ではない

これも良く言われることで、ただ現状維持をしているつもりで何も変えないで安定して経営をしていくことは、実は現状維持にすらなっていないということがあります。起業したばかりの頃は混沌としていて、安定してるなんてことはなくて色々と考えて変えてくるのが当たり前で、いつかもっと安定させたいと思ったりもしましたが、世の中は自分たちだけでまわっている訳ではないので、そうそう安定するなんてことはないんですよね。

会社員でいたころは、半年や1年といった単位で評価されて、場合によっては組織変更や異動などにより数字がリセットされることもありましたが、起業するとそんなことはなくなります。年度の目標や期ごとの評価も大事ですが、その期間を走りきれば良い訳ではなくて、間違いだと気付いたり、もっと良いアイデアがあったりしたら、どんどん変えていかないといけないし、そうした方がうまくいっているように思います。

会社を経営していくと少しずつ安定しそうになりますが、いつまでも起業したてのような気持ちと状態を維持していけるようにしたいと思っています。そのために、常に会社に新たな変化を持ち込んでいきたいし、既にある仕組みを壊すことができるとしたら、それはトップにしか出来ないことです。「愚者は経験から学び、賢者は歴史から学ぶ」という言葉がありますが、歴史に学びすぎて経験できないなんてことの方が実は愚かで、変化をするためには経験しないとわからないことが多いはずです。

「変化するために新たな経験に投資していくこと」が3つ目の行動指針です。

経営するということは、会社がもつ経営資源をどこに賭けるか（投資するか）を考えることだと思っています。お金を生み出す営業活動や制作といった仕事をすることも大事なことですが、生み出された資源をどう使うかを考えることこそが経営者の仕事になるんだと思います。会社を立ち上げたばかりで大きくないうちは、次の半年や1年先のために何にどれくらい賭けるのかを考えるので精一杯です。しかし、この先経営をつづけていくことで、10年経ったときには、そこから10年先の未来のために賭けれるような会社にしていきたいと考えています。それが会社の成長のような気がします。

社内ベンチャーだったSonicGardenをMBOして、株式会社ソニックガーデンを起業したのが最も大きな変化ですね。会社を退職するという経験も産まれて初めてしましたし、自分の会社を持つということも初めてでした。

1年前の今頃には、すでに会社を作る企画は動き出していたので、今年の動きは自分自身で驚きがあるかというと、元々の想定からそこまで大きく違ったというとそんなことはないですが、結果としては想定よりも一層前向きに進んだように思います。

今年はこれまで以上に沢山ブログを書いた年でもありました。沢山アクセスを頂いた記事を1位から5位まで紹介しながら、ふりかえってみたいと思います。

1位：モチベーションの源泉：何のために働くのか、転職か起業か

この記事を書いたのは7月7日で、事業のMBOが成立するまでは非公開だったのですが、既に株式会社ソニックガーデンを設立した後だったんですね。今回は起業するにあたって、一人で始める訳ではなく、仲間とともに立ち上げたんですが、仲間たちのモチベーションの源泉を深く考える機会があり、それを記事にしたのでした。とても頼もしい仲間たちがいたからこそ、起業することが出来たと思っています。

2位：オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来

起業するにあたって、やはり自分がずっと考え続けてきたソフトウェア開発の理想的なあり方を追求したいと思い、仲間たちやお客様とディスカッションを繰り返し、考え抜いて作り出したのが「納品のない受託開発」という「ソフトウェアパートナーシップモデル」でした。このビジネスモデルがあったからこそ起業できたとも言えますし、起業したからこそ、このビジネスモデルが実践できているとも言えます。

3位：写経で身につけるプログラミングの基本

SonicGardenではコンサルティング事業の一環として教育事業も行っています。アジャイル開発やRubyでのプログラミング、クラウドでの運用経験などを身につけてもらうものですが、少し普通の教育プランと違うのは、研修スタイルでも、コーチングのスタイルでもなく、SonicGardenのオフィスにきてもらってOJT形式で、一緒に働く中で身につけてもらうというものです。そのOJTの中で考えたことを記事にしました。

4位：『国境なきプログラマ』を目指す～ノマドワークの究極のかたち

SonicGardenのプログラマは、本人の希望によってはノマドでタイムフリーな働きかたが可能です。その最たる事例を紹介したのが、この記事です。海外で働きたいという本人の希望があり、アイルランドに移住しつつ、SonicGardenの仕事をしてもらうというスタイルを実現させました。このスタイルは、これまでの組織の形や契約形態では実現しえなかったことかもしれません。これも起業したことで得られたことの一つです。

5位：株式会社ソニックガーデンを設立しました〜退職から独立の経緯と起業への思い

独立をして株式会社ソニックガーデンの設立が出来たことが、今年の一番の出来事として残っています。私自身は、経営者として大きな賭けに出るタイプではなく、石橋をしっかり叩いてから新しいことに挑戦するタイプだと認識しています。なので、それほど大きな賭けで起業した訳ではないですが、それでも思い切ったことには違いありませんでした。

私が成し遂げたいビジョンのために起業する選択とその実現まで辿り着けたのは、多くの方との出会いがあったからで、厳しい意見や暖かい応援、どれもが私の中で力になっています。

今年もありがとうございました。来年もよろしくお願い致します。

良いお年を。

ずっと以前は開発合宿をしていた時期もあったのですが、あれは結局は日常の仕事がそれほどエキサイティングでなかったり、日々の仕事場では会議や電話取りなどがあって開発に没頭できないなどの理由があればこそ価値があったのかもしれません。しかし今の私たちの開発スタイルは、毎日が無駄な会議もなく開発に没頭できるようになっており、もはや毎日が開発合宿のような状態になってしまったので、あえて開発をするためだけに合宿をする必要はなくなったのでした。

そうして開発合宿は必要なくなったのですが、開発合宿中に朝昼晩と一緒にご飯を食べたり、お風呂に入ったりしながら話をする時間というのは、実はチームで一体感をもつのに大事な要素でした。そこで「ビジョン合宿」と称して、徹底的に語り合うことだけをする合宿を定期的に開催するようにしたのです。

どんな場所とスケジュールだったか

今回の合宿では、三浦半島にあるマホロバホテルを利用しました。5名部屋を予約しましたが、部屋は非常に広く、会議用のスペースとディスカッションできる円卓があり、ホワイトボードのレンタルも出来て、とても集中して議論ができる環境でした。そして、京急で品川から１時間でいけるというのも大きなポイントで、午前中から議論を開始できます。また食事も美味しく、三浦海岸のマホロバは今までいくつも行った合宿場所の中で、一番よかったと思います。おすすめです。

特に、部屋の中にある円卓のテーブルが議論をする際に非常によかったです。四角いテーブルではなく、全員がお互いのことを見て話すことができる円卓は、全員が対等に発言できる権利をもっているような印象を与えてくれて、とても活発な議論ができたように思います。今度オフィスを移転する際は、ぜひ部屋の真ん中に円卓をおけるような広さのところを検討したいと思うほどでした。

当日の朝に現地集合し、まるまる一日中ディスカッションできるようにスケジュールを組みました。マホロバは午前中からの早めのチェックインも対応してくれました。昼食と休憩は挟むとはいえ10時から18時までのディスカッションは相当ハードですが、普段そこまですることがないので、合宿ならではということで徹底的にやっています。18時からは風呂に入って食事、レクリエーション、そして宴会で一日目が終わります。２日目は、9時から11時まで最後のまとめとふりかえりを行い、それでホテルをあとにしました。

ディスカッションでの気づき

SonicGardenでは普段から情報共有やビジョンについても話し合ったりしていますが、それでも本人の成長や環境の変化などがあって、少しずつズレたり思うところが出てきたりするものなので、定期的にそうした思いをチームで共有して、改めてチームのビジョンを自分のものにする必要があると考えています。それがビジョン合宿の目的になります。

午前の部では「ビジョンの共有」というテーマです。SonicGardenは7月が期初めなので、この12月末で上期が終わるというタイミングでもあるので、先ず最初は、会社の上期終わっての顧客獲得数や売上高、コスト、利益などといった計数についての共有を行います。基本的にプログラマに対しても、計数情報はすべて社内ではオープンにして誰でも見えるようにするという方針でやっているので、いつでも見えるのですが、あえてプログラマが数字を毎日意識することはないので、こういう機会に説明して共有します。プログラマも数字を理解し意識することで、普段の働きかたの中から全体を意識した行動ができるようになると考えています。

会社の計数を共有したら、そこからビジョンの共有に入っていきます。具体的にはSonicGardenのコーポレートサイトに書かれている内容を改めて読み返しつつ、それについてのディスカッションを交わしていきます。このビジョンの共有のタイミングで、以前からのお決まりですが、社長である私はその議論に参加しないというのをやっています。議論に参加しないだけでなく、部屋からも出て行ってしまって、そこでの議論は聞かないようにしています。これは、やはり普段だったら言えないことを言えるようにするというのと、ビジョンの共有と言うとどうしてもトップダウンに伝えることにしてしまいがちなんですが、それでは腹に落ちないことも多いので、自分たちで考えてもらって認識のあってるところ違ってるところを共有してもらうというやり方をとっています。

なので、午前中は私は三浦海岸をぶらぶら散歩などしてました。

ディスカッションのポイント

午前中のビジョンの共有のポイントは「成果を出そうとしない」ということで、それを最初に明言しておき、全員が言いたいことが言えたら良いというようにしています。ついつい会社の議論だと成果や正解を出そうとしてしまいがちですが、そもそもその前提となるところ、思いの部分の共有はロジカルに理解することよりも、もっと泥臭いやり方の方がしっかりと共有できるものだと思います。

午後は２つのテーマで話し合ってもらいました。「競合に勝つにはどうすればいいか？」と「新しいサービスを生み出すには？」というテーマです。このテーマ出しだけは私がやりますが、そこから先の議論は、午前と同じくみんなで考えてもらいます。午後はさすがに部屋から追い出されることはないのですが、それでもみんなに考えて話してもらうことが大事なので、なるべく私が発言しないようにしないといけません。ただし、発言しない人が同じテーブルにいたら気を使ってしまうので、私はここはあえてだいぶ離れた場所で、議論を聞きながら仕事をしていました。私は各人が話してる様子を見ることで、会社がどういう状態かを把握しようとします。

午後のディスカッションのポイントは「時間をきってしまうこと」ということで、必ずしもベストな回答が出なくても時間がくればまとめるようにします。そうしないとずっと考えてしまうことになるし、長いこと考えたからといって良い答えが出る訳ではないので、時間を決めておき、その時間がきたら議論は終了させます。

宴会とレクリエーション

風呂の後は宴会です。今回の合宿は年の暮れということもあり、会社の忘年会も兼ねてます。こうしてお酒が飲めるというのも、ビジョン合宿の良いところです。開発合宿で来ていたころは、合宿中になんとか作らないとという気持ちばかりで、夜にお酒飲むとかできなかったものでした。

宴会のあとは、恒例になっていますが卓球大会をしてから、続きは部屋飲みです。ウノをしたりスティックボムをしたり、楽しく夜は更けていきます。部屋で呑むといいのは、そのまま寝てしまえることですよね。

ソニックガーデン検定の実施

SonicGardenでは人月ではないので、プログラマの生産性については個人個人が別々であるという前提でいます。なので、ルールを用意して生産性を揃えることは考えていません。とはいえ、それぞれのプログラマの生産性はどれほどのものか、というのは常に把握していなければいけません。そこで、一つの試みとして、ソニックガーデン検定を実施しました。

今回のソニックガーデン検定は、合宿の15日ほど前から、ある特定のアプリケーションを全員でいっせいに別々に開発を行い、そのお披露目を合宿で行うというものです。同じアプリを、同じ制限時間の中で開発することで、それぞれの持ち味や性質などがわかるようになるという狙いです。

今回は、Foursqareをモチーフにしました。すでにあるサービスの完コピを課題にすれば、仕様をどうするかで悩む必要はないですし、外から使ってみながら内部のモデル構造を考えながら作らないといけないので、データモデルを考える訓練にもなります。バンドで言うと耳コピみたいなものでしょうか。

4人のプログラマでエントリしましたが、四者四様のプログラムが出来上がり、発表はかなり楽しめました。全員が12時間以内程度で、iPhone用のインタフェースでのチェックインが出来るような一通りのものが出来上がったのを見るのは心強い思いでした。

ふりかえりと宣言大会

2日目の午前中の9時からチェックアウトの11時までは、合宿そのもののふりかえりと、宣言発表を行います。合宿1日目の午後に話し合った経営戦略について、具体的なアクションとしてどうするかをまとめます。2日目の午前は、私も参加します。ようやく円卓に入って一緒に話をします。特に、みんながまとめてくれた意見に対して、私としてはどう考えているかを話しをします。

一通りのまとめとふりかえりが出来たところで、次は各自で次の半年にすることの宣言をします。宣言のフレームとしては「この半年間でわかったことは何か？」それを受けて「次の半年にやることは何か？」そのために「みんなに協力してほしいことは何か？」の３つです。最後の「みんなへのお願い」があるのが、ひとりでやるわけじゃない感じがして気に入っています。

大企業ならともかく、ベンチャーや小さな会社の場合、ビジョンの共有などといったまどろっこしいことはあまりしなくても、わかりあえて進めていくことは出来るかもしれませんが、私としては、小さい組織だからこそ話し合うことが大事だと思っています。

こうした合宿は必ずしもすぐに成果が出るものでもないので、ついおろそかにしがちですが、人が一緒に働く上で、お互いの気持ちや考えていることなんかをしっかり共有しておくことは、情報共有なんかよりもずっと大事なことなんです。

ソーシャルメディアをツールでなく人で解説した本

本書は、ソーシャルメディアを題材にしていますが、テクノロジーの本ではありません。ましてや、巷にあふれるFacebook/Twitterの操作本でもありません。本書では、ソーシャルメディアを活用する「人」とその人が起こしたムーブメントにフォーカスを当てた本です。そして、ソーシャルメディアにおける本当の主役はツールではなく、それを使う人々であるため、とてもまっとうなソーシャルメディアの解説本と言えます。

本書のタイトルになっている「ドラゴンフライ エフェクト」とは、「焦点（Focus）」「注目（Grab Attention）」「魅了（Engage）」「行動（Take Action）」の４つのスキルを上手に活用することで、成し遂げたい目標のためにソーシャルメディアの力を活かすことのできる手法のことです。それらの原則とスキルはあたかも、蜻蛉（ドラゴンフライ）の４つの羽に喩えられ、うまく調和させることで、ソーシャルメディアにおける自分の意思を大きな波紋にすることが出来ると主張しています。本書では、そのソーシャルメディアで起こった波及効果について、様々な事例を交えて説明しています。

ソーシャルメディア活用をデザイン思考で解説

また本書の特徴は、デザイン思考を活用して手法の解説をしています。前述の４つのスキルには原則という形でまとめられています。原則の名前だけ抜粋して紹介します。

・焦点（Focus）：焦点を絞るためのデザイン原則
　１）人間的（Humanistic）
　２）実行可能（Actionable）
　３）検証可能（Testable）
　４）明確（Clarity）
　５）幸福（Happiness）

・注目（Grab Attention）：注意を引くためのデザイン原則
　１）私的に
　２）驚きのあることを言う
　３）メッセージを視覚化する
　４）感覚に訴える

・魅了（Engage）：魅了するためのデザイン原則
　１）ストーリー（物語）を語る
　２）共感する
　３）信頼を得る
　４）メディアを組み合わせる

・行動（Take Action）：行動を起こさせるためのデザイン原則
　１）簡単にする
　２）楽しくする
　３）相手に合わせる
　４）オープンにする

キーワードだけですが、ソーシャルメディアを活用するにあたって重要であると感じられるものが並んでいるのがわかります。ソーシャルメディアならではのマーケティング術を身につけることができると思います。ソーシャルメディアのなかった時代のマーケティングから、ソーシャルメディアを活用するマーケティングに時代が移るとして、本書を読むことで、ソーシャルメディアを活用する上で重要なことは、ひとりの人間の人間性や意思の力だと再認識させてくれます。これまでよりも、よりコンテンツを発信している「人」の顔を前面に出すことで、興味・関心・共感を得ていくことが出来ます。

ストーリーの力

私が特に勉強になったと思うのは、「魅了」の原則１の「ストーリーを語る」でした。ユーザへの情報提供は、きれいに整理された情報や、きれいにライティングされた文章があることの方が大事だと思っていたところがありましたが、それも大事かもしれませんが、それよりも物語として相手に伝えることの方が記憶に残りやすいし、興味をもってもらいやすい。確かに、営業マンがパンフレットを持って説明に来るより、創業者が何故その事業を始めたのかを知れた方が、購買につながりそうに思えます。

本書を通じて、ソーシャルメディアの活用方法を学ぶことが出来ますが、そこに書かれたストーリーとしての事例を読んでいくことで、世界を良くしようと働きかけた人たちの思いに触れることで、幸せとは何かを考え直すきっかけも得ることが出来るでしょう。自分の死に直面しながら、世界を良くするために動き、そこにソーシャルメディアがあったことで、何倍にも大きな波を起こした人たちのストーリーは、読んでいて胸にこみ上げるものがありました。

世界をよりよくする

ソーシャルメディアで世界が良くなる訳ではないけれど、人の意思が思いのほか速く広まるようになったのは事実。ソーシャルメディアのプラットフォームは今後変わるかもしれないけど、それを活用できるように人は進化していくのでしょうね。世界はフラットにシンプルになりつつあり、権威や財産を持たなくても人々の協力を得られるようになってきている息吹を感じることができました。

本書を読んだあとは、自分でも何か行動したいと思うようになると思います。そこで必要なのは目標、それも「意義ある目標」です。なにかを為そうとするときに、これまでよりも早く大きく波及効果をもたらすことができるようになったとはいえ、為すべきことがなければ始まりません。実はそれを見つけることが一番難しいのかもしれませんが、それも実はソーシャルメディアで誰かの活動や思想を見てヒントを得られるかもしれません。

私の会社であるSonicGardenもFacebookにファンページがあります。SonicGardenのビジョンは、ウェブサイトに掲載していますが、私たちの思いに賛同してくれファンページでLikeを押してくれた皆さんとは、メンバーのページに並べて表示するようにしました。まずは行動ということで、ぜひ「Like!」をお願いします！

(c) izyu｜写真素材 PIXTA

プログラミングは知識だけでは駄目

まず、プログラミングをしたことのある人ならわかると思いますが、プログラミングは知識だけを身につければ出来るようになるものではありません。学校教育における歴史や地理のように猛勉強で覚えれば出来るようになる訳ではないです。もちろん、学ぶプログラミング言語の文法や基本的なAPIについては覚えているにこしたことはありませんが、それらを覚えることはそこまで重要ではありません。プログラミングは、自転車や自動車に乗るといったような身体性の技術に近いと思っています。動かしてみて、試してみて初めて身に付く感覚です。通勤の電車の中で一生懸命、プログラミングの本を読んだとしても、さほど効果は薄いでしょう。

そんなプログラミングを身につける効率のいい方法は、自分自身でプログラムを書くことですが、そうは言っても初心者にとっていきなりプログラムを作ることは難しいです。プログラミングの難しさには、「何を作るか」と「どうやって作るか」の２つの問題が隠されているからです。その辺りについてはプログラマと漫画家〜「何を作る」のか考えたいプログラマと「どう作る」を追求するプログラマで書きました。プログラミング初心者はまず「どうやって作るか」を身につけるべきです。そのために出来ることは、チュートリアルのように実際にプログラムを作っていく内容の本を買って、そこに書いてあることを、自分自身の手で打ち込んでみることです。プログラマの間では、それを「写経」と呼んでいます。

写経しながら少しずつ変えていく

写経の大事なポイントは、自分の手でソースコードを打ってみて、実行してみるということです。そうすることで、プログラムが動く感動も味わえますし、もし動かなければどこが悪ければ動かないのかを知るきっかけになるからです。おそらく、どんな言語でも最初は"Hello World"を表示することから始めたはずです。そのプログラムの表示する文字列の部分を変更していくことで、どこを変えれば、どこの振る舞いが変わるのか、を学ぶことができたはずです。同じように写経をしながら、ソースコードの一部を変えながら、動きがどう変わっていくかを試していくと、より良いでしょう。プログラミングの良いところは、どんな失敗をしても、そこで損失するコストがゼロに近いことです。どんどん試すべきです。

どのプログラミング言語を選ぶ？

最初はソースコードの全ての意味がわからないことがあっても、何度も写経していくことで、そこに書かれたソースコードの意味を理解していき、最終的に見本を見なくても同じソースコードを書けるようになることが最初の目標です。プログラミング言語は好きなもの、好みや今後の就職先などを考慮して選べば良いと思います。もし私に聞かれれば、Rubyをオススメします。Rubyの良いところは表現力が豊かなので、初心者は初心者なりの書き方、上級者は上級者なりの書き方が出来るところです。ただ沢山のライブラリを覚えれば良い訳ではなく、慣れてくれば慣れてくるほど自分自身で上達した感じを持てることがいい点だと思っています。とはいえ、プログラミング言語は宗教論争にも喩えられるほど好みの問題でもあるので、必ずしもどれがベストということは言えません。

写経を続けていきながら、並行して、自分で作りたいプログラムを作っていくと、理解がより進みます。オリジナルのプログラムを作っていくのにあたり、わからないところや、参考にしたいソースコードを必要とする場面が出てきますが、その際に自分で写経したプログラムがサンプルになります。プログラミングの初級者のうちは、自分のストックとして沢山のサンプルコードを持っておいた方が良いでしょう。また、自分で作りだすと、作りかたで難しいところが出てきます。そういうときの為にTips本もあると良いです。例えばRailsのアプリを作るのであれば「Rails3レシピブック 190の技*1」という本がオススメです。（電子書籍もありますね）

*1 Amazonのリンク最新版に変えました

写経の次の段階に進む

自分でプログラムが書けるようになってきたら、その先本当にレベルアップをしたいのであれば、自習だけで続けるのは難しいかもしれません。ソースコードの書き方に正解はありません。正しい書き方というのはないのですが、熟練者であれば、保守性の高いソースコードや、可読性の高いソースコードなどの観点からは優劣を付けることはできます。初心者のうちは、その優れた書き方を知る術はありませんが、自分で作ったソースコードを、熟練者からコードレビューをしてもらうことで「良いお作法」を身につけることはできます。もし身近にコードレビューをしてくれる熟練者がいない場合は、勉強会などに参加して、題材に自分のソースコードを出してみるのも良いかもしれません。コテンパンにのされてトラウマになるかもしれませんが・・・

この学習法は、いわゆる「守・破・離」の「守」を実践する方法です。まずは、お手本の通りに打ち込んでみる。それもお手本を見るだけでなく、自ら実践してお手本通りに出来るようになる。そこから、少しずつソースコードを変えていき、自分の理解を深めていく、というやり方です。ただ、プログラミングの学習としての写経の良さは、そんなご大層なものでもなく、ベーシックマガジンという雑誌を知ってる世代であれば、印刷されて掲載されているソースコードを目で見ながら、自分のMSXなどのパソコンに打ち込んだ経験があるはずで、その時の経験って、とても良いプログラミングの勉強になってたと思いませんか？

SonicGardenの実施するソフトウェア受託開発の新しいビジネスモデル「ソフトウェアパートナーシップモデル」についてわかりやすく紹介して頂いています。

もしお手元にお持ちの方は、ぜひご覧ください。

私の講演では、これも先日ブログで書かせて頂いたオフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来をベースにして、私自身の自己紹介から、ソフトウェアパートナーシップモデルについて、そして、そのビジネスモデルの先に考えているビジョンについて、お話させて頂きました。発表資料は以下です。（いつものSlideshareが調子わるすぎるので、Scribdというサービスに乗り換えました。）

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

当日の私の発表時間が50分程度に対して、50枚近くのスライドを用意しています。途中、プレゼンテーションZenスタイルのスライドも沢山あるので、さくさく進むとはいえ、かなり早口で講演させて頂きました。これは、最近の私のマイブームなやり方なんですが、ブログで詳しい内容は説明しますし、スライドも公開するので、発表の時はテンポを重視してなるべく聞いて楽しく、めまぐるしく進む位で眠くならないように、一種のパフォーマンスとして早口でプレゼンテーションするというのを試しています。参加された方の感想も聞いてみたいところです。

喋りで資料に書いてないところもだいぶ補足していますし、Q&Aを通じてご紹介できた内容もあるのですが、そこはご参加頂けた皆様の特典ということにしておきます。当日の様子はTogetterでTweetをまとめてくださってます。この記事の最後に付けておきましたので、こちらも雰囲気の参考にしてください。15時くらいからが私の発表です。この資料であればいつでも講演しますので、お気軽にTwitterやFacebookなどを通じてご相談ください。メールは kuranuki_at_sonicgarden.jp です。

依田さん、E-AGILITY協議会の委員会の皆様、今回は講演の機会を頂き、本当にありがとうございました。私が今回講演させてもらって一番嬉しかったのは、匠BusinessPlaceの牛尾さんは、お互いがまだ若かりし頃に、私の脳にかかったブレーキを思いっきり壊してくれて、私に外に出て行く勇気を与えてくれた方で、その牛尾さんに「脳のブレーキを壊してくれた」と喜んでもらえたことでした。10年近くかかってようやく恩返しができた気持ちです。ありがとうございました。

プレスリリース：「株式会社ソニックガーデン」設立および事業移転のご案内

最初のきっかけは、この4月に実施されたTISの３社合併でした。合併に関する発表があったのが昨年の秋頃で、その時期から今回の動きは始まっています。なので振り返ってみると１年がかりだったんですね。会社が合併するということは、会社が変わってしまうということです。その変化を必然とするならば、それに向けて私はSonicGardenをどうすれば良いのか考えることになりました。これまでSonicGardenは、社内カンパニーという中途半端な形ではありますが、会社の意向や他人から与えられたものではなく、私たち自身で創り上げてきた思いが強いです。そのため、自分たちのビジョンを実現すること、自分たちのやり方を選べること、何より、一緒にやってきたスタッフと働き続けるためにも、別会社として法人化を目指すことにしました。つまり、大きな変化に飲み込まれる前に、自分たちが自ら変化することを選んだのです。

当初は、私も会社や株式に関する知識もなく100%子会社という方向性で進めてきました。しかし、株式公開している上場企業の中で、新しい法人をつくるということは想像以上にハードルの高いものでした。これまで、大企業の中でアジャイル開発の実践や社内SNSのオープンソース化、社内カンパニーの立ち上げなどのパイオニアをしてきた自負をもっていた私ですが、これ以上は書けませんが、今回は従業員という形では出来ない領域まできてしまったようです。そうしたタイミングで、3.11の大地震が起きました。あのとき私は島根県に出張中で、その地震そのものを直接に感じてはいないのですが、それがより一層の衝撃となりました。テレビの中で起きる惨劇に、なす術のない自分、東京に戻ってもまたいつ地震が来るかわからないという恐怖、なにより人は簡単に死んでしまうということをまざまざとリアリティを持つことになりました。

私は、経営者としても大きな賭けに出るタイプではなく、しっかりリスクヘッジをしながら進めていくタイプだと自分で認識しています。自分の人生においてもそうで、アジャイル開発を世の中に広める手段として大企業の社長になって発信するという目標のために、これまで割と地道に企業内での出世を進めてきました。しかし、この地震をきっかけに思ったのは、そこまで到達するためにそんなに長く待てない、ということでした。本当にいつ死ぬかわからないとしたら、そんなに先のために今耐えるという選択肢で良いのだろうか、と。自分の生き方に後悔したくないという思いが強くなったのです。また、株式公開している企業でトップになったところで、果たしてどこまでの自分のビジョンを貫き通すことが出来るのか、上場企業の中を知れば知るほど、疑問をもったというのも正直なところです。ここはリスクをとるべきだと判断しました。

そうした私の思いをこれまで一緒にやってきてくれた仲間たちと何度も話し合いました。今回の思いの源泉には、親会社の意向などで解散することなく、今のメンバーでチャレンジを続けていきたいというところから始まっているので、彼らが一緒でなければ意味がありません。しかし、安定していると思われる企業で働いてきた中で、転職ではなく起業をするという選択肢は本人の気持ちだけでなく、その家族も含めての大きな決断になります。特にお子さんが産まれて間もない家庭を持っているメンバーたちは本当に大変な決断だったと思いますが、全員が共にチャレンジしてくれるという決意を固めてくれました。みんなの決断に本当に感謝しています。

起業することと法人を作ることは別の話です。よく同一視されますが、事業を興すだけであれば学生でも出来ますし、会社に勤めながらでも出来ますし、会社の中で事業を立ち上げることも起業と言えるでしょう。法人を作ることの手続きは簡単ですが、その作った会社で事業をして生活をしていくというのは大変なことです。ビジョンがあって、仲間がいるからといって、それだけでやっていけると思い込めるほど若くはありません。ビジョンの実現のためには事業戦略とビジネスモデルが必要だと知っています。よくあるベンチャーの姿だと、しばらくは無収入で頑張ったあとにひとやま当てて急成長するということを目指すのかもしれませんが、私たちが目指す姿は違います。家族を大事にする私たちは、最初から安定した収益もあげられるようなビジネスを組み込んだ上で会社を作ることにしました。それが「ソフトウェアパートナーシップモデル」です。

未来に成し遂げたい「ビジョン」、今を一緒に戦ってくれる「仲間」、未来と今を繋ぐ「ビジネスモデル」この３つが揃ったことで、ようやく会社としての第一歩を踏み出すことになりました。なので、今回の独立にしても一か八かの大きな賭けという感じでもなく、割と現実を見据え堅実にいけるところは堅実にいっています。それでも、起業というのは実験のようなものだと私は思っています。人にとって自分の信じるビジョンがあったとしても、それは仮説に過ぎません。仮説では理解してもらえる人は少なく、自分が正しかったことを証明するには実験をするしかありません。多くの起業家は、自分自身の正しさを証明するために実験で試しているように思います。そう思えたら、もしうまくいかない時があっても、それは仮説が間違っているだけなので、修正すれば良いだけです。会社の終わりが自分の人生の終わりではないと割り切ること。

ここに書ききれないことと、当然ここに書けないことなど沢山ありますが、誰にとっても今時点の最良の選択ということで、今回のチャレンジが決まりました。今回の発表で、多くの方々から励ましのお言葉を頂きました。ありがとうございました。またちょうど、このブログを書いているときに、Facebook上で、ブレイクスルーパートナーズの赤羽さんからもお祝いのコメントを頂きました。その続きで、SonicGardenが会社として目指したい姿や、ソフトウェアパートナーシップモデルに関する質問などを頂き、お答えさせて頂く中で、改めて自分の考えの整理が出来ました。ありがとうございました。そのやり取りの一部始終が私にとっても興味深いものとなったので、転載をしておきます。

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

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

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

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

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

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

(c) hinel｜写真素材 PIXTA

ディフェンシブな開発

今から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、クラウドによって実現しています。それを実現したプロセスが「「運用中心プロセス」という考えかた～モノ作り中心から動くサービスを中心に据えることへのパラダイムシフト」という記事に書いた「運用中心プロセス」です。

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

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