Regional Scrum Gathering Tokyo 2015に参加した。
3日分の発表内容メモと感想のまとめ。長い。

3日間のイベントで、初日は主にスクラム実践者の方々のセッション、2日目はオープンスペーステクノロジーというディスカッション形式、 3日目はコーチや本の執筆をされている方々からのキーノートという構成。3日目のみ有料だった。

Day1

初日は以下の4つのセッションに参加した。

Scrum Patterns: The New Defacto Scrum Standard

Copeさんによるスクラムとは何かを再確認するような発表。 英語だったので意味を取り違えてる部分もあると思うが、以下のようなことを言っていた。

  • スクラムはただのルールブック。
  • チェスプレーヤーに例えれば、ルールを知っているだけでは良いプレーヤーとは言えない。
  • スクラムにおいてマネージャーという存在はいらない。無駄。スクラムでは自己管理する。タスクマネージャーというのもいらない。
  • Kanbanを使ってるチームは病気。
  • チームのゴールは価値を創ること。スクラムやルール自体はゴールじゃない。
  • スクラムによって、どのようにして学ぶかを学ぶ。
  • 毎朝のスタンドアップミーティングは何のためにあるのか？SBIを管理するショートプランニングミーティングみたいなもの。
  • もしもスプリントが終わった時にベロシティの見積もり通りになる確率が50%以上なら誰かが嘘をついてる。
  • 息子は14歳でCSMになれたんだから皆も出来る。
  • ベロシティは6ヶ月で倍になる。なってないなら、あなたは理解してない。
  • 信頼が大事。マネージャーやテスターを信頼してますか？
  • アジャイルマニフェストにあるように顧客との協調が必要。

なぜKanbanを使うのは良くないのか聞いたところ、 例えば1つの製品をデリバリーするために、

  1. パーツAをつくるチーム: 生産性98
  2. パーツBをつくるチーム: 生産性96
  3. テストするチーム: 生産性100

がいたとすると工程2のところで在庫が出る、という説明だった。 なのでHenrik Knibergさんの本に出てくるステータスが細かく管理され、WIPが制限されているようなカンバンを指しているわけではない。 役割が分断されているようなチームは無駄がでて良くないよね、という意見だと解釈した。

また、見積もったタスクが全てDONEできる確率は体感として50%以下な感じがするんだけど、と言ってみたところ、

  1. スプリントへの割り込みタスクを止める人がいない
  2. 違うチームへの依頼で待ち時間がある

といったことが原因でしょという話になった。 これは確かにそうなんだけれども、他のチームと働くことが多いというチームの性質や、 会社の枠組みでロールの分断された組織があるという状況もあるのでなかなか難しい印象。 ただ、これらについては他の方とも話しているうちに試してみたいアイデアを得た。

Copeさん節はいつも通りかなりの破壊力があったし、理想の組織での話のように感じる部分はあるが、原点となるマインドと強いパッションには共感を覚える。 スクラムというと色んな要素はあるものの、価値を生み出すのがゴール。

開発モデルの作り方 ～守破離の破！～

  • とりあえずやってみることでプラクティス厨じゃだめだと気付いた。
  • ざっくり開発者が言ってきた日数に係数かけて見積もる。エンジニア「２日です」オーナー「わかりました(４日か)」。
  • 自己流から破はできない。型があるから型やぶり、型がない人が型を破ったら形無し。

リーン開発の現場を参考にされていることも、その他の部分でもすごく共感できることの多かったセッション。

現状、良かれと思って基本や事例から変化させて取り込んでる手法についてはプラクティス厨になっている気もする。 色んな方々の知識によってスクラムの基本形ができていて、それから学べる要素も多いと思うので基本形をもう一度見直したくなった。

