年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。

そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。

Fastfood / happymealy

大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。

アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立
近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手法（注）です。
http://www.nttdata.co.jp/whatsnew/2012041300.html

この注目の理由「ユーザーの要件を確実に、高品質に、より短期間で提供すること」・・・これは果たして本当にアジャイルにマッチしているのでしょうか？

2つのアジャイル開発

私が知っていたのは「日々変化するビジネス環境の中で、ソフトウェアが予測困難な要件や変化する仕様に対応できていない」という課題があり、そこから産まれたニーズが「変化に対応していけるソフトウェア開発」というもので、それに応えることができるのが「アジャイル開発」だったと思っていました。

しかし最近の文脈では「短納期化と低コスト化する中で、ユーザーの要件を確実に、高品質に、より短期間で提供できていない」という課題に対して、「低コストで速く作れるソフトウェア開発」というニーズに応えるものが必要で、それを「アジャイル開発」と呼んでいるようです。

• 「変化に対応していけるソフトウェア開発」
• 「低コストで速く作れるソフトウェア開発」

この2つの「アジャイル開発」は、解決したい課題もニーズも異なっています。もしどちらにも対応できるとしたら、アジャイル開発は万能薬と言えるかもしれませんが、この世に万能薬などありません。

アジャイル開発は一体、そもそもどんな課題を解決するための手法だったのでしょうか。

アジャイルを「速い・安い・旨い」のように表現している人は、アジャイル開発に「低コストで速く作れるソフトウェア開発」を期待をしているということです。しかし、実際にはそうはうまくいかないでしょう。

もし本当に何の代価もなく手っ取り早く「速く・安く」作れる方法があるのであれば、アジャイル開発はもっと爆発的に広まってるはずです。トレードオフなしに、何も得ることはないということを理解すべきです。

アジャイル開発がうまくいかないのは、人材の問題や契約の問題と言われていますが、そうではなく「アジャイル開発」が「低コストで速く作れるソフトウェア開発」というニーズに対するソリューションではないからではないでしょうか。

「速く・安く」作りたいのであれば、アジャイル開発などと言わなくても良いし、ただ手法としてのやり方を変えたからといって、コストを下げたり、短納期に作ることはできません。そこは手法の問題ではなく、顧客に提供する価値の定義を変えないといけません。

ニーズとのミスマッチ

いろいろな方から「どうすればアジャイルを導入出来ますか？」と相談を受けることも多いですが、そうしたときは「なぜアジャイルを導入したいのですか？」と聞き返します。

それに対し「速く作りたいし、コストも抑えたい」と仰る方もいらっしゃいますが、それであれば、私の知っている「変化に対応していけるソフトウェア開発」では解決しないので、アジャイルをお勧めしたりしません。

お客様のニーズとして「決められた仕様を確実に作ること」が最初にあって、そこを変えずに「速く・安く」というのであれば、「変化に対応していくこと」はニーズに対して応えていないのです。それに応えるのは「オフショア」や「自動化」でしょうか。

お客様のニーズが「要件が見えておらず、少しずつ作っていくことで形にしていきたい」というものや「業務に詳しい人間はITに詳しくなく、画面や動きを見ながら作っていきたい」というものであれば、「変化に対応していけるソフトウェア開発」はフィットするでしょう。

そうしたニーズをお客様の口から引き出すことができるとしたら、それに対する解決方法を提示すればよくて、そこにアジャイルなんて言葉を使う必要さえないのです。そのお客様のニーズに応えられる提案ができるのだとしたら、そこでビジネスはできるのです。

一括請負のビジネスモデルで難しいのは、そもそも、そうしたニーズに応えるためのビジネスモデルではないからです。アジャイル導入の課題は「契約」や「大規模」とよく言われますが、それは一括請負のビジネスをしているベンダーの立場からの言葉です。

一括請負のビジネスモデルをするベンダーがアジャイルの手法に取り組むことは多いに結構ですが、そのビジネスモデルを変えない限りは、「変化に対応していけるソフトウェア開発」へのニーズに応えられないはずです。

「アジャイル」は死んだ

一括請負のビジネスモデルを前提とするならば、アジャイル開発には「変化に対応していけるソフトウェア開発」を期待するよりも、「低コストで速く作れるソフトウェア開発」を期待することになります。

最終的な仕様と金額が決まった中では「変化に対応していけるソフトウェア開発」のニーズはないでしょう。

このことは別に悪いことではなくて、お客様のニーズが「決まったものを速く・安く」ということを求めるのであれば、それに対して応えていくことで商機になるわけですから、そこを追求すれば良いのです。

ビジネスモデルにも手法にも善悪なんてないのです。あるのはニーズがあってビジネスになるかどうか、です。「決まったものを速く・安く」というニーズに応えようと企業努力をするのは、至極まっとうなことです。

しかし、その「決まったものを速く・安く」というニーズに対する解決策としてアジャイル開発と言って期待してしまうことに違和感を憶える訳です。

そもそもアジャイルが「安さ」を実現するためのものだとするなら、価格競争の手段ということになります。もしアジャイルが本当に価値のあるものだと思うのならば、そんな安売りをすべきではないと思っています。

価格競争のための「オフショア」の代わりのバズワードとして「アジャイル」が使われるのであれば、そうしたムーブメントを後押しする気ににはなれません。

もし、アジャイルという言葉が「低コストで速く作れるソフトウェア開発」を指すものだとマスメディアや大手企業によって言葉の意味がねじ曲げられて、多くの人に認知されてしまうのであれば、もはや「変化に対応していけるソフトウェア開発」のことを「アジャイル」と呼ぶのはやめても良いのかもしれません。

もし、ファストフードのような開発をアジャイル開発と呼ぶのであれば、私の中で「アジャイル」は死んだも同然です。言葉の定義なんて変わるものだし、正しい定義を振りかざしても仕方がないのはわかっていますが、バズワード化するというのは、こういうことですね。

改めて言うと、ファストフードのように「速く・安く」のニーズに応えようとするのは良いのです。それがビジネスなのだから当然のことです。しかし、そのニーズを解決するソリューションとして「アジャイル」を担ぎ上げなくても良いんじゃないか、と思うのです。

経営者だけでなく、現場でアジャイルを広めようと取り組む技術者にも言いたいのは、アジャイルがそのマーケットにおけるビジネスモデルの中で求められているものなのか、どんなニーズに応えるものかを考えるべきではないかということです。

バズワードを振りかざす前に、マーケットにおけるビジネスモデルを理解し、お客様のニーズを把握して、そこにあった解決方法をひとつひとつ考えていくことが大事なことでしょう。

リーンスタートアップとは、起業家であるエリック・リースの失敗と成功の経験をもとに、製造業におけるリーン生産方式の概念を応用して説明した、これまでにない新しい「スタートアップの手法」のことです。

リーンスタートアップそのものについては、以前に私もブログで紹介しましたので、そちらも参照ください。

リーンスタートアップとは

世の中のスタートアップの殆どが失敗しているけれど、実は成功の確率を高めるにはやり方があって、そのやり方としてまとめたものが「リーンスタートアップ」だと本書では言っています。

そのやり方は、必要最小限の機能だけでリリースをすることや、サイクルタイムを極端に短くしていくこと、ユーザや顧客の反応を実験してフィードバックをうけ、意思決定を科学的に判断するというようなことが特徴的です。

この方法は、新規事業を成功させるためには、事前に綿密な事業計画を立てて、大きな投資や予算を獲得し、優秀な人を集めて、素晴らしい製品を作り上げるべきだ、と考えている人からすると、ありえないと思えるかもしれません。

しかし、ありえないことを起こすことがイノベーションであるならば、従来の方法では生みだすことは出来ません。これまでにないやり方が必要なのです。

だからといって「Just do it!」の精神で、あたかもギャンブルのようにスタートアップに取り組めば良いかというと、それではうまくいきません。

そのスタートアップにかける情熱やエネルギーを無駄遣いすることなく、成功させるためには従来とは違うマネジメントの方法が必要になります。それがリーンスタートアップです。

以下のリーンスタートアップの５つの原則を本書を読むことで身につけることができます。

１．アントレプレナーはあらゆるところにいる
２．起業とはマネジメントである
３．検証による学び
４．構築ー計測ー学習
５．革新会計（イノベーションアカウンティング）

わたしのリーンスタートアップの起源

私も自分で起業してスタートアップを立ち上げている一人なので、リーンスタートアップに書かれていることはとてもしっくりきました。私もエリックと同じでアジャイル開発に取り組んだ後、そこでの経験を元に起業したという経歴をもっているので、彼が経験した成功と失敗について、とても共感しました。

私が大企業に所属していた頃に社内ベンチャーを立ち上げたことが、今の「株式会社ソニックガーデン」の前身になっています。社内ベンチャーを立ち上げたきっかけも、新規事業をしたいという情熱が最初でした。

当時をふりかえってみると、大企業の中で新規事業をしようとすると、最初に事業計画書をつくる必要があります。そこまでは会社として当然ですが、そこから予算をとったり、事業をすること自体の承認を得たりと、様々な関係部署や役員などとの調整が入ります。

多くの関係者のアドバイスやおせっかいの結果として、当初考えているよりも大きな成果を求める計画が出来上がり、短期間でそれを実現するために、最初から大きく賭けないといけなくなってしまいます。当然リスクを排除した中身もつまらないものになります。

しかし新規事業は未開拓の領域に進むことなのに、最初から計画を決めきって大きく進めていくようなやり方は向いてなかったのです。そこで、社内ベンチャー２年目以降は与えられた予算を殆ど使うことなく、小さく少しずつ検証しながら進めていくやり方に切り替えました。

その結果として、大きな予算を使って進めようとするよりも、小さく検証を繰り返しながら進めていく方が、事業としては成功することが出来、会社として独立することができるようになりました。

無駄をなくして、検証から学ぶことのできるチームを作ることができれば、大きな組織では出来なかったことを実現することが出来るのです。

「リーンスタートアップ」という本の価値

この本を読んで、当たり前のことが書いてあると思った人もいるかもしれません。私もそれに近くて、リーンスタートアップそのものを知る前からやっていたことを、リーンスタートアップを知る人に説明したら「それはリーンスタートアップですね」と言ってもらえたからです。

そういう人にとっては当たり前のことしか書いてないかもしれないけれど、スタートアップに関して、こうした経験を元に分析された上で総合的にまとまって理論として書かれた本は他にあまり知りません。

この本が広まって、多くの人に読まれることで、読者同士の共通言語が出来ることが大事なんだろうと思います。

特にエンジニアは、経営（マネジメント）に関することにあまり興味をもっていない人が多い。にも関わらず、このリーンスタートアップというビジネス書は、エンジニアも興味をもっている人が多いです。

アジャイル界隈でのキーワードである「リーン」という言葉を入れてきたエリックリースのうまさはありますが、これまで読むことも意識することもなかったであろうエンジニア層にリーチできたのは素晴らしいことです。

