エンジニアメンター1on1のやりかた

社内勉強会で発表した内容を外向けに編集して書きます。

ぼくが勤める会社では、エンジニアメンターという制度があります。

developer.hatenastaff.com

エンジニアメンターは定期的に1on1を開催するのですが、1on1は突き詰めて考えていくととても難しいものです。それこそちゃんとやろうと思うと、コーチングの専門的なスキルが必要だったりするわけですが、エンジニアメンターが全員プロ並みのコーチングスキルを保有する必要があるかというと、そんなことは無いと思っています (マネージャーなどの管理職であればそれなりにちゃんと勉強しておいてほしいですが)。

そこで、社内勉強会でエンジニアメンター向けに、このくらいのポイントを抑えておけばいいですよ、というのを伝えました。

ポイントは2つだけ

エンジニアメンター制度における1on1は、コーチングなどの専門的なスキルを学んで取り組まなければならないようなものとは異なると考えています。ですので、あまり難しいことを考えても意味はありません。誰もが気軽に開催して、時々でいいので「やってよかったね」と思えるくらいで充分です。

抑えておくべき点は以下の2点です。

  • 1on1の目的など考えない
  • 決められた頻度で必ず開催する

それぞれ理由を説明します。

1on1の目的など考えない

1on1のそもそもの目的は、チームでの仕事や、日々のふりかえりなどでは拾いづらい個人にフォーカスがあたった問題を拾い上げることだと思います。では、ここでいう「問題」とはなにか。それはそれぞれの状況や人によって異なるので定義できるものではありません。

「なにか問題を拾い上げないと」という目的意識を持って1on1を開催するのも悪くはないですが、ではその問題がなにも見つからなければ1on1の意味はないということになってしまうのでしょうか。問題が何もなければ、今は平和でよかったね、で終われば良いはずですから、そういう意味でも1on1を開催する目的、などというものは深く考えずに気軽な気持ちで開催したほうがよっぽど有意義だと思います。

なので、ここではあえて「目的など考えない」としておきましょう。

決められた頻度で必ず開催する

定期開催こそが1on1の最大の意味

こちらが1on1にあたってはとても重要です。1on1をやると、隔週や毎月、といった頻度で相手を数十分程度拘束することになります。ただでさえ日常の業務で忙しいのに、相手の時間を奪ってしまって良いのだろうか、と悩んでしまう人も多いです。そうすると人によっては、毎回特に問題点などないから、わざわざ開催しなくてもよかろう、今月はスキップしようか、などとやってしまいがちです。

1on1において最も大事なのは、「何もしなくても自動的に定期的に場が発生する」ということです。仮になにか悩み事をかかえていたとして、その悩みは誰になら相談できるのかを考え、その人に声をかけて時間を作ってもらって相談する、という一連の動きはなかなか骨が折れるものです。ですが、そういった労力をかけずに自動的に会話の機会が発生すれば、ちょっと話してみようか、という気持ちになることもあります。

人間はさまざまな「相談先」を持ちます。上司や同僚、友人、家族などです。抱えている悩みに応じて相談先は変わるので、複数の窓口に気軽にアクセスできる環境がとても大切です。1on1は、その相談先の窓口が常に空いていて、放っておいても自動的にその機会が訪れる、という状態そのものに最大の意味があります。

単純接触効果

もうひとつ、定期開催には重要な意味があります。

単純接触効果という言葉があります。ザイアンスの単純接触効果とか、熟知性の原則、となどで検索すると専門的な情報にアクセスできます。 これは、人間は接触する機会の多いものに対して親近性を高める、という社会心理学の分野で研究されているものです。

同じ"3時間"という時間でも、年に1回3時間会うのと、35日連続で5分ずつ会うのでは後者のほうが親しみが湧きます。

1on1は悩み事を相談する場であると書きましたが、あまりお互いのことを良く知らない同僚に深い相談ができるだろうか、という懸念はこれによって払拭されます。

仮に隔週で15分ずつ1on1を開催すると、1年でおよそ25回程度の頻度で接触機会があります。仕事上の問題を相談するという程度の、エンジニアメンター1on1の場では充分すぎる回数です。

