転職しました

これは何

いわゆる退職エントリです。 転職活動とその意図について記録しておきたいと思います。

はじめに

株式会社ドワンゴを7月末で退職します。2014年に新卒として入社して5年目になり4年ちょっと働いたところでした。 ニコニコ静画・漫画のインフラリーダとしてアクセスが順調に増えていくシステムに対して、なんとか安定運用することだけをずっと考え続けました。会社全体の効率化のために他部署に借り出されたりしたけど軸足はずっと静画でした。 最初はくそ使い捨てスクリプトくらいしか書けないレベルだったけど、信じてインフラ権限を与えて成長させてくれたチームには感謝の気持ちでいっぱいです。

なぜ転職?

主な理由は以下のもの

新しいことにチャレンジするタイミングだと思った

  • 転職するなら30までにしたいと思っていた。私にとって社会人5年目のタイミングなので、経験と学習能力のバランスがよく取れている時期
  • インフラとしてずっとやっていくとやれることが頭打ちになる気がした
  • 最近はSRE的な動きをするようになって多少はバックエンドのコードを触るようになったけども、もっと多分野触って一人でちゃんとしたサービス作れるようになるまで成長したい、という思いがあった

一発当てたい

  • 昔からぼんやりと、お金を稼ぎたいという意識がずっとあった
  • 最近結婚したので将来お金がないことで困りたくないという意識が強まった。窮困することを心配するというより、やりたいことや住みたいところが出てきた時にコツコツ貯金してできる数百万〜千万のお金では自由になれないと感じた

ネガティブな理由は?


当然大なり小なりあります。よくある疑問について書いておきます。

  • 給料上がらなかったの?
    • 以前からお給料が上がらなくなったら会社から成長が止まったとみなされていると考えて、転職しようと考えていました
    • 幸い、2年目入ったあたりからコンスタントに上がってくれたので強い不満はそこまでありませんでした。強いて言えば、リーダという一応の肩書きがついた直後にあまり上がらなかったのでそれが転職活動のトリガーにはなりました。とはいえ、冷静に考えればリーダとして実績を出していけばまた問題なく上がるだろうとは思っていたので燻りながらもクリティカルではなかったです。他にいいところがなければ残留方向
  • 人間関係とか?
    • 良好でした
    • 強いて言えば、技術や仕事の進め方・改善提案がめちゃめちゃうまかった先輩や同僚が何人か抜けたことがありショックではありました。これも比較的自分が自ら学べるタイプではあるのでクリティカルではありませんでした(けど、転職というものがよりリアルに感じられたのは事実)

転職先について


というわけで、知人に誘われてM&A関係のプラットフォームを作るベンチャー起業に転職することにしました。ブログは現在の所属とは切り離しておきたいので少しぼかしておきます。

選んだ主な理由は以下のとおり

  • お金を稼ぐためにはお金周りの業種にいた方が良いと思っていたし、お金の話は元から好きだった
  • ストックオプションをもらえるので上場したら一発当てられる
    • 当たれば億万長者ではないけど、二発目当てるために一息つけるくらいの金銭的余裕はできそう
    • 自分では出来ないちゃんとした営業ができるCEOはじめとするチームメンバがいるし、ビジネスモデルも納得できるものなので、自分の努力次第で最高のシステムを作って一発当てられると信じている
  • 社員エンジニア二人目なのでバックエンド・インフラをメインに多分野を触れるようになるのを期待

ドワンゴ社のいいところ

  • 本物の裁量労働により、時間の融通がきくのはいろんなところに書かれている通りですが、最高です。16時に朝会で、本当にその時間にギリギリ出社する人もいました
  • 自発的な勉強会がたまに組織される
    • 自発的に動けて技術が好きな人にとっては良い会社だったと思います
  • 祭りが定期的に発生していた
    • 超会議とか公式の祭りもありますし、闇LT大会などの他の会社ではなさそうな奇抜で面白い人の祭りが沢山ありました
  • やりたいと言って、自分で仕事を取りに行けばやりたいことをやらせてもらえます
    • 良くも悪くも言い出しっぺの法則
    • どこでも一緒だとは思うけど意思表現が苦手な人には辛いことも多かったように見えました(これはいいところではないか。まあ表裏一体なのでしょうがない)

