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

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

無職日記(05/22 ~ 05/28)

はじめに

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

やったこと

所感

  • 放送大学の講義の受講よりも、横道に逸れて色々なことをちょこちょこ手を出した週であった。雑念が出て、放送大学の講義には比較的集中できない週だったと思う。
  • 放送大学の「解析入門」の複素関数関連の講義を受講する前の準備として、複素関数に関する本を読んだり、YouTubeの動画を視聴した。「解析入門」の講義はラジオ形式でテキストとラジオの音声で理解するのは自分に取ってハードルが高い。複素関数の講義をカバーする範囲の情報は頭に入ったと思うので、復習も兼ねて教科書を読んで、章末の演習問題を解いていく。

【放送大学 / 解析入門】第10章の演習問題の解答の導出過程メモ

はじめに

放送大学で「解析入門」の講義を受講している。章末問題を解くのに時間がかかったのと、巻末には解答しか掲載されていないので導出過程を残しておく。 講義では演習問題Aの1は(1)から(5)までは解説があるのだが、(6)だけまさかの解説がスキップされていた。この問題こそ解説が必要だろうと思ってしまった。

演習問題A

演習問題 1(6)

  • 他の問題と同じ収束半径を求める問題。
  • 問題を見るとnの階乗が出てくるので、ダランベールの方法で収束半径を求めようとしていたが、計算ができずに詰まってしまった。
  •  \sin (n\pi)/2はnが偶数の時は0、奇数の時は1か-1になる。それを利用して、コーシー・アダマールの公式を使って収束半径を求める。階乗が出てきてダランベール方式に飛びついてしまうが、そうすると解けないという引っかけ問題。
  • コーシー・アダマールの公式に従って計算をすると、nの階乗のn乗根の逆数が出てくる。これについては数列の平均の収束の定理を使って、nの階乗のn乗根が無限大に発散することを確かめて、逆数をとることで0に収束することを確かめればよい。

参考

『エンジニアリング組織論への招待』を再読した

本を整理していて、本の表紙に「技術的負債・経営との不和。プロジェクトの理不尽。上がらない生産性。そのすべての正体は不確実性の扱い方の失敗にあった。」と書いてあり、気になり出したので再読した。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング:書籍案内|技術評論社

2022年1月に昇進試験があり、そのときにマネジメントとは何か?みたいなお題で少し話す必要があったので、年末年始の帰省の間に読んだ記憶がある。 当時の私は上長の指示がふわふわしていて曖昧な指示が多いなと感じていたので、以下の文を読んで考えを改めた。この内容を昇格試験で話したら、面接官の管理職の一人がいい考えですねと言ってもらえて、受けが良かった記憶がある。

企業という組織は、組織全体を通じて、何かを実現するために、より曖昧な状態から具体的な状態に変化させるということをおこなっているのだと俯瞰できます。いわば不確実なものを確実なものに変化させる「処理装置」なのです。(p.13)

個人的な行動の観点として、以下の文を読んでこれはコントロールできることとできないものを意識するようになり、コントロールできないものは一旦置いておいて行動するようになって気が楽になった。1on1でコントロールができないものに対してはお気持ちとセットで上長に伝えるようにはしていたが...。

何か問題を感じたり、不安を感じたりしたときに、人は知らず知らずのうちに、「コントロールできないもの」をコントロールしようとして、さらに思考が混乱するとか、ストレスに感じてしまいます。何か、問題を解決したかったり、良い結果をもたらしたかったら、何がコントロールできるのか、そして何がコントロールできないのかを冷静に判断する必要があります。(p.40)

1年くらいマネジメントっぽいことをやって再読したことろ、マネジメントについて書いてあるところが目につくようになって、マネジメントをやったことも無駄ではなかったのだなと再認識した。リスク管理の本も読みたくなってきたので、再読して良かったなと感じる。

マネジメントとは、対象となる〇〇の資源・資産・リスクを管理し、効果を最大化する手法(p.136)

この本で複数の施策をどれか一つしかできないときに、それぞれのチームで観点が違うことが対立の原因になっていることが書かれており(「コストと売り上げ」や「資産と負債」の観点)、足並みが揃わない時はそれぞれが何をよくしようとしているのか?や今は何の数値をよくしようとしているのか?に立ち返って話すのもいいのかなと思った。

