2011年8月アーカイブ

アジャイル開発の方法論の先駆けである「エクストリームプログラミング（XP）」。そのXPの日本のユーザグループ（XPJUG）が、毎年開催しているイベントが「XP祭り」です。XP祭りは、名前にXPと冠していますが、XPに限定しないコンテンツを用意しているのが特徴です。

そのXP祭りが今年も開催されます。９月３日に開催されるXP祭りについての詳しい内容はこちらです。すでに200人の定員いっぱいになっているようですが、立ち見で良いのであれば、ぶらりと立ち寄ってもらっても良いそうです。良かったらご参加ください。

私も午前中のパネルディスカッションに参加させてもらう予定です。懸田さん、野口さん、濱さん、平鍋さん、和田さんという方々とディスカッションできるということで楽しみにしています。

パネルディスカッションに参加するにあたり、ある程度の事前アンケートを頂いていて、書いていたらしっかり考えてしまったので、このままブログにしてみることにしました。

1. プロフィール

SonicGardenというソフトウェア企業で代表をしています。日々アジャイルソフトウェア開発とリーンスタートアップを実践しています。クラウドを活用したワークスタイルの変革を目指しています。元プログラマで「心はプログラマ、仕事は経営者」をやってます。ブログは http://kuranuki.sonicgarden.jp/ です。さらに詳しいプロフィールはこちら → http://about.me/yoshihito.kuranuki

2. プロフィール画像

3. アジャイルとの関係、関わり方

アジャイルとの出会い、その後の関わり方など、倉貫さまが、アジャイルとどのように関わっていらっしゃるかが分かる情報をいただきたいです。

私にとってアジャイル（当時はXP）との最初の出会いは、平鍋さんとの出会いとも言えます。学生時代にベンチャーで働いて、ソフトウェア開発の楽しさを知り、社会人になってデスマーチに入って、ベンチャーでの頃とのギャップに疑問を感じていた自分にとって、2000年の夏に平鍋さんに出会ってXPを知ったことは、大きな転機になりました。

私は「アジャイル」という言葉を知ってからアジャイルに取り組んだ訳ではなく、自分のやりたいことを端的に表した言葉が「アジャイル」だったという感覚でいます。だからこそ、自分で実践していないと気が済まないのです。最初は自分にとって教科書だったXPも、自分で実践していくうちに離れていき、自分なりのやり方になっていきました。

今、自分の会社を経営していくにあたって、アジャイルは当社の強みであると考えて戦略を立てますが、強みというのは裏付けであって、お客様に提供する価値とは別だと考えるようになりました。大事なのはビジネスモデルです。成し遂げたいビジョンがあり、そのビジョンの実現のための戦略とビジネスモデルを考え行動します。その結果として、誰から見てもアジャイルであると言われるようにありたいと思っています。

4. コミュニティとの関係、関わり方

コミュニティとの最初の出会い、その後の関わり方、現在の関係性など倉貫さまにとってのコミュニティの位置づけが分かる情報をいただきたいです。コミュニティに感じている問題点などでも構いません。

私が最初に関わったコミュニティは、やはりXPJUG（日本XPユーザグループ）だったと思います。オブジェクト指向に関する勉強会やコミュニティはあったのですが、当時の私には敷居が高く、ただのオーディエンスでしかいられなかったように思います。一方でXPJUGは、まだ日本で誰も権威はいなかったので、参加しやすかったのでしょう。

最初はただの参加者でいた自分でしたが、色々な方の発表を聞くうちに、自分でも話してみたいと思うようになりました。特に、牛尾さんとの出会いは強烈でした。牛尾さんの発表を見て、私も誰かに伝えたいという衝動が抑えきれなくなり、自分から情報発信するようになったのでした。

一度、発表者に立つと運営側にも入りやすくなり、気付いたらXPJUGの２代目の代表を仰せつかることになりました。私自身はカリスマとは無縁の人間ですが、スタッフの皆さんと共にXPJUGを続けさせてもらうことができ、幸せでした。コミュニティは会社の常識に捕われず、外を知ることの出来るとても大切な第１歩だと思っています。コミュニティに参加したら、次は行動に移すと良いですね。

