Social Change!

少し前になってしまいましたが、シリコンバレーの「Plug and Play Tech Center」で行われたtanabata.usというイベントに参加してきました。

チェンジビジョンの平鍋さんに誘って頂き、ヌーラボの橋本さんと３人で行ってきました。イベントの詳しくは平鍋さんのブログに詳しいです。

http://blogs.itmedia.co.jp/hiranabe/2010/07/tanabataus.html

tanabata.usでは、ライトニングトークスのような発表の場があり、シリコンバレーで働くエンジニアやスタートアップの起業家、投資家の前で、SonicGardenとyouRoomについて発表してきました。そのときの資料は以下です。

astah* や cacoo と違って実績も少ないので、コンセプトを伝えて、あとはデモを見せるような内容にしました。ビジネスモデルとして、Freemiumというのは一般的な様子でした。

今回は、このイベント以外にもシリコンバレーやサンフランシスコ周辺のスタートアップ企業やソフトウェア企業を訪問してきました。そのあたりについては、また別のエントリで。

チームやプロジェクトの情報共有や協調作業で使えるyouRoomというサービスが、Twitterの見た目を参考にしているところもあって、仕事でTwitterをやろうという場合に使えるのではないか？と考えてもらうことも多いです。

一方で、SKIPという企業内で使うSNS、いわゆる社内SNSもあったりする。こちらは、見た目はTwitter風ではなくレガシーなSNSに近いため、気軽に使えるという印象が弱くなっているように思う。（Twitterが広まったことで、ブログが相対的に重厚な印象を持つようになったように感じてます）

youRoomとSKIPで、どちらがどう使うか、違いは何か、というところについて、作った我々はわかっているつもりだったけど、ちゃんと整理していなかったので、以下の図のように整理してみました。

横軸に目的や用途で分類し、縦軸では特徴的なポイントで分類してみました。精密に考えると違っているところもあるかと思いますが、雰囲気は伝わると思います。（SKIPとyouRoom以外のツールは私の勝手な見方です）

youRoomでは、メールのような1on1ではなく、ある程度テーマで括られた複数人のグループの中での情報共有を考えて作りました。そこのルームへの書き込みは、自分の呟きや日記というよりも、そのルームに参加しているメンバー全員へ向けたメッセージになります。なので、あまり自分だけで完結するような独り言は書きにくくなっていると思います。逆に、そのルーム全員が見てる中で連絡・会話をすることが出来るので、チーム内で起きていることを自然と共有することが出来ます。だから、youRoomはメーリングリストの今風への置換えになることを目指しています。機能は違いますが、立ち位置はグループウェアにも近いかもしれません。

SKIPでは、youRoomと違って、会社などといった組織で用意された「場」の中での個人の発言にフォーカスをあてています。SKIPでのユーザ自身の発言（ブログ等）は、誰かに向けたものではなく、あくまで自分自身で完結する独り言に近いものになります。特定の誰かに向けたものでないということから、気軽に書き込みをすることが出来ると言えます。メールで全社員に向けて勉強会の案内をするのは気が引けるけれども、ブログで案内することは気軽に出来るはずです。興味のある人だけが見れば良いからです。送りつけるのではなく見にくる、という感覚です。SKIPでは、組織内で個人と個人を結びつける役割を果たします。

そうして考えると、SKIPは「会社のビル」のような場であり、そこで話される内容は、業務も含みますが、どちらかというと会社や仕事に関する雑談が交わされる場。youRoomは、「プロジェクトルーム」のような場であり、そこで話される内容は、業務などの特定のテーマに限った話をする場、とすることができるかもしれません。なので、SKIPではセクションをまたぐ横の連携、youRoomではセクション内での縦の連携に使えそうです。

一方で、今のSKIPは、旧世代的であり、レガシーな機能と見た目をしているのは事実です。よって、前述のような使いかたと機能の違いで見れば、SKIPが向いているようなものでも、youRoomを使おうと考えてしまう場合もあり、混乱を産んでます。そこで、SKIPもバージョン2を目指すという段階で、右下のポジションを目指した改良を実施しようかと考えています。ただ、そこにはすでに、Chatterやyammerがいそうな気がしてます（笑）逆に、youRoomは、その辺りと本当は競合しないんですが、見た目で誤解されてることが多いです。

