デブサミ2013に行ってきました。1日目 #devsumi

デブサミ2013に行ってきました。
その感想など。

昨年、一昨年も申し込みはしておきながら仕事の都合で行けなかったので今回が初めての参加となりました。（両日とも午後からの参加でした。。）

印象に残ったセッションをいくつか。

初日の『QA@IT』の事例。
登壇者：西村さん（@IT）、浦嶌さん、角谷さん（永和システムマネジメント）
司会：和田さん（タワーズクエスト）

アジャイルで、とてもうまくいった事例の紹介という印象でした。
今回のお話は、主にはPOと開発チームとの関わり方のお話だったように思います。

プロジェクトがうまくいった要因は以下のようなものではないかと感じました。
・POが顧客の会社のなかである程度の決定権があること。
・POが、ほしいものについての明確なビジョンがあったこと。
・POがプログラマの仕事について理解があること。
　（西村さんに関して言えば、ご自身がプログラミングをされることもあって、お話の中からプログラマに対しての尊敬を感じました。実際のプロジェクトにおいてもGithubへのコミットもされているそうで、これには驚きました。）

今までも同様のツールを使用していたが、今ひとつしっくりきていなくて
今回、西村さんとやってみたらすごくしっくりきた。「これだよ、これ！」的な感じ。

司会の和田さんからはお題として、「今回は特殊解だったのか？」というものが出されました。
いろいろ回答がありましたが、永和さんの社内では他にも同様にうまくいっているプロジェクトもあるので必ずしも特殊とは言えない、という意見が印象的でした。
（角谷さんによると、実際には特殊かもしれないが、上場企業と受託開発一筋の会社の間でもこういう枠組みでチャレンジできるのだから、来場者の皆さんとも地続きの話だと思ってもらいたい、という思いがあったそうです。）

終了後、角谷さんにいろいろと質問をしてみました。
※ご回答の内容は覚えている範囲のことですので細部まで正確という訳ではありません。

※ちなみに、浦嶌さんや西村さんではなく、なぜ角谷さんに聞いたのかというのは、個人的に愛読書であるアジャイルサムライの訳者さんはどう考えるのか聞いてみたかったということと、長年のアジャイル開発の経験をお持ちで複数のプロジェクトの比較など、より俯瞰的に見た意見が聞けるのではという考えからのものでした。

質問: 過去のプロジェクトでも同じツールを使用したり、同じようなやり方でやっていたのに今ひとつだったとのことだが、今回のプロジェクトでやり方を変えて上手く行ったということはあるか。
ツールの使い方という意味では基本的には変わっていないとのご回答でした。

質問: 今回のプロジェクトの経験があることにより、例えば過去の上手くいかなかったプロジェクトをもう一度やったら成功させられると思うか。
難しいでしょうとのご回答。プロジェクトごとにコンテキストが異なるので、ある成功事例を単純に他に活かすことはなかなか難しいとのことです。

質問: 顧客の信頼を得るためにどのようにアプローチするのか。顧客と会話するとき、PO以外の関係者とどの程度会話すべきか。ある程度、こちらから会話の場を持たせてもらえるよう働きかけるべきか。
（今回は西村さん以外にも会話・説明する場があり、プロジェクトの進め方の理解を得たという話でした）
最初から成果があるわけではないので、最初は顧客の信頼を得るために「できますよ！」と胸を張って堂々と言わなくてはいけないケースは、どうしてもある。今回のように初めて一緒にやる相手であれば、なおさらのこと。
ただ、顧客の信頼を得るためとは行っても、どこまで積極的に会話をしに行って良いかは、やはり顧客によるそうで、そもそも会話の場を持つ気のない人に強引に行っても仕方ないとのことです。やはり門前払いとか、そういった場合もあって難しい。今回は西村さんが会話の場を作ってくれたそうです。

「過去のプロジェクトをもう一度やったら」の質問に対する回答は、正直意外なものでした。顧客へのアプローチの仕方や巻き込み方など、何か掴めたのではないかと思ったからです。
僕は先の質問と合わせて、成功するプロジェクトと失敗するプロジェクトの分岐点というか共通する手がかりのようなものが掴めればと思っていたのですが、やはりプロジェクトごとに調整が必要なのだと感じました。その調整が難しい。。

また、あとから、いろいろ考えたのですが、顧客の中でも成功基準が割れるときは
どう考えればよいのだろうかと思いました。
今回でいうとPOが望むものをよい連携で作って、POはそれなりに満足度が高いように思われました。ただし、ビジネス的に大成功というわけではないそうで、大規模な機能追加をどんどん行うような余裕はないとのことでした。
QAサイトという、ものがものだけにビジネス的に大成功というのはなかなか難しいと思いますが。
POの作りたいものでは、顧客の会社の（主に上層部の）求めている成果を上げられなかった場合、開発チームはどのようにアプローチすべきでしょうか。
顧客の内部で解決すべき問題として、手を出さない？

正直、POの資質や役割についてよく分かっていない部分も多いのですが、
こういう形もありなんだなぁと感じました。
（POがコーディングすることもありうるという驚きもあり）

長くなってきたので、1日目はここまで。