5. 10回めを迎えたXP祭りへのメッセージ

もしもメッセージがありましたら、いただけるとうれしいです。

10回目のXP祭り、本当におめでとうございます。私がXPJUGの代表をさせてもらっていた時のポリシーは、コミュニティは商業目的でないので、小さくともグダグダでも、楽しい仲間で続けることだけでも価値があると思っていました。一度消えた火を付けるのはとても大変だけど、小さな火でも燃え続けていれば、きっと誰かの灯りになるはずです。XPJUG代表の渋川さんが、私の渡したバトンをしっかりと受け継いでくれて、とても嬉しく思います。ありがとうございます。

6. 起業したきっかけ、理由を教えてください。

起業に託した想いを教えていただきたいです。

私が最初になんとかしたいと思ったのは、自分の人生でした。ベンチャーでプログラマとして楽しく働いた後、大手企業に入社して、そこでのソフトウェア開発におけるプログラマの扱いがとても残念で、プログラミングが本当に大好きな私は、プログラマとしての自分が評価され続けるためには、会社と業界を変えないといけないと思ったんです。プログラマが最下層なんて世界を覆す革命が必要だと。

そんな中で出会ったのがアジャイル（XP）で、アジャイルを通じて業界を変えれるかもしれないと思い、活動してきました。独りで実践しても駄目だったら、仲間を作り、それで駄目なら、マネージャや営業もこなし、私の目指す姿を求めてきました。その結果、わかったのはこの業界のビジネスモデルの問題だということでした。それを纏めたが「ディフェンシブな開発*1」でした。
　*1．http://d.hatena.ne.jp/kuranuki/20060116/p1

そこで示した２つの道の一つ、社内システム部門の立場に身を置くことを決めました。転職ではなく、社内での異動に近い形です。そこで、今の事業の一つに繋がる社内SNSを開発することになります。社内での評価は上々だったのですが、社内向けでいる限り、いつ会社の意向で潰されるかわからない。そこで、オープンソースにした上で、自分でビジネスをすることにしました。それがSonicGardenの誕生の経緯です。

自分には成し遂げたいビジョンがあって、それを成し遂げることをミッションとするような、自分と志を共にする仲間が必要です。そして、私のビジョンの実現には、ビジネスモデルから変える必要がありました。ビジネスモデルと企業の目指すゴールは密接に関連します。ゴールを決めることが出来るのは、その企業のトップだけです。それが出来るために起業したのです。

私が目指しているのは企業のトップになることでなく、私のビジョンの達成だからです。

あわせて読みたい：技術者からベンチャー企業経営者へ

プログラマには「何を作る」のか考えられるプログラマと「どう作る」を追求するプログラマの２種類いる。どっちが優劣ではなく違いがある。漫画家で言うと、独りで全て出来る人と、原作と作画が分かれて作画を追求する人。そう考えてプログラマは漫画家に似てると思った。
http://twitter.com/#!/kuranuki/status/107815093332492289

プログラマという職業は何に似ているか。IT土方という言葉があるように、ただの単純労働のように思われてる一面があることに、私はとても憤りを覚えます。私はプログラミングがとても大好きで、プログラミングはクリエイティブな活動だし、高いスキルが必要なものだとも考えていて、それが出来るプログラマは、もっと希少な職業であっても良いはずだと考えています。

では、プログラマは土方ではなく何に似ているか。あるとき「漫画家」が近いのではないか、と思うようになりました。プログラムを作るときは、何を作るのかを考える時間と、どうやって作るかを考える時間があります。どちらも創造性が必要ですが、使う脳みそが違うように思います。漫画で言えば、原作を考えることと、作画をすることに分かれていることに近いように思います。

漫画家には、話を考えるところから、コマ割りやセリフ、構図といったネームを考えるところ、そして作画するところまでを全て独りでやっている人が多い。それは、どんな問題を解決するかを、どんなインタフェースのデザインで、どうやってソースコードで表現するかまでを独りで考えてすることに近いのではないでしょうか。そう考えると漫画家って凄いですよね。

