PI Study #2 「ペアワイズ法を使ったテスティングワークショップ」

@東京都豊島区東池袋３丁目４番３号池袋イースト10F テラインターナショナル株式会社
http://pistudy.doorkeeper.jp/events/11043

仲間とはじめた勉強会の2回目。
1回目はSTARの良質なコンテンツを使ったので、余裕だったけど、今回は1からつくったので、なかなか大変でした。
で、一人KPT。

KEEP

• 講義を聞くだけではなく、実際に手を動かす
• モクモクとやるのではなく、チームで話しながらやる
• 講師は気負わず、知ってる範囲で知ってることを伝え、共に学び合う
• みなさん熱中してくれた（休憩もとらずにやってた）
• 「他の勉強会も色々でてるけど、平均より良い勉強会ですよ」と言ってくれた
• 永井くんが「Gebを勉強して今度は僕がやります！」と言ってくれた

PROBLEM

• ペアワイズ法と銘打ったにも関わらず、ペアワイズ法を深堀りしなかった
• 2因子網羅の部分の説明が足りず、理解してもらえなかった人がいた
• DevNomiテスト編で、計算が複雑すぎてそこで無駄な時間を食ってしまった
• チームに発表してもらったときに、気の利いたコメントが言えなかったし、チーム間でディスカッションするファシリテーションができなかった
• 若手向けを意識したけど、若手は勉強会にはあまり来ない

TRY

• 絶対に持ち帰って欲しいものを1つ決めて、そこはきちんと深堀りして準備する
• ディスカッションの時間をきちんととり、準備したうえでファシリテーションする

DevLOVE「オブジェクト設計とリーン開発、その実践」に参加しました

@名古屋市中区錦1-15-8 アミティエ錦第一ビル 4F Coworking Space A+LIVE セミナールーム

正しいものを正しくつくる
ギルドワークス創業おめでとうございます！
増田さんのプロジェクトで増田さんに叱られながら仕事してみたいなぁ。

第一部 オブジェクト設計エクササイズ [13:10〜14:00] 増田亨氏

実践的な設計って、なんだろう？ from 増田 亨

設計とは、変更コストを下げるためにコードを整理整頓する実践的な工夫

プロセスやツールよりも設計

コードを整理、整頓する。
それは、変更コストを下げたいから。
（作って終わりならいらないけどね。）

実践的ってなんだろう？

いくつかの観点で、対岸を行ったり動きながらバランスを取る。
（全体<->部分、長期<->短期・・・）

具体的にどうやるの？

変更コストの原因を知る。
変更コストの最大の敵は「重複したコード」。

重複したコードのいやな臭い（Martin Fowler "Refactoring"）

• 長いメソッド
• 大きなクラス
• たくさんの引数

マスダ流重複の臭い判定基準

• クラス：50行（100行）
• メソッド：3行（5行）
• 引数：0（1）

これを超えたら警戒警報！
（カッコの中はチーム用に緩めた数字）

コード整理の基本パターン

• Value Object
• 振る舞いを持った区分
• ファーストクラスコレクション

Value Object

immutableがポイント。
例）Stringクラス
内部の値を変えずに、新しいObjectを返している。

getメソッドをつくらない。
getをつくるとロジックが散らばる。
データのある場所にロジックを寄せる。
setメソッドもつくらない。
setをつくると状態管理のコードが散らばる。
=> immutable（不変オブジェクト）

プリミティブなクラスは使わず、業務（ドメイン）固有のクラスを作る。
例）
String, StringBuilder, List<String> => ProductName, Remarks
BigDecimal, Integer => Money, Quantity, Unit
Calendar, Date => InitialDate, DueDate, ValidTerm

振る舞いを持った区分

enumにメソッドを持たせる。
定数も、関連するロジックはそこに閉じ込める。

ファーストクラスコレクション

privateなコレクション、publicな振る舞い。
コレクションをgetして操作するとあちこちにコードが登場する。
例）
Customers, OrderLines, UsageHistory, ToDoList・・・

コードの整理　アンチパターン

• Smart UI（画面単位で設計）
• トランザクションスクリプト（機能単位で設計）
• Active Record（テーブル単位で設計）

=> 必ずコードが重複する。

Smart UI => 画面間で重複が発生する。トランザクションスクリプト => 機能間で重複が発生する。
Active Record => テーブル間で重複が発生する。

コードの整理　グッドパターン

• ３層＋ドメインモデル
• 業務の関心事（業務知識）に基づき設計する

=> 変更が簡単

