4/9, 10 にアジャイルジャパン2010が開催されます。ぜひきていただきたいので、みどころ紹介です。

体験しよう！考えよう！行動しよう！

Agile Japan 2010

― 日本のアジャイルはここにある ―

まず、基調講演に、野中郁次郎先生をお呼びしています。最近、「Managine Flow」という書籍を書かれていますが、その中でも、日本型現場経営、実践知経営を前にだしてお話をされています。

基調講演

• 野中先生

先日、先生を訪ねて、基調講演をお願いし、こころよく引き受けていただきました。まず、ソフトウェア開発の世界で、スクラム、が注目されていること。このことは先生自身もご存じなかったようです。また、アジャイルのリーダーに必要とされる資質が、先生が形容した、実践知型、Phronetic Leadership、動詞の経営、と相似形をなしていること。経営が現場とビジョンを結ぶ「場」をつくり、そこで暗黙知と形式知の循環が行われること。ＭＢＡのような理論ではなく、現場と行動ありきのマネジメントスタイル。このあたりをお話したもらいたいと思っています。

• Alan Shalloway

基調講演には、もう一人、Alan Shalloway に米国から来てもらいました。彼はオブジェクト指向技術からパターン、そしてアジャイルに、と道のりをあゆみ、現在は Kanban を押しているアジャイルの伝道師です。AgileとLeanが接近するにつれ、ソフトウェア開発の歴史的な転換期が来ています。ようやく、ソフトウェア開発が「知識獲得活動」だと認識され、その活動が企業内でマーケティングや営業活動と並行に位置づけられるようになる。Lean な組織を目指して、組織を横断した価値創造活動にソフトウェア開発者も参加する時代に来た、という認識です。Scrumがどうやって企業でスケールするか、Scrumの次の形はどんなものか、という議論も含め、期待しています。