プログラマでも、それを全て独りでやってのける人たちがいます。例えば、最近の有名どころだとマークザッカーバーグ。Facebookの最初のコードは彼が産み出したもので、どんなものに、どんなデザインで、というところも彼自身が考えたものです。たとえ映画「ソーシャルネットワーク」のように誰かのアイデアを聞いて閃いたからとしても、やはり彼自身のものに違いはないでしょう。

プログラマと漫画家の相似を考えるきっかけは、Rubyのまつもとさんとの雑談でした。プログラミングは何に似てるか、という話題になったとき、確かまつもとさんは「小説を書くのに似てるのかも」と仰っていました。そう、彼も原作者であり、表現者でもあるんですね。だから「小説」のメタファで良いわけです。いずれにせよプログラムは大量生産の工業品ではないのです。

一方で、漫画には原作者と作画でクレジットが分かれているものもあるし、原作と作画を分かれて担当する二人組で作っている人たちもいますね。どちらが偉い訳ではなく、役割分担なのでしょうし、おそらくお互いにリスペクトし合った上で、ぶつかりあっていないと良いものは出来ないんだろうと想像しています。プログラミングだって同じはずで、本来は対等なんですよね。

アジャイル開発でいうスクラムだと、原作はプロダクトオーナーで、作画がプログラマになりますね。さしずめ、スクラムマスターは編集者でしょうか。そこでも、どちらかが一方的に強いという力関係が発生すると良いものはできません。やっぱりプログラマは、ただ言われたことだけをする単純労働者ではないのです。

プログラミングの教科書によくあるのは、課題があってそれを実装しましょう、というものですが、それは「何を作るか」の部分が省かれてしまっています。「どう作るか」は訓練することが出来ますが、「何を作るか」はあまり教育でどうこうできるところではないのでしょう。その辺りも漫画の描き方の訓練と通じるところがありそうです。

私とSonicGardenで目指すビジョンでは、プログラマはアーティストのように扱われるような業界にしたいという思いがあります。プログラムは、そのプログラマの作品であり、かつ商品としての価値も求めていきたい。それを考えるとき、漫画家というのは参考になりそうです。

なので、「ハッカーと画家」というよりも、「プログラマと漫画家」が似てると言った方がしっくりきています。ただし、私の漫画家の知識はバクマンを読んだ程度なので、間違ってるかもしれないのであしからず。

スクラム（Scrum）は、アジャイル開発における方法論の一つで、今もっとも注目されている方法論と言われています。（アジャイル開発とは何か？についてはこちらを。）

SonicGardenでは、お客様とプログラマでどうすれば良い製品作りが出来るかをずっと追求してきました。その結果、顧客の製品責任者と、開発運用の全てを担当するプログラマを直接対話できるようにし、その関係のファシリテートだけをマネージャがするようになりました。それを、スクラムを知る友人に話したところ、まさしくスクラムだと聞きました。私自身は、スクラムを体系的に学習したことはないですが、アジャイル開発を追求した結果、スクラムに辿り着くことができたようです。

そのスクラムに関する大きなイベント、スクラムギャザリング東京2011が10月に開催されます。

「塹壕よりScrumとXP」の著者であるHenrik Kniberg氏と、アジャイルを用いた製品開発分野で世界的に注目されるコーチであるJeff Patton氏の２名が来日し、その講演を聞けるまたとないチャンスです。

スクラムは単なる開発手法の枠を超えて、組織風土の変革を起こすキッカケとしても有効です。これから自社をアジャイルな組織に作り替えていきたい、アジャイル開発を実践する企業にしたいと考えている経営者の方にとって、とても価値のあるイベントになっていると思います。オススメです。

スクラムギャザリング東京2011のくわしくはこちらから。

お知らせ記事です。SonicGardenが提供する企業向けSNS：SKIPのお客様交流会を東京と大阪にて開催します。SKIPに限らず、企業向けSNSの導入を検討されている方や、既に別のツールを導入されている方も参加可能ですので、人数に限りはありますが、もし良ければ奮ってご参加ください。

• 8/29（月）15：00～19:00　大阪
• 9/30（金）14：00～17:00　東京
• お申し込みはこちら