日経コンピュータさんに２号連続で掲載頂きました！

2月17日号には「幸せを呼ぶアジャイル開発」の連載で、SonicGardenを取り上げて頂きました。112pです。号全体がクラウド特集ということで、クラウドサービスをアジャイルに開発している私たちにお声をかけて頂けました。取材で好きなようにだけ喋ったんですが、うまくまとめてくださってます。http://coin.nikkeibp.co.jp/coin/nc/special750/

3月3日号では、同様の連載で、XP祭り関西2010でお話させて頂いた内容を掲載して頂きました。XPの10年を振り返る、というテーマで話した内容です。こちらは、ぐっとアジャイルにフォーカスした話です。

2月6日に開催されたXP祭り関西2010に参加してきました。

「アジャイルマインドを育もう」というテーマで開催された今回のXP祭りに呼んで頂いて、お話しする機会を得ました。「アジャイルマインド」という曖昧なテーマではあるんですが、私なりの「アジャイルマインドとは何か？」を探るために、eXtreme Programmingが誕生してからの10年を、コミュニティの歴史と共に、私自身のXPライフについて振り返ってみました。そのエッセンスから、参加された皆さんに、私が考える「アジャイルマインド」について感じてもらおうと考えました。以下、資料です。（言葉で補足しないと伝わらないかも）

スタッフのみなさん、本当におつかれさまでした。

福岡県の主催する「第２回フクオカRuby大賞」にて、Ruby製のオープンソースの社内SNSである"SKIP"が、優秀賞を頂きました。多くの応募の中から選んで頂き、大変光栄に思います。ありがとうございました。

http://www.pref.fukuoka.lg.jp/f17/rubyforum2010.html
http://itpro.nikkeibp.co.jp/article/NEWS/20100127/343813/

【受賞理由】

ユーザの意見を迅速に反映しながら運営する必要があるSNS（ソーシャル・ネットワーキング・サービス）の開発に、Rubyが有効であることを証明し、今後、同種のビジネスへの適用が期待されることが高く評価された。

頂いた賞に恥じぬよう、引き続き精進して参りたいと思います。

プレゼンテーション審査の際に使った資料を公開します。

私たちSonicGardenは、今回、優秀賞を頂いたオープンソースSKIPを、クラウドで提供する"SKIPaaS"というサービスを提供しています。アジャイルとクラウドの相性の良さについては別途エントリで記事を書こうかと思いますが、アジャイルとクラウドのそれぞれにおいて、今回Rubyを採用したことは私たちにとっても、とても重要な選択だったと思いますし、その選択は間違いなかったと思っています。

Webで何か新しいサービスを考えようとしたときに、必ず立ちはだかるのがGoogleです。面白そうなアイデアを思いついたとき、「Googleがやっているのではないか？」「Googleが始めたらどうなるか？」を考えてしまいます。

私たちも、youRoomという「メーリングリスト+Twitter」のようなコミュニケーションツールを提供していますが、GoogleGroupsとの違いであったり、Googleの今後の動きは気になっています。

Webの世界におけるGoogleの存在感は、今となっては圧倒的とさえ言えます。10年前であればマイクロソフトが握っていた巨人のそれです。なので、何かWebで始めるときに、Googleを意識しない訳にはいきません。

先日も、bit.lyをはじめとする、URL短縮サービスにGoogleが参入するニュースが話題となりました。既に始めているURL短縮サービスにとっては、戦々恐々とする思いかもしれません。

一方で、YouTubeのように、GoogleのGoogle Videoと正面から戦った上で、買収されるという結果もありますね。必ずしも、Googleが勝つとは限らないのがWebの世界の面白いところです。

では、今もっとも勢いがあるWebサービスと言えば、Twitterでしょう。1500万ドルでGoogleと提携したというニュースもありました。そこで一つ疑問が湧きます。

なぜGoogleはTwitterを作ることが出来なかったのか？

