今まで全く予定があわず、行けなかった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を開いて皆が本気だしたらこんなもんじゃないよねということを思い出してもらおうと思う。

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

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

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

残りは後日。