SKIPとは、企業内における社員同士のネットワーキングを醸成し、それによって大企業にありがちなセクショナリズムや、成長企業によくある一体感の喪失などを防ぎ、社員にとって働きがいのある職場環境となることを実現します。その結果として、社員間のナレッジの伝達や、新しい企画の創出などといった経営課題の解決に結びつくことを期待されています。

SKIPにおけるナレッジマネジメントの考え方は、これまでのシステムが扱ってきたナレッジマネジメントとは大きく異なります。

今までのように、情報や知識を会社の論理で統制をとったとしても、現場では役に立たないことが往々にしてあると思います。重要なことは、現場の社員同士が、困った時に助け合えるようにすることで、本来ナレッジマネジメントで実現したかったことが達成できると私たちは考えました。

SKIPでは、社員同士の結びつきを強めることで、暗黙知と形式知を創出する知識創造スパイラルのエンジンになるように設計しています。

現在、SKIPのお客様の多くは、ナレッジワーカーを多数抱える大企業が中心です。ご相談頂く部署は様々で、経営企画部や、社内広報（コーポレートコミュニケーション）などといった、システムそのものより、本来のソリューションを求めてご相談いただくケースが多いです。

企業向けのSNSの世界では、そのツールの選定や導入までよりも、導入を決めてから社内でちゃんと使われ始めるまでが重要なプロセスになります。トップダウンにしても使われないし、ボトムアップでは広まらない、社員のリテラシもバラバラ、課題は沢山あります。私たちがお手伝いも致しますが、実際にはそれぞれの企業で色々と悩みながら進めておられます。

私たちは、企業向けSNSの導入には、パッションとミッションの２つが必要だと考えています。担当者に会社からのミッションがあれば、一般的な社内システムなら導入できるでしょう。しかし、SKIPは使い始めて成功ではなく、長く使ったことによって会社を変えることが出来て成功と言えます。企業向けSNSの導入は、会社変革なのです。会社変革にはパッションが必要です。

今回のお客様交流会では、既に導入しながら会社変革にチャレンジし続けている方々同士で、直接にネットワーキングして頂くことで、お互いの経験や知見を直接に共有して頂ける機会として、ご用意致しました。これは、SKIPが企業内で実現しようとしていることと同じ形です。

企業内SNSを導入をミッションで与えられたけれどパッションが足りない方、会社を変えたいというパッションはあるけれどミッションを与えられてない方は、ぜひご参加頂くことで今後のヒントを得ることが出来ると思います。

SKIPは「情報共有基盤」である前に「情熱共有基盤」でありたいと考えています。会社を良くしたいと思う熱意は、社内で仲間を見つけることで、消えること無く広がっていくはずです。その経験を、今回のお客様交流会でも実現したいと考えています。

お客様交流会にて、お会いできるのを楽しみにしています。ご参加の登録は以下からお願いします。

• 8/29（月）15：00～19:00　大阪
• 9/30（金）14：00～17:00　東京
• お申し込みはこちら

今のシステム開発の業界における価格は、実はその提供している価値に対して、コストが高すぎるのではないか、と以前から考えていました。IT投資に対するパフォーマンスの比率が著しく悪い、摩擦係数が異常に高い気がします。それが何故なのかを考えてみました。（今回は問題提起だけなので悲観的なようですが、別途私の提案編を書く予定です）

色々なお客様とお話しさせて頂くと、かなりの予算投資をしてシステムを構築した後に、実際に使い始めると修正したい箇所が出てくるもので、その改修をベンダに依頼すると想像以上の金額の見積りが返ってきて驚いた、という話をよく聞きます。

実際に、画面の一部のキャプションを少し直すだけでも、数万円とかの見積が出てきた、というのも大袈裟な話ではないのでしょう。そんな経験をしてしまうと、より一層に構築時に確実に作って、改修しなくて済むように、と考えてしまっても仕方ありません。

また、システムを分割して少しずつ発注をしていくと、どうも割高になってしまうということもあります。大雑把に見積りを依頼した方が安くなるというのであれば、やはり最初に色々と決めきって、一度に大きく発注した方が良いと考えてしまうことでしょう。

この方向性の果てにあるのが、今のシステム開発の慣習である大掛かりな要件定義と一括請負にいきつく訳です。しかし、このビジネスの形こそが実は、システムの価格を異常に高くしている原因になっているのです。その原因は以下の３つだと考えています。