人見知りの人など、1on1に抵抗がある人も少なくないと思いますが、最初の3, 4回我慢すれば単純接触効果によって特に気にならなくなりますから、こういう意味でも定期的に「必ず」開催することに意味があります。

監視の最初の一歩目とそこからの育て方

はやいものでもう12月。今年もアドベントカレンダーがはじまりました。

本エントリは、Mackerelアドベントカレンダー2020の初日です。

監視は難しい

Mackerelがローンチしてから6年が経ちました。この6年間、ぼくもほぼMackerelに関わる仕事をし続けています。6年前と比べて、多少はソフトウェア開発・運用の現場でも、監視の民主化みたいなものが浸透してきたかな、というのは感じつつあります。devopsというワードがバズワードではなく、エンジニア文化をあらわす一般的な用語として認知されつつあるのもそのあらわれでしょうか。

Mackerelを導入すれば、簡単に監視をはじめられますよ、と我々はお客さんに対して説明するわけですが、そうはいってもやはりまだまだ難しいところもあると思います。6年前に当時アプリケーションエンジニアとして正式ローンチ2ヶ月後にチームにジョインした当初のぼくなども、監視についてはほとんど何もわかっていませんでした。

今だとよい手引があります。

『入門監視』などはモニタリングについてひととおり学べるたいへんよい書籍です。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

  • 作者:Mike Julian
  • 発売日: 2019/01/17
  • メディア: 単行本(ソフトカバー)

宣伝のようになって恐縮ですが、今回監修という立場で制作に関わらせていただいた、『わかばちゃんと学ぶサーバー監視』も、著者の湊川さんが苦心されて、マンガでたいへんわかりやすく最近の監視界隈をひととおり概観できる書籍になっています。

わかばちゃんと学ぶ サーバー監視

わかばちゃんと学ぶ サーバー監視

  • 作者:湊川あい
  • 発売日: 2020/12/22
  • メディア: 単行本(ソフトカバー)

監視すべき項目は環境によって違うから難しい

Mackerelの仕事をしていて、よく聞かれるのは、結局なにを監視したらいいのですか? CPU使用率の監視閾値は何パーセントにすると良いのですか? というようなものです。

「この項目に対して閾値をこれこれで監視すればよいですよ!」とズバッと一撃で回答できるとよいのですが、残念ながらそうはいかないところに難しさがあります。というのも、やはり実際に運用されているアプリケーションや環境によって、監視すべき項目というのは異なるからです。

たとえば、CPU使用率を監視して負荷を検知したい、と考えたとしましょう。たくさんCPUを使っている状態は負荷が高いから、80%くらいに閾値を設定すればよいのかしら、と考えたくなりますが、それがそうでもないのです。

オートスケール環境で、アプリケーションを並列に複数のサーバーで動かしている場合、インフラコストの効率化の観点でいえばCPUはなるべく使い切っているほうが効率がよい、となります。10台のサーバーで、それぞれのCPU使用率が60%なのだとすれば、まだそれぞれ40%の余力があることになりますから、台数を減らしてそれぞれCPU使用率90%くらいまで使い切ったほうがコスト面での効率がよい、と考えることができます。負荷が高まればサーバー台数を増やせばよいわけですから。

この場合、負荷はCPU使用率よりもloadavgであるとか、ネットワークトラフィックであるとか、他のメトリックを監視するほうが適切であるともいえるでしょうか。

一方で、簡単にスケーリングしづらいデータベースサーバーなどは、充分に余力をもたせて20%程度の使用率をキープしたい、ということもありえるでしょう。

このように、一口にCPU使用率、という監視項目をみても、アプリケーションの構成や考え方によって、検知したい閾値は大きく異なってくるのです。

悩んだら「ユーザーに近い場所」を監視する

さて、難しいとばかり言っていても先に進みませんから、まずはわかりやすく簡単にはじめられるところから監視を考えていきましょう。

そもそもわたしたちはなぜ監視をしたいのでしょうか?

