Regional Scrum Gathering Tokyo 2018 1日目 メモ

2018.scrumgatheringtokyo.org

1日目に参加して、忘れないうちに走り書きメモ

Keynote

Build a Workplace People Love – Just add Joy

ジョイ・インク 役職も部署もない全員主役のマネジメントのMenlo Innovations CEOであるRich Sheridanさんのお話。

speakerdeck.com

Joy Incは去年のScrum Gatheringの抽選で当たって読んでましたが、また読みたいなと思えるエモくて良い話でした。

  • chaosな状態だと作れなくて、それをどうにかしようとbureaucracy(官僚的)な状態になると始められなくなる
  • 人と人の関係を基礎とした組織。喜びを大事にする。
  • 喜びというのは、誰かに貢献することによって得られる
  • 恐怖と戦い、変化を受け入れられるように。変化を生むために、うまくいくか実験をしていく。
  • 実験は小さいものから始めると良い

Cultural context is everything

https://confengine.com/regional-scrum-gathering-tokyo-2018/proposal/5350/cultural-context-is-everything

コンテキストに依存した理解、認知というのは、理解とは何か (コレクション認知科学 2)を読んで以来気になっています。日本で「儀式」というと「思考停止した作業」のようなネガティブなニュアンスを含むこともあると思うのですが、合理的な理由の無い作業に文化が反映されている、他からは意味がないように思えても当事者には意味がある、というような話で、そういう捉え方があるのかと新鮮でした。

一方で、合理的でないように思えるけど組織的に大事な儀式と本当に無駄なものの区別って難しそうだなという印象を持ちました。

  • よその事例を真似してもうまくいかないのは、その事例の背後に隠された文化的なコンテキストがあるから
  • 文化は指紋のようなもので、uniqueで、正確にコピーすることはできない
  • うまくいっている事例の背後には、強いidentityがある
  • アンチパターンがあるわけではなくて、改善すべきプロセスがあるだけ
  • プロセスはpracticeによって行われるものではなくて、principlesから行われるもの
  • 文化ははっきり形があるものではないが、ritualが文化を反映する
  • 自分たちの文化を創り上げましょう

チームワークあふれる働き方を目指して -サイボウズが歩んだスクラム導入の道-

https://confengine.com/regional-scrum-gathering-tokyo-2018/schedule/rich#session-24279-info

www.slideshare.net

会社内で誰もスクラムを実施したことが無い状態から、1チームに導入、その後全社的にも広がってきているというお話。前段の話から、単にやり方をまねしてもうまくいくわけではないのですが、エンバジェリストっぷりが大変参考になるお話でした。

最初、爆死というぐらい失敗したそうですが、その際にも、特にScrumを辞めようという話は出なかったとのこと。目的をしっかり合わせることが出来れば、辞めても問題解決にはならないので、よりより手段を探す、ということになるのかなと思いました。

また、一部の成功事例がそのまま全社的に広がっていく文化は羨ましいです。

6 Years Of Teaching Certified Scrum Developers: Re-spec, Re-design & Re-entry

https://confengine.com/regional-scrum-gathering-tokyo-2018/schedule/rich#session-24281-info

CSDのお話。CSDはすごく良いという話を聞いたことがあったのですが、機会があれば是非受けたいなと思う内容でした。

  • 早く開発するだけでは意味がなくて、価値を届けることが大事
  • 良い開発チームとはどういうものかを学べる
  • keyword: knowledge, creation, preservation
  • CSDは5日間で、70%は実際に開発の時間
  • 5日間で、1スプリント。これは、できるだけ本当の開発に近づけるため
  • それまでの研修で作られたコードを引き継いで、続きの開発を行う(1週間で全員が辞める会社のような状態)
  • 前のチームが得た知識をちゃんと保存しておくことが大事。テストコードによって残す。それによってすぐに開発に着手できる。
  • エンジニアは学び続けないといけない。不足している知識はon demandで学ぶ。
  • TDDを通じて学ぶ
  • 1スプリントなので、振り返りを通じての学びはトレードオフとして諦めている
  • 開発チームのビルディングは講師が務めるスクラムマスターの役割。逆に言うと、スクラムマスターの手本も見られる。

Walking Scrum History with Patterns

https://confengine.com/regional-scrum-gathering-tokyo-2018/schedule/rich#session-24283-info

Scrumのパターンを集めたサイト http://www.scrumplop.org/ が気になりました。パターン・ランゲージはまだちゃんと理解できていないので、併せて抑えていきたい・・・