【覚えておきたい】サービスの災害復旧パターン

大規模災害が起こった時の災害対策パターン、基本的なことだけど名前も含めて忘れがちになるので備忘のためにまとめておきます。

前提でわかっておきたいRTO / RPO

災害が起こった時の対策を考える前に、まず理解しておかなければいけないのがRTO（Recovery Time Objective / 目標復旧時間）とRPO（Recovery Point Objective / 目標復旧時点）です。
このRTOとRPOがどのくらい許容できるかが、災害復旧のためのアーキテクチャを選ぶための大前提の要件になります。
災害復旧のための構成を充実しようとすればするほどコストがかかってくるので、このRTO / RPOとコストのバランスを考えて構成のパターンを選択していきます。

RTO（Recovery Time Objective / 目標復旧時間）

RTOは障害が発生してからシステムがまた利用できるまでにかかる目標時間のことです。
この時間が長くなればシステムが使えない時間が長くなり、逆に短くなると災害が起こってもすぐにサービスが利用できるようになります。
災害が発生してしまったときに、特にライフラインに関わるシステムはこのRTOの時間を短くするような設計が必要です。
逆にゲームなど「災害が起こった時は止まっても仕方がないよね」といえるサービスについては長くてもそこまで問題にはなりません。

RPO（Recovery Point Objective / 目標復旧時点）

RPOは復旧作業が発生したときにどの時点の状況に戻すかの目標時点を示したものです。
この時点が大きくなると障害によって失うデータが大きくなり、逆に小さくなると失うデータは少なくなります。
例えば、RPOを1日とすると最大24時間のデータが消え、5分とすると最大5分のデータが消える可能性があります。
これはデータの重要度や、データを失ったときに取れるオペレーションなどを考慮して検討するといいと思います。
例えば、紙の帳簿をインプットする社内システムは紙があれば数日前のデータでも復旧できますが、ECサイトの決済系のデータは損失が許されません。

RTOとRPOのイメージはこちら。

【本題】災害復旧のためのパターン

ここからが本題です。災害復旧のためのパターンを４つ書いていきます。

• バックアップ＆リストア
• コールドスタンバイ / パイロットライト
• ウォームスタンバイ
• ホットスタンバイ / マルチサイト

バックアップ＆リストア以外はRPOを高くすることができます。
また、下に行くほどコストはかかりますが、RTOを短くできます。
コストバランスと求められるRTO / RPOを考えてパターンを選んでいきましょう。システムの重要度が高くなるほど下のパターンを選ぶ必要が出てきます。

また、災害復旧という観点で考えると災害対策用のデータセンターの場所も重要です。
例えば東京のデータセンターが潰れてしまうほどの災害が発生したときにもシステムを止めたくない場合は、関西のデータセンターに災害対策用の環境を用意する必要があります。
さらには、関東・関西のデータセンターが潰れてしまうほどの災害が発生したときもシステムを止めたくない場合は、海外のデータセンターに災害対策用の環境を用意することを検討します。

では、それぞれのパターンについてもまとめていきます。

バックアップ＆リストア

最初の構成パターンはバックアップ＆リストアです。
RTOとRPOが他のパターンよりも大きくなってしまいますが、一番コストを抑えられるパターンです。
災害が発生したときにデータの損失がある程度許容され、サービス停止も長時間許される場合はこのパターンが適切です。

システムを運用していく上でデータはとても大切です。ある程度のデータ損失は許容されても、データを全て失ってしまうとサービスの継続ができなくなってしまうので、最低限バックアップをしておきましょう。
そして、災害復旧のときにはバックアップをリストアしてデータを復元し、システムを構築し直します。

RTOとRPOについて

このパターンのRTOはバックアップしたデータをリストアして構成を作り直すので長くなります。
システムを１から構築する時間とバックアップをリストアする時間を想定してRTOを計算します。
また、人の手が必要な作業もあると思いますが、災害発生したときにオペレーターがすぐに対応できない可能性も考える必要があります。

このパターンのRPOはバックアップの頻度とそれをコピーまたはレプリケーションする頻度に依存します。
日次でのバックアップをしている場合は、最大24時間のデータ損失が発生します。

コールドスタンバイ / パイロットライト

次の構成パターンはコールドスタンバイ / パイロットライトです。
バックアップ＆リストアよりもRTOをRPOを小さくすることができ、ウォームスタンバイやホットスタンバイよりもコストも抑えられるのがこのパターンです。
災害が発生したときにデータは無くなってはいけないけれど、サービスの停止はある程度許される場合はこのパターンが適切です。