このビジネス書を読んだ同士であれば、経営者でもマーケッターでもエンジニアでも、共通言語をもつことができて、同じ言葉で議論をすることが出来ます。それってすごいことだし、そうして議論できるチームというだけで、スタートアップとして成功する確率が高そうに思えます。

ちょっと読んで知った風に振る舞うのではなく、一度、謙虚にじっくり読んでみると良いと思います。（たしかにちょっと文章は冗長だと思いますけどね。）

読書メモ

ここでは本書を読んで気になった部分をメモしておきます。

p69.「リーンな考え方における価値とは顧客にとってのメリットを提供するものを指し、それ以外はすべて無駄だと考える。」

顧客とってのメリットとなること以外は無駄だと言ってます。とてもシンプルで、かつ明確な判断基準になります。どれだけアジャイルだなんだと言って沢山つくったとして、それが最終的に顧客にとってのメリットにならなければ、すべて無駄なことなのです。

p79.「問うべきなのは「この製品は作るべきか」であり「このような製品やサービスを中心に持続可能な事業が構築できるか」である。」

スタートアップは実験だと考えるべきで、できるかどうかではなく、すべきかどうかを先に考えなければいけないし、それが正しく答えられるためには実験をする必要があるのです。実験を行って「検証からの学び」ができるチームでなければいけません。

p148.「作るのにどれだけの時間がかかったかなど、顧客は気にしない。顧客が気にするのは、自分にとっていいか悪いかである。」

これも開発者だと勘違いしてしまうところです。作るのに時間をかけたものは価値があると思いたくなる気持ちもわかりますが、時間は価値にならないのです。そうであれば、最小限の時間で最大限の効果を出せるように無駄をなくす意識をもつべきですね。

p.150.（MVPを作るときのシンプルなルール）「求める学びに直接貢献しない機能やプロセス、労力はすべて取り除く」

MVPは思っているよりも小さくていいし、立派でなくても良いんです。人が動いても良いし、あるものを使っても良いんです。大事なことは顧客に提供して「検証からの学び」を受け取れるかどうか、なのです。

このように、作るべきモノの開発よりも、顧客そのものを中心に考えることがリーンスタートアップの基本にあります。その辺りはアントレプレナーの教科書という本に出てくる「顧客開発」の考えかたに近いです。

それもそのはず、アントレプレナーの教科書を書いたスティーブブランクは、リーンスタートアップの著者であるエリックリースのメンターだったからですね。

目次

• はじめに
• 第１部　ビジョン
• 第１章　スタート
• 第２章　定義
• 第３章　学び
• 第４章　実験
• 第２部　舵取り
• 第５章　始動
• 第６章　構築・検証
• 第７章　計測
• 第８章　方向転換（あるいは辛抱）
• 第３部　スピードアップ
• 第９章　バッチサイズ
• 第１０章　成長
• 第１１章　順応
• 第１２章　イノベーション
• 第１３章　エピローグー無駄にするな
• 第１４章　活動に参加しよう

プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。

pka karate-pittsburgh-kids karate-kidz zone-class-sept 2011-17 / PKA Karate

SonicGardenの教育事業では、たまに訪問する家庭教師的なスタイルではなく、教育対象の方に弊社のオフィスにフルタイムで来て頂いて、一緒に仕事をしながらOJTでペアプログラミングやコードレビューを通じて、身に付けてもらうというものです。そこで身に付けてもらうようにしている習慣を紹介します。これらは元々は私が先人たちから学んだことでもあります。

自分で書いたすべてのコードを説明できるようになれ

プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使うのか、メソッドで切り出すかどうか、それらすべてロジックで作られていて、そのロジックを決めているのは、作っているプログラマの判断です。

プログラムの中で、曖昧なままに作っている部分があるとしたら、それは確実にバグの温床になります。作っている本人が「なぜこう書いたのか？」を説明できない部分というのは、本来あってはいけないのです。ましてや仕事で作っているプログラムで。

なので、学習を始めたばかりのプログラマたちには「自分の書いたすべてのソースコードについて説明できるようにしなさい」と指導するようにしています。プログラムのどの部分についても「なぜこう書いたのか？」を説明できる習慣を付けるのです。

原理や動作を理解しないまま、Googleで検索したサンプルコードや、他の誰かの書いたコードからコピー＆ペーストして、何度かパラメータを変えてみたりして動いたらOK、なんていうプログラミングの悪習慣を身につけてしまってはいけません。

優秀なプログラマはたとえ動いたとしても「動いてよかった」なんて思わずに、その「なぜか動いている」という状態をとても気持ち悪いと思ってしまうのです。論理的でないことを嫌うのです。

プログラミングの世界では、DRY（Don't Repeat Yourself）という言葉があります。プログラム中に同じコードを繰り返し存在させてはいけないという考えかたです。すべてのコードを説明できる状態になれば、自然とDRYになっていきます。

SonicGardenのコードレビューでは「なぜこう書いたのか？」を確認します。大事なことは、プログラマが自分で判断した結果であることで、理由を言えることです。もしその理由が間違っているのであれば、正しく直せば成長の機会につながりますが、理由もいえないソースコードであれば、レビューする価値すらもありません。

プログラミングに取りかかる前にTODOリストを作れ

プログラミングを始めると、並列に作業が進むことはなくて、ひとつひとつ順番に作業をしていくことになります。その作っていく順序を、頭の中でシミュレーションして事前に把握しておくことが、できるプログラマの優れた習慣になります。

行き当たりばったりで作っていってしまうと、作業に漏れが発生することがありますし、どれくらい進んでいて、どれくらいかかりそうか、ということもわからなくなります。プログラムというのは、つくり方もロジカルであるべきなのです。

たとえベテランのプログラマであっても、順番に進む作業スピードが速いというだけで、進めていく内容に違いがあるわけではありません。その作っていく際の作業の順番、すなわちTODOリストが頭の中になければいけません。

なので、プログラミングを始めたばかりの人たちには「作業の前にTODOリストを作りなさい」と教えています。何をどういった順番で作って行くかというチェックリストです。作業が終わったかどうかのチェックを付けていきます。

もしTODOリストが作れないとしたら、やろうとしていることのゴールが明確でなかったり情報が足りなかったりしているということがわかります。

TODOリストは、特にツールを使う必要はなく、テキストエディタでも良いし、手元の紙でもいいのです。大事なことは、見えるようにすることです。見えるようにすることで、自分も迷うことがなくなるし、誰かに進捗を聞かれた時にもすぐに共有することが出来ます。

初心者のうちはなるべく細かく細かくTODOにする位でちょうど良いでしょう。最大でも一時間以内で終わるように刻むのです。終わるまでに一日以上かかるのはもはやTODOとは言えません。

最初、初級者のうちはTODOの粒度が小さくなってしまいますが、それが成長するにつれて大きな粒度でも扱えるようになります。この一歩の歩幅の大きさが成長の証です。

この歩幅が小さいうちは、何を作るにも大変かもしれません。プログラマとして成長するというのは、新しい知識を得るのではなく、この一歩の歩幅を大きくしていくことなのです。

わからないところを想像で補うのではなく話し合え

TODOリストを作る際や実際にプログラミングしている際に、ときには仕様でわからない点が出て来たりするはずです。そうしたときに、つい先に進めたいがために「きっとここはこういうことだろう」と決めつけて、先に進めてしまうことがあります。しかし、想像で作ったところは往々にして後から見直しが入ることが多いです。

仕様ではっきりしないところがあればどうするか、答えはシンプルで、わかる人に聞けば良いのです。SonicGardenではプロダクトオーナーという仕様に関する責任者がいますので、その人と改めて共有するしかありません。なるべく困ったときは「想像して決めつけずに話をしよう」と言っています。

プロダクトオーナーと話してみると、プロダクトオーナー自身もわかってなかったことや考慮出来てなかった点だったりして、そこからお互いに議論して正解の仕様をつくっていくことになることも多いです。

こうしたことを実現するためには、プロダクトオーナー側がいつでも質問を受け付けられる姿勢でいることと、素早いレスポンスが求められます。これはプロダクトオーナーにとってみると大変なことですが、もし本当に良いソフトウェアを作りたいなら、これくらいのことは必須条件になります。

仕様を把握する際のポイントは、ソフトウェアの動作を詳細に決めていくことも大事ですが、そもそものひとつひとつの要件の背景にある意図を把握することが大事になります。その機能がなぜ必要なのか、を知ることで、実現方法をプログラマから提案することができるようにもなります。

また、初心者のうちは、どうしても細かい動きまで確認してからでないと作れないことも多いのですが、一般的なソフトウェアの動作に関するコモンセンスを身につけていくことで、プロダクトオーナーやユーザのニーズの意図を汲み取るだけで、だいたいのことがプログラミングできるようになります。

「どうも難しい仕様だな」と思ったときに、そのまま頑張ってプログラミングして実現することに努力する前に、「もっとシンプルな仕様にできないか」と考えて、プロダクトオーナーにシンプルに実現できる仕様を提案することが出来るようなプログラマを目指したいところです。

皆さんの考える「プログラマが身につけたい良い習慣」があれば @kuranuki に教えて下さい。

本書を読み終えた今、とても共感するところがたくさんあり、確かに私の「お気に入りの一冊」になりました。この本には、私がこれまで考えて実践してきたことに近いことが言語化されて書かれていました。

そして、私もこんな本を書きたかったんだ、と少しの嫉妬と悔しさも残りました。

この本を読むことで、会社を大きくしなければいけないがために、自分のライフスタイルを犠牲にするようなワークスタイルをすることは本当に幸せなことなのか、見直すきっかけになるかもしれません。

私もよく講演でも話している「小さな会社で、楽しく働き、豊かに暮らす」という思想について、本書では色々な事例を紹介しながら説明しています。それを実現するには色々な要素があると思いますが、本書は「ブランディング戦略」という切り口で説明しています。

「ブランド」は大きな会社だけがするものではなく、小さな会社こそが「ブランド」を持つことで、ライフスタイルとワークスタイルを充実させることが出来るようになる、と著者は言います。

私たちの会社であるソニックガーデンも、社員数が10人にも満たない小さな会社ですが、多くの皆様に知ってもらうことで、理想に近い働きかたが出来ています。意識してなかったですが、それは「ブランド」だったのかもしれません。

読書メモ：ソニックガーデンの場合

ここでは本書を読んで気になった部分を、私たちの会社であるソニックガーデンでのケースで考えながら紹介します。

p036.「会社自体にファンをつけていく」「会社自体に価値をつける」

「お客様」である前に「ファン」になって頂く、という発想。これは「グレイトフル・デッドにマーケティングを学ぶ」で学んだことと同じですね。大事なことだし、そういう会社が生き残ると思います。

ソニックガーデンは小さい会社なので、マーケティング予算はそれほど潤沢にある訳ではありません。そこで、自分たちの仕事の進め方や、ソフトウェア開発で学んだことなどをブログや寄稿などを通じて業界に還元しつつ、そのことで多くの方に知ってもらうということをしています。

