いよいよ22日の昼からスクラムフェス大阪が始まりますー！
2日目(23日)の最後にお話しますー。
「スクラムを始めたんだけど、自分の現場で具体的にどんな風に実装したらいいかを悩んでる人」に、何かを伝えることができたらいいなって思いながら準備してます！そんな人はぜひ聞きに来てくださいー！
いろつけたー #scrumosaka pic.twitter.com/JambJgHOwp
— Mitsuyuki Shiiba (@bufferings) February 16, 2019
たのしみー(๑•̀ㅂ•́)و✧
で、どんな話をしてるかなーって思ったけど、こんな感じかなーって思ったので書き出した。多いかな。
最初は事実。
次は気持ち。プラスの方から始める。
プラスの気持ちの右の方は、行動してみたいこと
次にマイナスの方。マイナスは、他人に対して向けない。場や状況それと自分自身に向ける。
マイナスの側の右の方は、より良くするために行動してみたいこと
で、最後にそこから、チームのアクションを出していく感じかなぁ
名前をつけるなら何だろう？ Done Learn ± Action かなぁって思ったけど語呂が悪いね。
追記
おーかっこいいー https://t.co/kns7e57FSy
— Mitsuyuki Shiiba (@bufferings) 2019年2月16日
Done Learn Emotion Actionかー！
解説を書かれた及部さんからいただきました。ありがとうございます！
今日届いてたのでどんなことが書いてるのかちょっとだけ読んでみようかなーって思いながら、あーわかるーとか言いながら読んでたら、サクッと読み終わってしまった。おすすめです。
良かった！
僕はこれまでに、何度かモブプログラミングを小さく実験してて「ふーむ。これは良さそう」と思ってて。ついに先週は「一週間ずっとモブプログラミングをする」という実験をして、このチームに合ってるなーと感じたので、組織として正式に導入する相談を進めてるところ。
この本には、そんな僕達が学んだり、悩んだり、試行錯誤したり、実感したりしたことの多くが書いてあって、笑った。先に読みたかったわ。
こういう人かな：
この本に書いてあるのは「モブプログラミングのやり方」だけじゃないです。
モブプログラミングの始め方から、よくある落とし穴、軌道修正の観点や、チームとしての人と人とのコミュニケーションまで、モブプログラミングをやるにあたって知っておくと良いことがたくさん紹介されてます。
僕が感覚だけで「モブプロ、なんて言ったらいいか分からんけど、やってみたら確かに良いわー」ってのを、具体的な言葉にしてまとめてくれてるので便利。そういうことだったのか！という気持ち。これで、マネージャーに「効率悪そう？」って聞かれたときでも、具体的に説明できそうー。
あと、チーム内でスキルの高い人がタイピストやってしまって、周りのメンバーがついていけてなかったりするよ？って書いてあって、したわ！ってなったし。別に常に全員が一緒のことやってるってわけじゃないよって話も、そうそう、あー、そういう分け方もあるのかーって思いながら読んだりしてた。
今後はモブプログラミングをがつがつやっていくつもりなので、チームのフェーズに合った章をそのつど読んでみて参考にしながら「チームで一緒に働く」ということをよりいっそう楽しもうと思います！
面白かったー！
公式ドキュメントを読みながら、特に深く考えずにちょこちょこ触ってみたのをメモ。
公式ドキュメント：https://docs.micronaut.io/latest/guide/index.html
SDKMANでインストールして
❯ sdk current micronaut Using micronaut version 1.0.4
なんとなくSpock使えるなら使っとこかくらいでプロジェクトを生成した。オプションが色々つけられるっぽい。
❯ mn create-app hello-world --features spock
たぶん、Spock使うようにしたからかなと思うんだけど、IDEAとの連携がうまくいかなくて、とりあえずGradleのコマンドを直接叩く感じで使っといた。
で、ドキュメントを流し読みながら、コントローラーを書いたり
@Controller("/hello") public class HelloController { @Get(produces = MediaType.TEXT_PLAIN) public String index() { return "Hello World"; } }
テストを書いたり
class HelloControllerSpec extends Specification { @Shared @AutoCleanup EmbeddedServer embeddedServer = ApplicationContext.run(EmbeddedServer) @Shared @AutoCleanup HttpClient client = HttpClient.create(embeddedServer.URL) void "test hello world response"() { expect: client.toBlocking() .retrieve(HttpRequest.GET('/hello')) == "Hello World" } }
HTTP Clientも簡単に作れるよってので、ふーんSingleってRxかぁと思いながら（よくわかってない
@Client("/hello") public interface HelloClient { @Get Single<String> hello(); }
それを使ったテストを追加してみて
@Shared
HelloClient client2 = embeddedServer
.applicationContext
.getBean(HelloClient)
void "test hello world response2"() {
expect:
client2.hello().blockingGet() == "Hello World"
}
JARにかためて動かしてみた。
❯ java -jar build/libs/hello-world-0.1-all.jar 00:03:59.035 [main] INFO io.micronaut.runtime.Micronaut - Startup completed in 1209ms. Server Running: http://localhost:8080
IoCとかConfigurationのところをざーっと読んで、SpringBootそのままだなと思った。
ひととおりの機能が揃ってるんだなぁって思いながら、Thymeleafもサポートしてるっぽいので作ってみて
Cloud Native Featuresのところは僕はk8s使うと思うからあんまり気にしなくて良さそうだし、サーバーレスは今のところ興味ない。
Jaeger連携もあったので、良くわからないままとりあえず実行だけしといた。
そんなところかなー。面白そう。
先週はこういうことを大阪からのリモートでやってた：
今週は東京に出張だったので、僕も入れて4人で全員同席のモブワークを実験してみた。そしたら、沢山の学びがあった。
今回のモブワークで実験してみたかったのは、モブワークが日常な場。つまり、チームにとってモブワークをすることが普通で、それ以外が非日常な場。
これまでもモブワークはしたことがあったのだけど、モブワークをすることは非日常なことだった。普通はペアで仕事をしていて、たまに「ちょっとモブワークしてみようか？」って言って、特別に集まってたのだ。
そうじゃなくて、モブワークを自然な状態にして、たまに「ちょっと別々に動いてみようか」みたいにすることができたら、ちょっと感じ方が違うんじゃないか？という気がしていた。なので、チームにお願いして試させてもらった。
いつもとは違う場を作りたかったから、通常の席とは別のオープンスペースにモブワーク実験会場を作って全員でそこに集まって開発をしてみた。
朝9時にみんなが会場に集まる。朝会ではコーヒーを飲みながら「今週のゴールに対して今の進み具合はどうか？そして、今日のゴールはどこに定めるか？」みたいな話をする。
それが終わったら学習セッションを始める。お菓子を食べながら、PhpStormのチートシートを眺めてみんなで「おぉ」とか「これは便利」とか言いながら楽しむ日もあれば、プロジェクトの中で気になってたことを相談して楽しむ日もあった。
学習セッションが終わったら、プロジェクトのための開発を始める。ここは毎日時間割を変えてみてた。一人で落ち着いて考える時間を作ってみたり、休み時間を増やしたり減らしたりして、どんな時間割がいいかなーってチームで試行錯誤してた。実はまだしっくりくる時間割は見つかってないので、みんなとは「これからも色んな時間割を実験してみよう」という話をしてる。
夕方には、今日のレビューとふりかえりをして後片付けをして帰る。
今回は、意図的に「全てのタスクに対して全員で取り組むこと」をルールとさせてもらった。つまり、全てのタスクに対して、1つの大きなディスプレイを全員で見ながら、1つのキーボードを使って開発をする、というルール。メインのディスプレイの横にサブのマシンを置いて、ちょっとした調べ物なんかはそちらでできるようにしておいたけど、基本は全員でタスクを進める。
というのも、そういうルールがないと、ちょっとうまくいってないかも？と感じたときに、すぐに元の開発方法に戻ってしまうから。そうじゃなくて、モブワークの中でもがいてみることで、もっと学びを得たいなと考えた。これは実際に当たった。もうちょっとしっくりくるやり方をできないか？と常にチームで試行錯誤することができた。
ちょっと自分の中で葛藤があったのは「モブワークが手段じゃなくて目的になってるんじゃないか？」ということだったが、これは最終的には自分の中で解決した。後で説明する。
モブワークによって、レビューや手戻りがなくなって「終わったと言ったときには終わったのだ！」ってなるのは前回も感じた通りだが、今回の実験によって、それとは別の変化がチームに起こった。
ひとつは、「学び」が当然のものとして開発の中に取り込まれたこと。
何かを学んだときに付箋をはるようにしていたら、毎時間何かが貼られていた。Winキー + ←→でWindowが左右に配置されるというようなことから、VimのVisual-modeまで。以前は学びがあるとは言っても「こんなことも知らなくてすみません」みたいなところがどこかにあったのだけど、今回は「新しい学びを得た！3yy p！」「それは圧倒的成長！！！天才か！！！」とかそういう感じ。
もうひとつの変化は「チーム」になった、ということ。
コードもドキュメントも設計も、これまではどこかに「それを担当したペアが作ったもの」という認識があったんだなって気付かされた。今は「チームとして作ったもの」になっている。だから何かの見落としに後で気づいても「もっとしっかりしてほしいなぁ」とかならずに「あー！しまったー！次はこの観点でも見ることにしよう」と、チームとして全員で協力して改善していける感じ。
さて。そんなこんなで最終日を迎えた今朝の計画のときにメンバーから「進んでるけど進んでない」「もっと速く開発できないだろうか？」という意見が出た。ので、こう返事をした「良いね。昨日までは、どちらかというと『学び』に軸足を置いてたんだよね。だけど、チームとしてのアウトプットに少し重心をずらしてみようか？」。
1週間の中で色々と伝えるためには、ちょうど「破」をしといた方が良いかもなと思ってたので「守」を解いて「じゃ、分担してみよう」という提案をした。「今、このチームは、本当にチームとして機能しはじめてるようにみんな感じてるよね。なので、作業を分担したとしてもこのチーム感をキープしたままにできれば良さそう」
ということで、2人ずつに分かれて作業をしたのだけど、結果としてはこれまでのペアワークとは異なって、チームとしてのペアワークになってたかなと思う。隣のペアの方が詳しそうなことは「ここちょっと手伝って」とか「ここで悩んでるんだけど、どう思う？」とか聞いたり、何か面白そうな話をしてるなーって思ったら、そっちのペアの作業に入ってみたりしてた。
それから、きりのいいところで、お互いの作業過程や結果を共有して、次に進んでいって、昨日までより速く開発を進めることができた。誰かが会議でいないときは、3人で進めてたり、2人と1人に別れたりして、臨機応変に動いてた。チームという「場」になったんだなぁって実感した。
そんな風に開発をしてたら、「スピード」と「学び」と「技術的負債」と「不安」のトレードオフスライダーをどこに置くか、を朝の計画のときに話したら良さそうだね。という意見がでてきた。学びも大切だけど、スピードも大切だから、そのバランスをチームで毎朝確認しながら取り組んでみよう。って。良い気づきだな。
先程の「モブワークが手段じゃなくて目的になってるんじゃないか？」という自分自身からの疑問に対しての僕の答えは「モブワークはプラクティスじゃなくて、チームの在り方だった」。だから、モブワークをやる、ということではなくて、チームで開発をしている、というだけのこと。それは、手段とかそういうのではない。
まだしばらくは意識して「モブワークをやる」ということになるかなとは思うんだけど、それはそのうち単に「チームで開発をしている」ということに溶け込んでしまうんだろうなぁという学びを得た。
そんな感じ。他にも沢山の学びを得たし、なにより、メンバーに恵まれて僕は幸せだなぁ。
この数年は色んな開発チームのサポートをしてるんだけど、最近、その中のひとつのチームに対するサポートの方法を切り替えた。「外からアドバイスをする」から「中に入って実際にやり方を見せる」に。
たまに「どうしてそこまでやる必要があるのか？それで成長できるのか？自分で考えて決断をしていくことで成長するべきではないか？」みたいに考える人もいるかもしれないけど、僕は単にそうした方がそのチームにとって良いなと思っただけ。
「このチームはダメだなー」とかは全く思ってなくて、むしろそのチームのことが好きなので「どうやるのが一番ストレスなく成長できるかなー？」というのを考えた結果の切り替え。
ただ、感覚で動いてしまってるので、自分の頭の中の整理のためと、そのチームも含めて周りの人に説明できるようにするために理由を考えてみたいと思う。たぶん、Management 3.0の7つのレベルのデリゲーション（権限委譲）の部分と照らし合わせてみたら良さそうかなと思ってるので、見てみる。
www.slideshare.net
こんな感じか。
「5. 助言する」かな？何か困ってるって相談されたときに「それはこうすればいいと思うよ」って伝えて、あとはチームが決めて進めるから。あ、でも「6. 尋ねる」と「7. 委ねる」もあるなぁ。「この部分、どうしてそういう決断をしたの？理由だけ知りたい！」とかもあるし、チームが自信があるところはそもそも関わりもしないので。
「2. 説得する」「3. 相談する」「4. 同意する」「5. 助言する」「6. 尋ねる」「7. 委ねる」全部やってるな。「外からアドバイスをする」と比べてみると「2. 説得する」「3. 相談する」「4. 同意する」が追加されたってことか。そうだな、僕が決定に関わるようにしたんだもんな。
チームが全然やったこともないような部分は「2. 説得する」で僕が決めて「その理由はね・・・」って説明するし、チームがちょっと苦手な部分は「3. 相談する」で「どうしたらいいと思う？」って聞いてから「じゃ、これにして進めよう」って話をするし、チームだけで決めるのが難しい部分だったら「4. 同意する」で一緒に考えて決める。
例えば、未経験の部分から考えると
最後は、「この部分はもう任せるー！」になるってことか。
んむー。すっきりした。チームが未経験の部分に突入してるから、その部分は僕が決定してあげるのが一番成長できるかなと思ったってことだな。チームにもこのステップを伝えておくと、成長のためのステップが見えて良さそうだな。ちょっと落ち着いたら、開発の中の色んな部分に対して、チームと一緒にデリゲーションポーカーしてみよっと。
書いた後に思ったけど、最終的には未経験でも自分たちで何とかする力もつけられたらいいな。あとで追記しとこ。
— Mitsuyuki Shiiba (@bufferings) 2019年2月2日
自分たちでサービスの開発と運用をしているチームで、僕がどんなことを考えながらドキュメントを残してるかなぁってのをメモ。
来月の自分が読んで分かりやすいなと思えるドキュメントを残す。
タスクをやってる最中は雑にメモを残していく。体裁は気にしないでとにかく気軽に気づいたことや学んだこと、これは来月の自分に残しておきたいなってことをメモしていく。統一感も何もない。
ここで大切にしたいのは
避けたいのは
ということで、走り書きの雑なメモができあがる。でも大切なことは全部書いてある。
タスクがひとくぎりついたら、メモを見ながらまとめる。
ここで考えるのは、書く人の気持ちじゃなくて、読む人の目線。僕は、来月の自分のことを考えながら書く
から、自分を想像しながら書けばいいので便利。
ポイントは
まとめ終わって要らなくなったメモや、重複する部分は削除する。削除は後になればなるほど「消しても大丈夫なのかな？」ってのが分からなくて難しくなる。
コンフルエンスを使ってるので、削除したページはゴミ箱に入るから、やっぱ必要だったわってなっても戻せる。安心。
情報を残すときに、最後の結果よりも、過程が重要な場合がある。
そういうときは、結果だけじゃなくて、その過程をドキュメントとして残すことが大切。
ということで、ドキュメントを書くときは
って感じか。
これ、コードと一緒だ。
ドキュメントのことを考えてると思ったら、コードのことを考えてた。