Scrumを破る話とその補足。Scrumありがとう、そしてさようなら -Scrum 破- #rsgt2017 で発表してた

2017/1/13 に開催されたScrumのカンファレンスで「Scrumありがとう、そしてさようなら -Scrum 破-」というタイトルで45min話してきました。 スライドを公開するのずっと忘れていて、何度か再演もしているんだけど公開しました。2016年のチームの成果の話です。

speakerdeck.com

カンファレンスのイベントページに書いたセッションの概要はつぎです。

Regional Scrum Gathering Tokyo 2017 - Scrumありがとう、そしてさようなら-Scrum 破- | ConfEngine - Conference Management Platform

ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透明性、検査、適応の3本柱を強化してきました。

私達はいまやスクラムに別れを告げつつあります。スプリントは1日以下で、ロール(PO, SM, Member)はスプリント毎にクジで決定し、スプリントレビューはPO以外が全員個別にデモします。テストやメトリクスも更に洗練され、いまや私達は自分達のタスクを最小6分単位でスケジュール、追跡し、改善に役立てています。

このチームが取り組んでいること、そしてどうしてこのようなことをやっているのかをみなさんにご紹介します。

背景とかこのチーム(基盤チーム)でわかったこととか

世界最高の製品開発チームとは何かを追求する実験場が基盤チームと言われればそうなんですが、単純にこのチームで仕事をするのが楽しいし、いろいろやっていることがどうも他の人と違うらしいってことはわかってきているので、事例紹介してフィードバックもらったり、誰かの参考になればいいかなぁと。

まぁ普通に考えて頭悪いとは思うんですけど、このチームを通してわかったのはマイクロマネジメントこそ最高である。っていうところですかね。以前の自分と比較して、プロジェクトマネジメントでマイクロマネジメントできないのは才能が足りないんだろうなって思うようになった。マネジメントはあらゆるリソースの使い方を考えて最高の成果を出すということが目的かなぁと思っていて、解像度が低い状態でしか判断できないって辛いよねっていうかね。高解像度かつ大画面なモニターがいいように、マネジメントもそのほうがよっぽどうまく違和感に気づけるのになーみたいな。

この発表は誰かに強制するものでもないし、ある状況ではこういったやり方や考え方もあるということを話しているだけな感じです。 ので、僕も例えば全く別のチームにいったり転職したりしたら、きっと違うことを考えるんだろうなぁとは思います。

Scrumの破であるという理由は、Scrumの3本柱である透明性、検査、適応は変えていなくって、この3つを重要視することは変えずにそれら以外は瑣末なルールだと解釈してScrum Guideを基盤チームオリジナルにどんどん変えていっているっていう感じです。

あぁ、そういう意味だとScrum GuideもGitHubにあると基盤チームでforkして公開するとかできて楽しそうですね。なによりチーム的にもわかりやすいかもしれない。

今までにいただいたフィードバックとか

  • 控えめに言ってクレイジー
  • 理想はこれなんですよねー
  • ちゃんと聞くと当たり前のことを突き詰めているだけなのがすごい
  • Extreme Scrum なんだよな
  • もうScrumとかどうでもよくね
  • kyon_mmは今後何年たっても「僕たちはまだScrumを忠実にやっているだけなんですよ」とかいいそうだよね。
  • タイムトラベラーやな kyon_mmさんはタイムトラベラー
  • そろそろ何周かしてしまっていて、勘違いしている人と話があっちゃいそう

今後とか現在とか

現在も形を変えてこのチームとして仕事をしていて、非常にたのしくやっています。できれば2017年の成果もどこかで話せたらいいなぁと考えています。 例えば、 #RSGT2018 (日本最大のScrumのカンファレンス 2018/1/11 - 1/12)とか。ただ、まだ公募に出していないので、ここでVoteしてね!って言えないんですが。 僕の話もいいわけですが、もしScrumとか製品開発に関わっているのであれば、これを読んでくださっている方はきっと #RSGT2018 で発表する素質がある気がするのでみなさんも公募を出してみてはどうでしょうか? 採用されなくても別に恥ずかしいとかはないと思いますし、去年は非採用のセッションをひたすら発表する別イベントがたっていたりしましたし、まず考えをまとめてみるだけでも、とても有意義かと思います。

