The HIRO Says

If you smell what The HIRO is cooking!!!

チームの成長に見る、アジャイルコーチとしてのアンドンの引き方

アジャイルコーチとしてチームの成長を支援していると、アウトプットの急増や意思決定スピードの向上など、チーム・メンバーの急激な成長を目の当たりにする機会があります。その瞬間は、コーチにとっての至福の時間でもあります。

一方で、コーチの予想や期待に反して、チーム・メンバーの成長が停滞しているように見える時もあります。そのような場合、コーチは強いストレスを感じてしまうことがあります。

今回は、チーム・メンバーの成長が停滞しているように見える時のコーチとしての心構えと、ストレスを感じた際の対応策について書いてみます。

1. 停滞しているように見える例と、その裏側で起きていること

  • チーム全体に質問を投げかけても、発言・リアクションがない/非常に少ない
    • チーム・メンバーの当事者意識が足りないとも取れますが、それ以外に「そもそも誰に向けた質問なのかが不明確なので反応できない」「お互いをまだ良く知らないので反応をためらってしまっている」「反応の仕方を熟慮して遅れているだけ」といったことも考えられます。
  • 何かアクションを起こそうとする際、都度コーチに許可を求めてくる
    • 指示待ちの文化から脱却できていないとも取れますが、それ以外に「判断の根拠が明確でないので困っている」「アクションを起こすことに不安を感じている」「勇気を出すのに慣れていないだけ」といったことも考えられます。
  • アドバイスをしても、すぐにそれを取り入れて結果を出そうとしない
    • チームやメンバーごとに、理解や習得のステップは異なります。アドバイスした自身と同じステップ・スピードで動くことを期待すること自体が間違いです。
    • むしろ、「言うことを聞かない」と感じてしまう場合、それはコーチとしてのアラート・危険サインです。


2. コーチとしての心構え

そもそもコーチは、チームのオーナーシップを持ちません。チーム・メンバーが中心であって、彼女ら/彼らを無理やりコーチの考える理想に従わせるのは、コーチングではなくただの強制です。

アジャイルコーチングに関する書籍『Coaching Agile Teams』でも、コーチのチームへのあるべき接し方を「Light-touch」と表現し、コーチはチームのオーナーシップを持たず、あくまでチームに委ねる形で振る舞うよう明記しています。

具対的な振る舞いとしては、コーチの気付きとして問題の存在やヒントを示すレベルに留め、指示や解法は出さないのが望ましいです。

3. コーチとしてアンドンを引く時

とは言うものの、コーチも人間なので、ストレスは感じます。ストレスに早期に気付き対処できる仕組みがあった方が良いでしょう。*1

具体的には、以下のことを感じ始めたら、コーチとしてのアンドンを引いて、仕事を一旦止めて、自身を振り返ってみることをオススメします。

  • チーム・メンバーの成長の停滞
  • コーチとして成果を出すプレッシャー
  • チーム・メンバーの振る舞いが「理想的」ではない

というのも、上記を感じること自体、コーチとしての自身のメンタル面での変調のサインです。メンタルの不調は、コーチのプロセスのバグのようなものです。なので、スクラムフレームワークなどでのチームのプロセス改善と同様、自身のプロセスも定期的に見直しましょう。今の作業を止めてでも。

4. まとめ

コーチは、チームのオーナーではありません。また、チーム・メンバーの成長の程度とスピードは、各々異なります。そこにコーチとして貢献できるポイントはあっても、何かを強制するポイントはありません。

それでも、コーチもストレスは感じます。チーム・メンバーの成長などに焦りや苛立ちを感じ始めたら、コーチとしてアンドンを引くサインです。一度仕事を止め、自身を振り返りましょう。

コーチとしてのinspect & adaptの対象は、基本はチームですが、自分自身を対象にしても良いでしょう。少なくとも、してはダメだと明記している論文・書籍を、私は見たことがないです*2。コーチとしてのスキルを自身の改善にも適用して、よりチームに貢献できるよう「油を指す」ことも、時には必要です。

先ほど油を指した人より。

参考書籍

