概要
日時：2014-09-06（土）
会場：早稲田大学理工学部キャンパス(東京都新宿区大久保3丁目4-1)
主催：日本XPユーザグループ、早稲田大学グローバルソフトウェアエンジニアリング研究所
参加したのは以下の５つです。
- 基調講演
- アジャイルを手放して得られたもの
- スクラムの知られざる勘所
- UXデザイン十訓
- LT大会
所感
基調講演
･･･正直うまくまとめられませんでした。
- XPを10年以上やって、XPと言われたモノを改良してやってたつもりが、XPは自己変革も含んでるのでまだXPの中だった・
- XP以前は、問題が起きないように先回りする作戦、XPはミスしてもいいから発見とリカバリーを高速にする作戦。
- XPは自分で合うのを考えてやろうよであって、これをやれというプラクティス集じゃない。
- でもプラクティスにすると、やれたかどうかすぐ分かるし、やれた気になる。すごい誘惑。
B-4:アジャイルを手放して得られたもの
GxPの鈴木雄介氏の講演。
資料: http://www.slideshare.net/yusuke/xp2014?next_slideshow=2
togetter: http://togetter.com/li/715876
その後：http://arclamp.hatenablog.com/entry/2014/09/13/182244
アジャイルが好きな時代も嫌いな時代もどうでもいい時代もあったけど、今がいい距離感な気がするのでその話をする、とのことでした。
まずは、プロセスとアーキテクチャが維持する品質の話が前段としてありました。
ソフトウェア品質と、プロセスとアーキテクチャの相互関係性
- ソフトウェアを作るのは難しい。プロセスとアーキテクチャを両輪として、相互にいい関係性を維持しないと、品質が維持できない。
- アーキテクチャとは、利害関係者が個別に持つ関心ごとを、ビュー(観点の意)として整合させたもの。
- プロセスとは、計画し、（実行結果を）計測し、計画と実行のズレを調整すること。調整するために計画すると言ってもいいくらい調整力が大事。
- 思いつきでアーキテクチャを決めたり、プロジェクト計画変更することはありえない
- が、考えすぎても分からないことはある。だからアジャイルが発明されたが、問題点もある。
アジャイルの問題点
全体整合性が軽視されがち
主にアーキテクチャ軽視。
当たり前の話だけど、後からアーキテクチャに近い層まで直すのには非常にコストがかかり、アジャイルのメリットが吹き飛ぶ。言い訳に使われる（アジャイルのダークサイドに堕ちる）。
アジャイルは不確実性に立ち向かうための道具だが、よりよいものを作るための覚悟がない人には、言い訳の道具として使われる。
ダークサイドに堕ちるかどうかで、言葉は同じなのに、考えていることが全然違うのが厄介。
| よく使う言葉 | ダークサイドの思考 |
|---|---|
| 顧客が欲しいものを作る | ダメなのは顧客の責任 |
| 後で変更できる | 最初に決めるのが面倒 |
| 動くコードが全て | 説明しても分からない |
| イテレーション毎に計画 | 全体にはコミットしません |
| 自動デプロイしてます | お前がテストしろ |
| 優れたメンバーを確保 | 委任契約でリスクは発注元 |
堕ちないために「アジャイルを手放す」
- まず、よりよいものを作りたいという覚悟をする。
その上で、「よいものを作るにはどうすればいいか？」にこだわる。
アジャイルで作るかどうか、は関係ない。アジャイル宣言の左右の項目は、どちらにも価値がある。
どちらにより価値があるかは、状況で違う。よいものを作るために最適なものを使えばいいだけ。とりあえずやってみるのはOK。経験から学べばいい。
ただし、現実を無視しない。
現実には「このプロジェクトにはアジャイルは合わない」という時もある。その時に、誰かの責任を問うたり言い訳しない。
まとめ
- 会社にとって大事なものをマネジメントするのに、あるひとつの方法なんかない。
- アジャイルとかWFとか、手法へのこだわりを捨てて、より最適な手法を考えよう
- どうつくるかではなく、どこに至りたいかを考える。
B-5:スクラムの知られざる勘所
津田貴史氏の講演。
スプリントの運用について改めて考えてみる、という内容。
- タイムボックスに作業があふれる場合は、本当に必要な物から詰める（全部入れるのをあきらめる）。
- 品質、納期、範囲(スコープ)でどれかを変えるなら、常識的に範囲しか動かせない、と根付かせよう。
- スプリントのゴールは動いてはダメ。つまり範囲も替えてはダメ。
タイムボックスの三原則
・品質厳守
・納期厳守
・上記に反しない限り範囲厳守。反する場合は範囲を調整。スプリントを繰り返す目的は、範囲を広げるため（品質をあげるために繰り返すわけではない）。
「スプリント⇒バグ修正スプリント」のように、バグ修正スプリントを入れてはいけない。品質はスプリント毎に完結させる。
スプリントの長さは計画する都度変えてもいい。
タイムボックスの本質とは、スプリントバックログとプロダクトバックログに何を入れるのか、仕分けること。
まとめ
- ゴールに整合した一貫性のある基準で範囲(スコープ)を分け、
- バックログの残り（在庫量）を適切に制御
- 計画通り箱(タイムボックス)に収めること
E-6:UXデザイン十訓
樽本徹也氏の講演。
ニールセンのユーザビリティエンジニアリングという本を元に、ヒューリスティック評価法をハンズオンでやってみよう！という内容。
(ハンズオン)UXデザイン評論家への道
- クレーマーになる。 （例題について）問題と思える所をピックアップ
- 屁理屈を身に着ける 上げた問題点が、10ヒューリスティクスのどれに違反しているか考える。割とこじつけ。
- 徒党を組む 3人以上で、まず個別に評価。その後持ち寄った問題点をマージし、まとめたものをリコメンデーション形式に書き直してレポートする。
解説など
１０ヒューリスティクス
９０年が原書、９４年に改定された。古いほうの方が流通してる。
新旧で対応関係がある。ほとんど同じ事を言っているが表現が違う。
94年版は「美的で最小限のデザイン」という項目が追加されてる。
める。個別評価後にマージする理由
集合形式でやるより視野が広がる。
声の大きい人に左右されにくい。
ヒューりティクス評価は、検出した問題にヒューリスティクスをつなげられればできる。
逆はまずできない。実際には見つけた問題にヒューリスティクスを当てはめられるかどうかが問題。
解決案を考えると、比較的適応するヒューリスティクスが決まることが多い。
まとめ
実は、あんまり役に立たない。
主観が多くあいまい。けちつけてるだけといえばそのとおり。
なので、自分が尊敬できる人をレビュアーに指名するべき。
意見が分かれた時は、議論せずに実験的手法で確認するほうがいい。評価というよりはアドバイスだと思ったほうがいい。
でも根拠は必要。双方がその根拠を理解してれば納得しやすくなる。
作った側には何らかの自身や根拠があってそうしているわけで、それを崩すにはそれなりの
根拠や説得力が必要。
根拠は失敗談や成功談でもOK
LT大会
聞く方に集中してあまりメモしなかったので一部だけ。
- 永和システムマネジメントが、アジャイル事業部で経営計画をクリエイティブコモンズで公開してるよ！
- アジャイルやりたい、の言葉の裏にある真意が食い違ってたのでスクラムマスターをクビになりました。
- スクラムマスターNight、10月中旬に開催します。FBで検索してね！
- コードをシンプルにしたかったらリーダブルコード読もうぜ！
クロージング
「アジャイルに効くアイディアを組織に広めるための48のパターン」という本を頂きました。
初参加だとちょっと優先してもらえるので、どんどん参加するといいよ！