私がいた部署は新規事業のところで在籍した約4年間採算が取れない状態だった。会社としては力を入れると言っていたが、アサインされるメンバーはずっと新卒か未経験のメンバーしかアサインされず、本当に力を入れる気があるのかなと思っていた。この本を再読して、不確実性が高い新規ビジネスだったからアサインされるメンバーが新卒や未経験のメンバーが多かったのかなと思った(ベテランエンジニアに比べて給料が安いので予算が少なくて済む、採算が取れるようになった段階でベテランエンジニアとか投入するつもりだったのではないのだろうか?)。「人の行動に悪意を見出すな」といったようなことが書いてあり、理解できていたつもりであったが、経営陣に対してはできていなかったことに改めて気づいた。

何か新しいビジネスやシステムの開発を行うとします。将来性はありそうですが、不確かです。このように、不確実性が大きい段階で、大きな予算をつけて大きなプロジェクトを走らせると、失敗した場合にその投資のすべてが無価値になってしまいます。(p.46)

組織で働く中で自分がネガティブな気持ちになったら、再読すると新たな気づきがありそうなので、折に触れて読み返したい。

(余談)放送大学で数学を勉強していたり、サラリーマンになって社会学文化人類学や哲学に興味を持って勉強するようになったことに対して、自分の行動の意味が支援されている気がした。

工学とは数学と自然科学を基礎とし、ときには人文社会科学の知見を用いて、公共の安全、健康、福祉のために有用な事物や快適な環境を構築することを目的とする学問である。(p.10)

【備忘録】Java 15で導入された`sealed`について覚書

はじめに

Java 15から導入されたsealedについて何がよいか理解しておらず、業務でJava 11からJava 17にアップグレードしてから有効活用できずにいた。 いくつか記事を読んだので、自分なりの理解を備忘録としてまとめておく。

sealedを簡単にまとめると

  • sealedは直和型の実現をサポートする。直和型は、ある型が複数の具体的な型のいずれかとして存在することを表現する手法(TypeScriptでtype Foo = Hoge | Fugaのような感じ)。
  • sealedキーワードを使用することで、特定のクラスを継承するクラスを制限できる。
  • 直和型は、結果やエラーを明示的に表現し、柔軟な処理フローを実現できる。
  • Java 16から導入されたinstance ofJava 20で導入された型ごとのswitch文を使って、異なる結果やエラーの型ごとに処理を記述できる。
  • 直和型は、現実世界の概念を正確に表現するなど、ドメインモデリングの表現力を向上できる可能性がある。

sealedを使って結果とエラーを直和型で表現するのと、try-catch文を使うのはどちらが良いのか?

sealedinstanceofを組み合わせると、Haskellで出てくるようなMaybe型のような書き方がこれまでに比べて安全にJavaで表現できるようになったが、どっちを使うべきかの見解を書いておく。

特徴

sealedを使って結果とエラーを直和型で表現する場合の特徴:

  • 直和型を使用することで、結果とエラーを明示的に表現することができる。
  • エラーが発生した場合でも、プログラムのフローが途中で中断しないで書ける。さらに、instance ofswitch文を使って、異なる結果やエラーの型ごとに処理を記述することができる。

try-catch文を使用する場合の特徴:

  • 慣れ親しんでいるため(?)、シンプルなケースでは使いやすい(はず)。

結局どっち?

どちらを使うべきかは、具体的なコンテキストや要件に依存しそう。

直和型を使う場合

  • 複数の結果やエラーの型があり、それぞれに異なる処理が必要な場合。
  • エラーの種類ごとに異なる処理を行いたい場合。
  • エラーハンドリングを独自のフローで制御したい場合。

try-catch文を使う場合:

  • 特定のエラーに対してのみ処理を行う場合。
  • 既存のコードベースや慣習がtry-catch文を使用している場合。

おわりに