1. ベンダの見積りにおける過重なバッファ


2. 開発と運用で別の業者を利用している


3. 最大時を想定したハードウェアの購入

摩擦係数の最大の原因は「見積り時の過重なバッファ」にあります。SIerのマネージャを経験するとわかりますが、自分がマネジメントするプロジェクトにおいて、自分が課せられた売上と利益を上げるためにコントロールできる要素は限られています。

ソフトウェアのような何が正解かわからない、目に見えないものの完成責任を負わされた時、リスクに対処するためにバッファを積んでしまうものですし、そのこと自体はプロジェクトマネジメントの世界では当たり前の処置の一つです。

そこまでは良いとして、マネージャはチーム毎に組織を作れば、それぞれのチームの長に見積りを依頼するのです。チームの長は自分の責任を守る為にバッファを積みますし、さらにプログラマに見積を依頼すると、彼らも当然バッファを積みます。

もうお分かりかと思いますが、それぞれの段階ごとにバッファを積んでいくので、本来価値よりもバッファの方が大きくなってしまうのです。まだ１社でやる場合はマシですが、外注という形にすると顕著に現れます。

一次受けしたマネージャ自身が見積りが出来れば、バッファもそこだけで済むのですが、実際に開発をする技術者まで聞かないと見積りが出来ないことに問題があります。しかし現実問題として、マネージャでは見積りは出来ません。

結果として、システム開発は本来価値よりも高い見積りになってしまうし、小規模に分割して見積りをした方が割高になる理由もわかると思います。これは、完成リスクも丸投げしようとするユーザ企業にも問題があるかもしれません。

次に「開発と運用で別の業者を利用している」という点です。システムの発注をアウトソーシングした後で、納品されたシステムは自社で運用する、もしくは安価な業者を利用して運用してもらうということが普通に行われています。

これは一度、システムは完成した後、改修は殆ど行われないという想定だからですが、そうしたい原因には、前述の高すぎる見積りがあります。つまり、開発そのものが見積りバッファによって高価になりすぎるので、せめて運用は安く、ということです。

しかし、運用だけを請け負うのだとしたら、他人の作ったものをメンテナンスするとなると、そのためにはしっかりした設計資料が必要になります。そうなると、最初の開発時にしっかりしたドキュメントを要求するのもわかります。嫌な流れです。

また、開発だけを請け負う業者としては、当然プロフェッショナルとしてメンテナンスしやすい設計や実装を心がけるとは思いますが、もしもプロジェクトが赤字になりかけたとしたら、まずは納品することを最優先してしまうかもしれません。

発注側の企業が、プログラムコードなどの保守性といったテストで見れない内的品質を検収時にチェックすることが出来れば、作り直しを要求することも出来るかもしれませんが、だいたいの企業ではテストを通すことを重視しています。

メンテナンスしにくいソフトウェアが出来上がってしまい、かつ、自分たちで開発したものでなければ、少しの改修をするにしてもどれだけの影響範囲があるか見えないので、キャプション一つ直すのにも、高い金額が発生してしまうのです。

そして、最後の「最大時を想定したハードウェアの購入」ですが、これまでのシステム開発だとインフラ設計や非機能要件というのが大事で、ハードウェアの見積りをしっかりする訳ですが、そこにも高価になる原因がありました。

どれくらいの人数が利用するのか、どれくらいのアクセス頻度なのか、停止して良い時間はどれくらいなのか、そういった利用する機能とは直交する要件を非機能要件と呼び、それに応じて、ハードウェアの見積りをする訳です。

そして、だいたいのケースにおいては、最大の利用シーンを想定した上でハードウェアを購入します。何故なら、ハードウェアを買ってしまうと、途中での変更は費用的にも容易ではないからです。なるべく効率を考えて、一番良いのを買おうとします。

しかし、本当にそこまでの利用想定までいくかというと不明だったりしますし、BtoC向けだと捕らぬ狸の皮算用になりかねません。何よりコンピュータの世界では有名な「ムーアの法則」というのがあります。時間とともにハードは安くなるのです。