災害対策用のデータセンターにデータを同期させるスタンバイ用のデータベースを用意します。
データベースのスペックはコスト削減のために低いものにする場合があります。
コスト削減のために、データベース以外のアーキテクチャ（アプリケーション層など）は構築しません。
災害が発生したら、スタンバイ用のデータベースをマスターにして、残りのサービスの構築します。

RTOとRPOについて

このパターンのRTOはデータベースの構築とデータのリストアが不要な分、バックアップ＆リストアよりも短くなります。
データベース以外の領域を構築し、サービスを再開できる時間を想定してRTOを計算します。
また、人の手が必要な作業もあると思いますが、災害発生したときにオペレーターがすぐに対応できない可能性も考える必要があります。

このパターンのRPOはデータを同期しているため短くなります。
最終のデータ同期タイミングまでのデータが災害対策用のデータセンターに残っているのでデータ損失が発生しにくくなります。
データを同期レプリケーションしているか非同期レプリケーションしているかでRTOが変わります。

ウォームスタンバイ

次のパターンはウォームスタンバイです。
RPOはコールドスタンバイと変わらず、RTOをより短くでき、コストをホットスタンバイよりも抑えられます。しかし、災害が発生したときにサービスのスペックが低くなるのがこのパターンです。
災害が発生したときにデータは無くなってはならず、サービス停止も数分から数時間までなら許容できる、またはサービスのスペックの縮退が許容できる場合はこのパターンが適切です。

コールドスタンバイの構成に加えて、データベース以外のレイヤーもサービスを構築します。
しかし、コスト削減のためにサービスが動く最低限の構成・スペックで構築しておきます。停止しておく場合もあります。
災害発生時は、サービス停止しておいた場合は起動し、リクエストの向き先を切り替えることでサービスが縮退された状態での素早い復旧ができます。
復旧後にスケールアップ・スケールアウトを追って実施することで、段階的にサービスのスペックを通常稼働と同じ状態に合わせられます。

RTOとRPOについて

このパターンのRTOはシステムが構築できているためコールドスタンバイよりも短くなります。
サービスを構築後に停止している場合は起動とリクエストの切り替えにかかる時間を、停止していない場合はリクエストの切り替えにかかる時間を想定してRTOを計算します。
人の手が必要な作業もあると思いますが、構築が事前に済んでいる分、比較的自動化がしやすくなります。なるべくRTOを短くするために自動化を検討します。

このパターンのRPOはコールドスタンバイと同じです。

ホットスタンバイ / マルチサイト

最後のパターンはホットスタンバイ / マルチサイトです。
RPOはコールドスタンバイと変わらず、RPOを最小にできますが、コストが最もかかります。災害が発生したときにも即時に本番環境と同等のスペックを得られるのがこのパターンです。
災害が発生したときにもデータ損失をせずに、短時間で業務復旧する必要がある場合はこのパターンが適切です。

通常の構成と同じ構成を災害対策のためのデータセンターにも構築し、リクエストの切り替えをするだけでサービス継続できる状態にします。
サービスのスペックの縮退もありません。

RTOとRPOについて

このパターンのRTOは最も短くなります。
災害用のデータセンターにリクエストを切り替えるためにかかる時間を想定してRTOを計算します。
リクエストの切り替えもなるべくRTOを短くするために自動化をしましょう。DNSの設定による切り替えができるので自動化もしやすくなります。

このパターンのRPOはコールドスタンバイと同じです。

パターンまとめ

備忘のため、災害復旧のための４つのパターンをまとめてみました。

OSS X Users Meeting #31 ～オープンソースプロジェクトを支える言語たち～ に参加しました！

OSSをテーマにしたイベントの OSS X Users Meetingに参加してきたので、その参加レポートです！

oss-x-users-meeting.connpass.com

基調講演『改めて学ぶオープンソースの秘密』まつもと ゆきひろ氏 / 一般財団法人Rubyアソシエーション代表理事

プログラミング言語が誕生してからどういった経緯・歴史を経て現在利用されているプログラミング言語になっていったかというお話をされていました。
「今までコンピューターでできなかったことが出来るようになると、それが人工知能って呼ばれる」など、発表の中で面白い表現が使われていて楽しくお話を聴けました！

