dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

大量のユーザーストーリーを素早く見積もる「サイレントグルーピング」という手法を知った

職場の同僚にこういう方法もあると教えてもらった。 その人も最近 Twitter で見かけたとおっしゃっていて、おそらく該当のツイートはこれ。

ここで言及されている記事をざっと読んで手法を学んだのでメモ。

記事

https://kenpower.ie/2011/05/22/using-silent-grouping-to-size-user-stories

記事自体は古く、2011年のもの。 XP2011 というカンファレンスで発表されたもののよう。

(2022-06-15 追記)
リンク切れになってしまった...

イントロ

  • ユーザーストーリーを見積もるためのよく知られたテクニックとして「プランニングポーカー」があるが、時間がかかり、不必要な議論に終始する可能性がある
  • これに対し「サイレントグルーピング」という手法はプランニングポーカーを補完するために使用でき、大規模なユーザーストーリーのセットを数分で見積もることができる

サイレントグルーピングのやり方

サイレントグルーピングは以下の4つのパートで構成される。

  1. Preparation
  2. Round 1: Individual Placement
  3. Round 2: Group Placement
  4. Discussion and Reflection

以下、順に見ていく。
前提として、見積もり対象のユーザーストーリーは事前に用意されているものとする。

1. Preparation

  • 下の図のようなボードを用意する。縦線で区切られ、各列には見積もりに使うストーリーポイントが振られている。

画像は記事より引用

  • また、グルーピングできないユーザーストーリーが出てきたときのためにパーキングロットを用意するのも良いアイディア
  • 中規模サイズのユーザーストーリーを1つ決める。これは、最初のいくつかのユーザーストーリーが比較されるベンチマークとなる

2. Round 1: Individual Placement

  • チームメンバーは一人ずつ順番に前に出て、1つのユーザーストーリーをボードに配置する
  • このラウンドの目標は、すべてのユーザーストーリーをボード上に配置することであり、したがって、すべてのユーザーストーリーの初期サイズの見積もりを得ることである
  • このパートを実行する一番簡単な方法は、単にメンバーが列を作って順にユーザーストーリーをボードに配置する方法だと思う

3. Round 2: Group Placement

  • チームメンバーは順番に前に出て、一度に1つのユーザーストーリーを動かす
  • このラウンドの目標は、すべてのユーザーストーリーのサイズについて、チームのコンセンサスを得ることである
  • このラウンドでは、競合が発生することがある。例えば、あるチームメンバーがユーザーストーリーを、例えば5から8に移動させ、別のチームメンバーが5に戻すというように、ユーザーストーリーが何度も移動させられることがある。この観察と意識的考察の行為で意見の相違が解消され、口頭で議論することなくサイズに合意することが非常に多い
  • ユーザーストーリーが2つ(またはそれ以上)のカラムをいったりきたりして、誰も妥協しない場合は、このユーザーストーリーについてもっと議論が必要なサイン。この場合ファシリテーターはこのユーザーストーリーをボードから取り除き、パーキングロットに置く

4. Discussion and Reflection

画像は記事より引用

  • ファシリテーターはチームに、それぞれのサイズに対する自信度を短い時間で議論させる。Fist to Fiveは良いテクニックだろう

サイレントグルーピングの利点("Summary of Benefits"より)

  • むちゃくちゃ早い
  • スケーラブル。著者はこの手法を最大8つのスクラムチーム(55人)と並行して使い、677のユーザーストーリーを28分でサイズアップしたことがある
  • チーム内の不明な点や意見の相違がすぐに浮き彫りになる
  • インクルーシブ。誰もがすべてのユーザーストーリーについてコメントする機会を得ることができる
  • プランニングポーカーを補完するものとしてうまく機能する。最初のベンチマークとなるストーリーはプランニングポーカーで見積もるとか、サイレントグルーピングでコンセンサスが得られなかったものだけプランニングポーカーでサイズを決定するとか
  • 話すことを明確に禁止しているので、内向的なチームメンバーが影響力を発揮しやすくなっている
  • グローバルなチームなどで言語の壁がある場合も有効

