デブサミに参加した
QA@IT
PO側の西村さんと開発側のursmさんの積極的なやりとりが一番印象に残った。西村さん側は積極的にコードに触れていくところ、ursmさん側が仕様（あるべき姿）やドメインに積極的関わっているところ。
アランケイやケントベックが思い描いたユーザ参加型のソフトウェア開発の一つの形態として、PO-開発の信頼関係とPull Requestベースのコラボレーションが１つの可能性としてあると感じた。ソーシャルチェンジ！
後でkakutaniさんに個別に話を聞けた。kakutaniさんとしては伝えたいメッセージがうまく伝えられていないところがあると感じている模様。聞いた内容と講演から自分なりに解釈してメモしておく。（咀嚼し損ねているところもあり）
受託開発の大前提として、発注側と受注側で会社が分かれている。既存の枠組みでは、ソフトウェアをつくって価値を提供するフローの中に多数の障害が存在する。それどこまでエクストリームに取り除いていくかが、重要なポイントとなる。
- 業者選定（選ぶ「信用」の基準に、相見積もりよりも コミュニティやGithub上の個人の評判を利用する方が有用では？として、フローを見直し、修正する。）
- 初期計画（中期計画「ガントチャート」は「信用」に欠ける情報では？としてフローを見直す。）
- 実際にソフトウェアつくる前（ここはまだ課題。使ってもらえるサービスをつくるため、作る前にやっておくことは？とフローを見直す。ランニングリーンのような何かからのレディーレディーからのイテレーションスタート。）
- 中間の実情把握（設計80%はもってのほか。定期デモやすぐに触って確認できる仕組みほかに、コードベースにつくっている過程や、プログラマーの日常のつまづきもそれとなく伝わる仕組み。）
- 納品検収（ちょめちょめな信用にかける分厚い仕様書、テスト報告書より、テスト込みリーダブルコードをGithubにプッシュして、CI上でグリーンを保ち、動くソフトウェアをデプロイし、ストーリー単位でAcceptかの確認する方が有用としてフローを見直す。）
... etc
発注側と受注側を含めて価値を生み出すフローの障害物を取り除く、チームを守る。 Be Social!
マッチョタイプのスクラムマスターの振る舞い例ではないかなと読み取った。