特に印象に残ったお話

ソフトウェアはもともと自由なものだったのが、商品化されて制限が厳しくなってきた、そんな中で再び自由を手に入れるためにフリーソフトウェアの考え方と、著作権を守るライセンスという考えが整理されていった。

オープンソースはソースコードはコードが公開されているだけでなく、自由なライセンスをつける必要がある。

オープンソースの定義という10項目がある。

1. 再頒布の自由
2. ソースコードがある
3. 派生ソフトウェア
4. 作者のソースコードの完全性(integrity)
5. 個人やグループに対する差別の禁止
6. 利用する分野(fields of endeavor)に対する差別の禁止
7. ライセンスの分配(distribution)
8. 特定製品でのみ有効なライセンスの禁止
9. 他のソフトウェアを制限するライセンスの禁止
10. ライセンスは技術中立的でなければならない

↑はメモが間に合わなかったので、こちらから引用しました。後で読む。
オープンソースの定義 (v1.9) 注釈付 – Open Source Group Japan – オープンソース・グループ・ジャパン

オープンソースの定義は素晴らしいが、開発者が生活出来るようにどうすればいいかをこれからは考えていかなければならないという課題がある。

オープンソースはここ20年で出てきた新しい世界で、オープンソースがないときに比べて遥かに良くなっている。
オープンソースをこれから守っていきつつ、貢献していきましょう。

講演『オープン化が進むC++の現状と展望』高橋 晶氏 / cpprefjp(C++)コミュニティ コアメンバ

私はC++を触ったことがないので、こういうライブラリがあるんだ〜・こういう状況なんだ〜と初見のお話が多かったです。

質疑応答のところであったGitHubスポンサー、知りませんでした。
開発者を経済的に支援できる仕組み。
GitHub スポンサーについて - GitHub Docs

資料はこちら
speakerdeck.com

特に印象に残ったお話

C++はまだまだオープンソースになっていない部分もあるが、オープン化自体は進んでいる。
そして、オープン化することで議論も活発になり、言語の進化が大幅に加速している。

高速化することで大きなメリットはあるけれど、教育が追いつかなくなっている。
変わりやすい最新のライブラリの設計をどう共有していくのかというのも課題。
オープンソースだと情報共有なども含めてボランティアに頼っているので、インセンティブをどう持たせるか・それに合わせて責任をどう持ってもらうかを考えていくことが、長く開発を続けていただくために必要。
GitHubスポンサーという仕組みがうまくいき始めているところもあるようで、それがもっと発展していけば良いかも。
GitHub スポンサーについて - GitHub Docs

C++の仕事が無くなったと良く聞くようになった。それは、C++が活躍する場が変化したことが原因。
C++はGUIやゲームなど、高速化のためのバックエンドとして利用するという需要が増えてきていて、領域に特化して言語が選ばれることは健全な流れ。
C#のバックエンドやPythonのバックエンドにもC++が利用されている。

特定の言語に固執せず、複数の言語を学んで適材適所でプログラミング言語を選んでいくのが良い。

講演『Pythonの現在とこれからと』鈴木 たかのり氏 / 一般社団法人PyCon JP Association 副代表理事

Pythonの概要から、どんな歴史で開発されてきたのか、どう運営されているかなどのお話がありました。
後半では言語のアップデートやこれからのPythonの未来のお話など、勉強になりました！

資料はこちら
slides.takanory.net

特に印象に残ったお話

Pythonで便利なライブラリを見つけるときはこのサイトがオススメ：Awesome Python
Pythonの妥協のないコードフォーマッター：Black
他にも旬なプロジェクトがいくつか紹介されていました！

Pythonのコミュニティも豊富

• PyCon JP 2021 2021年10月15日(金)、16日(土)
• PyCon JP TV 月１ライブ配信　次回は2021年9月3日(金)
• Python Charity Talks in Japan 2021.09 - connpass 2021年9月11日(土)
• Python Boot Camp(初心者向けPythonチュートリアル) — PyCon JP Pycon JPがやっている初心者向けハンズオン

Python3.10のアップデートでは「Better error messages」という更新も入り、初心者に優しくなった

これからの未来：Pythonの高速化が進んでいきそう
The “Shannon Plan” ：4年で5倍の高速化(1年で1.5倍)
GitHub - markshannon/faster-cpython: How to make CPython faster.

