最近ホテルの部屋に風呂があるかどうかを重要視しないようになった。ホテル外のサウナに行くのが当たり前になったからだ。部屋にあるのはシャワーだけでよいということになってきた。きれいでシャワーあればいい説。
Regional Scrum Gathering Tokyo 2020に参加した
遅くなったけど書き残しておく。
はてなでは、スクラムマスターや開発プロセス、チームビルディング等に興味ある人たちで構成される、すくすく開発会という場がある。ここで 
id:daiksy に教えてもらったことがきっかけでRegional Scrum Gathering Tokyo 2020に参加することになった。
スクラム関係のカンファレンスに参加するのは初めてだったのだが、以下のツイートのようにとてもよい体験をすることが出来た。
https://twitter.com/hokkai7go/status/1214839105227354112
一番良かったのは、Coach's ClinicでSREチームでスクラムマスターをやるうえでの悩みをryuzeeさんに相談できたことだった。この相談をきっかけに、割り込みタスクの棚卸しや分析について取り組んでみることに決めた。チームの振り返り前にデータを集めておく感じでやろうかなと思っている。割れ窓タイムでトイル削減への継続的な取り組みは出来ているものの、それでもなかなかトイルや継続的な改善活動は進んでいかないという悩みがある。
他には、スプリントでは50%くらいは失敗しなさいという発言とか、フラクタルスプリントというものの存在など、参加して聴講して会話することでかなりの刺激をもらうことができた。
すくすく会や所属チームへのフィードバックだけでなく、外部にもこうした内容の発信を今年は増やしていきたいと思う。
Codewarsでプログラミングを学び始めた
SREとなって一年以上が経ちコードを書く機会が増えた。プログラミングに対しては以前から苦手意識があったが、そうも言ってられないなと思いプログラミングの継続的な学習に対して行動をし始めた。きっかけとなる出来事はもう一つあり、密かに尊敬しているTwitterのフォロワーがこのあとに挙げるサービスを使って勉強をしている様子が垣間見えたということも大きかった。
何かWeb上でプログラミングを学習しようと思ったので、以下の観点で探してみた
- 学習したいプログラミング言語があるか
- いろんな書き方が学べるか
- 自分のレベルに合っていそうか
自分は今Rubyを書いているし、一番書ける言語はRuby(もしくはシェルスクリプト)という感じなので、Rubyを学べることは最大の要件だった。また、Go言語の学習も少し先に必要になることがわかっているので、RubyもGo言語も学べるところが良いなと思った。
そんななか、TwitterのフォロワーがCodewarsでRuby勉強している投稿をしていて気になったのでCodewarsを使い始めた。
Codewarsで良かったと思うことがいくつかある
- 課題ごとに使う言語を選べること
- 提出前にテストコードを通す必要があるのだが、TDDのRed, Green, Refactorのサイクルを試しやすい
- コードを提出すると、他の人が書いたよりスマートな解答を見ることができる
- 問題文が英語なので英語も学ぶことができる
AtCoderで競技プログラミングをするという選択肢もあったが、少し学びたい内容とはズレていそうだったので今回は検討から外した。
コードクロニクルも触ってみた。冒頭のノベルゲー部分は、ノベルゲーよろしくスキップかオート機能があるといいなと思った。適切なレベルから始められるといいかもしれない。
2019年を振り返る
仕事がそこそこ盛り上がっていることと、副業もやっていてギリギリまで仕事が納まらなかった。なんとなく大掃除をして、紅白とガキ使を断続的に入れ替えて見ていたら振り返りを書こうという気持ちになったので書いておく。2018年は時系列で振り返っていたが、2019年はテーマごとにピックアップする形にする。そば茹でてたら年内に間に合わなかった。
仕事
2018年のテーマはレガシィとの向き合いだった。ここで言っているのはレガシィなシステムやソフトウェアのことだと思ってもらえればいい。レガシィ大変。過去の経緯に引っ張られることで、崖に一人取り残された気持ちで仕事をするタイミングがちょこちょこあった。京都で新規建造物を作ろうとしたら地下から出土品が出てきて、出土品の調査をしつつ新しい建造物(ソフトウェア)を作っていくような仕事の様子ですと振り返りの中で表現した。物理的な建築物と違ってどちらも同時に進められそうに思ってしまうから不思議だ。幸いなことにこういう気持ちになったことをある程度正直にチームの振り返りで話すこともできているし、かなり手助けを得ることが出来ている。本当にチームに感謝している。こうしたレガシィとの向き合いを少しはブログにまとめることができた。
https://blog.hokkai7go.jp/entry/regeneration-legacy-reverse-proxy
このブログを書いたのは2月だったが年末にかけてもっとヘビーなものと闘うことになる。これはまだ終わっていないのでまとめられていない。いつかアウトプットしたいと思う。2019年はいくつか登壇することができた。これまで自分の引き出しになかったスクラムやチーム関係の話題での登壇に挑戦できたし、内外の反応も良かったようでうれしい。
https://blog.hokkai7go.jp/entry/sre-lounge8 https://blog.hokkai7go.jp/entry/devlove-kansai-sre-scrum https://blog.hokkai7go.jp/entry/jtf2019-hatena-sre-scrum
私生活
2019年の年始から京都に住み始めて10ヶ月で大阪に引っ越し結婚した。大きく人生が動いたしどんどんと生活の拠点が西に動いていっている。西日本なんか良いです。JAL修行を完了できたのもよかった。
ライブ
2019年は18回くらいライブに行ったらしい。WHY＠DOLL解散の前に見ておけてよかった。だいたいBiSH関係だけどそれ以外だとエヴァンゲリオンのオケはよかった。昔行ったスターウォーズのやつと同じくらいワクワクした。2020年もそこそこライブ行きたい。
はてなSREチームにおけるスクラムの実践というタイトルでJuly Tech Festa2019に登壇します
こんにちは 
id:hokkai7go です。この記事は、はてなエンジニア Advent Calendar 2019の7日目です。
掲題の通りですが、「はてなSREチームにおけるスクラムの実践」というタイトルでJuly Tech Festa2019に登壇します。一つ前のエントリで触れていた、定期的な振り返りの振り返りはこちらの登壇内容に関係したものでした。自分の発表は会場Cにて、13:00-13:45(45min)の枠です。
話す内容
資料はこちらです。
http://slides.hokkai7go.jp/jtf2019-hatena-sre-scrum.pdf
直リン注意。(蛇足ですが、これまでSpeakerdeckを使っていましたが、日本語フォントの中身が白っぽくなり、スカスカになってしまう現象があったので資料をそのまま共有する形にしてみました。)以前DevLOVE関西で話したもののパワーアップ版となっています。チームビルディングの話題、スクラムの実践に関する観点、振り返りの振り返りをしてみた内容などを追加しました。
元同僚のゆううきさんに以下記事でDevLOVE関西での発表資料を紹介してもらえました。ありがとうございます。
ゆううきさんの記事には以下のように書かれています。
SREではトイルを削減したり、システムの停止時間を短くしたりするため、ソフトウェアエンジニアリングに注力することになります。このため、ソフトウェア開発でよく用いられるアジャイル開発のようなプラクティスを適用する流れは、自然な成り行きと言えるでしょう。
まさにこの通りです。スクラムのプラクティスや、独自で始めた取り組みとそれらの理由や効果などをお話します。以前の発表についてはこちら。
次の はてなエンジニア Advent Calendar 2019 の担当は 
id:kouki_dan です。お楽しみに！
定期的な振り返りの振り返りをやってみたら面白かった件
スクラムの実践に関する登壇資料を作っている。正確には以前発表した内容の解像度が低い部分について分析して、より明確な内容にして発表資料をパワーアップさせているという方が実態にあっている。
自分がスクラムマスターをやっているチームのあるタイミングの振り返りから、自分たちのスクラムのプロセスを変えようとする発言が出てくるようになったのだがその理由を探るために、過去15回分くらいの振り返りシートを振り返ってみた。 （自分がスクラムマスターをやっているチームではKPTというフレームワークを使い、2拠点つないで振り返りを行うためスプレッドシートにKPTを記入して振り返りを行っている。） すると、あるタイミングから目線がチームに向いている発言がちらほら出るようになってきたことに気がついた。何が要因なのだろうとチームイベント等を分析してみたところ、新しいメンバーが入るタイミングで他チームからファシリテーターを呼んでチームビルディングをしたこととか、他チームからファシリテーターを呼んで振り返りを行ったことが要因の一部として考えられるのではないかと思うようになった。
他にも要因として考えられるものはあったのだが、確信してると言うには弱いかなと思うものなのでここでは省略したい。
言うまでもなく、チームやメンバーの置かれている状況、ファシリテーターの技量によるところも大きいのだが、外部からファシリテーターを呼ぶことの意義は大きいのかもしれないと思えたのだった。また振り返りの振り返りをやったことで気がつくことがあればこうして記事を書きたいと思っている。
型に不慣れな自分がGo言語でハマったところ
たまには失敗というか躓いたことも書いておこうと思ったので記事にしてみた。
これまで社内勉強会とかでスターティングGo言語の読書会とかはやったことがあり、なんとなく触れると思っていたのだが本番環境で動くコードを書く段になったところ大いにハマったのでその記録をしておこうと思う。
型合わせに時間が吸われる
一番苦しんだのはこれだと思う。
VS CodeのGo言語用拡張などをインストールしていたが、ある程度慣れてないとコンパイラやLinterが怒っている意味さえも掴みきれなかった。会社SlackでGo言語チャンネル等で質問して助けてもらうことが何度かあった。
Rubyで言うpry/irbで小さなコード片を書いて試しながらプログラミングしていくスタイルがとれなかったことでガクッと効率が落ちた
慣れているRubyでプログラミングするときにはpryやirbで変数の中身を見つつやっていっているのだが、こうしたスタイルでの開発ができてなくて最初のうちは困っていた。しかし今ではデバッガを使うことを覚えたので幾分かマシになっている。しかもgo replで調べてたらgoreというものがあることを知った。うちのCTO氏製ツールじゃん。使っていこう。
ドキュメントを読む際の勘所がわかっていない
イマイチ説明が難しいが、Go言語の公式やSDKのドキュメントを読み解くのに時間がかかっていることに気がついた。
ポインタを扱うのが久しぶり過ぎて忘れていた
https://future-architect.github.io/articles/20190713/
この記事を見てポインタのこと完全に思い出した。
Table Driven Testをはじめとして、テストがとっつきにくいと感じた
言語化むずかしいけどテスト書くタイミングで手が止まりがちだった。
まとめ
趣味で触る範囲ではハマらなかったであろうが、仕事だからあれこれハマって勉強になったという体験をできた。達人プログラマーで、全然違うプログラミング言語触ってみるといいといったことが書かれていたが本当にやってみるといろいろあるなと思った。
