#xpfes12

TDDとスクラムの事例がお目当てでXP祭り関西に参加してきました。

 

アジャイル開発における計画と管理〜アジャイルのプロジェクトマネジメント〜

システムインテグレーター　梅田弘之氏

概要は、アジャイルでもプロジェクトマネジメントは必要だという話。
ご自身が取締役社長ということで経営者からみてアジャイル開発がどう見えているのかという内容でした。

ウォーターフォールを敵視するな

基幹業務などでは、ステークホルダも多く色々な調整を行ったりしていれば、要件定義に３ヶ月かかってしまうこともあるわけで、その辺りを理解する必要がある

たしかに、基幹業務などでは億単位の金額が扱われたり関係する部署がとても多かったりでヒヤリングするのにも結構時間がかかると思う。実際、中には色々な人がいて（そもそも利用者が物理的に遠かったり）すんなりヒヤリングできるわけでもなかったりするし。

ただ、要求を決めるためにかかった３ヶ月がどういった内容かにもよるかなとも思いました。

一度に要求を決めようとすると要求を決める関係者それぞれが少しずつ返信が遅くなるだけで結構な待ち時間ができて、それが積もるとそれなりの時間になり結果的に要求の決定が遅れるという事態の原因の一つになるのかなと。

ウォーターフォールの場合、フェーズ毎に作業が進んでいくため後工程になればなるほど手戻りの発生する箇所が増える。
それを意識するあまり、仕様の決定が遅れかつ、納期がまだまだ先なため決めきれないというのがあると思う。
そこに、タイムボックスを適用することで要求を決める人も全ての要求を要求定義のフェーズで決めきらないと駄目だと思っていたのが、この機能についてだけ決めてくださいに変わるので、要求分析やヒヤリング対象が絞られて要求が決めやすいのではないかと思う。

 

ただ、適用が難しいかなと感じるのは、実際のリリースはずいぶん先なのに１イテレーション（スプリント）の終わりを本当のリリースと同じように扱えるかというところ。
要求を決める人が今回はスクラムを行うと同意している場合は協力的になってもらえる（もらえないと困る）と思うが、要求を決める人が加えられずにスクラムを行う際のリスクはこのタイムボックス内に要求を確定してもらえないというところかなと思う（アンチパターンだけど）。

ウォーターフォールは、売れる物を作るのが苦手

梅田さんのところでは、パッケージ製品の開発が主な開発でその際パッケージ作成とそのパッケージをお客さんに導入する開発は別と仰っていた。

パッケージ作成は、内部の開発だからハンドリングがすべて会社でできるためアジャイル開発向き
ウォーターフォールは売れる物を作るのが苦手

たしかに自社製品を作るのに、ウォーターフォールでは作れない。

お客さん向けの仕事にどうアジャイルを取り入れるかが最大の課題でありチャレンジ
アジャイルでやっても作るものによって犠牲にすることが異なる。
プロダクト開発は、スコープを犠牲にできる。
請負開発は、コストを犠牲にするしかない

請負開発とプロダクト開発で犠牲にするものの違いは全くその通りだと思う。

この違いは、

プロダクト開発はスコープを犠牲に出来るけれど、犠牲にしたスコープによって製品が売れるかどうかのリスクを自社で追う必要がある。

逆に請負開発はコストを犠牲にするけれど製品が売れるかどうかへのリスクは自社で追う必要はない（発注側で仕様を決めてしまうから。作った物は売れてほしいけれど）。

どのリスクをどちらが負うかによって、犠牲に出来る物と出来ない物が変わってくる。

 

請負の際にいつも確認するのは
「納期は最大どこまでのばせますか？」

ここを聞いておかないと仕様変更・追加に対してコストをかけたとしても残業や休出、過剰なメンバ追加しかコストをかける時間がとれなくなってしまうため、プロジェクトが遅れ始めるとひどい生活が始まってしまう。
請負開発では、コストを犠牲にするしかないけど生活は犠牲にしたくないというのを、死守できるかどうかは納期が最大どこまで延ばせるかにかかっていると思う。ここで見積もりも合わず、納期も絶対延ばせない案件だと受けないか最悪工数ベースの契約に持って行く場合が多い。

TDDサイクルを加速する技術たち

@irof氏

irofさんのセッションに参加するのは初めてで今回一番楽しみにしていた。
最初にしっかり「京都アジャイル勉強会」の告知もして頂いた。ありがとうございます。

