msksgm’s blog

msksgm’s blog

Webエンジニアです。日々の勉強記録、技術書感想、美術観賞感想を投稿します。

2023年1月の振り返り

概要

2023 年 1 月の振り返りです。

今月は以下を目標にしていました。

msksgm.hatenablog.com

勉強概要

今月は下表のように勉強していました。 今月は合計約 175.3時間です。 年末年始休暇を合算して数えているため、すごく勉強時間が多いです。 目標は平均 120 時間 ~ 150 時間に設定しているため、無理しないように継続して取り組んでいきます。

項目 1 週目(年末年始休暇を含む) 2 週目 3 週目 4 週目 5 週目
平日朝の勉強時間 0 約 12.1 時間(29 ポモドーロ) 約 11.7 時間(28 ポモドーロ) 約 13.8 時間(33 ポモドーロ) 約 3.75 時間(9 ポモドーロ)
平日夕方の勉強時間 0 0 0 約 1.67 時間(4 ポモドーロ) 約 0.83 時間(2 ポモドーロ)
休日の勉強時間 約 61.7 時間(148 ポモドーロ) 約 17.5 時間(42 ポモドーロ) 約 10.4 時間(25 ポモドーロ) 約 10.8 時間(26 ポモドーロ) 0 時間
Kotlin+Spring Boot 勉強会 約 8 時間 約 4 時間 約 6 時間 約 5 時間 約 2 時間
ソフトウェアテストの教科書」勉強会 0 時間 約 2 時間 約 2 時間 約 1 時間 0 時間
connpass の勉強会 0 時間 0 時間 約 0.5 時間 約 0.5 時間 0 時間
合計 約 69.7 時間 約 35.6 時間 約 30.6 時間 約 32.8 時間 約 6.58 時間

1 月の OKR 結果

2023年1月〜3月の目標に記述した OKR 目標は CI/CD とテストです。 具体的には下表の通りになります。

注力分野 Objective(3 ヵ月経過後の目標) Key Result(必要だと考えていること)
CI/CD CI/CD の実践や構築に対して恐れがない状態 CI/CD の概念とツール、シェルスクリプトの知識
テスト 品質観点のテスト知識を持ち、テスト計画が立てられる状態。 ソフトウェアテストの基礎知識、テスト技法、品質、ツールの知識

1 月は以下の通りに落とし込んでいました。

注力分野 Objective(1 ヵ月度ごとの目標) Key Result(具体的な行動予定)
CI/CD CI/CD の理論を学ぶ。シェルスクリプトの勉強をする。 「継続的デリバリーのソフトウェア工学」「シェル・ワンライナー 160 本ノック」を読む。
テスト 品質観点のテストの基礎知識を獲得する ソフトウェアテストの教科書」「ソフトウェア品質を高める開発者テスト」を読む。テストドキュメントの見直しをする

それぞれの注力分野に対する結果は以下です。

注力分野 達成度(100 点満点) Key Result(行動結果)
CI/CD 60 点 「継続的デリバリーのソフトウェア工学」を読んだ。「シェル・ワンライナー 160 本ノック」を読むのをやめた。シェルスクリプトへの理解を後回しにして、会社の CI/CD のドキュメントのインプットをしていた。
テスト 80 点 ソフトウェアテストの教科書」「ソフトウェア品質を高める開発者テスト」を読むことで品質観点のソフトウェアテストの知識が深められた。チームで品質について考えるワークショップを開催し、「誰のためのソフトウェア」を考えることで業務理解が深まり、チームの共通認識が合わせられた

注力分野の振り返り

CI/CD

60 点 の理由は、「最初に掲げていた目標から方向転換が起きたこと」「インプットばかりでアウトプットがあまりできなかったこと」です。

