XP祭り

倉貫さん。
XPの基本説明とEXP(Enterprise XP)について。

以下はメモ。
重要なのは楽しく開発するということ。
反復開発のメリットはリスクの早期発見と解消。
デメリットはドキュメントやテスト工数が嵩むこと。
# かさむって嵩むって書くんだ重むかと思ってた
しかし開発の一番の目的は動くソフトウェアにあるんじゃないか。
変化の抑制から変化の克服へ。パラダイムシフト。
XPを大規模プロジェクトでも使って行こう。
XPに残された問題。
- 契約
- 大規模プロジェクト
- ドキュメントによる品質保証
- セキュリティと機密保持
- 人員調達
デスマはなくならない。→そもそも上流が…
インターネットアプリケーションはユーザが能動的なのに対し、
エンタープライズアプリケーションは受動的。
人数が大くなると価値観の相違が表出してしまう。
上流工程をXPで。
上流下流って言葉のイメージが悪い。
試作製作にしてみては。
まずはXP人口を増やそうじゃないか。

以下は感想。
大規模開発にXPを適用するってのは不可能ではないと思う。
やりたければやればって感じ。
私はやりたくない。というかそんなエネルギーない。
じゃウォーターフォールで現状に甘んじているのかってそうではなくて
エンタープライズなんてやってられるかと。いややってるけどさ。
XPてのは開発を楽しむ人間のためのものだと思う。
大規模プロジェクトで開発を楽しむ気がある人間がどれだけいることか。
私は完全にあきらめモードですね。
開発を楽しむ気がないやつがエンタープライズやればと思う。
というかそうなっているからこそ、大規模のやり方が変わらないんでないかな。
偉い人の問題はもちろんあるけど、
そもそも現場の人間の意識に楽しもうという気がないのではないかと。
だから無理にXPなんて押し付けたってどうしようもないよ。
楽しくやりたい人間は小規模でいいんですよ。
内輪でアジャイルにやればさ。
これが進んでいくとやる気のあるプログラマは大企業から減っていって
エンタープライズ分野はかなりボロが出てくるのではないかな。
そうなってくると顧客側はうまくいってる小規模精鋭の集団に目が行くようになり、
大規模開発もそういう人達に任せるかっていう風潮が出てくるかもしれない。
ま私はどちらにしろ大規模には興味ないですけどね。
仕事を仕事と割り切って楽しむ気なんて皆無な人の中にも凄い人達がいるっていうのももちろん知ってます。
でも楽しむ気がなければ向上心もあまり沸かないよね。
金のためだけに技術力を上げるのはけっこう厳しいのではないかと。

平鍋さん。
この人はアジャイル文化のハブ的な存在ですね。
喋り上手いなぁ。

メモ。
プロジェクトを見える化してモニタリングすべし。
野球のスコアボードがいい例。みんな同じものを見る。一目で状況がわかる。
アナログが良い。壁に貼るべし。デジタルだと誰も見ない!
バーンダウンチャート(プロジェクト全体の見える化)
かんばん。ToDo,Doing,Done。タスクレベルで状況が一目瞭然。
朝会! 15分スタンドアップミーティング。かんばんの前で。
ペアボード。問題vs私たちの構図。
色付きUML。壁に貼る! ソフトウェアの中身を見える化。
ふりかえり。イテレーションの終わりに。
Keep/Problem/Try。
Keepに入るものには名前を付けるべし!→自分たちのプラクティス
(例)ぬかどこ、ニコニコカレンダー
必ず打ち上げしよう!
マインドマップ。思い出しやすい。
自己紹介、本の感想、要求分析などに使える。
PF。プロジェクトファシリテーション。
実践はとっかかり。→ポータビリティが低いので、使えないと思ったら捨てる
QoEL Quality of Engineering Life。
プロジェクトを越えて続く人間関係を得る。
5つの価値。
-コミュニケーション
-行動
-気づき
-信頼
-笑顔
リズムをデザインしよう。

感想。
大変モチベーションの上がるお話でした。
もう朝会とかやらない意味がわからないね。
ふりかえりとか超重要じゃん。
なんというか開発を単なる仕事と捉えてる人達と一緒に仕事するのはしんどいよ。
やれと言われたからやる、みたいな。無理。
問題vs私達の構図は非常に重要ですね。
バトルになってるなと思ったら外から見て、問題vs私達の構図に軌道修正しましょう。
こちらがそうすれば相手も変わるでしょう。
打合せの時の座り方もなるほどなと思った。
対面する形だとバトルになりやすいと。

ひがさん。
DIコンテナSeasarの人です。
年が読めない。