アジャイルコーチ、および広くコーチングに関してまとまった書籍です。コーチがチームのオーナーシップを持たないことや、チームの成長度合いによってteaching・facilitating・advisingを使い分けようといった、実践的な内容が多く含まれています。また、Scrum AllianceCertified Team Coach (CTC)の取得に際しての参考書籍としても紹介されています。ちなみに、英文はちょっと難しめです。

人それぞれ前提とする認識・信条が異なることと、そのズレが怒り・ストレス・トラブルになることが明記されています。「他者は自分と同じであるべき」という、我々人間がつい思いこみがちな「認識のズレ」を正すのに良い書籍です。

上述のアンガーマネジメントと一緒に読むことで、他者との対立を生じさせにくいコミュニケーション方法を習得することができます。また、人間観察にも良いヒントが多く含まれています。

*1:"Good intention doesn't work, only mechanism works!" by Jeff Bezos

*2:もしあれば、純粋に私の勉強不足ですので教えてください。

ポーランドのDevOpsDaysに登壇させていただきました

4/27(水)に、ポーランドのクラコフで開催されたDevOpsDays Kraków 2022に、スピーカーとして登壇させていただきました。



経緯

ポーランドの同イベントの関係者から、3/25(金)夜にLinkedIn経由でコンタクトをいただきました。世界中で開催されているDevOpsDaysの過去の登壇者リストから、私を選んで声をかけてくれたとのことでした。確かに過去に、東京および台湾で開催されたDevOpsDaysで登壇させていただいたことがあります。



発表内容および要点

同イベントのセッション情報は、こちらになります。(英語)

当日の発表資料は、こちらになります。(英語)

同イベントの開催要旨に、

meet experts and get unique knowledge that you won’t find in any academic books
(意訳)専門家にあって、学術書には載っていない独自の知見を得よう

とあったことから、自身の過去のアジャイルコーチ・DevOps実践者としての事例を中心にお話しすることとしました。また、過去の同イベントの発表内容の多くが「ツール」に関するものであったことから、DevOpsの組織・文化の変革やプラクティスの側面にフォーカスすることで、独自性を出すこととしました。加えて、近年研究しているチームトポロジ、NVC(Nonviolent Communication)Four Key Metricsなどを活用して、自身の事例から「再現性」のある知見を抽出することも狙いました。

また、要点は以下の通りです。

  • 最初の事例は、まだモバイルアプリ開発でDevOpsが一般的ではなかった2013年に、手動ビルド・デプロイによる長時間作業・失敗の多発による開発者・ステークホルダーのフラストレーションを、CI/CDの仕組みを自作することで解決したという事例でした。
  • 2つめの事例は、DevとOpsとの間のサイロによってCIサーバーの増強がスムーズに進められなかった問題を、IaC(Infrastructure as Code)で打破して、Dev・Ops双方の生産性を高めたという事例でした。
  • 3つめの事例は、複数マイクロサービス連携時の本番障害多発による各チーム間のギクシャクしたコミュニケーションを、APIテストとObservabilityで埋めた事例でした。
  • いずれの事例も、「人の問題」に着目し、それを自動化などの技術によって解決したことが共通点でした。
  • その共通点からの「再現性ある知見」として、以下を挙げました。
    • 「人の問題」を見つけるために、NVCが有効であること
    • 自動化などの技術の効果測定には、Four Key Metricsが有効であること
  • 組織・文化の変革やプラクティスを考える上では、「自身および関係者を幸せにする観点でDevOpsを活用しよう」ということが要旨でした



今回の発表を後押ししてくれたもの

今回の登壇は、知人のプロレスラーと、会社の上司の後押しのおかげでもあります。

まず、知人のプロレスラーからは、「ただいい試合をするだけではダメ」「試合をしていない時こそ、対戦の経緯の説明や自分からのテーマ発信など、ファンに関心を持ってもらえるような仕掛け・振る舞いが必要」「だからこそ勇気を持って一歩踏み出すことが必要」ということを教えてもらいました。ポーランドからオファーをいただいた際、「面倒だな」と安易な方向に流れそうになった私の気持ちを奮い立たせてくれたのは、この知人のプロレスラーのおかげでした。