スクラムマスターは要らない

  • 全員POであってほしい。
  • 以前は計画もスピードも重視で根性で乗り切ってた。 - 今は大阪の組織は全てスクラム。
  • 当時、ベンチャーからの成長で組織はカオスだった。
  • 「エンジニアとして働きたいチーム」をつくろうとした。
  • 摩擦とヒエラルキーに悩んだ。
  • 摩擦を生む境目が何か考えた。それは責任範囲だと考えた。「ここからはあなたの仕事、責任」
  • もう一つはエンジニアに期待してない。スキル低いエンジニアでも回せるようにしよう。
  • なんでこういう組織になったか考えた。失敗を乗り越えるためだと考えた。失敗しないように。「この範囲なら失敗しないよね」
  • 子供に転んでほしくないと考えた。そのためには転ばせる必要がある。
  • エンジニアへの期待値をあげて、責任範囲を細かくしない。
  • タイムボックス、スコープ、レトロスペクティブで失敗を小さく、失敗できるように。
  • スキル高い人だけがチーム入ってほしいのではなく、成長できるようにしたかった。
  • いますぐ終わらせる、できるひとにとりあえずやってもらうではなく、コスト払っても３ヶ月後に早く開発できるようにしたかった。
  • 立ち上げメンバーのようにユーザにとってうれしいことを考え、プロダクトオーナーシップを持ってほしい。
  • そもそもみんな持ってるはず。
  • 「ここまででいいよ」と壁つくってた。
  • 「あなたが一番いいと思うものつくって」というようにした、始めはおそるおそるだったが、徐々にみんな言える環境になった。
  • 次はみんなが働きたいと思う組織を目指した。
  • チームを超える横串の場をつくった。
  • マネージャとかもフラット、ただのロールという認識を広めた。。
  • 組織５０人でもやもやしてることを出した、レトロスペクティブ。
    • ex.全チームにホワイトボード、プロジェクタ導入、カフェテリアの匂いをなくす
  • 希望者全員CSMの研修にいってもらった。
  • いけない人向けには大阪に人を呼んだりした。
  • とりのぞける障害はとった、だから「みんなで大阪の開発部を良くしていこう」
  • 組織というプロダクトを変えた。
  • ただやる人はいらない。プロダクトオーナーシップをもったスクラムマスター、エンジニアになってほしい。

本編以外のQAへの回答からの抜粋は以下。

  • 方向性の違いは否定するのではなく、話し合ってもともとの原因を探る。
  • 取り組みの結果、もともとPO、SM、PMとか全部やってたのをメンバー任せられた。
  • 消極的な人にも参加をよびかける。ほっておかない。定期的な面談とかやるんじゃなく、気付いたらすぐ伝える。

うーん、羨ましい。 質問への回答にも少しあるが、コミュニケーション的な部分でぶつかった壁や解決したことが多々あったんじゃないかと思う。 今の状況ではKPTやるとどんなものが上がっているのか気になる。

アジャイルコミュニケーションプラログラム ~チームワークに関する心理学的アプローチ~

「言っても仕方ない」「どうせダメだ」みたいな心境になった人、させる人について対応や原因を考えるセッション。

例えば、「報告しろ」+「自分で考えろ」という矛盾した指示(ダブルバインド)を出されたりすると、そのような心境をつくる一因になると考えられる。 ペアや4人組でのワークでは、身の回りで起きているコミュニケーション不全の状況を考え、励ましの言葉を考え、それを人から言われてみる、というようなことをした。

こういうセッションはむずむずするが、ワークと割り切って普段やらないことを試したり、意識できてないようなところを確認できるので面白い。 あーあるある、という状況に名前をつけて認識できるようにする感じ。関連する本を1冊読んでみたくなった。

クロージング

初日のクロージングは参加者全員で来年度のRSGTのポスター・テーマを考えた。 それぞれ10人程度の9チームに分かれ、意見をまとめ、発表した。

限られた時間内に焦りながら成果を出そうとする感覚は、マシュマロゲームみたいな印象。 すみません、プロトタイプとか全然つくりませんでした。アイデア考えて、締め切り直前に最終版を書き始めました。

みなさんどうやって取り組んだろうか？ 振り返りしたチームもあるようだし、自分がいたチームは「だれが」「なにを」期待するイベントにしたいかのアイデアを考えて投票、 それに合うフレーズのアイデアを出し合うようなフローで参加した。

意外に感じたのは、チーム内で我先にとファシリテーター役出るかと思ったらそうでもなかった。お見合い。 そんな雰囲気の中でも活発に意見を出して、雰囲気をつくっていた女性の方々すごいと思いました。