• 仕様変更は業務から発生する
• 業務の関心事の依存関係がクラスの依存関係になっている
• 変更の対象箇所以外でわけのわからない副作用がおきない

第二部 リーン開発の現場 [14:10〜15:00] 市谷聡啓氏

理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ！

誰かが正解を持っている訳ではない

開発の命運を握る２つのレバー

• 期待
• リスク

期待

関係者が互いに持っているプロダクト/プロジェクト/チームへの暗黙的な望み

期待マネジメント

期待を明らかにして適切に調整しつづける。役割と時間を超えて。

チーム => プロジェクト => プロダクト => ビジネス => 組織

レイヤーごとに目的と期待がある。
レイヤーを超え、役割を超えた理解が必要。

Moving Management Target

期待とリスクのバランスは時間とともに変わっていく。
時間を超えた理解が必要。

インセプションデッキ

期待マネジメントのツールの１つ。
大事なのは、アウトプットではなく、その過程でお互いに理解しあうこと。

仮説検証型と最短距離型

目的実現のための選択肢がいろいろある。
=> 何を選ぶか決めるために試行し検証する。
=> 検証から何をどう作るか徐々に決められる
=> 手段と対象がわかれば、最短距離でつくる

スコープが決まってないのに期限だけ決まってる
=> 超危険
=> 仮説検証時は期間契約、スコープが決まれば請負契約

大事なのは、フェーズによって戦い方が変わるということ。

仮説検証型のPlan

リーンキャンバス（仮説）
=> エクスペリエンスマップ（検証）
=> ユーザーストーリーマッピング（仮説）
=> インセプションデッキ（検証）

参考）
「開発戦略は「意思決定」を遅らせろ！」（稲垣 公夫）

最短距離型のPlan

CCPM
パーキンソンの法則：バッファを使いきってしまう。
=> バッファをプロジェクト全体で管理する。

荒ぶる計画を飼い慣らす

• 要求レベルをMust, Want, Tryで可視化する
• プロジェクトの8-9割でMustを実現できる見込みを立てる
• 残った工数でWantを開発する

仮説検証型のDo

なんのための反復？
何を検証するのか？

カンバン（仮説検証型、最短距離型）

仮説検証型：タスク、課題解決の可視化 => タスクボード
最短距離型：全体フローの見える化 => カンバンボード

仮説検証型と最短距離型の見極め

=> インセプションデッキ

ソフトウェアを創り上げるもの

誰が、誰と、誰のために
どういうルールで、何を作るか

リーン開発の現場 P.109

理想とはたとりつくべき場所のことではなく、ありたい姿に向かい続けることなんだ！

第三部 Q&A [15:10〜16:00]

• DDDをどれくらいかけて覚えれば？
  => 2008年からはじめてわかりはじめたのが2012年。現場で続けるのが一番。
• フレームワークを使っている場合（コード自動生成）の折り合いは？
  => 大嫌いだから使ってない。折り合いの付け方もノウハウ。
• クラスが多くなったときのまとめ方は？
  => 業務にあわせてパッケージを構成している。
• お客様に丸投げされたときにどうすれば？
• バッファと見積の合意方法は？
  => QCDSのトレードオフスライダーを使ったりする。
• そもそもドメインって何？
  => まあ、気にしないほうがいい(^^)。カタカナは日本語にするとよい。
• インフラからプログラマになるとき何を学べば？
  => 今はインフラもコードで自動化する時代。そこからはじめては。
• 設計の価値をどう伝えれば？
  => 相手が開発者であれば、変更が大変だったネタを思い出して盛り上がる。そこからスタートすると伝わりやすい。設計とは何かとか良い設計とはとかのアプローチは必ず失敗する。ただ、人がつくったコードで痛い目あってる体験共有からだとうまくいかない。
• 期待をどうマネジメント？どうまとめる？
  => インセプションデッキを使う。困ったらぜひギルドワークスへ(^^)。インセプションデッキの期待が高くなり過ぎないようにしれっとね。
• 設計の考え方をどう共有するか？
  => 経験がないのでわからない。若い頃は意地になって相手を潰すぐらい勉強した。
• カンバンをどう広めるか？
  => いきなり実プロジェクトでやるのはリスクが高い。カンバンだったら、まずは、自分でやれる範囲でやるとか。失敗できるところでやってから。
