Ryuzee.com

ということで、2/26に明星大学で行われたオープンソースカンファレンスでTracを使ったアジャイルな開発プロジェクトの可視化について話をしてきましたので資料を公開します。

ご不明な点等ありましたらコメントいただければと思います。
また発表の際は、会場が完全に満席になるくらいお越しいただいてありがとうございました。

マイク・コーン氏のブログ記事のSeparate Estimating from Committingより適当訳。

多くの組織における根本的かつ共通の問題は、見積もりとコミットメント(約束)が同一のものとして扱われていることである。
ある開発チーム(アジャイルか否かに関係なく)は、顧客が望むもの一式を納品するのに、利用可能なリソースを踏まえて7か月かかるだろうと見積もりした。チームメンバーはこの見積もりをマネージャに提出したが、マネージャは見積もりを部長に、部長は顧客に知らせてしまった。そして、いくつかのケースにおいては、その見積もりが、チームの「伸縮可能なゴール」を奪ってしまうことになる。

ここでの問題は、チームの7か月という見積もりが合っているか間違っているか、ではない。問題は見積もりがコミットメント(約束)に変化してしまったことだ。「我々は7か月かかると見積もりました」という言葉は「我々は7か月以内に終わらせます」という言葉に(誤って)変換されてしまう。見積もりもコミットメントも重要だけれども、それらは別々のアクティビティとして見られるべきなのだ。

私は今晩、娘の水泳に迎えに行く必要があった。私は娘に何時に終わる(我々は泳いで、シャワーを浴びて、家に帰る準備が出来た、というのを終わりと定義している)のか尋ねた。
彼女は言った。「たぶん5:15には準備できる」これは彼女の見積もりだ。もし私が確実に約束(決めた時間に外で待っててよ。じゃないとそのまま帰っちゃうよ、なんて場合)できる時間を尋ねていたら、彼女は練習が長引いたとかコーチの時計が5分遅れていたとか、シャワーが行列していたとかいうような問題が発生した場合の対応を含めて、たぶん5:25と答えただろう。
約束できる時間をきめるために、娘は見積もりをした。でも彼女は見積もりの時間をそのまま伝えるのではなく、約束できるデットラインに変換するべきだったのだ。

見積もりをコミットメント(約束)にしてはいけない。見積もりとコミットメントの違いについて覚えておき、2つのアクティビティは分離し、必要に応じてマネージャや顧客を教育しよう。
私は「Succeeding with Agile」という私の新しい本で見積もりとコミットメントについてより詳細に説明している。

スケジュールの話だけじゃなくて、コストの話も同じだね。
上の話はアジャイルだろうがウォーターフォールだろうが関係なく気にしておく必要がある。
社内のちょっとした見積もり依頼が、気が付いたらそのままの数値で顧客に出ていた、とかは良くある話。
間違った約束や契約は、チームも顧客も会社も不幸にする。

ということで、2/26および27にオープンソースカンファレンス2010春が開催されますが、Shibuya.tracのセッションでちょっと時間をもらって、Tracを使ってAgileプロジェクト(Scrum)を実施する方法について話す予定です。

2010-02-26 (金) プロジェクト管理Webアプリ「Trac」をより便利に使う方法、教えます 14:00～14:45

以下内容のちらみせ。
Agiloの日本語化をした自分自身が、ドッグフーディングで自分が関わるプロジェクトで実際に利用していますので、そこで得られた知見も含めてお伝えしたいと思っています。

時間がある方は是非お越しください。

Scrumのアンチパターンや間違ったScrumについて書かれたスライド。耳が痛いところもあったりする。

一例をあげると

• ゴールの無い、魂のないScrum
• プラクティスのつまみ食いと、プロセスの早すぎる最適化
• プランニングの停滞
• コマンド・コントロール型のマイクロマネジメント
• 個人による誇張
• リスクマネジメントの欠如
• オーバーコミットメントの危険なサイクル
• 改善の遅延

スライドの最後の方に書かれていた言葉は素晴らしい言葉なので紹介。
「あなたがアジャイルをやっていて楽しくないのなら、それは正しいやり方でやっていないからだ！」

Retrospectives | 7 Secrets of my Retrospectivesより。

