たけこうの意識低い系ブログ

@talfi121 意識低い系エンジニアのブログです。時々思いついた時に書きます。極稀にエンジニアっぽい技術系を書きます。

Regional Scrum Gathering Tokyo 2017(2日目) 参加してきた

2017/01/12, 13 の2日間にかけて開催された
Regional Scrum Gathering Tokyo 2017 2日目の参加レポートというか自分用メモです。

1日目の記事はこちら

1日目に引き続き、酒飲んで帰宅した直後に書いてるので色々見にくいところがあるかもですm(_ _)m
スライドは公開され次第、更新していく感じで

セッション一覧、スライドなどはこちら
ハッシュタグ#RSGT2017
togetterhttps://togetter.com/li/1069966

参加したセッション一覧

  • Agile journey through the decade - あるエバンジェリストが歩んだアジャイル近代史
  • 日経電子版 穴のあいたバケツ開発
  • Scrum / DevOps の導入を加速させるグローバルマインドセット
  • 缶詰屋さんの課題解決にスクラムを使ってみた
  • 結果的にスクラムになってる!なのがいいと思う!
  • 最短で成果を上げる!強いスクラムチームの作り方
  • Pitfalls of Scrum -- My findings from coaching / スクラムの落とし穴 〜アジャイルコーチが遭遇するよくある問題とその解決方法

Agile journey through the decade - あるエバンジェリストが歩んだアジャイル近代史

長沢さん @tnagasawa

スライド公開されてない模様

メモ

ハッシュタグ付けてtweetするとリアルタイムで流れていてそっちに気が取られたww

Agileが浸透していなかった時代
→どちらかというと「なんか宗教じみてたり、現実と合ってないんじゃない??」とかで選定条件から外されてた

コンサルからエバンジェリストになって
コンサルなので契約の期間があって、その期間が縁の切れ目になることが多い
終了後、しばらくしてから聞いても「上手くいかなかった」の声が多かった

MSのエバンジェリストをやっているとMSの製品を使ってる人、コミュニティの人にしか会えない
→そこに壁があるなら壊そうと考えた
Agileを使えばその壁が壊せそうだし、MSという名前を使えないかと考えた
企画書出して通過
→社内の人とはできないのでソラコムの玉川さんに協力を求めた
IBMとMSのエバンジェリスト2人が登壇(当時はそんなことがなかった)
暗黙のルール(サイトにコミュニティの情報とか書いてはいけない)を明確なルールじゃないから!ってことで破った
「実践している人たちの事例を広める、 その場 を作ったに過ぎない」
イベント主催「AgileDay」 #msagile

色々やったけどかなりの傷を受けた
味方はいなかったけどやらせてくれた

「ソフトウェア開発は、そもそも難しいんだよ」
お客さんがAgileでやろうと言っていたとしても足並みが揃っていないとダメ
現場とビジネスが同じ場所を見ていなければアジャイルは進まない、コンセンサスを取ることが重要
同じゴールを見ましょう
現場とビジネスの足並みは揃ってきた

  • バズワード化してきたけど、バズワードに出会ったら、現場を見つめる。現場を信じる
  • 文化を悲観するより、今ある問題と向き合う
  • 文化とは過去のものが承認されてできたもの。あまり重要ではない。
  • 今ある問題に向き合えばそれが未来の文化になる

Q&A
Q : 矢を受けた時にどうやってストレスマネジメントしてましたか
A : 矢を受けてないと思うことが一番
後は、1人で抱え込まないこと。
仕事でべったりしてる仲間ではなく、コミュニティの仲間などに愚痴ったり

日経電子版 穴のあいたバケツ開発

武市さん

スライド公開されてない模様

メモ

穴のあいたバケツに多く水を入れたいプロダクト

  • イケてるバケツを開発できるチームを作る(内製化)
    今までの開発
    いちいち遅くてデカイ
    →シャアボタンを追加に2週間開発 + 申請期間
    おそすぎる、フィードバック得られない
    アジャイル開発で小さく速く届ける
    →内製化 まずはスモールスタートで一番ユーザに近い画面を内製化
  • バケツを大きくする
    全面リニューアル
    クラッチで全て内製化
    社員でも自分事化出来ない人はいらない
  • バケツの穴を塞ぐ リテンションとは小さなカイゼンの繰り返し
    新機能を追加するわけではない

