RSGT2022の発表資料の行間を埋める説明文書
2022年1月6日に、Regional Scrum Gathering Tokyo 2022 (RSGT2022)で、『社内アジャイルコーチの卒論』と題してお話しさせていただきました。
プレゼン資料はこちらです。
一方で、プレゼン資料だけでは伝えづらい「行間」というものもあります。それらを埋めるための説明文書を作成しましたので、共有させていただきます。プレゼン資料と一緒に確認していただければ幸いです。
はじめに
私は、2021年8月末日でLINE株式会社を退職しました。これは、2012年12月に楽天株式会社に入社して以来約9年間続けてきた、社内アジャイルコーチを辞めたということでもあります。
この9年間、非常に多くの人・チーム・組織に関わり、数多の実験と失敗を重ね、社内アジャイルコーチとしてのキャリアを積み重ねてきました。
この度、社内アジャイルコーチを辞するにあたり、これまでのキャリアで得た多くの事例・知見をアジャイル実践者の皆さんに共有することは、日本および世界のアジャイルコミュニティへの貢献になると考えました。
9年の蓄積を45分のセッションで全て話すことは非現実的であるため、説明のしやすさの観点から、(1) チーム、(2) 技術、(3) 組織の3点からお話させていただきます。
1. チーム
この章では、「ヒト」およびその集合である、「チーム」の扱い方について説明します。
アジャイルの文脈では、次のようなチームにどのように接するべきかが、よく議論されます。
- アジャイル初心者のチーム
- 各ロールのエゴが強くて対立の多いチーム
- 他人事感の強いチーム
社内アジャイルコーチとしての経験から言うと、これらへの唯一の正解はなく、自分たちが試行錯誤を繰り返した中で、うまくいったと感じられたものが「正解」と考えます。
そこでこの章では、私が実際に試して「正解」だと感じたものをご紹介します。
(1) アジャイル初心者のチーム
このチームは、「学ぶ」ということを知らないということが主要な課題です。加えて、失敗を恐れ、効率的に学習できない傾向もあります。特に日本人のみで構成されるチームの場合、この傾向が顕著です。さらに、「会社は勉強の場じゃない」・「会社で勉強するな」のような発言をする上司がいる場合、学ぶことを悪だと捉えるバイアスがここに加わります。
上記のようなチームにおいて社内アジャイルコーチは、チームに入り一員となり、一緒に痛い目に遭いながら背中を見せ続けることで学び方を教えるアプローチが有効に機能します。さらに、基本Teaching、場に応じてFacilitatingを使い分ける方法が有効です。
具体的には、コーチが実験と失敗を何度も見せ体験させることで、失敗で学習を加速するという体験をチームに提供します。加えて、コーチが率先して失敗することで、チームに対して「失敗しても大丈夫だ」という安心感・心理的安全性を提供できます。さらに、そのような振る舞いに興味を示すチームメンバーがいる場合、その人が強力な改善のドライバーになりうるため、コーチとしての経験やスキルを教え込むと良いです。また、勉強することで成果につながることを、結果として上司に見せ続けることで、上司が納得せざるを得ない状況にすることも、有効なアプローチです。但し、そのような上司は、後で決定をひっくり返す恐れもあるため、成果を出した段階で必ず意図を説明し、協力を取り付けることが肝要です。
(2) 各ロールのエゴが強くて対立の多いチーム
このチームは、「こんなことも分からないの？」・「これはルールだから従え」のように、他者を攻撃する話し方が多いことが、特徴であり課題です。
より具体的には、「自分の前提は正しい」・「自分の前提は他者も理解しているべきだ」という思い込みを各メンバーが持っていること、またその思い込みを他者に明示的に伝えていないことが共通点です。
そうした思い込み、および言葉と前提のズレの存在を見える化し、チーム全体で認め合うこと、その上でチーム共通の目的に各自の前提を合わせることが、基本的な解決方針となります。その際、NVC（Nonviolent Communication）が有効なアプローチとなります。メンバー間の言葉と心の距離を縮めることができます。
(3) 他人事感の強いチーム
このチームは、自力での課題解決の意思・能力が薄弱で、いつも「他の人・チームがやってくれるはず」と考えていることが課題です。従って、そのチームを課題解決の当事者としてしまうことで、当事者意識への「バリア」を無理やり消すことが、一つのショック療法として有効です。
Flywheelのメタファというものがあります。Flywheelは、ちょっと回しただけではすぐに止まってしまいます。回し続けるためには、常時力を与え続ける必要があります。一方で、力を与え続けると、加速度が徐々に高められます。このFlywheelと同じように、チームを当事者にし続け、常に活動し続けるファシリテーションが、改善に有効に作用します。
また、他人事感が強まる原因として、他の人・チームがボトルネックであるケースがあります。その場合は、社内アジャイルコーチとして、チームと一緒にボトルネックを解決することが、当事者意識を高める点でプラスです。
同様のことは、経営層がコーチ任せの場合にも当てはまります。逆に、経営層のコミットが得られない場合は、遅かれ早かれ施策をひっくり返されるため、チームから離れることを私は勧めます。
この章のまとめは、次の3点です。
- アジャイル初心者のチームは、コーチが背中で学び方を教えることが有効です。
- 各ロールのエゴが強いチームは、NVCで言葉と前提のズレを正すことが有効です。
- 他人事感の強いチームは、当事者意識への「バリア」を消すことが有効です。
2. 技術
この章では、アジャイル推進時に常につきまとう、「技術」の扱い方について説明します。
アジャイルの文脈では、技術の扱い方について、次のような議論がよく行われます。
私の社内アジャイルコーチとしての経験から言うと、これらもケースバイケースです。「コンテキスト依存」という言い方もできます。
一方で、いずれの方法が妥当かを判断する根拠は、あった方が便利です。私はこれまでの社内アジャイルコーチとしての経験から、「MUT」という判断軸を活用しています。
「MUT」とは、以下の英単語の頭文字をつなぎ合わせたものです。
- Maturity: チームの成熟度
- Urgency: 緊急性
- Trust: コーチへの信頼度
ちなみにこの「MUT」は、あくまで私個人の経験ベースで生み出したアイデアで、学術的な裏付けはないです。加えて「MUT」は、厳密に数値的に表現し判断するというよりも、それぞれのバランスを見て判断する形を取ります。社内アジャイルコーチとしての「観察眼」が、そこでは役に立ちます。
(1) 「開発の足回り」
CI/CD/DevOpsなどは、誰がどこまで整備するべきでしょうか？先の「MUT」では、次の2つのパターンが考えられます。
(a) アジャイルコーチが実施するパターン
Mがやや低く、Uが高い場合が、このパターンに当てはまります。
このパターンは、チームに整備の経験がない場合に有効です。また、アジャイルプロセスの習得の緊急性が高い場合、こちらの方が集中しやすく、また後で自動化による加速度的効果を得られやすいです。そのため、私が好んで使用するパターンでもあります。
但し、チームが（社内）アジャイルコーチに頼る恐れ、また（社内）アジャイルコーチがチームに過度にコミットしてしまう恐れがあります。そのため、一人でやりすぎず、必ず早期にチームに引き継ぐTeachingを意識することが重要です。
(b) チームに任せるパターン
MTが高くUが低い場合が、このパターンに当てはまります。
このパターンは、チームに整備の経験がある場合に有効です。また、アジャイルプロセスの習得の緊急性が低い場合に馴染みやすいです。
このパターンでは、Facilitatingが機能しやすいです。Lintやセキュリティチェックなど、チームがまだやっていないことに目を向かせると良いです。他にも、セキュリティチェックやdeployの高速化など、工夫をインストールできる余地があれば、それらにも目を向けられるようにしましょう。
(2) テスト自動化
これも、誰が何をどこまで行うべきでしょうか？先の「MUT」では、次の2つのパターンが考えられます。
(a) チームに任せるパターン
MTが高くUが低い場合が、このパターンに当てはまります。
テスト自動化が（アジャイルでは）開発の一環となりつつあること、およびプロダクトの責任範囲を考えると、チームが担当するのが理に適います。
このパターンでは、ペアプロなどを活用し、開発の一環としてのテスト自動化の考えをインストールするFacilitatingをお勧めします。
(b) アジャイルコーチが実施するパターン
Mが低くUが高い場合が、このパターンに当てはまります。
このパターンは、チームの作業の代行者には絶対にならないことが重要です。チームの成長を阻害しかねません。また（社内）アジャイルコーチは、これが面白くなりすぎて全てやろうとする誘惑に打ち克つことも求められます。
そのため（社内）アジャイルコーチとしては、Teachingを活用し、最初の例の作成に止め、チームメンバーにやり方を教えることにフォーカスすることをお勧めします。
(3) 開発そのもの
（社内）アジャイルコーチは、どこまで関与・寄与すべきでしょうか？
アジャイルコーチが実施するパターン
Tが極端に低い場合が、このパターンに当てはまります。
但しこのパターンは、チームの信頼を急ぎ得る必要がある場合だけ限定した方が良いです。例えば、「理論倒れ」はのコーチは、実際嫌われる傾向があります。そのような問題を回避するために、自身の実力を見せつつ、課題解決を一緒に行うことで、一体感を生み出す「必要悪」的に活用しましょう。
また、どこかで第三者視点を失いかねないリスクがあるため、必要な信頼を得られたら、早期にチームに任せましょう。
この章のポイントは、「チームの学習・成長が全て／中心」であるということです。
社内アジャイルコーチは、触媒・潤滑油であることに徹することが重要です。加えて、実務の実施主体にはならないことも必要です。さらに、これらのパターンだけで情報収集をしすぎないことも必要です。過度のメトリクスは、「管理型」へ陥る恐れがあります。
この章のまとめは、次の3点です。
- MUTのバランスで判断することが有効です。
- コーチの観察眼を活かしましょう。
- ひとりでやりすぎてはダメです。
3. 組織
これまでの章では、チーム・メンバーがメインの説明をしてきました。この章では、一つのチームを良くしただけでは解決できない、組織レベルの課題へのアプローチを説明します。
私たちは、アジャイルに限らず、次のような議論をよく耳にします。
- 会社よりもコミュニティの方が自分を認めてくれるのではないか？
- コミュニティは「逃げ」で、仕事ができない人の集まりなのではないか？
- この会社・同僚・上長・役員に人生を賭ける価値はあるだろうか？
これらの議論は表層的で、より深い分析が必要と私は考えます。私はこれらの分析のために、組織の内側と外側、公式と非公式からなる4象限の考え方を活用します。以下では、この4象限に沿って、先の議論を分析していきます。
(1) 社内の仲間
組織の内側・非公式にある「社内の仲間」・「社内コミュニティ」については、「心のValue Stream」の構築が重要と私は考えます。これは、社内で、価値を共有できる同士、および業務を進める上で協力できる仲間・チームを見つけ、その組み合わせでvalueの提供・価値観の共有・心が折れそうな時のリカバリをできるようにするという意味です。
ちなみにこの言葉は、私の思いつきです。適切な用語があれば、教えてください。
(a) 社内の「お隣さん」を味方につける
これは、書籍『アジャイルサムライ−達人開発者への道』にも書かれている考え方で、自分たちの近くにいるキーパーソン・チーム・組織と関係を構築し、成果を出しやすくしようというものです。
(b) Spotify Model
これは、組織の公式のラインだけではなく、プロダクトや同様の関心事を持つ人たちによるマトリクス型の組織及びコミュニティを活用しようという考え方です。
(c) オーラの泉メソッド by 川口さん
これは、RSGTの運営委員でもあるかわぐちやすのぶさん発案の考えです。自分以外に同じことを言ってくれる人がいることで、自分の主張を他の人にもシームレスに届けやすくなります。
(2) 社外の仲間
組織の外側・非公式にある「社外の仲間」・「社外コミュニティ」は、会社という「前提」から離れて考える点で有効です。
具体的には、会社・社内だけに目を向けていると、視野が狭くなり、心身を消耗させるリスクがあります。加えて、社外コミュニティOSSは、情報収集や学習の手段として有効です。さらに、会社の改善の観点では、「外圧」「世論」を有効活用できることがあります。
また、社外に目を向けることは、決して「逃げ」ではなく、「スキル」であると私は考えます。というのも、社外に目を向けることで心をリセットすることができ、Burnoutを予防・防止することができます。また、良いコンディションは、良い価値を生み出しやすくなる源泉でもあります。
(3) 自社の経営層
組織の内側・公式の、特に「経営層」は、尊重しつつ過度に頼らない、「条件付き利用」という発想が「安全」です。
というのは、経営層の全社的視点と影響力は、明らかに有効ではあります。一方で、常に味方とは限らない点に注意する必要があります。
特に、経営層が意思決定の意思・能力を持たない場合、全部丸投げされて逃げられることもあります。そのような兆候が見えた場合は、強い意志を持ってその組織を離れることを、私はお勧めします。
この章のまとめは、次の3点です。
- 社内の仲間のチェーンを構築しましょう
- 社外に適切に目を向けるスキルを身につけましょう
- 自社の経営層は、距離を縮めつつ依存はしないようにしましょう
結論
ここまで色々とお話しさせていただきましたが、私は社内アジャイルコーチとして、次のように多くの失敗をしてきました。
まず、ラインマネージャーになり、昇進に目が眩み、アジャイルコーチとして皆を成長させることよりも、会社の経営方針にメンバーを従わせることを優先するという失敗をしました。
次に、アジャイルに理解のある同士、自分を理解してくれる同士を社内に見つけきれず、孤独に負けました。
さらに、会社を信用しすぎました。マネージャーや役員に嘘をつかれ、守るべきチームが切り捨てられました。役員間の対立のとばっちりを受け、仲間やチームが会社を去っていきました。会社が自分と同じ方向を向いていると思い込んでいました。
身から出た錆も多いのですが、こうした失敗から私は、以下のことを学びました。
まず、常に自身を組織の外側に置き、当事者にはならないことです。課題は理解するものの、課題解決の当事者にはならないこと。また、自分自身は課題を解決するための手助けであり続けること。これが、アジャイルコーチとして心がけるべきことです。
次に、社内外に仲間を増やすこと。社内に同好の士のチェーンを作ること。社外のコミュニティにも自身の居場所を作ること。社外にメンターを見つけ定期的に対話すること。これらは、孤独に打ち勝ち、自分自身を成長させ続けるために有用です。
さらに、自身の組織での栄達よりもコーチ対象の成長を、そして自身の成長を重視することです。一生涯学習し続けること、そして「教える」であり「教わる」であり続けることが、持続可能かつ実りの多い人生となります。
私自身、ニックネームが「ヒーロー」であることもあり、多くの人の役に立つ「ヒーロー」として、そして「ヒーロー」としてのアジャイルコーチというものを度々意識して行動し続けてきました。
しかし、今の私ならば、自信を持って言えます。火消しのように、無理して目立つような存在としてのヒーローは、もう要りません。自分だけがヒーローになる必要はないし、みんなをヒーローにする必要もありません。
自身と関わる人たち全てが刺激し合いながら成長し続け、課題を解決し続けること。そのための一助であり続けたい。それが、私が社内アジャイルコーチを卒業してたどり着いた、今の境地です。
AWS初心者が半年でSolution Architect Professionalを取得するまで
2021年に転職したことをきっかけに、2021年7月末からAWSの勉強を始めて、12月初めにSolution Architect Professionalを取得しました。
後で同僚に聞いてみたところ、初心者＆年齢を考えるとかなり早いペースだと言われたので、（後日自分が詰まった際に思い出せるように）勉強方法をまとめてみました。
前提：どのくらい初心者だったか
それまでずっと社内クラウドのある会社にいて、パブリッククラウドはせいぜいGCPでKubernetes The Hard Wayをやってみた程度。IAMとAMIの区別も曖昧だったレベルでした。
一方で、Kubernetesを1年半ほど管理・運用していたこと、またKubernetes Podcast from Googleのヘビーユーザーだったこともあり、全く何も知らないという状況ではなかったです。
(1) AWS Certified Cloud Practitioner (CLF)
- 取得: 2021年7月29日
- 勉強時間: 5日
こちらは、AWSの提供しているトレーニングコースだけで十分でした。
AWS Certified Developer - Associate (DVA)
- 取得: 2021年10月16日
- 勉強時間: 2ヶ月半
元々developerなので、その経験を活かして試験問題のサンプルを見てみたところ、何が書いてあるのかさっぱり分からず😧
「座学だけでは無理だな、実際に手を動かして覚えよう」と判断し、2ヶ月ほどかけて以下のことをやりました。
- Kubernetes The Hard WayをAWSでも実施
- 上記を、CloudFormationのテンプレートとしてイチから書き出して動作するようにしました。
- aws-modern-application-workshopを一通り実施。加えて、これも全てCloudFormationのテンプレートとしてイチから書き出して、動作するようにしました。
- Lambda + API Gateway + DynamoDBのシステムを、CloudFormationのテンプレートでイチから構築しました。
- AmplifyのGetting Startedサイトで、Amplify・GraphQL・Cognitoを一通り構築。これもCloudFormationのテンプレートとしてイチから書き出して、動作するようにしました。
- Kinesisのホワイトペーパーを読み、実際に動作確認しました。
加えて、受験2週間前から、こちらのサイトの問題集を解き続けて、一通り解答できるようにしておきました。
今になって考えると、Kubernetesをある程度知っていたため、「Kubernetesならばこれのことを指すのかな？」と置き換えながら理解するやり方ができたことは大きかったです。
AWS Certified Solutions Architect - Associate (SAA)
- 取得: 2021年11月2日
- 勉強時間: 3週間
DVAの問題集を解いていたところ、「これ明らかにSolution Architectの出題範囲だよな〜」という箇所をいくつか見つけていたので、DVA受験1週間前からSAAの勉強も並行して実施していました。このおかげで、DVAとつなげて理解できたことがプラスでした。
問題集を解きつつ、分からないことを見つけたらすぐに公式サイトをチェックして動作確認の繰り返しでした。
AWS Certified SysOps Administrator - Associate (SOA)
- 取得: 2021年11月12日
- 勉強時間: 2週間
これもSAAと同じ方法で行けました。DVA - SAA - SOAは、一つの科目として考えて勉強すると、補い合える点が多かったです。
AWS Certified Solutions Architect - Professional (SAP)
- 取得: 2021年11月29日
- 勉強時間: 2週間ちょっと
DVA - SAA - SOAで学んだ知識をベースに、仕事を終えてから毎日夜11時くらいまで、また土日のどちらかを丸一日この試験の勉強に充てて、ひたすら問題を解き、分からないことを見つけては調べることの繰り返しでした。
ただこの方法は、知識だけではなく非常に長い問題文と選択肢を読み抜く気力と体力、そして「てにをは」や明らかにおかしい翻訳に負けない精神力が試されるこの試験を乗り越える手段としては有効だったと思います。
この試験については、多くの問題に触れておくことと、本番試験で日本語だけではなく英語でも問題と選択肢を確認することがポイントでした。
まとめ
改めて振り返ってみると、以下の3点をひたすら地味にやり続けたと言えます。
特に個人的には、CloudFormationのテンプレートに書き起こすことが、各種リソースやAPIを知り、次に調べるべきことを見つけられた点で有意義でした。
この調子で、次はAWS Certified DevOps Engineer - Professionalを狙います。
オンラインイベントをより「productive」にする1私案
昨日9/18（土）、XP祭り2021に参加させていただきました。また、久々に登壇もさせていただきました。
同イベントは、20周年記念であることに加え、キーノートの同時聴講者数が400名前後に達するなど、非常に盛況でした。
一方で今朝、気になる投稿を見つけました。
XP祭りに参加して今日思ったのが、セッション聴きながらリアルタイムでDiscordで書くコメントって、気をつけないとなって思った。
— はち@複業PdM (@PassionateHachi) 2021年9月18日
自分も経験があるけど、話してるときに
「いや、そうはおもわない」
「話すスピードが…」
「え？」
とかは、思ってるより、登壇者を不安にする。すごく影響受ける。
実は私も、聴講者からのフィードバックを少しでも取り入れて場を盛り上げようと、スマホでDiscordを表示しながら登壇していたのですが、
「それって間違ってない？」
的な言葉がまず目に入ってウッ！となってしまい、その「不快感」的なものを消化しきれないまま朝を迎えました。*1
その一方で、上記投稿を見た際、「これは整理する価値のあるモヤモヤなのでは？」との思いも、同時に抱きました。
そこで、自身の気持ちを整理する観点からも、思いついたことを徒然にまとめてみました。
個人的体験の整理
- 問題点（だと思うこと）を指摘することを、「常に絶対的に正しいこと」と信じている人はいます。
- 加えて、どれだけキツい表現を使っても「許される」と「拡大解釈」している人もいます。
- さらに、「不快感を感じないスキルを持つのが（指摘される人の）マナーだ」とおっしゃる方もおります。
- キツい表現を、「キツいもの」と認識せずに使っている人はいます。
- これは、年齢ではなく、気付いているか／キツいという経験をしたことがあるかどうかの問題だと、個人的には思っています。
- 登壇者よりも「優位に立ちたい」観点から、誹謗中傷に及ぶ人もいるかも知れません。
聴講者が上記のように振る舞うことで、登壇者が「嫌な思い」を強く感じてしまい、結果登壇を止めるに至った場合、それは我々にとって「プラス」なのでしょうか？これは、一度考えてみる価値のある問いだと思っています。
「言葉の不快感」にまつわる理論
- マインドフルネス
- 私たちは会話の際、相手の表情や声色などの情動的な情報も加味して、内容を解釈します。
- 一方でメールやチャットなどのテキスト情報は、情動に関する情報がすっぽり抜け落ちます。
- 私たちは、相手の情動に関する情報が得られない場合、相手の情動を「捏造」します。加えて、「捏造」した情報は、ネガティブなものになりがちです。
- ゆえに私たちは、テキスト情報だけに接すると、「不快な」メッセージとして捉えがちです。
- アンガーマネジメント
- 私たちは、出来事や言葉を、「コア・ビリーフ」（Core belief、私たちが普段信じているもの／価値の判断基準にしているもの）に基づいて解釈します。
- コア・ビリーフは、人によって異なります。（前提が異なるとも言えます）
- 私たちは会話をする際、通常お互いのコア・ビリーフを明らかにしません。
- ゆえに私たちは、コア・ビリーフが全く異なる人からの言葉を、「言葉足らず／的外れな指摘」と感じて、怒りの感情につなげがちです。
- NVC
- 私たちは、「正しい」・「正しくない」のような言葉を使われると、身構えたり拒絶する態度を取りがちです。
- これは、「正しい」・「正しくない」といった言葉に、自身の価値基準と異なる「評価」を他者が「押し付ける」側面があるためです。
- Motivation 3.0
- 私たち人間は、己の能力を伸ばして「熟達」に向かいたいという動機付けを持っています。
- 動機付けの観点から、能力を伸ばすことに役立つフィードバックは、非常に効果的です。
Win-winになるための私案
登壇者・聴講者が、以下の形で協力しあって、一緒にセッションを作れるようにすれば良いのでは？と思っています。
- 登壇者は、「熟達」に達するために、セッションを通じて己の能力を伸ばす。
- 聴講者は、登壇者が能力を伸ばすことに役立つフィードバックをすることに注力する。
- 登壇者はそれらを「報酬」と捉え、さらに能力を伸ばすことができる。
また、上記を実現するために、以下の工夫も必要と考えます。
- 登壇者・聴講者双方は、可能な限り「コア・ビリーフ」を明らかにする。
- 聴講者は、「正しい」「正しくない」のような、自身の価値基準を押し付ける言葉遣いを避ける。
- 聴講者は、登壇者のトピックの補足や、話すスキルを高められる投稿をする。
- 聴講者は、テキストだけではなく、ボイスチャットなど情動を伝えやすい手段も活用する。
- 登壇者は、聴講者からのフィードバックに感謝の意を伝える。
わかりやすく一行で表記すると、
「登壇者 vs 聴講者」を「登壇者 + 聴講者 = イベントを最高にする」
と言えるでしょうか。
書いていて気づきましたが、これってキーノートスピーカーの平鍋健児さんがよくお話される、
「あなた vs 私」ではなく「問題 vs 私たち」の構図を引き出す
と、本質的には同じなのかも知れませんね。
参考書籍
*1:投稿の続きには、きちんと「（自分の）前提が間違っていたようです」との補足がなされていました。
山と谷の連続だった溶連菌感染症からの復帰
GW直前に溶連菌感染症を患い、１月ほど休職しておりましたが、本日6/1（火）に復職しました。
同様の症状に困っている方のプラスになればと思い、治療の経過をまとめてみました。
体調不良の兆し
2月下旬に父が一時危篤になり、それ以来実家との往復*1・母のサポートの比率*2が高まりました。
加えてこの時期、業務がやや忙しめでした。
そのせいでしょうか、喉の痛みや体の怠さを感じる頻度が徐々に増えてきていました。
父の死去 -> PCR検査
4/14に父が亡くなり、葬儀や書類手続きに追われること1週間*3。たまに声が出なくなることが何度かありましたが一切無視して、全ての作業を終えました。
そして仕事に復帰したのですが… 頭がぼんやりし、ひどい怠さに襲われ、Slackのメッセージが全く頭に入ってこない。とても仕事にならず、仲間に迷惑をかけると思い、業務を中断。
時期が時期だっただけに、新型コロナの可能性を考慮し、PCR検査を受けられる病院を探し、急ぎ受診しました。
溶連菌、見つかる
PCR検査は陰性だったのですが、一方で溶連菌が発見されました。
喉の痛み・体の怠さ・めまいなどはあるものの、咳は少なく、37度を超える発熱もあまりなし。
この症状から、医師が溶連菌感染症を疑い、気を利かせてくれて追加検査をしてくれたところ、見事にビンゴでした。
ちなみにこの病気、免疫が非常に低下している時に罹る恐れがあり、私の場合はなりに「重症」とのことでした。
処方された抗生剤を服用しながら1週間程度静養するように言われ、大人しく従いました。
まさかの薬の「バージョンミス」
薬の副作用の発熱と下痢に耐えること1週間、症状は全く改善しませんでした。
医師にも何度かこのことを訴えましたが、「治っているはず！」と一切聞く耳を持ってくれませんでした。
会社の産業医の先生に相談したところ、「（最初にかかった内科ではなく）耳鼻咽喉科を受診した方が良い」とのアドバイスをもらい、急ぎ耳鼻咽喉科を受信したところ、割とショッキングなことがわかりました。
- 最初に処方された「ペニシリン系」とカテゴライズされる抗生剤に、耐性を持つ溶連菌が存在する
- 私の感染している溶連菌は、この耐性を持つ種類だった
- （専門外の）内科の医師であれば、溶連菌感染症に「ペニシリン系」を処方するのはセオリー
つまり、「バージョンの合わない」薬を服用し続けて症状が改善していなかった＋耳鼻咽喉科を受診しないと詰んでいたと言うことです。
その後、耳鼻咽喉科で処方された抗生剤を服用することで、症状が改善しました。
さいごに
- 上記のような症状があったら、溶連菌感染症の可能性を考慮し、耳鼻咽喉科を受診しましょう。
- 症状が改善しない場合は、別の病気または薬の見直しを検討しましょう。
- 初期症状の段階で、無理を重ねていることを疑い、休息をとるようにしましょう。*4
*1:現在の住まいから片道2時間半程度。朝の始発電車で実家に向かい、やることを済ませてから現在の住まいにとんぼ返りし、仕事をするということもありました。
*2:業務時間中でも頻繁に電話がかかってくるようになり、結構堪えました。
*3:4/16（金）にDevOpsDays Tokyo 2021に登壇させていただく予定になっておりましたが、急遽キャンセルせざるを得なくなりました。参加された皆さまおよび運営の皆さまには、ご迷惑をおかけいたしました。
*4:私の場合、父の危篤・死去が原因の一つだったので、避けられなかったかもです。
DZoneの自動化テストのガイドブックを読んでみた
海外の知人からの紹介で、『DZone's 2019 Guide to Automated Testing: Facilitating Continuous Delivery』というガイドブックを読んでみました。
2019年版とちょっと古めではありますが、
- 2021年の現時点でも、実務で参考になる／役立つ点が多かったこと
- 日本国内で、同ガイドブックのまとめ記事を見つけられなかったこと
- 自分用にメモを残しておきたかったこと
から、個人的に気になった点やポイントをまとめてみました。
What Is This Guide?
- IT系情報サイトのDZoneが2019年に発行した、ソフトウェア業界における「自動化テスト」（Automated Testing）*1に関するガイドブックです。
- DZoneの読者約500名に対するアンケートに基づく分析、および同調査に協力したソフトウェアベンダー各社の自動化テストに関する寄稿文で構成されています。
- 同ガイドブックは、DZoneへメールアドレスを登録することで、無料で入手できます。
背景：なぜいま「自動化テスト」か？
- 昨今のソフトウェアプロダクト・サービス（以下「プロダクト」と表記）は、サブスクリプションベースのSaaS（Software as a Service）であることが増え、常時機能追加や変更が行われるようになってきています。
- 常時機能追加や変更を行えるようにするためには、自動化テスト・CD（Continuous Delivery/Deployment）・DevOpsが必須・前提となります。
- 手動テストは、この開発・リリーススタイルでは、どうしてもボトルネックとなりがちです。
Executive Summary & Key Research Findings
読者のアンケート結果から、自動化テストに関する以下の傾向がみて取れます。
- 「Shift Left」の拡大
- SDLC（Software Development Life Cycle）において、自動化テストの開始時期が早期化しつつあります。
- 開発フェーズから開始：54%（2018年）→66%（2019年）
- ステージング／QA／テストフェーズから開始：31%（2018年）→22%（2019年）
- 加えて、専任のQAを持たない会社・組織が増加しつつあります。（2018年：7%→2019年：44%）
- テストに関する責務を、開発者が持つ傾向が拡大しつつあるとも言えます。
- SDLC（Software Development Life Cycle）において、自動化テストの開始時期が早期化しつつあります。
- どのテストを自動／手動で行うか？
- 自動
- 統合テスト（Integration Tests）
- コンポーネントテスト（Component Tests）
- 性能テスト（Performance Tests）
- ユーザストーリーテスト（Story-level Tests）
- 手動
- ユーザ受け入れテスト（User Acceptance Tests）
- 使用性テスト（Usability Tests）
- ユーザストーリーテスト（Story-level Tests）
- Deploy後のテスト（Post-deployment Tests）
- 自動
- 自動化テストの優先度の向上
- 過去の調査結果では、会社・組織における自動化テストの優先度が低くされがちという課題がみられました。
- 一方で今回の調査結果では、自動化テストを優先しない会社・組織が減少しつつあります。（2018年：33%→2019年：28%）
- TDD
- 2018年の調査では、TDDを会社・組織内の全てのプロダクトの開発に適用するという回答者が多かったです。
- 一方で2019年の調査では、TDDを全てのプロダクトの開発に適用する回答者は減り、選択して一部のものに適用する回答者が増えています。
- TDDとDevOps専任組織との相関関係
- 会社・組織内にDevOps専任組織がある場合の方が、ない場合よりもTDDの採用率が高いです。
- DevOps専任組織の有無と、自動化テストを阻む要素との関係
- DevOps専任組織がない場合：自動化テストの作成自体が大きな障壁になっています
- Test execution and Orchestration
- Test report and analysis
- Maintaining a stable and up-to-date test lab
- Test automation creation
- DevOps専任組織がある場合：いかに自動化テストを（会社・組織全体に）広め、実施結果レポートを分析するかに視点が移っています
- Maintaining a stable and up-to-date test lab
- Test automation creation
- Test execution and Orchestration
- Test report and analysis
- DevOps専任組織がない場合：自動化テストの作成自体が大きな障壁になっています
How to Test What Matters
テストカバレッジ（Test Coverage）に潜む品質面の課題を指摘し、その上で我々は如何にして品質の高いプロダクトを実装すべきか？についてまとめられた文章です。
- 課題
- 解決方針
- 以下のようにプロダクト自体の実装を工夫することで、品質を高めることができます。加えて、ムダなテストスクリプトも減らすことができます。
The Four Keys to Achieving Parallelization in Automated Testing
自動化テスト、特にSelenium WebDriverのUI E2Eテストスクリプトを並列実行できるようにするためのポイントについてまとめられた文章です。
- 課題
- テストスクリプトが増えすぎると、テストの実行時間が延びてフィードバックを迅速に得られなくなる「Slow Test問題」が発生しがちです。
- この問題を放置し続けると、自動化テストが敬遠されるようになり、最悪の場合自動化テストそのものが実施されなくなり破棄されることがあり得ます。
- 解決方針
- テストスクリプトを並列実行できるようにすることで、実行時間を短縮します。
- Atomic
- ユースケースシナリオに準拠した全ての画面遷移および全画面項目を検証するE2Eテストスクリプトではなく、そのうちの単一の画面遷移と項目だけを検証するテストスクリプトを作り実施することです。
- E2Eテストの例
- 1ケースで、以下の全てを検証する
- ログインページへ遷移する
- ユーザ名の入力欄が表示されていること
- パスワードの入力欄が表示されていること
- ログアウトのリンクが表示されていること
- 商品をショッピングカートへ追加できること
- 1ケースで、以下の全てを検証する
- Atomicなテストの例
- ログインページへ遷移し、ユーザ名の入力欄が表示されていること
- ログインページへ遷移し、パスワードの入力欄が表示されていること
- 同じ検証内容で、Atomicなテスト180ケースとE2Eテスト18ケースとを用意して実行時間を比較したところ、前者が後者よりも8倍速かったとのことです。
- Autonomous
- テストスクリプト間に実行順序の依存関係を作らないようにし、単独で実行できるようにするということです。
- 実行順序に依存関係がある例（上から順番に実施が必要）
- 商品の注文を確定させる
- 上記の注文を取り消す
- Autonomousな例（順番に関係なく実施可能）
- 商品の注文を確定させる
- （上記とは関係なく）商品の注文を取り消す
- 実行順序に依存関係がある例（上から順番に実施が必要）
- テストスクリプト間に実行順序の依存関係を作らないようにし、単独で実行できるようにするということです。
- テストデータの冪等性
- テストデータは、テストスクリプト実行前に読み込み、実行後に破棄するようにする、ということです。
- 上述のautonomousなテストの前提にもなります。
- Selenium WebDriverのテストスクリプトでは、Javaのstaticキーワードを使用した変数・メソッドの使用を避ける
- Atomic
- テストスクリプトを並列実行できるようにすることで、実行時間を短縮します。
Executive Insights on the State of Automated Testing
ガイドブックの締め括りとしての、自動化テストの今後の課題です。
- 自動化テストのスピードと品質を高める必要がある
- 自動化テストの標準・ベストプラクティスが不足しているため、これを充実させる必要がある
- 自動化テストを、CI/CDパイプラインおよびDevOpsと統合することで、その効果をさらに高める必要がある
- 自動化テストの焦点が、UIテストからAPIテストへシフトしつつある
- 自動化テストを担う人材が不足している
個人的メモ
- 自動化テストに関するメトリクス
- 総テスト量
- 単位時間あたりの実施テスト数
- テストの実行時間
- テスト全体
- 1テストあたり
- 手動テストの実施時間と自動化テストの実施時間との比率
- ガイドブック内の「バズワード」
*1:テストに関する用語の翻訳は、『ソフトウェアテスト標準用語集（日本語版）』（Version 2.3.J02、JSTQB技術委員会訳）を参考にしています。
怒りを感じた時にできる「ちょっとした」工夫
「最近怒りっぽくなったな〜（アカン）」という自省に基づくポエムです。
事例
皆さん、このような経験はありますか？*1
- 上司から、隣のチームへ書類を提出するよう頼まれた
- 実際に書類を提出してみると、隣のチームから「この書類はなんですか？」と言われた
このような場合、私は即座に「なんですかとは何だ」「何で事情を把握していないんだよ」「バカにしているのか」と考え、怒りを感じがちです。*2
ポイント
上記の事例は、自分の前提と違うことが起きたことが、怒りのきっかけです。
- 上司は、隣のチームへ、私から書類が提出されること教えているはずだ／べきだ
- 隣のチームは、書類が提出されることを知っているはずだ／べきだ
- 隣のチームは、書類が提出されたら受け取るはずだ／べきだ
「〜いるはずだ／べきだ」という言葉が多いですね。
しかし、ちょっと冷静に考え直してみると、上司から隣のチームに話がそもそも届いていない可能性もあり得るんですよね。その場合、隣のチームにとってみては、「書類を出されたけれども何これ？」と反応するのが自然なんですよね。
この種の怒りと付き合う工夫
自分の前提と違うことが起きたら、自分の頭の中にある「〜いるはずだ／べきだ」を探し、それを疑ってみましょう。
- 自分の前提は、勝手な思い込みであることが往々にしてある*3
- 相手も、そもそも困っている可能性がある
- お互いに、共通の問題に直面している可能性がある
その上で、一つ一つお互いの前提を確認し合い、ズレを見つけた上で、一緒に解決策を見つけるようにすると、自分にとっても相手にとってもwin-winになれます。
また、「重要な前提をお互いに共有されていないのでは？」という仮説を立てられると、相手への敵意が減り、問題解決へ意識を向けやすいです。
さいごに
正直、常にこのように振る舞い続けることは、今の私にはまだ難しいところが多いです。
一方で、国籍・バックボーンが異なる人たちとのやりとりの増加、会社・組織のスケールアップ、物事の複雑度の向上など、連絡の行き違いや前提のズレは、昨今どうしても増えがちです。
なので、自分の前提と違う場面に遭遇したら、自分の前提を一旦「脇に置いて」*4、お互いの前提のズレを見つけることに注力すると、怒りよりも知的好奇心を高められ、結果課題を解決しやすくなります。
参考資料
ＮＶＣ 人と人との関係にいのちを吹き込む法 新版 (日本経済新聞出版)
- 作者:マーシャル・Ｂ・ローゼンバーグ,安納献
- 発売日: 2018/04/20
- メディア: Kindle版
- 作者:加藤 一二三
- 発売日: 2019/10/03
- メディア: 単行本