転職活動についていろいろ

いろいろ転職サイトやエージェントを使いました。時系列で並べておく。何かの参考になれば。

2年目終わり頃くらい

怪しげなヘッドハンターからメールが届き始める。 話を聞いて近い同業他社を紹介されるが1人前になる前にどこに移動しても同じだろうなと思って一回だけ話を聞きに行ったが後はスルー。

4年目始めくらい

技術ブログを適当に書いて wantedly に登録したらそれなりにオファーが沢山来た。 数社知っている会社を中心に話をききにいきました。印象的なのは以下のところ。

  • リクルートライフスタイル: 問題解決できる人しかとらない、というのが印象的。「あんまり活躍できない人がいたらどう扱うの?」と質問したら「しっかりお金渡す早期退職制度があるからそういう人はいなくなる。」(私がそう受け取ったという解釈です)と言われたのですごい会社だなと興味を持った
  • アトラシアン: 場所が横浜の馬車道にあって西海岸の雰囲気。昼前に会社訪問に行ったらメンバーと一緒にランチをすることになって、メンバの印象がすごく良かったので1〜2ヶ月くらいずっと本気で考えて転職しようか悩んでいた。ただ、まだバックエンド開発をほとんど触っていなかったのでサポートエンジニアになってそのスキルが取れないのはキャリアとしてまずいと思って見送り。
  • マネーフォワード: お金の会社はお給料良いのだなあ(雑)と思った。話が合いそうな人が多そうな会社だなとは思ったが、現場メンバとは実際には顔合わせしなかったのでそこまで本気で考えれなかった気がする。

4年目終わり頃

市場価値を知りたくなって転職ドラフトに登録して本気でレジュメを書いた。 現職より100万くらい高いオファーを出してくれた会社が複数あったので、エンジニアは転職すると給料が上がるというのを実感する。 あとバックエンドコードが書けるインフラエンジニア(SRE)が需要が高いことを肌で感じた

印象に残った会社

  • コネヒト: ママリという子育て世代向けSNSを運営している会社。インフラエンジニアの方とじっくり面談して、なんだか感覚的なところだけどすごく働きやすそうな気がした。やることが現職とあまり変わらなさそうというのとお給料的にも多少上がるくらいなのでリスクをとったり関係を断絶させてまで行くのは躊躇して断念
  • マネーフォワード: ここでもありがたくもオファーをいただきました。結構スキル的に雰囲気的にマッチしていたみたい
  • ヘルスデータプラットフォーム: 面談通してものすごく高く評価してくれました。手当を入れるとその当時の給与から150万以上も上がることになりクラクラした。健保会員向けアプリの開発会社で、肝心の事業内容にそこまで興味が持てなかったのが残念なところ。「専門家同士でお互い背中を守りあって開発していきましょう」とおっしゃっていたのが印象的でした

5年目始め

他の業界や職種も視野に入れて将来を考えたいと思ってエージェントに相談するべく登録してみた。 しかし同時期、退職した同僚を交えた飲み会でちょうどエンジニア募集をしているという話に。 「バックエンドでもなんでも長い目で見て経験させてくれるならありだね」という私の希望にマッチしそうだったのでオフィスに遊びに行くことに。お金の話と人を見て、これならいけるかもと思って転職を決意。

あとがき

ドワンゴ社には本当にお世話になりました。どこでも働けるスキルを得たいと思って新卒で入った会社だったけど、大正解でした。部署配属も「勉強できるところに入れてください」と面談で言って構築運用部というインフラ部署に入れてもらったのも良かったです。

次の会社でうまく働けるか分からないけど、無理をしすぎることなく淡々とやっていけば道は開けるはず、と信じてやっていきます。

インフラ手順書テンプレートを作った話

これは何

インフラ的な手順作業書の書き方についてまとめたい。 このページのテンプレートをコピーして書き始めると、手順書がスムーズにかけることを目標としています。 ここに書いてあるものはコンフルエンスを前提として書いています。

インフラ作業をやるときには原則的に手順書を書いてチームメンバーにレビューしてもらいましょう。 予定していない作業をぶっつけ本番でやると、大幅に時間がかかったり事故がおこったりすることが多々あります。