Day2

Open Space Technology

2日目は全てOpen Space Technologyの時間。 午前はアイデア募集をして、似たものはまとめて、午後に向けて時間と場所の割り振りをした。

私は"スクラムで取ると嬉しいメトリクス・数字"というテーマで時間をとらせてもらい、以下のようなアイデアがでた。

測定手法・項目 効果
ベロシティ 見積もり精度向上
各タスクが何日で完了したか 見積もり精度向上
◯◯さんが実施したレビュー回数 特定の人への依存の視覚化
テストカバレッジ 品質
テストの書き出し、実装にかかった時間 工数視覚化?
割り込みタスクの数・かかった時間 見積もり精度向上
バグの数 見積もり精度向上
デモミーティング参加者のフィードバック数 期待値や成果の指標
目標達成できると思う率 心境・潜在タスクの視覚化
TODO・FIXMEコメント、つみのこしタスクの量 潜在タスクの視覚化、理解度の視覚化
コードの静的チェック 技術的負債の視覚化
トラックナンバー 特定の人への依存の視覚化
タスクや開発プロセスが停滞してたとこ共有 特定の人への依存の低減、プロセス上のボトルネックの発見
UATの実行時間 性能保証、変化に気づける
スプリントへの満足度 開発プロセス上の問題発見
問い合わせに返答してる率 対応もれ防止
最終ソースコミット時刻 働く環境の状況が見える
同じ種類のバグを出してないか コード改善

もっとはやくデリバリーしたいと思っても、どこが原因になってるか見えてないことは多いので、 上がったような項目からアイデアを得て改善できると嬉しい。

Lean Coffee

ランチの時間にはLean Coffeeを行った。Coffeeは飲んでないけど。 テーマを出し合って、投票して人気だったのテーマから順にディスカッションをする。 7分ごとに議論を継続するか、次の話題に移っていくかの確認がある。

適度に時間が区切られており、人数も少人数だったのでわりと集中して参加できた印象。

議論ででたアイデアの中で、“メンバーそれぞれがスプリントの名前を出し合う"というのが個人的に面白いと思った。 ビジョンが共有されてなければ、全く違うものが出てそれに気づくだろうし、 見返した時に何をしてきたのか、何が不足しているのかの考えるヒントになる。

Day3

3日目は以下の4つのセッションがあった。

Promotion of Growth Led by Scrum. ~ Road to Agile/KAIZEN. Improve THE Experience for Challenger ~

  • 日本の状況は誤った情報が多い印象。
  • 自分の本もスクラムに色付けしたもの。
  • 今から学ぼうとするとミスリーディングが多い。正しい情報が多い状況をつくっていきたい。
  • スクラムを選択肢にいれてほしい。
  • ◯◯ブートキャンプとか◯◯サムライも誰かが経験したもの。
  • 第一ソースに会う機会を増やしていったほうがいいと感じる。
  • 奴隷になってる。会社やスクラムの。
  • スクラムだからではなく、スクラムの目指してるものを考えれてるのか。
  • Ken Schwaberのgoogleでの動画から分かるように、透明感、３ヶ月後とかの状況を知る、把握するためのツール
  • ビジネスを成功させるものではない
  • できない人がやって数ヶ月後ほとんど何も完成してないだろう、それがわかる
  • 改善したい人のペルソナを考える
  • 飢餓感タイプか(圧倒的当事者意識くん)
  • 危機感タイプか(やればできるこ)
  • 飢餓感タイプは与えることに抵抗ない
  • 危機感タイプはいただければやります、ひどいともうほっといてください
  • 飢餓：「忙しいからほっておいてくれ！」
  • 危機：「トラブルさえなければいい」
  • どちらもなにも求めてない。どちらもスクラムほしがってない。
  • 飢餓：あなたの望みの助けになるよ、と伝える。
  • 危機：なんで重要なのかというイメージもってもらう。イメージさえできればできる。
  • アプローチは対象によって違う
  • えばたさんは危機感タイプ。だから本場に行くことで危機感を覚えるように動く
  • フィードバックは"言う"ことだけではない。なんでも言ってたら、それはただの独り言
  • 適切に行動を変える刺激を与えたり、与えなかったりすること
  • 挑戦する場がなければ人は動かない
  • スクラムにはフィードバックが組み込まれてる
  • ルール通りにやることで、８割方のフィードバック得られるはず
  • スクラムスレーブ(奴隷)になる。どうやって未来をつくっていくのかを考えないと。
  • ブラックボックスな状態でスクラムやります、は仲間をつくらない。
  • スクラムでプロダクトよくなるは嘘。または、あくまでも特定の状況での事例にすぎない。
  • 機会を多くして、プロダクトよくする機会がふえるだけ。
  • チームもいきなり成長することはない。
  • スクラムは現状をつきつけて残酷。ベロシティとか。
  • 「組織が違うんです。頭でっかちいるんです。」
  • じゃあ働きかけていきましょう。キーパーソンに。スクラムにはそういうことを考えるきっかけがあるだけ。
  • 勇気をもって未来をつくってほしい。未来はリスクある。そこにいる人が勇気を持たなければならない。
  • スクラムやったからよくなるとは限らない。

