The HIRO Says

If you smell what The HIRO is cooking!!!

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

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技術委員会訳)を参考にしています。

Agile202Xの公募資料を公開しました

グローバルカンファレンスへ公募を出すことを検討されている日本のアジャイル実践者の皆さまの参考になればと思い、過去に出した公募資料のGitHubリポジトリを公開しました。 フィードバックなどもいただけますと、大変ありがたいです。

Agile2020(公募が通った方です)

Agile2021(公募が通らなかった方です 😅)

怒りを感じた時にできる「ちょっとした」工夫

「最近怒りっぽくなったな〜(アカン)」という自省に基づくポエムです。

事例

皆さん、このような経験はありますか?*1

  1. 上司から、隣のチームへ書類を提出するよう頼まれた
  2. 実際に書類を提出してみると、隣のチームから「この書類はなんですか?」と言われた

このような場合、私は即座に「なんですかとは何だ」「何で事情を把握していないんだよ」「バカにしているのか」と考え、怒りを感じがちです。*2

ポイント

上記の事例は、自分の前提と違うことが起きたことが、怒りのきっかけです。

  • 上司は、隣のチームへ、私から書類が提出されること教えているはずだ/べきだ
  • 隣のチームは、書類が提出されることを知っているはずだ/べきだ
  • 隣のチームは、書類が提出されたら受け取るはずだ/べきだ

「〜いるはずだ/べきだ」という言葉が多いですね。

しかし、ちょっと冷静に考え直してみると、上司から隣のチームに話がそもそも届いていない可能性もあり得るんですよね。その場合、隣のチームにとってみては、「書類を出されたけれども何これ?」と反応するのが自然なんですよね。

この種の怒りと付き合う工夫

自分の前提と違うことが起きたら、自分の頭の中にある「〜いるはずだ/べきだ」を探し、それを疑ってみましょう。

  • 自分の前提は、勝手な思い込みであることが往々にしてある*3
  • 相手も、そもそも困っている可能性がある
  • お互いに、共通の問題に直面している可能性がある

その上で、一つ一つお互いの前提を確認し合い、ズレを見つけた上で、一緒に解決策を見つけるようにすると、自分にとっても相手にとってもwin-winになれます。

また、「重要な前提をお互いに共有されていないのでは?」という仮説を立てられると、相手への敵意が減り、問題解決へ意識を向けやすいです。

さいごに

正直、常にこのように振る舞い続けることは、今の私にはまだ難しいところが多いです。

一方で、国籍・バックボーンが異なる人たちとのやりとりの増加、会社・組織のスケールアップ、物事の複雑度の向上など、連絡の行き違いや前提のズレは、昨今どうしても増えがちです。

なので、自分の前提と違う場面に遭遇したら、自分の前提を一旦「脇に置いて」*4、お互いの前提のズレを見つけることに注力すると、怒りよりも知的好奇心を高められ、結果課題を解決しやすくなります。

参考資料

*1:あくまで説明のためのフィクションです

*2:実際に怒りを表したり、相手を怒鳴ったりすることは(ないです)

*3:とは言うものの、今回の事例では、話は事前に通しておいて欲しいというのは正直なところです。

*4:「捨てる」必要はないです

カンファレンスのプロポーザルの書き方!2021

今朝起きてスマホをみたら、しいばさんからこんな通知が届いていました。


教えていただいた「Shinagawa Agile Talks」で、47:30くらいから、確かに私のセッションプロポーザルの書き方を、参考例の一つとして紹介していただいていました。

「お手本になるプロポーザル」として紹介していただいた例は、こちらになります。 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2021/proposal/14621/tips-of-product-management-for-internal-tools

ちょうど良い機会+需要も多少ありそうですので、私が意識・工夫しているカンファレンスのプロポーザルの書き方のtipsを、以下に簡単にまとめてみました。


1. アウトラインが中心

アウトラインは、プロポーザルを書く際に一番重視している箇所です。 なぜならば、自分を知らない人たちに対して、自分が提供したいトーク・ワークショップのイメージを、最も「いきいきと」伝えられる箇所だからです。