手順を残しておけばどういう進捗状態になっているかすぐ分かりますし、これから近い作業をする人が参考にすることができます。 まったく手順資料がなかったとすると、すべての作業をゼロから考えなくてはならず、大きなコストがかかってしまいます。手順を作ること自体がコストではありますが、長期で見てコストが低くなると考えて資料化するべきだと考えています。

=============以下手順テンプレート=====================

タイトルは、実施日時が決まっている手順は年月日を書いておきましょう。例えば単に「メンテナンス手順」と書いてあると後から見た時にいつのかわからなくなりますが、「20180206 全体メンテナンス手順 MySQL Master昇格」 などと書いてあると大体タイトルだけ見て参考にできるか判断することが出来ます。

目次

目次はつけましょう。目次を見てよくわからない(階層がガタガタしているとか、節のタイトルが意味不明とか)の場合にはたいてい読みづらい資料になっています。

作業目的&作業概要(方針)

この作業書にかかれている作業の目的と概要を書きましょう。 目的を達成する手段は(場合によっては)沢山あるので、目的をはっきりさせて手順方針を決めた時点でチームレビューを受けたほうが手戻りが少なくて良いです。 目的と方針は表裏一体なので対で書くと良いのではと考えています。

作業目的

目的です。

作業概要

この手順の概要について数行程度で書きましょう。細かい手順だけがあると、それをすべて読まないと全体をつかむことが出来ません。

期限&スケジュール感

厳密な期限がある場合にはそれを根拠と共に書いておきましょう。チケットなどあれば貼っておくとよいです。  特に強い根拠がなくても期限の目安や目標時期だけ書いておいてもいいと思います。仕事を振った人が「このタスクはどれくらいかかるかな? いつ終わるのかな?」というのが把握できるようにする目的です。 ある程度タスクが洗い出されている場合には、いつごろにどのタスクをやるというロードマップを書いておくとよいです。厳密でなくてもよいので工数見積もりが書いてあるといいかもしれません(理由は同上)。

関連リンク

チケットや全体を通した参考資料を貼っておきましょう。前提知識やこれまでやられた似た作業手順を貼っておくのも良いと思います。 手順の個別項目に関連する資料はその場に貼っておいたほうが便利です。

手順に関わる調査資料などを子ページに置いていきましょう(コンフルエンスなど階層化できる場合)。子ページへのリンクが自動で表示されない設定になっている場合には子ページを表示するとしておいたほうが階層がすぐ分かって便利です。子ページのマクロは孫ページまで表示するように設定することもできます。

検討事項

検討内容によって手順が変わるような先に考えておくべき重要な検討事項について書いておきましょう。なければ不要です。 検討が終わったらそれをタスクに落とし込むか、「その他」項目や子ページにまとめるなどしましょう。

検討事項1

ほげ

検討事項2

ふが

事前準備

当日でなくてもできる作業については事前にやってしまいましょう。やった結果もまとめておきましょう。 特に他部署依頼など時間がかかりがちなものは先に潰しておきましょう。作業ボトルネックは何か? それを潰すには何をすればいいんだろう?という視点で考えるといい気がします。

事前準備1

ほげ

事前準備2

ふが

同期的作業タイムスケジュール

他チームと同期的にやらなくてはいけないとかメンテナンスの時間が決まっているなど、当日のタイムスケジュールを決める必要がある手順については書いておきましょう。非同期でできるものは事前作業としてやってしまいましょう。 同期的作業が特になければ、事前作業、事後作業ともに一つの項目にまとめてしまって良い。

実際にかかるだろうなという時間に追加してバッファや万が一の切り戻しの時間も考慮して決めましょう。

| 時間 | 作業内容概要&リンク | 担当者 | |:-----------|------------:|:------------:| |xx:xx ~ | 詳しい作業内容が長くなる場合には作業詳細に書いてリンクを貼っておきましょう。 | やること: @担当者 役割分担できそうなら相談して依頼しましょう。 | 長時間に渡る作業の場合には休憩時間なども考慮に入れましょう。人は休まないとミスをします。