次のサイトで 画面右側の + Propose Sessionボタンを押せば登録できます。

confengine.com

全体のことが書いてあるページはこっち

Regional Scrum Gathering Tokyo 2018 - Tokyo, Japan | ConfEngine - Conference Management Platform

まぁなんにせよ、ソフトウェア開発組織としての知見共有とか悩み共有して次の一歩を踏み出すという場はとてもよいと思っているので、その1つとして自分も貢献できたらなって思っています。

参考書籍

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

エクストリームプログラミング

エクストリームプログラミング

アメリカ海軍に学ぶ「最強のチーム」のつくり方

アメリカ海軍に学ぶ「最強のチーム」のつくり方

チームワークの心理学: エビデンスに基づいた実践へのヒント

チームワークの心理学: エビデンスに基づいた実践へのヒント

お気に入りの生産性あげるための工夫(アプリとかブラウザ拡張とか)

オススメのものを列挙するよー。

1日の過ごし方

大切にしているコンセプトは「もっているものを最大に使いこなす」ということで、手を使える時間はプログラミングとか、たまにしか手を使えない時間は電子書籍か動画、耳しか使えない時間は音声ってつかいわけています。なので、手が空いているときはできるだけものを作るようにシフトして生活している。

  1. 起床したら気になる記事をInoReaderとかはてなブックマークから検索して、Pocketに共有。
  2. シャワーあびたり身支度する時間、通勤で歩いている時間、などはPocketで共有した記事を音声読み上げで聞く。
  3. 音声読み上げできなかった記事は、空き時間に目視で確認。(大抵は業務時間の隙間とか)
  4. 気になったソースコードはPCのChromeでSourcegraph for GitHubを使って確認して、必要そうだったらcloneする。
  5. 手が動かせる時間ができたら、いろんなものを動かしてみる。

実践している時間はバラバラなんでよくわからない。

InoReader

いろんなブログとかRSSで購読するためのWebサイト、スマートフォンアプリ。 スマートフォンで見て気になったらSlackとかPocketとかはてなブックマークに共有しています。 PCブラウザで見るときはショートカットキーが使えて便利。

www.inoreader.com

Pocket

Webページをまるっとスクレイピングして保存できるWebサイト、スマートフォンアプリ。 Androidで音声読み上げを入れれば、記事を読み上げることができる。 これで、シャンプーしながらとか歯を磨きながらでも勉強できるようになりました。神ツールだと思った。

getpocket.com

Sourcegraph for GitHub

GitHubのコードをブラウザ上でIDE的に見ることができる。 なんとコードジャンプもできてまぢ便利。神ツールだと思った。

chrome.google.com

ポモドーロテクニック

25分毎に1度休憩するというテクニック。 で、これはお手製ツールを使ってやっています。25分過ぎると、アプリが全画面表示になって作業を強制的にストップするようにしています。 結構便利です。集中して仕事したいときはかならずポモドーロテクニック使っていますねー。

Chrome拡張で便利なのはStrict Workflowっていうプラグインかな。25minの間はTwitterとかが見れなくなります。(どのサイトを見れないようにするかはカスタマイズできます)

chrome.google.com

ブラウザ上で英単語翻訳

ブラウザで表示している画面で、ダブルクリックした英単語とか選択した英単語を日本語に翻訳してくれる拡張をつかっています。 いろいろあるんですが、最近は、速訳!英辞郎®英和辞書っていうやつを使っています。 ページの翻訳はChromeそもそもできるんでね。

chrome.google.com

スクラムとかアジャイルのワークショップ 2017.05 版

毎月スクラムに関する勉強会を開催していて、そこでワークショップをやることがあります。 また社内で勉強会をやることもあります。 そこでいままで実施したワークショップの一覧があるといいなぁとおもったのでまとめておきます。 yattomさん、みほらぶさん、角さん、たかえすさん、川口さんありがとう!!!