1. チームはスプリントの間ベストを尽くしたと信じよう
2. 最初にファクトデータを集めよう
3. 議論するのではなくて、ファシリテーションのテクニックを使ってファクトデータを集めよう
4. まずは良い雰囲気を作ろう
5. 振り返りの内容を承認しよう
6. この先改善するために出来ることを見つけるためのブレストのセッションを設けよう
7. 未来に焦点を当てよう。チームが改善すべき問題とスクラムマスターが改善すべき問題を分離しよう

僕が良く言うのは、スプリントの結果はチームとしての結果なのだから、特定個人の問題を追及し(すぎ)ないこと。
チームとしての問題を個人の問題に付け替えてしまうと、個人は問題の隠蔽を始めてしまうケースがある。Agileの基本理念の1つに「オープンであること」があるが、それがなくなると、チームとしての力が結集できなくなる。
また振り返りのファシリテーター役は、チームを非難しないことも大事だ。チームとしての結果はスクラムマスターが責任を持てば良く、そこでスクラムマスターがチームを非難してしまうのは、自分が問題や妨害の解決、ファシリテートが出来ていなかったということだ。

アジャイルって受託開発との相性が最悪な気がするより。釣りっぽい記事な気もするんだけど。

SIerから見たアジャイル

工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。

要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。

今の日本のSIerのモデルは”まだ”建設業みたいな多重階層の構造であることは間違いない。
収益性については、一次受けのSIerは少ない要員で沢山のプロジェクトを外注使って回すことでレバレッジかけて、一人あたりの売上と利益を高くしている。
でも、もう気付いている会社も沢山あるんだろうけど、このビジネスモデルって、名前で仕事が取れる時にしか有効じゃないんだよね。

大手のSIerに発注した際によくあるのが、打ち合わせに一次請けの社員は1人くらいしか来なくて、残りは全部外注がやっているパターン。お客さんからすれば、マージン一杯抜かれて高い金払うくらいなら外注さんと直接契約した方が安くて良いよね。
残念ながらレバレッジかけまくってる会社からは技術力はどんどん無くなっていって、そのうち見捨てられてしまうんじゃないの？

そう考えると、分業のモデルは、工程ごとの分業ではなくて、チームの中に何人外注さんを混ぜるか？って方向が正しいのだと思う。
自社の要員で全部開発できるけれども、平均単価を下げるために外注さんを混ぜるのと、開発できないので外注さんに任せるのでは、自社の経営におけるリスク度合いが全く違うよね？

顧客から見たアジャイル

アジャイルが上述のやり方だと仮定すると、僕が顧客側にいたらこういう質問をすると思う。
* 最終的なリリース日はいつになるの？
o 意思決定を延ばすってどういうことなの？
o ウチはこの予算でいつまでにやって欲しいんだけど、それ守れるの？
* イテレーションって毎回納期もスケジュールも違うの？
o そのやり方でウチにメリットあるの？上に説明しにくいよそれ。
* ある機能の開発中、別の機能に要件漏れがあったらどうなるの？
o Aという機能を要件→テストまで回してOKだとする。
o でもBという機能の実装中にAの変更が必要なのが発覚した。
o これどうすんの？手戻りして直してくれるの？

若干アジャイルに関して誤解があるような気がする。
アジャイルだからリリース日を決めない、ってことは無い。
Scrumであればスプリント毎にレビューして、場合によっては本番にリリースするし、XPだって数イテレーションごとにリリースする。
XPなんかは最初にリリース計画もするし。
意思決定を延ばすのは、実装する機能の優先度に関わっていて、重要なものから意思決定していけば良いということ。逆にあってもなくても良い機能を今意思決定しても仕方ない。ビジネス上の価値の実現がシステム構築の目的だから、その価値の実現に大きく寄与するものについては、ギリギリまで判断を待ちたいと思うよね。
あと、イテレーションやスプリントと呼ばれる時間は、原則として一度プロジェクトを始めたら固定にするので、今回のスプリントは2週間だけど、次は1か月ということは無い。よく「でもこの機能の開発はスプリントに収まらないし？」とか聞かれることがあるが、そういう場合はストーリーの分割をすれば良い。大きすぎる項目は見積れていないのと同じだし。
手戻りについては、そもそもアジャイルって変化が起こることを想定しているので、機能や要件の漏れがあれば、重要度と照らし合わせて次のスプリントで実施するだけだ。
そのコストはどうするのよ？というのは契約次第だけど。（契約の話は以前書いたので、http://www.ryuzee.com/contents/blog/2932 を参照）