Scrum / DevOps の導入を加速させるグローバルマインドセット

牛尾さん @sandayuu ロッシェルさん @JICRochelle

スライドはこちら

メモ

アメリカの後追い感あるからスピード遅いからそういうのを速くしたい
AgileかWFとかで議論している場合じゃねえんだよ!!

DevOpsはAgileの上に成り立ってるけど
日本文化の上にAgileを載せようとするとなんか噛み合わない
Agileってアメリカの人達が作ってきたものだから西洋文化入ってますよね??
別に日本人が能力的に劣っているとかではない、西洋文化をインストールしてやろう

8つの文化習慣を西洋文化ではどういう背景でなっているのかを理解すればいい
文化を変えるのは大変とか言うけどScrumインストールは文化を変えてるのと変わらない
テクニックだけをインストールするんではなくて、マインドセットもインストール
「This is not Agile, Wa(和)-gile」
気付かぬうちに日本のやり方になっているから本来の姿を理解する

日本の文化で育っているので「違い」に気付けないからまずは理解
周囲の巻き込みは最初から行っていく
最初はうまくいかないけど、やってみること

8つの習慣を理解する

  • 優先順位をつける
    日本:順位付けするけど、可能な限り全て終わらせる
    米国:5つあったら1番上だけやって、後はやらない
  • 会議の違い
    日本:会議の前後に準備する
    会議で寝る人もたまにいる
    会議の後で実行に移る
    米国:準備しない
    米国では喋らない人がいない
    会議の時間で何とか済まそうとする
  • 失敗した時
    日本:怒られる、部下が失敗することに対して恐れるようになってしまう
    米国:感情的になるのは御法度で失敗したことからの学びが重要
    フィードバックが喜ばれる
  • プロジェクトが中止になった時
    日本:プロジェクト開始後に文句を言う
    でも計画したし、予算も取ってるから意味ないけどやってしまう
    米国:変化に対応するのが大事だと思うので、意味ないならやらない(とめる)
    何か中止になった時も上手く行った時と同じようなパーティをするところもある
  • サーヴァントリーダシップ
    日本:指示するだけのことが多い
    米国:一緒になって先導して実行する
  • チームワーク みんなが助け合って、状況の変化にフレキシブルに対応していくこと
    リーダっぽい人がいてみんなその人に聞いてとかではない
  • 従業員への信頼
    アメリカビューだと全員を子供扱いしていると見える
    プールで強制的な休憩時間があるが、アメリカでは絶対にない
    ルールで縛りたがるし、日本はハンコ多すぎてスタンプラリーっぽいよね
    そんなのは自己責任で自主性に任せよう
  • 「許可を求めるな、謝罪せよ」
    自分で考えて、いいと思ったんならやってしまえよっていう常識を語っているだけ
  • 自信を持って他人を助ける
    何か知ってないと語れない、やれないと思いがちだけどその場で一緒に考えようぜ
    準備しないことを恐れない
  • 顧客
    大事なのは顧客とコラボレーションできるかどうか
    うまくするためには顧客を教育する
    日本では顧客がプロダクトを見下す
    遠慮してしまいがちで、行動する前に躊躇して辞めてしまうことが多い

缶詰屋さんの課題解決にスクラムを使ってみた

オオトモさん @toshiotm

スライドはこちら

メモ

急に会社辞めて、缶詰大学に通いだした人のお店

かなりやること多くて全く手が回ってなかった

問題点

  • 中に入り込みすぎて客観的に見れなくなった
  • 目の前に有ることに必死で、その場しのぎの判断をしてしまう

これらってソフトウェア開発の場面でもよくあるよね

課題1

ユーザストーリマッピングを「サクセスストーリーマッピング」に変えて使おうってなった
問題と実現したいことを書き出して時間軸にそって並べてみる
実現したいことを達成した結果を定量的な数字で洗い出す

課題2

従業員に対して要求は出すけど実現は自分達でやってほしかった
ってことで「受け入れ条件」を書く
サクセスストーリーマッピングからバックログを作成
作成したサクセスストーリーマッピングも将来のビジョン、ゴールの共有ということで従業員に見せる
スプリントプランニングでタスクだしして、接客していない時にタスクをこなす

