YAPC::Tokyo 2019に参加してきた

はじめに

これです yapcjapan.org

はてながスポンサーになっていたのでスポンサーチケットで参加させてもらった。誰か行きませんかと社内で募集があったので手を挙げた感じ。同僚の id:papix が運営を頑張っているとJPA方面の方からも聞いていたので、行かない選択肢がなかった。社内に共有したメモから抜粋して感想等を書いておく。

Perlは勉強中で、最低限さくさく読めるようになろうとしているところ。

冬のPerl

Perl 5.28

Perl 5.30

  • 多少のパフォーマンス改善
  • Unicode11
  • なんかいっぱいエラーになるものがあるらしい

Perlを取り巻く状況

  • cpanのactive authorはだいぶ減っている
  • CPAN Pull Request Challengeが4年以上続いていた
  • Perl::LanguageServer
  • Perl 6.d がリリースされました

2019年の開発予定

  • MoarVMの最適化、部分的エスケープ解析
  • 高速化
  • 並行・並列処理

Rakudoとか、MoarVMとかわからん

広木大地さん講演

資料: ２つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deck

2つのDX - 開発者体験 - 企業のデジタル化

組織構造

  • 不確実性を減らすといい。減らすと生産的になれる
  • 組織も不確実性を減らしていく
  • 多くの不確実性に応えられるチームほど生産的
    • エンパワーメント型

コミュニケーション

  • エンジニアは否定ばっかりだから…というツイートがバズっていたが物事をはっきりさせたい様子が、否定形に見えてしまうのではないか
  • 情報の非対称性を減らすことがコミュニケーションなのではないか
  • コミュニケーションは、常識の距離が近いほど簡単。コンテクストが受け入れやすいから。常識の距離が遠くなるとコミュニケーションは難しくなる。このズレをすり合わせていけるのがコミュニケーション能力なのではないか

ダンバー数 https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%B3%E3%83%90%E3%83%BC%E6%95%B0

  • 明晰な言語化という意味だと、立法行為と同じことをしているのでは
  • 我々エンジニアはコミュニケーションそのものをしている
  • 学習を促す心理状態になれば、本能を克服できる
  • 心理的安全性と責任の両方が高ければラーニングゾーンに行ける
  • 本能的機能は組織にも適応される: ゲシュタルト原則
  • 問題は、構造にこそあるのではないか。構造をリファクタリングする
  • ソフトウェアづくりはコミュニケーションそのもの

  • こういったことを考えていると、ポエムでしょ？と言われる

    • ソフトウェア開発を誤解した反応だと思うとのこと

  • ★ 要求インスペクション、よくわからんかった

    • 懇親会で聞いた: ペアプロ/モブプロも品質改善をするが、プロダクトオーナーと要求インスペクションをやることで、より上流工程での品質改善ができて効果も高いよってことだった。
  • コード解析より組織構造解析によるバグ予測のほうが成績がいいこともある
  • QCDのトリレンマを超える

よいチームの傾向

  • 関わる人数が最小限度
  • チームが本能的な恐怖を克服する方法を知っている ★これもよくわからなかったな
    • 懇親会で聞いた: →チームが組織学習できる心理的安全性があるとわかっている状態になっているかということ。なるほどね。
  • 多様性のある状態から認識を揃える力がある

組織構造とリファクタリング

  • 社内にも取引コストはある
  • 変えようとするとコストが非常にかかるものと簡単にできるものは、取引コストによって変わる
  • 組織設計とアーキテクチャの関係
    • 相互に影響を与え合う
  • システムは時間を経ると交換可能性を失ってコントロールを喪失する
  • ホールドアップ問題 - Wikipedia
  • なぜ多くのエンジニアは「技術的負債現象」と表現せざるを得なかったのかという論点
  • 見えてしまったら技術的負債ではないのかもしれない
  • 両利きの経営