感想

👍良いと思った点:
これが有効な場面はあるなと感じた。たとえば過去の経験上も、四半期ごと・半年ごとなどの長めのスパンで粒度の荒い新機能(エピックと呼ぶことが多い)複数をざっと見積もる、というのをやったことがあるので、そういった場面であんまり時間かけずに見積もり出すのには機能しそう。

利点にも書いたとおりプランニングポーカーと比較してどちらかだけを使う、というよりは相互補完的なものなので、選択肢と持っておくのは良い。

あと、議論ベースの見積もりより平等なところも良さそう。性格的に内向的だったり入社して日が浅いメンバーであっても他の人と同じようにボードの前で意思表示しないといけないので、意見の偏りがない。

🤔気になった点:
「そんなうまくいくかぁ〜?」とは正直思った。発言禁止ってことはお互いが持ってる情報を出し合って認識を合わせていくみたいなことが基本できないので、ストーリーが列を行き来しながら徐々に特定の見積もりに収束するということが本当に起きるのか、やや懐疑的ではある。

余談

「エッセンシャルスクラム」でもちょこっとだけ紹介されてた。こちらはスプリントレトロスペクティブの文脈。

書籍「エッセンシャルスクラム」より引用

2022年1〜3月のふりかえり

最初の四半期のふりかえりを完全に忘れていた。書く。

前回: 2021年のふりかえりと2022年にやりたいこと - dackdive's blog

✨ やったこと

CRE(Customer Reliability Engineering)について調べている

現職で CRE という役割もやらせてもらえることになり、今期の特に前半は CRE についての情報を集めたり責務について考えたりすることが多かった。

現職での CRE としての取り組みは弊社のカスタマーサクセスチームが note にめちゃくちゃ詳しくまとめてくれている。

また、CRE 系のイベントにも参加した。

「各社CREチームのサポート体制と独自の取り組みについて【はてな|freee|アンドパッド】」参加メモ - dackdive's blog

ここはまた別途記事にまとめたい。

フロントエンド: テストについて調べていた

フロントエンドに関してはテスト周りを勉強していた。今まで Testing Trophy も曖昧な理解だったし、どこに対してどういう目的のテストを書くと良いかもう少し言語化できるようにしたかったからだ。
そのため Storybook の UI Testing Handbook というドキュメントを読んだり、最近は Storybook の Interactive Stories を調べたりしていた。

今のところまだ Integration Test をどう定義するか、それを E2E テストとどう棲み分けるか、といったあたりが理解不十分なので、来期も引き続き勉強したい。

UoPeople: MATH1280 Introduction to Statistics

今 term は統計学をやった。内容や感想は以前書いた。

📝ブログ・登壇

なんと、今期は2回も社外イベント登壇の機会があった。

そこそこ反応あったし普通に勉強になったので登壇駆動としては大成功。

こちらも自社のフロントエンドについて整理したりこっちからお悩み相談させてもらったりと非常に有意義なイベントとなった。

ブログ書いたものは以下。

💪次の四半期(2022年4〜6月)のテーマ

なにか月に1つぐらい目標決めたいなーと思いつつ4月も半ばなので2つぐらい。
また、次の term は UoPeople の授業受けないことに決めたので今期よりは時間がある。ので技術系の本読むとか Rust 勉強するとかやりたい。

  • 簿記 3 級取る
  • HTML 解体新書 読む
  • Rust 勉強する(なにか具体的な目標がほしいところ)

あたりかな。

💸 買ったもの

良いコーヒーミルが欲しくなって買った。
一時は 1Zpresso だの コマンダンテ だのといった高級品に手を出しかけたが、ネットでコスパ良いと評判だったこいつにした。