また、会社の上司に今回の登壇オファーの件を相談したところ、「自分がやりたいと思っているのであれば、ぜひトライしよう」と言ってもらい、また会社の手続き面についても説明いただき、結果スムーズに登壇することができました。



まとめ

  • DevOpsDaysは、世界中で情報のやり取りがされています。海外および英語での登壇を希望されている方は、まずDevOpsDays Tokyoで登壇することから始めてみてはいかがでしょう?
  • 社外への発信は、自身のプレゼンスおよびスキル向上の面で有益です。面倒くさがらずに、勇気を持って一歩を踏み出しましょう。
  • 自分を後押ししてくれる周囲の人は重要です。そうした人たちとの関係を築き、また多く耳を傾けましょう。



参考書籍

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. アジャイル初心者のチーム
  2. 各ロールのエゴが強くて対立の多いチーム
  3. 他人事感の強いチーム

社内アジャイルコーチとしての経験から言うと、これらへの唯一の正解はなく、自分たちが試行錯誤を繰り返した中で、うまくいったと感じられたものが「正解」と考えます。

そこでこの章では、私が実際に試して「正解」だと感じたものをご紹介します。

(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を取得しました。

後で同僚に聞いてみたところ、初心者&年齢を考えるとかなり早いペースだと言われたので、(後日自分が詰まった際に思い出せるように)勉強方法をまとめてみました。

前提:どのくらい初心者だったか

それまでずっと社内クラウドのある会社にいて、パブリッククラウドはせいぜいGCPKubernetes The Hard Wayをやってみた程度。IAMとAMIの区別も曖昧だったレベルでした。

一方で、Kubernetesを1年半ほど管理・運用していたこと、またKubernetes Podcast from Googleのヘビーユーザーだったこともあり、全く何も知らないという状況ではなかったです。

(1) AWS Certified Cloud Practitioner (CLF)

f:id:hageyahhoo:20220103160029p:plain:medium

  • 取得: 2021年7月29日
  • 勉強時間: 5日

こちらは、AWSの提供しているトレーニングコースだけで十分でした。

AWS Certified Developer - Associate (DVA)

f:id:hageyahhoo:20220103160002p:plain:medium

  • 取得: 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)

f:id:hageyahhoo:20220103160047p:plain:medium

  • 取得: 2021年11月2日
  • 勉強時間: 3週間

DVAの問題集を解いていたところ、「これ明らかにSolution Architectの出題範囲だよな〜」という箇所をいくつか見つけていたので、DVA受験1週間前からSAAの勉強も並行して実施していました。このおかげで、DVAとつなげて理解できたことがプラスでした。

問題集を解きつつ、分からないことを見つけたらすぐに公式サイトをチェックして動作確認の繰り返しでした。

AWS Certified SysOps Administrator - Associate (SOA)

f:id:hageyahhoo:20220103160059p:plain:medium

  • 取得: 2021年11月12日
  • 勉強時間: 2週間

これもSAAと同じ方法で行けました。DVA - SAA - SOAは、一つの科目として考えて勉強すると、補い合える点が多かったです。

AWS Certified Solutions Architect - Professional (SAP)

f:id:hageyahhoo:20220103160139p:plain:medium

  • 取得: 2021年11月29日
  • 勉強時間: 2週間ちょっと

DVA - SAA - SOAで学んだ知識をベースに、仕事を終えてから毎日夜11時くらいまで、また土日のどちらかを丸一日この試験の勉強に充てて、ひたすら問題を解き、分からないことを見つけては調べることの繰り返しでした。

ただこの方法は、知識だけではなく非常に長い問題文と選択肢を読み抜く気力と体力、そして「てにをは」や明らかにおかしい翻訳に負けない精神力が試されるこの試験を乗り越える手段としては有効だったと思います。

この試験については、多くの問題に触れておくことと、本番試験で日本語だけではなく英語でも問題と選択肢を確認することがポイントでした。

まとめ