• どんなドキュメント管理してる？
  => クラス図やドキュメントを全部作ってない。ドメイン知識が増えれば、ドキュメントがなくてもわかる。新しいメンバーにはドキュメントではなく、業務を覚えてもらう。業務がわかれば、ソースが読める構造になっている。
  => IDEが優秀だから。IntelliJ IDEAがオススメ。すぐ乗り換えよう。
• どんな工程？
  => 全部網羅的に設計せずに、重要な部分だけ抜き出して設計してる。
• 開発スピードが落ちない？
• マスダ流は厳しすぎない？
  => 実践でいきなりやるのは難しいかもしれないが、実際にやって、まずは体験してみて。
• なんのロジックも持たなくて、単純な置き換えでもクラス化する？
  => する。名前がほしいから。

SeleniumとGebとCasperJSの比較

STARの教材を使って、SeleniumとGebとCasperJSを比較してみました。

どれも詳しくなく、軽く触っただけですが。

比較結果

個人的には、Geb（+spock）が好きです。

ただ、Web系でJavaScriptバリバリの人が多いなら、CasperJSは有力でしょう。

コマンド一発でインストールできて、テキストエディタ一本で開発できちゃうし、動作もサクサク。

この軽量さは好感が持てます。

クロスブラウザができないという弱みはありますが、結局、クロスブラウザって目視確認しないと微妙な崩れとかわからないので、実はそんなに弱みではない場合も多いと思います。

操作性

操作性はGebが圧倒的です。

JQueryライクに要素をとれたり、すべてのhtmlコントロールでメソッドが大体同じだったり、シンプルにコードが書けたり、とにかく気が利いています。

CasperJSもJQueryライクに要素がとれて便利ですが、メソッドを揃えるような工夫はあまりないです。

あと、JavaScript全般に言えることですが、入れ子が多くなって私は嫌いです。

Selenium(Java)は、とにかく長たらしく書かなければならないので面倒です。

Selenium：☓

Geb：○

CasperJS：△

環境整備の容易さ

Seleniumを普通とすると、Gebは少し面倒でした。

groovyとspockのバージョンの整合性ではまったり。。。

比較ということでGebを☓にしましたが、SeleniumとGebはそんなに変わらなく、CasperJSが圧倒的に簡単です。

コマンド一発で環境整備できちゃいます。

（「WEB+DB PRESS vol.80」がとてもわかり易いです。）

Selenium：△

Geb：☓

CasperJS：○

クロスブラウザ

CasperJSはPhantomJSで動かすものなので、そもそもクロスブラウザという概念がありません。

SeleniumとGebはクロスブラウザ対応しています。

Selenium：○

Geb：○

CasperJS：☓

コード

GebとCasperJSは私が書いたので、あまりキレイではないかもしれませんが、コードを比較してみてみるとおもしろいです。

Selenium

STARリポジトリ　のanswer参照。

Geb

https://github.com/itagakishintaro/STARHandsOnGeb

CasperJS

https://github.com/itagakishintaro/STARHandsOnCasperJS

「UX、デザイン思考、リーンスタートアップのためのインタビュー入門」に参加しました

UXD/HCD ワイワイCAFE「UX、デザイン思考、リーンスタートアップのためのインタビュー入門」@株式会社アイ・エム・ジェイ 本社 青葉台カフェ

UI/UXに限らず、業務システムの業務ヒアリングなどでも使えるとてもよいワークショップでした。

v=f(x)：「ユーザーの声を聞くべからず」

ユーザーインタビューなのに、ユーザーの声を聞いてはならない。
それはなぜ？
ユーザーの声は、ユーザーの体験をユーザーが分析したものだから。
v=f(x)のvはボイスで、xはUX。
UXを素人であるユーザーが分析した結果であるユーザーの声を聞いてはならない。
ユーザーの体験そのものを理解し、我々が分析しなければならない。

弟子入りゲーム

アンケートもグループインタビューもユーザーの声を聞く手法。
では、どうやって、ユーザーの体験そのものを知るのか。
その答えが「弟子入り」。
ユーザーを師匠と見立て、弟子になったつもりで聞く。

基本

基本は次のとおり。

• クローズド質問（Yes/Noで答えられる）ではなくオープン質問（体験を自由に語ってもらう）
• 文脈をクリック（気になるところがあったら、そこを掘り下げる）
• 意見や判断を聞かない
• 仮説検証（こうだったらどうします？）はダメ、体験を聞く

ゲーム1回目（5分で3センテンス正解）