以前より力入れずに挽ける感じがするし粉の粒度も揃ってる気がする。気に入って使ってる。

「各社CREチームのサポート体制と独自の取り組みについて【はてな|freee|アンドパッド】」参加メモ

参加しました。

動画

ハッシュタグ#hatena_freee_andpad

以下メモです。

テクニカルサポートをプロダクトの強みにするMackerel CREの取り組み

f:id:dackdive:20220224210845p:plain

f:id:dackdive:20220224210905p:plain

  • サポートのフロー

f:id:dackdive:20220224211345p:plain

  • CRE内にテクニカルサポートとカスタマーサクセスがある
    • 今日はテクニカルサポートの話が中心
  • どう対応しているか
    • すでに情報があるもの:セルフサービス化
      • 独自のセルフサービススコアという指標で、お客様がどれぐらい自己解決できたかをモニタリング
      • FAQの検索語監視君
        • FAQで検索したけど検索結果が0件だったものを、検索回数が多い順に定期的に Slack に流す f:id:dackdive:20220224210950p:plain
    • 定形の回答がないもの
      • CREによる調査:環境の情報提供、ソースコード確認、アプリケーションログ
      • CREでもだめならエスカレーション。開発チームにもサポート担当がいる
      • 応用的な活用方法の提案
    • 課題
      • ヘルプとFAQのプラットフォームが異なるので相互にサジェストできない
      • セルフサービススコアは実際に自己解決した割合ではない
      • プロダクトへのフィードバックループの強化

freeeのCRE誕生から現在までの歩みとセルフサービスへの挑戦について

  • 問い合わせフロー
    • ユーザー起点なのか開発者起点なのかでフロー分けてる。開発者起点の場合は最初からCREが対応

f:id:dackdive:20220224213156p:plain

  • プロダクトとチーム進化の軌跡
    • 最初はテクサポチーム
  • 業務内容 f:id:dackdive:20220224213315p:plain
    1. 問い合わせ対応
      • 全体のフロー改善も担当
      • 対象プロダクトはfreeeのプロダクトラインナップのうちの一部
    2. セルフサービス開発
      • chat bot開発など、ユーザーが自己解決できるしくみを
  • チーム構成
    • プロダクトごとにさらにユニットに分かれている
    • ユニットごとにOKRにを設定
      • ユーザー様回答までのSLOを持ってるユニットや、一次回答までのリードタイムを目標にしたり
  • チームの歩み
    • QAチームの1チームとしてテクサポ誕生
    • 最初はフローを整えることに専念

f:id:dackdive:20220224213723p:plain

  • エンジニアへの問い合わせ数は順調に減っている
  • 03 セルフサービスの開発
    • chat bot
    • お問い合わせフォーム統合
    • ヘルプページ刷新: Zendesk → React + TypeScript、検索を Algolia に
  • これから
    • ユーザー対応領域:解決時間を短く
      • セールスエンジニア的な動きを模索中
    • プロダクト対応領域:問い合わせを減らす

アンドパッドのテクニカルサポートと要件定義への関わり方

  • 問い合わせフロー
    • カスタマーサポート、営業、カスタマーサクセスが問い合わせを受ける
    • CREは問い合わせの一次窓口という感じ

f:id:dackdive:20220224213605p:plain

  • バグ対応フロー
    • CRE自身は修正まではやらない
  • テクニカルサポートにおける意識
    • SaaSであることを意識する
    • お客様の疑問の意味を常に考える
  • 現状の課題
    • 仕様か不具合かの判断が難しい
      • 仕様FAQ作成中
    • ドメイン知識の難しさ
      • オンボーディング資料として各種ドメイン資料を作成中
  • 要件定義への関わり方
    • 開発チーム側へCREとしての懸念を伝える
      • 関連する機能(影響範囲)
        • 機能が複雑化、マイクロサービス化により機能間の連携が増える
        • 問い合わせを一本化しているので様々な問い合わせが CRE に来る→幅広い知識を身につけているCREからの目線を伝える
      • 改善を実施することによって実現される運用上の影響
        • ある改善が一部のお客様にとってデメリットとなる