で本当に相性悪いの？

ケースバイケースなんだと思う。

顧客が、システムを「作ること」に価値を置くのか、「作ったものから得られるもの」に価値を置くのか、なんだと思う。
予算主義、丸投げ主義な顧客にはアジャイルは向いていない。あとは意思決定が苦手な組織や縦割り組織にまたがる案件とかもダメ。
こういう顧客の場合、意思決定のロジックがビジネス上の価値と関係が少なく、決めた通りにやることが評価の対象になってしまったりする。
一方で自分達で投資対効果を検討できたり、リリース時期によるビジネス機会の拡大/損失が理解できる顧客の場合は、アジャイルは向いている。

なお残念ながら、「作ること」に価値を置くタイプの顧客の案件をアジャイルでやって失敗したこともある。

5 min on Scrum | Retrospectives| 10 Ideasより。抜粋。

個人的には、振り返りは近所の緑の多い公園にいってやったり出来ると素晴らしいと思う。

1. 振り返りの形式を変えて行こう。新しい質問を追加したり、違うテイストでやってみたり。
2. オフィスの中じゃなくて、公園とか庭で振り返りしよう。
3. NLPに関する本を読んで、本に記述されている表現方法を使ってみよう。(訳注:[1])
4. 質問することを学ぼう!。
5. 振り返りの最後に、次回の振り返りをどうやって良くすることが出来るかを尋ねよう。
6. スプリントで作ったものを持ってこよう。(訳注:[2])
7. チームに事前に開催通知を送ろう。そうすればチームは振り返りにデータを準備してくることができる。
8. ストーリーワークショップを振り返りとして実施しよう。90分で、直前のスプリントに関する短いストーリーを書き、映像を作り、上映しよう。
9. 未来予測のワークショップをやってみよう － 将来の2011年について振り返りをして、どうしたら2011年をより良く出来るかを考えてみよう。
10. 会議を生産的にすすめる方法について扱う研修に行こう。そしてそこで学んだことを取り入れよう。

訳注。どっちもドイツ語なので後で調べる
[1] http://agilesoftwaredevelopment.com/blog/peterstev/start-trust-start-retrospective
[2] Neurolinguistisches-Programmieren-Kommunikation-personliche-Entfaltung NLP,

Have Fun With Agileより。これ良い記事だと思う。

要約するとこんな感じ。

• 働くときに楽しいことは言うまでもなく重要だ
• Agileな開発手法はチーム中心のモデルで、良いチームを作るために色々な手法がある
• よくやるのが、業務終了後にみんなで飲みに行ったりすること。でも個人の時間使うし強制は出来ないよね
• 他にはチームみんなでゲームするって手もある
• チームを作るときにゲームをする、っていうのはお互いを良く知るためにも役に立つ
• チームのメンバーは、学習と同時に楽しむことで、より賢くなれる。
• チームは自分たちが楽しんでリラックスしていれば、多くのストレスを抱えることもない。リラックスした脳はより生産的だ
• 楽しんでやること(ミーティングだったり、振り返りやデイリースクラムを楽しむこと)は価値があることだと思う
• プロジェクト予算でルービックキューブとか他のゲーム買ったりしても良いんじゃない？

Googleは社内にバランスボールとかビリヤードがあるし、国内の会社だって、会社でゲームやったりしている会社はネットサービス系の企業には結構ある。
そう考えると上の話も納得できるんじゃないかな。

開発者のための無償のチートシートの１つとして、Scrumに関する資料が公開されている。
入手は下記から。
http://refcardz.dzone.com/refcardz/scrum
※なお入手の際には無償の会員登録が必要だ。

内容はA4用紙約5枚分で、

• スクラムとは
• スクラムでの役割
• スクラムでの会議
• スクラムで利用する道具
• スクラムのスケーリング
• 関連情報等

という内容になっており、コンパクトな説明でありつつ十分な内容をカバーしている。
英語で書かれているが中身は簡単なので、是非一度読んでみると良いのではと思う。

 

日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有