p041.小さな会社のブランド戦略は「大好きなお客さまとだけ付き合うための戦略」

ブランディングを実践していくことで、どんなお客様と仕事がしたいか、ということが実現できるという話です。私たちもこのことの重要性は実感しています。ソニックガーデンではソフトウェア開発の受託もしますが、よくある人月商売も技術者派遣もしていません。それをすると経営者としては安易に稼ぐことのできることはわかりますが、それをしてしまうと起業した意味すらなくなります。

だから、ソニックガーデンでは受託をする際に人月も派遣も一切しないのですが、そうである姿勢を前面に打ち出したブランディングをしています。だからこそ、ソニックガーデンに相談に来て頂くお客様は、その時点でずっと絞られますが、間違いなくソニックガーデンのスタイルに共感を憶えたお客様だけに来て頂くことができています。

p106.ファンをつくるためには、「まずは自分たちが最高に楽しく仕事をすること」

楽しそうに仕事をしていることが、ファンになってもらうために大事なこと、というのは当たり前のことだけど忘れがちです。自分たちの会社や上司の愚痴をいったりする人の会社にファンはつかないですよね。

ソニックガーデンでは、受託開発をする際に心がけているのは「お客様にもソフトウェア開発の楽しさを知ってもらうこと」です。私はソフトウェア開発は元来クリエイティブで楽しいものだと信じていて、それを実現するためにアジャイルなどに取り組みましたが、今や自分たちが楽しむだけでなく、お客様ともその楽しさを共有したいと思っています。

p112.ミッションづくりに、とことん時間とエネルギーを

本書では会社におけるミッションこそが、揺らぐことのないブランドの基盤であると繰り返し伝えています。確かに、使命感よりも儲けることが先にくる会社にブランドはないのかもしれません。

ソニックガーデンでは、会社を設立したタイミングでミッションやビジョンが確立していましたが、これは社内ベンチャー時代から入れて３年目でようやく出来上がったと言っても良いくらいに時間をかけました。今思えば、社内ベンチャーという苦しく不安定な立場でいた時間が、自分たち自身の存在理由を深く考え直す良い時間だったのかもしれません。

そして、ソニックガーデンでは半年に１度、ビジョン合宿と呼んでいる一泊二日の合宿にいっています。そこで全員でミッションとビジョンの見直しをするのです。前回おこなった2011年12月の合宿の様子はこちらでブログにしています。

p116.いつも頭にポジショニングを

小さな会社に適したポジションは「激戦区から、ちょっとズレたところ」、小さな会社の基本戦略は「戦わないこと」と著者は言います。そのためにポジショニングを意識する必要があります。

「激戦区からちょっとズレたところ」というのは、すごく実感としてあります。ソニックガーデンの商品である社内SNS:SKIPなどは、大手企業も参入している激戦区になりつつありますが、私たちは5年以上、そのマーケットでビジネスをしてきた実績があり、競合他社と違って提供する価値を「会社を元気にすること」と位置づけることで、欧米でつくられた製品ではできないヒューマンケアを含めることで、競合との差別化を図っています。そして、ニッチであっても、その価値を求めるお客様の数は、小さな会社をやっていくなら十分なほどにいらっしゃいます。

成功の定義

本書では、小さな会社で成功することについて書かれています。そして、本書によると成功とは「幸せになること」「思い描いた理想のライフスタイルを完成させること」ということです。

私は起業したときによく言われたことが「そのビジネスモデルで成功することを期待してます」とか「ぜひ成功してください」とか言われました。ありがたいお言葉なんですが、でもずっと違和感があったんですよね。

今現在のソニックガーデンでは、赤字もなく利益がちゃんとある状態で、社員のみんなも家族との時間を持つことができて、今この瞬間が大金持ちってことではないけど、豊かに楽しく暮らせているので、私としては成功なんだけど、他の人からは成功と見えないのかな、と。

それは、成功の定義が人によって違うからなんですね。大企業になったり、上場して大金持ちになったら成功だと思う人もいれば、そうじゃない人もいます。私たちの価値観は、小さな会社でも、信頼出来る仲間と、喜んで頂けるお客様と、楽しく働き豊かに暮らすということなので、気にする必要はなかったのかもしれません。

社長の仕事

この本には社長の仕事は「３年後に生き残ってる理由を、今日考える」ということが書いてます。私も同感です。小さな会社の場合、社長自身がプレイングマネージャをしていることが多いので、社長としての仕事を持てないことになり、結果として会社がちゃんと儲かることに繋がらないという悪循環がありますね。

ソニックガーデンでは、ありがたいことに社長が「社長の仕事」をする時間をかなりもらっています。だからこそ、新しいビジネスモデルを産み出せたり、ブランディングや人事にも力を入れることが出来ています。

ソニックガーデンは２代表制を採用しており、副社長も代表取締役なので、普段の業務の遂行はCOOとして副社長だけでまわせるようになっています。また、チーム全体が自立的でスタッフそれぞれがビジネスの判断もできるようになっていることも強いです。そんな仲間と一緒に起業できて、本当に幸せなことです。

「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。

実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。

SonicGardenでカイゼン型開発を行う理由

ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受託開発を行っています。図１の左上の領域です。

ソフトウェアの受託開発と言えば、これまでは図１左下の一括請負による納品型のビジネスモデルが主流ですが、実はそのビジネスモデルはお客様にとってもベンダーにとっても、そして開発者にとっても不幸になる問題をはらんでいると考えているからです。

「一括納品モデル」がもたらす問題

一括請負による契約の納品型のビジネスモデル（以降、一括納品モデル）では、発注者とベンダーはあらかじめ決められた金額と要件の中で納品と検収を目指して開発を行います。

そのために発注者は発注前にすべての要件を決める必要があり、発注後は当初に決めた要件を途中で変えることは基本的に不可能となります。

このビジネスモデルの中では「仕様変更」とは追加費用が発生するものであり、初期の想定違いや技術的なリスクによって発生する仕様変更にかかる費用を、プロジェクトの途中で発注者とベンダーでどちらが負担するのかで揉めることも多くあります。

「要件定義」で解決するのか？

そうした問題を解決するためにベンダーが考えたことは、いわゆる「要件定義」と呼ばれる工程でしっかりと、要件を洗い出して計画を立てることが重要だということでした。

事前にすべての要件を並べだし、問題点やリスクを洗い出すことで、計画通りに開発が進められるようにしようということです。

しかし、果たしてそれは発注者であるお客様にとって、本当にメリットのあることなのでしょうか。システム開発の初期の時点で考えた「計画通りに」システムが「完成」したとして、本当にお客様にとって役に立つのかというと、はたして疑問です。

発注者とベンダーのゴールの違いが原因

お客様にとってはシステムは稼働してからが重要ですし、当初の計画を立てた時期の外部環境とシステムが完成した頃の外部環境は変わっているはずで、そのままのシステムだけでは役に立たないことも多くあります。

ましてや、社内の社員だけが使うシステムならまだしも、ECサイトやウェブサービスなどといったエンドユーザがベンダーから見たお客様のお客様である場合には、想定通りにシステムが使われることは滅多にありません。

システムは動き始めてからが本番で、そこからどれだけ環境やユーザからのフィードバックを得て「改善」していけるかということが重要で、そういうシステムこそが本当にお客様にとって価値をもたらすものになるはずです。

発注者にしてみるとシステムが完成してからが重要で、ベンダーにはシステムが完成するまでが重要になっている、このゴールの違いが、一括納品モデルによって引き起こされる問題の原因です。

ベンダーが利益を出すためには？

あらかじめ要件と金額が決まっている一括納品モデルにおいて、ベンダーが利益を出すためには、開発途中に発生しそうなリスクを計画上の時点でなるべく潰し、見積もりの際に想定した利益分を減らさないような開発の進め方をしなければいけません。

単価の低いオフショアを使うことは価格競争を勝ち抜くためには必要ですが、人月という単位で見積もりをする限り、本来であれば売上と利益が下がってしまうので、自身の首を締めることになりかねません。

ここでベンダーのマネージャが採れる戦略は、売上をあげるために立派な提案書を作り沢山の機能をお客様に必要と思ってもらって大層なシステムを作りましょうと言うことと、利益を確保するためになるべくリスクを洗い出して想定するバッファを沢山積んでおいて実際にはそのバッファを使わないように守りに入ることだけです。

この一括納品モデルの中では採れる戦略が限られているのです。

契約だけを変えても意味がない

この一括納品のビジネスモデルがある限り、ウォーターフォールであるとかアジャイルであるとかといった開発の進め方では解決しないし、これは契約の仕方や料金回収のタイミングを変えたからといって解決する問題でもないのです。

一括納品モデルでは、発注側は金額内で要件を守らせることを重視してしまい、ベンダーはリスクをとらずに利益を守ることに集中してしまいます。結果として、そのシステムが発注者にとって価値を産むかどうか、ということよりも、決められた要件通りに作ることこそが大事になってしまうのです。

この守りに入ることでしか価値を産まない問題を私は「ディフェンシブな開発」と呼んでいます。

「ディフェンシブな開発」からみた業界構造

「ディフェンシブな開発」から気付いたことは、実は「一括納品モデル」を採用するシステムインテグレーション（SI）ビジネスの本質は保険屋と一緒なのではないか、ということです。

つまり、顧客からすれば、要件と金額を決めて発注さえすれば、途中に何があろうと最後までやり遂げてくれるというのがSIerなのであれば、扱うプロジェクト数が少ない小さなSIerに頼むよりも、多少割高になったとしても大手の会社に頼む方が安心なことは自明です。

大手のSIerであれば、いくつかのプロジェクトが赤字になろうとも、他のプロジェクトで黒字になっていれば会社としてはやっていけます。つまり最後までやり遂げるということがSIerのお客様への大きな価値になる訳です。

会社を大きくするしかなかった

システム開発において発生するであろうリスクも含めて丸投げしてきたのが、これまでの一括納品モデルだったのです。

大手SIerに発注するとなると、高いバッファが積まれて、金額が高くなったとしても、決められた金額からはみ出すことなく発生するリスクを受けてくれるのであれば、頼むだけの価値があったのです。

つまり、リスクを受けきれるだけの体力があり、大きなプロジェクトを受けても検収までやりきれる体力があるような大きな会社が強い世界になるので、多くのSIerが合併や統合をしているのは理にかなったことなのです。これはまるで保険会社と同じなのです。

違うのはSIerのプロジェクトで扱うのは保険のようなお金ではなく実際に働くエンジニアたちなので、会社から見て赤字プロジェクトでもやむなしとされるところで働くエンジニアが悲惨であることは残念なことです。

生産性を上げる意味がなかった

エンジニアから見た一括納品モデルのビジネスとしては、「人月という単位」で見積もられる中で求められるのは「成果物の完成責任」であるという捻れの構造です。

最終的には納品をするのであれば「完成責任」が求められるのは当然です。それはそういったビジネスで良いのですが、それを「人月」という作業量で見積もっていることがおかしくしています。