パネルディスカッション〜各社の取り組みのここが気になる!〜

Q. ドメイン知識はCREとしてどれくらい求められる?
  • 段階があると思う by アンドパッド
    • テクニカルサポートをするに十分なドメイン知識は教えていきたいと思っている。それを学ぶ方法がないというのが現状の課題
  • 専門的な知識が必要だと思うところはある by freee
    • プロダクトの仕様に関することは過去の問い合わせのナレッジなどもあるのでそれを参考にしながら
Q. CREはまだできて浅い職種なので、役割定義が難しいと感じています。どのようにCREを定義していますか?
  • はてな
    • セールスエンジニア→CREという経緯
    • 隔週ぐらいでCREについて考える会をやっていた
  • freee
    • 混乱期って書いてた
    • テクニカルサポートの延長戦上、って思われてしまいがちだけど、エンジニアとして問い合わせ自体をなくしていく活動も大事
  • アンドパッド
    • freee さんと似てるなと思った。2年遅れぐらいで歩んでる
    • エンジニアの負荷を下げて、エンジニアが本来やるべきことに専念できるようにする
Q. 各社CREの採用のときにどのようなCRE像をイメージしていますか?
  • freee
    • ドメイン知識は最初から要求していない
    • どちらかというとエンジニアの素養
    • 最先端の技術使いたい、よりユーザーに寄り添いたい、という気質の人
  • はてな
    • お客様の課題にどれだけ自分ごととして関心を持てるか
    • 面接でも「こういうこと言ってるお客様がいたらどのへん気になりますか?」とか聞く
  • アンドパッド
    • 顧客信頼性とはお客様の本当の課題を解決すること
Q. はてなへの質問
  • お知らせメールをCREで出すに至った理由は? by freee
    • セールスエンジニアからスタートしていろんな業務を吸収してったという歴史的経緯から
    • エンジニアは仕様とか厳密な文章書くのは得意だが、お客様が知りたいことを想像して書くみたいなのはCREの方が得意
    • お知らせ書くことがCREにとってめちゃめちゃ勉強になる、というのもある
Q. freee への質問
  • なにから手を付けるか、どこからやるか、という優先度はどう決めている? by はてな
    • CREだけで決めてるわけではなく、サポートチームと連携してやっている
  • チャットでも優先度の基準ってどういう感じで策定してますかってあった
    • あれは「サポートからエンジニアに依頼するときの優先度」の話だと思う
    • 優先度を策定した。代替手段がないもの、とか判断の軸を作った
Q. アンドパッドへの質問
  • 要件定義にも関わるとのことだが、そのきっかけは?
    • 元々は個人の経験を活かして。テクサポチームがない時代に、自分の役割とか抜きに誰かが困ってることをやっていた

所感

サポート体制や業務内容、現状の課題など各社の具体的な話が聞けて参考になりました。
CRE という職が生まれた歴史的経緯が会社によって様々なので、サポートひとつとってもどのような体制でCREが何をどこまで担うかはけっこう違う印象を受けました。また、どこも「CREとはこうあるべき」という絶対的な解は持ってなく模索中なんだなとも。

CRE は「エンジニア」である以上、日々のサポート業務にとどまらず技術で問題を解決することが求められると思っていますが、一方でフローの整備など泥臭く地道な作業も各社やられていて、そのへんは今まさに自分もやっていることなので安心しました。

TypeScriptの公式チートシートを読んだ

先週の This Week In React に流れてきたやつ。

ざっと読んでみたけどそこまで目新しい発見はありませんでした。以下メモ。 💬 はコメント。

Classes

f:id:dackdive:20220124011610p:plain
https://www.typescriptlang.org/static/TypeScript%20Classes-83cc6f8e42ba2002d5e2c04221fa78f9.png

