日経コンピュータさんに２号連続で掲載頂きました！
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ライフについて振り返ってみました。そのエッセンスから、参加された皆さんに、私が考える「アジャイルマインド」について感じてもらおうと考えました。以下、資料です。（言葉で補足しないと伝わらないかも）
スタッフのみなさん、本当におつかれさまでした。
"XP祭り"というイベントがあります。
eXtreme Programming（通称XP）というアジャイル開発プロセスを、日本に広めるための活動をしている「XPJUG」というコミュニティが開催しているイベントです。2002年に初めてのXP祭りを行い、毎年秋頃に開催してきました。ソフトウェア開発、IT業界で働くプログラマーやエンジニアを中心としたベンダーに依存しない独立した活動です。また、関西に在住のエンジニアの方々を中心に立ち上がった「XPJUG関西」というコミュニティもあり、関西でも「XP祭り関西」が行われてきました。
そして、今年2010年に、2つのXP祭りが予定されています。
まずは「XP祭り関西2010」です。「アジャイルマインドを育もう」というテーマで開催されます。
講演者の面々として、
の木下さん
の岡島さんまた、私も昨年のXP祭りで、XPJUG代表の引退を表明させてもらいましたが、今回は私とXPの出会いのきっかけから、経験したこと学んだことなどを振り返りつつ、引退に至まで、お話させて頂く予定です。
東京での「XP祭り2010」は、秋頃に開催の予定です。その実行委員会のキックオフが、早くも開催されます。
なぜ、今からキックオフで、なぜ、委員会の参加を募集するのか？それは、昨年のXP祭りのふりかえりをスタッフで行った際に、XPJUGの存在意義について語り合った中で出たアイデアが発端です。XPJUGとして「XP祭り」は非常に大きなもので、逆に言えば、XP祭りを開催することこそが、XPJUGの意義ではないか、と考えたのです。すなわちXPJUGとは「XP祭り実行委員」のことである、と。
XP祭りは、スポンサーを付けずベンダ色のない、あくまで現場のエンジニアの方々を中心としたイベントとして行ってきました。そのため運営スタッフと参加者の境が非常に薄く、運営スタッフも参加者として楽しむし、参加者の皆様にも運営をお手伝い頂くなど、非常に良い関係が築けています。そこで、次の2010年に開催するXP祭りでは、よりもっと参加者の方々との関係を深め、運営についても、よりもっとオープンにしていくことを考えました。
そこで、「XP祭り2010」からは、「XP祭り実行委員会」のスタッフになってくれる方を広くオープンに募っていき、その方々と共に、XPJUG（XP祭り実行委員会）として開催に向けて準備をしていきたい、と思っています。コミュニティ活動は初めて、という方もこれを機に参加頂ければ幸いです。
参加申し込みはこちら・・・XP祭り2010実行委員会キックオフ
また、youRoom上で、オープンなディスカッションを行っています。youRoomへの参加登録は必要ですが、自由に参加できますので、興味のある方はご参加ください。
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の罪であろう。
『ソフトウエア開発においては、開発側が必要とする工数と、発注側が必要する工数を同等にするべきである』こんな法則があるのではないだろうか。そして、『発注側は、自社がかけれる工数（コスト）以上の、発注をしてはいけない』というルールでもあれば、うまくいくのではないだろうか。
開発における生産性だけを考えるだけでなく、全体としての視点を持ちたいものである。
先日、対談？を受けての記事が、ソフトウェア開発未来会議で公開されたようです。
「前編：日本におけるアジャイル ソフトウェア開発のこれまで」
eXtreme Programmingが世に出てから、10年らしいです。
平鍋さん、小井土さんとの話は、背景の共有がいらないので楽しいですし、勉強になります。
まだまだ学ぶことは沢山ありますね。
連休を利用して読みました。
小飼弾氏が、わかるには「35年の人生が必要」と書いていた本書、奇しくも35歳の誕生日の翌日に読んだの私にとっては、「当たり」の本でした。
プログラマ出身であり、プロジェクトマネージャの経験を経て、ソフトウェア会社の経営をしている私だからこそ頷ける点が沢山書かれています。これは確かにプログラマはこぞって読むかもしれないけれど、プログラミング経験だけでは、面白みがわからないだろうなぁ。ギークでもありスーツでもある人がこの本の真のターゲットなんだろうな。
第９章で、私が以前、ディフェンシブな開発で書いたことと同じようなことを言っています。Joelが学生に向けた講演の一部です。オーダーメイドの企業向けシステムを作るインハウスプログラマの仕事と、ソフトウェア製品会社で働くソフトウェア開発者としての仕事の２つあり、慎重に選ぶように語っています。プログラマにとっての幸せは、人によるだろうけど、やっぱり会社の利益に直接貢献できる仕事である方が良いと思う。そこは完全に同意です。それができるのは、ソフトウェア会社で働く方が絶対に良い。プログラミングできることを、キャリア形成の強みにできるのは、ソフトウェア会社なんだろうと思う。
他にも多くの示唆に富んだ本でした。プログラマだったし、今でも休日はプログラミングをしたりもしているけれど、時に、思考がスーツよりになりすぎて、忘れかけてしまっていることがあったりして、それを思い出す良いきっかけになりました。紹介したい点はまだまだあるんですが、また、別の記事で、触れたいと思います。
一番気に入ったフレーズ。
会議して詩を書こうとなんてするか？
ソフトウェアって、本当はそうだよね。
最近のコメント