講演『26 Java Years - これが今のJavaだ！』谷本 心氏 / 日本Javaユーザーグループ代表

Javaは古い？堅い？ダサい？→No!! という走りだしから始まって楽しいプレゼンでした。

特に印象に残ったお話

JavaはOSSと共に歩んできた言語。エンタープライズ系で使われることが多い言語でありながら、開発環境・ライブラリ・フレームワークなどにOSSプロダクトが盛んに使われていた
言語も現在はOSS化され、企業でも提供を開始している

IDEはIntelliJ IDEAが主流。
追加で調べてみたら、2020年でシェア72%らしいです。良い。→数字で見る 2020年における Java の現状 | The IntelliJ IDEA Blog

主流になったOSSのプロダクトがJavaの標準機能として取り込まれている。
そうやって企業・団体・エンジニアの貢献によって、JavaのOSSエコシステムは成熟していった。

しかし、その一方でJava界隈のOSSで起きた問題もいろいろあった。
Javaは Write Once, Run Anywhereというポリシーを守るため、JavaではないものをJavaと認めないという意思があった。（不要なJavaの分断を防ぐという意味では良い判断。）
JavaであるかどうかについてはTechnology Compatibility Kit (TCK) で互換性のチェックを通っているかで判断している。
以下については、そういった考えがある中で、Javaと認められないことよって起こった事件。

• Apache harmony事件 → OpenJDKに合流
• Android事件 / Google訴訟事件 → OpenJDKになってAndroidの開発に適応されたが、既にJavaではなくKotlinが主流に。

※現在はOpenJDKが唯一のOSS版Javaになっている。

今の主流は各社が提供するOpenJDKを利用することが主流。
各社によって少しずつ提供するツールは異なるが、コア機能については100%同じ。他の部分も99%は同じ。

Javaのように長い歴史と巨大なエコシステムを伴うものをOSS化していく上で相当な努力があった。

講演『エコシステムと WebAssembly』chikoski氏 / WebAssembly Night、Rust.Tokyo 主催

WebAssembly、聞いたことはあるけれど触ったことがなかったし概念もよく分かってなかったので、そもそもWebAssemblyってなに？ってところからお話いただいたのとてもありがたかったです。

特に印象に残ったお話

Rust.Tokyo 2021： 9/18 開催

WebAssemblyは C / Rust / Assembly Script などをコンパイルしてブラウザで高速に動かせるようにしたもの
ブラウザの上でJavaScriptではないプログラム（C++など）を動かしたいというニーズはずっとあった。
VimをWebAssemblyで動かしてブラウザ上で動かしているというツールも既にある。
他にも、Webアプリでは Acrobat / Squoosh / Zoom / Autocad、サーバレス環境では Envoy / Istio など、利用例は広がっている。

WebAssemplyが利用されるにつれてニーズが分類できるようになってきた。それがエコシステムとパフォーマンス。
パフォーマンスについて、WebAssemblyはネイティブよりも1.2倍遅いと言われてはいるが、ブラウザで処理することでAPIでアクセスすることもなくなり、そのレイテンシがいらなくなるなど、純粋に比較することは難しい。
パフォーマンスはJavaScriptよりも安定していると言われている。常に同じようなパフォーマンスで動いてほしいというニーズに合っている。

現在はパフォーマンスよりもエコシステムについての期待が高い。
既にある資産をJavaScriptに書き直すのではなく、WebAssemblyを使うと少ないコストでブラウザ上で動かせるというメリットが大きい。
手に馴染んだ言語が使え、開発者体験をの向上が期待できる。（学習コストや既存資産の活用など）

WebAssemblyの利用事例：Shopify
Getting started

言語を選定する上で、Performance x Flexibility x Security を考える必要がある。WebAssemblyは以下の通りニーズを満たせる。

• Performance
  • サーバー内の実行
  • ネイティブコードの事前生成
  • 精製したコードのキャッシュ
• Flexibility
  • プログラムなのでユースケースが広い
  • いろんな言語で実装可能
• セキュリティ
  • メモリ保護
  • 安全な実行コードの生成
  • アイソレーション

WebAssemblyはコンパイル・デコンパイルができるので、コンパイル後のもののコードが読めるというメリットもある。
Wasmファイルはコンパイルによって作られる関数定義のまとまり

WebAssemblyの辛いところ

• Wasmにはバージョンがなく（1で固定されている）、仕様もさまざま。
  • Roadmap - WebAssembly
