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

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

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

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

www.scrumosaka.org

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

speakerdeck.com

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

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

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

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

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

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

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

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

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

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

コンウェイの法則

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

コミュニケーション

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