改めて振り返ってみると、以下の3点をひたすら地味にやり続けたと言えます。

  1. 問題集を何度も解き、分からない箇所を減らす
  2. AWSに直に触れて、分かる箇所を増やす
  3. 公式ドキュメントやホワイトペーパーを読み、分かることを増やす

特に個人的には、CloudFormationのテンプレートに書き起こすことが、各種リソースやAPIを知り、次に調べるべきことを見つけられた点で有意義でした。

この調子で、次はAWS Certified DevOps Engineer - Professionalを狙います。

オンラインイベントをより「productive」にする1私案

f:id:hageyahhoo:20210919155528p:plain

昨日9/18(土)、XP祭り2021に参加させていただきました。また、久々に登壇もさせていただきました。

同イベントは、20周年記念であることに加え、キーノートの同時聴講者数が400名前後に達するなど、非常に盛況でした。

一方で今朝、気になる投稿を見つけました。


実は私も、聴講者からのフィードバックを少しでも取り入れて場を盛り上げようと、スマホでDiscordを表示しながら登壇していたのですが、

「それって間違ってない?」

的な言葉がまず目に入ってウッ!となってしまい、その「不快感」的なものを消化しきれないまま朝を迎えました。*1

その一方で、上記投稿を見た際、「これは整理する価値のあるモヤモヤなのでは?」との思いも、同時に抱きました。

そこで、自身の気持ちを整理する観点からも、思いついたことを徒然にまとめてみました。

個人的体験の整理

  • 問題点(だと思うこと)を指摘することを、「常に絶対的に正しいこと」と信じている人はいます。
    • 加えて、どれだけキツい表現を使っても「許される」と「拡大解釈」している人もいます。
    • さらに、「不快感を感じないスキルを持つのが(指摘される人の)マナーだ」とおっしゃる方もおります。
  • キツい表現を、「キツいもの」と認識せずに使っている人はいます。
    • これは、年齢ではなく、気付いているか/キツいという経験をしたことがあるかどうかの問題だと、個人的には思っています。
  • 登壇者よりも「優位に立ちたい」観点から、誹謗中傷に及ぶ人もいるかも知れません。
    • SNSクソリプ問題やマウンティングに相当するものです。

聴講者が上記のように振る舞うことで、登壇者が「嫌な思い」を強く感じてしまい、結果登壇を止めるに至った場合、それは我々にとって「プラス」なのでしょうか?これは、一度考えてみる価値のある問いだと思っています。

「言葉の不快感」にまつわる理論

  • マインドフルネス
    • 私たちは会話の際、相手の表情や声色などの情動的な情報も加味して、内容を解釈します。
    • 一方でメールやチャットなどのテキスト情報は、情動に関する情報がすっぽり抜け落ちます。
    • 私たちは、相手の情動に関する情報が得られない場合、相手の情動を「捏造」します。加えて、「捏造」した情報は、ネガティブなものになりがちです。
    • ゆえに私たちは、テキスト情報だけに接すると、「不快な」メッセージとして捉えがちです。
  • アンガーマネジメント
    • 私たちは、出来事や言葉を、「コア・ビリーフ」(Core belief、私たちが普段信じているもの/価値の判断基準にしているもの)に基づいて解釈します。
    • コア・ビリーフは、人によって異なります。(前提が異なるとも言えます)
    • 私たちは会話をする際、通常お互いのコア・ビリーフを明らかにしません。
    • ゆえに私たちは、コア・ビリーフが全く異なる人からの言葉を、「言葉足らず/的外れな指摘」と感じて、怒りの感情につなげがちです。
  • NVC
    • 私たちは、「正しい」・「正しくない」のような言葉を使われると、身構えたり拒絶する態度を取りがちです。
    • これは、「正しい」・「正しくない」といった言葉に、自身の価値基準と異なる「評価」を他者が「押し付ける」側面があるためです。
  • Motivation 3.0
    • 私たち人間は、己の能力を伸ばして「熟達」に向かいたいという動機付けを持っています。
    • 動機付けの観点から、能力を伸ばすことに役立つフィードバックは、非常に効果的です。