依存関係があるサービスには連絡しておきましょう。その話をしたリンクもはっておきましょう。当日に連携が必要な場合にはその連絡内容もあらかじめ作っておくとテンパらなくてよいです。

同期的作業詳細

上のタイムスケジュールに書ききれなかった詳細な内容について書きましょう。上のタイムスケジュールにリンクを張りましょう。リンクは目次のものをコピーすると楽です。

設定更新がある場合には、その設定を確認できるコマンドなども一緒に書いておきましょう。可能であれば設定の一部だけでなく全部をカバーする確認方法を検討しておきましょう。

中作業1

作業は問題があった時に巻き戻せるように進めましょう。可能な限り一気にすべてを破壊的に進めるのではなく、徐々に次の状態に移行していきましょう。

少作業1

チェックボックスで細かく書いておいたほうがよい 終わったらチェックをつける

少作業2

好みではあるが、少作業にもタイトルをつけたほうが目次を見て流れがつかみやすい

中作業2

ふが

後処理

当日にやらなくてもよい手順についてまとめておきましょう。 忘れがちなのでリマインダやgaroon予定など入れておくとよいかもしれません。

その他

参考となる小話や調査について書く。分量が多いときには子ページに切り出しましょう。

非効率な仕事の進め方とルール化について(オートフォーマット編)

背景

最近ちょっとだけバックエンド開発の仕事をやらせてもらっている。 当然その分野の先輩がいるわけで、その人たちの書いたコードを修正したり追加したりするのが多い。

IntelliJを使ってPHPを書いているのだけども、オートフォーマットをしてPRを出すと細々とコメントがつくことが何度かあった。 私はREADMEに書いてあるルールに従ってIntelliJのオートフォーマッタを設定して修正しているだけなんだが、ここはこうした方が良いとか、最近の運用ではこうなっている、とか細々としたコメントが大量につく。 「クラス定義の後ろの "{" の前は改行しよう」とか「いや、ここは今はもうそのルールは古い」とか。そんなくらいの話。

問題点

おかしいな?と思ってヒアリングすると幾つかの問題がチームにあることがわかった。

  • READMEの記述が古い
    • 古いコードに引きずられてルールが作られていて、すでに誰も見ていない。新しく入った人だけがそれを見て振り回される。
  • 昔のコードをフォーマットするかしないかで意見が統一されていない
    • 自動フォーマッタを入れている人は修正を出すが、そうでない人も多い。ボーイスカウトルールとは(来た時より出る時には綺麗にしましょう)
  • 温かみのあるコミット分割
    • ある人は新規で追加した部分はフォーマッタかけるが、ファイル全体に修正がPRに出るといやなので、git add -pなどを用いて自分の変更箇所だけコミットするなどしていた。温かみ運用。毎回手動でやっているのか・・・

修正

私の提案

  • 形がい化したルールを削除(READMEに書いてあることは正しいものとする)
  • PRで議論をして満足するな。議論して決まったことは同じことを繰り返さずREADMEに明記すること。書いていないルールはそのPRを通す通さないには関係してはならない。直したければ別PRとして修正すること。
  • オートフォーマッタ設定の方法もかく。会社でライセンス買っていて大体みんなIntelliJ使っているのでその設定方法の明記。vim使っている人は従ってもらい同等のものを入れてもらう
  • 古いファイルもまずオートフォーマットしてそのコミットを分ける。必要に応じてPRも分ける。実作業と分けた方が良い(緩やかなルール)

できなかったこと

  • editorconfig などでルールの自動読み込み
    • すでにあるエディタ設定が優先だったし、PSRなど包括的なルールで設定できなさそうだった。これは知見が足りないだけかもしれない。

終わりに

上の提案はあくまで提案で、そのような内容をREADMEにかくPRを出してマージされた段階。 そのあとの運用はまた回してみて問題が出れば修正。

とにかく「繰り返しの無駄な議論」「細かすぎる指摘によるマージブロック」「温かみのある手作業」 こういうのをなくしていかなければならない。

誰かに質問をわざわざしに行くのが苦手な私が、それを克服した話

背景

私はもともと誰かに質問をするのが苦手な気質。 ランチや移動中にカジュアルな話をしていて「そういえば」くらいのノリで聞くのはできたけど、改めて「質問なんですけど・・・」みたいに人の席に行って聞くのが苦手だった。

