Agile Japan 2012に参加！ #1に引続き午後のセッション２

 

「アジャイルをも活用した新しいビジネスモデル」に参加

受託開発をやっている身としては、

発表されたときからすごく気になっていたビジネスモデル。

 

永和システムマネジメントさんの「価値創造契約」について

詳細はこちら

http://www.esm.co.jp/new-agile-contracts-service.html

 

気になっていたポイントは、

お客様にどうメリットとして受け取ってもらうのだろうか？

というところ。

 

チケットという単位でサービスを作ってもらうことで、

今までよりお客様にとって何が良いのか？

 

聞いた内容や質問した内容をまとめると

• お客様には２つのやり方を提案して、どちらがよいか選んでもらったり、向いていると考えた場合は提案している
• エレベータピッチを作成して、それを元に開発途中の要求変更と照らし合わせを行っている
• 価値創造契約を行ったお客様の評価は良い
• 開発側の課題としては、良さをお客様に伝えるのが難しい
• 価値創造契約を行うお客様と、WFのお客様は大きく異なる

 

参加者から「チケットという概念がお客様にとって理解しがたいのでは？」という質問があり、

ピボータルトラッカーにやりたことを追加していってもらい１チケットの分量や内容を状況に応じてお客様とすりあわせている。

チケットプランは、目安であって当てはまらない場合は柔軟に対応している。

とのことだった。

 

肝心の気になったポイントの明確な回答は得られなかったけれど、お客様の評価が良いということが何よりうまく言っている証拠だと感じた。

 

自分が実際に提案するなら、信頼貯金がたまっているお客様へは提案して受け入れてもらえそうな気がするし、気に入ってもらえそうだと思う。

また、早いサイクルで動く物が手に入りかつ、着手前なら優先度も変更できるわけだから一度価値創造契約を体験したお客様は元の受託契約には戻らないのではとも思った。

 

難関は、信頼貯金がないor新規のお客様へどう説明するか。

これは、Agile開発をお客様に提案することと同意かな。

 

ソニックガーデンさんの「ソフトウェアパートナーシップモデル」について

詳細はこちら

http://kuranuki.sonicgarden.jp/2011/09/post-50.html

 

聞きながらなので、かなり端折ってしまうけれど

• 常駐はしない（のぞまれることもある）
• 瑕疵担保責任は負わない
• 月額定額でおこなっている
• お客様がサービスを確認するためのテスト環境は、Herokuを使っている
• 見積もりをしていないので、開発途中の機能の抜き差しは開発に何も影響しない

 

「価値創造契約」のチケットという概念について聞かれて、

チケット性を導入してしまうと、１チケットでどこまでできるという見積もりが発生してしまうから取り入れなかったと言われていた。

 

開発にあたるメンバーには、かなりのスキルが必要とされるため人材育成が大変なのでは？という質問に対しては、

徒弟制で行っている。

また、格安で研修生が行うことを選ぶことも可能で、その品質は師匠が担保する。

新人はそれで育って行き、雑用の用なことはさせない。

中途を採用する場合でも、週１ぐらいで半年ぐらいの面談を行って見極める。

とのこと。

 

聞いててため息が出るくらい、徹底している。

ここまで徹底するためには、新しい会社でなくては駄目なのも納得。

ただ、あこがれても既存の会社をここまで徹底したものに仕上げる労力を費やすぐらいなら(不可能に近い)転職転社した方が、本当にやりたい事をすぐ出来るのだろうなと感じた。

 

全体を聞き終わって感じたことは、

永和システムマネジメントさんの「価値創造契約」は、既存の会社でAgile開発に適応した契約形態を考えた場合に生み出された契約形態だと思った。現実→理想という思考かな。

 

ソニックガーデンさんの「ソフトウェアパートナーシップモデル」は、理想の契約形態を想像した上で、現実の受託開発に落とし込んだ結果生み出された契約形態だと思った。理想→現実という思考かな。

 

今の職場がどちらに近いかで考えると「価値創造契約」に近い契約形態を生み出さないと顧客を巻き込んでのAgile開発は難しい。

もしくは、　カンパニー制などであれば、完全に仮想プロダクトオーナーをたてるというのもありな気がする。

今まで全く予定があわず、行けなかったAgile Japan。今年は、参加してきました！

 

まずは、全体の感想。