Win-winになるための私案

登壇者・聴講者が、以下の形で協力しあって、一緒にセッションを作れるようにすれば良いのでは?と思っています。

  • 登壇者は、「熟達」に達するために、セッションを通じて己の能力を伸ばす。
  • 聴講者は、登壇者が能力を伸ばすことに役立つフィードバックをすることに注力する。
  • 登壇者はそれらを「報酬」と捉え、さらに能力を伸ばすことができる。


また、上記を実現するために、以下の工夫も必要と考えます。

  • 登壇者・聴講者双方は、可能な限り「コア・ビリーフ」を明らかにする。
  • 聴講者は、「正しい」「正しくない」のような、自身の価値基準を押し付ける言葉遣いを避ける。
  • 聴講者は、登壇者のトピックの補足や、話すスキルを高められる投稿をする。
  • 聴講者は、テキストだけではなく、ボイスチャットなど情動を伝えやすい手段も活用する。
  • 登壇者は、聴講者からのフィードバックに感謝の意を伝える。


わかりやすく一行で表記すると、

「登壇者 vs 聴講者」「登壇者 + 聴講者 = イベントを最高にする」

と言えるでしょうか。


書いていて気づきましたが、これってキーノートスピーカーの平鍋健児さんがよくお話される、

「あなた vs 私」ではなく「問題 vs 私たち」の構図を引き出す

と、本質的には同じなのかも知れませんね。

参考書籍

*1:投稿の続きには、きちんと「(自分の)前提が間違っていたようです」との補足がなされていました。

山と谷の連続だった溶連菌感染症からの復帰

GW直前に溶連菌感染症を患い、1月ほど休職しておりましたが、本日6/1(火)に復職しました。

同様の症状に困っている方のプラスになればと思い、治療の経過をまとめてみました。 f:id:hageyahhoo:20210531174820p:plain