とりあえず CI/CD を学ぶきっかけとして、「継続的デリバリーのソフトウェア工学」を読み切りました。 CI/CD の基礎的な概念を学ぶのが目的でした。一貫して CI/CD によるシフトレフトの重要性とそれを達成するための手法(工学、フィードバック、設計、など)を紹介していました。 CI/CD の重要性を学ぶには十分でした。しかし、良い意味と悪い意味の両方で、同じことが繰り返し記述されていたため、読み進めるたびに新しい発見がある内容ではありませんでした。 「工学」という割には多方面からの考え方ではなく、作者の思想が色濃くでていると思いました。
別件ですが、JaSST のタイムテーブルを眺めていたら、CI/CD/CV という単語を知りました。

続いて、「CI/CD の実力向上の要素としてシェルスクリプトに詳しくなる」という考え方のもと、「シェル・ワンライナー 160 本ノック」を読んでいました。 しかし、想像以上に難易度が高く、ワンライナーを学ぶよりは CI 周りで使われるスクリプトを学んだ方が目的に合致していると考えたため、読むのをやめてしまいました。 ちゃんと読んだのは第 1 部時点です。その時点でも、シェルのしくみに少し詳しくなり良かったと考えています。シェルスクリプトの方向性で学ぶのなら、マスタリング Linux シェルスクリプト 第 2 版を読もうと考えています。

より実践的な CI/CD について学ぶため、会社で利用する CI/CD ツールのドキュメントを読んでいました。 2 週間程度で読み切り、知らなかった機能やなんとなく使っていた機能含めて得られるものが非常に多かったです。 あらためて会社の設定を読み直して、以前より容易に読み進められる部分もあれば、まだ理解できない部分も明らかになりました。 会社の別チームのリポジトリも参考にして、新しく必要そうなビルドを組み込んでいきます。

今月を踏まえて実感したのは、理論よりも簡単で良いから頻繁に利用するリポジトリに役立つ CI を組み込む方が大事だということです。 来月は、本当に簡単な部分から取り組んでいきます。それができたら今後の CI/CD の関心事としてシェルスクリプト、Git コマンド、GitHub API になります。 インプットだけにならないように実践できるチャンスを伺っていきます。

テスト

80 点 の理由は「目標に掲げていた書籍を読み切ったこと」「チーム内で品質について考えることで、ソフトウェアの目的、方向性の認識を合わせられた」からです。

ソフトウェア品質を高める開発者テスト」を読みました。 作者の別の書籍である「知識ゼロから学ぶソフトウェアテスト 【改訂版】」を読んだことがあったため、読みやすかったです。 ユニットテストについて設計を保証すること以上にテスト技法観点から考えたことがなかったので良い振り返りになりました。 しかし、この本だけでは品質を考えたソフトウェアテストの知見は自信を持って言えるほど深まりませんでした。

並行して、「【この 1 冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第 2 版]」の勉強会を実施していました。 品質の定義、テスト技法、テストドキュメントといった基本的だからこそ地盤を固めるべき知識の獲得を目指し、議論しながら読み進めることができました。 そこで、QA について考える際に、品質と欠陥の定義があらためて知り、どうやって現場に落とし込んでいくのかに最初に関心を持ちました。 職場において、「品質」と「エラー・欠陥・障害・故障」について考える資料を作成し、ワークショップ形式で考える会を実践しています。 すべてをやり切ってはいませんが、最初の部分だけでも「やってよかった」と言われるぐらい好印象のフィードバックをもらいました。 最後まで完遂することで、プロダクトファーストな戦術的 QA と戦略的 QA を定義し、品質向上のために寄与していけそうです。 ほかにも、テストドキュメント周りでまだまだできることがあるので、引き続き本書を参考にソフトウェアテストを高めていきます。

品質について考えることでプロダクトファーストな観点から、業務の理解度を深まったと実感しています。 チームビルディング的な一貫でやれるようになりたいです。 品質が固まったら、今後は戦略的 QA と戦術的 QA について考えていきます。 どちらも造語です。DDD で使われる言葉を拝借しました。 QA においてもチーム的な部分と技術的な部分に落とし込める部分があると想像しているので、これから具体化していきます。 とりあえず次やることは、テスト技法を実践し、結果をドキュメントにまとめる力を養うことです。