Twitterの基本的な仕組み自体は非常に簡単なものなので、特別な技術が必要な訳ではありません。裏側のスケーラビリティの確保が技術的に困難であるのはわかりますが、そこはGoogleの専門分野と言っても良いでしょうから、さほど問題にはなりません。つまり、テクノロジの問題ではなさそうだと考えました。

20%ルールを持つGoogleですから、技術者の時間という問題でもなさそうですし、「リアルタイムWeb」というコンセプトも、あの天才集団で思いつかない訳はなさそうです。実際にGoogleWaveを作り上げています。だけど、Twitterのようなものは作っていない。何故だろうか。

その疑問をTwitterでつぶやくことで、色々と反応を頂いた中で、@huehara88さんとのやりとりが面白かったので転載します。

放っておいたって勝手に作ってしまいそうな技術者がわんさかいる中で、GoogleからTwitterライクなサービスが出なかったのは「ミッションでないから」という理由は、もっともな気がしました。あっているかどうかはともかく、一応すっきりしました。

Google の使命は、世界中の情報を整理し、世界中の人々がアクセスできて使えるようにすることです。

この有名なミッションに従って、Googleがサービスの提供開始のデシジョンをしているとして、あれだけの社員がそのミッションを理解して働いているのだとしたら、Googleの強さの理由もわかるような気がします。あの規模で、その企業文化を維持できているとしたら、それこそがGoogleの真の強さの源泉と言えるかもしれません。

どんな新しいWebのサービスも「Googleがいるから」と言い訳にしないで、始めてみないとわからない、ということだし、Googleのミッションとは違うことなら、参入してくる可能性も低い、かもしれません。

・・・と言ってるそばから、「Googleなう」なんてサービスが始まったりして。

"XP祭り"というイベントがあります。

eXtreme Programming（通称XP）というアジャイル開発プロセスを、日本に広めるための活動をしている「XPJUG」というコミュニティが開催しているイベントです。2002年に初めてのXP祭りを行い、毎年秋頃に開催してきました。ソフトウェア開発、IT業界で働くプログラマーやエンジニアを中心としたベンダーに依存しない独立した活動です。また、関西に在住のエンジニアの方々を中心に立ち上がった「XPJUG関西」というコミュニティもあり、関西でも「XP祭り関西」が行われてきました。

そして、今年2010年に、2つのXP祭りが予定されています。

まずは「XP祭り関西2010」です。「アジャイルマインドを育もう」というテーマで開催されます。

講演者の面々として、

• アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣の木下さん


• プロジェクトを成功させる 現場リーダーの「技術」の岡島さん


• DevLOVEのpapandaさん


• Redmineやチケット駆動開発を実践されてるあきぴーさん

また、私も昨年のXP祭りで、XPJUG代表の引退を表明させてもらいましたが、今回は私とXPの出会いのきっかけから、経験したこと学んだことなどを振り返りつつ、引退に至まで、お話させて頂く予定です。

「XP祭り関西2010」のお申し込みはこちらから

東京での「XP祭り2010」は、秋頃に開催の予定です。その実行委員会のキックオフが、早くも開催されます。

XP祭り2010実行委員会キックオフ

なぜ、今からキックオフで、なぜ、委員会の参加を募集するのか？それは、昨年のXP祭りのふりかえりをスタッフで行った際に、XPJUGの存在意義について語り合った中で出たアイデアが発端です。XPJUGとして「XP祭り」は非常に大きなもので、逆に言えば、XP祭りを開催することこそが、XPJUGの意義ではないか、と考えたのです。すなわちXPJUGとは「XP祭り実行委員」のことである、と。

XP祭りは、スポンサーを付けずベンダ色のない、あくまで現場のエンジニアの方々を中心としたイベントとして行ってきました。そのため運営スタッフと参加者の境が非常に薄く、運営スタッフも参加者として楽しむし、参加者の皆様にも運営をお手伝い頂くなど、非常に良い関係が築けています。そこで、次の2010年に開催するXP祭りでは、よりもっと参加者の方々との関係を深め、運営についても、よりもっとオープンにしていくことを考えました。