公演中に紹介されていたKen Schwaberさんの動画は多分これ。

また、メモ上では大分省略しているが、 2タイプのペルソナに対して継続・ゴール設定といった状況に合わせた具体的なメッセージの紹介があった。

周りの方々を見ていてもそうだが、1次ソースに触れるというのは大事なんだろうなあと感じた。 また、2タイプにわけて考えるという切り口は面白い。 相手の求めるフィードバックに役立つのはもちろん、自分がどっちかを意識しておくことで、人との違いに変にイライラせずに済みそう。

レビューの課題と対策、モダンコードレビューの動向

モダン: どの時点でのモダンかわからない。 例えば"新"喜劇。

エンピリカルソフトウェア、フィードバックを基にした研究。

ソフトウェアレビューの目的：

  • 不具合の修正コストの低減
  • 保守性向上
  • 状況把握と承認

レビューは指摘ポイントの自由度高く、本質的な欠陥の指摘が少ない。

アンチパターンの例:

  • コードの前半ばかり見てる
  • 作り直してやろうかと考える
  • 時間があるだけやり続ける
  • 人間関係の持ち込み
  • 見栄の張り合い、「なにか言わないと」
  • 人格攻撃、「センスないね」

ある研究の結果:

  • 機能的な問題(21.4%)
  • 保守上の問題(71.1%)

教科書的な対応としては、レビューする前に目的を定義する。

  • 命名規則
  • ユーザビリティ
  • 性能問題

そのための方法:

  • コードレビュー
  • 手動テスト
  • テストコード、テスト自動化
  • 見つけると効果ある(定数を右に書くかどうかは効果低そう)
  • コスト減らす(特殊な状況だけ起きるものとかカバー)
  • あとあと拡張しやすくする（プラグインにするとか）

リーディングテクニック:

  • シナリオを用意して個々に割り当てる
  • 先にシナリオはチームで合意しておく
    • ex.メモリリークないか(確保と解放の数あってるか)、無停止でデプロイできるか

シナリオのメリット:

  • 限界を知って割りきれる。「初めてやるし仕方ない」
  • 問題の指摘するふりした攻撃とかを減らせる。

  • 唯一の正解があるわけではない

  • 身の丈にあったシナリオ設定する

    • ex.鉄道のシステムとかつくるのと違って、絶対に落ちないアプリそれほど求められてない

  • タブとかスペースの数は息の長くないモジュールにやっても仕方ない

  • が、OSSだとちょっと違う

  • メンテナがいないと滅びるのでevolvabilityが重視される

  • アジャイルでなくても信頼、助け合いは必要
  • 言葉の端々への配慮必要
  • 態度を変えさせるための指摘してはだめ

新人向けの注意:

  • 問題指摘されても自分の批判と考えないように
  • 「知ってました」「そうでしたっけ」と照れ隠ししない
  • 厳しい批判に「自分でやってください」と逆上しない
  • 「本質的でない」と逆批判しない