class Location {
  constructor(public x: number, public y: number) {}
}

const loc = new Location(20, 40);
loc.x // 20
loc.y // 40
  • Abstract Classes
  • Decorators and Attributes
    • デコレータをクラス、メソッド、アクセサ、プロパティやパラメータに使えるよ、とだけ
    • どういう動作になるのかは書かれておらず

Interfaces

f:id:dackdive:20220124011739p:plain
https://www.typescriptlang.org/static/TypeScript%20Interfaces-34f1ad12132fb463bd1dfe5b85c5b2e6.png

  • Common Syntax
    • 💬 new XXX() したときの型の宣言とかしばらく知らなかった
      • new(s: string): JSONResponse;
  • Extension via merging
    • interface は複数宣言することでマージできる

Types

f:id:dackdive:20220124011836p:plain
https://www.typescriptlang.org/static/TypeScript%20Types-4cbf7b9d45dc0ec8d18c6c7a0c516114.png

左上の Type vs Interface にどっち使う?の判断材料について言及されていた。

  • Type vs Interface
    • Interface はオブジェクトの形状を表現するのにしか使えない
    • Interface は複数回宣言することで拡張できる
    • パフォーマンスがクリティカルな型は Interface のほうが速い可能性がある
  • 💬 このへんの型については新しい知見はなかった
    • Primitive Type, Object Literal Type, Tuple Type, Union Type, Intersection Types(& によるマージ)
  • Type Indexing
  • Type from Value: typeof 値 で値を元にした型が作れる
  • Type from Func Return: ReturnType<関数の型> で関数の戻り値の型が作れる
  • Type from Module

以下はライブラリを作成するときや既存のJavaScriptコードを表現するときに素晴らしい機能だが、多くのTypeScriptアプリケーションではほとんど使わないとのこと。

  • Mapped Types
type Artist = { name: string, bio: string };

type Subscriber<Type> = {
  [Property in keyof Type]:
    (newValue: Type[Property]) => void
}
type ArtistSub = Subscriber<Artist>
  • Conditional Types: A extends B ? C : D
  • Template Union Types
    • 型にテンプレートリテラルを使う
    • type AllLocaleIDs = `${SupportedLangs}_${FooterLocaleIDs}_id`

Control Flow Analysis

f:id:dackdive:20220124011918p:plain
https://www.typescriptlang.org/static/TypeScript%20Control%20Flow%20Analysis-8a549253ad8470850b77c4c5c351d457.png

  • If Statements
    • if で型を絞り込む
  • Discriminated Unions
    • Union の各メンバが同じプロパティを持っている場合、 if や switch で型を絞り込める
type Responses =
  | { status: 200, data: any }
  | { status: 301, to: string }
  | { status: 400, error: Error }
  • Type Guards
    • 関数の戻り値の型に is を使うやつ
    • これは as と同じく TypeScript の推論に頼らず自分で宣言しているだけなので取り扱い注意
  • Assertion Functions
    • 関数の戻り値の型を asserts <引数> is SomeType で定義するやつ
  • Assignment
    • as const

所感

  • 「全然知らねえ!」というのはなかったよかった
  • Mapped Types とか Conditional Types とか Assertion Functions とか、説明聞いただけだとよくわからんみたいなのが最低限のサンプルコード載せてくれてるのはありがたい

KPT以外のふりかえり手法について調べた

背景

現職のログラスでは週に3回ぐらいのペースで10分勉強会というものをやっています。

先日そこでふりかえり手法について話したので、自分のブログにも残しておきます。
社内事情的なものを消した以外は、ほぼ勉強会のときに使った資料そのままです。

---------------資料ここから------------------

少し前に見たこの資料が面白かったので、+αで調べたことも含め紹介します

本日のゴール

  • KPT以外にもこんなふりかえりあるんだ〜というのを知ってもらう
  • それぞれのチームでいろんなふりかえり試してみようという機運になる