そこで、「XP祭り2010」からは、「XP祭り実行委員会」のスタッフになってくれる方を広くオープンに募っていき、その方々と共に、XPJUG（XP祭り実行委員会）として開催に向けて準備をしていきたい、と思っています。コミュニティ活動は初めて、という方もこれを機に参加頂ければ幸いです。

参加申し込みはこちら・・・XP祭り2010実行委員会キックオフ

また、youRoom上で、オープンなディスカッションを行っています。youRoomへの参加登録は必要ですが、自由に参加できますので、興味のある方はご参加ください。

XPJUGのルーム（ http://r31.youroom.in/ ）

あけましておめでとうございます。本年もよろしくお願い致します。

2009年は、TIS株式会社の中でSonicGardenという社内ベンチャーを立ち上げた年でもあり怒濤のように過ぎ去った一年でした。多くの出会いがあり、色々な方々に支えて頂きながら、ほんの少しですが前に進めることができたと思います。

SonicGardenとしては、去年に引き続き、企業内SNSとしてSKIPを提供させて頂いています。SNSの本質は人と人の関係構築にあると思います。そこに情報を載せることでナレッジとなり、そこに思いを載せることでビジョンを共有でき、そこで個性を発揮することでセクショナリズムを解消することができると考えています。もはやSNSというキーワードはバズワードを通り越して、とりたてて注目する言葉ではなくなっているかもしれません。しかし、企業内におけるソーシャルネットワークとコラボレーションの重要性は、これから益々増してくると確信しています。SKIPでは、思いを同じくして下さる皆様と共に、単なるツールだけでない情熱共有基盤を提供させて頂き、皆様のお役に立てればと考えています。

また、企業内SNSで培ったノウハウと部品群を活かし、youRoomという新しいウェブサービスも始めました。youRoomでは、企業内に限らず、より多くの方に多くの場面で使って頂くために、無料のインターネットサービスとして提供しています。まだ実験的な取り組みではありますが、「あなたにとって世界（ソーシャル）は一つではない」というテーマで「ソーシャル」の次に来るものを確かめるために試行しているサービスです。お試し頂ければ幸いです。

組織として、社内ベンチャーという形はいびつであることは確かですが、だからこそ出来ることは何かを考えつつ、今年も進めていきたいと思います。

個人的には、2009年は迷ったり惑ったりすることがあり、反省することも多い一年でした。何事も自分で経験しないと痛さや辛さのわからない性格でもあり、無駄が嫌いな割に無駄なことも沢山してきました。性格はすぐには変えられないので、省みることで、次につなげていけるよう努力していきたい所存です。

どうぞよろしくお願い致します。

2009/12/12に開催されたDevLOVE2009 FUSIONにて講演する機会を頂きました。

SlideShareに資料をアップしました。プレゼンテーションZenに多少影響を受けてるので、講演時の説明がないとわからない部分があるかもしれませんが、その辺りは、今後のブログで補足していきたいと思います。

今回のテーマは、同じIT業界と言っても、受託開発（SI）とサービス提供（SaaS）では、すごく大きな違いがあるということを、「ソフトウェア開発」という観点で伝えようというものでした。

まとめとしては、受託開発やパッケージは「製造業」であり「Point of Sales」の考え方を基底においてビジネスをすべきで、そこでは、１度の「納品／出荷」が顧客へ提供できる瞬間になるのに対し、ソフトウェアサービスビジネスでは「サービス業」であり「Point of Use」の考え方でビジネスをするためには、一期一会の精神でユーザが「使う瞬間」を大事にしていかなければいけない。サービスを実現するためには、常に改善／維持を繰り返す必要があり、繰り返すために、色々な要素を「小口化」して、「小口化」することで「日常にしていく」ことが大事ですよ、ということを具体例を交えて話しました。

私自身は既に毎日の業務としてのプログラミングをしていないので、この内容で、DevLOVEという場所で聞く人に価値を伝えられるか、不安だったんですが、papandaから頼まれた時に、「Fusionだから良いんですよ！」という言葉を胸に、講演してきました。

そんな訳で、今回は、蘊蓄や抽象的なことを語ることもしないし、熱いメッセージを伝えることも封印するという、ある意味、最近の私らしくない内容になっています。（でも、今回のような事例発表は、私の原点でもあります。）