(※3/16追記： てつ。さんが、Alan の最新書籍から、彼の現在の関心事でを解説していますhttp://pub.ne.jp/Under_the_Bridge/?entry_id=2796493)

アジャイルジャパンは、基調講演だけでなく、事例、ワークショップ、を大切にし、きてくれたかたに何か持って帰ってもらえるような、元気がでるカンファレンスを目指しています。

事例セッション

• 大規模事例

事例ですが、大規模アジャイルの事例３つの合同セッション。富士通、IBM、情報システム総研、が、それぞれの経験を話したあと、パネルディスカッションで、「大規模アジャイル」についてその問題点、乗り越え方を討論します。神部さん、玉川さん、児玉さん、（森下アジャイル研究所の）森下さんよろしく！

• 官公庁事例

今回、山形県の開発事例、および、佐賀県からプロジェクトファシリテーションの事例が発表されます。アジャイルっていかにも産業界の流行のように思えていましたが、この要素は官公庁でも利用されているんです。山形県からは開発の事例、佐賀県からは、現場活性化に、プロジェクトファシリテーションを使った事例をお話してもらいます。ともに元気がでる事例まちがいなし。東さん、よろしく！

• Webサービスの事例

アジャイルといえば、そのもっともビジネス効果が期待できるのはWebを使ったB2Cサービスでしょう。Webでのショッピングサイトを手がける株式会社楽天および、モバゲータウンなどWebとケータイを繋ぐをビジネス手がける株式会社DeNA。両者も、悩みながらアジャイルに取り組み始めました。生々しい、現実の課題を語ってもらいます。田澤さん、稲村さん、よろしく！

ワークショップ

次に、ワークショップを。アジャイルジャパンの特徴ともいえる、体を使った参加型のセッションです。

• ファシリテーショングラフィック

昨年、とても盛り上がったのがこのセッション。今年もやります。「ホワイトボードの前に立つ」のが楽しくなるこのスキル。ぜひ身に付けて帰ってください。関西PFPの西河さん、よろしくお願いします！

• プロジェクトファシリテーション

プロジェクトを見える化し、リズムを作るテクニックは、必ずしもアジャイル開発だけに用途を絞らなくてもいいはずです。PFP（プロジェクトファシリテーションプロジェクト）から、レゴブロックを使ったワークショップで、体験的に見える化とリズムづくりの効果を体験してもらいます。なおまるさん、よろしく！

• 会議ダイエット

ゲーム『ぷよぷよ』『BAROQUE』等の企画監督脚本をてがける、米光一成さんにお話して頂けることに！これはぼくも楽しみです。

• アジャイルUX

いま、アメリカで一番熱い話題は、このアジャイルとUX（ユーザエクスペリエンス）の融合。UXの専門家たちが、こぞって、アジャイルに視線を送っているのは、ユーザに感動を与える、使ってもらえるUIは、アジャイル以外では作れないから。利用品質ラボの樽本さん（ユーザビリティエンジニア）にお願いして、ワークショップが実現しました！

• かんばんGame

あなたのプロジェクトに、かんばん、立ち上げませんか？見える化の主役、プロジェクトファシリテーションでも一番最初にやってみる、このプラクティス。やってみませんか？ToDo/Doing/DONEのかんばんにはじまり、最新の WIP Limit を持った Pull 型 Kanban にいたるまで、実際に手を動かしてやってみるワークショップです。やっとむ、岡島さんよろしく！

• 「伝える」コツがわかる

アジャイルをやっていると、コミュニケーション、人に伝えることの大切さが身にしみます。コーチングの感性を使って、相手の気持ちで伝えるレッスンです。このワークショップに出る価値は大きい！アネゴ企画の上田さん、よろしく！

もちろん、これだけではなくて、まだ詳細が決まっていない枠もたくさんあります。ぜひ、ぜひ、上司/部下と一緒にペア割りで申し込んでくださいね。

申し込みサイトはこちらです。※早割り（半額）は 3/19 金曜日までです。
http://www.agilejapan.org/2010/02/09221719.html

（※3/15追記： IPA から、「非ウォーターフォール研究会」の方向もあります。日本でのアジャイルを含む新しいシステム開発の現状が見えてきます。）

SEMATのCall for Actionを引き続き紹介します。４章のゴールと５章の原則です。

ゴールには、この活動の目標とトラック（ワーキンググループ）が示されていて、それぞれに活動が進められるようです。

・ 定義(Definitions)：　ソフトウェア工学、およびその領域のその他本質的なコンセプトを定義する。
・ 理論(Theory)：　本質的な助力を提供する理論（特に数学からの）。
・ ユニバーサル(Universals)：　Sematカーネルに組み込むべき、ソフトウェア工学の汎用要素を特定する。
・ カーネル言語(Kernel language)：　ユニバーサル、プラクティス、パターンを記述する言語を定義する。
・ 評価(Assessment)：　ソフトウェア工学のプラクティス、理論を評価する手法。（Semat自体の評価も含む）

ぼくは特に、Theoryに注目しています。ここには、既存のソフトウェア工学の枠をこえて、いろいろな理論が集まりそうです。たとえば、集合論や確率、統計、キュー理論などはたやすく予想されるでしょうが、より心理学に近いもの、例えば、「カテゴリー理論」が例として出てきます。これはLakeoffらの認知心理学で、オブジェクト指向の原点となる、クラスの抽出に人間の認知特性が大きく関わることをもとにしています。

次に、この活動を進めるにあたっての原則を引用。

1. 品質(Quality)。主目標はソフトウェア製品とプロセスの改善にある。
2. シンプルさ(Simplicity)。カーネルには本質的なコンセプトのみを含む。
3. 理論(Theory)。カーネルは堅固で厳密な理論的な基礎の上に築かれる。
4. 現実性とスケーラビリティ(Realism and scalability)。カーネルは実践的なプロジェクト（大規模プロジェクトを含む）に適用可能で、そこで検証可能な手法でなければならない。
5. 正当性(Justification)。すべての提案は、明確な論拠によって正当化されなければならない。
6. 反証可能性(Falsifiability)。すべての主張は、実験的な評価と反論を受けなければならない。
7. 先見性(Forward-looking perspective)。前世代に起こった方法論の淘汰を考慮に入れつつも、完全な互換性には縛られない。
8. モジュール性(Modularity)。プラクティスとパターンはカーネルを使って定義され、それぞれの組織のニーズに合うように組み合わせたり調整したりできる。
9. 自己改善(Self-improvement)。カーネルは自身の進化を可能にする仕組みを搭載しなければならない。
10. オープン性(Openness)。カーネルの開発においては、Semat活動のメンバーからの適切な形式の示唆は、すべて考慮対象とされなければならない。
11. 公平性(Fairness)。貢献するすべてのアイディアは、功績として評価されなければならない。どんな側面も、特定のステークホルダやコミュニティの利益に偏って設計されてはならない。
12. 目的性(Objectivity)。アイディアは、前もって明確に定義された目的性の判断基準によって評価されなければならない。
13. タイムリー性(Timeliness)。進捗と結果をデリバリするために、締め切りを設けてそれを監視しなければならない。

1-9はカーネルに適用される原則。そして、10-13は活動のプロセス全体にわたる原則となっています。

活動に先立って、その原則をこうやって書き示すことは、プロジェクトのよい進め方ですね。

さて、今月中には日本語訳を完成させたいと思っています。

astah 6.1 が公開されています。
http://astah.change-vision.com/ja/feature/newfeature.html

目玉は、「ドローサジェスト」と「要求図」です。ドローサジェストは、クラス図などを書くときに、マウスをアイテム上でムーブオーバーするときに次の動作を先読みして補助してくれる機能です。（以前、ムービーで紹介しました）

もう１つの、要求図をサポートしましたが、少し技術的なバックグラウンドについて説明したいと思います。

「要求」という概念は結構解釈に幅があり、いろんな文献でいろんな定義がありますが、ぼくらが参考にしたのは、まずは SysML です。

やりたかったことは、「要求」と「モデル」を関連付けることによって、どのモデルがどの要求に基づいているかを管理し、要求の変更に関してその依存モデルをたどること。また、逆方向に、あるモデルが、どの要求を満たす目的で作られているのかをたどることです。

この目的のためには、「要求」という概念を取り入れることが必要です。astah* 6.0 では、「要求テーブル」、という形で取り入れました。今回は、これに加えて要求図を提供しています。

ここで、要求、モデル、テスト、の３つの関係はこのようになります。

• モデルは要求を満たす(satisfy)。
• テストは要求を検証する(verify)。

この関係を構築したいのです。さらに、要求は、モデリングの各段階（分析・設計など）で導出されて(derived)行きます。

縦のカラムに要求、モデル、テスト、をならべて、それぞれが具体化する（行を下に向かう）についれてどうなるか、を図示してみました。要求はIDとTEXT、という単純な中身ですが、それを洗練するために、ユースケースなども使われます。

「テスト」についてはまだどのように astah に取り入れるか思案中ですが、おそらくは要求と同じように「テスト」という概念をもちこんでモデルや要求とのトレーサビリティを確保するでしょう。また、マインドマップを使ったテスト戦略設計なんかも、積極的にサポートしたいですし、テストコードとの関係も構築したいと思っています。

すべてが astah でできると思っていなくて、word や excel でかかれた仕様書やテストなどへのリンクも含めて、「要求」、「モデル」、「テスト」の関係と双方向追跡が実現できるとよいと思っています。また、astah の持っているマインドマップのような丸いモデル要素（融通が利く）を生かして、それらをつなげる方法も模索していきたい。