要求開発とドメイン駆動設計
昨日の要求開発アライアンス６月定例会での柳本さんのセッションが素晴らしかったので簡単に書き留めておきます。今回の定例会テーマは「要求開発とドメイン駆動設計」についてで、メインのセッションは増田亨さん。柳本さんのイントロセッションはそこへの導入部として、要求開発のおさらいとドメイン駆動設計との関係についての仮説の紹介。
何が素晴らしいかというと、セッションの中で要求開発の「３つのT」について触れていること。これは何年か前に私が単なる思いつきで要求開発のMLに投げたりブログに書いたりした概念・フレームワークで、要求開発界では華麗にスルーされ続けてきたもの。このような形で定例会の場で取り上げられるとは、感慨深いです。
Always All Ways: [IT] 要求開発の３つのT
http://pub.ne.jp/Under_the_Bridge/?entry_id=2647694
で、別のエントリでそれに関連して要求開発とScrumについても書いているのですが、この３つのTの概念というのは、実は要求開発とそれを補完する他の方法論などをつなぐフレームワークとしても考えられるのではないかというのが、昨日の私のヒラメキ。さて、どうしてくれようw。
Always All Ways: [IT] Scrumと要求開発
http://pub.ne.jp/Under_the_Bridge/?entry_id=2649587
というわけで、取り急ぎ、柳本さんのセッションのUstreamアーカイブを貼付けておきます。（回線が不調だったので残念ながら若干画質を落としています。）
ドメイン駆動設計と要求開発
なお、メインの増田さんの講演については、途中でUstreamサーバへのコネクションが切れてしまって中断していますが、以下のURLで見ることができます。
http://www.ustream.tv/recorded/15504375
http://www.ustream.tv/recorded/15504975
プレゼン資料はこちら↓
View more presentations from Kent Ishizawa
ドメイン駆動設計 の 実践 Part3 DDD
さらに、全体を通してのtwitterでのみなさんのコメントは、 @take3000 さんがまとめてくださっているので、併せて読みたい。
「要求開発アライアンス6月定例会『ビジネスからシステムまでつなげる仕組み～ドメイン駆動設計Ｘ要求開発～』」のまとめ
http://togetter.com/li/152000
View more presentations from 増田 亨
Ryuzeeさんに講演してもらった 〜Scrumと組織〜
先日、Ryuzeeこと吉羽龍太郎さんに会社に来ていただき、約20名の開発者に向けて「Scrumと組織」というタイトルで講演をしていただきました。開発者に対して、アジャイルのいろんなプラクティスやScrumのフレームワークそのものではなく、組織をテーマにしていただいたのが今回のミソです。その中でも特に、コミットメントやチームの責任・文化に焦点を当てて話をしていただき、私自身も改めてとても勉強になりました。
当日の資料は、以下で公開されています。
Ryuzee.com [Agile]Scrumと組織（資料公開）
Scrumと組織
さて、ここで「コミットメント」について少し書いておこうと思います。
誤解を恐れずに言うと、私自身の「コミットメント」という言葉に対する認識は、例えていうならば「約束できない約束」みたいなもんです。ある意味で、これは、ビジネスオーナーやプロダクトオーナーに対する開発チームの約束であり、ソフトウェア開発において最も重要な「信頼関係」の構築に欠かせないものです。でも一方で、何が約束できて何が約束できないかという暗黙の了解というか阿吽の呼吸というか、そういった部分も必要なのです。
そこで、参考になるのが、"Scrum and XP from the Trenches"でも有名なHenrik Knibergが2011年2月16日にJfocusで行った講演の資料で、その名も"Scrum and XP - Beyond the trenches"です。
そのp.36で、彼はSprint commitmentについて書いています。そのまま引用すると、まず、
Common misconceptionsとして次のようなものを挙げています。
View more presentations from Ryuzee YOSHIBA
”We promise to achieve this goal” ”We promise to deliver all stories included in the sprint backlog”その上で、プロダクトオーナーに対するチームのコミットメントとして以下のように記述しています。
”We promise that...” ... we believe we can reach the sprint goal. ... we will do everything in our power to reach the sprint goal, and will let you know immediately if we no longer believe we can reach it. ... we believe that we can complete all stories included in the sprint backlog. ... we will demonstrate releasable code at the end of the sprint . ... if we fall behind schedule we will talk to you and, if necessary, remove the lowest priority stories first. ... if we get ahead of schedule, we will add stories to the sprint from the product backlog, in priority order. ... we will display our progress and status on a daily basis. ... every story that we do deliver is Done.なんだかとても現実的で、かつ信頼関係を構築するには必要十分な内容になっていると思いませんか？
継続的改善フレームワークとしてのScrum
とあるところで記事として書こうかなと思っていることを、頭の整理＆下書き代わりに書きなぐっておきたいと思います。
Scrumはフレームワークである
Scrumって何？という話をする時に、あまり意識せずに、アジャイル開発の「プロセス」だとか「手法」だとか「方法論」だとか言ってしまうこともあるのですが、自分自身では「フレームワーク」という言い方が一番しっくりくるため、ここ数年はできるだけ「フレームワーク」と呼ぶようにしています。
そして、さらにどんなフレームワークかと言えば、Tobias Mayorが"Scrum doesn't do anything"(Agile Anarchy http://agileanarchy.wordpress.com/2009/10/11/scrum-doesnt-do-anything/)の中で述べているように、
Scrumはアーキテクチャである
一方で、「Scrumはアーキテクチャである」という言い方もできるのではないかとも思っています。
ここで言う、「アーキテクチャ」は、ローレンス・レッシグが「CODE VERSION 2.0」の中で書いているような、人間の行動を規制する４要素（法・規範・市場・アーキテクチャ）の一つとしてのアーキテクチャです。まぁ、正しく言うとちょっと違うのですけれども、なんとなく、それに近いものがあるな、と。
Scrumは継続的改善のためのフレームワークでありアーキテクチャである
上記のように考えると、Scrumとは、
これによって何が生まれるかというと、（ここは長くなるので話を端折りますが）フレームワークやアーキテクチャに則った行動を習慣づけられることによる「意識」の変化です。
一般的には、「意識を変える」→「行動が変わる」という流れと思われがちですが、実際には、この逆のパターン、すなわち、行動を変えることによって意識が変わってくるということの方が多いように私は思っています。ただ、そこで難しいのが、いかにして行動を変えるか、というところ。そのための、フレームワークあるいはアーキテクチャとして機能するのが、私はScrumだと思っています。そしてそれが支えるものは、とりもなおさず、「継続的改善」なのです。
そういう視点から考えると、Scrumを組織に導入するにあたっていろんなことが考えられるわけです。そのあたりをきちんと整理していずれまとめてみたいと思います。
Scrumはフレームワークである
Scrumって何？という話をする時に、あまり意識せずに、アジャイル開発の「プロセス」だとか「手法」だとか「方法論」だとか言ってしまうこともあるのですが、自分自身では「フレームワーク」という言い方が一番しっくりくるため、ここ数年はできるだけ「フレームワーク」と呼ぶようにしています。
そして、さらにどんなフレームワークかと言えば、Tobias Mayorが"Scrum doesn't do anything"(Agile Anarchy http://agileanarchy.wordpress.com/2009/10/11/scrum-doesnt-do-anything/)の中で述べているように、
Scrum is a framework for surfacing organizational dysfunction.というのが、とても的を射ているように思います。
Scrumはアーキテクチャである
一方で、「Scrumはアーキテクチャである」という言い方もできるのではないかとも思っています。
ここで言う、「アーキテクチャ」は、ローレンス・レッシグが「CODE VERSION 2.0」の中で書いているような、人間の行動を規制する４要素（法・規範・市場・アーキテクチャ）の一つとしてのアーキテクチャです。まぁ、正しく言うとちょっと違うのですけれども、なんとなく、それに近いものがあるな、と。
Scrumは継続的改善のためのフレームワークでありアーキテクチャである
上記のように考えると、Scrumとは、
- 組織の機能不全を表面化させることで、それへの対処を促すフレームワークとしての特性だけでなく、
- またその実効性を担保するための、人間の行動・振る舞いを規制・規定するアーキテクチャとしての特性をも持っている
これによって何が生まれるかというと、（ここは長くなるので話を端折りますが）フレームワークやアーキテクチャに則った行動を習慣づけられることによる「意識」の変化です。
一般的には、「意識を変える」→「行動が変わる」という流れと思われがちですが、実際には、この逆のパターン、すなわち、行動を変えることによって意識が変わってくるということの方が多いように私は思っています。ただ、そこで難しいのが、いかにして行動を変えるか、というところ。そのための、フレームワークあるいはアーキテクチャとして機能するのが、私はScrumだと思っています。そしてそれが支えるものは、とりもなおさず、「継続的改善」なのです。
そういう視点から考えると、Scrumを組織に導入するにあたっていろんなことが考えられるわけです。そのあたりをきちんと整理していずれまとめてみたいと思います。
アート・オブ・コミュニティ
翻訳者の渋川さんと縁があり翻訳のレビューなどを少しやらせていただいた関係で、献本をいただきました。渋川さん、オライリー・ジャパンさん、ありがとうございます。（私がレビューで貢献したのは、主にIron Maidenの出てくるくだりです（笑））
渋川さん自身も「訳者まえがき」で触れられている通り、ここでの「コミュニティ」という言葉には日本で一般に使われているのとまた少し違ったニュアンスもあり、またその分、ずっしりとした重みのある内容となっています。そのあたりのニュアンスが、本書のサブタイトル（「貢献したい気持ち」を繋げて成果を導くには）にもしっかりとあらわれていますね。ちなみに、この「訳者まえがき」は本文に負けず劣らずすばらしい内容ですので、本書を手に取った方は読み飛ばさずにしっかりと最初から読んでみることをおすすめします。
全編通して、どの章をとっても読み応えがありますが、個人的に本書の中から好きな章を３つ選べと言われれば、迷わず以下の３つの章を挙げます。
1章 アート・オブ・コミュニティ
1.1 コラボレーション駆動のエートス
1.2 コミュニティの本質
1.3 コミュニケーションの基礎
1.4 チャンスをつかむ
1.5 コミュニティマネージャ：コミュニティになる
1.5.1 個性をこじ開ける
1.5.2 信用こそがすべて
1.5.3 聞くことの価値
1.5.4 エゴを避ける、さもなければ他の人があなたを避ける
1.5.5 理論vs行動：行動が勝つ
1.5.6 自分自身になる
1.6 次章に向けて
4章 プロセス：シンプルであれば継続できる
4.1 獲得すべきものに視線を向け続ける
4.1.1 大切なものから視線を外さないようにする
4.2 最高のプロセスを構築する
4.2.1 複雑な物を分解する
4.2.2 プロセスをじっくり考える
4.3 ニーズを査定する
4.3.1 コミュニティのサイクル
4.3.2 コミュニティの入り口
4.3.3 貢献者を評価する
4.3.4 フィードバックの管理
4.4 プロセスに賛同してもらう
4.4.1 プロセスをドキュメント化する
4.4.2 見つけやすくする
4.4.3 プロセスを使用する
4.5 プロセスの再評価
4.5.1 習慣化する
4.6 次章に向けて
9章 対立への対処
9.1 動物の本能
9.1.1 対立の構造
9.2 嵐の前の静けさ
9.2.1 議論好きな性格
9.2.2 提案に対するバリア
9.2.3 責任に関する問題
9.2.4 正当性の欠如
9.3 対立解決のプロセス
9.3.1 ファシリテーターという役割
9.3.2 対立の解決
9.4 燃え尽き症候群に対処する
9.4.1 燃え尽き症候群の発見と治療
9.4.2 ワーク・ライフバランス
9.5 まとめ
本書は、Jono Baconの著作ではありますが、不思議なことに翻訳者の渋川さんの情熱と人柄がにじみ出てくるような、味わい深い一冊です。
Agile Tour Osaka 2010 予習ガイド
Agile Tour Osaka 2010の開催まであと一週間を切った。
せっかくなので、当日までにざくっと予習していくならコレ！というのを個人的な趣味で厳選してピックアップしておくこととする。
【基調講演（by 長瀬さん）】
これはもう、予習などせずに全身を長瀬さんの基調講演に委ねていただければOK。っこのセッション自体が、日本におけるアジャイルの歴史と未来における自分自身の位置を再確認し、午後のセッションに向けての頭の中の再整理するための予習の時間とも考えられる。
余談だが、「オブジェクト脳のつくり方」をお持ちの方は、当日持ってくると著者（牛尾さん）と監修者（長瀬さん）のサインを同時にいただけるチャンスありw。
【セッション１（by あきぴーさん）】
これはまさに、
「Redmineによるタスクマネジメント実践技法」
を読んだ人、これから読もうと思っている人のためのセッションのようなもの。できることなら事前に読んで、疑問点などを当日の懇親会などで本人にぶつけてみるのがよいだろう。
【セッション２（by 牛尾さん）】
ここはオーソドックスに最近の牛尾さんのWeb連載を挙げておく。
「アジャイルは絶対、そのまま導入するな！〜本当に得をしたい情報シス部門にこっそり教える導入成功の極意」
【セッション３（by 懸田さん）】
こちらは、ちょっと変化球で…。Jeff Pattonのインタビューを紹介しておく。
"Jeff Patton on User Centered Design and Story Mapping"
せっかくなので、当日までにざくっと予習していくならコレ！というのを個人的な趣味で厳選してピックアップしておくこととする。
【基調講演（by 長瀬さん）】
これはもう、予習などせずに全身を長瀬さんの基調講演に委ねていただければOK。っこのセッション自体が、日本におけるアジャイルの歴史と未来における自分自身の位置を再確認し、午後のセッションに向けての頭の中の再整理するための予習の時間とも考えられる。
余談だが、「オブジェクト脳のつくり方」をお持ちの方は、当日持ってくると著者（牛尾さん）と監修者（長瀬さん）のサインを同時にいただけるチャンスありw。
【セッション１（by あきぴーさん）】
これはまさに、
「Redmineによるタスクマネジメント実践技法」
を読んだ人、これから読もうと思っている人のためのセッションのようなもの。できることなら事前に読んで、疑問点などを当日の懇親会などで本人にぶつけてみるのがよいだろう。
【セッション２（by 牛尾さん）】
ここはオーソドックスに最近の牛尾さんのWeb連載を挙げておく。
「アジャイルは絶対、そのまま導入するな！〜本当に得をしたい情報シス部門にこっそり教える導入成功の極意」
【セッション３（by 懸田さん）】
こちらは、ちょっと変化球で…。Jeff Pattonのインタビューを紹介しておく。
"Jeff Patton on User Centered Design and Story Mapping"
Agile Tour Osaka 2010の見どころ解説
世界40都市以上で開催されるアジャイル開発のイベント、ついに日本上陸。来る10月30日（土）に大阪で開催することとなった。
Agile Tourとは何か？
（英語） http://www.agiletour.org/en
（日本語） http://www.agiletour.org/ja
Agile Tour Osaka 2010の概要はこちら↓
http://www.agiletour.org/ja/osaka.html
そして、そのうち公開されるだろうが、実行委員特権で（笑）各セッションの内容・見どころなどを一足先にこっそり（？）ここで紹介する。
※ なお、ここに掲載した内容は現時点の予定であり、予告なく変更となることもあることを予めご了承願いたい。
【基調講演】
「日本のアジャイル開発の変遷、現在・過去・未来」
日本のアジャイルをその黎明期から見て来られた、ご存知、テクノロジックアートの長瀬嘉秀氏による基調講演。
【セッション１】
「チケット駆動開発がAgileになる理由 〜No Ticket, No Commit!〜」
今、巷でホットな本と言えば、『Redmineによるタスクマネジメント実践技法』（小川明彦・阪井誠）である。10月13日発売予定のこの本の著者の一人である"あきぴー"氏による講演。これは、見逃せない！ 読んでから聴くか、聴いてから読むか？
【セッション２】
「西日本にだけこっそり教える アジャイルコンサルタントの秘密 〜アジャイルプロジェクトでの失敗防止のコツ〜」
その全国区での活躍と同時に、大阪では相変わらず絶大なる人気を誇る"アリスター・ファウラーMc剛"…じゃなかった、牛尾剛氏の凱旋LIVE！
タイトルに「西日本にだけこっそり教える」とか書いていてもUstreamで全世界に発信されてしまうかもしれない恐ろしい世の中に、彼は果たしてどのような挑戦状を叩き付けるのか！？乞うご期待★
【セッション３】
「ユーザーストーリーマッピング ～ アジャイルな計画づくりを加速する」
東京から四国松山に居を移し、プロジェクトファシリテーション、アジャイルソフトウェア開発のコーチとして活躍する懸田剛氏による、これまた興味深いセッション。
以上、基調講演と３つのセッションについて簡単に紹介したが、それ以外にも公募によるライトニングトークスあり、懇親会ありの充実した一日。是非とも、開発者だけではなく幅広い層のみなさんにご参加いただきたい、そしてきっと満足していただけるイベントになると思う。席には限りがあるため、申込みはお早めに！（現時点ではまだ「こくちーず」の申込みページは準備中のステータスであるが、間もなく申込み受付が始まるはず…）
※ 申込受付開始！ http://kokucheese.com/event/index/4870/ （10/1 23:55追記）
※ 10/16 あきぴーさんの講演タイトルおよび内容を変更。
Agile Tourとは何か？
（英語） http://www.agiletour.org/en
（日本語） http://www.agiletour.org/ja
Agile Tour Osaka 2010の概要はこちら↓
http://www.agiletour.org/ja/osaka.html
そして、そのうち公開されるだろうが、実行委員特権で（笑）各セッションの内容・見どころなどを一足先にこっそり（？）ここで紹介する。
※ なお、ここに掲載した内容は現時点の予定であり、予告なく変更となることもあることを予めご了承願いたい。
【基調講演】
「日本のアジャイル開発の変遷、現在・過去・未来」
日本のアジャイルをその黎明期から見て来られた、ご存知、テクノロジックアートの長瀬嘉秀氏による基調講演。
2000年にXPを日本に紹介してから10年が経ちました。エンジニアの間で熱狂的に支持を受けXPユーザグループを作りました。しかし、その後、日本ではアジャイル開発は現実的ではないというマネジメント層の反発により、普及しませんでした。
今年になり、様々な要因でアジャイル開発に脚光が当たりだし、大手ベンダー、SIerが導入し初めています。
現在、大手企業が考えているアジャイル開発と日本でのアジャイル開発の未来像をお話する予定です。
【セッション１】
「チケット駆動開発がAgileになる理由 〜No Ticket, No Commit!〜」
今、巷でホットな本と言えば、『Redmineによるタスクマネジメント実践技法』（小川明彦・阪井誠）である。10月13日発売予定のこの本の著者の一人である"あきぴー"氏による講演。これは、見逃せない！ 読んでから聴くか、聴いてから読むか？
近年のソフトウェア開発は短納期・大規模化しているにも関わらず、プログラミング技術の進化に対して、開発プロセスやプロジェクト管理の技法は現場ではそれほど進化していないように見受けられます。
私自身もXPJUG関西に所属後、XPの実プロジェクトへの運用を試していたものの、ずっと上手く実践できてきませんでした。
しかしながら最近、高機能化したバグ管理システム(BTS)をソフトウェア開発のタスク管理に応用すると、Agileに開発できる経験をしました。
その開発プロセスはチケット駆動開発と呼ばれており、プロジェクト管理機能を持つBTSをベースにAgileな開発プロセスに特化した手法です。
今回は、過去3年間運用したチケット駆動開発の経験談と、Agile開発との親和性についてお話します。
【セッション２】
「西日本にだけこっそり教える アジャイルコンサルタントの秘密 〜アジャイルプロジェクトでの失敗防止のコツ〜」
その全国区での活躍と同時に、大阪では相変わらず絶大なる人気を誇る"アリスター・ファウラーMc剛"…じゃなかった、牛尾剛氏の凱旋LIVE！
タイトルに「西日本にだけこっそり教える」とか書いていてもUstreamで全世界に発信されてしまうかもしれない恐ろしい世の中に、彼は果たしてどのような挑戦状を叩き付けるのか！？乞うご期待★
近年、アジャイル開発に注目が集まっていますが、一方でアジャイル開発を実施したけど、上手く行かなかったという話もよく聞きます。
本講演では、2000年からアジャイルに取り組んできて、今のところアジャイル開発で失敗していない私が、アジャイル開発で成功するためのコツをお話いたします。
かっこいい最新型のアジャイルの考え方じゃない現場での泥臭い話が多いですが、アジャイル開発を本当に成功させたい人は是非ご覧ください。
【セッション３】
「ユーザーストーリーマッピング ～ アジャイルな計画づくりを加速する」
東京から四国松山に居を移し、プロジェクトファシリテーション、アジャイルソフトウェア開発のコーチとして活躍する懸田剛氏による、これまた興味深いセッション。
アジャイルな計画づくりのためには、対象となる製品の全体像についての共通認識を、開発者とプロダクトオーナーが共有しておく必要があります。従来のScrumで提唱されているプロダクトバックログでは、その役割を果たすには残念ながら力不足です。
Jeff Patton氏が提唱するユーザーストーリーマッピングを計画づくりの際に併用することで開発者とプロダクトオーナーは全体像を共有した上で優先順位づけを行うことができるようになります。
本講演では、実際にAgile2008でJeff Patton氏から受けた講義、実施の体験にもとづき、その利点と実際の使い方をお伝えします。
以上、基調講演と３つのセッションについて簡単に紹介したが、それ以外にも公募によるライトニングトークスあり、懇親会ありの充実した一日。是非とも、開発者だけではなく幅広い層のみなさんにご参加いただきたい、そしてきっと満足していただけるイベントになると思う。席には限りがあるため、申込みはお早めに！（現時点ではまだ「こくちーず」の申込みページは準備中のステータスであるが、間もなく申込み受付が始まるはず…）
※ 申込受付開始！ http://kokucheese.com/event/index/4870/ （10/1 23:55追記）
※ 10/16 あきぴーさんの講演タイトルおよび内容を変更。