具体的には、以下のような工夫をしています。

  • セッションの全体構成を、ツリーで表現する
    • ミーティングの前に、参加者にアジェンダを共有することと同じです。
    • どのようなトピックを、どのような論理構成で伝えるつもりなのかを明示できるため、プロポーザルの内容をよりクリアにできます。
    • プロポーザルが通った際は、これをベースに資料を作れば良いため、時間を節約でき、より良い内容にブラッシュアップし続ける余裕を生み出せます。
  • 各トピックの、おおよその時間見積もりを明記する
    • 上記のツリー情報を、さらにイメージしやすいものとして伝えやすくなります。
    • カンファレンスの運営側に対しても、タイムスケジュールやスタッフの方の仕事量などを把握しやすくするメリットを提供できます。
    • プロポーザルが通った際は、資料のページ割り当て量の参考にできます。
  • イデアの伝え方も明記する
    • どのタイミングで
      • 例:1章の最初に
    • どのように伝えるつもりか
      • 例:xxxという質問を参加者に出し、アイデアを出してもらう(3分)
    • その結果セッションをどうしたいか
      • 例:参加者が、xxxという課題をより「自分ごと」として理解しやすくなる

アウトラインは、そのプロポーザルがReady状態であることを明確に伝えられる箇所です。まずはここを最優先で書きましょう。


2. 「一目」におさめる

関連する情報を、画面をスクロールせずに一目で把握できるよう、常に文量とレイアウトを工夫しています。

Confengneを例にすると、以下の情報を、ブラウザのデフォルトのフォント設定で「ちょうど」1画面内におさまるように記述します。

  • タイトル + 概要
  • アウトライン
  • Learning Outcome + Target Audience + Prerequisites for Attendees
  • Links

画面スクロールは、文章を読む際のストレスになり、内容把握の妨げになり得ます。そのため、読者に画面スクロールを強いないことは、プロポーザルの可読性の向上につながります。


3. 「3」を保つ

イデアや箇条書きなどは、極力3つにするようにします。

これは、とあるコンサルタントの方から教えていただいた、提案の選択肢の数が与える心理的効果を考慮しています。具体的には、

  • 2つ:少なすぎて、十分考えていないのでは?という不安感を与えてしまう
  • 4つ以上:多すぎて、情報を整理できていないのでは?という不安感を与えてしまう
  • 3つ:必要十分に考えて整理されているという安心感を与えられる

このような方法でも、読者に心理的安心感を提供し、プロポーザルへの関心・共感を高められます。


さいごに

上記内容は、些細なことに思われるかも知れませんが、大きな差を生む小さな工夫です。

実は、私の過去のプロポーザルも、内容自体は皆さんとあまり差がありません。それでも私のプロポーザルが採択されたことが多めだったのは、このような「見せ方の工夫」を他者よりも意識して実践していることにあると認識しています。

これ以外にも工夫していることはまだまだありますが、いずれも他者のプロポーザル・資料・発表内容を観察し続け、自身が実験を繰り返して検証して身につけていったものです。

ヒントは、あちこちに転がっています。皆さんもそれらに目を配らせ、自身のプロポーザルのスタイルを確立してみてはいかがでしょうか。


テキストベースでの自身の仕事・時間の管理術

先日、会社の同僚たちとの雑談で、「お互いに日々の業務で工夫している仕事・時間の管理術を紹介し合ったら面白そう」という話になりました。そこで、私がここ7-8年実施している工夫を、以下に簡潔にまとめてみました。一つでも読者の方のプラスになるアイデアがあれば幸いです。

1. SetUp: 一日の業務を始める時

毎朝、以下のルーティンを実施しています。

1) その日の仕事をリストアップする

認識・把握している範囲で良いのでリストアップします。会議など時間が決まっているものは、実施時間も明記します。

2021/03/06
・部の定例MTG(15:00 - 16:00)
・A機能のPull Requestのレビュー
・B報告書の提出


2) 仕事を実施する順に上から並べ替える

併せて、実施時間が決まっている仕事には、🔴などの一目で分かる印をつけます。

2021/03/06
・A機能のPull Requestのレビュー
・B報告書の提出
・🔴部の定例MTG(15:00 - 16:00)


2. Process: 業務中

1) 実施する仕事に印をつける

自分が分かる印で良いので、これから実施する仕事に印をつけます。以下では⭐️を使っています。

2021/03/06
・⭐️A機能のPull Requestのレビュー
・B報告書の提出
・🔴部の定例MTG(15:00 - 16:00)


2) 完了した仕事に印をつける

