スクラムフェス大阪2019( #scrumosaka )でお話しますー

いよいよ22日の昼からスクラムフェス大阪が始まりますー!

www.scrumosaka.org

2日目(23日)の最後にお話しますー。

confengine.com

スクラムを始めたんだけど、自分の現場で具体的にどんな風に実装したらいいかを悩んでる人」に、何かを伝えることができたらいいなって思いながら準備してます!そんな人はぜひ聞きに来てくださいー!

たのしみー(๑•̀ㅂ•́)و✧

開発チームのふりかえり

で、どんな話をしてるかなーって思ったけど、こんな感じかなーって思ったので書き出した。多いかな。

f:id:bufferings:20190215204520j:plain

最初は事実。

  • やったこと
  • 学んだこと

次は気持ち。プラスの方から始める。

  • 良かったなって思ったこと
    • 別に続けたいわけじゃないけど、良かったなってこと。トラブルをみんなでさっと解決できたの良かったなーとか。
  • ありがとうって思ったこと

プラスの気持ちの右の方は、行動してみたいこと

  • 続けたいなって思ったこと
  • やめてみたいなと思うこと

次にマイナスの方。マイナスは、他人に対して向けない。場や状況それと自分自身に向ける。

  • もやっとしてること
    • もやっとしてるけど、特に何もアクションを望んでるわけじゃなくて、ただもやっとしてるなってこと
  • 自分自身に対してへこんだこと

マイナスの側の右の方は、より良くするために行動してみたいこと

  • 変えてみたいなと思うこと
  • やめてみたいなと思うこと

で、最後にそこから、チームのアクションを出していく感じかなぁ

  • すぐ取り組むアクション
    • チームでできるもの
  • 長い目でやっていくアクション
    • チームの外の組織とかそういうの

名前をつけるなら何だろう? Done Learn ± Action かなぁって思ったけど語呂が悪いね。

追記

Done Learn Emotion Actionかー!

良い本だったよー→モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

## 2月23日に発売予定

解説を書かれた及部さんからいただきました。ありがとうございます!

今日届いてたのでどんなことが書いてるのかちょっとだけ読んでみようかなーって思いながら、あーわかるーとか言いながら読んでたら、サクッと読み終わってしまった。おすすめです。

f:id:bufferings:20190214233349j:plain:w400

books.rakuten.co.jp

## 読んでみてどうだったか?

良かった!

僕はこれまでに、何度かモブプログラミングを小さく実験してて「ふーむ。これは良さそう」と思ってて。ついに先週は「一週間ずっとモブプログラミングをする」という実験をして、このチームに合ってるなーと感じたので、組織として正式に導入する相談を進めてるところ。

この本には、そんな僕達が学んだり、悩んだり、試行錯誤したり、実感したりしたことの多くが書いてあって、笑った。先に読みたかったわ。

## どういう人におすすめ?

こういう人かな:

  • モブって何が良いの?って思ってる人
  • モブって面白そうだけど、どうやって始めたらいいの?って思ってる人
  • モブやってみてるけど、色々悩む!って人
  • モブやってみたけど、うまくいかんかった!って人
  • モブうまくいってるけど、この後どうやってったらいいかなー?って思ってる人

## やり方だけじゃないよ

この本に書いてあるのは「モブプログラミングのやり方」だけじゃないです。

モブプログラミングの始め方から、よくある落とし穴、軌道修正の観点や、チームとしての人と人とのコミュニケーションまで、モブプログラミングをやるにあたって知っておくと良いことがたくさん紹介されてます。

## 便利とあるある

僕が感覚だけで「モブプロ、なんて言ったらいいか分からんけど、やってみたら確かに良いわー」ってのを、具体的な言葉にしてまとめてくれてるので便利。そういうことだったのか!という気持ち。これで、マネージャーに「効率悪そう?」って聞かれたときでも、具体的に説明できそうー。

あと、チーム内でスキルの高い人がタイピストやってしまって、周りのメンバーがついていけてなかったりするよ?って書いてあって、したわ!ってなったし。別に常に全員が一緒のことやってるってわけじゃないよって話も、そうそう、あー、そういう分け方もあるのかーって思いながら読んだりしてた。

## 今後

今後はモブプログラミングをがつがつやっていくつもりなので、チームのフェーズに合った章をそのつど読んでみて参考にしながら「チームで一緒に働く」ということをよりいっそう楽しもうと思います!

面白かったー!

自分用メモ:Micronautを初めて触ってみた

公式ドキュメントを読みながら、特に深く考えずにちょこちょこ触ってみたのをメモ。

公式ドキュメント: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もサポートしてるっぽいので作ってみて

f:id:bufferings:20190212001243p:plain:w200

Cloud Native Featuresのところは僕はk8s使うと思うからあんまり気にしなくて良さそうだし、サーバーレスは今のところ興味ない。

Jaeger連携もあったので、良くわからないままとりあえず実行だけしといた。

f:id:bufferings:20190212001929p:plain:w300

## ざーっと見た感想

  • DBとつないでAPIとしてデータを返してみたい
  • テンプレートエンジンも使ってみたい
  • Kafkaとの連携でイベント処理をしてみたい
  • メトリクス周りどんな感じなんだろうな?
  • GraalVMのnative image作成で遊んでみたい

そんなところかなー。面白そう。

モブワークがチームの中に溶け込んでしまうということ

## 今週は全員同席モブワーク

先週はこういうことを大阪からのリモートでやってた:

bufferings.hatenablog.com

今週は東京に出張だったので、僕も入れて4人で全員同席のモブワークを実験してみた。そしたら、沢山の学びがあった。

## 実験:モブワークが日常な場

今回のモブワークで実験してみたかったのは、モブワークが日常な場。つまり、チームにとってモブワークをすることが普通で、それ以外が非日常な場。

これまでもモブワークはしたことがあったのだけど、モブワークをすることは非日常なことだった。普通はペアで仕事をしていて、たまに「ちょっとモブワークしてみようか?」って言って、特別に集まってたのだ。

そうじゃなくて、モブワークを自然な状態にして、たまに「ちょっと別々に動いてみようか」みたいにすることができたら、ちょっと感じ方が違うんじゃないか?という気がしていた。なので、チームにお願いして試させてもらった。

いつもとは違う場を作りたかったから、通常の席とは別のオープンスペースにモブワーク実験会場を作って全員でそこに集まって開発をしてみた。

## 1日の流れ

朝9時にみんなが会場に集まる。朝会ではコーヒーを飲みながら「今週のゴールに対して今の進み具合はどうか?そして、今日のゴールはどこに定めるか?」みたいな話をする。

それが終わったら学習セッションを始める。お菓子を食べながら、PhpStormのチートシートを眺めてみんなで「おぉ」とか「これは便利」とか言いながら楽しむ日もあれば、プロジェクトの中で気になってたことを相談して楽しむ日もあった。

学習セッションが終わったら、プロジェクトのための開発を始める。ここは毎日時間割を変えてみてた。一人で落ち着いて考える時間を作ってみたり、休み時間を増やしたり減らしたりして、どんな時間割がいいかなーってチームで試行錯誤してた。実はまだしっくりくる時間割は見つかってないので、みんなとは「これからも色んな時間割を実験してみよう」という話をしてる。

夕方には、今日のレビューとふりかえりをして後片付けをして帰る。

## 守

今回は、意図的に「全てのタスクに対して全員で取り組むこと」をルールとさせてもらった。つまり、全てのタスクに対して、1つの大きなディスプレイを全員で見ながら、1つのキーボードを使って開発をする、というルール。メインのディスプレイの横にサブのマシンを置いて、ちょっとした調べ物なんかはそちらでできるようにしておいたけど、基本は全員でタスクを進める。

というのも、そういうルールがないと、ちょっとうまくいってないかも?と感じたときに、すぐに元の開発方法に戻ってしまうから。そうじゃなくて、モブワークの中でもがいてみることで、もっと学びを得たいなと考えた。これは実際に当たった。もうちょっとしっくりくるやり方をできないか?と常にチームで試行錯誤することができた。

ちょっと自分の中で葛藤があったのは「モブワークが手段じゃなくて目的になってるんじゃないか?」ということだったが、これは最終的には自分の中で解決した。後で説明する。

## 2つの変化

モブワークによって、レビューや手戻りがなくなって「終わったと言ったときには終わったのだ!」ってなるのは前回も感じた通りだが、今回の実験によって、それとは別の変化がチームに起こった。

ひとつは、「学び」が当然のものとして開発の中に取り込まれたこと。

何かを学んだときに付箋をはるようにしていたら、毎時間何かが貼られていた。Winキー + ←→でWindowが左右に配置されるというようなことから、VimのVisual-modeまで。以前は学びがあるとは言っても「こんなことも知らなくてすみません」みたいなところがどこかにあったのだけど、今回は「新しい学びを得た!3yy p!」「それは圧倒的成長!!!天才か!!!」とかそういう感じ。

もうひとつの変化は「チーム」になった、ということ。

コードもドキュメントも設計も、これまではどこかに「それを担当したペアが作ったもの」という認識があったんだなって気付かされた。今は「チームとして作ったもの」になっている。だから何かの見落としに後で気づいても「もっとしっかりしてほしいなぁ」とかならずに「あー!しまったー!次はこの観点でも見ることにしよう」と、チームとして全員で協力して改善していける感じ。

## 破

さて。そんなこんなで最終日を迎えた今朝の計画のときにメンバーから「進んでるけど進んでない」「もっと速く開発できないだろうか?」という意見が出た。ので、こう返事をした「良いね。昨日までは、どちらかというと『学び』に軸足を置いてたんだよね。だけど、チームとしてのアウトプットに少し重心をずらしてみようか?」。

1週間の中で色々と伝えるためには、ちょうど「破」をしといた方が良いかもなと思ってたので「守」を解いて「じゃ、分担してみよう」という提案をした。「今、このチームは、本当にチームとして機能しはじめてるようにみんな感じてるよね。なので、作業を分担したとしてもこのチーム感をキープしたままにできれば良さそう」

ということで、2人ずつに分かれて作業をしたのだけど、結果としてはこれまでのペアワークとは異なって、チームとしてのペアワークになってたかなと思う。隣のペアの方が詳しそうなことは「ここちょっと手伝って」とか「ここで悩んでるんだけど、どう思う?」とか聞いたり、何か面白そうな話をしてるなーって思ったら、そっちのペアの作業に入ってみたりしてた。

それから、きりのいいところで、お互いの作業過程や結果を共有して、次に進んでいって、昨日までより速く開発を進めることができた。誰かが会議でいないときは、3人で進めてたり、2人と1人に別れたりして、臨機応変に動いてた。チームという「場」になったんだなぁって実感した。

## トレードオフスライダー

そんな風に開発をしてたら、「スピード」と「学び」と「技術的負債」と「不安」のトレードオフスライダーをどこに置くか、を朝の計画のときに話したら良さそうだね。という意見がでてきた。学びも大切だけど、スピードも大切だから、そのバランスをチームで毎朝確認しながら取り組んでみよう。って。良い気づきだな。

## チームの在り方

先程の「モブワークが手段じゃなくて目的になってるんじゃないか?」という自分自身からの疑問に対しての僕の答えは「モブワークはプラクティスじゃなくて、チームの在り方だった」。だから、モブワークをやる、ということではなくて、チームで開発をしている、というだけのこと。それは、手段とかそういうのではない。

まだしばらくは意識して「モブワークをやる」ということになるかなとは思うんだけど、それはそのうち単に「チームで開発をしている」ということに溶け込んでしまうんだろうなぁという学びを得た。

そんな感じ。他にも沢山の学びを得たし、なにより、メンバーに恵まれて僕は幸せだなぁ。

チームを育てるのに7つのレベルのデリゲーションを考えてみる

この数年は色んな開発チームのサポートをしてるんだけど、最近、その中のひとつのチームに対するサポートの方法を切り替えた。「外からアドバイスをする」から「中に入って実際にやり方を見せる」に。

たまに「どうしてそこまでやる必要があるのか?それで成長できるのか?自分で考えて決断をしていくことで成長するべきではないか?」みたいに考える人もいるかもしれないけど、僕は単にそうした方がそのチームにとって良いなと思っただけ。

「このチームはダメだなー」とかは全く思ってなくて、むしろそのチームのことが好きなので「どうやるのが一番ストレスなく成長できるかなー?」というのを考えた結果の切り替え。

ただ、感覚で動いてしまってるので、自分の頭の中の整理のためと、そのチームも含めて周りの人に説明できるようにするために理由を考えてみたいと思う。たぶん、Management 3.0の7つのレベルのデリゲーション(権限委譲)の部分と照らし合わせてみたら良さそうかなと思ってるので、見てみる。

www.slideshare.net

## 7つのレベルのデリゲーション

こんな感じか。

  1. 伝える:私が決定し、チームに伝える
  2. 説得する:私が決定し、チームを納得させる
  3. 相談する:チームに相談してから、私が決定する
  4. 同意する:チームと一緒に決定する
  5. 助言する:助言はするが、チームが決定をする
  6. 尋ねる:チームが決定し、後で私を納得させてもらう
  7. 委ねる:チームが決定し、私は気にしない

## 「外からアドバイスをする」は、どこかな?

「5. 助言する」かな?何か困ってるって相談されたときに「それはこうすればいいと思うよ」って伝えて、あとはチームが決めて進めるから。あ、でも「6. 尋ねる」と「7. 委ねる」もあるなぁ。「この部分、どうしてそういう決断をしたの?理由だけ知りたい!」とかもあるし、チームが自信があるところはそもそも関わりもしないので。

## 「中に入って実際にやり方を見せる」は、どこかな?

「2. 説得する」「3. 相談する」「4. 同意する」「5. 助言する」「6. 尋ねる」「7. 委ねる」全部やってるな。「外からアドバイスをする」と比べてみると「2. 説得する」「3. 相談する」「4. 同意する」が追加されたってことか。そうだな、僕が決定に関わるようにしたんだもんな。

チームが全然やったこともないような部分は「2. 説得する」で僕が決めて「その理由はね・・・」って説明するし、チームがちょっと苦手な部分は「3. 相談する」で「どうしたらいいと思う?」って聞いてから「じゃ、これにして進めよう」って話をするし、チームだけで決めるのが難しい部分だったら「4. 同意する」で一緒に考えて決める。

## こういう風にやってるってことか

  • 2 説得する:チームが未経験の部分は、私が決定し、チームを納得させる
  • 3 相談する:チームが苦手な部分は、チームに相談してから、私が決定する
  • 4 同意する:チームだけで決めるのが難しい部分は、チームと一緒に決定する
  • 5 助言する:チームが不安に思ってる部分は、助言はするが、チームが決定をする
  • 6 尋ねる:チームが得意な部分、だけど説明することを意識しておいて欲しい部分は、チームが決定し、後で私を納得させてもらう

## 権限移譲のステップ

例えば、未経験の部分から考えると

  1. まずは決定を見せてあげて、未経験→経験はあるけどまだ苦手、にして
  2. そしたら次は「前は僕だけで決めたけど、今度は考えを聞かせて?でも、僕が決めるから安心して」で、考えをもらって
  3. そしたら次は「じゃ、今回はみんなでかんがえて決めよー!」ってなって
  4. その次は「こういう観点があるといいと思うよー」みたいなのを伝えてチームに決めてもらって
  5. んで「お、どうしてそう決めたのか理由を教えてー」って理由を説明できるようにしてもらって

最後は、「この部分はもう任せるー!」になるってことか。

## すっきりした

んむー。すっきりした。チームが未経験の部分に突入してるから、その部分は僕が決定してあげるのが一番成長できるかなと思ったってことだな。チームにもこのステップを伝えておくと、成長のためのステップが見えて良さそうだな。ちょっと落ち着いたら、開発の中の色んな部分に対して、チームと一緒にデリゲーションポーカーしてみよっと。

## 追記

ドキュメントを書くときに考えていること

自分たちでサービスの開発と運用をしているチームで、僕がどんなことを考えながらドキュメントを残してるかなぁってのをメモ。

## 結論から

来月の自分が読んで分かりやすいなと思えるドキュメントを残す。

## タスクをやってる最中は雑にメモ

タスクをやってる最中は雑にメモを残していく。体裁は気にしないでとにかく気軽に気づいたことや学んだこと、これは来月の自分に残しておきたいなってことをメモしていく。統一感も何もない。

ここで大切にしたいのは

  • 情報を残すこと
  • 時間をかけないこと

避けたいのは

  • きれいにかくこと
  • きれいに書かなきゃと思って、内容じゃなくて見た目に時間を取られること
  • 書くの面倒だから、あとにしようってしてしまうこと

ということで、走り書きの雑なメモができあがる。でも大切なことは全部書いてある。

## 次はまとめる

タスクがひとくぎりついたら、メモを見ながらまとめる。

ここで考えるのは、書く人の気持ちじゃなくて、読む人の目線。僕は、来月の自分のことを考えながら書く

  • 忘れっぽくて、今やったことも明日には忘れてるし
  • ドキュメントを読むのが苦手なので分かりやすく書いてないと頭から煙がでる

から、自分を想像しながら書けばいいので便利。

ポイントは

  • どういう立場の人に向けたドキュメントなのかを意識する
    • エンジニアが新機能を開発するときに見るのか、運用するときに見るのか
    • 新しく入ってきた人が見るためのものなのか
    • システムの管理者用なのか、利用者用なのか
    • とかで書きたい内容が変わってくる
  • 全ての詳細をずっと同じレベルで書くのではなくて、段階を経て伝えたいことに届くようにする
    • 全体像→中くらい→詳細
  • 複雑なものは図をひと目見たら伝わるようにする
    • だけど、これも全ての詳細を図に盛り込むんじゃなくて、伝えたいことに焦点を絞った図。
  • 1ページが長くなりすぎないようにする。
    • 読んでるうちによく分からなくなるから。
  • かといってページ数が多くなりすぎないようにする。
    • 読む気がしないから。
  • それから、ページの階層が深くなりすぎないようにする。
    • どこまであるんや、って迷子になるから。

## それから削除する

まとめ終わって要らなくなったメモや、重複する部分は削除する。削除は後になればなるほど「消しても大丈夫なのかな?」ってのが分からなくて難しくなる。

コンフルエンスを使ってるので、削除したページはゴミ箱に入るから、やっぱ必要だったわってなっても戻せる。安心。

## 過程が重要な場合

情報を残すときに、最後の結果よりも、過程が重要な場合がある。

そういうときは、結果だけじゃなくて、その過程をドキュメントとして残すことが大切。

## まとめ

ということで、ドキュメントを書くときは

  • 「書き出す」と「まとめる」を分ける
  • 書く人の気持じゃなくて、読む人のことを考えて書く
  • 重複する情報は削除する
  • 過程が重要な場合は、結果だけじゃなくて過程もドキュメントとして残す

って感じか。

## あれ?

これ、コードと一緒だ。

  • まずは動くようにしてから、リファクタリング
  • 読む人のことを考えて書く
  • 重複は削除
  • コードにあらわれてこない部分をコメントに残しておく

ドキュメントのことを考えてると思ったら、コードのことを考えてた。