師匠（ユーザー）と弟子（インタビュアー）に分かれます。
師匠は、ユーザー体験がA4で4ページくらい書かれたスクリプトを読んで、ユーザーになりきる。
弟子は、インタビューをして、師匠の体験をインタビューして書き取る。
さて、どのくらい聞き取れるでしょうか？
私はボロボロで3センテンスしか正しく聞き取れませんでした。

ゲーム2回目（10分で15センテンス正解）

インタビューの仕方を少し教わります。
コツは次のとおり。

• 占い法はダメ（当てに行かない）
• 次は何をします？と聞いていく
• ある程度いったら、戻って、その前は何をします？と聞いていく
• 知ったつもりにならない

これを聞いた後、やり直したら、びっくりするくらい正しく、多くスクリプトを読み取れました。
1回目の後だし、時間も倍になっているので当たり前ではありますが、コツを意識するだけで、圧倒的にやりやすくなりました。
（1回目はアンチパターンの「占い法」でいってしまっていました。。。）

インタビュー設計

KJ法

聞きたいことリストをKJ法で整理します。
KJ法はおなじみですが、少し誤解があるそう。

• 似たものを近くにするとき、今、貼られているカードの中での相対的な距離で考える
• トップダウン的思考になるので見出しを先につけてはダメ、あくまでボトムアップ思考
• 縦横整列させず、空間をめいっぱい使う

写真は私のチームの成果物です。

シーケンス＋質問を考える

次に、インタビューのシーケンスを考え、見出しと聞きたいことを一列に並べます。
その後、質問を考えます。
質問は、弟子入りゲームで学んだことを活かして考えます。
写真は私のチームの成果物です。
※見出しのカードの字体が素敵でしょ。チームにたまたま不思議書体女子がいました(^^)

懇親会

懇親会が熱かった！

リアルタイムドキュメンテーション

リアルタイムにドキュメンテーションする方法らしいです。

1チームが実験台になって、スタッフに観察＋リアルタイムドキュメンテーションされ、これを使ってふりかえりが行われました。

カードの分類は以下のとおり。

• 黄色カード：事実の記録
• 黄色カードに赤い枠：講師の言葉
• 青カード：観察者の主観（気になったコト）
• 青ミニ付箋：残念な点
• 赤ミニ付箋：よかった点

これを観察者が説明して、観察されたチームが反論するというもの。

はじめてみたのですが、とても面白かったです。

でも、やるのはちょっと難しそう。。。

アプリデモ

UI/UXの賞をとったIMJさんの子供向けアプリ。

本当に、UI/UXが考えられたおもしろいアプリでした。

メンタルモデル

書籍「メンタルモデル」の訳者の1人、羽山祥樹さんによるメンタルモデルの解説。

その解説に、今回の講師の樽本さんが割り込んでディスカッション。

熱かった！

ちなみに、メンタルモデルは「ユーザーが期待、想像するもの」的なメンタルモデルとは別。

行動観察ではなく、インタビューから読み取るものなのでメンタルモデルと名付けられたそう。

混同するからよくないよね。

PI勉強会#1「Selenium勉強会」

@テラインターナショナル

記念すべき第1回は、2013年12月1日に大盛況のもと行われた、システムテスト自動化カンファレンス2013 ハンズオン「実践で学ぶ、効率的な自動テストスクリプトのメンテナンス」のコピーです。

こんな良質なコンテンツをフリーで公開しちゃうなんて、STARありがとう！
コンテンツ作者のTRIDENT伊藤さん、ありがとう！

以下、オリジナルコンテンツに対して、私なりにちょい足しした内容をメモしておきます。

メソッドチェーン

※SHIFTの玉川さんに教えてもらいました。ありがとうございます。

模範解答では、以下のようになっています。

pageObject.method1(foo);
pageObject.mothod2(bar);
・・・

これより、次のようにメソッドチェーンで書いた方が美しいコードになります。

pageObject.method1(foo)
               .mothod2(bar)
                ・・・

SpockとGebの紹介

※Gebはきょんさんに紹介してもらいました。ありがとうございます。

ハンズオンはJUnitですが、Spockの方が書きやすい。
Groovy, BDDとか言うと、何だか難しそうに思えるけど、実はSpockを使った方が簡単ということを伝えました。
口頭だけなので、どこまで伝わったかわかりませんが。。。
（JUnit実践入門もとってもおすすめしたので、どっちやねん！って感じだったかも。。。）

Gebは、JQueryライクに要素をとれてスッキリ楽々なことと、値の入力、取得がほとんどのコントロールで同一なので、むしろSeleniumより覚えること少なくて楽だということを伝えました。
こちらも伝わっていればよいのですが。。。