nagoya-scrum.connpass.com

カンバンゲーム

www.slideshare.net

www.slideshare.net

バルンガ

www.slideshare.net

紙ヒコーキ

dev.classmethod.jp

振り返り

speakerdeck.com

↑の中で次の5つを実施 * +/Δ * Circle of Question * Value Stream Map * KPT * SMART Goal

プロダクトオーナーの意思共有

d.hatena.ne.jp

フィアレスジャーニー

www.slideshare.net

download – Fearless Journey

mocha-cocoa.blogspot.jp

スプリント期間と見積もり

speakerdeck.com

happylilac.net

プログラミング言語雑感 2017春

まえおき

kyon_mm のスキルでは。。。っていうだけで、皆さんがどうなのかはしりません。

Groovy

こまったらまずこれで検討するやつ。(.NETと比較して)どこでも動いてよい。IntelliJ IDEA + Gradleでつかっておけば問題ないやつ。

GrabやGradleの恩恵がすさまじく、可搬性の高いスクリプトやアプリケーションの開発にもってこいですね。くわえて、Spockっていうすばらしいテスティングフレームワークがあるだけで採用したくなる。Groovy自体も漸進的型付きなかんじがあって、そこそこに静的な型検査ができるのもいいなーとか。

WebアプリケーションつくるときはさいきんはRatpackっていうフレームワークでつくることがおおいですが、ガチな運用したことがないので結局はGrailsがいいっていう場面はあるのかもなーっていう見解。

C#

Visual Studio.NET Frameworkから離れなければとりあえず安定している。いつも不満なのは、Visual Studioで出来る操作をMSBuildでやるにはどうしたらいいのか調べるのに苦労しています。誰かサクサク知る方法を教えてください。

async/awaitの変換回りはかなり気色悪い(褒めている)とかあるんですが、(LangExt っていうライブラリをつかえば)そこそこつかえるかなぁとはおもっています。 いつも不満なのは、ASP.NETとかADO.NETとかそういうやつですよ。(あれー)

F#

.NET Frameworkでアプリケーションつくるときの第一候補とする言語。C# とかいう言語では最近REPLができたそうですが、F# は古来からありますよ! みんなでレッツF# !

F# はアクティブパターンがつかいやすくてマヂ神! ってかんじですかね。タイププロバイダーとかいうおもしろ機能はいろいろ使いこみたいんですが、まだ使いこなせていないです。 あ、あと弊社? で開発している FQC っていうコンパイラの後ろ部分(IL生成部分)があるので、こいつへのPullReqとかおまちしております。

ほかの言語

よくわからん。とりあえず、言語仕様書とGetting Startよめばなんとかなるだろという雑な扱い。 Javaは最新の言語仕様書読めていないし、C++はそもそもたいしてしらないです。言語仕様書がうすい言語は勉強しやすくてよいですね。(そうだろうか。。。)

Erlang

最近勉強しているのは、CoqからErlangの生成とかできるのではーと妄想して調べていたら、PPLでそんな話があったとかで、やっぱりそうなるよねー!っていう話をステーキたべながらしていた。 Erlangカッコイイなーってあこがれこそあれど、なかなかたくさんのコードを書こうとすると、なれがたりていないです。。。(静的型検査がないやつで、たくさんのコードを書くことにそもそもなれていないってだけです)

JavaScript

JavaScriptは僕にはむずかしいので、Vue.js でいいかんじにやっておしまいです。Vuejsの日本語ドキュメントすばらしい。課金したい。 一時期は、AltJSで生成すればなんとかなるとかおもっていましたが、JavaScript書くほうが楽な場面そこそこあるなーっておもっていました。 それもWebAssemblyでなんとかなるのかもーっていう夢がひろがってよいですね。

Java

Groovyを実行する基盤のやつ。ヴァルハラ〜。各プログラミング言語とかビルドツールがJava9にスムーズに対応できるのか不安。

OCaml

なごやで公用語のやつ。プログラミングの基礎っていう書籍でつかわれているしね。

