駆け出しエンジニアはPMFの夢を見るか？

駆け出しエンジニアの記録

無職日記（06/12 ~ 06/18）

無職日記

はじめに

今年の8月で32歳になる。今のところ介護や育児がなく、自分の都合で自分のためだけに時間が使えるラストチャンスだと感じ、2023年の2月末で一旦退職した。2023年の10月までやりたいことをやって、復職予定である。毎日何かしらアウトプットが出せれば良いが、そういうわけにもいかないので振り返りも兼ねて週に1回ほど日記を書こうと思う。

やったこと

  • 放送大学の講義の自習型課題を解いた。￥
  • 自習型課題を解く中で線型代数で基底変換の理解が浅いことがわかったので、復習した。
    • インターネットに転がっている教材を見て、簡単な例題を丁寧に追うことで定理のイメージを掴んだ
  • 10月からの再就職に向けて職務履歴を整理し、転職サイトに登録した
    • 書籍をもらえるキャンペーンもあったので、このタイミングで転職サイトに登録した
  • 位置情報系のエンジニアの勉強会に参加 + たまたま研究室の後輩とばったり出会し、晩御飯を一緒に食べた
  • PSYCHO-PASS GENESIS 2を読んだ
  • The FLASHを観にいった
  • 映画終わりに約半年ぶりによく行くホットドック店にいった

所感

  • 7月の中旬から単位認定試験が始まるので、来週は微分方程式の講義の受講と過去問を解いて単位認定試験対策を進めていく
  • 転職活動に向けて、エンジニア経験でアピールしたいことやリーダー経験でアピールしたいことをスライドでまとめておいた方が良さそうだと思った
    • 環境が特殊なので、職務経歴書と口頭で前提を説明するのが難しそうだなと感じたため

『SoftwareDesign 2023年 6月号 特集「改善につながるオブザーバビリティ」』を読んだ

読書 備忘録 オブザーバビリティ 技術

gihyo.jp

これまで縁のなかったオブザーバビリティに入門したかったので読んでみた。3章構成で、1章はオブザーバビリティについての概要、残りの2章は企業での実際の取り組みについての特集だった。

感想

オブザーバビリティの成熟度が高いと、システムやビジネスに与える影響が甚大である「認識しておらず、理解しておらず、監視していないもの（Unknown Unknowns）」に対して、問題に気付いたり、理解できなかった問題に対する答えを見つけ出せるようになるようになると理解した。※言葉の使い方としてはオブザーバビリティができている / できていないという言い方より、オブザーバビリティの成熟度が高い/ 低いという言い方が正しそう。

監視はシステムの健康状態を定期的にチェックする方法です。（省略）一方、オブザーバビリティはシステムの内部状態を観測し、エンジニアがシステム最適化のための洞察を得られる能力です。（省略）オブザーバビリティは監視を内包しており、監視自体は引き続き重要な手法として存在し続けています。

NewRelicの提唱するオブザーバビリティ成熟モデルでレベル2まで到達できていれば、機能としては問題ないがパフォーマンスが良くないところを改善できる。また、レベル3まで到達すればサービスを顧客がどのように使っているか可視化できる。NewRelicの提唱するオブザーバビリティ成熟モデルを使えば、自分が携わっているプロダクトのオブザーバビリティの成熟度がどこかわかり、レベルを上げることで得られる効果の説明がしやすそう。

おまけ

大まかな概念や実際の取り組みがわかったところで、手元で動かして体感したいと思い、JSUG勉強会のSpring Boot 3.0 オブザーバビリティツアーガイドで実際に体感してみた。

ツアーガイドの環境

  • アプリケーションはSprin Boot 3.0
  • オブザーバビリティ
    1. FilebeatでアプリケーションのログをElasticsearchに転送し、Kibanaで可視化する（ロギング部分）
    2. Prometheusが定期的にアプリケーションのメトリクスを取得し、Grafanaで可視化する（メトリクス部分）
    3. Zipkinにアプリケーションからトレースデータを送信して、ZipkinとKibanaで可視化する（トレーシング部分）