はじめに

実は奥が深いふりかえり
  • ふりかえりだけで1冊の本になる

f:id:dackdive:20220113015304p:plain:w240f:id:dackdive:20220113015308p:plain:w240

個人的にはKPTもけっこう難しい面があると思っている

KPT以外の方法も選択肢として知っておくといいよね!ということで調べた


ふりかえり手法の紹介

主に冒頭のスライドと、ふりかえりカタログ を参考に。

1. タイムライン

f:id:dackdive:20220113015749p:plain

  • チームでもちょっと取り入れてる
  • 事実ベースで書き出すので良いこと悪いこと思い出すきっかけになるのは👍
  • 毎日書かないと1週間でも思い出せないという学び
2. Fun / Done / Learn

f:id:dackdive:20220113015832p:plain

  • 前職で一時期やってた
  • 進め方に書いてないけど、最初に今週やったことを事実ベースで書き出してから図にマッピングする
    • →タイムラインと同じく、事実ベースで思い出すので感情に左右されにくい
  • KPT よりポジティブな雰囲気になりやすい
    • チーム作りたてのときとかメンバーにシャイな人が多いと効果アリ
  • (良い意味で)今のログラスでは別に必要ないかなーという印象
    • Kも出てるし、Pもそんな暗い雰囲気にならず議論できてるので
3. Good & New

f:id:dackdive:20220113015940p:plain - 前職ではデイリーチェックイン時のざつだんで使ってた - これ単体で使うというよりはふりかえりとかのアイスブレイク的用途かな

4. 象、死んだ魚、嘔吐

f:id:dackdive:20220113020156p:plain

  • ネーミングセンスよ
  • やったことはないが、各項目を読むと意外と理にかなってるのでは?という気も
  • 月1とか、ちょっとまとまった期間におけるふりかえりとかによさそう
5. Six Thinking Hats (6つの帽子思考法)

f:id:dackdive:20220113020017p:plain

  • モブプロの本に出てきた
  • 類似のものとして「斜に構える、構えないを繰り返す」というのがある
    • こっちのがシンプル
  • どちらも、強制的に批判的・ネガティブな意見を出させるのは言いにくいこと言わせるという点でよさそう

おわりに

  • なんでこんな話をしようと思ったかというと、「気軽に実験できる文化を維持したいよね」みたいな気持ちがあった。自戒もこめて
  • 前提として、何かをするときに「なんでやるのか」「どんな効果を期待しているのか」を考えておくの大事
  • 一方で、やってみないとわからないこともある
  • 「それなんでやるんですか」をやりすぎると何も実験できない組織になる
  • ふりかえりのやり方にしてもそうで、実験のハードルとしてはめちゃ低い
    • 失敗してもたかが1週間なのでどんどん実験してみよう。自戒もこめて
  • アトラクタの永瀬さんもこんなことを言っている

先が読めないからこそアジャイルが役に立つ 予定調和にハマらないためのスクラム活用術

実際にControlled Chaos……制御されたカオスという言い方をしたりします。その中で安全に実験や失敗をしてみることが、そもそものアジャイルスクラムの価値かなと私は考えていて。
...
アクションに起こしやすくて、計測可能なトライというか改善を上げることはもちろんいいんですが。そうではなくて、お願いしたいことはたまに実験をしてみてほしい。一見何も相関がなさそうなことをやってみると、実はあとから因果があったと判明するかもしれません。

  • 制御されたカオスを楽しもう!

参考リンク

------------資料ここまで---------------

後日談

この話をした翌日が月次振り返りで、早速「象、死んだ魚、嘔吐」を試してみようという動きになった。それだけでも話してよかった。

2021年のふりかえりと2022年にやりたいこと

完全に年を越してしまったが、毎年書いてるので書く。

去年:

dackdive.hateblo.jp