いまだに自分はプロダクトにしろツールにしろ仕事でつかったことがないので、いつかつかってみたいとおもって幾年ってかんじです。 Emacs以外でいいかんじにつかえるIDEがほしいです。JetBrainsさんつくってくれませんかね。

Scala

東京で定番化?流行?しているらしい。個人的にはGatlingつかわないWeb企業ほぼないとおもっているので、Scala書いたことないWeb系の人いるほうが希少なのではーくらいにおもっている。

VDM++

形式的な仕様に憧れてさわってみたりしているものの、「おれがつくったほうがもっといいDSLつくれそう」というサイクルをとおして振り出しにもどる系の言語です。もう最近はVDM++でいいんじゃないだろうか。。。っていう気がしなくもないですが、B-Methodとどっちにすればいいんだーってなやんじゃいます。

ふりかえり

JetBrainsさんがいないと生きていけないです。

Java女子部でSpockの入門ハンズオン講師しました。 #javajo

Java女子部というコミュニティで2017/03/25に半日間のハンズオンでSpockというテスティングフレームワークの使い方を教えてきました。 Javaはだいたい書けるけど、Groovyとかよくわかりません!みたいな人に最低限のGroovyの使い方とSpockを教えるみたいな感じです。

javajo.doorkeeper.jp

すすめかたはだいたい次のような感じです。

  1. GitHubからソースコードをダウンロードしてもらう
  2. kyon_mmがスライドで概要をつたえる
  3. kyon_mmがIDEでサンプルコードをひらきながら解説する
  4. 参加者がサンプルコードのテストが失敗している部分を通るように直す
  5. kyon_mmがテストが通るようにコードを記述するのデモする
  6. Groovy/Spockの基本については2 - 5を繰り返す
  7. 解説がおわったらペアプロでTDDライクにSpockをつかいながらコードをかいてもらう

いわゆるKoan形式とか4clojureみたいなかんじといいますか、テストが通るように修正することで機能を学んでいくっていう感じです。

speakerdeck.com

github.com

スライドに誤解をまねくような表現がないように配慮したつもりですが、もし違っていたらツッコミもらえるとうれしいです。 Groovyの解説はJava8のまま書いても動かないところを中心にしました。

また、当日サンプルコードがいくつか間違っていたので修正したものをGitHubにあげています。

正規表現のところに // によってエスケープがなんたらというテストを最初書いてしまっていて、 動かなかったのは、文字列としてであって正規表現でのテストではなかったためです。現在のGitHubのmasterでは文字列のテストに移してあります。すみませんでしたー><

全体的には自分の知識が再整理されたとか、TDDとはなんだーとか、自動テストの考えかたとかいろいろ興味をもってもらえたのがとても勉強になりました。 呼んでいただいたJava女子部の皆様には感謝です。特に声をかけていただいた、あやさんありがとう! Java女子部はもっと怖い人のいるところだとおもっていましたが、みなさん優しかったですし、楽しい人達でした。 参加者のみなさまからも楽しかったと言ってもらえたので、やってよかったなーっておもえました。

今後も関わるのであれば、Java女子部でF#をつっこむのは難しいでしょうし、GatlingとかBetamaxとかGebでしょうか。

GroovyとかSpockまぢべんりな子なので、ぜひ使ってみていただけると嬉しいです。 また、スライドやGitHubはご自由に使っていただいて構いません。みなさまでSpockを愛でる方向で。

Enjoy Spock!

うさみみが2016年に読んだオススメ書籍と振り返り

仕事

社内他チームをマネジメントしたり、Breaking Scrumしたりと挑戦しました。たのしかったです。 セミナーや新卒研修などにも携わり。ヴァル研究所様とお仕事できたのは素晴しい経験になりました。 また、 enPiT という文科省と各大学の連携でやっている「(僕から見ると)イケてるITエンジニアの卵つくろうぜプロジェクト」に関わらせていただきました。大学院生の教育に関われる日が来てよかった。これからも積極的にかかわりたいです。 株式会社オンザロードというか、僕へのお仕事の依頼はいつでもWelcomeなので kyon.mm あっとまーく gmail.com まで。