アーカイブ動画を視聴した時のメモ

  • ログの形式をElasticsearchの標準の形式（ECSと呼ばれる）で出力するプラグインがある。
    • ECSはjson形式。Log4j2を使うと、MDC経由で任意のkey-valueを設定できる。
  • プロセス間でトレースデータを共有することをContext Propagationと言い、プロトコルはW3C（Spring Boot 3系のデフォルト）とB3 （Spring Boot 2系のデフォルト）の2種類がある。
    • Spring Bootの2系と3系の両方を使っているときはデフォルトのプロトコルが違うため注意!
  • トレーシングの実装はZipkin BraveとOpenTelemetry（OTel）があり、OpenTelemetryの方が勢いがありそう
    • ↓ ChatGPTにも聞いてみた

    • OpenTelemetryはクロスプラットフォームなトレーシングの規格とライブラリであり、データ収集、エクスポート、統合に広範なサポートがあります。Zipkin BraveはJava向けのトレーシングシステムで、Javaコミュニティで人気があります。両者は分散トレーシングの目的を果たすツールですが、OpenTelemetryはより広範なプラットフォームと統合性を持っています。

感想

  • 可視化のダッシュボードを作るためにはメトリクスが何を意味するか理解する必要があり、勉強の方向性が広がった。
  • オブザーバビリティを実現するためのインフラの構築や運用、セキュリティを考えると、SaaSを使った方が結果的には安く済みそう。

その他

ミドルウェアはセットアップされている前提のようだったので、公式の資料やChatGPTに相談しつつローカルのコンテナ環境でミドルウェアが動くようにした。

GitHub - genkiFurukawa/spring-boot-3-observability-tour: Spring Boot 3.0 オブザーバビリティツアーガイドのアプリを動かすためのミドルウェアのセットアップの備忘録

無職日記（06/05 ~ 06/11）

無職日記

はじめに

今年の8月で32歳になる。今のところ介護や育児がなく、自分の都合で自分のためだけに時間が使えるラストチャンスだと感じ、2023年の2月末で一旦退職した。2023年の10月までやりたいことをやって、復職予定である。毎日何かしらアウトプットが出せれば良いが、そういうわけにもいかないので振り返りも兼ねて週に1回ほど日記を書こうと思う。

やったこと

所感

  • 「解析入門」が受講し終わった。複素関数については講義の課題を解くレベルであれば理解できたと思う。一方、微分方程式の課題を解く中で線形代数の知識が必要な部分で思い出せない部分があったりしたので、来週は線形代数の自習型課題を解くことで復習もしたい。
  • オブザーバビリティにちょっと入門できた気がする。オブザーバビリティを実現するツールの使い方やメトリクスの意味や考え方など、勉強しないといけないことの幅が広がって、いい機会だった。在職中はどうせやるチャンスもないしと思って放っておいたのは良くなかった。

『熊とワルツを リスクを愉しむプロジェクト管理』を読んだ

読書 技術

bookplus.nikkei.com

ソフトウェア開発におけるリスク管理について書かれた本。リスクの定義からリスクを定量化をしてどう管理していくかが書かれている。この本が出版されたのが2003年、アジャイルソフトウェア開発宣言が出されたのが2001年ということを踏まえて、アジャイルという考えが今ほどは広くは受け入れらていなかった時代に書かれた本だと想像して、本書を読むと良さそう1。

在職中のことではあるが、実績に基づいて見積もりを出したにも関わらず、根拠なしに半分の時間でできるでしょ？と言われ押し切られた結果2、残業前提で業務に取り組まざるを得ない状況が多々あった。納期に間に合わないこともリスクの一つなのかなと考えていたので、今更ではあるが自分に何かできることはあったのかなと思い読んでみた。