• データ表現に関する規定がない。
  • 言語ごとにライブラリを提供し、それを使ってデータ表現を統一しながらコンパイルをしていく必要がある。

全体を通して

全体を通して、OSS化によって言語の発展が活発になっているというポジティブさを感じました。
その一方で、ボランティアで成り立っている以上、開発者の生活をどう支えていくかについて課題を感じているという意見も複数あり、OSSの難しさもあるなぁと思いました。
セッション途中で紹介されたGitHubスポンサーがとても良い仕組みですね。

楽しかった〜！

モブプログラミングのやり方がぎゅっと詰まった「モブプログラミング・ベストプラクティス」を読んだ

「モブプログラミング・ベストプラクティス」を読みました。

"モブプログラミング"とは、3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していくことです。
モブプロをチームで実践したことがないまま、「みんなが集まって一つのコードを修正するって非効率じゃない？」寄りの考え方だったんですが、この本ではそんな考え方に対する回答も書いてくれていて、納得しつつ読み進められました！

モブプロというテーマだけで一冊の本になっちゃうほど色々とプラクティスが詰まっていましたが、どれも丁寧に解説されていてわかりやすい＋モブプロを始めるイメージがつきやすい本でした。
サラッと読めるし、手元に置いておきたい。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

📖 目次

• 1章　なぜモブプログラミングなのか
• 2章　モビングの始め方
• 3章　モビングと人
• 4章　モビングの軌道修正
• 5章　定期的なモビングのための仕事場の改造
• 6章　モビングを定着させるためのチームへの働きかけ
• 7章　フロー重視の考え方
• 8章　モビング定着後の長期的な展望

リソース効率とフロー効率

冒頭で書いた「みんなが集まって一つのコードを修正するって非効率じゃない？」という考え方をしている人は7章「フロー重視の考え方」がオススメです。
リソース効率とフロー効率という言葉は先日取得した認定スクラムマスターのトレーニングでもサービスの改善（ビジネスの俊敏性）を上げていくために重要な考え方として解説がありました。

書籍ではリソース効率・フロー効率のそれぞれについて次のように解説されています。

リソース効率

リソースを最大限使おうとする考え方。
例えばフロントエンドの仕事があるたびに、それを早くこなせる人に仕事を振る。
リソース効率を重視するとスペシャリストとボトルネックが作られていく。（スペシャリストの作業待ち、キャパオーバーなど）
新機能の開発コストを下げる

フロー効率

機能全体を早く市場に送り出すことを重視する考え方。
チームは一丸となって新機能に取り組む。
フロー効率を重視するとゼネラリスト（広範囲で知識・技術がある人）が作られ、機能を早く市場に送り出すことに力を入れられるようになる。
新機能を早く市場に送り出して利益を得る

リソース効率・フロー効率についてはこのスライドもわかりやすく解説されていて参考になります。

フロー効率性とリソース効率性について #xpjug from Itsuki Kuroda

www.slideshare.net

モブプログラミングはフロー効率をあげるためにコストパフォーマンスの良い方法です。

モブプログラミングの成功をどのようにして計測するか

新しい取り組みを進めていくときにはちゃんと効果を出せているのか不安になると思います。
そこで最初に期待値を設定しておくことが重要と「1.3.2 成功をどのようにして計測するか」に書かれていました。
モブプログラミングが解決する問題は複雑なので計測が難しく、チームが直面する課題によっても変わるという前提で、計測方法として検討する価値があるものとして以下が挙げられています。
上２つは定量的で計測可能なもの、下２つは定性的でメンバーにヒアリングしていくものです。

• マージコンフリクトの解決にかかる時間の短縮
• 本番システムに入り込む欠陥の数の減少
• チーム内の経験の浅いメンバーの学習度の上昇
• チームがモブプログラミングの導入を改善と感じているかどうか

モブプログラミングのタイムテーブル

効果的にモブプログラミングをしていくためには「準備としてのお膳立て」や「モブプログラミングの振り返り」というのもタイムテーブルに組み込んで、モブプログラミングをやる意義の理解や改善をしていくことが大切です。
（モブプログラミングって、人が集まって急に始めていくものかと思っていました…。）
「2.3 お膳立て」のコラムに書かれているモブプログラミングのタイムテーブルがこちらです。