一括で大きなシステムを一度に作ろうとしてしまう流れにのってしまうと、ハードウェアも高価で大きなものを一度に購入した方が安いかもしれない、という気持ちになってしまうのかもしれません。そして、長い期間をかけて償却するしかなくなります。

長くなったので、もう一度「システム開発が高くなる３つの理由」を列挙します。

1. ベンダの見積りにおける過重なバッファ


2. 開発と運用で別の業者を利用している


3. 最大時を想定したハードウェアの購入

これらは、ベンダだけが悪い訳でも発注側のユーザ企業がだけが悪い訳でもなく、今の業界の構造が抱える問題と言えます。ソフトウェアも未来も目に見えないものであり不確実なものであるのに対し、事前に固めようというベクトルがもたらした結果です。

私も、以前に大手のSIerでマネージャをやっていた頃は、当時の金額が当たり前だと思っていたんですが、今考えると、やっぱりちょっと感覚がおかしかったかな、と思います。自分たちの価値をおとしめる訳でなく、本来価値にあった金額にすべきと考えます。

今回は問題提起だけを行いました。私は、この昔ながらの習慣そのものを疑問視し、新しいビジネスモデルがないものか模索してきました。そして今は「納品しない」という提供スタイルによって、低価格でも高品質なものを提供できるのではないか、という仮説をもっています。その紹介はまた別の機会に。

あわせて読みたい：ディフェンシブな開発 ～ SIビジネスの致命的欠陥

アジャイル開発を開発者以外にも２ページ程度のサマリで説明するというのに挑戦してみました。なるべくアジャイル開発の文脈で使われる言葉（適応型とか）を使わないようにしてみたのと、従事する人でなく決定権を持つ人向けに中身よりも得られる価値などを中心に記述しました。（記事の最後でPDFを皆さんの会社でも使えるようクリエイティブコモンズで公開してます。）

---

アジャイル開発に関するサマリ

アジャイル開発（アジャイルソフトウェア開発）とは、ソフトウェア開発における開発手法の総称です。その特徴は、日々変化するビジネスや市場環境に応じて、作るべきソフトウェアも変化させていくことが出来る点です。

アジャイル開発におけるゴールと狙いは、IT投資に対するソフトウェアから得られる価値を最大化することです。コストパフォーマンスの最大化であり、ただソフトウェアを作ることだけが目的ではありません。

１．誕生の経緯と求められる背景

90年代までの開発では、事前に立てた計画を遵守することが正しいソフトウェアを手に入れる方法だと考えられていました。そのためにドキュメントとルールを沢山用意し、分業することで人の入れ替えによるリスクも抑えました。

しかしオープンな技術が登場し、ビジネス要件が複雑化していくに従い、プロジェクトの終盤になってリスクが顕在化する事例が増えてきました。一度作ってみないと予想した通りに作れるか、予想したものが手に入るかわからないのです。

それを回避するために、反復型と呼ばれる開発手法が登場します。しかし、沢山のドキュメントとルールを作りながら、プロセスを繰り返すのは無理がありました。繰り返しの中で変化に対応できる、軽量化された開発手法が必要とされたのです。

２．導入のメリットと効果

アジャイル開発を導入することによるメリットと効果は以下の通りです。

• 変化するビジネスの状況に応じて、本来必要とされるソフトウェアが手に入る
• ソフトウェアをどう作るかでなく、それが産み出すビジネス価値に集中できる
• 継続的に学習し、自らプロセスを改善していけるチームを持つことができる

ソフトウェアは一度開発して終わりという考え方ではなく、ビジネスのPDCAサイクルにあわせて継続的に改修を加え、企業価値の向上に繋げることが本来果たすべきソフトウェアの価値であるという考えに基づいています。

ソフトウェアを開発するにあたって、予見的に全ての機能を最初に決めてしまう必要はなくなり、少しずつ階段を登っていくように、必要なソフトウェアを手に入れていくことが出来ます。

３．アジャイル開発の進め方

アジャイル開発では、数週間ごとに実際に動くソフトウェアを一部の機能から順に作っていきます。工程の一部を順に進める訳ではないので、分業せずに開発者がソフトウェアを作るために必要な作業をすべて行います。