サービスがダウンしていることに気づかず、復旧が出遅れてしまったり、ユーザーに迷惑をかけてしまうことがないようにしたい、というのがそもそも監視をしたい動機でしょう。

であれば、まずはユーザーがサービスを使えているかどうか、というのをはじめに監視するのがよいということになります。

MackerelにはURL外形監視という機能があります。

mackerel.io

これは、実際に稼働しているWebサイトに対してリクエストを行い、そのレスポンスを監視する機能です。

正常に動いていれば、サイトは200のステータスコードを返しているわけですから、そうでないステータスコードを受け取ったときにMackerelはアラートを発生させます。

まずはこれだけやっておけば、サイトがダウンしているのに数時間気づかなかった、というようなことは避けられます。ダウンしてまもなくMackerelからアラートを受け取ることができるからです。

この監視さえ一つ入れておけば、サイトのダウンには気付けるようになります。しかし、できることならダウンする前に、その予兆を察知したいですよね。なので少しずつ監視を育てていきましょう。

URL外形監視には、レスポンスを受け取るまでの時間に対して閾値を設定できます。サイトの応答が遅くなる、というのは何かが発生している予兆です。本来すぐに返事がくるはずのページが、たとえばデータベースの負荷がかかっているなどの理由で重くなっている状態です。

レスポンスタイムを監視すれば、サイトが完全にダウンしてしまうよりも少し前に気づくことができるかもしれません。

少しずつ監視を育てていこう

ステータスコードとレスポンスタイムを監視すれば、障害が発生した瞬間を捉えることができます。厳密に言えば多少の誤差はあるでしょうが、少なくともこのあたりの時刻で不調が起き始めたのだな、ということがわかります。

次に、それを手がかりに他のメトリックを眺めてみましょう。たとえば、レスポンスタイムのアラートが発生した時刻付近で、サーバーの他のメトリックに変調はなかったかどうか。アプリケーションサーバーのメトリックはいつもと変わりないのに、データベースサーバーのloadavgが大きく増えている、といったことがわかれば、原因はデータベースに近いところにあると判断することができます。では、次はもう少しはやく不調に気付けるように、データベースサーバーのloadavgを監視しましょう。継続的にメトリックをとっていれば、普段の正常な数値はわかるはずですから、そこから少し高い数字を閾値に設定します。

このように少しづつ監視を「育てていく」ことで、自分たちのアプリケーション特性に応じた監視項目が整ってくるのです。

ここで大事なのは、情報は普段から継続的にとっておく、ということです。

ある日の朝、体重計に乗ったところ80kgという値でした。この値だけみても良し悪しはなにもわかりません。身長とあわせて判断すればひょっとしたらもう少し何かがわかるかもしれません。ぼくにとって80kgという値は、いますぐ痩せなければならないたいへんな数値ですが、体を鍛えているがっしりした体格の人にしてみれば正常値かもしれません。今日のこの瞬間80kgだった、という数字にはなんの意味もないのです。継続的に計測していて、2ヶ月前は70kgだったのに今は80kgだ、というような継続的な情報の蓄積に基づいて判断してはじめて、数値には意味が生じるのです。

ですので、メトリックはなるべく多く、継続的に取得しておくのが良いでしょう。

メンテナンスしやすいサービスを選ぶ

監視項目は、普段の運用業務での傾向を眺めながら、継続的にデータをとり、チューニングしていくべきものです。

ですので、アプリケーションエンジニアやSREが、気軽に設定を試行錯誤できるようなサービスを選ぶべきです。必ずしもMackerelを使うべき、とは言いませんが、思い立ったらすぐに設定を変えることができるくらい身近に監視サービスがあるのが望ましい気がしますね。

それでは明日からのアドベントカレンダーも、よろしくお願いします。

ついに覚悟を決めて在宅ワーク環境を整備しはじめた

今年の3月から自宅で仕事をしているのだけど、緊急避難的な措置だと思っていたので特に環境を整えたりはせず、リビングで膝の上にMacbookを置いて仕事する生活を半年ほど続けてきた。

そうこうしていると勤め先から今後2年間のワークスタイルの方針が提示された。

pr.hatenastaff.com