• 準備：お膳立て（30分前後）
  • モブという形でひとつの仕事に取り組むことの意義を説明する（10分）
  • モビングでの役割分担を説明する（8分）
  • モブが解決する問題の概要を説明する（10分）
  • タイピストの順番を決める（2分）
• 本体：モビングインターバル（1時間30分前後）
  • 最初のタイピストにキーボードを渡す
  • タイマーを10分にセットして開始する
  • モブ全員が協力して問題の解決のために努力する
  • 10分経過したら、タイピストは作業を中止して次の人に交代する
  • セッション終了の20分前まで、タイマーをセットし直して、インターバルを繰り返す
• 締めくくり：経験からの学習（20分前後）
  • それまでのセッションを振り返り、うまくいったこと、うまくいかなかったことを挙げ、次回の改善方法を議論する

英語のスライドですが、冒頭のモブプロの説明を補うために使えるオンラインスライドも提供されています。
モブプロの進め方の動画も差し込まれているので、使いやすそうなスライドだと思います。
Introduction to Mob Programming

💬 まとめ

他にもモブプロを進めていく上でのチームとしての課題に対するアプローチや、モブプロを取り組みやすくするためのアプローチ（席やホワイトボード・ディスプレイの配置なども含めて）など、幅広くしっかりと解説されていました。
モブプロを始めたくなる一冊ですし、始めた時に手元に置いておきたくなる本だと思いました！

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

チームビルディングのためにお互いの性格を知る『ビッグファイブ性格特徴モデル』

チームビルディングでは、チームでより大きな力を発揮するためにメンバー同士がお互いのことを理解することが大切です。

それぞれの個性をあらわし、理解する時に時に役立つのが、「ビッグファイブ性格特徴モデル」です。
これは科学的・心理学的に信憑性があり、世界のさまざまな文化の違いを超えて信頼できることが証明されている分析方法で、性格は次の5つの要素の組み合わせによって決定されるという考え方です。

• 外向性（外向 ←→ 内向）
  • 社交的・話好きで活発な振る舞いをする
• 協調性（協調 ←→ 排他）
  • 他人に対して思いやりがあり協力的
• 勤勉性（勤勉 ←→ 怠惰）
  • 自己コントロールをして忠実に行動する・達成を目指す・計画的
• 情動性（論理 ←→ 情動）
  • 心理的ストレスを受けやすい
• 創造性（創造 ←→ 保守）
  • 珍しいアイデア・好奇心・目新しさや多様性を好む

この性格診断は、それぞれの要素があるかないかの◯か×かで判断するのではありません。
要素に対してどの程度か を判断していきます。
また、この診断は人間の優劣をつけるものではなく、人間の強みを調べるものだということを理解しましょう。

ビッグファイブの診断ができるサイトは多くあります。
私は次のサイトを試してみました。120問の方も10分程度で終わったので是非やってみてください。

• 15問の質問に答える：性格診断｜心理テスト性格診断無料
• 120問の質問に答える：科学的性格診断・心理テスト | Big5-Basic（ビッグファイブ・ベーシック）

自分の個性タイプがわかったら、チームビルディングのためにお互いに説明することでコミュニケーションのヒントにしていきます。
ただし、個性タイプを示すことは結構勇気がいることだと思うので、それぞれのメンバーがグループに対して信頼を寄せていなければならないし、かつ何のためにそうするのかを理解している必要があります。
説明をする場には、管理職など自分の昇進・昇格に影響があると感じる人はいない方が心理的な安全性は高くなります。

グループディスカッションをする時には以下のような流れが参考になるかと思います。

• メンバーに対して個性の説明をする
• 進行役が説明者に以下の質問をする
  • 今の説明はあなたがどういう人間化をよく表していると思いますか？
  • この評価を見てどう感じましたか？
  • この評価は正確ですか。正しいところとそうでないところを詳しく説明してください。
• チームメンバーの話をきく
  • この評価は役に立つと思うか
  • 今挙げられたこと以外で持っていると思う長所は何か

参考： モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

こういった性格の理解をお互いに深めていくことでチームメンバーがどういった力をチームで発揮してくれるか考えていけるヒントになると思います。

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

おまけ

恥ずかしいけど私の結果も出しておこう。
科学的性格診断・心理テスト | Big5-Basic（ビッグファイブ・ベーシック）を使ってテストしてみました。
この後に色々と細かい説明が記載されています。

多分、3年前の自分とも全く結果が違う気がする。。。

認定スクラムマスターを取得しました！