作業量で見積もるのであれば、作業量に応じた報酬が出るのが普通です。必ず完成することを、作業の見積もりで約束するとなれば、大きなバッファを積むしか回避する方法がなくなるのです。

また、人月の見積もりの問題は、エンジニアが生産的であればあるほど、見積額が下がってしまうということです。３人３ヶ月で作れるチームと、10人10ヶ月かけて作り上げる体制と計画では、単価が変わらなければ後者の方が売上高は高くなってしまいます。

これでは、エンジニアが生産性をあげようというモチベーションが下がってしまうのは当然です。

「Point of Sales」と「Point of Use」

ソニックガーデンでは「納品のない受託開発」に取り組む以前から、社内SNS:SKIPやプロジェクトツール:youRoomなどをクラウドを通じて提供するビジネスを行っていました。このクラウド（SaaS）の世界では、一括納品モデルの受託開発の世界とは真逆の考えかたが求められるマーケットでした（図１）。

そして、このクラウドの業界を経験したことで、品質管理に関する考えかたについて大きな発見がありました。

図２は一般的な業界による品質の考えかたの違いを表した図です。左側が製造業で、右側がサービス業です。

製造業は、モノを販売する業種なので「Point of Sales」と呼ばれる、お客様が購入する瞬間を最も品質の高い状態にもってこようという考えかたです。例えば新車を買う時は、購入の瞬間が最高の品質になっていないと嫌だと思います。モノを購入するビジネスは「Point of Sales」なんです。

一方、右側のサービス業は、モノを売るのではなく利用することに対してお金を払ってもらうビジネスの品質の考えかたです。例えばタクシーはサービス業で、乗った瞬間が最高の品質になっていなくてはいけません。この利用する瞬間を最高の品質で保つというのが「Point of Use」です。

クラウドは完全に右側の考えかたでソフトウェア開発を行っています。いつでも利用開始でき、常に安定していて、定期的にバージョンアップしていくのは「Point of Use」です。

そして、実は一括納品モデルを採用しているSIerは「Point of Sales」だったんです。そう考えると、SIerは製造業であり、工程を分割するようなエンジニアリングの考えかたは、理にかなっていたのかもしれません。

しかし、そろそろソフトウェア開発を製造業のメタファから脱却する時期にきてると考えています。

スモールスタートとスケールアウトが求められる時代

これまでのシステム開発と言えば、企業内における業務の効率化や、会計や製造のための基幹システムなどが多かったため、事前に要件を決めることも何とか可能だったかもしれません。

しかし、これからのITを活用する場面は、事業の付加価値としてのシステムや、ITそのものでビジネスをする企業にとってのシステムが求められるようになってきており、そうした場面において事前に全ての要件を決めきることなど不可能となりつつあります。

事業としてのシステムを作る際は、事業開始のタイミングでの初期投資を抑えたいものですし、一方で、事業が軌道に乗るに従って機能やインフラを拡大していきたいと考えるものです。

本気で事業を成功させる気があるのであれば、こうしたスモールスタートをしつつ仮説検証を繰り返しながら、将来的にスケールアウトすることを目指すべきです。

しかし、一括納品モデルではそれには対応することができません。お客様が「Point of Use」のサービス業をするのであれば、それを支えるシステムも「Point of Use」で作り続けなければいけないのです。

これからの時代、こうしたニーズを求められるようになり、そこに大きな市場ができると予想しています。

「一括納品モデル」に代わる新しいビジネスモデル

システムのスモールスタートをするためにはどうすれば良いか。

一つの答えは技術者を抱えて内製をすることでしょう。大手のゲームプラットフォーム企業などの資金力のある会社では、多くの技術者を雇い入れて内製を行っています。技術者が社員であれば、柔軟に開発を進めていくことも、リリースの内容やタイミングを見直すことも容易です。

しかし、すべての会社で技術者を抱え込んで内製できるかというと、それは現実的ではありません。IT以外の本業がある会社で優秀なエンジニアを採用することは非常に難しいことですし、社員として雇うのは大きなリスクになります。

内製部隊を持てないけれども、事業のためのシステムをスモールスタートで作ることができるようなアウトソーシングを望むニーズに対して、私たちソニックガーデンでは「パートナーシップモデル」というビジネスモデルを発明しました。それが「納品のない受託開発」です。

パートナーシップモデルでは、「受託で開発すること」と「納品しないこと」と「派遣しないこと」の３つを両立させることを実現しました。

まず「月額定額」ということにすることで、金額を工数の見積もりから分離しました。月額定額の中でエンジニアが出来る範囲の開発と運用をしていきます。

これは顧問弁護士などの顧問ビジネスのようなスタイルに近いと言えますが、コンサルティングではなく実際のシステムのライフサイクルをすべて受け持つ内製部隊のように働きます。

同時にクラウドを活用することでエンジニア自身は派遣されずに働くことができるようにしました。働いている時間を直接売っている訳ではないので、生産性をあげるモチベーションがとてもうまく働きます。

私たちの目指す姿はリスクを理解したお客様とプログラマが直接対話を行い、お客様のためにオーダーメイドで価値を産むソフトウェアを提供するというスタイルです。私たちが目指すのはお客様にとっての真のパートナーになることです。

これが、ソニックガーデンがカイゼン型開発を行う理由です。

東京サテライトでは、メイン会場ではなかなか出来ないことにチャレンジしようということで、アジャイルのイベントなのだけど「スタートアップ」というテーマを選びました。とはいえ、有料のイベントでそのテーマで本当にアジャイル界隈から人が集まるのか、非常に不安ではあったのですが、130名以上の方々にご参加頂くことができ、本当にほっとしました。ご参加頂き、ありがとうございました。ブログ書いてくださいね。

また特になにごともなく、一日がかりのイベントを無事おえることができ、肩の荷がおりました。ほとんどのアジャイルジャパン実行委員が大阪に行ってしまっているので、少ない人数で大変でしたが、本当にうまくいって良かったです。実行委員の野口さん、高柳さんには企画の段階からお手伝い頂き心強かったです。ありがとうございました。そして、スタッフ、サポーター、講師の皆さん、本当にありがとうございました。

私の今回の東京サテライトでやりたかったことが３つありました。

１つ目は、参加者の皆さんの「脳のブレーキ」をぶっ壊すこと。せっかく平日に一日かけてイベントに参加するので、ただ勉強になるのも大事かもしれないけれど、普段の自分の周囲や環境の中だけではあまり触れることのないような話を聞くことで、イベント参加前の自分と参加後の自分で変わってほしいな、という思いでした。

リーンスタートアップのワークショップでは、アジャイルのエンジニアやマネージャにエレベーターピッチを作ってもらい、リーンUXのワークショップではペルソナ作りをしてもらい、パネルディスカッションでは起業したり経営に携わっている人たちの生の声を聞いてもらうことで、実現できたのではないかな、と思っています。

２つ目は、新しい登壇者に登場してもらうこと。これまであまりアジャイル界隈では見なかった人たちをもっと表舞台にひっぱり出したいと思っていました。アジャイルのイベントで話す人って、だいたい定番になりつつあるかなと思っていて、ここいらで入れ替えをしても良いんじゃないか、と。みんな大阪に行っててチャンスだと。

リーンスタートアップ界隈では知らない人のいない和波さんを、アジャイルの人たちに紹介できたのも良かったし、パネルディスカッションの井上さん、堀さん、吉田さんは、話も上手でまさしくアジャイルな姿勢をもって生きてる人たちで出てもらえて良かったし、楽天の藤原さんに講演してもらえたのも、フレッシュでとても良かった。

最後の３つ目は、私が負けず嫌いなので、大阪にメインを持っていかれはしたけれど、東京でのサテライトをメイン会場に負けない位に、楽しくてアツいイベントにしたいというものでした。交流会での参加者の皆さん同士の活気ある雰囲気を見て、個人的には満足した結果になりました。

アジャイルの出口として「組織変革」に加えて「スタートアップ」が見つかったのだとしたら、その「スタートアップ」にフォーカスした最初のアジャイルのイベントとして「AgileJapan2012東京サテライト」があり、そこに参加した皆さんが、今回のイベントをきっかけに自分たち自身で考える「スタートアップ」をしてくれたとしたら、それ以上に嬉しいことはありません。

なにはともあれ、本当に楽しい一日でした。ありがとうございました。

当日のTogetter

Ferrari F1 - Fernando Alonso / JiteshJagadish

ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。

SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。

ホワイトボードとMVP

実際の開発の流れとしては、まずはホワイトボードを使って最大でも１ヶ月ほどで完成できる範囲の設計をします。この際は細部や例外に拘るのではなく、最小限だけれども全体の流れを一通り実現できるような機能を設計します。こうした必要最小限の機能をリーンスタートアップでは「MVP」と呼ばれています。そして、MVPが決まれば、すぐにプログラミングに取りかかります。わざわざドキュメントにする必要はありません。

Pivotal Trackerとチケット駆動開発

実際にプログラミングをする前に、ユーザから見て意味のある機能単位のユーザストーリーと呼ばれる単位に分割し、Pivotal Trackerというツールに登録していきます。ユーザストーリーの追加はプロダクトオーナーの仕事です。プログラマは登録されたユーザストーリーを優先順位の順に並んでいるので上から順に対応していきます。こうしたやり方を「チケット駆動開発」と呼びます。

実際にはプロダクトオーナーがどんどんと勝手に追加していくのではなくて、プログラマとのディスカッションを行ってから合意がとれてから追加していくことになります。その時のポイントは、プロダクトオーナーは解決したい課題から話し始めることです。解決するための機能をどう実現するかは、色々なプログラムのつくり方によって変わってくるので、機能の実現方法についてはプログラマと話あって決めます。そうすると、余計な機能を作り込んだり、技術的に無駄に頑張るといったことがなくなります。

youRoomと顧客同室

最初の設計で詳細まで決めないので、プログラミング中に不明な点などが出てきたら、youRoomというツールを使ってコミュニケーションを図ります。youRoomはグループ毎にコミュニケーションがとれるツールで、メーリングリストよりも気軽に投稿できるので、何かあればすぐに確認ができます。チャットと違い非同期に書き込めるのでお互いの集中時間も妨げません。youRoomを使えば仮想的に「顧客同室」を実現できます。

メールだとついつい一度に沢山の情報を誤解のないように伝えようと一通のメールが長くなってしまいがちです。そうすると、気軽な返信ができなくなってしまい、また返事も長くなるという悪循環に陥ることで結果コミュニケーションの総量が減ってしまうという問題がありますが、youRoomだとそんなことは起こりません。一つの情報量を制限することで、総量としてのコミュニケーション量を増やすことができます。

Githubとコードの共同所有、コードレビュー、リファクタリング