仮にワクチンが発明されて新型コロナウィルスを気にしなくて良い世界になったとしても、今の在宅勤務とのハイブリッドな状態は長く続きそうな気配もあるし、意を決して自宅の環境をもう少し整えることにした。

去年の7月に引っ越して以来、ほとんど物置のように扱っていた部屋があるので、そこを仕事部屋にする。

まずは昇降デスクを買った。健康を意識し、スタンディングで仕事をしたいと思ったからだ。

1日中立って仕事をし続けるのも疲れるな、と思ったので、数年前にオフィスでつかっていたバランスボールを持って帰ってきたが、それはそれとしてちゃんとした椅子も欲しくなる(まだ買ってないけど)。

f:id:daiksy:20201111121244j:plain

不思議なもので、机に向かっているだけで仕事への集中度合いが全然違う気がする。

リビングと違って今の部屋にはスピーカーが無いので、Home Pod miniも買った。届くのが楽しみである。

www.apple.com

WDP誌で『インフラ障害対応演習』という特集記事を書きました - 内容と裏話 -

10月24日発売のWEB+DB PRESS vol.119 にて『インフラ障害対応演習』という特集記事を執筆しました。 ボリュームは25ページです。

経緯

今年の2月に、Developers Summit 2020というイベントで、下記のような講演をしました。

speakerdeck.com

これをご覧になった技術評論社の編集の方から、本講演を記事化しませんか、というお声がかかりました。

その後、記事化にあたってどういう構成が良いかを編集者さんと議論を重ね、最終的に講演のトピックの1つであった「障害対応演習」を深く掘り下げて記事化することとなりました。

記事の内容

記事冒頭の一部を引用します。

本特集では、障害対応を上手にこなすための方法の一つとして、障害対応を安全な環境で練習する「障害対応演習」を紹介します。 第 1 章では、障害対応の性質や課題と、それを解決するためになぜ障害対応演習が重要なのかを解説します。第 2 章では、筆者が業務で運用に携わって いる Mackerel という SaaS(Software as a Service)プロダクトにおいて、実際に行った障害対応演習の詳細を事例として紹介します。第 3 章では、昨今の社会情勢に伴ってニーズが高まっているフルリモートワー クの環境について、障害対応の観点から留意すべき事柄を説明します。最後に第 4 章で、障害対応演習で確認すべき大事なポイントや、演習を通して何を学ぶべきかを解説します。

このような内容になります。 かつての「動いているシステムは触るな」といわれた時代から、現代ではシステムが常に更新されつづける時代へと変化しました。そしてそれに伴ってSREという考え方が登場。これらの流れを簡単に解説しながら、障害対応演習の概要と、なぜそれが重要なのかを第1章で説明します。

読みどころは第2章です。Mackerelで去年実施した大規模な障害対応演習の実例を、当時の計画書や実施記録、担当エンジニアへのヒアリングなどからかなり赤裸々に書きました。

第3章では、昨今重要性が高まっている「フルリモートワークでの障害対応」について解説しました。第4章では、演習を通して、障害対応全体に適用できるような学習ポイントを紹介しています。

その他裏話

3月ごろから、編集者さんと企画を整理しはじめました。最初はデブサミの講演内容をそのまま記事化する形で考えていたのですが、技術評論社さんでの企画会議のフィードバックを得て構成を練り直し、7月くらいまでは編集者さんと一緒に目次をつくっていました。

7月, 8月の土日をすべて執筆にあてる、という形で執筆をしました。最初は30ページ弱ものボリュームをこのテーマで書ききれるか不安でしたが、事前にかなり詳細に目次を作っていたため、いざ執筆がはじまるとさほど迷わずに既定のページ数を埋めることができました。

企画段階もそうですが、全般的に編集者さんがとても的確にガイドをしてくれて、「著者と編集者が二人三脚で本を作るというのはこういうことか」というのを強く実感する日々でした。これまでも共著などで本の執筆に携わることはありましたが、編集者さんと直接やりとりする立場での執筆は今回はじめて(従来はメイン著者がいて、サブ的に執筆に関わっていたので)で、とても楽しかったです。