2021年の四半期ごとのふりかえり:

読んだもの

第一特集の「[自作OS×自作ブラウザで学ぶ]Webページが表示されるまで」が気になって買った。
けっこうシステムコールのところとか難しくて理解があやふやだった記憶。

これは WebAssembly 特集が読みたくて。
読書メモ:Software Design 2021年3月号の「WebAssembly入門」を読んだ - dackdive's blog

今だと 日本語訳 も出ているのでそっち買った方がいい。

読書メモ:「The Art of WebAssembly」を読んだ - dackdive's blog

一瞬だけ Ansible をやる必要性にかられて買った。
前半しか読んでないが、Playbook とか Inventory といった基本的な用語が公式ドキュメント読むよりはるかにわかりやすく説明されててよかった。

面白かった。こういう本もっと読みたい。
得意なこととはなにかっていうエピソードが印象的だった。

仕事をするとき、同じくらいのエネルギーを注いでいるはずなのに、妙によろこんでもらえるときと、あんまりよろこんでもらえないときがあるんですよ。
(中略)
つまり、自分たちがすごく苦労したと思ってないのに、妙に評価してもらえるときというのは、放っておいても、どんどんいい結果が出て、いい循環になって、どんどん力が出ていく状態。それが自分たちに向いている得意なこと、そうじゃないことは向いてないことだ、というふうに、わたしはだいたい判断していますね。

これも面白い本だった。仕事と全然関係ない息抜きに良かった。

評判良さそうだったのと Concurrent Mode あたり気になって読んだ。だいたい全部読み終わったはずだけど読書メモ書けてないな...

書いたもの

時系列で。だいたいこのブログで、たまに Zenn の方にちゃんとまとめた情報を書くようにしてた。

作ったもの

これぐらい。

Pixe.la という草生やす API サービスをブラウザ上で試せる君。

あとは、2020年の終わりぐらいから読んだ記事はここに残すようにした。
https://reading-list.zaki-yama.dev/

所感

ざっくり、1年の前半は Rust や WebAssembly を勉強していて、後半は追いつけてなかったフロントエンド技術のキャッチアップに注力していた。
後悔はないが、最近は Rust は全く勉強できてなくて、周りでやってる声もよく聞くようになったのでもっかい一から入門したいなという気持ち。

今年の後半には University of the People (UoPeople) への入学と株式会社ログラス への転職という比較的大きな決断が2つあった。
UoPeople に関しては無事最初の term を乗り越えてもうすぐ 2 term 目も終わろうかというところ。正直まだ面白いと思える授業内容ではない (その前段の基本的なプログラミングの授業をやっている) が、このペースなら仕事や子育てと並行して続けられそうだという感触が得られたのは良かった。のんびりやっていきたい。
転職に関しても良い選択だったと思っている。以前の職場もそうだが、優秀で人間的にも良い人たちに囲まれているのはとてもありがたいこと。もうすぐ3ヶ月経とうとしているので転職エントリを書きたい。

2022年にやりたいこと

去年も書いた気がするけど、大きく変えたい・新たに挑戦したいみたいなことはなくて、引き続きコンピューターサイエンスや Web フロントエンドの勉強を継続していきたい。

コンピューターサイエンスはよくも悪くも UoPeople 以外のことを始める余裕はないので挫折しないよう頑張る。
去年以上に頑張る必要があると思ったのはフロントエンド領域で、Hooks 時代の React における設計の知見だったりとかテストまわりだとかで自分がリードできるほどの能力がないと感じており、このあたりは喫緊の課題。当面はフロントエンドのテストのことを勉強したい。

あとは Rust。なんとか時間を見つけて勉強を再開したい。。。

おわりに

2021年は引き続きコロナでメンタル的に辛いときもあったので、なんもできなかったなーとか思ってたんだけど、こうしてふりかえると一応前の年よりは前進してる感じがして良い。

2022年もよろしくお願いします。