仕事が完了したら、自分が分かる印をつけます。以下では🟢を使っています。

2021/03/06
・🟢A機能のPull Requestのレビュー
・B報告書の提出
・🔴部の定例MTG(15:00 - 16:00)


3) 突発的な仕事が来た場合

システムトラブルなど、当初予定していなかった仕事の実施が必要になった場合は、実施順序を考慮した上で仕事のリストに追加します。また、その日に終えられない仕事が出てきた場合は、次の日のタスクに移動します。

2021/03/07
・B報告書の提出

2021/03/06
・🟢A機能のPull Requestのレビュー
・⭐️Cシステムのエラーの原因調査
・🔴部の定例MTG(15:00 - 16:00)


4) 気付き・発見の明記

後日上長や他チームに共有した方が良い情報などが見つかった場合は、その情報をリストに追記します。

2021/03/07
・B報告書の提出

2021/03/06
・🟢A機能のPull Requestのレビュー
・🟢Cシステムのエラーの原因調査
 ・💡既存のアラート機能では把握できないもの -> Dチームに改善を依頼する
・🔴部の定例MTG(15:00 - 16:00)



3. TearDown: 一日の業務を終える時

最終的に、以下のようになるはずです。

2021/03/06
・🟢A機能のPull Requestのレビュー
・🟢B報告書の提出
・🟢部の定例MTG(15:00 - 16:00)

印を全て削除して、一日の業務を終えたサインとします。

2021/03/06
・A機能のPull Requestのレビュー
・B報告書の提出
・部の定例MTG(15:00 - 16:00)



4. 一週間・一ヶ月の業務を終える時

終了した仕事のリスト一週間は、そのまま週報にできます。 同じ理屈で、一ヶ月分のリストは、そのまま月報に活用できます。


一連の工夫の動機

  • この工夫を始めた当時、とても一日ではこなせない量の業務依頼・メール・会議依頼が毎日届くようになった時期で、何らかの取り組みが急務でした。
  • メール・カレンダー・JIRAなど複数の情報ソースが存在していて、かつそれらの行き来が遅くて苦痛だったため、手軽に一箇所で情報を扱える仕組みが個人的に好ましかったです。
  • ちょうど当時、Atlassian社のConfluenceの操作方法を業務上急ぎ覚える必要があり、勉強の一環で少しずつ試してみたところ、徐々に上記の仕組みを確立していきました。


個人的に感じているメリット

  • JIRA・Trello・付箋などのタスクボードと比較しても、実施が手軽です。
  • 仕事に対する心の余裕を生み出せます。
    • 現状把握が容易になります。
    • 頭の中にだけ情報がある時と比較して、忘れるのでは?という不安感を解消できます。
    • 頭の中にだけ情報がある時と比較して、思い出すためのエネルギーを減らせます。
  • スケジュールの調整がしやすくなります。
    • 仕事が大量に来たとしても、調整箇所を特定しやすくなるため、考える余裕を持てます。
  • 会議など、実施時間が決まっている仕事の見落としを減らせます。
  • 作業の実施順序や優先順位を考える訓練にもなります。


工夫の背景にあるアイデア

  • 仕事のリストを書き出して、終わったものに印をつけるアイデアは、Getting Things Done (GTD)と、Kent BeckのTDDの本からヒントを得ています。
    Test Driven Development: By Example (Addison-Wesley Signature Series (Beck))

    Test Driven Development: By Example (Addison-Wesley Signature Series (Beck))

    • 作者:Beck, Kent
    • 発売日: 2002/11/08
    • メディア: ペーパーバック
  • 一日単位での仕事のリストアップと優先順位付けのアイデアは、スクラムのプロダクトバックログおよびスプリントバックログを、個人の作業に応用してみたものです。「個人バックログ」と雑に呼称しても良いかもです。
  • 一日の終了時にリストから印を消すアイデアは、スクラムのバーンダウンチャートをヒントに、毎日達成感を感じられるようにしようというのが狙いです。
  • テキストベースを続けていることは、レポート作成の効率化も意識しています。また、社外カンファレンスなどでの登壇資料作りのメモとしても活用しています。


おわりに

上記の工夫は、あくまで私が自身の知識・経験の範囲内で、実験を繰り返して有効だと考えて続けているものです。 もっと他に良い方法は、まだまだたくさんあると思います。 もしより良いアイデアをお持ちの方がいらっしゃいましたら、教えていただけるとありがたいです。


