だいくしー(@daiksy)のはてなブログ

daiksyの徒然的なもの 以前のブログはこっち -> http://daiksy.blogspot.jp/

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は原稿を書かねばならない現実逃避によって書かれている。この分量を本来書くべき原稿に書いていたら進捗を得られていたのだが...。

オンライン登壇のノウハウゲット - スクラムフェス大阪で話してきました

スクラムフェス大阪というイベントに参加してきました。

www.scrumosaka.org

プロポーザルを採択いただき、登壇する予定だったのですが、昨今の情勢を踏まえてオンライン開催に切り替わり、人生初のオンライン登壇にチャレンジしました。 今回の発表資料はこちらです。

speakerdeck.com

登壇内容自体は、今年の頭にDevelopers Summit2020でお話したものとほとんど同じだったので、新しくプレゼンを作り直す必要が無い、と言う余力をせっかくなのでオンライン開催ならではの工夫に使おうと思いました。

通常の話者が壇上に立ち、聴衆が並んで座ってそれを聞く、と言うスタイルに比べて、オンライン開催はもう少しスピーカーと聴衆の距離が感覚的に近いと感じています。具体的にはチャットなどのコミュニケーションによってダイレクトに話者に意見を述べることもできますし、手元のマイクをONにするだけで、全員が同じ条件でスピーカーに話しかけることも可能なわけです。

なので、セッション中に引用している資料のURLをリアルタイムにチャットに流したり、チャットでの質問や感想をできるだけその場で拾って講演に組み込んだりすることで、インタラクティブな要素の強い内容を目指しました。

そのためには一点壁がありました。講演資料をKeynoteで作成しており、発表者メモなども仕込んでいたので、どうしてもスライドの投影をKeynoteのプレゼンテーション再生でやりたいのですが、PCに複数ディスプレイを接続しても、ディスプレイが全てプレゼンテーション再生に全画面持っていかれてしまって、チャットを読んだり書いたりできない...。

苦肉の策として、PCを二台並べて、スライド再生用とチャット用と使い分けることにしました。

今後さらにオンラインプレゼンテーションの機会は増えるはずですので、プレゼンテーションツールを実装している各社はこの辺りの対応をお願いしたいです...。

とはいえ、試み自体はうまく行って、リアルタイムコミュニケーション登壇は成功したんじゃないかなーと思います。

聴いてくださったみなさん、ありがとうございました。

大規模なプロジェクトでのアジャイル - More Effective Agileの読書メモ

  • 大規模: 2つ以上のアジャイルチームが必要なプロジェクト
  • 大規模プロジェクトにおけるアジャイルの変更点
    • 創発的な設計 -> ウォーターフォールのように全ての作業を事前に完了させる必要はないが、標準的なアジャイル開発よりも事前に完了させなければならない作業が増える
    • テスト -> 依然として小さなテストの恩恵は受けるが、統合テストやシステムテストの重要度が高まる

コンウェイの法則

  • 大規模プロジェクトで複数のアジャイルチームを構成するには、その分割点がコンウェイの法則にしたがっているべきである
  • アーキテクチャが不充分だと、結局は大規模なシステム全体に精通しないといけなくなり意味がない。
  • アジャイルの隆盛と、マイクロサービス化の潮流のタイミングが似ているのは偶然ではない
  • チームを分割したためにコミュニケーションコストがオーバーヘッドになるくらいなら、諦めてチームを統合したほうがよい。設計に関する技術的な判断と、チーム組織に対するマネジメントな判断とのトレードオフ

コミュニケーション

  • 小さなチームと異なり、全ての情報が口頭伝達でもうまく行く、という期待を捨てなければならない。より多くの作業を文書化しなければならない
  • スクラム・オブ・スクラムミーティングにはスクラムマスターよりもプロダクトオーナーを出席させる方が良いだろう

オンラインのCSPO研修を受講しました

6月8日から11日までの4日間。オンライン(Zoom)で開催されたCSPO(認定スクラムプロダクトオーナー)研修を受講しました。

なんで受けたの?

昨年、自分の所属しているチームでPOの交代という大きなイベントがありました。

自分はチームのディレクターとして新しいPOを迎え入れることを考える必要がありました(ぼくは実はPOではない)。今手掛けているプロダクトにおける、POの役割というのはとても幅広く、いかにして新しいPOの負荷を下げて支援するか、ということを考えた結果、新しくPOチームを作ってPOを支援する体制を作ることを決めました。

POチームを運用する中で、当然様々な課題が発生するわけですが、POの目線に立って書かれた良い書籍などになかなか巡り合えず、学習にとても苦労しました。そこで、いっちょCSPOを受けてPOを支援するための学習をするか、と思い至ったのです。そのうちPO本人にも受けてもらいたいな、とは思っています。

どうだった?

実は最初に申し込んだのは世の中がこうなる前だったので、元々東京の研修会場で受講する予定でした。その後、情勢が変わり、何度か延期されたあとでオンライン研修に切り替わりました。

以前受講したCopeさんのCSM研修の印象がとても強かったので、正直オンラインでの研修に不安はあったのですが、スタッフさんのご尽力と神アレンジによってオンラインでも大変素晴らしい経験ができました。

オンライン開催だったので、終わった後にお酒を飲みにいく、などの流れになりませんから、明日の予習とか1日のメモをまとめたりだとか、集中して学習できた、という気がします。一方で、他の受講者とのコミュニケーションが少ないので、議論に発展する部分が少ないなーという寂しさもありました。ただ、最終日に急遽参加者が集まるdiscordサーバーが立ち上がったので、この後時間を見つけて議論ができると良いなと思っています。

4日間とても良い学習ができました。