開発中のソースコードはGithubで共有することで「コードの共同所有」を行いますし、Githubのソースコードにコメントが出来る機能を使って、プログラマ同士で「コードレビュー」を行います。コードレビューで知識と知恵の補完をすることができ、その指摘をもとに「リファクタリング」を行うことで保守性が高まります。ソニックガーデンでは外部のデザイナーともGithubを使って共有しています。

RSpec、Cucumberとテスト駆動開発、ペアプログラミング

プログラミング時には、RSpecとCucumberを使って「テスト駆動開発」を行うことで、繰り返し開発をしてもデグレしないようにしています。また実装上で難しい箇所を開発する際や、本番環境を触る際は必ず２名以上で作業にあたるようにしており「ペアプログラミング」と呼ばれています。ソニックガーデンではペアプログラミングをしやすいように、フリーアドレス制にしているのと、机を向かい合わせでなく背中あわせになるようにレイアウトしています。

Herokuとステージング環境、継続的デリバリ

プログラマ側で完成したら、HerokuというRubyのPaaS上に作った「ステージング環境」にアップロードします。プロダクトオーナーはいつでもこのステージング環境を見ることで動くソフトウェアを確認することができます。「継続的デリバリ」をする対象がステージング環境になります。プロダクトオーナーは動作確認が出来れば、Pivotal Tracker上でアクセプトすることで、そのユーザストーリーが終了します。

Skypeとイテレーション

１週間単位くらいでSkypeを使ったリアルタイムのミーティングも実施します。このミーティングは進捗の確認というよりも、次の１〜２週間で何を作るのかといった認識あわせをする場になります。なぜならば進捗状況は、毎日Pivotal TrackerとyouRoomで確認出来ているからです。ここは「イテレーション」とよばれるタイムボックスを意識する場でもあります。期間をきることで、決めるべきことを決めて進めていく感覚になります。日々の情報共有さえできていれば、30分もかからずに終わることも多いです。

なぜ対面の会議でなくてSkypeなのかというと、会議のための移動には無駄なコストが沢山ついてくるからです。移動する人数分の移動コストは無駄ですし、会議が始まるまでの待ち時間も無駄です。人数が増えると日程調整もままならなくなります。なので、会議は必要な時間だけ繋ぐSkypeがベストです。また、SonicGardenにはアイルランド在住のプログラマもいるので、必然的にSkypeにならざるを得ません。

このようにして、実際に動くソフトウェアを中心にして、徹底的に無駄を省きながら、繰り返して開発を続けて改善していっています。紹介したツールはすべてクラウドから利用でき、無料で試すことができますよ。

ご質問などあれば、お気軽にTwitter( @kuranuki )などで聞いて下さい。

以前の記事「アジャイルはロックだったんじゃなかったか」で、主旨文を書きましたが、今回の東京サテライトは、メイン会場では出来ないチャレンジをしていこうと【アジャイルmeets スタートアップ！】というテーマにしました。

アジャイルがビジネスを作るとき、必ずしも既存組織からでないといけないってことはないはずで、むしろ新しいビジネスを産み出すときにこそ、アジャイルでなければならない、という思いがあって、「アジャイル」の新しい出口を示したいと思いました。このテーマはこれまでの客層に受けるテーマとは大きく違うので不安ではあったのですが、そこはサテライトということでチャレンジしても良いんじゃないかと考えたのです。傍流から小さく始めるのはスタートアップの基本ですしね。

ここからは、AgileJapanアジャイルジャパン2012の東京サテライトで用意したオリジナルコンテンツの紹介をしていきます。今回の登壇者のキャスティングでは、これまでアジャイルと言えばのお馴染みのメンツではなく、あえて新しい人たちを多く登壇してもらうことにしました。これもサテライトならではの新たな試みです。ここから次のロックスターが産まれることを期待しています。

アジャイル入門セッション：「楽天での実践から学んだアジャイルのはじめ方」

日本最大のアジャイルのイベントであるアジャイルジャパンとしては入門から応用まで幅広くセッションを用意したいと思い、入門セッションを用意することにしました。そこで登壇頂くのは、楽天株式会社の藤原大さんです。楽天での数千人規模で使うRedmineを導入した人で有名な藤原さんです。

今回は、入門セッションとして「実践から学んだアジャイル開発のはじめ方」という内容でお話頂きます。作り途中の資料を拝見してますが、ワクワクするような内容ですよ。楽天の藤原さん、これから期待のアジャイラーです。

ワークショップ：「リーンスタートアップ　新規事業を成功させる４つのステップ」

アジャイルジャパンでは毎年ワークショップを開催し、参加型で頭と手を動かして、アジャイルを体験してもらうということをやっています。今年のテーマでワークショップをするとなると、「リーンスタートアップ」は外せません。そして、リーンスタートアップのワークショップをして頂くのに、"Lean Startup Japan"の和波さん以外に思いつきませんでした。

４月頃のエリックリースのリーンスタートアップ本の発売と来日も控えたこのタイミングで、まずは日本のリーンスタートアップのエヴァンジェリストから直々に学び、体験することのできる機会は貴重です。

ワークショップの構想からお手伝いさせて頂きましたが、エンジニアにとっても、新たなサービスを作りたいと考えている人にとっても、非常にエキサイティングなものになったんじゃないかと思います。技術をどのようにビジネスとして表現できるかを学ぶワークショップを通じて、アジャイルがビジネスに貢献できることを知ってもらいたいです。そして、なんとスペシャルサポーターとして、Rubyの会や達人出版会でも有名な高橋征義さんにお手伝い頂けることが決まりました。技術と起業の両方がわかる視点をもった高橋さんのアドバイスも必見です。

ワークショップ：「リーンUX流「顧客発見」～プラグマティック・ペルソナで顧客を見える化 」

リーンスタートアップのワークショップが、ビジネスをどう作っていくかの話であれば、こちらはどうやってサービスやプロダクトを作っていくかのワークショップになります。リーンUXを実体験できるワークショップには、先日書籍「アジャイル・ユーザビリティ」を出版されたばかりの樽本さんにお願いしました。

ただのシステム開発ではなく、ビジネスに繋がるサービスやプロダクトのデザインには、ユーザインタフェースを考えるだけでなく、顧客がどう感じどう考えるかまで踏み込んだユーザエクスペリエンスが重要になります。そして、本当に良いモノを作ろうとするならば、そのUXの部分は専門家が知っていれば良いものではなく、モノ作りをするプログラマやエンジニアも知っているべき内容なのです。参考：ユーザエクスペリエンス設計は誰のものか

パネルディスカッション：「新しいビジネスを創るためのカギ」

ワークショップの裏で開催するのは、私がモデレータをさせて頂くパネルディスカッションになります。今回のパネルディスカッションでは、エンジニアでありながら、ビジネスのことにも関わってきた３名の方に登壇頂き、それぞれの立場から「ソフトウェアを創ること」と「ビジネスを創ること」の接点について、これまでの経験談を中心に語って頂こうと思っています。

登壇者は、ユニバーサルナレッジ株式会社代表取締役の井上俊一さんと、株式会社シャノンCTOの堀譲治さん、株式会社co-meetingの吉田雄哉さんの３名です。

井上さんは、ヤフーやバイドゥ（元日本法人社長）といった大きな企業を渡り歩いた後、今はご自身含めエンジニアの社員自身がオーナーシップを持てるような小さな組織でビジネスを創りだしておられる経験をふまえて語って頂きます。

堀さんは、シャノンさんでエンジニアの人数が増えてきた中でCTOという立場から、ちょうどアジャイルに取り組んでいらっしゃることから、エンジニアリングから経営やビジネスを創るという観点からお話頂こうと思っています。

吉田さんは、つい昨年に友人のエンジニア同士で起業されたばかりで、コワーキングスペースなどの新しい働きかたを実践されていることなど、これまでの起業に対するイメージを覆してくれるようなお話をして頂きたいと思います。

このパネルディスカッションを通じて、個性的な考えを持ち、アジャイルな生き方をしてきた３名の方の経験談で、参加者の皆さんの「脳のブレーキ」を壊せるようなものにしたいと思っています。

その他事例セッションも沢山用意しています

ワークショップとパネルディスカッションの後は、３つの会場で並行して事例セッションを行います。IBM、日本マイクロソフト、AmazonWebServiceという３社にコーディネートして頂き、先進的でユニークでためになる事例を、様々なスタイルでご用意頂きました。どのベンダーのセッションが一番人気になるのか、それも興味深いところです。

また軽食付きの交流会を用意しています。スタートアップ界隈でいう「ミートアップ」ですね。一日一緒にアジャイルジャパンで学んだ仲間たちと共に、一日のふりかえりを語り合い、新たな出会いが産まれる場になるようにしたいと考えています。

交流会では、ただの飲み会でおわることなく、事例トークということで、会場の一部を使って、アジャイル実践の事例を語って頂くイベントも用意しています。こちらは時間の許す限り発表して頂きたいと思いますので、もし登壇したいという方がいれば、私まで連絡してください。

ぜひ楽しいイベントにしましょう。皆さんにお会いできるのを楽しみにしています。

アジャイルジャパン2012東京サテライトの申込はこちらから

日常の中でインターネットを使っていれば「こういうサービスがあればなぁ・・」と思ってアイデアが浮かぶことがあると思います。もしくは、新しくローンチされた誰かのウェブサービスを見て「これ、同じこと考えてた。やってれば良かった。」と思うこともあるでしょう。しかし、ウェブサービスのアイデアを閃くことから、実際にローンチできることまでには、実に大きな溝があります。

Campfire in NB / Martin Cathrae

自分でプログラムやデザインが出来るか、もしくはそれが出来る信頼に足るパートナーが見つかるか、といったことも重要ですが、もし、たとえプログラムを作ることができるとしても、オープンソースやクラウドによってコストが下がったと言っても、実際にローンチに至るまでは難しい、という印象があります。

ウェブサービスのローンチに必要な「情熱」

ウェブサービスのローンチが難しいのは、そこに至るまでには相当な「情熱」が必要だと感じているからです。いや、なにがなんでもローンチさせるという「執念」かもしれません。

最初にアイデアが閃いてから、実際に企画を考えたりプログラムを作っていく途中に、挫けるタイミングはいくらでもあります。例えば、ちょっと競合調査をすれば、他に良いものがたくさん見つかります。そうすると、作ったとして本当にユーザが使ってくれるんだろうか、自分のやっていることに意味はあるんだろうか、等と、ついつい考えてしまいがちです。それでも自分が正しいと信じる「情熱」が必要なんです。

また、エンジニアにありがちですが、プロトタイプを作って満足するというケースや、逆にこだわり過ぎていつまでたっても完成しないというケースもよくあります。開発する技術を習得したかったり、腕試しをしたかったりという情熱だけでは、ローンチまでは至らずに終わってしまいます。ここでも、ウェブサービスをローンチした先のゴールがあって、そこに向かう「情熱」がないと続けられなくなってしまいます。

「ちょっと儲かりそう」とか「あれなら自分でもできそう」くらいの気持ちでは、なかなかローンチまでは難しいです。とはいえ、そこまでの情熱を燃やし続けるのは大変なことですし、何も工夫しなければ挫けると思います。