ユーザの要求を如何に見える化するか
仕変はユーザのやりたいことが見えていなかったことが原因で起こる
ユーザ中心設計。
ユーザレビュー可能な形で仕様を固める→UMLはユーザにはわからんよ
以下のものを提示する。
- UIモックアップ (紙芝居レベル)
- 操作マニュアル (ユーザが理解できるドキュメントと言えばコレ)
- 業務手順書 (マニュアルの範囲には収まらない複雑なロジックや詳細な仕様確認のため)
ユーザインタビューの内容
- 目的は？
- 何ができないと困る？
- 何ができると嬉しい？
- 今できていることは何？
確認ポイント
- データ項目
- ボタン/リンクのアクション
- 画面遷移
- エラーメッセージの表示方法
UIモックアップはデザインに凝らないこと。
プロトタイプではないのでロジックを入れないこと。
使い捨てではない。デザイナーの仕事のスタートポイントになる。
操作マニュアルは画面設計書の代替。
ユーザの気持ちに近づけるという利点がある。
要求フェーズの段階で例外を洗い出す。正常系以外もちゃんと考える。
後に作っていたものを先に持ってくるという逆転の発想はテストファーストと似ている。
業務手順書はシステムを導入せずに手作業でやるとしたらどうなるかを考えて作る。

感想。
できたらいいなと思う。
UIモックアップだけでもあると全然違うだろうね。
操作マニュアルと業務手順書はちょいと重いけど、ユーザの事を考えるならやるべきだろう。
後で文句言われても反論できるようにではなくてさ、
文句言われないようにしようという気持ちだよね。
本当に役に立ちたい、喜んでもらいたい、そいういう気持ちで開発しないと。
画面項目定義書とかイベント定義書とかさ、正直イラネと思うわけ。
まいろいろとしがらみがあって効率悪いと気づいていても変えられないんだけどね。
ちょっと前に私は仕事でUIモックアップを作ったんだけど、
コレをちゃんと作るべきなんだよって思ってて真面目にやりましたよ。
というか図とかUIとかってきちっと統一取れてないと我慢ならないんですよ。
脱線するけどドキュメントの用語とか統一するためのメタドキュメントを作らない意味がわからない。
ドキュメントの質が悪いのはメタドキュメントがきちんと整備されてないからですよ。
だから個々人が勝手に時間かけて考えて、しかしバラッバラで統一するのに無駄な時間が…
これはアジャイルとは全然違ってむしろ大規模プロジェクトで定番になっていていい話だと思うのですがねぇ。

萩本さん。
要求開発。
要求とは開発するものである。

レアケースのシステム化が本当に必要なのかちゃんと話し合って決める。
ビジネスとシステムノ表裏関係を意識する。
ビジネス課題(表) - ビジネスオペレーション(裏)
ビジネスオペレーション(表) - システム要求(裏)
システム要求(表) - システム設計(裏)
運用イメージの欠如。せっかく作っても使われない!
要望-要求-要件
ユーザと開発者の暗黙知問題
-慣習化された業務知識
-フレームワーク知識
ToBe(将来)かAsIs(現在)か
どちらを先に可視化するべきか →ケースバイケース
発想の過程を可視化すべし ※UMLはスナップショット
→マインドマップは向いているのでは
モデリングの目標と検証方法を明確にする
制御可能で制御価値のあるものに絞ってモデリング(可視化)する
仮説検証型PDCAサイクル

感想。
全体としてかなり上流というか抽象的な話だったので半分くらいしか理解できなかった。
ただまぁここでも可視化ですよ。見える化。
見えないものは制御できない。
見えれば戦略が立てられますからね。

パネル。
倉貫さん、平鍋さん、関さん(dRubyの人)、
萩原さん(マイクロソフト)、ひがさん、萩本さん
という錚々たる顔ぶれ。

マイクロソフトの萩原さんの思想はかなーり共感。
IT革命とか言ってたけど金儲けしたいだけじゃん、
もっとこの業界を本当に革命しようじゃないかと。
つまらないモノばっかり作ってないで、もっと面白いテーマがたくさん転がっています。
せっかく革命の時代にいるんだからおもいっきり暴れましょう。
方法論とかもいいんだけど、技術でなんとかできるものは技術でなんとかしてしまえ、
まだまだその余地はありまくる、とか。
人が大事なのは当然なんだけどさ。
それを解決するためのシステムであり技術でしょと。
まだやってないこといっぱいあるじゃん。

ライトニングトークス。
角谷さん。RabbitでRubyの宣伝。
Rubyコミュニティは積極的に宣伝してしかもプレゼンウマーな人が多いのが強い。
高橋メソッドはここでも広まっていました。
なんかお笑い系が後半やたら多かった。
いっぱい笑わせてもらいました。
他にも面白いのが盛り沢山だったけどメモしてなかったので略。

いやーいい刺激になった。
一番心に残ったのはコレ。
「見える化重要」