2 月の OKR

1 月の OKR を踏まえて、2 月の OKR を再設定します。 1 月時点では、抽象度の高かった内容から、より具体的な内容に切り替えました。 来月は実務におけるアウトプットの比率も増やします。

注力分野 Objective(1 ヵ月度ごとの目標) Key Result(具体的な行動予定)
CI/CD 業務のリポジトリに新しい CI を組込み業務効率向上に貢献する。シェルスクリプトの勉強をする。 「継続的デリバリー」を読む。業務のリポジトリに新しい CI を組み込む。可能であれば「マスタリング Linux シェルスクリプト 第 2 版」を読む
テスト ソフトウェアテスト技法を学ぶ ソフトウェアテスト技法練習帳」を読む。「ソフトウェアテスト技法」に挑戦する。「単体テストの考え方/使い方」の勉強会を実施する。業務のテストドキュメントを整理する。

読書

OKR の書籍

OKR 達成のために以下の本を読みました。

以下の本は読みきれませんでした。

継続的デリバリーのソフトウェア工学

msksgm.hatenablog.com

ソフトウェア品質を高める開発者テスト

msksgm.hatenablog.com

シェル・ワンライナー 160 本ノック

今月中の完読を目標にしていましたが、CI/CD の基礎を固めることを優先するため、読むのをやめました。

【この 1 冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]

msksgm.hatenablog.com

その他

興味のある本をつまみ食いしています。途中から「継続的デリバリー」を読み始めたので読み切ることができませんでした。

美術展

今月もいけませんでしたが、来月は行く予定が立ってきました。

技術記事の作成

引き続き Kotlin の書籍を zenn の本作成機能で作成しています。 いったん方向性を変えて、基本的な部分を埋めています。 今月中に公開するのが目標でしたが、2 月までかかる予定です。

その他

「Server-Side Kotlin Meetup vol.7」に参加しました。

server-side-kotlin-meetup.connpass.com

今回の内容は OSS でした。登壇者が自作の OSS を公開している人が多く、熱意を感じました。 良い刺激になった一方で、自分は現状のままで登壇者の方々ほど尖れるのか不安になりました。

また、初めて Kotlin 愛好会の LT 会をリアルタイムで視聴しました。 Kotlin への愛を感じられる会で参加して良かったです。いつか自分も発表してみたいと思いました。

love-kotlin.connpass.com

1 月の振り返りまとめ

初めて計画した OKR を実践し、振り返った月になりました。 3 ヵ月後の抽象的な目標に対して行動するように決めると、1 ヵ月の間に方針変更があっても、一貫して勉強に取り組めました。 1 ヵ月の結果(Key Result)の感想は、「あらかじめ決めた本を読む」を実践するよりは、「学んだことを自分なりに落とし込んで行動にうつせた」ときの方が満足のいく結果になりました。 しかし、計画ができていなかったら行動を移す際の意思決定に時間をかけてしまっていたと、とも振り返っています。 そのため、OKR を実践するには以下の塩梅の重要なのではないかと考え始めました。

  • 無計画すぎない
    • 無計画すぎるのは、対象分野に対する解像度が低すぎる。1 ヵ月程度は中盤までは、ある程度の準備期間としてとらえて、解像度を上げる時期にする
  • あまり具体的に決めすぎない、具体的に決められたことを達成できて満足しない
    • 具体的に決められたことは、こなすことが目的になりがちになる。Objective も具体的すぎる可能性があるので見直す

この観点からすると、自分の計画の立てた方は少し具体的すぎたようにも思えます。 最終的に大事なのは「3 ヵ月後の Objective を達成できるか」ですので、途中で違和感を感じたら積極的に計画の振り返りを実施します。 来月も少し具体的すぎる目標な気がするので、ブレないように意識して進めていきます。