問題点

エンジニアをやっていると分からないことはたくさん出てくる。 ドメイン知識についてや難しい技術について。

ドメイン知識についてはそもそも聞かなきゃわからないことが多い。 サーバの中をひたすらあさったり、コードを読んだりして推測することはできるけど、時間はかかる。

(自分にとって)難しい技術についても、ブログ読んだりドキュメント読んだりすればいつかは扱えるようになる。 大体の場合は通勤時間にスマホで雑にブログとか5個くらい読んで大まかな用途みたいなところを掴んで、公式ドキュメントで理念や細かいHowを読み込むと自分のものになっていく気がする。 たまにブログ情報も少なかったりドキュメントが貧弱なミドルウェアとかにぶち当り、無駄に時間をかけてしまう。

そういう時、詳しい人に「ねえねえ、10分だけちょっと最初の概要だけ教えてよ」と話を聞いて、そのあと自分で触ってみるとすっきり問題なく使えることが多い。

わかっちゃいるが聞けない

質問の仕方として「自分が何が分からないのかはっきりさせてから聞きなさい」と教育されてきたからなのかカジュアルに人に聞けない。 分からないことが分からない時には誰かに話してはいけないような気がしている。でもその時間が長く続きすぎるなら、10分だけ時間をもらったほうが良さそう。

克服しつつある

最近、あるプロダクトのSRE的な部分のリーダとして仕事をするようになった。 必然的に、誰かに技術や仕事の進め方、ドメイン知識を伝えないといけない。 私が仕事を振る時、相手に最初に短い時間をとってもらって出来るだけ方針やはまりどころを伝えようとするけども、それでも伝えきれないものが出てくる。または、ある程度進んだけど次のステップで困っているなどの相談がくる。 その時に(みんなじゃないけど)私の机のところにカジュアルに話を聞きに来てくれる人がいる。

仕事の進め方ってみんなやり方がバラバラで、Slackメンションしてから時間とってもらっていいでしょうか?みたいにちゃんとする人も、しゃべりながら近づいてきて問答無用で会話を始める人、逆に詰まっているのに話を全然持ってこない人など。 その中でピカイチの成果を出すのはやっぱり躊躇なく話を聞きに来る人。

こちらの時間は取られてしまっているのだけど、それでもその人がウンウン唸って詰まる時間が少ないので仕事はスムーズに進む。チームとしてトータルコストは低そう。 そういう風に人の仕事ぶりを見るようになって、忙しくなってきた自分がコストを低く結果を出すためには、やっぱり誰かの力をテコとして使うのがいいんだろうなと思ったりする。すべての内容を聞くのは相手の時間を使いすぎるのでいまいちだけど、一番詰まるところだけを人の力を使って解決してしまうのが良いのかなと。

終わりに

まだ克服できていない部分ももちろんある。意識して克服していきたい。 ”人に質問をする”のが苦手という断片的な部分よりも、最小コストで結果が出せているかな?という点にこだわっていきたい。 この文章を書いたのは、後から自分が見て、ちゃんと出来るようになっているかな?というのを確認したいがため。

チームがうまくまわるようにAnsibleのPlaybookでGitHubプルリクテンプレートを使いたい話

目次

背景

最近インフラを触り始めた人と一緒に働くことが多くなってきた。みんなに効率よく経験を積んでもらいつつ、インフラチームをうまく回すための施策を細々考えている。この記事はその中の一つについてのメモ。 私は「こういう内容が良いのではないか」と思って作ったものなので今後チーム内外の意見をもらって内容が書き換わる可能性は大いにある。

GitHubのテンプレート機能はどう使うか

レポジトリのルートディレクトリに PULL_REQUEST_TEMPLATE.md という名前でファイルを置くと、プルリクを作るときに自動的にその内容が書かれる。 詳しい置き方や仕様についてはググれば出てくるのでここには書かない。