動くソフトウェアを短期間で開発をするために、コミュニケーションコストを下げるために少人数の体制をとり、仕様に関する責任者もチームに同席し、ドキュメントなどを極力減らすことで必要な工数の効率化を行います。

実際にユーザにとって価値のある機能を、数週間単位で肉付けをしていくにあたり、既に動いている部分の改修にかかる保守性を高めていくことを、テストの自動化などといったベストプラクティスを用いて実現します。

４．導入方法と目指すべき姿

「アジャイル開発」というのは総称であり、実際には「エクストリームプログラミング」や「スクラム」といった具体的な手法が多数存在しています。アジャイルソフトウェア開発宣言（参考URLを参照）に則った開発手法のことを指します。

最終的には、自社の組織にあわせた手法に練り上げ、常に現場からの改善をもって自己プロセスの見直しを行えるような組織文化を作り上げることを目指しますが、最初に導入するにあたっては、既にある手法に従って進めていくことが肝要です。

アジャイル開発の多くの手法は「価値」「原則」「プラクティス」という構造で表現されています。最初の段階では、具体的な方法として記されている「プラクティス」に従って開発を行うと良いでしょう。

（プラクティスの例）

• ペアプログラミング（２人一緒に開発を行い、レビューを常時実施する）
• テスト駆動開発（自動で実行できるテストから先に作成し品質を高める）
• ふりかえり（反復ごとにチーム全体でプロセスについての改善を行う）

５．導入の際に発生する課題と対策

導入する際に、従来からのビジネスモデルや既存の組織評価の中で行おうとするとうまくいかないことが多い。従来が「ソフトウェアの完成を目指す」のに対し、アジャイル開発では「継続してソフトウェアを改修し続ける」考え方だからです。

システムベンダーに発注する場合でも、従来通りであれば、要件に対しての見積りが行われ、それを確実に作ることを目指してしまいます。それでは、継続的な改修という訳ではなくなります。

アジャイル開発を本当に導入することを考えるのであれば、ソフトウェアを作ることにフォーカスするのではなく、そのソフトウェアがどういった価値を産み続けるのかを考えた組織やビジネスモデルに変えていかねばなりません。

参考URL

・アジャイルソフトウェア開発宣言 = http://agilemanifesto.org/iso/ja/

---

この資料は、再配布できるようにPDF化して、クリエイティブコモンズで公開します。ご自由にご利用ください。ダウンロード：アジャイル開発に関するサマリ

This work is licensed under a Creative Commons Attribution-NoDerivs 2.1 Japan License.

先週末から、SonicGardenのプログラマである @maedana が、住居をアイルランドのダブリンに引っ越しました。一方で、SonicGardenの仕事は続けてもらうことになっています。少し面白いワークスタイルなので紹介します。

View Larger Map

彼は特にアイルランドに縁もゆかりもあるわけではないですが、英語を身につけたいというモチベーションがあり、英語圏で彼の年齢で長期滞在が出来るところは限られており、結果としてアイルランドに決めたようです。（ただダブリンはRubyにゆかりのある松江市と姉妹都市らしいというのを後から知りました。縁ですね。）

当社（SonicGarden）では、以前からどこでも仕事が出来るためのノマドなワークスタイルを目指していました。その為に、仕事は当然ノートPCですし、システムはすべてクラウドに置き、厳密な勤怠管理をするのではなく自主性を重んじるなど、環境と制度を整えてきました。

その結果として、3.11の大震災の際も、震災後に無理をして出社するということはしないで、各自が在宅か地元に帰って、そこから通常業務をするようにしましたが、まったく業務に支障がないことが判明しました。（請求書発行などの事務仕事は難しいと思いますが）

当社では、自社サービスの開発運用と、納品しない受託（サービス型受託）の開発運用、この２つを事業部で分けるのではなく、それぞれの個人の時間の中でシェアするという業務の仕方をしています。当社のプログラマは自社サービスのディレクターも兼ねる場合がありますが、彼の場合は純粋なプログラマです。