2/1 - 2/5に認定スクラムマスター取得のためのトレーニングを受講し、2/10に試験に合格して無事に認定スクラムマスターの資格を取得しました！
証書にはトレーニング完了日が記載されるようですね。

認定スクラムマスターを取得しようと思った経緯

2年前にアプリケーション開発者をしていたときにアジャイルの考えを取り入れた開発をしていました。
開発手法は私自身の興味領域でもあったので、これまでもスクラムガイドを読んだりスクラム関連の書籍を読んだりしてきました。
しかし、これからの仕事でスクラム開発に関わる可能性が出てきて、きちんとスクラム開発を学びたいと思い、認定スクラムマスターのためのトレーニングと認定取得にチャレンジすることにしました。

トレーニングの内容

トレーニングはこちらから申し込みました。
これで、5日間のトレーニングと2回の認定資格受験資格をもらえます。
www.odd-e.jp

5日間のトレーニングはすべてオンライン（Zoom）で開催されました。
9時から15時までワークショップを含めたトレーニングがあり、その後に16時まで質疑応答の時間が設けられていました。
ワークショップは少人数のチームに分けられてMiroを利用してリアルタイムにボードを編集しながら進めていきました。

トレーニングでの講義やワークショップでは、「アジャイルやスクラムで大切にしている考え方」や「スクラム開発での役割の理解」に関する内容が多かったです。
「デイリースクラムとは」「スプリントレトロスペクティブとは」という細かいプラクティスに関する内容は少なく、「アジャイルソフトウェア開発宣言」や「スクラムマスター・プロダクトオーナー・開発者の役割」「最初のインプットとなるプロダクトバックログとは」「チームの作り方」というようなベースとなる考え方の理解を重点的に解説やグループワークによる議論を進めていきました。

色々と勉強になる点は多かったですが、スクラムマスターの研修ということで参加前には「スクラムマスターはどんなことをしなければいけないのか学びに行こう」という気持ちでしたが、スクラムマスターは自立自走を促していって、最終的には何もしなくても問題ない状態になるよう働きかけていくということを学びました。

トレーニングを受けるにあたり、スクラムの前提知識はそこまで必要ではなかった気がします。ただ、トレーニング前に以下のドキュメントとサイトに目を通しておくように案内はありました。
こちらを事前に読んでおけば、トレーニングでついていけないということはないと思います。

• スクラムガイド https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
• 2020年版 : https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
• アジャイルソフトウェア開発宣言 http://agilemanifesto.org/iso/ja/manifesto.html
• Agile Principles http://agilemanifesto.org/iso/ja/principles.html
• スクラムリファレンスカード http://scrumreferencecard.com/ScrumReferenceCard-jp.pdf

個人的には15時以降の質疑応答の時間が楽しかったです。
講義の内容についての質疑応答ももちろんありましたが、「自分の現場ではこういう問題が起こっているけど、どうしたらいいか」というような相談会にもなっていて、他の参加者の実態なども知れて面白かったです。
その時間でトレーナーの方の話を聞いた結果、（スクラム開発ガイドには準拠するという前提で）問題が発生した時にこうするべきだというプラクティスはなく、関わる人たちの話を聞いてチームで解決できる道を考えていくという回答が多くありました。
スクラムマスターは答えを提示する役割ではなく、スクラムチームが自分たちで解決方法を見つけられるように促していくという役割であることが、質疑応答の時間からも理解できました。

テストの内容

トレーニングで認定試験を受験しても問題ないとトレーナーに判断されたら受験資格をもらえます。
（推測ですが、私の受けたトレーニングでは全ての方にトレーニング資格が届いていたのではないかと思う・・・）
資格試験は2回受験でき、一度は落ちても大丈夫とのことでした。

資格試験はWebで自宅から受験でき、日本語を選択可能で、選択式の問題でした。
スクラムガイドの内容を理解できていたら落ちない試験かと思います。

これから

今回、晴れて認定スクラムマスターになりました🎉
トレーニングの内容を理解できたことと、試験に合格したことで自信も得たので、これから仕事にも活かしていきたいと思います✊

また、研修の中でいくつか書籍も紹介いただいたので、それを読みつつ更に理解を深めていこうと思います。

(参考) 講義で紹介されていた書籍

リーン・スタートアップ　ムダのない起業プロセスでイノベーションを生みだす
学習する組織 ― システム思考で未来を創造する
大規模スクラム Large-Scale Scrum(LeSS)