「情熱」を維持するための最も効果的で最も危険な方法

もっとも効果的な情熱の燃やし方としては「退路を断つ」という方法で、サラリーマンの場合は会社を辞めて独立したり、会社経営や個人事業主をしていたとしても、受託などの他からの収入をなくしてしまうことをすれば、やろうとする新規事業に賭けるしかなくなるので、なんとしてもローンチしようとするでしょう。

しかし、それではリスクが大き過ぎます。そもそもローンチできたからといってマネタイズするまでは、かなりの時間がかかりますし、そちらの成功の方が大変です。

そういうリスキーな方法ではなく、副業的に少しずつ進めたり、限られた時間の中でも続けていきローンチに漕ぎ着けるために、なんらかの仕組みを作ることで、情熱を保ち続けることが出来るのではないか、と思います。

「情熱」を維持するための仕組みを作る

ソフトウェアはユーザがいて初めて存在してるのと同じです。そこで、まずは自分たち自身がユーザになれるサービスにした方が良いでしょう。よく「ドッグフードを食べる」と言われますが、自分たちで普段使っていれば改善の意欲は湧いてきますし、最悪、他にユーザがつかなかったとしても存在価値を感じられます。逆に、自分が使わなければ次第に忘れていってしまうことになります。ソニックガーデンのサービスも基本的に自分たちが必要だから作っているものが殆どです。

ソフトウェアは使う人が重要ということで、自分たち以外に最初に使ってくれるユーザを探すというのも大事なことです。誰かが使ってくれて、良いことも悪いこともどちらにせよフィードバックをもらえることは大きなモチベーションになりますし、責任感も緊張感も増します。

最初のユーザを巻き込みつつ、自分たちをうまくドライブするには、イベントなどへの出展や応募に参加するというのは良い方法です。期限が決まりますし、着地しなければいけないですし、それなりの完成度でなければ注目されません。イベントへの応募は良い動機付けになりますし、もしそうしたイベントで賞をもらえたらメディアにも注目されます。

もし、そういうイベントがタイミング的になかったり、もうちょっと前の段階で人を巻き込みたいとしたら、プライベートなプレローンチパーティを開催するのは良い手かもしれません。自分たちの知り合いの中で、作っているサービスを使ってくれそうな人たちに集まってもらいお披露目パーティを開催するのです。その日付が決まると、それまでに恥ずかしいものは出せないので一生懸命追い込まれることになります。また、実際に会って意見をもらうことで、非常に強いフィードバックを得ることができますし、そうして協力してくれた最初のユーザはファンになってくれる可能性が高く、今後の口コミや招待なども期待できます。

その他人を巻き込む期限を設定するときは、あまり長くしすぎない方が良いです。つい完成度を気にしてちょっと長めに設定すると、必ずだれてしまいます。長くても１ヶ月くらいでゼロから必要最小限の機能を作るくらいの期間設定が良いと思います。その必要最小限の機能をリーンスタートアップではMVPと呼んでいます。小さいものを作るには小さな情熱で済む訳です。

なんとか情熱を絶やさずにウェブサービスをローンチさせるには以下がポイントになりそうです。

• 自分たちで使うこと（自分たちが必要としているものを作ること）
• 他人を巻き込むこと（馴れ合いの中でグダグダにしないこと）
• 短い期限を設けること（かっとなって出来る範囲にすること）

それでようやくローンチできたとしても、本当に大変なのはマネタイズするまでです。ローンチ後に続けていけるかどうか、そこには我慢と執念が必要になってきます。その話はまた別の機会に。

ソニックガーデンが自分たち用につくった営業支援ツール"Keep in touch（仮）"のプライベートなα版のモニターを募集しています。くわしくはこちら。モニター希望して頂ける方は、@kuranukiまでリプライください。

キャリア系のサイトでの対談の中でということもあり、エンジニアがこれからの時代、どういったスキルやマインドが必要になるか、ということを話しています。

• [特集:SEが消える 2/3] 脱・従来型SIに必要なのは、第一に経営者の覚悟。第二に営業できる現場エンジニア
• [特集:SEが消える 3/3] 自称スペシャリストほど使えない。新型エンジニアに「トータルフットボール」が求められるワケ
• 変わるSI構造の中で「価値あるプログラマ」として生きる――SIerから独立した倉貫義人氏

この対談記事を読むと、スーパーなSEかスーパーなプログラマしか生き残れないんじゃないか、と不安になるかもしれません。でも、私はそうなって良いんじゃないかと思っていますし、これを読んでそれは「スーパーエンジニア」だというのであれば、それが「普通のエンジニア」と思われるような業界にしていきたいと思ってるんです。

もう、理系の大学を出て、専門外だけど選ぶ仕事がないからってシステムエンジニアを目指すとかやめて欲しいんです。文系なら営業、理系ならSEって、誰でも出来る仕事だと思われて、すごい残念な選び方をされてるし、SIerも今までそういう人たちを採りすぎてた。ちゃんとITのプロを目指したい人だけが入れる業界にしたいですよね。

人と話せて、企画ができて、ものづくりができて、サポートもできる人こそがプロフェッショナルなエンジニア。プロフェッショナルなのだから、続けるために努力や才能が必要だとしても、それはそうでしょう、と思うのです。

どうすれば顧客と話も出来て設計も運用もできるプログラマを育てられますかって聞くけど、業務時間の殆どを調整とかExcelとかやらせてたら無理に決まってるよね。

— Yoshihito Kuranuki (@kuranuki) February 25, 2012

目指すエンジニアの姿が見えているならば、それ以外の仕事をしていて上達する訳がないんです。サッカー選手のはずが、他の競技の練習してるようでは試合に勝てる訳がないんです。キャリアを積みたいなら、それが活かされる仕事を選ばなければいけないですよね。

だからといって、やみくもにフリーランスとして独立するとか、会社を起こすとかしちゃうと、それはそれで積み重ねたかったエンジニアとしての時間よりも、別のことに時間をとられてしまうので、気をつけた方が良いです。

ちゃんと、プログラマならプログラマとして集中してキャリアが積めて、その延長上に自分の報酬があがっていけるようなビジネスをしている会社に移るというのが、一番ではないかと思うのです。

ちなみに、ソニックガーデンはそれが出来る会社です。

デブサミ10周年、おめでとうございます。そして、ありがとうございました。10周年という節目で講演させてもらえて、本当に光栄でした。

私は、1日目の「【16-A-7】あの人の自分戦略を聞きたい！」への参加と、2日目の「【17-C-3】オフェンシブな開発～「納品しない受託開発」にみるソフトウェア受託開発の未来」にて講演をさせて頂きました。後者の資料で前者の資料を包括してるので、後者の方を公開します。

デブサミで思い出深いのは、2006年のデブサミにて、XPユーザグループの代表をさせて頂いていたときに、コミュニティ枠で講演をさせて頂き、そこでベストスピーカー賞を頂いたことです。

そのときに発表したのは「カイゼン型開発」というテーマで、プロジェクトの開始前に最低限のソフトウェアを作ってしまい、最初から保守開発を始めるという進め方を提唱しました。多くの共感を頂いてのベストスピーカーだったと思いますが、一方で「理想的だが現実的ではない」という意見も沢山頂きました。

確かにその時は、事例もなく、ただの仮説に過ぎなくて、実現するための技術も足りていませんでした。しかし、それから6年経過した今、あの時のアイデアを実現すべく努力してきた結果、私はソニックガーデンを作り、実際の事例を作って、ただの理想ではないことを証明してきました。

今回の10周年のデブサミで、その私の経験した結果を、デブサミ2006で講演して提案して共感を頂いたことへの、自分なりの回答をする機会を頂けたことは、本当に嬉しく思います。

【17-C-3】オフェンシブな開発～「納品しない受託開発」にみるソフトウェア受託開発の未来

これまでの受託開発のスタンダードは「人月による一括請負」でしたが、そのビジネスモデルでは、顧客にとってユーザのニーズやビジネス環境に応じた仕様変更が困難で、開発者にとっては生産性を幾ら上げてもビジネスに貢献できない、といった多くの問題がありました。

それに対し、クラウドを活用し、開発と運用を分離せず、月額定額の利用料をベースにした新しいビジネスモデルの構築に挑戦し、その結果「納品がない受託開発」に辿り着きました。本講演ではこの「納品のない受託開発」について、実際の事例をもとに紹介します。

伝えきれなかったこと

今回のデブサミのテーマ「10年後も世界で通じるエンジニアであるために」に対する私なりの考えは、10年後も通じるためにはエンジニア自身の努力もたしかに必要ではあるけれど、それだけでなくて、エンジニアがこれまでよりも、もっと重視されて、もっと素晴らしい仕事であると思われるような社会を作っていくことも大事なことだと考えています。

その10年先の未来、ソフトウェアエンジニアの所属する会社としての一つの理想型が「リーンソフトウェアビジネス」という考えかたのもと、小さな組織としての会社が沢山できて、そこで大きなマーケットを創っているということを、私は考えています。エンジニアには、そうした社会で働くには何が求められるのか、それを考えてほしいと思っています。

デブサミが10年続けられたことは、情熱こそがすべての源泉だということを教えてくれたんだと思ってます。デベロッパーは何かを作り出す力があって、それが世界を変える時代になった。あとは情熱さえあれば世界を変えることが出来ると教えてもらったんです。次は、僕らの番ですね。 #devsumi

— Yoshihito Kuranuki (@kuranuki) February 16, 2012

デブサミ2012アワード

3/20に追記：

デブサミアワードが発表になりました。

私の講演は、セッションの評価✕来場者数で19位でしたが、満足度ランキングでは3位に入ることができました。ありがとうございます。ランキング2位のまつもとさんの裏番組で健闘した方だと思います。アンケートのコメントも沢山頂けてありがとうございました。

講演の際のTweet集

本書は、2月の16日17日の2日間で開催されるDeveloper Summit 2012（デブサミ）の10周年を記念して出版される本で、デブサミ当日に会場でも購入することができますし、この本の多くの著者の方々もいらっしゃるようです。私も両日とも参加します。

私の選んだ本は、Eric Sinkの「Eric Sink on the Business of Software 革新的ソフトウェア企業の作り方」という本です。色々ある本の中で１冊だけ選ぶというのはとても難しかったのですが、私がプログラマでありながらビジネスを考えるきっかけになった本ということで、この本を選びました。他の方と被らなければ良いなーと思ってたんですが、アプレッソの小野さんが選んだのと同じ本でした。。。ま、それだけ良い本だということで。

起業のサクセスストーリーはたった一つじゃない〜起業を考えはじめたプログラマに読んでもらいたい1冊

革新的ソフトウェア企業の作り方　Eric Sink on the Business of Software