結論と感想

  • エンジニア以外の職種においても情報の非対称性が解決され、エンジニアのDX(開発者体験)と、会社としてのDX(デジタルトランスフォーメーション)が同一になること
  • すごく納得した。どういうこと？と思われる方がいれば、エンジニアリング組織論への招待を読んでみることをおすすめする
  • 併せて読みたい: 「チームが機能するとはどういうことか」を読んだ感想 - 実はhokkai7go](https://blog.hokkai7go.jp/entry/2017/02/07/090655)

Dive into MySQL Error

資料

t.co

MySQLのエラー

  • エラーの分類
    • MySQLサーバのエラー
    • クライアントネガティブ応答
    • クライアントライブラリの異常
  • ネガティブな応答
  • 余談
  • MySQLエラーパケット
  • 先頭FF固定

エラーコード分類

  • 1000系がサーバ
  • 2000系がクライアントサイドエラー
  • 3000番台 5.7から
  • それ以上は8から

エラーコード分類による切り分け

  • 1000番台ならサーバ系
  • 2000番台ならクライアント
  • という切り分けはできる。まずはこれらと、3000番台なのかどうかを見る
  • syntaxのバリデーションはクライアントサイドではしない。

perror

  • perror というツールで調べられる
  • 2003番のエラーでも、どこでタイムアウトするかによってちょっと違う
  • MySQL has goneとか、サーバサイドの問題も一部2000番台に含まれている
  • 2059番 デフォルトの認証プラグインが変更された。古いクライアントから接続しようとすると、このエラーが出る
    • 5.7からは接続できるが、5.6以下はこれが出る
  • slaveはクライアント
    • エラーを起こすと、1000, 2000番台のエラーに従う
  • エラーメッセージ実は日本語にできる
    • 3000番台以降は日本語対応されていないからプルリクチャンスかもしれない
  • perror
    • 引数にエラーコードを受けて、内容を返す
  • 1593は、Fatal errorだけが決め打ちで、それ以降は状況次第で出し分けている。ググりにくい
  • エラー番号が分かれば、grepしやすい
  • プラガブルストレージエンジンのログ

まとめ

エラーメッセージを身近に感じてほしいとのこと。調べ方のためにもソースコードやドキュメントを読んでおくのは良さそうと思った。

Keynote

tokuhirom

  • PSGI/Plack
    • HTTP:Engineのリプレースプロジェクト
    • 他言語だと仕様と実装が分離されている。たとえばRack
    • 徹夜して書いたライブラリの話をフルセッションでやるのが許された牧歌的な時代
  • Amon2
  • Teng
    • O/R Mapper
    • 当時kamipoさんが言うところのクソクエリが話題になっていた
  • Furl

perldoc.jpの翻訳作業をやる人が一人しかいない。コントリビュートチャンス

さいごに

いい刺激をもらえた。onkさん、Songmuさんの発表の両方で感じたが、Rubyなど他言語のよいところを輸出入するという考え方はとてもよい。何の言語やツールかはわからんけど、なにかコードやドキュメントを書くことでの貢献をもう少しできそうかもという思いを持った。小さく始めて継続できる感じを探ってみたい。LOCAL学生部の人達に学生交通費支援制度あるってーと宣伝しておいたら本当に北海道から数人来てくれていて最高だった。学生同士でもワイワイしていたし、そこらへんにいたバリバリやっているエンジニアたちとも交流していたようだったのでとてもよかった。尊い。

はい。それは私です。S.O.Sって曲最高だし、MAHO EMPiRE最高だよねと話した。尊い。

LOCAL Community Summit 2019を主催しました

イベント概要

LOCAL Community Summit 2019(以後LCS2019と表記します)というイベントを1/19(土)に行いました。 これです。

local.connpass.com

過去に2回実施しており、2年ぶり3回目の開催となりました。

blog.hokkai7go.jp

blog.hokkai7go.jp

一般社団法人LOCAL(以下、LOCAL)という、「北海道の技術者コミュニティを盛り上げよう」という目的の団体の理事をやっていて、東京でもイベントやろうよ！って趣旨のものです。

イベントの説明はこんな感じです。

LOCAL Community Summit (LCS) は、

地方のエンジニアやコミュニティの取り組みを、地元だけではなく東京でも発表してみよう！
私達の地域の楽しさを、他の地域のエンジニアにも伝えよう！
地元を離れ首都圏で活躍しているエンジニアや、いろんな地域のコミュニティと繋がろう！
というテーマのもと、一般社団法人LOCALが北海道を飛び出し、東京で開催しているIT系勉強会イベントです。

今回は札幌地域へのU・Iターン促進イベント #みんなの札幌移住計画4 との同時開催で、「コミュニティ運営とエンジニアとしての成長」などをキーワードに、多彩なゲストをお招きして開催します。

札幌市への移住イベントとの同時開催という形でした。ちなみにLOCALは北海道の技術コミュニティに着目しており、札幌だけが北海道ではないと日々思いながら活動しています。もちろん、札幌は大好きです。

今回の特色

今回は、明確には募集ページには書いてないのですが、セッションごとにそれぞれセッションオーガナイザー的な人を置き、テーマぎめから登壇者確保までをやってもらう形にしました。後述する941さんの登壇内容から聞いたのですが、MANABIYAさんのカンファレンスでは、明確にセッションオーガナイザーが置かれていてオーガナイザーごとにその枠の取りまとめを行う形になっているそうです。それ、いいな。主催者の負担はできるだけ下げたい。

担当したセッション

僕は実行委員長役とSession1,2を担当していて、僕がどうしても直接聞きたかった人たちにお願いすることにしました。そーだいさんの「私とコミュニティと生きる道」という話と、941さんによる「エンジニアに愛される技術イベントを運営するために必要なもの、それは愛」という話です。どちらも自分の思っていたとおりにいい感じになって開催者冥利に尽きる感じでとてもありがたいですね。

そーだいさんセッション

soudai.hatenablog.com

ブログにも書いてもらっていました。激エモですね。私信ありがとうございます。真面目なことも書くと、LOCALという仕組みは先駆者が作ってくれた良い仕組みだと思っていて、他の地域でもあると良さそうと思っています。簡単に言うと北海道における技術コミュニティをつなぐというメタなコミュニティです。コミュニティ同士をつなげるというの、その地域を盛り上げるために意味があると思うんですよね。そのうえで、北海道と他地域をつなげようというのがLCSのやりたいことなのでした。京都に移住したこともあり、関西コミュニティとの出会いが少しずつあるので、また何かやりたいかもなと思い始めています。

それな。すごくわかります。

そう。コミュニティって、あなたなんですよね。この話を明確に説明しているとても良い記事があります。るびまという、Rubyist向けのマガジンには巻頭言があり、このようなことが書いてあります。とても好きな一文です。

コミュニティとは誰か。もちろん、あなたのことだ。あなたがコミュニティであり、 それ以外にコミュニティはいない。あなたのような人々の集まりを、コミュニティと呼ぶのだ。

コミュニティの新陳代謝についても触れられていて、思うところが多いセッションでした。

941さんセッション

941さんはこうおっしゃってるんですが、実際少し早めに終わったものの会場も盛り上がっていて質問がじゃんじゃん出てきていてとてもよい空間でした。何を思って、どういう苦労をして技術イベントをやっているかという話を、まさにイベントを主催している最中に聞けてとてもよかったです。

このtweetがいちばんきれいにまとまっていてありがたい感じです。絵文字って大事。

飲み会の幹事から始まり、1000人以上の規模にもつながるとはすごいですね。

はい！わかりました。

ほかセッション

ほかセッションについては、onodesとT_akmsが担当してくれました。 suzukiさん、jkudoさん、T_akmsの三人はよく知っていると思っていたけど、全然知らない興味深い話がでてきていて面白かった。特に、エンジニアのためのマネジメントキャリアパスを読んだ後だったからか、suzukiさんのキャリアパスに興味津々だった。

富良野から来ている、@tomio2480 (FuraIT)の話は年々凄みを増していて良すぎました。旭川や富良野で学生さん向けのIT勉強会をやっている方です。

やっぱり後から見直しても何を言っているかわからないが、技術よりも場と人脈をつないでいくのが大事というのはとてもよくわかります。

話のつかみで豚汁の話が飛び出して、どんどんコミュニティの話になっていき、気がついたらめちゃくちゃ示唆のある話が押し寄せてきて、なるほどこれは現代落語のようなセッションだなと思いました。

学生に対しても、「僕は明日いなくなる。」と伝えてコミュニティ運営をしているのってすごいことだと思いませんか。常に属人性排除に向けて手を打つことを言っているわけでしょう。なかなか真似できない。この話を聞けて本当に良かった。

LT

OSC北海道参加者の方々は知っているかも知れない、sakuraさんがとてもありがたいLTをしてくれました。月並みかもしれないけど、自分の言葉で感謝を伝えられるのって大事なことだなと思いました。

LT枠埋まるかどうか心配だったのですが、結局5枠すべて埋まりありがたかったです。

合同企画

#みんなの札幌移住計画4合同企画「とことん、私とあなたの札幌移住計画」
#みんなの札幌移住計画4合同企画「仮想札幌市長選」

という2セッションを、合同でやっていただきました。実際に移住した人がLOCAL理事にもいて、彼らも登壇して移住についての質問に答えるというセッションがありました。実際の声が聞けるのはやはりとてもいいことですね。そのうえで、失敗についても語られていて良かったです。

さいごに

大規模イベントではないものの、やはりイベント運営はとても不安になることを思い出しながらやっていました。でも当日を迎えてみると、準備しっかりしたことや、人に任せることが少しずつうまくなってきたのか負担が下がったこともあり、やってよかったという気持ちがギュンギュンと出てきているところです。2018年末の引越から、ここまでの破滅したスケジュールをなんとか事故無く終えることができてとても安心した気持ちです。次回があれば参加したいとか、これまでやってきたことへの感謝をもらえるとか思っても見なかったので、続けてみるものだなーと思ったのでした。何より、参加者や関わった人たちが楽しそうにしている様子を見られたのがよかった。

SRE Lounge #7 に参加してきました

これです。 https://sre-lounge.connpass.com/event/114005/

感想等

とてもよいイベントでした。SREって、そうだよねーと思うところが多かった。SREがカバーする範囲が広いということと、すべてをカバーできる人はいないからお互いにリスペクトして多様性がある状態にしておくのがいいんじゃないかという話があってわかりみが深かった。ここまでが仕事なんでと責任範囲を区切ってしまうことは、DevOpsの考え方的にも自分は違うと思っている。オーバーラップしていくしかないと思う。

ここから先は自分やみんなのツイートを引用したい

そうですね。

Toilの話

toilの話は何度も出ていた。ゆううううううううううううううううううううううき氏のブログは何度も言及されていた。次世代Webカンファレンスがあってすぐだしタイムリーだったのもありそう。

Toilとの闘いの内面についてはこのブログに書かれていることが、なんかすごくすんなりきた。 chroju.github.io

自分が思っているのはこれです。

Toilとの向き合い方についての自分の中での答えは、今の所割れ窓タイムによって継続的に技術的負債や、暗黙的な運用に対して光を当ててみて、長くいるメンバーから歴史的経緯を聞いて改善案を話し合ったりするというものです。下記の記事にまとまっています。他の人達がどうToilと向き合っているのかを知りたい。Toilの計測ももちろん大事だけど、どう制御しているのか。

blog.hokkai7go.jp

まあぶっちゃけると、正直Toilとの向き合い方だよねと思って始めたわけではないんだけど、やってみるとじわじわと良さを感じているところでした。

他

SREのこと、みんなわかってくれていないけど、それは自分たちがうまく伝えられていないからでは？という話へのリアクション

これはまじでありそうですね。エンジニアがエンジニア採用をやる意味もこういうところにあると思う。

さいごに

なんかこんな感じです。次は登壇したいなと思っています。

新年早々Rubyのバージョン上げようとしたらRubyGemsとBundler2の組み合わせで問題にぶつかった

問題

which bundle できてるのに、bundlerの実体がないの？

$ which bundle
/hoge/ruby/bin/bundle
$ bundle
Traceback (most recent call last):
    2: from /hoge/ruby/bin/bundle:23:in `<main>'
    1: from /hoge/ruby-2.5.3/lib/ruby/2.5.0/rubygems.rb:308:in `activate_bin_path'
/hoge/ruby-2.5.3/lib/ruby/2.5.0/rubygems.rb:289:in `find_spec_for_exe': can't find gem bundler (>= 0.a) with executable bundle (Gem::GemNotFoundException)

結論

RubyGemsとBundler2のバージョンの組み合わせによって起こる問題のよう。

昨日、私はBundler 2.0をリリースしました。 そのうちの1つは、BundlerがRubyGems v3.0.0を必要とするように設定したことです。 リリース後、多くのユーザーが本当に新しいバージョンのRubyGemを必要とするBundler 2の問題に直面していることが明らかになりました。 私たちはユーザーからのフィードバックを注意深く聞いていて、RubyGemsの要件を最低でもv2.5.0に緩和することにしました。 この要件を調整する新しいBundlerバージョンv2.0.1をリリースしました。 これによって引き起こされた混乱についてユーザーに謝罪します。

(Google翻訳より)

bundler.io

stackoverflowにもあるように、 The real answer is here if you try to install bundler 2.0.1 or 2.0.0 due to Bundler requiring RubyGems v3.0.0 というのが原因。

stackoverflow.com

対応

gem install bundler -v '1.17.3'

これだけでよかった みなさんも気をつけましょう。よい2019年をお過ごしください

ちなみに

ありがたい記事ですね。 tmtms.hatenablog.com

Bundler Gem 標準添付は延期
Ruby 2.5 に入る予定だったのですが、2.5 リリースには間に合わなかったようです。

間に合っていたらこの件は起きてなさそうだった。2.6に期待。

ざっくり時系列で振り返る2018年

1月

  • id:asonas と渋谷のサイゼで新年を開始 1/3
  • ののた生誕、虹コン 1/7
  • アンナチュラルにハマっていた
  • BiSHカラオケ 1/14
  • 室蘭でSansan勉強会 1/15
  • 北海道でも札幌以外の場所へも還元しようとちょっと頑張っていた頃
  • いくらお金と労力を注ぎ込んだかわからないけど、婚活サイトから付き合うこともあるんだなって思った。救われたけどもう労力かけるのが面倒で嫌かも
  • グレイテストショーマンいい映画だった。音楽もいい

2月

  • The music of john williams: star wars and beyond 2/24
    • 東京フィルとてもよかったです

3月

kamipoさんと現場かぶりしたときには、終演後に感想会をやることがこのときあたりから増えた

  • シェイプオブウォーターもよかった
  • レキシカラオケ 3/10
    • 縛りカラオケおもしろい！
  • 高木和弘無伴奏ヴァイオリンリサイタル～ササノハ２０１８～ 3/28
    • めちゃくちゃ良かった。

今思い出しても、ちょっとよくわからないくらい超絶技巧で良かったです。

4月

  • BiSHライブ 4/21
  • でんぱ組ライブ 4/28
    • 初の遠征でした。ねもちゃんの地元茨城まで。

5月

  • LDD室蘭 5/19 blog.hokkai7go.jp
  • 初のヒゲ脱毛
    • 痛いけど耐えられないほどではなかった。同居人のほうがハマっていてウケた
  • BiSH横アリ 5/22
  • 新規案件の立ち上げをほぼ独力でやることになって、めちゃくちゃ楽しくてやっぱりサービスやアプリケーションエンジニアと関わらないとだめなんだと気がついた。2018年に気がついたことの中で一番良かったことかもしれない。
  • 初めて外資系の採用プロセスに乗るというのを経験できた

6月

  • BiSH x Sads 6/15
  • 2回目の台湾 6/22-24
    • 現地集合現地解散はなかなか調整が大変ということがわかった
    • 台湾そのものと、キャセイのラウンジめちゃくちゃ良い
    • 6年も間をあけず、毎年のように行きたいと思った

blog.hokkai7go.jp

7月

8月

8/1 はすごく面白くて、現職のはてなの最終面接があったので朝から絶食のうえ最終面接して、そのままタクシーで健康診断を受けに行った しかも、人生初の胃カメラを選択して、だいぶしんどい感じになりつつ昼ごはんも食べられず、技術書典に出展できることを知った気がする

  • TIF初参戦 8/4
    • BiSHを見るために暑い中大変だったけど、フィロソフィーのダンスというアイドルグループを知ることができてよかった。マリリかわいい。
  • 宮古→室蘭のルートで帰省 8/11-8/14
    • 何度も山奥には行っていた宮古だけど、初めて市内に降り立ててよかった。
  • 平塚グリーンサウナに夜から昼までずっといたけど本当に良かった 8/28

9月

  • 同い年の社員で北海道 9/1-3
    • ほぼ卒業旅行。うまいものしか食べていなかった
    • タイミングが数日ずれていたら地震に巻き込まれて東京に戻れなかったっぽい。
  • はてな入社 9/4
    • いつか京都へ移住することが決まった
    • 出張のとき使ってみたけど、受け取れる時間があるならスーツケースのレンタルは結構いいことがわかった
  • 二子玉Fishで初めてボルダリングのコンペ出た 9/22

10月

  • 技術書典5 に初出展 10/8

    • 技術好きだけど、人とか組織のほうが興味対象として大きいってことを感じ始めた

  • うっかり沖縄 10/27 blog.hokkai7go.jp

11月

  • くるりとハンバートハンバート良かった 11/3 blog.hokkai7go.jp

  • 会社の人たちとバンドで初スタジオ 11/16

    • 練習動画を見たドラムの先生からいいバンドですねと言われてだいぶ良かった
  • 琵琶湖の上での船上結婚式よかった 11/18
  • BiSH福岡と翌日にチェキ 11/23
    • 推しを前にすると人は幸せそうな顔をすることがわかった（自分）

12月

  • re:Inventでラスベガス 11/25-12/2

blog.hokkai7go.jp blog.hokkai7go.jp developer.hatenastaff.com

時系列じゃないけど心に残ったこと

  • うっかりして伊豆に日帰り旅行とかも行っていた
    • 京都になったので、また違ううっかりができると思うと楽しみ
  • ドラムレッスンは2017年から個人レッスンに切り替えていた
  • 前職の社員総会で初めて人前でドラムを叩いた
  • 道民と、びっくりドンキーによく行った年だった
  • 銭湯、サウナにもめちゃくちゃ行った
  • WACKオーディションおもしろかったですね。勝ち残った子がアイドルに変わっていくさまを見られたのはよかった。MAHO EMPiREかわいいよMAHO EMPiRE
  • ボルダリングもほぼ週に一度行っていた

さいごに

2018年は大小含めて20のライブに行っていたようでした。アイドルとともにあった一年です。2019年はハロプロ入門として曲を聞いていきます。また昨年の誕生日記事に書いてますが、目標の長期運用が行えるようになったり、毎月の個人的なふりかえりを実行したり、投資による効果が出たりというのは引き続き行うことができました。

なんか京都に移住することになった

はじめに

これまで8年弱東京に住んでいました。下記の転職エントリに関連しますが、はてなでSREをしており京都採用だったので今回2018年の年末というタイミングで東京を離れ、京都に移住しました。あと、平成最後の天皇誕生日に30歳になりました。 blog.hokkai7go.jp

タイムライン

サラバかなは、もちろんBiSHの曲ですね。まだ中途だから。

対象的にとても良い運転手にも出会っていて、50過ぎの人なのに降り際に勉強になりましたとか、語り口が優しいですねと言ってくれて尊い乗車体験だった。

関連情報

下記の記事を見ていて、なるほどねー京都かー。と思っていましたが、まさか自分が京都に移住するという選択肢を取るとはタイミングでは思っていませんでしたし、onkさんと同僚になるとも思っていませんでした。これからもよろしくお願いします。

なんか京都に移住することになった - onk.ninja

タイトルはここから blog.sugyan.com

引越について

年末に引越をやるのはわりと大変ですね。引っ越しするのが大変という事実をすっかり忘れていました。そのうえ今回はわりとスケジュールが厳しくて、

  • 11/16-20: 結婚式や家の契約等で京都
  • 11/23-24: 推し事で福岡
  • 11/25-12/2: re:Invent2018でラスベガス
  • 12/7-9: 出張等で京都
  • 12/22: 推し事で幕張

と言った感じで移動や楽しいイベントが多く、しかも年末で忘年する必要があって毎日飲む予定がある中で引越し準備をする必要があってエキサイティングでした。こんな状況においても風邪ひとつ引くこともなく健康でいられたのは、そもそも頑丈に生んでもらえたことと、サウナの習慣ができて健康という両方のおかげのように思います。ありがたい。入居したらやっと気が楽になってきた。

とはいえ

BiSHや知人のライブや出張があれば東京にはよく行きますし、それっぽい用事があれば北海道にも行きます。もともとフットワークが軽い人間なので、会えなくなるなぁと悲観してほしくないなと思っています。これまでと変わらぬ感じでお願いします。いきなり今日飲むぞ！というのは難しいけど調整します！

さいごに

そういえば12/23が誕生日でしたが、引っ越し前で出すのも微妙だろうと思ってほしいものリストを出していませんでした。今は引越し後なので、遠慮せずどしどし贈っていただけるとありがたいです。30歳の前後でこのような大きめな決断を躊躇なくできてよかったと感じています。補足しておくとコンパクトな街でかつ、碁盤の目状になっているという札幌を思い出す構造の都市であることと、ごはんがおいしいということは自分にとって重要なことでした。暑さと寒さには気をつけたいと思います。

http://amzn.asia/iaY4Y0D

これを見ていて自分と仲の良い方々、京都に来たときは一声かけてください。ちょっとしか時間なくても、お茶か新福菜館あたりでラーメンでも行きましょう。引き続きよろしくお願いします。

割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話

はじめに

はてなでSREをしている id:hokkai7go です。この記事は、SRE Advent Calendar 2018の13日目の記事です。 

割れ窓理論とWeb開発での実践例について

割れ窓理論（われまどりろん、英: Broken Windows Theory）とは、軽微な犯罪も徹底的に取り締まることで、凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論。アメリカの犯罪学者ジョージ・ケリングが考案した。「建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される」との考え方からこの名がある。破れ窓理論[1]、壊れ窓理論[2]、ブロークン・ウィンドウ理論などともいう。  [割れ窓理論 - Wikipedia] より

割れた窓が放置されていると他の窓も割られやすくなってしまいます。軽犯罪を取り締まることで重大な犯罪も抑止できるとする理論です。不安や無秩序な状態を取り除くことができるというのも大きそうです。 

 pixivさんが以前このような記事を公開されていました。devpixiv.hatenablog.com公開された当時からこの記事に書いてある内容がとても気になっていました。なぜなら私達はエンジニアで改善に向かいたいからです。また、はてなでSREとなりインフラ周りを中心としてソフトウェアと向き合うことが増えたことや、こうした活動の提案を受け入れてもらえる感じがあったためSREチームでも割れ窓を直す活動をやってみることにしたのでした。SRE以外のプロダクトチームでも実践しているようでした。

また少し視点は違いますが、労働災害防止の経験則であるハインリッヒの法則を見ても、異常(ヒヤリ・ハット)や軽微な事故を放置するのは良くないことがわかります。SREは信頼性向上に責任をもっており、障害という重大事故を防ぐための現場活動として割れ窓理論の実践は有用であるように見えました。

ハインリッヒの法則（ハインリッヒのほうそく、Heinrich's law）は、労働災害における経験則の一つである。1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在するというもの。

今回のAdvent Calendarでもすでに引用されていましたが、まさに下記を体現する活動であると捉えています。

ゴミが散らかったりしないように環境を保つことによってイノベーションにまっすぐ焦点を当て続け本物のエンジニアリングが前進できるようにしているのです

Betsy Beyerら著、澤田 武男ら監修 「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」2017年  

はてなSREチームでの割れ窓理論の実践について

はてなSREチームでは、割れ窓に関するタスクを行う一連の時間を「割れ窓タイム」と呼んでいます。現在のところ、以下のような実施方法となっています。

  • 適宜、チームメンバーは割れ窓を発見したらissueを作成し、割れ窓ラベルをつけておく
  • 割れ窓タイムの日程を確保し、取り組みやすそうなissueを週刊割れ窓マガジンという記事にリストアップしておく
  • 週に1度、1時間リモートでつないで作業時間をとる(SREチームは東京、京都の2拠点で仕事をしているからです)
  • 割れ窓タイムスタート時に、その日の割れ窓タイム用issueを立て、やることが決まればissueにその旨を書き、ログを取っていく
  • 実施後に非同期的に参加者がその日の割れ窓タイム用issueに感想やKPTにつながる内容をコメントする
  • 感想やKPT等を割れ窓タイム用issueにまとめる
  • 振り返りやすいよう、スプレッドシート上でissue URL等を一覧にしておく
  • 割れ窓タイム企画者が、企画の改善のために振り返りを行う

また、割れ窓の対象物ですが

  • SREチームで作っているソフトウェア
  • サーバの設定
  • 物理サーバやAWS上などのリソース
  • アラート

といったものを扱っています。割れ窓タイムで取り組むべき内容と、普段の仕事で取り組むべき内容の線引が難しいなとも感じており、割れ窓タイムで実施する内容のガイドラインを作ろうかと考えているところです。

効果

効果は以下にまとめました

  • 割れ窓タイムがないと取り組めないタスクに取り組むことができる
  • モブプロ、モブオペを推奨しており、知識(前提知識や、コード、過去の経緯等)の共有を図りやすい。新しく入った人のキャッチアップにも利用可能
  • 一人で取り組むには勇気がいりそうなところも、複数人で判断できるので勇気を持って取り組むことができる
  • あそこに割れ窓がありそうという認識がみんなに出てきた
  • みんなが集まっているので、タスクで困ってもすぐに相談、解決できてスピード感がある
  • これって割れ窓じゃないですか？と話す機会が増えた
  • 同じ割れ窓が発生することを検知できる
  • 普段だと時間取れないけど、割れ窓で直しましょうという会話がされるようになった

タスクの解決ができるだけでなく、知識の共有やコミュニケーションの促進につながるという点が良いと感じています。

 

今後に向けて

これまで割れ窓タイムを8回ほど実施してきたのですが、割れ窓タイムで取り組むべき内容と、普段の仕事で取り組むべき内容の線引が難しくなってきているところがあります。また割れ窓タイムのスケジューリングや、短時間で終わらないものへの対処、過去の経緯や多分に絡む物のコンテキストの説明の難しさにどう立ち向かうのがよいのかという点を今後の改善点としたいと思います。

ゴミが散らからないようにして、本物のエンジニアリングが前進していけるようにしていこうな！

こうした取り組みを一緒にやっていきたいSRE職を大募集中です。

hatenacorp.jp

 

参考文献

割れ窓理論にまつわるうわさを整理しよう。そして見えざる権力を見える化しよう。 - 廿TT

割れ窓理論を導入してWebサービスのクオリティに直結した話 - pixiv inside [archive]