初日のバイトの子が一緒になってプランニングやってたりしてて良い!!!
ソフトウェア開発以外でもスクラムやってるの初めて見た
今後の動向ってのも見てみたい

結果的にスクラムになってる!なのがいいと思う!

しいば さん @bufferings

スライドはこちら

メモ

どうやって 組織の中で スクラムを始めるのかを考えてみる
答え スクラムをはじめない というのが出てきた

例1

スクラム導入しようって言われたけど
とりあえずGood&Moyattoで問題聞いて、洗い出して問題を解決しようってことにした
問題の解決策としてスクラムのプラクティスとは言わずに実施
まずは、1週間だけと言って開始
2週間後にはもうかなりスクラムっぽくなっていた

スクラムやろうとしてやると スクラムお化け が出て来る
問題解決をしようとしてコツコツやっていくとみんな受け入れやすい

例2

スクラムを始めていてスクラムお化けに取り憑かれているというチームから相談
一旦スクラム忘れようぜ!!
上手く行ってない因果ループを見つけて、どこからカイゼンしてもいい
どっか対処しやすいところからやっていけば全部ひっくり返しやすくなる

スクラムやろうとするのではなく、実感している問題から始めてチームに合ったやり方で1歩ずつ

問題解決の道標としてスクラムを使えば組織に合ったスクラムになる

しいば さんからの質問
皆さんのスクラムやろうとしている根本的な問題はどこですか??

最短で成果を上げる!強いスクラムチームの作り方

松浦さん @ayaya1024

スライド公開されてない模様

メモ

最短で成果を上げる秘訣 KYPAS

  • K 期待を確認する
    期待マネジメント
  • Y まずはやってみる
    小さく始める
    本一冊あたり3年分の学びを得ることができる
  • P すばやいPDCAをまわす
    すばやいフィードバックを
    フィードバックをもらったら、感謝を伝えて腹落ちするのが大切
  • A プロのアスリート
    休むのも仕事
    自ら積極的に相談しに行く
  • S 強いスクラムチームを作る
    社内だけでなく社外も巻き込む

強いスクラムチームの作り方

社内実践事例「イノベーションサミット」
リーンスタートアップ手法を用いて農業ICTで活動中

  • ネーミングで共通認識をとる
  • 小さな成果を積み上げる
  • できるペースでできる範囲で
  • 少数精鋭のチーム(なんでもリリースできる体制)を作る

スクラムをやろうとするのではなく、スクラムは手段
課題があって、その問題を解決していく、自然とスクラムになるのが良い

正解は1つではない
他人を変えるのは難しいのでまずは、自分でカイゼンしていくことが大切

スクラムの落とし穴 〜アジャイルコーチが遭遇するよくある問題とその解決方法

吉羽さん @ryuzee

スライドはこちら

メモ

  • いつも完成しないスプリント
    • 改善したからベロシティが上がるとは限らない
      次のスプリントの成果を参考にするのならOK
    • 最初のスプリントの見積もりなんてあてにならない
      →プロジェクトの最初に色々なものをコミットメントなんてできない
    • 祝日はキャパシティから引っこ抜く
    • リズムが大事、毎回同じ会議室でスクラムイベントとか
    • 1スプリント自分がやったことないタスクをこなす期間を用意
  • 機能不全なプロダクトオーナー
    兼任はしてもいいけど、クリティカルな部分を持たないことを強くオススメする
  • 不十分なふりかえり
    • 最初に口を開かなかった人はずっと開かない
    • カイゼンすることが目的ではなく、プロダクトをデリバリするのが目的 カイゼン活動は定期的に繰り返していくもの
    • ふりかえりの方法は同じ方法を続けるのではなく、色々試してみる
  • 不安定な品質
    スクラムはテクニカルプラクティスを定めてないけどやらなくていいわけではない!!
  • 機能しないデイリースクラム
    書けないペンが残っている開発チームはダメ
  • 教育不足
    ルールを知らずにゲームをやるのか??

感想

なんとなーくだけど組織って話が多かった気がする
スクラムをやろうとすると多分組織に何かしら問題があるってのがみんなの共通認識なのかな??
とりあえず殴り書きのメモだし、まだ自分の中に落とし込めてない話も色々あるので復習とか聴けなかったセッションのスライド見たりしたいところ

楽しい2日間でした!!!ありがとうございました!!