動画のサイズを減らすffmpeg

オンラインの仕事も増えて、動画を作って触ることが増えました。
iMovieなどの動画編集ソフトで動画編集もするのですが、編集した動画をエクスポートすると基本的にファイル容量が増えてしまいます。（元々が200MB程度だった動画が1GB近くなったりしていた。）
動画を仕事相手に共有する際の制約などから動画のファイルサイズを小さくしたかったのですが、やり方が分からずとても苦労していました。
実際に編集ずみの動画を画面に流して画面収録で取り直したり。。。

そこで、ffmpegというツールを知り、コマンドで簡単に動画サイズを縮小できたので、自分用にMEMOしておきます。
具体的には、
元ファイル：200MB → 動画編集ずみ： 900MB → ffmpeg：200MB
くらいになったので、個人的には大満足の結果になりました。

インストール方法

macの場合は Homebrew を使って簡単にインストールできます。

brew install ffmpeg

WindowsやLinuxのパッケージもあり、ここからダウンロードできます。
Download FFmpeg

動画のサイズを減らす

動画には詳しくないのですが、CRFというエンコーダーの数値があり、それを指定して動画変換することで動画サイズを圧縮できました。

コマンドとしては以下のようにオプションを指定します。

ffmpeg -i input.mp4 -crf 18 output.mp4

圧縮方法によってCRFのデフォルト値は異なり、CRFの値は小さくなるほど品質が良く、大きくなるほど品質が悪くなっていきます。
こちらのサイトによればそれぞれの圧縮方法に対してのCRFデフォルト値は以下のようになっており、±6の変更によってファイルのサイズは半分もしくは2倍になるとのこと。

• x264 : 23
• x265 : 28
• 1080p HD video : 31

上記のコマンドとして記載している18は品質をかなり良いものにしているのですが、iMovieなどの動画編集ソフトで付けられた無駄なファイルサイズを削減することが目的であり、動画品質はなるべく落としたくなかったので全く問題ありませんでした。
動画変換後も私が感じ取れる品質の変化はありませんでした。

参考：
FFmpegで動画変換！各OSごとのインストール方法と使い方まとめ｜新卒エンジニアの開発日記
CRF Guide (Constant Rate Factor in x264, x265 and libvpx)

オンライン飲み会（やミーティング）を切り上げるためのクソアプリ

この記事はクソアプリ Advent Calendar 2020 - Qiitaに参加したかったけどできなくて羨ましくてクソゥ！な私が気持ちの供養のために作ったクソアプリの紹介です。

どんなアプリ作ったの？

オンライン飲み会では切り上げるタイミングがわからず、グダグダとなんの盛り上がりも無いまま時間が過ぎていくことがあります。
（そして、オンラインミーティングでは、参加者からの厳しい質問の中で回答が浮かばずにミーティングを切って逃げたくなることがあるでしょう。）
そんな時に、何か言い訳があれば…。みんなが仕方ないと思うような言い訳があれば…。
そんな全人類のためのアプリを作りました。…クソアプリじゃないな？？？

アプリの動き

言い訳が表示されているので、ラジオボタンで選択して「失礼します。 😫」ボタンを押します。
その言い訳に合わせた音声が流れてくれるので、あとは選択した「言い訳」と「失礼します」を申し訳なさそうな顔😫で言って「退出」ボタンを押しましょう。
「退出」できたら「抜け出し成功 😏」ボタンを押して音声を止めます。

実際のサイトはこちらで試せます。（音量注意）
オンライン飲み会を終ろう

クソアプリのイメージ動画です。（音量注意） https://t.co/GIcaiuczmJ pic.twitter.com/45R5wXvU65

— しょぼちむ 🤟 (@syobochim) 2020年12月16日

アプリのコードはこちらです。
github.com

音声の出し方

音声はHTMLの

HTMLに以下のように記載して

<audio id="aka-naki" preload loop>
    <source src="audio/aka-naki.mp3" type="audio/mp3">
</audio>

JavaScriptを使って再生する。
JavaScriptを使わなくてもHTMLだけで音源の再生は可能ですが、今回はボタンを押したイベントで音声を流したかった。

const iiwake = document.getElementById(reason);
// 再生
iiwake.play()
// 停止
iiwake.pause()

終わりに

本家のアドベントカレンダー、見ていてとても楽しい！