また機会があれば、なにか書きたいなと思います。

自分でも満足のいく良い記事が書けたと思うので、ぜひお手にとって読んでみてください。

スクラムマスターって何をする人? への答え - SCRUM MASTER THE BOOK

『SCRUM MASTER THE BOOK』を読んだ。

この本は、長年多くのスクラムマスターを悩ませてきた2つの問題を解決してくれる。

  • スクラムマスターって何をする人?」と聞かれたときの説明
  • スクラムマスターの自分はこのあとどういうキャリアに進めばよいだろう

スクラムを推進する多くのチームが、「専任のスクラムマスターは必要なのか」という問いを会社や上司から投げかけられて、悩んでいることだろう。 その理由のひとつに、エンジニアやデザイナー、マネージャといった馴染み深い役割ほど、スクラムマスターがなにをすべき人なのか浸透していない、ということがあるだろう。

答えは、この本を読めば良い。

本書は、「スクラムマスター」に焦点をあてた本だ。世のスクラムマスターに対して #スクラムマスター道 という教えを説き、導いてくれる。 スクラムマスターはこれを読めば、自分が明日から何をすべきか、明確な指針を得ることができるだろう。

スクラムマスターの根深い悩みのもう一つが、自分の今後のキャリアについて。

ぼくは、チームのスクラムマスターという役割から少し目線を拡げて、現在は会社全体のスクラムマスターの支援や、アジャイル的な考えかたの浸透に取り組んでいる。

この本にもそうしたスクラムマスターの段階的な成長、#スクラムマスター道 についての教えが書かれている。

自分は5年後どうなっていたいかに悩みながら、チームのスクラムマスターに取り組んでいる人にも1つの視野を提供してくれるだろう。

スクラムの多くの文献に触れ、プラクティスを学んだスクラムマスターが最後に学ぶべき「スクラムマスターとしての心構え」としての #スクラムマスター道 に入門しよう。

技術文書の執筆にめちゃくちゃ便利なtextlint

現在、少し長い技術文書を執筆する機会があって、ここ半月ほど毎週末にまとまった文章を書いている。

ここまで長い文書をまとめて書くのは、大学の卒業論文以来かもしれない。

書くにあたって、だいたいのエンジニアがそうするであろう振る舞いとして、『理科系の作文技術』を再読した。

あとは校正の手間をできるだけ省くために、リアルタイムでおかしい文章に気づけるようにtextlintを使ってみた。これも初体験。

github.com

特に、日本語の技術文書を添削してくれる textlint-rule-preset-ja-technical-writing が死ぬほど便利だ。

github.com

デフォルト設定からちょっとだけアレンジした。

{
  "filters": {},
  "rules": {
    "preset-ja-spacing": true,
    "preset-ja-technical-writing": {
      "max-ten": {
          max: 4
      },
      "ja-no-mixed-period":false
    },
    "spellcheck-tech-word": true
  }
}

max-ten は一文中の読点の数が設定を超えたら怒ってくれる。デフォルト値は3だが、ちょっと制限がきつすぎるなと感じたので4にした。

ja-no-mixed-period は句点が無いと怒ってくれるのだが、見出しのように句点を打ちたくない箇所で大量に怒られるので、これはfalseにした。

ぼくがよく怒られるのは次の2つ。

「助詞の連続使用」とくに"が"、"に" あたりでしょっちゅう怒られる。

「〜だと思います」と書いてしまう。技術文書は主張をはっきりさせるべきなので、曖昧な表現は使うべきではない。ぼくはしょっちゅ「かもしれない」「思います」と書いて怒られる。怒られまくる。ぼくが普段いか に曖昧な文章を書いているのかということをつきつけられる毎日である。

あと、意味の重複する言葉もけっこう怒られる。「することができる」は「できる」と書け、とよく言われる。

これらは気をつけていても油断すると書いてしまうので、書いた瞬間に怒ってくれるtextlint最高である。

ちなみにこのblogは原稿を書かねばならない現実逃避によって書かれている。この分量を本来書くべき原稿に書いていたら進捗を得られていたのだが...。