以前アジャイルサムライ読書会in京都の懇親会で、テスト版９７のこと（あのときはこっちが本編だったな）を教えて頂いてそれ以来自分の中でのTDDへの最初の壁が取り払われた。それから、テストと並走してプログラミングする毎日を送ってます。

前後のテーブルと会話する形式だったので、メモしきれなかったのだけれど残ったポイントは

変化しつづけるものは変化に強い

テストと合わせてjenkinsを使っているとこの言葉は自分的には納得。実際救われたことは何度もある。

思った通りにうごくコードをかく技術がTDD

通常は、書いた通りに動く。だけど、思った通りにうごくを実現するためには、テストが必要。

リファクタリングの終わりどころは次のRedが一つになったら終わり

仮に一つ修正加えたらRedになる箇所が、複数ある場合はまだリファクタリングできるとのこと。

どれも禅問答のような言葉だけど、話を聞いているとストンときます。

きっと自分で気づかないと意味がないから自分で気づきやすいように考えてもらって結果を共有して、自分の意見を述べるというセッションにしたのかなと思った。

例え悪いかもしれないけれど、倒幕するときにも草の根運動のようにこのような議論の場が持たれて最後は大きな仕事に結びついたように感じた。

なので、チームへの啓蒙の第一歩は、自分がテストを書き続けて周りにその良さを広めることでしか実現できない（もしくはirofさんのセッションを受ける!?）と思うので、やっぱり自分が書き続けて周りにTDDの良さを感染させるしかないのかなと思いました。

大規模なゲーム開発をスクラムで

田口 昌宏氏

大規模なゲーム開発で実際にスクラムを取り入た際の事例紹介でした。

面白さを見積もり時に組み込むことは難しい

スクラムに取り組んだ際の動機だったと思う。

午前の梅田さんのお話ともリンクするのだけれど、試行錯誤する開発についてはスクラムはとても適用しやすい。

１スプリント２週間で隔週水曜日にスプリントプランニング
火曜日にレビュー、お菓子付きショーケース

懇親会に参加できなかったので、聞けなかったのだけど水曜日にスプリントプランニングを設定したのはなぜか聞きたかった。

田口さんのお話を聞いていて一貫して思ったのが、まずやってみる。
それで問題が出たら、その問題を解決するために対処する。それがスクラムのツールでカバーできるところはツールを導入し、その導入もただ入れてみるのではなく実際にチームに適用するように随所に工夫が施されていた。
（コミュニケーションに問題出たので朝会導入。ただし２チームで朝会の開始時間をずらして実施。それぞれの朝会の内容を共有できるようにしたなど）
スライドの写真を見ていて思ったのは、参加している皆が本当に楽しそうにやっているところ。

朝会やタスクボードでかしこまったミーティングがなくなった。

確かに、かしこまったミーティングがあるところは日常的にコミュニケーションに問題がある。
プロジェクトが遅延してくるとミーティング多くなるのはこのせいかなと感じる。日頃からコミュニケーションがとれていれば、遅延してきたからといってミーティングを増やす必要はないはず。

３〜４時間のプランニングで制度の高いものが出来る

これは、プランニングポーカーしているととてもよく思う。自分はそこででた意見を実際に見積もりや開発時のチェック項目としてあげたりしている。
京都アジャイル勉強会でもプランニングポーカーをしていると、自分が考えていなかった意見がぽんぽん出てくるのですごく参考になる。

10名超えると朝会で話す内容が薄くなったので、チームを分割。スクラムマスタも２名に導入
壁は情報発信継続力がすごいし、壁は解像度が高い
ショーケース時の品質は、落ちたらアウトぐらいにしている。全テストを通らないと駄目とかではない

などなど。

参考になることばかりだし、すぐに自分も取りいれて自社ではどうなったのかを共有したいと思うことばかりでした。

もっと色々聞きたかったのだけれど、懇親会には参加できなかったのでまたどこかでぜひお話を聞きたい。

 

まとめ

スクラム開発を取り入れている人の話を聞いていると、「巻き込み力」とでもいうのか回りの人をその気にさせるのがとてもうまいなと感じた。

スクラムに限らずだけど、知→無知への提案はなぜか上→下のような関係になりやすい気がする。普段からの関係性がとても良好なので提案しても上→下の関係にならず対等に論じあえるのだと思う。

日頃から傾聴することが大事だとつくづく感じた。

京都アジャイル勉強会について