テンプレートを作るにあたり気をつけたこと

  • 後からプルリクを見直したときに、何をやっているか分かるか。後から新人が入ってきたときにプルリクをトレースして学ぶことができるようにしたい。
  • 開発環境や本番環境に全て(半)自動反映になっていれば最高だが、今のところそうなっていない。 反映漏れ事故をなくしたい。
  • コードだけ書いて本番に反映せず満足してしまう人もたまに居るので、きちんとデリバリーしようという意識を持ってもらうために、それを促す記述を入れたい。
  • プルリクを出した後のネクストステップを意識するとスムーズに仕事が回るので、それを考えてもらいたい。
  • 時間は無限ではないので緊急度や重要度を意識して、やらなくて良い仕事はやらない。ネクストステップがない場合もある。
  • よく分からないことをプルリク出してもレビュアが気がつかなければプルリクが通ることがある。事故の元なので曖昧なことは表明してもらってみんなで解決したい。

テンプレート内容

# 概要
### 経緯
issueやconflenceリンクがある場合にはそれを張っても良い。

### このprの目的
課題は何か

### 変更点概要
この変更によりどう解決されるのか

# 本番/開発環境更新
### 反映タイミング
開発環境と本番環境への反映を行うタイミングを記述する。以下の選択肢から1つ選択して詳細を記述する。

* 開発環境に反映済み
  * 対象サーバを記述する
* マージ後開発環境にのみすぐ反映する
  * しばらく開発環境で動作を確認したい場合に選択。もしくは緊急度が低く、本番へは次のサーバリプレイス時に入れば良いという場合
  * 反映すべきサーバを書いておく
* マージ後すぐに本番に反映する
  * 緊急度が高い場合
  * 本番更新チケットを作成して、リリースタグを切って反映する。参考: http://hogehoge.jp
  * 反映すべきサーバを書いておく

### 動作確認手順
更新後に行う動作確認の手順を記述する。すでに開発環境で動作確認を行っている場合にはその内容を書く。
できるだけprを出した本人以外でも動作確認ができるように書く。自明な場合には記述しなくてもよいが、レビュアーはレビューをする段階で分からなかったら確認するのが望ましい。

# 関連issue/pr/外部リンク

# その他
### 今後の課題
次に解決すべき課題があれば書く。

### 実装に関する留意点
困ったことやイマイチな点など。

初めて会社でAPIを書いて学んだことメモ

これは何

普段主にインフラエンジニアとして働いている私が、会社で初めてAPIを一つ書いたので、そこで得た学びや考えたことを記録しておこうと思います。

何を学んだこと・考えたこと

仕様書を書こう

どのようなAPIなのか、目的やリクエストパラメーターやレスポンスフォーマットについて定義する。 特にAPIの場合はレスポンスフォーマットが変わるとクライアント側でパースするのに困ってしまうのではっきり定義しなければならない。 APIは使う側ありき。

レスポンスフォーマットの統一性

他のAPIとできるだけ揃えた方が良い。統一性がないと使う時に大変。 ドメイン全体でJSONのうちのMeta情報やDataオブジェクトをどのようなフォーマットにするのかというのを決めておき、各種APIはそれに従うのが良い。何も決めずに走り出すとメチャメチャになってしまうのでまず共通ルール。共通ルールはフレームワークへ落とし込んでおいて、そのフォーマットから外れなければ簡単にレスポンスを作れるようにしておく。 共通ルールをしっかり作っておくと大枠は固定されるので、後から細かいところをちょっと変えるにしても混乱が少ない。

DBで保持しているデータとAPIJSONのキー名は必ずしも合わせる必要がない

裏で使っている名前に引きずられがち。利用者にとって使いやすい名前にする。 例えばDBで公開状態をpublic_statusという名前で持っており、0,1の値を取るとする。どちらの値がpublicなのかちょっと分かりづらいと感じたとする。その場合、public_statusにこだわらなくても、APIレスポンスとしてはデータ要素が削除されているかというのが重要であるなら is_deletedという名前で返してあげるのが親切。

時間はUnixTimeで返そう

JSTUTCで帰っていると使いづらい。DBでJSTで保持していても変換してUnixTimeで返すと良い。

エラー応答についても定義しておこう

主なエラー応答やステータスは共通ルールとして定義しておこう。 各APIの仕様書においては、特殊な条件やちょっと迷いそうな場合についてエラー応答について記述しておこう。