講演

1月に「15分単位でメトリクスとってるスクラムチームあるんだけど、質問ある?」っていう発表をしてから、ちょこちょこ発表をしました。

(意外と発表してた)

セミナー

3ヶ月に1度くらいのペースで、Git Boot Camp Premiumというセミナーを翔泳社で開催しています。ちなみにオンサイトでも開催できるのでいつでも依頼してください。(他のものでも) 2017年からはもっと他のセミナーも増やそうかと計画中です。

私生活

幸せでした。家族に感謝ですね。

その他いろんなこと

すみませんでしたああああああ><

2017年にやりたいこと

  1. きょんくんがいないチームにBreaking Scrumを導入したい。(きょんくん流 Breaking Scrumの導入事例になってみたいチーム募集しています)
  2. F# かOCamlかGroovyで仕事したいので、仕事ください。
  3. 形式手法導入したい。

読んだオススメなやつ

ここから下は基本的にどれも素敵な書籍なんですが、そこから更に好きなやつを選ぶなら、

  • Joy, Inc
  • SOFT SKILLS
  • なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践
  • グッド・マス ギークのための数・論理・計算機科学

ですね。まぁ、好みも問題かも。

IT系にいるならよんでほしいやつ

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

組織とかチーム

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

なぜ人と組織は変われないのか ― ハーバード流 自己変革の理論と実践

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

カンバン仕事術

カンバン仕事術

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

トヨタのカタ 驚異の業績を支える思考と行動のルーティン

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(上)

ザ・トヨタウェイ(下)

ザ・トヨタウェイ(下)

チームワークの心理学: エビデンスに基づいた実践へのヒント

チームワークの心理学: エビデンスに基づいた実践へのヒント

数学的な

圏論の歩き方

圏論の歩き方

グッド・マス ギークのための数・論理・計算機科学

グッド・マス ギークのための数・論理・計算機科学

記号論理学: 一般化と記号化

記号論理学: 一般化と記号化

アルゴリズムとかデータ構造とか

Purely Functional Data Structures

Purely Functional Data Structures

教育

幼児教育の経済学

幼児教育の経済学

「学力」の経済学

「学力」の経済学

ネットワーク

擬人化でまなぼ! ネットワークのしくみ

擬人化でまなぼ! ネットワークのしくみ

さいごに

みなさまありがとうございました。ほんとうに。来年はもっとブログ書きます。

Gitを5年間教える側にまわって気付いたこと

Git Advent Calendar 2016 - Qiita の記事になります。 本記事では自分がGitを教えたことで気付いたことをまとめます。 ゆえに「Gitに入門したい人」に向けたものではありません。が、多少のエントリーポイントは示しますので参考になるかとは思います。 コミュニティ、有償セミナーで5年間Gitを中心としたバージョン管理システムを教えてきた経験の話です。 ただ、Git, GitHubなどのデベロッパーではないので、彼等の思想とは異なるかもしれませんが、そこは一人のGitの講師として見てもらえれば。

命名の混乱とユーザー層

Gitのコマンドは名前から理解しにくいことで有名です。 git rebase --intractive などは典型です。 例えば、branch という単語が示す内容はあまりにも違っています。 VCS毎に branch の意味が違うことも難しくしていますが、加えてGitの場合には branch (枝)というメタファーと実態の乖離が大きく、理解するまで時間がかかったという人もいるようです。 (ちなみにMercurialでは同等機能は bookmark となっており、Mercurialはbranch(枝)とbookmark(しおり)の両方で管理することができます)

そして、ユーザー層?スキーム?が様々であるため、GUIツールではあまり対応がとれないような言葉になっていることもあります。 GUIツールで困ったときに違う単語で調べる必要があり、加えてGitのコアユーザーはコマンドラインで使うため、GUIツールのトラブルシューティング情報は少なめになっています。 もちろんこれらを乗り越える人もいますが、自分の経験ではあまりいませんでした。 乗り越えないままに使うことはできるけど。。。という感じでしょうか。 ので、トラブルが起きたときにはGitで解決をせずに別の方法(ファイルのバックアップをどこかからもってきたり、新しくリポジトリをcloneしなおしてから、コピペしたりすること)で解決している人もたくさんいます。 別にそれ自体は悪くないですが、Gitの学習という意味では大きな壁になっています。