「起業すること」は、多くのプログラマが一度は考えることだと思います。オープンソースやクラウドといった環境が整いつつあり、スタートアップについても以前に比べ遥かに多くの知識を得ることができるようになりました。私としては、たくさんのソフトウェア企業が出てきてほしいし、プログラマ自身が起業することは多いに賛成なのですが、それでも、安易に会社を辞めたりするのではなく、まずは、どういった企業を作りたいのかを考えるべきだと思います。もちろん、本当に起業すべきかどうかも考えるべきです。

自分一人で食べていくフリーランスなのか、コンサルティングや受託開発をするのか、自社の製品を広めたいのか。ベンチャーキャピタルから出資を受けるか自己資金か。短期間での上場を目指すのか。目指すビジョンによって採るべき選択肢は大きく変わってきます。世の中で目にするスタートアップに関する情報は、ウェブサービスを立ち上げてベンチャーキャピタルから投資をうけ、上場かバイアウトによって一攫千金を得たというようなサクセスストーリーが多いです。しかし、それだけが成功のビジョンではないはずです。

起業を考える上でも、企業のあり方には様々なビジョンがあることを知っておくべきだと思い、本書を推薦します。

この本には「小さなISV」という表現が出てきます。ISVとはIndependent Software Vendorの略。自社でソフトウェアを作り販売しているソフトウェア会社のことです。中でも、特に少人数で構成されている会社のことをそう呼んでいます。著者のEricはこう言っています「小さなISVは小さいままでいる傾向がある。大きくなるにしても、成長はゆっくりとしている。有機的に成長し、自身の利益を投資することで成長する。小さなISVは地味でも収益を上げていることが多い」。こうした会社のあり方も一つのビジョンなのです。

私は、学生時代にベンチャー企業で働いた後、大手のシステムインテグレータに就職し、そこで12年働きました。その大企業の中では、現場部門から企画部門など様々な部署を経験させてもらい、そこでの最後の２年は社内ベンチャーという形で小さな組織を経営する経験をしました。今は、その社内ベンチャーである「SonicGarden」をMBOすることで、株式会社ソニックガーデンの代表取締役をしています。ソニックガーデンも小さな会社であり、これからもさほど大きくしていくつもりはありません。それが私のビジョンだからです。

私たちはアジャイルソフトウェア開発が好きで、自分たち自身で実践していたいと思っています。アジャイル開発では分業をしないため、プログラマはただコーディングをするのではなく、ソフトウェアを作る全ての役割を担います。プログラマが多くの役割を担うことで、間接的な職種や情報共有のための会議などを極力なくして高い生産性を発揮できるようにするために、小さな組織であることを大事にしています。小さな組織で大きな収益をあげることは、時間を販売していては成立しないため、ビジネスモデルが重要になります。

ソフトウェア企業の場合は大量の資金調達がなくても成立するため無理に上場する必要はありません。小さい組織のままで大きな利益をあげていくことで、社員全員で、長く豊かな生活を送るというビジョンをもっています。一般的な起業とは違うイメージかもしれませんが、こうした考えかたもあるということです。

起業を考えたとき、一か八かの一攫千金を狙って大きな賭けに出るようなビジョンだけではなく、ローコストながらも着実に成長するようなビジョンもあると知っておくことはとても大切です。本書を読むことで、後者のビジネスにおいてオーナーシップを持つにはどうすれば良いか、プログラマならではの視点から学ぶことができます。

具体的なテクニックや内容は本書を読んで頂くのが良いと思いますので、以降では私が本書を読んで感じたことや、考えたことを記しておきます。書評というよりコラムになってしまいました。

ユーザエクスペリエンスの難しさ

そもそもユーザエクスペリエンスとはなにか。ソフトウェア開発で言えば、ディスプレイに表示される画面のインターフェースのことではありません。それは単なるユーザインタフェースに過ぎないのです。ユーザエクスペリエンスとは、利用者がそのソフトウェアと対峙をした際に感じる気持ちや感覚、結果として受ける印象や思考の流れのことまでを含んだもののことです。

ユーザエクスペリエンスの設計は、単に出来ることを満たせば良いかどうかという機能の話だけではなく、どんな色や絵を配置するかといった見た目の話だけでもなく、ユーザ自身の体験を設計しなければいけないので非常に難しいことです。しかも、設計者が設計したものを「伝える」方法はさらに難しいのです。「ユーザの体験」を伝えるって一体どうすれば良いのでしょうか。

そこで「ストーリー」を使います。ストーリーとして表現すること、伝えることで、「ユーザの体験」を考えることが出来るし、共有することができます。ストーリーテラーとして書き出すことで、利用者の心理状況を具体的に考えることができるし、オーディエンスはストーリーを読むことで利用者の気持ちを追体験することができます。

ユーザエクスペリエンス設計は誰が身につけるべきか

製品のユーザエクスペリエンスは、誰が設計するべきでしょうか。もしくは、ユーザエクスペリエンスの善し悪しを誰が判断すべきでしょうか。単にUX専任のデザイナーがいれば済む話ではありません。ユーザエクスペリエンスとは製品そのものを表すと言ってよくて、だからこそ、製品やサービスの責任者自身が、ユーザエクスペリエンスの設計に携わるべきです。専門家にアウトソーシングして済む問題ではないのです。

製品やサービスの責任者であれば、ユーザエクスペリエンスを考えるべきだし、他に作り手がいるのであれば、それを伝えなければいけません。ユーザインタフェースの設計に画一的な答えはありません。使うユーザやシチュエーション、そのサービスで実現したいビジョンによって、ユーザインタフェースは変わってきます。そのユーザインタフェース設計の前提となるのがユーザエクスペリエンスについての共有です。

ユーザエクスペリエンスがちゃんと伝わっていなければ、ユーザインタフェースや機能についての本当に細かい点まで伝えないと思い通りにならないと嘆くことになるでしょう。しかし、ユーザエクスペリエンスが共有できていれば、そんなことにはならないはずです。製品やサービスの責任者であれば誰でも、ユーザエクスペリエンスについて学び、伝え方としてストーリーテリングを学び、実践すべきです。その学びのきっかけとして本書を読むと良いでしょう。

アジャイルとユーザエクスペリエンス

ソフトウェア開発においてはアジャイル開発というのは、ユーザエクスペリエンスを高める最良の方法だと、考えています。ソフトウェアの場合は、実際に動かすまで本当にどんなユーザ体験が起きるのかわかりにくいという問題があります。動くソフトウェアなしでユーザエクスペリエンスを高めることはとても難しいのです。よって、アジャイル開発を通じて動くソフトウェアで確認していくことは効果的なんです。

ではストーリーは不要でしょうか。そんなことはありません。大河ドラマほどになるような膨大なストーリーを最初から最後まで用意しておくようなことは必要ありませんが、プログラミングをしていくにあたり、やはり何かしらのよりどころがなければ、ユーザインタフェースの設計に一貫性を欠くことになってしまいます。

アジャイルの場合は、一気にすべてのストーリーを書き上げるのではなく、少しずつ書いていき、それにあわせて少しずつ動くソフトウェアを完成させていき、その動くソフトウェアからのフィードバックをうけてまた、ストーリーを書き直したり書き足したりしていくというやり方になります。アジャイル開発では昔から、作るべき仕様を「機能」や「要求」と言わずに「ユーザストーリー」と呼んでいたのです。

アジャイルジャパン東京サテライトでも、ユーザエクスペリエンスに関するセッションがありますので、ユーザエクスペリエンスに興味をもったなら、ぜひご参加ください。

目次　こちらより引用

• 1章：なぜストーリーなのか？
• 2章：UXストーリーの効果
• 3章：ストーリーは聞くこと、そして観察することから始まる
• 4章：ストーリーの倫理
• 5章：UXプロセスにおけるストーリー
• 6章：ストーリーを集める
• 7章：ストーリーを選択する
• 8章：アイデアを生むストーリーの使い方
• 9章：ストーリーで評価する
• 10章：ストーリーを共有する
• 11章：ストーリーをクラフトする
• 12章：オーディエンスに配慮する
• 13章：ストーリーの構成要素を組み合わせる
• 14章：構造とプロットを作る
• 15章：ストーリーの伝え方
• 16章：新しいことに挑戦する

アジャイルジャパン2012東京サテライト

午前中のアジャイルサムライ著者やTOC岸良氏のキーノートスピーチについては、大画面を使ってのUST生放送をパブリックビューイングします。そして、午後は東京オリジナルのコンテンツを用意しています。

私は東京サテライトの実行委員でもあるので、大阪には行かないで、東京を盛り上げていきたいと思っています。

もっとしびれるようなソフトウェア開発がしたい

今年の東京のアジャイルジャパンはサテライト開催のため、いわゆる王道のアジャイルではなく、サテライトだからこそ尖ったメッセージをもって取り組みたいと考えました。熱い大阪に負けない位、熱くてエネルギーの坩堝のようなイベントにしよう、と。

アジャイルはソフトウェア開発の現場で産まれました。プログラマたちから始まったムーブメントが、マネジメントの場面、顧客との関係、そして会社の組織変革へと広がって来ました。それに伴い語られる問題が、大規模なプロジェクトでどうすれば良いか、組織の経営者や顧客にどう伝えるのか、固い会社の中でアジャイルをするには、といった話題ばかりになってきたように思います。そういうの正直ワクワクしないんです。

そんな制約や体制の中でどうすれば良いかなんて考えるのではなくて、そんな前提をぶっ壊すようなアイデアやアクションをとるのがアジャイルだったと思いたいのです。モノ作りの原点に帰って、もっとしびれるようなソフトウェア開発がしたいのです。

Cults / Man Alive!

そこで、アジャイルジャパン東京サテライトでは「モノ作り・製品作り・サービス作りへの原点回帰」をテーマに【アジャイル meets スタートアップ！】として開催することにしました。スタートアップといっても、必ずしも会社を作ることではなく、スタートアップとはソフトウェアを創る人とビジネスを創る人が一体となって、新しい製品やサービスをつくっていくことだと位置づけています。

どうすれば大規模の人数でもアジャイルっぽくするか、よりも、小さなチームで大きな成果を出すのにどうすれば良いかを考えたい。

情熱のない人たちの多い会社を変えるにはどうすればいいか、よりも、自分の人生を捧げるほどの情熱を仕事にぶつけることを考えたい。

変わってくれない他の誰かを変えようとすること、よりも、自分自身がアジャイルであり続けるために挑戦していくことを考えたい。

ソフトウェアでも世界を変えることができる場所があります。次の市場を創りだすことのできる場所、それが新規事業すなわちスタートアップです。そして、ソフトウェアによる新規事業の主役は「ハッカー」であり、中心の場所は「モノ作り・製品作り・サービス作り」の現場で、そこで求められる姿勢は「アジャイル」なんです。

アジャイルジャパン東京サテライトでは、アジャイルのもう一つの出口としてのスタートアップにフィーチャーして開催したいと思います。

最後に、私が東京サテライトのサイトに書いた東京側の主旨文を載せておきます。ぜひご参加ください。皆様に会えるのを楽しみにしています。

アジャイルジャパン2012 東京サテライト開催に向けて