sealedの使い所について、少し理解できたと思う。直和型でモデリングした時にDBなどからデータを取ってくるときはどうするべきなのか疑問が残った(リポジトリ層でデータをまるっと取得して、データの内容によってどの型かどうか判断してインスタンスを生成する感じか?)。その点については引き続き考えていきたい。

参考

『「感想文」から「文学批評」へ』を読んだ

文学批評の歴史を踏まえて文学批評の各分野を説明してくれる入門書。

小鳥遊書房 本が本を産む|書籍一覧|「感想文」から「文学批評」へ

登場人物にまつわる要素で13という数字が出てきたら何かを裏切ることを示しているといった考察や、作者の人生やインタビューなどから作品のテーマを解読している記事や本が好きで、批評にはどのような歴史やどのようなジャンルがあるのか体系的に知りたくて読んだ。歴史を踏まえて文学批評の各分野の生い立ちを見ていると、健全な批判を繰り返して文学批評という分野が成長しているように見えた。

作品を理解するためには、作家の個性(性格・仕事・生い立ち・人間関係など)を理解する必要があるという「作家論」が十九世紀のヨーロッパで多くの人に受け入れられ広がった。しかし、作家というものが重視されだしたのは、16世紀から始まるヨーロッパの近代社会からであって、作家と作品を切り離して作品だけに着目して分析すべきだという「ニュークリティシズム」が生まれた。その「ニュークリティシズム」もそれぞれの作品の分析で留まってしまい、普遍性がないという批判を受け、全ての作品には共通する構造があるという「構造主義」が生まれた。

自分がソフトウェア開発をやっていたり、数学が好きだったりするので、「構造主義」に対して好印象を持つのだが、この「構造主義」も納得感の高い批判が出てくる。構造の取り方が主観的であるという批判や作品の書かれた社会や歴史的な背景を無視しているという批判である。作品の書かれた社会や歴史的な背景を踏まえて作品の声を分析しようというのが「イデオロギー批評」である。この「イデオロギー批評」も作者の作者の個人的な体験に過ぎず、ある集団のアイデンティを過度に一般化しようとしているのではないかという批判がある。このような批判を受けて「読者論」が出てきたり、さらに作者・作品・読者のいずれにも重点を置かない「メディア論」が出てきて、「読者論」や「メディア論」についてもわかりやすく解説されている。

本書を読んで、自分が批評のジャンルの中で「構造主義」や「イデオロギー批評」に強く関心を持っていることが分かったので、次はこの本を読んで更に批評に対して理解を深めたい。

批評理論を学ぶ人のために - 世界思想社

無職日記(05/15 ~ 05/21)

はじめに

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

やったこと

所感

  • 微分積分演習」の授業は受講完了、残りは「解析学」・「線型代数学」・「微分方程式」の3講義。受講し終わった講座は証明や定義が腹落ちしていないところは復習しつつ、未受講の講義を受けて期末の単位認定の試験に向けて勉強する。
  • Web通信指導は全て提出したので、期末の単位認定の試験は受けれそう。一旦区切りが良くなった。
  • Web通信指導があり、この2週間はプログラミングに関する勉強に時間が割けていなかったので、来週からはプログラミングに関する勉強に時間を割く。

無職日記(05/08 ~ 05/14)

はじめに

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

やったこと

所感

  • 「入門微分積分」についても全講義を一通り受講し終わった。「解析入門」や「線型代数」の講義を受ける準備が整った。05/15週はこれまでの復習もしつつ、残りのWeb通信指導の提出を目標に勉強する。
  • 『ふつうのLinuxプログラミング 第2版』を読んで、Linuxの構成要素が①ファイルシステム、②プロセス、③ストリームの3要素で大枠は説明できること、Webサーバの仕組みの概要が理解できたと思う。Spring Bootのリクエストのハンドリング部分を知りたいことが読み始めた背景だったので、Webサーバの仕組みの大枠を理解できた状態でソースコードを読むところに着手できそう。
  • 『「感想文」から「文学批評」へ』を読んで、文学批評の歴史背景を含めた各批評スタイルを勉強できた。今後、文学批評の本を読むときの基礎知識がついたし、批評を読む時にどのようなスタイルで批評しようとしているのか意識し始めることができそうで、もっと早く読んでおけばよかったと感じた。