2022FYの振り返り
5月のGWも過ぎてしまったが、できてなかった昨年度の振り返りをします。
昨年度のトピックは育休と権限委譲です。
育休
子供が産まれたので、それに合わせて2ヶ月間の育休を取得しました。
みんなが言っていることですが、育休を取得して良かったです。
期間
育休に入る前までは少し長いかな？と思っていましたが、可能であればあと1, 2ヶ月ぐらいは続けたかったです。
自分のキャリアへの影響に関しての焦りも少しありましたが「長い人生の中の2ヶ月だと思えば良い期間なんじゃない？これまで仕事頑張ってたんだし」という妻の言葉にも救われました。
女性の場合だと最低でも出産前後で強制的に仕事から離れないといけないので、かかるプレッシャーが全然違うんだろうなと、振り返ってみてしみじみと感じます。
取り組んで良かったこと
ネントレに取り組んだことが一番良かったです。
昼も夜も関係ないことは覚悟していましたが、育休中だし昼間も寝れるから大丈夫でしょうと高をくくっていました。
が、現実はそれほど甘くなく、睡眠不足の日々が続きました。睡眠時間が削られると気持ちに余裕がなくなり、イライラする日々が続きました。
そこで始めたのがネントレです。
まだ時期的に早かったかもしれませんが、この本を読んでできるところからやってみようと始めました。
マンガなので2時間ぐらいあればサクッと読めます。買ったその日から実践できるのでおすすめです。
幸いにもはじめて1週間ぐらいで効果が出て、朝までぐっすりと寝るようになってくれるようになりました。
睡眠時間はきちんと確保するように気をつけて生活しています。
権限委譲
2021FYの振り返り - bryutus blog でも書きましたが、自分のスキル不足を長く働くことで補っていました
それまでの仕事のやり方を変える必要が出てきたので、チーム内へと権限委譲を行いました。
権限委譲を行う中で特に意識したことは 2 つです。
- アウトプットを受け止める
- 役割における責任と権限、業務の意図を明確にする
アウトプットを受け止める
他の人に任せるので、同じアウトプットになるわけがありません。
それを自分が満足いくアウトプットになるように矯正してしまうと、いつまで経っても権限を委譲したとは言えません。
メンバーが出すアウトプットを受け止めて、それが会社のミッションに沿ったものになるように働きかけることが大切だと考えています。
アウトプットの方向性を合わせるために、どうしてそのように考えたのか、もしかしたらこういった観点が不足してるんじゃないか、迷ったところに関しては方針が明確になっていないんじゃないかと会話を増やすことを心がけています。
役割における責任と権限、業務の意図を明確にする
新しい役割を担ってもらう時には、責任だけではなく権限も本人とチームに共有しています。
権限もセットで渡すことでその人ができる領域を増やして、試してみたいことにチャレンジができる環境になれば良いなと考えています。
業務だけを引き継いで意図が明確になっていると、何を意識しないといけないのかが分かるので、自分たちだけの判断で今のやり方を改善できるようになることを期待しています。
今年度に向けて
育休を取得する前は少なからず不安がありましたが、育休を取得すると決めたことでこれまでの仕事のやり方も変わり、結果的には家庭にも仕事にも良い影響が生まれたと思っています。
権限を委譲したことで発生した問題は属人化させてしまっていたことだと認識し、それをチームで解消するためにはどうすれば良いのか？をメンバーと一緒に悩み、考え、改善する一年にしようと思います。
個人的な抱負は、業務でもプライベートでもコードを書く時間を増やすことです。
Four Keysに期待していること
5. Accelerate by texta.fmを聴いてFour Keysの存在を知り、エピソード中に紹介されていたLeanとDevOpsの科学を読み始めたのが昨年の9月頃でした。
開発にだけフォーカスした数字ではなく、ビジネスも含めた数字だったことが興味を持ったきっかけです。 所属している組織でもFour Keysの計測してみようという話になっているので、計測することにどういった期待を持っているのかを整理してみようかと思います。
Four Keysとは
Four KeysとはDevOps Research and Assessment（DORA）が計測している4つの指標のことを言います。
- 速度に関する指標
- デプロイの頻度
- リードタイム
- 安定性に関する指標
- 平均修復時間（MTTR）
- 変更失敗率
この4つすべての指標の計測結果が抜きん出ているハイパフォーマーは、その他のミディアム・ローパフォーマーよりも2倍以上も組織としてのパフォーマンスが優れていることが分かっています。
また、速度と安定性にはトレードオフがあるような気がしますが、ハイパフォーマーはすべての指標が高いということからも、トレードオフの関係性がないことが言えるようです。
2017年のソフトウェアデリバリのパフォーマンス
| 2017 | ハイパフォーマー | ミディアムパフォーマー | ローパフォーマー1 |
|---|---|---|---|
| デプロイの頻度 | オンデマンド （1日複数回） |
週1回から月1回 | 週1回から月1回 |
| リードタイム | 1時間未満 | 1週間から1ヶ月 | 1週間から1ヶ月 |
| 平均修復時間 | 1時間未満 | 1日未満 | 1日から1週間 |
| 変更失敗率 | 0-15% | 0-15% | 31-45% |
出典: LeanとDevOpsの科学[Accelerate] / Nicole Forsgren Ph.D. (著), Jez Humble (著), Gene Kim (著), 武舎広幸 (翻訳), 武舎るみ (翻訳) / インプレス
また、このFour Keysを改善促進する効果が高いと言われているケイパビリティ（機能や能力）も調査されています。2022年12月現在だと27のケイパビリティがあります。
2021年のレポートからは、この4つの指標に加えて「信頼性」という5つ目の指標も出てきています。
期待していること
ビジネスに貢献できているという安心感がある
ビジネスに対して良い影響が示されている指標なので、エンジニアの自己満足にならずに安心して数字を追い求めることができそうです。 また、このFour Keysの数字と会社の財務の数字を結びつけることで、エンジニアの取り組みを非エンジニアにも分かりやすく説明することができるようになるかもしれません。
開発者体験が向上しそう
Four Keysを追い求めるとなると、書籍名にも付いているようにLean開発手法を用いた開発にならざるを得ないと考えています。
サイクルタイムを縮めるためにバッチサイズを小さくすると、PRも小さくなり、レビューもしやすくなります。リソース効率を重視するのではなくフロー効率を重視することで、チーム内でのドメイン知識が均一化されて属人化も生まれにくくなります。結果的に、開発者体験が向上するのではないかと期待しています。
仮説・検証のサイクルを素早く回すことができる
Four Keysやサイクルタイムを計測して定量化することで、改善の取り組みが効果的なのかどうかを素早く・正確に判断することができそうです。 判断が素早くなると仮説・検証のサイクルをより多く回すことができるようになりそうだと期待しています。
おわりに
現時点でのFour Keysに対しての理解と期待していることを整理してみました。 計測を始めて、それをどのように活用して、どのように改善していったのか、を書けるようになることを目指します。
参考
1on1で意識したいこと
「実践！1on1ミーティング」を読んで、1on1で意識したいことをまとめてみました。
書籍は、理論や目的、具体的な手法がまとまっているので、実践して困ったことがあったら読み返してを繰り返すことで、良い1on1を体得できそうという期待を感じました。 1on1にについての書籍でどれを読んでみたら良いか分からないという方には、ぜひこれを！とレコメンドしたいです。
スタンス
- 自分を尊重してくれない人には、心を開かず、簡単にやる気は低下する
- 横からの勇気づけ、応援というスタンスが大事である
- 論理やテクニックで相手を変えることはできないので、粘り強く温かく接し続ける
面談と1on1の目的の違い
- 面談： 課題を解決すること
- 1on1： メンバー本人の内省を促すこと
自律型人財を育てる３つのフェーズ
第1フェーズ： 心理的安全性（安心感）の醸成
- メンバーに対して思っていることは、メンバーからも思われている（相手は自分の鏡）
- まずは存在承認（認める）から
- ジャッジをせずに、ありのままの事実をニュートラルに受け止めて、肯定面を見る
- Youメッセージではなく、Iメッセージを使う
第2フェーズ： 動機づけられる、頑張る理由を見つける
- ビジョン型と価値観型があることを知る
- 「なぜ（Why）」ではなく「何（What）」を使う
第3フェーズ： 気づき、チャレンジする
書籍にも書いてあったように、質問集等は暗記するのではなく、自分用の1on1ガイドラインを作ってみようと思います。
2021FYの振り返り
年度末なのでつれづれなるままに今年度の仕事をタイムラインで振り返ります。
04 - 06月
大きなマイルストーンのリリースを行った。
もちろんリリースしたら終わりというわけではないので、リリースに合わせた運用も始まり、日々発生する問題に対処することに追われていた。
新年度からは役職が付いて管理職になった。
2月ぐらいから前振りがあったけど、マネジメントに関する書籍を2冊読んだぐらいでほとんど準備ができていなかった。
07 - 09月
メンバーとの1on1を始めた。
評価者と被評価者という関係や1on1に対しての警戒心もあってか、始めたばかりの頃は「特に何もないです」で終わることもあったけど、最近は少しつつくと「実はあの時こう思っていて...」と話してくれるようになったメンバーもいる。
1on1に対する期待値を高く持ち過ぎて空回りしていたけど、あの時の発言はどういう意図があったんだろう？どんなことを考えていたんだろう？と、興味の対象を本人に移してからは良い方向に向かっていると思う。
ビジネス側とのやり取りに忙殺されており、これまでの開発手法に限界を感じていた。
極端に言うとメンバー毎に一人カンバン方式のような開発手法を取っていて、仕様や要件に関する確認が全て自分に集まっていたため、自分がボトルネックになっていた。また、チーム内でも隣の人がどんなことをやっているのか分からず、ヘルプもやりづらい状況だった。
社内のスクラムマスターに相談をして、スクラム開発やチームビルディングの書籍を読んでいた。
10 - 12月
スクラム開発をチームに導入した。
それと同時にこれまでやってきた業務の一部をチームにやってもらうことにした。単純に個人に委譲すると自分の大変さが別の人に移るだけで何も問題は解決していないので、チームや仕組みで解決できないかということを心がけている。
が、結局個人に大変さが移っただけの部分もある。マイルストーンをうまく置くことができず、方向性が定まっていないのが今の課題だと考えている。
これまでハレーションを恐れて気を遣った結果、マイクロマネジメントになってしまったりと誰も嬉しくない状況になってたけど、チームのことを信頼して責任を持ってもらおうと思うように徐々になってきている。
業務量のキャパシティは変わっていないが、業務の領域が少しスライドしただけで、またチャレンジできるところが見つかって仕事がより楽しい。メンバーも同じ想いになってくれてると嬉しい。
01 - 03月
仕様の認識違いやテスト漏れ、デグレによる不具合が続いたこともあり、クオリティを上げるためにはどうすれば良いか？ということを考えていた。
体系的にテストを学んだことがなかったため、練習帳なるものを購入してテスト技法についてを見かじった。
設計と開発、テストの距離をもっと近くするためにDDDの勉強を始めて、勉強してきた知見を共有する会を同じプロジェクトの人と密かにやっている。
振り返りと来年度に向けて
組織的にもメンバーからリーダーになったけど、成果の出し方の考え方が変わっていないので、自分1人のパフォーマンスで何とか頑張ろうとして長時間労働一択になっている。メンバーも見てて大変そうとしか思えなくて、リーダーという役割を魅力的に感じてくれる人は少ないだろう。
来年度はメンバーに面白そうだとか、チャレンジしてみたいと思えるような環境を作ることを頑張りたい。
昨年の今頃は来年度のことを考える余裕が微塵もなかったけど、今年は次のことを考えてアクションできているところもある。
少しずつだけどきっと前進してる。大丈夫。
「ソフトウェアテスト技法練習帳（Part 3・4）」の中で出てきたテスト手法を整理してみた
前回のPart 1・2に続いて、Part 3・4に出てきたテスト手法についてを整理してみます。
Part3 状態遷移テスト
ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03には、このように記載されています。
コンポーネントやシステムは、現在の条件や過去の履歴（システムの初期化後から起きるイベントなど）によって、イベントに対して異なる振る舞いをする。過去の履歴は、状態の概念を使用してまとめることができる。状態遷移図は、ソフトウェアの取り得る状態、ソフトウェアが開始および終了する方法、ソフトウェアが状態間で遷移する方法を示す。
・・・
状態遷移表は、状態間の有効な遷移と無効だと思われる遷移のすべてと、イベント、有効な遷移の際のアクションを示す。状態遷移図は有効な遷移のみを示し、無効な遷移は除くのが一般的である。
状態遷移図
どのような状態があるのか、その状態が変化するイベントはなにか、これらの状態をイベントでつなげることで状態遷移図を作成します。
状態遷移表
作成した状態遷移図をもとに状態遷移表を作成すると、状態とイベントの組合せの漏れや仕様にない遷移を見つけやすくなります。
| 状態X | 状態Y | 状態Z | |
|---|---|---|---|
| イベントA | 状態Y | 状態X | N/A |
| イベントB | N/A | 状態Z | 状態Z |
| イベントC | N/A | N/A | 状態Y |
関係行列
縦軸に遷移前の状態を、横軸に遷移後の状態を、各セルに状態が遷移するときのイベントを記載した関係行列を作成します。
| 状態X | 状態Y | 状態Z | |
|---|---|---|---|
| 状態X | a | ||
| 状態Y | a | b | |
| 状態Z | c | b |
- a: イベントA
- b: イベントB
- c: イベントC
1スイッチカバレッジ
2回のイベントで遷移するパスを全て網羅するカバレッジです。
1スイッチカバレッジは、関係行列の積を取ることで求めることができます。
| 状態X | 状態Y | 状態Z | |
|---|---|---|---|
| 状態X | aa | ab | |
| 状態Y | aa + bc | bb | |
| 状態Z | ca | bc | bb + cb |
テストケース
1スイッチカバレッジの状態遷移のパスをテストケースとして起こしていきます。
| No | 遷移前の状態 | イベント | 期待値 |
|---|---|---|---|
| 1 | 状態X | イベントA → イベントA | 状態Xに遷移すること |
| 2 | 状態X | イベントA → イベントB | 状態Zに遷移すること |
| 3 | 状態Y | イベントA → イベントA | 状態Yに遷移すること |
| 4 | 状態Y | イベントB → イベントC | 状態Yに遷移すること |
| 5 | 状態Y | イベントB → イベントB | 状態Zに遷移すること |
| 6 | 状態Z | イベントC → イベントA | 状態Xに遷移すること |
| 7 | 状態Z | イベントB → イベントC | 状態Yに遷移すること |
| 8 | 状態Z | イベントB → イベントB | 状態Zに遷移すること |
| 9 | 状態Z | イベントC → イベントB | 状態Zに遷移すること |
その他にも、C1カバレッジ（遷移網羅）や有限オートマトン、プッシュダウンオートマトンといったキーワードがありましたが、正直に言うとこれらについては理解が追いついていません。
今は理解はできていないですが、そういった考え方や手法があったなと頭の片隅に置いておき、実践を交えつつ理解を深めようと思います。
Part4 組合せテスト
ISTBQの用語集には、このように記載されています。
ブラックボックステスト技法のひとつ。複数のパラメータの値を特定の組み合わせで実行するためのテストケースを設計する。
すべての組合せをテストするには非現実的なこともあります。そういった場合に、効率的な組合せテストを行うためにペアワイズ法を使います。
ペアワイズ法は、バグは1～2因子の組合せに多く存在することが経験的に知られていることに基づいてテストケースを作成する方法です。
- 因子: 入力のパラメータや条件
- 水準: 因子の取り得る値や範囲
- 同値分割法や境界値分析を使って最適化する
次のような因子と水準があった場合に、全てのケースをテストしようとすると27通りのテストパターンが存在しますが、ペアワイズ法を用いると9通りまで数を削減することができます。
$ pict model.txt Type Size File Stripe 100 FAT32 Span 100 FAT Stripe 500 NTFS Span 10 NTFS Span 500 FAT32 Single 100 NTFS Stripe 10 FAT Single 10 FAT32 Single 500 FAT
このように2因子間の組合わせの網羅は行いますが、3因子間の100%の網羅性は保証していません。3因子間以上の網羅性を犠牲にして組合せ数を削減しています。
ペアワイズ法を使ってテストケースを作成するために、Microsoft社が公開しているPICTを利用しました。
「ソフトウェアテスト技法練習帳（Part 1・2）」の中で出てきたテスト手法を整理してみた
仕事でテスト漏れによるバグが発生したことでテストのやり方について思うことがあったので、「ソフトウェアテスト技法練習帳」を買って問題を解いています。
この書籍は問題集として特化しているため、その中で使っているテスト手法についての言及はあまりありません。
自分の理解のためにPart 1・2で出てきたテスト手法についてを整理してみます。
Part1 同値分割法と境界値分析
同値分割法
ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J03（以下、シラバス）には、このように記載されています。
同値分割法は、同等に処理されると想定したデータすべてを同じパーティション（これを同値クラスと も呼ぶ）に振り分ける技法である（『Kaner 2013』および『Jorgensen 2014』を参照）。有効な値と無効な値の両方に対して同値パーティションがある。
システムに入力が可能な値を、有効な値（システムに受け入れられる値）と無効な値（システムに拒否される値）とにパーティションを分けてグルーピングし、そのグループの中の代表的な値をテストする手法です。
同値クラスは「その範囲はどの値でも同等に処理されることが合理的に予想される」集まりです。
有効な値の同値クラスを「有効同値クラス（有効同値パーティション）」と呼び、無効な値の同値クラスを「無効同値クラス（無効同値パーティション）」と呼びます。
例えば、年月日のうちの「月」の値を入力する場合、月の入力値の同値クラスは以下の3つにグルーピングすることができます。
境界値分析
シラバスには、このように記載されています。
境界値分析（BVA）は同値分割法の拡張であるが、パーティションが数値または順序付け可能な値で構成される場合だけ使用できる。パーティションの最小値および最大値（または最初の値と最後の値） が、境界値である（『Beizer 1990』を参照）。
同値クラスの上限値、下限値とその前後の値（境界値）を入力としたテストを実施します。
境界付近では間違いが起こりやすいため、その付近を狙ってテストを行います。
同値分割法と組み合わせて実施することが多いです。この練習帳でも2つの手法を組み合わせた問題が出題されています。
例えば、年月日のうちの「月」の値を入力する場合、境界値は以下のようになります。
Part2 デシジョンテーブル
シラバスには、このように記載されています。
デシジョンテーブルは、システムが実装すべき複雑なビジネスの規則を表現するのに有効である。デシジョンテーブルを作成する際には、テスト担当者は条件（主に入力）と結果的に起きるシステムのアクション（主に出力）を識別する。条件とアクションは表の行となり、条件を上部、アクションを下部に記述する。
条件（入力）に対して、プログラムがどのように動作（出力）するかを表形式にまとめたものです。入力条件の組み合わせと対応する出力結果を整理することでテストケースを作成する技法です。
JIS X 0125では、Y/NやXで記述する方法を制限指定と呼び、数値や選択肢で記載する方法を拡張指定と呼んでいます。
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|
| クーポン持参 | Y | Y | Y | Y | N | N | N | N |
| 平日/休日 | 平日 | 平日 | 休日 | 休日 | 平日 | 平日 | 休日 | 休日 |
| 65歳以上 | Y | N | Y | N | Y | N | Y | N |
| 割引なし | - | - | - | - | - | - | X | X |
| 10%OFF | - | - | X | X | - | - | - | - |
| 30%OFF | - | X | - | - | - | X | - | - |
| 50%OFF | X | - | - | - | X | - | - | - |
結果が同じ動作がある場合、その組み合わせを省略して書くこともできます。しかし、ロジックが不明であり、処理順序が分からない場合に省略すると必要なテストケースが漏れてしまう可能性があるので注意が必要です。
条件が増えるとテストケースが増え、表が大きくなります。ほかの条件と比べて関連性の低い（独立性の高い）条件で分割することで、表を小さくすることができます。
良い1on1を待っている
良い1on1を受けると、心の中に何となく引っかかっていたことが、会話を通して徐々に輪郭を持つようになり、それを言葉にすることで内省が進み、次に何をすれば良いか具体的なアクションが見えるようになります。
チームのメンバーにも同じような体験してほしいという思いから1on1を定期的に行っているのですが、なかなか成果を出せていないように感じています。
そこで、これまでに受けてきた良い1on1を振り返って、自分がやっている1on1に反映できそうなところがないか、何が違うのかというところを見つめ直してみようかと思います。
ここでは、1on1の中で聞き手やサポートをする人のことをメンター、話し手や主役になる人のことをメンティとして記載しています。
良い1on1では、何を話しても大丈夫だという安心・信頼感があります。
安心・信頼感があると、話をする時に余計な言葉の変換が挟まらなくなり、より生の考えを話せるようになります。
人に悩みを話すことにも勇気が必要です。
たとえ1on1という場を設けてメンターとしての心構えを持ってたとしても、安心・信頼感が足りなければメンティは正直に何でも話すことはありません。
メンターとメンティが人事評価の評価者と被評価者という関係になることが多いかもしれませんが、人事評価をするための場ではないということを伝えることは重要だと思います。
良い1on1では、メンターからの問いかけを通して内省が促進します。
オープンな質問や発言の曖昧さを排除してくれるような問いかけをされると、それを言葉で説明するために頭の中を整理します。
頭の中ではふわっとした曖昧なままで済ませていたことも人に説明するために、自分の中で詳細に理解しようとします。
その理解する行動の中で、どうして課題だと感じていたのか、どうしてもやもやしていたのかという本質的な問題に気づけます。
また、愚痴やネガティブな表現をメンターが要望に言い換えて聞き返すことで、メンティが本当に伝えたかったことが言語化され、前向きな提案にもつながります。
良い1on1では、次にとるべきアクションをメンティが見つけます。
ほとんどメンティだけが話して壁打ちをしてもらっているだけなので、メンターから直接答えを教えてもらうことはないのですが、不思議と何かしらの答えを導き出します。
その答えが有効でない場合もありますが、一度問題を認識しているため、次のアクションも一人で考えるようになります。
こうやって改めて書き出してみると耳が痛いですが、どういう状態になったら良い1on1ができていると言えるのか自分なりの評価軸を持つことができました。