リスク管理には成熟さが求められ、ソフトウェア業界の多くがリスク管理ができていない未熟な組織が多いと本書では主張されている。13章ではソフトウェア・プロジェクトに共通のリスクが挙げられており、「内在的なスケジュールの欠陥」・「要求の増大（変更）」・「人員の離脱」・「仕様の崩壊」・「生産性の低迷」の5つがある。「内在的なスケジュールの欠陥」とは「時間と労力について予定を立てるプロセスに欠陥があるか、あるいは完全に破綻しているために生じるものである」とある。

無理なスケジュールを押し切られてしまった自分にとっては耳が痛い話であったし、ただリスク管理ができておらず未熟であることが分かってしまった。また、読み始めたきっかけの問題は自分だけで解決できる問題ではなく、組織で取り組んでいかないといけない問題であることがわかり、ボトムアップでやっていくことは難しそうだなと感じた。

一方で、「きのうの問題は今日のリスクである。」（p.71）と書いてあるように、チームの振り返りなどを使ってリスクを列挙していく作業をしておけば、組織としてリスク管理ができるくらいに成熟してきた時に、すぐに行動に移せる準備ができたのかもなと思ったりなどもした。

ひどい欠陥のあるスケジュールを約束したり、引き受けたりするマネージャーは、ろくな仕事をしていない。大事な点は、プロジェクトが予定より遅れた場合、それは開発者がきちんと仕事をしていないせいではないということだ。（p.123）

ソフトウェア開発のプロセス以外の要因が列挙されていたり、リスク発見手法が記載されており、今後プロジェクトマネジメントをしたときに、上長とのコミュニケーションに使えそうである（こういう不確定要素があるから今は断言できないとか、幅を持たせた上でしか回答できないなど。そのような情報込みで話せば、建設的な議論ができるかもしれない）。リスク発見手法やリスクの数値化などは業務の中で実践していく必要がありそうで、今回は軽めに読む形で終わらせてしまった。復職したら折に触れて読み直したいと思う本だった。

  1. 13章にあらゆるソフトウェア・プロジェクトに共通のリスクの記載がある。その1つが「要求の増大（要求の変更）」であるが、これはアジャイルの開発手法を採用すれば、リスクを軽減できているはずなので、スクラム開発している人からするとピンと来ないのかな？などと思ったりした。↩
  2. 下っ端のポジションだったので、反論しても聞き入れられる余地がなかった。↩

無職日記（05/29 ~ 06/04）

無職日記

はじめに

今年の8月で32歳になる。今のところ介護や育児がなく、自分の都合で自分のためだけに時間が使えるラストチャンスだと感じ、2023年の2月末で一旦退職した。2023年の10月までやりたいことをやって、復職予定である。毎日何かしらアウトプットが出せれば良いが、そういうわけにもいかないので振り返りも兼ねて週に1回ほど日記を書こうと思う。

やったこと

所感

  • 数学の講義以外に気になることがちらほら出てきて、横道に外れてしまうことが多かった。まだ受講し終わっていない講義の3つのうち、2つがラジオ講義で受講しいても理解が浅く、YouTubeや他の本を読んで補足する形が多く、補足をする中で横道に外れたり、ソフトウェア関連の勉強したくなったりしてしまった。
  • 放送大学の講義を受講していて、そもそも何の問題を解決したくてこの分野が始まったのだっけ？という歴史が気になったので、数学史入門を読んだ。微分積分学がライプニッツとニュートンから始まって解析学まで発展していく歴史があったことを理解できた。線形代数の歴史については本書で語られていなかったが、調べてみると微分積分学と比べると歴史の浅い分野らしいことが分かった。

【備忘録】(読書メモ)ちょうぜつソフトウェア設計入門

備忘録 設計 技術

gihyo.jp

これまでも、たくさんの人が「開放閉鎖原則」をサンプルコード付きで説明してくれていて、原則の言わんとしていることは理解できたが、実際どうすれば原則を守ったコードが書けるのか分からなかった。5章のオブジェクト指向原則でSOLIDについて説明があり、この本のおかげで「開放閉鎖原則」を満たすコードを書くにはどういう指針で考えれば良いか分かった気がする。「変化するであろう仕様と変化しないであろう本質を抽出して、設計・実装する」が「開放閉鎖原則」を満たすためのポイントになりそう。