淡々と、私が経営する社内ベンチャーのSonicGardenという組織について、そこで、どういった形で「ソフトウェア開発」をしていて、何に気付き何を学んだのか、事例を話しました。私のやっていることが正解かどうかなんてわかりませんが、聞いて頂いた方々の中で何かの発見に繋がれば良いな、と思っています。

資料作りには苦労しましたが、人に伝えるということをきっかけに、自分なり色々と整理することができたと思います。このような機会を与えて下さった、DevLOVEのスタッフの皆さんに感謝します。DevLOVE2009は、とても良い会だったと思います。おつかれさまでした。

「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」

システム開発で、顧客からこう言われた時、どうするか？

SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。

ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。

冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているから出る発言だろう。

さて、この話の前提として、タイミングは「仕様」がまだ完全に固まっていない状態であり、ここで言う「仕様」とは、ユーザから見たシステムの挙動（正しい動き）のことを指している。開始前に「仕様」が完全に固まった（夢のような）プロジェクトは見たことがないため、おそらく一般的な話。

また、発注者と開発者の２つのロールがあり、「仕様」を決めるのは発注者の役割で、「仕様」に従ってプログラムを作るのが開発者の役割、また、完成したプログラムが「仕様」に沿ったものかの確認をする（検収する）のも発注者の役割、としている。

この前提が違う、という場合は、この話は当てはまらない。しかし、発注側とした役割もSIerがやっている場合があるだけで、ソフトウェア開発の工程／手順としてはそれほど違いはない筈である。

改めて。そんな状況で本当に開発者の開発速度がボトルネックになるのだろうか？コストをかければ、完成が速くなるのか？「仕様」が完全に固まっており、発注側による「検収」を含まない、ということであれば可能かもしれない。しかし、「仕様」が完全に固まっていることって本当にある訳がないし、きちんと「検収」されていない状態を完成とは呼ばない。しかし、「要件定義」->「開発」->「検収」という流れが１度しかないウォーターフォールであれば、そう考えたっておかしくない。

しかし、今はアジャイル開発におけるボトルネックの話をしている。アジャイル開発であれば、その流れは何度も繰り返されるし、ただ単に作るだけで完成かといえば、そうではない。本当に発注側が欲しいと思っているソフトウェアが提供されてこそ完成と言える。

繰り返しながら、「仕様」を決め「開発」をし「検収」していくとしたら、開発する速度と同等の速度で、仕様を決めていかねばならないし、作られたソフトウェアの確認をしていかなければならない。そう考えたら、かなりの時間を発注側が割かねばならないはずである。おそらく、開発と同等かそれ以上のコスト（工数）がかかるのではないか。つまり「オンサイト顧客」という状態だ。

そう考えると冒頭の言葉はありえない。お金を出して時間内に開発側が作れる量を増やすという解決策だけでは駄目で、発注側にも、コストをかける用意が必要になる。しかし、発注側の人間は多くの場合、色々なプロジェクトや業務に携わっていることがあり、容易に沢山の工数をかけることは実質不可能なはず。そう考えると、開発にいくらコストをかけても、仕様の決定と成果の確認が追いつかなければ、意味がなく開発側も持て余すことになる。

実際に、週に２〜３度の２〜３時間の打ち合わせで、開発側と発注側のコミュニケーションが間に合うかというとそんなことはなく、発注側からの回答を待つために、無駄なスイッチングコストが発生したり、回答結果によっては無駄な開発をしていたことが発覚したり、ということを経験した方は沢山いるのではないだろうか。私はある。

逆に今、私は発注側として仕様を決める作業と確認の作業をしているが、開発側の速度を最大限にするために、平日の朝までに、毎日の確認と仕様の決定を行い、なるべくリアルタイムで開発側からの質問に答えるようにしている。ここで速度の限界は、発注側である私の速度になっている実感がある。

つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。

これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。

アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないSIerの罪であろう。

『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。

開発における生産性だけを考えるだけでなく、全体としての視点を持ちたいものである。