自分自身の答え合わせとふりかえりの場だったRSGT2021

2021年の1月6日(水)から8日(金)まで、Regional Scrum Gathering Tokyo 2021(RSGT2021)に参加させていただいていました。

イベントそのものに関するレポートは既に多くの方が書かれているので、私はイチ登壇者としての視点からの個人的体験をまとめてみます。

※他の方のレポートは、こちらから見つけられます。



1. 登壇による「現場での経験」の答え合わせ

学術や理論を整理して話すことに(私よりも)長けた方々が既にたくさんいらっしゃるので、私は「現場での経験」、特にソフトウェア開発の実務での実験・失敗・発見の生々しい話、実践知にフォーカスしてお話させていただくように心がけています。

特に今回は、「SET」(テスト自動化やDevOpsなど、特に技術的アプローチからアジャイルを推進するロール)として社内ツール群を提案・開発・運用し続けた経験をもとに、社内ツール視点でのプロダクトマネジメントについてお話させていただきました。

開発者主体だとどのような行動・失敗をしがちなのかという情報とその克服案を、アジャイルコーチ・アジャイルを実践中の方・アジャイル初心者の方いずれにも提示して、私自身および参加者の双方に考える場を提供しようというのが、私のねらいでした。

その点では、「SETという役割・チーム自体が私たちのプロダクトとも言える」という視点を得られたことが、私的には大きなプラスでした。

2. 「共に苦しんで共感を育むこと」の裏付け

私は昨年のRSGT2020の発表で、「共感・思いやり」に「compassion」という英単語を当て、

  • この「compassion」の語源がラテン語の「compatio」であること
  • 「compatio」の意味が「共に苦しむ」であること
  • 同僚や支援先チームと一緒に問題解決に取り組んで「共に苦しむ」ことで「共感」を育くみ、課題解決を加速させる

という話をさせていただきました。

これと近しい考え方が、クロージングキーノートの野中郁次郎さんの発表にも出てきて、自分自身の気付きと発表内容に裏付けを得られたことが非常に嬉しかったです。

ちなみに、「共感」に「empathy」の英単語を当てていたら、上記の考えには気付きにくかったです。怪我の功名でした。

3. フラクタルな組織「だった」(いろいろな意味で)

私自身、アジャイルコーチになって「多くの観察から自分自身を成長させられてきた」経験とその喜びから、これを他の人や組織にも広げたいと思い振る舞い続けてきました。

また、私自身が数年前に体調を崩したことから、私がいなくても自律的に考え成長し続けられるチームづくりを心がけていました。私がリーダを務めるSETチームは、それを志向し続けています。

加えて、そのような個人・チームは、上位の組織(あるいは会社)を「乗り越えて」価値を提供し続けられる強みがあるとも考えていました。

これらを「フラクタル」という考え方である程度整理できること、一方で適切な言語化を私自身ができていなかったことで周囲に伝え切れていなかったな〜という反省を得られたことが、今回のカンファレンスでの1番の個人的収穫かもしれません。

というわけで、早速こちらをいま読んでいます。



4. 私だからできる「貢献」を

  • より「アピールしやすい」プロポーザルの書き方の工夫・アイデアを、数度にわたってDiscordでお話しさせていただきました。今回のカンファレンスで「話をしてみたい!」と思われた方の背中を押せれば嬉しいです。
  • 私なりのプレゼン資料の書き方の工夫・アイデアを、数度にわたってDiscordでお話しさせていただきました。長沢さんとは別の視点から、アジャイルコミュニティに9年ほどいる私自身の「秘伝のタレ」を「伝授」しましたです。
  • 参加者の多くに、特にスマホアプリのテスト自動化に悩まれている方が多かったので、「お互いにコミュニティ活動を通じて知見を共有し合おう」と提案させていただきました。ちょうど同僚が同じ目的で「てすらぼ」というコミュニティを運営していたので、こちらを紹介させていただきました。続きはここで議論しましょ〜



さいごに

ちょうどコロナ禍の拡大で判断が難しい状況で、このような素晴らしい機会を提供してくださったスタッフの皆さま、参加者の皆さま、応援してくれた同僚のみなさんに感謝です。

また、Among Usを一緒にプレイしてくださった方にも感謝です。(またやりましょ〜!)