私たちの言う「プログラマ」は、ただ言われた仕様を実装するのではなく、プロダクトオーナーとディスカッションして要件を確認し、画面やDBの設計をし、ソースコードで表現をし、テストを行い、ステージング環境や本番環境へのデプロイから、日々の運用まで、ソフトウェアの開発と運用に関する全てを行う職業のことです。

当社でのプログラマの仕事の仕方は、Pivotal Trackerというインターネット上で動いているタスク管理のツールを使って、そこでインプットされた要件を順番にこなしていくのが基本です。内容がわかりにくいものは、SkypeやyouRoomを使って納得がいくまでディスカッションします。プロダクトオーナーはそれに応えられるようにしています。

このスタイルは自社サービスだろうが受託サービスだろうが同じようにやっています。彼自身は移動することなく、日本にいるプロダクトオーナーと連携しながら仕事を進めることができるようになっています。ノートPCとネット回線さえあれば、世界中のどこにいても仕事ができるのです。

なので在宅勤務でも良いのですが、彼の場合は独身ということもあり、家にずっといたいという動機は薄く、会社には出勤という概念より、ワーキングスペースを使う意味で来ていました。そこで彼は閃いたんです。そもそも在宅勤務でも良いということは、家を別の国に移して、在宅勤務しても良いということに。

私としては、将来的には世界中のプログラマと仕事をしたいと思っていますし、プログラマが場所に縛られずに仕事ができれば、今までよりも精神的にも物理的にもより豊かな生活を送ることができると思うので、彼のアイデアには大賛成で、応援することにしました。むしろ、そんなチャレンジをしてくれることに感謝しています。

これは、将来のビジョン実現に向けた壮大な実験の一つです。おそらく時差の関係など、想像もつかない課題は出てくる可能性はありますが、ひとつひとつクリアしていき、このプログラマのノマドワークスタイルについての経験と知見を貯めていければ良いなと思っています。

ダブリンに旅行などで行かれて興味ある方は @maedana にコンタクトとってみてください。そして、こんな働き方に共感してくれた方は、ぜひSonicGardenのFacebookページのLikeもお願いします！

あわせて読みたい：

• 仕事をするのにオフィスはいるのか？


• ソフトウェアをサービスで提供するビジネスにおけるタスク管理とは〜RedmineからPivotal Trackerへ

表題のタイトルで、Web Site Expert #37に記事を書かせて頂きました。

TwitterやFacebookで採用されたことで、今のウェブアプリケーションの一つのトレンドになっているユーザインタフェースが「タイムライン」形式です。Twitterはそのタイムラインに140文字の短い言葉だけを流すことができるので「マイクロブログ」とも呼ばれています。Twitterの特徴は、ブログと同じで全世界に公開し、世界中のユーザがお互いに繋がるように作られています。

youRoomでは、そのTwitterやFacebookなどで採用されているユーザインタフェースの部分をプロジェクトなどの情報共有ツールに採用できないかと考えて設計しました。全世界に公開されて、人と人を繋げるソーシャルメディアではなく、情報共有ツールにタイムラインのインタフェースのエッセンスを入れたのです。

この記事では、そのインタフェースのスタイルを「マイクロブログスタイル」と呼び、youRoomでの実現について説明しています。

また、youRoomではマーケティングにあまりコストをかけずに口コミを中心に実験的な施策を色々とうってきました。結果として10カ国以上からのアクセスや利用をしてもらえるようになってきつつあります。その取組みについても紹介しています。

大阪で行われたRedmineとタスク管理の勉強会（RxTstudy）に参加してきました。ライトニングトークスにも参戦するつもりだったのですが、出来た資料が大きくなっちゃったので、急遽お時間を頂いて長めにお話させてもらいました。

Redmineの勉強会で、Redmine本の著者ということで呼んでもらえたにも関わらず、すでに当社ではRedmineからPivotal Trackerに移行をしていて今は使っていないということで、なぜ移行することになったのか、そこに至った背景と哲学についてお話させて頂きました。

発表資料はこちらです。

今回は、ユーストリームでの配信と録画をして頂いていたので、発表の様子もあわせて見て頂けると、より一層内容が理解できると思います。

ユーストリームへのリンク


Video streaming by Ustream

また当日のTwitterでの会場の反応はTogetterにまとめて頂いてます。