自分でもFizzBuzzを書いてみて、雰囲気は掴めたと思う。あとは実際の業務で意識して「開放閉鎖原則」を満たせるコードを意識的に書けるようにしていきたい。

FizzBuzzをTSで素振り

// 開放閉鎖原則（拡張に対してオープンであり、変更に対してクローズド）をFizzBazzを参考に理解する
// ルール1: 入力された数字をあるルールに従って変換表示する
// ルール2: 3の倍数の場合は、Fizzと表示する
// ルール3: 5の倍数の場合は、Buzzと表示する
// ルール4: 3の倍数かつ5の倍数の場合は、FizzBuzzと表示する
// ルール5: これらの条件に当てはまらない場合は数字をそのまま表示する

// 変わらないと期待できる本質は以下
// 1. 整数を入力すると文字列を返す
// 2. 任意の変換ルールを複数定義できる
// 3. 変換ルールはなんらかの判定条件を満たした時に適用される
// 4. 変換結果は前のルールの結果を受けて累積したものになる

// 🚀: ルールが追加された場合はIReplaceRuleを実装して、NumberConverterのルールに追加すれば良い（= 拡張に対してオープン）
// 🚀: 判定条件を満たした時の出力が変わる時は、それぞれのルールの実装クラスを修正すれば良い（= 変更に対してクローズド）

interface IReplaceRule {
    match(carry: string, n: number): boolean;
    apply(carry: string, n: number): string;
}

class NumberConverter {
    private rules: IReplaceRule[]
    constructor(rules: IReplaceRule[]) {
        this.rules = rules;
    }

    convert = (n: number): string => {
        let carry = "";
        for (const rule of this.rules) {
            if (rule.match(carry, n)) {
                carry = rule.apply(carry, n);
            }
        }
        return carry;
    }
}

class CyclicNumberRule implements IReplaceRule {
    private base: number;
    private replacement: string;

    constructor(base: number, replacement: string) {
        this.base = base;
        this.replacement = replacement;
    }

    match(carry: string, n: number): boolean {
        return (n % this.base == 0);
    }
    apply(carry: string, n: number): string {
        return carry + this.replacement;
    }
}

// NOTE: 何も表示しない仕様に変わる可能性があるためルールとして実装する
class PassThroughRule implements IReplaceRule {
    match(carry: string, n: number): boolean {
        return carry === "";
    }
    apply(carry: string, n: number): string {
        return n.toString();
    }
}

const fizzBuzz = new NumberConverter([
    new CyclicNumberRule(3, "Fizz"),
    new CyclicNumberRule(5, "Buzz"),
    new PassThroughRule()
]);

console.log(fizzBuzz.convert(1));
console.log(fizzBuzz.convert(3));
console.log(fizzBuzz.convert(5));
console.log(fizzBuzz.convert(15));

読んでいて印象に残ったところ

単体テストの文脈でいうモックの使われ方とは、使われ方を検証するための疑似オブジェクトのことです。モックオブジェクトは、ダミーメソッドの呼び出しが行われたかと、そのパラメータが何であったかをチェックできます。（p.133）

返り値の型がvoidのメソッドのユニットテストを書くときに、ダミーメソッドの引数が期待値通りかやダミーメソッドの呼び出し回数が期待値通りか検証するのもやり方の一つという気づきがあった。

実態の多様性を隠蔽するのが、オブジェクト指向プログラミングの核心部分です。その醍醐味を使うとき、次の課題として常に生成の分離が控えています。（p. 226）

OSSのソースコードを見たときに、interfaceの実装クラスが大量にあって追いにくいなと思った時があった。が、この追いにくさは隠蔽と抽象化が上手くできている可能性があって、今後どのように隠蔽と抽象化をおこなっているのかという視点でコードを読むという観点が自分に芽生えたと思う。

【雑記】稲作農家は赤字経営のところが多いのは本当か？

雑記 農業