アジャイル誕生から10年が過ぎ、「アジャイル開発」は以前とは比べようもないほど広く知れ渡り、多くの事例が生まれ、様々な場面で応用されてくるようになった。そして、アジャイルが広まれば広まるほど、組織で活用するための「マネジメント」の話題や、組織に根付かせるための「既存の組織改革」の話題が多く聞かれるようになってきた。

アジャイルが「ソフトウェア開発」の現場だけの手法で終わることなく、マネジメントや組織改革の取り組みに繋がっていくことは、自然なことで素晴らしい試みに違いない。アジャイルは大人になった、アジャイルに携わる私たちが大人になったのだ。良く言えばアジャイルは成熟したのだが、一方で本当にアジャイルは、そんなお行儀の良いものだったか？という疑問が沸々とわいてきた。

アジャイルの本質が人や組織にあることに異論はないが、10年前にアジャイルが登場して感じたことは、もっと破壊的で混沌としつつも、それでいて本当に役に立つソフトウェアを創りだすことが出来る期待感だったはずだ。ソフトウェア開発は、実際に作ってみなければわからないことばかりだし、だからこそプログラミングを中心に据えるやり方が良いとモノ作りの現場から始まったのだ。

本来のアジャイルは既成概念や体制を批判し、新たなムーブメントを作ろうとするロックだったんじゃなかったか。だからこそ惹かれたんじゃなかっただろうか。

そうであれば、既にある企業の組織改革やマネジメントに目を向けるアジャイルがある一方で、もう一方に振り子を、しかもエクストリームに振る必要があると感じている。つまり、ゼロからソフトウェアを作りビジネスを創りだしていくというスタートアップにも目を向けたい。ソフトウェアを創る人とビジネスを創る人が渾然一体となって、新しいモノやサービスを作り上げる場面でのアジャイルの活用だ。

そこで、AgileJapan東京サテライトでは「モノ作り・製品作り・サービス作りへの原点回帰」をテーマに【アジャイルmeets スタートアップ！】として開催する。

「スタートアップ」というと会社を起こすイメージがあるが、会社の設立＝起業ではない。会社を作るかどうかに関係なく、新しいモノやサービス、製品をゼロから作り出すこと、そしてモノ作りからビジネスを創っていくことこそがスタートアップなんだ。そして、ソフトウェアでゼロからイチを創ることや、何かを新しく始めることにおいて、アジャイルほど適した進め方は無いはずだ。

昨年の震災以降、多くの日本人がその価値観を見直し、変えてきているように思う。新しい働きかたを提案して自ら実践する人たちや、これまでに無かったサービスを産み出し市場を作ろうとする人たち、そうした日本の未来につながる新しい動きがたくさん出始めている。

AgileJapan東京サテライトでは、そうしたムーブメントを応援すべく、アジャイルが新しいサービスやビジネスを創りだす上でどのように役に立つのかを学べる場を提供したい。新しいことを始めようとする気持ち、新たな息吹を感じたい気持ち、未来につながる新しい変化を起こしたい気持ちを持っているなら、ぜひ参加してほしい。

新しいアジャイルの1歩を踏み出そう。

アジャイルジャパン2012東京サテライト

アジャイルをも活用した新しいビジネスモデル

アジャイルとビジネスモデルに関するパネルディスカッションなので、本来であれば私がぜひ登壇して「納品のない受託開発」を紹介したいところですが、私は東京サテライトを担当しており、大阪に行けないため代理で弊社ソニックガーデンの副社長に出てもらうことにしました。彼が表舞台に出ることはあまりないので貴重な機会ですが、ソニックガーデンの契約書など全て彼の仕事なので、私よりも具体的な話が聞けるはずです。

そして、そのパネルには当然ですが「価値創造契約」を掲げる永和システムマネジメントの方が登壇されます。そこもきっと永和システムマネジメントの木下さんが出てくるものだと思っていたら、登壇するのは市谷くん（papanda）だというのです。DevLOVEの立場でなく永和システムマネジメントとしての立場での彼から、そのビジネスモデルについて語られるというのは、これも貴重な機会ではないでしょうか。

そして、何よりこの２人が同じ舞台に立つということに、私の極めて個人的な感情ですが、なんとも不思議な運命を感じているのです。

会社を変えようとした２人

私がこれまでの仕事人生において、最も暑苦しくて面倒くさい（賛辞です）、そんな人を思い出すといえば、永和システムマネジメントの @papanda こと市谷くん、そしてもう一人は弊社ソニックガーデン副社長の藤原です。（敬称略で普段の呼び方で書いてます）

市谷くんと藤原の2人は今でこそ袂を分かち、別の会社で働いているけれど、もしかすると今も同じ会社で共に働いていたかもしれません。何故なら彼ら2人と、そして私は、かつては同じ会社で働いていたからです。そんな2人と私の関わりを少し紹介します。

市谷くんと藤原の最初の出会いは、当時その会社で私が作って運営していた社内SNS（今のSKIPの元になったもの）の中で立ち上がった社内イベント企画の運営委員会でした。

Developers Summit（デブサミ）に刺激を受け、社内デブサミをしようと言い出したのは市谷くん、そして、その運営に乗り出したのが藤原でした。旗を振る市谷くんと、先に進める藤原と、今思えば、そのイベントのCEOとCOOとしてうまく機能してたんだな、と思います。近くで見ていても、楽しそうに輝いている良いコンビでした。

そして彼らはそのイベントをやり遂げ、会社の風土を少し変えてしまうことになるのです。それについては以下の記事が詳しいです。この頃は、この2人に今の未来が待ち受けているとは、私を含め誰一人予想すら出来ませんでした。

身近な仲間と繋がり、刺激を与えあう「社内デブサミ」はいかにして生まれたか ～「会社の空気を変える」社員のつくる社内イベント

後に彼らのこの活動は時を経て、別の場所で大きな実を結ぶことになります。

ひとつは、IT業界の若者たちに大きな影響を与えるコミュニティに成長したDevLOVE。社内デブサミの経験を経たのち、市谷くんは外に意識を向けました。

もう一つは、社内SNS：SKIPというサービスとなり、ソニックガーデンの事業の大きな柱となりました。藤原の会社風土を変えた経験がビジネスになりました。

彼らがその社内イベントをやっていた頃、私はソニックガーデンの前身である社内ベンチャーの立ち上げに奔走していたのを覚えています。そして新規事業の新しいチームを作るなら、この2人と共に、と考えてました。出来ることなら一緒に働きたいとも思ったのですが、当時の私の政治力の至らない点などもあり、それぞれ別の部署で働く彼らが、その私のチームに入ることはなかったのです。

市谷 聡啓 氏　株式会社永和システムマネジメント

市谷くん。彼は私が大手SIerの中でのアジャイルに取り組んでいる頃に、そこに中途入社してきたのでした。大阪から上京してきたばかりの彼とは、同じ大学出身だったり、住んでる家が近所だったり、接点も多くて仲良くなり、よく話をしたものでした。当時の私は既に「ディフェンシブな開発」を発表するに至るほど、自分自身はSIerのビジネスモデルとそこでのアジャイルの難しさを実感し、社内向けのSNS開発に自分の戦略を変えた時期でした。

そんな私から見て、現場でアジャイルに取り組み、傷つき苦しみながら挑戦を続けている姿は、まるで自分の若い頃を見ているかのように思えていました。大手SIerでぶつかる壁にことごとくぶつかっていましたね。だからこそ、私は彼の相談にはのりたいと思ったし、期待もしていました。私の出来なかったアプローチで彼ならば成し遂げるかもしれない、と。私が彼に出来ることの一つは、彼がやってみたいということに対して「やれば良いじゃない」と極めて軽く返すことでした。それは、かつて私が平鍋さんにしてもらったことで、本人が重く考えてることを、相談相手が軽く返してくれたら、気軽な気持ちでチャレンジできるから。これはまた別の平鍋さんとのエピソード。

しかし数年後、彼はその会社を去ってしまったのです。理由は私は知りません。もっと話をしておけば良かったと悔やむこともありました。ただ、彼はもう大阪から上京したてのただのパンダではなく、社外に多くの居場所をもつまでに成長したからかもしれません。

再び私の前に現れた時、彼は永和システムマネジメントの人になっていました。再会したときの彼の目は、大阪から希望をもって上京してきた、あの時の目をしていました。彼はもしかしたら、最後の場所を見つけたのかもしれません。

藤原 士朗 氏　株式会社ソニックガーデン

藤原士朗。彼は私が大手SIerで現場を離れ管理職になって初めての新卒採用したうちの一人でした。私が採用したもう一人の藤原の同期は、今や私よりも有名になったid:rx7こと並河です。今思えば、その年の新人は良い人材が揃っていたのですね。彼らの入社したころの私は、社内にアジャイルチームを作り、多くの人を集めていた時期でした。

しかし、ちょうど彼らが入社して数年した頃、私に大きな転機が訪れます。ある事情により私のチームが解散させられることになってしまうのです。十数人いた私の部下は全て別のプロジェクトにもっていかれ、残されたのは、藤原ただ一人でした。２人きりのチームになってしまい、色々と考えた結果、たった２人で初めて触るRubyを勉強しながら社内SNSを作りはじめたのでした。私がRubyで社内SNSを作ると言い出したとき、彼にはどうするか聞いたのを覚えています。私についてくるということは普通のSEとしての出世からは外れてしまう、ただしエキサイティングであることは間違いないが、どちらを選ぶか、と。彼は即答しました、私と一緒にRubyで社内SNSを作ることに。

その数年後、彼も社内の人事異動によって、私のもとから去っていくことになります。その代わりに並河が戻ってきて、私のもとで今のクラウドに繋がる技術に取り組みブログを書き始め、それが今のソニックガーデンの基盤に繋がるのですが、それはまた別の並河とのエピソード。藤原が、私の元から離れている間に、部門の壁を越えて社内デブサミを立ち上げたのが市谷くんだったのです。そこで繋がったのです。

さらに数年後、藤原は私の元に戻ってきてくれました。彼と２人で作った社内SNSを事業の柱とする社内ベンチャーSonicGardenの誕生です。その彼は今、私とともにMBOをし株式会社ソニックガーデンの副社長をしています。

アジャイルをも活用した新しいビジネスモデル

市谷聡啓と藤原士朗という、私と何度もすれ違い繋がって、離れていったり、同志となったりした私の人生とも大きく関わった２人が、AgileJapanという大舞台で、一緒に壇上にあがり対談をするということに、数奇な運命を感じているのです。

「価値創造契約」と「納品のない受託開発」この２つのビジネスモデルは大きな違いがあります。それは、実際にやっている私たちだけにしかわからないことかもしれませんが、もしかしたら、このパネルディスカッションを通じて、その違いについて知ることが出来るかもしれません。

私は何より、この２つのビジネスモデルを代表する、２人の男の運命の対談が楽しみで仕方ないのです。

AgileJapan アジャイルジャパン2012