仕様書はコードからすぐに参照できるように書いておこう

@see などで参照リンクとしておいておこう。 簡単な説明はコードにコメントしてしまった方が良いが、長くなるなら仕様書に切り出してリンクを貼っておくのを忘れずに。1セットで管理していく。

コードフォーマットはエディタに任せよう

エディタに微妙にフォーマット設定が入っていなくて細々としたPRコメントを沢山もらっしまった。 フォーマットについてはプロジェクトのREADMEにすべて明記して新しく入った人が迷わないようにする。可能であればエディタ設定ファイルなども共有しよう。 人間がやることではない。機械に任せられるのは機械に任せよう。

テストを書こう

PRコメントに長々と手動の動作確認の結果を書くのはよくない。TDDの考え方を取り入れて仕様が決まったら先にテストを書いてしまうのが良い。

コメント: とはいえ今回のケースでいうと、それなりにテスト書くのに苦労したので先に書くのは難しかったかも。Seleniumでテストを書いたのだが、他の開発者がMacだったが私だけWindowsでテストを回したので無駄に苦労した。開発環境は可能なかぎり教えてくれる人と合わせた方が良い。

同じような応答を返すWebFrontページがあるなら仕様を合わせよう

WebFrontページとソート順や件数などの仕様が異なると混乱を招く。仕様がくいちがうならその旨を理由と合わせて明記しよう。

障害電話受け1番になった時に使える三つの心得

これは何

システムに障害が起こった時に電話が一番にかかってくるようになった人のための心得。具体的な障害対応手順ではなくて、元気にSREエンジニアとして生き残っていくための心得。

心得

1. 本当の優先事項は何かを考える

仕事の電話がかかってきた。(仮に)今は奥さんの誕生日食事会の途中だ。さあ電話に出て対応をするか? そういう時には対応をしてはいけません。他の人に任せましょう。ほっておけば2番目の人が電話を受けてくれます。 人生で重要なことの優先順位をつけましょう。電話がかかってきたら必ず仕事、なんてことはやってはいけません。そういう風に考えていると24時間いつでもかかってくる電話を所持していると精神が持ちません。気をつけましょう。 エンジニアとしても人としても長生きしましょう。 (補足:待機人員として拘束時間になっているならちゃんと出ましょう。しかし特に決まりもなく電話を持たされている場合には法的には何も拘束力がないと理解しています)

2. 最初にやることを意識する

まずは他の人も呼びましょう。 あまりにも軽微な障害なら一人で対応しても良いですが、すぐに問題原因が特定できない可能性があるもの、影響範囲が狭くないものの場合にはチームメンバーが気がつけるようにSlackで@channelしましょう。躊躇なく。 その目的としては以下のような人員を増やす目的があります

  • 問題原因特定のための人員
  • 原因特定後、手作業が発生した時に対応する手として
  • 影響システムや社内一次報告、関係会社などに連絡する連絡人員として
  • SREの知見は少なくてもユーザ目線で障害発生や復旧を確認できる動作確認人員として

なんにせよチームメンバならやれることはあるはずなので人を集めましょう。 上にはいろいろ理由は書きましたが、一人で対応するとテンパったりミスをしたりするのでオブザーバでもいてもらった方が良いです。

3. 障害対応は実況しよう

やったことは生のコンソールログを含めてSlackに貼っておこう。他のチームの状況なども可能なかぎり一つのチャンネルに集める。これの目的は以下のもの

  • 途中から対応に参加した人が状況を把握できる
  • 手分けして対応をしている場合に他の人の状況が把握できる
  • ミスや考え違いをしていたら他の人が気がつくことができる
  • 振り返りに使うことができる(後で見て情報ないと本当に困るので、やってみると効力がわかるはず)

実際にやったことだけでなく、障害原因の予想や、対応方針、ふわっとした違和感なども投げましょう。少しでも情報を表に出してみんなで考えることが大切です。書くことで自分の考えも整理されます。

終わりに

これらは電話をもらって頑張って死にそうになっている同期や後輩を見て考えたことです。

長生きしましょう。 ストレスためすぎているなと思ったら電話をおいて海にでも出かけるのも良いです。この投稿で言いたいことはこれがほとんで全てです。