メイン会場に入って思ったのは、思った以上にスーツが多かったこと。

毎年そうなのか分からないけどペア割り、上司や同僚を誘おうということで、会社関係の方と出席されている方が多かったんだろうか。とても素晴らしいことだと思う。

 

基調講演から出席できたので、その内容も書きたいのだけれどそちらはまだ、整理しきれていないのでまずは午後のセッションからまとめ。

 

・アジャイルな開発からアジャイルな組織へ

@ryuzeeさんのセッション。

http://www.slideshare.net/Ryuzee/agileagile-aj21-b2 

グラフを見せながらの説明だったのだけれど

WFは、開発が後半に集中するため後半になるほどリスクがあがる

Agile は、優先順位の高いものから着手し開発するため前半にリスクがある

とのこと。で思ったのが、

WFは、製品開発の工程全体のつじつまが合わなくなるリスクを担保したいから各フェーズごとにうまくいっているよねということを確認&決定しながら進めようとしているのかなと。

でも、実際は動く物を作らずに各フェーズでの決定が正しいことを証明出来る訳がなく、かつ、色んなステークホルダーに仕様の確認作業などが発生し、だんだん作業が遅れてくる。でもまだ動くものはいっさい出来ていない。

こんな状況で開発フェーズに入った頃には時間もコストも予定より膨らんでいることになる。

本来の意味での設計(コーディング)作業が最も品質と直結しているはずなのに、そこに時間をかけることが出来ない。

ここに無理が生じているのかなと。

 

Agileは、前半に要求の高いフィーチャを持ってくることで、そもそももっとも必要な要求が作られない/遅れるというリスクを早い段階で解消できる。

成果物に対する作った結果いらないや頼んでいないというリスクへのヘッジも出来る。

また、早い段階で実際に動くものが手に入るので要求の高い機能の品質を犠牲にする必要がない。

さらに、見積った結果今後のスケジュールがどう進むかがわかるため再見積もりやリスケなどの手が早くにうてる。お客さんとのネゴシエーションも早く行えるし、ネゴシエーションのための材料も過去のスプリント(イテレーション）から見積もれるので、説得力もあり交渉の余地も生まれる。

ということは、Agileを初めてやったチームで、ベロシティがうまくあがらなくて心配になるというのは実はAgileでやっている証拠だったりするのだと思う。

これを知っているのと、知らないのとでは途中のチームメンバーの不安やモティベーションの維持が全然違うのではと感じた。

 

次に継続的デリバリについて

flickrのサイトに開発のデプロイ状況がかかれていて見せて頂いたけどかなりすごい。

１週間に24人で384回変更して68回デプロイした。

みたいなのが書かれてあった。68回デプロイってデバッグなら分かるけどここでは本番化だからな。すごい。

障害時のリリースが通常より早いのなら、普段からできるはず。

製品そのものをAgileにたもつ。

というのも言っておられた。

TDD, リファクタリング、CIだったりかな。

問題は、これを、お客さんにどう説明するか。

明日食べる物がないのに、数ヶ月先の食べる物の心配はなかなか出来る人はいない。

プロジェクトの開始段階では、明日食べる物はあったわけだから、最初から取り入れる方が受け入れやすいはずなのだけど、プロジェクト初期の１時間もリリース前の１時間も同じ１時間のはずなんだけどなぜか重要度が異なるかのように扱われる。

だからこそタイムボックスをきって、学生症候群もパーキンソンの法則（第１法則）も起こらないようにする必要があると感じた。

 

で言うだけでは意味がないので今後のアプローチだけど、

受託系の会社の場合、当然かもしれないけれど稼働率９９％という目標。

実際これのせいでかなり苦労していて、

プロジェクトとプロジェクトの合間はそんなにうまく埋まらなかったり必要としている人材がプロジェクトが始まったときに空いていなかったりするけど、数人日を惜しんで他の人材を加えたり先行着手したりということをやっている。

でも、その合間にScrumの勉強会、WorkShopを開いて皆が本気だしたらこんなもんじゃないよねということを思い出してもらおうと思う。

稼働率はいままでより良くないのに利益率はさがってないということが起きて正のスパイラルが証明できると思う。

チームを全体最適化させると自己組織化する

頑張って共有し合えるチームを作ろうと思う。

残りは後日。