体調不良の兆し

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%
      • テストに関する責務を、開発者が持つ傾向が拡大しつつあるとも言えます。
  • どのテストを自動/手動で行うか?
    • 自動
      • 統合テスト(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専任組織がない場合:自動化テストの作成自体が大きな障壁になっています
      1. Test execution and Orchestration
      2. Test report and analysis
      3. Maintaining a stable and up-to-date test lab
      4. Test automation creation
    • DevOps専任組織がある場合:いかに自動化テストを(会社・組織全体に)広め、実施結果レポートを分析するかに視点が移っています
      1. Maintaining a stable and up-to-date test lab
      2. Test automation creation
      3. Test execution and Orchestration
      4. Test report and analysis


How to Test What Matters

テストカバレッジ(Test Coverage)に潜む品質面の課題を指摘し、その上で我々は如何にして品質の高いプロダクトを実装すべきか?についてまとめられた文章です。

  • 課題
    • テストカバレッジは、自動化テストの数的・量的情報ではあります。
    • 一方でテストカバレッジは、プロダクトの品質を必ずしも保証する情報ではありません
    • テストカバレッジの数値を上げるためだけに、不必要なテストスクリプトを増産しているチームが世界的にみられます。これは、プロダクト開発の視点からは「作業のムダ」だと言えます。
  • 解決方針
    • 以下のようにプロダクト自体の実装を工夫することで、品質を高めることができます。加えて、ムダなテストスクリプトも減らすことができます。
      • 実際の(実システムの)データを使用してテストを行う
        • テスト用に作成した人工的データでは、イレギュラーなシナリオやバグを検知できない恐れがあります。
      • OSSのライブラリやフレームワークの機能はテストしない
        • これらは、既に十分にテストされリリースされているものと想定できます。したがって、これらのテストスクリプトをわざわざ作ることは、作業のムダになります。
        • 加えて、これらのテストスクリプトを作って残してしまうと、後にチームに加入したメンバーが事情を知らずに真似してしまい、結果同様のテストスクリプトがムダに増産される恐れが高まります。
      • ビジネスロジックを「Pure Functions」(=ステートレスな実装)にする
        • ステートレスにすることで、実装とテストを容易にできます。
        • このことは、TDDで実装しやすくできることも意味します(後述)。
      • TDDで「Pure Functions」で実装する範囲を拡大することで、プロダクト全体をテストしやすい実装とする


The Four Keys to Achieving Parallelization in Automated Testing

自動化テスト、特にSelenium WebDriverのUI E2Eテストスクリプトを並列実行できるようにするためのポイントについてまとめられた文章です。

  • 課題
    • テストスクリプトが増えすぎると、テストの実行時間が延びてフィードバックを迅速に得られなくなる「Slow Test問題」が発生しがちです。
    • この問題を放置し続けると、自動化テストが敬遠されるようになり、最悪の場合自動化テストそのものが実施されなくなり破棄されることがあり得ます。
  • 解決方針
    • テストスクリプトを並列実行できるようにすることで、実行時間を短縮します。
      • Atomic
        • ユースケースシナリオに準拠した全ての画面遷移および全画面項目を検証するE2Eテストスクリプトではなく、そのうちの単一の画面遷移と項目だけを検証するテストスクリプトを作り実施することです。
        • E2Eテストの例
          • 1ケースで、以下の全てを検証する
            1. ログインページへ遷移する
            2. ユーザ名の入力欄が表示されていること
            3. パスワードの入力欄が表示されていること
            4. ログアウトのリンクが表示されていること
            5. 商品をショッピングカートへ追加できること
        • Atomicなテストの例
          • ログインページへ遷移し、ユーザ名の入力欄が表示されていること
          • ログインページへ遷移し、パスワードの入力欄が表示されていること
        • 同じ検証内容で、Atomicなテスト180ケースとE2Eテスト18ケースとを用意して実行時間を比較したところ、前者が後者よりも8倍速かったとのことです。
      • Autonomous
        • テストスクリプト間に実行順序の依存関係を作らないようにし、単独で実行できるようにするということです。
          • 実行順序に依存関係がある例(上から順番に実施が必要)
            1. 商品の注文を確定させる
            2. 上記の注文を取り消す
          • Autonomousな例(順番に関係なく実施可能)
            • 商品の注文を確定させる
            • (上記とは関係なく)商品の注文を取り消す
      • テストデータの冪等性
        • テストデータは、テストスクリプト実行前に読み込み、実行後に破棄するようにする、ということです。
        • 上述のautonomousなテストの前提にもなります。
      • Selenium WebDriverのテストスクリプトでは、Javaのstaticキーワードを使用した変数・メソッドの使用を避ける
        • これらは、Javaの仕様上全テストスクリプトで共有されるため、並列実行の妨げとなります。


Executive Insights on the State of Automated Testing

ガイドブックの締め括りとしての、自動化テストの今後の課題です。

  • 自動化テストのスピードと品質を高める必要がある
  • 自動化テストの標準・ベストプラクティスが不足しているため、これを充実させる必要がある
      • コンポーネントは小さく実装し、テストのしやすさを向上させる
      • テストスクリプトは小さく実装し、実行時間を短くする
      • 何をテストすべきか/しないかの判断基準を用意・提供する
  • 自動化テストを、CI/CDパイプラインおよびDevOpsと統合することで、その効果をさらに高める必要がある
  • 自動化テストの焦点が、UIテストからAPIテストへシフトしつつある
  • 自動化テストを担う人材が不足している


個人的メモ

  • 自動化テストに関するメトリクス
    • 総テスト量
    • 単位時間あたりの実施テスト数
    • テストの実行時間
      • テスト全体
      • 1テストあたり
    • 手動テストの実施時間と自動化テストの実施時間との比率
  • ガイドブック内の「バズワード
    • クラウド
      • テスト数の増加時、およびSlow Test問題発生時に、インフラのスケールアウトで解決を図る
      • Device Farmなどで、テスト対象端末の準備・管理を容易化する
    • AI/ML


*1:テストに関する用語の翻訳は、『ソフトウェアテスト標準用語集(日本語版)』(Version 2.3.J02、JSTQB技術委員会訳)を参考にしています。