そういった意味で、自分が大切にしているのは Git公式の Pro Git というページです。 Git - Book

このページを読んで理解できるのであれば、それなりにプログラミングや、VCSに精通しているとおもいます。 ですが、なんとなくで使える程度の人や、パパっとワークフローがわかればいい人にはちんぷんかんぷんなページだと思います。 ここにある概念を大切にしながらGitを使う開発プロセストレードオフを伝えることが大切だと思っています。

Gitの概念を日本語でうまく表現している書籍は次の2冊だと思います。出版時期は少々古いのですが、あまり古びた内容でもありません。

入門Git

入門Git

実用Git

実用Git

バージョン管理、統合の戦略が広まっていない

Gitを教えていていつもぶつかるのは、そもそもSCM(Software Configuration Management)の戦略が知識としてもあまり広まっていないということです。 GitはSCMを支える重要な要素ですし、様々な戦略を取れるようにGit自身は多数の機能を提供しています。 この何年かで、「ローカルでGitを使うときの作法」「Pull Requestによるレビュープロセスの確立」「Infrastructure as a Code」といった知見は広まってきましたが、バージョン管理を活用したチームやプロダクトのプロセス品質を上げるという方向についての議論はあまりされていません。 というよりは、ずっと課題だと思う(ソフトウェア構成管理という単語がずっと使われている事情からそう思う)わけですが、流れとしては「SCMの戦略」よりも「SCMを中心として少しでもよくなってきている開発の改善力を中心にもっと範囲を広げよう」という感じだと見ています。 大切だと思いますし、そうすることで無駄が減る(部分最適をする前に全体を見ることが出来ることによって余計なことをしないで済む)こともあります。 ですが、Gitを活用したSCMの戦略が貧困なままでは、ビジネスのボトルネックになるばかりです。

一例としては、 Jenkins + GitによるIntegrated Workflow + Gateway CheckInを実践することができます。

www.slideshare.net

また、SCMという広い意味では次も参考になります。

qiita.com

「何を編集しやすく、何を実行しやすく、何を統合しやすく、何をレビューしやすく、何を組合せやすく、何をスケールアウトしやすく」それぞれのトレードオフや理想を達成するためにGitを利用することは多くの場面で大切です。

ただ、そういったSCMの戦略がわかっていない、関心がない人もたくさんいますし、必要ではない人もいます。 (もちろんわかっている人もたくさんいますが、割合の話ですね)

まとめ

  • Gitの概念、コマンドを覚えるのは苦労しやすいポイントであり、反復練習か、Gitを使わないという選択肢を見つける必要がありそう。そして、それに耐えられない人がGitをなかなか使い始められなかったり、Git使っています() みたいな状態になってしまっている。
  • Gitを使うことで、どのような理想的な開発プロセスにしたいのか。というSCMの戦略に関心がない人や、そもそも知識が共有されていない現状があることを踏まえて、Gitの使い方を教える必要がある。

自分の教えかたを2,3年毎に大きく変化させることでいくつか気付きがありましたが、大きいこの2つについて紹介しました。 では、これらをどうするのか? という話ですが、前者は Gitカルタ という形でコマンドをさわらずにGitの操作をイメージで掴めるようなゲームとして教えています。

codezine.jp

後者については、事例をはさみながら教えていますが、いまのところGit Boot Camp Premiumというセミナーでは最初のほうだけを教えるに留まっています。 ので、更に拡充して2017年はコミュニティ、有償セミナーを開催しようと思います。おそらく別枠で開催する感じがいいかなぁと。

おまけ

弊社、基盤チームではGitからの脱却を目指して新しいVCSの設計を始めています。いつ完成するのかはわかりません。いろいろ不満なのでね。。。