モダンコードレビューは:

  • パスアラウンドに似てる、メールでなげて回覧板みたいにするやつ
  • OSSのコードレビューに似てる

欠陥検出以外に・・

  • 情報共有
  • 透明性向上
  • 代替実装方法の検討
  • 良い点、続けてもらいたいことも積極的に伝える

グーグルでのコードレビュー:

  • 目的は協調であり、欠陥検出ではない
  • コーディングプロセスの一部として統合されてる

メリット

  • 修正時間を短くする
  • 新人の教育
  • 信頼感の醸成

グーグルのツール:

  • mondrianというツールで管理
  • OSSクローンのrietveldがある

シスコでのコードレビュー:
シスコでのコードレビューも小さくたくさんやってる感じ

Microsoftはcodeflowというツール。mondrianやgerritと似てる。

コードレビューに期待することアンケートでは

  • 保守性
  • 情報共有
  • やってること見える化

あたり上位にきてた。バグ見つけるだけじゃない。

モダンコードレビューでの注意点

  • 断片でみるので全体での一貫性や整合性が見落としがち
  • 些細な指摘ならないシナリオ設定
  • 誰かがみるだろうと放置
  • 特定の人に集中する

Githubなどで利用されているプルリクエストがちょうどモダンコードレビューに当たるとのこと。
なんでプルリクという形に落ち着いてるのか考えるきっかけになる。 また、どうしてOSSでは保守性が重視されるのか、という切り口は面白いと思った。

そして紹介されていたアンチパターンは、耳の痛いものばかり。。

State of Agile / Software Dev in Vietnam and relationship between Japan and Vietnam

  • ベトナムの現状、手法やhowが多い
  • value driven development
  • これからwhyに変わっていくだろう

問題:

  • まずは信頼が大事。コードの品質よりも大事だとおもう。
    • 日本はレポート多い。下手すると毎時間。
  • 言葉の壁。定義されてない期待。
    • ex.５分早くミーティングにいくべき。とか
    • やりたいこと(日本語)->仕様書(日本語)->ベトナム語と、たくさんの変換

POをオフショア先に置くのが一つの解決策では。 プロキシPOではなく。スクラムチームまるごとをオフショア先におく。

プロキシする人が多いとややこしいというのは共感。 依頼側も依頼される側も「信頼関係を築きたい」と考えている状況ならもっとシンプルになりそう。

今回の発表者のお二人もそうだし、紹介されていたベトナムでのイベントはとても盛り上がっている印象を受けた。 ベトナムでは多くの講演が英語らしい。 ベトナム行きたい。

Innovate and Invigorate Your Agile Discovery Practices

  • 多くのチームは一度ディスカバーに時間を費やした後、多くの時間をデリバリーに費やしている
  • ディスカバーとデリバリーのフローは断絶されてるべきではない。
  • そしてジャストオンタイムであるべき。
  • inovate(革新) + invigorate(活性化)
  • 一般的なストーリーはユーザーとアクションから構成される
  • 要件は機能要件と非機能要件に分けられる
  • それらの要件をさらに7つに分解したのが"7 product demensions”(プロダクトの7側面)
  • チームはinterdependent(互いに依存している状態)がよい
  • 独立状態でもなく
  • 依存でもなく(一方的な)
  • イメージを共有するために、より視覚的に考えるべき
  • 実際に7側面を考える場を設けるとそれはエネルギッシュで騒がしい場になる - ディスカバーすることでモチベーションも高まる

今回紹介されたDtoD本は日本語に翻訳されている。紹介動画もある。

イメージ的にはスコープや要件に新たな切り口を定義する感じだろうか。

発表者の方々はHowではなくWhyを語る人が多い印象を受けた。 ただ、Howを実践することでWhyを発見することはあるはず。 一方で、もっと人やプロダクトの価値にもっとフォーカスすべきだなあと感じた。

ベトナムの方々は強いインパクトがあった。 彼らはスクラムの未来を考えよう、とビジョンやマインドを語っていたし、若かった。ベトナムのIT業界の平均年齢は27歳らしい。

今回のイベントに参加して、本家アジャイルカンファレンスにも行きたくなった。

最後に、実行委員の皆様ありがとうございました。