まとめ

  • 前に雑談で稲作農家は赤字経営のところが多いという話をされて、感覚的には違和感を感じなかったが、数字として証拠はあるのかなと思いざっと調べてみた。
  • 令和3年度の60kg当たり全算入生産費と米の相対取引価格の値を見ると、作付面積が10 ha未満の農家は赤字となる。農業センサスによると、10 ha以上の作付面積がある経営体は全体の3%。よって、ランダムに経営体にヒアリングしたとすると、赤字と答える経営体の方が多いことが推測される。
  • 作付面積を大きくし農地を整備すると、稲作の現状とその課題についてのコスト削減事例にあるようなことが実現できる。しかし、春作業（育苗、耕起・整地及び田植）が規模拡大を阻害している。
  • 米生産コストをめぐる現状と対応方向によると、全体労働に占める割合は春作業に行う作業で耕起（13.3%）、育苗（19.2%）、田植（14.9%）が高い。一方、防除は1.8%、追肥は0.7%と秋作業で行う中間作業は低い値にある。

見つけることのできた農水省の資料

  • 令和3年産 米生産費（個別経営）

    • 令和3年度の60kg当たり全算入生産費は平均14,758円。個別経営の1経営体当たりの作付け面積は平均181.0 a。

    • 作付規模別の全算入生産費も記載されている。

      作付規模 60kg当たりの全算入生産費（円）
      0.5ha未満 26,903
      0.5ha ~ 1.0ha 21,353
      1.0ha ~ 3.0ha 16,289
      3.0ha ~ 5.0ha 13,080
      5.0ha ~ 10.0ha 12,161
      10.0ha ~ 15.0ha 11,188
      15.0ha ~ 20.0ha 10,244
      20.0ha ~ 30.0ha 10,786
      30.0ha ~ 50.0ha 10.277
      50.0ha ~ 9,040
      全国平均 14,758

  • 令和3年産 米生産費（組織法人経営）

    • 令和3年度の60kg当たり全算入生産費は平均11,293円。個別経営の1経営体当たりの作付け面積は平均2319.4 a。
    • (コメント)個別経営の稲作農家に比べて、3,000円ほど生産費が安い。
  • 過去に公表した米の相対取引価格・数量
    • 令和3年度の60kg当たりの相対取引価格の全国銘柄平均は12,804円。
    • 山形県のつや姫は 18,376円、新潟県魚沼のコシヒカリは20,426円と群を抜いている。
    • (コメント)平均値で見ると、個別経営の稲作農家は赤字ということになる。個別経営と組織法人経営の比率がどれくらい
  • 稲作の現状とその課題について
    • 3枚目のスライドを見ると、5.0 ha（= 500 a）以上の作付け面積がある経営対数は7%（経営体の総数は713,792件）。
      • ※資料では農業センサスの令和2年度の統計値を引用している。
    • 9枚目のスライドに米の生産コストの推移のグラフがある。
      • 生産費の中で労働費の割合が14,758円中、3,860円を占めており、比率の中では一番高い。
    • 春に行う作業（育苗、耕起・整地及び田植）が、労働費の中で割合が高い項目。
    • (コメント)個別経営の稲作農家に比べて、3,000円ほど生産費が安いのはスケールメリットのおかげ（10枚目のスライド）

      作付規模の拡大に伴い、自ら作業を行うことによる賃借料及び料金の減少、機械１台当たりの稼働面積の増加による農機具費の減少、作業効率の向上による労働時間の短縮等により、生産費は大幅に縮減している。

  • 米生産コストをめぐる現状と対応方向
    • スライド19枚目・20枚目を見ると、全体労働に占める割合は春作業に行う作業で耕起（13.3%）、育苗（19.2%）、田植（14.9%）が高い。一方、防除は1.8%、追肥は0.7%と秋作業で行う中間作業は低い値にある。
    • (コメント)数字だけ見ると、労働時間に占める割合で防除や施肥は低いが、作業が夏場になることなどから体力的また環境的に厳しいなど労働環境の問題はあるのか気になるポイント。
    • (コメント)平成25年の資料なので情報が古い可能性あり。

その他