概要
2023 年 4 月〜6 月の振り返りです。 今年から四半期の振り返りも OKR で行います。
4 月〜6 月の振り返り記事
2023 年 4 月〜6 月の振り返りを欠かさず実施しました。
4 月の振り返り記事
5 月の振り返り記事
6 月の振り返り記事
勉強関連
勉強時間
3 ヵ月間で合計勉強時間は、291 時間でした。 勉強時間は 120 時間~ 150 時間を目標にしていました。 4 月は残業時間が多く、5 月は GW を利用して旅行にいっていたため、達成できませんでしたが、6 月に持ち直すことができました。
| 4 月 | 5 月 | 6 月 |
|---|---|---|
| 約 78.9 時間 | 約 97.9 時間 | 約 115 時間 |
3 ヵ月間（４月〜６月）の OKR
4 月時点の OKR
OKR の振り返りをします。 4 月時点で立てた OKR は下記でした。
| 注力分野 | Objective（3 ヵ月経過後の目標） | Key Result（必要だと考えていること） |
|---|---|---|
| ソフトウェアテスト・プロダクトマネジメント | 品質の向上と担保を第一義に、テストプロセスおよび開発プロセスを経験した状態 | ソフトウェアテスト技法、テストプロセス、の知識。品質マネジメントを主目的にした開発プロセスまたはプロダクトマネジメントの導入と実践 |
| DevOps・CI/CD | 開発（Dev）側が必要な運用（Ops）の技術と考え方を認識した状態 | DevOps の知識の拡充。モニタリング、オブザーバビリティ、SRE の知識。業務内外にかかわらず CI/CD の実践経験 |
また、4 月時点で 1 ヵ月ごとの具体的な OKR は下表でした。
| 注力分野 | 月 | Objective（1 ヵ月度ごとの目標） | Key Result（具体的な行動予定） |
|---|---|---|---|
| ソフトウェアテスト・プロダクトマネジメント | ４月 | ソフトウェアテストの技法について一通り学んだ状態。プロダクトマネジメントの初歩的な部分を学び始めた状態 | JSTQB に合格する。「ソフトウェアテスト技法ドリル」の勉強会を開催する。「はじめて学ぶソフトウェアのテスト技法」「ALL for SaaS」を読む |
| ５月 | プロダクトマネジメントについて学んだ状態。ソフトウェアテストの技法を学ぶ。 | 業務で「単体テストの考え方/使い方」の勉強会を終える。「プロダクトマネジメント」を読む。「ソフトウェアテスト技法」または「実践的プログラムテスト入門」に挑戦する | |
| ６月 | ソフトウェアテストのついて深く知っている状態。継続的にプロダクトマネジメントの知識をアップデートした状態 | 「ソフトウェアテスト技法」または「実践的プログラムテスト入門」を読み終える。「正しいものを正しくつくる」「チーム・ジャーニー」などを読む | |
| DevOps・CI/CD | ４月 | DevOps の基本を認識している状態 | 「Effective DevOps」「The DevOps ハンドブック」を読む。業務のふりかえり方法を変えてみる。個人と業務で CI/CD を組み込む |
| ５月 | モニタリング、オブザーバビリティ、SRE の基本を認識している状態。業務で DevOps について議論された状態 | チームで必要な DevOps について議論を始める。「入門監視」「オブザーバビリティ・エンジニアリング」「SRE サイトリライアビリティエンジニアリング」を読む。個人と業務で CI/CD を組み込む | |
| ６月 | DevOps および周辺技術について認識している状態。業務において DevOps の認識がとれており、より最適な状態に向かっている状態 | チームで必要な DevOps について議論を終えている。より最適化するために、チームで DevOps に対する目標を定める |
6 月時点の OKR 結果
それに対して、1 ヵ月毎に実践した OKR を振り返ると下表になります。Objective は毎月の振り返りで修正しています。たとえば、5 月の Objective は 4 月末の振り返りで更新しました。 当初はソフトウェアテスト・プロダクトマネジメントと DevOps・CI/CD でしたが、開発者テスト・プロダクトマネジメントと DevOps・SREに更新しました。
| 注力分野 | 達成度（100 点満点） | Key Result（行動結果） |
|---|---|---|
| ソフトウェアテスト・プロダクトマネジメント | 75 点 | JSTQB に合格した。「ソフトウェアテスト技法ドリル」「はじめて学ぶソフトウェアのテスト技法」「ALL for SaaS」を読んだ。業務で統合テストの自動化を行い、テスト分析も実践した |
| ソフトウェアテスト・プロダクトマネジメント | 80 点 | プロダクトマネジメント系の書籍を 3 冊読んだ。業務で「単体テストの考え方/使い方」の勉強会を終えた。 「ソフトウェアテスト技法」に挑戦したが諦めた。 |
| 開発者テスト・プロダクトマネジメント | 65 点 | 業務のソースコードを 4 種類のプロダクションコードに落とし込んだ。書籍から UI コンポーネントテストの基礎を学んだ。業務コードの改善に取り組んだが、難解すぎて時間がかかっている |
| DevOps・CI/CD | 65 点 | godoc を静的な HTML にすること方法がわかり、業務の CI/CD に組み込んだ。「Effective DevOps」「The DevOps ハンドブック」を読んだが、現状活かせていない |
| DevOps・CI/CD | 75 点 | 「入門監視」「オブザーバビリティ・エンジニアリング」を読んだ。開発運用の MTG の進行方向を変更した。「SRE サイトリライアビリティエンジニアリング」を途中で読むのをやめた。 |
| DevOps・SRE | 70 点 | SRE 本の勉強会を始めて、全 9 回のうち 4 回を終えた。一応、開発運用間の共通の目標を持てた |
3 ヵ月間（４月〜６月）の OKR 結果
3 ヵ月を総括した振り返りは下記になります。
| 注力分野 | 達成度（100 点満点） | Objective | Key Result |
|---|---|---|---|
| ソフトウェアテスト（開発者テスト）・プロダクトマネジメント | 73.3 点 | 品質の向上と担保を第一義に、テストプロセスおよび開発プロセスを経験した状態 | 入門の範囲ではあるが、ソフトウェアテストについて体系的に学んだ。品質の担保と同様に開発速度の高速化が目的であると考え、統合テストツールの開発や、テスト設計書の策定などに取り組んだ。業務で「単体テストの考え方/使い方」の勉強会を実施し、認識合わせを行った。さらに 4 種類のプロダクションコードを業務コードに対して評価した |
| DevOps・CI/CD（SRE） | 70 点 | 開発（Dev）側が必要な運用（Ops）の技術と考え方を認識した状態 | DevOps の概念について学んだ。DevOps の技術的な要素の 1 つである監視とオブザーバビリティについて学んだ。SRE に興味を持ち始め、SRE 本の勉強会を始めた。Linux とネットワークの勉強を開始した。運用と開発間の課題を解決するような活動を始めた |
それぞれの振り返りをしていきます。
注力分野の振り返り
今回は 3 ヵ月間の振り返りでわかったことから記述します。 ３ヵ月間の継続的な学習によって、自身のなりたいエンジニア像がわかってきました。 それは、「プロダクトの高速かつ持続的な成長を可能にするため、チーム作りと技術詳細に精通したエンジニア」です。 そのために必要な要素を考え、現状の自分に知識が必要な領域は、開発者テスト、プロダクトマネジメント、DevOps、SRE だと考えました。 ほかにも、現在は優先順位が高くないため目標から外しているソフトウェアテストやアジャイルといった分野に加えて、名前すら知見のない領域があると考えています。 しかし、とりあえずは現在掲げた分野に対して継続して取り組もうと考えています。
開発者テスト・プロダクトマネジメント
開発者（ソフトウェア）テスト・プロダクトマネジメントを総評すると以下になります。
- 勉強によって、テストの興味ある分野がソフトウェアテストから開発者テストになった
- プロダクトマネジメントを継続的に学習できた
テストについては、4 月と 5 月にソフトウェアテストの勉強をしていました。 具体的には以下の取り組みを行っていました。
- 個人で「ソフトウェアテスト技法」の勉強会を開催して読み切った
- 業務で「単体テストの考え方/使い方」の勉強会を開催してやり切った。チームの単体テストに対する考え方を統一した
- バイバー本に挑戦したが諦めた
- JSTQB Advanced Level Test Analyst の受験を考えたがやめた
4 月と 5 月の間にソフトウェアテストについて継続的に学びました。 勉強するしたことで、テストがテスターのソフトウェアテストと、開発者が対象の開発者テストがあることに気がつきました。 どちらも大切なのですが、現状の優先順位を考えた結果、開発者テストを優先することにしました。
そのため、5 月の途中から 6 月にかけてテストは開発者テストに注力していました。 具体的には以下の取り組みです。
- 「Hands-On Dependency Injection in Go」を一部読んだ
- 「フロントエンド開発のためのテスト入門」を一部読んだ
- 「単体テストの考え方/使い方」を踏まえて現場のソースコードを評価して、リポジトリのあるべき姿を議論した
- 業務コードで、単体テストが理想の状態が程遠いリポジトリに対して単体テストの改修に着手し始めた
浅く広く開発者テストの具体的な方法を学んだ後に業務コード改善の着手に入りました。 単体テストの改善を進めているうちに業務理解が進んだり、新しいリファクタリングを思いついたりと、得られるものがあります。
プロダクトマネジメントについては、4 月から 6 月にかけて書籍を読むことで学んでいました。感想文を書いていたり書いていなかったりですが、以下の本を読みました。 時間の割り当て方にばらつきがあり、1 冊しか読めなかった月から、数冊読んで感想まで書いた月もありますが、継続的に学習できて良かったです。 自身が求めるエンジニア像になるための分野の 1 つですので、今後も継続して学習します。
- 「All for SaaS」
- 「アジャイル開発とスクラム第 2 版」
- 「プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける」
- 「正しいものを正しくつくる」
- 「チーム・ジャーニー」
DevOps・SRE
DevOps・SRE（CI/CD）を総評すると以下になります。
- DevOps が求める組織論について、複数の書籍を読み、なんとなく理解してきた
- DevOps の組織的な側面だけでなく、監視・オブザーバビリティについても学び、それらの重要性と DevOps との関わりについて理解した
- SRE について調査し、自身が所属する組織に必要なことがわかった
- SRE の聖書である、「SRE サイトリライアビリティエンジニアリング」（SRE 本）の勉強会を開始した
- SRE に必要な技術的な領域である UNIX（LINUX）とネットワークの勉強を始めた
DevOps は、4 月と 5 月に主に取り組んでいました。
取り組みとして、「The DevOps ハンドブック」「Effective DevOps」「システム運用アンチパターン」を読むことで、 DevOps の理解を深めました。
最終的な比較を zenn の scrap に「DevOps を「The DevOps ハンドブック」「Effective DevOps」「システム運用アンチパターン」で比較」にまとめました。
そして、細かい違いはあれど DevOps は「プロダクトの価値の提供を最速にすると同時に、継続的な学習と実験の文化を作り出すこと」が共通の目標になると結論づけました。
それらを達成するための手段が、ビジネス KPI（価値）の明確化、自動化、CI/CD、ログとメトリクスの測定・分析、チームビルディング、アジャイル、ドメイン駆動設計などが挙げられると考えました。
自身の過去の取り組みを振り返ったときに、一部においては実践し継続していますが、一方では手が届いていないことを理解しました。
DevOps を学ぶ取り組みの 1 つとして、監視・オブザーバビリティを入門 監視」と「オブザーバビリティ・エンジニアリング」から学びました。
これらを読むことで、ビジネス KPI と技術的指標の関連付け、ユーザー体験の観測といったことを学びました。
どちらも重要な事柄であると共感した一方で、ほとんど取り組めていない領域だと思いました。
これらについても継続的に実践していきます。
DevOps を学んでいく過程で SRE に興味を持ち本腰をいれて学ぶべき分野だと判断しました。
そのため、5 月の終盤から 6 月にかけて SRE について勉強を始めました。
具体的には、SRE 本の勉強会と SRE に必要な技術領域を学ぶ方法の調査です。
SRE 本の勉強会は、全 9 回で開催する計画立てました。
6 月終了時点で 4 回目を終えています。
SRE を具体的な事例で学べる一方、あまりにも Google の具体的すぎる内容のため読むのに時間がかかることも多いですが、勉強会で関心が一致したことだけを深堀することで継続できています。
SRE に必要な技術領域を学ぶ方法の調査は、SRE 本に記載されていた以下の文章から、Linux とネットワークに注力して調査しました。
私たちがさらに求めている技術的スキルの中で最も代表的なものを 2 つ挙げるなら、間違いなく UNIX システムの内部とネットワーキング（レイヤー 1 から 3）に関する専門知識です。
結果、以下の scrap にまとめました。そして、「入門モダン Linux」や「3 分間ネットワーク講座」などを読み進めています。
7 月以降も SRE と DevOps について学んでいきます。 SRE は SRE 本を読みつつ、Linux やネットワークの知識を別の書籍で拡充していきます。 場合によっては資格の取得をする予定です。 DevOps は基本的には SRE 本を読んでチームで実践したり、ビジネス KPI の分析、監視・オブザーバビリティの改善に取り組んでいきます。
読書
読みきれていない本や読書感想文を書けていない記事を含めると、以下が挙げられます。
- ソフトウェアテスト技法ドリル
- はじめて学ぶソフトウェアのテスト技法
- ALL for SaaS
- Effective DevOps
- The DevOps ハンドブック
- プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける
- 正しいものを正しくつくる
- オブザーバビリティ・エンジニアリング
- 入門 監視
- システム運用アンチパターン
- アジャイル開発とスクラム第 2 版
- SRE サイトリライアビリティエンジニアリング
- チーム・ジャーニー
- 入門 モダン Linux
- ネットワークはなぜつながるのか 第 2 版
- ［改訂新版］3 分間ネットワーク基礎講座
「プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける」
「正しいものを正しくつくる」
「オブザーバビリティ・エンジニアリング」
「入門 監視」
「入門 モダン Linux」
7 月 ~ 9 月の OKR 目標について
振り返りの最初に書いた通り、自身がなりたいエンジニア像は「プロダクトの高速かつ持続的な成長を可能にするため、チーム作りと技術詳細に精通したエンジニア」です。 それらを達成するさまざまな手法がありますが、7 月以降も継続して、開発者テスト、プロダクトマネジメント、SRE・DevOps に注力していきます。
それぞれを選定した理由は下表の通りです。
| 項目 | 理由 |
|---|---|
| 開発者テスト | 開発者テスト（主に単体テスト）は、開発者が最も最初にプロダクトのフィードバックを得られるタイミングだから。フィードバックのタイミングが早く、それ自体が高速であることは、プロダクトの高速な提供に直結するから |
| プロダクトマネジメント | 企画段階で誰のためのソフトウェアなのかを理解することで、プロダクト開発を通じて目的の一貫性を持つことが可能になる。最終的なユーザーのフィードバックの指標やビジネス KPI が明らかになるから |
| SRE・DevOps | プロダクトの信頼性について技術的な側面から評価ができることで、プロダクトの成長やチームの行動の選択の一助になるから。DevOps の理論の実践は、チームの文化づくりにつながるから |
開発者テスト・プロダクトマネジメントは分割しました。そして、それぞれの取り組みを評価する方法をゆるくします。 SRE・DevOps を分けなかったのは、基本的には SRE 本の内容が優先なのと、SRE 本で学んだことを実践することが多くなると予想しているです。3 ヵ月の間に分割する可能性もあります。
現状の目標はそれぞれ以下になります。
- 開発者テスト: 業務コードの単体テスト改善およびリアーキテクチャをリードすることで、経験をつむ
- プロダクトマネジメント: 毎月最低 1 冊の書籍を読み、感想文を書くことを必須にする
- SRE・DevOps: SRE 本を読みつつ、Linux とネットワークの勉強計画を行い、知識を拡充する。DevOps は SRE 本を読んだ内容をチームに導入したり、ビジネス KPI の分析に時間を割いたり、監視・オブザーバビリティの観点からフィードバックを取得する
具体的な計画や詳細な点数の付け方は 7 月 ~ 9 月の目標記事で記述します。
まとめ
この 3 ヵ月の振り返りで最も良かったと思えたことは、自身のなりたいエンジニア像が明確になったことです。
さまざまな領域を継続的に学んできましたが、ようやく共通の目標が定まった感覚です。
きっかけは、The DevOps ハンドブックで記載されていた、「第 3 の道：継続的な学習と実験の原則」に共感したことです。
きっかけはそうですが、それ以外にも継続的に学習記録を残したことで、過去の行動から逆算して目標を理解できたので、記録を残していて良かったと思えました。
こういった事例があると、来月以降も継続して取り組む気になれますし、業務内外問わず中期的な振り返りを進めようと思いました。
次に良かったことは SRE が強い興味の対象であることがわかったことです。
以前は SRE を知ったときには内容や簡単な概要を知るのみで特に興味はありませんでしたが、今では適切に理解し学ぶべき分野だと判断しています。
しかし、いきなり周囲に SRE を勧められても特に取り組む気にはなりませんでしたし、自分で必要な分野だと考えるようになったのも過去の勉強記録をたどれるようにしていたからだと思いました。
個人的なキャリア的な観点では、SRE 周りの興味が付きないのであれば、Web サービスを提供する側ではなく、SRE 導入の支援や周辺技術の導入するといった事業に対して興味が生まれました。 理由は 2 つあります。 1 つめは、技術領域を主目的とした業務経験をしてみたいからです。 これは、SRE といった特定の話ではなく、一度専門的な技術領域を業務として学ぶ期間を設けることで、考え方が刷新されるのではないかと考えたからです。 2 つめは、さまざまなユースケースで信頼性の考え方を学びたいからです。 職場では、SRE の体制がなかったり、やろうとしているが手探りな状況だったり、特定のユースケースに特化したパターンだったりとした懸念が挙げられます。 現状の環境のまま、SRE の導入をすることで学べるのがベストですが、時間がかかりすぎたり、自身を持って評価できない懸念があります。 いろいろ書きましたが、とりあえずは職場で SRE・DevOps の導入しつつ、個人で SRE 本を読みながら技術スキル（Linux、ネットワーク）の学習を終えたときの状況次第だと考えています。
最後にですが、今回も OKR の振り返りができました。 まとめの最初に記述した通り、自身のエンジニア像が見えてきたことと SRE に対して興味が明確になってきた点において OKR 目標を掲げてきてよかったと考えています。 唯一の懸念点は LT 会に参加しなかったことです。ネタは割とあるのに、発表できなかったのは自身の行動力の無さを実感しました。 発表しないことに対する問題に加えて、パワポ作成能力やプレゼン能力の低下を実感しているので、若干気がかりなので来月以降に職場で簡単な LT などができないか検討してみます。 OKR そのものの懸念点は 2 つあります。 1 つめは、単純に注力分野が多いことです。 これは、評価の基準を低めに考えることで対策しようとしています。 2 つめは、来月以降取り組むことは 3 ヵ月で完了しないことが多いと考えています。 これについて明確な答えは出ていません。 3 年目に半年以上費やすことを考えると、自分のキャリアの方向性に関わってくるので、精査しつつ実践します。
