XP祭り2014に参加してきました。

9/6（土）に実施されたeXtreme Programming (XP)中心のイベントに初めて参加してみました。

f:id:hnishim:20140907002840j:plain

http://xpjug.com/xp2014/

非常に面白かったので、ざっくりまとめておきます。

10:00-11:00 オープニング

「アジャイル仙人」らしい小井土さん、福井さんによるXP入門、といいつつほぼ雑談。本イベントのユルい感じが非常に伝わった笑

ただ、「Context（文脈）に合わせてツールや技法を使う」だったり、「変化を受け入れて状況に合わせていく」というのはその通りだよなあ、と。

11:00-12:00 基調講演「XPの俺」関将俊さん

事務局の方からの事務連絡＋αを挟んで本日の基調講演。Ruby界隈の人らしい。

まったく聞く側を考えているとは思えない話し方に内容を相まってまったく伝える気が感じられないｗ

とはいえなかなか面白いこと言ってたと思う。

減らすほうが大変

「導入したプラクティスなどを減らすことのほうが、増やすことよりも大変」というのはなるほどなと。これまでやってきたことを否定することになるので難しい。

オープニングであった「変化を受け入れ状況に合わせていく」という話や、クリステンセンの「創造的破壊」にもつながる話。

問題への向き合い方

XP以前の問題への向き合い方は「問題が起きないように先回りする」やり方であったが、XPでは「問題は起きるものであり、早く見つけて早く直す」ことで「細かく失敗することで、大失敗をしない」ことを目指しているとのこと。

これはベロシティとイテレーションによって「要望全部を期日どおりには出来ないんで、ここまでにこれだけやりましょう」というのと同様に、完璧を求めすぎて息が詰まる感じだった既存のシステム開発を、現実的なラインで手を打ちましょう。そのほうがお互いハッピーですよね？ということであり、これがXPやアジャイルのエッセンスなんだと思う。

TDDの本質

テストを先に書く＝テストファーストがTDDの本質ではなく、「テストによって完了を知る（何を以って完了かを事前に明確に定義出来る）」ことがTDDの本質だという話だった。これは聞いてる最中はなるほどと思った気になってたが、これって別に普通に設計して、開発して、テスト書いて、テストして、の場合でもそうなんじゃないか？先にテスト仕様（テストコード）があることで、開発とそのテストが完了したかどうかが前もって定義されている、ということかな？

あと、忍者式テスト＝手動で毎日リグレッションテストの話は初めて聞いた。ストイックすぎるだろ、、と思いながら聞いていたが、ホントに出来るのかそんなこと？

13:00-14:30 E-4 ワークショップ「己の中の曖昧さに向き合うが良い」

「曖昧さ」というキーワードだけで参加したところ、中身はTOC (Theory of Constraints, 制約条件の理論)の思考プロセスについてだった。

講師の長身長髪やせ型のお兄さんがメイド服を着て講義をしていたけどご愛嬌。

TOCというと『ザ・ゴール』程度しか読んだことがないので、基本的に生産の話という風に思っていた。その後思考プロセスにまで拡張されたというのは何となく知ってはいたのだけど、実際に触れるのは今回が初めてな気がする。

内容的には「ロジカル/クリティカルシンキング」関連でやるお話と基本的に同じ。なので個人的にはあまり新鮮味は感じなかった。ボトルネック・スループットを重視するTOCの管理理論と直接結びつかなかったので、TOCの思考プロセスってこういう話だっけ？という印象。たぶん違う気がするので近々『ザ・ゴール2』読んでみようかな。

15:00-15:45 A-6 講演「価値創造契約」木下史彦さん

永和システムマネジメント、アジャイル事業部長の木下さんの講演。同事業部では「価値創造契約」と謳い、システム導入費用は0円、解約手数料も0円でサービス利用料で回収する受託開発を3年ほど前からやっているとのこと。

で、その結果は？ということだが「上手くいかないっす」とのこと笑

その失敗の原因についてがメイントピックだったが、非常に面白かった。今回の中で一番面白かったと思う。

解約手数料0円は顧客のメリットにならない

一番衝撃的だったのはこちら。解約するに際しての手数料を0円にすることで顧客はリスクフリー（その分開発元企業がリスク負担をする）なので普通に考えればこれは大きなメリットなはず。ただし、実際にはそうではないという。

理由は、顧客側も失敗前提でシステムを導入しないから、「入れてみてイケてなくてもタダで解約出来ますから」なんてことは社内で説明することは出来ないから。また、実際解約する場合も再び発注先を見つけなければいけないということで本当にコスト負担がゼロというわけでもないので結局失敗したときのメリットというのは考えらないという。

良い物を作れば長く使ってもらえる、とは限らない

価値創造契約で導入したものの、3ヶ月後に経営方針が変わりERPに入れ替えることになって解約になったケースがあるとのこと。「良い物を作れば長く使ってもらえる」というクライアントファーストな考え方は、恐らく長期的・マクロ的には正しいのだろうが、こういったケースが発生しないわけではないということだろう。

顧客の担当者変更

導入後顧客側の担当者が変更になり、新しい担当者にはその契約形態が理解されにくいという。これは新しい製品やサービス、ビジネスモデルの場合はどうしてもつきまとってしまう問題だろう。

サービス利用料に対する対価

構築費用を取らずにサービス利用料に上乗せで回収しているため、運用保守に充てる工数よりも多くの金額を月々払ってもらうことになる。そのような契約形態だということを顧客側が分かっていたとしても、サービス利用料に対するエンジニアの稼働（＝人月）を求められてしまうとのこと。感情的には分かるが、こんなこと言ってくる顧客いるのか。。

上記以外にも失敗原因ひとつひとつ面白かったのだけれど割愛。以前に少し真剣に同様なビジネスモデルを考えていたので非常に良い先進事例として聞くことが出来た。