データ駆動とキーワード駆動の紹介

※もし、間違ってたら、誰かやさしくコメントください。

キーワード駆動（もどき）のデモ

※あくまで、もどきです。

これは結構ウケました。
えー、こんな簡単に、こんなことまでできちゃうのー的な(^^)

https://github.com/itagakishintaro/DevNomiTest

pages配下：テスト対象のコード

src/test配下：テストコード

（KDTcore.groovyがコアのコード）

※Groovyの環境設定はREADME.mdを参照してください。

「サービスデザイン思考入門（オージス総研）」に参加しました

サービスデザイン思考入門@オージス総研

ペルソナ、カスタマージャーニーマップ、ビジネスモデルキャンバスを使いながら、病院のサービスを題材にサービスデザイン思考をしてみる4時間のワークショップ。
個人的にはとてもよい勉強になったけど、会社でやるのはなかなかに大変だなぁ。

資料は、フェイスブックの「デザイン思考コミュニティカレッジ」で公開してくださるそうです。
なんで、資料はそちらから。

ペルソナの設定

はじめに、エンパシーマップを使って、ペルソナを設定しました。

私が知っているペルソナとは違うやり方なので、おもしろかったです。

「共感」を大事にしているデザイン思考にあったフォーマットなんですかね。

カスタマージャーニーマップ（AsIs）

流行りのカスタマージャーニーマップ。

ググると色々なフォーマットがありますよね。

今回は、とてもシンプルなフォーマットを用意してくれていました。

横軸が時間で、縦軸は「アクティビティ（シーン）」、「インタラクションズ」、「感情の起伏」の３つだけ。

インタラクションには、「気持ちとかも入れていいよ」というゆるい感じ。

やりやすいですね。

テーマ設定

カスタマージャーニーマップを踏まえて、テーマを決めます。

「感情が下がったところが狙い目だけど、視野を広く持ってテーマを決めましょう」とのこと。

でも、やっぱり、感情が下がったところをテーマにしちゃいました(^^)

アイディアだし

テーマに沿って、アイディアだしをします。
ここも、多少テーマからズレてもOKとのこと。
あと、「枠からはみだせ！」と。
いっぱいアイディアがでました。

カスタマージャーニーマップ（ToBe）

アイディアを適用したときのカスタマージャーニーマップを書いてみます。
感情のマイナスがなくなりました！

寸劇とフィードバック

できたカスタマージャーニーマップをもとに、寸劇を披露します。
（恥ずかしいけど、結構、雰囲気ができあがってるからできてしまう。）
で、寸劇をみた他のグループからフィードバックをもらう。
「良かったところ」、「改善点」、「疑問点」、「アイディア」の4分類。
意外に、見た人から「こんなのどう？」的なアイディアももらえたりしたのがおもしろかったです。

ビジネスモデルキャンバス

ビジネスモデルキャンバスは有名ですね。
（リーンキャンバスも有名。）
ググればすぐでてきますが、私は書いたことはなく、初体験。
ここで、スイッチが現実モードに切り替わります。
で、かなり「うーん」ってなってしまいました。
現実では、キャンバスの時点やプロトタイプをリリースした後のフィードバックで、何度もやりなおすんでしょうね。

ピクト図解

ピクト図解はワークはなくて、説明だけでした。
でも、ルール自体は簡単なので、使うのは簡単そうです。
使いこなすのは難しいんでしょうが。

ふりかえり

KPTです。

まあ、おなじみのやつです。

懇親会

色々なバックボーンの人の色々な話を聞けて、とてもよい懇親会でした。
中でも「実際には、叩かれまくるフェーズが絶対必要！」というのが印象に残りました。
そりゃそうですよね。

お礼

4時間コースで、懇親会の軽い飲食があって1000円。
えらいぞ、オージス！
これからも頑張ってオージス！！
ということで、オージス総研さん、ありがとうございました。

DAD本読書会#4に参加しました

DAD本読書会#4 @21cafe

DAD本こと、「ディシプリンド・アジャイル・デリバ​リー エンタープライズ・アジャイル実践ガイド」の
読書会#4です。
今回は、監修者の藤井さんに質問して、お話を聞いたり、みんなでディスカッションする方式でした。
DAD本勉強会ですが、RUPの話で盛り上がってしまいました。
以下、メモです。
誰がしゃべったのかは、もう覚えてませんので、藤井さんの見解とズレもあると思いますので、ご注意を。

方向付けフェーズ

方向付けフェーズは重厚じゃない。ゆるいRFPをつくるイメージ。

