#xpfes12

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

この違いは、

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

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

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

 

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

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

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

@irof氏

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

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

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

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

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

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

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

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

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

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

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

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

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

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

田口 昌宏氏

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

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

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

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

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

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

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

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

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

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

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

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

などなど。

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

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

 

まとめ

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

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

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