アジャイルサムライ読書会in京都が終わり、引続きアジャイル導入を考える方達（自分も含め）のための勉強会を京都で行うということで、そのまま「京都アジャイル勉強会」という名前で、人も内容もほぼそのままに始まりました第一回。

 

アジャイルサムライは読んで終わりでなく、実践して経験値を積むときの指南書となる本だと思うので「京都アジャイル勉強会」では、アジャイルサムライにでてくる数々の手法を本番前に何度も経験し失敗し、本当に身体で覚えるまでやって本番は楽に乗り切ろうという試みのもと行っています。

 

もちろん既に本番をやっているけれど、経験値を積みたいという方も大歓迎(実際に数名参加されています）。

 

第一回となる今回は、「色々試そうプランニングポーカー」と題してプランニングポーカーで色んなことを試して、試した結果を皆で考え共有しようということで行われました。

実践

参加者が、１１名だったため、５名、６名の２チームに分かれて各藩で、プランニングポーカーの見積もり対象となるシステムを決めてそのユースケース出しから入りました。

私の藩は、「オンライン上の年賀状作成ソフト」です。

 

そこから、１０こ程度のユースケースを考えて、そのユースケースに対して見積もりを行いました。

 

最初に手持ちのカードは、１、３、５、？の４枚。

３を基準値として「仕様が大きくぶれにくく規模が大きくも小さくもないユースケースを３としました」。

その後、それ以外のユースケースの見積もりを皆で行いました。

 

４枚で見積もりした内容を今度は、１、２、３、５、８、？の６枚にして行い枚数が増えることによって、結果や思考がどう変わるのかを試そうという試みでした。

 

実際は、１回目の見積もりの内容が本当にシステムを作るかのように議論が熱くなり２回目の見積もりは駆け足となってしまったため詳細に比べることが出来なかったのですが、１回目で見積もりできたユースケースに対してのみ２回目の見積もりを行ったとところ面白い結果になりました。

 

１回目で同じ３を出していた人同士が、２回目では、２、５になる。

１人は、２が入ったことで１よりは大きいけど３よりは小さいから３を出していたのが、２が出来たことで２に変わる

もう１人は、８が入ったことにより３よりは大きいけど５よりは小さいが５をだすとそれ以上大きい値がなくなるため３としていたけれど、８が入ったことにより５に変わる。

ということを考えていました。

 

だしたカードが同じだからといって同じ判断でそのカードを選んだとは限らないということが分かる。
ということは、見積もり時のユースケースの粒度によってはカードの枚数を６枚程度で行いあえて意見が割れるようにしてみることで、チーム内の意見を引き出し安いと感じた。

 

あと面白かったのは、説明しているうちに意見が変わってしまうことが多々あったこと。

 

考察

実際の見積もりだと見積もりが合わない場合に、各機能についてどうしてこんなにかかるのかということを延々と話し合い結果数人日とかひどいときには数時間の削減を迫られたりするのだけれど、実際数ヶ月前に数人日や数時間の想定をしたところでいざ作業に着手したとたんに、あれが必要これが必要とかであっという間に数人日オーバーになっていく。

 

相対見積もりだと議論になる箇所が、見積もり工数ではなく仕様や前提条件になるため不毛な工数削減に合いにくくそもそも、詳細ではないくせに詳細な話になることが防げるということを改めて実感した。

 

また、今回ユースケースについてはあまり時間をかけずに作成したため、内容についての前提条件が確定していなかったこともあり、実際にカードを出し合ってからの議論が長くなった。

見積もりを行う前に、ユースケースの前提条件や理解度を合わせておいた方が工数の決まっている本番では良いと感じた。

 

余談

CSMの研修でプランニングポーカーを行った際も、仕様について１５分ほど話し合う時間がさかれたと思う。

ただ、その時面白かったのは出された仕様をチームで検討する時間を与えるので、仕事を受けるかどうか答えてくれというもので、検討後チームの代表が前に言って講師に仕様を受けるかどうかを聞かれた際にチームの代表の仕様についての質問はいっさい受けずに、とにかくYesと言わせようとしていたこと。
で、あまりの講師の圧力になし崩し的に大半がYesと答えてしまっていた。

ここでは、絶対に圧力に屈しては駄目で即席の見積もりや、安請け合いは結局交渉の条件に使われてしまうという教訓だったと思う。詳しくは「リスバーガー」で検索すると分かる。

 

次回も引続き「色々試そうプランニングポーカー」をやります。