お客様がアジャイルについてわかっていないとDADを提案するのは難しい？
教育をして、DADでできるか判断する。
RFPでてからだと遅い。

検討不足と学習や発見との違いは？

そもそも、検討不足と学習や発見の分類に意味がない。
抜けが見つかってよかったと言えばいい。
結果的に価値のあるものをつくるために、つくってみて、動くものをみた方が抜けを見つけやすいことが多い。

推敲フェーズ

Unified Processの「アーキテクチャ中心」は捨てた？

なんでDADでは推敲フェーズがないのか？

出版前には推敲フェーズがあった。
Unified Processの「アーキテクチャ中心」を完全に捨てた訳ではない。
アーキテクチャを初期に確定させるのはNGだけど、変える前提で、ある程度アーキテクチャの見通しをたてて、リスクを潰すという発想。
そうなると、フェーズとして残さない方がよいという判断だと思う。

XPではアーキテクチャをはじめに考えない？

Kent Beckはテクニカルなリスクを優先順位に一切考慮しないと言っていて、Martin Fowlerは少しは考慮すると言っている。
このレベルの人たちは、飛行機の中でxUnitつくっちゃう人だから、頭のなかでアーキテクチャのこともちゃんと考えてるから崩壊しない。
DADでも他でもそうだが、stabilizationという機能を追加しないでアーキテクチャの整合をとるためのイテレーションを設けることがある。
大規模開発や金融系の開発をバックボーンに持つ人はアーキテクチャを重視する傾向にある。

DADは合意を重視

DADはアジャイルスケーリングモデルの中間。
意思決定やコミュニケーションの仕方を整理している。
常に早くリスクヘッジする。
それがビジネスリスクかテクニカルリスクかは問わない。
重要なのはそれを合意すること。
フェーズの区切りは、合意ができていること。

WaterfallとUnified Processは何が違う？

Waterfallで1次開発、2次開発とやっていたら、繰り返し。
Waterfallはアーキテクチャを重視する。
そもそも、ロイズの論文ではWaterfallは規模が大きい時は2回は繰り返すと言っている。
だったら、WaterfallとUnified Processは何が違う？

ユースケース駆動

UPの「ユースケース駆動」、「アーキテクチャ中心」、「インクリメンタルかつイテレーティブ」の3つで残るのは、ユースケース駆動。
あとは、1年を2回とかで反復と言えるか？

日本での大規模開発はRUPがいい

RUPはヘビーという誤解がある。
RUPは成果物を決めているが、成果物は紙ではない。
決めなければいけないことを定義しているだけ。
アジャイル開発でプロジェクトを進めるときは、バラバラの要素を組み合わせる必要がある。
RUPはまとまっている中から省いていく。
そうとらえると、日本の大規模開発では、RUPがあっているように思う。

業務システムでアジャイル開発は難しい？

業務システムは機能も多いし、ある程度まとまらないと評価できないので、アジャイル開発が難しいのでは？
BPRをしたいが、ステークホルダーが多くて、かつ、ITリテラシーが低い人ばかりなので、使わせて確認しながらやりたいというお客様の要望でやってうまくいったことがある。
業務システムという区切りではなく、何をしたいかが重要。
ゴールが不明確でアジャイルと言っているケースが多い。
BPRしたいとか、変えたいという意思がないとアジャイル開発する意味は無い。

大規模ではアジャイル開発は難しい？

なんで大規模だとアジャイル開発は難しい？

意思決定が難しいのでは？

Waterfallでも意思決定しているはず。ものを見せずに意思決定できるのなら、ものを見せたらもっと意思決定がしやすいはずでは？
みせる人数が多くて大変だったり、みせると意見がですぎてまとまらないのでは？
人数については、機能ごとに対象者は絞られるので、そうでもない。
ただし、バラバラにでた意見のまとめ役は必要。
意見はいっぱいでていい。
くだらない意見がいっぱいでて、実際に動くものをみると、くだらないことがわかるようになる。

複数システム、プロジェクトと連携するマルチベンダーの場合は？

アジャイル開発というかイテレーション開発になるが、統合リスクを管理するために、定期的に統合するメリットはある。

感想

アジャイル開発の勉強会で出席者がSIの人ばっかりってのはめずらしい。
貴重な場です。

あと、21cafe。すごくおしゃれで、無料。すばらしい！
いつか自分もここで勉強会を主催したいなぁ。

お礼

藤井さん、21cafeさん、ステッカーありがとうございました！