スクラム道フルブーストに参加してきました。 #scrumdo
先週金曜日は品川シーサイド：バンダイナムコ未来研究所で開催された「スクラム道フルブースト」に参加してきました。SODEC行ったその足でそのまま参戦。既に体力残量ゼロでしたが、オレ自身「スクラム道 | Doorkeeper」は初参戦、しかも普段なら開催時間、開催場所的に絶対参加できないイベント、SODECに行っていたからこそ参加できたので、そこは気合で乗り切ました。押忍！
バンダイナムコ社屋。外観工事中だったので、気付かず一回素通りしちゃいました。
社屋入ってすぐの様子。滝が流れてたりゲーム筐体がいっぱい並んでたりと、普通の会社じゃない感じ満載。
セミナーホール？ 映画館みたい！ 座席にそれぞれテーブルも付いてて使い易い！！バンナムさん会場提供有難うございます！！！
「スクラム道 | Doorkeeper」はもっと上手くアジャイル開発をしたいという思いから生まれたコミュニティとのこと。普段は
という3つの柱で活動されているようです。今回のフルブーストはそのうちの「1.スクラム道場」をピックアップ、初心者向けに公開したもの。普段の「スクラム道場」はテーマを決めてそれに対して少人数でディスカッションするという形式を取っているそうですが、それだと少人数制ゆえにハードルが高いし、どんなことをやっているか伝えるために「普段のスクラム道場をステージ上で再現する」ことを主旨としているそうです。なかなか無い形式の勉強会ですね。「スクラム道場体験版」って感じでしょうか。この日扱うテーマも、全て以前のスクラム道場で一度扱ったものばかりだそうです。
まず最初に、テーマ設定。運営チーム5人の中から、オーディエンスが聞きたい発表者を選びます。
西村直人さん。テーマは「インセプションデッキ」
永瀬美穂さん。テーマは「スプリント計画ミーティング」
高橋一貴さん。テーマは「スクラムマスター」
吉羽龍太郎さん。テーマは「スプリントバーンダウンチャート」
今給黎(いまぎれ)隆さん。テーマは「プロダクトバックログ」
トーナメント形式で、オーディエンスの挙手の多かった人が発表することに。
結果、今給黎さんが発表することに決定。厳正な投票の結果…というよりは、単に直前の「裏切り者」「汚い一票を」*1の自己紹介がオーディエンスの興味を引いたものと思われ。この日このタイミングで喋らせにゃ！みたいな。
そんなこんなでプレゼンが始まります。今給黎さんが発表したプレゼン資料と、プレゼン中にオレが取ったメモは以下のような感じです。
スクラム道場.07
View more presentations from Takashi Imagire
― メモ ―
- プロダクトバックログ = 価値が優先順位付で具現化されたもの。「何を作るか」を集約。
- → ユーザー体験
- 「○○○(人名、立場、役職)として○○○(機能)が出来る。何故かというと○○○(ビジネス価値)だから」
- INVEST
- 依存しない(独立)
- 交渉可能(後から交渉できる)
- 価値がある(×：「どうしてこの機能作ったんだっけ？」)
- 定量化可能(ダラダラ作らない)
- 手ごろな大きさ(数日〜)
- テストできる
- バックログに大切な事
- Ready-Ready 準備された状態にする→ベロシティを増す、迷いがなくなる = 速さが増す
- Done-Done 標準化された完了条件
- プロダクトバックログ
- 導出されるもの = 期間
- リリースバーンダウンチャート
- 項目とチームの現在の状態
- 優先順位のバランス
- プロジェクトの状態を見て
- 価値
- 時間
- リスク
- 無駄
- プロダクトバックログの作り方
- 折を見て改善
- 価値の単位を区切る
- →成果物を確認
- バグ
- →別のユーザーストーリー
プレゼンが終わると早速ディスカッションが始まります。オーディエンスの中から
- 今のプレゼンに質問がある
- 今回のテーマに関することで、今実際に悩んでいる・困っていることがある
- とにかく出たい！喋りたい！
人が募集され、壇上に上がります。ちなみに会場は「壇上に上がりたい人」「話を聞くだけでよい人」で着席の段階で既に分かれていますので、「壇上に上がりたい人」エリアから優先的に選出されました。あとは運営チームから2名ほど。全体で10名程度が壇上に上がりました。
ちなみに、マイクロソフトさんからプランニングポーカーの差し入れがあったらしく、壇上に上がった人全員にプレゼントされていました。
パーキンソンの法則は改善できる
― メモ ―
- パーキンソンの法則 = 予備日は使い果たされる
- →Scrumはポイント、改善できる？
- チームでやると改善できる
- 直せないなら全体が緩んでいる
- 個人ほど起こらない
- ふりかえりで洗い出す
- ストーリーポイント = 個人のスキルに寄らない → 正確
- 繰り返しスプリントを回しているとおかしい状態が露見できる
パーキンソンの法則（パーキンソンのほうそく、Parkinson’s law）は、1958年、英国の歴史学者・政治学者シリル・ノースコート・パーキンソン（英語版）の著作『パーキンソンの法則：進歩の追求』、およびその中で提唱された法則である。具体的には、
- 第1法則:仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
- 第2法則:支出の額は、収入の額に達するまで膨張する
の2つからなる。
お恥ずかしながら「パーキンソンの法則」という単語をこの時初めて知りました。要は「スケジュールにマージン持たせて引いても、エンジニアはそれを使い切っちゃうよ」という意味らしいです。ギリギリまでリファクタリングしてたり、ノンビリ開発してたり、理由は様々だと思いますが。
確かに工数をポイントであらわしていると具体的な日数はエンジニアには見えない(把握しづらい)から、マージンを使い果たす、ということ自体が無くなるでしょうね。ふりかえりで「ノンビリやり過ぎじゃね？」という話も出てくるでしょうし、ペアプロやればサボりようがないし。防ぐ手段はいくつかあるんじゃないかと思います。
個人的に思ったのは、そもそもとして「パーキンソンの法則の発生を本当に防ぐ必要があるのか？」ということ。チームがオーナーとコミットしたスケジュール(予算)と品質で開発できているのであれば問題無いわけだし、別に防ぐ必要無いとオレは思うんですよね。
もちろん、「後で予想外に工数を使ってしまうストーリーがあるかもしれないから前倒しでやりたい」「サボり許さない！」「開発スピードが上がっていることを実感したい(←？)」などなど思いは色々あるのでしょうが、それが育成目標なのか単なる感情論なのか、それともっと別の思惑から来るものなのか、そもそも防ぎたい理由をハッキリさせた方が良いと思います。でないと「やることはちゃんとやってるのに何で責められにゃならんのだ！？」とメンバーが疑問や憤りを感じた時に、説得する術がなくなる気がしますね。
そういえば「7人のアジャイルサムライ」の時@TAKAKING22さんが、「各スプリント毎をドラクエのボスキャラみたく仕立てたいんですよ。で、ストーリー片す度にそのポイント分ボスキャラのHPが減ってく、みたいにしたい。そしたら倒したくて楽しくて、ついついドンドン開発しちゃうと思うんですよね。」って言ってました。サボりを防ぐとかいったネガティブな発想よりは、@TAKAKING22さんのようにポジティブな発想が望ましいんじゃないですかね。
ポイント算出したものが実際開発したものとズレたら？
― メモ ―
- こだわる必要はない
- チームで認識があっていれば問題ない
- みんな知ってる
- ベロシティが上がってるのを見たい
- だけど毎回基準がずれると測りにくい、困る
プランニングポーカーで工数ポイントを見積する際には、最初に基準となるストーリーを決めて、それより大きいか小さいかでストーリーごとの工数ポイントを決めていきます。ちなみにオレは普段は最小値「2」と最大値「8」を決めて三点見積でやってます。
この質問は「そもそも指標とすべきストーリーのポイントが、実際に開発を始めると全然想定のポイントと異なる工数を要した。この場合全体の工数ポイント設定が狂ってしまい、他のスプリントと比べた際にベロシティの比較が正しくできない」というものでした。質問者の意図としては「ベロシティをスプリント毎に比較して、自分たちが成長している度合を可視化したい」というのが前提としてあったようです。
それに対する意見としては、「そんなに気にしなくていいんじゃないの？」というのが大半。ポイントに関してはスプリントごとにリセットされるし、チームではひとつのストーリーが狂っても狂ったことまで含めて共通認識があれば問題ない、などなど。ベロシティについても、そもそも成長度合いを測る為のものではないし、成長度合いを見たいなら別の指標を用いた方が良い、という意見がありました。
確かに「全く同じストーリー(機能開発)」というのがあり得ない以上、単純比較はそもそもできませんし、相対見積という感覚に基づいたものである以上、ある程度「ブレ」はあるものとして受け入れていくしかないでしょうね。成長の度合いを見たいなら、別の指標を探した方が良いというのもその通りだと思います。オレはベロシティを「期限内に開発を終えられるかどうかの指標」とだけ認識しています(間違ってたらゴメンナサイ)が、ベロシティを人事評価に使うのは難しそうだなぁ、と元中間管理職の立場から一言申したいっすね。
でもまぁ、個人的にはベロシティを成長度合いの基準にしたいというなら、別にしてもいいんじゃないかと思います。可視化できるから分かり易いですしねぇ。それでチームのモチベーションが上がるならやるべきでしょう。本来の使い方がきちんと出来ていて、その上でチーム内限定で別の意味を持たすのはアリだと思います。ただ、メンバーが別の案件やチームに行ったときに、間違った認識を持ったままだとまずいので、「これは本来の使い方じゃない」というのはしっかり覚えておいてもらった方が良いと思います。
「初めてスクラムをやるチームに良い物を渡した」の「良い物」の基準って？
― メモ ―
- チームにあった情報
- INVEST
サラッと今給黎さんが回答して終了。「初めてのスクラム開発」みたいな薄めの教本があるといいですね。今だと「アジャイルサムライ
チームが未体験の技術要素に対する優先度付けは？
― メモ ―
- ちょっとトライする
- 最優先でタイムボックスを区切って挑戦
こちらもサラッと。プロジェクトの開始前、もしくはプロジェクトの冒頭で技術検証フェーズを設けるというのが常套手段ですね。事前にプロトタイプとか開発できるともっと良いですけど。
大規模プロジェクトの見積をどうしたらよいか？
― メモ ―
- ストーリーが膨大、全部でどの程度か知りたい
- →大雑把にやる、大体で見積もる
- →もっと大きなくくりで見積もる
- →1/3だけ見積もる
この質問は「案件が大規模なのだが、予め全体の工数規模を提出しなくてはいけないので、毎日プランニングポーカーを繰り返しているが一向に終わらない。助けてほしい。」という切実な願いから来るものでした。何のために見積もらなくちゃいけないのかは忘れちゃいました、たぶん予算とか稟議とかの関係じゃないですかね。
これに対して出てきた意見は上記メモのような感じ。YAGNI*2にも反するので、大まかな全体工数が分かるようにすればいいのでは、という意見が大勢でした。
これ、アジャイルとかウォーターフォールとか関係ないですねぇ。ウォーターフォールだと大日程計画作成に該当すると思うんですけど、細かく見積もってもブレがどうしても生じますし、稟議で予算を出すならギリギリスレスレを狙うのは逆に危険ですから、ちょっと大きめに見ておくのがいいんじゃないでしょうか。
5分間の休憩。休憩中も議論は続く。
休憩明けて2ndラウンド。希望者を新たに募り先ほどからメンバーを入れ替えてディスカッションを再開します。2ndラウンドからツイートの様子がスクリーンに表示されるようになりました。
プロダクトオーナーがスクラム初心者の場合、良い方法は？
― メモ ―
- 上手く行かないなりに1回スプリントを回す
- 割り切り
- 大項目、中項目など言葉を変えてあげる
- プロダクトオーナーとチームの用語のマッピング
割と聞いていると、程度の差はあれ「プロダクトオーナーには初心者だろうがなんだろうがちゃんと『スクラムのプロダクトオーナー』になってもらう」という考えの人が多かったように感じます。…この考え方、凄く違和感があるんだけど、オレだけか？
要は「プロジェクトに新しい人が入ってきてそれまでの開発手法は知らない」「その新しい人がビジネスの詳細を最も把握している」というだけで、これまたアジャイルもウォーターフォールも全然関係ないと思うんですよね。だったら段階的に自分たちの開発のやり方を覚えて貰うだけで、いきなり十全Scrumにしようとすること自体がまず無理だと思うんです。特にその人がビジネスを抑えている人であれば、彼が仕事できないとものづくり自体が始まらないので、彼が把握できないやり方を押し付けてもしょうがない。スケジュールに余裕があれば事前教育やトライ＆エラーでやればいいけど、そんな余裕が無いのなら別の手段を考えるべきでしょう。
つまり「チーム側がある程度折れて新しい人に合わせる」。サッカーや野球であれば監督が変わればプレイスタイルが変わるのは当然で、サッカーや野球の範囲で、選手たちの能力の範囲で合わせるのは、別に不思議な事でもなんでもありません。まぁPO＝監督ではありませんけど、関わる人が変われば多少なりとも影響を受けるのは必然だと思います。
以前出た意見だと、チーム内でもう一人POを立ててその人がビジネスのキーマンから意見を全て吸い上げてPOに成り代わる、というものがありました。齟齬が発生する危険はありますんで、止むを得ない場合だけにしたいですけどね。
後は、同じようにチーム内でPOをもう一人立てるところまでは一緒で、その人に新米POの補佐的立場に立ってもらう、なんてことが出来たら、色々教えたり体験したりしてもらいながら覚えて行って貰えるんじゃないかと思います。専任の担当者が作れないにせよ、知識のない新しい人に入って貰うんですから、それなりに手間暇かけるのは当然でしょう。
ちなみにウォーターフォールだったらどうなるかなぁ、と想像してみたんですが、そもそも初心者がプロジェクトのキーマンになることはありえないんですけど、もし間違ってなっちゃうと、プロジェクト立ち上げ時の遅れが取り戻せずに終盤デスマが発生するだけな気がします。よくあるよくある。
凄い勢いでプロダクトバックログが積みあがっていくんだけど…。
― メモ ―
- ROI*3が高いかどうか。
- 優先順位設定
- ×：チームが付ける
- ○：プロダクトオーナーが付ける
- →そもそもプロダクトオーナーが付ける優先順位が怪しい
- →プロダクトオーナーが責任を持つ
- →プロダクトオーナーチームを作る(プロダクトオーナー同士でディスカッションできる会議体の設定)
- →ストーリーのROIをポーカーで見積もる
- →単にチームの意見を聞いてもらうだけでいいのでは？
- 頭ごなしで話を聞いてくれないならどうしようもないがｗ
- プロダクトオーナーとのコミュニケーションの場を持つ
- 飲み会
- 同じ場所で働く、隣のデスク
- ランチミーティング
最初は「プロダクトバックログが積み上がって行って収拾がつかない。どうしたらいいか？」という質問だったんですが、話が二転三転していきます。オレが把握している限りだと、以下のような流れだったと思います。
- Q:「プロダクトバックログがドンドン積み上がっていって収拾がつかない」
- A:「費用対効果の高い順に優先順位を付けていって、順々にやっていけばいいんじゃない？」「必要ないものは都度見直しで切り捨てて行けばいい」
- Q:「そもそもプロダクトオーナーの付ける優先順位設定に納得がいかない。どうしてもビジネス的に優先度が高いようには見えない。信頼できない。」
- A:「付けた優先順位に責任を持つのはプロダクトオーナーなのだから、多少違和感あってもその順序で開発すべき」
- A:「そもそも優先順位に納得いかない旨については、伝えれば考慮して貰えるのでは？」
- A:「それ以前にコミュニケーション不全になってるんじゃないの？」
- Q:「じゃあコミュニケーションを円滑行う為にはどうしたらよい？」
- A:「飲み会！飲み会！」
- A:「凄く簡単。席を移動して、隣で働くようにする」
- A:「ランチミーティングとかをやったら？」
要するにコミュニケーション不全が原因だったんですね。席を移動してみんな一緒のところに働くのが一番効果がある、というのはその通りだと思うんですけど、「凄く簡単」かどうかは疑問ですねぇ。オレが今まで一緒に仕事してきたPO的な人って、オフィスどころか国内にさえいない人たちばっかりでしたから。ビジネスのキーマンって忙しいので、そうそう捕まらないイメージがあります。
顧客に提出する為だけにプロダクトバックログから情報を出してきて資料を作らなくちゃいけない。止めたいのだがどうすればいい？
― メモ ―
- バックログをチーム向けと客向け、それぞれ作る
- 通訳を用意
- なぜプロダクトバックログを見せなくちゃいけないのか？
- ストーリーが固まっているなら毎回見せる必要はないのでは？
どうも顧客との打合せの際、毎回プロダクトバックログからストーリーを引っ張り出してきて、都度資料を作って打合せに臨んでるらしいんですね。ストーリーは「顧客とコミットした機能」だから、それに対して何度も打合せをする必要があるのか？ というのが、逆に登壇者らから質問が上がったりもしました。「プロダクトバックログをそのまま顧客に見せちゃえば？」という意見もありましたし「そもそもプロダクトバックログの中身は、打合せする必要が無い内容なのでは？」という意見も。
これ、聞いてて思ったんですけど、壇上の皆さん、「何の打合せ」なのか誰も明らかにしないまま議論を進めてたんじゃないですかね？ もし要件を詰める為の打合せだったらストーリーの書き出しは必要不可欠な作業ですし、進捗会議だったら予めWBSのようなものを用意しておいて、毎回アップデートするだけだと思いますし。「何の打合せ」なのかで対応が全然変わると思うんですけど、そこがはっきりしないで議論だけ盛り上がってたんで、たぶん全然問題解決できてないんじゃないかなぁと。質問者がノンビリした口調の方だったんで、議論が盛り上がり過ぎて途中で口を挟めなくなってるようにも見えました。
分からないことだらけなりに個人的な見解を書きますと、顧客用に報告資料を毎回作るのは当然の事だと思うので、その情報元がプロダクトバックログしかないというなら止むを得ないんじゃないでしょうか。毎回同じこと書くのがめんどくさいのであれば、資料のフォーマットを使い回せばある程度作業量を軽減できるとも思いますし、顧客と相談して簡略化してもいいと思います。まぁ実際のところ、彼が何で悩んでたのか分からないので、何とも言い難いですが…。
そして終了。上記の「酣」は「たけなわ」と読むそうです。この後諸連絡があってイベントは終了しました。この際告知されたScrumBootCamp東京2012は、募集開始後一瞬で満席になりました。おそるべしスクラム道。
総括
全体を通して非常にレベルの高い議論が交わされたと思います。中・上級者向けで、生半可な知識しか持ちえない人が普段のスクラム道に参加すると打ちのめされて絶望感しか味わえないんじゃないか、そう察してしまう内容でした。そういう意味では、今回の「スクラム道フルブースト」のようなイベントは、セーフティネットの役割も果たしましたし、リトマス試験紙的に「自分がスクラム道に通用するかどうか」を試す、格好の機会になったんじゃないかと思います。とりあえずオレは聞いてる議論に関しては一通りついていけたと思うので、ホッと一安心。
7人のアジャイルサムライもそうだったんですが、こういう参加者が議論を行うタイプのイベントは、最初提示されたお題が、実はそこが問題じゃなくて、議論の中で本質を探っていくうちにだんだん議論の主旨がずれていく、という傾向がありますね。そこがライブ感があって面白いところではありますけど、ファシリテーター的な役回りの人がお題提示者に意図を随時聞いていかないと、最初提示された問題だったり思いだったりが解決できないという難しさはあるよな、と感じました。
一方で、率直に感じたことは、「オタク臭い」「ガラが悪い」というあまり宜しくない印象でした。
なんというか、アジャイルオタクというか、アジャイル原理主義というか、どいつもこいつもアジャイルが好き過ぎるというか、アジャイル以外を拒絶する雰囲気があったと感じました。
あと、登壇者が壇上で踏ん反り返っていたり、足を投げ出していたり組んでいたり、ビンボー揺すりをしていたり、帽子を取っていなかったり。アジャイルどうこう以前に社会人としてどーよ！！？ かしこまる必要はないと思いますが、自分がどんなふうに見られているのか、もうちょっと気にした方が良い。おそらく全くそんなことは意識してなかったんでしょうが「壇上に上がった人は『スクラム道』の代表でありサンプル」になるわけです。初参加の人が見ればコミュニティ全体のイメージを損なう可能性があるわけで、それを踏まえ相応に気を遣うべきなんじゃないかと。普段のスクラム道のように少人数の集まりで全員が議論に参加する人であれば問題ないのですが、今回は「スクラム道の紹介」だっただけに宜しくなかったんじゃないかと思っています。…まぁ「それも含めスクラム道のカラーだから」というのであればやむを得ないですけどね。
しかし、観衆から自由に参加者を募るという形を取っている都合上、これらを運営サイドで事前に防ぐことができるかというと、非常に困難だと思っています。壇上に上がる人が実はサクラで予めその辺に関してはネゴってある、とかでない限り。そんな中でも議論にユーモアを交えながら時間内に収めて更にきちんとまとめまで行ってみせた、司会進行の西村さんの手腕は本当に見事でした。何をやったらあんな能力が身に着くんだろ、朝まで生テレビとかに裏レギュラー出演してんのかな？
これだけ色々書いといてなんですが、個人的には非常に満足しています。参加してよかった、面白かったと思っています。オレもこれまで色んな社外勉強会に参加してきましたが、その中でも最もアクの強いコミュニティかもしれませんね。それだけに人を選ぶかもしれませんが、チャレンジしてみたくなるだけのものは垣間見れました。オレ自身は受託開発に身を置いていますので、平素からアジャイル開発を積極的に実践できるかというとかなり微妙なんですが、彼らに追いつけるように色々トライしていきたいと決意を新たにしました。
